Referring to #635 (comment). Some switches, e.g. ubisys, Busch-Jaeger, innr RC 110, iCasa remote, have multiple endpoints with client clusters, controlling a different group of lights from a different (set op) button(s).
The preferred way to expose these switches is to create a single ZHASwitch resource (for the first endpoint), and map the buttonevents from the other endpoints to this resource. The config.group attribute contains a comma-separated list of (decimal) group IDs, instead of a single group ID.
While this was implemented for the ubisys (and the Busch-Jaeger ?) switches, I didn't dara to implement it for the innr RC 110 (#635) nor for the iCasa remote (#1978), because I saw some errors in the deCONZ log. Looking into these errors, they are caused by some (old?) code not considering that config.group might contain a list of groups.
|
const QString &gid = item->toString(); |
|
Group *group = getGroupForId(item->toString()); |
Some of the (newer) code actually does:
|
QStringList gids = item->toString().split(',', QString::SkipEmptyParts); |
As far as I can tell, the old code is used only as a safety net to ensure the /groups resources are available for the group (!) mentioned in the sensor's config.group. Meaning, it's probably safe to ignore the errors and expose the innr and icasa remotes using a single /sensors resource.
Referring to #635 (comment). Some switches, e.g. ubisys, Busch-Jaeger, innr RC 110, iCasa remote, have multiple endpoints with client clusters, controlling a different group of lights from a different (set op) button(s).
The preferred way to expose these switches is to create a single ZHASwitch resource (for the first endpoint), and map the buttonevents from the other endpoints to this resource. The
config.groupattribute contains a comma-separated list of (decimal) group IDs, instead of a single group ID.While this was implemented for the ubisys (and the Busch-Jaeger ?) switches, I didn't dara to implement it for the innr RC 110 (#635) nor for the iCasa remote (#1978), because I saw some errors in the deCONZ log. Looking into these errors, they are caused by some (old?) code not considering that
config.groupmight contain a list of groups.deconz-rest-plugin/bindings.cpp
Line 2682 in 15ff6d3
deconz-rest-plugin/rest_sensors.cpp
Line 2059 in 15ff6d3
Some of the (newer) code actually does:
deconz-rest-plugin/bindings.cpp
Line 2329 in 15ff6d3
As far as I can tell, the old code is used only as a safety net to ensure the
/groupsresources are available for the group (!) mentioned in the sensor'sconfig.group. Meaning, it's probably safe to ignore the errors and expose the innr and icasa remotes using a single/sensorsresource.