Error message rules "The name 'OFF' cannot be resolved"

Setup, Configuration and Use Scripts & Rules
1

I found an errormessage when openhab2 starts that i don’t understand:

2018-12-15 11:07:39.027 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Haustür': The name 'OFF' cannot be resolved to an item or type; line 104, column 37, length 3
2018-12-15 11:07:39.034 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Flur_Stehlampe': The name 'OFF' cannot be resolved to an item or type; line 90, column 42, length 3

This are the rules:

rule "Flur_Stehlampe"

when 
    Item Zwave_Flur_Stehlampe_caldav changed or Item DarkOutsite changed
then
    if (Zwave_Flur_Stehlampe_caldav.state == ON && DarkOutsite.state == ON ) {
        logInfo("caldav", "Stehlampe an")
        sendCommand(Zwave_Flur_Stehlampe,ON) 
        }
    else {
        logInfo("caldav", "Stehlampe aus")
        sendCommand(Zwave_Flur_Stehlampe,OFF)     # line 90
        }
end

rule "Haustür"

when
    Item Garten_Haustuer_caldav changed or Item DarkOutsite changed
then
    if (Garten_Haustuer_caldav.state == ON && DarkOutsite.state == ON) {
        sendCommand(Garten_Haustuer,ON)
        logInfo("caldav", "Haustür on")
        }
    else {
        sendCommand(Garten_Haustuer,OFF)      # line 104
        logInfo("caldav", "Haustür off")
        }    
end

These are the items:

Switch Zwave_Flur_Stehlampe  "Flur Stehlampe" <light> {channel="zwave:device:f409f165:node16:switch_binary"}
Switch Garten_Haustuer      "Haustür"       { gpio="pin:24 initialValue:low" }

Any idea about the errormessage

There a other rules of this kind in my config without an remark in the log.

By the way, the rule works fine.

Greeting Detlev.

2

Did you get these errors on restart only?

3

Use this syntax:

Garten_Haustuer.sendCommand(OFF)

The generic function is not aware of all types, I guess it is just defined as

string, string

.

1 Like
4

@ Vincent,

yes i’ve got these errors only on restart. Im wondering about, because there are a lot of other rules using sendCommand(,)

5

Don’t worry about them.
openHAB is trying to run the rules without having loaded all the language vocabulary.
It has to do with the order in which thing are started which can be a little random.
Ignore these errors.

I strongly advise you to go though your rules and change your sendCommand and postUpdate action to methods as show above.
The reason is: https://www.openhab.org/docs/configuration/rules-dsl.html#myitem-sendcommand-new-state-versus-sendcommand-myitem-new-state and https://www.openhab.org/docs/configuration/rules-dsl.html#deeper-dive

1 Like
6

I’ve been looking for a better way to say this. Thank you for this. I’mma gonna steal it. :wink:

7

Thanks for your help and the hint to the explanation.
I will begin to revise my rules :slight_smile:

Detlev.

8

I checked the rules-dsl.html, particularly the section “deeper dive”, but still can’t find an explanation. My workaround is doing well, but I would like to understand the mechanisms that avoid a simpler and more elegant solution.

The following rule does work:

if (a.state==“ON”) {
s.sendCommand(“ON”)
}
else if (a.state==“OFF”) {
s.sendCommand(“OFF”)
}

However, the following does NOT work:

if (a.state==“ON”) {
s.sendCommand(a.state)
}
else if (a.state==“OFF”) {
s.sendCommand(a.state)
}

My final goal is to simplify it with the following, most elegant solution:

s.sendCommand(a.state)

To complete the information, the Items are defined as follows (simplified):

Switch s “bla” {channel=“…”}
String a

Any idea why I cannot use sendCommand with the content of the variable? As I understand the documentation, (almost) all variables are converted to Strings inside sendCommand, but then it should work with the simpler solution.

9

A String Item state is not the same as a Switch Item state. “ON” not the same as ON.

A state is not quite the same object as a command. Especially confusing with ON/OFF which looks the same!
Try
s.sendCommand(a.state.toString)
for lowest common denominator

1 Like
10

Thank you very much, @rossko57. Works perfectly now. I had thought about this but rejected because I understood from the documentation that the value is converted anyway to the type the item needs. Seems that doesn’t happen properly in this case.