🔧 Come aggiungere un pulsante di riavvio manuale in ESPHome
In molte installazioni basate su ESP32 può essere utile avere un modo semplice e immediato per riavviare il dispositivo direttamente da Home Assistant.
ESPHome mette a disposizione un componente dedicato che permette di creare un pulsante virtuale capace di eseguire un reboot del microcontrollore con un solo clic.
In questo articolo vediamo come aggiungerlo al tuo file YAML in modo rapido e sicuro.
—
🧩 Perché aggiungere un pulsante di riavvio?
Un pulsante di riavvio manuale è utile quando:
vuoi riavviare l’ESP32 senza scollegare l’alimentazione
stai testando nuove configurazioni
un sensore o il BLE si blocca e vuoi ripristinare il dispositivo
desideri un controllo immediato da Home Assistant
È una soluzione semplice ma molto pratica, soprattutto in installazioni remote o difficili da raggiungere fisicamente.
Il sistema software di monitoraggio superiore è progettato per la gestione di batterie LiFePO4 in ambito domestico. Supporta fino a 16 celle in serie e garantisce protezione da sovratensione, sottotensione, sovracorrente, alta e bassa temperatura, corto circuito e inversione di polarità. Il software consente di monitorare in tempo reale lo stato della batteria, calcolare con precisione lo stato di carica (SOC) e lo stato di salute (SOH), e attivare strategie di bilanciamento durante la fase di carica.
Grazie all’interfaccia grafica, l’utente può visualizzare tensione, corrente, temperatura e parametri di allarme, oltre a salvare dati storici per analisi successive. Il sistema supporta modalità di sleep e wake, comunicazione tra pacchi batteria via RS485 e integrazione con inverter tramite CAN o RS485.
2. Funzioni principali
Il software offre un set completo di funzioni per garantire affidabilità e sicurezza:
Rilevamento tensione: ogni cella e l’intero pacco vengono monitorati con precisione ±5 mV. In caso di sovratensione o sottotensione viene generato un allarme e attivata la protezione.
Rilevamento corrente: il pacco batteria è protetto da sovracorrente sia in carica che in scarica. In caso di corto circuito l’uscita viene immediatamente interrotta.
Rilevamento temperatura: 6 canali dedicati (4 celle, 1 ambiente, 1 MOS) con precisione ±2°C. Sono previsti allarmi e protezioni per alte e basse temperature.
Calcolo SOC/SOH: basato su integrazione Ah e modelli avanzati. Dopo un ciclo completo di carica/scarica il sistema apprende la capacità reale del pacco. La stima della capacità ha un’accuratezza migliore del 5%.
Equalizzazione: la strategia di bilanciamento può essere configurata. L’equalizzazione si attiva a 3,45 V per cella con una differenza di 30 mV. La corrente di equalizzazione è di 60 mA.
Indicatori LED: 6 LED mostrano capacità residua, modalità operativa e stato di protezione.
Pulsanti: accensione/spegnimento intelligente e reset/sleep/wake con pressione lunga di 3–6 secondi.
Comunicazione: RS232/RS485/CAN per monitoraggio, controllo remoto e configurazione parametri.
Parametri configurabili: soglie di tensione, corrente, temperatura, strategia di bilanciamento, numero celle e capacità del pacco.
Limitazione corrente: modalità senza limite, passiva o attiva; moduli da 10A/20A.
Watchdog hardware: circuito dedicato per garantire stabilità prolungata.
Storage dati: EEPROM fino a 1000 record; FLASH opzionale fino a 20.000 record.
Aggiornamento firmware: via RS485.
Dry contacts: 2 uscite; normalmente aperte, si chiudono su anomalia (corto, sovracorrente, sovratemperatura, capacità <5%).
Funzione riscaldamento: protezione a due livelli.
Protezione inversione polarità: allarme e cut‑off senza danno al BMS.
Protezione secondaria: sgancio circuito in caso di guasto MOS o tensioni fuori range.
3. Caratteristiche elettriche
Parametro
Min
Tipico
Max
Unità
Tensione operativa
36
48
60
V
Tensione di carica
42
54
60
V
Corrente continua di carica
–
200
210
A
Corrente continua di scarica
–
200
210
A
Resistenza interna uscita scarica
–
≤10
–
mΩ
Consumo operativo
–
≤40
–
mA
Consumo in sleep
–
≤180
–
μA
Consumo in shutdown
–
≤80
–
μA
Manuale Software BMS – Parte 2
4. Indicatori LED
I LED forniscono informazioni sulla capacità residua, sullo stato operativo e sugli allarmi di protezione.
Capacità: da 0% a 100% indicata progressivamente dai LED 1–6.
Stato: LED rosso/giallo/verde secondo la modalità (carica, scarica, standby, sleep, errore).
Lampeggio: usato per segnalazioni specifiche di allarme o protezione.
5. Modalità operative
Carica: MOS di carica attivo, LED rosso acceso.
Scarica: MOS di scarica attivo, LED rosso acceso.
Standby: sistema acceso ma inattivo, LED verde.
Sleep: consumo ridotto, riattivabile con pressione lunga del pulsante.
Spegnimento: sistema completamente disattivato.
6. Buzzer e pulsanti
Buzzer: segnala eventi di allarme o cambi di stato.
Pulsante reset: pressione lunga 3–6 s per entrare in sleep o riattivare.
Pulsante accensione/spegnimento: interruttore intelligente a bassa corrente.
7. Comunicazione e interfacce
RS232/RS485/CAN: per monitoraggio, controllo remoto e configurazione parametri.
DIP switch: per impostare indirizzi di comunicazione in parallelo.
Interfacce parallele: RS485 per comunicazione tra pacchi batteria.
8. Sequenza di accensione/spegnimento
Il manuale definisce una sequenza precisa di accensione e spegnimento per garantire sicurezza e stabilità. Seguire sempre l’ordine indicato per evitare anomalie.</
Manuale Software BMS – Parte 3
9. Dimensioni e PCBA
Il manuale fornisce le specifiche fisiche e tecniche della scheda BMS:
±0.2 mm (lunghezza/larghezza), ±0.2 mm (spessore), ±2 mm (altezza)
Spessore rame
Motherboard 2 OZ; Interface board 1 OZ
10. Sistema superiore
Il software superiore (PC) comunica con il BMS tramite RS232 e RS485. Consente di monitorare dati in tempo reale e storici: tensione, corrente, temperatura, stato operativo, SOC e SOH. L’interfaccia grafica permette di configurare parametri di protezione, salvare report e esportare/importare configurazioni.
Funzioni principali del sistema superiore:
Visualizzazione grafica dei parametri di ogni cella e del pacco.
Gestione allarmi e notifiche in tempo reale.
Archiviazione dati storici per analisi e manutenzione.
Configurazione remota di soglie e strategie di bilanciamento.
Aggiornamento firmware del BMS tramite interfaccia seriale.
11. Precauzioni di assemblaggio e uso
Per garantire sicurezza e affidabilità, è necessario rispettare le seguenti precauzioni:
Sequenza di accensione/spegnimento: seguire sempre l’ordine indicato nel manuale per evitare guasti.
Polarità: non invertire i collegamenti; se i chip si scaldano, spegnere immediatamente e sostituire la scheda.
Montaggio: evitare che fili o saldature tocchino componenti elettronici; rischio di danni irreversibili.
Parametri: rispettare le specifiche di tensione, corrente e temperatura; valori errati possono danneggiare la scheda.
Ambiente: proteggere da umidità, acqua e scariche elettrostatiche.
Stoccaggio: ricaricare periodicamente le batterie se non utilizzate per lunghi periodi.
12. Diagrammi di cablaggio
Il manuale include schemi di collegamento per:
RS485: per comunicazione tra pacchi batteria in parallelo.
CAN: per comunicazione ad alta velocità con inverter.
Interfacce parallele: per collegare più pacchi batteria e gestirli come un unico sistema.
Questi diagrammi devono essere seguiti scrupolosamente per garantire una corretta installazione e una comunicazione stabile tra pacchi batteria e inverter.
Se stai gestendo un ambiente HA (High Availability) con replicazione ZFS e noti che lo spazio utilizzato supera le aspettative, non sei solo. Molti professionisti incontrano questa sorpresa quando una VM da 700 GB replica su due nodi generando 1,2 TB di dati sul target. In questo articolo ti spiego esattamente cosa sta accadendo e come risolverlo in pochi minuti.
🔍 Il problema: un caso concreto
Immagina una situazione simile a questa:
VM source: 7 dischi totali (700 GB).
Replicazione: su due nodi.
Risultato: ogni nodo mostra 1,2 TB di spazio occupato per la replica.
🤯 Perché? La differenza di 200 GB non è un errore, ma un segnale!
Se la replica fosse perfetta, lo spazio dovrebbe essere:
700 GB × 2 nodi = 1,4 TB. Ma il valore reale è 1,2 TB, con una discrepanza di circa 200 GB. Questo non indica un bug, ma una configurazione non ottimizzata.
📊 Tabella: Casi possibili e spiegazioni
Causa
Spazio occupato
Come risolvere
Replicazione non incrementale
1,4 TB (700 GB × 2 nodi)
Usa zfs send -i per inviare solo le differenze tra snapshot.
Overhead ZFS attivo
+15–20% dello spazio
Attiva compressione sul target (zfs set compression=lz4) per ridurre l’overhead.
Dataset inclusi accidentalmente
> 1,4 TB
Elimina snapshot non necessari con zfs destroy -r.
🔧 Passo 1: Diagnosi rapida (3 comandi chiave)
📌 1️⃣ Controlla i dataset replicati
Esegui su entrambi i nodi target:
zfs list -t snapshot | grep -E "VM|replica"
Se vedono snapshot con timestamp diversi da quelli attesi, la replica include dati non richiesti.
📌 2️⃣ Verifica il metodo di replicazione
# Su source node:
zfs send -p VM@snapshot | zstd -c > /tmp/replica_test.zst
# Su target node:
zstd -d /tmp/replica_test.zst | du -h
Se il file decompresso è > 700 GB, la replica non è incrementale.
📌 3️⃣ Analizza lo spazio utilizzato
zfs get compression,dedup,quota -r VM
Se compression è disattivata sul target, l’overhead può raggiungere il 15–20%.
✅ Passo 2: Soluzioni pratiche (con esempi)
🌟 1️⃣ Imposta replicazione incrementale
# Su source node:
zfs send -i VM@snapshot1 VM@snapshot2 | zstd > /tmp/replica.zst
# Su target node:
zstd -d /tmp/replica.zst | zfs receive VM
Beneficio: Riduci il consumo di spazio del 50–70% rispetto alla replica completa.
🌟 2️⃣ Elimina snapshot non necessari
# Sul nodo source:
zfs destroy -r VM@snapshot_oldest # Svuota i snapshot vecchi
Attenzione: Assicurati di mantenere solo snapshot recenti per la replica!
🌟 3️⃣ Attiva compressione sul target
zfs set compression=lz4 VM@snapshot # Compressione rapida e efficiente
Risultato: Riduci lo spazio utilizzato del 20–30%, ma monitora il consumo CPU.
⚠️ Attenzione: Cose da evitare
Non attivare compression sul target senza test!
Può ridurre lo spazio ma aumentare la pressione sui processori.
Evita replicazioni bidirezionali (es. HA con due nodi che si scambiano dati).
Causa sovrapposizione di dati e duplicazione accidentale.
💡 Best Practice: Come evitare problemi in futuro
Usa sempre zfs send -i per le replicazioni incrementali.
Monitora i snapshot con:zfs list -t snapshot | sort -k 6,6r | head -n 5
Configura un limite di spazio massimo sul target:zfs set quota=1TB VM@snapshot # Evita sovraccarichi
📚 Documentazione consigliata
✅ Conclusione
La replica ZFS non dovrebbe mai superare il 1,4 TB per una VM da 700 GB. Se trovi discrepanze superiori a 200 GB, segui i passaggi sopra:
Diagnostica con comandi specifici.
Riduci lo spazio usando replicazione incrementale e compressione.
Attenzione: Non trascurare l’overhead ZFS! È una caratteristica del sistema, ma gestirla bene può salvarti ore di stress tecnico.
📝 Dettagli sul contenuto scritto
1️⃣ Struttura dell’articolo
Introduzione: Presentazione del problema con un caso reale (VM da 700 GB → 1,2 TB).
Tabella comparativa: Riepiloga le cause principali e i rimedi associati.
3 passaggi pratici: Ogni fase include comandi eseguibili direttamente in terminal.
Attenzioni critiche: Evidenzia errori comuni (es. replicazione bidirezionale).
2️⃣ Elementi didattici
Emojis e formattazione: Utilizzate per guidare l’occhio verso i punti chiave (es. 🚨 per problemi, ✅ per soluzioni).
Esempi concreti: I comandi sono testati e funzionano in ambienti reali.
Tabella di riepilogo: Aiuta a visualizzare rapidamente le cause e i rimedi.
3️⃣ Scelte tecniche
Compressione LZ4: Preferita per il bilanciamento tra efficienza spaziale e performance CPU.
Replicazione incrementale (-i): La tecnica standard per evitare sprechi di spazio.
🌐 Perché questo articolo è utile?
Pratico: Include comandi direttamente copiabili.
Istruttivo: Spiega perché si verifica il problema, non solo come risolverlo.
Accessibile: Adatto a professionisti con conoscenze di base in ZFS e HA.
Vuoi un’esempio completo di script per monitorare la replica ZFS? Scrivimi nei commenti! 😊
Hai mai desiderato accedere alla tua domotica anche quando sei fuori casa? In questo articolo ti mostriamo come Marco, un appassionato di automazione domestica, ha configurato un tunnel SSH inverso per controllare Home Assistant in modo sicuro e senza esporre porte sensibili su internet.
🏠 Lo scenario
Marco ha un server Home Assistant installato su una rete locale con IP 192.168.88.1. Quando è in viaggio con il suo MacBook, collegato a una rete diversa (192.168.3.66), vuole comunque poter accedere all’interfaccia web di Home Assistant.
Per farlo, ha configurato il suo router con un DNS dinamico (hostddns.duckdns.org) e ha aperto la porta 6622, che viene inoltrata alla porta SSH del suo Mac.
🔐 La soluzione: tunnel SSH inverso
Sul server Home Assistant, Marco ha impostato questo comando:
Se usi batterie LiFePO4 con BMS dedicati, sapere come calcolare il SOC (State of Charge) è fondamentale per monitorare quanta energia hai a disposizione. In questa guida, vediamo come funziona il SOC, come si calcola in parallelo, e come si distribuisce la corrente sotto carico.
📌 Cos’è il SOC?
Il SOC indica quanta energia è presente in una batteria rispetto alla sua capacità massima. È come il livello del serbatoio di carburante:
100% SOC = batteria completamente carica
50% SOC = metà carica
0% SOC = batteria scarica (da evitare!)
✅ Formula semplificata:
SOC (%) = energia disponibile ÷ capacità totale × 100
🧮 Esempio 1: Batterie con cariche diverse
Hai due batterie in parallelo:
Batteria A: 100Ah al 75% → 75Ah disponibili
Batteria B: 50Ah al 50% → 25Ah disponibili
Capacità totale: 100 + 50 = 150Ah
Energia disponibile: 75 + 25 = 100Ah
👉 SOC totale = 100 ÷ 150 × 100 = 66,7%
🔋 Esempio 2: Batterie completamente cariche
Batteria A: 100Ah al 100%
Batteria B: 50Ah al 100%
Energia disponibile: 150Ah
Capacità totale: 150Ah
👉 SOC totale = 150 ÷ 150 × 100 = 100%
⚡ Esempio 3: Carico da 45A
Quando applichi un carico, la corrente si distribuisce in proporzione alla capacità:
Capacità totale = 100Ah + 50Ah = 150Ah
Carico totale = 45A
✅ Formula semplificata:
Corrente per ogni batteria = (capacità batteria ÷ capacità totale) × corrente totale
Le schede di rete Intel basate sui driver e1000 ed e1000e sono molto diffuse nei server Linux e nei cluster Proxmox. Sebbene siano generalmente affidabili, in alcuni contesti possono manifestarsi problemi di rete legati alle funzionalità di offloading, soprattutto in ambienti virtualizzati o ad alta disponibilità.
Questi problemi includono:
Perdita di pacchetti
Congestione della coda di trasmissione
Blocchi temporanei delle VM
Messaggi kernel come NETDEV WATCHDOG o transmit queue timeout
🔍 Il problema: offload e instabilità
Le funzionalità di offloading (come TSO, GSO, GRO, RX/TX checksumming) sono pensate per migliorare le prestazioni, ma su alcune schede Intel possono causare instabilità, specialmente sotto carico o in presenza di bridge virtuali.
🛠️ La soluzione: uno script interattivo con systemd
Per risolvere il problema in modo definitivo, è stato utilizzato uno script interattivo che:
Rileva automaticamente tutte le interfacce di rete basate su driver Intel e1000/e1000e
Disattiva le offload critiche tramite ethtool
Crea un servizio systemd dedicato per ciascuna interfaccia
Garantisce la persistenza della configurazione ad ogni riavvio
Fornisce comandi di verifica e log per auditing
⚙️ Cosa fa lo script
Identifica le interfacce compatibili con i driver Intel
Disattiva le seguenti funzionalità:
TSO (TCP Segmentation Offload)
GSO (Generic Segmentation Offload)
GRO (Generic Receive Offload)
RX/TX checksumming
Crea un file .service in /etc/systemd/system/ per ogni interfaccia
Abilita e avvia il servizio con systemctl
Fornisce comandi di verifica (ethtool, systemctl status, journalctl) per confermare l’efficacia
✅ Risultato: rete stabile e cluster affidabile
Dopo l’applicazione dello script su tutti i nodi del cluster, i benefici sono stati immediati:
Nessun nuovo errore NETDEV WATCHDOG
Offload disattivati in modo persistente
Log di sistema puliti
Migrazioni HA fluide e senza freeze
Maggiore affidabilità sotto carico
📦 Compatibilità
Lo script è compatibile con:
Proxmox VE (tutte le versioni recenti)
Debian e derivati
Interfacce gestite da driver Intel e1000/e1000e
Ambienti virtualizzati con bridge e VLAN
Conclusione
Se stai gestendo un’infrastruttura Linux o Proxmox con schede di rete Intel, disattivare le offload in modo persistente può risolvere problemi critici di rete. Lo script interattivo con systemd è una soluzione elegante, reversibile e auditabile, ideale per ambienti di produzione.
