Quick References per lo studio – Prototipi hardware: sicurezza & ordine

Lascia una risposta

In laboratorio sicurezza = metodo + ordine. Un prototipo ben organizzato non è solo più “bello”: è più sicuro, più facile da testare e più veloce da riparare. Lavoriamo con alimentazioni, correnti, componenti sensibili: le buone abitudini proteggono persone, strumenti e risultati.

Preparazione dell’area

Banco pulito: via oggetti non necessari, liquidi lontani, cavi non incrociati.
Illuminazione adeguata, seduta stabile, spazio per notebook/strumenti.
Documenti a portata: schema, pinout, datasheet; cartellina con buste (evita “pezzi sparsi”).

Alimentazione: scelte e verifiche

Parti sempre disalimentato: cabla a cavo staccato.
Tensione e corrente: verifica che la sorgente regga (es. 5 V/2 A per moduli + motori).
Polaritá corretta: segna rosso = +, nero = GND; no fili volanti senza colore.
Protezione: preferisci alimentatori con limite di corrente o fusibili rapidi; imposta limiti sul banco di alimentazione.
GND comune: con più sorgenti, i riferimenti di massa vanno uniti (salvo isolamenti voluti).

Cablaggio e componenti

Cavi corti e fissati (fascette/nastro): riduce falsi contatti.
Breadboard: limiti (resistenza di contatto, cadute, correnti basse). Per correnti > 200–300 mA, evita breadboard → morsetti/stripboard.
Sezione dei fili adeguata (motori ≠ jumper sottili).
Polarità di LED, elettrolitici, moduli. Diodo di ricircolo con carichi induttivi (relè/motori).
ESD (sensori e IC): tocca massa prima di maneggiare, se possibile usa bracciale ESD.

Strumentazione e misure

Multimetro: inizia sul fondo scala più alto; controlla sonde e modalità (V, A, Ω).
Misure “prima di accendere”: continuità su alimentazione (niente corto), verifica resistenze sospette.
Misure “dopo”: V su pin chiave, I assorbita dal sistema, calore (dito/misuratore IR).
Log: annota valori e condizioni (tensione di alimentazione, carico, ambiente).

Procedura di test (incrementale)

Un passo alla volta: prima l’alimentazione, poi un sensore, poi un attuatore…
Stato noto ad ogni passaggio: se qualcosa “salta”, sai dove guardare.
Rollback: se peggiori, torna alla versione stabile precedente.

Chiusura lavori (safety & ordine)

Spegni/disalimenta, scollega, lascia un post-it con lo stato del prototipo (“sensore X instabile; rifare cablaggio domani”).
Rimetti a posto componenti (sacchetti etichettati), attrezzi, cavi avvolti.
Backup: foto cablaggi, schema aggiornato, commit del codice con messaggio chiaro.

Rischi tipici & prevenzione

Surriscaldamento: dissipatori/pad termici, correnti entro specifiche.
Corto accidentale: fili spelati, breadboard usurate, stagnature “a goccia” → isola e rifinisci.
Rumore elettrico: twist dei cavi segnale, condensatori di bypass (0.1 µF vicino ai Vcc), massa stellare.
Batterie Li-ion/LiPo: carica solo con circuiti dedicati, non perforare o piegare, mai cortocircuitare, storage a ~3.8 V.
Meccanica: bordi vivi, parti in movimento: occhiali protettivi se c’è rischio.

Scarica PDF A4 della guida operativa – Apri il sorgente Markdown su GitHub

Se non sai cos’è il Markdown segui il link

---
title: "QR – Prototipi hardware: sicurezza & ordine"
version: "1.2"
autore: "<Classe/Studente>"
licenza: "CC BY 4.0"
ultimo_aggiornamento: "2025-10-05"
---

## 1) Preparazione dell’area
- [ ] **Banco pulito** (via liquidi/oggetti inutili), **luce buona**, sedia stabile.
- [ ] **Documenti a vista**: schema, pinout, datasheet (cartella o busta trasparente).
- [ ] PC/Notebook con IDE aperto e cavo **funzionante**.
- [ ] Foto “prima” del banco (torna utile per confronto e relazione).

