That might be the case if you’re only using one type of item in your persistence group but as soon as you put multiple types in your persistence group the persistence stops working. I tested that with MapDB and it does not work as I have it configured above, but it did before the change.
Sorry for not being detailed enough: I only posted the switch result, I also have numbers and strings in that group and all are persisted fine.
Still not 100% sure if the changes made it into my build, though …
OK allow that’s good to know! I’ll test some more on my end as well.
I’m not sure if you are right. You have only on item in the group. So no effect.
This will have in impact only if you use more items in a group and different item types (switch, contact, numbers, …)
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
@Kai: Great, i found a bug! Do you think i can exchange it for a solotion here?
No, that is only when you solve a bug. 
oh, i almost expected something like this 