I’ve got a number of rules that run, such as the TimeofDay, location and various light and plug routines.
Yesterday my power tripped and although my synology turns itself back on and the OH docker fires up I found myself having to manually run these rules to catch up with current state.
How do people deal with this, I know I can run persistence but it’s not always what I want, (I don’t think), as location changes, lights have been switched since then etc.
I also don’t want all the rules firing at once as a couple are reliant on anothers state.
I thought about having ‘one rule to rule them all’ and have it run on start up and then systematically trigger each rule in the specific required order and insert a few timers to give each rule time to run but is this the best way to do it or is there a system command / better way???
I use persistence with restoreOnStartup. If the devices changed state since OH went offline, the binding will update the Item to the new state shortly. If not, my Items will reflect the current state of the Item.
In the unusual case where I don’t want to have the Item restored, I’ll exclude it in the persist config. But the key here is your rules have to be smart enough to test that the Item isn’t NULL.
Also rare, but in the case where a rule needs to run on startup, I give it a system runlevel trigger so it runs during startup.
Then those rules should run based on an event generated from the rule that needs to run first. Or they need to be made robust where they can handle the case where the subsequent rules haven’t run yet.
The best way would be to configure your system so that these timing dependencies do not matter. Use restoreOnStartup and add checks in your rules so they can handle the cases where Items don’t have usable states yet.
I’m struggling with understanding your question.
As Rich replied, persistence is a good start
And it’s generally good practice to (also) have a rule that you can trigger anytime that initializes all items (or all that are NULL) you need to have in some defined state for your rules to work.
Just like initializing variables before use is part of basic programming sanity practice.
This you can call on system startup, or to reset complex state machines.
Thanks both, a good combination of persistence and one rule to deal with nulls on start up / manually when needed seems the best way to go. Thanks for the advice
I add startup triggers to each of the relevant rule(s) that need it instead of having one mother of all startup rule.
It makes maintenance much easier.
For example, I have a rule that warns me via TTS that doors / windows are open while the airconditioner is running. It triggers on door/window state changes. However, if I restarted openhab while a door is open, it won’t ever trigger my rule. This is when I add an onstart/onload trigger to the same rule so that openhab will still issue a door warning after a restart.
There are many many cases where adding an onstart/onload is very handy for me.
