IoT & Web: Crea un monitor di semafori con Zephyr OS, Next.js e WebSocket

In un mondo dove IoT e web convergono sempre più, la capacità di creare interfacce di monitoraggio in tempo reale sta diventando cruciale. Attraverso questo tutorial pratico, esploreremo la creazione di un sistema completo di monitoraggio dei semafori, combinando la potenza di Zephyr OS per IoT con le moderne tecnologie web. Questo progetto servirà come esempio concreto per comprendere le sfide e le soluzioni del monitoraggio IoT in tempo reale.

Nota: Come esperto di Zephyr OS, sono disponibile per supportare i vostri progetti di sviluppo IoT. Non esitate a contattarmi via email o su LinkedIn o via GitHub per qualsiasi domanda su Zephyr OS o per discutere le vostre esigenze di sviluppo embedded.

Il codice sorgente completo di questo progetto è disponibile su GitHub.

Struttura dell'Articolo

1. Panoramica del Progetto

   • Architettura globale
   • Tecnologie utilizzate
   • Obiettivi di apprendimento

2. Parte IoT: Controller del Semaforo

   • Introduzione a Zephyr OS
   • Implementazione del controller in C++
   • Comunicazione con il server

3. Backend: Server e Comunicazione

   • API HTTP con Bun
   • Server WebSocket per il tempo reale
   • Gestione dello stato con Redis

4. Frontend: Interfaccia di Monitoraggio

   • Costruzione con Next.js 15
   • Componenti React in tempo reale
   • Gestione dello stato e aggiornamenti

5. Infrastruttura e Deployment

   • Configurazione Docker
   • Script di sviluppo
   • Deployment in produzione

6. Approfondimenti

   • Test e Qualità
   • Monitoraggio e Osservabilità
   • Miglioramenti Funzionali

Introduzione

Il monitoraggio in tempo reale dei dispositivi IoT presenta sfide uniche, dalla gestione dello stato alla comunicazione bidirezionale. Il nostro progetto di semafori connessi illustra perfettamente queste problematiche: come garantire una sincronizzazione affidabile tra dispositivi fisici e un'interfaccia web mantenendo prestazioni ottimali?

Obiettivi del Progetto

Questo progetto didattico mira a:

• Dimostrare l'integrazione tra IoT e tecnologie web moderne
• Esplorare i pattern di comunicazione in tempo reale
• Mettere in pratica le best practice dello sviluppo full-stack
• Comprendere le sfide della supervisione IoT

Architettura Globale

Il nostro sistema è costruito attorno a quattro componenti principali:

1. Controller IoT: Sviluppato con Zephyr OS in C++, simula un controller di semaforo
2. Gateway API: Server HTTP per la comunicazione con i controller
3. Server WebSocket: Assicura la distribuzione in tempo reale dei cambiamenti di stato
4. Interfaccia Web: Applicazione Next.js per visualizzazione e controllo

Nota importante sulla simulazione: In questo progetto, simuliamo il dispositivo IoT in un container Docker per scopi didattici. Il controller si limita a registrare i cambiamenti di stato. In un deployment reale, questo controller sarebbe installato su un dispositivo IoT effettivo (come un Raspberry Pi Pico) e controllerebbe fisicamente i semafori tramite i suoi GPIO.

Esempio con Raspberry Pi Pico

Il Raspberry Pi Pico è una scelta eccellente per implementare questo progetto in condizioni reali perché:

• Supporta ufficialmente Zephyr OS
• Ha GPIO per controllare i LED del semaforo
• Può essere connesso alla rete tramite vari moduli di comunicazione a lungo raggio (LoRaWAN, NB-IoT, LTE-M) adatti per installazioni all'aperto
• Il suo costo è molto accessibile (circa €5)

Per passare dalla nostra simulazione a un deployment reale, sarebbe necessario:

1. Sostituire i log con comandi GPIO
2. Adattare la configurazione di rete per WiFi o moduli di comunicazione a lungo raggio (LoRaWAN, NB-IoT, LTE-M) a seconda del contesto di deployment
3. Gestire l'alimentazione e la resilienza
4. Aggiungere un involucro protettivo

1. Panoramica del Progetto

Architettura Globale

Il nostro sistema di monitoraggio dei semafori si basa su un'architettura distribuita moderna, progettata per garantire una comunicazione affidabile in tempo reale tra i dispositivi IoT e l'interfaccia utente.

