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

Normaly removing the integration is enough. If youre using the zwavejs addon it could be possible that its getting the path from there. But thats just my guess. Try to restart HA after removing the integration first.

Also, avoid /dev/ttyACM0 this could mess up if you have other USB devices connected. Use the hardware-id instead. For example /dev/serial/by-id/usb-0658_0200-if00 for my Aeotec stick.

not wanting to crosspost, but since I am in kind of a stressed situation without my zwave devices, please allow me this: 2021.2: Z-Wave... JS! Where is the zwave domain?

Hi, I tried to migrate to the new Z-wave JS integration yesterday, it worked but all Z-wave devices except the usb controller appeared with different names/ids so all automations using the previous names/ids were unusable without modifying all automations one by one.
I then tried to go back to the deprecated Z-wave integration but all Z-wave devices were still “renamed” so I had to go back to my previous HA save.
All ok now.
My questions are :

  • Is it a normal behaviour or did I miss something?
  • Will there be a safe migration too or any other safe way to migrate?
    Have a great day :slight_smile:

Sure at this step this is normal, and you will have to adapt all your automations. This is why I will wait for the wizard migration tool.

Moved from the now deprecated zwave implementation to the new JS version. It all works really nice. Hopefully the ZwaveJS addon will have a nice interface soon, to change device settings. Noticed zwavejs2mqtt has it.

Where would be a good place to come with feature requests for the Z-Wave.JS integration? Here in this thread?

I’m currently using the integration rather than MQTT devices. And I think it’s confusing that the integration only uses the Product string from Z-Wave.JS (which I can’t edit) to define the device entities. I have three Telldus wallplugs of the same model, and I end up with these entities:

As I name my Z-Wave devices zwave_1, zwave_2 etc., it would be great if there was an option in the integration to use Z-Wave device names in the entity names.

You can edit them all at once when going to the integrations. When you change a device name there, you get a popup with the question if you want to change all the names for the device properties.

1 Like

That’s true - thanks for the input. I can just name them “zwave_N” with also renaming entities, and then renaming them back to something sensible without renaming entities. I just figured having the node number as part of the entity name when adding the entities to begin with would be a good idea.

1 Like

I’ve got a strange one… I have 3 battery pir sensors, 1 battery yale conexis lock and 1 mains smart plug.

According to the network map my mains smart plug is connected back to my usb stick VIA one of the pir sensors AND the yale lock.

My understanding was battery devices do not act as relays?!?!? also the smart socket being a mains device actually should of established its self as a relay?!?!?

Anyway I’ve only just moved over to zwave js so maybe it needs time to settle down?

Great to finaly see that there is a solution without using mqtt, alot of us dont want to use that, and to be honest it has nothing to do with zwave and ha.

so i understand there are two version of zwave-js server one with mqtt and one without, are there a official docker container for zwave-js with websocket only?

as far as I know there isn’t one. there wasn’t one from OZW either.

Only the old zwave integration had that (really nice…) feature.

Hopefully there is a workaround to be able to give a good indication of a dead node or similar.

Maybe there is something there already and it’s just not obvious.

Not really.

you should probably start a new thread in the specific “feature request” topic.

Download the zwavejs2mqtt image and disable the gateway in the UI.

Yes, really a pity (understatement) we cant easily find the state of all of the Zwave modules state and attributes. There were many many very informative data in those Zwave devices. Maybe they’re hidden in the .storage, (cant find any) but I really prefer to have it all in the Frontend too.

btw, do we still need the .xml files? seems they aren’t updated any longer

Anyways, I can compare it all nicely now, since all my entities/devices/states are back, and up and running, cross HA instances :slight_smile: yeah

Only real let down is the demise of the Zwave Graph, since that was the other way of showing the neighbors. This was of course a custom plugin. Maybe a core Graph is in the making too. #fingers crossed

Where? As an issue in the GitHub repo for the integration?

I don’t know for a fact but I’d say no.

I would think that the “xml” files or their equivalent would be stored in the container/add-on and the only thing HA needs is stored in the registry.

But I definitely wouldn’t delete that file right now either. you just never know. :wink:

That’s normally where feature requests go for HA core stuff. I don’t think they like feature requests to be added as “issues” on github.

1 Like

Does it support websocket only and no mqtt? If so it might be better to use this one that has a proper gui

yes, there are several pointers there to the individual devices, none though to what we wondered about above: the zwave modules.

I see 3 of them :wink:
Schermafbeelding 2021-02-04 om 15.32.25

and this pyozw.sqlite:

@Mariusthvdb

fixed… :laughing:

1 Like

back to our earlier discussion, on my confusion about which integration / add-on to install and compare with the former situation… (even typing this confuses me)

I now have a working setup with the new Z-Wave JS add-on, which automatically notifies one to install the Z-Wave JS integration. Took me a bit of reworking the entities/devices, but after doing so, all of my automations and mqtt state_streams could be left unchanged, and my other instances still see the Zwave devices relevant pieces I need for their proper operation. Thats what’s so nice about the state_stream, one can easily pick the few state to publish, and leave all the other entities/states on the Zwave instance to check and do whatever one needs to do.

With that working setup, I now wonder what the advantage could be using the Z-WaveJS2Mqtt add-on. Not even talking about the Mqtt bit off it, merely the features off it in manipulating the Z-wave devices. Since I can’t find any screenshots of that interface, and don’t want to risk anything for now, I would really love to see some screens of members here that did install that integration.

Tbh, the UI of the core Z-wave JS hardly impresses with Z-Wave network operations:

and the add-on is even less advanced :wink:

Describing it with a positive mindset: we’ve got a swiftly operating and modern core Zwave network now, and a huge perspective for improvements! Got to make one smile, with both thumbs up :+1: