I’m struggling to get a rule working using GroupStateChangeTrigger for all members of a group.
In my case, I have several Hue Lights grouped in gLampe_Wohnzimmer.
For some devices, e.g. ‘Essecke’ a color item change does trigger the rule as expected.
However, when ‘Black IRIS’ color is changed, the rule is not triggered.
Any idea why this is not working for all items, member of this group?
2024-11-13 08:33:15.308 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'item_BlackIRIS_Farbe' received command OFF
2024-11-13 08:33:15.308 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'item_BlackIRIS_Farbe' predicted to become OFF
2024-11-13 08:33:15.309 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'item_BlackIRIS_Farbe' changed from 38.176,42.65700,44 to 38.176,42.65700,0
2024-11-13 08:33:18.199 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'item_Hue_Essecke_Farbe' received command OFF
2024-11-13 08:33:18.199 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'item_Hue_Essecke_Farbe' predicted to become OFF
2024-11-13 08:33:18.199 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'item_Hue_Essecke_Farbe' changed from 71,85,37 to 71,85,0
2024-11-13 08:33:18.214 [DEBUG] [nhab.model.script.Rules.LightControl] - Item: item_Hue_Essecke_Farbe -- State: 71,85,0 -- OldState: 71,85,37
While checking your question I assume to have found the reason, why the changes are not triggered.
However, I don’t understand why this is happening.
For the working light, the “Direct Group Member” is the Color Item itself item_Hue_Essecke_Farbe.
For the non-working items, the Equipment name is listed, e.g. item_BlackIRIS.
When I check the items I realized, that the group gLampen_Wohnzimmer are not in the Parent Groups list of the items ?!?!
Its obvious that changes are not triggering the script.
But why is the item not belonging to the group? Shouldn’t the items inherit the Parent Groups of the Item Equipment group?
GroupStateChanngeTrigger only triggers on changes to direct members of the Group, not members of subgroups.
You’ll also want to be careful using semantically tagged Group Items for control like this. It’s not likely to render in the Overview tabs of MainUI’s Overview page, and if you are not using those there really is little benefit in using the semantic model in the first place.
For a functional Group like this I recommend creating the Group outside the semantic model. Then you can add the light Items directly to the Group so there are no subGroups.
Alternatively, I think jRuby and Jython file based rules offer a “descendents” set of triggers that will ignore subGroups and trigger rules based on the whole hierarchy of Items below the given Group. One could also probably craft a GenericTrigger to capture the descendents. But I think creating a new Group outside the semantic model is going to be easier to implement and maintain in the long run unless you are already using file based jRuby rules (e.g.).
