I am running openhab 2.4 and having an issue when i restart. It seems that not everything is restoring values on startup. I have 2 persistence profiles configured. 1 to restore on start up (mapdb) and 1 going to mysql for historical and graphing.
Strategies {
default = everyUpdate
}
Items {
// persist all items on every change and restore them from the db at startup
* : strategy = everyChange, restoreOnStartup
}
and
Strategies {
// for rrd charts, we need a cron strategy
everyMinute : "0 * * * * ?"
default = everyChange
}
Items {
// additionally persist weather info every minute
gHistory* : strategy = everyUpdate, everyMinute
gChart* : strategy = everyUpdate
* : strategy = everyChange
}
Items are initialized to NULL. restoreOnStartup will replace the NULL with the most recent value in the database.
Some bindings will set an Item to UNDEF, meaning undefined, when they fail to connect or lose their connection and their Things go offline.
The bindings are doing this after restoreOnStartup runs.
You need to look at the individual bindings to see if there is a way to modify this behavior in the binding, or roll with it. It is actually quite useful to know that an Item’s state is unknown like this.
It definitely appears right now that it is the new mqtt binding that is setting things as UNDEF until a value comes in. I have some other things that are NOT configured to the mqtt binding and they restore ok. I believe I can work with that. Thanks for the recommendation!
Do rules execute after the bindings load? i am guessing yes. I am considering an onstartup rule to run through a specific group, if it’s set to UNDEF, manually restore the values. But obviously it would have to run after everything loads
You didn’t mention which binding you were using. This is a known issue. When the binding starts up it subscribes to the configured topics. If there is no value on those topics it sets the Item to UNDEF.
When restoreOnStartup runs, it only restores those Items that are NULL. So no matter what, as long as your sensors are not using retained messages, the MQTT2 binding will set the Items to UNDEF until such time that the sensor publishes a new reading.
At first I too was annoyed by this but as I think about it, it really makes a lot of sense. If a sensor reading should persist, then a retained message should be used in the first place. If one is worried about stale data then UNDEF is the correct state for the Item to be in until a new reading is published.
But, it does break the expected behavior of restoreOnStartup. David is aware of the situation but doesn’t really have an idea for a fix yet. I think this is a case where being flexible is our best option.
Unfortunately the order that things get loaded is not terribly well defined and there are some real problems with startup order. But I do something almost exactly as you describe to reset my Expire binding timers and it works 99% of the time. Periodically it will run before things are ready and I’ll get exceptions in the log during startup so I do have to monitor that when I reboot.
It doesn’t occur often enough for me where I’ve tried to see if putting the code in a timer and running it later would fix it. I’m pretty sure it wouldn’t but I’ve never tried.
I gotcha. You are right, those sensor values I should have the retain message set for the mqtt. I completely forgot about that. I may end up having to do a combination of both for the time being till I can reflash some of my nodes.
Another thing you may be able to do (which I do too) is have a System started Rule that publishes a message that all your nodes subscribe to. When they receive the message they publish whatever the current reading is. Since you have control over the nodes that’s another option.
I was looking at that for some of my permanently powered ones. Unfortunately i have some that are deep sleep and wouldn’t get the message. But atleast with those i can do a rule if it’s UNDEF then check db and update the item.
