- Inizio
- Competenze
- IoT ed embedded
IoT, sistemi embedded e videosorveglianza
Progettiamo sistemi che collegano l’informatica al mondo fisico: firmware per microcontrollori, gateway e chioschi su Raspberry Pi, integrazione di inverter, telecamere e dispositivi smart anche senza cloud, analisi video e audio, piccoli robot.
Una parte di questo lavoro nasce in laboratorio: prototipi che girano davvero, tutti i giorni, misurati e documentati, che servono a capire una tecnologia prima di portarla da un cliente. Lo stato di ogni esempio dice quali sono prototipi e quali lavori consegnati.
Firmware per ESP32 e schede di I/O
Scriviamo firmware in C++ per schede ESP32-S3 con ingressi optoisolati e relè: macchine a stati, API REST, MQTT, un cruscotto web servito dalla scheda stessa, aggiornamenti via rete (OTA) e accesso remoto senza aprire porte sul router.
Tecnologie e prodotti
- ESP32-S3
- PlatformIO ed ESP-IDF 5
- I²C e SPI
- MQTT, REST, WebSocket
- OTA
Un esempio
-
Laboratorio Prototipo
Due sorgenti di energia che non devono mai toccarsi
- Il problema
- Commutare i carichi fra rete elettrica e fotovoltaico senza che le due sorgenti vadano mai in parallelo.
- Cosa abbiamo fatto
- Una scheda a 8 ingressi e 8 relè pilota due contattori interbloccati anche meccanicamente, con un timer di stabilità di 15 minuti, il funzionamento manuale come stato di partenza e il ritorno al manuale dopo una perdita del fotovoltaico. L’accesso remoto passa da un tunnel WebSocket in uscita: WireGuard sulla scheda è stato provato e scartato.
- Dove siamo arrivati
- In funzione continua dal maggio 2026; una scheda gemella per il riscaldamento, bloccata in un ciclo di avvio da una revisione rara del chip, è ripartita con un bootloader diverso.
Inverter, batterie e bus seriali
Integriamo apparati di potenza attraverso i protocolli documentati e, dove la documentazione manca, li ricostruiamo misurando: multimetro sui pin, ascolto passivo del bus con verifica del CRC, prove a più velocità. Il componente originale che funziona non si tocca finché l’alternativa non è validata.
Tecnologie e prodotti
- RS-232 e RS-485
- Modbus RTU
- pyserial
- Raspberry Pi
Esempi
-
Laboratorio In corso
Una porta «USB» che era una seriale RS-232
- Il problema
- La porta di servizio di un inverter, marcata come USB, non rispondeva a nessuna prova.
- Cosa abbiamo fatto
- Quattro tentativi falliti (USB device, USB host, seriale TTL, cavo dati), poi il multimetro: −5 V a riposo sul filo dati, cioè RS-232 a tre fili. Sul bus RS-485 fra inverter e batteria, un ascolto passivo con validazione del CRC Modbus ha mostrato che l’inverter interroga 14 indirizzi con una funzione proprietaria.
- Dove siamo arrivati
- Banco di prova definito e decodificatore pronto dalla mappa dei registri del costruttore; il dialogo diretto è ancora in corso.
-
Laboratorio Prototipo
Un cloud del produttore reso stabile
- Il problema
- Nell’attesa del dialogo diretto, i dati arrivavano dal cloud del produttore, che faceva scadere la sessione (127 accessi in due ore) e rinominava i campi.
- Cosa abbiamo fatto
- Autenticazione a token e lettura tollerante, con segnalazione dei campi spariti invece di un valore sbagliato.
- Dove siamo arrivati
- Zero nuovi accessi in nove minuti di prova e nessuna batteria mostrata «allo 0%» per un campo rinominato.
Dispositivi smart senza dipendere dal cloud
Portiamo in rete locale dispositivi nati per app e cloud, con API nostre, e li rendiamo raggiungibili da remoto con tunnel in uscita, senza aprire porte in ingresso.
Tecnologie e prodotti
- Protocollo locale Tuya
- eWeLink OAuth2
- autossh
- aiohttp e systemd
Un esempio
-
Laboratorio Prototipo
Quota del cloud esaurita in due giorni
- Il problema
- La quota gratuita del cloud dei dispositivi finiva in due giorni, a circa 26.000 chiamate al giorno.
- Cosa abbiamo fatto
- Letture accorpate con un tetto mensile e un servizio su Raspberry Pi che usa il protocollo locale, con una connessione aperta per dispositivo; il cloud resta di riserva.
- Dove siamo arrivati
- Quattro dispositivi letti e comandati in locale, collaudo 24 prove su 24, sei comandi su sei dal cruscotto.
Chioschi e pareti video su Raspberry Pi
Usiamo Raspberry Pi come postazioni a schermo intero: immagine configurata da script al primo avvio, browser in modalità chiosco sotto systemd, una guardia che ricarica la pagina, diagnostica dell’uscita video e dell’alimentazione.
Tecnologie e prodotti
- Raspberry Pi e Raspberry Pi OS
- Chromium in modalità chiosco
- Xorg e systemd
- vcgencmd
Un esempio
-
Laboratorio Prototipo
Una parete informativa e il limite della scheda grafica
- Il problema
- Un Raspberry Pi 3 doveva mostrare un portale a 1920×1080, ma il browser era fermo a una versione troppo vecchia.
- Cosa abbiamo fatto
- Reinstallazione con il sistema operativo attuale e Chromium aggiornato; schermo nero all’avvio risolto cambiando driver video; 15 cali di tensione in 26 minuti eliminati con un gruppo di continuità.
- Dove siamo arrivati
- Parete funzionante, e un requisito scritto: la GPU del Pi 3 arriva a WebGL 1, per le mappe interattive serve un Pi 4 o 5.
Telecamere IP, DVR e flussi video
Ripubblichiamo telecamere e registratori, anche vecchi o chiusi, come flussi standard; dimensioniamo frame rate e trasporto sulla banda reale.
Tecnologie e prodotti
- RTSP e HLS
- H.264 e HEVC
- ffmpeg e mediamtx
- SDK dei costruttori
- GStreamer
Esempi
-
Laboratorio Prototipo
Un DVR senza RTSP, ripubblicato come flusso standard
- Il problema
- Un DVR analogico a 4 canali non offriva RTSP, ONVIF né un’interfaccia web.
- Cosa abbiamo fatto
- Con l’SDK del costruttore abbiamo scoperto che il flusso proprietario contiene MPEG-PS con video H.264: copiato senza ricodifica con ffmpeg verso un server RTSP.
- Dove siamo arrivati
- Quattro canali disponibili in RTSP standard (704×576, circa 25 fotogrammi al secondo).
-
Laboratorio Prototipo
Video in ritardo fino a 27 secondi, riportato a 1,5
- Il problema
- Tre telecamere 4K e un videocitofono via VPN arrivavano con 14-27 secondi di ritardo, e il citofono a pezzi.
- Cosa abbiamo fatto
- 10 fotogrammi al secondo alla sorgente a parità di risoluzione e collegamento diretto al posto del relay; per il citofono UDP con una coda di riordino.
- Dove siamo arrivati
- Sulla camera misurata, 10 fotogrammi su 10 letti con 1,5 secondi di ritardo; errori H.264 del citofono da circa 1.600 a 18 ogni tre minuti. Poi il limite è diventato la banda in salita, misurata in circa 11 Mbit/s.
Analisi video e audio
Rilevamento e inseguimento di persone, veicoli e animali su ogni fotogramma, comando autonomo delle telecamere motorizzate, lettura delle targhe e riconoscimento acustico delle sirene, con un portale di notifiche che l’operatore può contestare. Correggiamo anche i componenti open source che usiamo: una nostra patch al ponte video ha fermato una perdita di 2.400 descrittori di file e 80 MB al minuto per client.
Tecnologie e prodotti
- YOLO11 e ByteTrack
- OpenCV
- ONNX
- FastAPI
- MQTT e SQLite
Esempi
-
Laboratorio Prototipo
Un'auto scura in controluce, da invisibile a vista
- Il problema
- Il modello più piccolo non vedeva un’auto scura in controluce.
- Cosa abbiamo fatto
- Scelta misurata del modello e soglie per classe (persona 0,50, veicolo 0,35, animale 0,45); inferenza spostata su una macchina dedicata.
- Dove siamo arrivati
- Da 0 a 205 rilevamenti su 205 fotogrammi; l’inferenza su un fotogramma 4K è scesa da 1.350 a 24 ms.
-
Laboratorio Prototipo
Sirene riconosciute senza reti neurali
- Il problema
- Riconoscere una sirena nel rumore ambientale senza falsi allarmi.
- Cosa abbiamo fatto
- Una regola sullo spettro: il tono deve emergere di almeno 40 dB sul fondo della sua banda per almeno 8 secondi. Prova con sirene sintetiche mescolate a 12,5 minuti di audio reale.
- Dove siamo arrivati
- Zero falsi allarmi e sirena riconosciuta in 8 secondi.
Robotica mobile
Trasformiamo kit robotici in nodi mobili comandabili dalla rete: firmware ESP32 con API a token e aggiornamenti via rete, piccole patch ai microcontrollori di bordo, banchi di prova e simulatori. I movimenti si verificano sui fotogrammi della camera, non sul comando inviato.
Tecnologie e prodotti
- Arduino (AVR) ed ESP32
- avrdude ed esptool
- Giroscopio MPU6050
- WebSocket e OTA
Un esempio
-
Laboratorio Prototipo
Un rover che si spegneva da solo
- Il problema
- Il firmware di fabbrica non comunicava lo stato della batteria (il rover si spegneva senza preavviso) e lasciava i motori accesi se il comando si interrompeva.
- Cosa abbiamo fatto
- Nuovo firmware sull’ESP32 e una patch al microcontrollore di bordo, con la memoria flash al 98%: lettura della batteria, arresto sotto 6,5 V, cane da guardia di un secondo, rotazione guidata dal giroscopio.
- Dove siamo arrivati
- Collaudo 13 su 13; una rotazione comandata di 90° misurata in 86,4°.
Misure di spettro radio (SDR)
Misuriamo lo spettro e l’occupazione dei canali con ricevitori SDR economici, separando i segnali veri dagli artefatti dello strumento.
Tecnologie e prodotti
- RTL-SDR
- rtl_power e rtl_tcp
- numpy e scipy
Un esempio
-
Laboratorio Prototipo
Venticinque trasmettitori che non esistevano
- Il problema
- Una scansione larga dello spettro «trovava» 25 trasmettitori inesistenti.
- Cosa abbiamo fatto
- Erano la curva di guadagno del ricevitore: confronto con una mediana mobile locale ed errore del quarzo stimato, con ripetibilità dichiarata di ±3 ppm.
- Dove siamo arrivati
- Banco di misura affidabile, con i limiti scritti.
SCADA e sistemi industriali
Supporto remoto su sistemi SCADA e HMI: analisi della diagnostica, mappa dell’architettura, runbook e liste di controllo per le ripartenze.
Tecnologie e prodotti
- FactoryTalk View SE e FactoryTalk Linx
- PLC Allen-Bradley ControlLogix e CompactLogix
- EtherNet/IP
- SQL Server Express
- PowerShell e WinRM
Un esempio
-
Impianto industriale Consegnato
Un'HMI bloccata dopo un blackout, per un PC spento
- Il problema
- Dopo un blackout l’HMI si bloccava a ogni avvio; una decina di riavvii non era servita.
- Cosa abbiamo fatto
- Analisi di circa 21.000 record di diagnostica con uno script ed esclusione documentata delle altre cause: due copie del progetto identiche byte per byte, tutti i PLC raggiungibili, licenze e database a posto. La causa: un PC che ospitava un server del sistema distribuito era rimasto spento.
- Risultato
- Riacceso il PC, l’HMI è ripartita. Consegnati il rapporto sull’incidente, la scheda del sistema, il runbook e una lista di controllo per le ripartenze dopo un blackout.