When ozwdaemon starts up, it checks the status topic to make sure there isn’t another ozwdaemon running with the same instance number. For whatever reason, you either have two different ones running, or there was some failure to cleanup the topic, so the status is still indicating online. If you really have nothing else running, you can try using something like MQTT Explorer to delete the OpenZWave topics, then restart ozwdaemon.
I have only 1 openzwave "thing and that is this addon. nothing else, nothing more…
Very strange behavior since it eventually started after 3-5 minutes and retrying (!)…
EDIT: there is definitely something ‘unreliable’ here, at least in my setup. After it start thus as above I had 1 out of 2 motion sensor reporting everything but motion… (to hass). restarting the openzwave addon resolved that…
I have a GE/Jasco Dimmer that allowed me to rename it, it is forever “Master_Bedroom_L” until it dies lol
Looks like you had a unclean shutdown of sorts either on the broker or ozwdaemon. You need to clear that status topic.
Hi @Fishwaldo. it recovered itself. I had done nothing special. I just “rebooted” the host here (reboot):
Now every morning I am missing “readings” from sensors. They are alive, are working (motion is still detected) but sometimes lux and some times temperature is 0:
They are next to each other on my desk and its around 20 25 degrees here 
EDIT: manually waking the sensor quickly gives temp and lux “0” and then fills them with the correct value:
Where to start troubleshooting? Is this some sort of “homeassistant” thing forgetting the temperature is there is no updated value?
It seems to once in a day (in the morning after some period of sleep?):
HA is not renaming entity ID from existing devices. But if you name your devices thorugh ozw-admin before you add the integration to HA you will get “friendly entity names” aswell. I advice you remove the integration from HA, make sure you have named your devices in ozw-admin and after that re-add the integration!
In the ozw add on, where is the options.xml file if I want to set some things in there like log level… and also, where is the log file stored? I found an options.xml in the /data dir, but does that get re-written on updated?
Logging is now handled differently in the images.
You can set a environment variable before starting your image as such:
QT_LOGGING_RULES="*.debug=false;ozw.mqtt.publisher.debug=true"
For the following example log lines:
[20200615 4:09:28.218 UTC] [ozw.library] [debug]: Detail - Node: 11 Notification: ValueChanged CC: COMMAND_CLASS_METER Instance: 2 Index: 256
[20200615 4:09:28.219 UTC] [ozw.mqtt.publisher] [debug]: Publishing Event valueChanged: 1125900096405538
The first line would not be logged, but the second one would.
@Michael_Griffin thanks very much for this note about lock support - I never would have known the limitations just from reading the release notes, and it saved me the pain of trying to migrate followed by making this discovery then migrating back.
Although, I suppose, most of that information can probably be derived from alarm_type and alarm_level.
I have three Kwikset Z-wave locks, one of them with a keypad, and I think I will wait until there is more complete lock support. In the meantime, unfortunately, my locks are not especially reliable using the built-in Z-Wave support.
That is how the lock_status attribute is compiled, it accounts the type and level and displays it in a readable form. You can do this from the exposed sensors, and using a lock manager package from the Share your projects section.
Wouldn’t happen to know how to do that in the add-on? and then where the log and options.xml are stored?
If you use the default docker container it’s in /tmp
I’m mid-process transferring my setup (again) from zwave to ozw using the addon. This time I made a list of node#'s and their associated entity_id’s, in hopes of making the process of renaming entities a lot easier (not having to walk around opening/closing all the windows 1 by one, etc).
For example, I’ve got 15 identical “Ecolink Door/Window Sensors” listed under devices that I have to rename, but how do I tell them apart without node#'s? Is there an easier way to rename entities after the ‘upgrade to ozw’, other than physically triggering devices to ensure you’re renaming the right one?
You can get the node ID from the sensor.
Example:
1 Like
HAHA, thanks for helping a blind man out! 
Aah, this is going to be so much easier than before.
1 Like
You could always dump your node list into a spreadsheet on google docs as well so you have a copy handy 
1 Like
So, have been holding off on this, but the addition of locks has got me itching to try it out. So just to clarify, the entities for lock, alarm_type and alarm_level are all working? Anyone ran into any issues or just minor annoyances? And it sounds like at this time that setting, or clearing codes it not yet supported. Did I read that right? Also, so I dont have to ask, is there a place I could go to see what capabilities are available for the various device types?
Thanks in advance
Does anyone know if this is still the case? So I have MQTT running on my NAS (natively, not in a docker), with a username/password, and Home assistant running on my NAS in a docker. It is currently working with HA without OZW. Should this work as is now, or should I wait a bit?
Yup you have to enable them, they’re disabled by default.
I’ve noticed my lock status not updating quick enough, but I think that may have been fixed in the latest update to ozwdaemon, I’m still checking.
Not sure, kwikset doesn’t support clearing codes per their manual.
I guess you could dig thru the ozw integration on home assistant’s github.
I have my MQTT on a seperate docker container and have ozwdaemon use that for MQTT same as HA and anything else I have that using MQTT. 
1 Like