Browsed by
Tag: zigbee

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.

Světla, Zigbee a NodeRED

Světla, Zigbee a NodeRED

Comments 17 comments

Ještě jsem to zatím nepsal, ale přes zimu jsem konečně dořešil veškerá světla v domě. Dlouhé roky odkládání a nechuti to řešit jsem nakonec hecl, a udělal vše najednou. Hlavní důvod, proč se mi to nechtělo řešit a na čem se to vždy zaseklo byla svítivost. Aby to nesvítilo ani málo ani moc, aby to mělo správný odstín atd. A tak jsem to nakonec vyřešil tak, že jsem všude koupil Zigbee regulovatelná světla, která jsou buď plno barevná, nebo alespoň regulace jasu a bílé.

Světla jsou namontovaná a tak přichází ta na řadu SW část. A tady momentálně trochu klopýtám, a tak jsme si říkal, že z toho udělám postupně sérii článků na téma “Jaké všechny způsoby jsou a co z toho nakonec vyleze :)”.

Můj momentální use-case, který se na světla snažím napojit je, že každá místnost bude mít většinou 3 režimy. Plné svícení žlutou barvou na běžné používání, plné svícení bílou barvou když je potřeba extra světlo, a tlumené noční svícení žlutou barvou na noc. A ovládat tuto kombinaci chci ideálně dvěma tlačítky na zdi, s tím že nechci žádné multi-kliky a jiná zvěrstva, která Loxone nabízí.

Moje vize je, že první, hlavní a podsvícené tlačítko v místnosti rozsvítí vždy výchozí režim a druhý klik vždy zhasne. Zatímco druhé tlačítko bude sloužit v prvním kliku k rozsvícení nočního režimu, druhým klikem k přepnutí na bílý, třetí pak klidně na žlutý a čtvrtý na vypnuto například (to mi je celkem jedno). Ale důležité je, aby první tlačítko vždy zhaslo světla, pokud svítí jakýkoli režim. A tady je s Loxone problém (alespoň v mé v8 verzi, ale dle dokumentace se to asi ani v dalších verzích nezměnilo).

Co bych potřeboval, aby (+) vstup fungoval tak jak funguje, ale S2 vstup měl možnost zadat, že když je režim 0, tak zapni režim S2, ale když svítí jakýkoli režim, tak S2 přepne světlo do režimu 0, tzn. ho vypne. A to samozřejmě nejde. A tak jsem začal vymýšlet.

První, vcelku logická úvaha byla, vyčítat výstup AQs a když je výstup 0, tak pošli signál na S2 a když je nenulový, pošli na vstup R.

Tzn. něco takového. Jenže, toto nefunguje. Problém je, že zatímco S2 vstup se spíná až se sestupnou hranou, tak R se spíná se vzestupnou hranou. Takže v okamžiku, kdy člověk namáčkne tlačítko, tak v případě rozsvíceného režimu správně uvede prvek Ovládání osvětlení do vypnutého stavu, jenže při uvolnění kliku ho pak rovnou i zpátky zapne. Jen proto, že se S2 chová jinak než R a nelze to nastavit (v mé v8 verzi, nevím jak dále, klidně piště, jestli už je to někde fixnuto). Další problém jsou pak nevzhledné čáry v diagramu, kdy s nimi nelze jakkoli hýbat, ale to už je možná v dalších verzích opraveno, to jsem nezkoušel.

Každopádně zpět k problému. Jednoduchým řešením tohoto problému by bylo mít buď možnost přepnout Sx nebo R, aby fungovaly nastejno. To jsem nikde nenašel, že by šlo. Druhým řešením by byl prvek, který by konvertoval vzestupnou hranu na vzestupnou, tzn. něco, co by vyslalo impulz poté, co je vstupní impulz ukončen. Bohužel, to se mi rovněž nepovedlo najít, ačkoli mi to připadá jako běžný usecase a možná jsme něco přehlédl (a proto sem i psal post na fórum, ale zatím bez odpovědi).

A tak jsem došel k tomuto řešení. Vychází z předchozí úvahy, jen řeší problém přenesení již změněného stavu znovu na začátek tím, že do cesty vkládá ještě prvek “zpoždění vstupu a výstupu”, takže poté, co člověk přepne, tak ještě 1-2s je na výstupu původní stav, takže to během kliku nezpůsobí vypnutí a zapnutí zároveň. Nevýhoda tohoto řešení je, že pokud člověk podrží tlačítko déle než nastavené zpoždění, tak se cyklus opět provede, a naopak pokud klikne na tlačítko 2x za sebou rychleji než je teoo zpoždění, tak se nic nestane. Tzn nelze rozsvítit a hned zhasnout.

Oba případy sice nejsou nic častého, ale není to zrovna elegantní řešení. Navíc to znamená mít v každé místnosti toto diagramové monstrum, což se mi taky ještě úplně moc nepozdává. Bohužel, zatím sem na nic lepšího nepřišel. Teoretické možnosti jsou buď napsat si logiku bokem v NodeRED, ale to moc nechci. Toto mi přijde, že by mělo byt komplet na straně Loxone.

A tím pro dnešek skončím. Pokud jste něco podobného řešili, ať už způsob ovládání více režimů nějak více tlačítky, nebo problém s ovládáním osvětlení, dejte prosím vědět. Stejně tak, pokud novější verze LoxConfigu něco z toho nějak řeší lépe. Sám pak dám v dalším článku vědět, jak jsem to vyřešil, stejně tak bude ještě článek o tom, jak jsem nakonec vymyslel přenos režimů z Ovládání osvětlení do NodeRED a Zigbee. To má asi taky mraky různých řešení, tak mě bude zajímat, jak jste to řešili ostatní :).

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:

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 :)).

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.

ZIGBEE – NodeRED a Zigbee2MQTT podruhé

ZIGBEE – NodeRED a Zigbee2MQTT podruhé

Comments 5 comments

Tak jsem tu s dalším článkem z mé Zigbee minisérie (i když jestli to půjde jako do teď, tak to bude větší série 🙂 ). V minulém článku jsem popisoval problém se Zigbee2MQTT díky staré verzi NodeREDu, dnes se podíváme na další komplikaci v Zigbee2MQTT.

Zigbee2MQTT podruhé

U Zigbee2MQTT ještě zůstaneme. Tentokrát ale (nakonec) ne u pluginu, ale u SW brány samotné. Dalším problémem, který se mi děl a který byl hodně špatný, bylo chybné opakování poslední zprávy při deploy projektu.

V praxi se to chovalo tak, že jsem stiskl zigbee tlačítko, to poslalo MQTT zprávu a provedlo například “toggle” příkaz na světle. Tzn. přehodilo stav ze zaplého do vyplého či naopak.

Problém ale nastal, když jsem udělal změnu v projektu a dal deploy. Po naběhnutí celého projektu se tento “toggle” (a i všechny ostatní) provedly znovu. To znamenalo, že se mi náhodně zapínaly a vypínaly světla či chytré zásuvky. Nic moc.

Původně jsem podezříval opět plugin Zigbee2Mqtt, jenže stejná chyba se děla i při použití základního MQTT prvku. Problém byl tudíž někde v MQTT samotném, případně v Zigbee2MQTT.

MQTT jako takové má vlastnost, že u každé zprávy lze zadat “retain” příznak. Zpráva s tímto příznakem se nejen pošle všem příjemcům v době zaslání, ale zároveň se její stav uchová a pošle se i všem novým posluchačům.

Vše tudíž vypadalo, že by to mohlo být ono. Ale proč se to děje. Podle dokumentace Zigbee2MQTT mají zprávy “retain” defaultně vypnutý (link zde) a v NodeREDu tento příznak taky nikde nenastavuji. Takže, WTF :).

Na pomoc jsem si tedy vzal MQTT Explorer, který je super věc na debugování podobných problémů. Lze realtime sledovat veškeré zprávy i jejich poslední stav. A v případě, kdy má zpráva příznak “Retain”, je tam zobrazen následovně:

No, a co byste řekli. Měl ho tam :). Takže někdo nějak posílal RETAINED zprávy, které zůstávaly viset v MQTT frontě a při restartu NodeRED programu se pak vždy vyhodnotily znovu.

Podobné chování se hodí například u okenních senzorů, či jiných prvků, kdy i po restartu potřebujete v NodeREDu nastavit poslední známý stav. Je to ale dost na h*** u tlačítek, kdy Vám to probliká celým domem :).

