Browsed by
Tag: MQTT

Ulanzi TC001

Ulanzi TC001

Comments 17 comments

Ahoj, tak dneska si dáme jeden gadget článek. Dorazila mi z Aliny další hračka, která je vlastně fakt jen pro radost, ale zato pro velkou radost :).

Jde o chytrý budík (dá li se tomu vlastně tak říkat), který jde flashnout lepším firmwarem a pak napojit na MQTT nebo REST API, takže pak ve finále z něj vlastně budík ani hodiny být nemusí :). Zařízení se jmenuje ULANZI TC001 a je fakt skvělé. Narozdíl od jeho dražšího (a zřejmě původně originálního) bráchy stojí jen 50usd (originál 200usd) a přitom podle mě funguje stejně skvěle (ale originál nemám, viděl jsem jen videa).

Zařízení se dodává s originálním čínským firmware, který sice také jde nějak někam napojit,ale cílová apka už není dále vyvíjená a jelikož je potřeba zařízení připojit do vlastní sítě, doporučuju raději flashnout pomocí open source firmwaru. Alternativní firmware se jmenuje AWTRIX 3, informace o něm najdete zde, a samotný flash pak probíhá plně automaticky z prostředí webové stránky pomocí připojeného USB kabelu do zařízení.

Flasher najdete na této stránce https://blueforcer.github.io/awtrix3/#/flasher (pro toto zařízení použijte první zmíněnou metodu na stránce)

Po naflashování Vám zařízení ukáže svou IP adresu a vytvoří wifi síť. Na tu se připojíte, nastavíte wifi credentials do Vaší sítě a hotovo. Zbytek už budete konfigurovat v rámci vlastní sítě přímo na zařízení.

Se zařízením se dá komunikovat buď přes MQTT nebo napřímo přes REST API. Dokumentace je detailně popsaná zde: https://blueforcer.github.io/awtrix3/#/api?id=switch-to-specific-app.

ULANZI TC001 má jednak 4 zabudované vlastní apky, a to čas, kalendář, teplotu a vlhkost, která se může střídat s Vašimi apkami, které mu nahrajete přes API, případně je můžete přes zařízení vypnout a nechat ukazovat jen Vaše data.

Možnosti jsou opravdu impozantní, jde se zařízením dělat spousta psích kusů. To hlavní je, že buď do zařízení nahrajete aplikaci pod nějakým jménem, pod kterým ji pak zas můžete odebrat, a nebo tam pošlete jen notifikaci, která se zobrazí jednorázově a pak zmizí. To se dělá pomocí příkazů /api/custom a /api/notify

Samotná zpráva pak může obsahovat (odhadem) tak 50 nastavitelných parametrů od barev, pozic, ikonek, progres barů, animaci, či třeba i vlastního kreslení po pixelu atd.

Na testování jsem zařízení narychlo propojil s NodeRED, kde jsem si udělal pár pokusů a rovnou začal sepisovat tento článek :). Proto jak vidíte je i samotný NodeRED dost ohavný, navíc v němčině, protože jsem si na první nastavení pomohl z repozitářů příkladů zde:  https://flows.blueforcer.de/search?provider=node_red

Samotný kód není nijak složitý. Pomocí funkce se připraví datový balík a ten pak pomocí REST api odešle:

Takto můžete své drahé udělat na valentýna radost. To prostě musí ocenit :))).

A to je vše. Až bude o víkendu (nevím teda kterém) trochu víc času, pohraju si s tím víc. Pokud někoho zařízení zaujalo a budete kupovat, pošlete pak fotky co všechno na něm zobrazujete :).

Netio PowerDIN 4PZ

Netio PowerDIN 4PZ

Comments 1 comment

Tak dneska tu mám představení nové hračky. Dostal jsem ji zase od firmy Netio, od které jsem dříve dostal chytré zásuvky na otestování. Tentokrát jde o jejich nový kompaktní chytrý prvek na Din lištu PowerDIN 4PZ, který ale umí opět všechny naše oblíbené protokoly 🙂

Když jsem byl osloven, jestli bych produkt nechtěl k otestování a k něčemu se mi nehodil, měl jsem vcelku jasno…… bazén :). Letos je v plánu dodělat ovládání našeho bazénu, zakopat všechny hadice a přepojit čerpadlo z prodlužky na venkovní rozvaděč.

Takže malý prvek, který dám do rozvaděče na DIN lištu se hodil naprosto přesně. Co se týká jeho vybavení, je opět naprosto parádní. Má 2x výstup 16A s integrovaným elektroměrem, dále pak 2x výstup jako NO/NC relé, 2x digitální vstup, Lan a WIFI. Takže spínání čerpadla, k tomu možnost spínání druhého zařízení, vstupy pak budou použity jeden pro rychlé spuštění čerpadla při čistění bazénu a druhý zatím zůstane asi nevyužit, ale můžu na něj dát třeba vodoměr, abych věděl, kolik vody jsem profiltroval :)). K tomu pak rovnou díky integrovanému elektroměru získám měření spotřeby čerpadla bazénu. Ideální.

 

