Browsed by
Tag: nodered

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.

Jak ovládat MQTT z Loxone

Jak ovládat MQTT z Loxone

Comments 14 comments

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.

Pushover aneb dokonalé notifikace

Pushover aneb dokonalé notifikace

Comments 20 comments

Dnešní článek bude o notifikacích. O takových, které můžete použít z jakéhokoli systému domácí automatizace, ale také z jakýchkoli svých hobby projektů, ze serveru, z emailu, prostě odkudkoli.

Aplikace se jmenuje Pushover. Pokud nevíte, proč je tu teď zrovna tento obrázek, nevadí. Ti co vědí, věřím, že ho ocení :). Každopádně, aplikace, o které dnes bude řeč vypadá takto:

Klientská část aplikace, tzn. to, co Vám zobrazuje notifikace, je dostupná pro Android i iOs a dále pak pro desktop jako browser extension pro Chrome, Firefox i Safari.

Posílat notifikace pak můžete buď skrz REST API, nebo zasláním emailu na speciální emailovou adresu, nebo pomocí jednoho z mraky pluginů, které pushover nabízí (například IFTTT, Zapier, Domoticz, Home Assistant a další).

Co se týká poplatků za používání a zasílání notifikací, myslím, že to mají nastaveno hodně rozumně. Neplatí se žádné měsíční poplatky (což fakt nesnáším), ale platí se jednorázový poplatek za každé zařízení, kde chcete notifikace dostávat.

Poplatek je přátelských $5USD za zařízení a platí pro neomezený počet příchozích zpráv od neomezeného počtu aplikací. Na vyzkoušení máte 7 dnů zdarma na každém zařízení.

To “Aplikací” je zde důležité. Při zasílání zpráv totiž můžete v administraci vytvořit několik různých typů aplikací, které mají svou ikonku, složku a nastavení a z ní pak posílat. Díky tomu si můžete notifikace v aplikaci pěkně kategorizovat.

Co se týká počtu odeslaných zpráv, tak každá aplikace může odeslat měsíčně 7500 zpráv zdarma. Pokud je potřeba více, je pak potřeba přejít z osobního účtu na “Team” účet a nabít si kredit. Pro vlastní potřeby jsou ale limity zdarma naprosto dostačující.

Teď už k samotné aplikaci a jak ji použít. Začněte registrací zde https://pushover.net/login, kde pak získáte přístup jak pro klientskou část (tzn. příjem notifikací), tak pro server-aplikaci k odesílání notifikací.

Na vyzkoušení funkčnosti je dobré začít emailem. Přidáme proto testovací emailový alias “Test email”, pro který dostaneme novou testovací emailovou schránku. V mém případě je to [email protected]  (nechávám ji zatím zapnutou, můžete mi psát vzkazy 🙂 ).

Pokud nyní zašlete jakýkoli email na tuto adresu, dorazí Vám to jako notifikace na všechny zaregistrované zařízení (připadně ta zařízení, které si v nastavení emailu zvolíte).

A na mobil či desktop Vám přijde zpráva takto:

Pomocí emailového propojení můžete zprovoznit notifikace v zařízeních, kde není možné REST API volání, případně si notifikovat emaily z Vaší emailové schránky. To hlavní je ale právě REST API.

Začněte tím, že si vytvoříte “Application token”. Ten se pak používá při odesílání zpráv skrz API. Zároveň, každá takto vytvořená aplikace má stránku se statistikama, kde vidíte, kolik jste toho poslali.

V mém případě jsem dostal API token ajz8xt2fmbsnpigyyjw67xeoxuhjbx, který budu používat v dalších ukázkách. Opět, token nechávám zatím zapnutý, takže mi můžete posílat zprávy. Když toho bude moc, tak ho pak zakážu :).

curl 
   --form-string "token=ajz8xt2fmbsnpigyyjw67xeoxuhjbx" 
   --form-string "user=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" 
   --form-string "title=Test from curl" 
   --form-string "message=Its working" 
   https://api.pushover.net/1/messages.json

Poznámka: V závislosti na Vašem OS musí být buď celý na jenom řádku, nebo musí být nové řádky adekvátně esacapovány pomocí ^ či \.

Toto je curl příkaz, kterým pošlete notifikaci z příkazové řádky. Na zaslání používám aplikaci “curl“, která slouží k zasílání (nejen) webových požadavků, případně pak PostMan.

V samotném dotazu pak položka “token” je Vaše zaregistrovaná aplikace, položka “user” pak uživatelský klíč (User key) z hlavní obrazovky Vašeho pushover účtu. Title a message jsou nadpis a tělo samotné zprávy.

Kromě těchto základních položek je možné do notifikace předat pár dalších nastavení. Všechny jsou popsány v této dokumentaci. Můžete ke zprávě přiložit obrázek, můžete nastavit, na které konkrétní zařízení má zpráva jít. Dále pak můžete zprávě nastavit nějaký jiný zvuk či její prioritu (ty určují, jak budou zprávy na mobilu zobrazeny a zda se v době klidu má zahrát zvuk).

curl 
   --form-string "token=ajz8xt2fmbsnpigyyjw67xeoxuhjbx" 
   --form-string "user=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" 
   --form-string "title=Test from curl" 
   --form-string "message=Its working" 
   --form-string "priority=1" 
   --form-string "sound=magic"
   https://api.pushover.net/1/messages.json

Takto třeba vypadá příkaz na zaslání prioritní zprávy s konkrétním zvukem. Na desktopu se pak zpráva ukáže takto:

Nyní se pojďme podívat, jak tyto notifikace poslat z aplikací, které umí provést REST API volání. Tzn. například Loxone nebo NodeRED.

Výše uvedený formát curlu je nám totiž zatím k ničemu, protože takto to do Loxone nedostaneme. Naštěstí umí Pushover i XML, JSON formát nebo “UrlEncoded” formát, o kterém se ale na první pohled v dokumentaci nedočtete.

Pojdmě si tyto formáty ukázat tentokrát v Postmanu. Jako první tento “UrlEncoded” formát. Použijeme “RAW” styl odeslání, abychom si museli sami vyplnit i HTTP hlavičky a tím si ověřili, že umíme vše vyplnit správně kvůli Loxone.

Do “Headers” je nutné vyplnit správně “Content-Type”. Toto zmiňuji proto, že Pushover tuto hlavičku striktně kontroluje a pokud hlavička nesedí s obsahem zprávy, tak zprávu ignoruje. Na tomto jsem se minule zasekl na několik hodin. Problém Loxonu totiž je, že i když ve virtuální výstupu posíláte XML či JSON, on to posílá jako “application/text” a Pushover to pak ignoruje.

Ačkoli formát “x-www-form-urlencoded” umožňuje zadat dotaz v relativně krátkém řetězci, není z mého pohledu ideální. Problém totiž je, že musíte ručně nahradit všechny speciální znaky jejich “encoded” variantama. Tzn. místo mezery musíte psát %20 a podobně.

Proto, na poslání dat z Loxonu se více hodí JSON formát, kde se o tyto věci nemusíte starat, ale zase je trochu delší samotný text k odeslání.

Namísto:

token=ajz8xt2fmbsnpigyyjw67xeoxuhjbx&user=xxxxxxxxxxxxx&message=HelloWorld

budeme posílat tento JSON.

{"message":"HelloWorld","token":"ajz8xt2fmbsnpigyyjw67xeoxuhjbx","user":"xxxxxxxxxxxxx"}

A spolu s tím musíme poslat i správnou hlavičku “Content-Type: application/json”

V Postmanu to pak bude vypadat takto

Tímto máme vytvořený a vyzkoušený požadavek na notifikaci. Toto opravdu vřele doporučuju všem, než se pustíte do samotného zadávání do Loxone. Protože jedna věc je rozchodit to v Postmanu, ale druhá věc pak rozchodit to v Loxone.

Pushover v Loxone

I když Vám to v Postmanu bude chodit, stále nemáte vyhráno. Spoustu věcí v Loxone nefunguje a hlavně, nemáte žádnou chybovou odezvu. Prostě se nic nestane.

Pojdmě na to. V Loxone vytvořte “virtuální výstup”, pojmenujte si ho třeba “Pushover Vystup”.

Hned tady číhá velké nebezpečí! Do virtuálního výstupu musíte zadat jeho adresu. POZOR, adresa nesmí obsahovat koncové lomítko, nebo celou URL adresu. Smí obsahovat pouze protokol + název serveru.

Tzn. správně je “http://api.pushover.net“, ale nikoli “http://api.pushover.net/” nebo “http://api.pushover.net/1/messages.json”. Právě jsem Vám ušetřil dvě hodiny trápení. Zamálo :).

Další krok je pak konfigurace samotného příkazu. Ukážeme si, jak odeslat data v obou formátech (url-encoded a json).

Tady těch nebezpečí číhá hned asi tak milión, tak pojdmě na to.

Nebezpečí číslo jedna. Instrukce při zapnutí MUSÍ začínat lomítkem. Pokud si myslíte, že Loxone umí toto lomítko doplnit (nebo použít v případě, že ho dáte do adresy v minulém kroku), jste na omylu. Tzn., instrukce musí být ve formátu “/1/messages.json“, nikoli “1/messages.json” či  “http://api.pushover.net/1/messages.json”. Další dvě hodiny trápení. You’re welcome!

Další lahůdka je “HTTP rozšíření při zapnutí”. Už jsem to psal minule, pod tímto názvem se skrývá odeslání HTTP hlaviček. Jak jsem psal, Loxone neumí rozeznat ani základní odesílané typy a proto je nutné Content-type odeslat ručně, jinak se s Vámi Pushover bavit nebude.

Tzn., do HTTP rozšíření při zapnutí vyplňtě “Content-Type: application/x-www-form-urlencoded“.

Dejte si pozor na to, že opravdu zkopírujete přesně jak to zde píšu. Pokud totiž zadáte “Content-Type:application/x-www-form-urlencoded” – tzn. bez mezery, jste opět v háji. Loxone totiž takto zadaný Content-Type ignoruje. Další dvě hodiny trápení ušetřeny.

Samotný HTTP Post příkaz pro zapnutí už naštěstí v případě Loxone další překvapení neskrývá. Zde už zadáte řetězec tak, jak jste si ho vyzkoušeli v Postmanu. Tzn. “token=ajz8xt2fmbsnpigyyjw67xeoxuhjbx&user=xxxxxxxxxxxxxxxxxxxxx&message=HelloWorld”

A do HTTP při zapnutí pak dejte POST.

Tím je hotovo. Pro JSON pak postupujte podobně:

Instrukce: /1/messages.json
Rozšíření: Content-Type: application/json
Příkaz: {"message":"helloworld","token":"adpddeny9puzybmr1de6vn11yyfc2w","user":"xxxxxxxxxxxxxxxxxx"}
HTTP při zapnutí/vypnutí: POST

Tím máte nakonfigurovaný virtuální výstup na zaslání zprávy při zapnutí/vypnutí. Bohužel, budete pravděpodobně potřebovat spoustu virtuální výstupů pro každý řetězec, který chcete z Loxone notifikovat. Není zde totiž příliš mnoho možností, jak takový JSON předpřipravit z dostupných parametrů a ten pak až odeslat.

Částečně se to dá suplovat pomocí prvku Stav, který umožnuje 4 vstupy a z nich vytvořit jeden textový výstup. Pomocí binárního multiplexoru/demultiplexoru jste schopni ze 4 vstupů udělat 16. Bohužel, v podání Loxone sice máme “Binární kódování”, ale už tak nějak neexistuje “Binární dekódování”.

Pushover v NodeRED

V NodeRED je situace s Pusoverem o dost jednodušší a vlastně to bude popis jen na pár řádků. Detekce Content-Type funguje automaticky, stejně tak se snadno zadává i URL dotazu.

Tady je request pro vložení do NodeRED, stačí jen vložit Váš user-key a token do vstupního JSON:

[{"id":"15258bfd.f63314","type":"inject","z":"2d78ae47.c1a9a2","name":"make request","topic":"","payload":"{\"message\":\"HelloWorld\",\"token\":\"ajz8xt2fmbsnpigyyjw67xeoxuhjbx\",\"user\":\"xxxxxxx\"}","payloadType":"json","repeat":"","crontab":"","once":false,"onceDelay":"","x":510,"y":580,"wires":[["e690ef61.8b0f9"]]},{"id":"e690ef61.8b0f9","type":"http request","z":"2d78ae47.c1a9a2","name":"","method":"POST","ret":"txt","paytoqs":false,"url":"http://api.pushover.net/1/messages.json","tls":"","proxy":"","x":710,"y":580,"wires":[["5b512352.6d2b2c"]]},{"id":"5b512352.6d2b2c","type":"debug","z":"2d78ae47.c1a9a2","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":930,"y":580,"wires":[]}]

JSON požadavek pro Pushover vložíme rovnou ze vstupního node jako Payload.JSON:

kde můžeme pěkně JSON rovnou i editovat:

