I’m a bit stuck here and I’m really trying to iron down my main issue right now. For a little while now, I’ve had an issue plaguing me that every time I restart OH, I end up having the rules executed against all the startup activity. This is annoying, and sometimes problematic as it’s causing undesired changes. I’ve read many of the issue around this and most were related to the old way OH used to operate and there was a setting in rules files to stop them from working until all items states have been loaded etc.
Well I’m running OH2 now, and it seems that the rules are being loaded before the states are restored or initialization of my ZWave devices is happening. I can’t narrow this down and it’s driving me nuts since right now we have a presence detection setup to open the garage. When the perfect storm exists, my garage is opening upon restart of OH. While it’s not that often I have to restart - it’s aggravating none the less. I also have a bunch of notifications that come streaming through as well bombarding our phones, some of which are simply duplicates.
Anybody able to offer advice where I can start checking for this?
Inserting logs here to show the startup. Obviously a few wonky things, but not disrupting functionality and shouldn’t be at the cause of the issue. But around 15:35:36 there is a section from openhab.log that calls out the actions from the rules being executed. Rename file to .rtf or .txt to view.
Wherever possible you should use received command and changed instead of received update in your rules. These will not be triggered when OH initialized your Items during the startup. This is a general best practice whether you are having problems or not. Particularly when dealing with something as important as opening a garage door.
You can look into setting a lock in a System started rule and have all your rules check this lock and avoid running if the lock is set. Then reset the lock to OFF with a Timer after enough time has passed.
Thanks for the input. I think I’ve just kind of come upon hitting the threshold where stuff worked ok as it was before, but now I have too much going on. I didn’t want to have to plug in some complicated mechanism like an extra check if a startup lock is enabled to all my rules. Not that I have a TON of rules, but I have enough. They get complex/complicated enough checking for errors as I build things out further - but this just adds another thing on top of it.
Has there been any talk or suggestion to possibly create some sort of mechanism to stop the rules/persistence loading in parallel vs loading in sequence? Or adding in an easy way to indicate that certain rules files should NOT load upon startup, and specifically delay those files? And no I don’t mean by setting up a script to just drop the rules file in after a set time.
Based on how many times I see the similar thread titles, I’d imagine this isn’t just some not so ordinary thing that plagues people - it’s just a matter of how many people decide to just deal with it.
Rationale I’m asking is that I’ve now narrowed down the issue and it seems it is indeed simply a matter of timing for when my states are restored vs my rules loaded and ready. I’m using only received command and changes, no received update. In fact I use received update to actually do some resets on things without triggering other rules. So those 1 or 2 might need protections - but overall it seems that this is really just not something I can overcome easily.
There is an issue open but the fix is not simple. Unless you are willing to try to tackle the problem I suspect it will take longer still before there is anything like a solution.
If you are truly using mainly received commands and the like then a simple is statement in your rules to check that everything you care about has a state before running could be helpful. Restoring the states of the items will not trigger these rules but that doesn’t invent them from executing before all items are ready.
It doesn’t seem right but typically only about 40% of code covers the happy path and the remaining 60% covers edge cases and errors. This domain is no different.