Nakonec se ukázalo, že chyba je v samotné Zigbee2MQTT konfiguraci. Z nějakého mně zatím nepochopitelného důvodu se všem nově napárovaným zařízením automaticky nastavuje i retain:true, příznak, ačkoli o tom dokumentace mlčí (NodeRED UI administrace toto nejde nastavit ani se nijak neukazuje). To bohužel pak zůsobuje výše popsané problémy, které mohou být pro spoustu uživatelů asi dost deprimující 🙂

Řešením tudíž je odmazat retain:true příznak z konfiguračního souboru configuration.yaml pro všechna zařízení, kde toto chování nedává smysl (defakto všude krom teploměrů a čidel).

Po odmazání je potřeba restartnout Zigbee2MQTT kontejner či službu, aby se nastavení znovu načetlo. Tím je problém vyřešen a už žádné samozapínání při restartu.

Ikea TRÅDFRI+ Zigbee + Loxone

Ikea TRÅDFRI+ Zigbee + Loxone

Comments 44 comments

Dnes trochu atypicky jeden krátký (nakonec se mi to celkem protáhlo :)) post na přání z publika :). Byla tu prosba o návod na propojení Ikea tlačítka TRÅDFRI z Ikea do Loxone pomocí Zigbee2Mqtt.

A protože další připravené články se zabývají trochu jinými tématy, rozhodl jsem se návod sepsat teď narychlo ve formě nového článku.

Celé schéma aktuálně vypadá takto. Ten horní pravý control-out je příprava na ovládání výsuvné pergoly, ale protože pořád prší, ještě jsem to raději nezapojoval a netestoval :).

V levé části grafu je Zigbee2Mqtt IN prvek pojmenovaný IkeaRoundButton01 dle názvu zařízení v konfiguraci Zigbee2Mqtt.

Jeho nastavení je Server (Zigbee2MQTT server), device(což je toto tlačítko) a jako výstup si z prvku bereme kompletní payload, tzn celý JSON objekt s daty ze zigbee.

Druhý z leva je prvek SWITCH. V něm lze zadat jeden až n podmínek, které když jsou pravdivé, tak vyšle na odpovídající výstup daného znovu celý svůj vstup.

Tzn prvek nikterak neupravuje vstup, jen ho přepošle na jeden z výstupu dle toho, která podmínka je platná.

Poslední parametr určuje, zda se vyhodnocuje do prvního platného pravidla, nebo vždy všechny. Tzn pokud se nastaví “všechny”, může se aktivovat více než jeden výstup. V mém případě je to jedno, je platná vždy jen jedna podmínka.

K rozhodování, která akce byla na tlačítku provedena testuji JSON atribut msg.payload.action (nastaveno v “property” prvku switch). Pro získání těchto hodnot je nejjednodušší si na začátku napojit DEBUG prvek (ten zelný) přímo na Zigbee2MQTT IN prvek a sledovat co z něj chodí.

Jak jde vidět v debug výstupu, z Zigbee2MQTT IN prvku leze JSON, ve kterém je properta action, battery a linkquality. Nás pro toto rozhodování zajíma jen ta akce, proto msg.payload.action.

 

Třetím prvkem z leva je prvek EXCHANGE. Ten je trochu nešikovně pojmenovaný, protože je to defakto přiřazení do proměnné (připadně změna, smazání či prohození).

 

Lze opět nastavit jeden či více kroků, ale pro naše účely nyní stačí jen jeden. Do přijatého msg.payload (ve kterém se ve chvíli vstupu nachází ještě JSON objekt ze Z2M) přiřadíme úplně jiná data (konkrétně textový řetezec). A to konkrétně taková, kterým bude pro změnu rozumět node-red-contrib-Loxone (dokumentace k Loxone WS třeba zde).

Na screenshotu je příkaz “up”, který posílám do bloku žaluzií. Tím říkám Loxone, aby začal vytahovat žaluzie. Dále pak na základě tlačítka posílám také UpOff, kterým se vytahování vypíná (při uvolnění tlačítka), a down a DownOff na spuštění dolů.

Zároveň zasílám up/down také po kliku na tlačítka. Zatím testuju co je pohodlnější a rozhodně je to jen kliknout a dalším klikem případně vypnout. Takže dlouhé podržení bude pravděpodobně vysunutí pergoly, které nechci, aby se spustilo jen náhodným/omylným kliknutím.