Vše jde ovládat jak přes Modbus/TCP, tak přes MQTT nebo XML HTTP REST. Takže integraci lze udělat buď přes NodeRED, nebo napřímo z Loxone přes Modbus.  Koupit lze PowerDIN už nyní na jejich eshopu za 6189 bez dph (7489 s dph).

Zatím mi tu leží v krabici, takže není moc co víc fotit. Věřím ale, že už konečně venku roztaje sníh a začne být i trochu pěkně, takže půjde odzimovat bazén a pustit se do všech potřebných prací :). Další články snad už soon :).

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"}]

 

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.

Zigbee2MQTT, NodeRed a Loxone

Zigbee2MQTT, NodeRed a Loxone

Comments 15 comments

Po delší odmlce dnes článek o tom, jak propojit Zigbee2mqtt a Loxone. Jde o volné pokračování článku “Zigbee brána pomocí Raspbery PI“.  Minulý článek jsme skončili tím, že nám z RaspberyPI leze pomocí protokolu MQTT informace o stavech čidel, případně pomocí MQTT jsme schopni zapnout třeba žárovku nebo inteligentní zásuvku. Dnes se pojdmě podívat, jak to nyní propojit s Loxone tak, abychom mohli vše ovládat nativně z Loxone prostředí.

Jelikož Loxone nepodporuje MQTT (a zřejmě ani nikdy podpodorvat nebude), je opět potřeba si pomoci aplikací NodeRED, kterou jsem zde na blogu zmiňoval už spoustukrát (Propojení všeho se vším od Arduina po Loxone).

V návodu začneme směrem od Zigbme2mqtt k Loxone. Budu předpokládat, že máte čidla nainstalované a nampárované a že víte, jaká data z nich lezou (to jde vidět například v Zigbee2MQTT konzoly).

Xiaomi teploměr

Jako první ukážu propojení na teploměru Xiaomi. Jako MQTT kanál se použije dle nastavení například zigbee2mqtt/temperature01. Do kterého se posílají data:

{"temperature":26.05,"linkquality":47,"humidity":32.86,"pressure":927.38,"battery":42,"voltage":2985}

Abychom data přijali do Loxone, je potřeba je z MQTT převést do UDP (což je asi nejjednoduší a nejrychlejší cesta jak je do Loxone předat).

Vytvoříme si proto v NodeRed novou záložku Zigbee, do které jako první přidáme MQTT vstup. Ten nakonfigurujeme na připojení k našemu MQTT serveru a jako “Topic” vyplníme topic dle čidla. V našem případě “zigbee2mqtt/temperature01″

 

Jako další přidáme funkci, ve které napíšeme logiku převodu MQTT na UDP. V případě teploměru nás krom samotné teploty zajímá také tlak a vlhkost.

Abychom nemuseli provádět nějaké složité parsování na straně Loxone, vytvoříme v NodeRED logiku tak, že z jedné vstupní zprávy s těmito údaji vytvoříme tři výstupní UDP pakety, které se postupně pošlou do Loxonu.

var objPayload = JSON.parse(msg.payload);

var temperature = new Object();
temperature.payload = "temperature01/temperature=" + objPayload.temperature;

var humidity = new Object();
humidity.payload = "temperature01/humidity=" + objPayload.humidity;

var preasure = new Object();
preasure.payload = "temperature01/pressure=" + objPayload.pressure;

return [ [temperature,humidity,preasure] ];

Na prvním řádku převedeme Json objekt do Javascrip objektu. Díky tomu do něj můžeme dále jednoduše přistupovat.

Na řádcích 3 – 10 pak postupně vytvoříme tři objekty s výslednými daty. Každému objektu nastavíme payload, což je proměnná, které se pak v dalším bloku (UDP výstup) pošle na zadanou UDP adresu a port.

Abychom si v Loxonu parsování co nejvíce usnadnili, v každém UDP paketu posíláme název dat, rovnítko a hodnotu. Tento název spolu s rovnítkem pak budeme v řetezci hledat a v primitivních parserech Loxonu parsovat.

Jako poslední pak vrátíme pole objektů. Tím NodeREDu říkáme, že nechceme vrátit a zpracovat jeden objekt, ale několik objektů.

Xiaomi Cube

Krom čidla teploty byste mohli chtít parsovat například data z Xiami Cube. Z něj naopak čteme vždy jen jednu hodnotu, ale může jich být více typů. Proto zde přikládám i program na vyparsování typu události, její hodnoty a převod hodnoty do Loxone.

 

