[OH3] [OH2] influxdb persistence - wrong strategy applied?

Hi everyone,

I am trying to optimize the amount of persistence data which is saved in influxdb by various openhab items.
The problem that I noticed is that always the * strategy (everyChange in my case) applies even for items that fall into a different strategy.
For example: some of the Astro* items suffer changes every minute, but I only want to save their persistence data once every hour.
However, persistence strategy applied to all Astro* items is everyChange instead of everyHour.
Somehow the strategy for all items * is taking precedence over the dedicated Astro* strategy.

Here is my influxdb.persistence file:

Strategies {
everyMinute : “0 * * * * ?”
every5Minutes : “0 */5 * * * ?”
everyHour : “0 0 * * * ?”
everyDay : “0 0 0 * * ?”
default = everyChange

Items {
gBattery* : strategy = everyChange, everyHour, restoreOnStartup
gEbusdTemp* : strategy = every5Minutes, restoreOnStartup
gPowerMetering* : strategy = everyChange, every5Minutes, restoreOnStartup
Sun*, Astro* : strategy = everyHour
* : strategy = everyChange, restoreOnStartup

This is happening in both OH3 and OH2.

Is this normal?
I would have expected that the default * strategy should apply only to remaining items that did not match any of the existing explicit strategies.

If I completely remove the * line, then only the explicit items are persisted. Everything else is skipped.

Is there any way to make the default strategy * applicable only to items that did not match any other strategy?


Yes. There simply is no “everything but” choice here, only * for “everything” and specific Items or groups as you specify.
It’s not so much about precedence as simply doing as it is told. It is legitimate for any Item to be included in more than one strategy.

In that case, I would propose the following solution:

  • implement a keyword (named, for example, StopProcessing) which should have a similar behavior to “stop processing other rules” feature in MS Outlook.
    This keyword should be placed, if needed, on a specific Item filter line, with the following behavior:
  • if the Item is matching the filter in this line, apply the strategy and end the execution of this particular persistence instance.

Items {
gBattery* : strategy = everyChange, everyHour, restoreOnStartup
gEbusdTemp* : strategy = every5Minutes, restoreOnStartup
gPowerMetering* : strategy = everyChange, every5Minutes, restoreOnStartup
Sun*, Astro* : strategy = everyHour, StopProcessing
* : strategy = everyChange, restoreOnStartup

Let me know what you think.


Personally I think you just tell the service explicitly what you want. It’s pretty easy to manage all this using groups. But then I’m often baffled by people wanting to persist everything.

You’re certainly not the only one wishing for "everything but"or “everything else”

and I’m sure other discussions.

Another more intuitive approach might be an “except” keyword

   fred : strategy = somestrategy
   * except fred : strategy = otherstrategy

This is simply about adding more flexibility to the setup and, as you said, I am sure I’m not the only one who would want it.
But on the other hand, if people wishing for “everything else” want to use the feature, they can use it. The rest of the world, won’t, so nothing changes for them.
It’s like having the option to exit a do/while or repeat/until loop in most programming languages, even though it breaks the principles of “structured programming”.

Now, moving away from the philosophical side of things.
The problem right now is that the * generic filter is useless if one cannot control / limit it’s scope. That leaves no option but to manage all items in dedicated persistence filters which requires a lot of effort to define groups for all items (or identify naming patterns and appropriate wild cards) and to manage each of them in (one or more) dedicated persistence filter line(s).

Not everone is interested to manage this level of granularity, but would rather prefer to persist everything and to handle only the frequency of persistence operations for “exceptional” cases.
I often find myself spending hours just to add or to reconfigure simple things in openhab. Much of the time spent is caused by the inflexibility of Influxdb which does not allow many simple operations such as renaming a measurement, deleting a column from a measurement or even change the data type of a column.

And yes, your proposal is more inline with the structure of the persistence file syntax, thanks for that.

Looking forward to get more feedback in regard to this :slight_smile:
Thanks a lot,

There are no wild cards either in xxx.persist files.

You’ll probably be miffed to discover they’re not dynamic either, only read at service startup.

You are of course very welcome to contribute, it is a community open source project after all.
Failing that,you’d need to persuade someone who can contribute toimplement your ideas. (That’s not me!)
Suggestions for enhancement can always be made in github.

1 Like

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