Hue Lights & storeState / restoreState not working

[bahmrockk (GBS)]

Hello All,

I’m at a loss completely now - but perhaps someone has an idea.
TL’DR> Hue Item changes on its own when the previous state had 0 brightness.

Test Setup:

• One hue lightstrip set-up as following:

Color wzIndirectLightColor { channel=“hue:0210:huebridge:tWZIndirekt:color”}

• A command list for the console:

openhab:send wzIndirectLightColor ("60","60","0")
openhab:send vDebug ON
openhab:send vDebug OFF

• The rule:

import java.util.Map
var Map savedState

rule "test"
when
	Item vDebug received command
then
	if (receivedCommand == ON) {
		logInfo("DEBUG", "ON")
		savedState = storeStates(wzIndirectLightColor)
		wzIndirectLightColor.sendCommand(HSBType::RED)
	}
	else {
		logInfo("DEBUG", "OFF")
		restoreStates(savedState)
	}
end

And now for the confusing part - the log results>

2022-12-05 10:55:40.940 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'vDebug' changed from OFF to ON
2022-12-05 10:55:40.945 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'wzIndirectLightColor' received command 0,100,100
2022-12-05 10:55:40.947 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'wzIndirectLightColor' predicted to become 0,100,100
2022-12-05 10:55:40.951 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'wzIndirectLightColor' changed from 60,60,0 to 0,100,100
2022-12-05 10:55:46.462 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'vDebug' received command OFF
2022-12-05 10:55:46.469 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'vDebug' changed from ON to OFF
2022-12-05 10:55:46.475 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'wzIndirectLightColor' received command 60,60,0
2022-12-05 10:55:46.477 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'wzIndirectLightColor' predicted to become 60,60,0
2022-12-05 10:55:46.482 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'wzIndirectLightColor' changed from 0,100,100 to 60,60,0

2022-12-05 10:55:48.771 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'wzIndirectLightColor' changed from 60,60,0 to 0,100,0

That last line is what makes me go crazy by now. The item is defined with only the hue link and no other rule refers to it (grep ftw).

If I define a Color testColor this behavior does not occur btw, only with hue lights.

Any tips or ideas are very welcome, I’m lost I have to admit.

[rossko57]

Same as this, isn’t it?

Rule: Types of Light Commands, Phantom Event

What we can’t see there is what the light really did. By which I mean, autoupdate has as usual made a prediction for us. We cannot be sure the lamp really went to 309,99,0 We can see a “real” OFF report seven seconds later - there was no command to that Item, so no autoupdate. Alright, so you were expecting to turn on at the colour of the last command you sent - 309,99,0 There is an assumption in that - because 309,99,0 is the equivalent of OFF. Are you sure your light takes any notice o…

[bahmrockk (GBS)]

Thanks for the link @rossko57!
That would mean though that the state actions are not working as described for this case or am I missing something? Plus in the logs I can see that the lamp really does go to x/y/0 and only after changes to 0/100/0.

I specifically don’t want to iterate over all lights - and it does work for a blank “Color” item with no hue thing linked to (I can’t test it with any other lights because I don’t have any :))

A workaround would be two state maps: one “as is”, then turning them all on and then restoring them in reverse order but that looks Hella hacky to me.

This is already briefly discussed in the linked thread but saving the colors in code wouldn’t solve the issue as turn on signals ca action? go via hue app as well. Is this then a bug in the savestates?

Thanks for taking your time btw!

[bahmrockk (GBS)]

Just in case someone is curious on how the solution in the link from @rossko57 looks like with the example above:

import java.util.Map
var Map savedState
var Map savedStateAllOn

rule "test"
when
	Item vDebug received command
then
	if (receivedCommand == ON) {
		logInfo("DEBUG", "ON")
		savedState = storeStates(wzIndirectLightColor)
		wzIndirectLightColor.sendCommand(ON)
		Thread::sleep(400)
		savedStateAllOn = storeStates(wzIndirectLightColor)
		wzIndirectLightColor.sendCommand(HSBType::RED)
	}
	else {
		logInfo("DEBUG", "OFF")
		restoreStates(savedStateAllOn)
		Thread::sleep(400)
		restoreStates(savedState)
	}
end

this works but the question is still open for me if this is a bug in savedState or a missunderstanding on my side what this action should actually do.

[rossko57]

@bahmrockk

Plus in the logs I can see that the lamp really does go to x/y/0 and only after changes to 0/100/0.

Don’t confuse the Item, the openHAB internal object, with the real world lamp.
You can update the Item state to anything you like, it won’t affect the real lamp.

Commands are processed by the binding and sent to the lamp.
Maybe at some time afterwards, the lamp will respond with a report of a new state.
Note that means trhat restoreStates will never ever affect the real lamp. You would need ro examine whatever/however you stored some state and send an appropriate command.

Meanwhile

openHABs internal autoupdate process has a guess at the expected result of the command and updates the Item state with that guess. That may or may not reflect the real lamp state. It may or may not be superceded by a real state report from the lamp later.

[bahmrockk (GBS)]

ohhh so restoreState basically manipulates the oponhab internal object state but the hue binding / the hue light says “last light color was red, deal with it” and the openhab internal object gets update when the lamp via the binding tells it “I stay red, pound sand”.

Thats the reason why I have to turn it on, so that the physical item and its binding is ok with the openhab object state - not a bug then but reality getting in the way of the code!

Edit: Thanks again for your explanations, @rossko57 !