WTH Why is it so difficult to simulate bindings/associations to facilitate cross-protocol integrations

Month of "What the heck?!"
, , , ,
1

I am in the unfortunate situation of owning many (nice, really) Z-Wave smart switches. There’s effectively no light bulb products on the market that are based on Z-Wave. Even when there still were bulbs available, good luck getting anything other than the dead standard E26-base stereotypical light bulb form factor. GU10? E12? Floodlights? Not happening.
That’s fine when using dumb bulbs, but it becomes a mess in the few locations where smart bulbs are needed (wanting color and / or temperature control, fixtures where the current is fed through the fixture before it reaches the switch, etc.)
It would be really helpful if HA facilitated simulating zwave, zigbee or matter nodes to enable the built in device binding/associations/pairing functionality native to those protocols. While it wouldn’t be as quick to respond as a true native binding/association/pairing relationship, and it wouldn’t work at all in cases where HA is down, it’d be a great improvement over the current option: trying to make it work with automations.

The underlying problem is that, in particular for smart switches, they often don’t behave as desired if their current state is out of sync with the light source’s state. If the switch thinks the bulb is at full brightness, you’re not going to be able to make the light that’s actually at 50% brighter from the physical control. If it thinks the bulb is “on”, but it’s actually off, not all switches will send a repeated “on” command. It’s been my experience that writing automations to maintain this state sync is problematic and unreliable, while native zwave associations are rock solid.

In the case of zwave, there’s already a feature built into the protocol "virtual nodes’ that’d likely facilitate this use case, but presumably the HA matter server and Zigbee stacks could probably do the same or similar.

Basically, I’d like to be able to create some sort of “virtual node” to bind/associate in the light switch’s native protocol stack, and another in the bulbs’ native protocol stack (or perhaps an entity/group if it’s generic wifi or whatever) and let HA manage the syncing between them. If I use the HA app to turn on the bulbs or change their brightness, the virtual node associated to the switch would receive the update to keep the switch’s local state correct, and if someone used the physical switch to turn things on/off or change brightness, the update would get to the virtual node and change the bulb state.

Feature requests:
Enable creation of 'virtual nodes' for Z-Wave networks and (within HA) tying them to devices/entity/groups. · home-assistant · Discussion #3838 · GitHub (zwave-specific)
Enable easy creation of cross-protocol device binding (smart switch and bulbs) · home-assistant · Discussion #3431 · GitHub (generic)

2

This is just a simple follow me automation, there’s 100s of blueprints that do this already.

3

The issue goes even deeper. As a protocol bridge HA seems to have the right hooks. The deeper issue is how “ground truth” is discovered and updated. We’ve got Z-Wave, Zigbee, Matter, HUE (and its other vendor specific ilk), BACNet, and I’m sure plenty others. Each of these make their own assumption about what the “ground truth” is, and where it lives. It could be the entity itself, on the controller on RAM or disk, in the cloud, or elsewhere. There’s no one size fits all solution, which is why academics still write research papers about it. But punting to “handle your own unique needs in a blueprint” is still a punt.

I read the github thread on this. The fact that there are “100s of blueprints that do this already” seems to prove the OPs point. If HA could provide an entity type whose purpose is to serve as a source of ground truth or a connection/mirror of ground truth kept elsewhere then instead of another 100 or so blueprints being invented to do this, maybe only a dozen might have to be invented.

If this WTH? gets enough attention then the details can get worked out in the github/Discord discussions.

4

But why reinvent the wheel. We have an automation engine that does this and limited resources. I personally rather have those resources work on things we don’t have. Just look at all these other WTHs.