Z NSPanel_HA_Blueprint na NSPanel Easy: migrace krok za krokem

Máte NSPanel na projektu Blackymas/NSPanel_HA_Blueprint, funguje vám a nechcete ho rozebírat. Dobrá zpráva: nemusíte. Migrace na NSPanel Easy je obyčejná OTA aktualizace - panel zůstane na stěně, sériový kabel necháte v šuplíku a nastavení automatizace se přenese celé.

Tenhle článek je čistě o tom přechodu. Rozjíždíte panel od nuly, nebo vás zajímá hardware, pinout a sériový flash? Mám na to kompletní návod na instalaci NSPanel Easy od nuly, kde rozebírám i to, proč to není neznámý fork.

Konkrétní důvod k migraci, ne jen „vývoj se přesunul"

Argumenty pro přechod bývají obecné. Tak tady je jeden konkrétní, na který jsem narazil ve vlastním buildu. A hned si ujasněme, o co nejde: připnutá verze původního projektu (v2026041) není starší než změna v ESPHome. Je novější a přímo na ni reaguje - v souboru esphome/nspanel_esphome_addon_upload_tft.yaml verzová podmínka je. Jen v té novější větvi chybí .c_str():

#if ESPHOME_VERSION_CODE >= VERSION_CODE(2025, 11, 0)
ESP_LOGCONFIG("${TAG_UPLOAD_TFT}", "  File model: %s", tft_file_model->current_option());
#else
ESP_LOGCONFIG("${TAG_UPLOAD_TFT}", "  File model: %s", tft_file_model->state.c_str());
#endif

Tam, kde %s čeká char*, se tedy předává objekt esphome::StringRef, a to je nedefinované chování. Kompilátor to říká při každém buildu naprosto natvrdo:

nspanel_esphome_addon_upload_tft.yaml:114: warning: format '%s' expects argument of type
   'char*', but argument 5 has type 'esphome::StringRef' [-Wformat=]

Není to kód někde v koutě - sedí v dump_config, takže se provede při každém startu panelu. U mě je v logu jako [C][nspanel.addon.upload_tft:114]: File model: NSPanel EU, hned vedle s poznámkou dump_config took a long time for an operation (115 ms).

Buďme poctiví: zatím to funguje. Ty bajty se náhodou přečtou správně a nemám nic, čím bych to spojoval s pádem panelu. Ale nedefinované chování zůstává nedefinovaným chováním - a NSPanel Easy tam .c_str() má.

Že to není jednotlivost, mi ukázal až samotný build. Přeložil jsem oba projekty na tomtéž panelu a stejném ESPHome 2026.7.3 a porovnal varování kompilátoru: Blackymas jich vysypal pět, NSPanel Easy jedno.

Varování při kompilaci	Blackymas v2026041	NSPanel Easy v2026.7.1
GPIO5 is a strapping PIN	ano	ne
platformio_options->build_flags je deprecated	ano	ano
%s se StringRef (nedefinované chování)	ano	ne
%hhu / %i / %u mismatche ve formátovacích řetězcích	4×	ne

A poctivost i na druhou stranu: deprecaci build_flags migrace nevyřeší, protože je v obou projektech - ESPHome tu podporu odstraní ve verzi 2026.12.0. V NSPanel Easy se to řeší v otevřených issues #343 a #344.

Není to verdikt nad celým firmwarem a čtyři varování navíc panel nezpomalí. Ale právě tahle třída problémů v režimu „jen kritické opravy" zůstane ležet, protože kompilaci nerozbije.

Kolik to reálně zabere času a s čím to mám ověřené

Oficiální dokumentace slibuje pod 10 minut na panel. Buďme poctiví: těch deset minut je vaše práce u klávesnice. Připočtěte kompilaci firmwaru (poprvé i deset minut) a nahrání TFT (10-20 minut). Vyhraďte si tedy půl hodiny až čtyřicet minut, z čehož většinu času budete jen koukat na progress bar.

