Devices with multiple switch endpoints

[ebaauw]

There seem to be two scenarios of exposing devices with multiple switch endpoints:

1. Combine all the switch endpoints into one ZHASwitch resource, as is done for the ubisys devices.
   

   deconz-rest-plugin/de_web_plugin.cpp

   Line 3503 in 4be717c

   // Combine multiple switch endpoints into a single ZHASwitch resource

   
   On receiving a command from a different endpoint from the switch, it's mapped to the one resource
   

   deconz-rest-plugin/de_web_plugin.cpp

   Line 523 in 4be717c

   // No sensorNode found for endpoint - check for multiple endpoints mapped to the same resource

   
   The same is done for the Xiaomi switches, but elsewhere in the code.

2. Expose multiple ZHASwitch endpoints (one per endpoint), as I have done for the innr RC 110 and has been done for e.g. the Busch-Jaeger switches. On receiving a command from the switch, it's handled by the resource corresponding to the endpoint.

Scenario 1 seems cleaner, but we still have an issue with storing multiple groups in config.group (that's why I opted for multiple resources for the innr RC 110).

I seem to remember that my D1 used to have two ZHASwitch resources many versions ago (scenario 2), but we combined them along the way (scenario 1). The old extraneous endpoints seem to be ignored (deleted?) on database load.

deconz-rest-plugin/database.cpp

Line 3207 in 4be717c

// check for older setups with multiple ZHASwitch sensors per device

However, homebridge-hue still expects four ZHASwitch resources for the ubisys C4.

@manup, could you help me with the following questions:

• Should I change the way homebridge-hue supports the C4? I don't have one to test it.
• Is scenario 1) indeed the target?
• If so, will you change deCONZ to expose the other switches as one ZHASwitch resource as well?
• How to deal with config.group in scenario 1?

[ebaauw]

Hmm, #36 (comment):

One of the Busch Jaeger switches has 4 ZHASwitch sensor resources and a dimmable light, here only the switches are shown combined as one device and the light is just treated as separate light.

This seems inconsistent with manup/homebridge-hue@6ae1901?

[manup]

Scenario 1 seems cleaner, but we still have an issue with storing multiple groups in config.group (that's why I opted for multiple resources for the innr RC 110).

Yes for Busch-Jaeger it was the same reason. Personally I like to have just one ZHASwitch resource there the config.group is an array.

When I recall correctly for the C4 it is implemented this way, I can check this over the week.

[ebaauw]

Personally I like to have just one ZHASwitch resource there the config.group is an array.

So let's make that happen. Indeed I would prefer an array for config.group, but that would be a change. Currently it's a string containing multiple groups separated by commas. Semantically, config.groups (plural) would be better for an array.

When I recall correctly for the C4 it is implemented this way, I can check this over the week.

"This" meaning multiple endpoints? Yes, originally, but that was changed. See e.g. #990. "This" meaning an array of groups? No, it's a string, see #990 (comment).

[manup]

The Busch-Jaeger switches need to keep the multiple resources and respective single config.group attribute. There are quite some installations out there with dozens of rules using them.

What we can do here is to extend the first ZHASwitch resource to emit all button events and provide the capabilities. This way everything should still work. The other resources can be marked with an attribute legacy or something like that.

I've already done this for the dresden elektronik Lighting Switch wich also has two resources. All events are reported on the first resource, works pretty well and older installations keep working too.

Instead of using existing config.group attribute we can also introduce config.groups if a resource supports multiple groups.

"config":
{
    "groups": [ { "ep": 10, "id": 200 }, { "ep": 13, "id": "23876" }, { "ep": 15, "id": null } ]
}

or

"config":
{
    "groups": [ 200,  23876", null ]
}

I think the C4 config.group string handling can be upgraded to also support config.groups array.

[ebaauw]

I think I would prefer the second form. As the endpoints are combined into a single ZHASwitch, the endpoint is no longer relevant to the client app. If you do add ep to the config.groups array, I think it should be in capabilities.buttons as well. If not, both arrays should have the same length (with matching positions).

[manup]

The api would indeed be cleaner, ok second form it is. :) The endpoints are only handy for creating bindings if needed, but this can also be mapped in deCONZ.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ebaauw]

This is still an issue, also for the switches, #1509.

[Smanar]

@ebaauw just by curiosity, the opple use binding too, to prevent broadcast command, but I don't see where you do that in the code ?

And I have another problem, on a device (switch with multiple endpoint) I don't want to use one group by endpoint, so I m using only one gid. And I don't think the code can't support this method because of

for (int j = 0; j < (int)srcEndpoints.size() && j < gids.size(); j++)

So do you think it's better use ugly hack, a new fonction to make bind to the coordinator (but without group), or there is something I have missed on the code ?

[ebaauw]

This is an old, stale issue. I did implement a comma-separated list in config.groups for the innr remote RC 110 (seven endpoints) and for the icasa remote (four endpoints). Both these controllers have client clusters on each endpoint, that can be bound to their corresponding group. See #2538.

The Opple now acts as a sensor, sending reports from the server Multistate Input clusters to the coordinator, instead of as a controller, sending commands from the client On/Off and Level Control clusters to a group. Consequently, config.group is no longer exposed for the Opple. Also, like most Xiaomi devices, it sends reports to the coordinator out-of-the-box, so bindings no longer need to be setup. Just need to write the right magic value to the right manufacturer-specific attribute to configure it.

The Tint remote by Müller light from my current PR (#2849) uses multiple groups, but all from the same endpoint. It acts very much like a ZLL device, picking groups on reset without a binding. Did some brilliant (?) hacking to get the groups listed in order in config.group.

[Smanar]

Thx.
BTW I have a doubt, it 's possible bind multiple endpoint to the (only one) same group ?

[ebaauw]

Yes. You can even bind different devices to the same group. Makes sense if you have multiple doors into a room, with a wireless switch next to each door. When pairing ZHA/ZB2 controllers, the REST API plugin creates a group per endpoint and binds the client clusters from that endpoint to that group. ZLL controllers pick the group(s) themselves, and do not require binding. The REST API plugin creates the group when the first command from the controller (endpoint) is received.