Auto-persistence deactivated when modifying one item

Add-ons Persistence Services
1

Applies to OH3 RC2
To make a rule-logic of mine work I needed to adjust the persitence strategy of one item (from everyMinute to everyChange), because I needed the last change (a motionsensor).
I could easily change that in a rrd4.persist file as usual.
BUT: I noticed that all other auto-created persistence got lost:
nothing to see anymore in “Analyze”.

Here’s the question:
Is it true, that when I modify one items’ strategy I have to re-create the persistence of all the others?

2

Update to the stable released version and see if the issue has already been resolved

3

rrd4j requires an entry in the database at least every minute or it doesn’t work. You can add saving on changes in addition to every minute, but you cannot eliminate the every minute too.

I suspect that any chart that the motion sensor participates in will be broken but other charts will work just fine. Though it might have messed up the whole database engine, I don’t know. Each Item has it’s own file under userdata/persistence/rrd4j now so you can change the strategy back so it include everyMinute and then remove the file and you’ll be back in business.

If the everyMinute is a problem, you need to use a different database to that Item. If all you need is the last update you can use MapDB for that purpose.

1 Like
4

Unfortunately it’s every chart/persistence that has stopped on that day I’ve added that (one and only) file “rrd4j.persist” to config:

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

Items {
        BLB_Attic_2_Dimmer: strategy = everyChange, restoreOnStartup
}

All the files you mentioned and the date are still there, the auto-storage just stopped on that day.
If you could give me a hint where I could search for settings I will investigate further.
For now I’ll remove that file to see what happens (if persistence commences).

I’m on OH 3.0.0-1 now btw.

5

Two Minutes later I already can state:
removing that one file made other Items record it’s data back to rrdj4 again.
Charts are showing data again.

I can totally understand why this happens (files overrule automagically things that are just working out of the box), but I thing it should be stated in the docs.

6

If that’s the new persist file then that means that that Item is the only Item being persisted now.

That would certainly break charting since nothing is being saved any more but that one item and since that one item doesn’t use every minute even that item won’t chart. And the rest of the Items are turned off so they won’t chart either.

If you override the default persistence, you must redefine persistence for all your Items you want to save. As with all text configs in openHAB. The text file will completely replace the defaults.

7

Off-topic snidey remark: Good! Auto persistence of everything is a horrible bloaty idea anyway :wink:

8

Failing to do so though means that all those Analyze buttons and line charts behind the Item representations will fail to work. And then people will start complaining, “why do I need to create a text file config to make my chart’s work”?

This is also a feature that has been requested a number of times by a number of people. As with autoupdate, a default has to be defined and no matter what is chosen someone is going to be unhappy.

Personally, I’m in favor of this approach (though I might have a little bit of a quibble on applying restoreOnStartup to everything by default). For most users they get an experience they come to expect based on how the UI presents things. If it’s chartable, they can click on analyze and get a chart, and they didn’t have to do a thing to set that up.

rrd4j for this is a compromise though. It’s great in that it’s embedded so it can ship with OH, and the database size never grows. But it doesn’t support all data types.

9

I have a hard time understanding this approach as it makes configuration unnecessary complex and cumbersome. Why isn’t it poosible to define a default strategy for all things and only some different strategies for a few special things (without damaging the default for the rest)? That would make sense but the current logic is just a nightmare for the user…

10

How exactly would that work? There default with rrd4j is all items, every minute and every change. How can you tell it to only do that for some items without requiring defining a new strategy? For example, hw can I say don’t persist Foo at all? You can’t unless you tell it all the items you do want to persist and omit Foo in that list?

And this is exactly no more complex than it has ever been. It’s less complex in fact because in all earlier OH instances you were required to set the strategy because there wasn’t a default.

And it’s consistent with every other configuration for in OH. What’s in the file overrides defaults and what’s configured through the UI in it’s entirety.

11

Perhaps I was not clear enough. I was just talking about the file based persistence configuration and how the entries in the section ‘Strategies’ and 'Items" are handled by OH.
If I define a default strategy within the Strategies-Section

default = everyUpdate, restoreOnStartup

then all items are persisted this way.
Now if I want persist some items “only” every minute (e.g. Bluetooth devices that send a temperature reports all 2 seconds) then I would put them in a group “persist1m” and add a line for this in the config file items-section:

pers1m* : strategy = everyMinute, restoreOnStartup

So the default should be what the word “default” means, the way all items are treated for which there are no special, individual config entries.
Unfortunately OH assumes now contrary to this that ONLY the items in the items-section need to be persisted while the default is no longer valid for all remaining items and stops persisting the rest of items (although default strategy is still “everyUpdate”). This appears not logical to me, because if I really wanted this behaviour, I would not set the default strategy “everyUpdate”, but no default strategy.
It should be eaysily possible to implement this behaviour because OH anyhow needs to parse the config settings in the items-section and decide which entry there is to priorize for an item (group membership, item name etc.). And only if no entry can be found for the item it could easily fall back to the default.

12

There’s two parts to it and you are missing the second part.

The default strategy is what is used if not strategy is provided on an entry in the Items section. But you still have to define which Items are persisted. If you want the default to apply to all Items then you need to tell it so by adding a line that uses * in the Items section. * stands for all Items in the system. If you don’t provide a strategy the default will be used.

pers1m* : strategy = everyMinute, restoreOnStartup
*

The docs should make this clear:

The default parameter assigns a strategy to be used if one is not specified in the Items section below. The default parameter may be omitted from the Strategies section, but only if a strategy is provided in each line of the Items section. If the strategy portion of the itemlist is omitted in the Items section, the default strategy specified in the Strategies section will be applied.
…
where <itemlist> is a comma-separated list consisting of one or more of the following options:

  • * - this line should apply to all items in the system

…

The example Items section below takes advantage of a default entry in the Strategies section. Assume the Strategies section contains the line:

 default = everyChange

then the following section,

Items {
   GF_Hall_Light
}

will cause the state of GF_Hall_Light to be persisted on every change.

This is how persistence has always worked since the very beginning. You have to define the strategy and you have to assign the strategy to the Items, even for the default strategy. Nothing has changed in how this config file has worked since before OH 1.6.

1 Like
13

Thank you for clarifying this. However, the problem remains the same. It seems not to be possible to define a special strategy for some items and use the default for “all others”. Your suggestion was:

But, as soon as I use the wildcard * in the items section ALL items will be persisted with the default strategy. Also the items which are a member of the pers1m group for which a special startegy is defined will be persisted according to the * line. So unfortunately I will have to assign all my 1358 items manually to a group just to assign them to the default strategy which is not really a comfortable approach. It would be much more efficient if one could only define a special strategy for some items while OH falls back to default for the rest.

Yes, but it has been cumbersome eversince. It forces you to explicitely assign persistence parameters for each and every item manually (either by group membership or by mentioning every single item in the items section of the persistence file) instead of offering a default for the rest.

1 Like
14

You can file an issue and see if anyone will volunteer to implement it. The .persist file still needs to be migrated to the UI so perhaps supporting something like this would be considered when implementing that.