Prostřední node – http request – pak nastavíme tak, aby se dotazoval na cílovou URL adresu Pushoveru (komplet adresa, server + URI):

A třetí node je pak už jen debug výstup, abychom viděli, co nám Pushover vrací jako odpověď.

A to je vše. Máme notifikace zprovozněné i z NodeRED a bolelo to o dost méně než v případě Loxone :).

A to je pro dnes vše. Věřím, že pro Notifikace najdete spoustu využití. Nemusí to být jen o notifikacích z domu samotného. Lze to použít i například pro notifikace z Arduin, které v domě a kolem něj dělají hromadu jiné práce, nebo třeba pro pracovní a hobby projekty, když se někde na serveru něco děje.

Navíc, díky možnosti vytvářet neomezené množství “aplikací” je snadné mít v notifikacích pořádek a využívat je i zpětně pro logování stavu domu.

Pokud si nastavíte, že notifikace nemá pípat (a tuším, že jde nastavit, že se ani na mobilu přímo neukáže v notifikacích), lze to použít i na logování třeba spínání kotle či topení rekuperace a pak se jen zpetně podívat, kdy se to dělo.

Propojení dat z MQTT do Loxone pomocí HTTP vstupů

Propojení dat z MQTT do Loxone pomocí HTTP vstupů

Comments 6 comments

Jak jsem psal v minulém článku, kde jsem bojoval s BigClownem, poslední fáze propojení (a vlastně i ta nejdůležitejší), je dostat data ze senzorů, která je posílají přes MQTT protokol do Loxone.

Není to nic složitého, ale napoprvé může člověk v několika místech narazit. V rámci článku budu předpokládat, že už máte nainstalovaný a rozchozený nějaký MQTT server (například Mosquitto) a že už Vám běhá NodeRED (třeba v NASu, RaspPI,…). Pokud ještě nemáte, mrkněte na moje články o NodeRED a Mosquitto, kde je instalace a použití popsáno.

Jako zdroj dat budu používat data z BigClown senzorů. Stejně tak jdou ale data simulovat napřímo pomocí příkazové řádku a příkazu mosquitto_pub. 

mosquitto_pub.exe -h dockerserver.dum -t node/kit-co2-monitor:0/co2-meter/1:0/concentration -m 10000

Takže například tímto příkazem simulujeme čidlo CO2 monitoru na zařízení s IDčkem 0 a posíláme data “concentration” s hodnotou 10000ppm (takže vlastně smrtící dávka :)) ).

A teď už k samotnému NodeRED. Abychom mohli data z MQTT přijmout a zpracovat, vložíme prvek Input – mqtt.

 

Po rozkliknutí prvku mqtt můžeme zadat několik vlastností. Name slouží jen k pojmenování v rámci diagramu, QoS je priorita služeb, která nás nezajímá. A pak Topic. Jako topic zadáme buď absolutní název topicu, nebo nějakou jeho masku. Maska funguje tak, že namísto jedné úrovně zadáme znak +, nebo místo více úrovní znak #. Takže pokud chceme chytat všechny zprávy, týkající se senzoru nula, může maska vypadat takto:

Pokud máme dvě zařízení, můžeme buď masku ještě více zobecnit, nebo přidat dva MQTT inputy a každému přiřadit jinou masku topicu. Já šel druhou cestou, jelikož se mi to více hodilo při ladění a testování.

Tím bychom měli data v NodeRED. Nyní musíme vyřešit, jak data předat do Loxonu. Jsou vlastně dvě cesty. Jedna je data do Loxonu nastavit, druhá pak nechat Loxone, aby si o data řekl. Dneska popíšu cesta, aby si o data Loxone řekl. Z tohoto důvodu si musíme data někam v NodeRED uložit a pak na základě Loxone dotazu mu hodnoty sdělit.

Přidáme další dva prvky do našeho projektu. Tím prvním je prvek Debug. Ten slouží k tomu, že cokoli se do něj pošle, to on ukáže v debug okně. Ideální na ladění a ověření, že data z MQTT přicházejí. Náš testovací příkaz z mosquitto_pub se v NodeRED debugu zobrazí takto:

 

Druhý prvek je Function. Díky ní můžeme v NodeRED psát vlastní JavaScriptové funkce a pracovat s datama. V mém případě jsem si ji pojmenoval DataBuffer a to proto, že ukládá do bufferu všechny hodnoty z MQTT pro pozdější využití.

var dataObjectName;
if ( msg.topic.indexOf("kit-co2-monitor:0") != -1)
  dataObjectName = "BCG-data0";
else
  dataObjectName = "BCG-data1";

var dataObject = flow.get(dataObjectName);
if ( typeof(dataObject) == "undefined" )  
  dataObject = {};

var currentdate = new Date(); 
dataObject.lastModification = "" + currentdate.getFullYear() + (currentdate.getMonth() + 1) + currentdate.getDate() + currentdate.getHours() + currentdate.getMinutes();

if ( msg.topic.indexOf("humidity") != -1)
    dataObject.humidity = msg.payload;

if ( msg.topic.indexOf("temperature") != -1)
    dataObject.temperature = msg.payload;
    
if ( msg.topic.indexOf("pressure") != -1)
    dataObject.pressure = msg.payload;
    
if ( msg.topic.indexOf("altitude") != -1)
    dataObject.altitude = msg.payload;

if ( msg.topic.indexOf("concentration") != -1)
    dataObject.concentration = msg.payload;

if ( msg.topic.indexOf("voltage") != -1)
    dataObject.voltage = msg.payload;

flow.set(dataObjectName, dataObject);

msg = null;
return msg;

Program funguje tak, že nejprve zjistí, ze kterého čidla data přišla. To udělá tak, že v názvu Topicu vyhledá text “kit-co2-monitor:0”. Když tam text je, je to monitor0, když ne, je to monitor1. Název topicu je uložen v msg.topic.

Jako druhý krok pak vezme (a nebo vytvoří, pokud ještě neexistuje) objekt z flow contextu (jedná se o objekt sdílený v rámci jednoho projektu/záložky, nikoli celého NodeRED), do kterého hodnoty uložíme. Tím, že se jedná o flow objekt, budou data dostupná i v jiném prvku “Function”. Rozdíl mezi contextem, flow contextem a global contextem vysvětlen zde.

Následně pak už jen zjistíme, jaký typ hodnoty nám vlastně přišel a uložíme si ji do odpovídající proměnné v našem datovém objektu. K tomu si ještě uložíme informaci o tom, kdy jsme obdrželi poslední změnu hodnot z daného čidla. A to proto, abychom mohli monitorovat, kdy naposledy čidlo komunikovalo.