var objPayload = JSON.parse(msg.payload);

if ( objPayload.action == "flip90" )
{
   node.error("flip90 "+ objPayload.to_side);
   msg.payload = "flip"+ objPayload.to_side;
}
else if ( objPayload.action == "flip180" )
{
   node.error("flip180 "+ objPayload.side);
   msg.payload = "flip"+ objPayload.side;
}
if ( objPayload.action == "rotate_right" )
{
    node.error("rotate_right " + objPayload.angle);
    msg.payload = "rotate_right"; //+ objPayload.side;
    return msg;
}
else if ( objPayload.action  == "rotate_left" )
{
    node.error("rotate_left " + objPayload.angle);
    msg.payload = "rotate_left"; //+ objPayload.side;
}
else if ( objPayload.action == "slide" )
{
   node.error("slide "+objPayload.side);
   msg.payload = "slide"+ objPayload.side;
}
else if ( objPayload.action == "shake" )
{
   node.error("shake");
   msg.payload = "shake";
}
else if ( objPayload.action == "tap" )
{
   node.error("tap " + objPayload.side);
   msg.payload = "tap"+ objPayload.side;
   return msg;
}
else if ( objPayload.action == "wakeup" )
{
    //do nothing
    return null;
} else
{
    node.error("Unknown " +  objPayload.action);
    return null;
}

node.error(msg.payload);

Kostku jsem nakonec do ostrého provozu nenasadil, protože citlivost ovládání není ideální a úplně mi její používání k srdci nepřirostlo. Proto program není dodělán do finální podoby (nejsou tam například klíč=hodnota příkazy) ale jde spíše u ukázku toho, jak případně logiku řešit.

UDP komunikace

Poslední node který do našeho projektu v NodeRED přidáme je UDP output. V něm nastavíme IP adresu Loxonu a port, na kterém bude Loxone naše data naslouchat.

Tím máme v NodeRED pro teď hotovo a přesuňme se do Loxone Configu, kde přidáme UDP virtuální vstup.

A do něj jednotlivé UDP příkazy. Například parsování teploty nastavíme takto:

Postupně takto vytvoříme všechny UDP příkazy, které z NodeRED posíláme:

A tím máme hotovo. Hodnoty pak použijeme v Loxone configu stejně, jako jakékoli jiné hodnoty z teploměrů a čidel.

A nyní opačný směr

Tím máme vyřešeny všechna čidla a ovladače. To další, co nás ale zajímá, je ovládání zásuvek a osvětlení z Loxone směrem k Zigbee2MQTT.

Začneme zase v NodeRED. Zde nyní jako první vytvoříme UDP vstup, na kterém bude NodeRED naslouchat příkazy, které mu budeme z Loxone posílat.

Jako druhá je opět funkce, tentokrát taková, co převede textový příkaz z Loxone na MQTT příkaz. Abych nemusel psát hromadu malých funkcí, co převede jednotlivé příkazy, vytvořil jsem si univerzální funkci, která umí převést libovolný příkaz z Loxone na MQTT.

Funkce vezme jakýkoli vstupní řetezec ve formátu GROUP/DEVICE/VALUE, rozparsuje jej a převede na MQTT příkaz. Příakaz vytvoří tak, že topic je vždy zigbee2mqtt/ následovaný parametry dle typu zařízení.

node.error("incomming: " + msg.payload);

//parse incoming data to group-device-value
const regex = new RegExp("([a-zA-Z0-9]+)\/([a-zA-Z0-9]+)\/([a-zA-Z0-9]+)");
var res = regex.exec(msg.payload);

var nameGroup = res[1];
var nameDevice = res[2];
var value = res[3];

node.error("group=" + nameGroup);
node.error("device=" + nameDevice);
node.error("value=" + value);

//preapre MQTT command
msg.payload = {};
msg.topic = "zigbee2mqtt/";

//create light command
if ( nameGroup == "light" )
{
    msg.topic += nameDevice + "/set";
    
    if ( value === 0 )
      msg.payload.state = "off";
    else 
      //loxone has 0-100, but we need 0-255
      msg.payload.brightness = value*2.55;
}

node.error(msg);
return msg;

V současnosti je připravena logika jen pro světla, kdy topic je zigbee2mqtt/devicename/set a hodnota buď “off”, pokud je nastavena 0, nebo číselná hodnota 0-255 dle nastavení 0-100.

Až bude potřeba přidat například spínanou zásuvku, pridám nový group-name “powersocket” a dle potřeby vygeneruju cílový payload. Je to určitě o dost přehlednější, než mít pro každou žárovku a každou zásuvku zvlášť program.

