The problem is, HA sometimes takes a very long time to shutdown.
It’s running on a fairly large server. CPU usage is low during during the shutdown process. My best guess is that it’s waiting on ZWave (Aeotec USB Stick) to shutdown. I came to this conclusion because if I comment out the zwave portion of my config, shutdowns are VERY fast.
I don’t add new devices/platforms/components very often. So I don’t mind waiting for a shutdown in those times. But I’m adding new automations all the time. And automations often require an input_boolean/text/datetime or a timer… but I’ve found ways to work around that. However, template sensors and binary_sensors also make the automations a lot more readable. And updates to those require a restart.
So, I’m looking for solutions to the slow restart problem. I’ve come up with these, all with their own difficulties.
-
Move ZWave outside of HA. This means I need a ZWave appliance or separate piece of ZWave software with an API. For appliances, there is ISY (expensive), Smart Things (cloud only), Wink (slow, probably cloud only), and Vera (which I’ve heard a lot of complaints about). For software, I’ve found zwave-mqtt-bridge (https://pypi.org/project/zwave-mqtt-bridge/) which is where I’m leaning at the moment.
-
Make template sensors and binary_sensors reloadable live. I’ve tried my hand at altering the HA code to handle this. There are quite a few places where I get caught up in the weeds though as it’s a fairly complex bit of code, heavily tied into HA internals and my Python skills are beginner, at best, and my knowledge of HA internals even less.
-
Borrow code from template sensor and binary_sensor to make my own custom_component that doesn’t rely as heavily on HA internals and supports reload. This wouldn’t actually be too difficult, but I worry that my component will break one day with an HA update because it’ll be unofficial and yet relying on quite a few existing HA libraries to get the job done in the easiest way possible.
Thoughts?