Rules after power outage

Setup, Configuration and Use Scripts & Rules
, ,
21

It’s not about persistence making it better. It’s about the default OH3 persist configuration action being to store and importantly, to restore-on-startup, your Items. By default.
So in this case it works against you by substituting some old state for the real device state, at startup.

If you’re happy your Thing method will work reliably, go with it. Me, I wouldn’t trust it on its own.
It costs you very little to have a start up rule examine the Item state, and if it finds it ON command it OFF (or set up a delay, or whatever it is you prefer). This will cover the case where your device comes online before your rules are active.

1 Like
22

I see the reason in your suggestion and I would like to follow it.
Do you know if there’s a tutorial that explains how to setup such a persist configuration?

23

Ok cool all good then so you basically are just turning the power on and off to the heater.

There are other types of failure than just power outage. What you could do is just set a Maximum run time using expire on the switch. You can also create a rule that runs periodically to check that the switch is in the state that it should be.

1 Like
24

You’d start with the Persistence docs.
but
It’s a bit of a sledgehammer to squash a small nuisance. It isn’t possible to configure persistence to omit an Item, so that means a Big Job manually configuring everything else. I wouldn’t embark on that without a better reason.

Let’s take a step back and review what we’re trying to do.

External Item may be OFF or ON, with an off-timer running. Then there’s an openHAB outage for whatever reason.

openHAB restarts - we hope.
You really should have some external failsafe for this, not all OH hosts recover from unexpected power failure very well.
You might consider replacing your switch with one that starts “idle” or allows you to configure start-up state. The old one can be re-used somewhere less critical.

But let’s work with what we have today. openHAB restarts, we don’t know how long the outage was or why. We don’t (yet) know if the external switch has recovered or not, nor if it is really ON or OFF. If there was any timer, it is lost.
We can’t do anything about it until OH gets to “rules ready” stage. At that point -

The Item may be ON or OFF, but that might be a restored-on-startup state.
We cannot trust that state reflects the real device, because we don’t know what happened during the outage.
But perhaps external device is already online, and it is the truth.

Let’s just have a startup rule commanding OFF. This might not be needed, but it’s free. This might not work if the external device isn’t online yet, but it’s still free.
The Item state will probably then update to OFF, but it still might be a lie.

If the device later comes online, the Item state will get updated to ON or OFF to reflect reality.
There’s a bunch of things you could do at this point. The choice is probably going to be about how it interacts with your ‘ordinary’ rules.

If your boiler is normally only ever going in 1-hour times, do as @denominator suggests and put an ‘expire command OFF’ on the Item.
If the device comes online already unexpectedly ON, the expire timer will start. (so long as the Item is ‘falsely’ previously OFF, which the startup rule should have ensured.)
This will likely simplify your rules too.

Or, use your Thing based rule to detect device coming online, and command OFF.

Or, if you prefer to keep a rules-based timer, you can detect an unexpected OFF-to-ON transition while the timer is not running, and do something about it. It’s a fancier version of the expire which allows you to take more flexible actions - a different delay or whatever.

1 Like
25

@rossko57 @denominator
Thank you very much for both your explanations :pray: :pray:
I actually already have an expire command OFF for the water boiler using a virtual item (due to zwave updates limitations).
So during regular usage the water boiler automatically shuts down after 1 hour, in sync with to the virtual item’s expire command OFF.
I guess I just need to create a fail-safe rule to prevent the water boiler from working non-stop after an outage.
I will try @rossko57 suggestion to create a startup rule that changes the item’s state to OFF. This way, once my zwave Things go ONLINE, the Item will automatically sync it’s real state to ON, thus enabling the expire rule of the virtual item.
I hope I understood everything you explained.

26

I tried to create a new rule that was set to trigger when “100 - Startup complete”, and then send an OFF command to the water boiler Item. It didn’t work, though.
Did I create the rule wrong?

27

Um, what might this rule look like? What did ‘didn’t work’ look like?

2 Likes
28

This is the rule I created.

triggers:
  - id: "1"
    configuration:
      startlevel: 100
    type: core.SystemStartlevelTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    label: Water Boiler Item OFF
    configuration:
      itemName: Boiler_Switch
      command: OFF
    type: core.ItemCommandAction

I assumed this rule will switch the Water Boiler Item OFF once OpenHAB finished starting up (and before the zwave Thing came ONLINE), so that once the zwave Thing does come ONLINE, it will change the Item state back to ON. Once the Water Boiler Item changes to ON, it will also change the Virtual Item to ON, and the Virtual Iten will run the expire timer, that will later be used to switch OFF the Water Boiler Item.

29

Rule looks reasonable. Look in your events.log to see what it did (commands are recorded there).

I’ll guess the command was issued. But as you’re expecting the state to change as a result, AND your device is usually still offline at this time, you’re relying on the autoupdate feature. Which can correctly assert, “the Thing is offline so this command can’t work, so no state change predicted.”

Based on that guess -
If the Item was left NULL at bootup, this wouldn’t matter. We’d get an easily detectable transition later from NULL to ON or OFF when the device comes online.
Unfortunately by default restore-on-startup will have already set ON or OFF.
That might or might not be true. Consequences -
If we start OFF and device joins later OFF, all is well.
If we start ON and device joins later OFF, all is well.
If we start ON and device joins later ON, there is no change to begin expire, and this is the critical condition we want to detect.

Reflecting on this, I think maybe the best non-obvious thing to do is to update the state to UNDEF in the startup rule, instead of commanding.
Consequences -
This will act as “ignoring” any restore-on-startup
If the device is already online at this point, we’ve thrown away good data BUT we will still get a routine update to the real ON/OFF state from the device soon.
If the device is still offline, if and when it comes online we will get an update to the real ON/OFF state in due course.
In either case, a rule/expire can easily detect the change from “anything” to ON and do the desired off-action.

If the device never comes online, the Item stays at UNDEF which gives a useful problem indication.

This is all very fiddly because of the default restore-on-startup, but overcoming that directly is a big pain if you have not already chosen manual persist configuration.

1 Like