Openhab continiously loosing connection to HUE Bridge

Add-ons Bindings
4

Hi,

this happens because openhab is looking for a String “error” in the JSON response from the bridge to determine if pairing is necessary or not. Unfortunately it seems as if the normal hue API response was extended in the latest firmware release by some “errorcode” parameter. This now triggers the pairing mechanism in openHAB.

I will make a pull request to fix this issue later today.

1 Like
5

wonderful, thanks a lot @dominicdesu
Yo let us know when fixed and where we can download to test?

thanks

6

Hi Dominic,

this is good news. Thank you very much for picking this up so fast.

Regards,
Matt

7

Hi,
it’s a little bit more work than I initially thought. I am afraid I’ll need another day to finish this. Will let you know as soon as the pull request has been created :smile:

By the way, if your openHAB is already authorized, you don’t need to push the button even though the message is displayed in the log. It should still be working. The “bug” here is basically that the message is displayed even though it is not needed.

2 Likes
8

interresting o know that it’s just a “cosmetic” issue, thanks @dominicdesu

9

Pull request created: https://github.com/openhab/openhab/pull/3259/

10

and merged …

11

Running OH 1.7.1 and my Hue is not pairing after a restart of openHAB.

I am running Hue bridge firmware version 01028090.

Currently the only way to get it back to working is wait for the pairing messages to appear in the logs and then run to the closet. :frowning:

I should add that I have made some changes to my network (went from 192.168.178.x to 192.168.1.x) in the few weeks OH was down at my home.

Where are the tokens kept that tell OH that pairing was successful? Or is is the bridge that is causing this?

Update: It look like the pairing is kept in between restarts of the service, but is lost after a reboot of the server.

  1. sudo service openhab start
  2. tail -f /var/log/openhab/openhab.log
  3. wait for pairing message in log
  4. press pair button on bridge
  5. confirm that openHAB can change Hue lights
  6. sudo service openhab restart
  7. tail -f /var/log/openhab/openhab.log
  8. wait for pairing message in log
  9. don’t pair! wait until the last message has shown
  10. confirm that openHAB can still change Hue lights
  11. sudo reboot
  12. tail -f /var/log/openhab/openhab.log
  13. notice that the pairing messages appear again
  14. don’t pair! wait until the last message has shown
  15. confirm that openHAB can NO LONGER change Hue lights
12

@dominicdesu The Hue binding has lost its connection again. Any chance that this error can be fixed for 1.7.1?
@teichsta When will 1.8.0 be released? I like to only use apt-get for my updates.

A minute ago it said:

$ sudo apt-get update && sudo apt-get upgrade
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

:slight_smile:

13

@digineut, as 1.7.1 is already released, I doubt that any further changes can be added. Please also note that above pull request is not part of 1.7.1.
The behaviour you describe is quite mysterious. openHAB uses the hue secret configured in openhab.cfg and checks if a user with this secret is already authorized on the bridge. If not, is will ask you to press the pairing button. When pressed, the secret should be saved on the hue bridge, so that next time openHAB connects to the bridge, the authorization will be successful.
I assume you didn’t change the secret or reset the hue bridge when you rebooted the server?

14

I did neither. Do you know how to have the bridge forget a specific secret?

15

@digineut, you could also try if you can access the hue bridge from the browser next time openHAB tells you the bridge is not paired. Just use this link:
http://<bridgeIP>/api/<yourOpenHABsecret>/
If the link returns an error, it’s likely an issue with the bridge, if the link returns the state of your hue system, something with the binding does not work correctly.

Answering your question, you can delete a user the following way:
Go to: http://<bridgeIP>/debug/clip.html, insert the following as URL:
/api/<username>/config/whitelist/<username2> and select DELETE. This will delete username2 (More details on this here)

16

@dominicdesu Thanks.

I got tired of troubleshooting and eventually just changed my secret. Had to pair once more. Will wait to see if this has resolved the issue.

17

Too bad. I rebooted my server and lost the connection to the bridge once again.

18

I just set up OpenHAB 1.7.1 and paired it with my Hue bridge, and did indeed run into the same problem as the original poster; however it seems to be purely a cosmetic issue. All the Hue related things work just fine, even though the service keeps nagging about the button push.

19

I’m also experiencing the pairing issue after a openhab v1.7.1 service restart.

I can confirm that the log entry is not only cosmetic…

Whats the status for you guys?

20

Could you update to the latest nightly build of the hue binding, enable DEBUG or TRACE logging for the hue binding and post the logs when the issue happens again?

21

Thanks. I will do!

22

@dominicdesu Thanks! I can confirm that the pairing and polling issues has gone with the latest snapshot version of the hue binding :smiley:

No need to provide any logs, it was all looking good, only got the “Hue binding has started” message and event messages from communicating with the different lights :thumbsup:

1 Like
23

Not exactly the same topic but maybe this is related:
For any reason and without apparent pattern I have a long delay while sending a command to the Hue bridge via openhab.

Has anyone of you similiar problems or even a solution how to avoid this?

Thx & regards
John