This is working fine and the item is no longer in the group. But if the item state is ON before I remove it from group, the gSwitchesAnzahl group items still has the item as ON in mind and counts this.
This fixes by itself if another item in the group changes status.
It looks like a manual remove of an item does not trigger recalculation of SUM.
Adding and removing Items to and from Groups using Rules like that is not really fully supported. When you do so all of the places where the mapping needs to be updated and maintained do not get updated. This is one of those cases. Removing the Item does not generate any events on the Event Bus so the Group never gets any indication that it needs to recalculate its State.
You can force the issue by issuing this command after removing the member:
gSwitchesAnzahl.removeMember(swSwitch04)
val member = gSwitchesAnzahl.members.head
member?.postUpdate(member.state)
The above will get whatever Item is first in the list of members. If it isn’t null (i.e. gSwitchesAnzahl isn’t empty) if postUpdates the current state of that member which will cause the Group to recalculate its state.
Though I gotta say I’m with Kevin. I tend to be skeptical when I see this sort of dynamic manipulation of Group membership. I’m open to this being a potential way to solve a problem, but I’ve yet to see a problem where this approach is simpler or better than other approaches.
My main target is to do most of the OH config not via coding but with proxy items which controlls this.
groups for controlling actions
groups for controlling alarms
groups for controlling monitoring
groups for controlling messages
groups for …
For this I have to add/remove items from groups via proxy switches which controlls this memberships.
Then my rules will be very easy. If “group get trigger changed” do whatever should be done. Very easy and not so much same code for every item.
But a lot of needed does not work.
previousState or something to detect 100% which item triggers group as a change. Because TriggeredItem does not give me the item within a group. Also group membership management does not fully work.
But it looks like this is not the way OH should be used.
What I fail to see is why you need to dynamically add or remove Items to Groups in this approach. You can code your Rules just like you describe with Items statically assigned to Groups. What am I missing?
From an architectural perspective, this comes across like an example of “when the only tool you have is a hammer, all problems look like nails.” There are lots of other techniques one can apply to avoid lots of the same code for every Item.
Finally, this sort of approach I think is possible using the JSR223 Rules so that might be worth a look if you want to continue down this path.
my config:
lot of Door contacts
a gDoorContact group which has all door contacts in which are needed for notification
lot of window broken switches
a gWindowBrocken group which has all window broken switches in which are needed for notification
At the moment I have a lot of duplicate code.
If doorcontact01 changed to ON then
if doorcontact02 changed to ON then
I want to reduce it to
if gDoorContact changed then
triggeredItem has reported WindowOpen and notify whatever
Code is needed only one time and covers all DoorContacts in group
Most of the Door Open sensors are in the group permanetly but some of them are needed on occation. Due to some reasons. And this group membership should be configured by rule or proxy switch.
if qProxySwitch01 is changed to ON
add triggereditem of proxy switch for doorSensorxx to gDoorContact group
With this I need only one rule for ever group and all other things are outside managed by just managing the groups from other triggers
Concrete example.
My garage door should added to the alarm system but after I leave and the door is closed latest 5 min after alarm system is on.
Easy to solve. Just add garage door sensor 5min. after alarm system is ON vai rule to the group. Nothing else to do. Monitoring or alarm is managed by the group.
So, since we know that Groups can’t really support this very well what other approaches can we use?
Does it work better to add the Item to the Group through the REST API rather than method calls on the Rule?
Put all Items that can potentially ever be part of your gAlarms as members of gAlarms and then use tags on the Items to filter those out that should not presently be considered:
gAlarms.members.filter[i | i.hasTag("alarm")].forEach[i |
// process all members of gAlarms with the "alarm" tag
]
There are addTag and removeTag methods which I think works so you can add and remove the tag to your Items dynamically from Rules.
I’ve never used Tags so I can’t say for certain this would work. And if you are using an extension that depends on tags (e.g. Alexa, Hue Emulation, etc) this might mess that up.
