When last we left our heroes, Home Assistant was running via SD card on a Raspberry Pi 4 B with 4GB RAM. Why was that not OK?

Well, the biggest thing is that SD cards have a finite life and as the primary hard drive for a continuously running system, it is subject to significant writing action over time. The operating system does stuff, Home Assistant does stuff, both of them log activities, etc. Some SD cards are optimized for longer write time, but in short, SD cards can actually wear out.

The SD card I used to install Home Assistant on the Raspberry Pi was not new, but probably has plenty of life left. Still, I’d rather use a drive intended to be a hard drive.

Running a Raspberry Pi on an SSD drive is pretty simple, though with the Pi 4, we are limited to USB adapters. I didn’t want to have such a critical component hanging on the end of a plug in cord, so I was happy to see a recommendation for the Argon One case for the Pi4. Specifically, I ordered the case equipped with an M.2 SATA adapter, along with a relatively unknown brand 64GB M.2 SSD.

The Argon One case is pretty nice in several ways, but the cool part here is that the basic case holds the Pi 4 in the top of the case and bottom cover is interchangable for a plain bottom or a bottom equipped with an M.2 SATA adapter. It uses a clever U shaped plug to connect the adapter to the bottom USB 3.0 jack on the board.

The Argon One case adapts the micro HDMI on the Pi4 to standard HDMI, if that matters to ya. In my application, I don’t need it, but if I use a Pi for something else, that will no doubt be handy. It also adds an actual power switch and still gives access to all the I/O pins.

Since I was upgrading anyway, I checked stock at Adafruit and found that they had 8GB Raspberry Pi 4 boards in stock, so I got one of those on the way as well. May as well do all the upgrading at once and be done with it for a while.

The process for setting up a Pi4 to boot on SSD is pretty straight forward. First, I used my USB to M2 adapter to put a Home Assistant image on the 64GB SSD, the image provided by Raspberry Pi Imager. Then in the utilities section, there is an image to put onto an SD card that sets the boot order in the Pi to try SSD first, which I burned to a handy SD card I had laying around. I booted on that SD according to the directions, then booted on the SSD in my USB adapter and it came up. I did not do all the setup as I wanted to wrap everything up in “permanent” fashion in the new case first.

It was at that point that I discovered that my 64GB SSD would not quit fit the socket in the case adapter. Much trial and error and even a little forcing revealed that, although it was not mentioned as so on the ordering description, the 64GB SSD was apparently an NVMe SSD and the case adapter specifically is not NVMe compatible. Not only was the non-NVMe drive a little cheaper, all indications were that NVMe speeds were wasted on Raspberry Pi hardware. None of that would help me right then.

I also found that M.2 SSDs that are verifiably not NVMe are really hard to find. Apparently nobody is looking for slower stuff anymore. If I found one at all, shipping times were long. I decided that the best bet was to look back to Argon One and get their upgraded NMVe base.

It took a couple of days to arrive and a few more to reach a point when I could dedicate some time to work on it. Everything looked ready to go, but the 64GB SSD would not boot up. As part of verifying it, I put it back in the USB adapter and put it on my PC. The PC would show the adapter plugged in, but as a drive with 0 bytes. Long story short, after several attempts at recovery, I concluded that somewhere in the previous attempts to use it, perhaps in the steps involving force, I must have damaged it. I gave up, drove to WalMart and got a Western Digital 500GB NVMe for less than $50. I think it may have been $34, but I don’t remember for sure.

Back in the late 1990’s, I was in the San Francisco area for work. We went to the local Fry’s electronics and found they had a fantastic deal on 1GB SCSI hard drives for about $300. It was still a lot of money, but imagine what I could do with a GIGABYTE of hard disk space?!?!? Try to find something that small now. Not even at WalMart.

Anyway, skip back to the part where I put the images on the SSD and from there forward, everything worked perfectly, including backing up the “old” 4G system and restoring it on to the new system. My Home Assistant is now running on a Raspberry Pi 4 with 8GB RAM and a 500GB SSD with 458GB free space.

The new case provided two big improvements. First, while i liked the heat sink wrap ‘case’ I had it in before, the Argon One case does look better, especially to my primary customer. Second, the fans on the heatsink case were iffy on day one and one of them had already just quit, so it ran hotter than it needed to. The system is inside a closed cabinet with a 16 port PoE switch and two NAS units, so it’s a little warm in there already.

