APEX #1 — Un automate qui fait tourner Docker, sérieux ?

Série ECLYPSE APEX — épisode 1/6

Vous connaissez ce moment où on vous tend un automate de GTB et où, au lieu de penser « chaufferie », vous pensez « tiens, et si je lui collais un serveur LoRaWAN dedans » ? Non ? Bon, c’est que vous êtes quelqu’un de raisonnable. Moi, pas trop.

L’ECLYPSE APEX de Distech Controls, c’est un automate CVC tout ce qu’il y a de plus sérieux… qui fait aussi tourner des conteneurs Docker. Oui, des vrais. Sur un rail DIN. Dans une armoire. À côté d’un disjoncteur.

Alors je vous préviens tout de suite : avec l’APEX, tout est possible. Enfin, presque. Tout est possible à condition de respecter ses limites matérielles, et c’est justement tout l’objet de ce premier épisode.

Tout est parti d’une frustration MQTT

Soyons honnêtes, je ne me suis pas lancé là-dedans par pur amour de Docker. Tout est parti d’un petit détail qui m’a rendu chèvre : les ECLYPSE embarquent bien du MQTT… mais uniquement en publication.

L’automate sait donc envoyer ses valeurs vers un broker, très bien. Par contre, s’abonner à un topic pour récupérer une température Zigbee ou une commande venue d’ailleurs, niet. C’est un peu comme avoir un téléphone qui peut appeler mais jamais décrocher. Tellement dommage, quand tout l’IoT du bâtiment parle justement MQTT.

Alors je me suis dit : si l’automate ne veut pas écouter, je vais lui coller quelqu’un qui écoute à sa place. Et sur l’APEX, ce quelqu’un peut vivre directement dans un conteneur.

L’APEX, c’est quoi au juste ?

C’est le haut de gamme de la famille ECLYPSE. Distech le présente comme un contrôleur « IoT Edge » qui ouvre un espace dédié aux développeurs IoT et IA. Traduction : un automate qui accepte qu’on le bidouille, officiellement.

L'automate Distech Controls ECLYPSE APEX : boîtier bleu sur rail DIN, voyants Power, Alarm et Status en façade — L'ECLYPSE APEX : un boîtier de rail DIN comme les autres, ou presque.

Caractéristique	ECLYPSE APEX
Processeur	Quad-core Cortex-A53 1,6 GHz (ARM64), annoncé 10× plus puissant que les ECLYPSE précédents
Mémoire	2 Go de RAM, environ 20 Go de stockage utilisable
Réseau	2 ports Ethernet 1 Gbit/s
E/S	Jusqu’à 320 points, soit 20 modules ECY d’extension
Protocoles	BACnet IP et MS/TP, Modbus RTU et TCP, M-Bus
Modbus	Jusqu’à 96 équipements (32 par bus)
Ouverture	API REST embarquée, conteneurs Docker, Azure IoT Edge
IA	Accélérateur TPU embarqué (absent de la version « Generation 1 »)
Sécurité	Secure boot et protections physiques anti-intrusion

La vraie différence avec un ECY-S1000 ou un 400/600, ce n’est pas le nombre de points. C’est le menu Conteneurisation dans Eclypse Facilities, où l’on importe des images et crée ses propres conteneurs. Et ça, mine de rien, ça change tout.

Tout est possible (ou presque)

Dès qu’un automate sait faire tourner Docker, il ne se contente plus de réguler une vanne trois voies. Il devient une petite passerelle qui parle à peu près toutes les langues du bâtiment. Sur mon APEX de test, voilà ce qui tourne aujourd’hui :

Mosquitto, le broker MQTT, qui sert de bus commun à tout le reste ;
Zigbee2MQTT, branché sur un coordinateur Ethernet, pour piloter des modules à 15 balles ;
ChirpStack, le serveur réseau LoRaWAN, pour les têtes thermostatiques et capteurs radio ;
Node-RED, qui fait le pont avec le programme EC-gfxProgram via l’API REST ;
Telegraf, InfluxDB et Grafana, pour avoir de jolies courbes sans toucher à la supervision.

Le point qui fait tilt : Node-RED sait créer tout seul des objets BACnet AV/BV dans l’APEX, à partir de ce qui remonte en Zigbee ou en LoRaWAN. Résultat, un module SONOFF devient un point BACnet comme un autre, visible depuis Niagara ou n’importe quelle supervision. Ça, c’est le grand festival de la fin de série.

