There are all sorts of very complex work arounds involving Timers and Rules that copy the .rules files after a certain number of seconds/minutes after the system boots and the like. In my opinion, it is easier to ignore the errors during boot.
There has been an issue open on this since OH 2.0. It’s a well known problem that is not trivial to fix apparently.
It should rarely be an actual problem in practice, mainly if it occurs during a System started Rule therefore preventing something that should occur at startup from occurring. In that case, you can put that part into a Timer and schedule it to take place when you know it’s safe.
rule "Set Danfoss_Hallway_Radiator_BatteryAlarm Flag"
when
Item Danfoss_Hallway_Radiator_BatteryLevel changed or
Item Astro_Sun_Season_Name received update
then
Thread::sleep(25000)
if ((Danfoss_Hallway_Radiator_BatteryLevel.state == NULL) || (Astro_Sun_Season_Name.state == NULL)) {
return;
}
if(Danfoss_Hallway_Radiator_BatteryLevel.state <= 10 && Astro_Sun_Season_Name.state.toString.contains("AUTUMN") || Danfoss_Hallway_Radiator_BatteryLevel.state <= 10 && Astro_Sun_Season_Name.state.toString.contains("WINTER") || Danfoss_Hallway_Radiator_BatteryLevel.state <= 10 && Astro_Sun_Season_Name.state.toString.contains("SPRING")) Danfoss_Hallway_Radiator_BatteryAlarm.sendCommand(ON)
else Danfoss_Hallway_Radiator_BatteryAlarm.sendCommand(OFF)
end
here the error:
2018-11-05 11:49:17.030 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Set Danfoss_Hallway_Radiator_BatteryAlarm Flag': The name 'Thread' cannot be resolved to an item or type; line 8, column 5, length 6
AHAHAHA … not sure how to fix it
I will ignore if no other option is available
thanks
I have some of these errors when restarting openHAB. I ignore them
The persistence will do it’s job eventually or the bindings…
The after a little while openHAB settles down.
Doing a Thread::sleep for 25 seconds is a very bad idea in the first place:
Yes. That is what I meant above when I said put that part into a Timer and schedule it to take place when you know it’s safe.
But as you are seeing, sometimes you can’t guarantee that core Objects exist when the Rules start running like Thread and Timer. So there will be times when even that won’t work.
In fact, it’s very unlikely that openHAB doesn’t recognize the item in a rule file.
Are you sure that the Item is populated? It’s possible that the item file has errors and the Item isn’t created at all.
In question of your rule, it would be easier to use another if() statement:
rule "Set Danfoss_Hallway_Radiator_BatteryAlarm Flag"
when
Item Danfoss_Hallway_Radiator_BatteryLevel changed or
Item Astro_Sun_Season_Name changed
then
if (!(Danfoss_Hallway_Radiator_BatteryLevel.state instanceof Number) || (Astro_Sun_Season_Name.state == NULL)) {
return;
}
if((Danfoss_Hallway_Radiator_BatteryLevel.state as Number)<= 10 && !(Astro_Sun_Season_Name.state.toString.contains("SUMMER") )
Danfoss_Hallway_Radiator_BatteryAlarm.sendCommand(ON)
else
Danfoss_Hallway_Radiator_BatteryAlarm.sendCommand(OFF)
end
There is no need to trigger on every update. It’s better to check if the battery level is of type Number, as you want to check it it’s less or equal.
I’ve had it report just about everything possible as unknown symbols during OH initial startup. Global variables, constants like NULL, ON, OFF, etc, base Java classes like Thread::sleep as reported above, etc. Every time we restart OH we are rolling the dice. Sometimes it completes with no errors, sometimes it throws the strangest errors that make absolutely no sense. I’ll be very happy when this gets fixed.
I’ve just had the same problem. I had a rule that was triggered by item Something in the when clause, and in its then clause, I wanted to use Something.state, but always got
The name 'Something' cannot be resolved to an item or type
when using the state – even though that very item had triggered the rule!?!
Trying to track down the problem, I inserted a log display first thing after the then
logInfo("rule#1", "Item changed to {}", Something)
The funny thing was: the item was logged, and the error disappeared! It seems like logging the item made it available to the rules engine?!
I think it is more likely that the logging gave the Rule engine enough time to finish loading the Items and make them available to the rules engine. One of the frustrating things with this problem is it all boils down to timing which can often turn the problem into a Heisenbug (i.e. a bug that goes away as soon as you try to change things to find it).
Because Items are processed and managed by lots of different parts of OH.
In this case events on Items are processed by the Event Bus. When an Item receives and update or changes or receives a command then this event gets published to the event bus. The Rule gets triggered based on these published events. But Rules need to parse and load the Items separately from the Event Bus because it needs to use Items in a different way. Consequently, the Event Bus has loaded all the Items but the Rules Engine has not. The event occurs and the Rules engine has loaded enough to know it needs to kick off this Rule but not enough yet to know that the Item exists.
