Browsed by
Tag: loxone

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

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

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

Loxone, vždycky je to externí vliv

Loxone, vždycky je to externí vliv

Tak mám oficiální vyjádření k čoudícímu DMX RGBW extensionu. Ani jsem vlastně nečekal nic moc jiného, takže jen přikládám pro info. Z pohledu supportu není ani potřeba znát detaily, tam mají rovnou jasno, že je to externí vliv. Je jim jedno, že máte rozvaděč Loxone, od Loxone partnera a s Loxone komponenty, stejně za to může někdo či něco jiného.  Takže z jejich strany obecně moc pomoc nečekejte.

K samotnému incidentu ještě dodávám, že do rozvaděče nebylo před incidentem šáhnuto nejméně rok, spíš víc.  A pobavil mne komentář na závěr, že to máme řešit s pojišťovnou jako externí vliv. Úplně vidím, jak jim vysvětluji, že přes den, modré nebe, žádné výpadky elektřiny, začíná hořet extension a jak je to externí vliv.

Každopádně, pojistky za zdrojem už mám, později přidám i před extensiony. A holt je potřeba počítat s tím, že můžou (a zřejmě i budou) časem odcházet i další komponenty či třeba zdroj.

A zde již oficiální vyjádření:

Omlouvám se za opožděnou odpověď. Reklamaci jsem probral s kolegou a zde je vyjádření.

Bohužel nemůžeme reklamovat zařízení poškozené externími vlivy. Toto poškození (ochranná dioda na vstupu 24V) vzniká pouze v případě přepětí vyššího než 28V na vstupních svorkách, To může být způsobeno:
1) Rozdílem v potenciálech – v celé instalaci používající 24V a propojených pomocí Link sběrnice, Tree sběrnice, nebo jiným kabelovým řešením, je nutné mít propojené GND svorky. Pokud tomu tak není, může se při úrovni 24V na výstupu zdroje objevit na vstupu zařízení klidně i 40V.
2) Zásah do rozvaděče, či selhání ostatní elektroniky – nechtěné přivedení vyšší napěťové úrovně než 28V, např. spojení s 230V rozvodem.
3) Externí vliv – např. úder blesku do nechráněné instalace.

Určitě doporučujeme překontrolovat instalaci, jestli není možné že došlo k některému z těchto problémů. Také doporučujeme pro každý extension použít separátní pojistku hodnocenou podle odběru extensionu – u 24V dimmeru >2,1A.

Situaci bych doporučil řešit s pojišťovnou, jako poškození externími vlivy.

Editováno:

Tak přikládám ještě jednu odpověd, na základě mého emailu, že vše bylo instalováno Loxone partnerem, žádná bouře nebyla a i zdroj a komponenty jsou Loxone:

Partnerům poskytujeme školení a produkty. Bohužel není možné kontrolovat jejich fyzické instalace.
Při školení jištění pojistkami určitě doporučujeme dle mnou vypsaných pravidel. Úroveň jištění záleží na zvyklostech konkrétního partnera a na tom, v jakém rozsahu byl dohodnutý rozsah jištění v rozaděči.
V případě, že není možné uplatnit pojištění, doporučil bych problém řešit s daným partnerem, který instalaci provedl.
Takže, když to není externí vliv, může za to Loxone partner, který ale s nimi nemá nic společného. Oni jim přeci doporučují, aby to dělali kvalitně.
Pojistky, aby už Loxone nehořel

Pojistky, aby už Loxone nehořel

Tak jsem se dnes konečně dostal k instalace pojistek na 24V okruh v rozvaděči. Jak jsem psal v minulém článku, z ničeho nic se mi vznítil DMX RGBW extension. Konkrétně se začal tavit transil (SMCJ28A-LF), který slouží k zachycení přepětí. Proč se to celé stalo je otázkou, od přepětí na zdroji, přes vadný transil, viníkem by mohl být údajně i prach v rozvaděči, atd, atd. Celé jsme to dostatečně rozebrali v diskuzi pod minulým článkem, čímž ještě jednou děkuji všem za rady a informace.

Bohužel, ať už byl prvotní důvod jakýkoli, problém byl také v dalších věcech. Jednak, originální zdroj Loxone v případě takového dlouhodobého přepětí nevypne, což je problém, a druhak, Loxone integrátor, který mi rozvaděč dělal, jaksi “opomněl” nainstalovat 24V pojistky tak, jak se to má dělat. Takže v rozvaděči nebylo nic, co by problému mohlo zabránit. A když se sejdou tyto tři faktory (problém s extension, zdroj, co neodpojí a integrátor, co neudělá svou práci v pořádku), může se stát velké neštěstí. My naštěstí v tu dobu byli doma.

