Groups seem to be broken

Setup, Configuration and Use Items & Sitemaps
, ,
1

All,
I am currently on the snapshot version of OpenHAB and I did an update last night and as soon as I restarted OpenHAB the standard Group functionality seems to have changed.

I have a rule the watches for a group to receive an update. In that group are a few switches and dimmers. If any of the switches or dimmers change or receive an update, the group was receiving an update, and that would trigger my rule. It was working fine until I updated last night. Now when one of the items changes or receives an update the group does not.

Did something change in that build? That’s a fairly big issue for me since I rely on that a good bit for my rules.

Any help would be appreciated.

Thanks!

2

Info are missing:
OH2 Snapshot Build #
Items and Groups
Rules
Some logs

Without this info… no-one can provide substantial help :stuck_out_tongue:

Btw: I am on the latest snapshot (932) I didn’t see any problems with Groups getting updates (I will check again)
Anyway, snapshots are unstable by definition :slight_smile:

3

Sorry, should have included more info!

Build 2.1.0 build 931

Groups and Items:

//Location Groups
Group 	gAll
Group 	gAllLights
Group 	gFirstFloor		(gAll)
Group 	gSecondFloor	(gAll)
Group 	gFrontPorch		(gFirstFloor)
Group 	gEntry			(gFirstFloor)
Group 	gLivingRoom		(gFirstFloor)
Group 	gDiningArea		(gFirstFloor)
Group 	gKitchen		(gFirstFloor)
Group 	gHallway		(gSecondFloor)
Group 	gMasterBedroom	(gSecondFloor)
Group	gUpstairsBathroom	(gSecondFloor)

Dimmer	LivingRoomCeilingLights		"Living Room Ceiling Lights"	<light>			(gLivingRoom, gLights)		["Lighting"]

Dimmer	EntryFanKeypad				"Entry Fan Keypad"				<light>			(gLivingRoom, gCeilingLights)				

Dimmer	LivingRoomKeypad			"Living Room Keypad"			<light>			(gLivingRoom, gCeilingLights)	

Dimmer	FrontLivingRoomFanLight		"Front Living Room Fan Light"	<light>			(gLivingRoom, gCeilingLights)["Lighting"]	
Number	FrontLivingRoomFanSpeed		"Front Living Room Fan Speed"	<fan_ceiling>	(gLivingRoom, gFans)

Dimmer	RearLivingRoomFanLight		"Rear Living Room Fan Light"	<light>			(gLivingRoom, gCeilingLights)["Lighting"]
Number	RearLivingRoomFanSpeed		"Rear Living Room Fan Speed"	<fan_ceiling>	(gLivingRoom, gFans)

Rule using these items that’s causing an issue:

rule SyncLivingRoom
when
	Item gLivingRoom received update
then	
	logInfo("SyncLivingRoom", "gLivingRoom received update")
	if (syncAllTimer == null)
	{
		syncAllTimer = createTimer(now.plusSeconds(2))[|
			var itemsOn = gLivingRoom?.members.filter(items| items.state == ON || items.state > 0)
			//logInfo("LivingRoomRules", "Items on in the Living Room: " + itemsOn.toString())
			var numItemsOn = itemsOn.size
			logInfo("LivingRoomRules", "Num Items On In Living Room: " + numItemsOn.toString())
			if (numItemsOn > 0)
			{
				if (AllLivingRoom.state != ON)
				{
					AllLivingRoom.postUpdate(ON)
				}
			} else {
				if (AllLivingRoom.state != OFF)
				{
					AllLivingRoom.postUpdate(OFF)
				}	
			}
			syncAllTimer = null
		]
	} else {
		syncAllTimer.reschedule(now.plusSeconds(2))
	}
end

There are no errors in the log. Actually there really is nothing in the log at all. The items update based on me changing the values or the bindings updating (they are on Insteon PLM) but the group just doesn’t update at all.

Maybe I should run update again to get to build 932, but if that doesn’t work I might role back. Just wanted to point it out so that if it is an issue it gets resolved if it’s not recognized yet.

Like I said, before I ran the update everything worked perfectly fine, even after rebooting the system a number of times. After the update, I rebooted about three times and that rule doesn’t work any more.

If it’s something I’m doing let me know!

Thanks!

4

As far as I understand


a group without a type or function can only be used for displaying purposes now, the state of the group does not change anymore.
Also see these not yet published doc changes:

1 Like
5

I don’t use rules that are triggered by Group updates but I just checked my OH2 snapshot #932 system and I can replicate this…

I have a group with only 1 item.
When I change the state of the item, the group state does not update…

openhab> log:set DEBUG smarthome.event.GroupItemStateChangedEvent
openhab> items list |grep P05
P05_Light (Type=SwitchItem, State=ON, Label=P05 Light, Category=switch, Groups=[GF_P05_Laundry, gGF_Lights, gKNX])
GF_P05_Laundry (Type=GroupItem, Members=1, State=OFF, Label=P05 Laundry, Category=washingmachine_2-1, Groups=[gGF])

I will do more checks.

6

I really am struggling to understand the reasoning behind that decision. I have a number of rules that rely on that behavior and it’s always been present and operated that way, so if that is the decision I have to say I really disagree with the decision to change it.

As far as I understand if you have a group with multiple types of items it can’t have a type or function. Am I understanding this correctly? And is there a way I can accomplish the same thing in a different way?

7

Wow, thanks for the heads-up @sihui ! I missed this one

8

From the docs:

Please note that this can only be used if all items in the group have the same type.

http://docs.openhab.org/configuration/items.html#groups

9

I did only notice because my new group definitions rely on this change :sunglasses:

10

So does anyone have a suggestion for accomplishing what I’m trying to do then since the functionality has been changed?

11

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

12

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.

13

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
14

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
15

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?

image.png1078×442 25.2 KB

I could be interpreting things incorrectly so let me know if I am.

16

Doesn’t .members get members of that group? and .allMembers get members of group and members of subgroups?

2 Likes
17

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?

18

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.

19

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.

20

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.