PSA: Upcoming Z-Wave JS changes and Z-Wave certification - how it impacts you

Configuration Z-Wave
1

Hi everyone, it appears a lot of questions have been coming up as of late about the change to the entity we create for the Basic Command Class value.

Z-Wave Certification

This has been stated before in several release watch parties as well as in the release notes, but it is probably not well publicized: Nabu Casa wants to get Z-Wave certification for Z-Wave JS and the Home Assistant integration with Z-Wave JS. While it’s only a requirement to get certified if Nabu Casa were to sell the product that’s being certified (in this case, Home Assistant), which they are not, and for the tinfoil hat wearers out there, they will not, getting certified would mean:

  1. The Z-Wave Alliance would then consider our stack as being on equal footing with other paid solutions
  2. We could start using the official Z-Wave logos.

The Z-Wave JS team has reviewed the certification requirements, the spec, and the integration features, and has identified all of the remaining tasks that need to be completed before we can try to get certified. The certification requirements tell us what functionality we need to expose, and then we have to find HA constructs that we can use to expose said functionality.

Since there is no black and white answer as to how to solve it, the Nabu Casa team has reviewed the certification requirements, and in places where they’ve agreed on how it should be done, I am working on implementing them.

How to have a more active role in the certification discussion

Want to participate in the discussion? There’s a project board that tracks certification requirements along with a proposed implementation: Z-Wave JS: Road to Certification · GitHub . We are aware that some of these solutions are not necessarily the most ideal, but the proposed implementation is how Nabu Casa thinks we can best use HA constructs to meet the requirements. In some cases, no good HA constructs exist and we will need to develop new ones, so those will take a bit more time to get to.

You should be able to add comments if you have an alternate suggestion for how something should be implemented. This is not, however, an invitation for people to complain about an implementation choice or to be rude to anyone, and if people start to do that, I would not be surprised if that repo gets locked down to prevent external comments. That would be a shame as we (or at least I, I can’t speak for Nabu Casa) would love additional ideas as it’s always possible that there’s an alternate path to meeting the requirement that we didn’t think of.

What probably brought you here (Basic CC Light)

Finally, back to the question that started it all: what is the best implementation of the Basic CC certification requirement?. If you think a device has the Basic CC exposed in HA and it shouldn’t, you should try the next couple of tasks in order:

  1. Find a way to upgrade to zwave-js 12.3.0 (this isn’t currently possible with the official addon but I will be updating the addon soon) which has some changes that will reduce the number of Basic CC entities exposed generally EDIT: The update to zwave-js 12.3.0 is now available
  2. Re-interview the device - if the Basic CC entity shouldn’t be there, it will hopefully be unavailable after re-interview and can be safely deleted once it is.
  3. If the Basic CC entity is still enabled and available, open an issue in the zwave-js/node-zwave-js repo making a case as to why it shouldn’t be exposed (of course you should first look to see if there is an existing one, and if there is, add a comment to that instead). Even better would be if you submitted a PR (along with the justification in the description) to zwave-js/node-zwave-js that would fix the exposure of the Basic CC entity for the device in question.

Conclusion

I hope this (probably needlessly) long post was helpful in providing context for the behavior changes that you are seeing. If it wasn’t helpful, sorry I was unable to help you, but please don’t add noise to this topic by adding a comment here to complain. I will leave comments open in case anyone has alternative ideas that we should explore, but I will happily hide/delete comments that stray from this objective, and if those types of comments create enough noise, I will lock comments on this topic entirely.

PS/FYI - I am not a Nabu Casa employee, I am just a guy who likes to write code in his spare time, particularly for the Z-Wave integration.

Thanks for listening/reading!

20 Likes
3

Thanks for explaining all of that @raman325, it does help explain some of the ongoing changes to the Z-Wave systems and the questions it may raise.

1 Like
4

This context is super helpful. Thank you!

1 Like
5

I may be confused or misinformed but what exactly is the issue with adding a new/additional entity to a zwave device?

What are the downsides or problems it might cause or is causing to prompt users to complain about it?

