Need help with persistence RRD4j

Hi guys,
i have openHAB 3.2.0 running on a Pi 4.

I want to enable the persistance for some Items and worked through the documentation. Still, it doesn´t work. After a reboot the Item shows NULL again.

This is what i did:

  • Enabled RRD4j in the settings as default
  • Put a textfile in openhab-conf//persistende with the name rrd4j.persist

Code in rrd4j.persist:

Strategies 
{
   everyMinute	: "0 * * * * ?"
   everyHour    : "0 0 * * * ?"
   everyDay     : "0 0 0 * * ?"
   default = everyChange
}
 
 
Items
    {
        VerbrauchAblesung_Dezember : strategy = everyChange, restoreOnStartup
    }

What am i missing? :wink:

What type of Item is that? rrd4j is limited to essentially numeric Items.

Note that this xxx.persist file will stop rrd4j persisting anything else at all (Don’t ask, don’t get) as it overrides the default strategies.

If you are only interested in restore-on-startup (for any Item type) use the Mapdb service, created for the job. You may have multiple services in use.

@rossko57
It is a number item

Alright, now use the API Explorer to see if the Item is being persisted. Remember you asked for onChange, so would need to see a changed event in your events.log.
In the case of rrd4j you can also inspect the folder userdata/persistence/rrd4j or something like and see a file for each Item name.

The default rrd4j configuration in the absence of any rrd4j.persist file at all, would be for every Number type Item would be to restore-on-startup.

For purely restore on startup (no charting etc. wanted) the MapDB recommendation stands.

@rossko57
allright, i will try MapDB first. Looks a lot simpler :wink:

TY!

It depends what you are trying to achieve; if it’s a learning exercise, work through plan A and find the mistake.

I’m using a combination of mapdb and influxdb. Basically throw everything at influxdb but then just use mapdb for persistence of the few things I want restored, which is typically stuff like ‘lastSeen’, ‘lastUpdated’ and the likes where it’s impossible to query a device for the actual state.

@rossko57

Hello again :wink:
I tried my very best, but still i have problems.

I added some switches and number items to my mapdb.persist file. Now, in my userdata folder → persistence → mapdb i can clearly see, that storage.mapdb gets updated every time i change the status of that switch.
But still, after a hard reboot (unplugging my pi), the values and switches are not restored.
When i use “sudo systemctl restart openhab.service” it works just fine, but also items are persisted, i do not have on my mapdb list.

I am confused :wink:

Here my config for mapdb.persist

