At the moment, most of my rules have a first rule ‘on startup’ to reset any items to whatever default setting they should be at.
However, this causes some annoyance when I’m playing / updating these rules as every time I save the rule OH checks the rules and run them, resetting all the variables as per the rule.
So, my question is, am I able to just create a startup.rules file and put all my ‘on startup’ rules in there so they won’t run when I’m tinkering?
Do the ‘on startup’ rules have to be in with the specific rules they kind of refer to or does it not really matter?
I don’t understand your point. Any rule to trigger on startup, i.e. ‘when System started’, will have code to execute in its body. It won’t refer to other rules. And you can put it into any rules file or its own one.
Just be aware that when you edit a file to contain any such rule, it’ll be executed when it’s compiled/reloaded.
“Global” variables are only global to the rules that are loaded from the same xxx.rules file.
So assuming you mean in with the specific variables they refer to, then yes.
You might use Items instead of variables (perhaps just for some key values), because Items are truly global to all rules.
You can of course construct more complicated schemes - a system start rule could set an Item, other rules can watch for that Item changing to do their own initializing tasks.
That’s my problem, I don’t always want the to execute when it’s compiled and why I just wanted to check the ‘on system startup’ didn’t need to be in the same rules file as the one that the item variables it refers to are in.
I suppose the question should have been ‘does the ‘on startup’ command have any special requirements and need to be in a rules file involving the items used within it.
Thanks, and yes…that is ultimately my plan, which is why I want to shove all the ‘on startup’ rules in their own file so I can keep them all in an easy to see / use file.
Thanks both for the help.
Perhaps using mapdb persistence would eliminate the need for such a rule.
I’ve, so far, steered clear of persistence but maybe I need to look into it more.
Can you overview / explain how that would help and negate the need for the ‘on startup’ command rule?
Persistence and restore-on-startup is no direct help for variables. It is possible to have a scheme restoring from Items to variables (but probably pointless, use the Items directly).
I think you need to be clear about what you are trying to initialize here.
Sure, but those rules cannot do anything for variables belonging to other files.
You need “local” rules in the same file to do that.
But those rules could be triggered by an Item which is turn triggered by your special-startup-rules-file. (And so those local rules will not be triggered by a reload of their local rules file)
My understanding is that mapdb stores the item state so it can be restored automatically at system startup.
Cheers. Some evening reading!
It does seem to sum up / solve one of my issues with on start up…
Rules are already started in parallel. Especially in rules that are started via
System started trigger, it may happen that the restore is not completed resulting in undefined items.