OS — Vue d'ensemble

leukOS livre une image Linux embarquée minimale et déterministe, construite avec Buildroot. Elle embarque le daemon du node, l'IHM Qt, le broker MQTT et, si besoin, le service domotic local — le tout prêt à flasher sur carte SD.

Daemon C++

Le daemon C++ est le cœur d'exécution du node leukOS. Lancé automatiquement au démarrage, il coordonne les composants matériels et exécute la logique d'automatisation localement. Le node reste ainsi opérationnel même lorsque la connexion au central est interrompue.

La classe Node orchestre ces sous-systèmes et leur fournit une surface de commande commune. Le daemon forme ainsi la couche d'exécution entre le matériel, les services locaux de l'OS et la supervision centrale.

Consulter la documentation détaillée du daemon C++ →

• Pilotage matériel : accès aux GPIO, relais, vannes, compteurs et microcontrôleurs raccordés au node.

• Boucle de contrôle : lecture des entrées, exécution des planifications, fermeture de sécurité des vannes et publication régulière de l'état du node.

• Fiabilité locale : persistance SQLite des états et des compteurs, restauration après redémarrage et surveillance par watchdog.

• Communication : commandes et remontées d'état via MQTT, API HTTP et gRPC, avec un fonctionnement dégradé possible hors ligne.

• Sécurité et extension : onboarding sécurisé des devices et pont vers les cartes ESP32, Arduino, STM32 ou RP2040.

Watchdog

Le watchdog protège le node contre les blocages du daemon ou du système. Il fonctionne indépendamment du réseau et du central afin de maintenir la disponibilité de l'automate sur le terrain.

Cette protection complète la persistance SQLite : après un redémarrage de sécurité, le daemon recharge les derniers états connus et reprend son cycle de contrôle local.

Consulter la documentation détaillée du watchdog →

• Activation : au démarrage, le daemon ouvre le périphérique Linux /dev/watchdog et configure son délai d'expiration, fixé à 15 secondes par défaut.

• Réarmement : la boucle principale nourrit régulièrement le watchdog. Tant que le daemon fonctionne correctement, le compteur ne peut pas atteindre son expiration.

• Récupération automatique : si la boucle se bloque ou si le processus ne répond plus, le réarmement s'arrête et le noyau redémarre automatiquement le node.

• Arrêt maîtrisé : lors d'un arrêt normal, le daemon désarme le watchdog avant de fermer le périphérique afin d'éviter un redémarrage inutile.

• Mode dégradé : si aucun watchdog matériel n'est disponible, leukOS journalise l'indisponibilité et poursuit son fonctionnement avec le heartbeat logiciel.

Client Kafka

Le client Kafka connecte les services de la plateforme centrale à un bus d'événements asynchrone. Il sépare la production des données de leur traitement : un service peut publier rapidement un événement sans attendre que son consommateur l'indexe ou l'affiche.

Cette couche transforme les événements temps réel en un flux durable et exploitable par l'observabilité, la supervision et les services de stockage de leukOS.

Pipeline de logs Kafka → · Flotte et santé des services →

• Pipeline de logs : les événements reçus par Mercure sont publiés dans le topic leukos-node-logs, puis consommés et indexés dans Elasticsearch.

• Santé de la plateforme : Saturn, Venus, Mercure et le service DNS/DHCP publient périodiquement leur état dans leukos-health-state. Mercure agrège ces messages pour alimenter la vue de flotte.

• Absorption des pics : Kafka joue le rôle de tampon lorsque le volume d'événements augmente ou qu'un consommateur ralentit.

• Résilience : les clients surveillent leur connexion, retentent les publications et permettent aux consommateurs de reprendre le traitement après une interruption.

• Découplage : Kafka transporte la télémétrie centrale mais n'intervient pas dans la boucle de contrôle locale. Le daemon et le watchdog continuent donc de fonctionner sans dépendre du broker.

Device Bridge

Le Device Bridge relie le daemon leukOS aux microcontrôleurs et cartes d'extension connectés au node. Il fournit une couche commune au-dessus des ports série afin que le reste du système puisse superviser ces équipements sans dépendre de leur protocole matériel.

Intégré à la boucle du Node, le bridge complète l'accès GPIO local et étend leukOS vers des capteurs, actionneurs ou cartes spécialisées. Une défaillance d'un plugin reste isolée et n'empêche pas le daemon de poursuivre ses autres fonctions.

Consulter la documentation détaillée du Device Bridge →

• Plugins matériels : profils configurables pour Arduino, ESP32, ESP8266, STM32 et RP2040 avec port, débit et état d'activation.

• Détection périodique : chaque plugin activé est sondé à un intervalle configurable, fixé à 15 secondes par défaut.

• Heartbeat série : le bridge peut envoyer une commande de présence et contrôler la réponse attendue avant de déclarer la carte connectée.