To me it seems that if the user has that entity added to the device then it should be easy enough to either disable it or just ignore it.

Or does it change the overall functionality of the device in as way that I’m not foreseeing?

1 Like
6

To be honest, I am not quite sure. I agree with you that the change is relatively benign, but it seems that some people had set up some automation and templates based on the assumption that a given device would only have one light entity, and others didn’t understand the difference between the new light entity and an existing light entity for the same device. It’s understandable why using the light entity type for the Basic CC is confusing, but it’s the best representation we have for how the Basic CC functions.

On the initial rollout, we also discovered that zwave-js was instructing us to create Basic CC lights for more devices than we should have, and that has been resolved in the latest addon update.

3 Likes
7

In addition to directly impacting some templates, it’s the general lack of context and understanding that leads to concern (for some of us.) A new thing shows up in something that is essential to our home systems. We don’t know what “Basic CC” is. Is it benign? If so, should I ignore, or disable, or delete it? Or does this indicate I’ve done something wrong and need to switch things over to start using it? For days, the answer to questions was “don’t worry about it”. A post such as the excellent one above is very helpful for us non-experts to place the issue into context.

1 Like
8

I think the response you received stems from the fact that new things have popped up regularly in the integration (or at least they used to, we’ve been slowing down as we’ve hit most of the functionality we were targeting), like the ping button or the node status sensor, and no one batted an eye when those entities were added. But when this light entity appeared (which is documented in the release notes, which also links back to the PR, which also links back to the certification task, which is on a certification project board - sorry to sound pedantic but I am trying to point out that this was all done out in the open and is easily traceable), a bunch of people have their hands up in the air.

The only thing we did was take something that you couldn’t interact with (a disabled by default Basic CC sensor) and make it something you could interact with (an enabled by default Basic CC light), being sure to document it in the breaking changes section of the release notes. At no point have any of the concerns that have been raised about this new entity indicated that something that used to be there isn’t (aside from the original sensor), so why would this particular entity be so concerning when every other addition we’ve made hasn’t been?

3 Likes
9

I understand the changes and thanks for explaining.

One minor inconvenience this causes on my end, is that I use node red for a lot of automations. When I’m in a current state node or event state node, I usually start typing my device name- ie sunroom lights, and then it used to come right up and I would just select the 1st option. Now, multiple entities come up, including light.sunroom_fan_basic which is first now (i have a fan in that room too) and I have to now scroll and use the mouse to pick the correct one, and make sure it’s right or my fan will turn on instead of the light in the automation.

Now this isn’t a huge deal for me, but there are a lot more entities in those drop downs cluttering things up. Is there an easy way to bulk disable these if a user doesn’t want or need them, besides going through each device?

I mean if this is the path to certification, that is probably more important in the big picture to attract more users, and if so I’ll live with it, but just pointing out how this has made automations a little more complicated to set up for me then before.

10

The Entities page in Settings has provided this functionality for who knows how long. E.g.:

11

Thanks, I will attempt to do more research before asking any additional questions

1 Like
12

Is there a way to do this in bulk? It’s really tedious having to click through the re-interview UI for each device.

13

Not in HA. You can do it with Z-Wave JS UI.

1 Like
14

@raman325 are there plans for Z-Wave Controller OTW flashing support via Home Assistant’s UI?

Maybe support could be added to Nabu Casa’s existing “Universal Silicon Labs Flasher” tool?

Would be awedome if would update Z-Wave controller firmware via “Silicon Labs Flasher Add-on”:

OTW programming of Z-Wave Controller is today available in Z-Wave JS UI but not i HA:

https://zwave-js.github.io/node-zwave-js/#/api/controller?id=updating-the-firmware-of-the-controller-otw

PS: Ability to easily update the Z-Wave Controller firmware regularly is obviously important, see:

https://zwave-js.github.io/node-zwave-js/#/troubleshooting/otw-upgrade?id=over-the-wire-otw-firmware-upgrades-of-z-wave-controllers

15

Why do you say it’s not supported? Go visit the device info page for your controller, there’s an update button there with OTW firmware update support.