All persistence stopped saving data suddenly (mapDB not active)

helipus · October 15, 2023, 5:58pm

Hi there,
I’m running openHAB 4.0.2(now 4.0.3) on a Synology NAS DS716 in a docker container.

For some weeks I have now the problem that the RRD4J persistence stopped saving data suddently. After I restart openhab everything works fine for some hours and then it happens always again.

Here you the marked the time when I miss the values. Then I restarted and after a while values are missing again.

This happend for all kind of items.
This item I have choosen for debugging.

I don’t find an error in the openhab.log and added some info logs in my rules which are always get called when the item changes:

2023-10-15 15:33:04.118 [INFO ] [nhab.automation.script.file.klima.js] - Automatisierung TaupunktBerechnung Outdorr gestartet.
2023-10-15 15:33:04.119 [INFO ] [nhab.automation.script.file.klima.js] - TemperaturIst_Outdoor:9.6 LuftfeuchteRelativ_Outdoor:72
2023-10-15 15:33:04.121 [INFO ] [nhab.automation.script.file.klima.js] - Outdoor TemperaturIst:9.6, LuftfeuchteRelativ:72, Taupunkt:4.8, LuftfeuchteAbsolut 6.6
2023-10-15 15:33:04.167 [INFO ] [nhab.automation.script.file.klima.js] - Automatisierung TaupunktBerechnung Outdorr gestartet.
2023-10-15 15:33:04.169 [INFO ] [nhab.automation.script.file.klima.js] - TemperaturIst_Outdoor:9.6 LuftfeuchteRelativ_Outdoor:72
2023-10-15 15:33:04.172 [INFO ] [nhab.automation.script.file.klima.js] - Outdoor TemperaturIst:9.6, LuftfeuchteRelativ:72, Taupunkt:4.8, LuftfeuchteAbsolut 6.6
2023-10-15 16:33:04.626 [INFO ] [nhab.automation.script.file.klima.js] - Automatisierung TaupunktBerechnung Outdorr gestartet.
2023-10-15 16:33:04.627 [INFO ] [nhab.automation.script.file.klima.js] - TemperaturIst_Outdoor:9.1 LuftfeuchteRelativ_Outdoor:72
2023-10-15 16:33:04.630 [INFO ] [nhab.automation.script.file.klima.js] - Outdoor TemperaturIst:9.1, LuftfeuchteRelativ:72, Taupunkt:4.3, LuftfeuchteAbsolut 6.4
2023-10-15 17:33:05.051 [INFO ] [nhab.automation.script.file.klima.js] - Automatisierung TaupunktBerechnung Outdorr gestartet.
2023-10-15 17:33:05.053 [INFO ] [nhab.automation.script.file.klima.js] - TemperaturIst_Outdoor:8.55 LuftfeuchteRelativ_Outdoor:76
2023-10-15 17:33:05.056 [INFO ] [nhab.automation.script.file.klima.js] - Outdoor TemperaturIst:8.55, LuftfeuchteRelativ:76, Taupunkt:4.6, LuftfeuchteAbsolut 6.5
2023-10-15 17:33:05.206 [INFO ] [nhab.automation.script.file.klima.js] - Automatisierung TaupunktBerechnung Outdorr gestartet.
2023-10-15 17:33:05.207 [INFO ] [nhab.automation.script.file.klima.js] - TemperaturIst_Outdoor:8.55 LuftfeuchteRelativ_Outdoor:76
2023-10-15 17:33:05.209 [INFO ] [nhab.automation.script.file.klima.js] - Outdoor TemperaturIst:8.55, LuftfeuchteRelativ:76, Taupunkt:4.6, LuftfeuchteAbsolut 6.5
2023-10-15 18:33:05.491 [INFO ] [nhab.automation.script.file.klima.js] - Automatisierung TaupunktBerechnung Outdorr gestartet.
2023-10-15 18:33:05.492 [INFO ] [nhab.automation.script.file.klima.js] - TemperaturIst_Outdoor:7.19 LuftfeuchteRelativ_Outdoor:76
2023-10-15 18:33:05.494 [INFO ] [nhab.automation.script.file.klima.js] - Outdoor TemperaturIst:7.19, LuftfeuchteRelativ:76, Taupunkt:3.2, LuftfeuchteAbsolut 6
2023-10-15 18:33:05.641 [INFO ] [nhab.automation.script.file.klima.js] - Automatisierung TaupunktBerechnung Outdorr gestartet.
2023-10-15 18:33:05.642 [INFO ] [nhab.automation.script.file.klima.js] - TemperaturIst_Outdoor:7.19 LuftfeuchteRelativ_Outdoor:82
2023-10-15 18:33:05.644 [INFO ] [nhab.automation.script.file.klima.js] - Outdoor TemperaturIst:7.19, LuftfeuchteRelativ:82, Taupunkt:4.3, LuftfeuchteAbsolut 6.4
2023-10-15 19:33:06.016 [INFO ] [nhab.automation.script.file.klima.js] - Automatisierung TaupunktBerechnung Outdorr gestartet.
2023-10-15 19:33:06.018 [INFO ] [nhab.automation.script.file.klima.js] - TemperaturIst_Outdoor:6.78 LuftfeuchteRelativ_Outdoor:83
2023-10-15 19:33:06.020 [INFO ] [nhab.automation.script.file.klima.js] - Outdoor TemperaturIst:6.78, LuftfeuchteRelativ:83, Taupunkt:4.1, LuftfeuchteAbsolut 6.3
2023-10-15 19:33:06.090 [INFO ] [nhab.automation.script.file.klima.js] - Automatisierung TaupunktBerechnung Outdorr gestartet.
2023-10-15 19:33:06.091 [INFO ] [nhab.automation.script.file.klima.js] - TemperaturIst_Outdoor:6.78 LuftfeuchteRelativ_Outdoor:83
2023-10-15 19:33:06.094 [INFO ] [nhab.automation.script.file.klima.js] - Outdoor TemperaturIst:6.78, LuftfeuchteRelativ:83, Taupunkt:4.1, LuftfeuchteAbsolut 6.3

