Hi all,
i have just bought 130 inovelli white series (Matter/Thread) dimmers for my home and installed the first two to test with 
I have added both devices to HA and i can control and configure both switches.
Only one switch can switch the load, the other has no load connected. Is there a way to group/associate both devices with each other so that i end up with a “classic” 3way configuration where i can use Switch 1 and Switch 2 to control the load?
Thanks for a hint
I might have found my own answer
This is from the inovelli site:
NOTE: This is an experimental feature and is not supported by any hubs at this time. We’ve built it into the firmware, but no hubs support it.
Matter Bindings are used to “bind” two or more Matter devices together. The benefit is that when two Matter devices are bound together, they no longer need the hub to communicate with each other (they will still report status to the hub). This is important because if your hub goes offline, the bound Matter devices will still communicate. Some common examples are:
2+ Matter switches bound together to create a virtual multi-way setup (like if you have a light switch at the top of your basement stairs and another one at the bottom but they are on different circuits, you can now associate them together so that when one turns on, so does the other)
Matter switch to Matter bulb
So i guess the question is - is Matter Binding on the roadmap for HA?
And is there any other workaround i can use in meantime?
I just installed my first Inovelli White and this is exactly what I’m looking for, too.
I found this from months ago: The State of Matter - #5 by marcelveldt
So good intention on HA side, but uncertain about timing.
As you found, the switches already support it. That leaves bulbs. Have you found any evidence of any bulb supporting it yet (preferably a thread bulb)? I picked up a Nanoleaf (reasonable price point), but I don’t want to start buying in quantity until I know I’m buying something that (will) support bindings.
Bindings is on our radar. We probably will start with a “rough” UI on the device page where you can enter the target node ID to create a binding. But no timeline currently.
You can use the switches event entity, and create a Home Assistant automation. Obviously, this puts Home Assistant into the loop though.
Technically, it might be possible to setup such a binding through the Matter Server’s WebSocket API. It certainly involves reading the Bindings Cluster spec, and figuring out how to exactly manipulate the Cluster attributes to setup a binding. It might also require ACL changes on the involved nodes, not sure about that.
From how I understand bindings, since the bulbs act as so called server, being controlled by a switch directly is really not different for them than being controlled by the Matter controller directly. The only difference is just that the command will come from a peer node instead of the controller node. So bindings should really work with any Matter bulb.
That is at least true for unicast (non-group) bindings. Unicast bindings are certainly the binding type which will be supported first.
I’ve just come to the same understanding. Thanks for corroborating that interpretation.
Where could I learn how to connect to this WebSocket? (running a Yellow if that matters)
I did a bit of poking around. In theory (in my head at least) this should be possible with chip-tool even outside of HA. I haven’t got it working yet, but maybe someone can see what I’m missing or point out why this wouldn’t work the way I’m picturing…
I have an Inovelli switch and a Nanoleaf bulb. I commissioned both via Google Home and then shared with HA. Both are on the same Thread network (that was a pain unto itself, but working now), and I can see both on both fabrics.
I installed chip-tool on Linux and shared both devices from HA and paired them with chip-tool. That brought them both onto a 3rd fabric. Google Home shows that each are participants on 3 fabrics. For anyone playing along at home, first copy the code from HA after hitting “share” and then within chip-tool (chip-tool interactive start) run:
pairing code <new-node-id> <code-copied-from-HA> --bypass-attestation-verifier true
Probably could do the attestation if I knew what else I needed to install beyond chip-tool itself. /shrug
So far so good.
Then I updated the ACL on the bulb. As @agners says, that should be all that’s needed for the receiver of a binding, and I saw that mentioned in 2 places on the internet. Important to note: writing the ACL writes the entire ACL (within the scope of the fabric AFAICT). That means just saying “give permission for the switch to control your on/off” means nothing further can happen – it destroys the permission for the controller to admin the device any longer. Ask me how I learned that.
So to update it I did:
# See what it was
accesscontrol read acl 2 0
# Change it
accesscontrol write acl '[{ "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, { "privilege": 3, "authMode": 2, "subjects": [3], "targets": [{"cluster": 6, "endpoint": 1, "deviceType": null}]}]' 2 0
# See what it is now
accesscontrol read acl 2 0
Some magic numbers there.
The first map there is just repeating what the first readout gave: Subject 112233 (hardcoded ID for the chip-tool controller) has privilege 5 (admin).
The second map is what I added: Subject 3 (the node ID I assigned to the switch when I paired it with chip-tool) has privilege 3 (operate). Specifically cluster 6 (on/off) hitting endpoint 1. Do not restrict to a deviceType.
The final 2 and 0 are Node 2 (the node ID I assigned to the bulb when I paired it with chip-tool) and the endpoint – ACLs are on endpoint 0, which is why all devices should support it and thus why we don’t need to hunt for bulbs that “support” binding.
In theory the bulb will now accept a request from node 3 to turn on or off.
Last step: create the binding.
# See what was there
Binding read binding 3 2
# Change it
binding write binding '[{"node": 2, "cluster": "0x6", "endpoint": 1}]' 3 2
# See what it is now
Binding read binding 3 2
I also noticed that writing the binding table is also a write-it-all; not any add vs delete. But since it’s empty it doesn’t matter here.
Magic numbers here are similar: We’re targetting node 2 which is my bulb, we’re binding cluster 6 (the on/off commands), and targetting endpoint 1. We’re sending this command to Node ID 3 (my switch), but the endpoint is 2.
The binding cluster on the Inovelli switch is on endpoint 2, not 1. This can be seen by reading the binding – all other endpoints say “I don’t have such a thing”. Endpoint 2 is also where Inovelli’s Blue switches (Zigbee) put the binding control. And the Zigbee bindings work fine. So something to be aware of, but shouldn’t affect the usage.
Buuuuttt it doesn’t work. Everything looks like it’s setup correctly. So I think I’m close. But I haven’t learned enough to debug the next step.
Scratch that. It DOES work! But only when physically pressing the switch. Not sure if that’s intentional or a bug in the firmware. TBD
I tried confirming that it’s entirely local by shutting down everything but the devices (no more HA, Nest Hub, or the Linux machine where I ran chip-tool). It didn’t work. But at this point I’m chalking that up to a flimsy mesh where each device was probably connected directly to one of the TBRs. I’ll try again with a more substantial mesh (or sit longer to see if it heals amongst itself) another day.
@pk4811 can call this a workaround since it’s certainly not point’n’click, but does get the job done. If we can get access to the websocket in HA we can probably get something a bit more ergonomic while waiting for official support.
Wow @Mactalla nice…! I was about to try to do the same.
As far as I understand, we should be able to use the API from here:
So theoretically we just need the right method and a webclient that uploads the jsons…
Thanks for the help! Just got my Inovelli switch today and followed your instructions and they worked!
I also wanted to get dimming working, so I modified the accesscontrol and binding commands to also include cluster 0x8 (LevelControl):
accesscontrol write acl '[{ "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, { "privilege": 3, "authMode": 2, "subjects": [3], "targets": [{"cluster": 6, "endpoint": 1, "deviceType": null}, {"cluster": 8, "endpoint": 1, "deviceType": null}]}]' 2 0
binding write binding '[{"node": 2, "cluster": "0x6", "endpoint": 1}, {"node": 2, "cluster": "0x8", "endpoint": 1}]' 3 2
I also had to set the “Switch Mode” in HA settings for the switch to “Dimmer+Single”.
Dimming works by holding up or down for a few seconds: you can see the brightness indicated on the blue LED on the switch, and once you get to the desired brightness, release the switch, and that brightness level will be relayed to the controlled light. I haven’t yet figure out a way to change the light’s brightness in real-time, synced with the LED’s level indicator though.
I was wondering if binding will ever get introduced with matter thread.
Also, do any of their thread devices have detached relay feature like the zigbee version?
Support for binding in HA is “planned for later this year” according to a github comment by Marcel few days ago.
Sorry, I meant specifically with other thread devices than inovelli. Are there other brands that support matter binding for now?
I see, yes, Eve for instance has some sensors with binding support, not just the well-known thermostat which binds to the radiator valves but, according to the compliance document, the motion sensor and/or the contact sensor (now I don’t remember which one) include it. In this case to turn lights on/off, although the feature has never been announced.
Same goes for Tapo, although not officially announced, they bridge the Tapo S200 as a dimmer switch meant for binding (that’s why it doesn’t work with any platform as a button like you would expect).
That’s strange. I used null to just bind and permit all clusters. Should be the same as what you did with 0x6 and 0x8, since those should be the only ones in play AFAIK. My lights (nanoleaf essentials) change in real time when I hold the paddle. Not as silky smooth as the Hue lights bound to a Blue switch. But it gets the job done.
Seems like at least this Chinese device supports it - you can Google translate this Portuguese product review, and see comments section (below) in English… mostly by yours truly. Also linked this thread there, seems relevant.
There’s a few more thread based relays and switches from this shop
https://my.world.taobao.com/item/759224027511.htm
http://e.tb.cn/h.Tae5tbIi1eKFZAS?tk=9Gty3qczzYO
It does mention something about matter binding there
Does anybody know - Is there a clear explanation somewhere of how bindings are supposed to work between the Matter Dimmer Switch Type (0x0104) and a dimmable light (0x0101).
For example, consider the Inovelli VTM31 dimmer switch. Endpoint 1 controls the load and is of type dimmable light 0x0101. Endpoint 2 is the Dimmer Switch type 0x0104 and includes a binding cluster.
Assume you have two of these switches, A and B, where the Dimmer Switch of A (endpoint 2) is bound to the Dimmable Light of B (endpoint 1), then
If a user presses and holds the Paddle-Up on switch A, what gets sent to B? Is it the “Move” command with an “Up” specified in MoveModeEnum and then a “Stop” command once the paddle is released? Are the Level Control Cluster’s attributes on endpoint 2 used when sending the Move - i.e., does switch A use attributes like the DefaultMoveRate when commanding Switch B? E.g., to set the move rate, etc.
Similarly, what is supposed to happen when a user short-presses the Paddle-Up? Is the command “MoveWithOnOff” sent or does the device send both an On/Off cluster “On” command followed by a “MoveToLevel” - or is “MoveToLevel” even used, or do you just turn “On” and let the remote device figure out the level based on its OnLevel or last Global Scene saved data?
And is there a report back to Switch A and does that change the Level Control cluster’s attributes at Switch A (e.g., the CurrentLevel attribute of endpoint 2’s Level Control cluster).
What if you are commanding a group and the devices in the group were set at different levels? How does that work - does each light just turn on at whatever it was last set, or is the “Onlevel” attribute and Switch A, Endpoint 2 used to set the group to a common level.
It seems that for Matter binding to be useful, this should not be implementation-dependent, but I can’t find anywhere that really says how this all works. Maybe you just rely on SDK on github and that just has it right whatever the intent is?
Note, in the case of the Inovelli switch, its odd that it works at all - the Matter Spec. says that the Dimmer Type Switch endpoint (endpoint 2) is supposed to have On/Off and LevelControl clusters and, as viewed using Home Assistant’s Matter Server, they aren’t there.
Seems like maybe another specification document is needed (is there a specification document beyond the 4 major specs downloadable from CSA - i.e., the “Core”, “Device”, “Application Cluster” and “Semantic Tag” specs).
Same as Zigbee, you bind a cluster client to that same cluster server so the client (typically a dimmer switch, motion sensor, contact sensor, etc.) can send commands to the server (let’s say a light or group of lights).
What commands it sends depends on the device and how it is implemented.
I would expect just one command and always the same one. For OnOff a button would send the On and another the Off, or if there’s just a single button, it will send a Toggle command. For LevelControl don’t expect much more than a Step (or MoveToLevel) commands to brighten / dim or Move + Stop for continuous dimming while held. Attributes being implementation dependent.
I would expect the client to be stateless and not care a bit about the state of the servers that are bound. Each one will process the command according to its settings, state, capabilities, etc.