Consider not hiding "unnecessary" endpoints if they implement different switch-type classes

[AlCalzone]

trafficstars

Need to think about the implications. For example ZEN30 has Multilevel and Binary Switch for a Dimmer and Relay.

At the very least, it should be possible to use the endpoints in associations

[mbbush]

One potential use case where it would be nice to have this would be in sending a multicast command to a combination of dimmer and on/off switches.

[AlCalzone]

In that case simply use the Basic CC. HA just merged a fix that would prevent this from working: https://github.com/home-assistant-libs/zwave-js-server-python/pull/464

[GrizzlyAK]

Hi guys, regarding the ZEN30, here is something I just noticed in core-2022.8.4 (and which still exists in 2022.8.6) of Home Assistant (ZWave-JS 9.6.2).

I have had a ZEN30 for quite some time, and it's been working fine. I have an entity for the Relay in HA that I named switch.zooz_zen30_switch_us_bath_fan and a button in my Dashboard which toggled it, which controls a fan in the bathroom. I just noticed today that the button no longer worked to control the relay (fan), nor did it reflect the state of the relay itself when toggled manually. When I toggled the button in the UI, it would turn on, and then back off after a second or two. Typical behavior when a switch entity is not connected to a physical device.

After some investigation, I noticed that there are two NEW entities that are defined: switch.zooz_zen30_dimmer_relay and button.zooz_zen30_dimmer_relay_ping. In ZWave, the relay is identified as binary Switch v1 twice, as 92-37-0- and 92-37-1-. The 0 version appears to be my old Switch entity, and the 1 version appears to be the relay entity, as the latter is the one that controls the relay/fan now.

The question is, when did this entity get created and why did it usurp my existing entity? Either ZWave-JS or Home Assistant (don't know which one) redefined an entity right out from under me, my dashboard, and my automation that relied upon it. That's not cool. I'm trying to understand exactly what happened so that either I, or the dev teams, can figure out how to avoid such behavior in the future. If it were a critical component (heat), and I was away from home, that could be BAD. Of course, this likely happened during an update, which I wouldn't do while away, but...

Cheers.

[AlCalzone]

The change is caused by https://github.com/zwave-js/node-zwave-js/pull/4736/files - but from the driver perspective, this only adds values (and un-hides an endpoint). I don't know how HA decides how to correlate entities with value IDs, especially pre-existing ones. @raman325 any idea here?

[kpine]

I don't know how HA decides how to correlate entities with value IDs

The value ID is encoded as part of an entity's unique ID, so an entity sticks to its value ID. Based on the reports, the Binary Switch endpoint 1 value ID is new and assumes the functionality of the previous endpoint 0 value ID, but at the same time that endpoint 0 is no longer functional, which makes the original entity no longer function.

[AlCalzone]

Hm, this might be caused by a changed lifeline association then, which now prefers endpoint 1. I have no clue how to prevent these things though, other than hoping manufacturers implement their endpoints in a standards-compliant way from the get go (this isn't the case here FYI).

[GrizzlyAK]

OK, thanks guys. I was able to easily reassign things to make them work again in HA using the new entity, but was concerned about potentially serious side-effects in HA with this behavior, and wanted to raise it to the team. Thanks for the response.

the Binary Switch endpoint 1 value ID is new and assumes the functionality of the previous endpoint 0 value ID, but at the same time that endpoint 0 is no longer functional, which makes the original entity no longer function.

So this behavior is programmed behavior in HA then? Could they then give the user a notification and let them decide which entity/endpoint to use (esp. if one is already defined)? Better yet, and if possible, HA wouldn't change anything and only notify the user that a new entity had been created for the device and let the user decide.

Appreciate all your efforts!!

[AlCalzone]

I think what kpine meant to say is that the device now updates the value endpoint 1 instead of endpoint 0 after the change, because the driver sets up the lifeline association differently. You should still be able to control the device through the old value, but you won't get updates on it.

wouldn't change anything and only notify the user that a new entity had been created for the device and let the user decide.

Unfortunately not possible. The driver has to automatically decide on one of the many ways to set up the lifeline association, and it will do in a way that it receives all updates, not just the ones from one endpoint. Granted, in your case this makes no practical difference, but this heuristic was found through years of trial-and-error and it seems to be the strategy that works for 95% of devices out of the box.

I don't expect this to be a frequent issue though. Normally when we add compat flags, they are necessary to make the device work at all or enable most of its functionality, so changes like this usually don't break anyone.

[AlCalzone]

Looks like we must do this for certification. One of the tests uses this setup: Root device:

basic device class:    Routing Slave
generic device class:  Binary Switch
specific device class: Unused

Endpoints:

generic device class:  Binary Switch
specific device class: Unused
is dynamic end point:  false

generic device class:  UNKNOWN (0x99)
specific device class: Unused
is dynamic end point:  false

generic device class:  Multilevel Switch
specific device class: Unused
is dynamic end point:  false

Only the 3rd endpoint supports Multilevel Switch CC, but we currently ignore it. This results in a version query for Multilevel Switch CC being missed.