Archivi tag: automazione

Esercitazione 4 – Macchina a stati per un ciclo automatico con start, pausa, allarme e reset

Allenamento per l’esame di maturità
Percorso di laboratorio con Arduino per studenti di quinta ITIS

Obiettivo didattico

Modellare un ciclo automatico come macchina a stati: attesa, marcia, pausa, allarme e reset. L’attività avvicina gli studenti al modo in cui si progetta un processo tecnico da esame.

Materiali suggeriti

  • Arduino UNO R3 o UNO R4,
  • 3 pulsanti (START, PAUSA, RESET);
  • 2 LED;
  • 2 Resistori da 220 Ohm (per i LED);
  • jumper.

Schema di collegamento

Richiamo teorico

Una macchina a stati finiti rappresenta un processo come un insieme di stati mutuamente esclusivi. In ogni stato il sistema esegue azioni ben definite e attende eventi che causano il passaggio allo stato successivo. Questo metodo riduce gli errori logici nei programmi complessi.

Schema logico dell’attività

  • All’avvio il sistema è in ATTESA;
  • se arriva START passa a MARCIA;
  • in MARCIA può ricevere PAUSA oppure entrare in ALLARME se scade il tempo massimo;
  • in PAUSA attende una nuova pressione di START;
  • da ALLARME si esce solo con RESET, che riporta il sistema in ATTESA.

Diagramma a stati

Per rappresentare in modo corretto il comportamento di questo esercizio è molto utile affiancare al codice un diagramma a stati. In questo caso, infatti, il sistema non si limita a eseguire istruzioni una dopo l’altra, ma cambia comportamento in funzione della condizione operativa in cui si trova.

Il programma può trovarsi in un solo stato per volta, e ogni stato descrive una precisa fase di funzionamento del sistema. Nel nostro sketch gli stati sono quattro:

  • STATO_ATTESA
  • STATO_MARCIA
  • STATO_PAUSA
  • STATO_ALLARME

Il diagramma a stati è particolarmente adatto a questa situazione perché mostra in modo immediato tre aspetti fondamentali:

  • quali sono gli stati possibili del sistema;
  • quali eventi provocano il passaggio da uno stato all’altro;
  • quale logica di funzionamento è stata implementata nel codice.

In altre parole, mentre il diagramma di flusso descrive bene la sequenza dei controlli svolti nel loop(), il diagramma a stati descrive meglio la struttura logica del processo.

Stato iniziale del sistema

Nel diagramma compare il simbolo iniziale che punta verso STATO_ATTESA. Questo significa che, all’accensione di Arduino o dopo un reset, il sistema parte nello stato di attesa.

In questa fase il ciclo automatico non è attivo. Il LED di marcia è spento, il LED di allarme è spento e il programma controlla continuamente i pulsanti in attesa di un comando di avvio.

Dal punto di vista didattico, questo è il comportamento tipico di molti sistemi automatici: il processo non parte in modo autonomo, ma richiede un comando esplicito dell’operatore.

Transizione da ATTESA a MARCIA

Dal nodo STATO_ATTESA parte una freccia verso STATO_MARCIA con l’etichetta:

START premuto / istanteInizioMarcia = millis()

Questa notazione va letta così: se il sistema si trova in attesa e viene rilevata la pressione del pulsante START, allora il programma passa allo stato di marcia. Durante questa transizione viene anche eseguita un’azione importante, cioè il salvataggio dell’istante iniziale della marcia tramite millis().

Questo passaggio è fondamentale perché permette al sistema di iniziare a contare il tempo trascorso in marcia senza bloccare il programma. In pratica, nel momento in cui parte la marcia, viene memorizzato il riferimento temporale da cui inizierà il controllo del timeout.

Significato dello stato MARCIA

Lo stato STATO_MARCIA rappresenta la fase in cui il sistema è attivo.

In questa condizione il LED di marcia viene acceso, il LED di allarme resta spento e il programma continua a controllare due possibili situazioni:

    • la richiesta di pausa;
    • il superamento del tempo massimo consentito.

Importante: nello stato di marcia il sistema non esegue una sola azione, ma resta in una condizione operativa in cui il programma continua a verificare gli eventi che possono modificare il comportamento complessivo del processo.

Transizione da MARCIA a PAUSA

Se durante la marcia viene premuto il pulsante PAUSA, il sistema passa a STATO_PAUSA.

