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:
- Probably feminine
- Not a very common name, like Mary, Linda, Susan, etc.
- 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)
- 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 🙂