A tady je drobná obtíž s Loxonem. Bohužel, HTTP Inputs v Loxonu neumí textové hodnoty (debilní co), takže je potřeba to poslat jako číslo. Proto si poskládám číslo ala 201718121822, což znamena 2017-18-12 18:22.

Takže hodnoty máme uložené a nyní musíme naučit NodeRED, aby byl schopný hodnoty servírovat dál. Na to má naprosto super prvek Input – http. Pomocí něj si nadefinujete, na jakých URL adresách má nodeRED poslouchat a jaká data vracet. Takže například chceme, aby na adrese http://nodered.dum/bigclown/kit0 se vracely hodnoty z prvního čidla, na adrese http://nodered.dum/bigclown/kit1 pak z druhého čidla.

Jednoduché, že? Tímto jsme ho právě naučili poslouchat na zvolené adrese. Teď mu ještě nějak musíme předat data. Proto přidáme opět prvek Function a spojíme ho s obouma vstupama a zároveň výstup funkce spojíme s prvkem Output – http response. Ten je k tomu, aby se pro daný http požadavek vrátila nějaká data.

Jednoduché, elegantní :). Zbývá už jen napsat funkci DataGetter, která vezme uložená data z flow contextu a vrátí je na výstup:


var dataName;
if ( msg.req.originalUrl == "/bigclown/kit0" )
    dataName = "BCG-data0";
else
    dataName = "BCG-data1";

var dataObject = flow.get(dataName);

msg.payload = 
    "lastUpdate=" + dataObject.lastModification  +
    " humidity=" + dataObject.humidity +
    " temperature=" + dataObject.temperature +
    " pressure=" + dataObject.pressure +
    " altitude=" + dataObject.altitude +
    " concentration=" + dataObject.concentration +
    " voltage=" + dataObject.voltage;
    
return msg;

Ta funguje tak, že z originalUrl zjistíme, jaká data máme vrátit (jeslti čidlo 0 nebo 1). Data pak získáme pomoci flow.get() a sestavíme z nich textový řetězec v podobě name=value name1=value1….., který pak následně vrátíme jako msg.payload. V objekt msg pak data jdou do http-response, a zobrazí se jako http odpověď. Takže když pak zavoláme adresu http://nodered.dum/bigclown/kit0, jako odpověď získáme toto:

A tím jsme s NodeRED skončili. Data máme z MQTT načtena a umíme je vystavit dál. Zbývá už jen naučit Loxone si o data říct. Do projektu v Loxone Configu přidáme dva HTTP Virtuální vstupy,

které si pojmenujeme třeba BigClown kit 0 a BigClown kit 1.

A každému příkazu zadáme dotazovací url. V mém případě již zmiňovaný http://nodered.dum/bigclown/kit0 a http://nodered.dum/bigclown/kit1

Do těchto virtuálních vstupů pak přidáme jednotlivé HTTP příkazy. Pro každou načítanou hodnotu jeden příkaz:

A každému příkazu řekneme, jak má hodnotu z textového řetězce vyparsovat, jak se má hodnota vypisovat, na kolik má být desetinných míst, jednotku, …

Takto například vypadá CO2 čidlo. Má rovnou zapnutou i statistiku, která se zaznamenává jednou za 10minut jakožto průměr hodnot. Parsování se provádí pomocí příkazu “concentration=\v”, je na jedno desetinné místo s jednotkou ppm (pomocí <v.1> ppm).

A to je vše. Tím máme hodnoty v Loxone :). Pro zajímavost, hodnoty Tepota/vlhkost jsou hodnoty z čidel od Sedtronicu, zatímco hodnoty z BigClowna jsou ty s označením “kit0”. Teplota i vlhkost se trošku liší, jelikož čidla Sedtronic jsou pod vypínačem ve zdi, zatímco čidlo BigClownu je vedle postele na stolku. Jde na tom občas hezky vidět, jak se rychleji zahřeje vzduch, než cihla :).

A to je pro teď vše. Příště zkusím dát dohromady ještě návod za pomoci virtuální vstupů. To zatím ještě nemám, protože mne to napadlo až teď při psaní článku :). Myslím, že by to také mělo také jít. Jen je otázka, jeslti nad tím půjdou i statistiky a další věci.

Darovanému BigClownu na zuby…. ?

Darovanému BigClownu na zuby…. ?

Comments 4 comments

Darovanému koni prý na zuby nekoukej. Nevím, jak je to ale s koňem vyhraným a s doplatkem. Snad se o takových koních nějaká ta kritika dá napsat.

Začnu popořadě. Vyhrál jsem 5000kč kreditu na BigClown IoT věci. Měl jsem radost.

Když jsem si pak začal procházet BigClown eshop, trochu mne radost přešla. Zvyklý na ceny Wemosu, Arduina a dalšího HW z AliExpressu se mi ceny na eshopu BigClownu zdály… jak to říct. Přemrštěné.

Jasně, dělají to kluci všechno v CZ (prý), dělají to s láskou, mají k tomu spoustu SW, dokumentaci, podporu. Navíc, s kýmkoli jsem u nich mluvil, byl vždy milý, ochotný, nápomocný. Takže stále převažoval pozitivní pocit.

A tak jsem začal zjišťovat, jak bych kredit využil. Zrovna jsem řešil CO2 dekektory do ložnice a k prckovi. Koukám, že CO2 detektor mají. Tak si říkám, koupím CO2 + core modul, pošlu to přes wifi, víc nepotřebuju.

Bohužel, chyba. Big clown nepodporuje wifi, ale mají vlastní síť postavenou na 868/915Mhz síti. Což je fajn. Jenže, potřebujete Core modul s rádiem (725kč) a k tomu USB dongle za 600kč, který pak ale někde ještě musí běžet.

To znamená další zařízení, o které se budu muset starat. Řešení jsou buď nějaké Raspbery PI, Docker instance v NASu a nebo Turris Omnia. Říkám si ok, tak i toto má řešení, pojdmě do toho.

Zkonzultoval jsem s člověkem z BigClowna můj nápad a on mi dal dohromady nákupní seznam věcí, co potřebuju k realizaci. Trochu se to rozrostlo. Ale ok. Zároveň ale musím vyzdvihnout ochotu BigClown lidí, ta je prostě super. Jde vidět, že mají rádi to, co dělají.

A poslal mi seznam (ceny jsou o něco vyšší než mají teď na eshopu, protože zlevňovali):

