Is this last bit optional ?
I would like to run the new zwavejs server because it’s ‘current’ but still have the devices published to mqtt for others and also have any other devices (from another controller) that appear in mqtt to be discovered by HA - is that do-able ?
Use the code from @petro (thanks!!!) before and after the transition. It will then be easier to match the new entity_id with the old.
Small adjustment to that code, made easier to import in excel, text to columns on semicolon:
{%- for node, zstates in states | selectattr('attributes.node_id', 'in', range(1000)) | groupby('attributes.node_id') %}
{%- for s in zstates %}
Node {{ node }};{{ s.name }};{{ s.entity_id }}{% endfor %}
{%- endfor %}
You should be able to take your current network key (if you have secure devices), add that to the config for ZwaveJS and just start it up. Well, stop the old zwave stuff first. It’ll take quite a long time to do all the initial interviews for each node, especially if some are asleep, those could take hours to show up properly, or even a whole day. You shouldn’t need to exclude and include everything.
Beyond that, you’ll end up with all new entities, which is unavoidable. So you’ll need to update all the automations and templates and stuff that used your old entities and point them to the new ones. I don’t think there’ll be a migration wizard or anything to automate this, since it’ll be very unique to each and every HA instance. Or, once the old z-wave entities are removed entirely, you should be able to rename the new ones to match the old names so templates and automations work properly again. Either way, you’ll need to update things manually, and I don’t think that aspect of migration will change, tho I could be wrong, and there could be some migration-magic in the pipeline.
Migration is on the roadmap, it may not be a soup-to-nuts, but to me it’s worth waiting to see what that will look like.
Watching the launch party, they are talking about migration right now, could be pretty cool - fully automatic.
Yep, I was referring to the refresh_rate! I had made a note in the comments of my zwave_device_config.yaml to watch out for polling_intensity on me GE dimmer bulbs, but I think I meant to put refresh_rate here.
I fired up a Z-Wave JS Docker container and woke up all my nodes. The GE Enbrighten bulbs work perfect, along with my August Pro Lock 3, Dome motion sensors, and Wink Door/Window sensors.
The only thing giving me issue is I can’t adjust the RGB colors or color temp on my HANK Electronics (HKZW-RGB01-V1.0) Z-wave bulbs.
I installed zwavejs2mqtt docker in my Unraid, configured it, added the devices.
Now in HA, I’m stuck trying to connect the integration module…
None of what I tried works…
Seems to be this settings:
You beat me to it. I have Unraid as well and seeing the exact same thing.
I have a number of wireless Zwave devices (locks and sensors). When it talks about “waking them up” to get Zwave JS to populate their entities, does that mean pulling them apart and pressing the wake button or merely operating them? Because the former is a huge pain in the ass in some cases, yet I tried operating them and they didn’t populate. Will they eventually all populate in the course of 24 hours without any intervention?
I’m hoping for a good wiki guide on moving from OZWave 1.4 to the new system. Kudos to anyone that can put together a clear migration process!!!
Forgive me, but already at step 1 I’m confused. “Install A or B” immediately begs the question of how and why to choose one or the other…
I suspect that I’m just going to stick with the OZW beta until such time as a dummies guide becomes available, and that functional parity with the OZW beta has been reached by whatever the new integration turns out to be.
Yes. That’s a start, but it needs to be expanded out. As replies to that message have stated, most of the steps aren’t super-intuitive. While I can try to comb through the responses, I’d love one document that is updated, and then updated, and then updated until most people that read it agree it is a clear step-by-step guide that most people can follow.
It doesn’t matter which one you install. The choice is yours. Zwave JS is managed by the core team, but it’s very new, so functionality is missing. ZwaveJS2MQTT is managed by the community, most of the functionality exists already. You can literally install both and try out both. That’s what I did, then I made my decision from there.
There are some steps missing in regards to ZwaveJS2MQTT, but that’s because I’m going off the top of my head. The step list that’s provided is exactly what I did using the Zwave JS addon. After I performed those steps, I tried ZwaveJS2MQTT, then switched back because I didn’t need any of the added functionality.
Looks like they’re starting to show up over time. It isn’t instantaneous.
They should show slowly over time. Each restart will also give you more information. I got everything setup and running in 3 zwave network restarts. Granted I only had 6 sleeping nodes.
I think I finally found how to setup the UNRAID docker for this to work…
I was able to finally add the HA integration…
Doing a little more testing then I’ll update this post… (in case this is a false alert lol)
Isn’t this sort of wrong? You can install and use both. ZWave JS doesn’t give you all the functionality that ZWaveJS2MQTT has, but don’t you need Zwave JS to get ZwaveJS2MQTT? At least, that’s what I just did.
If you need to configure any zwave devices you need the zwavejs2mqtt since the other one doesn’t have that ability yet. But both are super easy to install as an addon. zwavejs2mqtt has a very nice dashboard with lots of controls, the other one is pretty barebones right now.
Could you explain how you passed the serial device through the unraid to the docker container?
I currently use the integrated z-wave with my USB stick pass-through to the HA VM and then supervisor can see path /dev/serial/by-id/xxxx
However, /dev/serial/by-id/ doesn’t exist in Unraid docker setup and the only option is /dev/bus/usb/ which I understand would change on restarts.