A tak jsem na základě doporučení ihned objednal první tři pojistková pouzdra a pojistky, abych hned za Loxone zdroj umístil ochranu. Objednávka z Čech, aby to tu bylo co nejrychleji. Pouzdra jsem bral tato, pojistky pak 5A. Později pak do rozvaděče přibudou další pojistky před každý 24V spotřebič tak, aby byl ochráněn každý z nich samostatně.

Celkové náklady na pojistky, když to přeženu, tak 50kč na pouzdru a pár korun na pojistku. Za to máte ochranu zařízení v hodnotě několika tisíc, občas i přes deset tisíc. Investice se vyplatí, bohužel, integrátor z toho zřejmě něměl provizi a tak neintegroval, nevím. Štve mne to, mrzí mne to. Věřil jsem, že ví, co dělá, měl certifikaci od Loxone, vypadal, že ví o čem mluví, projekty, co dělal, měly hlavu a patu, žádný matlal na první pohled. Bohužel, člověk nemá jistotu nikdy a je to z mého pohledu i selhání firmy Loxone. Autorizuje integrátory, které doporučuje lidem, a ti přitom nedělají/neumí ani základní věci.

No nic, pojďme se podívat na vyřešení problému, cca hodinka práce v rozvaděči. Začnu první WTF momentem, kdy ve mne hrklo, že jsem objednal špatná pouzdra. Při prvním pohledu na packy vzadu na pouzdru to vypadalo, že nejsou na DIN lištu. A i při prvním pokusu o usazení na DIN lištu to nevypadalo lépe. Naštěstí stačí trochu trpělivosti a tu správnou polohu i na DIN lištu jsem z toho nakonec vyrazil :). Pro ostřílené profesionály asi naprostá banalita, ale já už to fakt viděl černě 🙂

Propojení mezi zdrojem a pojistkami jsem udělal pomocí 2,5 CYA kabelu s dutinkami. Pojistky jsem dal hned vedle zdroje.

A tím se blížíme k druhému WTF momentu. Z nadšení, že už to bude hotovo, jsem dal pojistky přímo do pouzdra. Což se…. nedělá, protože pak nejde zavřít, žejo 🙂

No, tak jsem je šroubovákem vydloubal ven a tentokrát je už správně dal do pojistkového držáku na výklopných “dvířkách”. Bohužel, pojistky se do držáku dávají zprava, takže se to tam od toho zdroje nedělalo úplně optimálně. Ale jde to. Když tak to pak ještě předělám, až budu dělat ostatní pojistky.

Pak už následovalo jen oštítkování všech nových kabelů, abych se v tom při příští návštěvě rozvaděče zase vyznal 🙂

A hotovo. Tak snad jsem tím podchytil případné budoucí problémy, ať už byl na vině zdroj, nebo cokoli jiného. Až pak dorazí ostatní pouzdra (z Aliexpresu), tak se budu muset pustit do větší předrátovávací akce a udělat pojistky před každý extension/PLC v rozvaděči.

Jak hoří Loxone?

Jak hoří Loxone?

Odpověď zní dobře a sám od sebe. Naštěstí jsme zrovna dorazili domu, sedám k počítači a najednou výpadek. Slyším divné pískání z technické a po přiblížení pekelný smrad.

Foto s kouřem bohužel nemám, to sem měl jiné starosti. Nahoře na mřížce jde ale vidět černé okouření.

Otevírám rozvaděč a co nevidím, nepoužívaný RGBW DMX extension si tam vesele hoří. Smradu jak v hradu, kouře rovněž. Loxone zdroj svítí červeně a smutně píská.

Shazuju pojistky, odpojuju ještě stále čoudící extension a opět vše nahazuju. Chvilka napětí kdy doufám, že to neodpálilo i něco jiného. Vše naštěstí najíždí. Otázka zní. Jak je možné, že Supr-tupr průmyslovému Loxone sami začínají hořet komponenty, které navíc nejsou ani využívány? To už je trochu moc ne?

RGBW DMX nebyl za celou dobu využitý VŮBEC. Tenkrát jsem ho nechal dát do rozvaděče, že jednou barevné pásky budu dělat. Od té doby se na něj nesáhlo. Takže o nějakém přetížení a dalších kecech nemůže být ani řeč.

Takže je to prostě šmejd. Co začne hořet příště? Komponentu mám cca 4 roky, možná o fous víc. Takže záruka je pasé, ale rozhodně mi to nepřijde normální. Takže si zítra popovídám se zelenýma expertama.

Další důvod do dalšího domu nepoužít Loxone, ale raději KNX či jiné komponenty a zelenou maximálně na vizualizaci.

To nám ten 2021 pěkně začíná.

ZIGBEE – NodeRED a Loxone

ZIGBEE – NodeRED a Loxone

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é

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

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

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.

Jak ovládat MQTT z Loxone

Jak ovládat MQTT z Loxone