## 2) Alimentazione (scelte & verifiche)
- [ ] Cabla **a cavo staccato**; alimenta **solo a fine controllo**.
- [ ] Tensione/ corrente **coerenti** con il carico (es. 5 V/2 A).
- [ ] **Polaritá marcata**: rosso = +V, nero = GND; niente fili volanti non isolati.
- [ ] Se possibile, **limite di corrente** sull’alimentatore o fusibile rapido.
- [ ] Con più sorgenti, **GND comune** (salvo isolamenti voluti).

## 3) Cablaggio e componenti
- [ ] **Cavi corti e fissati** (fascette/nastro); evitare anelli e incroci inutili.
- [ ] Breadboard ok per segnali/ piccole correnti; per >300 mA usa morsetti/stripboard.
- [ ] Sezione fili adeguata (motori ≠ jumper sottili).
- [ ] **Polarità**: LED/elettr. corretta; **diodo di ricircolo** con relè/motori.
- [ ] **ESD**: tocca GND prima di maneggiare IC/sensori; se possibile usa bracciale.

## 4) Strumentazione & misure
- [ ] Multimetro: scala corretta (V, A, Ω) e **sonde ben inserite**.
- [ ] **Prima di accendere**: continuità tra +V e GND (no corto).
- [ ] **Dopo**: misura V su pin chiave, **corrente assorbita**, temperatura (dito/IR).
- [ ] Logga dati e condizioni (V aliment., carico, ambiente).

## 5) Procedura di test (incrementale)
1. **Alimenta** → verifica solo la parte di potenza.
2. **Aggiungi** un modulo alla volta (sensore → attuatore).
3. **Stato noto** a ogni passo; se peggiori, **rollback** alla versione stabile.
4. Una modifica per volta (HW *o* SW), poi test.

## 6) Chiusura lavori
- [ ] **Spegni e scollega**.
- [ ] **Post-it** di stato: “sensore X instabile; rifare cablaggio domani”.
- [ ] Riponi componenti/attrezzi; avvolgi cavi.
- [ ] **Backup**: foto cablaggio, schema aggiornato, commit codice con messaggio chiaro.

## 7) Rischi tipici & prevenzione
- **Surriscaldamento** → dissipatori/pad; rispetta correnti massime; ventilazione.
- **Corto** → rifinisci stagnature; isola punti nudi; sostituisci breadboard usurate.
- **Rumore elettrico** → twist cavi segnale, **bypass 0.1 µF** vicino a Vcc, massa a stella.
- **Batterie Li-ion/LiPo** → carica **solo** con circuiti dedicati; non perforare/piegare; mai in corto; storage ~3.8 V.

Esempio – “Il motore non parte e il driver scotta”

Setup

Alimentazione 12 V (banco da laboratorio, limite corrente 1.5 A).
Driver ponte H (es. L298N o similare), motore DC 6–12 V, Arduino UNO.
Cavi: alimentazione 0.5–0.75 mm², segnale jumper corti.

Sintomi

A “start”, motore fermo o vibra; driver caldo dopo pochi secondi; LED di alimentazione ok.

Procedura di diagnosi

01. Isola blocchi

- Scollega Arduino → alimenta solo il driver e il motore in manuale: ponticella IN1=HIGH, IN2=LOW (o usa enable).
- Se ancora fermo, il problema è driver/motore (non il codice).

02. Verifica alimentazione

- Misura V_motore a vuoto: ~12 V?
- Cala a 5–6 V quando provi a muoverlo? → alimentatore in current limit (motore richiede più spunto).
- Soluzione: alimentatore con corrente di picco più alta o soft-start (PWM graduale).

03. Controlla cablaggio e polarità

- GND comune tra Arduino e driver.
- Sezione fili verso motore sufficiente (evita jumper sottili).
- Diodi di ricircolo: presenti/integrati? Se driver ne è privo, aggiungili.

04. Assorbimento & termica

