No I’m just restarting openhab via ssh
sudo systemctl restart openhab2.service
I actually turned the router off physically , and reboot
Led will help a lot to find the problem later
I’m emulating that scenario, My openhab just rebooted and the router is off
yikes! that is causing the problems me thinks. Start simple and don’t keep restarting OpenHAB.
Create a switch item for testing, toggle it with a simple site map or the REST api and get your rule working. Then after you understand how things work, you can put the router item back into the rule
I did that just by classic ui, the rule is working fine, the led blinking as expected,
but what if this scenario happened
The openhab just booted up, the router is offline, that’s why I’m restarting openhab
Excellent, good job!
Openhab is actually made to run for a long time without ever needing to restart. I only restart OpenHAB when I’ve made some change that requires a restart such as updating stuff on the host machine. It is considered best practices to run OpenHAB on a host with a battery backup so it never restarts because of a power loss. As you have learned, when OpenHAB is restarted, it needs a few minutes to stabilize. Most the time, once you have your set up working correctly, you leave it alone and just let it run.
How to delay this rule from execution until openhab stabilized ? you said “There are some ways to do that”
ok, without going back and checking your first post, what platform are we talking about here? If it is a Pi with OpenHabian, I think the is an option in openhab-config or whatever to set it up for you. Otherwise search your exact question ‘delay rules loading on start up’
It is basically a hack. Because when OpenHAB starts, the order of how things are loaded can not be guaranteed so if a rules file (for instance) loads before the items it uses loads, chaos ensues.
So the idea is to write a different file name extension to all the files, run a timer and after a few minutes, rename all the files with the correct file extension and they will load
I’m using Pi with openhabian 2.4
OK great. I use linux on a desktop PC so can’t help much, search. I’ve found if you get your rules running right and have a battery backup and leave OpenHAB running, it really isn’t necessary.
If you consider your problem solved, change the title to include [SOLVED] and put a checkmark in the little box of the post that helped getting it working
Happy OpenHABing!
I just need to thank you all, you were so helpful and patient,
I understand that openhab designed to run for a long time, and I have to wait until system stabilized
this is my mistake here, I guess
exactly. It is a home automation system. It is made to be automated… basically run without intervention. If you have a battery back up, you can even set it up to intelligently shut it self down if power is lost for a long period and restart itself when power returns. Some users here run it at remote location where there is no one to keep an eye on the actual system.
Note that these errors will not stop the rule working later, they only affect the router-offline-at-openhab-bootup situation.
Above assembled from different logs.
I can propose the theory of events.
Note that it takes five minutes to fire the rule from the trigger event. This is a system under stress. Not surprising at bootup time, but it exposes timing cracks we might normally never fall down.
Okay, so the rule is running, next we do a createTimer - it’s birthday is embedded in message 3, the jobname. Again, it’s taken a whole second to get two lines along in the rule.
What’s not obvious is that createTimer is partly asynchronous, the creation part completes before the handle is written back to the variable.
Next, the timer goes off after 1 second - first thing it should do is log out it’s own handle. But the rule thread is still mired in treacle and hasn’t yet finished updating the handle variable (maybe partly because the timer code is using it). The timer code blows up, which deletes the handle.
Now the rule can finish updating the handle - but by now it’s invalid, the last message in that set.
Alright, so in summary it’s a nasty timing race with two root causes - extended processing times during bootup, and timer code referencing its own handle shortly after creation. Spiteful little bug.
One circumvention would be a much longer first run time for the timer - say 10+ secs. Simple enough, but does not address -
On reflection, I’d comment that relying on the rule detecting the change to OFF at bootup time is bad practice anyway. If the network binding sets Item states before rules come online (which is actually desireable!) your ‘changed’ rule will never trigger at boot time.
If network binding were a bit slower, we’d never run into this issue. This pot-luck approach is no good, run the same code on a different box for different results.
Let’s change that.
@Andrew_Rowe suggests the “delay rule” process.
I’m not sure that is the whole answer, because the rule currently fires from ‘changed’. You need something else to see if it is already offline at bootup.
Why not just ping the router after boot up?
yeah, I agree. I don’t use delay rules loading. What I’ve found is I have system startup rules for any unassiociated items (dummy items) that set them to simple states that don’t require any processing
example:
switch = OFF, number = 0
ftr: @Andrew_Rowe suggests the “delay rule” process
I didn’t really suggest that, the user asked how and I replied
in fact I tried to discourage using it
much better solution
Certainly an option. As the network binding is already doing that though, we just need some logic that says “when bootup chaos subsides, is the router offine?” as well as the usual “changed” trigger.
I wonder if a speed test, as it allows a delay for start up, would work?
From doc’s:
Use the following options for a network:speedtest :
20 .1000000 .5 .This is a bit clonky, but ought to do
var delayedStart = new Boolean("false")
var Timer BlinkingTimer = null
rule "system inits"
when
System started
then
createTimer(now.plusMinutes(2)) [ |
delayedStart = new Boolean("true")
if (Router.state == OFF) { // provoke the flash rule
Router.postUpdate(UNDEF)
Thread::sleep(500)
Router.postUpdate(OFF)
}
]
end
rule "Network Router OFF"
when
Item Router changed to OFF
then
if (delayedStart) {
logInfo("network", "Router is offline")
if(BlinkingTimer !== null) { // in case it started up already
BlinkingTimer.cancel()
BlinkingTimer = null
}
BlinkingTimer = createTimer(now.plusSeconds(1)) [ |
if (GPIO_OKLed.state==ON) {
GPIO_OKLed.sendCommand(OFF)
} else {
GPIO_OKLed.sendCommand(ON)
}
BlinkingTimer.reschedule(now.plusMillis(500))
]
}
end
I don’t know but timers always seemed tedious and prone to problems for me. I like to use the expire binding but must admit I’ve never used one in a startup rule
Would something like this even work?
items
Switch MyTimer3min { expire="3m,command=OFF" }
rules
rule "my start rule"
when
System started
then
MyTimer3min.sendCommand (ON)
end
rule "My start timer expired"
when
MyTimer3min changed to OFF
then
if (Router.state == OFF) {
// do stuff
}
end
note to copy and pasters - requires expire binding installed