The big improvement, however, is speed. Particularly if a process involves reloading or rebooting, the SSD is significantly faster than the SD card. Updates take far less time than they used to, which is important since there are so many of them, especially at the beginning of every month 🙂

If I were to pick one disadvantage to this new setup versus running Home Assistant as a virtual machine on the NAS, it’s that the VM method gave me the snapshot tool. With it, I could completely hose the system and have a snapshot to restore from, either the automatic weekly snapshot or if I thought I was going to break something, a specific ‘before’ snapshot. There isn’t really a substitute for that particular freedom with the current setup.

No, not me. Home Assistant, moving off the server farm. The tiny tiny server farm.

My Home Assistant instance runs ran as a virtual machine hosted on my Synology NAS. It had grown enough that after the last update or two , it had started hitting some performance limits for the virtual machine settings. It can take 30 minutes for a reboot to complete and I have had to wait overnight for everything to settle down. It would probably help if I started these tasks before bedtime. Anyway, the CPU never shows as super busy, but the memory climbed up in the 80% range a few times, so I presume that it had run short enough on RAM to started paging virtual RAM. The RAM, already virtualized, being substituted by virtual RAM from a hard drive that is busy recording video from a bunch of cameras plus doing other NAS stuff can’t be the best way to do that. I can understand why performance would suffer.

Unfortunately, there weren’t enough resources available to resolve this in the Synology. The NAS is a DS220+, which is configured with the maximum of 6GB RAM. The Home Assistant VM was configured with 3GB and the system would not let me bump it to 4GB. Understandably, that would leave only 2GB for everything else the NAS is doing. I was able to walk it up to the max it would let me assign, 3683 MB and that took two runs at it. After all that, it wasn’t enough to make any difference.

A few weeks ago, I noticed that Adafruit had the Raspberry Pi4 back in stock. I wasn’t specifically thinking of migrating Home Assistant when I ordered it, but after the last Home Assistant update traumas, I thought it might not be a bad idea. After all, my thoughts have been to migrate Home Assistant to a fanless PC I have.

Not my picture, but this is the unit I have 🙂

Anyway, because the procedure for deploying Home Assistant on a Raspberry Pi is well established, streamlined and pretty easy, I elected to go for it and see how it went. I didn’t really time it, but from the time I decided to start until it was up and working with all my existing devices was no more than 2-3 hours, probably less.

I have proof that my Home Assistant instance had grown a lot. I made a backup about a year ago in a test run to move off the VM and on to the Kodlix GN41 hardware. While that was semi-successful, I elected at that time to stay on the VM. In any case, that backup was still on the system. The current backup was only 6 times larger.

Immediately, I could tell that the GUI was more responsive. I also restarted it a couple of times and the system was up in way less time, minutes instead of hours.

Due to extreme frustration a few months back, I removed the USB dongle for ZWave and basically decided that Zwave was less important than an otherwise stable system. I absolutely needed the Zigbee dongle because several devices, most notably the lights and fan in the back yard, as well as all of the battery operated sensors, are Zigbee. I essentially abandoned ZWave. The only active ZWave devices at the time were two wall switches for some outdoor lights and a few underutilized signal repeaters. The two switches were replaced with Tasmota switches and I moved on.

One of the issues that I seemed to have with the Synology VM was that the USB subsystem is apparently pretty sensitive to disconnection. If something disconnected the USB cable or I had sudden amnesia and forgot that this caused problems and unplugged one of the dongles, it would be an absolute crapshoot as to whether it could come back without arcane procedures, most of which probably did nothing. Also, from what I can tell, the VM would not pass more than two USB devices to Home Assistant, which meant I would not be able to add anything other than the two dongles.

Emboldened by the success with the RPi4 thus far, I plugged the ZWave dongle back in and found that it came up without issue. Of course, no devices are deployed, but there is time to do that. This is cool because I have a Zooz ZEN32 scene controller that I do want to use, which is why I got it! I am looking forward to replacing one of the three way switches in the kitchen then using the other four buttons on it for various outdoor switches.