USB Dongle 890 Kč
Core Module 790 Kč
Battery Module 390 Kč
Power Module 490 Kč
CO2 Module 2.490 Kč
Humidity Tag 249 Kč

Komponenty jsem chtěl na 2 stanice, takže celková cena se vyšplhala na 8728kč, ale dostal jsem slevu, takže nakonec jen 7000kč. Uff. Ale dobrá, je to doplatek jen 2000kč nad to, co jsem vyhrál, dám jim vydělat a aspoň si to vyzkouším.

chrome_2017-12-17_12-42-57

Tady trochu přeskočím v čase a dodám, že záhy následovala druhá objednávka, kde jsem ještě doobjednal tyto komponenty:

2x Temperature Tag 125kč
2x Barometer Tag 225kč
2x Cover module 100kč

Takže dalších 900kč. Důvodem bylo, že jsem chtěl dát dohromady přesně stejný CO2 senzor, jako je ten referenční. Důvod objasním později, každopádně cena jednoho CO2 modulu se vyšplhala na cca 4000kč.

2017-12-06-17

Pořád jsem ale věřil tomu, že když už to stojí takové peníze, jen to dám dohromady, rozchodím a bude to. Jenže, tak jednoduché to nebylo.

První, co na BigClownu člověk uvidí a ocení je jednoduchost, s jakou se vše složí. Jenže, vlastně toho moc jiného zas udělat nejde. Existuje několik modulů, ty se do sebe zacvaknou a tím člověk s HW skončil.

2017-12-06-17

Na to, že se BigClown platforma prezentuje jako punková, jako geekovská, tak jde spíš o BFU věc. Za 4000kč si koupíte skládačku, co dáte za 5minut dohromady, pak ji strčíte do krabičky a tváříte se, jaký jste IoT mág.

chrome_2017-12-17_12-54-37

Samozřejmě, jde to rozšířit. Má to piny, má to vstupy, má to výstupy. Jenže, to má arduino za pár $$ taky. Z tohohle pohledu jsem úplně nepochopil cílovku. Pokud jsem nováček, radši spálím při pokusech deset Wemosů D1 a stále si jich budu moct 200 koupit, než si koupit jeden kit BigClowna a bát se, co mu udělám.

chrome_2017-12-17_12-55-34

Na prototypování je to fajn, ale zase. Existují na to lepší zařízení, například nějaké Arduino Mega za pár peněz. Ale nic, neklesal jsem na mysli a tešil se na vymazlené IDE, odkud budu věci uploadovat do Core modulu. Těšil jsem se, jak to mají vymazlené, jak se zase naučím něco nového a jak z toho pak něco použiju třeba i na Wemos…..

A zase zklamání. Když jsem začal zjišťovat, jak to je s BigClown ekosystémem, narazil jsem hned na dva zádrhele. Tím prvním je ještě nehotová dokumentace, kde je všude TODO. Ano, lidé od nich na tom pracují, a opět při dotazu přes mail jsou hodně ochotní. Ale. Za 8000kč HW a dokumentace má spoustu TODO sekcí (stav ke dni 17.12.2017).

Ať jsem dělal co jsem dělal, nenašel jsem nic v dokumentaci žádný článek o nějakém IDE. Podezřelé. Ale nic, třeba se to vyjasní časem, budeme číst od začátku a postupovat postupně.

Pro BigClowna potřebujete dva balíky. Toolchain Setup a Playground Setup. První jsou různé drivery, to druhé pak prostředí, pomocí kterého si můžete BigClowna otestovat. Hurá, tešil jsem se.

Instalace Toolchainu proběhla ok. Zkusme tedy Playground, ať už vidím nějaké kód, něco vyzkouším. Aha. Nevyzkouším.

Instalátor Playgroundu je zabugovaný. Nefunguje. Navíc, pokud na Vašem počítači používáte vlastní instalaci Pythonu nebo Node.JS, oboje Vám bude nejprve odinstalováno a pak přeinstalováno BigClowní verzí. WTF.

Kromě toho bude během instalace playgroundu nainstalována další hromada balastu (NPM, NodeRED, Mosquitto,….), kterážto ale skončí chybou, takže nic nefunguje, ale přitom je na disku vše uloženo.

Proč? Chtěl jsem jen nějaké IDE, napsat si HelloWorld program, poslat ho do BigClownu, nechat ho zablikat diodou! Proč potřebuju na první seznámení tohle všechno? Navíc, já už svůj NodeRED i mosquitto mám. A teď mi to straší i na notebooku a ještě nefunkční. A kde je nějaké to IDE?

No, nebudu to maskovat, to už mne to fakt sralo. Nic nefungovalo. V dokumentaci TODO, Instalátor ERROR. Nebudu tu dlouze popisovat jak, ale nakonec jsem si to sám vyřešil a opravil (to bude součástí druhého článku na téma “Jak zprovoznit BigClown”).

Vzdal jsem IDE, vzdal jsem vlastní Hello World. Já už vlastně ani nechtěl programovat. Měl jsem jen jeden cí. Zprovoznit CO2 senzory a vydolovat data. Prosím, ať aspoň to funguje. A co myslíte? Ani prd.

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Cannot open DFU device 0483:df11
No DFU capable USB device available

Zkusil jsem nahrát hotový SW na CO2 monitor do Core modulu dle návodu na stránkách BigClown. Jenže, chybová hláška viz výš. Takže, ani to nepůjde po dobrém.

Nakonec jsem našel návod, jak chybu odstranit. 

Pomocí utility Zadig je potřeba odstranit špatné DFU ovladače ve vašem počítači, které jsem ale 5 minut před tím nainstaloval pomocí oficiálního BigClown instalátoru. Proč se proboha nenainstalovaly správně? Proč to musím hledat někde v dokumentaci? A to jsem to testoval na úplně čisté instalaci windows. Nedokážu si to představit testovat to na svém pracovním kompu.

Ok, drivery jsem opravil. Už to půjde? Už to bude bez problémů? Ale kdeže….

bcf flash --dfu bigclownlabs/bcf-kit-wireless-co2-monitor:latest

Zajímavé. Udělal jsem vše podle návodu a stejně to vrací chyby. Ale kupodivu tyhle chybové hlášky neznamenají, že se SW nenahrál. Nahrál. A vše je vlastně OK. Asi chtějí jen případné Punkové nováčky udržet v pozoru.

Někde v téhle fázi boje jsem si uvědomil, že moje jediná šance na zachování zdravého rozumu je použít kompletně referenční projekt, nic neupravovat a neměnit. A proto jsem doobjednal zbývající komponenty. Aby vše fungovalo (hehe, já naivka).