Po kliknutí na prostřední tlačítko pak posílám příkaz “plus”, kterým se přepínají scény v prvku ovládání osvětlení. Kdyby to bylo klasické tlačítko, příkaz by byl “toggle”. Bohužel se mi nepodařilo u bloky ovládání osvětlení vynutit zapnutí/vypnutí konkrétního světla, funguje mi jen přepínání scén.

Posledním prvkem v pravo je pak samotné napojení na WebSocket Loxone. V tomto prvku se nastavuje cílový miniserver, místnost/kategorie a prvek, do kterého se příkaz má poslat.

Do tohoto prvku musíte poslat příkaz, který splňuje podmínky Loxone WS. Ten jsme si připravili v předchozím kroku v prvku Exchange. Vstup vypadá například takto: msg.payload = “plus”. (Jde o obyčejný string zaslaný na cílový prvek).

A to je vše. Pokud jste postupovali podle tohoto návodu, právě jste přijali kliknutí Ikea TRÅDFRI tlačkítka přes Zigbee síť transportovanou přes MQTT protokol do NodeRED, který pak data zkonvertoval do WebSocket příkazu poslaného do Loxone. Snadné, ne? :)).

Pro případné zájemce, zde je NodeRED projekt na celou tuto logiku (stačí dát import a přes clipboard vložit):

