[Hue] Hue V2 API, what will be the impact for the binding?

The new V2 API is now available as early access:

I think there are some remarks that might be quite relevant to the openHab binding:

  • The V1 OAUTH2 (/oauth2) endpoint has been deprecated since July 2020 and will be disabled on short term – please double check that you are using the V2 OAUTH2 endpoint.
  • The V2 API does not support HTTP, but also for the V1 API it will be blocked
  • As per today, we deprecate UPnP as a local bridge discovery method, scheduled to be disabled in Q2 2022
  • The Philips Hue SDK will not be updated to support the V2 API as it has been deprecated since July 2019

Hi,

I also just saw this. So if V2 API work is started I would be willing to help as I was just looking through the code, as I was trying to find the cause of slow downs in processing on our system. (Split to 3 bridges for performance - but it’s still creaking now as I keep expanding it).

In regards to V2, HTTPS is enforced or will be (aka HTTP removed). Importantly from what I can see - if v2 is adjusted for / designed for it could significantly improve the performance. Unless I’m mistaken the current implementation get’s everything then pull’s the related data from what can be a rather large JSON response, to the relevant data points that have had channels linked. That’s probably the best way given the v1 API I’d guess.

In theory this new API on a quick look would allow for much more efficient polling. The motion sensing for example has been separated out, so that could be polled at a high frequency (and it returns only the data you need for sensor updates - so it would reduce & speed up processing work in OpenHab), while the power state of batteries could be polled at say daily interval’s after a startup poll, etc… (Reduce contention on any synchornized elements, etc…).

Discovery will have uPnP disabled with a switch to mDNS by the looks of it. mDNS is a usable possibly in OpenHab on a quick google, so it wouldn’t block discovery as such. I personally use IP based configuration, as my IOT equipment sit’s in a protected VLAN. I have not looked at the discovery code, so that maybe already using this or the uPnP they are shutting down?

The OAuth bits I believe relates to remote use of the API, as far as I’m aware the OpenHab binding uses an application key, for direct requests to the bridges, so its irrelevant in its use-case.

However importantly the API is very different, so the binding would need if its to be supported a bit of careful re-work. Everything is mapped by GUID’s now such the model of switch, and the device identification. In theory stuff could be migrated as until the switch over is done the old id based meta-data is still there “for now”. It does feel like after a second read a V2 version of the binding may be a more manageable approach however?

Either way it seem’s possible, and possibly like it could really improve the performance. I personally am a little worried as I have 500 rules at least across my devices, as they handle basic localised control with OpenHab driving CLIP sensors for higher level control of these flows, and it seems the rules are going to some scripting system. (That cant stand in the way of progress I guess however) :slight_smile:

Thats just my first take on a quick look at the developer doc’s anyhow.

I already started migration to v2 API here:

As explained in the PR I am planning to separate the implementation into three steps.

  1. Basic refactoring - in the linked PR

  2. Restore current behavior on v2 API - meaning new endpoints, new model - and keep v1 for users who own older Hue Bridges in the background

  3. Add handling of SSE

If you like to help you are welcome.

1 Like

Thanks Christoph, I’ll start looking through now to get up to speed.