Strategies 
{
   everyMinute	: "0 * * * * ?"
   everyHour    : "0 0 * * * ?"
   everyDay     : "0 0 0 * * ?"
   default = everyChange
}
 
 
Items
    {
        LueftungsanlageOGUG : strategy = everyChange, restoreOnStartup
        AutomationLueftungCO2 : strategy = everyChange, restoreOnStartup
        LueftungSommer : strategy = everyChange, restoreOnStartup
        Auto_Licht_Haustuer : strategy = everyChange, restoreOnStartup
        Autom_Bewegungsmelder_Ueberdachung : strategy = everyChange, restoreOnStartup
        Weichnachtsbeleuchtung : strategy = everyChange, restoreOnStartup
        Autom_Geraete_Nachts : strategy = everyChange, restoreOnStartup
        PumpeNotification : strategy = everyChange, restoreOnStartup
        RollosAutomodus : strategy = everyChange, restoreOnStartup
        BadezimmerThermostetModes : strategy = everyChange, restoreOnStartup
        BastiThermostatGooglemodes : strategy = everyChange, restoreOnStartup
        EddaThermostatModesGoogle : strategy = everyChange, restoreOnStartup
        FieteThermostatGooglemode : strategy = everyChange, restoreOnStartup
        GoogleModeItem : strategy = everyChange, restoreOnStartup
        PiaThermostatModes : strategy = everyChange, restoreOnStartup
        SchlafzimmerThermoststModes : strategy = everyChange, restoreOnStartup
        WZSuesGoogleThermostatmodes : strategy = everyChange, restoreOnStartup
        WZNordGoogleModes : strategy = everyChange, restoreOnStartup
        GoogleKuecheModes : strategy = everyChange, restoreOnStartup
        Bad_7_Solltemperatur : strategy = everyChange, restoreOnStartup
        Basti_6_Solltemperatur : strategy = everyChange, restoreOnStartup
        edda_6_Solltemperatur : strategy = everyChange, restoreOnStartup
        Fiete_2_Solltemperatur : strategy = everyChange, restoreOnStartup
        kueche_4_Solltemperatur : strategy = everyChange, restoreOnStartup
        Pia_5_Solltemperatur : strategy = everyChange, restoreOnStartup
        Schlafzimmer_1_Solltemperatur : strategy = everyChange, restoreOnStartup
        WC_8_Solltemperatur : strategy = everyChange, restoreOnStartup
        WZnord_2_Solltemperatur : strategy = everyChange, restoreOnStartup
        WZsued_1_Solltemperatur : strategy = everyChange, restoreOnStartup
        VerbrauchAblesung_Januar : strategy = everyChange, restoreOnStartup
        VerbrauchAblesung_Februar : strategy = everyChange, restoreOnStartup
        VerbrauchAblesung_Maerz : strategy = everyChange, restoreOnStartup
        VerbrauchAblesung_April : strategy = everyChange, restoreOnStartup
        VerbrauchAblesung_Mai : strategy = everyChange, restoreOnStartup
        VerbrauchAblesung_Juni : strategy = everyChange, restoreOnStartup
        VerbrauchAblesung_Juli : strategy = everyChange, restoreOnStartup
        VerbrauchAblesung_August : strategy = everyChange, restoreOnStartup
        VerbrauchAblesung_September : strategy = everyChange, restoreOnStartup
        VerbrauchAblesung_Oktober : strategy = everyChange, restoreOnStartup
        VerbrauchAblesung_November : strategy = everyChange, restoreOnStartup
	    VerbrauchAblesung_Dezember : strategy = everyChange, restoreOnStartup
        Solltemp_zwischenspeicher_Edda : strategy = everyChange, restoreOnStartup
        Solltemp_zwischenspeicher_Kueche : strategy = everyChange, restoreOnStartup
        Solltemp_zwischenspeicher_WZNord : strategy = everyChange, restoreOnStartup
        Solltemp_zwischenspeicher_WZSued : strategy = everyChange, restoreOnStartup
        Solltemp_zwischenspeicher_WC : strategy = everyChange, restoreOnStartup
        EBikeVerbrauchTotal : strategy = everyChange, restoreOnStartup
        EBikesAblesungZwischenspeicher : strategy = everyChange, restoreOnStartup
	    Auto_AbschaltungHWRUG : strategy = everyChange, restoreOnStartup 
    }

Do you see my mistake?

That sounds like you are crashing the host, not rebooting.
Are you using ZRAM to store your database files?
The loss then is entirely predictable.

@rossko57

No, no ZRAM here.
So is there no way to persist items in case of a loss of electricity?

You are running openHAB on a raspberry pi4, chances are high that you used openhabian. In this case ZRAM would be usex as the default setting automatically.

This is telling us you are using ZRAM, in other words a volatile database.

I guess you mean restored?
Where there are multiple persistence services, thay can all do restore-on-startup.
Which service does what is controlled by individual xxx.persist files.
In the absence of a xxx.persist file for any individual service, a default strategy is invoked. Exact detail of default strategfy varies for each service, but all are essentially “persist everything you can - and restore on startup”.
So any given Item may be persisted in multiple places and restored multiple times.

@rossko57

allright, i think i understand that.
So, what do i have to do to get my items restored after i.e. a system crash, blackout, wife not knowing anything about that little box etc. ? :wink:

Volatile means, it gets lost after the pi lost its power?

Ty so much

Yes.
To avoid that you would need to record your database to non-volatile stroage medium - for a Pi, that is probably SD card.
You’d exclude your database from ZRAM.
The cost of that is a small performance reduction, and reduced SD card life.

If you were only worried about restore (and not lost charting etc.) then you might only deal with Mapdb in this way.

A halfway-house solution is to arrange a script or process to periodically save the volatile database to permanent store.