Aller au contenu principal

Flux de données

Cette page suit deux parcours de bout en bout : la consultation/état (web ↔ central) et la descente d'un ordre (web → central → node → matériel).

Consultation / état​

  1. Le frontend interroge venus en GraphQL.
  2. venus route vers saturn (inventaire/actions/dns) et mercure (logs).
  3. saturn lit PostgreSQL ; mercure lit/écrit Elasticsearch.
  4. venus assemble la réponse et la renvoie au web.

Descente d'un ordre​

  1. L'utilisateur déclenche une mutation GraphQL côté web.
  2. venus appelle saturn, qui enfile l'action puis la dispatch en HTTP vers l'API locale node (:8080).
  3. Le daemon applique l'ordre sur le GPIO (relais actif à l'état bas) et persiste.
  4. L'action est marquée sent ou failed côté central.

Ingestion des logs techniques node​

Chaque événement critique peut être corrélé au matériel grâce aux champs node_id, meta.machine_id et meta.mac.

Chemin alternatif : commande locale​

L'IHM Qt du node court-circuite le hub : elle envoie directement un POST à l'API locale (:8080), garantissant le contrôle même sans réseau.

Écran tactile → POST /relay/<id>/on → Daemon → GPIO

Persistance et redémarrage​

  • Chaque changement d'état de relais/compteur est écrit en SQLite (node.db).
  • Au démarrage, le daemon restaure l'état persisté : les relais retrouvent leur position, les compteurs leur valeur cumulée.
  • Le central persiste l'authentification et l'inventaire des nodes en PostgreSQL, et les logs techniques en Elasticsearch.