Création de micro webUI

Une webUI (pour web User Interface - l'équivalent dans le brwser d'une GUI) est une interface graphique utilisée dans le navigateur. Pour dire les choses simplement, une webUI c'est un microsite web qui fournit une interface graphique permettant d'interagir avec la carte à microcontrôleur.

En général, une webUI ou webapp, c'est :

• du code html
• du code javascript
• des librairies diverses et variées
• des échanges entre l'interface et un serveur

Dans le cas d'un usage d'une carte micropython, typiquement wifi, la caractéristique clé, c'est que l'on =dispose d'un microserveur avec assez peu de possibilités, et il faut donc tout optimiser. En clair, on oublie les librairies javascipt au-delà de quelques dizaines de ko.

Différentes configurations

Le cas type : avec une carte micropython wifi avec micro-serveur intégral sur la carte

Dans ce cas, c'est simple, tout est sur la carte micropython

Carte micropythonwifi avec microserveur allégé sur la carte et librairies sur poste partagé du réseau local

Dans ce cas de figure, on ne met sur la carte micropython wifi uniquement les pages web propres de la webUI,

Quelles options pour le poste partagé ?

Typiquement, avec une grappe d'ESP, on va avoir un Raspberry Pi qui jouera le rôle de broker MQTT, fournira un tableau de bord Domoticz, et on pourra très logiquement mettre sur ce Rapsberry Pi les librairies js partagées entres tous les ESP locaux.

Mais plus simplement, on peut aussi simplement servir les librairies js sur le poste depuis lequel on accède au serveur. Ceci est valable si on est sur le même réseau local que l'ESP auquel on se connecte. Cette façon de faire a un avantage de sécurité : le microserveur ne fournit aucune page active si les libs ne sont pas servies depuis le poste local. Utile en usage "dév" disons.

Plus largement, le microserveur pourra aller chercher les librairies sur un CDN sur le web, mais cela suppose que le réseau local soit connecté au web. C'est à mon sens un point de faiblesse si on ne dispose pas localement des librairies utilisées : on est en dépendance de l'accès web, de la disponibilité des serveurs utilisés, etc.. et cela crée des latences. Cela crée d'autre part un problème de sécurité car cela veut dire que l'on expose en permanence au web la grappe d'ESP locaux. Mais c'est une possibilité, notamment en phase de test initial ou de développement.

Carte micropython sans interface réseau, sur port série (bridge local http-serial)

On peut être surpris de çà... mais c'est une possibilité que j'ai exploré dans un post séparé: en clair on fait un bridge local http-serial : les requetes du navigateurs sont envoyées à la carte micropython via le bridget et les réponses de la carte sont envoyées au navigateur.

L'intérêt de cette solution est aussi d'exposer la carte micropython sur le réseau local, voire web, mais surtout sur le réseau local et permet de se connecter à l'interface qu'elle sert.

Dans la mesure où l'on fait tourner le "bridge serial - http" sur le poste local auquel est connecté la carte micropython, on peut doser facilement ce que l'on met sur la carte micropython elle-même et ce que l'on met sur le poste local. Notamment les librairies peuvent être servies sur le poste local.

A part, un bridge wifi/serial

Dans ce cas de figure, on utilise la carte ESP comme "bridge" avec n'importe quelle carte finalement fonctionnant sur le port série.

Un exemple est ESP3D : https://github.com/luc-github/ESP3D Ce bridge est dédié I3D / CNC et permet en fait d'interfacer des requêtes reçues par wifi avec une carte connectée sur le port série. Il serait intéressant de regarder plus en détail ce que ce bridge reçoit sur le réseau / renvoie sur le port série, et il n'y a fondamentalement rien qui empêche de faire la même chose en micropython assez facilement.

ESP3D semble jouer le rôle d'un serveur en mode hotspot. Un rapide coup d'oeil au (gros) code, écrit en C, montre que le serveur utilise les sockets, supporte les websockets, seule communication à même de faire du bidirectionnel. Il est capable de servir ESP3D-WEBUI qui est en soi autonome, si ce n'est la gestion des requêtes.

Boite à idée, exemples d'interfaces webUI

ESP3D-WEBUI Ici, une webUI à la "pronterface" compatible pour l'ESP : https://github.com/luc-github/ESP3D-WEBUI Cette interface est prévue pour fonctionner à la base avec un bridge wifi/serial, appelé ESP3D : https://github.com/luc-github/ESP3D Ce bridge est dédié I3D / CNC et permet en fait d'interfacer des requêtes reçues par wifi avec une carte connectée sur le port série.

Ce qui est intéressant, c'est que c'est prévu pour tourner sur un ESP , servi par le firmware ESP 3D qui assure le transfert vers le port série et c'est donc assez léger quoique très complet. C'est probablement une excellente source d'inspiration tout en montrant ce qu'il est possible de faire, envisager en terme de webUI. En résumé, on peut aller assez loin !

Mode d'interaction entre la webUI et le code serveur micropython

2 grands modes sont possibles :

• synchrone = requete / reponse : ajax
• asynchrone = bidirectionnel "vrai" : websocket

Libs légères potentiellement intéressantes pour créer des micro webUI :

Smoothiecharts : http://smoothiecharts.org/ SegmentDisplay : http://www.3quarks.com/en/SegmentDisplay/

Alpline JS : https://github.com/alpinejs/alpine/