A počítejte s tím, že po přeflashování to nějakou dobu vypadá rozbitě - panel čeká, dokud nedoděláte Krok 3, a do té doby si stěžuje v logu. Rozepisuju to v Kroku 2.

Postup mám odzkoušený 27. 7. 2026 na vlastním panelu: z Blackymas v2026041 na NSPanel Easy v2026.7.1 s ESPHome 2026.7.3. Aktuální vydání najdete na stránce releasů.

Checklist před migrací

Než začnete, projděte si tohle. Nic z toho není složité, ale dvě z těch věcí umí migraci zastavit hned na prvním kroku:

• Panel běží na NSPanel_HA_Blueprint a je dostupný v ESPHome Device Builderu. Bez funkčního OTA spojení bezdrátová migrace nejde.
• Víte, jaké add-ony máte v konfiguraci. Podívejte se do bloku packages: → files: a seznam si opište, budete ho přepisovat.
• Víte, jestli máte v substitucích nextion_update_url. Chování téhle substituce se změnilo nejvíc ze všeho, viz níž.
• Znáte svůj model displeje (EU / US / US Landscape).
• Panel má rezervu v paměti. Pokud v konfiguraci máte bluetooth_proxy:, odstraňte ho ještě před migrací - nahrávání TFT potřebuje kus RAM, kterou s BLE nedostane. Změřená čísla i to, proč Bluetooth na panelu nedoporučuji, mám v hlavním návodu.
• Víte, kde máte v YAML sekci substitutions: - všechny změny se odehrají tam a v packages:. Jak celá konfigurace vypadá u čisté instalace, najdete v Kroku 2 hlavního návodu.

Wi-Fi údaje, jméno zařízení ani zbytek substitucí měnit nebudete. Vlastně jen říkáte ESPHome, odkud si má balíček stáhnout.

Co se mění: starý projekt proti novému

Tady je celá migrace v jedné tabulce. Zbytek článku je jen její rozepsání.

Věc	NSPanel_HA_Blueprint	NSPanel Easy
url v packages:	https://github.com/Blackymas/NSPanel_HA_Blueprint	https://github.com/edwardtfn/NSPanel-Easy
ref	main nebo tag	latest při první instalaci, pak konkrétní tag
Add-on soubory	v rootu repozitáře	v podsložce esphome/
Základní nspanel_esphome.yaml	root	root - nemění se!
ota_password	odvozené z Wi-Fi hesla	samostatné, u bezdrátové migrace ho musíte doplnit
Jazyk panelu	volba v Blueprintu	substituce language: cs v YAML
nextion_update_url	volba modelu TFT i override URL	jen plný override
API akce upload_tft, wake_up	registrované vždy	defaultně vypnuté, zapínají se substitucí
Blueprint	Blackymas/nspanel_blueprint.yaml	edwardtfn/nspanel_easy_blueprint.yaml
CJK jazyky	samostatné TFT varianty	zabudované ve standardních TFT

Krok 1: Změny v ESPHome YAML

Otevřete konfiguraci panelu v ESPHome Device Builderu. Blok packages: přepište takhle:

packages:
  remote_package:
    url: https://github.com/edwardtfn/NSPanel-Easy
    ref: latest
    refresh: 300s
    files:
      - nspanel_esphome.yaml   # zakladni balicek - BEZ prefixu esphome/
      # Add-ony, pokud je pouzivate - VZDY s prefixem esphome/
      # - esphome/nspanel_esphome_addon_climate_heat.yaml
      # - esphome/nspanel_esphome_addon_climate_cool.yaml
      # - esphome/nspanel_esphome_addon_climate_dual.yaml
      # - esphome/nspanel_esphome_addon_cover.yaml
      # - esphome/nspanel_esphome_addon_display_light.yaml

Nejčastější chyba celého kroku

Add-ony se přesunuly do podsložky esphome/, ale základní balíček nspanel_esphome.yaml zůstal v rootu. Když prefix přidáte i jemu, kompilace skončí na 404 nebo prázdném balíčku. Když ho naopak zapomenete u add-onů, dostanete tu samou chybu z druhé strany.