Doobjednal jsem proto teplotní, tlakové a vlhkostní čidla (tagy) i krytky, aby vše fungovalo a vypadalo jako u nich. A pak počkal na dodávku. Když vše dorazilo, pokračoval jsem.

Když komponenty dorazily, krabičky jsem zkompletoval a pustil se do rozchození přenosu mezi Core modulem a USB donglem. A co byste řekli? Vše při starém, hromada dalších problémů.

Stále jsem se snažil pochopit, jak spárovat zařízení. Kde je něco, čím párování udělám? Jak komunikace funguje… Jenže, to v dokumentaci taky moc popsáno není. Jediné co se dozvíte je, že na spárování USB donglu a zařízení potřebujete NodeRED, MQTT a další programy. Proboha….

A to je podle mne další obrovská zvláštnost u BigClownu. Namísto jednoduchých příkazu je potřeba strašně moc balastu. Všechno je obaleno deseti vrstvama. Namísto konfiguračního souboru a nějakých příkazů potřebujete funkční BigClown toolchain + Mosquitto server + NodeRED na to, abyste přidali nové zařízení.

Já si teda punk představuju jinak. Opět nechápu, na koho je tohle cíleno. To si jako ten teenager koupí zařízení za 4000kč, za 5 min si ho složí, pak si nainstaluje hromadu SW (kde vlastně ani instalátor nefunguje), do něj vloží CTRL+C a CTRL+V bloky, klikne na tlačítko “spárovat” a cítí se punkově? A vypráví pak ve škole, jakej je IoT mág?

No ty bláho. Ale dobře. Takže cíl byl rozchodit tohle všechno ručně, protože instalátor moc nepomohl. Psal jsem tedy znovu na podporu i s dotazem, jeslti třeba není nějaká ta command line utilita.

A ona je. Jmenuje se BCG (BigClownGateway) a je to driver, který převádí data z Usb donglu to MQTT. To je bohužel to nejníž, kam se člověk dostane. Pod tím je už zřejmě jen BigClown protokol, co přenáší šifrovaná data ze zařízení do Donglu. Ten pak vezme ID zařízení, název a hodnotu dat a pošle to jako MQTT zprávu.

c:\Program Files (x86)\Python36-32\Scripts\bcg -H dockerserver.dum -P 1883 --debug

Ok, výborně. Už vím jak pustit samotný přenos ze zařízení do USB Donglu a z něj pak převést data do mého MQTT serveru. To už bude hračka. Bude?

c:\Program Files (x86)\Python36-32\Scripts&amp;gt;bcg -H dockerserver.dum -P 1883 --debug
2017-12-15 11:07:47,373 INFO: Start
2017-12-15 11:07:47,391 INFO: Connected to MQTT broker with code 0
2017-12-15 11:07:47,391 DEBUG: subscribe gateway/all/info/get
2017-12-15 11:07:47,392 DEBUG: subscribe gateway/ping

No jasně že ne. Nebyla a nebude. Ačkoli podle výstupu to vypadalo, že vše jede. Že je BCG připojeno k MQTT, že jsou zaregistrovány MQTT topicy, že je vše ready, nic se nestalo. Nic to nedělalo.

Tak jsem zase zkoušel vše možné i nemožné a další hodina byla háji. Ověřil jsem jiný MQTT server, zkusil simulovat MQTT příkazy. Vše fungovalo až na BCG utilitu.

Tak mne napadnlo, jestli třeba není nějaký konflikt s COM porty. Byl a nebyl. Utilita v základu používá linuxový port /dev/ttyUSB0 a je jí jedno, jestli je na Linuxu nebo Windows. Je jí i jedno, že se to nedaří. Nijak se neobtěžuje informovat o tom, že se třeba bude zkoušet připojet k danému portu, nebo že se to ani po 10ti minutách nepovedlo.

Chjo. Tak jsem chování opět nahlásil zpět do BigClownu ochotné podpoře, ta mi domněnku potvrdila a já testoval dál.

bcg -H dockerserver.dum -P 1883 --device COM4 --debug

2017-12-15 11:26:37,713 INFO: Start
2017-12-15 11:26:37,728 INFO: Connected to MQTT broker with code 0
2017-12-15 11:26:37,728 DEBUG: subscribe gateway/ping
2017-12-15 11:26:37,729 DEBUG: subscribe gateway/all/info/get
2017-12-15 11:26:37,733 INFO: Opened serial port: COM4
2017-12-15 11:26:37,733 DEBUG: write b'["/info/get", null]\n'
2017-12-15 11:26:37,760 DEBUG: read b'["/info", {"id": "836d19836e74", "firmware": "bcf-usb-dongle-v1.5.5"}]\n'
2017-12-15 11:26:37,761 DEBUG: subscribe gateway/bcf-usb-dongle-v1.5.5/+/+
2017-12-15 11:26:37,764 DEBUG: write b'["$eeprom/alias/list", 0]\n'

Výborně. Po zadání portu se už správně otevřel COM4, který je napojený na USB Dongle. Zdá se, že to z USB donglu i data čte. Tak žeby? Žeby, prosím, žeby už to fungovalo?

Stisknu tlačítko “List all gateways” a co nevidím, V debug výpise se mi vrací správně identifkace USB Donglu. Tím získávám nezlomitelnou sebedůvěru, že už bude vše dobré. Že jsem vyhrál.

Mačkám tedy druhé tlačítko “Start node pairing”, restartuju CoreModul abych vynutil párování a NIC….. zase NIC. Moje ego i důvěra ve vlastní schopnosti klesá na nulu. Jak proboha nemůžu být schopný rozchodit něco, co je stvořeno pro Lamy, stojí to víc než kdejaký chytrý telefon a má to být Punk?

Jak to, že jsem Wemose a Arduino rozchodil za hodinu a nic jsem o tom tenkrát nevěděl a tohle, se všema těma zkušenostma, nedokážu rozchodit? Je chyba ve mně? Jsem lama? Je to věkem? Je to osobní?

No tak zase píšu na podporu. Posílám screenshot, popisuju chování a potupně žádám o další radu. Odpověď přichází záhy. Chce to aktualizovat dongle, 1.5.5 pouzival slova jako enrollment.

NOJÓ. Že mne to nenapadlo rovn… CO? Proč proboha nemá USB Dongle nemá rovnou správnou verzi firmware, než to těm nebohým lamám pošlou? Proč to nezjistil už installátor? Proč to nenapíše nějakou hlášku v tom NodeREDU? Proč to není někde viditelně v dokumentaci? PROČ?

