I have two things with a ghostly behavior that I’ve never seen this before. Whenever I put this item on a specific rule and make it turn OFF, all lights go OFF.
Then, while that item is inside that rule, if I turn that specific item OFF, it also turns OFF all lights.
There is NO other rule anywhere that sets this.
It is a Shelly device and inside Shelly APP there are no rules.
The same thing happens with another thing so two different things have this weird behavior.
Have anyone ever had this situation? I’ve already removed and created new things and did the same with items (because I’ve noticed sometimes duplicated items or things might cause some problems), but still, didn’t worked.
Yes I do. And actually, by removing them from groups, it actually worked out! But why does this one specifically and not the others on the same groups?
To the best of my knowledge, this should not happen. If you have an aggregation function on a group, the group state will update if an appropriate change occurs in one of the group members. Commands to a group are propagated to the child items, but updates to a group are not. So, there should be no way that just one item changing causes other items in the group to change as well unless there is a bug.
Can you show us this rule? This is the one factor that causes this strange behavior so either this is a result of the rule itself or this is where the bug is.
Ah, I misunderstood, I thought the problems stopped when you removed the item from the rule.
Your OH version is recent enough that the logs should show you the source that causes each log event. Trigger the unwanted behavior and watch the logs. Your group Items are getting a command from somewhere before that command then goes out to all the child items. The log should now be able to help you track down where that command is coming from.
YES! Indeed this IS the solution. In two groups I had “All ON then ON else OFF”. So… whenever at least one of the items went OFF, all belonging to that group would go OFF.
I’ve changed group behavior to “All OFF then OFF else ON” and everything is ok now.
I don’t know if somehow these things are linked via the shelly system (I don’t have any shelly devices so I don’t know the ecosystem), but I’ll say it again, if this is happening entirely within OH, then either a major bug has been introduced, or there is some other explanation for what is going on. This is very simply not the way that group aggregation functions have ever worked or been intended to work. If changing the aggregation function solves your immediate issue then that is because it is masking some other problem, not because it is the actual solution.
I am on a recent OH shapshot and I cannot reproduce this behavior at all. Here’s a quick test example: 1 group with All ON then ON else OFF and three switches:
Clicking on the card with the group state, brings up a handy testing dialog with toggles for the group and the switches:
You can see from the video above that there is no instance of toggling one of the Item switches that impacts the other Item switches. There is no OH core way to do that. Only using the group toggle to send a command to the group item results in all the switches reacting at once.
Given that I cannot recreate the bug in a recent snapshot, and I see no issues or PRs that have addressed and error such as this in the UI or Core repositories, the most probable explanation is that you have some other rule or connection. Even if the Item in question does not show up directly in a rule, then perhaps it can trigger a rule because it is a member of some group and that rule causes your group Item to receive a command that then propagates to all the other items.
However, it is possible that this is a bug in some other area that my test doesn’t cover (such as the shelly binding) so, it would be very helpful for you to find the actual cause and report it if it is a bug.