ota_password - past, která vás pošle pro sériový kabel

U starého projektu se OTA heslo odvozovalo z Wi-Fi hesla přímo v remote packagi. NSPanel Easy tuhle vazbu rozpojil, takže si OTA heslo můžete nastavit nezávisle. Jenže při bezdrátové migraci si nový firmware musí ještě sáhnout na panel se starým firmwarem - a ten čeká heslo odvozené z Wi-Fi.

Bez tohoto řádku se bezdrátová migrace nespojí

Do bloku substitutions: doplňte:

substitutions:
  # ... ostatni hodnoty zustavaji
  ota_password: ${wifi_password}   # kvuli zpetne kompatibilite pri migraci

Bez toho vám OTA selže na autentizaci a snadno dojdete k závěru, že musíte panel otevřít a flashovat sériově. Nemusíte. Dokumentace to zmiňuje, ale jen jako poznámku pod tabulkou - proto to tady píšu takhle nahlas.

Pokud panel z nějakého důvodu flashujete přes USB-TTL, tohle vás netrápí a OTA heslo si můžete zvolit libovolně.

Jazyk panelu

V NSPanel Easy se jazyk nastavuje v ESPHome YAML, ne v Blueprintu:

substitutions:
  language: cs

Do firmwaru se zakompilují jen texty toho jednoho jazyka. Když substituci vynecháte, panel po migraci spadne na angličtinu bez ohledu na to, co jste měl vybrané ve starém Blueprintu.

Po migraci si zkontrolujte formát času

Jazyk se přenese, formát datumu a času se ale může nastavit na dvanáctihodinový. U mě se to po prvním startu v logu ukázalo takhle:

[C][nspanel.localization:4513]: Language: 'cs'
[C][nspanel.localization:4514]:   Valid: Yes
[C][nspanel.localization:4517]:   Date format: '%A, %d.%m'
[C][nspanel.localization:4517]:   Time format: '%-I:%M %p'

Jazyk cs sedí, jenže %-I:%M %p je 12hodinový čas s AM/PM - na českém panelu skoro jistě nechtěný. Formát se nastavuje v Blueprintu v sekci Localization, ne v YAML. Pro 24hodinový čas tam chcete %H:%M.

nextion_update_url

Tahle substituce změnila význam a je potřeba si rozmyslet, do které skupiny patříte:

• Měl jste ji jen proto, abyste vybral model displeje? Odeberte ji. Model dnes řeší selektor Display model v Home Assistantovi, který navíc sám staví správnou verzovanou URL.
• Hostujete si vlastní nebo lokální TFT soubor? Můžete ji nechat, ale vězte, že je to nově plný override - obchází selektor modelu i celou verzovací logiku a použije se přesně ta jedna adresa. Za to, že za ní leží kompatibilní a aktuální soubor, ručíte vy. Pokud za ní leží soubor ze starého projektu, odeberte ji - pro NSPanel Easy platný není a panel by po migraci dostal nekompatibilní TFT.

Chybějící API akce

Pokud z automatizací voláte akce upload_tft nebo wake_up, po migraci je nenajdete. NSPanel Easy je defaultně neregistruje, protože každá registrovaná akce ubírá heap při startu. Vrátíte si je substitucemi:

substitutions:
  include_action_upload_tft: true
  include_action_wake_up: true

Krok 2: Přeflashování přes Wi-Fi

Uložte konfiguraci a pak:

1. V ESPHome Device Builderu najděte svůj panel a klikněte na tři tečky
2. Install → Wirelessly
3. Nechte to zkompilovat a nahrát

To je všechno. Panel se restartuje s novým firmwarem, nikam nelezete a žádný převodník nepotřebujete. Máte-li panelů víc, opakujte Kroky 1 a 2 pro každý zvlášť - migrovat všechny naráz nemusíte.

Verzi si připněte, ale až po migraci