Třetím blokem v NodeRED diagramu je pak MQTT output node. To dle nastaveného msg.payload vytvoří MQTT topic a odešle ho na zadaný server.

Loxone UDP výstup

Poslední co zbývá je Loxone UDP výstup, který bude posílat data do NodeRED.

Jako první přidáme “Virtuální výstup” do Loxone configu (bacha, zatímco existuje UDP vstup, tak opakem je Virtuální výstup, nikoli UDP výstup…..).

Tento výstup pak nakonfigurujeme jak je ukázáno na obrázku výše. Důležitá je adresa, kde to, že je to UDP určujeme přímým odkazem na zařízení v URI. Tzn v mém případě /dev/udp/192.168.0.222/60001

Příkaz pro nastavení svítivosti Ikea žárovky pak vypadá takto. Je potřeba natavit instrukci pro zapnutí a vypnutí, která je ale v našem případě stejná a až samotná hodnota určuje, zda zapínáme nebo vypínáme.

Na takto vytvoření příkaz pak normálně napojíme blok ovládání osvětlení AQ1, takže v okamžiku, kdy budete měnit osvětlení se budou přes UDP posílat příkazy s aktuální hodnotou.

Tady bohužel pak trochu narážíme na limity MQTT, jelikož při plynulé změně hodnot z 100 na 0 se pošle 100 příkazů, které se musí nejprve převést na UDP, z nějak pak na MQTT, kde ho pak Zigbee2MQTT musí převést na Zigbee a poslat žárovce. Výsledkem je, že při stmívání a rozsvěcení žárovky může dojít ke zpoždění.

Zde by bylo určitě lepší mít možnost poslat přes UDP příkaz rovnou k Zigbee bráně. Bohužel, nic takového jsem nenašel.

A to je vše

A to by mělo být vše pro to, abyste propojili Zigbee a Loxone v obou směrech. Na většinu zařízení je celý koncept naprosto dostatečný a stabilní. Jediná vyjímka jsou ta stmavovaná světla, kdy při plynulém přechodu z maxima na minium se může stlumění světla trochu zpozdit.

PS: Tak, jako je univerzální funkce na ovládání a nastavování MQTT zařízení, šla by napsat i univerzální funkce na příjem hodnot z teploměrů. Předpokládám, že až čidla po době více rozšířím, tak že i tu ještě trochu předělám.

 

Zigbee brána pomocí Raspbery PI

Zigbee brána pomocí Raspbery PI

Comments 113 comments

Tak, úvod o Zigbee spolu s důvody, proč je tak úžasný, máme za sebou z minula  a dneska se pojďme podívat na samotné rozchození.

Co budem potřebovat

Na provoz vlastní Zigbee brány budete potřebovat buď Raspberry (doporučuju RaspPI novější než v1. Na té to sice běží, ale dost pomalu). A nebo nějaký NAS nebo linuxový stroj, kde Vám pojede například Docker.

Dále pak komponenty na výrobu Zigbee brány:

A případně nějaká čidla na vyzkoušení

Já jsem se nakonec vydal cestou Raspberry 3 B+ , protože se mi nepovedla Zigbee USB rozchodit pod ESXI (ten ho chybně identifikoval jako USB drive a celý tuhnul). Zatím mi na Raspberry běží jen zigbee2mqtt, ale výhledově ho chci zkusit rozchodit spolu s Loxberry.

Flashnutí CC2531 USB snifferu

Jako první krok je potřeba stáhnout Flash Programmer (verzi 1, nikoli v2). Je nutná registrace, která je ale zdarma. Dále pak nainstalovat CC Debugger driver (zatím jen instalujte, nic nezapojujte do PC).

Nyní propojte všechny tři zakoupené komponenty z prvního seznamu mezi sebou (CC Debugger – Downloader Cable — USB Sniffer). Z USB Snifferu je potřeba vyndat chráničku, která je na pinech nastrčená. Měli byste získat celek, který má na obou koncích USB koncovku.

Propojku na USB sniffer připojte tak, že červená linka na kabelech je na straně, kde není USB zásuvka.

Nyní připojte USB kabel z CC Debugeru a ověřte, že zařízení vidíte ve správci zařízení. Mně tento krok sám o sobe nefungoval a bylo potřeba ještě ručně nainstalovat driver ze souboru swrc212a.zip z podsložky cebal\win_64bit_x64.

Pokud ve správci zařízení vidíte CC Debugger, připojte i USB Sniffer. Takže budete mít oba USB porty zapojené.

Nyní na CC Debugeru zmáčněte tlačítko Reset, čímž by se měla kontrolka rozsvítit zeleně.

Spusťte aplikaci Flash Programmer, kde byste v horním seznamu měli vidět CC Debuger zařízení. Pokud nevidíte, znamená to, že Vám nefunguje výše zmíněný driver. Zkontrolujte ho a případně nainstalujte.

Stáhněte custom firmware pro USB Sniffer – https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/CC2531/bin

V aplikaci zvolte custom firmware a vyberte soubor stažený v předchozím kroku.

Odškrtněte “Retain IEEE address when reprogramming the chip” a stiskněte “Perform flash”.

Počkejte, než se USB sniffer zase rozsvítí zeleně. Tím poznáte, že je přeprogramování hotovo.

Aplikaci můžete ukončit a sniffer vyndat z Vašeho PC:

Pokud používáte Linux, nebo se chcete podívat na původní návod, tak ten je k dispozici zde: https://github.com/Koenkk/zigbee2mqtt/wiki/Getting-started

Instalace na Raspberry

Tady je postup vcelku primitivní a funguje přesně jak je popsáno zde: https://github.com/Koenkk/zigbee2mqtt/wiki/Running-the-bridge

Jako první krok odpojte CC Debugger a Downloader kabel a připojte USB Sniffer do Raspberry. Pak zjistěte, zda Vaše Raspberry vidí USB Sniffer. To zjistíte tak, že ve složce /dev uvidíte ttyACM0. Takže zkuste například

ls -l /dev/ttyACM0

Pro samotnou instalaci postupně spusťte kroky popsané na výše zmíněné stránce. Tzn:

sudo curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
sudo apt-get install -y nodejs git make g++ gcc
sudo git clone https://github.com/Koenkk/zigbee2mqtt.git /opt/zigbee2mqtt
sudo chown -R pi:pi /opt/zigbee2mqtt
cd /opt/zigbee2mqtt
npm install

Pokud se něco nepovede, zkuste zkontrolovat verze npm a verzi node dle popisu v gihubu. Mně vše fungovalo napoprvé.

Když budete mít nainstalováno, je potřeba ještě zigbee2mqtt nakonfigurovat. To se dělá v souboru /opt/zigbee2mqtt/data/configuration.yaml.

Konfiguraci proveďtě pomocí nástroje nano:

nano /opt/zigbee2mqtt/data/configuration.yaml

upravte MQTT bránu dle Vašeho nastavení a soubor uložte (CTRL+O a ukončete pomocí pomocí CTRL+X).

Nyní zigbee2mqtt spusťte a otestujte, že vše jede.

cd /opt/zigbee2mqtt
npm start

Měli byste vidět něco jako:

2018-12-04 17:12:03 INFO Starting zigbee-shepherd
2018-12-04 17:12:04 INFO zigbee-shepherd started
2018-12-04 17:12:04 INFO Currently 0 devices are joined:
2018-12-04 17:12:04 INFO Connecting to MQTT server at mqtt://mqtt.dum
2018-12-04 17:12:04 INFO zigbee-shepherd ready
2018-12-04 17:12:04 INFO Connected to MQTT server

Automatické spouštění po startu

Pokud chcete, aby se brána spouštěla automaticky při restartu Raspberry, je potřeba ještě zaregistrovat zigbee2mqtt jako service.

sudo nano /etc/systemd/system/zigbee2mqtt.service

Vložit:

[Unit]
Description=zigbee2mqtt
After=network.target

[Service]
ExecStart=/usr/bin/npm start
WorkingDirectory=/opt/zigbee2mqtt
StandardOutput=inherit
StandardError=inherit
Restart=always
User=pi

[Install]
WantedBy=multi-user.target

A opět uložit a ukončit (CTRL+O, CTRL+X).

Nyní službu nahoďtte a podívejte se, že běží

sudo systemctl start zigbee2mqtt
systemctl status zigbee2mqtt.service

a pak ji povolte jako automatickou

# Start zigbee2mqtt
sudo systemctl start zigbee2mqtt

# Show status
systemctl status zigbee2mqtt.service

A tady ještě několik užitečných příkazů, především pak ten poslední, pomocí kterého se můžete podívat na log zigbee2mqtt i když běží na pozadí (hodí se při párování dalších zařízení).

# Stopping zigbee2mqtt
sudo systemctl stop zigbee2mqtt

# Starting zigbee2mqtt
sudo systemctl start zigbee2mqtt

# View the log of zigbee2mqtt
sudo journalctl -u zigbee2mqtt.service -f

Celý návod je opět dostupný zde:https://github.com/Koenkk/zigbee2mqtt/wiki/Running-the-bridge . Stačí následovat krok za krokem.

Při prvním testování doporučuji zigbee2mqtt spustit jen z příkazové řádky (ne jako service). Lépe uvidíte, co se uvnitř děje.

Párování zařízení

