I’ve recently moved my HA instance to a VM and had to install ozwdaemon on a different machine (Pi) because the VM server is remote. It’s exposed a weakness with the current implementation of ozwdaemon.
Currently, ozwdaemon checks for the existence of the MQTT server before starting, and then immediately quits if it loses the connection - not very resilient - rather than retrying until it re-appears. Not a problem when ozwdaemon is installed as a hassio-addon, but a problem otherwise.
I’ve raised it as an issue on github, but I wanted people to be aware because it’s made my ZWave network very unstable because of all the restarts.
As a stop-gap, I’ve created a systemctl service to restart it if it exits. This gets it working again, but the ZWave network is a mess.
It’s got me to thinking: is it more reliable (long term) to use a purpose designed ZWave hub rather than an AEOTEC stick on a Pi with ozwdaemon? (The same applies to Zigbee).
This is by design. You shouldn’t be restarting the host so often, and if you need to, maybe look into throwing the stick in a Pi and run the docker container with a mqtt broker on the Pi as well setup to bridge to your main MQTT instance. This is how I mitigate having to do restarts of OS updates on my docker host where HA lives.
I have HA on Pi and connect it to my server using the HA API
I add devices on PI
I use template integrations to add entities on remote HA server
Eventstream and statestream can be used as well to connect HA instances but MQTT entities are not handled as cleanly as API since with API I can better control name, type and combine into one entities.
Quite a convoluted setup, all you need for a remote ozwdaemon setup is docker and the ozwdaemon container. Point the MQTT to your MQTT broker and set the OZW_INSTANCE to 2 if it’s the 2nd daemon on the broker.
Visual representation (note this shows a bridging setup):
This doesn’t seem to be a very convenient “design”.
Why should I buy a pi just to run the zwave network just because the zwave to mqtt connection isn’t resilient?
I would think it would be better to fix the mqtt zwave connection issue than to require people to buy another dedicated machine or force them to restart their zwave instance just because MQTT got interrupted as that is a big selling point for the new ozw because it’s supposed to decouple zwave & HA.
None of my other IOT devices need to reboot if I lose the MQTT server so they can reconnect. Why is OZW any different?
This is a known problem, and second oldest open issue on Github.
For a workaround use a local MQTT broker that is bridged to the main broker as suggested by @firstof9. The local broker connection will be much more stable. In fact, the HA OpenZWave Addon works the same way.
It will not solve the problem 100% of the time. I noticed my ozwd restarting everynight. Turns out the nightly backup on my RPi3 consumed all resources, causing every single MQTT client connection to timeout and disconnect. For scenarios where the connection is lost for reasons like rebooting hosts, it’s a fine solution.
I could easily provide a reason that justifies this behavior, but the simple answer is because that’s the way the developer wanted to implement it.
Networks are never 100% available. End-point devices should be designed to cope with the occasional network dropout - not just quit.
Most users won’t have the problem because they install the daemon on the same docker server as the mqtt sever and HA. Some (like me) take advantage of the MQTT architecture to move the daemon to a more convenient place.
This is what I did as well, when I first started using HA it was on my PI3B+ with my zwave stick. Once the new beta rolled around and had decent basic support, I migrated my HA instance from venv to docker containers on a server machine and left the zstick in the Pi.
Some people insist on having a supervised install too, still technically coupling all their containers to HA in a fashion
I have mine setup the way it’s setup because I started with the Pi running HA then migrated it when I was able to decouple zwave from HA. The way I have it setup allows me to run OS updates and what not on my big docker server without bringing down the zwave network. I find it handy.
I’m sure it’s not the ultimate way fishwaldo would prefer to implement this, ideas have been thrown around that the mqtt publisher should have it’s own thread and handle reconnecting on it’s own.
Unfortunately no one has submitted a PR for such functionality as of yet
But why does it need to be remote from the HA machine?
Of course, if it had to be remote (for some reason) then a Pi is a great option. I just don’t see the need to force it to be remote from the HA machine just because OZW isn’t resilient enough to be able to reconnect to the broker.
This is a bit backwards. If anything, the recommendation is to keep OZW and the MQTT broker on the same host. If you move OZW to a remote host separate from the broker, you will more likely hit this problem, as OP has observed, because any kind of network issue can result in a timeout. If the broker is local to the OZW host, there aren’t any network issues to worry about. In that case, your main source or problem is from restarting the MQTT broker.
The timeout is a separate issue though. If you shutdown the MQTT broker the client connections are terminated and OZW will shutdown regardless.
yeah, I get that. I was responding to the impression that I got from that post that the idea was that it was expected somehow to be run on a remote host. I run OZW, HA and MQTT all on the same machine myself.
I should have been more clear and instead of saying “it” I should have said “OZW and the MQTT broker” because that’s what really meant.
Right. But that shouldn’t be an issue either. Which is the point I’m trying to make.
You said it was by design. I think it’s a poor design if so. There should be a way to allow OZW to re-establish the connection to the broker. All of my other IOT devices can do it and they all run on a simple NodeMCU/Esp8266 either programmed by me or ESPHome and even HA itself can accomplish the task.
I don’t know how qt-ozw works so maybe I’m wrong but re-establishing an MQTT connection so your zwave network doesn’t go belly up on a network glitch seems like a basic function that needs addressed before it is adopted as the default HA zwave implementation.
You are preaching to the choir. Like I said, the github issue is still open with tags “enhancement” and “help wanted”. The design today doesn’t mean it’s necessarily permanent, but it doesn’t magically get implemented without someone writing the code.
