I’m not sure if this goes under binding or persistence but it seems more closely related to bindings. And, this is a development question for OpenHAB2 so maybe it doesn’t even go in Community.
I’ve read how persistence works (https://github.com/openhab/openhab/wiki/Persistence). If I understand it correctly every time and item is changed that change is recorded in the persistence service and is restored on startup. Is it possible for the binding handler to get access to the persistence data? In the binding I am working on for the cm11a X10 controller the controller can only change the dim level an incremental amount. Therefore to correctly set the dim level on startup I need to get the persisted dim level and then turn the lamp off and then send the correct number of dim increments to get it set to the appropriate level.
On a related subject, during startup the ThingHandler.handleCommand method is called with a command of RefreshType. This happens before the bridge handler has been called. What is the purpose of that call? Could that somehow be used to help restore the values.
Sort of. There is a config file that dictates how often and under what circumstances Item’s states get saved to the DB and whether or not that Item gets restored to its last state on startup.
I can’t answer the specific answer, but this doesn’t sound like something the Binding should do. For one thing, as I explained above, there is no guarantee that these Items are persisted at all let alone restored to their previous state on start up. I’m not certain, but I’m not sure there is any event generated when an Item is restored on startup so I’m not sure there would be a way for your binding to know whether the Item was restored or not.
Finally, when an Item is restored on startup in OH, it is strictly internal to openHAB (i.e. like a postUpdate, the state change doesn’t go to the binding. A restored Item will not go out to the binding and ask it to set the state of the device to the same value restored. You have to write rules if you want that behavior. But that is not and should not be the default behavior.
If there should be a default behavior it would be to set the state of the Items to what ever state the device happens to be in after OH starts, not to set the state of the device to what OH thought it was.
I’m struggling to understand why do we (binding developers and also users) need “restoreonstartup” feature if we cannot “listen” to this event, so we cannot restore device state according to OpenHAB state.
Here is a simple example:
If device state is changed during OpenHAB down time, then there is not any way of restoring device state according to the previous OpenHAB state (loaded from its persistence).
What’s the point of having restoreonstartup at all, if only internals (links state) of OpenHAB is restored, but devices itself is not? This basically leads to inconsistent state between devices and OpenHAB.
Not true. Like I said in my response, this is something that can be done in Rules.
rule "Command device to restored state"
when
System started
then
MyDevice.sendCommand(MyDevice.state)
end
There are many cases where one does not want to restore a device to the state it was in when OH went down. Cases where doing so is not just undesired but can be down right dangerous. For example, if my garage door opener happened to be up when OH went down I certainly don’t want OH to open my garage door when it comes back up. Far better to have a temporarily inconsistent state and then through Rules or based on setting of the bindings to poll for the current state of the device and update the internal OH state to match the real world.
Applying the policy of “do the least amount of harm” it is far better to have a temporarily inconsistent state internal to OH that will eventually (often within seconds) get updated to match the real world than activating devices to make them match OH’s internal state on a reboot.
And where it makes sense you can use the rule above to force the device into the restored state.
As for why would we use the feature? Nothing forces you to. But 99% of the time when OH restarts nothing changes so when OH comes back up its internal state will match the real world. Using restoreOnStartup lets you avoid a whole lot of error checking in your rules because you can ignore the case where an Item is Undefined because the restoreOnStartup guarantees they will have a state. Sometimes one will have Items that represent a state (e.g. alarm clock time, flags, etc.) which should be restored before any rules run. And, like I said, any inconsistent state will remain inconsistent for only a short period of time except in cases where a user has devices that never report their status. Finally, if you did want to force your devices to match their restored state the only way you can do this is through the use of restoreOnStartup.
Thanks.