Philips Hue CLIP 2 API v2 Discussion Thread

It’s not that clever. The behaviour in OH is exactly the same as in the Hue App.

I have just updated the JAR and got the folowing:

12:45:53.824 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoSuchMethodError: 'org.openhab.core.library.types.HSBType org.openhab.core.util.ColorUtil.xyToHsb(double[], org.openhab.core.util.ColorUtil$Gamut)'
        at org.openhab.binding.hue.internal.dto.clip2.Resource.getColorState(Resource.java:265) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateChannels(Clip2ThingHandler.java:478) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.onResource(Clip2ThingHandler.java:380) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateResource(Clip2ThingHandler.java:685) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateContributors(Clip2ThingHandler.java:571) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateDependencies(Clip2ThingHandler.java:584) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.lambda$1(Clip2ThingHandler.java:372) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
        at java.lang.Thread.run(Thread.java:833) ~[?:?]
12:45:54.123 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoSuchMethodError: 'org.openhab.core.library.types.HSBType org.openhab.core.util.ColorUtil.xyToHsb(double[], org.openhab.core.util.ColorUtil$Gamut)'
        at org.openhab.binding.hue.internal.dto.clip2.Resource.getColorState(Resource.java:265) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateChannels(Clip2ThingHandler.java:478) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.onResource(Clip2ThingHandler.java:380) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateResource(Clip2ThingHandler.java:685) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateContributors(Clip2ThingHandler.java:571) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateDependencies(Clip2ThingHandler.java:584) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.lambda$1(Clip2ThingHandler.java:372) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
        at java.lang.Thread.run(Thread.java:833) ~[?:?]
12:45:54.446 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'hue:device:45c11460b6:4a1f8a73-3543-41f4-b4d9-173dc03747f5' changed from UNKNOWN to ONLINE
12:45:54.543 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoSuchMethodError: 'org.openhab.core.library.types.HSBType org.openhab.core.util.ColorUtil.xyToHsb(double[], org.openhab.core.util.ColorUtil$Gamut)'
        at org.openhab.binding.hue.internal.dto.clip2.Resource.getColorState(Resource.java:265) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateChannels(Clip2ThingHandler.java:478) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.onResource(Clip2ThingHandler.java:380) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateResource(Clip2ThingHandler.java:685) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateContributors(Clip2ThingHandler.java:571) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateDependencies(Clip2ThingHandler.java:584) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.lambda$1(Clip2ThingHandler.java:372) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
        at java.lang.Thread.run(Thread.java:833) ~[?:?]
12:45:54.745 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoSuchMethodError: 'org.openhab.core.library.types.HSBType org.openhab.core.util.ColorUtil.xyToHsb(double[], org.openhab.core.util.ColorUtil$Gamut)'
        at org.openhab.binding.hue.internal.dto.clip2.Resource.getColorState(Resource.java:265) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateChannels(Clip2ThingHandler.java:478) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.onResource(Clip2ThingHandler.java:380) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateResource(Clip2ThingHandler.java:685) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateContributors(Clip2ThingHandler.java:571) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateDependencies(Clip2ThingHandler.java:584) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.lambda$1(Clip2ThingHandler.java:372) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
        at java.lang.Thread.run(Thread.java:833) ~[?:?]
12:45:55.153 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoSuchMethodError: 'org.openhab.core.library.types.HSBType org.openhab.core.util.ColorUtil.xyToHsb(double[], org.openhab.core.util.ColorUtil$Gamut)'
        at org.openhab.binding.hue.internal.dto.clip2.Resource.getColorState(Resource.java:265) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateChannels(Clip2ThingHandler.java:478) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.onResource(Clip2ThingHandler.java:380) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateResource(Clip2ThingHandler.java:685) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateContributors(Clip2ThingHandler.java:571) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateDependencies(Clip2ThingHandler.java:584) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.lambda$1(Clip2ThingHandler.java:372) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
        at java.lang.Thread.run(Thread.java:833) ~[?:?]
12:45:55.448 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoSuchMethodError: 'org.openhab.core.library.types.HSBType org.openhab.core.util.ColorUtil.xyToHsb(double[], org.openhab.core.util.ColorUtil$Gamut)'
        at org.openhab.binding.hue.internal.dto.clip2.Resource.getColorState(Resource.java:265) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateChannels(Clip2ThingHandler.java:478) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.onResource(Clip2ThingHandler.java:380) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateResource(Clip2ThingHandler.java:685) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateContributors(Clip2ThingHandler.java:571) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateDependencies(Clip2ThingHandler.java:584) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.lambda$1(Clip2ThingHandler.java:372) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
        at java.lang.Thread.run(Thread.java:833) ~[?:?]
