[OH3] Rrd4j persistance not working for groups

When the file is touched, the logs show:

2022-01-23 00:21:04.634 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'rrd4j.persist'

I’m assuming that rrd4j is installed and active because:

  • The 2nd paragraph of Persistence | openHAB mentions exactly that;
  • All the regular items, ie not groups, are stored and I have charts with data with several months old.

However, on the UI it is not selected as default, but there is not other installed.

Then it is not yet using your file that specifies only the two groups (and will disable default selections).
System seems to see it okay, but not using it yet. Try a restart to make it active,

I think rrd4j being offered there confirms it is installed.
Selected as default service or not makes no difference to what is stored when, but if you have no default service your charts/analyze pretty stuff will not work.

I misunderstood the meaning of default. I assumed the items would be saved, no matter what, and we needed only to add the groups. Given that, I changed to the rrd4j.persist file to:

Strategies { 

    everyHour : "0 0 * * * ?"
    everyDay  : "0 0 0 * * ?"
    everyMinute : "0 * * * * ?"

    default = everyMinute
}

Items {
    * : strategy = everyMinute, everyChange, restoreOnStartup
    sens_grp_temp_int : strategy = everyMinute, everyChange, restoreOnStartup
    sens_grp_temp_ext : strategy = everyMinute, everyChange, restoreOnStartup
}

Note: above I’m using the real group names.

Activating the rrd4j log level to debug, using log:set DEBUG org.openhab.persistence.rrd4j, I can see:

$ tail -F /var/log/openhab/openhab.log|grep grp_
2022-01-23 03:20:46.711 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Stored 'sens_grp_temp_ext' as value '9.09' in rrd4j database (again)
2022-01-23 03:20:46.715 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Stored 'sens_grp_temp_ext' as value '9.06' in rrd4j database
2022-01-23 03:20:47.723 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Stored 'sens_grp_temp_ext' as value '9.06' in rrd4j database
2022-01-23 03:20:48.761 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Stored 'sens_grp_temp_ext' as value '9.03' in rrd4j database
2022-01-23 03:20:49.770 [DEBUG] [d4j.internal.RRD4jPersistenceService] - Stored 'sens_grp_temp_ext' as value '9.03' in rrd4j database

However on the UI I don’t see anything (empty chart, when analyzing the group (Items menu)).
On /var/lib/openhab/persistence/rrd4j there are files with the names of the groups, which proves (I think) the values are being stored.

Could it be that you need to distinguish between ( from the docs ):

  • <itemName> a single Item identified by its name. This Item can be a group Item. But note that only the group value will be persisted. The value of the individual group members will not be persisted using this option.
  • <groupName>* - all members of this group will be persisted, but not the group itself. If no strategies are provided, the default strategies that are declared in the first section are applied. Optionally, an alias may be provided if the persistence service requires special names (e.g. a table to be used in a database, a feed id for an IoT service, etc.) Note that * is NOT a wildcard match character in this context.

Okay, so persistence is all working.

As discussed earlier -

When asking for a chart of a Group, there is another issue. Did you mean the Group aggregate or did you mean all the members. Not sure how/where you select that in MainUI

rrd4j is enabled by default on any OH3 installation to persist any item.
BUT you must delete your rrd4j.persist for that to work else it overrides the default.
So the most simple and fastest solution is to simply delete it.

PS: you don’t want to persist the group itself anyway but the items within.

OP stated that they wanted to persist the Group Item as it contains data itself.

Group states such as AVG will compute dynamically from their member states.
I don’t know for sure but I think the rrd4j persistence implementation doesn’t care about persisting group states themselves because there’s little or no use in doing so.
If you have a use case you can create a ‘shadow’ type of item (write a rule to copy the group state over on any change) and persist that.

It will do it if you explicitly tell it to, using .persist file (and it’s a numeric state)
OP says he has it working now.

Do you mean that an AVG group wouldn’t need to be persisted, since its items are?

When we have several sensors to create a measurement (average), it’s not that useless.

It looks as the only option!..

here: http://openhab:8080/analyzer/?items=ITEM&chartType=&coordSystem=

replace ITEM with an item or group, and you get a chart.

With the config I posted before

I’d say it should persist all the items and 2 groups. So the items that belong to the group are persisted also. And the logs suggest that. Just in case, I added the group items to the config:

Items {
    * : strategy = everyMinute, everyChange, restoreOnStartup
    sens_grp_temp_int : strategy = everyMinute, everyChange, restoreOnStartup
    sens_grp_temp_int* : strategy = everyMinute, everyChange, restoreOnStartup
    sens_grp_temp_ext : strategy = everyMinute, everyChange, restoreOnStartup
    sens_grp_temp_ext* : strategy = everyMinute, everyChange, restoreOnStartup
}

But nothing changed. The item and group definition is this:

