IoT & Web : Créez un moniteur de feux tricolores avec Zephyr OS, Next.js et WebSocket

Dans un monde où l'IoT et le web convergent de plus en plus, la capacité à créer des interfaces de monitoring en temps réel devient cruciale. À travers ce tutoriel pratique, nous allons explorer la création d'un système complet de surveillance de feux tricolores, combinant la puissance de Zephyr OS pour l'IoT avec les technologies web modernes. Ce projet servira d'exemple concret pour comprendre les enjeux et les solutions du monitoring IoT en temps réel.

Note : En tant qu'expert Zephyr OS, je suis disponible pour vous accompagner dans vos projets de développement IoT. N'hésitez pas à me contacter par email ou sur LinkedIn ou encore via GitHub pour toute question sur Zephyr OS ou pour discuter de vos besoins en développement embarqué.

Le code source complet de ce projet est disponible sur GitHub.

Plan de l'Article

1. Vue d'ensemble du projet

   • Architecture globale
   • Technologies utilisées
   • Objectifs pédagogiques

2. Partie IoT : Contrôleur de feux tricolores

   • Introduction à Zephyr OS
   • Implémentation du contrôleur en C++
   • Communication avec le serveur

3. Backend : Serveurs et Communication

   • API HTTP avec Bun
   • Serveur WebSocket pour le temps réel
   • Gestion des états avec Redis

4. Frontend : Interface de monitoring

   • Construction avec Next.js 15
   • Composants React temps réel
   • Gestion de l'état et des mises à jour

5. Infrastructure et Déploiement

   • Configuration Docker
   • Scripts de développement
   • Déploiement en production

6. Pour aller plus loin

   • Tests et Qualité
   • Monitoring et Observabilité
   • Améliorations Fonctionnelles

Introduction

Le monitoring d'appareils IoT en temps réel présente des défis uniques, allant de la gestion des états à la communication bidirectionnelle. Notre projet de feux tricolores connectés illustre parfaitement ces problématiques : comment assurer une synchronisation fiable entre des appareils physiques et une interface web, tout en maintenant des performances optimales ?

Objectifs du Projet

Ce projet pédagogique vise à :

• Démontrer l'intégration entre IoT et technologies web modernes
• Explorer les patterns de communication temps réel
• Mettre en pratique les bonnes pratiques de développement full-stack
• Comprendre les enjeux de la supervision IoT

Architecture Globale

Notre système s'articule autour de quatre composants principaux :

1. Contrôleur IoT : Développé avec Zephyr OS en C++, il simule un contrôleur de feux tricolores
2. API Gateway : Serveur HTTP pour la communication avec le contrôleur
3. Serveur WebSocket : Assure la diffusion en temps réel des changements d'état
4. Interface Web : Application Next.js pour la visualisation et le contrôle

Note importante sur la simulation : Dans ce projet, nous simulons le périphérique IoT dans un container Docker pour des raisons pédagogiques. Le contrôleur se contente de logger les changements d'état. Dans un déploiement réel, ce contrôleur serait installé sur un véritable périphérique IoT (comme une Raspberry Pi Pico) et piloterait physiquement les feux tricolores via ses GPIO.

Exemple avec Raspberry Pi Pico

La Raspberry Pi Pico est un excellent choix pour implémenter ce projet en conditions réelles car :

• Elle supporte officiellement Zephyr OS
• Elle dispose de GPIO pour contrôler les LED des feux
• Elle peut être connectée au réseau via différents modules de communication longue portée (LoRaWAN, NB-IoT, LTE-M) adaptés aux déploiements extérieurs
• Son coût est très abordable (environ 5€)

Pour passer de notre simulation à un déploiement réel, il faudrait :

1. Remplacer les logs par des commandes GPIO
2. Adapter la configuration réseau pour le WiFi ou les modules de communication longue portée (LoRaWAN, NB-IoT, LTE-M) selon le contexte de déploiement
3. Gérer l'alimentation et la résilience
4. Ajouter un boîtier de protection

1. Vue d'ensemble du projet

Architecture globale

Notre système de monitoring de feux tricolores repose sur une architecture distribuée moderne, conçue pour assurer une communication temps réel fiable entre les appareils IoT et l'interface utilisateur.

Flux de données

1. Niveau IoT

   • Les contrôleurs de feux tricolores, basés sur Zephyr OS, gèrent l'état des feux
   • Dans notre implémentation, les changements d'état sont transmis via HTTP à l'API Gateway, mais d'autres protocoles auraient pu être utilisés :
     • MQTT pour une communication plus légère et optimisée IoT
     • CoAP pour les réseaux contraints
     • LoRaWAN pour la communication longue portée
     • gRPC pour des performances accrues
   • Les contrôleurs maintiennent une connexion robuste avec le serveur