I see here and also in the event.log that the items gets changed always as it should. Just the rrd4j don’t get stored?

I found this topic with the exact same problem:

But the solution is not working for me because I don’t have mapDB installed.

Some test which I don’t completly understand? Are the tests all fine?

^

Anyone has an idea why my persistence is not working anymore?

nagisa · October 15, 2023, 8:51pm

cc InfluxDB Persistence stops permanently when Influx-DB-Server has outage for what is likely a similar issue.

helipus · October 21, 2023, 9:44am

I’m running openhab 4.0.3 now the problem is still there.

I did change all the ownership rights now manual like this:
root@openhab-4:/openhab# chown openhab:openhab -R *
The problem is still there.

I have a few of these in my log:

2023-10-21 11:01:12.709 [WARN ] [sistence.internal.PersistenceManager] - Querying persistence service 'rrd4j' to restore 'VS_Einfahrt_Briefkasten_AusrichtungX' takes more than 5000ms.
2023-10-21 11:01:25.073 [WARN ] [sistence.internal.PersistenceManager] - Querying persistence service 'rrd4j' to restore 'Licht_Diele_Decke_ZuletztGesehen' takes more than 5000ms.
2023-10-21 11:01:33.389 [WARN ] [sistence.internal.PersistenceManager] - Querying persistence service 'rrd4j' to restore 'Fenster_Werkstatt_Nord_Batterieladung' takes more than 5000ms.
2023-10-21 11:01:49.656 [WARN ] [sistence.internal.PersistenceManager] - Querying persistence service 'rrd4j' to restore 'TemperaturIst_Schlafzimmer' takes more than 5000ms.
2023-10-21 11:01:54.666 [WARN ] [sistence.internal.PersistenceManager] - Querying persistence service 'rrd4j' to restore 'Alarmsteuerung_Outdoor_Hauseingang' takes more than 5000ms.