12:45:55.452 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'openHABServer_MemoryUsed' changed from 59.5 to 59.8
12:45:55.454 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'openHABServer_CPULoad' changed from 1.9 % to 4.9 %
12:45:55.548 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoSuchMethodError: 'org.openhab.core.library.types.HSBType org.openhab.core.util.ColorUtil.xyToHsb(double[], org.openhab.core.util.ColorUtil$Gamut)'
        at org.openhab.binding.hue.internal.dto.clip2.Resource.getColorState(Resource.java:265) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateChannels(Clip2ThingHandler.java:478) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.onResource(Clip2ThingHandler.java:380) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateResource(Clip2ThingHandler.java:685) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateContributors(Clip2ThingHandler.java:571) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateDependencies(Clip2ThingHandler.java:584) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.lambda$1(Clip2ThingHandler.java:372) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
        at java.lang.Thread.run(Thread.java:833) ~[?:?]
12:45:55.953 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'hue:room:45c11460b6:0c3872fc-9c14-4d02-8ebc-bb3a8c142aea' changed from UNKNOWN to ONLINE
12:45:56.154 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoSuchMethodError: 'org.openhab.core.library.types.HSBType org.openhab.core.util.ColorUtil.xyToHsb(double[], org.openhab.core.util.ColorUtil$Gamut)'
        at org.openhab.binding.hue.internal.dto.clip2.Resource.getColorState(Resource.java:265) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateChannels(Clip2ThingHandler.java:478) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.onResource(Clip2ThingHandler.java:380) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateResource(Clip2ThingHandler.java:685) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateContributors(Clip2ThingHandler.java:571) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.updateDependencies(Clip2ThingHandler.java:584) ~[?:?]
        at org.openhab.binding.hue.internal.handler.Clip2ThingHandler.lambda$1(Clip2ThingHandler.java:372) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
        at java.lang.Thread.run(Thread.java:833) ~[?:?]

All the lights etc. seem to be working however. Will test all the rest ASAP.

EDIT: Actually seem to get this each time I send a color to a lamp?

function colorHexToHSB (hexColor) {
  var rgb = /^#?([a-f\d]{2})([a-f\d]{2})([a-f\d]{2})$/i.exec(hexColor);
  if (!rgb) return '';
  var r = parseInt(rgb[1], 16) / 255, g = parseInt(rgb[2], 16) / 255, b = parseInt(rgb[3], 16) / 255;
  var v = Math.max(r, g, b), n = v - Math.min(r, g, b);
  var h = n === 0 ? 0 : n && v === r ? (g - b) / n : v === g ? 2 + (b - r) / n : 4 + (r - g) / n;
  return [60 * (h < 0 ? h + 6 : h), v && (n / v) * 100, v * 100].join(',');
}

var thread = Java.type('java.lang.Thread')


cache.private.put('Hue_color_spot_7_Brightness', items.getItem('Hue_color_spot_7_Brightness').state);
cache.private.put('Hue_color_spot_7_Color', items.getItem('Hue_color_spot_7_Color').state);
cache.private.put('Hue_color_spot_7_Color_Temperature', items.getItem('Hue_color_spot_7_Color_Temperature').state);
cache.private.put('Hue_color_spot_7_Power', items.getItem('Hue_color_spot_7_Power').state);
console.info(('Hue_color_spot_7_Brightness: ' + String(cache.private.get('Hue_color_spot_7_Brightness'))));
console.info(('Hue_color_spot_7_Color: ' + String(cache.private.get('Hue_color_spot_7_Color'))));
console.info(('Hue_color_spot_7_Color_Temperature: ' + String(cache.private.get('Hue_color_spot_7_Color_Temperature'))));
console.info(('Hue_color_spot_7_Power: ' + String(cache.private.get('Hue_color_spot_7_Power'))));
items.getItem('Hue_color_spot_7_Power').sendCommand('ON');
items.getItem('Hue_color_spot_7_Color').sendCommand(colorHexToHSB('#ff0000'));
thread.sleep(5000);
console.info('******Timer Expired*****');
items.getItem('Hue_color_spot_7_Brightness').sendCommand((cache.private.get('Hue_color_spot_7_Brightness')));
items.getItem('Hue_color_spot_7_Color').sendCommand((cache.private.get('Hue_color_spot_7_Color')));
items.getItem('Hue_color_spot_7_Color_Temperature').sendCommand((cache.private.get('Hue_color_spot_7_Color_Temperature')));
items.getItem('Hue_color_spot_7_Power').sendCommand((cache.private.get('Hue_color_spot_7_Power')));
console.info('******Rule Completed*****');

And even though the lights are thn all OFF (assuming they started off), the Group still reports as ON, until they group is toggled. Hoping this is just a side effect of the WARN?