ref: latest je tady záměrně - migrační dokumentace ho pro tu první instalaci chce a starý tag z původního repozitáře by nefungoval. Až bude panel běžet, doporučuju přepnout na konkrétní tag a refresh: never, ať se vám verze nemění pod rukama při každé rekompilaci. Proč na tom trvám, vysvětluju v Kroku 2 hlavního návodu.

První start vypadá rozbitě, dokud nedoděláte Krok 3

Tohle je podle mě nejcennější věc z celého článku. Po přeflashování to nějakou dobu vypadá jako havárie - do logu se sypou řádky W i E, displej nereaguje a člověk má neodolatelnou chuť panel restartovat nebo přeflashovat. Nedělejte to.

U mě od restartu do hlášky The system is ready to run actions uběhlo necelých pět minut. Ale to číslo neberte jako vlastnost firmwaru - tolik mi prostě trvalo naimportovat Blueprint a přepsat path: v automatizaci, tedy celý Krok 3. Panel na to celou dobu jen čekal. Kdo má Krok 3 hotový dřív, bude mít panel hotový výrazně rychleji.

Takhle to u mě vypadalo od sekundy nula:

Čas od startu	Řádek v logu	Co se děje
0 s	start firmwaru	-
0,4 s	[W][nextion:110]: Not connected	první z desítek stejných hlášek
44 s	[E][nspanel.hw.display:531]: Display is not set. Restarting.	vypadá to jako chyba, je to zotavení
57 s	[I][nspanel.hw.uart:077]: Baud scan: starting (target 921600 bps)	hledá se rychlost, na které displej mluví
65 s	[I][nspanel.hw.uart:177]: Baud scan: found active rate 115200 bps	našel starou rychlost
66 s	[I][nextion:116]: Connected	displej navázán, konec automatické části
74 s	[I][nspanel.addon.upload_tft:128]: Starting auto-upload count down: 65 sec	firmware si naplánoval nahrání TFT - u mě nedojelo, viz Krok 4
204 s	[W][nspanel.versioning:092]: Blueprint version mismatch!	odtud panel čeká na vás, ne na sebe - já v tu chvíli importoval Blueprint
289 s	[I][nspanel.versioning:207]: Blueprint version: 2026.7.1	Blueprint sedí - tenhle řádek přišel proto, že jsem dokončil Krok 3
292 s	Receiving settings from Blueprint: 100.0%	nastavení přeneseno
295 s	[I][nspanel.base:120]: The system is ready to run actions	hotovo

Ta časová osa má dvě části a je dobré je nepomíchat: prvních 66 sekund je práce firmwaru a proběhne vždycky stejně, ať děláte cokoli. Všechno po nich je čekání na vás.

Prvních 66 sekund: to se děje samo

Not connected a scan rychlosti sériové linky. NSPanel Easy mluví s displejem na 921600 baud, kdežto NSPanel_HA_Blueprint na 115200. Displej si svou rychlost pamatuje, takže nový firmware zpočátku mluví do prázdna. Log to říká doslova - na 921600 sice nějaká odpověď přijde, ale je to smetí:

Baud scan: rx 228 bytes at 921600 bps but no 0xFF terminator - likely framing garbage
Baud scan: no response at 921600 bps
Baud scan: trying 115200 bps
Baud scan: rx 4 bytes at 115200 bps: 1A FF FF FF
Baud scan: found active rate 115200 bps

Hláška [W][nextion:110]: Not connected se do té doby v logu objeví desítky krát. Je to očekávané.

Display is not set. Restarting. není pád panelu. Je označená jako E a zní zle, ale je to součást zotavení - panel se nerestartuje celý, jen si vynutí nové navázání displeje.

Po navázání přijdou desítky hlášek Invalid variable name, Invalid component ID/name a Invalid page ID. Nový firmware v tu chvíli mluví se starým TFT z předchozího projektu - v logu je to vidět jako TFT: 2026041 proti ESPHome: 2026.7.1, k tomu Old TFT contract v0 — initializing EEPROM. Ten starý TFT prostě nezná komponenty, které nový firmware oslovuje. Zmizí to až po nahrání nového TFT (Krok 4).

