What's the status of the firmware API? I tried looking through the PR requests but couldn't quite figure out if it's ready to go. I started looking through the code but seems there may still be issues with it (some of the javadoc doesn't match with the method implementations, etc) plus I have a few questions on the implementation (something like why the firmware is tied to the thingtype rather than a thing [which I need at a thing level]).
I would consider the Firmware API as ready to use / implement (of course there might be changes in the future). Additionally I am aware of that there are also two open PRs for the Firmware API. They are still on my todo list to be finalized.
> why the firmware is tied to the thingtype
Actually the firmware of a device is updated by a proper implementation of the FirmwareUpdateHandler which is related to a thing. Only the provisioning of the firmwares depends on thing types which met our requirements very well. Our assumption was that we require only one firmware image in the system for a dedicated thing type (btw, the API supports model restriction).
Pls feel free to create also issues (or even PRs) for the incorrect javadoc. I think I would understand your concerns better if you share some more information of your "personal" firmware update idea. I am also aware of that the current API does not fit perfect to updates triggered by an API / executed via cloud (like Hue). I am happy to dicuss possible enhancements with you
When I look through it again, I'll document and create an issue for the javadoc errors. My time is stretched too thinly right now (with openHAB stuff) to submit PR on ESH (although I'd love to find the time to implement a few of them that are bugging me [like ExtendedDiscovery for PNP/MDNS participants]).
A reference implementation would be great to have - I know one of the PRs (can't remember which) has already asked for that however.
The provisioning of the firmware is what is going to stop me from being able to use this as the Firmware class is produced at a ThingType level rather than a Thing level.
Here's the use case I have:
NEEO Brain and Remote - I do NOT have access to the firmware directly but indirectly through it's API (I can check for a new firmware, I can determine if there is a new firmware and I can start/stop a firmware update and get progress indications during the firmware update). All that seems to fit nicely with the FirmwareUpdateHandler.
However, what firmwares are available are dependent upon the account/setup on the brain (some device may be setup to get only stable firmware, others beta firmware, others alpha firmware).
Because of all that - what firmware is based on the thing itself - not the thingtype.
Based on my limited knowledge so far on the firmware api - doesn't seem like I can implement it because of that one point (the rest of it seems to work for me).
Please correct me if I'm wrong on those assumptions
I fully understand your problem. We have exactly the same issue for the Hue Binding so that we havent yet published any firmware updates for Hue bridges / bulbs. Let me think about how we can integrate this concept into the current API.