Dnešní článek je třetí z mé třídílné minisérie pro začátečníky o tom, jak propojit Loxone s externími systémy. Dnes to bude o komunikaci s MQTT. Předchozí dva se týkaly REST API a ModbusTCP. Všechny tři způsoby využití budu ukazovat na chytrých zásuvkách Netio, které tyto protokoly podporují.

V případě MQTT je to s Loxone trochu složitější. Bohužel Loxone nepodporuje MQTT napřímo (není to zřejmě v jejich ekonomickém zájmu), takže je potřeba si pomoci NodeRED aplikací. V té lze programovat dodatečnou logiku a pomocí například REST API komunikovat pak vůči Loxone.  V tomto článku se už nebudu zabývat základy NodeRED, jelikož jsem o nich psal návody ve starších článcích zde: Zigbee2MQTT a ve článku NodeRED – Propojení všeho se vším. Stejně tak nebudu extra vysvětlovat MQTT, připojení k němu či instalaci serveru, která je popsaná ve článku MQTT Message Broker a Propojení MQTT a Loxone.

 

Takto nějak vypadá cíl našeho dnešního snažení. Stejně jako v případě Modbusu a RESTu budeme implementovat zapnutí a vypnutí zásuvky, tentokrát pomocí MQTT (za pomocí NodeRED a REST API volání).

Podobně jako v případě ModbusTCP propojení začneme tím, že si vyzkoušíme fungování samotného MQTT protokolu a dostupnost cílového zařízení. V případě MQTT používám aplikaci MQTT Explorer, kde se můžete přípojit k Vašemu MQTT serveru a sledovat, jaké topicy jsou k dispozici a případně testovat odesílání topiců vlastních.

Abychom otestovali, že naše cílové zařízení (v tomto případě chytrá zásuvka) naslouchá MQTT zprávám, zkusíme odeslat zapínací příkaz. V tomto případě je to vystavení topicu netio/PowerCable-mqtt-8E/output/1/action s hodnotou 1. Konkrétní nastavení záleží vždy na cílovém zařízení a je potřeba postupovat dle dokumentace. Dokumentace k Netio MQTT zásuvkám je k dispozici zde.

Pokud nám zařízení po MQTT komunikuje, přejdeme do fáze dvě a tím je rozchození komunikace z NodeRED směrem k MQTT. Abychom opět nejprve otestovali základní funkčnost, uděláme si jednoduchý projekt, kde budeme mít dvě tlačítka, která nám budou posílat stav 1 a 0 směrem do MQTT.

Pro tyto účely vložíme prvek MQTT output, nastavíme mu cílový server a topic. Hodnota topicu se pak do MQTT Output node dostane z “Inject” prvku, do kterého nastavíme hodnoty 1 a 0. Dáme deploy na projektu a otestujeme, že po kliknutí na inject prvky se relé zapne či vypne.

Pokud opět funguje vše jak má, pokročíme dále. Testovací vstupy 1/0 si v projektu ponecháme a přídáme dva vstupní REST API pointy. Jednomu dáme adresu /netio/zasuvka/0 a druhému /netio/zasuvka/1. Tento vstup pak napojíme na template prvek, který bude posílat hodnotu 1 a 0 směrem do MQTT output prvku. Zároveň si HTTP vstup pošleme i na debug výstup a samotný HTTP požadavek ukončíme prázdnou odpovědí pomocí HTTP response.

Samozřejmě by to šlo celé udělat mnohem více elegantně, mít například jen jeden REST API vstup, akceptovat vstup ne přes GET, ale POST jako hodnotu 0/1, nebo dokonce třeba “device=1,state=0” a vstupní data rovnou parsovat a posílat směrem do MQTT output.  Cílem této ukázky je ale přehlednost a pokud bych do toho motal ještě parsovaní v Javascriptu, myslím, že by to přehlednosti úplně nepomohlo :).

Takto upravený projekt dáme opět uložit a vyzkoušíme. Pokud vše šlo podle plánu, můžeme nyní pomocí URL adresy vedoucí na náš NodeRed a přidáním “/netio/zasuvka/1” či “/netio/zasuvka/0”  zapínat a vypínat zařízení pověšené na MQTT.

A nyní už zbývá poslední krok, napojit Loxone na náš NodeRED API Restpoint. Tento postup je nyní už naprosto identický s tím, co bylo popisováno v prvním článku o komunikaci mezi Loxone a REST API. Proto to nyní vezmu trochu rychleji. Vytvoříme nový virtuální výstup, který nasměrujeme tentokrát směrem k NodeRED. V mém případě http://nodered.dum.

Do virtuálního výstupu přidáme “Příkaz virtuálního výstupu”, kterému dáme instrukci k zapnutí a vypnutí dle našeho nastavení v NodeRED. V mém případě “/netio/zasuvka/1” a “/netio/zasuvka/0”.

