Update on the Z-Wave integration · Home Assistant dev docs

I think By-ID won’t work - it should be by-id.

OK. I was typing from memory.
The string I entered was exactly the string currently in my configuration.yaml. I just copied and pasted it.

Here’s the offender:

OK, it’s a documentation error.
You need to have

Question.

If I were to install Mosquitto add-on, instead of self hosted mosquitto. Would that in anyway result in mqtt topic to change when I am switching over from one broker to the other?
I suspect switching broker doesnt change it, but I would like to have it confirmed.

Again, thanks to all the devs and the work on zwave integration. A lot of hard work and dedication. You guys are awesome.
Regards

OK, I have the daemon installed and running, and the integration.

HA recognised my TKB switches OK, but only partially recognised the Danfoss radiator valves. It recognised the device and the battery state entity, but not the set points and other entities. Looking at log.json, there’s plenty of traffic about full discovery of the rads, so I’m guessing that there’s something missing in the addon.

Luckily, I don’t need the rads right now - I hope :slight_smile: - so I’ll stick with it.

I’ll dig deeper and raise an issue where appropriate.

EDIT: I see from github that the climate elements were only added to the codebase a couple of days ago. I’ll leave well alone for now as I’m running 110 rather than dev code.

Hi, there seem to be 2 repos for this integration:
The custom component:


and the official version:

Can anyone explain the difference? I would like to use a cover node but that is not included in the “core” version but it seems to be included in the custom component. Does it make sense to start an issue for the core version or will it be included in a next Home Assistant Core version?

Can I run the OpenZwave daemon on a Raspberry Pi Zero and will a USB Zwave stick work with one?

So the HACS version, is the pre-release for early testers. This integration has been renamed to OpenZWave (beta) as it moved from the pre-release HACS repo to the official Home Assistant Core repo. It is the same integration. – It was renamed to avoid confusion with the existing zwave2mqtt project

There is no need to file a bug, the devs are already working to bring the remaining platforms from pre-release to beta. We should see more supported platform in HA 0.111 - You can use the HACS pre-release while we’re waiting.

Also if your handy with mqtt, it is possible to use most devices already even though they are not available in OpenZWave (beta)

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. :slight_smile: 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 :smiley:
Nevermind, will wait for more stable things around this as i don’t want to screw up my production :smiley:

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 :face_vomiting: 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.
image


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