Browsed by
Tag: iot

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

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

Tak jsem se konečně dostal k nákupu chytrých zásuvek od Lidlu. A rovnou jsem do košíku přihodil ještě chytré světlo, které tam nově mají. Světlo chci použít v pracovně jako noční “přisvětlení”, abych nemusel při nočních šichtách svítit velkým světlem, ale zároveň nekoukal po tmě do monitoru.

Začnu nejprve Zigbee zásuvkami. Designově jsou opravdu povedené. Na obrázcích v eshopu vypadaly o dost hůř. Bohužel se v eshopu momentálně vůbec neukazují, takže ani nemůžu přiložit obrázek na srovnání.

Napárování se zigbee2mqtt proběhlo u jednoho kusu napoprvé, druhý kus pak nějak kompletně rozbil databázi zařízení :). Psalo to divné chyby o neexistujících cestách mezi zařízeními, přestal fungovat Zigbee2MqttAdmin panel a celkově se to úplně rozložilo. Řešením bylo buď vytáhnout zálohu Zigbee2Mqtt nastavení, nebo odmazat poslední napárované zařízení v database.db souboru (je to JSON) a napárovat znova, kdy už pak vše jelo jak mělo.  Když už jsem byl v tom, tak jsem rovnou aktualizoval i všechny komponenty v Dockeru, takže možná problém vyřešila i nějaká aktualizace. Moc jsem po tom nepátral a byl jsem rád, že to zase jede :).

Propojení NodeRed+Loxone

Co se týká propojení s Loxone, stále hledám optimální cestu. Řešení, kdy jsem v NodeRED přímo ovládal zařízení v Loxone se mi nelíbilo, protože pak člověk nemá přehled, kde se co děje. Takže nyní testuju trochu jiný přístup, kdy komunikace mezi NodeRED a Loxone je výhradně skrz virtuální vstupy a značky a samotná logika pak je napojena až v LoxConfigu. Je to sice o trochu pracnější, ale zatím mi to vyhovuje o dost víc.

Díky tomuto rozložení pak NodeRED je opravdu jen jakýsi most mezi technologiemi. V LoxConfigu pak mám jednu stránku, kde jsou všechny tyto značky a vstupy pohromadě, aby bylo vidět, co všechno do Loxone přes NodeRED jde.

Stejnou značku pak vytáhnu buď i ke konkrétnímu prvku, nebo si udělám už nějakou konkrétně pojmenovanou značku dle akce a tou to propojím mezi listy. Takže například vstup z Ikea tlačítka napojím rovnou na blok ovládání, zatímco komplexnější logiku, která spínala několik různých vánočních světel po domě mám schovanou pod značkou “act-VanoceObyvak” a až tu pak protáhnu skrz celý Loxconfig. Je to sice trochu více práce, ale je to o dost přehlednější, když se k tomu pak po čase vracím.

Když něco nejede, mám všechny vstupy/výstupy z NodeREDu na jedné záložce a snadno se to testuje. Když byla logika původně z NodeRED napojena například přímo na blok osvětlení, tak najít co/kdo to sepl bylo peklo :).

A celý tento systém má ještě jednu výhodu. Ne všechny prvky jdou přes Websockets v Loxone ovládat, případně třeba chybí některé příkazy (například toggle u konkrétního výstupu bloku osvětlení). Ale když si to do Loxone člověk dostane přes značku, tak už s tím uděla v Loxconfigu cokoli.

Lidl zigbee světlo

Co se týká Zigbee světla, tak provedení i světelnost mi na moje potřeby přijde dobrá. Ovládání je v Zigbee2Mqtt připraveno už velmi pěkně, takže jde na světle ovládat spoustu věcí, od klasického zapni/vypni, po různé barvy, teplotu barvy, ale i různé efekty.

Propojení mezi NodeRED a Loxone opět stejně jako v případě zásuvek. Tzn v Loxone mám značku on/off, na kterou je napojen pak NodeRED přes Loxone NodeRedContribLoxone komponentu. Nastavení barev mám na otestování udělané jen narychlo napřímo v NodeREDu:

Takhle vypadá přepínání barev. Myslím, že za ty prachy dobré :). Asi to reálně nikdy nevyužiju, ale na hraní supr :)))).

 

 

 

