Edge energy engineering
Dalla misura elettrica.
Home Energy Meter trasforma una misura fisica reale in dati storici, progressivi, costi e previsioni attraverso una pipeline edge-first progettata per funzionare localmente e restare osservabile.
Flagship case study di edge engineering
Home Energy Meterdalla misura al forecast.
Sistema edge per monitoraggio energetico domestico che collega misura Modbus, persistenza locale, fasce F1/F2/F3, tariffa, bollette, stima costi e previsione fine mese.
Il case study presenta solo comportamento implementato e validato sul campo. Misure domestiche, dati contrattuali, dettagli LAN e identificativi runtime privati vengono esclusi intenzionalmente.
Problema di engineering
Il monitoraggio energetico diventa utile solo quando misura, contesto e operatività concordano
Un valore istantaneo in watt non basta. Un sistema utile deve sopravvivere agli errori seriali, preservare l’integrità temporale, allinearsi alle letture ufficiali, comprendere le fasce nazionali, modellare le tariffe e restare operabile su un vero host Linux edge.
Sorgente fisica
Le misure arrivano da un PZEM reale via Modbus RTU, non da telemetria sintetica.
Host edge condiviso
Il runtime condivide un Banana Pi con altri workload: CPU, storage e deployment vanno misurati invece che presunti.
Correttezza temporale
Riallineamenti, tariffe e fasce dipendono dalla decorrenza reale; scorciatoie basate sul solo stato corrente corromperebbero lo storico.
Dati domestici privati
Il prodotto usa dati realistici di consumo e bolletta mantenendo informazioni personali e contrattuali fuori dal sorgente.
Architettura
Una pipeline locale dal protocollo di campo all’intelligenza energetica per l’utente
Il misuratore fisico è isolato dietro un collector resiliente. La telemetria normalizzata viene persistita localmente, rollup compatti alimentano API e dashboard e il modello economico resta timestamp-aware per rendere riproducibili anche i cambi tariffari storici.
- 01PZEMMisure elettriche
- 02Collector PythonModbus · retry · recovery
- 03SQLite + rollupStorico raw · F1/F2/F3
- 04FastAPILive · serie · operazioni
- 05Dashboard + Cost EngineCapire · costare · prevedere
Misura e modello dati
Acquisizione a un secondo, progressivi ufficiali e analytics ricostruibili
Il collector interroga il meter ogni secondo, valida la plausibilità delle grandezze elettriche e persiste localmente la telemetria. I calcoli storici distinguono misure raw, energia derivata, offset del contatore ufficiale e rollup compatti.
- Discovery automatica PL2303 e reconnect seriale permettono il recovery anche se Linux assegna un device seriale diverso dopo una riconnessione USB.
- La health del collector espone esplicitamente starting, healthy, degraded e stopped invece di nascondere gli errori di comunicazione.
- L’attribuzione F1/F2/F3 segue Europe/Rome e mantiene separati progressivi ufficiali e contatore energetico del meter fisico.
- Il riallineamento timestamp-aware seleziona un sample di riferimento uguale o precedente all’istante reale della lettura e rifiuta riferimenti troppo lontani.
- Rollup persistenti 5 minuti, 1 ora e 1 giorno rendono gli analytics ricostruibili ed eliminano le scansioni raw 1 Hz dall’hot path principale della UI.
Commissioning e integrità
La baseline ufficiale è un’operazione auditabile, non un semplice pulsante reset
Il passaggio dai dati di test allo storico ufficiale crea un backup, azzera il contatore hardware, rimuove solo la telemetria di test, preserva configurazioni e carichi e registra un primo allineamento timestamped verso il contatore reale.
- Backup prima
- Snapshot SQLite prima del commissioning distruttivo
- Tempo di riferimento
- Istante reale della lettura, non quello del click
- Dati preservati
- Carichi, calibrazioni e configurazione fornitura
- Stato audit
- Preparing → awaiting alignment → completed
Affidabilità e operatività
Il failure handling va dal cavo seriale a systemd e alle prestazioni del browser
Il lavoro di engineering non si ferma all’happy path. Recovery, confini dei servizi, privilegi minimi, diagnosi delle prestazioni e regressioni browser fanno parte del contratto del prodotto.
Recovery seriale
Device assente, errori CRC/protocollo e reconnect degradano la health senza terminare il runtime.
Privilegi minimi
Il processo web non ha sudo generico: può avviare solo helper systemd nominativi per restart, reset e commissioning.
Deployment operativo
Collector, API e updater sono unit systemd versionate con clone production read-only e dati persistenti fuori da Git.
Prestazioni misurate
Latenza cold degli analytics e contesa CPU sono state profilate sull’host reale, portando a rollup persistenti e cleanup degli owner frontend.
Tariffe, bollette e previsione
Il modello economico separa costi deterministici e componenti calibrate
Profili di fornitura, versioni tariffarie e bollette normalizzate sono dati temporali. Il Cost Engine applica la tariffa effettiva all’istante della misura, mentre componenti ricorrenti regolate/fiscali vengono stimate da bollette reali quando non è ancora disponibile un catalogo normativo completo.
Deterministico
Prezzo energia/vendita, quote fisse e quota potenza derivati dalla tariffa versionata.
Calibrato
Componenti ricorrenti rete/oneri e imposte stimate con mediana robusta delle bollette storiche normalizzate.
Escluso dalla proiezione
Bonus, crediti, Canone TV e rettifiche una tantum non vengono trasformati silenziosamente in costi futuri ricorrenti.
Layer prodotto
La UI trasforma i dati di campo in decisioni senza nascondere l’incertezza
Dashboard, consumi, contatore, carichi, grafici tecnici e costi condividono la stessa API locale. Gli analytics pesanti sono caricati in lazy, le richieste vengono deduplicate e il rendering dei grafici è stato più volte auditato sul comportamento reale del browser.
Cosa dimostra
Engineering end-to-end tra hardware, Linux, dati, API, UX e dominio energia
Home Energy Meter dimostra la capacità di trasformare un problema operativo fisico in un prodotto software osservabile: integrazione del protocollo di campo, persistenza, domain modelling, runtime resiliente, performance, deployment e analytics rivolti all’utente devono funzionare come un unico sistema.
- 1 Hz
- cadenza predefinita acquisizione di campo
- 3
- fasce ufficiali F1/F2/F3 modellate
- 5m / 1h / 1d
- rollup analytics persistenti
- edge-first
- il core funziona senza dipendere dal cloud
Stato attuale
Sistema R&D maturo, ancora prima del gate finale V1
L’installazione edge reale è operativa e la catena principale misura→costo è implementata. Restano hardening/soak più estesi, backup/retention/log rotation generali, alcune verifiche sui controlli runtime e l’audit responsive completo. Anche l’accuratezza del forecast va confrontata con futuri periodi di fatturazione completi.
Evidence runtime
Un’interfaccia reale costruita sui dati di campo, non un mockup di dashboard
Queste immagini derivano dall’istanza Home Energy Meter realmente operativa. Prima della pubblicazione sono stati rimossi il browser e sostituiti con dati plausibili i valori, le date, gli identificativi e i nomi di carichi riconducibili all’abitazione.
Nota di pubblicazione: struttura e funzionalità mostrate provengono dal prodotto reale. Valori numerici e dettagli identificativi sono intenzionalmente dati non di produzione.