Philips Hue CLIP 2 API v2 Discussion Thread

In Main UI if you try to manually command the channel, you will see the supported list of options.

1 Like

Can we have a screenshot, please? I searched for this nearly the whole day - I don’t see that in OH GUI.
But if you can see it, just let us know the possible options, please :smiley:
I cannot choose from any options. “UNDEF” cannot be clicked - there is not list :roll_eyes: :

But anyhow, I was able to solve it for me.
LSELECT became replaced by BREATHE.
If you want to stop the blinking earlier than 15 seconds, I set the brightness to zero afer 3 seconds, e.g. rule:

  HueAlarmZone.sendCommand("BREATHE") //blinking on (Alert)
  Thread::sleep(3000)                 //wait 3 seconds
  HueAlarmBright.sendCommand(0)       //blinking (lights) off, brightness=0

1 Like

Hi @AndrewFG,

I am facing an issue I would like to share with you:
I do have a couple of HUE dimmers in my house.
They are working fine with your binding.
When I perform an openHAB-restart the rules are running although without any button pressed.

The rules look like this:

rule "HUE dimmer"
when Channel "hue:device:69f9118654:193:button-last-event" triggered
   if (receivedEvent == "1002") {
      <do some stuff, e.g. light on>
   if (receivedEvent == "2002") {
      <do some other stuff, e.g. Shelly OFF>

After openHAB reboot we can see in the log that every button on dimmers seem to be pressed:

2023-07-13 18:00:23.985 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:2:button-last-event triggered 2002
2023-07-13 18:00:24.035 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:2:button-last-event triggered 3002
2023-07-13 18:00:24.086 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:2:button-last-event triggered 4002
2023-07-13 18:00:24.187 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:2:button-last-event triggered 1002
2023-07-13 18:00:24.238 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:001788fffe2296fe:2' changed from UNKNOWN to ONLINE
2023-07-13 18:00:24.404 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:001788fffe2296fe:143' changed from UNKNOWN to ONLINE
2023-07-13 18:00:24.493 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:001788fffe2296fe:25' changed from UNKNOWN to ONLINE
2023-07-13 18:00:24.540 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:140:button-last-event triggered 3002
2023-07-13 18:00:24.557 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:001788fffe2296fe:147' changed from UNKNOWN to ONLINE
2023-07-13 18:00:24.590 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:140:button-last-event triggered 4002
2023-07-13 18:00:24.642 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:140:button-last-event triggered 1002
2023-07-13 18:00:24.690 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:140:button-last-event triggered 2002
2023-07-13 18:00:24.756 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:001788fffe2296fe:140' changed from UNKNOWN to ONLINE
2023-07-13 18:00:25.023 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:001788fffe2296fe:3ba2618c-0739-4280-9d49-9c022ac63092' changed from UNKNOWN to ONLINE
2023-07-13 18:00:25.043 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:001788fffe2296fe:94' changed from UNKNOWN to ONLINE
2023-07-13 18:00:25.073 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:69f9118654:189:button-last-event triggered 1003
2023-07-13 18:00:25.094 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:167:button-last-event triggered 3002
2023-07-13 18:00:25.144 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:167:button-last-event triggered 4002
2023-07-13 18:00:25.173 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:69f9118654:189:button-last-event triggered 2002
2023-07-13 18:00:25.194 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:167:button-last-event triggered 1002
2023-07-13 18:00:25.224 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:69f9118654:189:button-last-event triggered 4002
2023-07-13 18:00:25.244 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:167:button-last-event triggered 2002
2023-07-13 18:00:25.274 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:69f9118654:189:button-last-event triggered 3002
2023-07-13 18:00:25.294 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:001788fffe2296fe:167' changed from UNKNOWN to ONLINE
2023-07-13 18:00:25.324 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:69f9118654:189' changed from UNKNOWN to ONLINE
2023-07-13 18:00:25.373 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:169:button-last-event triggered 1002
2023-07-13 18:00:25.395 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:001788fffe2296fe:161' changed from UNKNOWN to ONLINE
2023-07-13 18:00:25.425 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:169:button-last-event triggered 4002
2023-07-13 18:00:25.526 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:169:button-last-event triggered 2002
2023-07-13 18:00:25.574 [INFO ] [openhab.event.ChannelTriggeredEvent ] - hue:device:001788fffe2296fe:169:button-last-event triggered 3002
2023-07-13 18:00:25.575 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:001788fffe2296fe:169' changed from UNKNOWN to ONLINE

Do you have an idea how to fix this?
Does the status of “button-last-event-triggered” survive a reboot - and when openHAB comes up the rule is excecuted?

I have scheduled an automatic openHAB reboot every two days - and this leads to (unwanted) enabled devices.

Thanks for your time for looking into this.
best, Kai

The dimmer unit has four buttons 100x, 200x, 300x, 400x. When the binding initializes, those buttons receive the last state x002 which means “button released”. So if you want to trigger a rule on a “button pressed” event you should probably look for x000 or x001 events rather than x002. Check the documentation. Philips Hue Binding Configuration for API v2 | openHAB

1 Like

Thanks for you answer, @AndrewFG.

Your idea is good, but it does not solve it:
I distinguish between short and long pressed button (means I use 8 possible triggers) - so going to x000 would remove 4 possible triggers.

Event Value

Further ideas? :slight_smile:

I don’t understand your problem. 0 is short press, and 1 is long press

1 is not long press, but repetition … if you hold the button, it’ll be sent multiple times.
I wonder whether it wouldn’t make more sense to abstract this in the binding, that is, have up to 4 button trigger channels, where each can send e.g. SHORT_PRESSED, LONG_PRESSED, LONG_REPEAT and LONG_RELEASED. The Homematic binding does it like that; it’s very convenient to use in rules like that.

Edit: thinking more about it, the above suggestion would be a convenience enhancement, but is not the root cause of the problem here. The problem is that IMHO button-last-event shouldn’t be triggered on startup. Wanting to support buttons pressed at OH or thing startup seems like a rather obscure niche use case compared to ‘I want to react to button release events’.

1 Like

The Hue bridge does send an SSE event whenever the binding connects. But probably that first event should not fire the respective OH trigger channel.


correct, when OH comes up a trigger should not be sent.

Docu says: 1000=pressed,1002=short release, 1003=long release.
When you short press and release the first button the triggers 1000 and 1002 are sent.
When you long press and release the first button the triggers 1000 and 1003 are sent.

Replacing 1002 with 1000 in rules (as you suggested) would remove the possibility to work with the long release 1003 trigger because you just check if button one was pressed (regardless if long or short).
Does this make sense? I hope it shows the problem.

Just to compare it with the Hue API-v1 binding the command was named “dimmer_switch_event” (equals to the new “button-last-event”). And this was working without sending a false trigger at startup :innocent:
I understand there might be changes in the HUE bridge with APIv2 - but maybe you see a chance not to check the last-button-pressed-trigger status at openHAB startup?

As I tried to explain earlier a openHAB restart fires all HUE buttons when it is booting. Radio, Light and much more are switched on… :crazy_face:

Over the years, I’ve seen folks have all kinds of problems with stuff happening when openHAB starts up. Rules firing before the items or rule engine or persistence service is initialized. From the beginning, I remember developers saying because of the architecture of the application, they couldn’t guarantee a specific sequence of events, that there was nothing they could do. Recently a rather long thread was started by a user who was trying to create a system to survive an unplanned cold restart (power failure). I suggested a UPS be added. The application doesn’t like restarts.
My question to you Kai, is how often does this happen? How often is restarting openHAB necessary? (during upgrades only?) Your problem only occurs during restarts. Restarts should only be needed on rare occasions. Can’t you plan to just turn all these things off on those rare occasions?
As time has gone on, the developers have tried to mitigate this problem in several ways. I know in the most recent version, there was a lot of work to make sure all the run levels fired on restart. Most rule languages have some form of system start trigger.
Perhaps you could write some kind of rule that sets a timer on system start that changes the state of a dummy item or something and put a only if clause in your dimmer rule or something. I don’t know, just food for thought

1 Like

Hi @Andrew_Rowe ,
thanks for your answer. I understand your point of view and agree in some points.
To answer your question: I do restart my openHAB every two days in the early morning. Reason for this was (and is) that there are reproducable connection issues with Apple Homekit. I am following the discussion about Homekit, mDNS and so on for months - and I don’t see a solution coming. Apple Homekit is loosing connection to openHAB after a certain time of days. By rebooting my OH ever 2 days I never ran into connections issues again and can control my OH via Apple Watch reliable.
As an IT-guy I agree if you answer: the “real root cause” is Apple Homekit? Yes, it is.
My problem is not really the HUE binding, but Apple Homekit.

In the meantime I built a workaround that HUE triggered rules will be delayed after OH reboot. But this is again just a workaround because I can see in HUE APIv1 binding that it was working for years.

Nevertheless is the behaviour of the HUE binding not as it should be. HUE-Dimmer-rules should not be fired because of a reboot, right? I can live with this (and my delay-workaround) but maybe some new users will run into this issues as well…
Just my two cents.

Any by the way, I really appreciate the new binding and all the work @AndrewFG did. The new binding is much faster and I am happy about this! I just wanted to give some feedback about things I found out. If this behaviour is already known and can not be changed easiliy, I am fine.

best, Kai

1 Like

OK, I thought I remembered that there was a situation like this that required a restart. (but I went back thru the thread and couldn’t find it) As you say, it’s a workaround until a real solution can be implemented.
So how about a when run level reaches 100, set a timer and disregard all dimmer button pushes until timer expires type thing, I don’t know. It’s a kluge on top of a kluge.
I sort of agree the button last event should not trigger on restart. I do have Hue devices and Hue seems to have an obsession with restoring the last state when they loss power and then come back on. Might be built into the system. Maybe Andrew can figure it out if it’s meant to be, maybe you can find a work around, maybe homekit will get fixed (I know the developer is working on it)
Happy automating

1 Like

It might be a DHCP lease renewal issue. Did you try using a static reserved IP address?

1 Like

Thanks @AndrewFG - I already investigated into that direction. I don’t have DHCP (anymore) in my network - all is static IP (except mobile devices).
But I guess we are getting off-topic? :crazy_face:
This is the HUE thread :innocent:

I’ve noticed that once the calculated lux appears to be less than 1, the channel reports UNDEF.

Based on the docs it appears that the calculation is correct, but if the api reports light_level_valid = true and the light_level is less than 1, I expected the channel to report 0 instead of UNDEF.

WDYT @AndrewFG ?

/var/log/openhab/events.log.6:2023-07-23 06:44:45.421 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_WC_Lux' changed from UNDEF to 1.4328475980645916 lx
/var/log/openhab/events.log.6:2023-07-23 08:24:41.200 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_WC_Lux' changed from 1.7631935968238326 lx to UNDEF
/var/log/openhab/events.log.6:2023-07-23 10:09:29.425 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_WC_Lux' changed from UNDEF to 1.1020467039630304 lx
/var/log/openhab/events.log.6:2023-07-23 13:54:06.707 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_WC_Lux' changed from 1.1020467039630304 lx to UNDEF
/var/log/openhab/events.log.6:2023-07-23 14:09:00.075 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_WC_Lux' changed from UNDEF to 1.6531033272370137 lx
/var/log/openhab/events.log.6:2023-07-23 14:14:04.553 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_WC_Lux' changed from 1.6531033272370137 lx to UNDEF
/var/log/openhab/events.log.6:2023-07-23 14:19:04.065 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_WC_Lux' changed from UNDEF to 1.4328475980645916 lx
/var/log/openhab/events.log.7:2023-07-23 16:38:50.159 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_WC_Lux' changed from 1.1020467039630304 lx to UNDEF
/var/log/openhab/events.log.7:2023-07-23 17:23:45.310 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_WC_Lux' changed from UNDEF to 1.1020467039630304 lx
/var/log/openhab/events.log.7:2023-07-23 17:53:42.212 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_WC_Lux' changed from 1.2122717925364968 lx to UNDEF
/var/log/openhab/events.log.7:2023-07-23 18:13:40.474 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_WC_Lux' changed from UNDEF to 1.1020467039630304 lx
/var/log/openhab/events.log.7:2023-07-23 18:23:39.454 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_WC_Lux' changed from 1.1020467039630304 lx to UNDEF

Disclaimer: Running version, looked at code here; openhab-addons/bundles/org.openhab.binding.hue/src/main/java/org/openhab/binding/hue/internal/dto/clip2/ at 72607d3bee908189b10eede5aa24ca0cabd301af · openhab/openhab-addons · GitHub

Can you please post a trace log entry showing the JSON of a light level where the calculated lux would be less than 1?

@seime I do wonder if the stated Philips formula '10000 * log10(lux) + 1' is really correct? That formula cannot encode a zero lux level. I wonder if it should actually be '10000 * log10(lux + 1)'. => WDYT?

^ See this

Hi Andrew, I agree that lux levels between 0 and 1 cannot be communicated by the formula in the doc.

Looking at this table Lux - Wikipedia I do not think changing the formula would yield a correct value anyway. Maybe the sensor just isn’t accurate enough to provide any useful measurement at low lighting conditions.

Tested a bit, and it is rather “impossible” to manually adjust the lighting condition to something that reports more than 0 and less than something that would result in a lux value between 0 and 1. The lowest light-level I was able to create (above 0) was 837

Here is a TRACE of a 0 level condition;

onEventData() data:[{"creationtime":"2023-07-24T12:09:15Z","data":[{"id":"51d1c0d2-1cce-45c9-a64b-5396bf753553","id_v1":"/sensors/28","light":{"light_level":0,"light_level_report":{"changed":"2023-07-24T12:09:15.426Z","light_level":0},"light_level_valid":true},"owner":{"rid":"3dcdda92-3d88-4ef0-80b1-3530bb110ebe","rtype":"device"},"type":"light_level"}],"id":"79a10d81-8ddc-488b-8581-e33669f6525b","type":"update"}]

We could wait and see if your post on the hue developer forum gets a response - or just treat light_level of 0 when reported with light_level_valid=true as the value 0?

This is the revised code. I think it WILL return valid Lux values (albeit different from what you would see in the prior version). I am testing it now…

EDIT: so far it produces the following…

  • 0 lx when sensor is in a box inside my rucksack.
  • 1890 lx when sensor is on my window sill on overcast (English) summer day.
1 Like