Seems clear enough to me
1 Like
My main problem is, I’m still on snapshot #921, will try to update to the newest at the weekend …
I’ve not had a chance to test anything with persistence yet but I can confirm that this change breaks about half of my rules and at least half of my design patterns will need minor updates at best, perhaps withdrawing them entirely at worst.
There is going to be a whole lot of very unhappy users when 2.1 hits beta and again when it hits the full release.
I’m not sure who is the right person to post this (@kai), but it really needs to be announced as a breaking change.
It seems I’ve got my work cut out for me as half of my rules are not triggering at all right now and I need to review and scrub the Design Patterns. It appears the Docs are already updated. The migration tutorial needs to be updated as well.
Grrrrrrr. I’m OK with breaking changes like this. They are to be expected. But when they come out of the blue with no forewarning it does not leave a good impression.
I wish I’d read this before spending the last week wondering and tinkering with my rules to understand why they aren’t triggering. Grrr.
The background of the change that @sihui mentioned was related to the state that such a group has itself. And that was completely broken before, especially with mixed types.
However, this is (or rather should be) unrelated to the capability of triggering a rule whenever a group member changes its state.
I have created https://github.com/eclipse/smarthome/issues/3622 to track this regression.
FTR: This change didn’t intend to break anything, otherwise it would have been discussed upfront - we definitely try our best to keep backward compatibility. The intention of the PR was to fix this bug, which unfortunately seemed to have some side effects.
If you come across such regressions, always feel free to report them early as an issue in the ESH issue tracker. I only came by chance across this discussion here.
I’d suggest to continue the discussion on how to solve the issue best on the issue that @sjka has just created.
1 Like
I have just posted a workaround for your problem in the issue mentioned by Kai:
You can find it directly in this workaround post.
1 Like
Great workaround. Just one of the things that makes this community so great, such quick responses. Thanks for the information!
could you please have a look at my configurations? i dont get it running.
for excample i got a group of three hue lamps, all switches (all the same item-type, no dimmer!)
when i switch the lights on or off, the group item doesnt get a state-update. also the group-item doesnt have the state OFF, it has the state NULL - is that right?
Here is the response body from the rest api:
curl -X GET --header "Accept: application/json" "http://192.168.178.11:8080/rest/items/Group_Wohnzimmer_Licht"
{
"members": [
{
"link": "http://192.168.178.11:8080/rest/items/HueLightstrip_SW",
"state": "OFF",
"type": "Switch",
"name": "HueLightstrip_SW",
"label": "HueLightstrip_SW",
"category": "switch",
"tags": [],
"groupNames": [
"Group_Wohnzimmer_Licht"
]
},
{
"link": "http://192.168.178.11:8080/rest/items/HueStehlampeSofa_SW",
"state": "OFF",
"type": "Switch",
"name": "HueStehlampeSofa_SW",
"label": "HueStehlampeSofa_SW",
"category": "switch",
"tags": [],
"groupNames": [
"Group_Wohnzimmer_Licht"
]
},
{
"link": "http://192.168.178.11:8080/rest/items/HueStehlampeTV_SW",
"state": "OFF",
"type": "Switch",
"name": "HueStehlampeTV_SW",
"label": "HueStehlampeTV_SW",
"category": "switch",
"tags": [],
"groupNames": [
"Group_Wohnzimmer_Licht"
]
}
],
"groupType": "Switch",
"function": {
"name": "OR",
"params": [
"OFF",
"ON"
]
},
"link": "http://192.168.178.11:8080/rest/items/Group_Wohnzimmer_Licht",
"state": "NULL",
"type": "Group",
"name": "Group_Wohnzimmer_Licht",
"label": "Group_Wohnzimmer_Licht",
"category": "Group",
"tags": [],
"groupNames": [
"Group_Wohnzimmer"
]
}
would be great if you could help me solving this problem, because i use the group-state in varios habpanel-widgets.
Hi,
Today I did the Big Upgrade from version #838 to #946.
Everything went pretty smooth. But I noticed I have the same issue as described in this topic. 
I have a pretty big set of rules which are triggered by a group item.
To be a bit more specific, the rule below is not triggered anymore:
rule "Raamcontacten consolideren"
when
Item gRaamcontact received update
then
logInfo("test","Group update trigger works fine")
end
Based on the workaround described in this topic (https://github.com/eclipse/smarthome/issues/3622#issuecomment-307333582), I adapted my group items definition to:
Group:Switch gRaamcontact "Raamcontacten" <window> (gAlarm, gAllecontacten)
Since all items in the group are actually numbers, I also tried this:
Group:Number gRaamcontact "Raamcontacten" <window> (gAlarm, gAllecontacten)
Unfortunately, my rule does not kick in.
To exclude any other cause, I added the individual item(s) of that group in the rule-trigger section. And then the rule is triggered correctly…
So any help would be appreciated. This change has broken 60% of my rules… 
I was also trying to add a function (SUM, MAX). And I noticed that the group status isn’t calculated correctly.
Item:
Group:Number:MAX gRaamcontact "Raamcontacten" <window> (gAlarm, gAllecontacten)
REST API response on gRaamcontact:
(notice that the last item has state “1” but the MAX of the group is still “0”.
{
"link": "http://192.168.3.2:8080/rest/items/Tex_Zone_Z036_W10_2",
"state": "1",
"transformedState": "Open",
"stateDescription": {
"pattern": "",
"readOnly": false,
"options": []
},
"type": "Number",
"name": "Tex_Zone_Z036_W10_2",
"label": "Z36 - Raam bureau zijkant kipstand",
"category": "window",
"tags": [],
"groupNames": [
"gGV_Bureau",
"gRaamcontact"
]
}
],
"groupType": "Number",
"function": {
"name": "MAX"
},
"link": "http://192.168.3.2:8080/rest/items/gRaamcontact",
"state": "0",
"type": "Group",
"name": "gRaamcontact",
"label": "Raamcontacten",
"category": "window",
"tags": [],
"groupNames": [
"gAlarm",
"gAllecontacten"
]
}
EDIT: Solved! I guess when you tamper with the group-functions a restart of OpenHAB is not a bad thing. Restarting solved my problem. I have defined all my groups now as “Group:Number:SUM”
@e36Alex Did you try a restart of openHAB? As this workaround seems to do its job for everyone else, I’d hope you get it working as well 
In general, I would consider the “workaround” even as the official fix, because the change that has been done in the framework really fixes quite some issues and make the architecture much cleaner. So I would suggest to keep things as they are and I will add a clear warning/advice in the upcoming 2.1 release notes that such item definitions need to be updated accordingly.
1 Like
@Kai:
Actually i found a way to get the result i wanted. but the options are not working smoothely in my opion.
here an example:
I have an group of three hue bulps. in the group are just the switches.
So in my opinion the state of the group should be the same in both of the opions with the following switch-states, but it isnt.:
Bulp 1: ON
Bulp 2: OFF
Bulp 3: OFF
ALL OFF --> OFF else ON --> Result: Group state is OFF
ONE ON --> ON else OFF --> Result: Group state is ON
I choose the second option now but i am not understandig the difference.
Also i got another issue during changing the options in the group, have a look at this:
Congrats, you have just found a bug in the Paper UI 
I have entered an issue for it: https://github.com/eclipse/smarthome/issues/3684
No, that is only when you solve a bug. 
oh, i almost expected something like this 
I suppose I’m pretty late to the party but I just upgraded today to 2.1.0-1 and ran into this issue.
My most important rules (used to) work by examining a Group switch status and then querying the Group to see which member last updated it. If a Group is already “ON”, a subsequent “ON” doesn’t update the last member that went “ON”.
What’s the alternative? Check every single switch to see if it changed??
Thanks but I have already read all this and it doesn’t solve my problem. I have already added the Type to my groups to get them to receive updates.
Previously if a Group was updated for example from OFF to ON I could find out which member made that change and that was great. If a subsequent member of the Group also updated from OFF to ON, the Group state didn’t change but a query on the Group returned the second member.
Now, in the above scenario, a query to the Group always returns the first member that did the update.
Since I have read that the issue is closed, I guess I’ll have to rethink my rules.
Thanks.
Maybe some details of this query?