I did only notice because my new group definitions rely on this change 
So does anyone have a suggestion for accomplishing what I’m trying to do then since the functionality has been changed?
In theory (and according to the docs), if you use a type and a function for the Group, it will update it’s state (from it’s members):
Try something like:
Group:Switch:OR(ON, OFF) gLivingRoom (gFirstFloor)
I will run some tests also
I can do that, the issue is I have multiple types of items in the same group and according to the docs that won’t work. I can play with it and see what happens.
It is just sooo frustrating when I get everything working and something like this changes and breaks all my code.
For every item type only the associated valid item states may be used in group definitions (switch only accepts on/off, contact only accepts open/closed, …).
From what I know ALL items accept NULL and UNDEF.
I’m using that with the expire binding for number items, after expiring the number item changes from a valid state to UNDEF through
Group:Number:OR(UNDEF,NULL) gCheckSensorStates “State [%s]”
and I am able to trigger rules on that group (changing from NULL to UNDEF) an easy way on UNDEF if they don’t get an update after some period of time (ESP8266 sensors sometimes hang …).
I don’t know if that would help for your setup.
1 Like
Seems to me this should be announced as a breaking change.
While I don’t necessarily disagree with the change per se, it is a change that will break a lot of people’s rules (mine included). I think an announcement is warranted.
8 Likes
There’s another issue I seem to notice. When you nest groups, the documentation says that each item in the lowest level group should appear in or belong to the highest level group as well. But working with them that doesn’t seem to be the case.
As an example:
Groups and items:
Group gtAll
Group:Dimmer gtLights (gtAll)
Dimmer TestLight1 (gtLights)
Dimmer TestLight2 (gtLights)
Rule:
rule TestRule1
when
Item TestSwitch changed
then
gtAll.members.forEach[item|
logInfo("TestRules", "Item: " + item.name)
]
end
When I run this rule I expected to see the Dimmers but I don’t. Maybe I’m not interpreting the documentation correctly?
I could be interpreting things incorrectly so let me know if I am.
Doesn’t .members get members of that group? and .allMembers get members of group and members of subgroups?
2 Likes
does the change in handling groups (only members of the same type are possible) also has an impact of presistence config?
Which means I have to change my presistence config too and create for every item type a separate presistence group?
That is a really good question. If that is the case I take back my original comment and do disagree with the change. This would be a step backwards for many of us.
Is anyone running with this code and can build up a test to see what works and what doesn’t?
This change invalidates a number of my Design Patterns and a good number of my running Rules.
I understand that breaking changes occur but to just drop this on the users unaware does not provide a good experience to the users.
I agree. This seems to be a major change without much user feedback or input from the community.
I did create a simple group for settings for the MapDB persistence service and have noticed it doesn’t seem to be saving my data on changes anymore. It might be that I have something set up incorrectly but here’s my setup.
Items:
Group gSettings
//ItemType Item Name "Item Text" <Icon> (Groups membership) ["Tag"] {Binding association}
Switch HolidayTime "Holiday Time" (gSettings)
Dimmer MovieOnLevel "Movie Light Level" (gSettings)
Dimmer NightOnLevel "Night Mode On Level" <moon> (gSettings)
MapDB persistence setup:
Strategies {
everyDay : "0 0 0 * * ?"
default = everyChange
}
Items {
gSettings* : strategy = everyChange, everyDay, restoreOnStartup
}
This was working before the update and now is not. If this is due to the new group behavior I think we should consider whether this is a forward change or not since it will likely break a lot of already stable setups.
Unfortunately I had to go back for other reasons to snapshot build #921, BUT:
According to this the change was implemented 2017-05-11 (#194), my build is from 2017-05-19, so that new function should be in there.
Group:
// Persistence Groups
Group gRestore // for Items to restore on startup (mapdb)
Item:
//Testing
Switch Test_Mapdb <switch> (gRestore)
Persistence:
Strategies {
everyMinute : "0 * * * * ?"
everyDay : "0 0 0 * * ?"
default = everyChange
}
Items {
gRestore* : strategy = everyChange, restoreOnStartup
}
REST API output Switch=OFF:
{
"name": "Test_Mapdb",
"datapoints": "1",
"data": [
{
"time": 1496771017607,
"state": "OFF"
},
{
"time": 1496771017607,
"state": "OFF"
}
]
}
REST API output Switch=ON:
{
"name": "Test_Mapdb",
"datapoints": "1",
"data": [
{
"time": 1496771063741,
"state": "ON"
},
{
"time": 1496771063741,
"state": "ON"
}
]
}
So for me it looks like it is still working with a “plain” old group definition.
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.