Speaking of outdoor switches, I had gotten a little lazy and let the batteries go on several of those Zigbee devices. With the new controller in place, I woke all that stuff back up and had forgotten that I had set up a couple of neat automations.

I have one that turns on the back yard lights when the back door is opened after sunset. That is almost always going to be when letting the dogs out. Then again, we just about always turn the lights on before letting them out, which can be done with either a voice command or a button mounted by the back door. 🙂

I also have a couple of handy, if slightly irritating, automations that announce if the refrigerator door is left open for too long. This was intended to help address a problem with the garage fridge, where heavy loading can sometimes cause the door to not close completely and it’s easy to miss it. I put regular door sensors in place, the transmitter on one door, the magnet on the other. If either door is not closed within two minutes, Home Assistant announces through three of the Alexae and sends a notification to my phone. The problem is that the kitchen fridge doesn’t reliably sense the door closing, so pretty much any foray into the box is reported as it having been left open 🙂

Before the hardware swap, one of the updates had a change that somehow broke the motion activated switch automation that I had in place in my workshop. I had followed some timer advice offered by Smart Home Junkie to use a motion detectors to automate a light in my workshop. This worked really well, but a December 2023 update apparently moved some cheese and broke that process in some way. After the update, the timer elements in this automation showed up on the System/Repairs list. I did some digging and found a blueprint that actually does a MUCH better job of automating not just a motion controlled light but really any binary sensor controlling any switch or scene or even another automation. It also has gobs of options for behaviors based on based on schedules or other sensors. A motion detector in, for example, a bathroom, might do nothing during daytime hours, turn on the room light after sunset, but turn on only a nightlight between midnight and 8AM.

I am going to update that back door automation with this blueprint. I need to resolve the kitchen refrigerator door sensor issue, probably by putting some spacers to get the magnet away from the metal door. My burglar alarm career experience pays off again.

The most exciting thing coming down the pike is native voice control. I have the parts and guide to build a custom speaker/mic device using ESPHome to perhaps wean us off the Amazon cloud dependency that is Alexa.

Incidentally, I have a coworker named Alexa who goes by Alex to avoid the unintended consequences of speaking her name aloud. I presume she resents having her life hijacked by a system that offers only lesser wake words as alternatives. Surely Amazon has the computing power to offer more than one alternative. Then again, branding: nobody doubts that the name “Alexa” really belongs to Amazon now. I’m sure they would copyright it if they could.

It occurs to me that the powers at Amazon probably did massive amounts of data sorting to find a name that was:

1. Probably feminine
2. Not a very common name, like Mary, Linda, Susan, etc.
3. Unique enough to not often be confused with other common words (Mary: airy, Barry, berry, carry, dairy, fairy, Gary, hairy, Harry, Jerry, Kary, Kerry, Larry, merry, nary, parry, Perry, query, tary, Terry, vary, very, wary)
4. Ok, maybe more than just those things…

Remember Home Assistant? This is a post about Home Assistant… 🙂

I have a couple of M5 Atom Echo devices, but I have had some trouble getting them to come up. Not sure if it’s me or them, but I have had good success in the past with ESPHome and the ESP8266 and the ESP32.

The voice module is just 4 components, an I2S microphone module, an I2S speaker module with a 3W amplifier, a speaker and the ESP32 microcontroller. This will be my first foray into I2S audio connected to a device. I2S is basically a synchronous serial protocol consisting of a data line, a data clock line and a ‘word select’ line that is more commonly called the left/right clock. The data line and data clock carry audio information, typically but not necessarily encoded at 44.1 kHz, with the word select alternating to indicate whether the data is for the left or right audio channel. In the case of this monophonic device, I presume we don’t need 44.1 kHz audio or two channels but ESPHome actually does most of the heavy lifting here and I have not done the deep dive as yet, but I did learn from a shallow dive that I2S requires the ESP32 and is not supported in the lighter ESP8266 variant. That might double the price from $3 to $6 🙂

Home Automation really is a kind of delicate balance of things that really aren’t supposed to happen at all, so when it all works, we are so happy. Even though it was a pain in the butt, I found this particular failure somewhat entertaining. I also learned a bit in fixing it.

