HSBType not handled correctly

Hello

I am running openhab on a Raspberry Pi 3B with openhabian.

I have IKEA RGB lights and control them with a python script. The scripts input are RGB Values so i convert the openhab HSBType with the following code to rgb:

val String blue = (ring_1.state as HSBType).getBlue.toString
val String green = (ring_1.state as HSBType).getGreen.toString
val String red = (ring_1.state as HSBType).getRed.toString

logInfo(" ","Ring 1 Colors: (b/g/r): " + blue + " " + green + " " + red)

This wokrs fine most of the times put sometimes it just does random stuff:

2018-06-28 10:31:49.954 [ome.event.ItemCommandEvent] - Item 'ring_1' received command 0,100,100
2018-06-28 10:31:49.981 [vent.ItemStateChangedEvent] - ring_1 changed from 120,100,100 to 0,100,100
2018-06-28 10:31:49.971 [INFO ] [org.eclipse.smarthome.model.script. ] - Ring 1 Colors: (b/g/r): 0 100 0

And this is wrong: HSBType 0,100,100 is pure red which should be (b/g/r) 0 0 100

I woudl appreceate any kind of help and i am sorry for my bad englisch

Maybe it’s a timing problem and a delay helps.

2018-06-28 10:31:49.971 [INFO ] [org.eclipse.smarthome.model.script. ] - Ring 1 Colors: (b/g/r): 0 100 0

is before

2018-06-28 10:31:49.981 [vent.ItemStateChangedEvent] - ring_1 changed from 120,100,100 to 0,100,100
2 Likes

@hr3 has a point, what it the rule’s trigger?

1 Like

:slight_smile: well it seems like it is a timing problem

adding Thread::sleep(100) before the hsb to rgb conversion did the job

thx a lot for the fast friendly awnsers, verry nice community :slight_smile:

This happened because the state if the item is updated after the command is received and in the mean time your rule queries the state which has not updated yet
If you change your rule trigger to changed or received update it will work without the delay because the rule triggers on an update event not a command event. But before you change the rule trigger you need to ask yourself the question if the command trigger is your case is really needed because sometimes it is.

Or use the receivedCommand implicit variable which gets populated by the command that triggered the rule. This is the better approach over a thread sleep for received command triggered rules.