Monitorare un Victron SmartSolar con ESP32, ESPHome e Display OLED SSD1306

Integrare un regolatore Victron SmartSolar con un ESP32 permette di ottenere un monitoraggio locale, immediato e completamente personalizzabile dei parametri principali del proprio impianto fotovoltaico. Questo documento descrive un sistema compatto che legge via BLE i dati del Victron, li elabora con ESPHome e li visualizza su un display OLED SSD1306.

Perché usare un ESP32 con ESPHome

L’ESP32 è un microcontrollore economico, potente e dotato di Bluetooth Low Energy. ESPHome semplifica la configurazione e consente di:

  • Leggere i dati via BLE dal regolatore Victron.
  • Inviarli a Home Assistant.
  • Visualizzarli su un display locale.
  • Creare logiche personalizzate.
  • Aggiornare il firmware OTA.

Il display SSD1306

Il display OLED SSD1306 (128×64 pixel) è ideale per visualizzare informazioni essenziali:

  • Consumo ridotto.
  • Ottima leggibilità.
  • Collegamento semplice tramite I2C.
  • Supporto nativo in ESPHome.

Nel progetto vengono visualizzati ciclicamente:

  1. PV Power (W)
  2. Battery Voltage (V)
  3. Battery Current (A)
  4. Stato MPPT

Collegamenti hardware

SSD1306 → ESP32
SDA     → GPIO 21
SCL     → GPIO 22
VCC     → 3.3V o 5V (in base al modulo)
GND     → GND

Codice completo ESPHome


     esphome:
  name: esphome-web-660f74
  friendly_name: Victron 35
  min_version: 2025.11.0
  name_add_mac_suffix: false

esp32:
  variant: esp32
  framework:
    type: esp-idf
    advanced:
      minimum_chip_revision: "3.1"
      sram1_as_iram: true  

logger:
  level: INFO

api:

ota:
- platform: esphome

wifi:
  networks:
    - ssid:xxx
      password: xxx

esp32_ble_tracker:

external_components:
  - source: github://Fabian-Schmidt/esphome-victron_ble

victron_ble:
  - id: MySmartSolar
    mac_address: "de630e81b151"
    bindkey: "9d9701c7ec7acd40e063725bc6ce5591"

sensor:
  - platform: victron_ble
    victron_ble_id: MySmartSolar
    name: "Battery Voltage"
    id: battery_voltage
    type: BATTERY_VOLTAGE

  - platform: victron_ble
    victron_ble_id: MySmartSolar
    name: "Battery Current"
    id: battery_current
    type: BATTERY_CURRENT

  - platform: victron_ble
    victron_ble_id: MySmartSolar
    name: "Yield Today"
    type: YIELD_TODAY

  - platform: victron_ble
    victron_ble_id: MySmartSolar
    name: "PV Power"
    id: pv_power
    type: PV_POWER

  - platform: victron_ble
    victron_ble_id: MySmartSolar
    name: "Load Current"
    type: LOAD_CURRENT

  - platform: wifi_signal
    name: "ESP32 WiFi Strength"
    update_interval: 60s

  - platform: integration
    name: "Solar Energy Produced"
    sensor: pv_power
    unit_of_measurement: "Wh"
    time_unit: h
    accuracy_decimals: 2
    state_class: total_increasing
    device_class: energy

  - platform: uptime
    name: Uptime Sensor
    filters:
      - lambda: return x / 3600.0;
    unit_of_measurement: "h"
    accuracy_decimals: 2

  - platform: internal_temperature
    name: "Temperatura interna"
    update_interval: 60s

  - platform: template
    name: "SOC stimato da tensione"
    id: soc_voltage
    unit_of_measurement: "%"
    accuracy_decimals: 0
    lambda: |-
      float v = id(battery_voltage).state;
      std::string state = id(mppt_state).state;

      // Normalizza in minuscolo
      std::transform(state.begin(), state.end(), state.begin(), ::tolower);

      // 100% SOLO se lo stato è ESATTAMENTE "float"
      if (state == "float" && v >= 54.40) {
        return 100;
      }

      // EVITA 100% fuori dal FLOAT
      if (v >= 54.40) {
        return 99;
      }

      // --- CURVA NORMALE SOTTO 54.40V (tabella LiFePO4) ---
      const int N = 10;
      float v_points[N]   = {54.4, 53.6, 53.1, 52.8, 52.3, 52.2, 52.0, 51.5, 48.0, 40.0};
      float soc_points[N] = {100,  90,   80,   70,   60,   50,   40,   30,   10,   0};

      if (v <= 40.0) return 0;

      for (int i = 0; i < N - 1; i++) {
        if (v <= v_points[i] && v > v_points[i + 1]) {
          float t = (v - v_points[i + 1]) / (v_points[i] - v_points[i + 1]);
          return soc_points[i + 1] + t * (soc_points[i] - soc_points[i + 1]);
        }
      }

      return 0;


binary_sensor:
  - platform: victron_ble
    victron_ble_id: MySmartSolar
    name: "MPPT is in Fault state"
    type: DEVICE_STATE_FAULT

  - platform: victron_ble
    victron_ble_id: MySmartSolar
    name: "MPPT has Error"
    type: CHARGER_ERROR

  - platform: victron_ble
    victron_ble_id: MySmartSolar
    name: "MPPT in FLOAT"
    id: mppt_in_float
    type: DEVICE_STATE_FLOAT

text_sensor:
  - platform: victron_ble
    victron_ble_id: MySmartSolar
    name: "MPPT state"
    id: mppt_state
    type: DEVICE_STATE

  - platform: victron_ble
    victron_ble_id: MySmartSolar
    name: "MPPT Error reason"
    type: CHARGER_ERROR

  - platform: wifi_info
    ip_address:
      name: "ESP32 IP Address"
    ssid:
      name: "ESP32 WiFi SSID"

  - platform: version
    name: "Firmware ESPHome"

output:
  - platform: gpio
    pin: 2
    id: led_ident

switch:
  - platform: output
    name: "LED Identificazione ESP32"
    output: led_ident

button:
  - platform: restart
    id: riavvia_esp
    name: "Riavvia V35 ESP32"

i2c:
  sda: 21
  scl: 22
  scan: true

font:
  - file: "gfonts://Roboto"
    id: my_font
    size: 18

globals:
  - id: lcd_page
    type: int
    restore_value: no
    initial_value: '0'

  # FLAG: SOC pronto
  - id: soc_ready
    type: bool
    initial_value: 'false'

interval:
  - interval: 1s
    then:
      - lambda: |-
          if (!id(soc_ready) &&
              id(soc_voltage).state > 0 &&
              id(battery_voltage).state > 0) {
            id(soc_ready) = true;
          }

  - interval: 6s
    then:
      - lambda: |-
          id(lcd_page)++;
          if (id(lcd_page) > 4) id(lcd_page) = 0;

display:
  - platform: ssd1306_i2c
    model: "SSD1306 128x64"
    address: 0x3C
    lambda: |-
      int page = id(lcd_page);

      if (page == 0) {
        it.printf(0, 0, id(my_font), "PV Power:");
        it.printf(0, 20, id(my_font), "%.1f W", id(pv_power).state);
      }

      if (page == 1) {
        it.printf(0, 0, id(my_font), "Batt Volt:");
        it.printf(0, 20, id(my_font), "%.2f V", id(battery_voltage).state);
      }

      if (page == 2) {
        it.printf(0, 0, id(my_font), "Batt Curr:");
        it.printf(0, 20, id(my_font), "%.2f A", id(battery_current).state);
      }

      if (page == 3) {
        it.printf(0, 0, id(my_font), "MPPT State:");
        it.printf(0, 20, id(my_font), "%s", id(mppt_state).state.c_str());
      }

      if (page == 4) {

        if (!id(soc_ready)) {
          it.printf(0, 0, id(my_font), "SOC in attesa...");
          return;
        }

        float soc = id(soc_voltage).state;
        float vbat = id(battery_voltage).state;

        it.printf(0, 0, id(my_font), "SOC Batteria:");
        it.printf(0, 20, id(my_font), "%.0f %%", soc);
        it.printf(0, 40, id(my_font), "%.2f V", vbat);
      }

Risultato finale

Il display mostra ciclicamente:

  • Potenza PV
  • Tensione batteria
  • Corrente batteria
  • Stato MPPT

Il sistema è autonomo, affidabile e perfetto per monitorare un impianto solare senza aprire Home Assistant.

Spiegazione didattica del funzionamento del codice (ID sensori, globals, interval, display)

1. Perché prima servono gli ID dei sensori

Prima di poter usare un sensore nel display o in una lambda, ESPHome deve sapere come si chiama quel sensore. Questo nome è l’id:.

Senza ID, il display non può leggere il valore del sensore e il codice non compila.

Esempio corretto:

id: battery_voltage


Questo permette al display di usare:

id(battery_voltage).state

Gli ID sono quindi etichette obbligatorie che collegano i sensori al codice del display.

2. La variabile globale `lcd_page`

globals:
  - id: lcd_page
    type: int
    restore_value: no
    initial_value: '0'

Questa variabile è un contatore che indica quale pagina del display deve essere mostrata.

  • `type int → è un numero intero
  • `initialvalue: ‘0’ → parte dalla pagina 0
  • `restorevalue: no → al riavvio riparte da 0

È il “segnalibro” del display.

3. Il timer `interval` che cambia pagina ogni 5 secondi

interval:
  - interval: 5s
    then:
      - lambda: |-
          id(lcd_page)++;
          if (id(lcd_page) > 3) id(lcd_page) = 0;

Ogni 5 secondi:

  1. aumenta `cd_page di 1
  2. se supera 3, torna a 0

È un ciclo continuo:

0 → 1 → 2 → 3 → 0 → …

Questo permette al display di cambiare pagina automaticamente senza pulsanti.

4. La sezione `display` che disegna la pagina corretta

int page = id(lcd_page);

l display legge quale pagina deve mostrare.

Ogni blocco if (page == X) rappresenta una pagina:

  • 0 → PV Power
  • 1 → Battery Voltage
  • 2 → Battery Current
  • 3 → MPPT State

Esempio:

if (page == 0) {
  it.printf(0, 0, id(my_font), "PV Power:");
  it.printf(0, 20, id(my_font), "%.1f W", id(pv_power).state);
}


Il display mostra solo la pagina corrispondente al valore di lcd_page.

📌 Riassunto didattico

  • Prima si definiscono gli ID dei sensori, altrimenti il display non può leggerli.
  • `cd_page è la variabile che tiene memoria della pagina corrente.
  • interval cambia pagina ogni 5 secondi.
  • `isplay legge `cd_page e mostra la pagina giusta.

È un sistema semplice, elegante e molto flessibile.

CPU diverse ! Proxmox cluster .

Quando gestisci un cluster Proxmox, pensi sempre che la parte difficile sia l’hardware, i dischi, la rete… e invece a volte il problema arriva da dove meno te lo aspetti 😄. È quello che è successo a me qualche giorno fa, quando una semplice migrazione live ha iniziato a comportarsi in modo strano. Tutto sembrava procedere bene: la RAM veniva trasferita, il tunnel era attivo, nessun errore evidente. Poi, proprio al momento del passaggio finale, boom… “resume failed – client closed connection”. La VM si spegneva sul nodo di destinazione come se qualcuno avesse tirato la spina 😑.

All’inizio ho pensato a un problema di rete, poi a un bug, poi a qualche servizio bloccato. Ho controllato conntrack, dbus‑vmstate, log di QEMU, journal… niente. Tutto sembrava in ordine. Eppure la migrazione continuava a fallire, sempre verso lo stesso nodo. Una cosa che ti fa grattare la testa e dire “ma che diavolo sta succedendo” 🤨.

La svolta è arrivata quando ho iniziato a guardare non i log, non la rete, ma l’hardware. I miei tre nodi non erano affatto gemelli: uno montava un Intel i5, gli altri due erano Xeon, ma di modelli diversi. E lì ho avuto l’illuminazione 💡. Anche se sono tutte CPU Intel, non condividono lo stesso set di istruzioni. Alcune hanno AVX2, altre no. Alcune hanno AES‑NI, altre lo gestiscono in modo diverso. E quando una VM è configurata con “cpu: host”, Proxmox espone al guest tutte le istruzioni della CPU fisica del nodo sorgente. Se il nodo di destinazione non le supporta, la migrazione live non può funzionare. È come cercare di far ripartire un motore diesel su un’auto a benzina… non succederà mai 😅.

A quel punto tutto aveva senso. QEMU provava a ripristinare lo stato della CPU sul nodo target, trovava un’istruzione non supportata e chiudeva la connessione. Da qui l’errore “resume failed”. Una cosa che sembra misteriosa finché non guardi il quadro completo.

La soluzione, alla fine, è stata sorprendentemente semplice 😊. Ho cambiato il modello CPU della VM da “host” a “x86‑64‑v2”, un modello più portabile che espone solo le istruzioni comuni a tutte le CPU moderne. In pratica, un linguaggio CPU che tutti i nodi del cluster capiscono senza problemi. Dopo aver applicato questa modifica, la migrazione live ha iniziato a funzionare immediatamente, senza errori, senza spegnimenti improvvisi, senza sorprese. Una sensazione di sollievo incredibile 😌.

Se tutti i nodi supportano AES‑NI, si può anche usare “x86‑64‑v2‑AES”, che offre un piccolo vantaggio prestazionale. Chi vuole mantenere performance elevate può provare “host‑model”, che è più compatibile di “host” ma comunque non perfetto in cluster molto diversi. “qemu64” resta l’opzione più portabile in assoluto, ma oggi è troppo limitante per la maggior parte dei carichi.

Alla fine, questa esperienza mi ha ricordato una cosa importante: in un cluster eterogeneo, la compatibilità CPU è fondamentale. Se incontri errori di migrazione live come “resume failed”, non farti ingannare da log strani o messaggi fuorvianti. A volte la risposta è molto più semplice: i nodi parlano lingue diverse, e basta scegliere un modello CPU che tutti capiscono per riportare la pace nel cluster 🚀.

ESP32 vs Arduino: quando scegliere cosa (e perché)


Per chi si avvicina al mondo IoT o microcontrolli, le due piattaforme più citate sono Arduino e ESP32. Entrambe costano poco e offrono molta flessibilità, ma hanno punti di forza molto diversi. In questo articolo vediamo come e quando l’ESP32 “prende il sopravvento” rispetto ad Arduino in molti progetti moderni.


1. Cosa sono (breve ripasso)

  • Arduino: una piattaforma open-source basata su varie schede, tipicamente con un microcontrollore AVR (es: ATmega328P nel classico Uno).
  • Facile da programmare (IDE semplice, librerie abbondanti)
  • Ottimo per progetti didattici e semplici interfacce fisiche.
  • ESP32: un chip System-on-Chip (SoC) con:
  • CPU dual-core a 240 MHz
  • Wi-Fi + Bluetooth integrati
  • Più RAM e flash del classico Arduino Uno
  • Supporto per RTOS (FreeRTOS), filesystem, stack TCP/IP.

2. Le differenze chiave in pratica

Ecco come si traducono queste caratteristiche in situazioni reali:

a) Connettività

  • Arduino di base ha solo porte I/O e seriale. Per Wi-Fi o Bluetooth serve un modulo esterno (ESP8266, BT42), che complica cablaggi e dipendenze software.
  • ESP32: Wi-Fi + BT integrati. Questo semplifica enormemente progetti IoT: sensori remoti, home automation, nodi mesh wireless, etc.

b) Potenza di calcolo e memoria

  • Un ESP32 ha tipicamente 4–8 MB di RAM e ~512 KB di flash.
  • L’ESP32 può gestire protocolli pesanti (MQTT, HTTP/HTTPS), server web embedded, caching in memoria e più eventi concorrenti senza bloccarsi.
  • Su un Arduino Uno con ATmega328P la RAM è piccolissima (circa 2 KB) e flash limitata (32 KB): si fanno a pezzi anche programmi medi.

c) Architettura e OS

  • Arduino usa loop infinito (setup(), loop()) che può diventare un collo di bottiglia in progetti complessi.
  • ESP32 supporta RTOS: puoi definire task multipli (es: uno per Wi-Fi, uno per sensori, uno per l’UI) e pianificarli indipendentemente.

d) Flessibilità hardware

Entrambi usano GPIO, SPI, I²C, ADC/DAC.
Le differenze sono più nelle capacità extra dell’ESP32:

  • Più canali di ADC (spesso 12 bit).
  • Periferiche avanzate: USB OTG, CAN bus, ecc.
  • Supporto per touch screen capacitivi integrato su alcune schede ESP32.

3. Dove l’ESP32 è più “diffuso” e perché

Ecco alcuni esempi concreti in cui l’ESP32 ha quasi sostituito Arduino:

  1. Progetti IoT semplici (misuratori di temperatura/umidità Wi-Fi, interruttori remoti)
  • ESP32 è “out of the box”: basta scrivere il codice e si connette senza moduli extra.
  1. Home automation / domotica fai-da-te
  • Nodi Zigbee o Z-Wave via Wi-Fi/BT (ESP32 + firmware compatibile).
  • Pannelli di controllo touchscreen integrati.
  1. Wearable e dispositivi connessi a basso costo
  • Smartwatch, tracker fitness DIY, smartwatch con BT audio: ESP32 offre potenza e radio in un unico chip.
  1. Server web embedded / AP personalizzati
  • Access point Wi-Fi che serve una pagina web per configurazione o controllo (es: router mesh personalizzato).
  • Server HTTP leggero per dashboard interne su LAN.
  1. Prototipazione rapida di applicazioni complesse
  • Con RTOS e librerie TCP/IP, ESP32 permette di simulare piccoli server o client senza PC intermediario (ottimo per test IoT).

4. Arduino resta rilevante dove l’ESP32 è “troppo”

Ci sono ambiti in cui Arduino è ancora una scelta migliore:

  • Semplicità estrema
  • Per progetti educativi o didattici, la versione base (Uno/Nano) è più chiara e meno sovraccarica.
  • Basso costo per alta produzione senza connettività
  • Se ti servono centinaia di nodi che leggono un solo sensore via seriale e non Wi-Fi, un Arduino Nano resta spesso più economico.
  • Ambienti industriali legacy o certificati
  • In alcuni contesti si preferiscono microcontrollori con una storia lunga e supporti certi (es: ATmega), anche se meno potenti.

5. Conclusione: “Quando scegliere cosa”

  • Scegli ESP32 se ti serve:
  • Connettività Wi-Fi + BT integrata
  • Più potenza di calcolo e memoria (per protocolli, GUI, RTOS)
  • Flessibilità per IoT, server embedded, wearable complessi.
  • Scegli Arduino se ti serve:
  • Semplicità didattica estrema
  • Bassissimo costo per progetti semplici senza Wi-Fi/BT
  • Ambiente consolidato e ben documentato per elettronica base.

In pratica: la maggior parte dei nuovi progetti IoT, wearable, smart home, dashboard embedded e prototipi veloci finiscono usando ESP32 al posto di Arduino “puro” proprio per via della connettività e delle risorse extra in un unico chip a basso costo.

ZFS + Proxmox: un mix potente per storage enterprise-grade 🛠️

ZFS (Zettabyte File System) è molto più di un filesystem; è un sistema di storage completo che offre data integrity, pooling flessibile, snapshot efficienti e RAID integrato. Insieme a Proxmox Cluster, ZFS crea una piattaforma solida per virtualizzazione aziendale.

Qui vediamo perché ZFS conviene su Proxmox, quali compromessi ci sono e come configurarlo in modo pratico.


Perché scegliere ZFS? 🧐

1. Data integrity senza pari

  • Checksum a livello di blocco: ZFS calcola e verifica checksum per ogni blocco fisico.
  • Auto-correzione: se un disco si corrompe, ZFS ripristina i dati da ridondanza (mirror, RAIDZ).
  • Zero write-through cache: anche in caso di crash improvviso, le scritture in memoria vengono sempre riportate su disco prima che l’OS segnali il completamento.

In pratica: probabilità minima di data loss dovuta a bit rot o errori hardware.

2. Pooling flessibile e espansibile

  • ZFS raggruppa più dischi fisici (o SSD) in un pool.
  • Puoi aggiungere/rimuovere dischi senza ripartizionare tutto, solo espandendo il pool.
  • Possibilità di avere diversi dataset all’interno dello stesso pool:
    • Ciascuno può avere quota, snapshot policy, compressione e RAID type differenti.

Ideale per ambienti misti (OS/VM + librerie media + backup).

3. Snapshot e rollback rapidi

  • Le snapshot sono copy-on-write: inizialmente puntano ai blocchi esistenti; cambiano solo quelli modificati.
  • Creazione quasi istantanea, con impatto minimo sulle performance (anche su HDD).
  • Serve per backup point-in-time, test software senza paura e rollback in caso di problemi.

Ottimo per VM: puoi fare snapshot prima di upgrade OS o patch e ripristinare rapidamente se qualcosa va storto.

4. RAID integrato ed efficiente

  • ZFS offre RAIDZ (RAID5), RAIDZ2 (RAID6) e RAIDZ3, che combinano ridondanza e capacità in modo flessibile.
  • In pratica: puoi avere 1/2/3 disco(i) di spare per rebuild e protezione dati.
  • Opzione mirror per prestazioni superiori, soprattutto con SSD.

Questo toglie la necessità di hardware RAID (anche se può coesistere).


Proxmox Cluster + ZFS: un matrimonio ideale 🤝

Proxmox Cluster si basa su Ceph o, più comunemente in ambienti piccoli/medi, su storage locale condiviso via NFS/iSCSI. Usare ZFS qui porta benefici concreti:

  • Storage locale per VM:
    • Ogni node ha il proprio pool ZFS con mirror/RAIDZ.
    • Le VM si “vedono” come dischi locali ad alte prestazioni.
    • Cluster è resiliente a guasti singoli (anche di nodo).
  • Facilità di espansione e gestione:
    • Aggiungi dischi ai node uno alla volta, senza downtime.
    • Proxmox usa ZFS via API per gestire snapshot e clonazione VM.
  • Ottimizzazione delle risorse:
    • ZFS può usare cache SSD per accelerare I/O su HDD (L2ARC).
    • Dataset possono avere compressione (LZ4) e deduplicazione (se le esigenze lo giustificano).

Pro e contro di ZFS su Proxmox ⚖️

Pro:

  • Data integrity eccellente.
  • Pool flessibili e scalabili.
  • Snapshot e rollback rapidi, ottimi per VM.
  • RAID integrato che spesso sostituisce hardware RAID dedicato.
  • Integrazione nativa con API Proxmox (gestione snapshot, clonazione).

Contro:

  • Consumo di RAM: ZFS usa memoria per ARC (cache in RAM), L2ARC (SSD cache) e dataset metadata; 8–32 GB di RAM è il minimo ragionevole per pool significativi.
  • Write amplification con SSD: anche se ottimizzata, la scrittura su SSD può consumare più TBW del previsto, soprattutto con RAIDZ/mirror e TRIM disabilitato.
  • Complessità concettuale: ZFS ha molti concetti (pool, vdev, dataset, quota) che richiedono tempo per padroneggiare.

Come configurare ZFS + Proxmox Cluster in pratica ⌨️

Per semplicità assumiamo due node con storage locale condiviso via NFS.

1. Aggiungi dischi ai node

  • Assicurati che i nuovi HDD/SSD siano non-RAIDed e visibili nel BIOS.
  • Nel GUI di Proxmox, vai a Disks -> Add e seleziona il disco.

2. Crea lo ZFS pool via CLI (esempio) Per due dischi da 4 TB su ogni node:

# Esempio con mirror (performance)
zpool create -o ashift=128k \
              -O raidz2,relativedegrade=adaptive \
              data /dev/disk/by-id/..._SATA...*

# Oppure RAIDZ3 per più resilienza su 4+ dischi:
zpool create -o ashift=128k \
              -O raidz3,relativedegrade=adaptive \
              data /dev/disk/by-id/..._SATA...*

# Poi crea dataset per le VM (con quota):
zfs create -o quota=400G data/vms

ashift=128k è ottimale per dischi moderni; relativedegrade=adaptive aiuta a mantenere prestazioni durante rebuild.

3. Condividi il pool via NFS

  • Sul nodo master:zfs export -o nfs_server=4,nfs_port=111 data/vms systemctl restart nginx # Proxmox usa Nginx per NFS
  • Sui node worker, in Datacenter -> Storage:
    • Aggiungi uno storage di tipo NFS.
    • Usa l’indirizzo del master e il path a data/vms (o al pool root).

4. Configura Proxmox per usare lo storage ZFS

  • In Datacenter -> Storage: imposta il nuovo NFS come provider per:
    • CD/DVD
    • HDD
    • SSD
    • Backup
  • Aggiungi VM o template e scegli questo storage.

Best practices per ZFS + Proxmox 🚀

  1. RAM adeguata: minimo 8–32 GB per pool di decente capacità.
  2. Cache SSD (L2ARC): aggiungila su dataset pesanti in I/O se hai dischi costosi e RAM limitata; altrimenti, HDD cache è più conveniente.
  3. Monitoraggio continuo: usa zpool status e Proxmox metrics per rilevare problemi precocemente.
  4. Trim periodico su SSD: abilita TRIM (tramite cron) per mantenere buone performance nel tempo.
  5. Snapshot policy sensata: automatizza snapshot regolari, ma non esagerare; ZFS conserva i dataset più recenti e le loro snapshot finché c’è spazio libero.

Conclusione 💯

ZFS è una scelta eccellente per Proxmox Cluster se cerchi:

  • Protezione dati affidabile (checksum e auto-correzione).
  • Flessibilità nel pooling e nella gestione dello storage.
  • Integrazione nativa con snapshot e clonazione VM.

I compromessi (RAM, write amplification su SSD) sono gestibili con una configurazione attenta e hardware adeguato. Se stai progettando un cluster Proxmox per uso aziendale o semi-aziendale, ZFS è quasi sempre la strada da seguire.

Ancora Vlan !!!

VLAN: la guida semplice per segmentare la tua rete (e perché dovresti farlo) ⚠️

Le VLAN (Virtual LAN) ti permettono di raggruppare computer sulla stessa rete fisica ma logicamente separati, come se avessi più reti diverse in un unico cablaggio. Ideale per uffici, scuole o anche per separare IoT e dispositivi personali a casa. Vediamo cosa sono e come funzionano!


Cos’è una VLAN? 🤔

Immagina il tuo switch di rete come un incrocio: tutti i cavi portano al centro. Senza VLAN, tutto quello che viene trasmesso su un collegamento (un “broadcast”) arriva a tutte le porte. Se c’è un dispositivo che manda traffico broadcast troppo spesso, può rallentare la rete per tutti.

Una VLAN crea dei “compartimenti” logici all’interno del tuo switch:

  • Dispositivi in VLAN diverse non si vedono direttamente tra loro (a meno che tu non lo configuri esplicitamente).
  • Broadcast rimangono confinati nella stessa VLAN, riducendo la congestione.

In pratica, più reti virtuali su un unico hardware fisico. 💪


Perché usare le VLAN? ✅

1. Sicurezza e isolamento

  • Separa PC dipendenti da server sensibili o dispositivi IoT.
  • Se una VLAN viene compromessa (es: Wi-Fi per ospiti), il danno è limitato a quella VLAN.

2. Gestione della rete più semplice

  • Raggruppa reparti (Contabilità, Vendite, HR) in VLAN separate.
  • Applica politiche di sicurezza e QoS diverse per ogni gruppo senza cambiare la cablatura.

3. Flessibilità e scalabilità

  • Sposta utenti tra uffici senza ripassare i cavi: basta cambiare l’assegnazione della VLAN al dispositivo o al port.
  • Aggiungi nuovi reparti, ospitati virtualmente (VM) o su server diversi, assegnandoli a nuove VLAN.

4. Ottimizzazione delle risorse di broadcast

  • Riduci il traffico broadcast complessivo, soprattutto in reti grandi.

Come funzionano dietro le quinte? ⚙️

Per far funzionare tutto questo, si usa IEEE 802.1Q, uno standard che aggiunge un “tag” speciale al frame Ethernet:

  • Il tag è un numero di 4 bit (chiamato VLAN ID), compreso tra 0 e 4095.
  • Lo switch guarda questo tag per decidere in quale VLAN mettere il traffico.
  • Dispositivi che non supportano 802.1Q vedono solo le VLAN configurate su di loro (o sul port).

Layer 2 vs Layer 3: cosa cambia?

  • Switch Layer 2 si limitano a fare forwarding in base al tag 802.1Q.
    • Ogni porta può essere assegnata a una o più VLAN.
    • Routing tra VLAN deve essere fatto da un router (o switch layer 3) con interfacce virtuali (SVI – Switch Virtual Interfaces).
  • Switch Layer 3 possono fare routing anche tra VLAN senza bisogno di router esterni.
    • Hanno SVI per ogni VLAN che fungono da router logiche.

Esempio pratico: configurazione base su switch

Prendiamo uno switch Layer 2 con porte 1–4 e 5–8, e vogliamo creare due VLAN: 10 (Uffici) e 20 (Ospiti).

Configurazione tipo:

interface GigabitEthernet0/1
 description Ufficio-PC1
 switchport mode access
 switchport access vlan 10

interface GigabitEthernet0/2
 description Ufficio-PC2
 switchport mode access
 switchport access vlan 10

interface GigabitEthernet0/3
 description Ospite-Laptop
 switchport mode access
 switchport access vlan 20

interface GigabitEthernet0/4
 description Ospite-Smartphone
 switchport mode access
 switchport access vlan 20

# VLAN config globale (spesso automatico, ma a volte serve)
vlan database
  range 1006 to 1023 default yes

Con questo:

  • PC1 e PC2 sono nella VLAN 10.
  • Laptop e smartphone in quella degli ospiti.
  • Se un PC della VLAN 10 manda traffico broadcast, lo vedono solo i dispositivi della stessa VLAN.

Riepilogo rapido delle VLAN ⏱️

CaratteristicaDescrizioneVantaggio principale
Cos’èRaggruppamento logico di porte su uno switchIsolamento, sicurezza
Tecnologia chiaveIEEE 802.1Q (tagging)Identifica a quale VLAN appartiene un frame
Broadcast domainRidotto alla singola VLANMeno congestione e miglior performance
Layer 2/3L2 = forwarding; L3 = routing tra VLANFlessibilità nella rete

Possibili insidie e come evitarle 🚧

  • Routing non configurato: se le VLAN devono comunicare, serve un router (o switch layer 3) con SVI.
    • Soluzione: abilita routing inter-VLAN sullo switch o usa un router/firewall per traffico tra VLAN.
  • Porte in VLAN multiple (trunk): possono creare loop o confusione se mal gestite.
    • Soluzione: usa STP/RSTP e configura correttamente le trunk ports (allowed vlan list).
  • Sovrapposizione di ID VLAN: due switch che usano lo stesso ID VLAN per scopi diversi creano conflitti.
    • Soluzione: pianifica bene gli ID VLAN in anticipo e documenta l’uso.

FAQ sulle VLAN ❓

  1. Le VLAN rallentano la rete? No, se ben configurate. Il traffico inter-VLAN (che passa per router/L3) può introdurre latenza, ma il routing interno alle VLAN è veloce.
  2. È possibile avere una VLAN “pubblica” e una privata su un unico switch? Sì: puoi assegnare una VLAN a tutti i port inaccessibili agli ospiti (es: 10), e un’altra solo a pochi port o wireless per gli ospiti (es: 20).
  3. Le VLAN funzionano anche con Wi-Fi? Assolutamente! I punti di accesso (AP) possono essere configurati per assegnare SSID diversi a VLAN diverse, creando reti separate (es: “ospiti” vs “aziendali”).
  4. Serve hardware speciale per usare le VLAN? No; la maggior parte degli switch moderni supporta 802.1Q e VLAN. L’unica cosa che cambia è la configurazione, non l’hardware.

Conclusione ✨

Le VLAN sono uno strumento potente e relativamente semplice per:

  • Migliorare la sicurezza della rete segmentando il traffico.
  • Ottimizzare le performance riducendo i broadcast in eccesso.
  • Aumentare la flessibilità per gestire nuovi dispositivi e reparti senza cambiare la cablatura fisica.

Aggiungere un Pulsante di Riavvio Manuale in ESPHome per ESP32

🔧 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.

✅ Codice YAML del pulsante di riavvio

Aggiungi questo blocco nel tuo file ESPHome:

button:
  - platform: restart
    id: riavvia_esp
    name: "Riavvia ESP32"

Questo crea un pulsante visibile in Home Assistant che, quando premuto, riavvia immediatamente il dispositivo.

🔍 Come funziona?

  • platform: restart è un componente ufficiale ESPHome
  • il pulsante appare automaticamente tra i dispositivi dell’ESP32 in Home Assistant
  • premendolo, l’ESP esegue un reboot pulito
  • non richiede configurazioni aggiuntive o dipendenze

È uno dei metodi più affidabili e compatibili con tutte le versioni moderne di ESPHome.

🎯 Conclusione

Aggiungere un pulsante di riavvio manuale è un modo semplice per migliorare la gestione del tuo ESP32.

È immediato, stabile e perfettamente integrato con Home Assistant, ideale sia per debugging che per manutenzione ordinaria.