We have a Roomba. There are a few places where I have deployed Roomba Virtual Wall devices to corral her (Your mileage may vary, but I’m pretty sure mine is female) and keep her out of areas where she will get into more trouble than she can get out of. One such area is under a chair where there is a floor mounted outlet with an extension cord plugged in and another is under a couch where that extension cord continues and powers a lamp at the far end of the couch. This lamp is equiped with a smart bulb, specifically a CloudFree Tasmota based smart bulb.

The batteries have gone out in virtual wall under the chair. Roomba was thus not restricted and in her wanderings under that chair, the cord was partly dislodged. This left a bad connection for the extension cord and intermittent power to the lamp. This was not detected immediately and the condition may in fact have been present for several days without incident. Last night, however, I walked through the room and upon stepping on the rug that this furniture is on, I saw the lamp flicker. That made me investigate and in that process, it would appear that the timing requirements of reboot cycle reset sequence were satisfied (either just then or perhaps earlier) and the bulb began flashing, a sure indication that it had been reset and lost it’s configuration.

It would take a while to discover the details but it would turn out that it had been reset hard enough for the ESP8266 controller in the bulb to have forgotten what it was connected to, to have forgotten that it was once a light bulb!

The ESP32 family of microcontrollers is extremely popular with manufacturers of smart devices. It is designed to do that sort of thing. Tasmota is essentially a replacement operating system for ESP32 microcontrollers, writen specifically to support the kinds of peripherals that common smart devices have on board. Many smart devices have the necessary physical connector or at least the solder pads on the circuit pad to connect to and reflash the device’s storage so that off the shelf devices can be ‘upgraded’ to Tasmota.

In the case of my CloudFree smart bulbs, the come from CloudFree already flashed with Tasmota and ready to use. Chances are that these are the same smart bulbs that some other company (or many other companies) sells, maybe Tuya or someone else, but they are still just a mass produced Chinese product with some LED peripherals connected to an ESP32 controller.

To operate an LED array, the GPIO pin needs to be configured as a PWM output, whereas to operate a switch, it would need to be a digital output. There are a handful of options. Tasmota simplifies controlling these options by a shorthand called templates. You create a template with a string of parameters that tells each pin how to operate and by extension, what controls to expose for those pins. It really is quite clever.

Mind you, I didn’t know any of this. I just knew that, once I got my bulb back on WiFi, it still didn’t work and that my other two working bulbs had full menus and under Configure Module, they had “CloudFree LBC” as the first choice and that was not even on the list in this bulb.

Google helped less than I would have hoped, but looking at CloudFree’s website helped a bit. On the description page for the bulb was some info that I would think would not normally be in the *sales* info for a smart bulb:

Of course, by itself, that doesn’t help, but it lead me down the right path. I remembered this screen when exploring the menus on my subfunctional bulb:

The pulldowns have various functions, such as Button, Switch, Rotary, PWM, etc.

I figured that I could duplicate the settings from one of my working bulbs and get a long ways towards restoring the functionality.

Now, in a bit of storytelling license, I didn’t show you the whole page, partly because the problem is already solved, but this page is called “Template Parameters” and it has the template name “CloudFree LBC”, which is the missing module name from the earlier mentioned list. From here, it is easy enough to duplicate a template, but it turns out that there is an even easier place, under Configure Other.

The single line in “Template” is a comma delimited list of the parameters from the “Configure Template” page. One copy from a working bulb, one paste here, one restart and suddenly, “CloudFree LBC” is once again an option. Another restart and the bulb is working again, just like that.

To be clear, Tasmota does ALL the heavy lifting here. Once Tasmota knows a port is PWM, it knows to give the main screen a slider to control it. The PWM parameters tells it the GPIO pin is a member of a 5 channel RGBCCT group, and which member, with channels for red, blue & green and two white channels for adjusting color temperature in white. Tasmota builds the main screen with RGB color, white color temperature and separate brightness controls accordingly. I do wish the white brightness was adjacent to the color temperature slider like the RGB brightness is next to the RGB color, but oh well.

Looking back at the CloudFree bulb sales page, red, green and blue are on GPIO 4, 12 & 14 respectively. Cool white is on GPIO 5 and warm white is GPIO 13, so those are 4 & 5 respectively in Tasmota.