Does this help anyone to solve my problem?

Added 2 days later:
Now I have more then 100 warnings like this on a restart. They kept getting more every day?
What can this mean?

helipus · October 21, 2023, 11:19am

It was running only 1h20min after the last restart then the persistance stopped recording again.
events.log shows the values still changed.

helipus · October 22, 2023, 10:33am

Last night I deleted all persistance files and restarted. 4hours later persistance stopped again.

Before there were all from user openhab and group openhab.
After openhab recreated all the rrd4j files it looked like this:

adminDSM@DS716:/volume1/SmartHome/docker/openHAB/userdata/persistence/rrd4j$ ls -l
total 491288
...
-rwxrwxrwx+ 1 dockerlimited users 542416 Oct 22 12:17 Steckdose_S01_Switch.rrd
-rwxrwxrwx+ 1 dockerlimited users 542416 Oct 22 12:15 Steckdose_S02_Switch.rrd
...

adminDSM@DS716:/volume1/SmartHome/docker/openHAB/userdata/jsondb$ ls -l
total 3140
...
-rwxrwxrwx+ 1 dockerlimited users   46247 Oct 12 13:13 org.openhab.core.items.Item.json
-rwxrwxrwx+ 1 dockerlimited users    9206 Oct 14 17:41 org.openhab.core.items.Metadata.json
-rwxrwxrwx+ 1 dockerlimited users   75707 Aug  5 23:18 org.openhab.core.thing.link.ItemCha

My docker variables are:

I checked this on bash:

adminDSM@DS716:/volume1/SmartHome/docker/openHAB/userdata/jsondb$ id openhab
uid=1033(openhab) gid=100(users) groups=100(users),65537(dialout),65536(openhab)
adminDSM@DS716:/volume1/SmartHome/docker/openHAB/userdata/jsondb$ id dockerlimited
uid=1028(dockerlimited) gid=100(users) groups=100(users)

I didn’t changed this for ages. Do I have a problem with rights and ownership?
Shouldn’t all files be from user openhab and user openhab?
I’m very confused now.

helipus · October 22, 2023, 11:53am

ah okay.
If I run a bash in the docker container user and group are still openhab. So this is all right then.

Still searching for the cause of my problem.

mhett · October 23, 2023, 8:23am

I have exactly the same problem in my installation. Maybe it has something to do with the number of persisted items. I had openhab openHAB 4.0.3 running for some time without issues. Now with some additional items rrd stops persisting values after random times. After restarting openhab it works again for a while.
I am curious if this has already been fixed:

github.com/openhab/openhab-addons

[rrd4j] Persistence stops working after some time

opened 01:44PM - 06 Jul 23 UTC

closed 07:38PM - 19 Jul 23 UTC

Flole998

bug

This appears to be a regression in the latest Milestone. After some time (it …seems like it is every full hour) charts aren't loading anymore. When I restart openHAB there's a flat line that begins for example at 15:00 in the charts, so I believe no data was written since then, even though the values changed later aswell (I can see that in the event log). That indicates, that the RRD4J persistance service I am using apparently completely stopped working, it can't be queried anymore and doesn't write data anymore. My persistence config looks like this: ``` Strategies { // for rrd charts, we need a cron strategy everyTenSeconds : "0/10 * * * * ?" everyMinute : "0 * * * * ?" everyHour : "0 0 * * * ?" everyDay : "0 0 0 * * ?" } Items { PersistenceLog* : strategy = everyTenSeconds, everyMinute, everyHour, everyDay, restoreOnStartup RRDPersistence* : strategy = everyTenSeconds, everyMinute, everyHour, everyDay, restoreOnStartup } ``` Could it be that everyMinute and everyHour try to update at the same time, causing this issue? It was working fine on Milestone 3, so I believe this should be adressed before the release.

helipus · October 23, 2023, 8:59am