A jak to mám vlastně zaktualizovat? Nikde jsme o tom nic nečetl (minimálně né v základních kapitolách Big clown for dummies). A tak posílám další email s žádostí o link. Odpověď opět téměř ihned. Jsem vysvobozen!

Opět nutno zmínit, že podpora je fakt ochotná. Bez nich bych to nerozchodil. Asi bych to vzal, zahrabal, zapálil, pohřbil a dělal, že se to nikdy nestalo. Pan Blavka z BigClownu prý na starosti dokumentaci, na které momentálně intenzivně pracuje. Všechno, na co jsem narazil jsem mu rovnou i posílal, takže to snad pro další Punkery už bude jednodušší.

bcf flash --device /dev/ttyUSB0 bigclownlabs/bcf-gateway-usb-dongle:latest --devices COM4

Tak jo, zkusme aktualizovat Usb stick. Snad to už bude poslední aktualizace, poslední zádrhel.

Ohóoo. Po updatu USB donglu začalo fungovat i napárování a posílání dat. Zase jsem se cítil jako král.

Po cca deseti hodinách laborování jsem zvládl rozchodit BigClowna s posíláním dat do NodeREDu. Z toho co jsem zažil se nabízí otázka, jestli ten Punk není náhodou v tom rozchození všech nástrojů a ve vyřešení nástrah nekompatabilních driverů, firmwarů a softwarů.

Když fungovaly data, bylo pak na čase to spojit s Loxonem. A protože je tenhle článek už tak pekelně dlouhý, nechám si to na příště a pojmu to trochu obecně. Půjde totiž o přenost dat mezi MQTT a Loxone, takže to může být použito pro jakékoli jakékoli zařízení, včetně mých oblíbených Wemosů.

 

Zároveň mám pak ještě rozepsaný jeden čánek, kde popíšu přesně celý postup rozchození BigClowna, kdyby s tím třeba někdo někdy taky bojoval (a nebo kdybych to za čas musel kvůli nějakému updatu absolvovat znova já).

Co se týká BigClowna obecně, celému konceptu prostě nerozumím. Maskuje to jak hardware, firmware i programování pomocí strašně moc high-level konceptů. Namísto přímého přístupu k HW je tam spousta balastu. Do toho HW, které je opravdu dost drahé a na první pokusy bastlení, kdy člověk logicky něco spálí, dost nevhodné. K tomu pak všechny výše popsané komplikace, které by člověk čekal u HW z Aliexpressu, ale ne u namíru prodávaného HW.

Nevím, možná je nějaká cílovka, kterou nevidím. Možná to jsou firmy, ale pak nechápu punkový styl. Možná to jsou bohaté děcka, co chtějí machrovat. Možná je to někdo úplně jiný.

Buď jak buď, chce to dodělat dokumentaci, vychytat celý proces tak, aby stejně jako trvá 5 minut zapojení HW, trvalo 5 minut i rozchození SW. A určitě to chce nějaké IDE, ukázky jak si napsat něco vlastního a celkově ten HW trochu víc přiblížit uživateli. Já měl takto pocit, že se ho celou dobu BigClown snaží předemnou schovat.

Loxone – tipy&triky – jak získat UUID kteréhokoli prvku

Loxone – tipy&triky – jak získat UUID kteréhokoli prvku

Comments 62 comments

Dneska (vlastně před chvilkou, a rovnou to píšu, protože jsem z toho fakt nadšen) se mi povedlu vskutku parádní kousek…. (a jestli mi někdo řekne, že jste to znali, nebo že to je někde popsáno, tak budu fakt naštvanej 😉 ).

Řešil jsem, jak propojit dohromady Roombu, MQTT, NodeRed, mé vlastní RoombaWalls a do toho Loxone. Cílem je, aby si Roomba uměla sama rozsvítit v dané místnosti a uměla si i sama zapnout virtuální zdi v okamžiku, kdy jsou potřeba.

Na rozsvěcení jsem se stále snažil zprovoznit Websockets (marně), Node-lox-mqtt-gateway (marně), případně pak nějak jednoduše přes virtuální HTTP vstupy/výstupy (lze, ale dost opruzoidně).

Až jsem se rozhodl trochu “blíž” podívat na Loxone webovou aplikaci, abych se podíval, jak vlastně oni komunikují s Loxonem. A tady jsem oběvil (alespoň pro mne) zlatý grál ;-).

Ačkoli v dokumentaci píší, že musíte definovat virtuální vstupy/výstupy pro komunikaci s venkem, není tomu tak úplně pravda. Stejně tak není pravda, že přes HTTP požadavek nelze zapnout napřímo dané světlo, aniž by člověk simuloval HW vstup Loxonu.

Je to totiž o tom, že každý prvek v LoxConfigu má vlastní Uuid. Tenhle Uuid zřejmě nejde zjistit v Loxone configu, teoreticky by asi šlo najít ho v Loxone programu v XML souboru, ale mnohem snáž to jde právě přes jejich web aplikaci.

