community italiana di domotica personale
 
Aggiornamento 2026.4 per ESPHome: miglioramento delle prestazioni, nuovi componenti ed altro!
Aggiornamenti, News

Aggiornamento 2026.4 per ESPHome: miglioramento delle prestazioni, nuovi componenti ed altro!

 , , , , ,

ESPHome - Logo v2

Dopo qualche mese di silenzio ESPHome, il sempre più apprezzato firmware per dispositivi basati su SOC ESP32/ESP8266 per l’uso in ambito di domotica personale si aggiorna con una nuova release. La nuova versione 2026.4.x, quella di aprile 2026, la quale porta con sé una serie di novità, correzione bug, nuove logiche e qualche nuovo componente e servizio supportato.

Alcuni nostri progetti basati su questo firmware:

ESPHome 2026.4

Come è noto, il progetto ESPHome segue molto da vicino (com’è normale, dato che organizzativamente ne fa parte) lo sviluppo dell’HUB per domotica personale open source Home Assistant. In pratica, ESPHome è una delle sue “braccia armate hardware”, sebbene possa essere utilizzato, a prescindere, in altre decine di contesti diversi.

Overview

ESPHome 2026.4.0 introduce importanti miglioramenti di prestazioni e affidabilità su tutte le piattaforme. I dispositivi ESP32 utilizzano ora di default la frequenza CPU massima (operazioni API fino al 33% più veloci), sbloccano 40KB aggiuntivi di IRAM, supportano verifica OTA firmata e tabelle di partizione personalizzate.

ESP8266 riceve un crash handler allineato a ESP32 e RP2040, mentre una nuova architettura di logging lato client consente una pubblicazione dei sensori fino a 46 volte più veloce, spostando la formattazione dei log fuori dal dispositivo.

L’inoltro delle advertisement del Bluetooth Proxy (percorso critico) scende a circa l’1,8% del tempo del loop principale su ESP32-C3. Inoltre, 31 pull request preparano il codice per ESP-IDF 6.0 e l’infrastruttura di benchmarking CodSpeed intercetta regressioni di prestazioni prima del rilascio.

Il sistema di substitutions è stato riprogettato, consentendo un caricamento della configurazione fino a 18 volte più rapido con supporto a percorsi dinamici !include. Il supporto Ethernet si espande con 5 nuovi chip su ESP32 e RP2040, mentre gli espansori GPIO introducono gestione tramite interrupt, riducendo il traffico I2C in idle fino al 99,7%.

La release include inoltre LVGL v9.5.0, supporto nativo per il controllo clima Mitsubishi CN105, 4 nuovi componenti sensore e il nuovo comando CLI esphome bundle per facilitare la compilazione remota. 

Checklist pre-aggiornamento

  • Se si utilizza LVGL con rotazione configurata nel componente display, spostare l’impostazione rotation nel blocco lvgl: e rimuovere touchscreen transform:.
  • Se si utilizza il media player i2s_audio, migrare al componente speaker (il media player i2s_audio è stato rimosso).
  • Se è presente use_legacy nella configurazione i2s_audio, rimuoverlo (il driver I2S legacy è stato eliminato).
  • Se si utilizzano dispositivi ESP32/S2/S3/C5 alimentati a batteria, aggiungere cpu_frequency: 160MHZ nella configurazione (il valore predefinito è ora 240MHz).
  • Se due chiavi YAML risolvono allo stesso nome dopo le substitutions, considerare che ora prevale l’ultima definizione (“last writer wins”).
  • Se si utilizza sen5x con voc_baseline, rimuoverlo (codice non funzionante); utilizzare invece store_baseline: true.
  • Se si utilizza rp2040_pio_led_strip con chipset: CUSTOM, specificare esplicitamente i parametri bit0_high, bit0_low, bit1_high, bit1_low.
  • Se si utilizza get_wave_chan_id() di Nextion nelle lambda, passare a get_wave_channel_id() (il metodo precedente è deprecato e sarà rimosso nella versione 2026.10.0).
  • Se si utilizza sensor.raw_state nelle lambda, migrare all’uso dello stato filtrato o dei trigger on_raw_value (.raw_state è deprecato).
  • Se si mantengono componenti esterni che utilizzano setter generati da macro TEMPLATABLE_VALUE con costanti C++ raw, instradare i valori tramite cg.templatable() nel codegen Python.
  • Se si mantengono componenti esterni che utilizzano ButtonPressTrigger, SensorStateTrigger o classi simili, migrare a build_callback_automation().
  • Se si mantengono componenti esterni che utilizzano FlushResult, rinominare in UARTFlushResult con prefisso UART_FLUSH_RESULT_. 

Prestazioni e Sicurezza ESP32

Sono state introdotte diverse modifiche alla piattaforma ESP32 per migliorare prestazioni, sicurezza e flessibilità.

Frequenza CPU Predefinita Portata al Massimo

I dispositivi ESP32, ESP32-S2, ESP32-S3 ed ESP32-C5 utilizzano ora di default 240MHz invece di 160MHz. Viene ripristinato il livello di prestazioni precedente a maggio 2025 per gli utenti Arduino, con operazioni CPU-bound fino a circa il 34% più veloci:

  • Handshake API cifrata: da 90ms a 64ms (29% più veloce)
  • Encoding Protobuf (BLE proxy): 34% più veloce
  • Cifratura Noise: 33-34% più veloce su tutte le dimensioni di payload

Su dispositivi alimentati a batteria o con vincoli termici è possibile impostare cpu_frequency: 160MHZ. Questa modifica aumenta il consumo energetico ed è quindi considerata una breaking change.

Miglioramenti Crash Handler

Il crash handler ora cattura i backtrace da entrambi i core sui dispositivi dual-core e preserva i dati di crash anche dopo riavvii dovuti a rollback OTA.

40KB IRAM Aggiuntivi su ESP32

Una nuova opzione consente di recuperare 40KB di SRAM1 precedentemente riservata, utilizzandola come IRAM. Questo amplia la finestra di cache flash e riduce i cache miss per Wi-Fi, BLE e API senza impattare l’heap.

L’abilitazione è suggerita automaticamente solo se sicura in base al bootloader. Non abilitare manualmente senza verifica: con bootloader precedenti alla versione 5.1 si rischia il blocco del dispositivo (richiede reflashing via USB).

Verifica OTA Firmata

È disponibile la nuova opzione signed_ota_verification per verificare la firma del firmware durante gli aggiornamenti OTA senza richiedere Secure Boot hardware. Sono supportate due modalità:

  • Chiave privata (signing_key) – Il firmware viene firmato automaticamente in fase di build
  • Chiave pubblica (verification_key) – Solo la chiave pubblica è inclusa; la firma avviene esternamente
esp32:
  framework:
    type: esp-idf
    advanced:
      signed_ota_verification:
        signing_key: secure_boot_signing_key.pem
        signing_scheme: rsa3072
Tabelle di Partizione Personalizzate

È ora possibile definire partizioni dati/app personalizzate tramite componenti o configurazione YAML. La generazione della tabella è stata unificata tra Arduino ed ESP-IDF. NVS è stato spostato alla fine della flash con dimensione aumentata (fino a 384KB su Arduino).

Aggiornamento Framework

La piattaforma è stata aggiornata a ESP-IDF 5.5.4 e Arduino 3.3.8. PlatformIO viene eseguito in un sottoprocesso per isolare il virtualenv ed evitare errori di import durante la build.

Fix Crash ADC

Le funzioni di controllo ADC sono ora posizionate in IRAM per garantire sicurezza della cache. In precedenza potevano verificarsi crash quando la cache flash veniva disabilitata durante scritture NVS in background.

Fix Brick OTA Web Server

È stato risolto un problema storico nel flusso OTA via captive portal e web server che poteva causare il brick del dispositivo in caso di upload interrotto e ripetuto. Il backend OTA ora si resetta a ogni nuovo caricamento.

Fix Crash mDNS

Aggiornata la libreria mDNS per correggere problemi di corruzione heap durante traffico sostenuto e un’eccezione da puntatore nullo durante il parsing dei pacchetti.

ESP8266 Crash Handler

Completando il supporto multi-piattaforma introdotto nella release 2026.3.0 (con crash handler per ESP32 e RP2040), anche i dispositivi ESP8266 dispongono ora di diagnostica post-mortem avanzata. In caso di crash, i dettagli dell’eccezione e fino a 16 indirizzi di backtrace ricavati dallo stack vengono salvati nella memoria RTC e riportati tramite API al successivo avvio.

Non è necessario alcun collegamento USB: i dati di crash sono disponibili tramite esphome logs (che decodifica automaticamente gli indirizzi in posizioni del codice sorgente tramite addr2line) e nel visualizzatore log di Home Assistant, interamente via Wi-Fi.

[E][esp8266]: *** CRASH DETECTED ON PREVIOUS BOOT ***
[E][esp8266]:   Reason: Exception - StoreProhibit (exccause=29)
[E][esp8266]:   PC: 0x40212EC5
[E][esp8266]:   EXCVADDR: 0x00000000
[E][esp8266]:   BT0: 0x40212F5A
[E][esp8266]:   BT1: 0x40203B10

Il campo PC rappresenta il program counter nel punto in cui si è verificato il crash, EXCVADDR indica l’indirizzo di memoria che ha causato l’errore, mentre BT0/BT1 ecc. rappresentano il backtrace dello stack, ovvero la catena di chiamate che ha portato al crash.

Utilizzando esphome logs, questi indirizzi vengono automaticamente tradotti in file sorgente e numeri di riga tramite addr2line, consentendo di visualizzare direttamente i nomi delle funzioni invece dei valori esadecimali.

Non è richiesta alcuna configurazione: la funzionalità è abilitata automaticamente su tutti i dispositivi ESP8266. L’impatto sulle risorse è minimo: 0 byte di RAM, 119 byte di IRAM e circa 1KB di flash.

Logging Stato Lato Client

Il logging dei cambi di stato è stato completamente riprogettato per eliminare il principale collo di bottiglia CPU su ogni dispositivo ESPHome.

In precedenza, ogni variazione di stato (ad esempio 'CO2' >> 420 ppm, 'Light' - Setting ON) eseguiva vsnprintf sul dispositivo per formattare una stringa di log e la inviava via UART, anche quando nessuno stava osservando la console seriale (situazione che riguarda la quasi totalità dei dispositivi). I benchmark hanno evidenziato che questa operazione poteva consumare oltre il 95% del tempo di pubblicazione dei sensori.

Ora i log di stato vengono ricostruiti lato client invece che sul dispositivo. Quando esphome logs o la dashboard si collegano, viene effettuata una sottoscrizione a messaggi di stato protobuf compatti, che vengono formattati localmente. I messaggi protobuf occupano una frazione dello spazio rispetto alle stringhe formattate e l’elaborazione viene eseguita sul computer anziché sul microcontrollore.

Questo approccio consente un miglioramento fino a 46 volte nel percorso di pubblicazione, con un risparmio di flash compreso tra circa 1,4KB (ESP32-C3) e 2,2KB (ESP8266). I cambi di stato continuano a essere visibili nei log come righe [S] (in ciano):

[18:03:14.677][S][sensor]: 'CO2' >> 420 ppm
[18:03:14.677][S][sensor]: 'Temperature' >> 35.63 °C
[18:03:51.747][S][light]: 'Light' >> ON

È disponibile il nuovo flag --no-states, che consente di sopprimere completamente le righe di cambio stato, utile in fase di debug quando il log è saturo di aggiornamenti dei sensori.

Per ripristinare il comportamento precedente (logging lato dispositivo), è possibile impostare logger: level: VERBOSE.

ESP-IDF 6.0

Questa release include 31 pull request dedicate alla preparazione di ESPHome per ESP-IDF 6.0, che introduce GCC 15, picolibc e importanti modifiche alle API di Espressif. Le modifiche interessano crittografia, driver e compatibilità della toolchain su tutto il codice. Sebbene ESP-IDF 6.0 non sia ancora il framework predefinito, queste modifiche garantiscono la piena compatibilità futura. Tutte le pull request correlate sono contrassegnate con l’etichetta idf-6.

Migrazione API PSA Crypto

ESP-IDF 6.0 depreca le API crittografiche legacy di mbedTLS. Tutte le operazioni crittografiche sono state migrate alla nuova API PSA Crypto:

  • Hashing SHA-256
  • HMAC-SHA256
  • BLE tracker con PSA Crypto
  • Decrittazione CCM per BTHome/Xiaomi BLE
  • Decrittazione GCM per contatori DLMS
Aggiornamenti Driver e API

Sono stati aggiornati oltre 20 componenti per adattarsi alle modifiche API di ESP-IDF 6.0, inclusi:

  • Wi-Fi, ADC, LEDC, RMT (strisce LED e trasmettitori/ricevitori remoti)
  • MIPI DSI, PSRAM, I2S audio, I2C, deep sleep
  • MQTT, USB host, timer OpenTherm, Ethernet, debug e camera
Compatibilità Toolchain
  • Risolto conflitto std::isnan con PicoLibC
  • Corretto stub vfprintf per printf con picolibc
  • Corrette conversioni implicite da int a gpio_num_t per GCC 15
  • Rimosso il driver I2S legacy in preparazione a ESP-IDF 6.0

Substitutions

Il sistema di configurazione YAML introduce due miglioramenti rilevanti che rendono le configurazioni complesse e multi-file più potenti e rapide da caricare.

Substitutions nei percorsi !include

È ora possibile utilizzare variabili di substitution ed espressioni Jinja direttamente nei nomi dei file !include, consentendo la selezione dinamica dei file:

substitutions:
  eth_model: LAN8720

packages:
  - !include network/${eth_model}/config.yaml

La funzionalità è compatibile anche con substitution passate da riga di comando, permettendo di utilizzare lo stesso file YAML per configurazioni hardware differenti senza duplicare i file.

Il motore di substitutions è stato riprogettato per eseguire tutte le sostituzioni in un’unica passata lineare, invece del precedente approccio multi-pass. Questo consente tempi di caricamento fino a 18 volte più rapidi nei progetti di grandi dimensioni con numerosi package e include.

La riscrittura risolve inoltre diversi casi limite legati ai riferimenti tra file (ad esempio espressioni come ${A * B} che combinano variabili locali e globali).

Per le chiavi duplicate generate tramite substitution, l’ordine di merge_config segue ora la regola “last writer wins”.

Espansione Ethernet

Sulla base del supporto completo per RP2040/RP2350 introdotto nella versione 2026.3.0, questa release amplia significativamente il supporto Ethernet su più piattaforme, aggiungendo 5 nuovi tipi di chip e introducendo per la prima volta Ethernet SPI sulla piattaforma RP2040. Le schede RP2040, come la serie WIZnet EVB-Pico, possono ora essere utilizzate come controller IoT cablati senza Wi-Fi.

Nuovo supporto Ethernet su RP2040
  • W5500: Ethernet SPI a 100Mbps, testato con 344 connessioni API riuscite su WIZnet W5500-EVB-Pico
  • W5100/W5100S: Ethernet SPI 10/100Mbps per schede come W5100S-EVB-Pico
  • W6100 e W6300: controller WIZnet di nuova generazione con supporto IPv6 per schede come W6300-EVB-Pico2
Aggiunte cross-platform
  • ENC28J60: controller 10BASE-T di Microchip ora supportato sia su ESP32 (IDF) sia su RP2040
Miglioramenti ESP32
  • Selezione interfaccia SPI: la nuova variabile di configurazione interface consente di selezionare spi2 o spi3, risolvendo conflitti con componenti display su schede come M5Stack CoreS3

GPIO Expander

I componenti GPIO expander PCF8574, PCA9554, MCP23008/MCP23017, MCP23S08/MCP23S17, PI4IOE5V6408, MCP23016, PCA6416A e TCA9555 supportano ora un pin opzionale interrupt_pin che elimina completamente il polling su bus I2C/SPI.

Expander supportati
  • PCF8574, PCA9554, PCA6416A, TCA9555: GPIO expander I2C
  • MCP23008, MCP23017, MCP23S08, MCP23S17, MCP23016: famiglia GPIO expander I2C e SPI
  • PI4IOE5V6408: GPIO expander I2C
COMPARATIVE
Metrica Polling Interrupt Miglioramento
Letture I2C/min (idle) 4100 ms 12 ms Riduzione del 99,7%
Iterazioni loop per ciclo 7477 16 468 volte in meno
Tempo lettura sensore binario ~0,6 ms (I2C) ~0,002 ms (cache) 300 volte più veloce

Quando configurato, i sensori binari restituiscono i valori dalla cache (senza accessi al bus) tra un interrupt e l’altro, e il loop principale viene completamente sospeso fino a una variazione di stato dei pin. I dispositivi MCP23x17 attivano automaticamente il bit MIRROR, consentendo a un singolo filo di interrupt di rilevare modifiche su tutti i 16 pin.

pcf8574:
  id: my_pcf8574
  interrupt_pin: GPIO16

Benchmarking

Questa release introduce un’infrastruttura completa di benchmarking in C++ basata su CodSpeed, che consente il tracciamento continuo delle prestazioni e la prevenzione delle regressioni. Inizialmente integrato per preservare i miglioramenti introdotti nella versione 2026.3.0, il sistema di benchmark ha rapidamente evidenziato ulteriori colli di bottiglia, guidando una serie di ottimizzazioni mirate durante l’intero ciclo di sviluppo.

Benchmark introdotti
  • Codifica e decodifica Protobuf (messaggi API, advertisement BLE, ListEntities)
  • Handshake Noise e cifratura dei payload
  • Pipeline di pubblicazione e chiamata per sensori, sensori binari, luci, coperture, climatizzazione, ventole, numeri, select, switch, text_sensor e button
  • Operazioni di scheduler (intervalli e timeout)
  • Scrittura frame API in modalità plaintext e cifrata

Le ottimizzazioni a livello API si concentrano sul fatto che l’API nativa rappresenta il principale canale di comunicazione tra ESPHome e Home Assistant. L’obiettivo è rendere il Bluetooth Proxy sufficientemente leggero da poter essere eseguito su qualsiasi ESP32-C3 senza impatto significativo sulle prestazioni.

Questo obiettivo è stato raggiunto: combinando i miglioramenti introdotti nella versione 2026.3.0, il forwarding degli advertisement del BLE Proxy (il percorso più critico e continuo del sistema) utilizza ora solo circa l’1,8% del runtime del main loop su ESP32-C3, rispetto al ~3,3% della versione 2026.3.0 e a una frazione molto ridotta rispetto a un anno fa.

Ottimizzazioni memoria

Guidata dalla maggiore visibilità ottenuta tramite strumenti di benchmarking e analisi della memoria, questa release introduce significativi risparmi di RAM e flash su tutto il framework.

Allocazioni dei componenti spostate da heap a BSS

È stata introdotta una modifica architetturale rilevante: tutte le istanze dei componenti (new_Pvariable) vengono ora allocate tramite placement new all’interno di un’area BSS statica a dimensione fissa, invece di essere allocate singolarmente sull’heap.

In precedenza, ogni componente, sensore, automazione e filtro generava una distinta allocazione heap, causando frammentazione progressiva della memoria. Con il nuovo approccio, le allocazioni vengono compattate in una regione BSS contigua, liberando l’heap per buffer di Wi-Fi, BLE e rete che richiedono realmente allocazione dinamica.

Questo elimina centinaia di piccole allocazioni per dispositivo e riduce in modo significativo la frammentazione dell’heap nei sistemi con lunga uptime.

Miglioramenti nell’analisi della memoria in CI

La pipeline CI di ESPHome esegue ora un’analisi automatica dell’impatto sulla memoria per ogni pull request, mostrando ai contributori l’impatto preciso su flash e RAM prima della fusione.

In precedenza, la memoria dei componenti era difficilmente tracciabile perché allocata interamente a runtime sull’heap. Con l’introduzione della modifica BSS, ogni componente diventa uno simbolo staticamente visibile, consentendo alla CI di misurarne e attribuirne il consumo.

Lo strumento analyze-memory è stato esteso per attribuire le allocazioni placement new ai rispettivi componenti, rendendo immediato individuare le aree ancora ottimizzabili. Questa maggiore visibilità ha guidato una serie di ottimizzazioni mirate nell’intero framework.

Aggiornamento LVGL v9

Il framework LVGL è stato aggiornato dalla versione v8 alla v9.5.0. La migrazione è stata guidata da 27 pull request e rappresenta un aggiornamento significativo della libreria, con una nuova pipeline di rendering, prestazioni migliorate e nuove funzionalità per i widget. Le configurazioni esistenti dovrebbero continuare a compilare ed eseguire correttamente, anche se alcune proprietà risultano deprecate.

Rotazione nativa con accelerazione hardware

La rotazione dello schermo viene ora gestita direttamente da LVGL invece che dal driver del display. Le modifiche di rotazione a runtime sono disponibili tramite lvgl.display.set_rotation e, dove supportato, viene utilizzata la rotazione hardware automatica.

Su ESP32-P4 la rotazione viene eseguita tramite PPA (Pixel Processing Accelerator), riducendo a zero il costo CPU per le trasformazioni dell’immagine.

Rotazione automatica del touchscreen

L’input touch viene ora ruotato automaticamente per allinearsi all’orientamento del display, eliminando nella maggior parte dei casi la necessità di trasformazioni manuali delle coordinate.

È necessario spostare la configurazione della rotazione dal componente display al blocco lvgl: e rimuovere o adattare il blocco transform: nel componente touchscreen.

Tema scuro integrato

L’attivazione del tema scuro è ora disponibile tramite una singola opzione dark_mode: true sotto theme:, che abilita il tema nativo scuro di LVGL, sostituendo la precedente necessità di replicare manualmente tutte le proprietà del tema.

Supporto completo agli eventi LVGL 9

È stata aggiunta la mappatura completa degli eventi LVGL 9 ai trigger di automazione di ESPHome, consentendo l’utilizzo diretto dei nuovi eventi all’interno delle automazioni.

Supporto per drop shadow

È stato introdotto il supporto agli effetti di ombra tramite la nuova proprietà di stile bitmap_mask_src e il formato immagine A8, abilitando effetti di drop shadow per elementi grafici.

Nuovi sensori e supporto hardware

Questa release introduce il supporto a nuovi sensori e piattaforme hardware, ampliando ulteriormente l’ecosistema ESPHome su diverse famiglie di dispositivi e interfacce.

Sensori e moduli aggiunti
  • SPA06-003: sensore digitale di pressione e temperatura Goermicro con interfacce I2C e SPI, disponibile tramite Adafruit e Seeed Grove
  • HDC2080: sensore di temperatura e umidità Texas Instruments
  • emonTx: supporto per emonTx/emonPi di OpenEnergyMonitor tramite bridge seriale UART, con trigger JSON e azioni a comando
Aggiornamenti sensori esistenti
  • BMP581: aggiunto supporto SPI oltre a I2C
  • BMP585: aggiunto supporto per il nuovo ASIC ID BMP585 all’interno del componente BMP581
Supporto piattaforme hardware
  • ESP32-C61 PSRAM: supporto PSRAM in modalità quad a 40MHz e 80MHz
  • nRF52 Zephyr: supporto alla temperatura interna del chip
  • LN882H: supporto alla temperatura interna del chip 

Breaking Changes

Frequenza CPU ESP32: la frequenza CPU predefinita è stata modificata al massimo supportato per ciascuna variante (ESP32/S2/S3/C5: da 160MHz a 240MHz). Questa modifica migliora le prestazioni di circa il 33%, ma aumenta il consumo energetico. I dispositivi alimentati a batteria devono impostare esplicitamente cpu_frequency: 160MHZ nella configurazione.

Tabella partizioni ESP32: il layout delle partizioni è stato modificato sia per il framework Arduino che IDF. NVS è stata spostata alla fine della flash con dimensione aumentata (da 20KB a 384KB su Arduino). I dispositivi esistenti riceveranno la nuova tabella partizioni al prossimo aggiornamento OTA. I dati NVS vengono preservati poiché la libreria li individua per nome e non per posizione.

RTC preferences ESP8266: la capacità delle RTC preferences è stata ridotta da 96 a 78 parole per fare spazio al nuovo crash handler. Gli overflow vengono ora gestiti su flash. L’impatto sulle configurazioni reali è considerato molto improbabile.

Modifiche ai componenti

LVGL rotation: l’opzione di rotazione deve essere ora configurata sotto lvgl: invece che nel componente display. LVGL gestisce direttamente la rotazione del display e del touchscreen, con supporto alla modifica runtime tramite lvgl.display.set_rotation. È necessario spostare la configurazione di rotazione dal display al blocco LVGL e rimuovere o adattare il blocco transform: nel touchscreen, se presente.

I2S Audio: il driver I2S legacy (opzione use_legacy) è stato rimosso. Il nuovo driver I2S è sempre utilizzato. Il componente media player i2s_audio è stato completamente rimosso; è necessario migrare al componente speaker media player.

Binary Sensor multi_click: le sequenze temporali di on_multi_click sono ora limitate a 255 elementi (in precedenza illimitate). Nessuna configurazione reale dovrebbe raggiungere questo limite.

Binary Sensor autorepeat: le liste temporali di autorepeat sono ora limitate a 254 elementi (in precedenza illimitate). Nessuna configurazione reale dovrebbe raggiungere questo limite.

L’elenco completo delle breaking change è disponibile qui.

AGGIORNAMENTO

Per aggiornare l’ambiente operativo:

pip3 install esphome --upgrade
docker pull esphome/esphome
  • su Home Assistant OS è sufficiente recarsi presso “Supervisor” > “ESPHome” e cliccare su “UPDATE“:

ESPHome - HASSIO Update

Per aggiornare, invece, i componenti dotati in precedenza di firmware ESPHome, dopo aver provveduto all’aggiornamento dell’ambiente operativo è sufficiente recarsi presso la lista dei propri componenti (già accesi e presenti in rete) e cliccare su “UPLOAD“, aggiornamento che avverrà come d’abitudine via OTA (over-the-air), previa una ricompilazione del firmware (automatica).

Questa pagina è redatta, manutenuta e aggiornata dallo staff di inDomus, un gruppo di persone molto diverse tra loro che trovi, per domande e supporto, sul forum e sulla chat del sito. Alcuni link sono taggati in qualità di affiliati Amazon e riceviamo un compenso dagli acquisti idonei, utile al sostenimento del sito, ma le nostre recensioni sono tutte indipendenti e non sponsorizzate. Se ti sei perso, a tua disposizione c'è la mappa.