Et là, je dois rendre à César ce qui est à César. Sylvain Montagny a fait un super boulot sur le sujet avec LoRaBAC, une application Node-RED open source qui fait le pont entre LoRaWAN et BACnet. Elle sait même écrire dans les automates Distech via leur API REST. On a travaillé sur des sujets très proches quasiment en même temps, chacun dans son coin : preuve que le besoin est bien réel ! Si la partie LoRaWAN vous intéresse, allez absolument jeter un œil à son travail.

Et c’est là que la boucle est bouclée : comme le MQTT de l’ECLYPSE ne sait que publier, c’est Node-RED qui fait l’oreille. Il s’abonne aux topics, puis il écrit les valeurs dans les objets BACnet de l’automate via l’API REST. Dans l’autre sens, il récupère les commandes du programme pour les renvoyer vers les équipements.

…à condition de respecter ses limites

Alors oui, c’est un automate costaud. Mais ce n’est pas un serveur Proxmox. Avant d’empiler les conteneurs comme des Kapla, voilà les murs sur lesquels je me suis cogné.

Limite	Ce que ça implique
2 Go de RAM (≈ 1,8 Go dispo)	Zigbee2MQTT seul prend 150 à 250 Mo. Avec InfluxDB, Grafana, Telegraf et Node-RED en parallèle, ça part vite.
Architecture ARM64	Il faut des images multi-arch. Certaines images `latest` sont x86 uniquement : vérifiez avant de tirer.
Politique d’administration (OPA)	Facilities refuse un conteneur dont la config sort des clous : ports, montages, cœur CPU attribué. Le message « administrative policy » sera votre nouveau meilleur ami.
Ports hôtes en 50xxx	Chaque service doit être publié sur un port de cette plage, et il faut tenir une table pour ne pas se marcher dessus.
Réseau entre conteneurs	Le plus fiable : passer par l’IP de l’APEX et le port publié.
Pas de passthrough USB	Pas de clé Zigbee USB : on prend un coordinateur Ethernet et on s’y connecte en TCP.
Pas de SSH, pas de compose	Chaque conteneur se décrit dans un JSON de création, et les logs se lisent via un volume.

Mon premier réflexe a été de tout mettre dans une seule image tout-en-un. Mauvaise idée : impossible à maintenir et à déboguer. L’architecture multi-conteneurs, un service par conteneur, est la seule qui tienne la route. On en reparle en détail à l’épisode 2.

Les règles du jeu avant de bidouiller

Je sais, vous avez déjà envie de lancer votre premier conteneur. Mais trois minutes de sérieux, parce qu’on parle d’un automate qui chauffe des bâtiments.

Jamais sur un APEX en production sans réfléchir. Tout ce que je montre tourne sur un APEX de test, sur mon bureau. Un conteneur qui sature la RAM, c’est la régulation qui trinque.
Fixez les versions des images. Un tag latest qui change en douce un lundi matin, c’est le meilleur moyen de passer la journée au téléphone.
Protégez vos volumes. C’est là que vivent vos données. Le volume de Zigbee2MQTT, par exemple, contient la clé réseau : le supprimer, c’est réappairer tous les équipements.
Rien d’exposé sans authentification. Les outils de dépannage du genre FileBrowser se coupent dès qu’on a fini.
Ce que je fais n’engage que moi. On reste dans les fonctions prévues par Distech, mais l’intégration de briques tierces, c’est votre responsabilité. Au moindre doute pour un site client, voyez avec votre contact Distech.

Le programme de la série

Un automate qui fait tourner Docker, sérieux ? — vous y êtes.
Les fondations — Docker sur l’APEX, le menu Conteneurisation, la politique OPA et Mosquitto.
Zigbee2MQTT — faire parler des modules à 15 balles avec une GTB pro.
ChirpStack — un serveur LoRaWAN dans l’armoire.
Node-RED et l’API REST, le grand festival — tout ce petit monde devient des points BACnet.
Bonus — Telegraf, InfluxDB et Grafana pour les amateurs de courbes.

Voilà pour les présentations. L’APEX n’est pas un jouet : c’est un automate de GTB qui a eu la bonne idée de s’ouvrir aux bidouilleurs. Tant qu’on respecte sa RAM, ses ports et ses règles, il encaisse à peu près tout ce qu’on lui donne.

Au prochain épisode, on ouvre le capot et on lance le premier conteneur. Préparez le café.