Stačí otevřít aplikaci v Chrome, přes developer tools (F12) se podívat do záložky “Console” a zmáčknout tlačítko dle potřeby (nebo třeba kliknout na žaluzie, nebo cokoli jiného. A hle. Máte kompletní URL adresu s požadavkem, UUIDem tak, abyste daný příkaz mohli vykonat i odkudkoli jinde.

Tohle jsou třeba žaluzie. A není potřeba žádný debilní virtuální vstup navíc, není potřeba nic donastavovat v LoxConfigu a není potřeba se ani prosit na naprosto nekompetentní Loxone podpoře, kde jen tak mimochodem o adrese /jdev/sps/io nemají ani tušení, jelikož znají jen /dev/sps/io, pomocí které šahají jen na fyzické vstupy/výstupy HW, což je ale k programování dost nešikovné.

A takhle vypadá primitivní NodeRED program na rozsvícení světla. To šedé vlevo je prvek “Inject”, který generuje msg se zprávou “status”:”on”

A takhle pak vypadá HTTP request, pomocí kterého se posílá zpráva on/off do loxonu

A to je vše. A takto tím pádem jde ovládat cokoli uvnitř Loxone, aniž by se museloy na vše dělat virtuální vstupy tak, jak to doporučují EXPERTI z Loxone podpory.

PS: Jen tak mimochodem, NodeRED je masakr. Pokud by v Loxonu vytáhli hlavy ze svých pr*** a nabídli by NodeRED nativně jako nadstavbu, neměli by jejich systém naprosto konkurenci.

Díky kombinaci UUID bloků v LoxoneConfigu a programovacím možnostem NodeRED jdou efektivně naprogramovat věci, které by byly jinak nemožné (viz rozsvěcení místností dle průjezdy Roomby, ovládání virtuální zdí roomby jen když roomba jede,….)

NodeRED – Propojení všeho se vším, od Arduina po Loxone

NodeRED – Propojení všeho se vším, od Arduina po Loxone

Comments 47 comments

Jak jsem psal v předchozím článku, MQTT i NodeRed instaluji na Ubuntu linuxu. Jde ale rozběhat třeba i na Raspberry Pi  nebo Turrisu (OpenWRT).

Instalace NodeRED je relativně jednoduchá. Do ubuntu jsem musel nejprve doinstalovat aplikaci npm (což jsem zjistil, že je balíčkovací služba pro javascript) a následně pak pomocí npm aplikace nainstalovat NodeRED.

sudo apt-get install npm
sudo npm install -g --unsafe-perm node-red

Po samo-doinstalování obrovského množství dalších navazujícíh balíků měl začít fungovat příkaz `node-red`. Ale prdlajs. Takže další postup pak byl:

sudo apt-get install nodejs-legacy
node -v
##v4.2.6

sudo apt-get install npm
npm -v
##3.5.2

sudo npm install -g --unsafe-perm node-red node-red-admin

Dál bylo potřeba otevřít firewall port 1880, který node-red používá pro komunikaci

sudo ufw allow 1880
##Rules updated
##Rules updated (v6)

A pak už node-red konečně naběhl.


node-red

Welcome to Node-RED
===================

9 Dec 15:41:14 - [info] Node-RED version: v0.15.2
9 Dec 15:41:14 - [info] Node.js version: v4.2.6
9 Dec 15:41:14 - [info] Linux 4.4.0-53-generic x64 LE
9 Dec 15:41:14 - [info] Loading palette nodes
9 Dec 15:41:14 - [warn] ------------------------------------------------------
9 Dec 15:41:14 - [warn] [rpi-gpio] Info : Ignoring Raspberry Pi specific node
9 Dec 15:41:14 - [warn] ------------------------------------------------------
9 Dec 15:41:14 - [info] Settings file : /home/dev/.node-red/settings.js
9 Dec 15:41:14 - [info] User directory : /home/dev/.node-red
9 Dec 15:41:14 - [info] Flows file : /home/dev/.node-red/flows_home-server.json
9 Dec 15:41:14 - [info] Creating new flow file
9 Dec 15:41:14 - [info] Server now running at http://127.0.0.1:1880/
9 Dec 15:41:14 - [info] Starting flows
9 Dec 15:41:14 - [info] Started flows

Další krok je nastavení, aby se NodeRED spouštěl sám po startu. To už nebudu popisovat, protože bych jen kopíroval návod, podle kterého jsem postupoval. Ten jde najít v tomto super článku (bod 3 a dál).

Použití NodeRED

Tak jo, nainstalované to je, co teď s tím dál ;-). Vraťme se k naší ukázce z minulého článku o MQTT. V levym okně máme příkaz na poslání zprávy přes kanál(topic) hello/world. V pravém okně nahoře je pak příjemce této zprávy, abychom viděli, že vše funguje.

V pravo dole pak nasloucháme nové zprávě “bye/world”. Jak jde vidět z následujících screenshotů, při poslání zprávy na “hello/world” se tato zpráva ukáže i na “bye/world”. Jak to?

Protože NodeRED ;-). Jako první jsem pro otestování funkčnosti NodeRED a jeho napojení na MQTT udělal jednoduché přeposlání přijaté zprávy z jednoho kanálu na druhý.

A takhle to vypadá v NodeRED. Vlevo je MQTT consumer, nastavený tak, aby naslouchal topic hello/world

V pravo pak MQTT publisher, který přijatou zprávu pošle po kanálu (topicu) bye/world.

Dole pak mám ještě debug výstup, který zobrazuje přijaté zprávy.

A co loxone, jde to propojit?

No jasně! ;-). Pro testování jsem použil zatím jen REST Api loxone, ale NodeRED podporuje i websockets, navíc jsou pro Loxone už naprogramované přímo rozšíření pro NodeRED (viz dále).

Nyní nám ale pro jednoduchý test stačí RestAPI. Upravíme diagram tak, aby po přijetí jakékoli zprávy v topicu hello/world se nám rozsvítilo (nebo zhaslo) světlo v pracovně. To je cool ne? 😉

Samotné nastavení HTTP požadavku vypadá nějak takto. Nic složitého, jen se zavolá HTTP GET na adrese /dev/sps/io/WebApiTest/PulseDown.

Co se týká URL adresy, tak Loxone dokumentace stojí za starou bačkoru. Podle návodu by měla být adresa /prikaz/control/hodnota, coz ale /dev/sps/io/INPUT/PRIKAZ rozhodne není.

Touto url říkáme, že chceme na virtuální vstup “WebApiTest” poslat Impuls Down-Up. V Loxonu tak musíme tento virtuální vstup vytvořit a propojit se světlem.

A to je všechno. Nyní, kdykoli se objeví zpráva, světlo se přepne. Naprostá paráda. Nevím jak vy ostatní, ale já jsem nadšen. Těch možností, k čemu se to využít, je totiž neomezeně. Díky kombinaci NodeRED+Loxone tak jde do Loxonu dostat spoustu nových dat, od Arduino senzorů, dat z externích databází až po informace z Twitteru, Email nebo cokoli jiného vás jen napadne.

Co dál

NodeRED má obrovskou komunitu a kromě základních bloků (Nodes) má parádní knihovn dalších rozšíření – http://flows.nodered.org/. Jsou tam například i bloky na komunikaci s Modbus, KNX nebo Loxone.

Nyní to chce pořádně vyzkoušet a pohrát si s tím víc. V základu mám ověřeno, že vše funguje. Nyní zkusím zprovoznit nad Arduinem nějaký ten senzor a přes MQTT-NodeRed ho posílat do Loxonu. A uvidíme, jak to bude šlapat. Co jsem zatím testoval, tak problémy žádné, ale běží mi to jen chvilku.

Pokud ale vše pojede opravdu jak má a bude to 100% stabilní, vidím v tom obrovský potenciál. Navíc v případě, že by Loxone pokračoval se svými gestapáckými manýry a ještě více uzavíral jeho systém, tak se takto dá udělat kompletní rozšíření a defakto z architektury “Loxone je ten hlavní” udělat “NodeRED je ten hlavní” a Loxone mít jen jako podružný systém.

Použité linky

forumlink
Link na diskuzní fórum o Loxonu a Arduinu