Párování samotné je občas vcelku věda. Každé zařízení má totiž vlastní postup, jak vyvolat párovací proces. Zatím mám vyzkoušené jen výše uvedená zařízení, ale ostatní snad už budou podobné.

Na zigbee2mqtt wiki je opět článek o párování, ale ten mi pomohl jen částečně.

Samotný zigbee2mqtt provádí párování cca jednou za minutu. Je proto potřeba se jednak trefit do tohoto časového okna (info o párování vidíte v logu) a udržet párované zařízení online.

V případe Xiaomi teploměru šlo všechno hladce. Stačilo podržet tlačítko teploměru po dobu cca 5 sekund a nacházet se v blízkosti USB sniferu.

V případě Xiaomi cube to byl boj. Co totiž na webu nepíšou je, že zařízení usíná. Je tedy potřeba opravdu trefit párovací okno, nejprve držet párovací tlačítko cca 5sekund, kdy se 3x rozbliká modře dioda. Pak párovací tlačítko pustit a dioda blikne ještě jednou (tím pravděpodobně potvrzuje, že se rozjel párovací proces). A nyní je potřeba cca jednou za sekundu jen krátce zmáčknout tlačítko. Tím kostku udržujete vzhůru. Jakmile se kostka přihlásí v logu zigbee2mqtt, můžete zběsilého mačkání nechat.

A na závěr Ikea žárovka. Tam se pro změnu párování dělá střídavým zapínáním a vypínáním, navíc je potřeba mít USB Zigbee sniffer jen pár cm od žárovky, ideálně úplně na ní.

Na tyhle účely jsem si vyrobil kabel s vypínačem a objímkou, abych mohl žárovku pustit přímo vedle Raspberry. Poté, co žárovku umístíte k Zigbee Snifferu, je potřeba 6x zapnout a vypnout žárovku tak, že ji vždy jen na chviličku zapnete, aby se téměř nestihla rozsvítit a pak na delší dobu vypnete (cca 0.5s zapnout a třeba 1s vypnout). Po těchto šesti ji nechte buď zaplou, nebo dál blikejte.

Závěrem

Jak vidíte, párování není úplně snadné :). Ale s trochou cviku to už jde.

A to je pro dnešek vše. Návod už je docela dlouhý, ale přitom je myslím vcelku snadný. Příště pak bude následovat ukázka, jak z MQTT dostat data přes NodeRED až do Loxone.

PS:

Ještě jen doplním pár vět ohledně diskuze před minulým článkem. Co by se mi opravdu líbilo, je PLC Zigbee na DIN lištu. Aby to bylo zase hloupé a nahraditelné zařízení, stejně jako třeba Quido nebo jiná seriovka. Něco málo jsem našel, ale ceny nejsou moc příjemné. Pokud by někdo věděl, dejte vědět.

Automatizace závlahy – softwareová část

Automatizace závlahy – softwareová část

Comments 36 comments

V minulém článku jsem popsal kompletní postup sestrojení automatické závlahy z Arduina, nyní tu zrekapituluju tu programovací část.

 

Začneme od NodeRED, takže vlastně trochu z prostředka. Dost se mi osvědčilo mít Wemosy co nejhloupější, stejně tak po Loxonu toho raději moc nechtít. Takže hlavní logiku mám v NodeRED, kde se dobře upravuje i testuje. Diagram ovládání jde vidět na obrázku nahoře. Defakto jen překlad Http volání do MQTT topiců a k tomu troška logiky.

Pro každý ventil mám v NodeRED jednu Http URL adresu, pomocí které ho ovládám. Takže například zapnutí vody z vodovodního řadu vypadá takto: http://nodered.dum/irrigation/input/water?state=on. Pokud zadám tuhle adresu, chytne ho tento node. Veškeré parametry za otazníkem převede do Json objektu a předá dál.  Takže z Http nodu vylézá objekt typu { “state” : “on” }.

Funkce Payload from state je zase vcelku jednoduchá. Jediné, co udělá, je, že ze vstupního objektu vyčte hodnotu “state” a tu pošle dál. Je to proto, že tato hodnota pak vstupuje do MQTT nodu, přes který se hodnota odešlě na MQTT server. Pokud bychom to propojili napřímo, vložil by se celý objekt.

Takže, jak jsem psal, z { “state”:”on” } se stává “on” a to se posílá do MQTT. Konkrétně jako topic “zavlaha/relay/0”. Pro každé relé mám udělaný samostatný topic, který pak wemosy naslouchají a podle toho relé nastavují. O tom dále.

