@Mactalla, thank you so much for detailed explanation.
I got things working with two way bindings. It is just instantaneous !!! Super happy with the result. The only minor issue I see is that if the switch is controlled through HA then the other bound switch would not react to the state change.
Could you please confirm that the 2 from 2/30/0 refers to the endpoint and not the fabric_id? I’m bit confused about the endpoint. I’ve got it set to 1 in the binding array, but the endpoint in the attribute key should be 2?
A smart plug can control the flow of electricity. But it has no UI for the physical world. It’ll do its job based on what it is told to do over the network. Maybe from a phone app or whatever.
A button control on the other hand has a physical button a human can press. But the button itself doesn’t actually DO anything. If the smart home wires up “when button A on that remote is pressed, then cut power on plug P”. Then it acts like a unified item. But deep down they’re still two distinct entities. And a button never listens to what anything else says or does. It’s purely a broadcaster.
Now put the remote on the plug, tie some string around them and call it a Dimmer Switch. One piece inside can control the electricity flow. The other piece is a button you can press. Conveniently those have been connected together so it works out of the box.
Now we’ve just taken 2 of these smart-plug+smart-button combos. We’ve told each smart button to not only notify the smart-plug to which it is strapped up against, but also notify the smart-plug over yonder. The plug is EP1. The button is EP2. So we’ve bound EP2 on A to EP1 on B. And EP2 on B to EP1 on A.
That also explains why if in HA you tell the “light” (which is the piece that can listen; the piece that can control the flow of electricity to your lightbulb) to switch on or off, it’s going to EP1 and not re-broadcast anywhere else. If a button (EP2) could listen, then conceivably it would propagate – but then we might have a feedback loop of button A telling button B who tells button A and round and round we go.
So 2 wall plugs. 2 buttons and 1 HA. That’s 2 receivers and 3 senders. We’ve just configured 2 of those senders to send to both receivers. Need to do the same in HA – send to both receivers, not just one.
@Mactalla, I kind of get it. Does it mean the following configuration should also work?
Switch 1 (controls the load)
Switch 2 (remote switch)
Switch 2 - EP2 → bind to Switch 1. If a button is pressed on EP2, then also turn on Switch 1.
Switch 1 - EP1 → bind to Switch 2. If the Switch 1 plug happened to get turn on (wither by pressing the button, or getting turned on using HA), then also turn on the Switch 2?
Also, I’ve tried 4-way binding and it worked perfectly.
I don’t believe EP1 emits anything. I think it’s just a receiver and “does its thing”. But I could be wrong.
Coming back to the talk about Clusters: every cluster has a Client and a Server side to it. So the On/Off Cluster has a Client half that knows how to send “pretty please, go turn On” and a Server half that will accept a request to “turn On”.
To bind A to B for any given cluster, the A device must implement the Client half of the cluster (to emit the request/notification/whatever) and the B device must implement the Server half of that same cluster. Else they cannot communicate in the same language.
So if EP1 implements the Client half of On/Off, then what you describe should work. But would need to introspect that endpoint to see whether or not it implements the Client half. It certainly implements the Server half and EP2 certainly implements the Client half. That’s how the current binding is functioning.
What I’m trying to achieve is to make the HA to correctly reflect the state of the switches after using the matter bindings. Even though the bindings work and the switches are in the same state, the HA is out of sync.
The first issue (only the physical button triggers the binding) might be by design, it depends on the implementation of the device.
The second issue (HA not getting the switch state update if the state changed via the binding instead of its own physical button) looks like a bug in the switch. HA gets the state of devices by subscribing to state changes, if the state is correctly updated when using the physical button, then it’s subscribed. The switch should send a report when the state changes regardless of the source of the change.
Is it possible to bind a device to Home Assistant itself, I have some Tapo S200B buttons but they only support binding through Matter so it’d be good if they could bind to Home Assistant matter server or something like that so I can get the value in HA.
I guess you already saw this post at the TP-Link community and voted for it, the best course of action would be for TP-Link to add support for the Switch cluster too so it behaves as other buttons:
That’s complicated, and I don’t think there’s been any progress since the link in the first post:
Even if you could use this binding script, I don’t think Home Assistant implements the OnOff and Level Control clusters as server, since HA is a controller and usually acts as the client when you want to control Matter lights. For the binding from the button to HA to work it would have to disguise as a Matter light.
And then comes the second issue, the Matter add-on, which creates the entities and is how you interact with the devices as user. That would need explicit support too for the kind of events that would receive.
The next thing to check is what clusters are supported as client since that determines the functionality when bound. According to the Matter compliance document, only the OnOff cluster.
<feature>Does the device implement the on/off cluster as a server?</feature>
<support>false</support>
<feature>Does the device implement the on/off cluster as a client?</feature>
<support>true</support>
That means it can turn on or off something when bound, the behaviour will depend on how it’s implemented though but I guess we can assume it turns it on when smoke is detected.
Since a light implements the OnOff cluster too you can certainly test binding the sensor to a light, it won’t be any different than the examples here binding a light switch to a light.
Matter Bindings only allow for a switch to control a bound entity thru physical button control not thru virtual/automation control of the switch. This is by current matter Spec design. Will likely take implementation of a Group Cluster to accomplish intuitive binding with virtual commands. DiscordDiscord
