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)
Thats just my first take on a quick look at the developer doc’s anyhow.