You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First some background, there are two ways to make a Matter light switch. The first way is what everyone is currently shipping. These light switches simply masquerade as light bulbs. They implement device types Light (0x100, 0x101, 0x10C, 0x10d). When the switch is flipped the light goes off and that's how you tell that the switch has been flipped. The problem with these devices is that you can't make lighting groups out of them without using scripts on a controller. For example you can't bind them into a pair for the top and bottom switches of a staircase.
The second way to make a light switch is by using an actual Matter light switch device type - Switch (0x103, 0x104, 0x105). I checked the certified device database and only a single light switch has been certified. It is a switch from Zemismart with device type 0x103. Devices using the Matter switch clusters support binding into groups and you can make the necessary pair for the top and bottom of a staircase. But in general no one is shipping this type of switch.
Please step back and consider how this second type of Matter light switches appears to a consumer. You buy a smart light switch, it is a single physical device. Then the prescribed way to build this second type of smart light switch in Matter is to implement three independent endpoints.
the light bulb
the light switch
a generic switch
Those three 'independent' endpoints are actually coupled by quantum entanglement so that if you push the switch on the physical device the light EP1 turns off, EP2 sends an ON/OFF event, and EP3 sends button events. If you really want a headache, make a multi-gang device with four switches. Then each of those four switches has three endpoints and it becomes a major mess in a controller app UI to try and correlate which switch is quantum entangled to which bulb.
The problem: These light switches are not three independent devices and should not be represented by three different endpoints! It is actually different aspects of a single device. Here's another way to explain it....
Matter needs a Smart-Switch device, but after weighing the options creating another device type is not the optimal solution. What works better is to allow all possible subsets of these device types on a single endpoint. Yes, the endpoint would list up to nine device types.
When a single endpoint includes all of these device types Light (0x100, 0x101, 0x10C, 0x10d), Switch (0x103, 0x104, 0x105), Generic Switch (0xF) it is saying: I am a single endpoint. You can treat me like a Light or a Switch or a Generic Switch or all three, but I am still just a single device with varied capabilities and all of those capabilities are integrated. They are not standalone capabilities.
Simultaneously allowing all of these device types on a single endpoint is also great for backwards compatibility. Existing code will just see the one device type it currently supports and it will continue to work unchanged. The extra capabilities will simply be ignored. On existing controllers this has the desired side effect of automatically degrading these smart switches into the first type of light switch -- a light bulb which has a physical switch inside.
To contrast the difference between coupled and independent endpoints, you could also build a lighting device with three independent endpoints. That device would have a light bulb and two separate physical buttons connected to Light, Switch and Generic Switch. Toggling the switch on this device is not going to turn off the light bulb or send generic switch events since the endpoints are independent. This device is not usable in an integrated manner and illustrates the difference between the integrated and non-integrated devices.
I would also argue that a smart-switch is not a composed device. It really is a single device, building it as a composed device still has the problem with the subdevices being entangled with each other. It would also need new software in all of the controllers.
Of course nobody is going to do anything with this and I'm just going to get a message from stale-bot a year from now when this issue is deleted.
Platform
all
Platform Version(s)
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered:
Feature description
First some background, there are two ways to make a Matter light switch. The first way is what everyone is currently shipping. These light switches simply masquerade as light bulbs. They implement device types Light (0x100, 0x101, 0x10C, 0x10d). When the switch is flipped the light goes off and that's how you tell that the switch has been flipped. The problem with these devices is that you can't make lighting groups out of them without using scripts on a controller. For example you can't bind them into a pair for the top and bottom switches of a staircase.
The second way to make a light switch is by using an actual Matter light switch device type - Switch (0x103, 0x104, 0x105). I checked the certified device database and only a single light switch has been certified. It is a switch from Zemismart with device type 0x103. Devices using the Matter switch clusters support binding into groups and you can make the necessary pair for the top and bottom of a staircase. But in general no one is shipping this type of switch.
Please step back and consider how this second type of Matter light switches appears to a consumer. You buy a smart light switch, it is a single physical device. Then the prescribed way to build this second type of smart light switch in Matter is to implement three independent endpoints.
Those three 'independent' endpoints are actually coupled by quantum entanglement so that if you push the switch on the physical device the light EP1 turns off, EP2 sends an ON/OFF event, and EP3 sends button events. If you really want a headache, make a multi-gang device with four switches. Then each of those four switches has three endpoints and it becomes a major mess in a controller app UI to try and correlate which switch is quantum entangled to which bulb.
The problem: These light switches are not three independent devices and should not be represented by three different endpoints! It is actually different aspects of a single device. Here's another way to explain it....
Matter needs a Smart-Switch device, but after weighing the options creating another device type is not the optimal solution. What works better is to allow all possible subsets of these device types on a single endpoint. Yes, the endpoint would list up to nine device types.
Light (0x100, 0x101, 0x10C, 0x10d)
Switch (0x103, 0x104, 0x105)
Generic Switch (0xF)
Electrical Sensor (0x510)
When a single endpoint includes all of these device types Light (0x100, 0x101, 0x10C, 0x10d), Switch (0x103, 0x104, 0x105), Generic Switch (0xF) it is saying: I am a single endpoint. You can treat me like a Light or a Switch or a Generic Switch or all three, but I am still just a single device with varied capabilities and all of those capabilities are integrated. They are not standalone capabilities.
Simultaneously allowing all of these device types on a single endpoint is also great for backwards compatibility. Existing code will just see the one device type it currently supports and it will continue to work unchanged. The extra capabilities will simply be ignored. On existing controllers this has the desired side effect of automatically degrading these smart switches into the first type of light switch -- a light bulb which has a physical switch inside.
To contrast the difference between coupled and independent endpoints, you could also build a lighting device with three independent endpoints. That device would have a light bulb and two separate physical buttons connected to Light, Switch and Generic Switch. Toggling the switch on this device is not going to turn off the light bulb or send generic switch events since the endpoints are independent. This device is not usable in an integrated manner and illustrates the difference between the integrated and non-integrated devices.
I would also argue that a smart-switch is not a composed device. It really is a single device, building it as a composed device still has the problem with the subdevices being entangled with each other. It would also need new software in all of the controllers.
Of course nobody is going to do anything with this and I'm just going to get a message from stale-bot a year from now when this issue is deleted.
Platform
all
Platform Version(s)
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: