Browsed by
Tag: nodered

Integrace HomeAssistant a NodeRed

Integrace HomeAssistant a NodeRed

Comments 3 comments

Tak dneska jsem si pro změnu hrál s propojením Home Assistant a NodeRed. Stále prozkoumávám, jak nejlépe to všechno spojit dohromady, a skoro mi začíná vycházet, že se bez NodeRedu neobejdu. Nevýhoda je, že to jsou zas 3 různé systémy, výhoda ale je, že je to s NodeRedem celé o dost snazší (a navíc rychlejší, protože to běží přes websocket).

Takže, aktuální vize je, že stejně jako mám v NodeRedu logiku na zigbee a iKamand, tak tam bude i hlavní logika na FVE. NodeRed si bude sosat data jak z HomeAssistantu, tak z Loxone, případně Loxone bude ty data do NodeRedu předávat on, to ještě doladím. Ale reálně v Loxone zůstane jen nějaká zobrazovací logika + přepínače/tlačítka, která ale budou spouštět věci v NodeRedu.

Je to trochu překombinované, ale pro mě jako vlastníka miniserveru v1 je to celé o dost rychlejší na práci i rozšiřování. Každá změna v LoxConfigu mi trvá v řádu minut, navíc nejde v LoxConfigu pořádně programovat, zatímco v NodeRedu si vyrobím logiku jakou potřebuju a změna trvá sekundu maximálně. Ale, nepředbíhejme, možná to ještě několikrát změním :).

NodeRed a HomeAssistant

Teď už k integraci. Do NodeRedu je potřeba doinstalovat node-red-contrib-home-assistant-websocket. Já jedu NodeRed přes docker, takže do DockerFile jsem si přidal RUN npm install node-red-contrib-home-assistant-websocket a hotovo. Jinde to bude potřeba řešit nějak přes addony v NodeRed UI zřejmě.

Po nainstalování a restartu NodeRedu uvidíte tyto prvky v levé liště. Je jich dost, sám v nich zatím lehce tápu, ale ty základní sem už pochopil :).

Prvotní propojení s HA je taky vcelku snadné, buď přes access token (long-lived access tokens), který vygenerujete v profilu uživatele:

a nebo pokud máte NodeRed přímo v Home Assistantu, tak je tam volba ”

Čtení hodnot z Home Assistantu

Čtení jde udělat dvěma způsoby. Jedno, kdy node red sám dotazuje HA v určitém intervalu a notifikuje hodnoty. Druhé, kdy se hodnota čte až když přijde vstupní signál.

Automatické čtení je realizováno pomocí “Events.: state” nodu:

zatímco čtení na základě eventy pomoci “current state”:

Nastavení obou je pak hodně podobné. Je potřeba node nějak pojmenovat (je fuk jak), vybrat připojený server, zadat entity ID (kterou zjístíme při kliknutí na entitu v HA a kliknutím na ozubené kolečko, viz minulý článek sekce “Bonusový krok, jak zjistit název ID stavu”).

Jako další pak jde zadat, zda má stav mít nějakou hodnotu, jak dlouho jí má mít, a v jakém formátu mají hodnoty z nodu vylézt. Výsledek pak je, že po načtení hodnoty vyleze z nodu něco jako:

{"_msgid":"8de529266cdb5849","payload":"1455","topic":"","data":{"entity_id":"sensor.solax_inverter_pv_power_total","state":"1455","attributes":{"state_class":"measurement","unit_of_measurement":"W","device_class":"power","icon":"mdi:solar-power-variant","friendly_name":"SolaX Inverter PV Power Total"},"context":{"id":"01KABAWW0DS8B1P1X0ACQY69H1","parent_id":null,"user_id":null},"last_changed":"2025-11-18T11:16:45.709Z","last_updated":"2025-11-18T11:16:45.709Z","timeSinceChangedMs":10125}}


kdy hlavní hodnota vyleze v “payload”, ale je tam připojeno i “data”, který obsahuje všechny ostatní informace, který HA vrátil.

Zápis hodnot do Home Assistantu

Zápis samotný mi dal zabrat trochu více, ale ve finále je to taky jednoduché. Jen člověk nesmí číst starší návody, kde se to jmenuje jinak :).

Zápis samotný se dělá pomocí univerzálního nodu “action” (takže až Vám budou návody říkat něco jiného, ignorujte je :)) :

V akci je potřeba opět zvolit název, server, a akci. Akce je, co se má v HA udělat. Může to být klik, může to byt togle, atd. je tam toho mraky. Abyste věděli, jakou akci volat, chce to se podívat zpět do HA a asi i trochu zkoušet. Já například chtěl nastavit % nabíjení baterie. Takže jsem šel opět do HA, do přehledu hodnot, klikl na danou hodnotu a otevřel nastavení:

tam, kde se dá zkopírovat ID entity je zároveň i prefix “number”. Opět, HA v tomto super, že má developer sekci, kde si to rovnou můžete nasimulovat. Otvírám tím pádem “Developer tools” a “Actions”. A stejně, jako když jsme testovali v minulém článku rest command, tentokrát otestujeme number.set_value.

