Zigbee, tasmota a NodeRed
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.
