Philips Hue CLIP 2 API v2 Discussion Thread

Add-ons Bindings
116

The log you sent me seems not to be from the latest version. The Jar file should have the ‎2023-‎04-‎20 ‏‎16:20 timestamp.

117

You are right. wget fooled me by appending .1 to the jar zip file.

Restarted openhab with latest version (please verify)

openhab> bundle:list|grep hue
356 │ Active │  80 │ 3.4.3.202304201519     │ openHAB Add-ons :: Bundles :: hue Binding

Now my scene channels seem to be missing altogether.

118

Correct.

Please check the log for ‘updateChannelList()’ entries and any warnings for that.

EDIT: I am guessing you would see entries like the following; in which case temporarily remove and restore the thing in your respective ‘.things’ file…

"{} -> updateChannelList() required channel '{}' missing => please recreate thing!",
119

I fixed that too. The new Jar is (again) in the same place.

120

Maybe. I can see at least four areas where one might apply some form of dynamics to a light transition…

  1. As you say, the dynamics.duration field for light resp. grouped_light
  2. Analogously the dynamics.duration field for scene (probably)
  3. The timed_effects.duration field for light (not sure about this though)
  4. The afore-mentioned behaviour_instance with its timing parameters

Now all of the above pose a problem for us in OH – namely…

Currently when OH issues (static) commands to things, it passes a single command parameter that defines the target value e.g. PercentType(23),
HsbType(11,22,33), StringType('SCENE_NAME'), OnOffType.ON etc.

HOWEVER to issue a timed command to a thing, OH would need to pass a ‘complex’ command with two parameters with the target value PLUS the delay time e.g. ComplexCommand(PercentType(23), DecimalType(45))

UNFORTUNATELY such an animal as ComplexCommand() does not exist in OH! Nor is there any conceivable way of representing such a complex command in a standard UI control element.

I have experience of a similar challenge in the Tado (thermostat) binding. Where OH issues complex commands like “set temperature 25 celsius for 1 hour”. It does this by implementing two channels “set temperature” resp. “until time”. And the binding implements a processing delay so that if a “set temperature” and an “until time” are both received from OH within say 2 seconds, they will be combined into a single command to the Tado hub.

The above solution works fine for heating: Who cares if a “set temperature” command would not be executed until 2 seconds later, just in case an “until time” command might also be received? However for Hue it may be more disturbing if an (immediate) “dimming” command would be delayed by 2 seconds, just in case a “duration” command might also be received.

@seime (and anyone else) => what do you think?

PS nota bene: the process delay issue with Hue could be ameliorated if the “duration” command could only be sent before the “dimming” command e.g. in pseudo logic as follows…

if ("duration" command received) -> delay 2 seconds -> if ("dimming" command received) => execute ("dimming" @ "duration")
 vs.
if (("dimming" command received) && !("duration" command received in last 2 seconds)) -> execute ("dimming" @ immediately)

EDIT: let me make a test version with the above-mentioned “two-channel-duration-before-action” model so we can play around with it…

EDIT 2: I made the test version with two-channel-duration-before-action setting the command dynamics. It works perfectly! :slight_smile: Jars in the usual place.

121

From rules you can use Rule Actions (existing hue action) to achieve this. From a UI perspective you can now access these thing actions from the API starting from 4.0 M1.

IMHO your suggested workaround could easily become flaky on a slow or overloaded system. I found this question while researching; to me it is unclear whether openhab guarantees events to be ordered in the same way as they are sent - or if dimming could be delivered before duration even if duration was sent first. Maybe @J-N-K could comment?

Also, for lights i personally find 2 seconds delay unacceptable because I expect immediate visual feedback when pushing a button to turn lights on. In fact, the reason I am testing your updated binding is to get rid of the state update delay when increasing/decreasing brightness with 10% from a push button on the wall :slight_smile:

1 Like
122

I can’t say if it ‘guarantees’ the order, but I can say that during my testing I have never observed handleCommand() being called out of order.

In the meantime I observed another more difficult issue, (which would cause problems both with my solution, and with a rules based solution). The problem is as follows…

  1. Light starts off at (say) brightness == 1%
  2. User sends a complex command e.g. set brightness to 100% over 20 seconds
  3. Binding sends complex command to bridge
  4. Bridge IMMEDIATELY sends SSE event with (target) brightness == 100%
  5. After about ~15 seconds bridge sends another SSE event with (actual) brightness == about 70%
  6. Binding informs OH with brightness == 70%
  7. OH core sends unsolicited handleCommand() with brightness == 70%
  8. This causes the binding to send brightness == 70% to the bridge
  9. Which STOPS the planned transition to brightness == 100%