I already like Tasmota for how easy it was to configure these bulbs and some switched power monitoring outlets I also got from CloudFree, but this shallow little dive into the inner workings lead me to appreciate it even more.

Ok, maybe that’s a bit much.

I had a couple of really busy months adding and changing stuff in Home Assistant. A lot of it was adding something, breaking something else, fixing that, adding something new, breaking something else, ad nauseum.

However, at some point, intentionally or not, I ended up kinda leaving it alone for a while, mostly at or after Christmas. I tweaked some dashboards and adjusted a timeout here or there, but really I just didn’t do a lot with it for a while.

My wife had knee surgery. To keep the herd of buffalo that we call Dachshunds from trampling her knee and so that her completely unnatural sleep “schedule” would have the smallest impact possible, she set up shop in the spare bedroom. I put a Tasmota bulb in the lamp and moved one of the Amazon Echo devices in there so that she could control said lamp without necessarily having to get up. The Echo is also handy as an intercom when I am working elsewhere in the house and she needs something.

Trouble is, Alexa would work fine controlling the lamp (or any devices) for a couple of days, then she’d claim there was no such device. Or she would ding like she had turned it on or off, but it didn’t do anything. That would go on for a day or so, then she’d be back to controlling devices again.

I made sure my wife had the Home Assistant app on her phone and a dashboard that had all the general stuff she cares about controlling so whenever Alexa got stubborn, at least she could still control the lamp and the thermostat.

Importantly, Home Assistant always controlled the devices. Alexa, not so much. But Alexa always worked for stuff that didn’t involve Home Assistant. Clue numero uno.

I Googled every combination of ‘home assistant alexa unreliable’ and similar keywords and it seemed like all hits were things about troubleshooting an initial connection between Alexa and Home Assistant. Nothing about Alexa’s moodiness.

During the time I wasn’t doing a lot of work on Home Assistant, I didn’t have cause to connect remotely, via the Nabu Casa cloud, but a couple of days ago, I did. I immediately noticed that a bunch of stuff on my dashboard was grayed out, like the devices were offline. I had notifications and there were 9 (!) updates pending, including an OS update. An OS update was very recently done and I wondered what went so wrong that they had to update the OS again, although that kinda made senseas to why there would also be a bunch of other updates, responding to that one.

I decided that I was definitely not going to do all those updates remotely and I would just wait until I got home to start working on it.

I got home, logged in. All devices look fine, no updates pending.

WTFO?

I opened a new browser tab and logged in via Nabu Casa and I had missing devices and pending updates. I checked the logs from both logins and they both had current entries, but not the same entries. Clue Numero Dos. Then I noticed that a change I had made to my dashboard only the night before was not there on the dashboard via remote. Clue Numero Tres!

I looked for a while for some feature or button that would synchronize the two, but no luck. I cried ‘uncle’ and submitted a ticket to Nabu Casa about it.

Meanwhile, I was chatting with a friend who is also running Home Assistant, the friend who had in fact got me started down this road. He suggested that maybe I had two Docker containers running. Well, he didn’t remember that I had abandoned running Home Assistant as a Docker container originally because there had been so many weird hoops to jump through just to add HACS and secondly because running it instead as a VM meant that I can recover from egregious errors by restoring a snapshot backup. 🙂

In any case, he is not an idiot and neither am I, so I followed his advice and verified that, no, I had no rogue VMs or Docker instances running.

About that time, I got a note back from Nabu Casa. The tech also suggested that, especially from the clue with the logs having entries that were in the same time frame but different, that there must be another instance of Home Assistant running. He detailed some sometimes people spin up a VM or a Docker to try it out, then install to hardware and forget about the Docker and leave it running. He suggested checking the Network menu on both to see what the IP addresses were.

I didn’t have to do that because as soon as I saw the word ‘hardware’ in his note, it reminded me.

Early in December, before Christmas, before my wife’s knee surgery, one of the things I was looking into was moving Home Assistant off the VM and onto a fanless PC I have. The idea was to escape a perceived issue with the USB dongles for Zwave and Zigbee, having recently spent an embarassingly long time getting them working again after what should have been, at most, a mild interruption. In any case, I was able to successfully bring up Home Assistant on this hardware device and, after a fashion, restore a current backup to it. I verified that all my configurations, dashboards, etc. had all moved over. I just didn’t want to commit to moving the USB devices for fear that there would be some issue with the PC then for some unknown reason, I would not be able to bring them back up on the VM. Besides, the snapshot backups are a pretty good reason to stay on the VM for now. So, I shut down the PC and didn’t think anything of it.

