Design Pattern: Group Based Persistence

No problem. There are lots and lots of details. It’s easy to miss.

Dear @rlkoshak ,

Many thanks for this great tutorial.
I hope you can help me with the following issue:

I did the setup as described in the first post of this thread. I want to use MapDB for restore on startup and RRD4J for charting. After switching from my approach - which was to include specific items into rrd4j.persist - to using groups, it doesn’t render the charts anymore.

My rrd4j.persist file:

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

Items {
    gR* : strategy = everyUpdate, everyMinute
// .items File
    Group gM            // mapdb - persist all items on every change and restore them from the db at startup
    Group gR            // rrdj4 - for Items to preserve their history + charting

    String SonoffS201_wifirssi      "Sonoff S20 #1: Wifi RSSI [%s]"     (gM,gR,Gsonoff) { channel="mqtt:topic:mosquitto:sonoff_0xxx:Sonoff_0xxx_rssi" }


   Frame label="Charts Sonoff S20" {
        Text item=Gcharts {
            Chart item=SonoffS201_wifirssi refresh=60000 period=h service="rrd4j" legend=true

I always get this message - for all items I’ve tried so far:

[WARN ] [thome.ui.internal.chart.ChartServlet] - Chart generation failed: null

With no charts:




Default persistence is set to rrd4j:

Unfortunately I don’t use rrd4j any more and I don’t use OH generated charts any more so I don’t really have anything to offer. What you have posted looks like it should work and the error is not informative.

Ok, thanks for letting me know.

Should I open a new thread for this issue? I want to avoid cross posting …

It would probably be best to open a new thread

I don’t use rrd4j either but maybe this thread can help you troubleshoot if you have a data issue or just a charting issue.

@rlkoshak, I noticed that you persist all items on startup, and I’ve done the same. However, the Persistence section of the Configuration Guide says:

It is usually not necessary to restore all Items since there is a good chance that they are no longer accurate (switches may have been toggled, sensor values are likely to have changed), and the restoration may result in unwanted rule actions.

It seems that persisting all items is fairly common in the OH community. Couldn’t persistence be limited to items that can’t be updated when OH starts up (e.g. unbound items)? It would theoretically be more accurate and have a very minor side benefit of reducing writes to the storage medium.

This is all moot if OH doesn’t actually update items on startup. I thought I might test it later by turning off persistence and seeing which items become NULL or UNDEF after I restart, but I wonder if I’m missing the bigger picture.

You mean restore all Items at startup?

Persistence would have no way of knowing. And there are cases where you may want to restore Items even if they are bound/linked to something. And if you know what you are doing and what to expect, there is nothing inherently wrong with restoring all Items at startup. It is a dangerous option, yes, but not an unuseful option.

When OH starts up or loads a .items file, all items get initialized to NULL. If you have persistence set up and configured to restoreOnStartup, OH will then update the Item with whatever the most recent value stored in the database happens to be. If your Rules happen to already be running these updates and changes might cause Rules to trigger and depending on what your assumptions are in those Rules and what those Rules do that may be undesirable behavior. Or it may not matter at all. Or you may have checks in those Rules to handle this case.

It’s impossible to preemptively detect and understand the difference between all of these cases so the docs warn the user to be deliberate instead of lazy. The correct solution (i.e. restore all or just some) is entirely dependent on your specific context.

For this design pattern I did the lazy thing so I wouldn’t have to go into all of this which is really not the main focus of the DP. I should also note that this DP was written before that sentence was added to the docs. :wink:

UNDEF is a different state entirely and is used by bindings or Rules to indicate that we don’t know what state the Item happens to be in. For example, if the MQTT Broker Thing goes offline, the MQTT binding will set all the Items linked to Channels on Things attached to that Broker will get set to UNDEF. By default the Expire binding will set an Item to UNDEF if you don’t specify the state yourself.

Yep, I should have been referring to restoring items, not persisting them. Thanks for picking up on that.

This is really what I was trying to ask. But now that I think of it, the more direct question is: when OH starts up and initializes items, does it ask them for their current states? If so, restoring seems unnecessary for items that can respond to requests, or for items that post frequent updates to OH.

That depends entirely on the binding-device combination. There is no built-in OH mechanism to ‘refresh’ all item states because that wouldn’t work for many device types.
So, for items that receive very frequent updates of the status from linked devices, there really isn’t a need for RestoreOnStartup, but if the device only sends its status when it changes, it would certainly help to persist its status.
The main purpose of RestoreOnStartup is for OH not to lose state in case of a restart for instance.

1 Like

No, it does not. The Item will remain NULL until such time something changes that. That something can be restoreOnStartup, the binding, a Rule, or manual interaction from a UI.

You might be surprised to learn that technologies that support having their current state reported on demand is in the minority. But indeed, for Items linked to devices that do get immediately updated you would not want to use restoreOnStartup in the off chance that the binding updates the Items before persistence gets a chance to.

1 Like

I am a little surprised by that. Guess I’ll find out which of my devices do it later tonight, with the expectation that the answer will be “few to none”. Thanks!

rlkoshak thanks so much for this contribution and all your others!

One point to note that caught me up for a while. If you are using more than 1 persistence service and you want to call a specific one to use it has to be the last string in the parentheses!
e.g. item.previousState(false,“rrd4j”) NOT item.previousState(“rrd4j”)
(note item.previousState() works and uses the default persistence service and I believe it assumes False input. Specifying True returns last state different to current state).
Just noting on this thread as this seems the go to thread for setting up persistence apart from the official docs.

hi i am looking for the way to use my db to learn haw we use the lights and then replay them when we are not home. say we are away for longer then a week. so i can turn on leave mode. and it will run it as if we where there. ?

Bit of a random thread to post to. Are people shy of making new threads?


Rich, could I ask why you don’t use rrd4j any more - is there a better way for charting?

It doesn’t support Switches and Contacts and doesn’t work with external graphing packages.

Though I believe HABPanel has pretty good charting and OH 3’s UI will come with some better charting options than the defaultsold openHAB 1/2 charting.

1 Like

Hi I’m struggling to receive the average temperature of a room using groups.

if (myActualTemp !== null) {
logInfo (myRuleName,"Item: " +
var Number n_AvgTempDay=myActualTemp.averageSince(now.withTimeAtStartOfDay,“mysql”)
logInfo (myRuleName,"Status: " + myActualTemp.state.toString)
logInfo (myRuleName,"Durchschnitt: " + n_AvgTempDay.toString) }

I assume that I cannot cast the average temperature using the myActualTemp item. The return value of n_AvgTempDay=myActualTemp.avg… is null.
How to solve?


Bear in mind that we don’t know what kind of thing myActualTemp is.
You mention that is an Item, perhaps it is a Group type Item?

The obvious candidate for a no-data return would be that you did not persist any data. You can persist the value of Group Items, if that is what we are dealing with here. First you must give the Group a state, by defining a type and aggregation function for it. Then you must explicitly include the Group Item in your xxx.persist file. No “wildcards” * because they are not wildcards and mean something special to persistence.

as an aside -

this is not really a sensible test for an Item

Thanks, I missed to provide some more information about this.
I do have for each room an item storing the actual temperature. This value is persisted at every change.
All of them are assigned to a group called gRoomActualTemp.

Number    Wohnzimmer_IstTemp    "Wohnzimmertemp [%.1f °C]"          <temperature>   (gRoomActualTemp)   
Number    Wohnzimmer_IstTemp_DailyAvg       "Durchschnittliche Zimmertemperatur" <temperature>  (gRoomDailyAvgTemp)

In a rule, once a day, I want to calculate the average temperature for the room. In order to ease the coding I use the following code:

	gRoomActualTemp.members.forEach[myActualTemp | 
	if (myActualTemp !== null) {
		var Number n_AvgTempDay=myActualTemp.averageSince(now.withTimeAtStartOfDay,"mysql")
		logInfo (myRuleName,"Durchschnittliche Temperatur im Zimmer " + myActualTemp.label.toString + " ist " + n_AvgTempDay.toString)
		val myDailyAvgTemp = gRoomDailyAvgTemp.members.findFirst[ myTempItem | == + "_DailyAvg"] as NumberItem
		logInfo(myRuleName,"durchschnittliche " + myActualTemp.label + " gesetzt auf " + n_AvgTempDay.toString)
		if (myDailyAvgTemp !== null) {myDailyAvgTemp.postUpdate(n_AvgTempDay)}

But I think that this is not working, but not sure how to solve using a pattern instead of considering each item separate in the rule.