I’m a relative beginner so forgive me if I’ve misunderstood something.
After power is cut, I’d like to be able to restore my devices to the same state they were in when the power went off. I see from previous forum topics that I can use persistence to restore the item states but then need to propagate these to the devices by sending commands via an appropriate rule. I’ve also found an example of such a rule on the forum. All good.
What worries me is the order that things will happen. For instance, take a Hue lamp which was off (0, Hue dimmer) when the power was cut. When power is restored the lamp goes on (100%, seems to be what they do). My persistence configuration will at some point cause the corresponding item state to be set to 0, as it was before. At some later stage (I see that a delay is recommended) my startup rule will send a command to the lamp based on the item state.
But meanwhile the Hue binding is polling the bridge and causing the item state to be updated appropriately. If this happens after the item state has been restored to its pre power loss value but before my startup rule runs, then the item state will be set to on (100%), since that’s the state of the lamp at that time. The pre power loss value is lost and my startup rule will propagate the 100% item state value to the lamp and it will stay on.
Could this happen, or have I misunderstood something?
That’s no longer true if you don’t have very old Hue stuff. You can set them to return to the previous state (from within the App).
The purpose of Restore On Startup is to have openHAB restore the internal representation of the state of devices after it is started to the state they had when OH was somehow shutdown or interrupted. There are no rules involved here. To make it very clear: this persistence feature is focused on OH to not lose the state of devices, it is not about knowing to what state devices return af they have been cut off from power.
The restore on startup does not change the state of any device, just the state inside OH.
In case you own Hue lights that don’t support the restore state on power on feature, the only way that comes to mind is to make your own persistence items to constantly store the state. But still, on startup it takes a while for all the rules to start running and in the meantime the lights will burn at 100%. But at least you don’t loose the pre-power loss state…
Thanks for the quick reply. Yes, I have very old Hue stuff I’m afraid. I can also see a similar potential problem with my mqtt stuff.
I am aware that restore on startup only sets the state inside OH, not the device state. That’s why I referred to the need for a rule to run on startup that sets the device state to the internal OH state (yes, I found an example of such a rule on the forum).
I can’t see any way of using either the available persistence techniques or some home brew version that wouldn’t suffer from the same chicken and egg problem I referred to in my post. If I make a “persistence” item then it has to be updated when the device changes state. If it does that then it will also be updated when the power is restored, so I’ve then lost the state before the power went off.
Sorry, I misinterpreted your request. Let’s restart…
So, you have devices that return to a predefined state (100% brightness in case of Hue lights) after a power interruption. The principle problem here is that OH cannot distinguish between being shutdown/interrupted because of a total power outage or because only OH is somehow interrupted/restarted. Also, OH cannot distinguish between starting after power interruption or because of a manually triggered restart. The only thing you can do about that particular issue - that I can think off - is create a kind of shutdown rule that sets a ‘clean shutdown’ flag and resets that flag at OH startup. Kind of like filesystem mechanisms work to detect a possible inconsistent state due to power failure while writing to disk.
Assuming that restarting of OH happens (mostly) after total power failure, you can define a few Items (or constants in a rule) that define the restore after power loss state. So in case of the Hue lights:
Number hue_light1 "My old Hue" {channel="hue:0220:xxxxxx:bulb_1:brightness"}
Your rule file:
val Number huePowerOnState = 100
rule "restore Hue ligts after power failure"
when
System started
then
hue_light1.sendCommand(huePowerOnState)
...
end
That way the Hue light and its internal state both are at 100%. Alternatively, of course, you can define another default value for brightness at startup. If you make them Items, you can even have a separate screen where you can set different power on values.
But in any case, the rule only kicks in after a while, so the Hue light will be at its “Power On” state until OH is up and running and executing its rules in any case.
There is an alternative approach. Formulating the requirement as “I want to restore the state from just before power failure” suggests the method.
Ignore restore on startup action and incoming live updates. Instead read the last state from persistence from before 5 minutes ago, and use that to command. You’d need to use “proper” persistence for this, as mapdb has probably overwritten its only store by now.
That sounds like what I want. I was just looking at the OH documentation on persistence and thinking along those lines. What do you mean by “proper” persistence?
That’s a nice way to do it, indeed. I should have thought of that… @pbax; this leaves only the issue that the lights will be at 100% for up to a minute or more after power restore until the computer and openHAB are up and running again.
I can live with the lights being on for a short time. Be a bit annoying if it’s a bedroom light and it happens when I’m asleep but I don’t think there’s any way round that. Thanks for your help. I’ll try and post a working solution when I’ve worked out what persistence service to use and the appropriate rule.
The other thing that comes to mind for me is a battery backup. I purchased one for my system and I’m working toward setting up OpenHAB so in the event of an extended power outage the system can shut it self down. It should be easy to also prepare for the shutdown by storing the states of things.
I also messed with system start up rules a bunch and in many situations I’ve found setting items to a predetermined state is actually better/more suitable then trying to restore them to some previous state.