[{"id":"c333e3da.bfcd3","type":"zigbee2mqtt-in","z":"4e77380b.b5af18","name":"","server":"4dd4dc36.2cc704","friendly_name":"IkeaButtonRound01","device_id":"0x842e14fffea3ff09","state":"0","outputAtStartup":true,"x":210,"y":240,"wires":[["20102bbc.6f9cb4","9fb1f206.7c05c"]]},{"id":"20102bbc.6f9cb4","type":"switch","z":"4e77380b.b5af18","name":"","property":"payload.action","propertyType":"msg","rules":[{"t":"eq","v":"brightness_up_click","vt":"str"},{"t":"eq","v":"brightness_up_hold","vt":"str"},{"t":"eq","v":"brightness_up_release","vt":"str"},{"t":"eq","v":"brightness_down_click","vt":"str"},{"t":"eq","v":"brightness_down_hold","vt":"str"},{"t":"eq","v":"brightness_down_release","vt":"str"},{"t":"eq","v":"toggle","vt":"str"}],"checkall":"false","repair":false,"outputs":7,"x":450,"y":240,"wires":[["be2577c2.997838"],["be2577c2.997838"],["3373d424.306ccc"],["c3e9d441.d0f198"],["c3e9d441.d0f198"],["9ce742fe.a0b25"],["97d7dcbb.f8e2a","fe05d856.cb7ef8"]],"outputLabels":["","","","","","","toggle"]},{"id":"c3e9d441.d0f198","type":"change","z":"4e77380b.b5af18","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"down","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":700,"y":200,"wires":[["f96c30e8.7c3f2"]]},{"id":"9ce742fe.a0b25","type":"change","z":"4e77380b.b5af18","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"DownOff","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":700,"y":240,"wires":[["f96c30e8.7c3f2"]]},{"id":"be2577c2.997838","type":"change","z":"4e77380b.b5af18","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"up","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":700,"y":120,"wires":[["f96c30e8.7c3f2"]]},{"id":"3373d424.306ccc","type":"change","z":"4e77380b.b5af18","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"UpOff","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":700,"y":160,"wires":[["f96c30e8.7c3f2"]]},{"id":"f96c30e8.7c3f2","type":"loxone-control-out","z":"4e77380b.b5af18","name":"","miniserver":"33d50a38.be2cc6","control":"160f9394-0337-d464-ffff3b22d8e2f329","x":910,"y":180,"wires":[]},{"id":"97d7dcbb.f8e2a","type":"change","z":"4e77380b.b5af18","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"plus","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":700,"y":280,"wires":[["38ab62ac.e8c79e","68c1752.9451b8c"]]},{"id":"38ab62ac.e8c79e","type":"loxone-control-out","z":"4e77380b.b5af18","name":"","miniserver":"33d50a38.be2cc6","control":"0e6f3276-00d7-0359-ffff01c79402a3b1","x":910,"y":280,"wires":[]},{"id":"c8d1c8cf.917108","type":"comment","z":"4e77380b.b5af18","name":"Ikea 5-ovladac pracovna","info":"","x":210,"y":80,"wires":[]},{"id":"d7dee6f.2f79718","type":"loxone-control-out","z":"4e77380b.b5af18","name":"","miniserver":"33d50a38.be2cc6","control":"160f9394-0337-d464-ffff3b22d8e2f329","x":910,"y":80,"wires":[]},{"id":"9fb1f206.7c05c","type":"debug","z":"4e77380b.b5af18","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":460,"y":360,"wires":[]},{"id":"fe05d856.cb7ef8","type":"debug","z":"4e77380b.b5af18","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":720,"y":360,"wires":[]},{"id":"68c1752.9451b8c","type":"debug","z":"4e77380b.b5af18","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":960,"y":360,"wires":[]},{"id":"4dd4dc36.2cc704","type":"zigbee2mqtt-server","z":"","name":"zigbee","host":"host-mosquitto","mqtt_port":"1883","mqtt_username":"","mqtt_password":"","tls":"","usetls":false,"base_topic":"zigbee2mqtt"},{"id":"33d50a38.be2cc6","type":"loxone-miniserver","z":"","host":"x.x.x.x","port":"80","enctype":"2","active":true,"keepalive":"30000"}]

 

ZIGBEE – NodeRED a Zigbee2MQTT

ZIGBEE – NodeRED a Zigbee2MQTT

Comments 10 comments

Jak jsem slíbil v minulém článku, dnes bude další pokračování o mé Zigbee cestě. A musím říct, že nepokračovala úplně vesele. Dost jsem se zasekl na NodeREDu, protože se vše chovalo opravdu značně náhodně.

Následující dva tři články tak budou postupně představení několika super komponent a zároveň i návod, jak řešit případné problémy. Dnes začnu s pluginem Zigbee2MQTT do NodeRED.

Zigbee2MQTT

První věc, která mi v NodeRED udělala opravdu radost, je plugin node-red-contrib-zigbee2mqtt, který je vlastně takový MQTT na steroidech.  Ten velmi usnadňuje integraci zigbee do Loxone. Je to plugin psaný přímo pro potřeby Zigbee2Mqtt bráně, takže rozumí jeho příkazům a umí tak nabídnout spoustu užitečných věcí.

Jednak nabízí pohodlné volby zařízení. Takže namísto odchytávání konkrétní MQTT zprávy si jen v comboboxu vyberete jedno ze svých zařízení (plugin se umí dotazovat Zigbee2Mqtt, takže má přehled o tom, jaké zařízení máte v Zigbee2Mqtt nakonfigurované).

Druhým benefitem je pak automatická konverze přijatých dat do Json objektu a v případě podporovaných zařízení dokonce extrakce konkrétní hodnoty z Json objektu přímo do výstupního msg.payload.

K tomu umí u každého zařízení přímo v NodeREDu ukázat stav baterie, aktuální zpracování zprávy a pár dalších zajímavých stavů. Až potud super. Kdyby vše fungovalo :).

Bohužel, v mém případě se tenhle plugin ze začátku choval tak, že zpracoval každou druhou až třetí zprávu a zbytek ignoroval. Původně jsem podezříval Xiaomi kostku, ale když to samé začly dělat i nově koupené vypínače, bylo jasno.

Zkusil jsem tedy dát vedle sebe jak tenhle Zigbee2Mqtt prvek, tak klasický MQTT. A podezření se potvrdilo. Ve výpisu nahoře jde vidět, že v MQTT je 5x přijatá zpráva a až po šesté je přijata také Zibee2Mqtt komponentou. Zkoušel jsem googlit, psal jsem na github, ale nikde jsem nenašel důvod, proč to zlobí (krom jedné zmínky v githubu, že autor používá nějakou starší mqtt komponentu interně, ale to nevypadalo na zdroj problémů).

Nakonec mě napadlo, že problém bude možná ve verzi NodeRED. Jak jsem zjistil, tak ačkoli používám Docker a oficiální NodeRED image, neměl jsem poslední verzi. Což bylo dost zvláštní.

Bohužel, inženýři z NodeRED se rozhodli pro opravdu vypečený tah. Původně se Docker container s NodeRED jmenoval nodered/node-red-docker, což jim už asi přestalo znít cool, takže repositář nechali ve staré verzi a založili nový, kde jsou další updaty. Ten se nyní jmenuje nodered/node-red. Bezva ne?

Takže pokud někdo používáte Dockerovaný NodeRED, zkontrolujte si repositáře. Dost dobře se totiž může stát, že používáte už obsolete pre-stable verzi 0.20.8 namísto aktuální 1.1.3. Po updatu na aktuální verzi a kompletní rebuild všech kontejnerů a promazání všech cachí začal i Zigbee2Mqtt plugin fungovat jak má. Tím byl vyřešen problém Zigbee2Mqtt.

Zigbee hrátky – seriál na pokračování

Zigbee hrátky – seriál na pokračování

Comments 27 comments

Dnešní článek bude pravděpodobně první z více článků o zprovozňování Zigbee v našem domě. Konečně mám zase trošku času a hlavně mi po měsíci dorazil nový Zigbee stick CC2652, který zdá se být o dost lepší než jeho předchůdce.

Věřím, že se díky tomu konečně dostanu se Zigbee do stavu, kdy ho plnohodnotně zaintegruji do našeho domu. A o tom bude tato série článků.

Psal jsem o tom párkrát na fóru, že jsem objednal nový USB stick CC2652 na Zigbee. Vzal jsem ho z Tindie, kde jednak měl dorazit relativně rychle, a pak je už naflashovaný přímo na potřeby Zigbee2Mqtt.

Píšu měl, protože byl nějaký problém s německou poštou, která prodejci vrátila mraky zásilek poškozených a on musel vše testovat a posílat znovu. Díky tomu se vše protáhlo na měsíc a něco. Naštěstí jsem na to stejně neměl čas, ani pomyšlení, takže mě to zas tak netrápilo. Za normálních okolností má dorazit do týdne.

Výhod téhle CC2652 oproti původní CC2531, na kterou jsem psal recenzi a návod na flashování, je hned několik (původní návod a recenze zde). Zaprvé, není potřeba kupovat flashovací HW a složitě stick flashovat, protože prodejce má už vše připraveno. Zadruhé, je plně kompatabilní se Zigbee 3.0, zvládne až 100 zařízení, má externí anténu a celkově lepší dosah. A zatřetí, což pro mne bylo nejdůležitější, USB stick splňuje pravděpodobně vše, co takový USB stick má splňovat a je kompatabilní nejen s RaspPI, ale také s ESXI systémem pro virtualizaci serverů.

Všechny tyto výhody pro mě znamenají, že nebudu muset provozovat RaspPI, ale stick mi poběží virtualizovaný na serveru, kde provozuji i ostatní Docker instance na správu domu. To ovšem neznamená, že by neběžel v NAS či RaspPI. Tam samozřejmě funguje také.

Tento návod se proto bude zmiňovat i o ESXI, který by mohl být i pro někoho dalšího zajímavý. Pokud byste potřebovali návod na RaspPI, postupujte dle původního návodu, jen vynecháte flashovaní a začnete sekcí “Instalace na Raspberry”. Návod zde: https://www.vodnici.net/2018/12/vlastni-zigbee-brana-pomoci-raspbery-pi/.

Zároveň se od dob prvního návodu změnilo/rozšířilo pár komponent na Zigbee správu, takže i o těch budu postupně psát, k tomu přihodím pár Docker a Docker-compose konfigurací, které budu aktuálně pro Zigbee síť používat. A na závěr pak přijde samotná implementace do Loxone, kde to bude opět vyžadovat NodeRED a nějaký ideálně univerzálnější kód, který bude překládat Zigbee na Loxone. Uvidíme.

ESXI

Začneme u ESXI virtuálního stroje. ESXI samotný zde moc popisovat nebudu, ve zkratce jde o “trochu” robustnější VM Ware virtuální stroje běžící na vyhrazeném hardware. Pro potřeby testování jsem si udělal nový Docker VM, kde budou veškeré testy probíhat a kam pak postupně zmigruji i ostatní docker kontejnery s chytrou domácností.

Zigbee stick do virtuálního stroje přidáme jako klasický USB device, s tím že se v pořádku i pro ESXI hlásí jako “cc2652rb stick”:

Po přidání uložíme a nahodíme stroj. S původním USB stickem CC2531 toto nebylo možné. Stick ihned po zasunutí do serveru způsobil kompletní vytuhnutí celého ESXI OS a tím i všech virtuálních strojů. Takže fungoval spíš jako takovy USB killer :).