Zbytek: panel čeká na vás

Blueprint version mismatch! a pak Receiving settings from Blueprint: 0.0% pořád dokola. Tady už panel nic nepočítá ani nevyjednává - ptá se Home Assistanta na nastavení a bude se ptát tak dlouho, dokud nemáte automatizaci přepnutou na nový Blueprint. Ta prodleva tedy není prodleva firmwaru, je to čas, který zaberete vy Krokem 3. Jakmile ho dokončíte, naskočí zbytek rychle - u mě 0 % → 66,7 % → 100 % za tři sekundy.

Praktický důsledek: Krok 3 klidně udělejte dřív než přeflashování, nebo hned po něm. Nemá cenu s ním čekat, dokud panel „nedojde", protože právě na něj se čeká.

Dokud panel neřekne „ready to run actions", nezasahujte

Nečekejte konkrétní čas - trvá to přesně tak dlouho, jak dlouho vám zabere Krok 3. Do té doby ty hlášky nic neznamenají a nemá smysl z nich cokoli vyčítat. Restart uprostřed toho začne celý ten proces znovu, včetně scanu rychlosti. Teprve řádek [I][nspanel.base:120]: The system is ready to run actions znamená, že je panel váš.

A pokud se v logu nehýbe vůbec nic ani po deseti minutách a Krok 3 už máte hotový, teprve pak odpojte panel od proudu a zapněte ho.

Bonus v logu: bohatší paměťová diagnostika

Až se panel rozjede, NSPanel Easy hlásí o paměti víc než jen volné bajty:

Internal:       230512 /  313308 bytes free (73.6%)
Internal min:   226724 bytes (watermark)
Internal blk:   110592 bytes (largest contiguous)
PSRAM:         2076676 / 2097152 bytes free (99.0%)

Vedle volné paměti tedy vidíte i watermark (minimum, na které kdy klesla) a největší souvislý blok. Při ladění je to výrazně užitečnější než jedno číslo - velké volné číslo totiž nic neznamená, když je paměť rozdrobená. Můj panel má po startu 73,6 % volné interní paměti, tedy pohodlnou rezervu.

Srovnání se starým firmwarem tady vědomě nedávám. Ty dva buildy jely v jiném prostředí (add-on v Home Assistantovi s ccache proti remote buildu bez něj, a build adresář se mezitím smazal a založil znovu), takže rozdíly v paměti nejde přičíst projektům. Byla by to přesně ta chyba, kterou popisuju v post-mortemu: ověřte měřicí sestavu, než uvěříte datům.

Jak poznáte, že nový firmware skutečně naběhl

Na stránce zařízení v Home Assistantovi musíte vidět diagnostické entity Version - ESPHome, Version - Blueprint a Version - TFT. Když tam nejsou, na panelu neběží konfigurace NSPanel Easy a nemá smysl pokračovat - postup na dohledání příčiny mám v samostatné sekci hlavního návodu.

Krok 3: Přepnutí automatizace na nový Blueprint

Tohle je nejelegantnější část celé migrace, protože existující automatizaci nepředěláváte. Změníte v ní jediný řádek.

Nejdřív si naimportujte nový Blueprint:

Případně ručně přes Nastavení → Automatizace a scény → Blueprinty → Importovat Blueprint s adresou:

https://raw.githubusercontent.com/edwardtfn/NSPanel-Easy/refs/tags/latest/nspanel_easy_blueprint.yaml

V seznamu teď budete mít Blueprinty oba. To je v pořádku a je to i potřeba.

Pak přepněte automatizaci:

1. Nastavení → Automatizace a scény, otevřete automatizaci svého panelu
2. V nabídce tří teček vyberte Upravit v YAML
3. Nahoře najděte sekci use_blueprint: a změňte jen řádek path:

