Browsed by
Tag: docker

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

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.