Recursive group membership found

Setup, Configuration and Use Scripts & Rules
1

I’m currently using 3.3.0-SNAPSHOT - Build #2852. I just came across some interesting errors in my openhab log:

2022-04-16 22:10:20.165 [ERROR] [rest.core.item.EnrichedItemDTOMapper] - Recursive group membership found: BackPorch_Light2 is both, a direct or indirect parent and a child of gOutsideLights.
2022-04-16 22:10:20.166 [ERROR] [rest.core.item.EnrichedItemDTOMapper] - Recursive group membership found: BackPorch_Light1 is both, a direct or indirect parent and a child of gOutsideLights.
2022-04-16 22:10:20.166 [ERROR] [rest.core.item.EnrichedItemDTOMapper] - Recursive group membership found: BackYard_Light is both, a direct or indirect parent and a child of gOutsideLights.
2022-04-16 22:10:20.166 [ERROR] [rest.core.item.EnrichedItemDTOMapper] - Recursive group membership found: BackPorch_Light3 is both, a direct or indirect parent and a child of gOutsideLights.

There were other similar messages.

Those items are members (children) of gOutsideLights. I don’t see how they can be parents of gOutsideLights.

gOutsideLights’ parent is just gLights and gLights has no parents.

neither gLights nor gOutsideLights has any tags, metadata, etc attached to them. This is their definition in the .items file:

Group gLights
Group gOutsideLights  (gLights)

Group:Switch:OR(ON,OFF) gBackYardLights "Backyard Lights" (gOutsideLights) {ga="Light", synonyms="Back Porch Lights, Back Yard Lights"}

Group:Switch:OR(ON,OFF) gBackPorch_Switch2 


Switch             BackPorch_Light2                         "Back Porch Light 2"                                                   <switch>           (gOutsideLights, gBackPorch_Switch2, gBackYardLights, gBackPorch)                                                                      ["Lightbulb"]                      { channel="mqtt:topic:backporch-switch2:power1", autoupdate="false", ga="Light", alexa="Light" }
Switch             BackPorch_Light1                         "Back Porch Light 1"                                                   <switch>           (gBackPorch, gOutsideLights, gBackYardLights, gBackPorch_Switch2)                                                                      ["Lightbulb"]                      { channel="mqtt:topic:backporch-switch2:power2", autoupdate="false", ga="Light", alexa="Light" }
Switch             BackYard_Light                           "Back Porch Light 4"                                                   <switch>           (gBackPorch, gOutsideLights, gBackYardLights, gBackPorch_Switch2)                                                                      ["Lightbulb"]                      { channel="mqtt:topic:backporch-switch2:power3", autoupdate="false", ga="Light" }
Switch             BackPorch_Light3                         "Back Porch Light 3"                                                   <switch>           (gBackPorch, gOutsideLights, gBackYardLights, gBackPorch_Switch2)                                                                      ["Lightbulb"]                      { channel="mqtt:topic:backporch-switch2:power4", autoupdate="false", ga="Light", alexa="Light" }

semantic model

Group  gOutdoor         "Outdoor"                              ["Outdoor"]
Group  gBackPorch       "Back Porch"         (gOutdoor)        ["Porch"]

What I can see is that the item is a member of groups gOutsideLights and gBackYardLights.
gBackYardLights is a member of gOutsideLights

Could that cause the recursive membership?

2

Can you show the definition of the item?

3

I updated the original post

4

Looks like the validator has discovered that e.g. BackPorch_Light2 is a member twice of gOutsideLights - once directly, once as a member of ‘subgroup’ gBackYardLights.

The message is a little misleading, but the principle seems right - why would you want that structure?

5

No particular reason. It has been like this since the start. I wasn’t aware that this structure is “incorrect”.

There could be valid reasons for having it this way though. For example, a rule can be triggered with member of gOutsideLights to do one thing and another rule with member of gBackYardLights. So this structure should be allowed, don’t you think?

I suppose I can remove gBackYardLights from the members of gOutsideLights, making the two independent.

6

I don’t think it’s incorrect, the message is a bug. Plain items should not be considered when determining parent objects. Can you please file a bug in openhab-core? Thanks.

7

I’ve just updated to the latest snapshot 3.3.0-SNAPSHOT - Build #2860
I’ll wait to see if the message reappears.

What could possibly trigger it?

8

It’ll reappear, the code did not change since it’s introduction in Fix recursive membership throws StackOverflowException on REST API call by J-N-K · Pull Request #2736 · openhab/openhab-core · GitHub.

9

Thanks for looking into it.

1 Like
10

I’ve been seeing the same error as well, but hadn’t gotten around to digging deeper.

Here’s my perfectly reasonable (in my opinion), non-recursive setup that triggers this error: Many of my automatic lights are controlled by aggregate group states instead of a single sensor. For example the control group in my master bathroom is on if there is motion sensed in the bathroom OR the light in the toilet room is on. The master bedroom control group, however, is on if there is motion in the bedroom OR the masterbath control group is on. Thus, masterbath control group is a member of masterbedroom control group. Both, for rule trigger and UI reasons, are members of the group of all my similar sensor groups.

Definitely not a recursive relationship as there is no path that loops back up from masterbath sensorgroup to either the main group or the masterbedroom sensorgroup, but masterbath group winds up being counted as a member of the general group twice: once directly and once via masterbedroom sensorgroup.

11

It’s “allowed” in that it has created the structure that you asked for.
Still makes no sense to me …

It’s more about Item membership - what do you think the Item gains from being a direct member of both Group and Group’s parent?

12

I’m seeing this error too. I don’t think I have a recursive loop either. Seems like it’s wrong. I would have a similar setup to JustinG’s mentioned above.

13

A fix has been merged three days ago. Do you see this issue on latest snapshot?

14

@J-N-K Thank you for submitting the fix so quickly! I’ve just updated my system to the latest snapshot, and I haven’t seen the error message in the logs.

15

Hi,

i am on actual stable version and got this “problem”, too.

With which stable version will this be fixed?
And is this just a kind of warning or is something really not working with this message?

Thanks,
Alex

16

It was fixed in 3.3.0
3.2.0 didn’t have the issue either.

17

I am on V3.3.0 already, but errors still appear.

18

It‘s not very likely there is another bug, but who knows. Most likely you really created a recursive membership. This might be an issue or not, depending on what you do with groups.

19

I installed stable v3.4 today (3.4.1 release build), seems like the error has reappeared here. I did not see this error in my previous stable version of 3.3.

“Recursive group membership found: gAlarmFlood_ZWave is both, a direct or indirect parent and a child of gAlarmFlood.”

I have branched the group tagging and they finally end up in the same top group. So, as far as I am concerned there is no recursive group membership there. The error is printed every 5th minute so the log reader is running wild :slightly_smiling_face:

Edit: Two days later, after a couple of more restarts, the error seems to have vanished without any changes to the code, so all things are back to normal again. Very interesting though.

1 Like
20

I see this now in Version 4.1.0: All groups reporting recursive membership at openhab start

1 Like