Takto připravený virtuální příkaz pak už jen opět vytáhneme do Loxone plánu a propojíme s tlačítkem. A tím máme cestu z Loxone k MQTT ukončenou.

Tentokrát byla bohužel cesta z Loxone do MQTT trochu složitější. Je to dáno tím, že Loxone úplně neuznává většinu nových formátu (MQTT, Zigbee,…) a razí si jen své proprietární technologie. Naštěstí tu ale máme možnost skrz RestAPI si z/do NodeRED dostat jakákoli data potřebujeme, takže přesto lze MQTT použít.

Jak ovládat Modbus TCP/IP z Loxone

Jak ovládat Modbus TCP/IP z Loxone

Dnešní článek je druhý ze série tří článků pro začátečníky o tom, jak propojit Loxone s externími systémy. Dnešní článek bude o komunikaci Modbus TCP/IP. Předchozí díl byl o REST API a příště bude ještě MQTT. Všechny tři způsoby využití budu ukazovat na chytrých zásuvkách Netio, které tyto protokoly podporují.

Modbus TCP/IP protokol je variace Modbus protokolu, který ke komunikaci používá klasický ethernet (TCP protokol) namísto klasického Modbusu RTU využívajícího RS485 nebo RS232. Z toho vyplývá, že ho pomocí Loxone lze ovládat bez nutnosti dokupovat Modbus extension.

 

Předtím, než se pustíme do samotného Loxone, začneme freeware aplikaci Modbus Master, kde si lze celou komunikaci vyzkoušet nanečisto, než přistoupíme k samotnému ovládání skrz Loxone.

Abychom mohli se zařízením skrz Modbus komunikovat, musíme znát adresy, na kterých zařízení čeká instrukce, případně, na kterých odesílá stavová data. Pro Netio chytré zásuvky je Modbus TCP/IP popsán v této dokumentaci.  Detailní návod, jak Modbus Master nastavit můžete najít také na stránkách Netia.

Pro sepnutí zásuvky číslo jedna potřebujeme tedy zapsat hodnotu 1 na adresu 101 do sekce 0x05 – Write Single Coil, pro vypnutí pak nastavíme hodnotu do stejné adresy.

Poté, co vyzkoušíme, že nám funguje komunikace mezi ModbusMasterem a samotným zařízením, je čas přejít do Loxon Configu. Toto otestování doporučují vždy před samotným nastavením do Loxone, protože se snadněji a rychleji dá vyzkoušet, že umíme správně se zařízením komunikovat.

Takto nějak vypadá cíl našeho dnešního snažení. Do sekce Netio tentokrát přibude tlačítko na zapnutí či vypnutí zásuvky skrz Modbus TCP/IP.

Začneme tím, že v Loxone Configu klikneme na sekci “Komunikace Miniserveru” a nahoře v menu klikneme na ikonku “Modbusserver”. Tím vytvoříme nový modbus server, který si pojmenujeme “Netio Modbus” a jako adresu mu nastavíme jeho IP adresu následovanou dvojtečkou a číslem portu (defaultně 502).

 

Do takto definovaného Modbus serveru nyní přidáme “Modbus zařízení”. A to kliknutím na ikonu “Senzory a aktory” a vybráním “Modbus zařízení”. Zařízení pojmenujeme třeba “NetioZásuvka”.

Do třetice pak do vloženého Modbus zařízení vložíme “Digitální aktor”. Digitální znamená, že nabývá hodnot jen 0 nebo jedna, zatímco analogový by nám dovolil nastavit libovolnou hodnotu do cílového zařízení.

Ve stromu vpravo (bod 1) vidíte, jak by mělo nakonfigurované Modbus zařízení vypadat. Máme NetioModbus server, do kterého je vložena NetioZasuvka zařízení, které má digitální aktor OnOff. Název tohoto aktoru můžeme nastavit opět libovolný a poté do IO adresy zadáme adresu, kterou jsme si dříve vyzkoušeli v aplikaci ModbusMaster a do Příkazu pak zadáme 0x05 – Write single coil.

Tím bychom měli mít Modbus komunikaci nastavenou a zbývá jen daný aktor vytáhnout do Loxon plánu, propojit s tlačítkem, uložit projekt do Loxone Miniserveru a vše vyzkoušet.

 

Jak vidíte, ani na ovládání přes Modbus TCP/IP není nic komplikovaného. Je vždy lepší si komunikaci vyzkoušet předem pomocí ModbusMasteru (nebo jiného SW klienta pro modbus) a až pak začít nastavovat do Loxone. Přeci jen má Loxone svá specifika a je dobré vědět, že zařízení i cílové porty fungují, jak očekáváme, a případný problém je tedy v nastavení v Loxone configu, než hledat naslepo zkoušet, proč to nejede a zda je problém v Loxone nebo ve špatné adrese 🙂