Number:Power item is interpreted as ON by parent group, triggering parent group to go to ON

Setup, Configuration and Use Items & Sitemaps
, , , ,
1
  • Platform information:
    • Hardware: Raspberry Pi 3 Model B Rev 1.2
    • 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? :slight_smile:

2

Can you share with us all the Items which belong to the group tShellyDimmerKitchen?

It sounds like you have a bunch of different types in the same group…

3

Sure. Since I configured everything via the UI, I’ll share a screenshot (isn’t there some textual configuration stored somewhere, also for items defined via UI?).

image
image745×830 47.2 KB

4

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.

5

Yes. Aggregation functions are not supposed to work unless members are of single item type.
It’s not possible to apply any senseful logic to items with different types.

Remove the power item from the group or ignore that it’s happening.

6

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?

Thanks for the fast help!!!

7

E.g. if you would put multiple energy/watt type items into one group, you can see the max/min/avg power consumption.

If you add multiple on/off switches into one group, you can add the “all off then off, else on” logic.

But don’t mix them up, as a state change of the group can also be forwarded to it’s members

8

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.

9

A couple things I notice.

These are all changed events. There are not commands. So it’s the device/binding that is reporting that the devices are being turned on.

Typically, any value that’s not 0 would be interpreted as ON. Though it could be that any value low enough would be considered ON.

/var/lib/openhab/jsondb/org.openhab.core.items.Item.json

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.

10

I’d like to rephrase all that.

You can have any mix of member types in any Group.
but
Aggregation functions only work properly with certain combinations

The worse that can happen if, say, you try and AVG a mix of Location and Color types is a Group state UNDEF. That’s all.

And the Group state, as pointed out, has nothing to do with issuing commands to external devices.
You need to look at the preceding events.log for commands.

11

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.