use_blueprint:
  path: edwardtfn/nspanel_easy_blueprint.yaml   # bylo: Blackymas/nspanel_blueprint.yaml
  input:
    # ... vsechno ostatni zustava PRESNE tak, jak je

4. Uložit

Do sekce input: nesahejte

Tam žije celá vaše konfigurace panelu - entity, tlačítka, počasí, stránky. Právě tím, že změníte pouze path:, se všechno přenese do nového Blueprintu beze změny. Kdo se pustí do překlikávání ve vizuálním editoru, dělá si práci zbytečně.

Dva vstupy, které vám v automatizaci osiří

Tohle je druhá strana toho elegantního „změňte jen path:". Když sekci input: necháte být, vezmete si s sebou i vstupy, které nový Blueprint vůbec nezná. Na mém screenshotu výš jsou vidět oba:

    language: cs
    timezone: Europe/Prague (CET-1CEST,M3.5.0,M10.5.0/3)

Ověřoval jsem to proti nspanel_easy_blueprint.yaml na tagu v2026.7.1 a ani jeden z nich tam jako vstup neexistuje:

• timezone - v novém Blueprintu zrušený úplně.
• language - přesunutý do substituce v ESPHome YAML (viz Krok 1). Starý vstup v automatizaci zůstane ležet a nedělá nic.

Po přepnutí path: si tedy input: projděte a tyhle dva řádky smažte. Nic nerozbijí, ale matou - a u language je to zrádné o to víc, že to vypadá, jako by se jazyk pořád nastavoval tady. Zbytku input: se nedotýkejte, ten platí dál.

Po uložení se přepněte zpátky do vizuálního editoru a zkontrolujte, že nastavení sedí a automatizace ukazuje nový Blueprint.

Automatizace po změně path hlásí chybu

Home Assistant přiřazuje path podle toho, jak Blueprint naimportoval, takže se může lišit od toho, co čekáte. Zjistíte ho takhle: vytvořte z nového Blueprintu dočasnou testovací automatizaci, přepněte ji na Upravit v YAML, opište si skutečnou hodnotu path, použijte ji ve své reálné automatizaci a testovací pak smažte.

Starý Blueprint smažte teprve tehdy, až u něj ve sloupci In use uvidíte 0. Dokud tam svítí jiné číslo, nějaká automatizace na něm ještě visí.

Se mazáním starého Blueprintu nespěchejte

Ta nula se objeví hned, jak přepnete path: - takže mazat můžete okamžitě, ale nemusíte. Pokud si necháváte otevřená dvířka k návratu, nechte si ho v seznamu. Nic nestojí a bez něj se rollback neobejde: automatizace by odkazovala na Blueprint, který v Home Assistantovi není. Smažte ho až potom, co si budete na novém projektu jistý.

Krok 4: Nahrání TFT do displeje

Displej potřebuje TFT soubor odpovídající novému firmwaru. Firmware si ho umí nahrát sám, ale ověřte si, že to skutečně udělal - u mě ne.

Na automatické nahrání TFT se nespoléhejte

Měl jsem upload_tft_automatically: true a v logu i ten odpočet Starting auto-upload count down: 65 sec. Přenos přesto neproběhl a TFT jsem nakonec nahrál ručně. Poznáte to na stránce zařízení podle tří diagnostických entit:

Baud rate            115200 bps
Version - Blueprint  2026.7.1
Version - ESPHome    2026.7.1
Version - TFT        2026041      <- porad stary

Version - ESPHome a Version - Blueprint musí sedět (u mě obojí 2026.7.1). Když se u toho Version - TFT pořád liší, automatika nedojela a přenos musíte spustit sami.

Mimochodem Baud rate ukazoval pořád starých 115200 bps, protože rychlost si drží displej - a to se srovná právě až s novým TFT. Je to konzistentní s tím scanem rychlosti při prvním startu.

Jak poznáte, že se TFT skutečně nahrál

Po úspěšném přenosu vypadá ta stejná diagnostika takhle:

Baud rate            921600 bps
Version - Blueprint  2026.7.1
Version - ESPHome    2026.7.1
Version - TFT        20.0