Questa transizione rappresenta una sospensione del ciclo. Dal punto di vista logico, il processo non è terminato, ma è momentaneamente fermo in attesa di un nuovo comando.

Nel diagramma questa freccia mostra che la pausa può essere richiesta solo quando il sistema si trova effettivamente in marcia. Questo rende molto chiaro un concetto fondamentale: non tutti i comandi hanno senso in tutti gli stati. Il significato di un ingresso dipende dallo stato corrente del sistema.

Transizione da MARCIA a ALLARME

La seconda uscita possibile da STATO_MARCIA conduce a STATO_ALLARME ed è attivata dal superamento del tempo massimo di marcia.

Nel codice questa condizione è realizzata confrontando il tempo attuale, ottenuto con millis(), con l’istante iniziale salvato all’ingresso nello stato di marcia. Quando la differenza raggiunge o supera il valore impostato in TEMPO_MASSIMO_MARCIA, il sistema genera l’allarme.

Questo passaggio è interessante perché mostra come una macchina a stati possa cambiare stato non solo in risposta a un pulsante, ma anche in risposta a una condizione temporale. In molti sistemi automatici reali, infatti, il tempo costituisce un vincolo di sicurezza o di controllo del processo.

Significato dello stato PAUSA

Lo stato STATO_PAUSA rappresenta una sospensione controllata del ciclo.

In questa fase il LED di marcia è spento e il LED di allarme è spento. Il programma non torna allo stato iniziale, ma resta in una condizione intermedia da cui il processo può riprendere.

Dal diagramma si vede che da questo stato esiste una sola transizione utile: la pressione di START, che riporta il sistema in STATO_MARCIA.

È importante però osservare un dettaglio del codice: quando si torna in marcia dalla pausa, il programma esegue di nuovo l’istruzione che salva istanteInizioMarcia = millis(). Questo significa che il conteggio del tempo massimo non viene congelato e poi ripreso, ma riparte da zero.

Questo aspetto è importante, perché aiuta a capire che il diagramma descrive la struttura generale del comportamento, mentre le variabili e le azioni associate alle transizioni determinano il comportamento concreto del sistema.

Significato dello stato ALLARME

Lo stato STATO_ALLARME rappresenta una condizione anomala o di sicurezza.

Quando il sistema entra in allarme, il LED di marcia viene spento e il LED di allarme viene acceso. In questo modo l’operatore può riconoscere immediatamente che il ciclo si è interrotto per il superamento del limite previsto.

Dal diagramma si vede che da STATO_ALLARME non si può tornare direttamente in marcia. L’unica uscita prevista è verso STATO_ATTESA, e questa transizione è attivata dal pulsante RESET.

Anche questa è una scelta molto importante dal punto di vista progettuale: in presenza di un allarme il sistema non riparte automaticamente, ma richiede un intervento esplicito da parte dell’operatore. È una logica tipica dei sistemi in cui la sicurezza o il controllo delle anomalie hanno priorità sulla continuità del funzionamento.

IMPORTANTE

Quando si studiano le macchine a stati è utile distinguere tra:

      • azioni di stato, cioè ciò che il sistema fa mentre si trova in un determinato stato;
      • azioni di transizione, cioè ciò che il sistema esegue nel momento in cui passa da uno stato a un altro.

Nell’esercizio proposto, l’accensione o lo spegnimento dei LED, è un’azione associata allo stato, perché avviene nel blocco di codice relativo a ciascun case.

Il salvataggio di istanteInizioMarcia, invece, è un’azione di transizione, perché viene eseguito nel momento in cui il sistema entra nello stato di marcia.
Questa distinzione è molto utile per comprendere meglio sia il diagramma sia il codice.

Continua a leggere

Esercitazione 3 – Scheduler cooperativo con tre task e supervisione dei tempi

Allenamento per l’esame di maturità
Percorso di laboratorio con Arduino per studenti di quinta ITIS

Obiettivo didattico

Organizzare il programma come scheduler cooperativo con tre task indipendenti: acquisizione analogica, lampeggio di stato e trasmissione seriale periodica. L’attività mostra come il loop() possa diventare un piccolo supervisore software.

Materiali suggeriti

  • Arduino UNO R3 o UNO R4;
  • 1 potenziometro;
  • 2 LED;
  • 2 resitori (per i LED);
  • breadboard;
  • cavetti jumper.

Schema di collegamento

Richiamo teorico