V seznamu akcí vybírám number.set_value a do parametrů zadávám entity_id a value. V případě set_value jde navíc využít i UI režim, takže nemusíte skoro nic psát, jen si to tam naklikáte a pak se podíváte, jak YAML vypadá:

Po vyplnění stačí dát spustit akci a hned vidíte, zda se hodnota změnila či nikoli (pokud ne, zřejmě voláte jinou akci, kdy je tam například input_text.set_value, input_number.set_value` atd). Pokud se Vám hodnota úspěšně změnila, vracíme se do NodeRedu.

V prvku action tím pádem pokračujete vyplněním “action” jako number.set_value (nebo jakékoli jiné akce, kterou jste si vyzkoušeli, že Vám funguje). Jako další pak přidáte targets, kde si z dropdown prvku vyberete odpovídající propertu. v měm případě `number.solax_inverter_backup_nightcharge_upper_soc`.

A jako poslední zbývá zadat hodnotu, která se má poslat. Tady jsem se lehce zasekl, než jsem si všiml dole tlačítka “Load example data”.

Hodnota do “Data” se totiž nesmí zadat jako “30”, ale jako JSON objekt s propertou value a hodnotou “30”. Toto je lehce matoucí, ale když si člověk přečte spodní část obrazovky, kde je navíc tlačítko “Load example data”, které Vám to předvyplní, je to hotové raz dva.

Pak už jen stačí spustit akci a otestovat, že se Vám v Home Assistantu hodnota změnila.

Závěrem

Tak, tím pro dnes zas hotovo. Další způsob komunikace otestovaný. Zítra zkusím ve volné chvíli mrknout znovu na propojení Loxone a NodeRed. Kdysi jsem používal ten fajn addon na přímé propojení Loxonu a NodeRedu, ale blblo tam znovu-navázání spojení po výpadku. Tak mrknu, zda to tam náhodou už není doděláno, protože by to na toto bylo fajn.

Pak by byl Loxone opět jen v roli vizualizátora, NodeRed v roli logiky, a Home assistant jako gateway k zařízení. I když jsou to 3 různé systémy, ve finále to asi zas tak zlé nebude.

 

Ulanzi TC001

Ulanzi TC001

Comments 17 comments

Ahoj, tak dneska si dáme jeden gadget článek. Dorazila mi z Aliny další hračka, která je vlastně fakt jen pro radost, ale zato pro velkou radost :).

Jde o chytrý budík (dá li se tomu vlastně tak říkat), který jde flashnout lepším firmwarem a pak napojit na MQTT nebo REST API, takže pak ve finále z něj vlastně budík ani hodiny být nemusí :). Zařízení se jmenuje ULANZI TC001 a je fakt skvělé. Narozdíl od jeho dražšího (a zřejmě původně originálního) bráchy stojí jen 50usd (originál 200usd) a přitom podle mě funguje stejně skvěle (ale originál nemám, viděl jsem jen videa).

Zařízení se dodává s originálním čínským firmware, který sice také jde nějak někam napojit,ale cílová apka už není dále vyvíjená a jelikož je potřeba zařízení připojit do vlastní sítě, doporučuju raději flashnout pomocí open source firmwaru. Alternativní firmware se jmenuje AWTRIX 3, informace o něm najdete zde, a samotný flash pak probíhá plně automaticky z prostředí webové stránky pomocí připojeného USB kabelu do zařízení.

Flasher najdete na této stránce https://blueforcer.github.io/awtrix3/#/flasher (pro toto zařízení použijte první zmíněnou metodu na stránce)

Po naflashování Vám zařízení ukáže svou IP adresu a vytvoří wifi síť. Na tu se připojíte, nastavíte wifi credentials do Vaší sítě a hotovo. Zbytek už budete konfigurovat v rámci vlastní sítě přímo na zařízení.

Se zařízením se dá komunikovat buď přes MQTT nebo napřímo přes REST API. Dokumentace je detailně popsaná zde: https://blueforcer.github.io/awtrix3/#/api?id=switch-to-specific-app.

ULANZI TC001 má jednak 4 zabudované vlastní apky, a to čas, kalendář, teplotu a vlhkost, která se může střídat s Vašimi apkami, které mu nahrajete přes API, případně je můžete přes zařízení vypnout a nechat ukazovat jen Vaše data.

Možnosti jsou opravdu impozantní, jde se zařízením dělat spousta psích kusů. To hlavní je, že buď do zařízení nahrajete aplikaci pod nějakým jménem, pod kterým ji pak zas můžete odebrat, a nebo tam pošlete jen notifikaci, která se zobrazí jednorázově a pak zmizí. To se dělá pomocí příkazů /api/custom a /api/notify

Samotná zpráva pak může obsahovat (odhadem) tak 50 nastavitelných parametrů od barev, pozic, ikonek, progres barů, animaci, či třeba i vlastního kreslení po pixelu atd.

Na testování jsem zařízení narychlo propojil s NodeRED, kde jsem si udělal pár pokusů a rovnou začal sepisovat tento článek :). Proto jak vidíte je i samotný NodeRED dost ohavný, navíc v němčině, protože jsem si na první nastavení pomohl z repozitářů příkladů zde:  https://flows.blueforcer.de/search?provider=node_red

Samotný kód není nijak složitý. Pomocí funkce se připraví datový balík a ten pak pomocí REST api odešle:

Takto můžete své drahé udělat na valentýna radost. To prostě musí ocenit :))).

A to je vše. Až bude o víkendu (nevím teda kterém) trochu víc času, pohraju si s tím víc. Pokud někoho zařízení zaujalo a budete kupovat, pošlete pak fotky co všechno na něm zobrazujete :).

Migrace NodeRED z node-red-contrib-loxone na UDP/HTTP vstupy/výstupy

Migrace NodeRED z node-red-contrib-loxone na UDP/HTTP vstupy/výstupy

Comments 7 comments

Tohle bude trochu víc technický článek a hodim si ho sem hlavně i pro sebe, abych po čase zas věděl, jak mám ty vstupy a výstupy konfigurovat :). Už tentokrát mi dost pomohl tento můj historický článek, kde sem podobný problém jednou řešil.

Důvod celé migrace byl, že tento na první pohled skvělý plugin se občas odpojil od Loxone a už se nedokázal sám připojit zpět. Většinou se odpojil v situaci, kdy se Loxone svévolně zrestartoval a nebo když jsem dělal nějaké změny a vícekrát za sebou do něj nahrával nový LoxConfig. Bohužel, komponenta nejen že se neumí nějak snadno sama připojit, ale nemá ani žádný vstup/příkaz na to, aby se reconnect dal ručně vyvolat. Zkoušel jsem bug párkrát reportovat na githubu, ale bohužel marně. Poslední verze je rok a půl stará, takže to vypadá, že je možná plugin i lehce opuštěný.

Jediné řešení vždy bylo připojit se do NodeREDu, pohnout nějakým prvkem a dát znovu deployment. V tu chvíli se prvek krásně znovu připojil. Drobnost, ale vysvětlovat ženě, jak se má připojit k NodeRED, nebo večer před koupáním vždy běžet k počítači, protože nefungují světla nebylo úplně to pravé ořechové.

A tak i díky podnětům z komentářů pod minulým článkům jsem to hecl a rozhodl se včera zkusit pár zásuvek/světel předělat na UDP/HTTP vstupy/výstupy. Celý proces by trval určitě o dost kratší dobu, kdyby můj MS1 nedělal upload každého LoxConfigu cca minutu a hlavně, kdyby LoxConfig měl pořádně zdokumentované parametry vstupů + k nim měl nějaký debugging. Ale to už jsou spíš mokré sny 🙂

A tak pro sebe i ostatní sem nahážu pár ukázek, jak UDP/HTTP vstupy natavit na straně Loxone i NodeRED, ať to příště už nemusím zas složitě dohledávat. Pojďme na to:

Loxone Virtual UDP input / Virtuální UDP vstupy

Vytvořit Virtuální UDP vstup, nastavit mu unikátní UDP port:

Do něj pak vložit Virtual UDP input command, nastavit “Command recognition”. Pro On/Off jen samotnou hodnotu:

V případě potřeby načítat hodnotu, vložit do recognition \v pro “value”. (tady je to chyták, u vstupů se používá \v zatímco u výstupů <v>).

Loxone Virtual UDP/HTTP output / Virtuální UDP/HTTP výstupy

Vytvořit Virtual Output. V případě HTTP NESMÍ být v adrese celá cesta, ale vždy jen název serveru. Koumáci z Loxone to sice pojmenovali address, ale není to tak. Pokud je tam pak jakákoli URI, loxone dle logů padá na tom, že ji neumí přes DNS přeložit.

Do něj vložit Virtual output command. Pro on/off vyplnit Command for ON, Command for OFF (to je v případě HTTP URL za doménou zadanou v Address)

HTTP extensions je opět blbě pojmenované, jde o HTTP headers, které se mají vložit k požadavku. HTTP post command zvládli v Loxone pojmenovat správně a HTTP method také. V případě, že chceme zasílat při zapnutí i vypnutí různé data, vyplní se oboje, pokud chceme zasílat jen při zapnutí/změně hodnoty, vyplní se jen atributy pro ON.

Pokud potřebuje odeslat nejen ON/OFF, ale právě nějakou hodnotu, použijeme značku <v> (pozor, nikoli \v jako v případě vstupů).

Značku <v> můžeme použít i kdekoli uvnitř textu, tzn například “value:<v>” a podobně. Údajně jde takto poslat i textový výstup. Nemám to ale vyzkoušené.

NodeRED příjem dat

Vložit http-in (nebo UDP-ip), nastavit URL nebo port pro daný příkaz. Co je důležité, krom HTTP-in je potřeba také vložit a propojit HTTP response, aby po zavolání požadavku NodeRED požadavek ukončil a odeslal OK response.

Z prvku pak leze textový řetězec, který jsme do něj poslali. Pokud bychom posílali JSON, je potřeba vložit ještě “JSON parse” prvek, který text převede na objekt.

NodeRED odeslální dat

Vložit UDP-out prvek, nastavit cílovou adresu a port, na který se májí UDP data odeslat

Do prvku pak už jen krmíme data a on je odesílá směr Loxone

 

Závěr

A to je vše, takto lze propojit vstupy i výstupy z Loxone s NodeRED bez nutnosti použít nodered-contrib-loxone knihovnu. Je to škoda, protože jinak se knihovna používala parádně, ale bohužel absence automatického reconnectu ji dost vylučuje pro reálné použití (minimálně u nás doma 🙂 ).

Loxone-Zigbee světla, den druhý.

Loxone-Zigbee světla, den druhý.

Comments 20 comments

Tak jsem využil nakonec skoro celou neděli k tomu, abych pokračoval v akci světla. Po diskuzi se zkušenějšími Loxong guru jsem zjistil, že nový LoxConfig opravdu nabízí mnohem více v bloku ovládání osvětlení a umí přesně to, co se snažím udělat ručně v Loxone v8. Bohužel to ale jinak než ručně neudělám.

Ale nevadí, výzva je výzva a tak to dotáhnu. Nový MS2+KNX extension nyní nebudu kupovat, takže si musím poradit takto (a kvůli Quidu a elektroměrům nemohu provést update MS1 na poslední verzi).

Jen zopakuji to, co jsem již psal dříve – po celém domě předělávám osvětlení pomocí Zigbee světel tak, aby první tlačítko v každé místnosti fungovalo jako klasické hloupé – první klik zapne výchozí světlo, druhý klik vypne. Tlačítko vedle něj pak prvním klikem zapne tlumený režim a dále pak už rotuje scény, vypínání se dělá opět tlačítkem jedna. Tedy, když přijde kdokoli neznalý chytrého domu, bude na nic nepřijde a všechno bude fungovat intuitivně.

Po prvních problémech jsem nakonec vše vyřešil pomocí bloku RadioButton. Důvod, proč jsem zvolil RadioButton místo bloku ovládání osvětlení, je ten, že RadioButton reaguje již na vzestupnou hranu signálu, takže pocitově je rozsvícení světla v místnosti rychlejší, než když se rozsvítí až po uvolnění tlačítka.

Celou výše uvedenou logiku jsem pak dal dohromady tak, že na výstupu AQ z RadioButtonu pomocí zpoždění přenáším výstup zpět na vstup, kde ho pomocí AND/NOT prvků porovnávám a dle výstupu provádím buď zhasnutí nebo rozsvícení.

Abych vyřešil případné příliš dlouhé držení tlačítka, používám na vstupu ještě Monoflop, který mi udělá přesně definovaný signál bez ohledu na délku držení.

Třeba se to bude hodit někomu, kdo má také v8 a chtěl by něco podobného řešit.

Jako další výzva pak bylo přenést několik různých scén do Zigbee. Tady bych si zase rád poslechl, jak to řešíte ostatní. Já jsem to udělal pomocí NodeRED následovně:

Pomocí výstupu AZ vyčítám z RadioButtonu aktuálně zvolený výstup, který pak přenáším do prvku “Stav”. V prvku Stav pak pomocí jednoduché porovnávací tabulky převádím jednotlivé stavy na příkaz, který ukládám do “Text status”.

Příkaz má jednoduchou formu “Cílové světlo/Cílová světla oddělená čárkou” | “color_temp”/”color_xy” | brightness. Hodnoty vycházejí z hodnot podporovaných Zigbee2Mqtt.

Tyto hodnoty pak dále parsuji a zpracovávám už v NodeRED. Toto řešení jsem zvolil nakonec proto, že mi umožňuje přímo v LoxConfigu editovat různé profily, přidávat další profily, upravovat jas a celé nastavení je tak pohromadě. A až samotné zpracování je mimo.

Původně jsem zkoušel to řešit třeba přes značky nebo načítat přímo hodnotu RadioButtonu do NodeRED, ale vadilo mi, že logika nebyla uceleně na jednom místě.

Zpracování v NodeRED pak vychází ze systému, který jsem popisoval v minulých článcích například zde: https://www.vodnici.net/2022/09/zigbee-tasmota-a-nodered/

Jediný rozdíl je v přidané funkci “TransformLightCommands”, která bere obsah příkazu z volání z Loxone a překlápí ho na msg zprávu, kterou již podporuje můj stávající NodeRED systém, tzn. takový, který to pak pošle přes MQTT do Zigbee2Mqtt.

Jediné, co mi na tom ještě trochu nevyhovuje, je nutnost přidat pro každý status prvek samostatný Loxone-control-in prvek. Ale tomu se bohužel nijak nevyhnu. Aspoň je to zase přehledné, odkud všude se hodnoty vyčítají.

Zatím mám na tento systém překlopenou cca polovinu domu a vše vypadá, že funguje jak má. Budu to teď přes týden testovat a sledovat a pokud se to osvědčí, příští víkend překlopím zbytek.

Celý zdrojový kód k překladu Loxone příkazů do Zigbee2Mqtt formátu je k dispozici pro podporovatele blogu zde. Jak jsem avizoval v předchozím článku, kompletní kódy budou nově dostupné jako benefity pro podporovatele blogu.

Zatím je tam jen JavaScriptový kód na převod, ale pokud by byl zájem, přidám i celý NodeRED projekt na propojení Loxone-Zigbee2Mqtt do této sekce.

A to je pro dnes vše. Až bude zase chvilka, tak dám dohromady ještě článek o světlech samotných, protože se mi už množí dotazy, jaká světla s podporou Zigbee jsme vybrali.

 

Edit: Vytvořil jsem konečně článek, kde je nasdílený komplet projekt na ovládání Zigbee z Loxone, jak vstupy, tak výstupy. Nejen světla, ale i chytré zasuvky a integrace Ikea Round buttonu. Článek je dostupný pro všechny, kteří nějakým způsobem podpořili náš web.

https://www.vodnici.net/2023/11/projekt-pro-nodered-na-zigbee-vstupy-vystupy-vcetne-svetel/

Pokud někdo posílal nějaký donate a nejede mu to, napište mi prosím na [email protected], pošlete info kdy/jak jste posílali nějaký donate a já Vám oprávnění nastvím.

Zigbee, tasmota a NodeRed

Zigbee, tasmota a NodeRed

Comments 20 comments

Dnešní článek je pokračování mého minulého o migraci ze Zigbee2Mqtt na Tasmotu.https://www.vodnici.net/2022/09/upgrade-zigbee/ ‎. Jak jsem avizoval na závěr minulého článku, postupoval jsem podle návodů od Budulínka až do fáze, kdy jsem potřeboval dostat data z/do Loxone. Jelikož při více zařízeních je už z Tasmota logu dat opravdu hodně, nechtěl jsem svůj miniserver v1 tímto úplně zatěžovat, protože mám určitou představu, jak je asi v miniserveru parsování UDP vstupů optimalizováno a jak funguje :).

Můj plán nakonec byl odchýlit se od přímého napojení na Loxone a využít NodeRed, zároveň se ale vyvarovat MQTT protokolu, který mi na Zigbee přijde krajně nevhodný. Cílem tedy bylo parsovat UDP pakety na úrovni NodeREDu a pak už zpracovaná data dostávat do loxone přes Nodered-contrib-loxone. (Teda, původně jsem si říkal, že by mohl být přímo nějaký plugin na Tasmotu pro NodeRED). Ale od toho jsem velmi rychle upustil, když jsem zjistil, že je postavený opět nad MQTT namísto UDP).

A tak jsem začal vymýšlet, jak si to v NodeRED udělat tak, abych měl co nejméně duplicitního kódu, ideálně mít samostatně část na zpracovaní dat z/do Tasmoty a pak už v ostatních záložkách jen využívat takto předpřipravené prvky. Po chvíli hraní si jsem nakonec vymyslel systém pomocí nodu link-in a link-out, které umí předávat předpřipravené msgs mezi vzdálenými prvky.

Výsledek je, že mám dva typy link-in prvků, jeden, do kterého můžu vkládat předřipravenou zprávu ve formátu { device: XXX, data1:x1, data2:x2 } a druhý, ze kterého už lezou naparsovaná data z Tasmoty v podobném formátu.

Takto například konvertuju 0/1 hodnotu z Loxone control-in prvku do Tasmota formátu { "device":  "MiSmartPlug01",  "Power":"1" }.

To hlavní kouzlo se ale skrývá na poslední záložce. Zde mám dva transformační “programy”. První přijímá UDP záznamy z Logu tasmoty a pomocí JS funkce je rozparsuje a vyrobí z ních JSON objekt zmíněný v předchozím odstavci. Pomocí funkce switch pak tento objekt pošlu na konkrétní link-out. Toto by šlo řešit i tak, že se to pošle na univerzální link-out, ale znamenalo by to pak u každého využití testovat, zda jde o správu určenou danému prvku. Takže mi přišlo lepší si to rozházet už tady a posílat na konkrétně pojmenované výstupy.

Podobně pak funguje i druhý program, který pak naopak ze vstupních objektů udělá příkaz pro tasmotu ve formátu /cm?ZbSend {….} a pošle ho přes HTTP Api do Tasmoty.

A to je veškerá magie :). Díky tomu mohu mít logiku na Tasmotu strčenou bokem na serveru, kde je výkonu násobně více a parsování logů je tam hračka, a předzpracovaná data jsou pak elegantně poslaná do Loxone. Jasně, je potřeba ten NodeRED mezikrok, ale to mi osobně nevadí, naopak, spousta věcí se mi zde dělá lépe, než psát ručně dokola pofidérní parsovací stringy Loxone, které mi přijdou, že ne vždy fungují tak, jak bych čekal :).

Na závěr pak ještě jedno zamyšlení. Možná jste si všimli, že v programu pro ovladače ikea je každý udělaný trochu jinak. Zatímco ovladač pracovny je udělaný tak, že spíná univerzální vstupy vytvořené i v Loxone a až tam se napojuje na logiku, tak ovladač z ložnice je napojený na prvky Loxone napřímo.

Stále totiž hledám nějaký “nejlepší” způsob jak Loxone s ostatními zařízeními propojovat a toto je jeden z pokusů. Zatím musím říct, že první varianta mi přijde lepší. Sice to znamená vytváření vstupů/výstupů i na straně Loxone, ale dává to celému systému takovou lepší kulturu. Je pěkně oddělěno NodeRED zpracování dat, které komunikuje jen s konkrétními vstupy v Loxone na nějakém centrálním místě a až v Loxone se pak těmto vstupům dává konkrétní funkce.

Díky tomu se pak v celém LoxConfigu lépe orientuje a hlavně i po čase, když člověk hledá kde/co se proč děje, tak je to na jednom místě. Zatímco když do toho šahá NodeRED napřímo, je občas dost složíté dohledat, proč se něco zrovna seplo.

Tak to jen takový poznatek na závěr. Klidně napište, jestli máte ještě nějaký jiný sýstém organizace nebo k jakým závěrům jste po čase využívání došli vy.

Upgrade Zigbee

Upgrade Zigbee

Comments 5 comments

Tak jsem si po delší době doma zase trochu zabastlil, dokonce i pájku oprášil, a tak bude dneska i článek :).

Přinucen okolnostmi jsem se musel rozhodnout, zda dát dohromady rozbitý zigbee2mqtt, nebo se dokopat a využít skvělého návodu od Budulínka a přemigrovat celé Zigbee na Tasmotu (donucen proto, že po dvou výpadcích proudu v noci a nouzovém vypnutí serveru se mi rozbil databázový soubor zigbee2mqtt a celá síť se rozpadla).

Bohužel, včera nebyl zřejmě můj den a tak do čehokoli jsem se z toho pustil, tak ani se skvělým návodem mi prostě nefungovalo vlastně nic 🙂

Začal jsem flashováním pomocí Tasmotou doporučeným adaptérem. No, tak ten ani zaboha. Nejprve jsem myslel, že jsem si blbě napájel piny na připojení kablíků, nebo že jsem někde zapojil něco špatně. Ale proste nic. Neustále chyba “Unexpected error: ESP Chip Auto-Detection failed: Failed to connect to Espressif device: No serial data received.”. Když ani několikáté přeměření a překontrolování nepomohlo, zkusil jsem druhý adaptér. Naštěstí jsem totiž tenkrát objednal dle návodu od Budulínka oba dva.

A světe div se, fungoval napoprvé. Takže ponaučení číslo jedna, nespoléhat na oficiálně doporučené adaptéry a brát radši oba 🙂

Připojení do sítě pomocí ethernetu prošlo napoprvé a tak jsem pokračoval v nahrávání firmwaru do už flashnutého zařízení. I to proběhlo dobře a už jsem začínal mít pocit, že už bude jen dobře….

Nebylo :). Po restartu zařízení zahlásilo “zigbee not available” a nazdar. Skvělý. Takže jsem rozbil něco cestou při flashování?

Takže znova flash zpátky původního firmware, znova pokus na nový firmware, stažení i beta firmware…. a nic. Furt to stejné.

Tak jsem šel do logů. V nich nic neříkající hláška “ZGB: timeout, goto 99”. Ok, takže se zigbee zařízení nestihne ohlásit včas? A tak zas půl hodiny googlení.

Trvalo to, inženýři z Tasmoty se to snažili velmi úspěšně maskovat a schovat, ale našel jsem to. Problém není v Zigbee zařízení :).

Problém je (a ukáže se v logu, když dáte maximální detaily logování), že Tasmota se nedokáže připojit k NTP time serverům a synchronizovat čas, a proto zakáže Zigbee… ok.

Takže pokračovalo kolečko, proč se vlastně nedokáže připojit. Ukázalo se, že nefunguje DNS překlad NTP adresy. Ale proč..

No, odpověď pak už byla vcelku snadná. Protože mi výpadek elektriky sestřelil nejen Zigbee2mqtt VM, ale také PiHole DNS server. Takže ten přestal fungovat a zatímco ostatní zařízení umějí pracovat i se sekundárním DNS, které mám nastaveno, tak Tasmota ne.

Takže jsem cestou ještě obnovil zálohy PiHole VM, opravil DNS resolver a pak už tasmota najela včetně Zigbee adaptéru. Párování a nastavení Tasmoty pak šlo už naštěstí jako po másle, takže jsem jen následoval zmiňované návody.

A to až do fáze, kdy jsem začal propojovat Tasmotu s Loxone. Nakonec jsem se rozhodl nepoužít přímé propojení pomoci UDP parsování v Loxone, jelikož když jsem viděl, kolik dat se do Loxone hrne a že každý virtuální vstup musí data znovu a znovu parsovat. Proto jsem se nakonec rozhodl využít NodeRED a data předzpracovat. Přeci jen mám jen původní miniserver a takto jsem ho spamovat úplně nechtěl. Ale o tom v dalším článku.

Závěrem už jen poděkování Budulínkovi za jeho návody, ušetřilo mi to určitě hromadu dalšího času a nervů, a hlavně, celý systém mi teď přijde o dost stabilnější než původní Zigbee2Mqtt.

Seznam odkazů na návody na Tasmotu:

Netio PowerDIN 4PZ

Netio PowerDIN 4PZ

Comments 1 comment

Tak dneska tu mám představení nové hračky. Dostal jsem ji zase od firmy Netio, od které jsem dříve dostal chytré zásuvky na otestování. Tentokrát jde o jejich nový kompaktní chytrý prvek na Din lištu PowerDIN 4PZ, který ale umí opět všechny naše oblíbené protokoly 🙂

Když jsem byl osloven, jestli bych produkt nechtěl k otestování a k něčemu se mi nehodil, měl jsem vcelku jasno…… bazén :). Letos je v plánu dodělat ovládání našeho bazénu, zakopat všechny hadice a přepojit čerpadlo z prodlužky na venkovní rozvaděč.

Takže malý prvek, který dám do rozvaděče na DIN lištu se hodil naprosto přesně. Co se týká jeho vybavení, je opět naprosto parádní. Má 2x výstup 16A s integrovaným elektroměrem, dále pak 2x výstup jako NO/NC relé, 2x digitální vstup, Lan a WIFI. Takže spínání čerpadla, k tomu možnost spínání druhého zařízení, vstupy pak budou použity jeden pro rychlé spuštění čerpadla při čistění bazénu a druhý zatím zůstane asi nevyužit, ale můžu na něj dát třeba vodoměr, abych věděl, kolik vody jsem profiltroval :)). K tomu pak rovnou díky integrovanému elektroměru získám měření spotřeby čerpadla bazénu. Ideální.

 

Vše jde ovládat jak přes Modbus/TCP, tak přes MQTT nebo XML HTTP REST. Takže integraci lze udělat buď přes NodeRED, nebo napřímo z Loxone přes Modbus.  Koupit lze PowerDIN už nyní na jejich eshopu za 6189 bez dph (7489 s dph).

Zatím mi tu leží v krabici, takže není moc co víc fotit. Věřím ale, že už konečně venku roztaje sníh a začne být i trochu pěkně, takže půjde odzimovat bazén a pustit se do všech potřebných prací :). Další články snad už soon :).

Nový workflow NodeRED+Loxone a nové Lidl zigbee hračky

Nový workflow NodeRED+Loxone a nové Lidl zigbee hračky

Comments 14 comments

Tak jsem se konečně dostal k nákupu chytrých zásuvek od Lidlu. A rovnou jsem do košíku přihodil ještě chytré světlo, které tam nově mají. Světlo chci použít v pracovně jako noční “přisvětlení”, abych nemusel při nočních šichtách svítit velkým světlem, ale zároveň nekoukal po tmě do monitoru.

Začnu nejprve Zigbee zásuvkami. Designově jsou opravdu povedené. Na obrázcích v eshopu vypadaly o dost hůř. Bohužel se v eshopu momentálně vůbec neukazují, takže ani nemůžu přiložit obrázek na srovnání.

Napárování se zigbee2mqtt proběhlo u jednoho kusu napoprvé, druhý kus pak nějak kompletně rozbil databázi zařízení :). Psalo to divné chyby o neexistujících cestách mezi zařízeními, přestal fungovat Zigbee2MqttAdmin panel a celkově se to úplně rozložilo. Řešením bylo buď vytáhnout zálohu Zigbee2Mqtt nastavení, nebo odmazat poslední napárované zařízení v database.db souboru (je to JSON) a napárovat znova, kdy už pak vše jelo jak mělo.  Když už jsem byl v tom, tak jsem rovnou aktualizoval i všechny komponenty v Dockeru, takže možná problém vyřešila i nějaká aktualizace. Moc jsem po tom nepátral a byl jsem rád, že to zase jede :).

Propojení NodeRed+Loxone

Co se týká propojení s Loxone, stále hledám optimální cestu. Řešení, kdy jsem v NodeRED přímo ovládal zařízení v Loxone se mi nelíbilo, protože pak člověk nemá přehled, kde se co děje. Takže nyní testuju trochu jiný přístup, kdy komunikace mezi NodeRED a Loxone je výhradně skrz virtuální vstupy a značky a samotná logika pak je napojena až v LoxConfigu. Je to sice o trochu pracnější, ale zatím mi to vyhovuje o dost víc.

Díky tomuto rozložení pak NodeRED je opravdu jen jakýsi most mezi technologiemi. V LoxConfigu pak mám jednu stránku, kde jsou všechny tyto značky a vstupy pohromadě, aby bylo vidět, co všechno do Loxone přes NodeRED jde.

Stejnou značku pak vytáhnu buď i ke konkrétnímu prvku, nebo si udělám už nějakou konkrétně pojmenovanou značku dle akce a tou to propojím mezi listy. Takže například vstup z Ikea tlačítka napojím rovnou na blok ovládání, zatímco komplexnější logiku, která spínala několik různých vánočních světel po domě mám schovanou pod značkou “act-VanoceObyvak” a až tu pak protáhnu skrz celý Loxconfig. Je to sice trochu více práce, ale je to o dost přehlednější, když se k tomu pak po čase vracím.

Když něco nejede, mám všechny vstupy/výstupy z NodeREDu na jedné záložce a snadno se to testuje. Když byla logika původně z NodeRED napojena například přímo na blok osvětlení, tak najít co/kdo to sepl bylo peklo :).

A celý tento systém má ještě jednu výhodu. Ne všechny prvky jdou přes Websockets v Loxone ovládat, případně třeba chybí některé příkazy (například toggle u konkrétního výstupu bloku osvětlení). Ale když si to do Loxone člověk dostane přes značku, tak už s tím uděla v Loxconfigu cokoli.

Lidl zigbee světlo

Co se týká Zigbee světla, tak provedení i světelnost mi na moje potřeby přijde dobrá. Ovládání je v Zigbee2Mqtt připraveno už velmi pěkně, takže jde na světle ovládat spoustu věcí, od klasického zapni/vypni, po různé barvy, teplotu barvy, ale i různé efekty.

Propojení mezi NodeRED a Loxone opět stejně jako v případě zásuvek. Tzn v Loxone mám značku on/off, na kterou je napojen pak NodeRED přes Loxone NodeRedContribLoxone komponentu. Nastavení barev mám na otestování udělané jen narychlo napřímo v NodeREDu:

Takhle vypadá přepínání barev. Myslím, že za ty prachy dobré :). Asi to reálně nikdy nevyužiju, ale na hraní supr :)))).

 

 

 

Jak jsem psal, nastavení barev z Loxone zatím neřeším. Pokud bych našel chvilku, tak si s tím víc pohraju a ještě napíšu článek. Bohužel jsem na tom teď časově ještě hůř než dřív, takže nebylo moc prostoru si s tím pohrát tak jak bych chtěl (a to si vždycky myslím, že už to s časem horší být nemůže :)).

NodeRED – více instancí

NodeRED – více instancí

Comments 0 Comment

Dnešní článek bude jen taková rychlovka na zamyšlení. Díky všem pokusům, co s NodeRED poslední dobou dělam, jsem se rozhodl vytvořit si dvě různé instance NodeRED.

Jedna je produkční, kde bude jen ostrý kód, který běží nonstop. Druhá pak bude developerská, kde budu testovat vše možné a kde bude v záložkách zůstávat i testovací bordel.

Díky docker-compose to není žádný problém. Každá instance používá svoje vlastní úložiště, zbytek mají obě instance naprosto totožné. Pro vývoj nových věcí tak používám developerskou instanci a pak pomocí import-export výsledek přenesu do produkční instance.

Můj aktuální kód pro NodeRED vypadá následovně:

FROM nodered/node-red

RUN npm install bufferutil 
RUN npm install utf-8-validate

RUN npm install node-red-node-smooth
RUN npm install node-red-dashboard
RUN npm install node-red-node-ui-list
RUN npm install node-red-contrib-zigbee2mqtt
RUN npm install node-red-contrib-loxone
RUN npm install node-red-contrib-tgr-jsonata
RUN npm install node-red-contrib-xiaomi-sensors

RUN npm audit fix

A to je pro dnešek vše. Přišlo mi to jako dobrý nápad a třeba to inspiruje i někoho dalšího. Příště pak mám v plánu pár ukázek napárování zigbee na Loxone, konkrétně Ikea pětitlačítko, které se mi zatím hodně líbí. Mám na něm v pracovně světla, žaluzie i plachtu pergoly. Dál pak Sonoff tlačítka a chytré zásuvky.

ZIGBEE – NodeRED a Loxone

ZIGBEE – NodeRED a Loxone

Comments 22 comments

Tak jsem tu zas s dalším Zigbee článkem. Opět navazuje na mé předchozí trable s NodeRED. Dneska to bude o něco méně problémů, ale přeci jen tam jedna drobnost je :).

Dnešním pluginem, který bych chtěl představit, je node-red-contrib-loxone. Ten umožnuje napojení se na Loxone skrz Websocket přímo z NodeRED, takže není potřeba vytvářet žádné virtuální vstupy, složitě posílat UDP a nějak to na straně Loxone parsovat.

Plugin je postaven nad komponentou node-lox-ws-api od Alladdina, který se občas vyskytuje i tady u nás na fóru.

Co se týká funčnosti, komponenty fungují parádně. Umí ovládat v Loxone cokoli, co má svůj viditelný Uuid směrem do vizualizace (webové rozhraní či app). Pokud tedy chci cokoli ovládat, připravím si na to třeba tlačítko a na to se pak napojím z NodeRED.

Plugin opět umožnuje pomocí comboboxů snadný výběr prvků z Loxone, takže není potřeba někde lovit Uuidy prvků, ale jednoduše si člověk pomocí výběru místnost-kategorie-prvek může zvolit přesně co potřebuje.

Drobná nevýhoda je, že do prvku pak člověk musí poslat přesně data, která Loxone očekává. Není zde žádná mezivrstva, která by to udělala za Vás. To je ale pochopitelné, protože těch typů prvků je hromada a musel by zde Alladdin či Zigbee2Mqtt udržovat obrovský seznam všech příkazů. Je proto o dost snazší podívat se do dokumentace pro Websocket API a poslat správný příkaz přes msg.payload.

Jediné, co mi zlobí, tak jakmile je nakonfigurován Loxone miniserver pomocí tohoto pluginu, tak deploy projektu občas trvá i pár sekund. Netuším, jestli je chyba někde na straně Alladdina nebo tvůrce NodeRED pluginu, ale do logu to háže chybu “Close time out”. Jako kdyby se to při deploy nejprve snažilo ukončit spojení s Loxone, což se ale nepodaří do daného časového limitu.

Řešení zatím neznám, ale není to nic, co by bránilo používání. Jen holt občas deploy trvá cca 3-5sekund namísto pár milisekund.