- Misura corrente di spunto (metti multimetro in serie): >1.5–2 A? Il L298N satura e scalda.
- Opzioni: driver più efficiente (MOSFET, es. BTS7960 o ponte H moderno), abbassa tensione o usa PWM limitato all’avvio.

05. Test incrementale

- Motore scollegato > misura V ai morsetti del driver con PWM 30/60/100%.
- Se V è stabile e driver non scalda → il problema è carico (motore duro/ingranaggi).
- Lubrifica/controlla meccanica; prova con un motore “buono”.

Checklist “fatto”

Motore avvia fluido a PWM 30→60→100%.
Driver < 70 °C dopo 2′ di lavoro (dito o termometro IR).
Alimentatore non entra in limit; cavi non scaldano.
GND comune, fili fissati, schema aggiornato con modello driver.

Note didattiche

Mostrare agli studenti foto prima/dopo del cablaggio, la tabella di misure (V/I a step di PWM) e un grafico corrente-tempo allo spunto: è evidente perché alcuni driver scaldano.

Progettare bene, programmare meglio: pseudocodice e diagrammi per sistemi elettronici – lezione 5/5

Lascia una risposta

Ripasso di inizio anno – appunti per la classe.

Di seguito un mini vocabolario, come sempre stampatelo e mettetelo nel tuo quadernone (alcune cose le abbiamo viste anche nella lezione precedente):

Useremo un dialetto semplice.

Una istruzione per riga.
Parole chiave in MAIUSCOLO e con i due punti : quando aprono un blocco:
- SE … ALLORA: … ALTRIMENTI:
- MENTRE (condizione):
- PER i da A a B:
- FUNZIONE nome(parametri): RITORNA valore
Indentazione (rientro) di 2–4 spazi per il contenuto dei blocchi.
Commenti: usa // all’inizio della riga.
Nomi chiari per variabili e costanti: sogliaLuce, tempoGiallo, pinLed.

Mini-vocabolario

IMPOSTA x a 10: assegna un valore
LEGGI x: prendi un input (da Serial o da sensore)
SCRIVI …: stampa (su Serial o su un display)
ATTENDI 500 ms: pausa
ESCI DAL CICLO: interrompi MENTRE o PER
OperatorI: ==, !=, <, >, >=, <=, AND, OR, NOT

Mappa mentale

Pseudocodice	Arduino (C/C++)
`IMPOSTA x a 10`	`int x = 10;` oppure `x = 10;`
`LEGGI da Serial`	`parseInt()/readStringUntil('\n')`
`LEGGI digitale pin`	`digitalRead(pin)`
`LEGGI analogico pin`	`analogRead(pin)`
`SCRIVI su Serial`	`Serial.print()/println()`
`ACCENDI LED`	`digitalWrite(pin, HIGH)`
`SPEGNI LED`	`digitalWrite(pin, LOW)`
`ATTENDI t ms`	`delay(t)`
`PER i da 1 a N:`	`for (int i=1; i<=N; i++) { ... }`
`MENTRE (condizione):`	`while (condizione) { ... }`
`SE / ALTRIMENTI`	`if (...) { ... } else { ... }`
`FUNZIONE`	`tipo nome(params){...}`
`RITORNA`	`return`

Funzioni di aiuto per leggere dal Monitor Seriale

Blocchi riutilizzabili

// ---------------------------
// Aiuti per I/O seriale
// ---------------------------