In un sistema embedded semplice non si usa un vero sistema operativo, ma si può costruire uno scheduler cooperativo con millis(). Ogni task possiede il proprio intervallo e il proprio istante dell’ultima esecuzione. Il loop() controlla se ciascun task è pronto e lo richiama.

Schema logico dell’attività

Il programma inizializza i timer dei tre task. Nel loop legge il tempo corrente e verifica uno dopo l’altro se è il momento di eseguire il task di acquisizione, quello di segnalazione e quello di stampa seriale. Se il tempo non è scaduto, passa al controllo successivo.

Diagramma di flusso

Diagramma di flusso Mermaid

flowchart TD
    A[Inizio] --> B[Configura pin, seriale e timer]
    B --> C[Leggi tempo attuale]
    C --> D{Task acquisizione pronto?}
    D -- Sì --> E[Esegui acquisizione]
    D -- No --> F{Task LED pronto?}
    E --> F
    F -- Sì --> G[Commuta LED di stato]
    F -- No --> H{Task seriale pronto?}
    G --> H
    H -- Sì --> I[Invia dati in seriale]
    H -- No --> J[Ritorna al loop]
    I --> J
    J --> C

Programma

/*
  Prof. Maffucci Michele
  Esercizio 3: scheduler cooperativo con tre task indipendenti
*/

const int PIN_SENSORE = A0;
const int PIN_LED_STATO = 8;
const int PIN_LED_SOGLIA = 9;

// ---------------------------
// Intervalli dei tre task
// ---------------------------
const unsigned long PERIODO_ACQUISIZIONE = 50;
const unsigned long PERIODO_LED = 300;
const unsigned long PERIODO_SERIALE = 500;

// ---------------------------
// Istanti ultima esecuzione
// ---------------------------
unsigned long ultimoTaskAcquisizione = 0;
unsigned long ultimoTaskLed = 0;
unsigned long ultimoTaskSeriale = 0;

// ---------------------------
// Variabili condivise
// ---------------------------
int valoreGrezzo = 0;
float tensione = 0.0;
bool statoLed = false;

void setup() {
  pinMode(PIN_LED_STATO, OUTPUT);
  pinMode(PIN_LED_SOGLIA, OUTPUT);
  Serial.begin(9600);
}

void loop() {
  // Il loop assume il ruolo di piccolo scheduler.
  unsigned long adesso = millis();

  // ---------------------------
  // Task 1: acquisizione
  // ---------------------------
  if ((adesso - ultimoTaskAcquisizione) >= PERIODO_ACQUISIZIONE) {
    ultimoTaskAcquisizione = adesso;
    taskAcquisizione();
  }

  // ---------------------------
  // Task 2: LED di stato
  // ---------------------------
  if ((adesso - ultimoTaskLed) >= PERIODO_LED) {
    ultimoTaskLed = adesso;
    taskLed();
  }

  // ---------------------------
  // Task 3: seriale
  // ---------------------------
  if ((adesso - ultimoTaskSeriale) >= PERIODO_SERIALE) {
    ultimoTaskSeriale = adesso;
    taskSeriale();
  }
}

// ----------------------------------------------------------
// Legge il sensore e calcola una tensione equivalente.
// ----------------------------------------------------------
void taskAcquisizione() {
  valoreGrezzo = analogRead(PIN_SENSORE);

  // Conversione esplicita ADC -> tensione.
  tensione = (valoreGrezzo * 5.0) / 1023.0;

  // Uso della misura per attivare un LED di soglia.
  if (tensione >= 2.50) {
    digitalWrite(PIN_LED_SOGLIA, HIGH);
  } else {
    digitalWrite(PIN_LED_SOGLIA, LOW);
  }
}

// ----------------------------------------------------------
// Task di segnalazione periodica.
// ----------------------------------------------------------
void taskLed() {
  if (statoLed == false) {
    statoLed = true;
    digitalWrite(PIN_LED_STATO, HIGH);
  } else {
    statoLed = false;
    digitalWrite(PIN_LED_STATO, LOW);
  }
}

// ----------------------------------------------------------
// Task di comunicazione seriale.
// ----------------------------------------------------------
void taskSeriale() {
  Serial.print("ADC = ");
  Serial.print(valoreGrezzo);
  Serial.print("  Tensione = ");
  Serial.print(tensione, 2);
  Serial.println(" V");
}

Continua a leggere

Capire prima di costruire: una nuova serie di elettrotecnica ed elettronica

Un percorso per chiarire i concetti fondamentali e lavorare in laboratorio con maggiore consapevolezza.

Chi frequenta da tempo questo sito sa che qui trovano spazio soprattutto articoli approfonditi: lezioni estese, tutorial dettagliati, schemi, immagini, codice, proposte operative per il laboratorio e percorsi pensati per la didattica.

L’obiettivo, in queste pagine, è sempre stato quello di affrontare gli argomenti con attenzione, provando a costruire materiali chiari, solidi e riutilizzabili per studenti, docenti, appassionati e maker.

Proprio per questo, può forse sorprendere la nascita di una nuova serie di post più brevi. Eppure questa scelta non nasce da un cambio di rotta, né da una riduzione delle ambizioni didattiche. Nasce, al contrario, da un’esigenza molto concreta che negli ultimi anni è diventata sempre più evidente: per affrontare bene i temi più complessi, bisogna avere chiari i concetti fondamentali.

Da anni lavoro soprattutto con studenti del triennio dell’ITIS, in particolare delle classi quarte e quinte. Più recentemente, però, mi è capitato sempre più spesso di accompagnare anche studenti del biennio, molti dei quali mostrano un entusiasmo autentico verso l’uso di Arduino e desiderano progettare dispositivi, automazioni e piccoli sistemi anche piuttosto articolati.

Questo entusiasmo è prezioso. Curiosità, desiderio di costruire, voglia di sperimentare: sono spesso il miglior punto di partenza possibile per avvicinarsi all’elettronica e all’automazione.

Accanto a questo slancio iniziale, però, nel lavoro quotidiano in laboratorio emerge con chiarezza anche un altro aspetto: le nozioni di base dell’elettrotecnica e dell’elettronica non sempre sono sufficientemente stabili e consapevoli.

Capita così che termini come tensione, corrente, resistenza, massa, polarità, collegamento in serie e in parallelo, uso corretto del multimetro o funzione di una resistenza di pull-up vengano utilizzati in modo intuitivo, ma non pienamente compresi.

Molti dei temi che compariranno in questa serie nascono proprio dalle domande ricorrenti che gli studenti più giovani mi pongono durante le lezioni e le attività di laboratorio. Ho voluto raccogliere quei dubbi, quelle richieste di chiarimento e quelle incertezze che emergono con maggiore frequenza per trasformarle in un percorso ordinato, accessibile e utile anche al di fuori della classe.

Ed è precisamente da questa osservazione che nasce l’idea della nuova rubrica.

Molto spesso, infatti, la difficoltà non sta soltanto negli argomenti avanzati, ma nel fatto che i fondamenti vengono incontrati presto, usati presto, ma non sempre assimilati con la necessaria profondità. Così può accadere che uno studente riesca a montare un circuito, caricare uno sketch e vedere un sistema funzionare, ma fatichi poi a spiegare che cosa stia realmente accadendo dal punto di vista elettrico. E senza questa comprensione, anche le attività più motivanti rischiano di restare fragili.

Per questo ho deciso di affiancare ai tutorial più articolati una serie di lezioni brevi, chiare e mirate, pensate per tornare sui concetti essenziali con un linguaggio accessibile, ma senza rinunciare al rigore.

Saranno testi più snelli nella forma, ma costruiti con la stessa attenzione che riservo ai contenuti più estesi: attenzione ai dubbi reali degli studenti, agli errori ricorrenti, alle semplificazioni fuorvianti e ai passaggi che, se trascurati, rendono più difficile tutto ciò che viene dopo.

A questa scelta si lega anche una riflessione sul formato.

So bene che oggi il video è uno strumento potente, immediato e molto efficace sotto molti aspetti. Non ho nulla contro questa forma di comunicazione, che anzi può essere molto utile in diversi contesti. Tuttavia, realizzare video con continuità richiede tempi di progettazione, registrazione, montaggio e revisione che, almeno in questa fase, non riesco a sostenere in modo regolare. Ma il punto, per me, non è soltanto organizzativo.

Da sempre prediligo la lezione scritta.

La scrittura mi obbliga a rallentare, a ordinare meglio le idee, a scegliere con maggiore precisione le parole e a riflettere più a fondo sul modo in cui un concetto può essere spiegato. Ogni testo diventa così non solo un contenuto da pubblicare, ma anche una traccia di lavoro, una struttura didattica, un riferimento che posso riprendere, sviluppare e collegare ad altri argomenti nel tempo. In questo senso, le lezioni scritte funzionano per me anche come uno storyboard permanente: aiutano chi legge, ma aiutano anche me a costruire percorsi più coerenti.

