Often this sort of thing happens because when you wrote the rule all of your switches had a state. But when you upgraded that Switch no longer had a state. One thing that could explain that is that in 2.x, rrd4j no longer supports storing Switch Items. So perhaps you were relying on a restoreOnStartup from rrd4j which no longer works in 2.x to make sure that Item had a value.
To filter the null Items out you can do a line like the following:
val ChangedSwitch = All_Lights_switches?.members.filter[s|s.lastUpdate("mapdb") != null].sortBy[lastUpdate("mapdb")].last as SwitchItem
Thanks Rich. My previous version was 2.1 (something from Feb-2017) that worked with no issues with rrd4j.
Anyway after understanding that I donāt really need rrd4j and my current mapdb setup is enough, I have now transitioned to just mapdb.
Thanks for the tip on detecting ānullā timestamps.
I upgraded to OH 2.1 and hoped, that the group problem was solved.
In OH 2.0 the group membership for items very often was not updated. Should be fixed in OH2.1. But not at all. There are some szenarios where there is no update to the group membership of items. The only way is to restart OH. Is there an additional way just to recreate group memberships for items?
The problem you are describing is not the same as the problem primarily described in the thread.
The thread is about a change made to how the state of a Group is calculated which was necessary but which now requires the users to provide a type in their Group definitions for those Groups to receive updates. And this change is implemented and deployed, I think in 2.1, definitely in 2.2.
You are describing a completely different problem, if I understand correctly, the membership in your Groups is not being updated when you make changes to your Items.
Iāve seen this in the past and I think there is an issue open for it.
As far as I know there is still no solution for that. You must still restart OH to refresh group memberships. I know it adds an extra step but hopefully itās not too painful for you. I know thatās one of the reasons I upgraded my platform from a Raspberry Pi 3 to an Intel i3 PC running Ubuntu. The speed difference is very appreciable.
On another note, I did some experimenting after updating to OH2.1 and found that if you create a group with mixed item types (Dimmers and Switches) itās best to create the group as a Dimmer type. Since dimmer inherits the OnOffType base type (which is what a switch is) the system will not be confused by the inclusion of Switches in the group. This way whenever any of the items in the group receive updates the group will as well.
That way you can use the group in a rule that reacts to āreceived updateā.
when
Item gRoomGroup received update
then
Do Stuff Here
end
An added benefit is that the system will not attempt to set invalid values on a Switch Group item when it gets a Dimmer command. Thus clearing up unnecessary errors in your log files.
Yes, according to the documentation that does work. And if you use it that does work. BUT, when you do that and one of the Dimmer items changes in the group you will always get an error that says an invalid value was set on the group item. However, if you make the group item Dimmer instead of a switch you will not get that error AND the received update trigger still works. My advice is there in order to reduce errors in your log. On top of which I donāt know what other issues those errors could be causing. This way you avoid the errors altogether.
