After power on at Raspi3 openHABian 2.3.0 Build #1218
rule "System started"
when
System started
then
logInfo("_","System started")
...
end
openhab.log
...
2018-02-22 07:43:53.141 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
2018-02-22 07:43:53.541 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2018-02-22 07:43:54.033 [INFO ] [b.core.service.AbstractActiveService] - Expire Refresh Service has been started
2018-02-22 07:44:11.039 [INFO ] [org.eclipse.smarthome.model.script._] - System started
2018-02-22 07:44:11.039 [INFO ] [org.eclipse.smarthome.model.script._] - System started
2018-02-22 07:44:11.106 [INFO ] [lipse.smarthome.io.net.exec.ExecUtil] - executed commandLine ...
After restart and at windows-installations it runs correctly 1 time.
I have the same issue since ever. But I think I know the cause of it.
This rule does not get executed every “restart”, but every time this exact rules-files is read or stored in memory. (I am not sure).
So, because the RasPi has limited memory, the file might get “kicked out” of memory to make space for more important rules and the read again once there is free memory.
So the rule is executed again.
On my system this can be about five times after I reboot my device.
That’s right. It also gets reloaded thus executed every time you (or Karaf or some script) change the rules file.
This might be correct, though. Depending on your Linux and Karaf setup, there can be some file copying going on at startup.
If you happen to find out the exact conditions, the developers will be happy if you file a bug on GitHub.
Nah, nonsense.
Either way, code your rules to not fail on double execution.
This bug is one of many problems openhab is having for years. There is a lot of uncertainty about the rule execution, finding the bugs seems exceptionally hard and the entire system is rather unstable and undeterministic in its behaviour. I have about 200k of rule files active, and I spend a lot of time traying to figure out faile safe mechanisms and watchdogs to keep the system alive, healthy and fully functional at all times.
This is the wrong way. “code your rules to not fail on double execution” is the wrong way to solve this. That is just a temporary workaround, and may not be more. Unfortunately, this issue persists for years now, and as long as everyone keeps working around this and similar issues, they won’t get fixed.
I now experienced the worst kind of this double execution: (after a reboot triggered by a watchdog) even the persistence restoration executed twice, but the second time with incorrect (probably older) values. This has turned my heatpump work mode from automatic to off, the rollershutter control though all shutters were up at 2:51 already (yes, I have plenty of failsafes in place already to no actually rise the shutters at that time), and my presence control forgot I was sleeping.
At times like that I really wish that openhab would be made more stable instead of just adding features. All I want is to have a home automation system I can rely on.
Well I didn’t mean it to be the right solution but a workaround (the only “solution” a user can provide on his own). I think building workarounds won’t affect whether the bug will be fixed or not. Developers don’t know what users are coding at home unless you complain loudly here and on Github and in a productive manner. See ESH #6410, I guess this one here is a consequence of that.
But I think I know the cause of it.