The problem is with the OH core step 7. above; and I don’t know how to fix it. Note: the problem does not arise with transitions less than about 15 seconds, since steps 5, 6, 7, etc. do not occur.

123

Tried the latest version (logs via email)

openhab> bundle:list|grep hue
356 │ Active │  80 │ 3.4.3.202304230854     │ openHAB Add-ons :: Bundles :: hue Binding

Now scenes seem to be working while sending commands, but the active scenes are still not showing correctly after startup. Mix of UNDEF and NULL.

Best regards

124

No 7 sounds really strange - there should be no command sent from the framework AFAIK?

125

Exactly. That is why, if you send a command (without precessor) it will be executed immediately. Whereas if you send a command that had been preceded by a delay command, it will be executed with the respective delay.

126

Me too. It’s upsetting. Maybe a bug in OH?

EDIT: yes, it is a bug in OH Core resp. Main UI.

  1. If you use (say) the Hue app to send a channel command, and that same channel is being displayed in Main UI, then OH will accept the new value, the Main UI will update, and OH will send a handleCommand() to the thing.
  2. If you use (say) the Hue app to send a channel command, and that same channel is NOT being displayed in Main UI, then OH will accept the new value, and OH will NOT send a handleCommand() to the thing.
127

Ok. In the latest build, I implemented it BOTH ways.

  1. Send a DecimalType(transitionDuration) to the dynamics channel, and then within ten seconds send (say) a PercentType(100) to the brightness channel, or …

  2. From within a rule send dynamicCommand(String channelId, Command command, DecimalType durationMSec)

The Jar is in the usual place…

128

Works, thanks!

BTW Did you consider keeping the same rule action name? Easier migration for rule users.

Regards

129

Yes I did. However one of the advantages of API v2 is that dynamics do not only apply to lights, but also to scenes and rooms and zones. So the old name is not completely appropriate. It is probably a trade off between making it easier for existing users, versus making it easier for new users.

130

@seime apologies for the delay, but there is a new Jar which fixes the scene actualisation and dynamics. It is in the usual place HERE

131

Thanks @AndrewFG,

openhab> bundle:list|grep hue
356 │ Active │  80 │ 3.4.3.202304251442     │ openHAB Add-ons :: Bundles :: hue Binding

Found this:

  • 3dcdda92-3d88-4ef0-80b1-3530bb110ebe -> updateState() 'light-level' updated to '11853' - light-levels are reported by a factor of 100 I guess?
  • Something still isn’t right with scenes. Restarted openhab, and suddenly two my room/zones do no longer have a scene channel - which they had before restart
    CleanShot 2023-04-26 at 19.01.07
    CleanShot 2023-04-26 at 19.01.07732×138 11 KB

Logs via mail,

Regards

132

See the following from the Hue API v2 documentation:

Light level in 10000*log10(lux) +1 measured by sensor. Logarithmic scale used because the human eye adjusts to light levels and small changes at low lux levels are more noticeable than at high lux levels. This allows use of linear scale configuration sliders.

EDIT: notwithstanding the comment about linear scales, I could imagine that OH users might prefer if this channel would reverse the above mentioned transformation formula and present the actual light level in Lux. => WDYT?

EDIT 2: i.e. rather than the channel being a Number (:Dimensionless), it should perhaps be Number:Illuminance ??

EDIT 3: to answer my own question, I think the answer should be ‘yes’…

1 Like
133

Can you please give me the resource id (the Hue resource id) of those things, so I can find them easier in your logs?

134 
Bridge hue:bridge-api2:stue "Hue Bridge Stue, Trapp og kjøkken (Ny)" [.. ]  {

Thing zone trappSpotter "Trapp spotter (lysgruppe)" [resourceId="2d5e0450-7b54-4c00-86cb-e487c041512c"] // Zone idV1:/groups/10
Thing room stue "Stue (lysgruppe)" [resourceId="b207b5ce-4cc4-4b4d-9242-74d938d66c17"] // Room idV1:/groups/17

...
}

String Light_Stue_Scene "Stue scene (navn)" { channel="hue:room:stue:stue:scene"}
String Light_Trapp_Spotter_Scene "Trapperom spotter scene (navn)" { channel="hue:zone:stue:trappSpotter:scene"}
135

Definately :slight_smile:

1 Like