2. Niveau Backend

   • L'API Gateway reçoit les mises à jour et les stocke dans Redis
   • Redis agit comme un store d'état centralisé
   • Le serveur WebSocket s'abonne aux événements Redis
   • Les changements sont diffusés en temps réel aux clients connectés

3. Niveau Frontend

   • L'application Next.js établit une connexion WebSocket
   • Les composants React se mettent à jour automatiquement
   • L'interface affiche l'état en temps réel des feux

Technologies utilisées

Côté IoT

cpp

Backend et Communication

typescript

Frontend

typescript

Objectifs pédagogiques

Ce projet a été conçu pour couvrir plusieurs aspects essentiels du développement IoT et web modernes :

1. Programmation embarquée

• Utilisation de Zephyr OS pour le développement IoT
• Gestion des états et des transitions en C++
• Communication réseau depuis un appareil embarqué

2. Architecture distribuée

• Communication entre systèmes hétérogènes
• Gestion d'état distribuée avec Redis
• Patterns de messaging temps réel

3. Développement web moderne

• Architecture hexagonale avec Next.js
• Composants React performants
• TypeScript et typage fort

4. DevOps et Infrastructure

• Conteneurisation avec Docker
• Scripts d'automatisation
• Monitoring et logging

Dans les sections suivantes, nous explorerons en détail chaque composant du système, en commençant par le contrôleur IoT basé sur Zephyr OS.

2. Partie IoT : Contrôleur de feux tricolores

Introduction à Zephyr OS

Zephyr OS est un système d'exploitation temps réel (RTOS) open source, particulièrement adapté aux systèmes embarqués et IoT. Dans notre projet, il offre plusieurs avantages clés :

• Gestion temps réel : Parfait pour le contrôle précis des feux tricolores
• Stack réseau robuste : Support natif des protocoles TCP/IP
• Empreinte mémoire réduite : Idéal pour les dispositifs contraints
• Support du C++ moderne : Permet une programmation orientée objet

Implémentation du contrôleur

Notre contrôleur de feux tricolores est implémenté en C++ moderne, utilisant les fonctionnalités de Zephyr OS pour une gestion efficace des états et de la communication.

Structure du code

cpp

Gestion des états

cpp

Communication avec le serveur

La communication avec le serveur backend est gérée par une classe dédiée utilisant l'API HTTP de Zephyr.

Client HTTP

cpp

Logging et Monitoring

cpp

Algorithme de gestion des feux

L'algorithme implémenté dans main.cpp gère le cycle des feux tricolores de manière sécurisée et coordonnée. Nous avons opté pour une implémentation simple et démonstrative, qui pourrait être enrichie pour des cas d'usage plus complexes.

1. Initialisation du système

   cpp

2. Cycle principal

   • Le système alterne entre les axes Nord-Sud et Est-Ouest
   • Chaque cycle comprend trois phases :
     1. Vert (30 secondes)
     2. Jaune (5 secondes)
     3. Rouge avec délai de sécurité (2 secondes)

3. Gestion des changements d'état

   cpp

4. Communication asynchrone

   • Un thread dédié gère l'envoi HTTP des changements d'état
   • Les événements sont mis en file d'attente via k_msgq
   • Le thread HTTP les traite de manière asynchrone

5. Sécurité et robustesse

   • Délai de sécurité entre les changements d'axe
   • Gestion des erreurs de communication
   • Logging des événements pour le monitoring

Pistes d'amélioration

Cette implémentation basique pourrait être enrichie avec :

1. Scénarios personnalisables

   • Configuration des durées par plage horaire
   • Modes spéciaux (nuit, urgence, événements)
   • Adaptation au trafic en temps réel

2. Gestion avancée du trafic

   • Détection de présence de véhicules
   • Priorité aux transports en commun
   • Synchronisation entre carrefours

3. Configuration dynamique

   • Interface de paramétrage à distance
   • Changement de scénario à la volée
   • Apprentissage automatique des patterns de trafic

Pour implémenter ces améliorations, il faudrait :

• Ajouter une couche d'abstraction pour les scénarios
• Implémenter un système de configuration dynamique
• Intégrer des capteurs et des règles métier complexes
• Développer une API de contrôle plus complète

Cette version simple reste néanmoins parfaitement adaptée pour démontrer les concepts de base de l'IoT et de la communication temps réel.

Configuration du projet

Le fichier prj.conf configure les fonctionnalités de Zephyr OS pour notre projet. Cette configuration active :