Dvě věci se změnily a každá z nich je samostatné potvrzení.

Baud rate přeskočí na 921600 bps. Tohle je ta pohodlnější kontrola, protože nemusíte nic porovnávat s dokumentací - dokud tam svítí 115200, přenos nedojel. Rychlost si totiž drží displej a přepne se právě až s novým TFT. Je to ten samý mechanismus, který na začátku způsobí scan rychlosti, jen z druhé strany.

Version - TFT přestane být kalendářní číslo. NSPanel Easy verzuje TFT samostatně, nezávisle na firmwaru a Blueprintu - proto tam uvidíte 20.0 vedle dvou 2026.7.1. Vypadá to jako chyba, ale je to záměr: projekt má tři nezávisle verzované součásti. Kdežto 2026041 bylo kalendářní číslo ze starého projektu.

Nespoléhejte na konkrétní číslo, spoléhejte na jeho tvar

Požadovanou verzi TFT si každé vydání nese samo - pro v2026.7.1 je to min_tft_version: 20.0 v souboru esphome/nspanel_esphome_version.yaml. S dalšími vydáními se to číslo může posunout, takže spolehlivé pravidlo není „musí tam být 20.0", ale „nesmí tam být kalendářní číslo". Když u sebe pořád vidíte 2026041, běží vám starý TFT.

Ruční spuštění:

1. Otevřete stránku zařízení: Nastavení → Zařízení a služby → ESPHome → váš panel
2. V sekci Konfigurace nastavte Display model na svůj skutečný model
3. Stiskněte Update TFT display
4. Počkejte, přenos trvá 10-20 minut

Když se přenos nespustí nebo se zasekne, projděte postup podle příčin v hlavním návodu - nejčastěji za tím stojí Active Reparse Mode displeje, který zapnul předchozí firmware.

Po migraci nesahejte na volbu „NSpanel Easy EU"

V selektoru Display model je i volba NSpanel Easy EU (Under construction). Zní přesně jako to, co instalujete, a člověk po ní logicky sáhne - je to ale rozpracovaný nový design displeje, ne „TFT pro NSPanel Easy". Odtud to „(Under construction)". Nahrálo by se něco o velikosti 3,3 MB proti 13 MB hotového souboru a panel by nebyl použitelný.

Pro evropský panel vyberte NSpanel EU, i když migrujete na NSPanel Easy. Tohle je podle mě nejzrádnější věc celého procesu, protože ten název koliduje se jménem projektu.

Co dělá všech pět voleb včetně NSpanel Blank a co se ze selektoru kromě souboru ještě řídí, rozebírám v hlavním návodu.

Panel po migraci nenaběhl

Když panel zůstane černý, nepřihlásí se na Wi-Fi a ani odpojení od proudu nepomůže, nejde už o migraci, ale o obecnější problém ESP32 - nejčastěji zamčené safe mode, které nesmaže ani přeflashování. Celý rozbor včetně diagnostiky mám v samostatném článku Když NSPanel po aktualizaci nenaběhne.

Jak se vrátit zpátky

Kdyby vám cokoli nesedlo, rollback je stejně nenásilný jako migrace a panel se neotvírá ani při návratu:

1. Pokud jste starý Blueprint už smazal, naimportujte ho znovu - bez něj nebude mít automatizace na co odkazovat
2. V YAML vraťte url na https://github.com/Blackymas/NSPanel_HA_Blueprint a ref na hodnotu, kterou jste měl
3. Add-onům odeberte prefix esphome/
4. Nahrajte firmware (opět bezdrátově)
5. V automatizaci přepněte path: zpět na Blackymas/nspanel_blueprint.yaml

Pokud jste už mezitím nahrál nové TFT, nahrajte si zpátky i to původní.

Časté dotazy

Přijdu o nastavení? Ne. Substituce, Wi-Fi údaje ani nastavení automatizace se nemění - přenášíte je jednu k jedné.