Well, spurred by the tech’s phrasing, I verified that the fanless PC was up and that was indeed the instance of Home Assistant that Nabu Casa we connecting to!

I looked into the logs deeply, particularly for anything to do with rebooting and sure enough, there it was. December 13, we lost powere at the house for several hours. The NAS and Home Assistant hosted there showed the reboot on the 13th, as did the Home Assistant running on the fanless PC. The little PC did what I’m sure it was configure to do, boot upon restoral of power. Since it probably booted up faster than the NAS and VM, it was first in line to authenticate to Nabu Casa.

Both systems were probably syncing with Alexa, so whichever had sync’d last had her attention. When she couldn’t find a device by a name I know was there was probably when she was connected to the PC and the names on it hadn’t been changed. Since I never logged into that one, none of those nine updates had been applied yet. The dashboards on *that* system had not been editted.

It’s unplugged now.

And Alexa is going on four days of continuous cooperation.

Update: 9 days and Alexa has been reliable. For this, anyway.

After I finally beat the dongles into submission, it took a little while to discover that many of my devices did not seem to be operating, but in reality, they were just not responding to verbal commands via Alexa.

Complicating things is that I was also dealing with some WiFi trauma while settling in the new Ubiquiti gear. I was suffering a lot of disconnections and I could not be 100% sure that the WiFi devices that I was trying to control may not have just been switching on and off like a crazy monkey. Short version on that seems to have been overzealous roaming defaults with only two fairly distant APs, but that is a story for that blog.

Once the WiFi was settled down, if not solved, it was obvious that Alexa could definitely see all the devices. I could change a device name and it would be detected, but I still could not control any devices with verbal commands. There were a couple of responses but by far, the most common was that there was no <device> in my profile. Sometimes, I would get that the device was not responding. What I would never get is a device that was controlled.

The timing for this failure is abysmal. My wife just had knee surgery and in preparation for that, I made sure the lamp in the bedroom where she would be staying (she must avoid the dogs for a while) had a smart bulb in it that she could control verbally, except that verbal control wasn’t happening.

After trying no shortage of useless stuff and random restarts of various services, I was getting to be on the right track and had tried removing the skill from Alexa. In Googling about that, I stumbled across a forum posting where someone suggested removing one file and restarting home assistant. I chose instead to rename that one file, just in case. Well, praise Jack Bauer because it worked. All the Alexa stuff works again!

Well, I had to re-re-rename some things back to normal, basically clean up the messes I made troubleshooting. I’ve had to do that a lot lately.

The file in question is /config/.storage/cloud. My old one was 3 times the size of the new one that the system created automatically to replace the missing one. It had several blocks that seemed to be associated with Google devices (of which I have zero, so far as I know) but generally, it was just a bigger file with more stuff in it. I’m sure there was redundancy or perhaps one scrambled line in there.

Now that I can tell Alexa to turn on the Christmas tree and she does, of freakin’ COURSE the rotating base for the tree would stop passing power through to the lights. It is always something.

With apologies to Ian Anderson.

Full disclosure. I am still not entirely sure exactly which of the myriad steps finally worked or what order of steps I finally accidentally hit, but the Zigbee and Zwave dongles just came up working again. Furthermore, it’s actually been a few days since that happened, so my memory of it is imperfect as well.

The all critical final step, however, is emblazened in my retinas forever. After doing this SEVERAL times already, removing and adding back the USB devices at the virtual machine level in the Synology NAS, with at least some number of minutes/hours/decades delay seems to let something reset enough that the device is not only detected (which it has been all along) but also works.

Of course, the damage I had done troubleshooting needed to be undone. Some devices had lost their names and almost worked. They had reverted to the default names given when the devices are first interviewed, generally some variation of their brand and model number.

