Group items not being persisted in InfluxDB

Add-ons Persistence Services
, ,
1

I have just installed InfluxDB and Grafana on my OpenHAB 2.1 installation on Debian.

I’m using group-based persistence so I have the following influxdb.persist file:

Strategies {
    everyMinute : "0 * * * * ?"
    everyHour   : "0 0 * * * ?"
    everyDay    : "0 0 0 * * ?"
	default = everyChange
}

Items {
    gInfluxSlow*    :strategy = everyUpdate, everyHour
    gInflux*        : strategy = everyUpdate
}

Then item definitions like this:

Group gInflux "Items stored by InfluxDB" (gAll)
Group gInfluxSlow "Slow Items stored by InfluxDB" (gAll)

Group:Number:AVG Bedroom_AirTemp "Bedroom Temperature [%.1f °C]" <temperature> (gBedroom, gInflux)

Number MS4_Temp "MultiSensor 4 Temperature" <temperature> (Bedroom_AirTemp, gMS4, gInfluxSlow) {mqtt="<[MQTT:sensors-out/14/0/1/0/0:command:default]",expire="190m"}

Number EnvB_BR_Temp "Bedroom EnviroButton Temperature [%.1f °C]" <temperature> (Bedroom_AirTemp, gEnvB, gInfluxSlow) {mqtt="<[MQTT:sensors-out/7/0/1/0/0:state:default]"}

In Grafana I can see measurements that correspond to the items “MS4_Temp” and “EnvB_BR_Temp” and they have data that tells me they’re being persisted properly. However I can’t access any measurements that correspond to the group items like “Bedroom_AirTemp”. It looks like the value for the group average is not being sent to InfluxDB.

Am I doing something wrong? Is this by design?

1 Like
2

I think this is by design. I’ve not looked into this very deeply but I’ve noticed that only Item members of a Group get persisted when using * in the .persist file. So to save a group like Bedroom_AirTemp you either need to convert it to an Item and use a Rule to calculate the average or list Bedroom_AirTemp (without the *) in the .persist file.

Like I said, I haven’t looked into this closely but I know that my either of my suggestions will work.

1 Like
3

I’d agree with that assessment.

I wonder if we should consider starting a discussion about a feature addition for that use case. @kubawolanin wdyt?

1 Like
4

Thanks Rich, I’m happy enough to work around it by putting the group items in the persist file, though of course that slightly obviates the group-based persistence paradigm.

I’d consider it normal behaviour for the group item values to be persisted though, so I’d support a change to the persistence engine to achieve this.

5

Not every group has a value that can or needs to be pertained. Even if the members should. For me it wouldn’t be evident to always persist the group itself.

My preference would be to explicitly persist the group itself so with * for the items and without for the group itself.

1 Like
6

Sure there are groups with no state values of their own, but surely this fact is available to the persistence engine? Perhaps then groups that have a state value can be persisted?

7

I would think that a Group that is a member of another Group that is being persisted with * is enough evidence for the persistence engine to know that we want the first Group’s state persisted too.

The expected behavior to me is when I use *, ALL members of the Group are to be persisted, not just the Items. To me, that is the more consistent behavior as in almost all other contexts (Rules, Sitemap, etc.) a Group that does have a type can and is treated like any other Item. Why should persistence be the one place where it isn’t?

If you don’t do that, then the expected behavior to me would be to recursively include the members of all subGroups in the persistence. (I don’t like this idea BTW and it runs the risk of circular references).

To simply ignore the Group members of a Group is not intuitive nor is it consistent with the rest of OH.

In the case where the Group never has a state (e.g. was defined without a Type) there will never be any events generated to cause persistence to save anything and the state of the Group would be NULL which already has to be handled by the persistence engine so I don’t think there would be any errors or anything like that. I could be wrong though, would need to test it. I could see it having difficulty figuring out how to create the table space for a Group without a Type.

I wouldn’t count on it. The fact that there is any sort of distinction between a Group without a type and those with a Type is a relatively new change. But, like I said above, Groups without a Type never receive update

1 Like