Poslední, co by asi stálo za zmínění v NodeREDu, je hlídač na automatické vypnutí. Jakmile přijde jakýkoli příkaz na závlahu, automaticky se spouští counter, který automaticky vše po 60ti minutách vypne. Je to proto, že z Loxonu povel například nemusí dorazit a tak by se zalévalo donekonečna. Takto, dokud přicházejí povely, coutner se resetuje. A když nic nedorazí, pro jistotu se ještě vše vypne (PS: Je potřeba použít prvek trigger, nikoli delay. Delay se totiž dalším impulzem neresetuje, ale notifikuje pak všechny).

Od NodeREDu se teď posuňme k Loxonu. Opět, v Loxonu žádná magie. Jen hromada virtuálních výstupů, které volají definované HTTP endpointy. A k tomu pár časovačů, které pak dělají samotnou automatizaci.

 

Výstupy mám pak napojené na tlačítka, abych mohl v případě potřeby ovládat závlahu i ručně. A tlačítka jsou pak automatizované pomocí časovačů.

 

A to je celé kouzlo v Loxonu. Jen tupý program, co ukáže tlačítka a v daný čas ho spustí. To by snad Loxone neměl pokazit :)))). Výhledově pak ještě musím dodělat detekci deště a zautomatizovat napojení retenčky. Tam mne čeká ještě čidlo úrovně hladiny vodz. Takže se pak LoxConfig ještě trošku zkomplikuje.

A teď k Arduinu a programu pro Wemos. S ním ještě nejsem úplně spokojený a jestli si najdu čas, chtěl bych celou logiku ještě více zobecnit a zjednodušit. Logika pro relátka vychází z programu, co jsem měl pro ovládání vánočního stromečku. Ono je totiž téměř jedno, co člověk spíná.

Teda, skoro jedno. Původní program totiž fungoval tak, že poslouchal MQTT topic /christmastree/relaystate. Když přišel řetězec typu 0100100 tak podle toho věděl, že má vypnout první relé, zapnout druhé relé, vypnout třetí a čtvrté, zapnout páté,….. To je fajn, když ovládáte světýlka stromečku, ale naprd, když chcete v danou chvíli ovládat jen některá relé.

A tak jsem firmware upravil tak, že krom kompletního stavu umí ještě naslouchat na více různích topicách pro jednotlivá relé, konkrétně /rele-identifikator/rele/0-n. Takže pak jde například zapnout relé 5 tak, že do topicu /rele-identifikator/rele/5 zapíšeme buď 1, nebo “on”.

A podle toho, co za topic dorazí, se pak buď parsuje celý řetězec, nebo jen konkrétní relé. Krom úpravy na různé topicy ale bylo potřeba ještě vyřešit komplikace se dvěma Wemosama. Z pohledu MQTT jsem nechtěl topicy nijak odlišovat, takže bylo potřeba jednotlivé Wemosy naučit, od jakého indexu relátka obsluhují.

Takže, pro každý modul je samostatný ifdef, kde je definovan jeho mqtt client name (protože ten musí být pro každé zařízení unikátní), od kterého indexu relé tento modul obsluhuje, a které digitální výstupy jsou v jakém pořadí použity.

Jenže, to je přesně to,co se mi vůbec nelíbí. Toto bych chtěl předělat do nějaké online konfigurace, aby po prvním najetí šlo přes HTTP tuhle konfiguraci zadat a nemuselo se při flashování nahrávat vše napevno. Něco podobného už má vyřešený Martin Doubek pro svůj Swifitch. Takže mu na to budu muset mrknout a okopčit :))

Cílem je, abych měl jednotný firmware, který budu moct nahrát do jakéhokoli Wemosu a jen mu pak dynamicky nastavil, které výstupy ovládají která relátka, které topicy má poslouchat, atd. Dalším vylepšením pak ještě chci udělat, aby po sepnutí relé zapsal do nějakého dalšího topicu stav po sepnutí. Tzn aby bylo vidět, že akci opravdu provedl. Jestli se k tomu někdy dostanu, tak bych z toho pak udělal nějaký veřejný firmware, co by si každý mohl stáhnout a nahrát do Wemosu, aniž by musel bojovat s programováním.

 

 

Automatizace závlahy – hardwareová část

Automatizace závlahy – hardwareová část

Comments 19 comments

To je děs, jak ten čas frčí. Koukám, že poslední článek je už zase měsíc starý. Ale bylo toho teď zas nějak moc. Pořádal jsem rozlučku, pak jsem dělal o týden později svědka a o další týden později jsme byli na týden u móóře. Konkretétně v Chorvatsku, kde se všichni asi už úplně zbláznili, protože zdražili na dvojnásobek a kvalitu služeb ještě zhoršili. No nic…

Ale k dnešnímu tématu. Už nějakou dobu mám hotovou závlahu po technologické stránce. Jen nějak furt nebyl čas a materiál na automatizaci. A tak jsem pořád chodil kroutit ventilama ručně :).

Něco málo z elektroniky jsem stihl ještě před dovolenou, ale první nasazení se nakonec uskutečnilo až dnes. Není to sice stále úplně hotové, ale už to umí zalévat a já to nebudu muset dělat ručně. Závlahu jsem postavil nad WemosD1 a relé boardem. Hlavice se mají ovládat pomocí 24V, ale stačí jim i 12V.

Bohužel, trochu jsem to nedomyslel s počtem okruhů. Ačkoli jich mám jen sedm, tak mám ještě dva vstupy (retenčka a vodovodní řad), což dělá celkem devět hlavic a tím pádem devět relé. No, takže 8-relé board byl málo. Takže 8+2 relátek. No a druhý problém byl s Wemosem. Devět výstupů se mi nepovedlo rozchodit. Výstup D4 je využívaný stavovou diodou a D8 mi stávkoval.

Takže bylo nutné nasadit wemosy dva :). Ale zase kdo to má, žejo, blbá závlaha řízená dvěma procesorama :).

O napájení se stará zdroj 12V/5A z Aliny (co jsem měřil, vypadá na tyhle účely dostatečně), k tomu pak DC-DC měnič na 12V-5V pro Wemosy a 12V přes relé na jednotlivé hlavice.

Vše pokusně pospojovat, ověřit funkčnost a otestovat, že se to do té krabičky nějak vejde :). Tou dobou jsem sice ještě nevěděl, jak to nakonec udělám, ale to mne nějak moc netrápilo a tak jsem pokračoval dál :).

Nakonec jsem koupil na relátka a Wemosy ještě o trochu vyšší krabičku a samostatné prostupky. Tou dobou jsem už tušil, jak asi komponenty v krabici rozmístím a tak jsem začal vrtat a skládat.

Abych nemusel všechno kompletovat v kuse až venku, připravil jsem si spoustu věcí pomocí různých spojek a konektorů. Takže jsem toho mohl většinu dodělat ještě u sebe v technické místnosti na stole a venku jsem pak už řešil “jen” konektory.

Tady jde vidět finální test komponent před kompletací krabičky. Nakonec jsem to vymyslel tak, že 8-relé board je přišroubovaný ke dnu krabice, zatímco 2-relé, 2x Wemos a DCDC měnič jsou přilepeny pomocí tavné pistole na bocích krabice.

Trochu jsem se bál, jak to bude držet a vypadat, ale je to naprosto supr. Pistole za pár dolarů z Aliny a kolik parády to udělalo.

Myslím, že by to mohlo držet navěky. Že dřív budu potřebovat něco vyměnit, než že by to pustilo. Oba Wemosy jsem si dal schválně USBčkem nahoru, protože ještě předpokládám update firmwaru (a updatu na dálku zas tak nevěřím).

Druhá krabička je pak o dost méně zajímavá. V ní je jen samotný zdroj, přívod 230V a odchozích 12V. Zatím mám zdroj připojený na klasickou 230V zásuvku, protože mne ještě čeká natahání elektriky ven přes chráničky, dozapojení v rozvaděči, atd. Takže zatím to mám napojené přes prodlužku (trošku na prasáka, no…).

A tady už jsou pak další fotky z dneška, kdy jsem se pustil do instalace venkovní části. Postupně jsem si ven zvládl vynosit tak polovinu dílny, jelikož mi furt něco chybělo.

Nejdřív jsem udělal konektory na ventily v levém boxu. To ještě šlo, protože délka kabelů od ventilů byla dostatečná. Takže akorát propojit s konektorem a trochu zpacifikovat jednotlivé kabely, aby v tom byl pořádek.

Horší to bylo v pravém boxu. Tam už kabely nedosáhly, takže jsem to musel prodlužovat a ještě pak napojovat na konektory. To byl fakt opruz.

A takhle pak vypadalo pozapojování ventilů k relátkům.

A tady už první testování. Kupodivu všechno fungovalo hned napoprvé.

Jediný zádrhel je, že když se krabičky zavřely a daly nalevo od ventilů, došel wifi signál. Takže musí být momentálně krabička s Wemosama těsně pod víkem šachty, aby byla online. To ale výhledově vyřeším tak, že dám na půdu ještě jeden Unify AP a nasměruju ho na zahradu. Tím bych měl pokrýt vše i pro další čidla/ovládání, které plánuju.

A takhle vypadá výsledek. Ten červený kabel vlevo je ta zmiňovaná prodlužka. Ta teď bude dočasně vše napájet, než udělám finální venkovní elektriku. Pro jistou je to ještě zabalené v igelitu a zatažené stříbrnou izolepou. A to je pro teď vše. Pak už následovalo ladění SW a propojení s Loxonem. O tom v dalším článku.

 

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.