Hue Binding Color Temp UNDEF and Slow updates

  • Platform information:
    • OS: Windows 10
    • Java Runtime Environment: Zulu 11.43.5
    • openHAB version: 3.0.0-M3

Hi All

I have noticed that when turning off my lights using the Hue Binding the Color Temperature item gets set to UNDEF. However the Brightness items gets set to 0%. Have checked via REST API and the actual state is UNDEF:

For Color Temp:

	
Response body
Download
{
  "link": "http://localhost:8080/rest/items/LoungeRoom_ColorTemperature",
  "state": "UNDEF",
  "stateDescription": {
    "minimum": 0,
    "maximum": 100,
    "pattern": "%.0f",
    "readOnly": false,
    "options": []
  },
  "editable": true,
  "type": "Dimmer",
  "name": "LoungeRoom_ColorTemperature",
  "label": "Lounge Room Color Temperature",
  "category": "ColorLight",
  "tags": [
    "Point"
  ],
  "groupNames": [
    "Lounge"
  ]
}

For Brightness:

Response body
Download
{
  "link": "http://localhost:8080/rest/items/LoungeRoom_Brightness",
  "state": "0",
  "stateDescription": {
    "minimum": 0,
    "maximum": 100,
    "pattern": "%d %%",
    "readOnly": false,
    "options": []
  },
  "editable": true,
  "type": "Dimmer",
  "name": "LoungeRoom_Brightness",
  "label": "Lounge Room Brightness",
  "category": "light",
  "tags": [
    "Point"
  ],
  "groupNames": [
    "Philipshue10163199253"
  ]
}

Both ITEMS have MIN and MAX of 0 and 100 (%).

I did try set the State Description Meta Data, but that did not help.

From what I understand the UNDEF could be as a result of loss of communication. Though this seems unlikely as the Brightness is always set correctly and the lights are responsive.

I also see that the is a long delay before the ITEM is updated when the lights are turned on again.

See the aminated GIF for example:

Light Widget

Not sure if this is a Binding issue or a local config issue?

Appreciate any advise.
Mark

Hi Mark,

At the time I implemented the feature it was the best option to set the color temperature to UNDEF if not available or the build was in a different color mode. This had changed over time and now we don not need to do that anymore. The color temperature value is present all the time in the API response if the Hue bridge. I submitted an improvement for it.

Thank you so much. Always appreciate the work.

Just to confirm, this will be included in the daily snapshots at some stage, and then in a M4 at a later date?

Would the .jar file be available to test before then?

Thansk
Mark

Once it is merged it will be available in nightly snapshot. Hopefully before ME. Currently I am testing the fix thus I can offer to hand over a *.jar file to you. But it will only work in snapshot builds because of recently changed dependencies in openHAB Core.

I am currently on 3.1.0.M3. But happy to try a SNAPSHOT to test.
So would a appreciate if you could share a jar file.

Thanks

1 Like

Here is a *.jar file with a fixed version: org.openhab.binding.hue-3.1.0-SNAPSHOT.txt (161.2 KB)

Please rename it from “.txt” to “.zip”, extract the “.jar” file and put it into your addons/folder. Uninstall any other binding version before.

1 Like

I see the fix is not listed for M4. Should the jar file work with M4?

The fix has not been merged yet. You can follow its status by subscription in GitHub. The provided *.jar file will work with milestone M4.

Hi

Gettting the following on 3.1.0.M4

13:38:39.550 [WARN ] [org.apache.felix.fileinstall         ] - Error while starting bundle: file:/C:/openHAB/addons/org.openhab.binding.hue-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.hue [263]
  Unresolved requirement: Import-Package: org.openhab.core.config.discovery.upnp

        at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.200.jar:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:440) ~[org.eclipse.osgi-3.16.200.jar:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.8]

Thanks
Mark

I saw this before. The framework sometimes does not install dependencies automatically when you put a binding into your addons/ folder.

First: You have to install the features via Karaf console and then put the .jar file into your addons/ folder.

The correct command is

feature:install openhab-transport-upnp

You can also install a different binding (e.g. avmfritz or Kodi) which requiresthis dependency too. This in turn installs the required service automatically.

1 Like

Up and running. Will test and let you know. But all seems good so far. Thank you.

Hi Christoph.

I have been battling with issue as follows:

At first I suspected that I was having an issue as I sometimes used Colour Temperature and Brightness, and then to display “Alarm” I was using HSB.

This does not seem to be the case though.

It looks like the _Color channel all goes to (0.0.0) when the lights (group from Hue Bridge) gets switched off - however when switched back on goes to the last settings.

Is there a way to access the _Color state when the light is off - so that it can be restored?

Is it better to the the Hue Bridge Groups, or create OH Groups of ligts?

Thank
Mark

Hi Mark,

I am afraid I cannot give you an answer in a second. I have to do some research and find out what the Hue REST API delivers while a bulb is off. I hope it is not urgent. Will put it into my to-do list.

Thanks Christoph.

Not Urgent, just my plan to implement a UPS alarm system. So any advise you can share would be appreciated. From what I can see the current state must be stored somewhere (on the hub?). As the lights are always restored to their previous setting if they are Turned on.

Any advise regarding OH Groups vs Hue Hub Groups?

No, I have not. I have to admit I never used OH groups for item type Color before. No idea how the states will be aggregated. I slightly tend to Hue groups because of the scene support and IIRC the is a very short delay between more than one command send to Hue API at the same time.

Hi,

I just tried V2 of the API and the issue is back. Is it possible, that the fix was only for V1?

I use openHAB 4.0.4

BR
Peter