Why 'newState' not work with Color Item?

Try to sync states, got error:

Script execution of rule with UID 'room-1' failed: An error occurred during the script execution: Could not invoke method: org.openhab.core.model.script.actions.BusEvent.sendCommand(org.openhab.core.items.Item,java.lang.String) on instance: null in room
Color   roomLight_BSLampRGB         "RGB" {channel="miio:basic:light:rgbColor"} 
Switch  roomLight_BSLamp            "Lamp" {channel="miio:basic:light:power"} 

rule "ROOM roomLight_BSLamp CHANGED"
    Item roomLight_BSLamp changed to ON
    or Item roomLight_BSLamp changed to OFF

Work only this way:

roomLight_BSLampRGB.sendCommand(if (newState == ON) ON else OFF)

I would have expected that to work.

As a work around it might be a little simpler to pass newState’s toString instead of using the ternary operator.


That should work too. Often what happens when you just see a null error like this it cannot coerce the type of the Item into one that’s useable. In this case I suspect that newState is of type State and perhaps a State can’t be sent as a Command.

Unfortunately Rules DSL isn’t really good at dealing with situations like this.

State   Command   Object
   \       |       /

OnOffType is an Object and a Command and an Object all at the same time. So far so good. But all the engine knows is that newState is of type State and that sendCommand needs something of type Command. The engine isn’t smart enough to look down that type hierarchy tree and then back up the tree to see that it’s also a Command so it just gives up.

@rlkoshak Thanks, .toString works.

So this is a new feature in openHAB 3? I had a working case in 2.5, such as:


(This was to test persistence by having the Den follow the Master light, in a rule executing every 10 seconds)

In openHAB 3.0.2 I had to add a .toString to get it to work.

I can’t explain why that worked in 2.5. Looking at the code, it shouldn’t have. historicState returns a State and you can’t send a State as a command to an Item.

There have been changes and updates to the Rules DSL engine over that time so perhaps something changed upstream to change how it figures out type.