Flusso dei Dati

1. Livello IoT

   • I controller dei semafori, basati su Zephyr OS, gestiscono gli stati delle luci
   • Nella nostra implementazione, i cambiamenti di stato vengono trasmessi via HTTP al Gateway API, ma si sarebbero potuti utilizzare altri protocolli:
     • MQTT per una comunicazione IoT più leggera e ottimizzata
     • CoAP per reti vincolate
     • LoRaWAN per comunicazione a lungo raggio
     • gRPC per maggiori prestazioni
   • I controller mantengono una connessione robusta con il server

2. Livello Backend

   • Il Gateway API riceve gli aggiornamenti e li memorizza in Redis
   • Redis agisce come store centralizzato dello stato
   • Il server WebSocket si sottoscrive agli eventi Redis
   • I cambiamenti vengono trasmessi in tempo reale ai client connessi

3. Livello Frontend

   • L'applicazione Next.js stabilisce la connessione WebSocket
   • I componenti React si aggiornano automaticamente
   • L'interfaccia visualizza gli stati delle luci in tempo reale

Tecnologie Utilizzate

Lato IoT

cpp

Backend e Comunicazione

typescript

Frontend

typescript

Obiettivi di Apprendimento

Questo progetto è stato progettato per coprire diversi aspetti essenziali dello sviluppo IoT e web moderno:

1. Programmazione Embedded

• Utilizzo di Zephyr OS per lo sviluppo IoT
• Gestione degli stati e delle transizioni in C++
• Comunicazione di rete da un dispositivo embedded

2. Architettura Distribuita

• Comunicazione tra sistemi eterogenei
• Gestione dello stato distribuito con Redis
• Pattern di messaggistica in tempo reale

3. Sviluppo Web Moderno

• Architettura esagonale con Next.js
• Componenti React performanti
• TypeScript e tipizzazione forte

4. DevOps e Infrastruttura

• Containerizzazione con Docker
• Script di automazione
• Monitoraggio e logging

Nelle sezioni successive, esploreremo in dettaglio ogni componente del sistema, partendo dal controller IoT basato su Zephyr OS.

2. Parte IoT: Controller del Semaforo

Introduzione a Zephyr OS

Zephyr OS è un sistema operativo real-time (RTOS) open-source, particolarmente adatto per sistemi embedded e IoT. Nel nostro progetto, offre diversi vantaggi chiave:

• Gestione real-time: Perfetta per il controllo preciso dei semafori
• Stack di rete robusto: Supporto nativo dei protocolli TCP/IP
• Impronta di memoria ridotta: Ideale per dispositivi vincolati
• Supporto C++ moderno: Permette la programmazione orientata agli oggetti

Implementazione del Controller

Il nostro controller del semaforo è implementato in C++ moderno, utilizzando le funzionalità di Zephyr OS per una gestione efficiente dello stato e della comunicazione.

Struttura del Codice

cpp

Gestione dello Stato

cpp

Comunicazione con il Server

La comunicazione con il server backend è gestita da una classe dedicata utilizzando l'API HTTP di Zephyr.

Client HTTP

cpp

Logging e Monitoraggio

cpp

Algoritmo di Gestione dei Semafori

L'algoritmo implementato in main.cpp gestisce il ciclo dei semafori in modo sicuro e coordinato. Abbiamo optato per un'implementazione semplice e dimostrativa che potrebbe essere migliorata per casi d'uso più complessi.

1. Inizializzazione del Sistema

   cpp

2. Ciclo Principale

   • Il sistema alterna tra gli assi Nord-Sud ed Est-Ovest
   • Ogni ciclo include tre fasi:
     1. Verde (30 secondi)
     2. Giallo (5 secondi)
     3. Rosso con ritardo di sicurezza (2 secondi)

3. Gestione dei Cambiamenti di Stato

   cpp

4. Comunicazione Asincrona

   • Un thread dedicato gestisce l'invio degli stati via HTTP
   • Gli eventi vengono accodati tramite k_msgq
   • Il thread HTTP li elabora in modo asincrono

5. Sicurezza e Robustezza

   • Ritardo di sicurezza tra i cambi di asse
   • Gestione degli errori di comunicazione
   • Logging degli eventi per il monitoraggio

Percorsi di Miglioramento

Questa implementazione base potrebbe essere migliorata con:

1. Scenari Personalizzabili

   • Configurazione delle durate basata sul tempo
   • Modalità speciali (notte, emergenza, eventi)
   • Adattamento al traffico in tempo reale

2. Gestione Avanzata del Traffico

   • Rilevamento della presenza dei veicoli
   • Priorità per i mezzi pubblici
   • Sincronizzazione tra incroci

3. Configurazione Dinamica

   • Interfaccia per i parametri remoti
   • Modifiche degli scenari al volo
   • Machine learning dei pattern di traffico

Per implementare questi miglioramenti, sarebbe necessario:

• Aggiungere uno strato di astrazione per gli scenari
• Implementare un sistema di configurazione dinamica
• Integrare sensori e regole di business complesse
• Sviluppare un'API di controllo più completa

Questa versione semplice rimane perfettamente adatta a dimostrare i concetti base di IoT e comunicazione in tempo reale.

Configurazione del Progetto

Il file prj.conf configura le funzionalità di Zephyr OS per il nostro progetto. Questa configurazione abilita:

• Supporto C++ e standard C++17 per utilizzare le funzionalità moderne del linguaggio
• Capacità di rete con IPv4 e TCP per la comunicazione con il server
• Socket e client HTTP per inviare gli aggiornamenti di stato
• Sistema di logging per il debug e il monitoraggio

Queste opzioni sono essenziali per il nostro controller IoT per comunicare attraverso la rete e inviare i cambiamenti di stato dei semafori al server centrale.

conf

Compilazione Ottimizzata con Zephyr OS

A differenza dei sistemi operativi tradizionali come Linux che includono molti moduli e driver predefiniti, Zephyr OS utilizza un approccio minimalista e altamente configurabile. Durante la compilazione, solo i componenti strettamente necessari vengono inclusi nell'immagine finale:

1. Differenza dai SO Tradizionali

   • Un Linux embedded classico è di diverse centinaia di MB
   • Include molti driver e servizi inutilizzati
   • L'avvio carica molti componenti superflui
   • La superficie di attacco è più ampia

2. Vantaggi dell'Approccio Zephyr

   • L'immagine finale è di soli pochi centinaia di KB
   • Solo i driver e i protocolli configurati vengono inclusi
   • L'avvio è quasi istantaneo
   • La superficie di attacco è minima

3. Configurazione Granulare

   • Ogni funzionalità è un modulo Kconfig
   • Le dipendenze vengono risolte automaticamente
   • L'ottimizzazione è massimizzata
   • Le risorse sono allocate staticamente

Questo approccio "da zero" permette di ottenere un sistema altamente ottimizzato e sicuro, perfettamente adattato ai vincoli IoT:

• Risorse limitate (RAM/Flash)
• Consumo energetico minimo
• Avvio rapido
• Superficie di attacco ridotta

Compilazione e Deployment

Il progetto utilizza CMake per la compilazione:

cmake

Questa implementazione IoT illustra diversi concetti avanzati:

1. Programmazione Event-Driven

   • Utilizzo di code di messaggi per la comunicazione tra thread
   • Timer per la gestione delle transizioni di stato

2. Gestione delle Risorse

   • Utilizzo efficiente della memoria
   • Gestione delle connessioni di rete

3. Robustezza

   • Logging dettagliato degli eventi
   • Gestione degli errori di comunicazione
   • Riconnessione automatica

Nella prossima sezione, vedremo come il backend gestisce la comunicazione con questi controller IoT e distribuisce gli aggiornamenti ai client web.

3. Backend: Server e Comunicazione

Il nostro backend consiste in diversi servizi che lavorano insieme per garantire una comunicazione fluida tra i controller IoT e l'interfaccia web.

Gateway API con Bun

Il Gateway API è il punto di ingresso per i controller IoT. Implementato con Bun per le sue prestazioni eccezionali, gestisce le richieste HTTP e mantiene la coerenza dello stato.

Gestione delle Richieste

typescript

Server WebSocket

Il server WebSocket assicura la distribuzione in tempo reale degli aggiornamenti ai client web connessi.

Implementazione del Server

typescript

Gestione dello Stato con Redis

Redis gioca un ruolo centrale nella nostra architettura, servendo sia come message broker che come store di stato.

Configurazione Redis

yaml

Subscriber Redis

typescript

Architettura di Comunicazione

Il nostro backend implementa diversi pattern di comunicazione essenziali:

1. Pattern Pub/Sub

   • Redis come message broker
   • Disaccoppiamento di produttori e consumatori
   • Distribuzione efficiente degli aggiornamenti

2. Pattern Gateway

   • Punto di ingresso unico per i dispositivi IoT
   • Validazione e trasformazione dei dati
   • Gestione centralizzata degli errori

3. Pattern Observer

   • Notifica in tempo reale dei cambiamenti
   • Mantenimento delle connessioni WebSocket
   • Distribuzione degli aggiornamenti ai client

Sicurezza e Prestazioni

Diverse misure sono in atto per garantire sicurezza e prestazioni:

1. Sicurezza

   • Validazione dei dati in ingresso
   • Header CORS configurati
   • Isolamento di rete con Docker

2. Prestazioni

   • Utilizzo di Bun per prestazioni ottimali
   • Connessioni Redis persistenti
   • Gestione efficiente dei WebSocket

3. Affidabilità

   • Logging degli eventi
   • Gestione robusta degli errori
   • Riconnessione automatica dei servizi

Nella prossima sezione, esploreremo l'interfaccia utente sviluppata con Next.js che permette la visualizzazione e l'interazione con il nostro sistema di semafori.

4. Frontend: Interfaccia di Monitoraggio

La nostra interfaccia utente è costruita con Next.js 15, seguendo le moderne best practice di sviluppo e un'architettura esagonale.

Architettura Frontend

La nostra applicazione segue un'architettura esagonale (ports and adapters) per mantenere una chiara separazione delle responsabilità:

typescript

Implementazione dell'Adapter

L'adapter gestisce la comunicazione con il backend tramite WebSocket:

typescript

Componenti React

Pagina Principale

typescript

Componente Semaforo

typescript

Stili e Configurazione

Configurazione Tailwind

typescript

Ottimizzazioni e Best Practice

1. Prestazioni

   • Utilizzo dei React Server Components
   • Ottimizzazione del rendering
   • Caricamento lazy dei componenti non critici

2. Accessibilità

   • Supporto tastiera
   • Attributi ARIA appropriati
   • Contrasto colori ottimizzato

3. Manutenibilità

   • Architettura esagonale
   • Tipizzazione stretta con TypeScript
   • Test automatizzati

Nella prossima sezione, tratteremo l'infrastruttura e il deployment della nostra applicazione.

5. Infrastruttura e Deployment

Il nostro sistema utilizza Docker per garantire un deployment coerente e riproducibile in tutti gli ambienti.

Configurazione Docker

Composizione dei Servizi

yaml

Script di Sviluppo

Script di Gestione dei Servizi

shell

Configurazione dell'Ambiente di Sviluppo

Immagine Docker per Zephyr

dockerfile

Servizi di Supporto

Script dei Servizi Docker

shell

Gestione delle Dipendenze

Configurazione Next.js

json

Best Practice di Deployment

1. Gestione dei Segreti

   • Utilizzo di variabili d'ambiente
   • Separazione delle configurazioni per ambiente
   • Archiviazione sicura dei segreti

2. Monitoraggio

   • Logging centralizzato
   • Metriche di prestazione
   • Alert automatizzati

3. Sicurezza

   • Isolamento della rete
   • Aggiornamenti regolari delle dipendenze
   • Scansione delle vulnerabilità

Nell'ultima sezione, discuteremo le strategie di test e il monitoraggio della nostra applicazione.

6. Approfondimenti

Per rendere questo progetto più robusto e pronto per la produzione, si possono esplorare diverse aree di miglioramento:

1. Test e Qualità

Per garantire l'affidabilità del sistema, dovremmo implementare:

Test del Controller IoT

• Test unitari per la macchina a stati del semaforo
• Test di integrazione di rete
• Simulazione delle condizioni di errore
• Validazione delle sequenze delle luci

Test Frontend

• Test dei componenti React con Jest e Testing Library
• Test end-to-end con Cypress o Playwright
• Test di prestazioni con Lighthouse
• Validazione dell'accessibilità

2. Monitoraggio e Osservabilità

Per un monitoraggio efficace in produzione, dovremmo aggiungere:

1. Prestazioni

   • Integrazione con Prometheus/Grafana
   • Metriche dettagliate dei WebSocket
   • Monitoraggio delle risorse IoT

2. Affidabilità

   • Sistema di heartbeat dei controller
   • Rilevamento automatico delle anomalie
   • Backup automatico degli stati

3. Sicurezza

   • Autenticazione dei controller
   • Crittografia delle comunicazioni
   • Audit degli accessi

3. Miglioramenti Funzionali

Il sistema potrebbe essere migliorato con:

1. Interfaccia Avanzata

   • Modalità manutenzione
   • Storico dei cambi di stato
   • Dashboard personalizzabili

2. Gestione degli Scenari

   • Programmazione basata sul tempo
   • Modalità speciali (emergenza, eventi)
   • API di integrazione esterna

3. Scalabilità

   • Supporto multi-incrocio
   • Sincronizzazione tra incroci
   • Bilanciamento del carico

4. Ottimizzazione Energetica per Deployment a Batteria

Per progetti che richiedono autonomia energetica (siti isolati, aree senza alimentazione di rete), sarebbero necessarie diverse ottimizzazioni:

1. Modalità di Alimentazione

   • Modalità normale per il funzionamento standard
   • Modalità eco per il risparmio energetico durante i giorni tranquilli
   • Modalità notturna con luminosità ridotta
   • Modalità di emergenza per batteria scarica

cpp

2. Strategie di Risparmio Energetico

   • Sospensione della CPU tra i cambi di stato
   • Raggruppamento delle trasmissioni di rete
   • Regolazione dinamica della luminosità dei LED

cpp

3. Alimentazione Solare

   • Dimensionamento appropriato dei pannelli
   • Batterie LiFePO4 per longevità
   • Sistema di backup

4. Monitoraggio della Batteria

cpp

Per un deployment di successo, si raccomanda di:

• Monitorare continuamente lo stato della batteria
• Pianificare sostituzioni preventive
• Pulire regolarmente i pannelli solari
• Implementare modalità degradate per batteria scarica
• Fornire segnalazione di backup

Conclusione

Questo progetto dimostra l'integrazione riuscita tra IoT e tecnologie web moderne per creare un sistema di monitoraggio in tempo reale. I punti chiave includono:

1. Architettura Distribuita

   • Chiara separazione delle responsabilità
   • Comunicazione efficiente tra componenti
   • Scalabilità e manutenibilità

2. Tecnologie Moderne

   • Zephyr OS per IoT
   • Next.js per frontend
   • WebSocket per tempo reale

3. Best Practice

   • Test automatizzati
   • Monitoraggio completo
   • Documentazione dettagliata

Questo progetto può servire come base per sviluppare applicazioni IoT più complesse adattando l'architettura e i pattern utilizzati secondo le vostre esigenze specifiche.

Messa in Pratica

Per ottenere il massimo da questo tutorial e sviluppare i vostri progetti IoT, ecco alcuni suggerimenti di esercizi pratici:

1. Iniziare in Piccolo

1. Versione Semplificata

   • Creare prima un singolo semaforo
   • Utilizzare un server HTTP semplice senza WebSocket
   • Visualizzare lo stato in una pagina web base

2. Simulazione IoT

   • Iniziare senza hardware fisico
   • Simulare il controller con uno script Node.js
   • Testare la logica di comunicazione

2. Evoluzione Progressiva

1. Aggiungere WebSocket

   • Implementare gli aggiornamenti in tempo reale
   • Gestire la riconnessione automatica
   • Aggiungere log per comprendere il flusso

2. Integrare Redis

   • Prima memorizzare stati semplici
   • Aggiungere persistenza dei dati
   • Implementare pattern pub/sub

3. Variazioni del Progetto

Ecco alcune idee per creare la vostra versione:

1. Altri Casi d'Uso

   • Monitor temperatura/umidità
   • Sistema di illuminazione intelligente
   • Controllo irrigazione automatica

2. Tecnologie Alternative

   • Sostituire Zephyr OS con ESP32/Arduino
   • Utilizzare MQTT invece di WebSocket
   • ...

4. Risorse Aggiuntive

Per approfondire ogni aspetto:

1. Documentazione Ufficiale

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

2. Repository di Esempio

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

3. Comunità

   • 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// Server WebSocket con Bun
2const wsServer = new WebSocketServer({ port: 8001 });
3
4// Sottoscrizione agli eventi Redis
5subscriber.subscribe('traffic-lights', (message) => {
6  wsConnections.forEach((ws) => {
7    ws.send(JSON.stringify(JSON.parse(message)));
8  });
9});

1// Componente Next.js con 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 (/* Rendering dei semafori */);
15}

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)

1async fetch(req: Request) {
2  const url = new URL(req.url);
3
4  // Header CORS per tutte le risposte
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  // Rotta per ricevere gli aggiornamenti dei semafori
12  if (req.method === "POST" && url.pathname === "/traffic-light") {
13    try {
14      const data = await req.json();
15      const { id, state } = data;
16
17      // Validazione dello stato
18      const validStates = ["red", "yellow", "green"];
19      if (!validStates.includes(state)) {
20        return new Response("Stato non valido", {
21          status: 400,
22          headers: corsHeaders
23        });
24      }
25
26      // Pubblicazione dello stato su Redis
27      await redis.publish("traffic-lights", JSON.stringify({ id, state }));
28      // Memorizzazione dello stato corrente
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("Errore:", 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("Nuovo cambio di semaforo:", data);
8
9    wsConnections.forEach((ws) => {
10      ws.send(JSON.stringify(data));
11    });
12  } catch (err) {
13    console.error("Errore nel parsing del messaggio:", err);
14  }
15});

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

1async function main() {
2    const redis = createClient({
3        url: "redis://localhost:6379"
4    });
5
6    redis.on("error", err => console.error("Errore Redis:", err));
7    redis.on("connect", () => console.log("Connesso a 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("Nuovo cambio di semaforo:", data);
18        } catch (err) {
19            console.error("Errore nel parsing del messaggio:", 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        ["Nord", "Sud", "Est", "Ovest"].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("Errore nel recupero degli stati:", error);
16      return [
17        { id: "Nord", state: "red" },
18        { id: "Sud", state: "red" },
19        { id: "Est", state: "red" },
20        { id: "Ovest", 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("Errore nell'elaborazione del messaggio 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">Monitor Semafori</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}

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# Colori per i messaggi
4RED='\033[0;31m'
5GREEN='\033[0;32m'
6YELLOW='\033[1;33m'
7NC='\033[0m'
8
9# Funzione per verificare se i container sono in esecuzione
10check_containers() {
11    if ! docker compose ps --quiet &>/dev/null; then
12        echo -e "${RED}I container non sono in esecuzione.${NC}"
13        echo -e "${YELLOW}Avvio dei container...${NC}"
14        docker compose up -d
15    fi
16}
17
18# Funzione per avviare i container
19up() {
20    echo -e "${YELLOW}Costruzione dell'immagine Docker se necessaria...${NC}"
21    docker compose build
22    echo -e "${YELLOW}Avvio dei container...${NC}"
23    docker compose up -d
24    echo -e "${GREEN}Container avviati con successo${NC}"
25}
26
27# Funzione per fermare i container
28down() {
29    echo -e "${YELLOW}Arresto dei container...${NC}"
30    docker compose down
31    echo -e "${GREEN}Container arrestati con successo${NC}"
32}

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#!/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

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// Esempio di codice Zephyr OS
2void change_traffic_light_state(const char* id, const char* state) {
3    // Invio dello stato via HTTP
4    http_client.send_traffic_light_state(id, state);
5    // Logging degli eventi
6    LOG_INF("Semaforo %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    // Preparazione della richiesta 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("Semaforo %s: %s", name, state);
8}

1void init_traffic_system() {
2    // Inizializzazione dei timer per ogni semaforo
3    for (auto &light : lights) {
4        k_timer_init(&light.timer, timer_expiry_callback, nullptr);
5    }
6    // Creazione del thread HTTP per la comunicazione
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    // Invio degli eventi di cambio stato
4    StateChangeEvent evt1 = {light1_index, new_state};
5    StateChangeEvent evt2 = {light2_index, new_state};
6
7    // Programmazione del timer se è specificata una durata
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,     // Funzionamento standard
3    ECO,        // Modalità risparmio energetico
4    NIGHT,      // Modalità notturna
5    EMERGENCY   // Modalità di emergenza (batteria scarica)
6};

1void enter_low_power_mode() {
2    // Riduzione della frequenza della CPU
3    pm_device_action_run(cpu_dev, PM_DEVICE_ACTION_RESUME);
4
5    // Configurazione del timer di risveglio
6    k_timer_start(&wakeup_timer, K_SECONDS(state_duration), K_NO_WAIT);
7
8    // Entrata in modalità 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}