Most of these were pretty easy to figure out, either by being relatively unique (at that point, I had deployed only one Third Reality motion sensor) or by what automation was still associated with the device. Curiously, those automations didn’t work until the name of the device was adjusted. For the afore mentioned motion detector, I had set up a fairly sophisticated timer automation as suggested by Smart Home Junkie and parts of the automation needed to adjusted with new device names as well.

I have all but one or two of those names resolved now, mostly because I just haven’t walked to the doors or plugs in question and verified which was which. Soon.

This power event did inspire me to look into moving Home Assistant over to dedicated hardware. Whether that is really justified depends on whether the advantages of dedicated hardware outweigh the advantages of hosting it as a VM and that really comes down to how it handles USB hardware under unusual conditions like an unplanned power loss.

Raspberry Pi hardware is still very hard to obtain, but I have an Celeron N4100 based fanless PC that is more than adequate to the task. I had a false start (not all the installation methods install identical versions), but did manage to get a suitable Home Assistant image on it and was able to restore a backup of my current configuration. For personal reasons beyond merely being the week of Christmas, I don’t want to tear into the actual move of all these devices to that hardware just this moment. After the holidays, I will revisit it.

On the heels of solving one problem comes another.

We had a scary storm nearby a few days ago.

This is just a few miles north of us and it is just a tiny bit of the storm damage. It took power out for our neighborhood, though only for about two hours. That was long enough for the little CyberPower UPS feeding my network stuff to run down. It was also the first time I have had something hooked up back there that was apparently sensitive to losing power, namely my Home Assistant VM hosted on a Synology NAS.

Before I get into the rest of this story, I’ll say that my UPS does have a USB port, but it is not specifically listed on Synology’s compatibility page. Still, I will secure the proper cable and give it a try. Doing an orderly shutdown of the NAS might have avoided this whole thing. Or not; I suppose that depends on what it takes to finally fix it.

After we got power back, the Home Assistant VM would not finish booting up.

Note that it had been waiting for nearly 6 minutes for whatever it was holding up for. Deep digging seemed to indicate that a database file for something may have gotten corrupted, meta.db. About the time I was figuring this out, I also remembered that I have the Synology doing nightly snapshot backups of this VM!

Though just this moment I don’t remember why, I elected to restore the snapshot from Dec 11. I have also since then locked that snapshot so that it won’t be rolled out. I may need it again.

That process at least got Home Assistant booted up and usable, though it took me a while realize that the Zigbee controller was not up. Zwave was up and working, which was a relief after the previous debacle involving it. I needn’t have worried, though. The attempts to restore Zigbee operation would soon kill ZWave, too.

The details of both seem to indicate that the software can’t find the hardware. Almost surprisingly, however, the hardware is there.

The kernel sees them. So, why can’t Home Assistant?

My first concern is Zigbee because I have more devices on Zigbee and they include the lights in the back yard, used frequently for letting the doggies out. The oldest of these doggies has enough trouble finding the door in the daytime.

For experimental purposes, I also tried another snapshot option wherein you can configure a new VM from one of these snapshot backups. Interestingly, it generates a new bogus MAC address, so DHCP gives the new instance a new IP address. That was slightly unhandy, but easy to fix. The oldest December snapshot, from the 4th, behaved exactly the same, which leads me to believe that this is probably not a filesystem issue, so I have put back the December 11 snapshot and have been working with it.

I tried something kind of radical and deleted the Zigbee Home Automation (ZHA) integration. Home Assistant discovers the dongle like a newly installed piece of hardware:

Unfortunately, it returns an unknown error upon attempting to configure it.

If I instead choose to Add Integration and search for Zigbee, I get these options:

The first option is the same as trying to configure the new hardware. The second option complains that Zigbee integration is not yet set up, but gives an option to proceed to set it up:

It proceeded to look very normal, like it was going to work:

Then, it ground to a halt.

There is something new here, though. It looks like it has the same port in there twice, neither working.

If I click on either of those, I get the same ‘failed to set up/check logs’ message as always, so insanity.

To break the chain, I have ordered Sonoff’s *other* Zigbee device, based on the Silicon Labs chipset. It would seem they had cause to add to the Texas Instruments architecture, whether it was to help assure a diverse supply chain or in pursuit (or retreat) of some features. I hope to know soon.