• Le support du C++ et du standard C++17 pour utiliser les fonctionnalités modernes du langage
• Les capacités réseau avec IPv4 et TCP pour la communication avec le serveur
• Les sockets et le client HTTP pour envoyer les mises à jour d'état
• Le système de logging pour le debugging et le monitoring

Ces options sont essentielles pour que notre contrôleur IoT puisse communiquer sur le réseau et envoyer les changements d'état des feux tricolores au serveur central.

conf

Compilation optimisée avec Zephyr OS

Contrairement à un système d'exploitation traditionnel comme Linux qui embarque de nombreux modules et pilotes par défaut, Zephyr OS utilise une approche minimaliste et hautement configurable. À la compilation, seuls les composants strictement nécessaires sont inclus dans l'image finale :

1. Différence avec les OS traditionnels

   • Un Linux embarqué classique fait plusieurs centaines de Mo
   • Il inclut de nombreux pilotes et services non utilisés
   • Le démarrage charge beaucoup de composants superflus
   • La surface d'attaque est plus importante

2. Avantages de l'approche Zephyr

   • L'image finale ne fait que quelques centaines de Ko
   • Seuls les pilotes et protocoles configurés sont inclus
   • Le démarrage est quasi instantané
   • La surface d'attaque est minimale

3. Configuration granulaire

   • Chaque fonctionnalité est un module Kconfig
   • Les dépendances sont résolues automatiquement
   • L'optimisation est poussée au maximum
   • Les ressources sont allouées statiquement

Cette approche "from scratch" permet d'obtenir un système hautement optimisé et sécurisé, parfaitement adapté aux contraintes de l'IoT :

• Ressources limitées (RAM/Flash)
• Consommation énergétique minimale
• Démarrage rapide
• Surface d'attaque réduite

Compilation et déploiement

Le projet utilise CMake pour la compilation :

cmake

Cette implémentation IoT illustre plusieurs concepts avancés :

1. Programmation événementielle

   • Utilisation de files de messages pour la communication inter-threads
   • Timers pour la gestion des transitions d'état

2. Gestion des ressources

   • Utilisation efficace de la mémoire
   • Gestion des connexions réseau

3. Robustesse

   • Logging détaillé des événements
   • Gestion des erreurs de communication
   • Reconnexion automatique

Dans la prochaine section, nous verrons comment le backend gère la communication avec ces contrôleurs IoT et distribue les mises à jour aux clients web.

3. Backend : Serveurs et Communication

Notre backend est composé de plusieurs services qui collaborent pour assurer une communication fluide entre les contrôleurs IoT et l'interface web.

API Gateway avec Bun

L'API Gateway est le point d'entrée pour les contrôleurs IoT. Implémentée avec Bun pour ses performances exceptionnelles, elle gère les requêtes HTTP et maintient la cohérence des états.

Gestion des requêtes

typescript

Serveur WebSocket

Le serveur WebSocket assure la distribution en temps réel des mises à jour aux clients web connectés.

Implémentation du serveur

typescript

Gestion des états avec Redis

Redis joue un rôle central dans notre architecture, servant à la fois de broker de messages et de store d'état.

Configuration Redis

yaml

Subscriber Redis

typescript

Architecture de Communication

Notre backend implémente plusieurs patterns de communication essentiels :

1. Pattern Pub/Sub

   • Redis comme broker de messages
   • Découplage des producteurs et consommateurs
   • Distribution efficace des mises à jour

2. Pattern Gateway

   • Point d'entrée unique pour les appareils IoT
   • Validation et transformation des données
   • Gestion des erreurs centralisée

3. Pattern Observer

   • Notification en temps réel des changements
   • Maintien des connexions WebSocket
   • Distribution des mises à jour aux clients

Sécurité et Performance

Plusieurs mesures sont mises en place pour assurer la sécurité et les performances :

1. Sécurité

   • Validation des données entrantes
   • Headers CORS configurés
   • Isolation réseau avec Docker

2. Performance

   • Utilisation de Bun pour des performances optimales
   • Connexions persistantes avec Redis
   • Gestion efficace des WebSockets

3. Fiabilité

   • Logging des événements
   • Gestion des erreurs robuste
   • Reconnexion automatique aux services

Dans la prochaine section, nous explorerons l'interface utilisateur développée avec Next.js qui permet de visualiser et interagir avec notre système de feux tricolores.

4. Frontend : Interface de monitoring

L'interface utilisateur de notre système est construite avec Next.js 15, en suivant les meilleures pratiques de développement moderne et une architecture hexagonale.

Architecture du Frontend

Notre application suit une architecture hexagonale (ports et adaptateurs) pour maintenir une séparation claire des responsabilités :

typescript

Implémentation de l'Adaptateur

L'adaptateur gère la communication avec le backend via WebSocket :

typescript

Composants React

Page Principale

typescript

Composant Feu Tricolore

typescript

Styles et Configuration

Configuration Tailwind

typescript

Optimisations et Bonnes Pratiques

1. Performance

   • Utilisation de React Server Components
   • Optimisation des re-rendus
   • Lazy loading des composants non critiques

2. Accessibilité

   • Support du clavier
   • Attributs ARIA appropriés
   • Contraste des couleurs optimisé

3. Maintenabilité

   • Architecture hexagonale
   • Typage strict avec TypeScript
   • Tests automatisés

Dans la prochaine section, nous aborderons l'infrastructure et le déploiement de notre application.

5. Infrastructure et Déploiement

Notre système utilise Docker pour garantir un déploiement cohérent et reproductible dans tous les environnements.

Configuration Docker

Composition des Services

yaml

Scripts de Développement

Script de Gestion des Services

shell

Configuration de l'Environnement de Développement

Image Docker pour Zephyr

dockerfile

Services de Support

Script de Services Docker

shell

Gestion des Dépendances

Configuration Next.js

json

Bonnes Pratiques de Déploiement

1. Gestion des Secrets

   • Utilisation de variables d'environnement
   • Séparation des configurations par environnement
   • Stockage sécurisé des secrets

2. Monitoring

   • Logging centralisé
   • Métriques de performance
   • Alertes automatisées

3. Sécurité

   • Isolation réseau
   • Mise à jour régulière des dépendances
   • Scan de vulnérabilités

Dans la dernière section, nous aborderons les stratégies de test et le monitoring de notre application.

6. Pour aller plus loin

Pour rendre ce projet plus robuste et prêt pour la production, plusieurs axes d'amélioration peuvent être explorés :

1. Tests et Qualité

Pour assurer la fiabilité du système, nous devrions implémenter :

Tests du Contrôleur IoT

• Tests unitaires pour la machine à états des feux
• Tests d'intégration avec le réseau
• Simulation de conditions d'erreur
• Validation des séquences de feux

Tests Frontend

• Tests des composants React avec Jest et Testing Library
• Tests end-to-end avec Cypress ou Playwright
• Tests de performance avec Lighthouse
• Validation de l'accessibilité

2. Monitoring et Observabilité

Pour un suivi efficace en production, nous devrions ajouter :

1. Performance

   • Intégration avec Prometheus/Grafana
   • Métriques détaillées des WebSockets
   • Monitoring des ressources IoT

2. Fiabilité

   • Système de heartbeat pour les contrôleurs
   • Détection automatique des anomalies
   • Backup automatique des états

3. Sécurité

   • Authentification des contrôleurs
   • Chiffrement des communications
   • Audit des accès

3. Améliorations Fonctionnelles

Le système pourrait être enrichi avec :

1. Interface Avancée

   • Mode maintenance
   • Historique des changements d'état
   • Tableaux de bord personnalisables

2. Gestion des Scénarios

   • Programmation horaire
   • Modes spéciaux (urgence, événements)
   • API pour l'intégration externe

3. Scalabilité

   • Support multi-carrefours
   • Synchronisation entre intersections
   • Répartition de charge

4. Optimisation Énergétique pour Déploiement sur Batterie

Pour les projets nécessitant une autonomie énergétique (sites isolés, zones sans alimentation secteur), plusieurs optimisations seraient nécessaires :

1. Modes de Puissance

   • Mode normal pour le fonctionnement standard
   • Mode éco pour économiser l'énergie en journée calme
   • Mode nuit avec luminosité réduite
   • Mode urgence en cas de batterie faible

cpp

2. Stratégies d'Économie

   • Mise en veille du CPU entre les changements d'état
   • Regroupement des transmissions réseau
   • Ajustement dynamique de la luminosité des LED

cpp

3. Alimentation Solaire

   • Dimensionnement adapté des panneaux
   • Batteries LiFePO4 pour la durée de vie
   • Système de backup

4. Monitoring de la Batterie

cpp

Pour un déploiement réussi, il est recommandé de :

• Monitorer en continu la santé de la batterie
• Planifier les remplacements préventifs
• Nettoyer régulièrement les panneaux solaires
• Implémenter des modes dégradés en cas de batterie faible
• Prévoir une signalisation de secours

Conclusion

Ce projet démontre l'intégration réussie de technologies IoT et web modernes pour créer un système de monitoring en temps réel. Les points clés à retenir sont :

1. Architecture Distribuée

   • Séparation claire des responsabilités
   • Communication efficace entre les composants
   • Scalabilité et maintenabilité

2. Technologies Modernes

   • Zephyr OS pour l'IoT
   • Next.js pour le frontend
   • WebSocket pour le temps réel

3. Bonnes Pratiques

   • Tests automatisés
   • Monitoring complet
   • Documentation détaillée

Ce projet peut servir de base pour développer des applications IoT plus complexes, en adaptant l'architecture et les patterns utilisés selon vos besoins spécifiques.

Mettre en pratique

Pour tirer le meilleur parti de ce tutoriel et développer vos propres projets IoT, voici quelques suggestions d'exercices pratiques :

1. Commencez petit

1. Version simplifiée

   • Créez d'abord un seul feu tricolore
   • Utilisez un simple serveur HTTP sans WebSocket
   • Affichez l'état dans une page web basique

2. Simulation IoT

   • Commencez sans matériel physique
   • Simulez le contrôleur avec un script Node.js
   • Testez la logique de communication

2. Évolutions progressives

1. Ajoutez les WebSockets

   • Implémentez la mise à jour en temps réel
   • Gérez la reconnexion automatique
   • Ajoutez des logs pour comprendre le flux

2. Intégrez Redis

   • Stockez d'abord des états simples
   • Ajoutez la persistence des données
   • Implémentez les patterns pub/sub

3. Variations du projet

Voici quelques idées pour créer votre propre version :

1. Autres cas d'usage

   • Moniteur de température/humidité
   • Système d'éclairage intelligent
   • Contrôle d'arrosage automatique

2. Technologies alternatives

   • Remplacez Zephyr OS par ESP32/Arduino
   • Utilisez MQTT au lieu de WebSockets
   • ...

4. Ressources complémentaires

Pour approfondir chaque aspect :

1. Documentation officielle

   • Zephyr OS Getting Started
   • Next.js Documentation
   • Redis Pub/Sub Guide

2. Dépôts d'exemple

   • Zephyr OS Samples
   • Next.js Examples
   • Redis WebSocket Examples

3. Communautés

   • Discord Zephyr
   • Forum Next.js
   • Reddit r/IOT

1CONFIG_CPP=y
2CONFIG_STD_CPP17=y
3CONFIG_NETWORKING=y
4CONFIG_NET_IPV4=y
5CONFIG_NET_TCP=y
6CONFIG_NET_SOCKETS=y
7CONFIG_HTTP_CLIENT=y
8CONFIG_LOG=y

1// Serveur WebSocket avec Bun
2const wsServer = new WebSocketServer({ port: 8001 });
3
4// Souscription aux événements Redis
5subscriber.subscribe('traffic-lights', (message) => {
6  wsConnections.forEach((ws) => {
7    ws.send(JSON.stringify(JSON.parse(message)));
8  });
9});

1// Composant Next.js avec WebSocket
2export function Intersection() {
3  const [lights, setLights] = useState<TrafficLightState[]>([]);
4
5  useEffect(() => {
6    const adapter = new TrafficLightAdapter();
7    return adapter.subscribeToUpdates((state) => {
8      setLights(prev => prev.map(light =>
9        light.id === state.id ? { ...light, state: state.state } : light
10      ));
11    });
12  }, []);
13
14  return (/* Rendu des feux tricolores */);
15}

1async fetch(req: Request) {
2  const url = new URL(req.url);
3
4  // Headers CORS pour toutes les réponses
5  const corsHeaders = {
6    "Access-Control-Allow-Origin": "*",
7    "Access-Control-Allow-Methods": "GET, POST, OPTIONS",
8    "Access-Control-Allow-Headers": "Content-Type",
9  };
10
11  // Route pour recevoir les mises à jour des feux tricolores
12  if (req.method === "POST" && url.pathname === "/traffic-light") {
13    try {
14      const data = await req.json();
15      const { id, state } = data;
16
17      // Validation de l'état
18      const validStates = ["red", "yellow", "green"];
19      if (!validStates.includes(state)) {
20        return new Response("État invalide", {
21          status: 400,
22          headers: corsHeaders
23        });
24      }
25
26      // Publication de l'état dans Redis
27      await redis.publish("traffic-lights", JSON.stringify({ id, state }));
28      // Stockage de l'état actuel
29      await redis.set(`traffic-light:${id}`, state);
30
31      return new Response(JSON.stringify({ success: true }), {
32        headers: {
33          ...corsHeaders,
34          "Content-Type": "application/json"
35        }
36      });
37    } catch (error) {
38      console.error("Erreur:", error);
39      return new Response(JSON.stringify({ error: error.message }), {
40        status: 500,
41        headers: corsHeaders
42      });
43    }
44  }
45}

1const subscriber = redis.duplicate();
2await subscriber.connect();
3
4await subscriber.subscribe("traffic-lights", (message) => {
5  try {
6    const data = JSON.parse(message);
7    console.log("Nouveau changement de feu tricolore:", data);
8
9    wsConnections.forEach((ws) => {
10      ws.send(JSON.stringify(data));
11    });
12  } catch (err) {
13    console.error("Erreur lors du parsing du message:", err);
14  }
15});

1async function main() {
2    const redis = createClient({
3        url: "redis://localhost:6379"
4    });
5
6    redis.on("error", err => console.error("Erreur Redis:", err));
7    redis.on("connect", () => console.log("Connecté à Redis"));
8
9    await redis.connect();
10
11    const subscriber = redis.duplicate();
12    await subscriber.connect();
13
14    await subscriber.subscribe("traffic-lights", (message) => {
15        try {
16            const data = JSON.parse(message);
17            console.log("Nouveau changement de feu tricolore:", data);
18        } catch (err) {
19            console.error("Erreur lors du parsing du message:", err);
20        }
21    });
22}

1export interface TrafficLightState {
2  id: string;
3  state: "red" | "yellow" | "green";
4}
5
6export interface TrafficLightPort {
7  getInitialStates(): Promise<TrafficLightState[]>;
8  subscribeToUpdates(callback: (state: TrafficLightState) => void): () => void;
9}

1export class TrafficLightAdapter implements TrafficLightPort {
2  async getInitialStates(): Promise<TrafficLightState[]> {
3    try {
4      const responses = await Promise.all(
5        ["North", "South", "East", "West"].map((id) =>
6          fetch(`${API_URL}/traffic-light/${id}`).then((res) => res.json())
7        )
8      );
9
10      return responses.map((response) => ({
11        id: response.id,
12        state: response.state,
13      }));
14    } catch (error) {
15      console.error("Erreur lors de la récupération des états:", error);
16      return [
17        { id: "North", state: "red" },
18        { id: "South", state: "red" },
19        { id: "East", state: "red" },
20        { id: "West", state: "red" },
21      ];
22    }
23  }
24
25  subscribeToUpdates(callback: (state: TrafficLightState) => void): () => void {
26    const ws = new WebSocket(WS_URL);
27
28    ws.onmessage = (event) => {
29      try {
30        const data = JSON.parse(event.data);
31        callback(data);
32      } catch (error) {
33        console.error("Erreur lors du traitement du message WebSocket:", error);
34      }
35    };
36
37    return () => ws.close();
38  }
39}

1import { Intersection } from "@/interfaces/components/traffic-lights/intersection";
2
3export default function Home() {
4  return (
5    <div className="min-h-screen flex flex-col items-center justify-center p-8">
6      <h1 className="text-2xl font-bold mb-8">Moniteur de Feux Tricolores</h1>
7      <Intersection />
8    </div>
9  );
10}

1"use client";
2
3interface TrafficLightProps extends TrafficLightState {
4  orientation?: "vertical" | "horizontal";
5}
6
7export function TrafficLight({
8  id,
9  state,
10  orientation = "vertical",
11}: TrafficLightProps) {
12  const lights = ["red", "yellow", "green"];
13
14  return (
15    <div className="flex flex-col gap-2 items-center">
16      <h3 className="text-sm font-semibold">{id}</h3>
17      <div
18        className={`bg-gray-800 p-2 rounded-lg flex ${
19          orientation === "horizontal" ? "flex-row" : "flex-col"
20        } gap-2`}
21      >
22        {lights.map((light) => (
23          <div
24            key={light}
25            className={`w-8 h-8 rounded-full ${
26              state === light
27                ? {
28                    red: "bg-red-500",
29                    yellow: "bg-yellow-500",
30                    green: "bg-green-500",
31                  }[light]
32                : "bg-gray-700"
33            }`}
34          />
35        ))}
36      </div>
37    </div>
38  );
39}

1export default {
2  content: [
3    "./src/pages/**/*.{js,ts,jsx,tsx,mdx}",
4    "./src/components/**/*.{js,ts,jsx,tsx,mdx}",
5    "./src/app/**/*.{js,ts,jsx,tsx,mdx}",
6    "./src/interfaces/**/*.{js,ts,jsx,tsx,mdx}",
7  ],
8  theme: {
9    extend: {
10      colors: {
11        background: "var(--background)",
12        foreground: "var(--foreground)",
13      },
14      borderSpacing: {
15        'road': '16px'
16      },
17      backgroundImage: {
18        'dashed-white': 'repeating-linear-gradient(90deg, white 0 12px, transparent 12px 32px)',
19        'dashed-white-vertical': 'repeating-linear-gradient(0deg, white 0 12px, transparent 12px 32px)',
20      }
21    },
22  },
23  plugins: [],
24}

1cmake_minimum_required(VERSION 3.20.0)
2
3set(CONF_FILE "prj.conf")
4set(BOARD qemu_x86)
5
6enable_language(C CXX)
7set(CMAKE_CXX_STANDARD 17)
8
9find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
10project(traffic-lights-orcherstrator)
11
12target_sources(app PRIVATE
13    src/main.cpp
14    src/logger.cpp
15    src/http_client.cpp
16)

1services:
2  redis:
3    image: redis:latest
4    ports:
5      - "6379:6379"
6    volumes:
7      - redis-data:/data
8    command: redis-server --appendonly yes
9    networks:
10      zephyr-net:
11        ipv4_address: 10.5.0.3

1services:
2  traffic-lights-monitor:
3    image: oven/bun:latest
4    working_dir: /traffic-lights-monitor
5    volumes:
6      - ./traffic-lights-monitor/:/traffic-lights-monitor
7    command: sh -c "bun install && bun run build && bun run start"
8    ports:
9      - "3000:3000"
10    environment:
11      - NEXT_PUBLIC_API_URL=http://zephyr-dev:8000
12      - NEXT_PUBLIC_WS_URL=ws://localhost:8001
13    networks:
14      zephyr-net:
15        ipv4_address: 10.5.0.5
16
17  redis:
18    image: redis:latest
19    ports:
20      - "6379:6379"
21    volumes:
22      - redis-data:/data
23    command: redis-server --appendonly yes
24    networks:
25      zephyr-net:
26        ipv4_address: 10.5.0.3
27
28volumes:
29  redis-data:
30
31networks:
32  zephyr-net:
33    driver: bridge
34    ipam:
35      config:
36        - subnet: 10.5.0.0/24

1#!/bin/bash
2
3# Couleurs pour les messages
4RED='\033[0;31m'
5GREEN='\033[0;32m'
6YELLOW='\033[1;33m'
7NC='\033[0m'
8
9# Fonction pour vérifier si les containers sont en cours d'exécution
10check_containers() {
11    if ! docker compose ps --quiet &>/dev/null; then
12        echo -e "${RED}Les containers ne sont pas en cours d'exécution.${NC}"
13        echo -e "${YELLOW}Démarrage des containers...${NC}"
14        docker compose up -d
15    fi
16}
17
18# Fonction pour démarrer les containers
19up() {
20    echo -e "${YELLOW}Construction de l'image Docker si nécessaire...${NC}"
21    docker compose build
22    echo -e "${YELLOW}Démarrage des containers...${NC}"
23    docker compose up -d
24    echo -e "${GREEN}Containers démarrés avec succès${NC}"
25}
26
27# Fonction pour arrêter les containers
28down() {
29    echo -e "${YELLOW}Arrêt des containers...${NC}"
30    docker compose down
31    echo -e "${GREEN}Containers arrêtés avec succès${NC}"
32}

1#!/bin/bash
2
3/workdir/tools/net-tools/loop-socat.sh & > /dev/null 2>&1
4/workdir/tools/net-tools/loop-slip-tap.sh & > /dev/null 2>&1
5cd /gateway-http-server-redis && bun run main.ts
6/bin/bash

1FROM ghcr.io/zephyrproject-rtos/zephyr-build:latest
2
3USER root
4
5RUN apt-get update
6RUN apt-get install -y \
7    net-tools \
8    uml-utilities \
9    bridge-utils \
10    nftables
11
12RUN apt-get install -y qemu-system-x86
13RUN apt-get install -y iputils-ping curl
14RUN apt-get install -y --no-install-recommends git cmake ninja-build gperf \
15    ccache dfu-util device-tree-compiler wget \
16    python3-dev python3-pip python3-setuptools python3-tk python3-wheel xz-utils file \
17    make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1
18
19RUN west init -m https://github.com/zephyrproject-rtos/zephyr --mr main .
20RUN west update
21RUN west zephyr-export
22
23RUN cd /workdir/tools/net-tools && make
24
25RUN curl -fsSL https://bun.sh/install | bash
26ENV PATH="/root/.bun/bin:${PATH}"
27
28COPY gateway-http-server-redis /gateway-http-server-redis
29RUN cd /gateway-http-server-redis && bun install
30
31EXPOSE 8000
32
33USER root

1{
2  "name": "traffic-lights-monitor",
3  "version": "0.1.0",
4  "private": true,
5  "scripts": {
6    "dev": "next dev --turbopack",
7    "build": "next build",
8    "start": "next start",
9    "lint": "next lint"
10  },
11  "dependencies": {
12    "react": "^19.0.0",
13    "react-dom": "^19.0.0",
14    "next": "15.1.3"
15  },
16  "devDependencies": {
17    "typescript": "^5.7.2",
18    "@types/node": "^22.10.2",
19    "@types/react": "^19.0.2",
20    "@types/react-dom": "^19.0.2",
21    "postcss": "^8.4.49",
22    "tailwindcss": "^3.4.17",
23    "eslint": "^9.17.0"
24  }
25}

1// Exemple de code Zephyr OS
2void change_traffic_light_state(const char* id, const char* state) {
3    // Envoi de l'état via HTTP
4    http_client.send_traffic_light_state(id, state);
5    // Logging de l'événement
6    LOG_INF("Feu tricolore %s: %s", id, state);
7}

1enum class LightState
2{
3    RED,
4    YELLOW,
5    GREEN
6};
7
8struct TrafficLight
9{
10    const char *name;
11    LightState state;
12    k_timer timer;
13};
14
15struct StateChangeEvent
16{
17    int light_index;
18    LightState new_state;
19};

1void change_axis_state(int light1_index, int light2_index, LightState new_state, uint32_t duration_ms)
2{
3    StateChangeEvent evt1 = {light1_index, new_state};
4    StateChangeEvent evt2 = {light2_index, new_state};
5
6    k_msgq_put(&state_change_queue, &evt1, K_NO_WAIT);
7    k_msgq_put(&state_change_queue, &evt2, K_NO_WAIT);
8
9    if (duration_ms > 0)
10    {
11        k_timer_start(&lights[light1_index].timer, K_MSEC(duration_ms), K_NO_WAIT);
12        k_timer_start(&lights[light2_index].timer, K_MSEC(duration_ms), K_NO_WAIT);
13    }
14}

1void HttpClient::send_traffic_light_state(const char *id, const char *state)
2{
3    // Préparation de la requête HTTP
4    struct http_request req;
5    memset(&req, 0, sizeof(req));
6
7    const char *headers[] = {
8        "Content-Type: application/json\r\n",
9        content_len,
10        NULL
11    };
12
13    req.method = HTTP_POST;
14    req.url = "/traffic-light";
15    req.host = SERVER_ADDR;
16    req.protocol = "HTTP/1.1";
17    req.header_fields = headers;
18    req.payload = payload;
19    req.payload_len = strlen(payload);
20}

1#include <zephyr/logging/log.h>
2
3LOG_MODULE_REGISTER(traffic_lights, LOG_LEVEL_INF);
4
5void log_light_state(const char *name, const char *state)
6{
7    LOG_INF("Feu tricolore %s: %s", name, state);
8}

1void init_traffic_system() {
2    // Initialisation des timers pour chaque feu
3    for (auto &light : lights) {
4        k_timer_init(&light.timer, timer_expiry_callback, nullptr);
5    }
6    // Création du thread HTTP pour la communication
7    http_thread_id = k_thread_create(&http_thread_data, ...);
8}

1void change_axis_state(int light1_index, int light2_index,
2                      LightState new_state, uint32_t duration_ms) {
3    // Envoi des événements de changement d'état
4    StateChangeEvent evt1 = {light1_index, new_state};
5    StateChangeEvent evt2 = {light2_index, new_state};
6
7    // Programmation des timers si une durée est spécifiée
8    if (duration_ms > 0) {
9        k_timer_start(&lights[light1_index].timer, ...);
10        k_timer_start(&lights[light2_index].timer, ...);
11    }
12}

1enum class PowerMode {
2    NORMAL,     // Fonctionnement standard
3    ECO,        // Mode économie d'énergie
4    NIGHT,      // Mode nuit
5    EMERGENCY   // Mode urgence (batterie faible)
6};

1void enter_low_power_mode() {
2    // Réduction de la fréquence CPU
3    pm_device_action_run(cpu_dev, PM_DEVICE_ACTION_RESUME);
4
5    // Configuration du réveil sur timer
6    k_timer_start(&wakeup_timer, K_SECONDS(state_duration), K_NO_WAIT);
7
8    // Entrée en mode sleep
9    k_sleep(K_FOREVER);
10}

1struct PowerMetrics {
2    float battery_voltage;
3    float current_draw;
4    float temperature;
5    uint32_t uptime;
6};
7
8PowerMetrics getCurrentMetrics() {
9    PowerMetrics metrics;
10    metrics.battery_voltage = adc_read_battery();
11    metrics.current_draw = adc_read_current();
12    metrics.temperature = read_temperature();
13    metrics.uptime = k_uptime_get();
14    return metrics;
15}