I have the restart policy set to unless-stopped. I know the container was running when I finally manually restarted it. Hope this gets addressed somehow.
What version and image are you using?
Allinone-latest
Except that it does not really do that (at least not ā-latestā, and not always):
See MQTT client timeout Ā· Issue #140 Ā· OpenZWave/qt-openzwave Ā· GitHub
In these cases ozwdaemon keeps running, and is stuck at 100% cpu when the connection to the MQTT broker is cut off.
1 Like
@Olen I wonder if this is related to https://github.com/OpenZWave/qt-openzwave/issues/150
Seems something gets overloaded and the MQTT connection doesnāt get serviced and then the daemon crashes/shuts down.
1 Like
After installing the latest version of OZW 0.6.0, my Zwave network stopped working.
Be careful installing the update!
Indeed same happened for me, just rolled back to my recorded snapshot of before the upgrade.
Iām now using the polling workaround on 5 of my switches. It seems that it polls a device every 6 seconds, and therefore all 5 devices every 30. Unfortunately 30 seconds is a very long time here. I see the ability to change intensity, but there must be somewhere to set the polling interval? Any ideas?
You can set the poll interval via options.xml, or use the undocumented setpollinterval command, which takes a payload of:
{
"interval": <integer>,
"intervalBetweenPoll": <bool>
}
However, I have not seen these settings have any effect, so I donāt know if itās really possible at this time. Alternatively, create an automation that published an mqtt refreshvalue command on a timer, and use any interval you like.
Polling too often can have a negative effect on the performance of your network.
Excellent! I was unaware of the ārefreshvalueā MQTT command. That allowed me to move my 2 dimmer modules off of polling and just refreshing them 4 seconds after any command to them. For the remaining 3 switches that donāt report manually, I think Iām going to have to aggressively refresh them. I donāt like it, but I donāt have a better option right now. 3 refreshvalues (1 per switch) every 5 seconds is quite sufficient, and I doubt will have too much of a performance hit on the network.
I have begun my migration to the new QT-OpenZWave. I am trying to rename the device and auto update the entity idās (like the popup mentions) and sometimes it doesnāt work. Only the device name is updated. Any ideas why? Any easy way to āmanuallyā update a few items that doesnāt involve multi clicks per device? Screenshot of mentioned popup below.
If you click Ok on that dialog it should rename the entitiy_ids as well, if itās not occuring itās usually due to the entities having been renamed already.
Is this still the future path? Itās difficult for me to follow updates or progress since thereās been no movement in the public repo for over 2 months and no response to critical issues like the one I filed several weeks ago. Right now Iām completely blocked and not sure what to do.
Iām contemplating moving to Zwave2Mqtt as a possible resolution, which seems to continue to see active development. Has anyone made a move in that direction?
1 Like
I dont have an answer for you but am curious as well as to why there have been no updates lately. I canāt complain much as my setup seems to just work right now. I had a crash a couple of weeks ago from the OZWD container that required a restart, but other than that, been rock solid since. It is nice to restart Home Assistant as much as you want and not have to wait for the network to reload.
1 Like
I too am starting to get worried. Iāve raised my concern in a separate thread https://community.home-assistant.io/t/srt321-zwave-thermostat-setpoint-still-not-supported-and-winter-is-approaching-fast/231077 but Iām wondering if I need to revert to the previous ZWave implementation (or ZWave2MQTT) to get my thermostat working properly
Iām considering reverting as well.
Well, his last activity on GitHub was in August, so maybe he is just taking a vacation 
If he would be unable to work on ozw anymore, this would have an impact on zwave2mqtt as well, as it is also based on open zwave, where fishwaldo is (one of the) the main contributor(s).
I had the same concern 
Can anyone help with this. Iām just getting to understand the mqtt.publish stuff.
This worked for my ge dimmer that was having issues reporting
topic: "OpenZWave/1/command/requestnodedynamic/"
payload: "{\"node\":127}"
this did not
topic: "OpenZWave/1/command/requestnodedynamic/"
payload: "{\"ValueIDKey\":2202632209}"
I used mqtt explorer to get the valueidkey.
Before I dig deeper just wanted to verify my format. Thanks in advance for any help