Hueemulation and expire/UNDEF ignores OFF comands

Add-ons Bindings
1

I have some items that are toggle on/off IR/RF operated (where state might not be 100% correct in openHAB), and some where I might need to do another try if e.g. somebody is blocking the IR path. I used to have this working well in 2.3, by using the expire binding { expire=“2s” }. That way, in openHAB, the state would always be UNDEF, and any command I sent to it would be passed through (usually from Alexa through hue emulation) to by IR/RF blaster.

After upgrading to 2.4 this seems to have been broken at some step. Whenever the state is UNDEF, any attempt to turn the thing OFF is ignored (Hue emulation does not send the command).

Anyone have any clues? Is there a state check in the new hue emulation that treats UNDEF as OFF?

1 Like
2

Or could it be the way they are reported out (to Alexa)?

http://openhab/api//lights/18

{
“state”: {
“bri”: 0,
“ct”: 500,
“on”: false,
“reachable”: true,
“mode”: “homeautomation”,
“alert”: “none”
},
“type”: “Color Temperature Light”,
“modelid”: “LTW001”,
“uniqueid”: “141f3319-b662-43c0-a755-aa7353af6063-18”,
“manufacturername”: “Philips”,
“swversion”: “66012040”,
“friendsOfHue”: true,
“colorGamut”: “2200K-6500K”,
“hascolor”: false,
“name”: “Christmas Tree”,
“config”: {
“archetype”: “classicbulb”,
“function”: “functional”,
“direction”: “omnidirectional”
},
“capabilities”: {
“certified”: true,
“streaming”: {
“renderer”: false,
“proxy”: false
},
“control”: {}
}
}

Notice “state” reports “on”=false (while state is UNDEF in openHAB). I don’t have a 2.3 to compare with, but at least my setup has worked perfectly in earlier openHAB versions.

3

Here’s a link to an issue filed on github, maybe you will find something helpful.:crossed_fingers:

4

Thanks, but that issue is not related. All my devices are discovered (I have changed White item tags to Lighting,Switchable).

5

Anyone? @David_Graeff do you know? Should I open an issue? I am a bit unsure if this regression affects hue emulation only or 2.4 core functionality.

6

Yesterday I’ve updated to 2.4 and since then I have the same problem with the hue emulation. If I turn off items via Alexa that are already off, the commands are no longer send to OpenHab - which is very bad for me.

7

Could you please open a bug report? I will add a test to the hue emulation that checks for this case (e.g. sending off to an already off-state item). AFAIK the hue emulation code does not consider the current state for on/off, it just hands it over to the framework.

8

Ok, just did:

9

In the current code the call to hueDevice.applyState, looks like it returns null if the new state is the same as the current state.

With 2.4 my harmony remote no longer turns off lights if OH already thinks they are off which I never noticed on version 2.2