A few unrelated projects has postponed tackling the plumbing part of putting the other two water meters in service. Meanwhile, I have been tweaking the behaviors and such for a couple other bits.

The heatlamp for the water system has turned itself on every day. It was indeed chilly for several days, so it wasn’t inconceivable that maybe it reached my low temperature trigger of 36F in the garage, but a couple of days over 50 that still had the light on every morning made me start actually checking.

I used one of the Emporia switches (cloud controlled; none of my Zigbee switches monitor power and that is a whole ‘nother conversation) so that I could monitor the power consumption of the outlet and thus detect a burned out bulb. The log showed some curious stuff though. This thing loses contact all the time.

If you look carefully, you can see the pattern. It becomes unavailable, then exactly one minute later, it comes back, appearing to change state, but I think it just renews it’s current state. That goes on as far back as you care to scroll.

However, at 6:00, something turns the switch on, then this same pattern just keeps repeating with the new status.

I checked the automation on the water temperature sensor and the outside temperature sensor, even though I had not automation for *this* switch for outside temp.

Finally, I found it. In the Emporia app on my phone, there was a schedule to turn the switch on at 6AM every day. I had originally deployed this plug out in the workshop for the horse trough and I wanted to ensure it was not accidentally turned off and left off. I disabled the scheduled.

The light was on the next morning.

I deleted the schedule and it finally stopped. 🙂

In related news, I have two CloudFree P2 plugs. These are plugs preconfigured with Tasmota and it turns out they have very extensive power monitoring capabilities and no cloud dependency. I have removed the other Emporia plug that (for reasons I don’t recall) was also deployed for the horse trough and put a CloudFree P2 in it’s place.

As you can see, it gathers a lot of power statistics. Currently, there is a recirculating pump that is running basically all the time. It is important, but not particularly critical. However, I am about to redeploy the deicing heater and if it goes out, particularly during freezing conditions, I need to know about it. The automation I have in place currently will notify me if it draws less that 10 watts for more than 10 minutes which would currently only tell me if something disconnected the pump, which one of the horses used to do on occasion. The pump draws 108W pretty much continuously. The heater pulls 1200-ish watts when heating and about about 1/2W when idle, presumably to work it’s thermostat. I presume I could script something to separate a pump failure from a heater failure, even though they run on the same outlet. I have more than once thought about separating them. At the very least, I could run them on two switch plugs.

The bad news is that I only ordered two of the CloudFree P2 units and one of them turned out to be DOA. I have contacted CloudFree about it (no reply, but it has not even been 24 hours yet) but I also ordered several more. I will have other things to control and/or monitor and especially at $10 apiece (Black Friday 2022 pricing apparently; back to $13 as I write this, but still a great price), they are a great little bit of kit.

I had some difficulties excluding and including my old Jasco ZWave switches to my new controller, but all appears forgiven now. I pulled the air gap power plug thingy on them and that seemed to properly reset them enough for them to be happy.

I dug into the wiring for a couple of 3 way switches in the kitchen. They are wired in the 2nd least favorite way for conversion to the Jasco switches I have had on hand for several years, but with some minor rewiring, I can make it work. I will post that separately one day. The one I really want to change out is a set of lights in our sunroom that is tecnically a 4 way, with one switch in the living room that is almost never touched, but is sure to complicate things, wiring-wise. I really want to deploy my Zooz scene controller where the kitchen located switch for that sunroom light is and use it to control several things.

The barn/workshop automation has to be all Zigbee or Wifi. I don’t think I can reasonably extend the ZWave network out there. That isn’t expected to be a problem; I have good Zigbee and excellent WiFI out there. I have a couple of Zigbee light switches, but I’m not sure how they handle 3 way connections as yet. I may need to deploy some wireless toggle switches for those remotes.

I put a new battery in the Ecolink tilting garage door sensor that I have had since Vera was new, along with putting a ZWave repeater in what I hope was a suitable place to extend the network into the garage, but the switch was last heard from on 16 days ago as I write this. I may try again now that the two light switches are working and helping to provide a little more network stability.

Before I discovered ESPHome, I had gotten a Zooz Multirelay with the idea of using it for the water filter project. As it turns out, a couple of it’s features are not particularly well suited to the needs of the water filter, but they are entirely suitable for automating garage door openers.