Hello there. I was waiting for this to come. So I gave it a try but without luck… Do I need to pair again all devices after switching to this integration ?
I reverted back to the “old” integration with restoring a snapshot.
@SNoof85 No, you don’t need to rebuild your network: it’s stored on the stick.
There is only limited support at the moment though. There’s a lot of activity on GitHub, so hopefully, 111 will support more platforms. Switches work for me, but I’m waiting for climate.
Gareth
After few hours on this i’m unable to make it work. I have only fibaro fgd212 in my zwave network. I see that everything looks good from the ozw add-on but I can’t see any message on my mqtt so I think this is my issue. I did not found the reason for now…
Edit: seems that openzwave addon runs it’s own mosquitto. would it conflict with my mqtt that is already running with the official addon for zigbee2mqtt ?
Yes, I recognise that.
I cant get the deamon to connect to my own mosquitto instance. It needs to be the mosquitto addon to connect to. Tried everything. I have asked about this above, but I got no reply, so I assumed I was the only one being stupid enough not to understand it. 
Or maybe this is the wrong topic as its the openzwave topic, not the daemon topic, I dont know.
But what i can’t understand is that i am using the mosquitto addon. Unless i did something wrong I’m not sure why the ozw daemon addon needs to start his own mqtt 
Nevermind, will wait for more stable things around this as i don’t want to screw up my production
I would imagine MQTT in Open Z-Wave Daemon needed to send messages to MQTT on HA. The Open Z-Wave Daemon translates from Z-Wave to MQTT, which will be running in the Daemons container, which it then sends to the HA MQTT.
No the topic is set by ozwdaemon it will not change if switch MQTT brokers -
You can check OpenZWave/# using mqtt explorer or even Home Assistant > developer tool > MQTT
Not everyone reads all the post, it’s easy for something to get lost in the shuffle or overlooked. I can’t tell you the number of times I’ve seen someone ask a question that was literally answered only one or two posts above their own ( I’m not saying you did that, just the point, it’s not people ignoring you, but could be people just aren’t reading your questions. ) Consider creating your own thread to ask for help or joining the discord server – Sometimes it quicker to get a reply, sometimes people may be able help in real time. No need to feel down on yourself – Everybody has to start somewhere
@RogTP pretty much said it here
So in total there are three parts to using this.
1 - ozwdaemon – This is either an add-on or it could be in a docker container ( Even a "bare-metal install but there are no instructions for this yet ). Just needs to running somewhere on your network ( I used a RPI to make dedicated device for ozwdaemon )
2 - A mqtt broker ( I use mosquitto ) running somewhere – This could be an add-on, a docker container, a “bare-metal” install or even in the 
cloud – ( I use a “bare-metal” install running from a jail on my FreeNAS server )
3 - Open ZWave (beta) - This is the new Z-Wave integration for Home Assistant – Install from the integrations page in Home Assistant – Also note, this is the same component as the HACS pre-release. The name has been changed as it moved from pre-release to beta. This name change was to aviod confusion with the unrelated zwave2mqtt project.
Hopefully something above could provide you with a clue to move forward. I’m sorry I can’t really help with anything specific to configuring an “addon” because I’m running Home Assistant Core from a virtualenv – I have never used an “addon” before
3 Likes
It is hard coded in the addon to be the local one (127.0.0.1):
1 Like
Hopefully that gets changed to be a config option before this gets added officially.
So I’m maybe wrong but that means you can’t run ozw and a mqtt broker for other any application that needs it ? Like zigbee2mqtt.
Thanks for the explanation. I have it running now, including my Fibaro FGRM-222 roller shutter. Cover component is configured like this:
- platform: "mqtt"
name: "level_mqtt_ozw"
command_topic: "OpenZWave/1/command/setvalue/"
set_position_topic: "OpenZWave/1/command/setvalue/"
set_position_template: "{ \"Value\": {{ position }}, \"ValueIDKey\": xxxxx }"
position_topic: "OpenZWave/1/node/24/instance/1/commandclass/38/value/xxxxx/"
value_template: "{{ value_json.Value }}"
position_open: 99
position_closed: 0
payload_open: "{ \"Value\": 99, \"ValueIDKey\": xxxxx }"
payload_close: "{ \"Value\": 0, \"ValueIDKey\": xxxxx }"
The one thing not working is the stop functionality. But I am not really using that.
And while looking at the payload_open/payload_close I may need to check that again. It may be swapped.
It was not working. Now it does work. The QT-Openzwave endpoint does not accept a value of 100, only 99 as a value for open (up).
2 Likes
Thanks for the reply, and to the others who did as well ofcourse.
Yeah, you pushed me in the right direction. THANKS!
Now I have the Daemon running (not the Add-on but in docker), and it is connecting to my separate MQTT instance.
I have Proxmox with Ubuntu container > Docker. I managed to get the USB stick to be passed through and used in the docker run command. Now I see the daemon doing its work, and see the info landing nicely inside the mqtt mosquitto broker not the addon one.
Now, Open Zwave Beta shows the info correctly. There are now 16 devices with 120 entities.
But, as known and expected, I see less devices than I have.
Just to inform: the devices I currently miss:
Shenzhen Neo Electronics Co Ltd Door/Window Detector
Shenzhen Neo Electronics Co Ltd Battery Powered PIR Sensor V2
Philio Technology Corp PH-PAT02-B.eu Multisensor 2in1
I will wait before I continue with the migration to mqtt untill the most ‘critical’ devices are working ok.
Good work on the dev team !!!
PS, I wasnt feeling down. I was a bit making fun in a self-depreciating manner. Ghehehe…
Actually now, I feel quit proude of my achievement, just having my first real linux experience since 1.5 months 
IN proxmox. I have never touched the stuff before. Now, I love the speed and stabillity of it. It just works.
Thanks. Good to know the cause now. I stopped trying to fix this in HA itself
Agreed. Hope so too.
As a work around, you could bridge the brokers. I’ve done this in the past, and it allows two brokers to share messages on either a set of topics, or all topics. This guide covers what you need (the simple config).
How did you call ozw.add_node? You just went to Services and clicked Call Service, without any params in it?
Just call it with no params and hope your device shows up under configuration -> devices…
There’s no user feedback about success or failure or anything to really debug that I could see… Hence my recommendation, just use the old Zwave Integration + UI. The new is not ready for general use IMO.
1 Like
Finally got a real chance to test this out.
I added a plug (which gets added as a switch) and I can see that it was discovered properly and got added to HA.
I can open it up in the states page (haven’t added it to lovelace yet) and it shows the correct status of the plug but I can’t control it from HA. If I control it from the device itself it turns on & off and gives the correct state feedback to HA. But I just can’t control it from HA.
I monitor the MQTT traffic and I can see HA sending a command but for some reason the device ignores it or maybe it’s sending the command to the wrong endpoint?
How am I supposed to know what HA is supposed to send?
Here are the commands sent from HA in MQTTFx:
Here is the status sent from the device when I switch it manually from the device itself:
and here is the info for the node from MQTT Explorer:
Any ideas on how I can troubleshoot this?
And another question that it brought up is what node information is the entity_id based on when it automatically gets added to the system?
That info would be good to know when we start transitioning our existing zwave integrations to this new integration so we can determine which device is which if we start renaming those things for automations, lovelace, etc to continue working.
The switch I just added ended up being “switch.unknown_type_ff00_id_ff07_switch” which is pretty un-useful to figure out which device is which later on.
As I mainly use ZWave to control radiators, and we are in high summer, I took the chance and migrated my ZWave network. Switches show up OK (use them to control lights, fans etc) and the batteries in the Danfoss rad valves also show up.
The actual migration was easy. I already use the MQTT add-on, so I
- stopped the ZWave network and HA,
- deleted the Wave config from configuration.yaml
- restarted HA and added the daemon addin, pointing it to the Wave stick
- Checked that the daemon was working
- added the OpenZWave Beta integration
The devices started to show up, but of course they had the wrong names. Using a process of physical changes and seeing what changed in HA, I was able to identify which new device was which node. I could then rename the device and entities in HA to be what they used to be.
I can’t do this with the valves yet because there is no way to determine which is which.
I have mine configured like this, seems to work. Hassio on virtualbox on Mac.
zwave_device: /dev/serial/by-id/usb-0658_0200-if00
OK, that must be recent then. It certainly didn’t like it when the add-on was first released.
I’ll update my response.