Ah. There was recent update to OH core where they added a ColorUtil class to improve the accuracy of color conversions. So you will need to upgrade your OH 4.0 to latest SNAPSHOT.

Thank you. The latest SNAPSHOT did resolve that warning.

I have now changed to using a different scene for my Alarm setup - as per your last update the scene will be “cancelled” if a lamp in a scene changes.

So I have created a new scene called Alarm Test whose GUID is 79f278e7-0457-4308-b7a7-c151907671b6

If I send 79f278e7-0457-4308-b7a7-c151907671b6 to the scene, the scene updates correctly.

However is I send Alarm Test, the scene does not get implemented. (If there is an active scene in place)

This causes a problem when trying to restore the previous state as the state is read as the Name of the scene, so my lights are on Lounge Default, if I send Lounge Default to restore the previous state, that is not implemented, however if I send fc344d9a-4c63-4e38-8082-d23b48b2152c (the GUID for Lounge Default) the state is restored.

This only seems to be a problem if there is already an active scene.

So if the lights are all off and I send Lounge Default or Alarm Test the correct scene is applied.

Any ideas on what the issue could be?

Rule code:

var thread = Java.type('java.lang.Thread')


cache.private.put('Lounge_Room_Scene', items.getItem('Lounge_Room_Scene').state);
cache.private.put('Lounge_Room_Brightness', items.getItem('LoungeRoom_Brightness').state);
cache.private.put('Lounge_Room_Switch', items.getItem('LoungeRoom_Switch').state);
console.info(('Lounge_Room_Scene ' + String(cache.private.get('Lounge_Room_Scene'))));
console.info(('Lounge_Room_Brightness ' + String(cache.private.get('Lounge_Room_Brightness'))));
console.info(('Lounge_Room_Switch ' + String(cache.private.get('Lounge_Room_Switch'))));
items.getItem('Lounge_Room_Scene').sendCommand('79f278e7-0457-4308-b7a7-c151907671b6');
items.getItem('LoungeRoom_Switch').sendCommand('ON');
thread.sleep(5000);
console.info('******Timer Expired*****');
items.getItem('Lounge_Room_Scene').sendCommand('fc344d9a-4c63-4e38-8082-d23b48b2152c');
items.getItem('LoungeRoom_Brightness').sendCommand((cache.private.get('Lounge_Room_Brightness')));
items.getItem('LoungeRoom_Switch').sendCommand((cache.private.get('Lounge_Room_Switch')));
console.info('******Rule Completed*****');

Yes I discovered this myself as well. I changed it so that commands no longer use the scene UID but use the scene friendly name. In other words “wysiswyg”.

WARNING: but before you install the latest Jar, please see my message below…

Seems that the “Name” was not working at all… Was just switching lights on in the last “scene”

Will wait and see, thank you.

Now just need to find how to create a scene with a blinking light in the Hue App.

WARNING: the OH binding maintainers team just updated the official naming convention for things and channels. And I was asked therefore to align with their new convention. This means that the next version of the updated Jars will have the following BREAKING CHANGES

  1. The bridge thing name is changed from hue:clip2:mybridge => hue:bridge-api2:mybridge
  2. Channel names that were in “camelCase” are changed to “dash-separated” e.g. hue:device:mybridge:[uid]:colorTemperature => hue:device:mybridge:[uid]:color-temperature

Apologies for this breaking change. The new Jars are HERE

I never used it myself, but in the App some lights do allow setting an “Effect” which is presumably a dynamic scene of some sort…

Please correct me if I am wrong, but will this affect any existing linked Items? Is there any reason to delete the THINGS etc?

Or do you think it would be best to cleanup and start again? and rediscover everything?

Thank you. Appears mine do not support this, even though some Dynamic Scenes from Hue work. Not the end of the world though I guess.

Personally I have .things and .items files, so I was able to hand edit them.

I did also have a handful of things created via the UI, and unfortunately those things got confused, and I needed to delete and recreate them.

Items that were linked to a channel whose name did not change are not affected. But items linked to changed channel names can be edited via the UI to link to the new channel.

Overall it took me about 30 minutes.

Just FYI, running a SCAN on the Hue Binding (to search for Bridge):

16:48:42.858 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
        at java.util.Objects.requireNonNull(Objects.java:208) ~[?:?]
        at org.openhab.binding.hue.internal.discovery.HueBridgeNupnpDiscovery.getBridgeList(HueBridgeNupnpDiscovery.java:146) ~[?:?]
        at org.openhab.binding.hue.internal.discovery.HueBridgeNupnpDiscovery.discoverHueBridges(HueBridgeNupnpDiscovery.java:75) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
        at java.lang.Thread.run(Thread.java:833) ~[?:?]

EDIT:
Stopped happening after deleting all previous THINGS