Zigbee stick

Další rozdíl oproti původnímu sticku je, že se hlásí jako /dev/ttyUSB0 a ne /dev/ttyACM0. Toto je dost zásadní změna, protože je potřeba ručně upravit konfiguraci v Zigbee2Mqtt data/configuration.yaml aby ho Z2M našel.

Docker

Pro základní testování sticku si přes docker-compose rozbíhám následující docker containery:

V případě MQTT používám defaultní kontajner, do NodeRED jsem si postupně přidal pár dalších knihoven a Zigbee2MQTT opět v defaultním nastavení, jen s vlastním konfigem.

DockerFile pro NodeRED mi aktuálně vypadá nějak takto. Přidávám komponenty pro dashboard a Zigbee2Mqtt podporu a pár dalších, které jsou potřebné pro M2T Admin rozhraní na lepší správu Zigbee sítě.

FROM nodered/node-red-docker

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

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

Samotný DockerCompose na provázání těchto tří kontejnerů pak může vypadat třeba takto:

  dum-mosquitto:
    build: mosquitto
    container_name: dum-mosquitto
    restart: always
    ports:
    - "1883:1883"
    - "9001:9001"
    network_mode: bridge
  
  dum-nodered:
    build: nodeRed
    container_name: dum-nodered
    restart: always
    ports:
      - "1880:1880"
      - "60000-61000:60000-61000/udp"
    network_mode: bridge
    links:
    - dum-mosquitto
    - dum-zigbee

  dum-zigbee:
    container_name: dum-zigbee
    image: koenkk/zigbee2mqtt
    volumes:
      - ./zigbee/data:/app/data
      - /run/udev:/run/udev:ro
    devices:
      - /dev/ttyUSB0:/dev/ttyACM0
    restart: always
    network_mode: bridge
    privileged: true
    links:
    - dum-mosquitto

