Group membership issue

I’m beyond confused by this, I have removed my items file for the phones (IP and BT detection) and put the file back in place after confirming they are removed; but my group is reporting a status that is not ON. I have a fake phone item for overriding rules if someone is staying at my house that I don’t their phone setup in OpenHAB.

openhab> smarthome:items | grep gMob
gMobiles (Type=GroupItem, Members=5, State=OFF, Label=null, Category=null)
FakePhone (Type=SwitchItem, State=OFF, Label=Fake Phone, Category=null, Groups=[gMobiles, gPersist])

openhab> smarthome:items | grep gMob
gMobiles (Type=GroupItem, Members=5, State=UNDEF, Label=null, Category=null)
FakePhone (Type=SwitchItem, State=ON, Label=Fake Phone, Category=null, Groups=[gMobiles, gPersist])

I caught this with my own phone the other night after seeing some oddness with a rule, so I don’t think its limited to a virtual device being a member.

Anyone else have a issue like this or have a suggestion of where I can go to resolve this?

Interesting find while troubleshooting this, I removed FakePhone from the group membership and the state of the group is working in an ON/OFF state. Still not sure what caused the issue as this wasn’t the behaviour when I first configured the items.

hi,

the group state “undefined” can happen, if you have not defined in which way the group state has to be calculated. If you have a group with switches (and only switches), you have to define it in a way like:

Group:Switch:OR(ON, OFF) group_movement

That means one Switch to “ON” is enough to switch the whole group to “ON” (OR). Did you define your group like that? if you just use

Group group_movement

you will get into trouble with an undefined state.
Source: https://github.com/openhab/openhab1-addons/wiki/Explanation-of-items#group

cheers

Excellent catch @spy0r! What still stumps me is that things did work as I would of kept working on it until it worked as an ON/OFF.

For future readers my second post about removing the FakePhone item membership did not change this behaviour in the long run; using the ‘Switch:OR(ON, OFF)’ resolved this issue.