No meethue.com connectivity but no error message

[lnlyssg]

I restarted homebridge earlier today to find nothing showing up from homebridge-hue in HomeKit. The log showed no errors other than a lot less messages from homebridge-hue. After restarting homebridge with the -D option I spotted "[12/28/2016, 11:22:43 AM] [Hue] contacting meethue portal" in the log and then when I went and looked at my bridge spotted that the internet/meethue light was flashing merrily away. A quick reboot of my router got it all back working again, however would it be possible for the plugin to spit out an error message to the log when it can't get a response from meethue.com? It would have made it much easier to see what was wrong!

[ebaauw]

Homebridge-hue does report an error message when the communication with meethue.com fails. I suspect in your case homebridge-hue did actually get a valid response from meethue.com, albeit an empty response, as your bridge was no longer registered with meethue.com. I'll add a check for this in v0.1.16.

Please note that that's still a workaround. I fear you had to redo your HomeKit configuration (re-assigning homebridge-hue provided services to HomeKit rooms, scenes, rules, etc). I need to move to dynamic platform accessories (issue #4) to prevent that. Also implementing local UPnP discovery of bridges (issue #6) would create less of a dependency on meethue.com.

[lnlyssg]

Ah of course, https://www.meethue.com/api/nupnp gave me a [] when I went to it so it was indeed an empty response.

And yes, I did have to re-do the HomeKit config although I had thought this was because I set the host entry in my config to the hub's IP address before then undoing it after the router reboot.

[ebaauw]

No, unfortunately, HomeKit deletes the accessories from it's database when homebridge no longer provides them.
With dynamic platform accessories, homebridge persists accessories between restarts in ~/.homebridge/accessories/cachedAccessories. On startup, homebridge would provide the saved accessories to HomeKit and show them as unreachable, until homebridge-hue re-discovers the bridge. This would also be the structural solution to startup timing issues when using multiple plugins, see issue #26.

[ebaauw]

Implemented check in v0.1.6.