// Legge un intero dalla Serial (es.: 42, -17).
// Attende che ci siano dati disponibili, usa parseInt()
// e poi "pulisce" il buffer fino al newline '\n' per preparare
// la prossima lettura.
int leggiInt() {
  // Attende finché il buffer seriale è vuoto.
  // Serial.available() restituisce quanti byte sono pronti da leggere.
  while (!Serial.available()) {
    // ciclo di attesa attivo: resta qui finché non arriva almeno 1 byte
  }

  // parseInt():
  //  - salta automaticamente spazi e caratteri non numerici iniziali;
  //  - legge opzionalmente il segno (-);
  //  - si ferma quando incontra un separatore (es. spazio, '\n', ecc.)
  //  - rispetta Serial.setTimeout(): se i numeri arrivano "a pezzi", attende fino al timeout.
  int v = Serial.parseInt();

  // Dopo parseInt possono essere rimasti caratteri nel buffer
  // (ad es. l'utente ha premuto Invio, quindi c'è '\n' o anche "\r\n").
  // Questo while consuma tutto ciò che c'è fino a trovare '\n' e poi esce,
  // in modo da "allineare" la prossima lettura all'inizio della riga seguente.
  while (Serial.available()) {
    // Legge un carattere dal buffer
    if (Serial.read() == '\n') break; // esce quando trova il newline
    // Nota: se volessi trattare anche '\r' come fine riga su sistemi Windows,
    // potresti controllare anche '\r' (carriage return).
  }

  // Restituisce il valore intero letto.
  return v;
}

// Legge una riga di testo fino al newline '\n' e la restituisce come String.
// Esempio di input: "ciao mondo\n" -> "ciao mondo" (senza newline né spazi finali).
String leggiLinea() {
  // Attende che arrivi almeno un byte.
  while (!Serial.available()) {
    // attesa attiva
  }

  // Legge i caratteri fino al delimitatore '\n' (newline).
  // Il newline non viene incluso nella String risultante.
  String s = Serial.readStringUntil('\n');

  // trim():
  //  - rimuove spazi iniziali/finali, tab e ritorni a capo residui.
  //  - Utile se su alcune piattaforme l'invio produce "\r\n" (Windows):
  //    readStringUntil('\n') rimuove '\n', ma può restare '\r' in coda; trim() lo elimina.
  s.trim();

  // Restituisce la riga "pulita".
  return s;
}

Codice senza commenti da copiare ed incollare:

// ——— Aiuti per I/O seriale ———
int leggiInt() {
  while (!Serial.available()) {}
  int v = Serial.parseInt();
  while (Serial.available()) {
    if (Serial.read() == '\n') break;
  }
  return v;
}

String leggiLinea() {
  while (!Serial.available()) {}
  String s = Serial.readStringUntil('\n');
  s.trim();
  return s;
}

Esempi guidati pseudocodice > sketch Arduino

Esempio 01 – Saluto con nome (solo Serial)

Scopo: input/output base, variabili stringa.

Pseudocodice – esempio 01

SCRIVI "Come ti chiami?"
LEGGI nome
SCRIVI "Ciao, " + nome + "!"

Arduino – esempio 01 – con commenti

void setup() {
  Serial.begin(9600);          // Inizializza la seriale a 9600 baud (Monitor Seriale deve avere lo stesso valore).

  while (!Serial) { ; }        // Attende che la porta seriale sia pronta (utile su schede con USB "native", es. UNO R4).
                               // Su UNO R3 spesso non serve, ma non fa danni.

  Serial.println("Come ti chiami?"); // Messaggio iniziale: l’utente vede la richiesta nel Monitor Seriale.

  Serial.setTimeout(60000);    // Imposta il "tempo massimo di attesa" a 60 s per funzioni come readStringUntil/parseInt.
                               // Se l’utente impiega tempo a digitare, la lettura aspetta fino a 60 s prima di rinunciare.
}

void loop() {
  String nome = leggiLinea();  // Legge una riga di testo inserita dall’utente fino al tasto Invio (newline '\n').
                               // Esempio: se scrivo "Michele" e premo Invio, nome = "Michele".

  Serial.print("Ciao, ");      // Stampa senza andare a capo...
  Serial.print(nome);          // ...stampa il nome letto...
  Serial.println("!");         // ...e chiude la riga con il punto esclamativo + newline.

  while (true) {}              // Ferma il programma qui (loop infinito).
                               // Serve per NON chiedere nuovamente il nome in un ciclo senza fine.
                               // Se vuoi che ripeta la domanda, rimuovi questa riga.
}

Arduino – esempio 01 – senza commenti

void setup() {
  Serial.begin(9600);
  while (!Serial) {;}
  Serial.println("Come ti chiami?");
  Serial.setTimeout(60000);
}