Jak jsem psal, nastavení barev z Loxone zatím neřeším. Pokud bych našel chvilku, tak si s tím víc pohraju a ještě napíšu článek. Bohužel jsem na tom teď časově ještě hůř než dřív, takže nebylo moc prostoru si s tím pohrát tak jak bych chtěl (a to si vždycky myslím, že už to s časem horší být nemůže :)).

NodeRED – více instancí

NodeRED – více instancí

Dnešní článek bude jen taková rychlovka na zamyšlení. Díky všem pokusům, co s NodeRED poslední dobou dělam, jsem se rozhodl vytvořit si dvě různé instance NodeRED.

Jedna je produkční, kde bude jen ostrý kód, který běží nonstop. Druhá pak bude developerská, kde budu testovat vše možné a kde bude v záložkách zůstávat i testovací bordel.

Díky docker-compose to není žádný problém. Každá instance používá svoje vlastní úložiště, zbytek mají obě instance naprosto totožné. Pro vývoj nových věcí tak používám developerskou instanci a pak pomocí import-export výsledek přenesu do produkční instance.

Můj aktuální kód pro NodeRED vypadá následovně:

FROM nodered/node-red

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

RUN npm install node-red-node-smooth
RUN npm install node-red-dashboard
RUN npm install node-red-node-ui-list
RUN npm install node-red-contrib-zigbee2mqtt
RUN npm install node-red-contrib-loxone
RUN npm install node-red-contrib-tgr-jsonata
RUN npm install node-red-contrib-xiaomi-sensors

RUN npm audit fix

A to je pro dnešek vše. Přišlo mi to jako dobrý nápad a třeba to inspiruje i někoho dalšího. Příště pak mám v plánu pár ukázek napárování zigbee na Loxone, konkrétně Ikea pětitlačítko, které se mi zatím hodně líbí. Mám na něm v pracovně světla, žaluzie i plachtu pergoly. Dál pak Sonoff tlačítka a chytré zásuvky.

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

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

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

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

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

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

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

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

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

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

ESXI

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

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

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

Zigbee stick

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

Docker

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

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

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

FROM nodered/node-red-docker

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

RUN npm install node-red-node-smooth
RUN npm install node-red-dashboard
RUN npm install node-red-node-ui-list
RUN npm install node-red-contrib-zigbee2mqtt

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

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

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

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

Zprovoznění

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

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

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

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

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

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

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

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

Darovanému BigClownu na zuby…. ?

Darovanému BigClownu na zuby…. ?

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

Nový firmware do vánočního stromečku

Nový firmware do vánočního stromečku

Začnu trochu od konce. Dělal jsem toho za svůj život už hodně, ale dneska poprvé jsem seděl pod vánočním stromečkem, do notebooku připojený USB kabel, co od něj vede, a debugoval a upgradoval jeho firmware ;-)).

Ale od začátku. Dostali jsme vánoční světýlka na stromeček. Bohužel, měly drobnou vadu. Po zapnutí elektriky se samy nerozsvítily. Bylo ještě potřeba na zdroji zmáčknout tlačítko. A to pokaždé, když se elektrika znovu zapnula.

No a to je naprd. Přece v chytrém domě nebudu ručně rozsvěcet vánoční stromeček, žejo. Takže začlo zkoušení a vymýšlení, jak problém vyřešit.

Problémů k vyřešení bylo hned několik. Jak ledky napájet, jak je spínat, čím spínat relátka a jak to propojit do Loxonu.

Napájení se nakonec vyřešilo elegantně. Od původního plánu napájet to 24V zdrojem s napěťovým děličem jsem se přes svůj laboratorní zdroj a měření spotřeby dostal až k USB 2A nabíječce, která krásně splinila zadání.

Další problém byly relátka. Z číny dorazil 8-modulový relé modul, jenže na spínání je potřeba 5V a to můj Wemos čip neměl. Tak jsem wemos vyměnil za Arduino UNO a zkusil to zapojit na něm. A relé se poprvé seplo, to bylo radosti.

Jenže jen do chvíle, kdy jsem si uvědomil, že UNO nemá ani ethernet, ani wifi. Takže pro dálkové spínání naprd. Takže zpět k Wemosu a jeho wifi.

Další cesta tak vedla přes samostatné napájení relé modulu 5V a pokusu, jestli náhodou relé pak nejde sepnout pomocí 3V z Wemosu. A abych to netestoval rovnou na Wemosu, využil jsem opět laboratorní zdroj (fakt ho miluju) a na napájení opět využil USB nabíječku.

A hle, prošlo to. Takže tudy by to mohlo jít. Takže jsem zkusil popropojovat Wemos a relátko, wemos napájet z USBčka, relé přes uřízlý USB kabel taky z USB nabíječky, a k tomu LEDky také z USB nabjíčeky.

To máme spoustu USB nabíječek ;-). Naštěstí relé modul a wemos utáhne jedna, a druhá na LEDky. To už jde. A časem koupím 5V 4A zdroj a bude to.

A protože s jedním relé není žádá sranda, tak sem to rozšířil na dub-step čtyř relátek 😉

Když byl hotový proof-of-concept, začal jsem to celé propojovat. Tady byla největší brzda nedostatek materiálu (tím jsem trpěl už i zkoušení, ale tady to byl extrém). Nejvíc mi chyběly kabílky na propojování PINů. Zatím jich dorazilo jen pár a tak jsem si zbytek povyráběl, z čeho šlo (hlavně pak z těch černých male-female patic, které lze stříhat štípačkama a dělat multi-konektory, viz ty žlutě zalepené konektory).

Po propojení a ověření, že vše bliká a cvaká, jak má, byla další mise nacpat to do nějaké krabičky, aby to vypadalo alespoň trochu civilizovaně a mohlo se to válet v obyváku. To se našetěstí povedlo také docela rychle a tak bylo řešení téměř hotové.

Nakonec pak už jen řetězy rozmotat, přenést do obyváku, znovu otestovat, a… vyhodit elektriku v celém baráku. Samozřejmě v deset večer, takže tma jak v řiti. A samozřejmě vyhozeno až venku na ulici.

I I. se přišla podivat, co jsem to zas udělal ;-). Kupodivu ale na vině nebylo moje udělátko, ale očividně dosloužilý zdroj k notebooku, co jsem si potřeboval zapojit. Po nahození se tím pádem mohlo pokračovat dál ;-).

Dneska jsem přesunul do obyváku stromek a ověsil ho lampičkama. Na řadu tak přišla softwareová část. Samoblikání je sice pěkné, ale chtělo to hlavně to zapínání a vypínání přes Loxone.

Plán byl využít už připravené MQTT komponenty z minula a jen to použít na něco konkrétního. Založil jsem další topic christmas-tree/relay a začal propojovat. Část v arduinu byla snadná. Vzít data ve formátu 101011 a podle toho postupně pozapínat/povypínat relátka. Easy.

Pak upravit Node-Red tak, aby se daly MQTT data posílat a testovat přes něj. Opět easy. Trochu složitější pak bylo parsování dat dle typu, tzn. když přijde z Loxonu “christmas-tree/relay/xxxx”, tak aby to poslal na správný kanál se správnýma datama. Ale stačilo zjistit, jak fungují v MQTT funkce, že je to Javascript a zjistit, jak se v JS pracuje se stringama. Easy.

EDIT: Večer jsem měl ještě chvilku čas, tak jsem si pohrál s Node-RED nastavením. Nutno říct, že je to naprosto impozantní a lze tam udělal naprosto cokoli (hlavně díky možnosti scriptovat pomocí JS). Takže nyní má stromeček ještě pět režimů blikání 🙂

Pak ale přišel kámen úrazu. To, co jsem očekával, že bude to nejjednodušší, tak nefungovalo. V Loxonu se mi nedařilo rozběhnout virtuální výstupy HTTP. Ať jsem dělal, co jsem dělal, tak z Loxonu data prostě nelezly. Nejen do Node-Red, ale ani na testovací app, ani do aplikace Hercules, co Loxon doporučuje, a ani nebyly vidět přes Ethereal či Wireshark.

A tak jsem zkoušel a zkoušel, nastavoval, ptal se na fóru a to, co všem funguje, mně nejelo. Nakonec jsem to všechno natvrdo zrestartoval a pakety začaly chodit. Bohužel, HTTP výstupy u mne mají cca 15sekund prodlevu. Pokud pošlu 10 signálů, místo aby přišly hned, dorazí vždy jeden, 15s pauza, další, zase pauza, …

Co naštěstí funguje bleskově jsou přímé TCP spojení. A protože HTTP nepotřebuju a TCP je přes NodeRED mnohem rychlejší/jednodušší, zůstal jsem u něj a HTTP dál neřešil.

A to byla poslední část potřebná k tomu, aby se z mobilu dal poslat příkaz do Loxonu, který pošle příkaz do NodeRED, který pošle MQTT zprávu na Ubuntu server, kde je pak zpráva poslána do Wemosu, který přes digitální výstupy pošle impulzy do relátek, které rozsvítí vánoční stromeček.

Jako jo, šlo by to asi o něco jednodušeji, ale takhle je to prostě cooool 😉

PĚKNÉ VÁNOCE VÁM VŠEM!

Mosquitto – MQTT message broker

Mosquitto – MQTT message broker

Co je Mosquitto? Je to MQTT message broker. To znamená, že umožňuje komunikaci mezi hromadou zařízení pomocí MQTT protokolu. Zařízení může být v jednom ze dvou režimů. To první je Publisher, to druhe Subscriber. Publisher data generuje a sype do nějaké fronty, Subscriber (odběratel) je pak načítá. Odběratelů může být neomezeně, stejně tak Publisherů (vydavatelů?).

Celé se to dá krásně využít k tomu, že všechny IoT čidla postavené na Arduinu generují data a jednotně je sypo do MQTT. Z MQTT se to pak jednotně načítá, ať už napřímo přes Loxone, nebo třeba do NodeRED, kde se nastaví co se s datama má dít a až pak se data pošlu dál.

Díky tomu se do čidel nemusí dávat žádná složitá logika na publikování dat, posílání jích do Loxone atd. Ale jen se to nasype do MQTT brokera a další logika se postaví až o stupeň dál.

Instalace Mosquitto serveru.

Já jsem využil toho, že mi doma běží server na pracovní věci, a tak jsem si udělal novou virtualizovanou instanci Ubuntu ;-). Ale jinak se dá mosquitto rozběhat i na Windows, Raspberry, Turrisu a dalších.

2016-12-04_12-54-58

Instalace byla v mém pomocí apt-get. Kromě balíku mosquitto sem bral i mosquitto-clients, které přidají příkazy na simulaci subscribera/publishera, takže lze otestovat, že vše běží jak má. Po nainstalování jsem pak pro účely ladění zapl komplet logování, které v ostrém provozu později vypnu.

sudo apt-get install mosquitto mosquitto-clients
sudo /etc/init.d/mosquitto stop
sudo nano /etc/mosquitto/mosquitto.conf
sudo /etc/init.d/mosquitto start

Do konfigurační soubor mosquitta jsem přidal:

2016-12-04_13-14-27

log_type error
log_type warning
log_type notice
log_type information

connection_messages true
log_timestamp true

A nahodil jsem zpět mosquitto. Pro otestování, že vše funuje jak má, jsou právě ty mosquitto-clients.

2016-12-04_16-06-53

Pro otestování subscribera je příkaz mosquitto_sub. Parametr -d zapíná debug zprávy, -t nastavuje název kanálu, nad kterým subscriber poslouchá.

mosquitto_sub -d -t hello/world

2016-12-04_13-09-54

Když máme posluchače, je potřeba vygenerovat nějakou zprávu. To se dělá pomocí publishera mosquitto_pub. Parametry opět stejné, akorat místo naslouchání na -t se do kanálu -t data pošlou, -m pak definuje zprávu na poslání.

mosquitto_pub -d -t hello/world -m "test"

2016-12-04_13-10-02

Jakmile vygenerujete publisherem zprávu, na subscriberovi se zobrazí

Client mosqsub/7136-home-serve received PUBLISH (d0, q0, r0, m0, 'hello/world', ... (4 bytes))
test

To znamená, že nám MQTT broker funguje jak má. Pokud by něco zlobilo, logy jsou dostupně v souboru  /var/log/mosquitto/mosquitto.log

Komunikace s Mosquitto serverem z Arduina

A teď ta druhá část, poslání/naslouchání MQTT s Arduina. Zkusíme poslat zprávu, kterou necháme zobrazit pomocí již nahozeného subscribera v konzoli a pak přijímat zprávy a při přijmutí bliknout diodou.

2016-12-04_13-54-39

Krok první, nainstalujeme si nějakou předpřipravenou MQTT knihovnu do Arduina. V menu VMICRO -> Visual Micro Explorer -> Manage Libraries.

2016-12-04_13-55-55

Zkusil jsem PubSubClient, tvrdí že je lightweight a takové mám rád ;-).

2016-12-04_13-56-32

Jako další krok vložíme knihovnu do projektu. Pokud člověk ví co dělá, stačí obyčejný #include<PubSubClient.h>, pokud ne, může si to vybrat takto z wizarda. Napoprvé je to fajn, že není potřeba lovit, jak se soubor přesně jmenuje.

2016-12-04_13-58-20

Zkusíme zkompilovat a zdá se, že je vše ok. Tak pojďme poslat nějaká data. Výhoda Arduina je, že celý ekosystém už je opravdu pěkně rozrostlý a na všechno existují připravené knihovny.

Na druhou stranu nevýhoda Arduina je, že celý ekosystém dělají lidé, co jsou zřejme opravdu borci na elektrotechniku, ale dost slabí na programování. Takže ačkoli je Arduino postavené nad c++,  jeho knihovny, ukázky a vše ostatní vypadá jako programy psané v čistém C kódu kdysi v minulém století.

Naštěstí to není až takový problém a všechno jde postupně zabalit do vlastních objektů a udělat si nad tím čistý kód.

Inicializace Wifi, Debugu, Mqtt a Diody

Aby měl návod trochu spád, spojím všechny tyto věci dohromady. Jak už jsem psal, kód pro Arduino je bohužel takový c-like spaghetti bastl. Ačkoli využívá objektový zápis, tak instance objektů existují kdesi globálně a jen se používají. To je supr pro nováčky, co netuší která bije, ale pro pokročilé vyvíjení je to imho škoda, protože to maskuje hromadu věcí a cokoli globálního je prostě blbě.

#include &lt;ESP8266WiFi.h&gt;
#include &lt;WiFiClient.h&gt;
#include &lt;PubSubClient.h&gt;

const char* ssid = "wifi";
const char* password = "password";
const char* mqtt_server = "192.168.0.102";

WiFiClient espClient;
PubSubClient mqttClient(espClient);

void setupDebug()
{
	Serial.begin(9600);
	Serial.println("WeMos MQTT test");
	Serial.println("");
}

void setupWifi()
{
	// Connect to your WiFi network
	WiFi.begin(ssid, password);
	Serial.print("Connecting");

	// Wait for successful connection
	while ( WiFi.status() != WL_CONNECTED )
	{
		delay(500);
		Serial.print(".");
	}
	Serial.println("");
	Serial.print("Connected to: ");
	Serial.println(ssid);
	Serial.print("IP address: ");
	Serial.println(WiFi.localIP());
	Serial.println("");
}

void setupMqtt()
{
	mqttClient.setServer(mqtt_server, 1883);
	mqttClient.setCallback(MQTT_callback);
}

void setupDiode()
{
	pinMode(LED_BUILTIN, OUTPUT);     // Initialize the LED_BUILTIN pin as an output 
}

void Blink(int nDelayOn, int nDelayOff)
{
	digitalWrite(LED_BUILTIN, HIGH);  // Turn the LED off by making the voltage HIGH
	delay(nDelayOn);                      // Wait for two seconds (to demonstrate the active low LED)
	digitalWrite(LED_BUILTIN, LOW);   // Turn the LED on (Note that LOW is the voltage level  
	delay(nDelayOff);                      // Wait for two seconds (to demonstrate the active low LED)
}

void setup() 
{ 
  setupDebug(); 
  setupWifi(); 
  setupMqtt(); 
  setupDiode(); 
}

Takhle nějak vypadá inicializace pro WeMos D1.

  • hromada “println” posílá po seriovém portu zpět do IDE stavy a zprávy
  • setupDebug inicializuje seriovou linku právě pro tyto přenosy.
  • setupWifi připojí wifi adaptér k zadané síti a vypíše kam se připojila.
  • setupMqtt nastaví parametry připojení pro MQTT clienta
  • setupDiode jakýmsi způsobem propojuje PIN LED_BUILTIN na OUTPUT diodu, toto zatím beru jako fakt a moc to nechápu
  • Blink slouží k bliknutí diody
  • A setup spustí všechny výše uvedené nastavení.

Spoustu nastavení, ale jinak nic objevného. Toto nastavení použijeme jak pro zapisování dat do MQTT, tak pro čtení.

Komunikace s MQTT brokerem

Po tom, co máme vše inicializováno, zbývá se jen připojit k MQTT brokerovi a posílat a přijímat data. Připojení se provede pomocí

if ( mqttClient.connected() == false )
  mqttClient.connect("ESP8266Client");

kdy řetězec “ESP8266Client” je pro mne velkou záhadou, ale mám to z examplu. Moc nerozumím tomu, proč je to jako string “ESP8266Client” místo objektu WiFi nebo espClient, ale je to jen další z divných věcí v Arduinu, která má zřejmě sloužit dobru, ale imho jen škodí.

Odeslání dat se provádí pomocí metody publish, která má jako první parametr název kanálu, jako druhý parametr data k odeslání.

mqttClient.publish("hello/world", "hello world");

Příjem dat se provádí pomocí zaregistrování callbacku metodou setCallback a pak přihlášení ke konkrétnímu kanálu metodou subscribe. Tady by mi přišlo logičtější mít co kanál možnost jiný callback, ale opět asi zjednodušení.

void MQTT_callback(char* topic, byte* payload, unsigned int length) {}
mqttClient.setCallback(MQTT_callback);
mqttClient.subscribe("hello/world/2");
&amp;amp;nbsp;

Celý kód pak vypadá třeba takto. V MQTT_callback se zobrazí obdržená data a blikneme diodou. V metodě reconnect se provádí testování platného připojení a jeho případně znovupřipojení, v metodě loop pak dokola testujeme platnost připojení, voláme interní loop MQTT clienta (kvůli přijmu dat) a každé 2sec posíláme zprávy do MQTT brokera “Hello world” spolu s pořadovým číslem zprávy.

void MQTT_callback(char* topic, byte* payload, unsigned int length) {
	Serial.print("Message arrived [");
	Serial.print(topic);
	Serial.print("] ");
	for ( int i = 0; i &amp;lt; length; i++ )
	{
		Serial.print((char)payload[i]);
	}
	Serial.println();

	Blink(100, 100);
}

void MQTT_reconnect() 
{
	// Loop until we're reconnected
	while ( !mqttClient.connected() )
	{
		Serial.print("Attempting MQTT connection...");
		// Attempt to connect
		if ( mqttClient.connect("ESP8266Client") )
		{
			Serial.println("connected");
			// Once connected, publish an announcement...
			mqttClient.publish("hello/world", "hello world");
			// ... and resubscribe
			mqttClient.subscribe("hello/world/2");
		}
		else
		{
			Serial.print("failed, rc=");
			Serial.print(mqttClient.state());
			Serial.println(" try again in 5 seconds");
			// Wait 5 seconds before retrying
			delay(5000);
		}
	}
}



void loop()
{
	if ( !mqttClient.connected() )
		MQTT_reconnect();
	mqttClient.loop();

	static long lastTime = 0;
	static int lastValue = 0;
	if ( millis() - lastTime &amp;amp;gt; 2000 )
	{
		char msg[50];
		snprintf(msg, 75, "hello world #%ld", lastValue++);
		Serial.print("Publish message: ");
		Serial.println(msg);
		mqttClient.publish("hello/world", msg);
		lastTime = millis();
	}
}

Na celém kódu není nic složitého a díky předpřipravenému MQTT clientu a hotovým ukázkám jde kód narychlo polepit dohromady.

Co je nevýhoda, tak kód je prostě ošklivý a nepřehledý. Na vlastní finální řešení to bude chtít obalit vše svými objekty, ideálně napsat i nějaké mock objekty kvůli testování a celkově nad tím udělat robustnější testování, aby člověk neprogramoval stylem zkompilovat-nahrát-zkusit-znovu. Takhle se programovalo v dobách Atari, ale ne dneska.

A to je vše, máme funční Arduino MQTT publisher i subscriber. Příště až bude čas, tak zkusím rozchodit onen Node-Red. A až dorazí věci z Aliny, tak na Wemos napom čidla a zkusim posílat nějaká smysluplnější data.

Ostatní linky

forumlink
Link na diskuzní fórum o Arduino vývoji