I’m coming from OpenHAB 1.x and having lots of odd behaviors. When OpenHAB2 starts, logs show that it removes all items, then adds them again. It then goes through and updates each item with a value (I assume this means loading the persistence data) This makes my HA system go nuts. I get notifications for each item and my rules get activated causing all kinds of things to happen. This never happened with 1.x.
I’m using rrd4j and I did copy the persistence files for my upgrade to keep my history data.
I see the same behavior in mine. My rules also trigger but I believe I had issues with that in 1.x to a certain extent as my rules have checking built in to ignore this false positive… at least the rules that would do something undesirable like open a garage door or something do. Some rules send commands to lights or thermostats on boot up but they are just re sending what the light or thermostat should already know or in the event the system has been off for a while, bring them to the state they should be in.
I know this doesn’t directly help but perhaps a quick update to some of the more invasive rules would mitigate this being a problem for you?
I do see a mention of this issue under Startup Behavior on the page below, though I don’t understand in my initial read through how a rule refresh helps with this issue.
Do you have an example of checking built in? I know I can take a look at the rules that react to updates rather than commands and probably clean some things up. But yes, the garage door opening is exactly what happens when I start openhab.
Oh, yeah, I think what you are referring to there was a different issue. In 1.x there was actually the opposite problem. Items and rules were processed at the same time during start therefore some rules wouldn’t run that you would want to and some rules that you do want to run might not run right because items aren’t initialized properly yet. The workaround were methods to basically delay rule processing and or make them fire a second time iirc.
As for checking, it’s not a specific magic bullet check. I just checked and my garage door rule has:
when Item NUM_GarageDoor received command
This is a number that gets set by other rules or by pressing a mapped button on the sitemap. These other rules may trigger but they fail other checks like the alarm had to have been previously armed away within a few seconds and not any more (it would have been null or undefined at bootup even if it isn’t armed)
The NUM_* gets updated but doesn’t receive a command so those rules don’t fire. It’s things like that.
Unfortunately rule writing can be a little tricky to come up with sneaky ways of doing things. People on here are GREAT about helping spiff up rules though.
Sometimes something as simple as changing a trigger like changed to ON into changed from OFF to ON will avoid triggering from restore or binding changing from null on startup.
I’ve gone through my rules and it appears that the startup update changed from NULL to 1 has triggered a rule I set to changed from 0 to 1. Does that makes sense, or must I be missing something?
There has to be some way to disable this behavior. Why does all the persistence loading need to be pushed through the runtime? I’ve built a lot of rules that have worked fine in OH1, but now I’m going to have to rewrite most of my rules and split them into specific changes? Unless I’m missing something in the issue above, I’m going to have to get creative.
Can I delay the loading of the rules? That would seem like the easiest way to deal with this.
There are differences between OH1 and OH2, some will bring joy, and some tears.
If you can write rules to cope with startup, you will probably also get rewards in them handling editing partial reloads, unexpected subsystem switch off/on etc. “Code defensively”.
I did find another rule that was triggering this action, so not a bug. I was able to eliminate these issues by having rules react to commands rather than updates. At least that was a lot simpler than rewriting rules for specific value changes.
