Pour contrôler 2 leds, la réponse est automatique : il faut un Arduino. L'allumage de led est le "Hello world" de l'Arduino. L'Arduino est un micro-contrôleur open source conçu en Italie. Il est simple et rustique avec une vocation pédagogique. Il existe des clones et des variantes adapté à différent besoins, mais c'est surtout sa prise en main qui est exemplaire, autant du coté logiciel que matériel.
Comme moyen de communication entre l'Arduino et le reste du monde, nous avons choisi l'Ethernet. Ces câbles aux jolies couleurs et à la tête carrée fait partie de l'ADN de Bearstech. Il existe une carte Arduino Ethernet qui propose même le PoE, simplifiant ainsi le montage en faisant passer le courant et le réseau par le même câble.
Quand Arduino se dit micro-contrôleur, ce n'est pas une blague. Niveau puissance, on est plus proche du TO7-70 que du PC de tous les jours. Et pour le code, on a royalement 32 kilo octets. Kilo, pas mega ni giga ni encore moins tera comme on en prend l'habitude. On a l'impression de lacher son exosquelette pour aller chasser avec un silex. C'est rafraîchissant.
Donc, le réseau, c'est de l'IP fixe, le DHCP prenant trop de place, avec de la socket, l'HTTP, bien que possible est quand même surdimensionné. Sommes-nous condamnés à bricoler avec du Telnet?
En fait, comme souvent, notre problématique existe en dehors du domaine pointu des yeux de nounours qui s'allument. Les musiciens et les gens qui organisent des spectacles sur scène ont des soucis similaires, et ils ont eut le temps de réfléchir et d'affiner des outils pour connecter des objets. L'internet des objets est balbutiants, mais il a déjà un ancêtre très vaillant : Opens Sound Control. OSC pour les intimes.
OSC permet de connecter des appareils simples en réseau et de leur permettre de s'envoyer des informations concises avec de très faibles latences. On peut voir OSC comme une évolution réseau de la norme MIDI, mais c'est un peu réducteur. OSC est utilisé dans des logiciels de 3D par exemple, comme Blender, qui a peu de ressemblances avec un outil pour faire de la musique. La page de Wikipedia donne une bonne vision des outils gérants cette norme ainsi que le matériel disponible.
OSC est une norme très simple. La communication se fait en UDP, avec des messages sérialisé de manière simple, s'adressant à une pseudo url. Le message contient les informations sur l'expéditeur, permettant ainsi de lui répondre (on est dans modèle carte postale, pour répondre on envoie à son tour une carte à l'expéditeur, plutôt que sur le modèle du téléphone, qui établit un lien bidirectionnel). On a un protocole concis, fortement asynchrone, prévu pour fonctionner dans un environnement de confiance. HTTP ne sera jamais maître du monde entier.
Arduino propose différentes bibliothèques pour gérer OSC, et cela semble être une tradition, il y a des produits qui ne compile plus sur les versions récentes du logiciel. C'est un peu pénible, sur le principe, mais Z_OSC fonctionne simplement sur un Arduino de 2012.
Pour discuter, il faut être deux. Arduino a donc besoin d'un ami. A Bearstech, l'ami à tout faire est Python. En plus des bindings sur des logiciels pro pour musiciens angoissés par la moindre latence, il existe une version en pure python, pyosc, en beta depuis des années, mais qui fonctionne à peine sortie de la boite, avec d'abondants commentaires dans le code pour savoir comment l'utiliser. Il est donc assez trivial de faire un serveur qui affiche tout ce qui passe pour se rendre compte des capacités d'un émetteur, puis ensuite de faire un client qui envoie des messages voulus.
Pour valider le coté norme, le plus sage est d'utiliser un outil prévu pour un utilisateur, et non un tas de code pour un geek. TouchOSC, sur iPhone et iPad est un très joli jouet permettant de créer des tableaux remplis de tirettes, de molettes, de plaquettes et de boutons. On est plus dans l'opensource, mais il est juste là pour faire des démos qui impressionnent. De toutes façons, le contrôle du nounours sera fait par Maa, avec ses outils peaufinés avec amours depuis des années. On expose de l'OSC, il le branchera sur son outil, sans que personne n'ait besoin de debuguer le code de l'autre.
Le plus brimant dans le développement d'application pour Arduino n'est pas la taille (processeur, mémoire, stockage) mais le coté séquentiel obligatoire. Il n'y a qu'un seul chemin, et quand quelqu'un attends, tout le monde attends. Depuis la fin du DOS, ça n'existe plus en informatique traditionnel. Donc, là, quand on attends un message OSC pour savoir quoi allumer, tout se fige, pas moyen de faire clignoter la loupiote. Il n'y a qu'une seul voie. Cette contrainte n'est pas si affreuse que ça, il ne faut pas réfléchir informatique comme outil versatile pouvant tout faire, mais optimisation et spécialisation pour obtenir des résultats bien meilleur. Un Arduino pour allumer deux leds aura un coût d'achat (et de de développement) ainsi qu'une consommation éléctrique et une faible émission de chaleur sans commune mesure avec n'importe quel outil de type petit ordinateur. C'est le paradoxe du couteau suisse.
La solution est simple. Plutôt que d'attendre un message binaire, allumer/éteindre, et de gérer une fluctuation gracieuse de la luminosité, comme la respiration d'un MacBook qui dort, il faut juste se concentrer sur ce que l'on sait bien faire, et d'attendre comme message une valeur entre en 0 et 1, pour allumer la led de manière fine, et de laisser les effets de variations au client.