HueBridgeHandler reporting null every minute

Setup, Configuration and Use Beginners
1
  • 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 https://www.openhab.org/addons/integrations/hueemulation/ 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 http://192.168.1.51:8080/api/testuser/lights)
70 published sensors (see http://192.168.1.51:8080/api/testuser/sensors)

UPnP discovery test

success

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

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(HueBridgeHandler.java:272) ~[bundleFile:?]
at org.openhab.binding.hue.internal.handler.HueBridgeHandler$PollingRunnable.run(HueBridgeHandler.java:121) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_222]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_222]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_222]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
at java.lang.Thread.run(Thread.java:748) [?: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

Items:
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” }

2

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

3

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
4

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 https://github.com/openhab/openhab-addons/pull/7518

5

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.

6

PR created:

7

The fix is already merged.

8

Nice. Thanks for your quick action.

9

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?