C’è poi un secondo aspetto che considero importante.

Nel caso di argomenti tecnici di base, credo che leggere un testo mentre si osserva uno schema, si prende un appunto, si prova un collegamento, si misura un valore o si monta un piccolo circuito possa essere estremamente formativo. Il testo scritto ha un ritmo diverso: permette di fermarsi, tornare indietro, rileggere, verificare, annotare, confrontare subito teoria e pratica. Non impone velocità, lascia spazio al tempo dell’apprendimento.

Non penso affatto che il testo debba sostituire il video in assoluto. Penso però che, almeno per alcuni apprendimenti fondamentali, la combinazione tra lettura, riflessione e azione pratica sia particolarmente efficace. In un contesto in cui siamo sempre più abituati a fruire contenuti rapidamente, riprendere un passo più lento può sembrare controcorrente, eppure, proprio questa lentezza consente spesso di fissare meglio i concetti e di trasformarli in competenza reale.

Questa nuova serie, dunque, non nasce per sostituire gli articoli lunghi, né per semplificare artificialmente i contenuti. Nasce per affiancarli e per offrire un percorso di accesso più graduale a studenti, principianti e lettori curiosi che desiderano chiarire bene i fondamenti prima di affrontare temi più complessi.

Ogni post sarà costruito attorno a una domanda semplice o a un nodo concettuale essenziale. L’obiettivo sarà spiegare in modo comprensibile, ma corretto, un singolo aspetto dell’elettrotecnica o dell’elettronica, cercando di collegarlo, quando possibile, a situazioni reali di laboratorio, a esempi concreti o a errori frequenti da evitare.

Questa serie è pensata soprattutto per:

  • studenti che stanno iniziando;
  • docenti che cercano spiegazioni sintetiche ma affidabili da riprendere in classe;
  • appassionati e maker che desiderano chiarire alcuni concetti di base;
  • lettori che preferiscono contenuti brevi, ma non superficiali.

Continuo a credere che, soprattutto nelle discipline tecniche, spiegare bene le basi sia un lavoro importante quanto affrontare gli argomenti più avanzati. Anzi, spesso è proprio dalla qualità delle fondamenta che dipende la possibilità di comprendere davvero tutto il resto.

Per questo motivo, accanto ai tutorial più ampi e strutturati, da oggi troveranno spazio anche queste brevi lezioni essenziali, pensate per rendere più accessibili i concetti fondamentali dell’elettrotecnica e dell’elettronica e per accompagnare, un passo alla volta, chi sta iniziando questo percorso.

Da dove partirà la serie

Questa collezione di lezioni è attualmente in costruzione e si svilupperà progressivamente a partire da alcuni concetti fondamentali che, nell’attività di laboratorio, si rivelano spesso decisivi per comprendere davvero ciò che si sta facendo.

Tra i primi temi che intendo affrontare ci sono:

  • differenza tra tensione, corrente e resistenza;
  • perché un LED ha bisogno di una resistenza in serie;
  • che cosa significa GND in un circuito;
  • collegamento in serie e in parallelo;
  • che cos’è un cortocircuito e perché è pericoloso;
  • a cosa serve il multimetro e come iniziare a usarlo;
  • pull-up e pull-down;
  • differenza tra segnale analogico e digitale.

Il percorso crescerà nel tempo, anche a partire dalle difficoltà più frequenti che emergono durante le attività pratiche e dalle domande ricorrenti degli studenti.

Spero che questa nuova formula possa essere utile.

Come sempre, osservazioni, suggerimenti e proposte di temi da affrontare saranno molto ben accetti.

Buona lettura e buon lavoro 🙂

Sensori e attuatori lontani da Arduino: guida pratica al cablaggio corretto

Metto in evidenza la mia risposta ad una domanda di un utente in riferimento ai problemi causati dalla lunghezza delle linee che collegano Arduino ai dispositivi elettronici.

Marco sei gentilissimo, grazie 🙂
Immagino che tu ti stia riferendo ai collegamenti diretti dei tuoi dispositivi elettronici ad Arduino, è un problema tipico che mi trovo spesso ad affrontare, inoltre l’attività di automazione del controllo di un plastico di trenini è qualcosa che spesso viene svolto a scuola.

