[Feature Request] Automatic firmware update

[thkrmr]

There's currently a feature request listed for firmware update notifications, I would also like to also propose an automatic firmware update functionality.

If fully automatic updates without user intervention/supervision are a concern, I propose an alternative approach: Have the ability to upload the firmware, click update and trigger the update as soon as the vehicle has been unplugged.

My vehicle is plugged in at all times while I'm not driving. Updating while plugged in isn't possible, but remembering to trigger an update just before departure or immediately after arrival isn't convenient, I forget it oftentimes. If I were able to at least "schedule" an update upon next departure from the comfort of my home (instead of going to the garage, unplugging, updating, plugging in), that would be a great quality of life improvement.

[photron]

Duplicate of https://github.com/Tinkerforge/esp32-firmware/issues/88.

All points you're mentioning will be supported in one form or another. This is currently working progress.

[thkrmr]

@photron that's awesome.

Because my current solution would involve HomeAssistant, checking whether the Tesla is away from the garage, whether WARP2 reports unplugged, fetching the firmware version number deployed on the WARP2 with the info API endpoint, getting the listing for firmwares from GitHub, comparing, then curl POST'ing the newest firmware to the misc/flash_firmware endpoint... I think built in functionality for this would improve it for everyone, instead of a hacky one off solution for myself.

By the way https://github.com/Tinkerforge/warp-charger/blob/master/firmwares/warp2_firmware.txt uses '+' as delimiter, while the info endpoint uses '-' https://docs.warp-charger.com/docs/mqtt_http/api_reference/info, firmware filenames https://github.com/Tinkerforge/warp-charger/tree/master/firmwares use underscores '_'. Stitching the automation together requires a few string replacements, depending on how your implementation will materialize, you might want unify the naming across sources.

[photron]

2.4.0-66558ade is the old format. The documentation was not updated yet. It's fixed now. Thanks!

With the current release we switch to semantic versioning number format. There the build part is separated using a '+'. The auto update system will support three different update tracks: beta, release and stable. Before, we would post beta versions in the forum and do some tricks with the major.minor.patch format to represent the beta version number. Now with semantic versioning numbers we will just do it the right way: 2.5.0-beta.3+66759fde

The filenames will stay with '_'. With the new system you should never need to handle the filesnames. Even for external automation you should be able to do everthing using the wallbox API and semantic versioning numbers alone.

There will be a new API command to manually trigger a check for updates. The wallbox will do this periodically on its own, if you enabled update checking. There will be a new API state that reports the currently available updates as semantic versioning numbers. Then there will be another new API command to trigger an update to a given firmware by its semantic versioning number. The wallbox will automatically take care to postpone the update if a car is currently connected.

The new default configuration will be to fully auto-update from the stable track.

I think with the new system in place, you should not need to do any custom automation for this. The wallbox should just be able to do it all for you. Or am I missing something?

[thkrmr]

@photron It's sounds very thought out and would completely supersede my automations. Thank you for such a detailed response and all the great work you guys do!