Have JDBC persistence with SQlite against items that are hue lights. Turn on lights, kill openHab server, verify in database the last state of the switch is ON (and brightness and color as well). Turn off lights with openHab not running, restart openHab and the light state does not restore.
The log messages indicate that when the hue binding starts up, it’s reading the current state of the lights and jdbc persistence is dutifully writing that info, ignoring the previous state. I think I could “fix” this using a rule that would read the previousstate from the jdbc persistence, but this sure seems like a hue binding issue to me. Anyone else?
To me is seems like the preferred behavior to me. When openHAB comes back up it should reflect the current state of everything, it should not force everything back to whatever it was when it shut down. For example, I open the garage, OH crashes, I close the garage. When OH comes back up I want OH to see that the garage is now closed. I absolutely do not want OH to reopen the garage.
If I did want that to happen I would expect to have to write my own system started rules to switch everything I care about to the last state, like you suggest.
The documentation states that this behavior is controlled with persistence and specifically the use of the restoreOnStartup strategy (neither of which are enabled by default). As you point out, there are many devices that you would not want restoreOnStartup applied to, which is why it’s explicitly controlled through the interaction of the item and persistence configuration. I should not have to write rules to have the last state restored: I should be able to use a persistence definition as applied to the devices to do this.
Lights are a relatively trivial example, however, I’d like mine to recover since the behavior of Hue lights on power interruption is to turn ON, I’d like them to go back OFF if that was their previous state). There are other devices for which auto-restore makes sense (security devices), and some that don’t (doors!)
Correct. When OH starts up it restores the state of the Items to whatever they were when OH went down. BUT, it doesn’t send out commands when it restores the states on the Items. This is a data only update to the Item within openHAB and will not trigger any rules or cause any of the Items behavior to trigger. It is just a way to initialize the Item’s state to a meaningful value as opposed to UnDef. Eventually the binding will, if supported, get the current state of the devices.
In short, restoreOnStartup doesn’t work like you think it does. It is strictly a data update thing and not a way to cause your devices to do something on startup. You have to write System started rules for that.
You don’t, but you do have to write rules if you want to have the last states restored as commands that get sent out to your devices. As I said, restoreOnStartup is for initialization of your Items.
For those Items where it makes sense to trigger the devices back to their previous states you have to write a rule.
If you put your items into a Group the rule is actually a trivial one liner.
Item:
Group gRestoreState
Add all your Hue and other Items that you want to be set back to their previous state on start.
Rule:
rule "Restore Device's Previous State"
when
System started
then
gRestoreStartup.members.forEach[item | item.sendCommand(item.previousState) ]
end
