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.