HueBridgeHandler reporting null every minute

  • Platform information:
    • Hardware: RPI3 - ARMv7 Processor rev 4 (v7l)/976 MB/29777
    • OS: raspbian / VERSION=“10 (buster)”
    • Java Runtime Environment: openjdk version “1.8.0_222”
    • openHAB version: openhab-distro : 2.5.5
  • Issue of the topic:

Hello, I’m trying to expose two zwave switches, currently connected to a zwave Aeotec usb driver, to be controled by one Amazon Echo device. I also have a Hue bridge controlling other hue lights that are also working as expected either via voice commands from Amazon Echo or from Openhab.

I installed the binding Hue Emulation binding by following all the instructions from and after installation I can even see new “CLIP*” sensors from my existing lights reported in the inbox of the paper UI.

I’m also able to perform the troubleshooting section by testing the status http://openhab:8080/api/status where I can see the two lights I added to my items and/or checking description and query the two lights.

This an extract of the output for the status command:

Self test

To access any links you need be in pairing mode!

Pairing mode: On (V2) Enable | Enable with bridge V1 emulation

2 published lights (see
70 published sensors (see

UPnP discovery test


serial no name
5F461H160922 Roku 2
20100621 [TV] Living room
0017882d83e2 Philips hue (

But I think I’m missing something because the following messages are reported in the event and info logs approximately every 10 seconds.

2020-05-26 19:23:12.669 [WARN ] [ue.internal.handler.HueBridgeHandler] - An unexpected error occurred: null
java.lang.NullPointerException: null
at org.openhab.binding.hue.internal.handler.HueBridgeHandler$2.doConnectedRun( ~[bundleFile:?]
at org.openhab.binding.hue.internal.handler.HueBridgeHandler$ [bundleFile:?]
at java.util.concurrent.Executors$ [?:1.8.0_222]
at java.util.concurrent.FutureTask.runAndReset( [?:1.8.0_222]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301( [?:1.8.0_222]
at java.util.concurrent.ScheduledThreadPoolExecutor$ [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor$ [?:1.8.0_222]
at [?:1.8.0_222]
==> /var/log/openhab2/events.log <==
2020-05-26 19:23:12.715 [hingStatusInfoChangedEvent] - ‘hue:bridge:CEEA5244AB8B’ changed from ONLINE to OFFLINE: Hue bridge connection lost.
2020-05-26 19:23:12.726 [hingStatusInfoChangedEvent] - ‘hue:0840:CEEA5244AB8B:28’ changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2020-05-26 19:23:12.737 [hingStatusInfoChangedEvent] - ‘hue:0840:CEEA5244AB8B:54’ changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2020-05-26 19:23:12.790 [hingStatusInfoChangedEvent] - ‘hue:bridge:CEEA5244AB8B’ changed from OFFLINE: Hue bridge connection lost. to ONLINE
2020-05-26 19:23:12.809 [hingStatusInfoChangedEvent] - ‘hue:0840:CEEA5244AB8B:28’ changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2020-05-26 19:23:12.829 [hingStatusInfoChangedEvent] - ‘hue:0840:CEEA5244AB8B:54’ changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2020-05-26 19:23:13.159 [hingStatusInfoChangedEvent] - ‘hue:0100:1:BSMT_BULB_03’ changed from OFFLINE: Hue bridge reports light as not reachable. to ONLINE

Switch FF_SW_FR_1 “Family Room []” [“Lighting”] { channel=“zwave:device:d898ae3f:node3:switch_dimmer” }
Switch FF_SW_FY_1 “Foyer []” [“Lighting”] { channel=“zwave:device:d898ae3f:node5:switch_binary” }

Was this an OpenHAB upgrade? Is so you may have invalid addons configured causing all addons to reload every minute.

The Hue binding was enhanced by support for groups recently. I have the slight feeling that this new feature does not interact nicely with Hue emulation binding because the Hue emulation does not provide an REST endpoint for groups.

@Lolodomo @DerOetzi Can you have a look into this? What may be the best solution to solve this?

We should definitely consider this before merging the new scene feature for Hue binding.

1 Like

What do you think, should we add this to hue emulation for being more conform to hue api. Additonally I will try to make it null proof in my PR

Sorry I have not in mind that there was a dependency between the hue binding and another binding (the hue emulation binding), just because I never care about the hue emulation binding.

When adding the support of groups in the hue binding, I added a new field “state” on each group. This state is not set by the hue emulation and it leads to a NPE.
I wrote a comment in the code that this field is not set by the hue API but I think my comment is wrong and in fact the hue API is certainly providing a state for a group. If not, we will have the same NPE with the real hue bridge. I will check that. So first the comment has to be removed.
Second, the hue bridge handler should allow a null state field and create one if null. This will make the hue binding compatible with the hue emulation binding.

So I think the fix has to be done in the hue binding and I propose to do it myself.

PR created:

The fix is already merged.

Nice. Thanks for your quick action.

Thank you for the quick fix.

Since I’m new in Openhab, I’m not familiar yet with the whole process. How can I install the fix to see how my system behaves after applying it?