Recently I upgraded from 60 wifi lights to 60 Matter over Thread devices. Specifically Overhead Lights (about 40) and some bulbs. All are Matter over Thread.
When I change a single room, everything works without a hitch, every time. When I change all the lights (i.e. All Lights Off) some lights will not change (almost like they got skipped or missed in the chaos) – every single time. Afterward, the lights that did NOT change will stop responding and the Thread network has issues lasting about 5-20 minutes until the network resolves.
This happens EVERY time I try to bulk-change the lights. This is VERY frustrating because, as I mentioned, my entire home is now Matter over Thread. Basically I have to turn each room off, one-by-one, at night or I crash my lights.
There should be Thread groups possible.
Thread groups are devices in a group that listen for additional commands in group actions.
Where you currently send one command to each device, the groups make it possible to send a single command that will be read by all devices in the group.
This will lower the RF chatter a lot.
You can do the group as a whole house or as single rooms.
I do actually not know if it is possible to have multiple groups on a device, which could really open up options.
Indeed, but as I understand WallyR, he is talking about reducing traffic in a Thread network using device groups within a Thread network but I’m not aware of such capability in Thread, thus my question.
I was considering this method for my next attempt at a solution. That said, the idea of “Thread Groups” is super interesting and I would love to see HASS support this (it might solve the problem all together).
I’ll give the automation + delay a chance next week when I get back to my home assistant and I’ll report back with results.
Ultimately they are IP multicast addresses in the Thread network, which allows a group of devices to listen to one address instead of having to address each one individually. So, under the hood, it is a feature of the Thread network.
However, being Matter over Thread devices, the way to interact with that feature is Matter groups. You add devices to one or multiple groups, the controller sets things up, you get a Group ID and use it to send Matter commands, for instance to recall a group scene.
Well, what the user was requesting is to send individual commands to each device depending on if it was on or off. That’s not group control, group control is sending one command targeted to all devices so you don’t need to send a command to each device.
On a second reading, maybe the request was valid, if the “on” is forced, then you cannot use Zigbee or Matter commands MoveToLevel and MoveToLevelWithOnOff which control if you want off devices to turn on or not when changing the brightness.
Still, it was not about supporting groups or not, but (if I understood it correctly) just a particular behaviour of sending an “on” command that would be better not to send.
OK, Thanks!
I think I have a tiny bit better grasp of this.
Assuming for example that several Matter devices have a binding with an assigned Group ID, then the Matter source device (say a switch is the source device that sends to several lights to be turned on) would send out an IPv6 multicast that looks something like: FF35:0040:FD<Fabric ID>00:<Group ID> This is site-local scope meaning it can go beyond a local Thread network.
After digging a little bit, Thread has its own way of handling IPv6 multicast scoped addresses like this. It appears to encapsulate an IPv6 packet like this into another IPv6 packet that is realm scoped (meaning only within the Thread network) using FF03::FC. It looks like these are broadcast out on the 802.15.4 network and Thread routers that receive it, forward this along the way also broadcasting it, eventually reaching all nodes within the Thread network.
I was talking about the Groups feature, but I did not know it was not implemented yet.
A multicast packet will reduce network traffic compared to a packet for each device in the group.
I’m technical, but not a full-blown computer engineer. Are you saying it is possible for me to group the objects in HASS and doing so will reduce the Thread network traffic?
PS
I imagine this will become a bigger problem for other users over time as well, as Matter/Thread becomes more popular and consumers naturally adopt more units into their homes – I’m just ahead of the curve by YOLOing the purchase of so many Thread devices.
It is important to note that the groups in HA is not the same as groups in Matter.
You need to group them in Matter (when that becomes available).
It might be in the Matter integration it will happen or in the Matter Server addon.
HA Groups, which you can do today, are from what I can tell just a list of entities, that HA takes actions on as individual entities so traffic-wise it sends to each device individually in rapid fire succession.
As for Matter, we will have to wait and see how HA will support Groups in the future.