void loop() {
  String nome = leggiLinea();
  Serial.print("Ciao, ");
  Serial.print(nome);
  Serial.println("!");
  while (true) {}  // fine
}

Esercizio aggiuntivo: chiedi anche l’età e rispondi “Sei maggiorenne/minorenne”.

Esempio 02 – Blink (LED lampeggiante)

Collegamenti: LED con resistenza su pin 13 (o usa quello onboard).

Pseudocodice – esempio 02

IMPOSTA pinLed a 13
IMPOSTA periodo a 500 ms
MENTRE (vero):
    ACCENDI LED
    ATTENDI periodo
    SPEGNI LED
    ATTENDI periodo

Arduino – esempio 02

const int pinLed = 13;
const int periodo = 500;

void setup() {
  pinMode(pinLed, OUTPUT);
}

void loop() {
  digitalWrite(pinLed, HIGH);
  delay(periodo);
  digitalWrite(pinLed, LOW);
  delay(periodo);
}

Esercizio aggiuntivo: leggi periodo da Serial.

Esempio 03 – Pulsante accende/spegne LED

Collegamenti: pulsante su pin 2, modalità INPUT_PULLUP; LED su pin 8.
Nota: il pulsante chiude a GND (premuto = LOW).

Pseudocodice – esempio 03

IMPOSTA statoLed a SPENTO
MENTRE (vero):
    LEGGI pulsante
    SE (pulsante premuto) ALLORA:
        ATTENDI 20 ms  // anti-rimbalzo semplice
        SE (ancora premuto) ALLORA:
            inverti statoLed
            applica stato al LED
            ATTENDI rilascio

Arduino – esempio 03

const int pinBtn = 2;
const int pinLed = 8;
bool statoLed = false;

void setup() {
  Serial.begin(9600);
  pinMode(pinBtn, INPUT_PULLUP);
  pinMode(pinLed, OUTPUT);
}

void loop() {
  if (digitalRead(pinBtn) == LOW) {  // premuto
    delay(20);                       // debounce base
    if (digitalRead(pinBtn) == LOW) {
      statoLed = !statoLed;  // toggle
      digitalWrite(pinLed, statoLed ? HIGH : LOW);
      // Attendi rilascio
      while (digitalRead(pinBtn) == LOW) {}
      delay(20);
    }
  }
}

Esercizio aggiuntivo: Estensione: stampa su Serial “ON/OFF” ad ogni pressione.

Esercizi

Esercizio 01 – Potenziometro > luminosità (PWM)

Obiettivo: Regolare mediante potenziometro l’intensità luminosa del LED.
Collegamenti: potenziometro su A0; LED su pin PWM 9.

Esercizio 02 – LED ON per 3 secondi quando premo il pulsante

Obiettivo: premo il pulsante > il LED rimane acceso per 3 secondi > poi si spegne.
Evitare ripetizioni mentre si tiene premuto (debounce base).

Componenti & Collegamenti

1 × LED + 1 × resistenza (220–330 Ω) su pin 8 → GND
1 × pulsante su pin 2 con INPUT_PULLUP (l’altro capo del pulsante a GND)

Esercizio 03 — LDR: accendi il LED quando è buio

Obiettivo: leggo la luce con una LDR. Se il valore è sotto una soglia (buio), accendo il LED; altrimenti lo spengo. Stampo i valori su Serial.

Componenti & Collegamenti

LDR in partitore su A0 (esempio: 5V — LDR — A0 — resistenza 10 kΩ — GND)
LED + resistenza su pin 9 → GND

Esercizio 04 – Potenziometro > luminosità LED (PWM)

Obiettivo: con il potenziometro regolo la luminosità del LED usando analogWrite (PWM).

Componenti & Collegamenti

Potenziometro 10 kΩ su A0 (estremi a 5V e GND, cursore ad A0)
LED + resistenza su pin ~9 (pin PWM) > GND

Buon Coding a tutti 🙂

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

Lascia una risposta

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 🙂

Quick References per lo studio – Scrivere una relazione tecnica

Lascia una risposta

