un petit mot techno web sur les
websockets. J'en ai entendu parler depuis longtemps et jamais eu l'occasion d'essayer. Et maintenant que j'y ai touché, je vois que c'est super simple à faire et super stable.
- En web traditionnel, c'est le client qui démarre chaque transaction, en général par un clic. Le serveur reçoit la requête http, prépare la page html et l'envoie au client qui l'affiche. La logique est dans le serveur. On peut mettre un peu de subtilité avec du javascript coté client mais le principe reste : c'est le client qui lance les débats.
C'est ce qui est fait sur Ampcontroller < 6.5
avantage : web standard simple, quasi tout est coté serveur donc simple à maintenir.
inconvénient : la page affichée ignore ce qui se passe coté serveur et elle affiche des données peut être périmées. Pour contourner, j'ai mis un auto-refresh régulier pour que le client se mette à jour (reload) mais il est quand même toujours en retard. Et si rien ne change, les auto-refresh systématiques créent du trafic http et de la charge serveur inutile.
- En 6.5 j'utilise les websockets, dans une configuration hybride.
Un websocket est un lien permanent établi entre un client et le serveur a la demande du client, en général dès que la page se charge. Le serveur peut recevoir des messages et aussi en envoyer.
En 6.5 quand quelque chose change sur la carte, un ordre de refresh est envoyé aux clients connectés qui rechargent alors la page.
avantage: la page web est a jour quasi instantanément, pas de trafic si rien ne change
Pourquoi hybride ? parce que je ne vais pas au bout du truc. Le serveur se contente d'envoyer l'ordre de refresh et la page se recharge alors intégralement (reload). C'est facile à faire car peu de javascript coté client mais ça coute toujours du trafic http et de la charge serveur.
Un effet secondaire: a chaque reload de la page, la connexion websocket est perdue/recréée. C'est pas grave en soi mais c'est pas le but en principe.
- Les websockets a plein potentiel
Se fait en maintenant la connexion et en échangeant des messages sans quitter la page.
Quand par exemple une température change, le serveur envoie au client par message la nouvelle température. Le javascript côté client analyse le message reçu et affiche la nouvelle température immédiatement. Pas de refresh global de la page, aucune transaction http, tout est hyper réactif.
Pourquoi je n'ai pas fait ? parce qu'il faut refaire toute la logique coté client en javascript. Bien que la page Home ait l'air simple, il y a pas mal d'informations et beaucoup de cas selon les seuils. Je n'ai pas eu le courage et puis l'ESP32 n'est pas débordé par les requêtes http de reload, donc pas indispensable de changer.
ps: si quelqu'un y voit une ressemblance avec mqtt, ce n'est pas fortuit

sur ESP32 j'ai entendu dire que l'implémentation de mqtt s'appuie sur les websockets.