feat: Add autodl for Hue (partial)

[Nerivec]

This is only for a small subset of devices (apparently the ones BT-capable).

CC: @mundschenk-at

[TheJulianJES]

I think there was already a discussion around this API a couple of years ago. It's a separate API from the images you get via the Hue Bridge for a reason.

This is the API used in the Hue mobile app, intended for lights directly connected to the phone via Bluetooth.

In the past, some images were pushed earlier (or I even believe some exclusively) via the mobile API compared to the Bridge API, until another revision was pushed out later via both APIs.
(But other images were only pushed months later compared to the Bridge API.)

So, at least in the past, the images may only have had Bluetooth-specific bug fixes and/or seem to have been (slightly) less tested than the ones provided via the Bridge API in a staggered rollout.

I would carefully consider if these updates should be provided to all Z2M users, with no testing, as soon as they show up via the mobile API, even if they're not pushed via the Bridge API to Hue users yet.

---

Also, I'd be cautious about redistributing unlicensed third-party binaries (with all rights reserved) in a GPLv3 licensed repo.
All my PRs only ever provided "official" links (with the binaries hosted directly by Signify), but since that's no longer possible, I stopped providing the updates sent via the Hue Bridge.

[Koenkk]

Maybe we should not put any license at all on this repo? Would that solve you concern? I'm not really worried about Signify, worst case we just remove the images.

[mundschenk-at]

Regarding the repo license, I'd just specify in the README that the license only applies to the tooling, not the firmware images. Maybe also add a separate LICENSE file to images and images1 that the binaries are not covered by GPL and copyrighted to the various manufacturers.

That IMHO is easily solvable. The other issue mentioned by @TheJulianJES is more of a liability issue for contributors. Uploading the OTA files is technically a copyright violation (if not done by the copyright holder themselves or allowed in a license). They might not care now, but who knows how they see things a few years down the line? (You as the author/maintainer of Z2M are probably in a better position to have nothing to fear legally than random contributors.)

A way to get around the distribution issue (for contributors) would be to add a workflow that adds URLs and metadata as before, and CI scripts then download and archive the OTA files in whatever way you deem necessary.

[TheJulianJES]

Always using version=0 here will give you old updates if intermediary updates are required, since you will always get a compatible image for version=0 per cid/type, which is always an old image.

[Nerivec]

The script is comparing actual versions in the list once fetched (sorting by version and picking latest).
Currently, there are no device with anything other than 1 update though, so I'm not sure how the intermediary updates work for Hue. I assume version limit if they followed spec? If using that scheme, it should be handled, since the update logic won't let an OTA file with a limitation be overridden, it will always keep both, which, in turn, should allow Z2M to update in the appropriate order.

[TheJulianJES]

The other scripts might handle this properly, but by always sending version=0, you won't fetch the newest firmware in the first place. As an example, say you send version=0 and get a firmware with version 1.
If you then send version=1, you might get another image with version 2 (which you did not get by sending ver=0).
This is why the parameter exists in the first place. The Hue mobile app always calls that with the currently installed version on the lamp.

So, the script would have to be updated to not only send 0, but also the latest known version number for that model, until no more updates are returned.

However, it seems like no intermediary updates are returned by the mobile API at the moment. I'm getting different results via the proper Hue Bridge AP, which is a bit weird...

[Nerivec]

From what I saw with the Hue bridge device ID, by sending version 0, you get all versions returned at once in the array. But yea, that's the only one that currently returns more than 1 firmware, so, it's more of an assumption.

[TheJulianJES]

Generally, only versions that can be installed from the current version are returned. For the OTA API used by the Hue Bridge, with older TI or ATmel-baed lights, you only get older firmware images until you increase version to the next image.

And the mobile API isn't used for updating the Bridge (anymore?) IIRC.
Using the Hue Bridge OTA API for querying images for BSB002 with version=0 returns the latest update and not the two older ones, so it seems like there are no required intermediary updates for the Bridge.
So, the two year old results that are included in BSB002 for the mobile API seem to be unintentional.

Btw., see your Discord DMs if you have some time.