Una relazione tecnica ha lo scopo di rendere trasparente e replicabile un lavoro: spiega che cosa è stato svolto, con quali procedure, quali risultati sono emersi e quali conclusioni ne derivano. Il suo primo obiettivo è comunicare: anche un progetto ben fatto, se non è descritto con rigore, di fatto “non esiste” perché non può essere capito, rifatto o proseguito da altri. Per questo contano struttura, sintesi e terminologia accurata.

Nel contesto di laboratorio (elettronica, informatica, scienze), oltre al testo, servono elementi operativi: uno schema disegnato in modo corretto, un bill of materials (BOM – in italiano: lista dei materiali) con caratteristiche, l’indicazione dei punti di misura, i datasheet e le convenzioni di rappresentazione adottate. Questa parte oggettiva permette il debug e facilita eventuali migliorie del prototipo.

La scansione consigliata comprende:

scopo/obiettivi;
materiali e strumenti (con versioni software e tolleranze/portate);
metodo (passi riproducibili e parametri);
risultati (tabelle/figure ordinate con unità e incertezze);
discussione (lettura dei dati, problemi, alternative);
conclusioni;
riferimenti (fonti e datasheet);
allegati eventuali (codice, schemi, CSV).

Criteri di qualità da tenere davanti agli occhi

chiarezza e sintesi: testo breve, ma completo rispetto all’obiettivo;
coerenza dei dati: assi etichettati, unità SI, legenda, stima dell’incertezza;
riproducibilità: parametri, condizioni operative, versioni hardware/software esplicite;
onestà tecnica: limiti, errori e problemi dichiarati e come sono stati gestiti;

Scarica PDF A4 della guida operativa – Apri il sorgente Markdown su GitHub

Se non sai cos’è il Markdown segui il link

---
title: "Relazione tecnica – "
autore: "<classe/nome cognome>"
data: "08.10.2025"
versione: "1.0"
---

## 1) Scopo / Obiettivo


## 2) Materiali e Strumenti
- Componenti/sensori (modello, tolleranze): …
- Strumentazione (portata/risoluzione): …
- Software/Firmware (versioni): …
- Datasheet/Riferimenti: …

## 3) Schema & Configurazione
- Schema elettrico / diagramma (con punti di misura)
- Pin-out / cablaggio / indirizzi (se I²C/SPI)
- Foto del setup (facoltativa ma consigliata)

## 4) Metodo (passi riproducibili)
1) …
2) …
- Parametri: 
- Criteri di accettazione: 

## 5) Risultati (dati ordinati)
- Tabella(i) con unità di misura e incertezze
- Grafici con assi etichettati e legenda
- Eventuali schermate (Serial/oscilloscopio)

## 6) Discussione (interpretazione)
- Cosa mostrano i dati? (trend, anomalie)
- Errori e limiti (strumento, metodo, ambiente)
- Alternative e possibili miglioramenti

## 7) Conclusioni
<2–3 frasi: risposta allo scopo + prossimo passo>

## 8) Allegati
- Codice .ino / script / CSV
- Schema in formato editabile

## 9) Riferimenti
- Datasheet, articoli, pagine web (con data di accesso)

Esempio 1 – Arduino: “Soglia di luce per LED d’allarme”

Scopo

Definire una soglia “luce bassa” per accendere un LED quando l’illuminazione in aula scende sotto il livello utile alla lettura.

Materiali e Strumenti

Arduino UNO, fotoresistenza + R 10 kΩ (divisore), LED + R 220 Ω;
Multimetro (portata 20 V DC, risoluzione 0,01 V);
IDE Arduino 2.3.x; quaderno dati; datasheet fotoresistenza.

Schema & Configurazione

Divisore su A0, LED su D7. Annotati i punti di misura (A0 e Vout LED) sullo schema.

Metodo

Rilevare A0 ogni 200 ms per 60 s in tre condizioni: finestra aperta (giorno), tenda tirata (penombra), luce spenta (buio).
Applicare media mobile su 10 campioni (riduzione rumore).
Proporre una soglia fissa iniziale e verificare falsi allarmi.
Valutare soglia “adattiva” = baseline – Δ (baseline = media primi 5 s).

