Error in Designer/Rule OnOffType


i´ve a problem with the following rule. The Designer complaining the “OFF”

Incompatible types. Expected java.lang.Number but was org.openhab.core.library.types.OnOffType

and i´m not sure why. I got the rule from the “demo.rules”

rule "Holiday lights off"
	Time cron "0 30 22 * * ?"
	if(AutoHoliday.state == ON)
			postUpdate(light, OFF) 


Did you import the right things? At the start of each rule file yu have to import some things.

import org.openhab.core.library.types.* import org.openhab.core.library.items.*


hi Thomas,

yes i´ve imported this:

import org.openhab.core.library.types.*
import org.openhab.model.script.actions.*
import org.openhab.core.library.items.*

Does it help if you change it to:



Hi watou,

works like charm :smile: …but for my thirst for knowledge…why is “postUpdate(light, OFF)” or “postUpdate(light, if(Math::random > 0.7) ON else OFF)” not working?


this works:

light.postUpdate(if(Math::random > 0.6) ON else OFF)
but why?

At the risk of being wrong (it happens a lot) I think what is going on is that the postUpdate action has to be generic enough to handle ALL Item types. So when you use the action it has a plethora of different types of State objects it needs to cast the value you pass to it into in order to update the Item. And if it works like the MQTT binding did (until recently, thanks@watou!, still no errors on my end) it ends up matching with the first type it can be cast to which may not always be the right type for the Item.

But, when you use the postUpdate method on the Item itself it knows a whole lot more about what sorts of States are acceptable and how to cast and convert between them so it handles the state better.

I’ve seen this both in my rules and in others posted on the forum and it is the main reason why I almost always use MyItem.postUpdate and MyItem.sendCommand instead of the actions. And when I do need to use the actions I convert the State to a String.

postUpdate(light, "OFF")
1 Like

Hi Rich,

thx for the detailed explanation. Then i´ll go ahead and use from now on “MyItem.postUpdate and MyItem.sendCommand”


I can’t check the code right now, but your theory makes sense, @rlkoshak. If the call were changed to

postUpdate(light as SwitchItem, OFF)

I wonder if that would make a difference? It’s too verbose and should be avoided, but I’m curious. They ought to be made to work the same as the light.postUpdate (...) method.

I was thinking something similar.

If I were implementing something like this from scratch, the action methods would turn around and end up calling the Item’s postUpdate or sendCommand anyway. That would consolidate the code so the behavior would be the same. But having not looked at the code I’m sure there is some limitation or other reason to not do it like that.

1 Like


postUpdate(light as SwitchItem, OFF)

…works :smile:
So its seem that you have to tell the postUpdate, which kind of item “light” is :

1 Like