OS: Linux openhabian 5.10.63-v7+ #1496 SMP Wed Dec 1 15:58:11 GMT 2021 armv7l GNU/Linux
Java Runtime Environment: which java platform is used and what version
openHAB version: 3.1.1
This morning when I woke up, I saw that my kitchen lights were on. These are behind a Shelly Dimmer 2 and integrated into Openhab as group tShellyDimmerKitchen.
Apparently, they went on in the middle of the night - by themselves!
I quickly looked into the logs and found the following:
2022-04-27 04:58:27.861 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'tShellyDimmerKitchen_Watt' changed from 0 W to 50.6 W
2022-04-27 04:58:27.865 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item 'tShellyDimmerKitchen' changed from OFF to ON through tShellyDimmerKitchen_Watt
2022-04-27 04:58:27.873 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'tShellyDimmerKitchen_Brightness' changed from 0 to 100
2022-04-27 04:58:27.875 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'tShellyDimmerKitchen_Power' changed from OFF to ON
2022-04-27 04:58:27.877 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'tShellyDimmerKitchen_Brightness' changed from 100 to 53
2022-04-27 04:58:34.313 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'tShellyDimmerKitchen_Watt' changed from 50.6 W to 50.35 W
So apparently, out of nothing, the wattage of the ShellyDimmer went to 50.6 W (possibly a glitch?), which led the tShellyDimmerKitchen to go to ON (as you can see, the brightness was previously set to 0 and the power was OFF, so it must have been the watt change).
The aggregation function of that group is set to “All OFF then OFF else ON”, which is the only sensible setting for me.
This group “ON” then triggered the lamp to actually go to ON.
So tShellyDimmerKitchen_Watt is of type “Number:Power” and has the class “Point”. Why does a change to 50 W result in it being interpreted as ON? I’m wondering because I also have an item tShellyDimmerKitchen_TotalEnergy that has a value of 0.5kWh and apparently is interpreted as OFF, because if not the group would always be ON?
Long story short, how can I make sure that “power glitches” in the middle of the night don’t turn the group state into ON?
Yes, in a JSON-formatted database, but not viewable in the UI outside of the API Explorer. There’s an open issue on this, but it doesn’t look like anyone’s working on it at the moment:
Either way, to me this setup seems strange - I’m not sure that a Group with aggregation functions applied should hold a number of different types of members. You’ve got numbers, switches and dimmers in the same Group. Usually, a Group with aggregation functions applied has members of a single type (only switches, or only numbers holding energy values etc).
This is the root cause though, and needs investigating.
Ah, okay, I didn’t know that this is an anti-pattern. So groups should then rather be used to group similar devices, or group devices in the same room, but not for grouping items that belong to the same thing?
I also do this, to have an Equipment Group (as you say, group all Items that belong to the same device, or Thing), but this is purely for the Semantic Model, and I do not apply aggregation functions to the Group.
I too am surprised this works to the degree that it is. I could see an aggregation function working for a mix of Switches, Dimmers and Color Items since all three can be treated as Switches, but I wouldn 't have expected Number Items to work. I bet it’s treating the Number Items as a Dimmer and any value > 1 is considered ON. That’s why it reports OFF for the 0.5 W reading.
Groups with an aggregation function that is. Without the aggregation function it doesn’t matter what type the Items are. But if you want to summarize the states of the Items in some way, they need to be referring to the same type of thing (e.g. Switches).
Only commands send to the Group from somewhere else (UI, rules, etc.). If the Group’s state changes because of the aggregation function, it will not command or update it’s children.
Update: I removed the aggregation function from the group, but it still happened with exactly the same sequence of events.
But as @rlkoshak says: These are only events, I don’t see a command anywhere. So I guess it’s coming directly from the Shelly device itself? I will have to look at the Shelly debug logs, I enabled them now.