Coin web de Frédéric Péters

Dans les dispositifs à la radio sur lesquels je n’ai pas encore écrit (d’après une rapide recherche) il y a « le switch », c’est l’appareil qui permet de déterminer quel studio est à l’antenne.

Il y avait un système avant 2013 dont je n’ai pas souvenir, j’ai juste retrouvé quelques traces, pas de photo, une courte notice d’utilisation, ça avait été mis en place en 2010, apparemment il y avait juste un levier, qui permettait de mettre le studio hors antenne quand dirigé vers le bas, et à l’antenne quand dirigé vers le haut, end of story. Et avant ça il n’y avait rien, la table de mix devait être tout le temps allumée et à l’antenne.

Bref 2013 et projet de second studio et pour accompagner ça un levier avec deux positions ça ne suffisait plus et on décide de s’embarquer dans la réalisation d’un nouveau système avec Arduino. J’écris "on" mais je ne fais qu’à peine suivre de loin.

Printemps/été/automne et octobre 2013 la mise en place; le levier a été remplacé par deux boutons-poussoirs et trois leds, le premier bouton pour faire la sélection, en passant successivement sur studio1/studio2/nonstop, en faisant clignoter les leds correspondantes, le deuxième bouton pour valider la position.

Tant qu’à être sur de l’Arduino, il y avait aussi eu idée d’embarquer une partie serveur HTTP, pour avoir la possibilité d’interroger l’état, et ça avait été fait et de mon côté j’avais branché ça sur du monitoring pour suivre dans le temps l’utilisation.

Bon an mal an ça tourne, il y a parfois à redémarrer manuellement après une coupure d’électricité, mais c’est vraiment exceptionnel, et ainsi fast forward jusque 2020 où tout ça a pris un certain âge et quelques pannes arrivent. Pas nécessairement directement liées au switch mais j’ai oublié de dire que les panneaux avec les boutons et leds, ils ont gardés d’autres fonctions de l’époque 2010, un levier pour couper l’électricité, un autre pour contrôler le mode d’un prémix micro, et ces pannes nous obligent à découvrir les détails de fonctionnement.

Aussi il arrive que des émissions laissent le studio 1 à l’antenne mais éteignent tout et ça fait du blanc à l’antenne et ça oblige quelqu’un·e à monter à la radio pour rebasculer sur le nonstop, quelques fois par an, jamais assez pour motiver à reprendre le code de l’arduino pour permettre la manipulation à distance.

On en et là et nouvelles pannes et cette fois ça semble l’arduino lui-même et pas de détection quand je le branche en USB, ce qui rend le debug plutôt impossible, mais on a un arduino en stock et c’est l’occasion d’y mettre le code que j’avais modifié pour gérer le POST pour le contrôle à distance (code qui existait mais était désactivé…) et c’est fait en janvier et ça tourne, mais l’âge continue à se faire sentir et c’est maintenant un des boutons en studio 2 qui ne fonctionne plus, ce qui y rend le switch tout à fait inopérant (d’où l’autocollant "HS" sur la photo).

Passion exploration et on démonte et on suit les fils, on multiplie les tests et a priori quelque part là-dedans il y a un contact qui ne se fait plus :

La photo illustre assez bien (?) la communication entre la partie Arduino en régie finale et les boutons/leds en façade dans les studios : des mètres de petits fils, et du pontage sur les fiches pour aller plus loin, schématisé à l’extrème ça donne :

régie finale ----- [ la photo ] ------------- studio 1
                        \--- studio 2            \--- leds supplémentaires

Il y a quelques moments de désespoir et je me dis qu’en attendant qu’on démêle tout ça, je pourrais au moins permettre via une page web le contrôle. Sauf que je suis assez frileux à l’idée de bombarder l’Arduino de requêtes, alors que j’aimerais quand même bien que l’affichage web reflète l’état en cours, pas celui d’il y a 5 secondes, ou 30, ou minutes.

Retour sur l’Arduino alors pour ajouter au code l’envoi d’un message UDP lors d’un changement de sélection, reçu, il permettra à un petit logiciel proxy de servir autant de requêtes que nécessaire, sans chauffer inutilement l’arduino.

Le code ajouté ressemble au final à peu près à ça :

#include <EthernetUdp.h>

[…]

EthernetUDP Udp;
IPAddress udp_remote_ip(192, 168, 17, 224);

[…]

  Udp.begin(1312);  /* init stack */

[…]

inline void notify_udp()  /* notify over UDP */
{
  char str_selection[20]; 
  snprintf(str_selection, 19, "{\"active\": %d}", activeSelection);
  Udp.beginPacket(udp_remote_ip, 1312);
  Udp.write(str_selection);
  Udp.endPacket();
}

C’est totalement bidon mais les exemples dans la documentation de l’API se concentrent tellement sur les fonctions individuelles que découvrir qu’il est nécessaire d’appeler Udp.begin() pour initialiser la stack n’était pas vraiment immédiat. (et le résultat un plantage au moment de l’appel à endPacket). (on verra aussi que je suis tellement rouillé du C que je ne prends pas de risque sur le deuxième paramètre passé à snprintf). (tout ça est également l’occasion de mettre en ligne le code, PanikSwitch)

De retour au mini-proxy, ça reste assez moche de bombarder comme ça l’API et la réponse à ça c’est d’utiliser WebSocket pour garder une connexion et uniquement l’utiliser quand il y a un changement.

Ainsi fut fait (modulo quelques détails, code ici) et tadam on a une page web qui affiche le statut « en temps réel » et permet de basculer de studio. Sur un clic sur un bouton ça fait l’appel au POST sur le serveur web de l’Arduino, qui envoie un paquet UDP, qui est attrapé et réémis sous forme de websocket, reçu par la page, qui peut alors changer la couleur du bouton.

Laissé ainsi ça amènera sans doute dans dix ans pour les suivant·es le même travail d’archéologie, et la même perplexité quant à la complexité de toute cette affaire. Au moins il y aura une explication écrite. Surtout d’ici dix ans la radio aura déménagé et ça aura été l’occasion de refaire tout ça, ce qui passera sans doute par une nette simplification.