Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Matter Light Switches make no sense #36329

Open
jonsmirl opened this issue Oct 31, 2024 · 0 comments
Open

[Feature] Matter Light Switches make no sense #36329

jonsmirl opened this issue Oct 31, 2024 · 0 comments

Comments

@jonsmirl
Copy link
Contributor

jonsmirl commented Oct 31, 2024

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.

  1. the light bulb
  2. the light switch
  3. 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.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant