Progetto 01 - IoT e IoE con Packet Tracer - Lezione 1 MCU sensori attuatori
Realizziamo un sistema IoE completo con Cisco Packet Tracer, Real HTTP, PHP, MySQL e dashboard web: dal potenziometro e MCU simulati al database reale e ritorno con il controllo remoto del LED.
1. L'architettura del progetto IoE completo
Prima di entrare nel codice è utile osservare il progetto come un insieme di componenti che collaborano tra loro. Il potenziometro rappresenta la sorgente del dato, mentre il LED rappresenta un attuatore che può essere comandato da remoto. In questo progetto utilizziamo Cisco Packet Tracer per realizzare un sistema IoE capace di comunicare con componenti software realmente eseguiti sul computer.
Il dispositivo simulato acquisisce il valore di un potenziometro, lo visualizza sul display e lo invia attraverso una richiesta HTTP a un server reale. Il server PHP riceve i dati, li registra in un database MySQL e li rende disponibili a una dashboard web. Dalla stessa dashboard è inoltre possibile inviare un comando all'MCU simulato per accendere o spegnere un LED.
dato 0-1023
Packet Tracer
JSON
API REST
sensor_data
Chart.js
In questo progetto Packet Tracer non rappresenta più l'intero sistema. La simulazione diventa una parte di un'architettura più ampia: l'MCU comunica realmente con software eseguito sul computer attraverso il protocollo HTTP. L'MCU è client quando invia, server quando riceve.
Simulazione del dispositivo IoT
MCU, potenziometro A0, display pin 2, LED pin 1. Base della Lezione 1 sensori e attuatori.
Comunicazione tra client e server
RealHTTPClient per POST JSON e RealHTTPServer sulla porta 8765 per ricevere comandi.
Ricezione e memorizzazione
iot_data.php salva valore e led_status, control_led.php inoltra GET all'MCU.
Visualizzazione e controllo
Bootstrap, tabella ultimi 10 valori, grafico Chart.js, pulsante accendi/spegni.
MCU sensori attuatori
Il potenziometro è sensore analogico, LED attuatore digitale. gpio e analogRead in Python.
Sistema completo
Simulazione + rete + API + DB + web in un unico progetto didattico verticale.
Spiega alla classe partendo dal flusso fisico: il dato nasce analogico, diventa digitale con ADC a 10 bit (0-1023), poi JSON, poi HTTP. Disegna la freccia alla lavagna: SENSORE → MCU → RETE → SERVER → DB. Quando vedono il flusso, il codice diventa più chiaro.
2. Creazione del database MySQL con XAMPP
La prima componente reale del progetto è il database. Utilizziamo XAMPP per avviare Apache e MySQL e phpMyAdmin per creare il database e la tabella che conterrà i dati provenienti dal dispositivo IoT.
Creiamo il database IoT_database e la tabella sensor_data.
La tabella contiene tre informazioni fondamentali oltre alla chiave primaria:
valore INT(5)
Contiene il valore letto dal potenziometro. Nell'esempio 0-1023 da ADC 10 bit. 2^10 = 1024 livelli.
led_status VARCHAR(10)
Memorizza lo stato corrente del LED, acceso oppure spento. Aggiornato dalla route control_led.
timestamp automatico
Registra data e ora dell'inserimento. Utile per asse X del grafico Chart.js.
Perché 0-1023? Il potenziometro viene letto tramite ADC a 10 bit. Con 10 bit hai 2¹⁰ = 1024 livelli numerici, rappresentati dall'intervallo 0–1023. Se ruoti il potenziometro a metà, leggerai circa 512. Questo è un ottimo collegamento con Sistemi e Reti e TPSIT sul concetto di conversione analogico-digitale.
In phpMyAdmin MySQL su Windows è case-insensitive, ma nello script PHP usiamo iot_database minuscolo. Se crei IoT_database e in PHP scrivi iot_database, funziona su Windows ma su Linux no. Mantieni ovunque lo stesso nome e ricorda: XAMPP vuole password root vuota, altrimenti la connessione fallisce.
3. Le API REST in PHP - iot_data e control_led
Il database da solo non comunica direttamente con Packet Tracer. Abbiamo bisogno di un componente intermedio che riceva le richieste HTTP, interpreti i dati e interagisca con MySQL. Questo ruolo viene svolto da due script PHP:
iot_data.php
Riceve dal dispositivo il valore del potenziometro e stato LED via POST JSON e memorizza nel DB.
control_led.php
Riceve dalla dashboard comando accendi/spegni e inoltra GET http://127.0.0.1:8765/control_led?comando=1
Che cos'è un endpoint?
URL attraverso cui app accede a funzionalità server. MCU usa endpoint http://127.0.0.1/test/IoT/iot_data.php
3.1 API per la ricezione dei dati — iot_data.php
Creiamo il file iot_data.php all'interno della directory utilizzata da XAMPP, ad esempio: C:\xampp\htdocs\test\IoT
" . $conn->error; } } else { echo "Errore: valore o stato del LED non ricevuti"; } } $conn->close(); ?>
La funzione file_get_contents() normalmente legge una risorsa. Lo stream php://input permette di accedere al corpo della richiesta HTTP quando il contenuto è JSON. Il risultato viene trasformato in array PHP con json_decode().
Fai scrivere agli studenti alla lavagna: valore sensore → oggetto Python → json.dumps() → HTTP POST → PHP php://input → array PHP → SQL → MySQL. Ripetilo a voce: questo è il cuore dell'IoE. Se ricordano il percorso, capiscono dove mettere i debug.
3.2 API per il controllo del LED — control_led.php
La comunicazione può avvenire anche nella direzione opposta. Quando l'utente preme "Accendi" oppure "Spegni", la dashboard richiama l'API control_led.php. L'API legge il parametro comando e invia una richiesta HTTP GET all'MCU.
Quando invia: MCU è CLIENT → POST a iot_data.php
Quando riceve: MCU è SERVER → espone route /control_led su RealHTTPServer porta 8765. Questo è fondamentale per la verifica: chiedi "Quando l'MCU è client e quando server?" e fai disegnare le due frecce opposte.
4. Realizzazione IoE in Packet Tracer - Real HTTP Client e Server
La rete e il collegamento dei dispositivi sono già stati illustrati nel progetto introduttivo IoT e IoE con Cisco Packet Tracer. Qui ci concentriamo sull'aspetto nuovo: la possibilità di utilizzare le funzionalità Real HTTP offerte da Packet Tracer. Apriamo la scheda Programming dell'MCU e osserviamo i template dedicati.
Real HTTP Client - Python
Permette al dispositivo di inviare richieste HTTP verso un server reale XAMPP. Usato per POST JSON.
Real HTTP Server - Python
Permette al dispositivo di ricevere richieste HTTP e rispondere tramite propria route. Per controllo LED.
Novità del progetto
Partiamo dalla base MCU + sensori + attuatori della Lezione 1 e aggiungiamo livello applicativo HTTP reale.
4.1 Creazione del progetto Python e import
4.2 Configurazione dell'MCU - Setup pin e server
L'MCU ascolta sulla porta 8765. Questo permette al server PHP di raggiungere l'MCU attraverso l'endpoint dedicato al controllo del LED. Il display sul pin 2 mostra il valore del potenziometro letto da A0, il LED sul pin 1 è l'attuatore comandabile.
4.3 La route per il controllo del LED - Server HTTP su MCU
Definiamo ora la funzione Python che riceve la richiesta HTTP. Il parametro comando determina se il LED deve essere acceso oppure spento.
La route viene registrata con server.route("/control_led", ["GET"], control_led). Di conseguenza:
La parte più ostica per gli studenti è lo split della query string. Mostra con print intermedi: url → split("?")[1] → split("&") → dict. Fai aggiungere print(params) per vedere cosa contiene. Così capiscono che comando=1 diventa {"comando":"1"}. Non dare per scontato che sappiano parsare URL.
4.4 Il ciclo principale - Lettura sensore e invio
Nel ciclo principale leggiamo il potenziometro, aggiorniamo il display, prepariamo l'oggetto JSON e inviamo i dati al server reale. Dopo ogni invio attendiamo due secondi.
Ogni 2 secondi: lettura sensore analogRead(A0) → scrittura display customWrite → creazione JSON → client.post() → sleep(2). Se dalla dashboard arriva comando LED, la variabile globale stato_led viene aggiornata dalla funzione control_led.
5. Sviluppo della dashboard web completa
La dashboard costituisce l'interfaccia attraverso cui osserviamo i dati acquisiti e interagiamo con il dispositivo simulato. Viene realizzata utilizzando PHP per connessione DB, Bootstrap per layout e Chart.js per rappresentazione grafica.
Connessione e logica
mysqli, query ultimi 10 valori ORDER BY id DESC LIMIT 10, stato LED più recente.
Layout responsive
Card per controllo LED, tabella sensor_data, canvas per chart. Interfaccia chiara.
Grafico storico
Line chart con labels timestamp e values valore potenziometro. Visualizza andamento tempo reale.
5.1 Connessione al database e recupero dati
5.2 Refresh automatico e controllo LED
La dashboard viene aggiornata automaticamente ogni due secondi, in modo da mostrare i dati più recenti ricevuti dal dispositivo.
5.3 Tabella e grafico
Il risultato è un grafico lineare che permette di osservare come varia il valore del potenziometro nel tempo. È il collegamento diretto tra Lezione 1 MCU sensori e la parte web.
Se il grafico è vuoto controlla prima se la tabella sensor_data contiene dati: SELECT COUNT(*). Poi verifica array_column: se $data è vuoto, json_encode restituisce [] e Chart.js non disegna. Aggiungi console.log(labels, values) per debug. Altro errore frequente: dimenticare .reverse() così timestamp è invertito.
6. Il flusso completo e test finale
A questo punto possiamo ricostruire l'intero percorso dell'informazione come sistema IoE didattico che parte dalla Lezione 1 MCU e arriva al controllo remoto.
SENSORE
Potenziometro
MCU
Lezione 1
JSON
valore+led
HTTP POST
RealHTTP
PHP
iot_data.php
MYSQL
sensor_data
PHP+Chart
:8765
attuator
Flusso dati: acquisizione → elaborazione → trasmissione → memorizzazione → visualizzazione.
Flusso comando: interfaccia → API → HTTP → dispositivo → attuatore. Il progetto non è solo mandare un valore a DB, è un esempio completo di comunicazione tra dispositivi, servizi web e database.
Test passo-passo
7. Troubleshooting e debug multilivello
Un progetto che coinvolge simulazione, rete, server, PHP e database può fallire in punti differenti. Un metodo utile consiste nel controllare il percorso del dato un livello alla volta.
Valore non arriva al DB
Controllare MCU print, URL endpoint http://127.0.0.1/test/IoT/iot_data.php, Apache attivo, connessione mysqli. Usa try/except Python.
Grafico vuoto
Controlla se tabella contiene dati, query SQL restituisce risultati, json_encode non vuoto, reverse labels.
LED non cambia stato
Verifica parametro comando 0/1, route /control_led registrata, porta 8765 in ascolto server.isListening(), firewall Windows.
Non modificare contemporaneamente tutti i componenti. Se qualcosa non funziona verifica prima singolo collegamento: MCU → HTTP, HTTP → PHP, PHP → MySQL, oppure Dashboard → PHP → MCU. In laboratorio questo metodo salva tempo: isolamento del guasto è competenza sistemistica fondamentale.
Il caso più frequente in aula: file_get_contents verso 127.0.0.1:8765 fallisce perché Windows Firewall blocca XAMPP o Packet Tracer. Mostra agli studenti come aggiungere eccezione porta 8765 e 80. Fallo provare: senza eccezione, led_status non cambia; con eccezione, funziona subito. Ottima lezione su porte e sicurezza.
8. Verifica / Esercizio pratico
🔬 Attività di laboratorio - Progetto 01 Lezione 1 + HTTP Real
Realizza il progetto completo partendo dalla base MCU sensori attuatori della Lezione 1 e aggiungendo comunicazione HTTP reale.
- Parte base (Lezione 1): Collega in Packet Tracer MCU, potenziometro su A0, display su pin 2, LED su pin 1. Scrivi codice Python che legge analogRead(A0) e visualizza con customWrite(2). Verifica funzionamento senza rete.
- Database: Crea IoT_database e tabella sensor_data con campi id, valore, led_status, timestamp. Inserisci manualmente una riga di test con INSERT e verifica in phpMyAdmin.
- API iot_data.php: Implementa ricezione JSON con php://input e json_decode. Testa con Postman inviando {"valore": 600, "led_status":"acceso"} a http://127.0.0.1/test/IoT/iot_data.php e controlla DB.
- Real HTTP Client su MCU: Importa realhttp, crea RealHTTPClient, implementa ciclo while True con sleep(2) e client.post JSON. Controlla console Packet Tracer e verifica nuovi dati in DB.
- Real HTTP Server e controllo LED: Implementa server = RealHTTPServer(), server.start(8765), funzione control_led con parsing query string comando=1/0 e digitalWrite(1,HIGH/LOW). Registra route e testa da browser http://127.0.0.1:8765/control_led?comando=1
- Dashboard e integrazione finale: Crea dashboard.php con query ultimi 10 record, tabella, Chart.js, pulsanti accendi/spegni verso control_led.php, refresh automatico ogni 2s. Testa flusso completo: muovi potenziometro → vedi grafico aggiornarsi → premi Accendi → LED si accende → DB registra nuovo led_status.
Soluzione: Il funzionamento corretto prevede: MCU legge 0-1023, JSON {"valore":X,"led_status":"spento/acceso"}, POST a iot_data.php che fa INSERT, dashboard SELECT * ORDER BY id DESC LIMIT 10, Chart.js con reverse timestamp. Comando LED: form GET comando=1 → control_led.php → file_get_contents(http://127.0.0.1:8765/control_led?comando=1) → MCU digitalWrite HIGH e aggiorna stato_led globale.
Valutazione: 30% base Lezione 1 funzionante, 20% DB + API, 20% Real HTTP Client/Server, 20% dashboard completa, 10% troubleshooting documentato. Richiedi screenshot tabella sensor_data con almeno 5 valori diversi e video LED che si accende da dashboard.
Una volta completato: aggiungere altri sensori (temperatura, luce), memorizzare più grandezze nella stessa tabella, realizzare più grafici nella dashboard, aggiungere soglie e notifiche (se valore > 800 alert), introdurre ulteriori attuatori (buzzer, motore), separare maggiormente API, database e interfaccia con pattern MVC, utilizzare progetto come base per architettura IoT completa con ESP32 reale.
9. Riepilogo e concetti chiave
📚 Prossimo passo - Progetto 02 IoE con Cisco Packet Tracer e HTTP Real avanzato
Partendo da questa base Lezione 1 + HTTP Real, nel Progetto 02 approfondiremo pattern REST completi, gestione di più sensori contemporanei, autenticazione API e dashboard con soglie e notifiche. Mantieni funzionante questo progetto: sarà la fondamenta per architetture IoT distribuite più complesse e per il passaggio a dispositivi reali come ESP32.