I have been up and running for a week now, with no issues so far. I have 17 nodes, all wired switches/dimmers, GE, Zooz, and Homeseer. Double tap scenes and led notifications all working.
The only thing I haven’t done yet, is to pair/add a new node.
I tried it out last night, but I had to revert because it doesn’t appear like my lock, leak sensors, or smoke alarms were supported yet.
Were there (or could there be) any issues reverting if things don’t work? I currently run on a Z Stick Gen5 and want to try this out since I soon need to do a significant update anyway to my HA setup. If I install the new software does it make any changes to the contents of the Z stick that would need to be undone?
For me, there was no issue reverting, except that I lost all the custom names of my devices. I just had to go back through and rename everything to match back up with all my automations and lovelace cards.
I reverted back to my zwave2mqtt by restoring a full snapshot.
Which smoke alarms do you use?
I migrated over to this today now that it supports MQTT authentication (PR exists but hasn’t been merged yet).
All of my lights and switches work perfectly but as expected my front door lock does not. But as this is using MQTT I went about trying to use an MQTT Lock. I managed to get it working successfully.
First you need to find the command class you want to trigger. I used mosquitto_sub to look through the data at OpenZWave/# and found the following.
OpenZWave/1/node/2/instance/1/commandclass/98/value/39354384/ {
"Label": "Locked",
"Value": true,
"Units": "",
"Min": 0,
"Max": 0,
"Type": "Bool",
"Instance": 1,
"CommandClass": "COMMAND_CLASS_DOOR_LOCK",
"Index": 0,
"Node": 2,
"Genre": "User",
"Help": "State of the Lock",
"ValueIDKey": 39354384,
"ReadOnly": false,
"WriteOnly": false,
"ValueSet": false,
"ValuePolled": false,
"ChangeVerified": false,
"Event": "valueAdded",
"TimeStamp": 1583006263
}
The two important parts required here are the ValueIDKey and Value. ValueIDKey is the command ID we need to trigger and Value is the current state of the lock. True in this case shows it is currently locked.
To test unlock the door I used mosquitto_pub to send a command to change the locked value to false. Unlocking the door.
mosquitto_pub -h localhost -p 1883 -t "OpenZWave/1/command/setvalue/" -m '{"ValueIDKey": 39354384, "Value": false}'
To re-lock the door the command can be changes to “Value”:true.
Now that works it is just a matter of constructing an MQTT Lock within the HA configuration. We know the lock and unlock commands as well as where in the json the current state is. As well as the state is either true or false for locked and unlocked.
lock:
- platform: mqtt
name: Front Door
command_topic: "OpenZWave/1/command/setvalue/"
payload_lock: '{"ValueIDKey": 39354384, "Value": true}'
payload_unlock: '{"ValueIDKey": 39354384, "Value": false}'
state_topic: 'OpenZWave/1/node/2/instance/1/commandclass/98/value/39354384/'
value_template: '{{value_json.Value}}'
state_locked: true
state_unlocked: false
Hopefully this will help someone construct unsupported devices using MQTT directly.
5 Likes
I would expect that work. You probably need to wake it up (remove the batteries, hold down the test button, insert batteries) so that it sends its node info to OZW. Since the cache file has changed, you’re essentially starting from scratch. All battery devices will need to be woken up to send their node info in order to have all the entities exposed.
I have migrated my test server to the new Z-Wave MQTT and everything seems to be up and running. I have a few questions:
-
OZW-Admin - I seem to be missing a manufacurer DB where does it exist? I downloaded the config and that seems to be working
-
Adding Nodes etc… - How do I add new nodes etc, I was assuming OZW-Admin would do this for me, but I dont see how?
OZW-admin is very basic at the moment. I’ll fix up the database issues very soon.
For “Network Commands” it’s not support yet. Right now you can only issue MQTT payloads to the right command topic for that.
I’ve got basic functionality up but now want to convert my center scene commands. Previously I’d trigger on the specific id and data that the relevant manufacturer used for the various taps. Now it looks like that gets sent over in the scene_activated event but also sent is a string that describes the meaning (e.g., “Pressed 2 Times”). Will these string descriptions be standard across manufacturers? I.e., it would be nicer to just always trigger off the same thing if they are (plus being more clear in the automation code). Or am I missing some other function that I should be using. Looking for the suggested best practice for responding to a central scene event.
It looks to me like the string responses for Homeseer switches are reversed. I.e., pressing the top of the paddle sends a “Bottom Button Scene” and pressing the bottom sends a “Top Button Scene”. Where would this get corrected? (I.e., I’m happy to post an issue in the right github but I’m not sure which.)
One more question: I have mostly Homeseer switches and these are working ok. However, I have a single Inovelli switch and it is not. When I turn on the switch from HA it sends a setvalue command just as it does for the Homeseer units. I looked at the value id and it corresponds to the command class 37 value that was read from the Invelli switch during startup. So the correspondence looks correct and it is trying to set the value to true (which would be on). However, unlike the Homeseer units which get an immediate response with the new state as on, there is no response from the Inovelli unit. This worked ok under the old zwave stuff. It appears that somewhere in OpenZWave or the OZW mqtt adapter, things are getting lost. Is anyone else using an Inovelli switch successfully and/or where would this issue get reported?
I am going to be starting a complete fresh install of Home Assistant.
Is it better to use this implementation of ZWave (knowing it is alpha-ish) or should I use the old integration. It’s for production but I can monitor it all.
Well for me zwave2mqtt is broken, my door sensors all die on reboot and when they are alive they aren’t triggered at all by doors opening and closing.
I’ve also ended up with duplicate sensors for each in HA. This one seems to be a bug that was reported previously and should have been fixed as it was patched and closed.
I’ve raised a bug report on github but for now need to go back to zwave in HA.
I hope this breaking change isn’t forced on us too soon!!!
The advice for anyone would be to use the built-in ZWave implementation. If you want to help develop the next implementation and are happy to put up with a few bugs or the occasional crash, use this version. Raise issues on github for any bugs you find and even better, if you’re able to, create pull requests to fix issues 
There will be a well documented or automatic migration from the current ZWave implementation to this once it’s ready.
3 Likes
thanks @JumpMaster.
I’ll stick to the default integration for now for the production system, but I might also setup a development system just to play with this new integration. I am not great with programming skills, but it never hurts to have an extra “beta” tester to help with bug reports.
Ok I have created an issue on github and can provide further diagnosis but can’t afford to be down further than 2-3 days hence.
When is it likely that this change will come or is it way into the future?
zwave2mqtt is not the same thing as qt-openzwave.
2 Likes