Rule issue: cannot be resolved to an item or type

Setup, Configuration and Use Scripts & Rules
10

Because the issue above. I’m trying to reduce the possibility to have items not yet populated before triggering the rule.

Even with persistence, I have the issue above

11

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:

12

better to use a createTimer(now.plusSeconds(25), [| ] ?

13

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.

14

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.

15

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.

2 Likes
16

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?!

17

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).

18
2 Likes
19

We developers sure do like our puns. :smiley:

20

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.

Maybe you’re right, but then I still don’t understand how the item can trigger the rule, yet not be available inside it.

21

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.

22

Thanks for the explanation. It’s everything but obvious for the user.

I wonder, if this could be improved by syncing the two processing threads before rules get executed?

23

There is an open issue (maybe two because there are a bunch of related issues here). All I know is there is no simple solution for it.

24

I feared this would be the case…

25

Any news in this case?

“cannot be resolved to an item or type”

26

This is a known an permanent bug with Rules DSL. The only solution is to implement something outside of OH itself to move the .rules files out of the rules folder, wait long enough for OH to finish starting up, and then move them back. There is an option in openhabian-config to configure this if that is what you are running. If not, it’s just a few commands added to the openhab2.service file. Look in the openHABian repo for their example.

27

Note there are fifty other ways to provoke this error message, apart from the files load timing issue.
Don’t just assume this is your issue without proper investigation.

28

Rich, I’ve a solution in place in my current openhabian installation, but I would like to migrate to docker … any idea how to manage this issue in a container?

thanks
Andrea

29

You will need to create a script that you mount into the container. See https://github.com/openhab-scripters/openhab-helper-libraries/pull/215 for an example way to do this sort of container initialization script. This should work to move the .rules files out. But I’m not sure how you would move them back after OH starts up.

1 Like