Number:Temperature    sens_temperatura_exterior_cave     "Temperatura exterior cave [%.1f ºC]"     (All, sens_grp_temp_ext)    {channel="modbus:data:qcv:qcv_temp:qcv_temp_ch_1:number"}
Number:Temperature    sens_temperatura_exterior_anexo    "Temperatura exterior anexo [%.1f ºC]"    (All, sens_grp_temp_ext)    {channel="modbus:data:qanx:qanx_temp:qanx_temp_ch_1:number"}
Number:Temperature    sens_temp_1a                       "Temperatura ambiente 1.ª [%.1f ºC]"      (All, sens_grp_temp_int)    {channel="knx:device:bridge:generic:knx_temperatura_1a"}
Number:Temperature    sens_temp_rc                       "Temperatura ambiente R/C [%.1f ºC]"      (All, sens_grp_temp_int)    {channel="modbus:data:sot1:sot1_temp:sot1_temp_ch_1:number"}
Group:Number:AVG      sens_grp_temp_ext                  "Temperatura exterior [%.1f ºC]"
Group:Number:AVG      sens_grp_temp_int                  "Temperatura interior [%.1f ºC]"

Not really clear what is and is not happening now.

The first persists the state of the Item, even if it is a Group
The second persists all members of a Group.
This has worked for many years.

This seems to show it still works?

You can use REST API (API explorer) to interrogate rrd4j and check if data is retrievable, as well as reportedly stored, for a given Item.

I would not expect GUI charting/analyze to work until/unless you select a default persistence service for it to use.

1 Like

Why don’t you look into the .rrd file of a group using the rrd4j inspector. That way you will know wether aggregated data is stored or not.

Read Here on how to open a .rrd file (and change the data, which you don’t need). The last post gives the link to the actually used rrd4j version ( I haven’t used THAT one yet).

Edit:
Using the REST API to look into the .rrd file is the better solution.
@rossko57 :+1:

It all depends on your use case (which you didn’t tell so this is somewhat an XY type o’ question).

Yes in theory you can postprocess everything. Depends on your use case and programming capabilities what would be the easier solution.

You can also use groupitem.persist() inside rules.

The bottom line is: when using this URL:

http://openhab:8080/analyzer/?items=ITEM&chartType=&coordSystem=

and replacing ITEM with an item or group, a chart should be rendered with a time series of the past values of the ITEM.
It works as expected (I expect…) for regular items, but for the groups in the rrd4j.persist file it doesn’t.

The rrd4j.persist file is:

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

Items {
    * : strategy = everyMinute, everyChange, restoreOnStartup
    sens_grp_temp_int : strategy = everyMinute, everyChange, restoreOnStartup
    sens_grp_temp_ext : strategy = everyMinute, everyChange, restoreOnStartup
}

The groups I want to persist are sens_grp_temp_int and sens_grp_temp_ext.

And rrd4j is selected as default on the UI:

I tryed out the REST API to inspect the persistence, and these are my findings:

1. Get the persistence list

http://openhab:8080/rest/persistence
response:
[
  {
    "id": "rrd4j",
    "label": "RRD4j",
    "type": "Queryable"
  }
]

2. Get the persisted items (default persistence service)

http://openhab:8080/rest/persistence/items
response:
[]

3. Get the persisted items (default persistence service)

http://openhab:8080/rest/persistence/items?serviceId=rrd4j
response:
[]

4. Get the persisted values from group (default persistence service)

http://openhab:8080/rest/persistence/items/sens_grp_temp_ext
response:
{
  "name": "sens_grp_temp_ext",
  "datapoints": "1389",
  "data": [
    {
      "time": 1642908360000,
      "state": "9.03"
    },
    {
      "time": 1642908420000,
      "state": "9.0"
    },
    {
      "time": 1642908480000,
      "state": "9.03"
    },
    {
      "time": 1642908540000,
      "state": "9.03"
    },
   ...
   ]
}

From the above, responses 2, 3 and 4 were not what I was expecting… For 2 and 3, I was expecting to get a list of all the items that are persisted (all the items, plus 2 groups). Response 4 proves data is being stored for the group, but for some reason is not rendered by the UI.

2 Likes

That REST return proved that the group items are persisted.
The checks number 2 and 3 are well known for that (mis-)behaviour.

1 Like

Leve the poor bloody rrd4j alone now, your problem is with analyze.

I wonder if the old OH2 chart widget still works, try

http://openhab:8080/rrdchart.png?items=sens_grp_temp_int&period=M

2 Likes

Yes it does! :woozy_face:

Okay, so are you happy that rrd4j persistence does work for Groups, and you are now in control of what and when gets stored?

Leaving a problem with the analyze servlet.
See if you can make sense of this apparent workaround -

1 Like

Yes!

I will

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.