Di seguito ti faccio una lista di problemi e soluzioni in riferimento alle problematiche di collegamento, sono molto sintetiche perché sono tratte dalle slide per i miei studenti, quindi sono quasi un copia ed incolla dalle slide sono strutturate a lista puntata con sintesi di spiegazione spero sia sufficiente per risolvere il tuo problema.

Spero di non spaventare con la risposta, in realtà mentre scrivo è diventata una guida sulle possibili cause del problema che stai riscontrando, credo che tu possa risolvere seguendo i 3 passi che trovi alla fine di questa risposta, (al fondo dove scrivo: “ATTENZIONE giusto per non spaventare“), credo che risolverai al PASSO 1.

Allora come dici: perché “allungando i fili di 2 metri il giochino non funziona più?”

Le cause possono essere:

1. Caduta di tensione sui cavi (power)
A 2 m il cavo introduce resistenza: se il dispositivo assorbe corrente (anche solo un relè, un servo o una striscia LED), la tensione arriva più bassa al carico.
Sul banco hai 5V applicati al dispositivo, sul plastico può diventare “4.4–4.7 V” e alcuni moduli iniziano a fare cose strane (reset, letture errate, relè che non agganciano, servo che impazziscono).

Sintomi tipici: Arduino che si resetta quando scatta un relè/servo, sensori instabili, moduli che “a volte sì a volte no”.

2. Disturbi elettromagnetici e ritorni di massa (ground)
Nel plastico ci sono spesso motori, bobine, elettromagneti, alimentatori switching: generano disturbi. Con cavi lunghi aumenta l’area del “loop” e quindi la sensibilità ai disturbi.
In più, se la massa (GND) non è distribuita bene, il riferimento logico “0 V” non è più uguale dappertutto: per Arduino un “HIGH” può non essere più così HIGH 🙂

Sintomi tipici: ingressi digitali che cambiano da soli, finecorsa che “rimbalzano” anche senza toccarli, comunicazioni che falliscono.

Precisazione: quando dico area di “loop” intendo l’area racchiusa dal percorso andata + ritorno della corrente

  • andata: dal pin Arduino (o dall’alimentazione) verso il componente tramite il filo del segnale o del +V
  • ritorno: dal componente che torna a GND (massa) e rientra verso Arduino/alimentatore

Questi due fili (andata e ritorno) formano, di fatto, una spira. Più i due conduttori sono lontani tra loro, più la spira ha area grande.

Una spira con area grande:

  • capta disturbi (si comporta come un’antenna “ricevente”)
  • irradia disturbi (si comporta anche come un’antenna “trasmittente”), soprattutto se nel loop scorrono correnti impulsive (relè, motori, servo)

Ti faccio un esempio pratico che riguarda il tuo progetto:

  • caso “peggiore”: cavo del segnale che va da solo lungo il plastico, e il ritorno GND passa da un’altra parte (magari su una barra massa distante). Loop grande > più problemi.
  • caso “migliore”: segnale e GND viaggiano vicini (idealmente intrecciati). Loop piccolo > molto più robusto.

Come risolvere in questo caso

Per ogni collegamento “lungo”:

  • porta SEMPRE insieme segnale + GND (o +V + GND) nello stesso cavo
  • meglio ancora: usa doppino intrecciato (twisted pair): riduce l’area del loop e quindi la sensibilità ai disturbi

3. Linee di segnale troppo “deboli” (capacità + riflessioni)

Un cavo lungo aggiunge capacità e a volte riflessioni/ringing (fronti ripidi su linee non terminate).
Se stai usando bus come I²C o SPI, 2 metri sono spesso già fuori specifica senza accorgimenti.

Sintomi tipici: sensori I²C che non vengono più visti, display che si bloccano, letture non valide, bus che va in errore.

Vediamo ora come risolvere

Continua a leggere

Home Assistant a scuola: la guida “a puntate” per elettronica & automazione – 01

Questa guida nasce con un obiettivo doppio: replicare in contesti diversi ciò che ho già sperimentato sul campo, a partire da casa mia e trasformare Home Assistant in una palestra didattica concreta per la scuola (ITIS). Il progetto è necessariamente diluito nel tempo: il mio lavoro quotidiano in classe è intenso e scrivere “un po’ alla volta” mi consente di essere più costante e produttivo. Nei prossimi mesi la guida sarà utilizzata integralmente dai miei studenti, quindi per me è anche un modo per strutturare meglio i materiali e organizzare le attività di laboratorio in modo progressivo e replicabile.

