I have a rule which accesses an item of type Switch defined in a .rules file. After upgrading OpenHab (this happened on all upgrades that I did this year), I see an error in the log:
[ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'Wecker PERSON1': The name 'Rules_Enabled' cannot be resolved to an item or type; line 67, column 6, length 13
This repeats on every rule iteration. The only way to resolve (I found the tip on the forum somewhere) is to load the .items file and by modifying it and saving (for example adding an empty line or so) it, thus having a new time stamp, OpenHab2 will consider a refresh of the .items file and then everything works again. Maybe someone has an idea what to change to my configuration to get around this work-around or does this qualify for a bug report?
In the .items file there is just a simple
Switch Rules_Enabled
And here the relevant .rules file snippet:
// System start can take some time and items may not have returned to persisted states yet - so we will delay 5 minutes
rule "delayForSystemStart"
when
System started
then
Rules_Enabled.postUpdate( OFF )
createTimer( now.plusSeconds( 300 )) [| Rules_Enabled.sendCommand( ON )]
end
//check weekly alarms every minute
rule "Wecker PERSON1"
when
Time cron "0 * * * * ?" //every minute
then
var int sollMinute
var int sollStunde
if (Rules_Enabled.state == ON){ //this is the offending line from the error log
}
end
No it doesn’t because the reason is unclear, and given you’re the only one to have this problem it’s likely not a bug but a misconfiguration of yours.
You don’t describe your problem well. Does it happen for all items ? All those in one specific .items file ? When does it happen - only once after you update the openhab package ?
Does it still happen after 1/2 hour of running when openHAB startup settled ?
Do you restore some config on upgrade ? My guess is you do and you restore a broken .items file.
Copy the .items file when the problem happens, edit and copy back. If it has an error that should then show up in the log.
Given you don’t run openHABian it can also be anything with your OS setup.
I’d suggest you install openHABian and import your config to see if it still happens.
I found my instance “losing” items, too. But, as Markus described, without detailed knowledge about when and under which circumstances this happens, I knew nobody could help and so didn’t post here.
Nevertheless, I go around this by running a cron-triggered script which just updates the timestamps of all .items files.
Yeah, it’s ugly. But it works until I get some time to investigate further.
This is very common, lots of threads about this which you can’t find due to suddenly flaky forum search.
There is some kind of cache which affects the system load sequence, if it is not yet populated bad stuff happens like random Items and rule functions getting omitted.
The cache is cleared at update, and rightly so.
So failures are highly likely at first boot after upgrade.
At the next reboot, all is usually well - the cache has repopulated.
Sometimes it takes two reboots, don’t know if that relates to platform or configuration differences.
The good news is this is not a significant issue at all. My system has done this, I believe, for every update since the early 2.5 releases (never saw it on any earlier 2.x versions); it is simply expected behavior as far as I’m concerned at this point. But one additional reboot (I typically let the first boot run for 5 - 10 minutes first) fixes it completely every time. As @rossko57 says, others have reported needing a second reboot, but I have never needed more than one. It is not a symptom of an insidious configuration issue and there don’t appear to be any deleterious downstream effects.
…looks like I may have to investigate further on the next update of OpenHab At the moment the system is working again, thus I cannot test much, I guess.
At the moment the system is working again, thus I cannot test much, I guess.