Risultati

Tabella 1 – Valori medi A0 (0–1023), n=300 campioni per condizione

Condizione	A0 medio	Dev. std	Note
Giorno (finestra)	780	22	alta variabilità
Penombra	430	18	stabile
Buio luce off	120	9	molto stabile

Discussione

La soglia fissa 200 funziona in condizioni estreme, ma è poco sensibile in penombra. Con soglia adattiva (baseline – 250) impostata dopo 5 s, l’attivazione scatta appena la luce cala di circa 30–35% rispetto al livello di partenza, adattandosi a mattino/pomeriggio. Limiti: sensibilità all’orientamento della fotoresistenza e ombre locali (proporre schermatura).

Conclusioni

La soglia adattiva riduce falsi negativi in penombra. Prossimo passo: mappare A0 > lux con calibrazione a due punti e riportare sul grafico unità SI.

Esempio 2 – Fisica: “Verifica della legge del pendolo”

Scopo

Verificare la legge

per piccole oscillazioni, stimando l’errore sperimentale.

Materiali e Strumenti

Filo inestensibile, massa 100 g, metro rigido (±1 mm), cronometro (±0,01 s). Rilevazione su 10 oscillazioni per ridurre l’incertezza di misura.

Metodo

Per ciascuna lunghezza L={0,30, 0,45, 0,60} m:

Misurare il tempo di 10 oscillazioni;
Calcolare

Confrontare T con

con

Risultati

L (m)	t10 (s)	T (s) misurato	T (s) teorico	Δ =	T-Tteo
0,30	11,0	1,10	1,09	0,01	0,9%
0,45	13,4	1,34	1,34	0,00	0,0%
0,60	15,5	1,55	1,55	0,00	0,0%

Grafico consigliato:

Discussione

Scostamento max < 1%: incertezze legate al cronometro e all’angolo iniziale (non perfettamente “piccolo”), attriti trascurati. Possibile miglioramento: fotocellula per misura automatica, media su tre serie per ogni L.

Conclusioni

La legge del pendolo è confermata entro l’errore sperimentale; proporre estensione a grandi ampiezze per osservare le deviazioni.

Qualcomm acquisisce Arduino e presenta UNO Q: AI e Linux nel formato UNO

Lascia una risposta

Comunicato importante per la comunità Arduino

Qualcomm Technologies, Inc. ha reso noto di aver raggiunto un accordo per acquisire Arduino, riferimento mondiale nell’hardware e software open-source. L’operazione accelera la strategia di Qualcomm di mettere le proprie tecnologie edge a disposizione degli sviluppatori. L’iniziativa si aggiunge alle recenti integrazioni di Edge Impulse e Foundries.io, delineando una piattaforma edge full-stack che copre hardware, software e servizi cloud. La chiusura resta soggetta al via libera delle autorità e alle consuete condizioni di closing.

La combinazione tra elaborazione, grafica, computer vision e AI di Qualcomm e la semplicità, accessibilità e community di Arduino promette di moltiplicare la produttività degli sviluppatori nei diversi settori. Arduino manterrà impostazione open e spirito comunitario, aprendo al contempo a un piattaforma completa per lo sviluppo moderno, con UNO Q come primo tassello.

Arduino conserverà brand, strumenti e missione in modo indipendente e continuerà a supportare microcontrollori e microprocessori provenienti da più fornitori. Con l’ingresso nella famiglia Qualcomm, gli oltre 33 milioni di utenti attivi della community avranno accesso allo stack tecnologico dell’azienda e alla sua presenza globale. Start-up, aziende, professionisti, scuole e maker potranno prototipare e validare più in fretta, con un percorso verso il mercato supportato dalle tecnologie Qualcomm e da un ecosistema di partner esteso.

Arduino UNO Q

UNO Q è una single board di nuova generazione con architettura a “doppio cervello”: un microprocessore compatibile Debian Linux accanto a un microcontrollore per il controllo in tempo reale. Basata su Qualcomm Dragonwing™ QRB2210, la scheda è pensata per visione e audio con AI reattivi al contesto, dai sistemi smart home evoluti all’automazione industriale. L’ambizione è renderla lo strumento di riferimento per ogni sviluppatore: versatile, accessibile e adatta a un apprendimento continuo.

