Il y a une année, nous vous annoncions un nouvel outil permettant de surveiller via Internet vos systèmes à base de modules Yoctopuce, nommé VirtualHub for Web. Cet outil utilise notre mécanisme de callbacks HTTP pour intéragir avec les modules, tout en offrant une interface Web très similaire à l'interface habituelle d'un YoctoHub ou du VirtualHub. La première version avait néanmoins certaines limitations, que nous travaillons à réduire progressivelement...
Une fonction importante de l'interface Web des YoctoHub et de VirtualHub est la possibilité de mettre à jour le firmware des modules. En effet, nous publions régulièrement des mises à jour des firmwares de nos modules, pour y ajouter de nouvelles fonctionalités ou corriger des erreurs. Lorsque vous avez le module à portée de main, l'application d'un nouveau firmware n'est en principe question que de quelques clics. Mais si le module n'est pas directement accessible physiquement, ni atteignable en direct par le réseau, c'est une autre paire de manche.
Concrètement, la mise à jour du firmware implique une procédure minutieuse en plusieurs étapes: il faut transférer le firmware dans une zone tampon sur le module (ou sur le hub qui héberge le module selon les cas), vérifier l'intégrité du fichier transféré, sauvegarder la configuration du module, basculer le module dans un programme de mise à jour dédié, récupérer le contrôle après-coup et réappliquer la configuration préalable du module. Toutes ces étapes ne peuvent être faites lors d'un simple callback HTTP, et c'est la raison pour laquelle nous ne proposions pour l'instant pas de mise à jour de firmware par callback HTTP.
Nous avons donc entrepris de doter VirtualHub for Web d'une fonction de mise à jour de firmware, qui fonctionne itérativement, en procédant étape par étape lors de callbacks HTTP successifs. Pour l'utilisateur, il n'y a presque pas de différence avec l'interface Web locale du module: la mise à jour de firmware se déclenche à l'identique, en quelques clics.
Par contre, à la place de donner lieu à une mise à jour immédiate, le fichier du nouveau firmware est sauvegardée sur le serveur:
C'est le serveur VirtualHub for Web qui va procéder aux différentes étapes de la mise à jour. On retrouvera dans les logs de VirtualHub for Web les traces de la progression de la mise à jour:
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
Pour accélérer le processus, certaines étapes de la mise à jour déclenchent une reconnexion immédiate du callback HTTP, mais ce n'est pas le cas pour toutes les étapes. Si votre hub est configuré pour ne faire que très peu de callbacks HTTP, c'est probablement une bonne idée de raccourcir l'intervalle entre les callbacks HTTP avant de procéder à la mise à jour, pour ne pas devoir rester dans l'incertitude durant des heures. Vous pourrez les remettre à l'intervalle de base une fois la mise à jour terminée.
Si vous avez activé des réglages pour mettre le hub en sommeil profond entre les callbacks HTTP et/ou après un certain temps, prenez soin de désactiver aussi ces réglages avant de vous lancer dans des mises à jour de firmware à distance, sinon vous risquez d'avoir des mauvaises surprises. Même remarque si votre système est alimenté sur batterie et risque d'arriver en panne de courant: si le hub s'éteint ou part en sommeil au milieu de la programmation d'un module, vous aurez probablement besoin d'intervenir sur place pour remettre le module en service.
Par sécurité, prenez soin aussi d'exporter les réglages du module depuis la console avant de lancer une mise à jour, au cas où un incident se produirait malgré tout. Et soyez conscient que vu la complexité du processus, nous ne pouvons pas exclure à 100% un incident où la mise à jour ne se passerait pas entièrement comme prévu, et qui vous forcerait à intervenir sur place pour remettre le système en service. Donc si votre hub n'est pas très accessible, avant de vous y lancer, pesez bien l'intérêt de la mise à jour par rapport au risque...
Limitations
A l'heure actuelle, le processus de mise à jour à travers VirtualHub for Web est destiné à être utilisé que depuis l'interface Web. Les librairies Yoctopuce qui permettent d'automatiser les mises à jour n'ont pas encore été adaptées pour tenir compte de l'action différée de la mise à jour, et retourneront donc un message d'erreur, tout en ayant déclenché la mise à jour.
La mise à jour est utilisable pour tous les modules connectés au VirtualHub ou à un YoctoHub effectuant un callback HTTP vers VirtualHub for Web, mais pas pour mettre à jour le YoctoHub lui-même. Pour permettre cela, nous devrons apporter encore un petit changement au firmware des YoctoHubs, qui suivra prochainement.
