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

[tlc (Cristian Toader)]

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?

thanks

[rossko57]

@tlc

The problem that I noticed is that always the * strategy (everyChange in my case) applies even for items that fall into a different 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.

[tlc (Cristian Toader)]

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.

Thanks

[rossko57]

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”

Persist everything except...?

Is there any way to do this, if you have certain items with values of no interest that you dont want to save to your database? something like: Items { * except xxxx : strategy = everyChange, everyDay, restoreOnStartup

Puzzled with persistency strategies not being taken into account

Hello, I’m running Openhab 2.5.M4 (yes, still stuck there, but it is a different story) with influxdb as persistency. I did not have to look at the way my items were persisted in a long time, but recently I re-looked at it for items that should not be persisted everyhour… It seems that they are stored everyhour while I had tried to configure them as to be persisted only in case of change. My influxdb.persist looks like this Strategies { everyMinute : "0 * * * * ?" everyHour : "0 0 …

and I’m sure other discussions.

Another more intuitive approach might be an “except” keyword

Items{
   fred : strategy = somestrategy
   * except fred : strategy = otherstrategy
}

[tlc (Cristian Toader)]

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
Thanks a lot,
Cristian

[rossko57]

@tlc

(or identify naming patterns and appropriate wild cards)

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.