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"
    Thing "powermax:serial:alarm" changed
    val status       = getThingStatusInfo("powermax:serial:alarm")
    val short_status = status.getStatus().toString()


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.