Commit: Add demonstration of auto subscription from switch to light. (CON-1515)

[jonsmirl]

f89603b

What is this commit doing? It looks like it is using a controller to subscribe to the light events to keep an indicator in the switch in sync. That's not how this is supposed to work. The way you keep the indicator in sync is to make a group containing the light bulb and the indicator, then the switch sends commands to the group. Doing this with subscriptions gets really complicated when there are multiple switches and lights involved.

The design of the Matter switch device is messed up and I am unable to talk to people about fixing it. If you look at my code for a switch, I am forced into making three endpoints for each switch:

    for (uint16_t i = 1; i < KEYPAD_NUM_BUTTONS; i++) {
        event = {.type = eEnumeratedEP, .enumerated = {.device_type = LOWPAN_DT_INDICATOR, .position = i}};
        ESP_LOGI(TAG, "Enumerating Keypad Switch %dGS", i);
        SendEvent(&event);
        event = {.type = eEnumeratedEP, .enumerated = {.device_type = MATTER_DT_COLOR_SWITCH, .position = i}};
        ESP_LOGI(TAG, "Enumerating Keypad Switch %dS", i);
        SendEvent(&event);
        event = {.type = eEnumeratedEP, .enumerated = {.device_type = MATTER_DT_GENERIC_SWITCH, .position = i}};
        ESP_LOGI(TAG, "Enumerating Keypad Switch %dGS", i);
        SendEvent(&event);
    }

The switch, the generic switch and then the indicator LED. This should not be three endpoints, it should be just one but I am blocked from providing feedback on the spec. My LOWPAN_DT_INDICATOR is an Extended Color Light which is attached to an LED, but I have to change the device type to keep Google/Apple/Amazon from adding it to their UI.

A correct switch endpoint would combine all of the clusters from MATTER_DT_COLOR_SWITCH, MATTER_DT_GENERIC_SWITCH, MATTER_DT_EXTENDED_COLOR onto a single, new device type. This new switch endpoint combines the three functions: it works like a matter switch, you can double tap it to send events, and it has an integrated indicator.

Then to make every thing stay in sync you add both these new switches and the light bulbs to a group. Now when any switch sends an ON command ALL of the bulbs and the indicators will see it.

[jadhavrohit924]

What is this commit doing? It looks like it is using a controller to subscribe to the light events to keep an indicator in the switch in sync. That's not how this is supposed to work. The way you keep the indicator in sync is to make a group containing the light bulb and the indicator, then the switch sends commands to the group. Doing this with subscriptions gets really complicated when there are multiple switches and lights involved.

This commit demonstrates the subscription for one light and one switch to keep the indicator on the switch in sync. Having a group of light bulbs is a different use case which is not demonstrated in this example.

We are looking into the second part of your issue.

[jonsmirl]

Even for a single light and switch this should use a group with two members -- the light bulb and the indicator. There should not be different mechanisms depending on the number of lights and switches involved.

A key thing to observe: the indicator in the switch is implemented as an Extended Color Light but it can't have the Extended Color Light device type (it should be part of the switch endpoint but because I can't change the spec I made LOWPAN_DT_INDICATOR). Since the indicator uses exactly the same clusters as the actual light bulb, when you send group commands it will exactly track the light bulb's state. And this works for as many switches and light bulbs as you want to group together.

This setup is why I was quite familiar with the issues in #1236

Here's my diagram from three years ago:

[jonsmirl]

You will be tempted to make a Generic Switch endpoint and then add the Color Switch and the Extended Light clusters to it. Theoretically that should work, but it won't due to this issue: project-chip/connectedhomeip#36408

What happens is Apple Home ignores the Generic Switch device type and does cluster inspection, when it does cluster inspection it finds the Extended Light clusters and then declares the device to be a light bulb even though the device type said it wasn't. In my opinion Apple Home is broken and doing cluster inspection should be banned. The function of an endpoint should be determined by it's device type, Apple should not be second guessing that.

Right now the only way to make this work is to put the indicator's Extended Light clusters onto a vendor specific endpoint -- ie LOWPAN_DT_INDICATOR. This is only because the spec needs to be fixed to support indicator LEDs on switches, once that is done there is no need for the vendor specific endpoint. Apple will also have to remove its ill-advised cluster inspection code.

[jadhavrohit924]

As I mentioned, this example simply demonstrates how auto subscription can be done in the esp-matter. This is not a production-ready example.

What you are suggesting is a different use case. If we create a group of lights, what will happen if I switch off half of the lights one by one? What will the led_indicator on the switch show as half of the lights are on?

Note: We are not considering led_indicator as a matter endpoint.

[jonsmirl]

There are two ways to control the lights 1) send a group command 2) send commands directly to the light bulbs. If you send commands directly to the light bulbs the group just gets out of sync, but that is the expect behavior. So in your example if you send directed commands to the bulbs, the indicators just get out of sync. To solve that problem: don't send directed commands to the bulbs, use group commands.

Note that it is possible for an individual light bulb to be in two or more groups. If you do that it is quite easy to get the groups out of sync especially if you create groups with incompatible states. But again, that's the way it is supposed to work from the prior Zigbee world.

An alternative way to build this would be that when you group the bulbs and switches together the devices all effectively merge into a single device and you lose the ability to control the bulbs individually. Matter/Zigbee did not choose that approach to grouping.

Once you get this far you are going to discover another flaw in the Matter architecture which I am unable to discuss with the spec people. Zigbee doesn't have multi-admin. So when you made lighting groups on Zigbee all of the controllers could send group commands to the groups. The parallel behavior occurs with scenes.

Matter has multi-admin. Now if you make groups and scenes they are locked onto a single fabric. Since the Google/Amazon/Apple apps can't make groups and scenes I have to make those using my own app and fabric. Of course the groups and scenes I make on my own fabric aren't controllable by Google/Amazon/Apple. To solve this I create 'virtual proxy' devices on my fabric. Dynamically creating the virtual devices does not need any changes to the spec. These proxy devices should be the "Control Bridge" endpoint, but since G/A/A don't support "Control Bridge" yet I only expose them as "Extended Color Lights".

Use my stairway example from above to see how this works. You have two light switches with indicators and you put them into a group. That all works as expected and if you turn on the top light switch the bottom indicator will update the status correctly. The lights are bound to each other using a group and the Matter switch endpoints send group commands to the bound group. But how can Google/Amazon/Apple control this lighting group? In my code when you create a lighting group I also dynamically create a new light bulb endpoint (Control Bridge when supported) which becomes a 'virtual group device'. This new dynamic endpoint is named after the group. What this new dynamic endpoint does is retransmit on/off/level/etc commands sent directly to it as group command onto my fabric, and the reverse for events. You then share this 'virtual group device' to Google/Amazon/Apple (and don't share the member devices of the group). So the 'virtual group device' receives the on/off/level command from the Google/Amazon/Apple fabric and then retransmits them as group commands on my fabric. If you want to turn the group on, just turn the 'virtual group device' on, etc.

I've had all of this working for over a year now. Using this system you can create lighting groups of any size without the complexity of needing a controller to manage the groups.

Note: No one wants to duplicate all of these groups and scenes over every fabric. It is impossible to maintain. You only want to manage these on a single fabric. Using virtual "Control Bridges" and then sharing those is the solution to doing this.