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

Configuration Z-Wave
61

Tried that and it fails, comes back telling me the node is DEAD. One thing I did notice. I looked at the Network Map and it has my GE Fan Switch as a connected node. Wondering if that is tripping it up. BTW: with Smarthings it just worked.

As a side note the GE Fan Switch (3 speeds) would not process the “Off” correctly. Would send “Off” when it should send “0”. I ended up putting together a FAN Template and sending my own MQTT Messages, Got it working perfectly now. But that was allot of effort.

62

I hate ZWave! I put a Aeotec Range Extender about 8 feet away from the door lock. This paired fine, but later showed as DEAD. Went ahead and re-interviewed the door lock and after several tries it read all the details including the user codes. But instead of actually displaying the lock type it shows as unknown manufacturer but it works.

63

Are you using MQTT to interact with the server or WS? I’m running the latest rc of HA but having fun trying to get the ZwaveJS integration to talk to it. It shows the nodes ready but when I click on devices or entities I get nothing back on those pages. I know I’m trying to be a pioneer here

64

Using MQTT, as I am running it on a remote Raspberry PI. I like the separation as I can start and stop either component. In other words Home Assistant is not dependant on ZWave starting.

65

Yeah same here minus the mqtt part trying to get it to work with the WS

66

I tested z-wave JS last night.

  1. Made backup
  2. Stopped OpenZwave Add-on in Supervisor
  3. Installed Z-wave JS
  4. Copied config form OZW add-on to ZWJS (yes this works. config style is similar/same)
  5. Started ZWJS

As Expected. Took some time to interrogate the controller and nodes, but after a while, the Integration, devices, and entities appeared. Had to “Reload” to see the changes, as node data stabilized.

I did not dig into it in terms of support for all my device types, but the basics seem to be intact.

I switched back to OZW again but did not uninstall the ZWJS add-on… just disabled the startup for now… That way I can see the updates as I am sure they will in the next few weeks/months.

The only minor issue for me at this stage is that I cannot set device parameters at the moment. I see it will be necessary to use the separate zwavejs/mqqt frontend. I will investigate this further.

I think that this could absolutely end up being the holy grail for zwave in HA. Once fully implemented it will address all my current issues with current options. Looking forward to seeing the development further

[edit]
On a slightly off-topic sidenote. I have a number of zwave devices, becuase I have been using zwave for years, but if I did not have them I would abandon zwave altogether. It really is a perfect example of the void between theoretical excellence, and practical failure. So I expect future support will dwindle…

1 Like
67

Will polling be supported at some point? I use polling with the built-in Z-Wave implementation in Home Assistant now since I have some old GE Z-Wave dimmers that don’t seem to spontaneously send state updates.

I’m glad to see that, even with the web socket interface, it’s still possible to expose MQTT. Watching the MQTT traffic go by is a great debugging tool, and why I like to use it for random intergrations that I do.

Thanks for the work being invested in this! I have a bunch of Z-Wave devices, and it’s a real drag having to hack the old library XML files when I add newer Z-Wave devices.

1 Like
68

While I’m truly amazed (and thankful) for the speed of development of the Z-wave JS integration, I wonder whether it is not premature to write in the upcoming 2021.2 release of Home Assistant that z-wave JS is now the recommended solution?
While I have the impression it will not take long for it to cover all the essential needs, it looks like at the moment there are still some features that are missing for it to become the default solution?

69

Wow, that was a pretty fast decision to deprecate the existing zwave integration.

Hopefully it isn’t as premature as it seems at first glance and the zwavejs integration is more mature than the rest of us knows.

I doubt I’ll be jumping in the deep end and switching right away.

1 Like
70

In other threads I read the standpoint of the homeassistant core team developers is:

“We support all zwave options”.

But I think they meant that from a homeassistant perspective because they also stated there that zwave is too complex to maintain as a core team.

Thus I believe “the homeassistant core team” is at this moment still “assuming” js zwave will be the successor and in their vision preferred “integration”. I remember this was also the case for OpenZwave Beta a few months ago, so let’s hope this one sticks.

