Let's start talking about the new Z-wave JS integration

Yeah, sure is. :slight_smile:

:slight_smile: In that case it must be the documentation. :wink:

Just below it shows the network key without hex 0x??. :wink:

to be or not to be…

There are two addons, zwave_js (official) and zwavejs2mqtt (community).

While the documentation is not perfectly clear, the zwave_js addon does allow both formats of keys, the OZW hex-style and the zwave-js string style. So if you’re migrating from an OZW-based install, you can just copy and paste the key as-is.

The zwavejs2mqtt software–and addon–only support the zwave-js style. The zwavejs2mqtt settings and key format are documented here. In this case you need to convert your hex key into a plain string.

2 Likes

I hope when the time comes they will let us know which JS we should use!

1 Like

I made the jump from the old 1.4 zwave integration to the new integration + zwavejs2mqtt addon. Looks amazing and seems to work and respond well. However I am wondering if I made the jump a bit too early.

Is there anyway to use scene control? I have a bunch of zooz switches which allow scene control for different combinations of taps up or down. I got this working pretty well with the old zwave integration but I’m not sure how to read these events with the new integration. Does anyone know if this is possible yet? These are pretty important in my setup, so I’m debating to either stay with the new setup or roll back to the old one until this is supported.

** EDIT ** I think I figured it out. I believe these come under the event: “zwave_js_event”

Thought I would add my experience…
I have been using ZWave2MQTT in a fully manual mode which allows me to control which MQTT topics get sent to HA. A couple of weeks ago I tried out ZWavejs2MQTT in the same mode of operation. I started with their just released alpha version, and along the way I submitted bugs and even submitted a PR to get a device that was supported by OZW, to be supported by zwavejs. Got great help and quick responses from the guys on working on this project (Thanks a bunch!!) and have now fully migrated over running version 1.0.1/6.1.1.

Working to understand my next steps, love that this came together so quickly!!! Thanks to the developers first and foremost.

So I am currently using the OZW beta and Mosquitto right now on Hass.io on a Linux VM under Unraid on a basement xeon server (not sure how much of that is relevant). The usb stick is pretty tucked and in the basement and I’m wondering if this gives me an opportunity to separate Z-wave stick/server from the HA machine so I can restart the HA install without restarting z-wave_js server.

Would it be advisable to run a z-wave_js server (under docker or maybe HA???) on a Rpi (or similar) with the USB stick then broadcast that to MQTT or does that ruin the speed of the direct integration between server/integration on the same machine/HA managed install?

Essentially, since I am on Network --> Unraid (with docker) --> Linux --> Hass.io --> HA, which level would be “best” to run the z-wave_js server? Thinking of going up to the network level and splitting of the z-wave_js server. Maybe even running z-wave_js server on the unraid level (via docker?).

Thanks again to all who have contributed.

Ok, read the whole topic and could not find the solution to my problem.

I run the zwave core implementation with my Aeotec Gen5 Z-Wave USB Z-Stick. What I did is install zwavejs2mqtt from Frenck. I disabled the core zwave installation in my config and restarted HA.

After the restart I started the add-on. I set the correct serail path and network key. After I saved the settings I checked the logs and saw this:

INFO ZWAVE: Controller status: Driver: Failed to initialize the driver: Timeout while waiting for an ACK from the controller

I restarted HA again. And then it suddenly ran. I could control my devices, but with a huge delay. However, it was working. Then when I made a change and enabled MQTT to see if I could get my devices in there (better to not do that as I read in this topic) it stopped working.

Even disabling MQTT, etc. doesn’t help. I keep getting the above error and can’t seem to get zwavejs2mqtt to work anymore. :frowning: Does anyone here have a clue what the problem can be?

I run HomeAssistant Supervisor edition on a pi 3b+.

How did you do this?

Just disabled the setup in the config. Just to make sure HA does not start Zwave.

What platform? You might need to restart the hardware to ensure the z-wave integration didn’t “claim” the stick for any reason.

Can someone tell me what the central scene activation looks like with the new integration. I extensively use ozw.scene_activated to trigger automations. What is the equivalent now?

I have been using zwavejs2mqtt since dec and it has been great experience all the way through with very rapid pace of development and a great maintainer and set of contributors.
(i only started HASS in dec, and went built in integration > ozw > zwave2mqtt > zwavejs2mqtt over period of about 48 hours, glad where i landed up)
I also use a pi with docker container for just zwave, i don’t plan to use the sueprvisor version of the server because the main container does that all and has a nice zwave UI.

any idea when the new integration be in production rather than beta?
I am still relatively new to hass and don’t fancy running beta of the full OS yet :slight_smile:

You need to be more specific. Did you only edit configuration.yaml? Did you also delete the integration from the UI?

If you didn’t delete the integration from the UI, you haven’t disabled it. Removing the setup from configuration.yaml is not enough.

1 Like

Use the event listener (in Dev Tools) and watch the zwave_js_event.

Ah - thanks. Hadn’t looked at that page since it went from beta to release. I assume the actual reported fields for a central scene notification will have something like command_class as central_scene and some other fields to report the scene_id and scene_value info?

Command class yes, other fields no, they are different but convey the same info.