Migration to zWaveJS

Add-ons Bindings
1

Hello All,

I have been using zwave-js-ui for around 2 years now using MQTT - initially I had added all my items manually as the new zwavejs binding did not exist.

Now, I decided to take the plunge and migrate everything to the new binding using WS Server (it worked great btw.. so much easier to setup than the old manual method).

I basically followed the instructions here

All my zwave devices were auto discovered via the z-wave JS binding (and appeared in the inbox). I added them one by one and then switched my existing items to the new channels.

Then I deleted the old channel, and thing.

This worked perfectly, all my persistence has continued seamlessly, and I have no issues (Ok I am exaggerating a little, there were some glitches, but nothing serious).

I now have ~50 things all using the new zwavejs bridge and 0 using the old mqtt binding.

So, my next thought was “well I don’t need MQTT for any of my zwave devices”, I can just disable it in zwave-js-ui under settings.

However, as soon as I do that, all my things go offline.

Looking at my mqtt traffic using mqtt explorer, I can still see zwave packets for 2 devices (even though I checked, these devices look like the are using the new bridge)

I tried restarting OH, Mosquitto & zwave-js-ui, no change.

This really seems like I have some kind of ghost items in OH that refuse to forget the MQTT connection.

For info, I am running:

OH v5.03 on RPI 5 under a docker container.

  Bindings: Z-Wave JS - 5.0.3, MQTT 5.0.3

Mosquitto v2.0.21 on the same RPI 5 different docker container

Zwave-js-ui v2.34 on a RPI3 under a docker container

Anyone have any ideas? apart from a clean install?

Thanks in advance

2

Does seem strange. Maybe check in zwave-js-ui settings under Home Assistant section. Make sure WS Server is toggled on and DNS is checked, plus port is 3000. Seems obvious, but I’ve been there before.

3

Thanks for the reply KJ,

My items are definitely connected to Zwave-js via WS Server, port is 3000 and DNS is checked.

The main reason I know they are using WS is that I hardly see any MQTT packets, so the WS Server is working well.

Also, my whole zwave network is much more responsive, as an example:

I have a motion detector in my stairs with lights, these are controlled by a rule.

With MQTT, I could be at the bottom of the stairs before the lights would turn on, now with WS Server, the lights turn on instantly.

I always had a latency which I imagine is linked to the number of steps:

Motion sensor → Zwave-js ui → Mosquitto → Openhab (trigger rule) → Mosquitto → Zwave-js ui → Light

Now this is a shorter path and is much faster:

Motion sensor → Zwave-js ui → Openhab (trigger rule) → Zwave-js ui → Light

I will keep on digging, and will feed back any updates.

4

Ahh, I found it!

When you disable the mqtt gateway on zWave-JS UI, it seems to do some kind of reset / restart.

I think this also disables the WS Server temporarily, which Openhab picks up and sets all the things to offline.

And strangely, they do not come back up (no idea why!).

To resolve the issue, I simply disabled then re-enabled the Z-Wave JS Gateway thing, and everything comes up green - I imagine a restart at this point would solve the issue too.

Now, I am 100% WS Server and it’s working correctly.

Thanks!

5

That’s very strange.
I have an Aeotec movement sensor which signals detection with an LED.
As soon as the led lights up my lights start to turn on.
So the step zwave → zwave-js → MQTT → openHAB → HABApp → openHAB → MQTT → Light is almost instant (<100ms).
Maybe there is something else going on?

6

Possibly because I have zwave on a different server than OH so there is network involved too? in any case I am happy because my latency issue is solved with WS. :slight_smile:

7

I’ve seen this also fix an issue where all items linked to zwave-js-ui things appear as orphans in the health check.

8

You are right, there is no connection watchguard in the binding, when it fails, it is permanent. I might add some kind of retry mechanism.

I’m also interested in any hickups you had or what can be done to make it easier to mgirate.

2 Likes
9

Hi @lsiepel ,

First, thankyou very much for this binding, it is fantastic!

To give some feedback as requested, I had 3 issues during my migration:

  1. The above mentioned point where all the things go offline with “Error: Bridge” in the OH Gui, this is easy to reproduce, simply use the restart button in the top right corner of zwave-ui control panel.

Currently in the logs we see these 2 messages:

Thing 'zwavejs:gateway: Zwave_JS_Binding' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Connection closed: 1005, null

Scheduling reconnect to Z-Wave JS Webservice every 2 minutes

Then the things come back up automatically 2 minutes later, so I don’t think any action is needed from your side.

  1. Things do not seem to be removed from the inbox automatically when they are added.

I have ~50 zwave devices, these were all listed in my inbox correctly, and I then added them one by one. For the Link channel to item step, I used the “use an existing item” option to link them to my previous z-wave items.

However, after adding, the thing successfully, the list of 50 things in my inbox did not reduce to 49.

The only way I managed to refresh the list was to use the “Scan” button under the binding after clicking the plus from the inbox. I suspect this is a OH issue, but I have never seen this before.

  1. The final issue I encountered was linked to the “type” of items, when I manually created things and items using MQTT, I used jsonpth. transformations.

For example I have movement sensors which were reporting true/false for movement. When I added these via the new bridge, these come in as on/off. Because the type is different the “use an existing item” feature does not work. I was forced to create a new item with on/off, and then change all my rules etc.

I think this is a data integrity feature of OH, and not an issue on your side - but it did make the migration more complex.

That’s it!, no other issues to report.

10
  1. haha i just started looking into it and found it was already there. Thanks.
  2. That is strange and can’t reproduce this yet. Just to be sure, you added them within the Main UI, not file based?
  3. Can understand the situation. This type of migration is typically something that cannot be automated and needs to be done manually.
11

I can reproduce, maybe related to renaming of the “nodexx”"

12

Will test, it should not matter as the representation property is set to the node id and that should take care of this.

13

But that is the thing, if you get the dialog to add the node, you get the option to change the nodeid, so it lets say it would be “zwavejs:node:123456678965:node19” you can change e.g. the node19 to zwavenode19, then the full nodeid would be “zwavejs:node:123456678965:zwavenode19”

14

As the node index (as id parameter) is the identifier, it should be removed from the inbox. The thing id should not matter. Exactly as you stated.
I’ll get back to this.

15

ok then i dont know how i did it, maybe its the “ok→edit” button, i cant test anymore because all nodes are now added, oh well, its not the end of the world either way :slight_smile:

Thx for checking though