• Données et commandes : les échantillons série sont conservés, les métriques au format clé=valeur sont extraites et des messages texte peuvent être envoyés à un plugin précis.

• Supervision : l'état de connexion, le dernier contact, les mesures et les erreurs sont intégrés au statut JSON et aux logs du node.

IHM Qt

L'IHM Qt est l'interface tactile locale du node leukOS. Développée avec Qt6 et QML, elle affiche l'état des équipements et permet à l'utilisateur de les piloter directement depuis l'écran du boîtier.

L'application reste un client de l'API REST locale : la logique métier, les règles de sécurité et les états de référence demeurent dans le daemon. Elle fonctionne en plein écran sur le framebuffer Linux, sans serveur graphique intermédiaire.

Consulter la documentation détaillée de l'IHM Qt →

• Interface tactile : écrans QML dédiés au tableau de bord, à la domotique, à la configuration et au diagnostic du node.

• État en temps réel : le NodeClient interroge GET /status toutes les secondes et expose les données aux composants QML.

• Commandes locales : les actions tactiles sont traduites en requêtes REST pour piloter les relais, ouvrir ou fermer les vannes et définir leur durée d'ouverture.

• Affichage embarqué : l'IHM cible un écran 5 pouces 800 × 480 et utilise QT_QPA_PLATFORM=linuxfb pour dessiner directement sur le framebuffer.

• Démarrage maîtrisé : le binaire leukos-ui est lancé après le daemon afin que l'API et le contrôle matériel soient disponibles avant l'interface.

Web IHM — Go, Home Assistant et Vue.js

La Web IHM fournit une interface locale accessible depuis un navigateur. Son backend Go, leukos-hub, reprend le modèle de fonctionnement de Home Assistant — états, événements, services et automatisations — et l'adapte à l'architecture leukOS.

Le frontend Vue.js 3 consomme les API du hub pour afficher les pièces, les équipements et leurs états. Cette couche reste locale au node et complète l'IHM Qt avec une expérience web utilisable depuis un ordinateur, une tablette ou un téléphone du même réseau.

Voir la place de la Web IHM dans l'architecture →

• Moteur Go : le hub maintient le registre des entités, leurs états, les événements, les appels de services et les règles d'automatisation.

• Modèle Home Assistant : les automatisations utilisent des déclencheurs, conditions et actions, tandis que MQTT Discovery facilite la publication et la découverte des équipements compatibles.

• Interface Vue.js : les vues couvrent le tableau de bord, les pièces, les devices, les entités, les automatisations, les réglages et l'historique des opérations.

• API locale : le hub expose ses ressources en HTTP et sert directement la SPA Vue, y compris les routes de navigation côté navigateur.

• Persistance et accès : les états et l'authentification sont stockés localement dans SQLite, avec une configuration OAuth possible pour sécuriser l'accès à l'interface.

Pourquoi Buildroot ?

• Minimalisme : uniquement les paquets nécessaires, empreinte réduite.
• Déterminisme : image reproductible, idéale pour un automate.
• Contrôle total : chaîne de compilation croisée, init léger (BusyBox / SysV).
• Démarrage rapide et surface d'attaque limitée.

Arbre externe Buildroot (BR2_EXTERNAL)

Le dossier nodes/os est un arbre externe Buildroot nommé LEUKOS :

nodes/os/
├── external.desc          # name: LEUKOS
├── external.mk            # inclut les .mk des paquets
├── Config.in              # menu Kconfig des paquets leukOS
├── configs/               # defconfigs par plateforme
│   ├── leukos_rpi02w_defconfig    (défaut : Pi Zero 2 W)
│   ├── leukos_rpi3bplus_defconfig
│   ├── leukos_rpi4_defconfig
│   ├── leukos_rpi5_defconfig
│   ├── leukos_intel_nuc_defconfig
│   ├── leukos_amd64_defconfig
│   └── leukos_arm64_defconfig
├── package/
│   ├── leukos-node/       # paquet du daemon C++
│   └── leukos-ui/         # paquet de l'IHM Qt
└── board/leukos/rpi/      # fichiers spécifiques carte (voir Boot & init)

Contenu de l'image

Sortie de build

L'image finale est produite dans :

.build/buildroot/output/images/openautomation.img

Elle contient une partition FAT32 de boot (64 Mo) et une partition racine ext4.

Pour aller plus loin

• Composants de l'OS — paquets, overlay et configuration.
• Compilation — construire l'image de bout en bout.
• Boot & init — séquence de démarrage des services.
• Commandes workspace — toutes les commandes unifiées du package.json racine.
• Config & Infra Generator — workflow YAML pour les .env et génération infra multi-cible.
• WireGuard — activer et exploiter le VPN embarqué.