Thanks, but still error Not Found (“No such image: homeassistant/amd64-addon-zwave:0.3.0”)
Got about to the same point as you did… except my ‘problem child’ is a garage window vibration device rather than a cover. Interesting seeing how the new ozw configures entities as far as naming and entity id conventions. Also some new and missing old entities swapped about.
For example, my aeotec g5 door sensors used to have a battery entity that never worked properly (always 100%), and now the integration doesn’t even add a battery entity (good, expected). Also, my ecolink flood sensors have a few added entities, including a freeze sensor which I’m not sure how it even works. Glad to be on the ‘upgradeable’ train now, regardless of having to get used to the new stuff.
Also, not sure if it will work itself out but I’m guessing due to the somewhat random timing of my removing and replacing covers on my devices (this triggers the tampering switches, which wakes the devices) left me a handful of the devices that seem to not be responding to the tamper switch… these entities always say the cover is open, and don’t change if I remove/replace the cover. I just did a reboot to see if that fixes it, but seems the devices have to wake on their own now to show up (the original integration showed such entities immediately after reboot).
Good bit is you can just make a mqtt sensor or what not to fix most things like that while you report an issue so it’s fixed 
Oops, I rebooted the pi and now all the battery powered devices are unavailable… don’t seem to be coming alive as a wait either. 
This is a deal breaker for me, since I have several devices that never wake unless I stick a paperclip in them. I lose those devices after a host reboot?
Because the addon does not currently save the cache file, which saves that data. Rebooting it loses the cache file. The next release of the addon should fix that.
This is a deal breaker for me, since I have several devices that never wake unless I stick a paperclip in them. I lose those devices after a host reboot?
You’ll have to have a little patience. 
The integration is beta and the addon itself is “experimental”. If you can’t tolerate some issues then you might want to hold off for now.
2 Likes
OK that makes more sense thanks. I thought this was more ready for prime time, but I guess not without a cache file. I’m in no rush so will roll back my ‘production system’ for now, but I wish I knew this before I renamed everything.
Add ‘instance : 1’ to the data if you are getting errors saving the settings in the add-on.
It is listed as optional, but seems to actually be mandatory at the moment.
Edit: Just noticed this was already mentioned above. I am a couple of days behind on this thread 
thanks Brendan
much thanks to the devs for their quick work on this. the new add-on update is awesome with the ability to use ozw-admin and i assume devices can now be renamed via ozw-admin and the names will survive reboots since the persistence is fixed…
EDIT: i guess renaming names via ozw-admin would not be a good idea since it might be going away in v1.7. i am renaming them in HA instead, waiting to see if they revert back or not though.
I don’t like this at all. I had several occasions this screwed up my config especially using multiple zwave devices of the same brand/type. To me the possibility of renaming through ozw-admin is a must-have to have clear and obvious names in HA. If it’s not in v1.7 then it should be, or at least in the ozw-daemon just like it is now.
I strongly agree! Even in the ‘old’ days, I used to shut down HA and start up the OZW Control Panel whenever I acquired a new Z-Wave device. I would set up the parameters there and, more importantly, rename the device before bringing it into HA.
About a week ago, I migrated from using the old Z-Wave integration to the new beta one. I’m running the OZW daemon (with OZW admin) in a docker container. Renaming the devices via OZW admin makes it so I can recognize the devices in HA, no matter what. And on top of that, I can rename individual entities of those devices in HA to suit my own logic and naming scheme. That’s a win-win situation for me.
1 Like
In HA 0.111, lock support was added, but unfortunately, it was very basic support–only lock, unlock, and battery.
A big missing piece of lock support is the “lock_status” attribute that existed in the old zwave integration. This attribute would have text like
Unlocked with Keypad by user 1
Manually Locked by Key Cylinder or Inside thumb turn
Looking at the code for the old zwave integration, it appears as though there was a lot of logic baked into the integration to determine that status. Is that something that is in the plans to port to the new ozw integration?
I know that user codes and admin is also missing, but that has a workaround via MQTT if necessary.
2 Likes
I would not advise using ozw-admin to rename devices, at least currently. If you lose your cache file (ozwcache*.xml) file for whatever reason (corruption, deleted, etc), you will also lose all of the names in HA. If you rename devices and entities within HA they are persistently stored in the entity registry. If you name them outside they will not persist.
Thats sounds clear. Is it on the roadmap to do it from within ozw? Can’t it be done “on the stick”?
From what I have seen is that the entity ID in hass hower is not renamed but taken over from ozw. Only the friendly name is “renamed”. Correct?
Can’t it be done “on the stick”?
The node naming exists, I believe, because some devices do actually store storing both a name and location (COMMAND_CLASS_NODE_NAMING). However in reality almost no devices implement this, none of mine do. The cache file is the alternative then.
From what I have seen is that the entity ID in hass hower is not renamed but taken over from ozw. Only the friendly name is “renamed”. Correct?
Right, so for me that’s not helpful. The entity ID names are more useful to me than the friendly names.
Yes, I agree now. Though it is very handy havind them from ozw…
One other thing… my battery sensors have 3in1, motion, temp and lux. After a day 1 of both (exactly equal) and sometimes one, sometimes the other, hass displays 0 for temp and 0.0 for lux. They do report motion correctly and upon waking an lux chage thes also gets updated including temp… what is this odd behaviour?
Ok just had restarted my complete hass instance (core). Now my openzwave won’t start anymore…
Can’t find why…?
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "downloadlatestmfsrevision"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/downloadlatestmfsrevision/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "enablepoll"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/enablepoll/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "getpollinterval"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/getpollinterval/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "hardresetcontroller"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/hardresetcontroller/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "hasnodefailed"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/hasnodefailed/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "healnetwork"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/healnetwork/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "healnetworknode"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/healnetworknode/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "isnodefailed"
[20200613 18:43:34.121 CEST] [ozw.library] [info]: Info - Node: 0 Lookup for mfs.db.openzwave.com returned 96
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/isnodefailed/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "open"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/open/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "ping"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/ping/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "refreshnodeinfo"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/refreshnodeinfo/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "refreshvalue"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/refreshvalue/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "removeassociation"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/removeassociation/")
[20200613 18:43:34.121 CEST] [ozw.library] [info]: Info - Node: 0 Serial port /dev/serial/by-id/usb-0658_0200-if00 opened (attempt 1)
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "removefailednode"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/removefailednode/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "removenode"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/removenode/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "replacefailednode"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/replacefailednode/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "requestallconfigparam"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/requestallconfigparam/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "requestconfigparam"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/requestconfigparam/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "requestnetworkupdate"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/requestnetworkupdate/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "requestnodedynamic"
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/requestnodedynamic/")
[20200613 18:43:34.121 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "requestnodeneighborupdate"
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/requestnodeneighborupdate/")
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "requestnodestate"
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/requestnodestate/")
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "sendnodeinformation"
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/sendnodeinformation/")
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "setpollinterval"
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/setpollinterval/")
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "setvalue"
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/setvalue/")
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "softresetcontroller"
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/softresetcontroller/")
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "syncronisenodeneighbors"
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/syncronisenodeneighbors/")
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "testnetwork"
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/testnetwork/")
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Creating Subscription for "testnetworknode"
[20200613 18:43:34.122 CEST] [ozw.mqtt.commands] [debug]: Subscription Setup for QMqttTopicFilter("OpenZWave/1/command/testnetworknode/")
[20200613 18:43:34.122 CEST] [ozw.library] [debug]: Detail - Node: 255 Queuing (Command) FUNC_ID_ZW_GET_VERSION: 0x01, 0x03, 0x00, 0x15, 0xe9
[20200613 18:43:34.122 CEST] [ozw.mqtt.publisher] [debug]: Topics: "OpenZWave/1/status/"
[20200613 18:43:34.122 CEST] [ozw.mqtt.publisher] [warning]: Another ozwdaemon is running for Instance 1
[20200613 18:43:34.122 CEST] [ozw.mqtt.publisher] [warning]: If not, please clean up the MQTT Topic: "OpenZWave/1/status/"
[20200613 18:43:34.122 CEST] [ozw.mqtt.publisher] [warning]: "{\n \"OpenZWave_Version\": \"1.6.1137\",\n \"OZWDaemon_Version\": \"0.1.0\",\n \"QTOpenZWave_Version\": \"1.2.0\",\n \"QT_Version\": \"5.12.5\",\n \"Status\": \"starting\",\n \"TimeStamp\": 1592066404,\n \"ManufacturerSpecificDBReady\": true\n}"
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Detail - Node: 0 Notification: DriverRemoved
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 ***************************************************************************
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 ********************* Cumulative Network Statistics *********************
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 *** General
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 Driver run time: . . . 0 days, 0 hours, 0 minutes
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 Frames processed: . . . . . . . . . . . . . . . . . . . . 0
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 Total messages successfully received: . . . . . . . . . . 0
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 Total Messages successfully sent: . . . . . . . . . . . . 0
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 ACKs received from controller: . . . . . . . . . . . . . 0
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 *** Errors
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 Unsolicited messages received while waiting for ACK: . . 0
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 Reads aborted due to timeouts: . . . . . . . . . . . . . 0
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 Bad checksum errors: . . . . . . . . . . . . . . . . . . 0
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 CANs received from controller: . . . . . . . . . . . . . 0
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 NAKs received from controller: . . . . . . . . . . . . . 0
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 Out of frame data flow errors: . . . . . . . . . . . . . 0
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 Messages retransmitted: . . . . . . . . . . . . . . . . . 0
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 Messages dropped and not delivered: . . . . . . . . . . . 0
[20200613 18:43:34.123 CEST] [ozw.library] [debug]: Always - Node: 0 ***************************************************************************
[20200613 18:43:34.123 CEST] [ozw.library] [warning]: Warning - Node: 0 WARNING: Tried to write driver config with no home ID set
[20200613 18:43:34.123 CEST] [ozw.library] [info]: Info - Node: 0 Stopping DNSThread
[20200613 18:43:34.129 CEST] [ozw.daemon] [warning]: =============================
[20200613 18:43:34.129 CEST] [ozw.daemon] [warning]: CRASH!!! - Dumping Backtrace:
[20200613 18:43:34.129 CEST] [ozw.daemon] [warning]: =============================
[20200613 18:43:34.129 CEST] [ozw.daemon] [warning]: #1 0x00007f0ecba7427d sp=0x00007f0ec89e8380 sigwaitinfo + 0x8
[20200613 18:43:34.129 CEST] [default] [warning]: Exiting....
Debug - Node: 0 Downloads Remaining: 0
Info - Node: 0 ManufacturerSpecificDB Initialized
1592066614: Socket error on client qt-openzwave-1, disconnecting.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
1592066614: mosquitto version 1.6.8 terminating
1592066614: Saving in-memory database to /data/mosquitto.db.
[s6-finish] sending all processes the TERM signal.
Restart, restart, restart container (addon) and now it is starting… what is wrong here? Is it just me or?
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