How about using a MQTT server on the Pi (to not be depending on HA and network availability) and bridging it to the HA MQTT VM? Works fine for me 
1 Like
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.
In which case, it was a poor design decision.
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.
1 Like
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.
1 Like
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.
Good point. It’s a good thing I’m not one of them. 
“because I said so” may win in an argument with your children but it’s less than satisfying in these kinds of cases.
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 
1 Like
You have to run it on something if it is remote to the HA machine.
1 Like
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.
It doesn’t have to be remote. I just prefer it remote 
I did compile a ozwdaemon container with a longer timeout that anyone can use if they’d like.
It’s the standalone version no vnc, but you can use ozwadmin from your desktop (which I highly recommend).
1 Like
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.
1 Like
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.
2 Likes
Oh, sorry, my bad.
I thought you said there was a good reason for the current behavior and, therefore, agreed with it.
Nevermind then…
Yeah, we are on the same page. I didn’t mean to argue one way or the other, just state the current reality.
2 Likes