Oltre alla piena compatibilità con Arduino IDE e con il classico ecosistema UNO, UNO Q è la prima scheda Arduino supportata da Arduino App Lab, il nuovo IDE integrato che unifica i flussi RTOS, Linux, Python e AI per accelerare sviluppo e distribuzione. App Lab è open-source e progettato per ideare, prototipare e scalare rapidamente soluzioni AI fino alla produzione. L’integrazione nativa con Edge Impulse velocizza l’intero ciclo di vita dei modelli—dalla raccolta di dati reali al tuning e all’ottimizzazione—per casi d’uso come rilevamento di persone/oggetti, anomaly detection, classificazione immagini, riconoscimento suoni ambientali e keyword spotting.

Dichiarazioni

Nakul Duggal (Group GM, Automotive, Industrial & Embedded IoT, Qualcomm Technologies, Inc.):

“Con Foundries.io, Edge Impulse e ora Arduino, acceleriamo la nostra visione di rendere accessibili all’ecosistema globale degli sviluppatori le nostre tecnologie di calcolo e IA più avanzate. Unendo l’ethos open-source di Arduino al portafoglio di Qualcomm, milioni di sviluppatori potranno creare soluzioni intelligenti più rapidamente ed efficientemente, con un chiaro percorso alla commercializzazione.”

Fabio Violante (CEO, Arduino):

“La collaborazione con Qualcomm ci permette di potenziare il nostro impegno su accessibilità e innovazione. UNO Q è solo l’inizio: vogliamo offrire alla community strumenti potenti per un’IA intuitiva, scalabile e aperta a tutti.”

Massimo Banzi (Co-fondatore, Arduino):

“Da semplicità, economicità e community è nato un movimento che ha cambiato la tecnologia. Entrando in Qualcomm, porteremo strumenti di IA d’avanguardia alle persone, restando fedeli ai nostri valori.”

Evento

Per approfondire, segui la diretta “From Blink to Think” del 7 ottobre 2025 alle 7:00 a.m. PT / 16:00 CEST:
https://www.arduino.cc/from-blink-to-think

Fonte: Qualcomm

Esempio – “Il motore non parte e il driver scotta”

Setup

Sintomi

Procedura di diagnosi

Checklist “fatto”

Note didattiche

Related posts:

Mini-vocabolario

Mappa mentale

Funzioni di aiuto per leggere dal Monitor Seriale

Esempi guidati pseudocodice > sketch Arduino

Esempio 01 – Saluto con nome (solo Serial)

Esempio 02 – Blink (LED lampeggiante)

Esempio 03 – Pulsante accende/spegne LED

Esercizi

Esercizio 01 – Potenziometro > luminosità (PWM)

Esercizio 02 – LED ON per 3 secondi quando premo il pulsante

Esercizio 03 — LDR: accendi il LED quando è buio

Esercizio 04 – Potenziometro > luminosità LED (PWM)

Related posts:

Nota sull’origine dei contenuti

Perché Home Assistant a scuola

Cos’è Home Assistant

A chi è rivolta la guida

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

Licenze, privacy e sostenibilità didattica

Esempi di attività “vicine alla vita scolastica”

Ambiente e qualità dell’aria

Sicurezza e accessi

Energia e edificio

Laboratori e didattica operativa

Vita quotidiana d’istituto

Inclusione e benessere

Manutenzione e asset

Come seguire la serie

Related posts:

Esempio 1 – Arduino: “Soglia di luce per LED d’allarme”

Scopo

Materiali e Strumenti

Schema & Configurazione

Metodo

Risultati

Discussione

Conclusioni

Esempio 2 – Fisica: “Verifica della legge del pendolo”

Scopo

Materiali e Strumenti

Metodo

Risultati

Discussione

Conclusioni

Related posts:

Comunicato importante per la comunità Arduino

Arduino UNO Q

Evento

Related posts: