ESPConfig Designer è un add-on di terze parti che affronta lo stesso problema del Device Builder da un’angolazione diversa: invece di darti un editor YAML con un catalogo a fianco, ti dà moduli da compilare e genera il YAML per te. Se il Device Builder è “scrivi la configurazione, ti aiuto a scoprire le opzioni”, ESPConfig Designer è “rispondi alle domande, la configurazione te la scrivo io”.
Non è un sostituto e non compete davvero: usa lo stesso motore ESPHome sotto, produce YAML standard, e i device che crea sono device ESPHome normali. È un guscio grafico. In questo capitolo vediamo come si installa, com’è organizzato, come si confronta con il Device Builder ufficiale, e in quali casi vale la pena averlo.
È UN ADD-ON DI TERZE PARTI:
ESPConfig Designer è sviluppato da sokolsok, è open source con licenza MIT, e vive su
github.com/sokolsok/ESPConfig-Designer. Non fa parte del progetto ESPHome né della Open Home Foundation: è un progetto della community. Vale quindi la prudenza che si applica a tutto quello che si installa da fuori (vedi 5 Integrazioni e HACS sul tema delle dipendenze da progetti singoli).
Installazione
Si installa come repository add-on custom di Home Assistant, quindi serve HAOS o Supervised.
Impostazioni → Add-on → Add-on store → menu ⋮ → Repositories.
Nel campo incolli l’indirizzo del repository:
https://github.com/sokolsok/ESPConfig-Designer
Chiudi, aggiorna la pagina dello store, e trovi ESPConfig Designer fra gli add-on disponibili. Installa, avvia, e attiva Show in sidebar come hai fatto per ESPHome.
Lavora sulla stessa cartella /config/esphome/ del Device Builder, il che significa due cose comode: i device creati con uno sono visibili all’altro, e non devi scegliere una volta per tutte. Puoi disegnare un device con ESPConfig Designer e poi continuare a modificarlo a mano nel Device Builder, o viceversa.
Come è organizzato
L’interfaccia si divide in quattro aree.
Dashboard è l’elenco dei progetti, il punto da cui si apre o si crea un device.
Builder è il cuore: la configurazione del device costruita con moduli e menu a tendina, con l’anteprima del YAML in tempo reale a fianco. Selezioni il chip, aggiungi un componente, compili i campi (pin, indirizzo, intervallo), e vedi comparire il blocco YAML corrispondente. La differenza rispetto al costruttore del Device Builder è che qui i moduli sono generati dagli schemi di validazione di ESPHome: i campi disponibili e i valori ammessi vengono dalla definizione del componente, non da una lista scritta a mano, quindi restano allineati.
Display Configurator è un editor a canvas per i layout degli schermi: posizioni gli elementi trascinandoli e lui genera il codice lambda corrispondente. È la funzione che si sovrappone di più a ESPHome Designer, di cui parliamo in 11 Display e ESPHome Designer; la differenza è che ESPConfig Designer lo fa per i display semplici dentro un flusso unico, mentre ESPHome Designer è uno strumento specializzato con un catalogo di widget molto più ricco.
Asset Manager gestisce i file che il firmware si porta dietro: font, icone, immagini. È il posto dove finiscono i .ttf e i .png che i display usano, senza doverli caricare a mano nella cartella giusta.
Il ciclo Save → Validate → Compile → Install
La barra dei comandi espone quattro pulsanti in sequenza, e la sequenza è anche il modo giusto di lavorare.
Save scrive su disco sia il file YAML sia un file JSON con lo stato del progetto (quali moduli hai aggiunto, come sono configurati). Il JSON serve a ESPConfig Designer per ricostruire l’interfaccia; il YAML è il file vero, quello che ESPHome compila.
Validate lancia il controllo di configurazione di ESPHome, lo stesso passaggio descritto in 4 Come funziona ESPHome. Dura secondi e dice se ci sono pin non validi, componenti inesistenti, o parametri fuori range.
Compile costruisce il firmware. Vale tutto quello che sappiamo sui tempi: primo build lungo, rebuild veloce.
Install invia il firmware al device via OTA.
Avere i quattro passaggi separati e visibili è didatticamente utile: rende evidente che validare e compilare sono cose diverse, e che l’errore che ti blocca in fase di validazione non ha niente a che vedere col compilatore.
Quando conviene, e quando no
La domanda vera è: avendo già il Device Builder, che ci faccio con questo?
| Device Builder | ESPConfig Designer | |
|---|---|---|
| Chi lo fa | Progetto ESPHome ufficiale, Open Home Foundation | sokolsok, progetto community |
| Approccio | Editor YAML con catalogo e costruttore a supporto | Moduli e form, YAML generato |
| Flash via USB | Sì, dal browser | No: compila e installa via OTA |
| Version history | Sì, git automatico | No |
| Remote build | Sì | No |
| Editor display | No | Sì, canvas integrato |
| Gestione asset | Manuale | Sì, Asset Manager |
Le due righe che decidono sono la terza e la quarta. Il Device Builder è l’unico dei due che fa il primo flash via USB, quindi ti serve comunque per portare in vita un chip nuovo; e ha la cronologia git, che è una rete di sicurezza che non vuoi perdere.
ESPConfig Designer ha senso in tre situazioni:
- Se il YAML ti mette a disagio. C’è chi si trova molto meglio con dei moduli da compilare, e non è un difetto. Se la scelta è fra usare ESPConfig Designer e non costruire il device affatto, la risposta è ovvia.
- Se lavori spesso con i display piccoli. Avere il canvas e la gestione dei font nello stesso posto in cui configuri il device fa risparmiare parecchi passaggi.
- Come strumento di apprendimento. Guardare l’anteprima YAML mentre compili i moduli è un buon modo per imparare la sintassi: dopo qualche device ti accorgi che scrivi più veloce a mano, e a quel punto sei passato dall’altra parte.
Non ha senso se cerchi di sostituire completamente il Device Builder: mancano il flash via USB, la cronologia e il remote build, che sono tre cose a cui non vale la pena rinunciare.
IL RISCHIO DEI PROGETTI A SINGOLO MANUTENTORE:
Vale per ESPConfig Designer come per qualsiasi add-on o integrazione custom: se domani il manutentore smette, l’add-on resta fermo e prima o poi un aggiornamento di ESPHome lo rompe. La mitigazione qui è comoda: i file che produce sono YAML ESPHome standard, quindi anche nello scenario peggiore i tuoi device continuano a esistere e a essere gestibili dal Device Builder. Perderesti l’interfaccia, non il lavoro. È esattamente il criterio con cui valutare qualsiasi strumento che si mette in mezzo: chiedersi cosa resta se sparisce.
Ricapitolando
- ESPConfig Designer è un add-on community (sokolsok, MIT) che genera YAML ESPHome da moduli e form.
- Si installa come repository add-on custom e lavora sulla stessa cartella
/config/esphome/del Device Builder. - Quattro aree: Dashboard, Builder con anteprima YAML live, Display Configurator a canvas, Asset Manager per font e immagini.
- Il ciclo è Save → Validate → Compile → Install, con i passaggi separati e visibili.
- Non fa il primo flash via USB: per portare in vita un chip nuovo serve comunque il Device Builder.
- Gli mancano anche version history e remote build, che sono due funzioni importanti.
- Conviene se il YAML ti mette a disagio, se lavori spesso con display piccoli, o come strumento per imparare la sintassi.
- Produce YAML standard: se il progetto si ferma, perdi l’interfaccia ma non i device.