Hi mhett,
it can be the reason because I also used it a long time with no problems and just added many more items. But I’m not sure if this is the reason. You might be right that the fix from the older bug report is still not active in 4.0.3 because this could be a good explanation.

I added a bug report yesterday to github. Because I couldn’t find a solution here or in discord.
It would be great if you could add some debugging information from your case there so that the maintainer have it easier to find the bug.

github.com/openhab/openhab-addons

[rrd4j] Persistence stopps saving data suddenly (mapDB not active)

opened 01:31PM - 22 Oct 23 UTC

helipus

bug

Hi there, For some weeks I have now the problem that the RRD4J persistence stop…ped saving data suddently. I recognized this because in the temperature graphs the line stopped suddenly. After I restarted openhab everything worked fine for some hours and then it happens always again. Since then I'm troubleshooting this problem and didn't found a solution yet. I tried the forum and discord. https://community.openhab.org/t/all-persistance-stopped-saving-data-suddenly-mapdb-not-active/ **The problem got worth from day to day. Now it takes only a few minutes till the persistence is not working anymore.** ## Expected Behavior Every minute the value of WT_Arbeitszimmer_IstTemperatur should be save from the rrd4j persistence. ## Current Behavior After a restart it shortly works like expected and then it just stops recording values. ## Possible Solution none found yet. ## Steps to Reproduce (for Bugs) Example: I restarted openhab at: `2023-10-22 14:20:18.869 [INFO ] [org.openhab.core.Activator ] - Starting openHAB 4.0.3 (build Release Build)` The first value was saved at 14:22 the last value at 14:47. Then it stopped again. (some other values stopped at 14:40 some at 14:48?!) ![Unbenannt](https://github.com/openhab/openhab-addons/assets/19687604/1face6a2-4a22-45bc-81ae-111b053f39f4) The rrd4j database file still gets written every minute if I check the filetime: ![image](https://github.com/openhab/openhab-addons/assets/19687604/fdaaf2ad-3f08-4482-8634-810e23956784) In total there are 1181 files in the persistence folder. events.log filtered for this item: ``` 2023-10-22 14:22:13.830 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WT_Arbeitszimmer_IstTemperatur' changed from NULL to 21.6 °C 2023-10-22 14:34:22.604 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WT_Arbeitszimmer_IstTemperatur' changed from 21.6 °C to 21.3 °C 2023-10-22 14:37:24.094 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WT_Arbeitszimmer_IstTemperatur' changed from 21.3 °C to 21 °C 2023-10-22 14:45:02.340 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WT_Arbeitszimmer_IstTemperatur' changed from 21 °C to 20.6 °C 2023-10-22 14:49:30.676 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WT_Arbeitszimmer_IstTemperatur' changed from 20.6 °C to 20.5 °C 2023-10-22 15:02:58.618 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WT_Arbeitszimmer_IstTemperatur' changed from 20.5 °C to 20.9 °C ``` So the item is changing correctly, the pesistence file is update but nothing is written. Because when I restart openhab the time from 14:47 till the restart stays empty in the graph. ## Context Maybe this helps debbuging the error: The log at the time the peristances stops: (nothing there which helps) ``` 2023-10-22 14:23:27.435 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Started HABPanel at /habpanel 2023-10-22 14:37:49.546 [INFO ] [penhab.core.model.script.Anwesenheit] - Veit ist wieder da! Er war 9 Minuten weg. 2023-10-22 14:49:12.161 [INFO ] [automation.script.file.oeffnungen.js] - Durchsage auf: Alexa_Arbeitszimmer_TTS 2023-10-22 14:49:39.052 [INFO ] [automation.script.file.oeffnungen.js] - Durchsage auf: Alexa_Arbeitszimmer_TTS 2023-10-22 14:49:39.056 [INFO ] [automation.script.file.oeffnungen.js] - Durchsage auf: Alexa_Werkstatt_TTS 2023-10-22 15:05:29.488 [INFO ] [automation.script.file.bewegungen.js] - Automatisierung gestartet durch: BW_Westfassade_Nord_Bewegung ON 2023-10-22 15:05:29.490 [INFO ] [automation.script.file.bewegungen.js] - Kamera Garten: Preset 7 ``` ## Your Environment I’m running openHAB 4.0.3 on a Synology NAS DS716 with DSM 7.1.1.-42962 in a docker container. docker container configuration: ![image](https://github.com/openhab/openhab-addons/assets/19687604/3f47387b-4e50-4bf8-8c85-80d7bec9649e) ![image](https://github.com/openhab/openhab-addons/assets/19687604/bf46af67-816c-4991-9eac-04ed9cfa20d1) ![image](https://github.com/openhab/openhab-addons/assets/19687604/cd3d8563-6395-457a-9e4f-ad15d0359adb) ![image](https://github.com/openhab/openhab-addons/assets/19687604/4fa2f868-c45c-4b17-84a0-7d49c207cf46) ![image](https://github.com/openhab/openhab-addons/assets/19687604/64bc4c5f-4c60-40d7-bc3c-280b59c82a71) ![image](https://github.com/openhab/openhab-addons/assets/19687604/7c2e92d0-55f6-4e39-9595-1bc88e8ac031) in docker: ![image](https://github.com/openhab/openhab-addons/assets/19687604/44244a7d-a243-4d58-84dc-0ff88f2db77e) on server: ![image](https://github.com/openhab/openhab-addons/assets/19687604/6aa2b36b-1980-413b-9be4-9d829c074853) the following folder just has a readme: `conf\persistence` `conf\services\rrd4j.cfg`: ``` # configure specific rrd properties for given items in this file. # please refer to the documentation available at # https://www.openhab.org/addons/persistence/rrd4j/ # # default_numeric and default_other are internally defined defnames and are used as # defaults when no other defname applies #<dsName>.def=[ABSOLUTE|COUNTER|DERIVE|GAUGE],<heartBeat>,[<minValue>|U],[<maxValue>|U],<sampleInterval> #<dsName>.archives=[AVERAGE|MIN|MAX|LAST|FIRST|TOTAL],<xff>,<samplesPerBox>,<boxCount> #<dsName>.items=<comma separated list of items for this dsName> ```

gd35 · November 8, 2023, 9:18am

Since I upgraded from OpenHAB 3.4 to OpenHAB 4.0, I noticed that I have the same issue…

(see the following screenshot taken at 8h20)

The current version of OpenHAB is 4.0.3. It is hosted within a Docker container on my NAS (Synology). I have to stop and restart the container to fix the problem. It seems that it is an issue with the persistence service (RR4D4J, the only one I have installed) since data were not recorded. When I restart the OpenHAB container, data are again stored but there are missing data (see the following screenshot)

I had a look into the log file and did not see a warning/error when OpenHAB stopped storing the data (around 4h42 this morning) except during the starting phase where I had such warning for some of my items (7 among 576 items in total).

2023-11-07 08:21:40.125 [WARN ] [sistence.internal.PersistenceManager] - Querying persistence service ‘rrd4j’ to restore ‘ZWaveNode028FGR222RollerShutter2_Elec
tricmeterwatts’ takes more than 5000ms.

Any advice to fix the problem ? Or should I upgrade to 4.1 to fix this issue ?

helipus · November 8, 2023, 10:18am

There is no fix yet. Bud I did open an issue (Link I posted before). You can watch this to see when an bugfix will be available. There you find my workaround also which reduces the load on the persistence.

gd35 · November 8, 2023, 10:30am

Thanks for this workaround. Does it mean that I should identify the items (among the 576) that need to be persistent to avoid storing everything ? My current config in mapdb.persist:

Strategies {
  default = everyUpdate
}

Items {
  gTimepicker* : strategy = everyChange, restoreOnStartup
  Chauffage_auto : strategy = everyChange, restoreOnStartup
}

I changed this config by replacing everyUpdate to everyChange as a default strategy. This should reduce the load to the persistence service. I restarted the container. Will see if this change will solve the problem. Otherwise, I will identify which items need to be persistent to reduce further the load.

helipus · November 8, 2023, 11:22am

I reduced the amount of items having the everyMinute strategy till this bug is solved.
I picked the items only where I read the graphs.

I also use mapdb now for the restoreOnStartup.

mapdb.persist

Strategies {
        default = everyChange
}
Items {
  * : strategy = everyChange, restoreOnStartup
}

rrd4j.persist

Strategies {
        everyMinute     : "0 * * * * ?"
        every5Minutes   : "0 */5 * * * ?"
        every15Minutes  : "0 */15 * * * ?"        
        everyHour       : "0 0 * * * ?"
        everyDay        : "0 0 0 * * ?"
        default = everyChange
}

Items {
  * : strategy = everyChange

  //Für Klimacharts & Heizung:
  LuftfeuchteAbsolut, LuftfeuchteAbsolut_Outdoor, TemperaturenIst, TemperaturIst_Outdoor, LuftfeuchteRelativ_Outdoor : strategy = every5Minutes, everyChange
  TemperaturenIst*, TemperaturSoll*, LuftfeuchteRelativ*, Ventile* : strategy = everyMinute, everyChange

  //Anwesenheit:
  AnwesenheitJemand, AnwesenheitPerson1_Delayed, AnwesenheitPerson2_Delayed : strategy = every5Minutes, everyChange

  //Für "Öffnungen in den letzten x Stunden" jede Minute den Zustand speichern.
  Oeffnungen* : strategy = everyMinute, everyChange
}

gd35 · November 8, 2023, 11:27am

Thanks for having pointed me that I did have any configuration for the rr4dj persistence service…
I will right away create one !
Thanks again

gd35 · November 8, 2023, 1:11pm

I have now the folllowing config for the rr4dj persistence service:

Strategies {
        everyMinute     : "0 * * * * ?"
        every5Minutes   : "0 */5 * * * ?"
        every15Minutes  : "0 */15 * * * ?"        
        everyHour       : "0 0 * * * ?"
        everyDay        : "0 0 0 * * ?"
        default = everyChange
}

Items {
  * : strategy = everyChange
}

I will later use the strategies for some specific items. Now by default, data are stored when they change. This should work but… eventually not…

The chart page stopped showing the data when I restarted OpenHAB at 12:00:

This chart visualizes data from 3 items:

ST30Temperaturesalon_Temperature
ZWaveNode035ZMNHJDFlushPilot_Dimmer
RdC_temperature_requise

I then had a look in userdata/persistence/rrd4j to see whether the corresponding persistent files have been recently updated:

-rw-r--r-- 1 9001 9001 755692 Nov  8 13:30 ST30Temperaturesalon_Temperature.rrd
-rw-r--r-- 1 9001 9001 542416 Nov  8 13:27 ZWaveNode035ZMNHJDFlushPilot_Dimmer.rrd
-rw-r--r-- 1 9001 9001 755692 Nov  8 13:30 RdC_temperature_requise.rrd

But does it mean that new data have been stored in them ? Maybe not, because half an hour after, timestamp have changed but not the size… My concern is that I would like to have the chart to display continuous value even if they do not change (like before when default strategy was everyUpdate).

I also checked another item related to my solar panel. The chart representing its evolution (power) works fine:

The last value is from 14:27 (the time I wrote this message).

In conclusion, I will monitor this in the following days.

gd35 · November 8, 2023, 5:15pm

I am making little progress on this issue. Some items work fine in term of persistence. Some do not work. In my previous post, the following item

ST30Temperaturesalon_Temperature

has a persistence issue. After 12:01, nothing is displayed in a chart although the timestamp of the corresponding rrd4j file shows that the file is updated. So, I decided to have a look into it using the rrd4inspector. And I found the reason while it is not displayed:

Is it normal to have NaN into the database instead of a correct value ? If not, where it comes from ?

UPDATE: I decided to have an every minute persistence strategy for all the items and then my OpenHAB system went back to normal behavior.

HenMus · January 11, 2024, 2:14pm

I have the same Synology NAS 716+II with 8GB Ram and have the same issue. I’m running OH 4.1.0. Is your workaround working? Is there a fix?

helipus · January 11, 2024, 3:33pm

@HenMus: I’m still using the workarounf and did not had any trouble with this. Good luck that it works for you too.

the.gangster · April 3, 2024, 6:40pm

As I am also fighting with issues like the ones described here and knowing that you kind of fixed it with your workarounds by modifying/limiting the strategies, may I also provide my findings:

Some background first:
Like @helipus I am also running OpenHAB (4.1.2 meanwhile) in a Docker on a Synology (DS918+).
At some point (I think already shortly after updating from 3.4.4 to 4.0.2 or so) I realized the graphs in OpenHAB stopped showing the statistics a couple of hours after the last restart.
So I added InfluxDB as a second persistence service (leaving RRD4j the default) and was happy to see that there all values are kept up-to-date even after days and weeks runtime. As I had a Docker with InfluxDB already anyway (and another one with Grafana) that was on my to-do list anyway.

Maybe I could simply have removed RRD4j persistence and/or switched default to InfluxDB without ever missing it, but as I had enough diskspace and (like I assumed) performance to run both I kept it like that. And to be honest, I didn’t want to break something I might have not yet understood in all of its aspects neither. As I started with OpenHAB somewhere last year I first rather concentrated on adding all my things and items into the model in my spare time, instead of how to optimize persistence (or even pick the best persistence service for my need).
So that is how it ran so far and with every update I was curious if the issues with the RRD4j data might have been fixed.
As it has not and as I had some time over the easter days, I now searched throught the community and GitHUB for others experiencing the same and that’s how I found this topic.

I also had those “restore … takes more than 5000ms” messages in my logs after a restart of OpenHAB or after removing and readding a thing.
I also had the impression, that the rrd4j persistence stops saving data some hours after a restart again and that a restart was needed to fix it.

But now, that I enabled Trace logging for RRD4j persistence it looks slightly different.
Filtered on just one of the items to better show what happens:

So for me it looks like it has a serious backlog and getting worse.
See the first entry logged at 2024-04-03 18:22:48:
it is storing a value sent at 2024-04-01 14:40:14 (timestamp 1711975214)
and the last one logged at 2024-04-03 18:29:15:
it is storing a value sent at 2024-04-01 14:42:00 (timestamp 1711975320)
So in ~6.5 minutes it was able to only store values of ~1.75 minutes (from meanwhile almost two days ago!). And in deed, the OpenHAB graphs show the values up to that very timestamp.

While those that are being logged with a current timestame 1712161xxx (=the white ones) were all discarded, due to “new value arrived with same timestamp”, but strangely that one is not logged here at all. Maybe it will in 2-3 days, when the processing finally reaches that timestamp. Who knows.

Looks like I can observe the above for every item. A little difference to the energy meter values above though can be seen for the values that are not reported that often:

There (with the same delay in timestamps) it looks like each one is processed twice, which looks strange to me as well but could be as expected.

Sorry for the long text. But wanted to draw a bigger picture than a text like “maybe it doesn’t stop saving completely although it appears to, but creates a massive backlog” could have done.

helipus · April 4, 2024, 7:47am

This might help the developers a lot. best would be if you add it also to the issue in github were they will be looking at: [rrd4j] Persistence stops saving data suddenly (mapDB not active) · Issue #15794 · openhab/openhab-addons · GitHub

the.gangster · April 4, 2024, 1:11pm

Sure.
I thought the topic here is already linked there to give the details.
But commented there now as well with the main findings and linked to here as well.
Let’s see if it helps. Looks like it didn’t really get much visibility so far.