Musím flashovat sériově? Ne, celá migrace jde po Wi-Fi. Jen nezapomeňte na ota_password: ${wifi_password}.

Můžu se vrátit zpátky? Ano, viz předchozí sekce.

Musím migrovat všechny panely zároveň? Ne. Každý panel je nezávislý, můžete jít jeden po druhém.

Panel po migraci mluví anglicky. Tohle je nejčastější dotaz vůbec. Jazyk se už nenastavuje v Blueprintu, takže vaše původní volba se nikam nepřenesla. Doplňte do substitucí language: cs, zkompilujte a nahrajte firmware znovu. V Blueprintu to nespravíte - sekce Localization v něm zůstala, ale řeší už jen formát datumu, času a jednotek.

Panel ukazuje čas s AM/PM. Jazyk se přenesl, formát času ne. Nastavíte ho v Blueprintu v sekci Localization - pro 24hodinový čas %H:%M. Podrobněji v Kroku 1.

Panel po migraci hlásí desítky chyb a displej nereaguje. Je to normální a nejčastěji to znamená, že ještě nemáte hotový Krok 3 - panel čeká na nový Blueprint. Rozebírám to v Prvním startu. Nezasahujte, dokud panel neřekne The system is ready to run actions.

Po migraci mám v automatizaci vstupy language a timezone, které nový Blueprint nezná. Přesně tak, přenesou se s nedotčenou sekcí input:. Nic nerozbijí, ale nic nedělají - smažte je.

Zmizely mi API akce, které volám z automatizací. upload_tft a wake_up se musí zapnout substitucí, viz Krok 1.

Musím měnit CJK variantu TFT? Ne, samostatné CJK varianty zmizely. Čínština, japonština a korejština jsou zabudované ve standardních TFT souborech, takže vyberte prostě model odpovídající vašemu hardwaru.

Odebral jsem před migrací bluetooth_proxy: - mám ho vrátit? Nedoporučuju. Důvody i změřená čísla mám v hlavním návodu. Praktické řešení je dát proxy na samostatnou ESP32, která má celou paměť pro sebe.

ESP32-WROOM

• WiFi
• Bluetooth

Koupit na AliexpressAliexpress3,63 $→

Zhodnocení

Čekal jsem od téhle migrace víc práce, než jakou nakonec vyžadovala: tři změněné bloky v YAML, jeden přepsaný řádek v automatizaci a pak už jen čekání na kompilaci a TFT. Že se nemusí sundávat panel ze stěny a hrabat se v sériové lince, je z mého pohledu ta nejcennější vlastnost celého postupu.

Pokazit se to dá vlastně jen na dvou místech - chybějící ota_password a volba NSpanel Easy EU v selektoru modelu. Když si na ty dvě věci dáte pozor, projde to na první pokus.

Nejnepříjemnější na tom celém ale nakonec byla ta jedna věc, která pokazit nešla: doba po restartu, kdy log vypadá, jako že jste si panel právě rozbil. Kdybych netušil, že panel jen čeká na Krok 3, sáhnu do toho - a začne to celé znovu. Když se na to dívám zpětně, měl jsem si Blueprint naimportovat ještě před přeflashováním a ušetřit si tři minuty nervů.

Související články

• Sonoff NSPanel v Home Assistantu: eWeLink, ESPHome a NSPanel Easy - kompletní návod na instalaci od nuly, hardware a pinout
• Když NSPanel po aktualizaci nenaběhne - rozbor jednoho výpadku
• ESPHome - Úvod a instalace

Zdroje

• Migrating to NSPanel Easy - oficiální migrační dokumentace projektu (anglicky)
• Dokumentace NSPanel Easy - včetně seznamu jazyků (anglicky)
• NSPanel Easy na GitHubu - zdrojové kódy a vydané verze
• Issue #3277 - Transitioning Development to NSPanel Easy - oznámení přesunu vývoje (anglicky)
• Discord komunity NSPanel Easy - nejrychlejší pomoc s potížemi (anglicky)