I saw something similar. I think it is because the old discovery component (looking for bridges named ‘clip2’) may have still been loaded when the new Jar is hot loading a discovery component looking for bridges named ‘bridge-api2’. So I think it is a transient issue, that won’t normally arise a) because we dont normally change such structures, and b) a cold load (system shutdown / restart) would fix it.

1 Like

Thanks Andrew, that has fixed the Scene names. Works well now.

I have now noticed something else though… But this may be an API shortcomming?

If the Lights are all on a scene (Lounge Default) and the Room/Group is switched OFF and then back on Later, the lights are restored to the same settings (configurable in APP I think - but can’t find right now), but the scene is not restored.

Is this an API thing or something else?

Yes, I think that is normal. If you just use the App, when you set a scene, the scene’s icon in the App is shown highlighted. And if you then do Off and On again, the lights restore to the same state, but the scene’s icon is no longer shown highlighted.

Thanks for doing this huge migration @AndrewFG. Much appreciated!

I’ve got 150+ Hue devices installed and configured via item/thing files. So I am naturally looking for the easiest way to migrate my setup :).

I read through your migration guide, and I think I spotted some outdated info, plus one question (mark no 3):

Is there a better way to correlate the old sensorId/lightId field with the new resourceId than by thing name? Ie getting access to both values using one of the APIs?

Many thanks. I will update. And tomorrow I will post some more specific advice on the migration process.

I just pushed a new commit with corrections to the documentation. Many thanks for pointing out those errors.

This is a ‘very good’ question. First a couple of observations as background…

  • Currently when you fetch a resource from the Hue bridge via API v2, the bridge returns a JSON payload containing both the ‘resource Id’ (idV2) and the old ‘id’ (idV1).
  • Philips / Signify warns two things about the idV1 field – namely a) it will only be present on ‘legacy’ devices that were added to the bridge prior to the official switchover to API v2, and b) at some time in the future the idV1 field may be deleted entirely i.e. even from legacy devices…

As far as migration is concerned, the binding has two features that may help you…

  1. There is an OH console command openhab:hue hue:bridge-api2:myname things that produces a listing of all API v2 things in the bridge. Note: you can pipe the output of that command to a file, in order to create a ‘.things’ file directly openhab:hue hue:bridge-api2:myname things > myThingsFile.things
  2. If you already have an operational API v1 system running, then the Inbox thing discovery process will attempt to create V2 things resp. items that are mapped to the already existing v1 things / items. HOWEVER obviously if the v1 items are hard coded via `.items’ files this mapping might not work…

Note: apropos the above-mentioned console command openhab:hue hue:bridge-api2:myname things, I will modify its output to include the ‘idV1’ also in the console output. I will post a new set of Jars shortly.

An example of the openhab:hue hue:bridge-api2:myname console command output is below. And the new Jars are in the usual place HERE

Bridge hue:bridge-api2:myname "Philips Hue Bridge" [ipAddress="192.168.1.108", applicationKey="1234567890abcdefghijklmnop"] {
    // Bridge home things
    Thing zone 11111111-2222-3333-4444-555555555555 "All lights" [resourceId="11111111-2222-3333-4444-555555555555"] // Zone idV1:/groups/0
    // Zone things
    Thing zone 11111111-2222-3333-4444-555555555555 "Downlights" [resourceId="11111111-2222-3333-4444-555555555555"] // Zone idV1:/groups/4
    ..
    // Room things
    Thing room 11111111-2222-3333-4444-555555555555 "Back Bedroom" [resourceId="11111111-2222-3333-4444-555555555555"] // Room idV1:/groups/3
    ..
    // Device things
    Thing device 11111111-2222-3333-4444-555555555555 "Aquarium Button" [resourceId="11111111-2222-3333-4444-555555555555"] // Hue Smart button idV1:/sensors/236
    ..
}

I have named my things using recognizable words such as spotTv1, but the currently generated thing is using resourceId as thing id

Idea: Whenever there is a V1 thing already defined, re-use the existing thing uid (last part after colon)

Example:

Existing thing definition (added stars for readability):
0220 **stueTv2** "TV spot 2" @ "TV" [ lightId="18" ]

Currently generated thing definition:
Thing device 160f8b94-555d-4972-962a-8b8fc4f23e6e "Stue TV spot 2" [resourceId="160f8b94-555d-4972-962a-8b8fc4f23e6e"] // Hue ambiance spot idV1:/lights/18

Suggested modified generated thing definition:

Thing device **stueTv2** "Stue TV spot 2" [resourceId="160f8b94-555d-4972-962a-8b8fc4f23e6e"]

With this modification I believe migration for users with thing- and item files would become a lot easier. Remaining task would be:

  1. Do a search/replace for item channel links
  2. Manually clean up existing group definitions (now zone and room)
  3. Manually clean up sensors (was 3 things, now 1)

WDYT?