Come sempre trovate su queste pagine una sintesi, di un percorso più esteso ed approfondito che verrà svolto in presenza a scuola.

Nota sull’origine dei contenuti

Questa guida nasce dalla traduzione in italiano del manuale di installazione ufficiale di Home Assistant e da miei appunti, il tutto riadattata in alcune parti per un uso didattico a scuola (ITIS), con esempi, lessico semplificato e procedure più guidate pensate per docenti e studenti.

Perché Home Assistant a scuola

La guida nasce per supportare docenti e studenti del percorso di Elettronica ed Automazione dell’ITIS con attività concrete di laboratorio: prototipi, sensori, attuatori, automazioni e dashboard. Farò usare Home Assistant come una vera palestra di allenamento per orchestrare dispositivi e servizi, simulare scenari della vita scolastica (aule, laboratori, LTO), raccogliere dati e creare procedure automatizzate utili alla didattica e all’organizzazione quotidiana.

Vogliamo documentare e standardizzare il lavoro del Laboratorio Territoriale per l’Occupabilità (LTO) e offrire una traccia replicabile: setup chiari, materiali riutilizzabili, esercizi graduali. La guida mostrerà come trasformare Home Assistant in un ambiente di sperimentazione che unisce elettronica, informatica, reti e buone pratiche di gestione del laboratorio, con un  percorso pensato per essere seguita passo passo sia in aula sia a casa.

Cos’è Home Assistant

Home Assistant è una piattaforma open-source per l’automazione e il controllo di dispositivi e servizi, pensata per funzionare in locale (privacy e affidabilità) e per integrare centinaia di tecnologie diverse in un’unica interfaccia e motore di automazioni. È supportata da una grande comunità e offre installazioni pronte per Raspberry Pi e altri sistemi, con gestione semplificata di add-on, backup e aggiornamenti.

La variante Home Assistant OS è un sistema operativo dedicato che rende l’installazione “apri e usa” su single-board computer e x86-64, riducendo la manutenzione e facilitando la gestione del laboratorio (snapshot, add-on, supervisione centrale).

Dal punto di vista storico e tecnologico, il progetto nasce nel 2013 ed è oggi sviluppato dalla Open Home Foundation e da una community globale; backend in Python, frontend web, migliaia di integrazioni e un focus costante su controllo locale e sicurezza.

Tradotto in pratica per l’ITIS: un “collante” che ci permette di collegare sensori/attuatori reali, creare dashboard per il laboratorio, costruire automazioni verificabili (trigger-condizioni-azioni) e fare misure e report utili alla valutazione delle attività.

A chi è rivolta la guida

Docenti di elettronica e sistemi che cercano esempi pronti (step-by-step) e materiali riutilizzabili.
Studenti di elettronica/automazione che vogliono vedere subito sensori e attuatori integrati in un flusso “dati > logica > azione”.
LTO / FabLab didattici che vogliono un’impostazione replicabile, con criteri di sicurezza, versioning dei file e checklist operative.

Cosa faremo (indice “a puntate” in fase di realizzazione)

  • Preparazione – Scelte hardware, HAOS vs altre installazioni, criteri di rete in laboratorio.
  • Installazione su Raspberry Pi – Flash, primo avvio, onboarding, snapshot.
  • Interfaccia & Add-on essenziali – File Editor, Samba/backup, MQTT, ESPHome (panoramica).
  • Prime automazioni – Trigger, condizioni, azioni, blueprint; notifiche e scene.
  • Dashboard di laboratorio – Card base, layout per postazioni, pannello docente.
  • Sensori & Attuatori reali – MQTT ed ESPHome con esempi di misura e pilotaggio.
  • Energy & Presence (opzionale) – Raccolta dati e visualizzazione didattica.
  • Sicurezza & manutenzione – Account, backup, ripristino, troubleshooting “da classe”.

Licenze, privacy e sostenibilità didattica

La natura open-source e il controllo locale permettono di usare Home Assistant anche senza dipendere dal cloud: un vantaggio in termini di privacy, latency e continuità delle esercitazioni in laboratorio. Le integrazioni coprono protocolli e prodotti eterogenei, così da valorizzare strumentazione già presente a scuola e ridurre i costi iniziali.

Esempi di attività “vicine alla vita scolastica”

