A year ago, we announced a new tool for monitoring your systems based on Yoctopuce devices via the Internet, called VirtualHub for Web. This tool uses our HTTP callback mechanism to interact with modules, while offering a Web interface very similar to the usual YoctoHub or VirtualHub interface. The first version nevertheless had certain limitations, which we are gradually working to reduce...
An important feature of the YoctoHub and VirtualHub web interface is the ability to apply firmware updates. Indeed, from time to time, we do publish firmware updates for our modules, to add new features or correct errors. If you have the device at hand, applying new firmware is usually just a matter of a few clicks. But if the Yoctopuce device isn't directly accessible physically, or can't be reached directly via the network, it's another matter altogether.
In concrete terms, updating the firmware involves a meticulous, multi-step procedure: the firmware must be transferred to a buffer zone on the module (or on the hub hosting the module, as the case may be), the integrity of the transferred file checked, the module configuration saved, the module switched to a dedicated update program, the control recovered afterwards and the module's previous configuration reapplied. All these steps can't be performed by a simple HTTP callback, which is why we don't currently offer firmware updates via HTTP callback.
So we have worked to build into VirtualHub for Web a firmware update procedure which works iteratively, proceeding step by step through successive HTTP callbacks. For the user, there's almost no difference with the module's local Web interface: the firmware update is triggered identically, with just a few clicks.
However, instead of an immediate update, the new firmware file is saved on the server:
It's the VirtualHub for Web server that will carry out the various stages of the update. VirtualHub for Web's logs record the progress of the update:
16:12:21 New Yocto-Display firmware uploaded on YD128X32-FF306 (ver. 56254) 16:12:21 Scheduling firmware update for YD128X32-FF306 (autoflash) 16:12:31 YHUBWLN4-18784D Hub flash state is not yet available 16:12:31 YHUBWLN4-18784D Not yet ready to process firmware updates 16:12:39 YHUBWLN4-18784D Uploading new firmware for YD128X32-FF306 (autoflash) 16:12:48 YHUBWLN4-18784D Firmware update pending for YD128X32-FF306, postponing file synchronization 16:12:48 YHUBWLN4-18784D About to reboot YD128X32-FF306 for auto-flash 16:13:18 YHUBWLN4-18784D Restore settings for YD128X32-FF306 after firmware update 16:13:18 YHUBWLN4-18784D Firmware for YD128X32-FF306 changed from 51180 to 56254 16:13:18 YHUBWLN4-18784D File K2000.seq must be re-uploaded to YD128X32-FF306 after firmware update 16:13:18 YHUBWLN4-18784D Request for YD128X32-FF306: POST /upload.html (K2000.seq) 16:13:28 YHUBWLN4-18784D Firmware for YD128X32-FF306 changed from 51180 to 56254 16:13:28 YHUBWLN4-18784D Downloaded all UI files for YD128X32-FF306
To speed up the process, some update steps trigger an immediate reconnection of the HTTP callback, but this is not the case for all steps. If your hub is configured to make very few HTTP callbacks, it's probably a good idea to shorten the interval between HTTP callbacks before proceeding with the update, so you don't have to sit in limbo for hours. You can then reset them to the basic interval once the update is complete.
If you have activated settings to put the hub into deep sleep between HTTP callbacks and/or after a certain time, take care to deactivate these settings too before embarking on remote firmware updates, otherwise you may be in for some nasty surprises. The same applies if your system is battery-powered and in danger of running out of power: if the hub shuts down or goes to sleep in the middle of programming a module, you'll probably need to intervene on site to get the module back into service.
To be on the safe side, export the module settings from the console before launching an update, just in case something goes wrong. And be aware that, given the complexity of the process, we can't 100% rule out an incident where the update doesn't go entirely to plan, forcing you to intervene on site to bring the system back into service. So if your hub isn't very accessible, weigh up the benefits of upgrading against the risks before you take the plunge...
Limitations
At present, the VirtualHub for Web update process is intended for use via the Web interface only. The Yoctopuce libraries used to automate updates have not yet been adapted to take account of the deferred action of the update, and will therefore return an error message, even though they have triggered the update.
The update can be used for all modules connected to the VirtualHub or to a YoctoHub performing an HTTP callback to VirtualHub for Web, but not to update the YoctoHub itself. To enable this, we'll need to make one more small change to the YoctoHub firmware, which will follow shortly.
