Disable the default restoreOnStartup in the channel definition

Ok, I finally got some time to test this and I think @Lolodomo is right. While I was making these changes, I had a lot of trouble with channels picking up stale values after restart, due to what seemed like a race condition with the persistence layer. I wasn’t able to reproduce it this weekend though. So it’s possible there was a problem with this previously and it got fixed (I’ve upgraded to 3.1.0-final since then), or maybe it was a different issue in my dev environment. In any case:

After a restart now, all of the channels (including zones violated, arm state, etc.) will start with their persisted values, but those are all set even before the binding starts initializing. Once it goes Online, they get set to the current values as queried from the panel. And if this fails, the old values remain but the binding never goes Online. The only values that can’t be queried are the Last Trip timers, which will be wrong if a zone was tripped while OH was down, but I’m not going to stress about this.

The net result is that the alarm channels can be considered safe to use if the binding is Online, and not otherwise. I created a channel to expose this, and I don’t let any of my rules fire unless the binding is Online:

// String Powermax_BindingStatus

rule "Alarm Connection Status"
when
    Thing "powermax:serial:alarm" changed
then
    val status       = getThingStatusInfo("powermax:serial:alarm")
    val short_status = status.getStatus().toString()

    Powermax_BindingStatus.postUpdate(short_status)
end

I still think this has the potential to be confusing and non-intuitive for users with the default persistence strategy. @rlkoshak I understand that you need to provide sensible defaults, and some users might want different behavior than the default. I don’t think it has to be all-or-nothing though. My suggestion is that the binding author should be able to provide persistence hints that give a reasonable default behavior for each channel. Any user who wants a different behavior could customize it of course. But I don’t think “persist everything” and “persist nothing” need to be the only out-of-the-box options. That’s probably a discussion for a different thread though.

From what I recall from my most recent trip into persistence service configuration, the underlying model has a notion of “filter”. I suppose these are rather for excludes since items or groups are specified to be included. Since handling of filters/excludes is currently missing in persist files and persistence manager I did my own experiments.
Based on that I coded my own persistence configuration mechanism which allows to manage exclusion filters:

I still do verify actual behavior to be sure it works. So, in theory with a lot of caution there is a way to exclude some of items from persistence policies.

2 Likes

I had a similar problem with the rrd4j default configuration, as there is no restore for strings. Which is quite strange for a default user.

Is there any reason mapdb is not included per default in a way where it only affects strings? I guess it’s quite an overhead ov two services need to react on everychange of everything. One is enough.

At least would have been nice to have a config file representing the default config of rrd4j to just remove “restoreonstartup”, instead of having to recreate the config file based on a short textual description in the docs what rrd4j supposedly does on default. This would have made it easier for the OP as well to just change it so some items don’t get restored.

There is no database that meets all the requirements for a good default persistence:

  • embedded, no external services required
  • limits storage so it doesn’t grow forever
  • stores historic data so anything that can be charted in MainUI will be chartable by default

rrd4j comes the closest to meeting all of those requirements.

No, this is not technically feasible at this time. It could be configured to do that but that configuration requires knowledge only you know (i.e. the names of the Items that are Strings). There is no way to tell persistence to “save all String Items”.

There are open PRs being worked to add the ability to configure persistence strategies through MainUI. When those get merged it will be as simple as changing the existing config.