On the other hand, there’s a lot to choose from :rofl:, a box full of chocolate, but not the Belgium ones at this moment… :wink:

71

I’m little bit confused because of all this new Open Zwave stuff.
Right now I’m using the official zwave integration.
I actually wanted to wait until the new official version is released, with the migration assistant that was presented at the conference last year.
Will this version be replaced by Z-wave js now? Is z-wave js the new official solution?

Thanks a lot

72

yes you should consider z-wave js as the future solution you will be migrating to. So keep an eye on how it’s features develop and when it covers want you need you can start migrating.

1 Like
73

So based on the contents of the following link it looks like the integration will be available as part of 2021.2. I assume your using a beta version.

https://rc.home-assistant.io/integrations/zwave_js/#current-limitations

Can you tell me if you’re getting any indication of how or who unlocked a door. I am current running RC1 with MQTT and this is what I get as far as state attributes. I would have expected to see an attribute for method or user slot. Are you seeing that in the integration? Looking at the MQTT Messages I am not seeing (doesn’t mean it’s not there) anything that would indicate that info.

id: 26-98-0-currentMode
nodeId: 26
commandClass: 98
commandClassName: Door Lock
endpoint: 0
property: currentMode
propertyName: currentMode
type: number
readable: true
writeable: false
label: Current lock mode
stateless: false
min: 0
max: 255
list: true
states:
  - text: Unsecured
    value: 0
  - text: UnsecuredWithTimeout
    value: 1
  - text: InsideUnsecured
    value: 16
  - text: InsideUnsecuredWithTimeout
    value: 17
  - text: OutsideUnsecured
    value: 32
  - text: OutsideUnsecuredWithTimeout
    value: 33
  - text: Unknown
    value: 254
  - text: Secured
    value: 255
value: 255
isCurrentValue: true
targetValue: 98-0-targetMode
lastUpdate: 1611895429256
nodeName: Side_Door_Lock
nodeLocation: ''
friendly_name: Side Door
74

I’m very confused and concerned about the direction they are moving in.
the beta notes say

" The old zwave integration is now considered legacy and deprecated"

so they have deprecated an official working version an the suggested replacement is a not fully functional beta?

And to install this limited replacement, you have to run supervisor? and if not zwave 2 mqtt?
I don’t run supervisor nor do I run mqtt for anything (nor do I want to run either for anything)
It also appears there is no migration path so you will have to rename everything? I have a very large zwave install and find it really annoying that I would have to rename everything.
Am I missing something or is this going to be as bad as It seems?

1 Like
75

The current zwave 1.4 has been deprecated for a long time. There hasn’t been an update to it in years. So this shouldn’t be something to be concerned about. If anything celebrate that the zwave stack is going to be:

  • updated to 1.6
  • utilize MQTT
  • finally administration of the network will work
  • be in its own container resulting in zwave network stability during HA restarts
  • support for significantly more devices
  • work with new zwave based community apps (Keylocker)
  • something being released and stable (finally) that can support large networks

Overall we are blessed!

3 Likes
76

But usually a “deprecation” announcement is usually (but not always…) followed up by the removal of the deprecated integration a short time later.

I think the concern is that they are rushing things and aren’t allowing the new “officially recommended” integration to be fully developed. It’s not unreasonable to be a bit concerned because of the events surrounding the last “way forward” announcement going awry.

To be clear, I’m not saying that is what’s happening. I’m just saying that the concern isn’t totally unwarranted. Especially the rush to the deprecation announcement with literally almost no one even seeing how the new integration is going to work.

2 Likes
77

I think in this case it’ll be sticking around for a bit.

Another bright side is, OTA firmware updates from HA in the future. :partying_face:

1 Like
78

Hardly an assumption. The integration has been written, and it is being released in the next update.

https://rc.home-assistant.io/blog/2021/01/27/release-20212/#z-wave-js

79

While deprecating, i think they intend to keep it running for a while

1 Like
80

While we’re considering it deprecated, we’re not in a huge rush to hide it or remove it, definitely not before zwave_js reaches feature parity

6 Likes