Ho organizzato le idee in categorie di attività: non saranno tutte realizzate, ma saranno utilizzate come base di discussione con gli studenti per valutarne la fattibilità e scegliere cosa sviluppare in gruppi di progetto (ad esempio in attività di PCTO). L’obiettivo è ragionare su come trasformare un’idea in un prototipo concreto, definendo priorità, vincoli e impatto didattico.

Come farò valutare dagli studenti le proposte (idee anche questa in fase di sviluppo):

  • Fattibilità tecnica: sensori/attuatori disponibili, integrazione con Home Assistant, complessità di sviluppo.
  • Impatto didattico: competenze coinvolte (elettronica, reti, coding, dati), utilità per la vita scolastica.
  • Costi e tempi: componenti necessari, budget, pianificazione a sprint.
  • Sicurezza & privacy: uso in ambiente scolastico, conformità e minimizzazione dei dati.
  • Manutenibilità & scalabilità: riuso dei moduli, documentazione, possibilità di estendere il progetto.
  • Inclusione & accessibilità: benefici per studenti con bisogni educativi speciali.

Ambiente e qualità dell’aria

  • Polveri sottili nel cortile (PM2.5/PM10): sensore (es. PMS5003/SDS011) su ESP32; dashboard con trend orari/giornalieri; automation: se PM supera soglia > notifica a docenti/ATA e cartello “ridurre attività all’aperto”.
  • Stazione meteo didattica: temperatura/UR, pioggia, vento, radiazione; correlare meteo con assenze in palestra/uscite didattiche.
  • Rumore nei corridoi/aula: microfono analogico per livello sonoro; semaforo visivo in classe per autoregolazione.

Sicurezza e accessi

  • Sistemi anti-intrusione: PIR, contatti magnetici su porte/finestre, vibrazione su vetrate; se rilevato movimento fuori orario > sirena/luce + notifica con snapshot ESP32-CAM.
  • Uscite di emergenza: sensori stato porta + test programmati; se porta ostruita/aperta fuori norma > alert a DSGA/collaboratori.
  • Armadi strumentazione: NFC/contatti per apertura; log prelievi/restituzioni per responsabilità e inventario.

Energia e edificio

  • Analisi consumo energetico: smart plug (banchi prova, stampanti 3D, forni reflow), pinza amperometrica/Modbus su quadri; automation: spegnimento notturno/standby; report settimanale per classe/spazio.
  • Bilancio termico/dispersioni: sonde T°/UR in e out (aule, corridoi, esterno) + porta/finestra aperta; se ΔT anomalo o finestra aperta con riscaldamento ON > notifica; log per stimare dispersioni e comportamenti.
  • Monitor fotovoltaico: produzione vs consumi scuola; suggerimento fasce orarie per carichi energivori (laboratorio macchine, stampa 3D).

Laboratori e didattica operativa

  • Banchi prova “occupazione & ticket”: pulsante “richiesta aiuto”, stato banco (OK/KO), coda assistenza sul monitor docente.
  • Gestione stampanti 3D: sensori temperatura/hotend, consumo, fine-filamento; avviso fine stampa e spegnimento automatico.
  • Magazzino componenti: bilance/pesi o contatori ottici su cassettini “critici”; scorte minime > lista acquisti automatica.

Vita quotidiana d’istituto

  • Bacheca digitale: dashboard con eventi del giorno, aule occupate, avvisi ATA; aggiornamento da Google Calendar/Sheets.
  • Clima “comfort apprendimento”: indice combinato (T°, UR, CO₂, rumore, illuminamento) per aula; suggerimenti operativi (arieggiare, abbassare tapparelle, ecc.).

Inclusione e benessere

  • Semaforo acustico-visivo per studenti sensibili al rumore: se superata soglia > luce soft + promemoria “voce bassa”.
  • Promemoria routine (PAI/PEI): notifiche discrete su tablet del docente (pause attive, cambio attività, idratazione).

Manutenzione e asset

  • Ciclo manutenzione attrezzature: ore di utilizzo macchine/pompe/saldatori; scadenze manutentive.
  • Perdite d’acqua (bagni/lab): sensori acqua; chiusura elettrovalvola + avviso bidello.

Come seguire la serie

Pubblicherò gli episodi con cadenza “abbastanza” regolare sul sito. Ogni articolo sarà una porzione del tutorial generale e conterrà file di supporto, checklist e dove necessario schede attività. Se volete ricevere gli aggiornamenti, iscriviti a questo sito o segui i miei canali social.

Non mi resta che dirvi: Buon Making a tutti 🙂