Více Docker jako takový rozbírat nebudu, psal jsem o něm opět ve dřívějších článcích a zbytečně by to prodlužovalo tuhle sérii. Navíc článků na základy dockeru je na internetu všude spousta 🙂

Zprovoznění

Po dokonfigurování dockeru a ESXI přichází na řadu oživení celého systému. Tady musím říct, že až na zádrhel se správným názvem zařízení ttyUSB0 vs ttyACM0 fungovalo vše hned napoprvé.

Pro testování jsem použil už dříve nakoupené a zmiňované Xiaomi teploměry, kostku a žárovku a dále Zigbee OnOff Controller. Napárování proběhlo hned napoprvé a to i přesto, že všechny zařízení byly původně spárované s původním USB stickem.

Bohužel, jako jediné vstupní zařízení mám momentálně Xiaomi kostku a ta mi prostě zlobí. Problém není v signálu, ale v kostce samotné. Občas pohyb/změnu detekuje a občas ne. Musím proto sehnat nějaké Zigbee tlačítka, která budem po domě na různé dočasné funkce používat (nyní konkrétně tlačítko vedle kojícího křesla na rozsvícení/zhasnutí lampičky 🙂 ).

Pro NodeRED jsem našel nové administrační rozhraní sloužící k lepší správě Zigbee2MQTT sítě včetně možnosti vykresit pěkný graf zigbee sítě:

A taky nové prvky pro NodeRED na snazší bagrování dat z Zigbee2MQTT. Dříve bylo pořeba zpracovávat přímo MQTT parametry, nyní už existují připravené prvky, kdy si člověk může spoustu věcí vyklikat a lezou z toho jen konkrétní zigbee data:

O tomhle už ale zase příště, protože je toho spoustu, co to umí, a chtěl bych se tomu věnovat víc detailně.  Zároveň je to momentláně vše, co mám u sebe rozchozeno. Až seženu tlačítka (zkusím něco z CZ i z Ali, kde to bude na dýl), tak chci zkusit už reálné rozmístění po domě, vyzkoušet dosahy a hlavně udělat už nějaký dlouhodobý systém jak v NodeRED, tak v Loxone, jak Zigbee integrovat. A o tom všem v dalších článcích 🙂

PS: Pokud by měl někdo zájem o předchozí USB stick CC2531 (v RaspPI funguje bez problému) včetně Downloader Cable a CC DEbugger Zigbee emulatoru, tak ho rád prodám. Je plně funkční. Původní cena 26USD, nechám za 400kč vše, pošlu kdyžtak zásilkovnou.

PS2: Tak jsem objednal pár dalších zigbee zařízení na testování. Konkrétně: