UNDEF from group item

  • Platform information:
    • Hardware: yes
    • OS: docker
    • Java Runtime Environment: included with docker image
    • openHAB version: 5.1.1
  • Issue of the topic:

I’m trying to create a group item that acts a bit like one using average aggregation except that I want to aggregate via a rule (in this case i’m using a python rule). The group item is configured with “None” set for the aggregation function as follows:

Name: insideTemperature
Label: Inside Temperature
Type: Group
Members Base Type: Number
Dimension: Temperature (F)
Unit: F
State Description Pattern: %.0f %unit%
Aggregation Function: None

Semantic Value: None
No Tags, No Parent Groups

The groups items are all similar but come from a combination of zwave/ikea-matter binding but are configured as:

Name: Office_Temperature_Indoor_Temperature
Type: Number
Dimension: Temperature (F)
Unit: F

Semantic Value: None
No Tags
appears to be in the temperature group

The reason for my custom “average” script is that I want to track the average temperature of only working devices, anything with a value older than 6 hours is discarded from the average. I’ll later add alerts for this as well.

I’ve tried disabling my custom rule and it seems to get stuck in the UNDEF value but with the rule on, it sometimes toggles to UNDEF then back to the calculated average. I do see a lot message like this that signals the UNDEF came from the item changing:

Item 'insideTemperature' changed from 69.3320006 °F to UNDEF through Office_Temperature_Indoor_Temperature

I had it previously working with a separate group item and a non group item to hold the value, then again with 2 group items where 1 was empty to hold the value but as soon as I add the items to the group, I start seeing the UNDEF values. Part of the reason for wanting them all in a single group item w/o an aggregate function is so that the sitemap (i find pages somewhat unusable still) – I show the group item in the sitemap and it displays the average and lets me drill down and see the group member values as well.

Notes:

  • I have seen a somewhat related post that’s a few years old that mentioned something regarding a different in units or semantic values but I dont believe I’m using any and they all match up.
  • Also, I had previously seen the UNDEF value being set by RRD4j and as a result I moved a new item with a different name than before.

So, when you choose None for the aggregation function that’s somewhat misleading. In fact what that does is set the aggregation function to EQUIVALENT meaning if all the members of the Group are the same state, that’s the state of the Group Item.

That’s never going to happen with a bunch of temperature sensors. And that’s where the UNDEF is coming from.

So in short, you can’t use this approach.

However, if you are excluding the sensor values from the average anyway that probably means you don’t really care if the Item has that stale value as it’s state anyway. So you could use expire to time out those Items, setting them to UNDEF or NULL and use the AVG aggregation function on the Group. I’m all but certain that the aggregation function will then skip over those Items and only include the ones with numeric states in the average.

That will help with the notifications too (as soon as the Item changes to UNDEF you know the data is stale and the sensor isn’t reporting).

If that doesn’t work, you’ll have to go back to storing the average in a separate non-Group Item.

You are indeed using units. You’ve set the Dimension as part of the type.

I can’t think of a single situation where RRD4J would set an Item to UNDEF. That would need more investigation.

The only time RRD4J would set an Item’s state at all is during restoreOnStartup. And there it will set the Item to it’s most recently saved state. And RRD4J doesn’t save UNDEF (nor NULL).

I mistyped and meant that I didn’t think I was using different semantic values.

Aha it is a little confusing, the OH ui does show this:
Group (Number:Temperature:EQUALITY) which I interpreted that to mean “equal to some value” and I figured it meant I can decide that value, like using “equal” as an assignment operator. lol.

I’ll experiment with this as it seems interesting and useful as I also wanted to monitor battery levels as I have some devices that still claim batter but haven’t reported any updates in months. Actually I know I removed the batteries manually to one of those devices that I’ve taken out of service.

There is also Threshold Alert and Open Reminder [4.0.0.0;5.9.9.9] for cases where using Expire isn’t feasible or practical.

You have to be careful in both approaches with very slow reporting Items (e.g. once or twice a day or less). Both Expire and threashold Alert require an update to the Item to kick off the timers that eventually recognize that the Item has stopped responding. If the Item goes offline and OH is restarted before that can be detected the timer will never go off.

So I created Restart Expire [4.0.0.0;5.9.9.9] which sends an update to all the Items with expire using their restored state at OH startup. This will kick off the timers again. I don’t have the equivalent for Threashold Alert, but it would be as simple as changing one word in the rule to pull the Items with threasholdAlert metadata instead of expire.

Would a state-filter work for this? I use it to prevent invalid values from being persisted but I don’t know if it would work for Group aggregation.

Number:Temperature BBQ_Temperature {
  channel="xxx" [
    profile="basic-profiles:state-filter",
    conditions=">= 0 °F", "< 1000 °F" 
  ]
}

Profiles can only be used when you have a link. You cannot Link a channel to a Group and if you could, that wouldn’t match @Miguel_De_Anda’s use case.

I was thinking use the state-filter on each item in the group. If I understand correctly when an invalid update is received the state-filter would ignore the value and the group’s aggregation average would remain unchanged.

But the problem isn’t invalid states updating the Item. It’s the Item not updating at all. @Miguel_De_Anda wants to exclude those Items that haven’t updated in a long time from the average. The Item still retains a valid state though and it’s not updated to something the average can’t handle. The state is just old.

1 Like