Browsed by
Category: IoT a Arduino

Ikea TRÅDFRI+ Zigbee + Loxone

Ikea TRÅDFRI+ Zigbee + Loxone

Comments 44 comments

Dnes trochu atypicky jeden krátký (nakonec se mi to celkem protáhlo :)) post na přání z publika :). Byla tu prosba o návod na propojení Ikea tlačítka TRÅDFRI z Ikea do Loxone pomocí Zigbee2Mqtt.

A protože další připravené články se zabývají trochu jinými tématy, rozhodl jsem se návod sepsat teď narychlo ve formě nového článku.

Celé schéma aktuálně vypadá takto. Ten horní pravý control-out je příprava na ovládání výsuvné pergoly, ale protože pořád prší, ještě jsem to raději nezapojoval a netestoval :).

V levé části grafu je Zigbee2Mqtt IN prvek pojmenovaný IkeaRoundButton01 dle názvu zařízení v konfiguraci Zigbee2Mqtt.

Jeho nastavení je Server (Zigbee2MQTT server), device(což je toto tlačítko) a jako výstup si z prvku bereme kompletní payload, tzn celý JSON objekt s daty ze zigbee.

Druhý z leva je prvek SWITCH. V něm lze zadat jeden až n podmínek, které když jsou pravdivé, tak vyšle na odpovídající výstup daného znovu celý svůj vstup.

Tzn prvek nikterak neupravuje vstup, jen ho přepošle na jeden z výstupu dle toho, která podmínka je platná.

Poslední parametr určuje, zda se vyhodnocuje do prvního platného pravidla, nebo vždy všechny. Tzn pokud se nastaví “všechny”, může se aktivovat více než jeden výstup. V mém případě je to jedno, je platná vždy jen jedna podmínka.

K rozhodování, která akce byla na tlačítku provedena testuji JSON atribut msg.payload.action (nastaveno v “property” prvku switch). Pro získání těchto hodnot je nejjednodušší si na začátku napojit DEBUG prvek (ten zelný) přímo na Zigbee2MQTT IN prvek a sledovat co z něj chodí.

Jak jde vidět v debug výstupu, z Zigbee2MQTT IN prvku leze JSON, ve kterém je properta action, battery a linkquality. Nás pro toto rozhodování zajíma jen ta akce, proto msg.payload.action.

 

Třetím prvkem z leva je prvek EXCHANGE. Ten je trochu nešikovně pojmenovaný, protože je to defakto přiřazení do proměnné (připadně změna, smazání či prohození).

 

Lze opět nastavit jeden či více kroků, ale pro naše účely nyní stačí jen jeden. Do přijatého msg.payload (ve kterém se ve chvíli vstupu nachází ještě JSON objekt ze Z2M) přiřadíme úplně jiná data (konkrétně textový řetezec). A to konkrétně taková, kterým bude pro změnu rozumět node-red-contrib-Loxone (dokumentace k Loxone WS třeba zde).

Na screenshotu je příkaz “up”, který posílám do bloku žaluzií. Tím říkám Loxone, aby začal vytahovat žaluzie. Dále pak na základě tlačítka posílám také UpOff, kterým se vytahování vypíná (při uvolnění tlačítka), a down a DownOff na spuštění dolů.

Zároveň zasílám up/down také po kliku na tlačítka. Zatím testuju co je pohodlnější a rozhodně je to jen kliknout a dalším klikem případně vypnout. Takže dlouhé podržení bude pravděpodobně vysunutí pergoly, které nechci, aby se spustilo jen náhodným/omylným kliknutím.

Po kliknutí na prostřední tlačítko pak posílám příkaz “plus”, kterým se přepínají scény v prvku ovládání osvětlení. Kdyby to bylo klasické tlačítko, příkaz by byl “toggle”. Bohužel se mi nepodařilo u bloky ovládání osvětlení vynutit zapnutí/vypnutí konkrétního světla, funguje mi jen přepínání scén.

Posledním prvkem v pravo je pak samotné napojení na WebSocket Loxone. V tomto prvku se nastavuje cílový miniserver, místnost/kategorie a prvek, do kterého se příkaz má poslat.

Do tohoto prvku musíte poslat příkaz, který splňuje podmínky Loxone WS. Ten jsme si připravili v předchozím kroku v prvku Exchange. Vstup vypadá například takto: msg.payload = “plus”. (Jde o obyčejný string zaslaný na cílový prvek).

A to je vše. Pokud jste postupovali podle tohoto návodu, právě jste přijali kliknutí Ikea TRÅDFRI tlačkítka přes Zigbee síť transportovanou přes MQTT protokol do NodeRED, který pak data zkonvertoval do WebSocket příkazu poslaného do Loxone. Snadné, ne? :)).

Pro případné zájemce, zde je NodeRED projekt na celou tuto logiku (stačí dát import a přes clipboard vložit):

[{"id":"c333e3da.bfcd3","type":"zigbee2mqtt-in","z":"4e77380b.b5af18","name":"","server":"4dd4dc36.2cc704","friendly_name":"IkeaButtonRound01","device_id":"0x842e14fffea3ff09","state":"0","outputAtStartup":true,"x":210,"y":240,"wires":[["20102bbc.6f9cb4","9fb1f206.7c05c"]]},{"id":"20102bbc.6f9cb4","type":"switch","z":"4e77380b.b5af18","name":"","property":"payload.action","propertyType":"msg","rules":[{"t":"eq","v":"brightness_up_click","vt":"str"},{"t":"eq","v":"brightness_up_hold","vt":"str"},{"t":"eq","v":"brightness_up_release","vt":"str"},{"t":"eq","v":"brightness_down_click","vt":"str"},{"t":"eq","v":"brightness_down_hold","vt":"str"},{"t":"eq","v":"brightness_down_release","vt":"str"},{"t":"eq","v":"toggle","vt":"str"}],"checkall":"false","repair":false,"outputs":7,"x":450,"y":240,"wires":[["be2577c2.997838"],["be2577c2.997838"],["3373d424.306ccc"],["c3e9d441.d0f198"],["c3e9d441.d0f198"],["9ce742fe.a0b25"],["97d7dcbb.f8e2a","fe05d856.cb7ef8"]],"outputLabels":["","","","","","","toggle"]},{"id":"c3e9d441.d0f198","type":"change","z":"4e77380b.b5af18","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"down","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":700,"y":200,"wires":[["f96c30e8.7c3f2"]]},{"id":"9ce742fe.a0b25","type":"change","z":"4e77380b.b5af18","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"DownOff","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":700,"y":240,"wires":[["f96c30e8.7c3f2"]]},{"id":"be2577c2.997838","type":"change","z":"4e77380b.b5af18","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"up","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":700,"y":120,"wires":[["f96c30e8.7c3f2"]]},{"id":"3373d424.306ccc","type":"change","z":"4e77380b.b5af18","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"UpOff","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":700,"y":160,"wires":[["f96c30e8.7c3f2"]]},{"id":"f96c30e8.7c3f2","type":"loxone-control-out","z":"4e77380b.b5af18","name":"","miniserver":"33d50a38.be2cc6","control":"160f9394-0337-d464-ffff3b22d8e2f329","x":910,"y":180,"wires":[]},{"id":"97d7dcbb.f8e2a","type":"change","z":"4e77380b.b5af18","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"plus","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":700,"y":280,"wires":[["38ab62ac.e8c79e","68c1752.9451b8c"]]},{"id":"38ab62ac.e8c79e","type":"loxone-control-out","z":"4e77380b.b5af18","name":"","miniserver":"33d50a38.be2cc6","control":"0e6f3276-00d7-0359-ffff01c79402a3b1","x":910,"y":280,"wires":[]},{"id":"c8d1c8cf.917108","type":"comment","z":"4e77380b.b5af18","name":"Ikea 5-ovladac pracovna","info":"","x":210,"y":80,"wires":[]},{"id":"d7dee6f.2f79718","type":"loxone-control-out","z":"4e77380b.b5af18","name":"","miniserver":"33d50a38.be2cc6","control":"160f9394-0337-d464-ffff3b22d8e2f329","x":910,"y":80,"wires":[]},{"id":"9fb1f206.7c05c","type":"debug","z":"4e77380b.b5af18","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":460,"y":360,"wires":[]},{"id":"fe05d856.cb7ef8","type":"debug","z":"4e77380b.b5af18","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":720,"y":360,"wires":[]},{"id":"68c1752.9451b8c","type":"debug","z":"4e77380b.b5af18","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":960,"y":360,"wires":[]},{"id":"4dd4dc36.2cc704","type":"zigbee2mqtt-server","z":"","name":"zigbee","host":"host-mosquitto","mqtt_port":"1883","mqtt_username":"","mqtt_password":"","tls":"","usetls":false,"base_topic":"zigbee2mqtt"},{"id":"33d50a38.be2cc6","type":"loxone-miniserver","z":"","host":"x.x.x.x","port":"80","enctype":"2","active":true,"keepalive":"30000"}]

 

ZIGBEE – NodeRED a Zigbee2MQTT

ZIGBEE – NodeRED a Zigbee2MQTT

Comments 10 comments

Jak jsem slíbil v minulém článku, dnes bude další pokračování o mé Zigbee cestě. A musím říct, že nepokračovala úplně vesele. Dost jsem se zasekl na NodeREDu, protože se vše chovalo opravdu značně náhodně.

Následující dva tři články tak budou postupně představení několika super komponent a zároveň i návod, jak řešit případné problémy. Dnes začnu s pluginem Zigbee2MQTT do NodeRED.

Zigbee2MQTT

První věc, která mi v NodeRED udělala opravdu radost, je plugin node-red-contrib-zigbee2mqtt, který je vlastně takový MQTT na steroidech.  Ten velmi usnadňuje integraci zigbee do Loxone. Je to plugin psaný přímo pro potřeby Zigbee2Mqtt bráně, takže rozumí jeho příkazům a umí tak nabídnout spoustu užitečných věcí.

Jednak nabízí pohodlné volby zařízení. Takže namísto odchytávání konkrétní MQTT zprávy si jen v comboboxu vyberete jedno ze svých zařízení (plugin se umí dotazovat Zigbee2Mqtt, takže má přehled o tom, jaké zařízení máte v Zigbee2Mqtt nakonfigurované).

Druhým benefitem je pak automatická konverze přijatých dat do Json objektu a v případě podporovaných zařízení dokonce extrakce konkrétní hodnoty z Json objektu přímo do výstupního msg.payload.

K tomu umí u každého zařízení přímo v NodeREDu ukázat stav baterie, aktuální zpracování zprávy a pár dalších zajímavých stavů. Až potud super. Kdyby vše fungovalo :).

Bohužel, v mém případě se tenhle plugin ze začátku choval tak, že zpracoval každou druhou až třetí zprávu a zbytek ignoroval. Původně jsem podezříval Xiaomi kostku, ale když to samé začly dělat i nově koupené vypínače, bylo jasno.

Zkusil jsem tedy dát vedle sebe jak tenhle Zigbee2Mqtt prvek, tak klasický MQTT. A podezření se potvrdilo. Ve výpisu nahoře jde vidět, že v MQTT je 5x přijatá zpráva a až po šesté je přijata také Zibee2Mqtt komponentou. Zkoušel jsem googlit, psal jsem na github, ale nikde jsem nenašel důvod, proč to zlobí (krom jedné zmínky v githubu, že autor používá nějakou starší mqtt komponentu interně, ale to nevypadalo na zdroj problémů).

Nakonec mě napadlo, že problém bude možná ve verzi NodeRED. Jak jsem zjistil, tak ačkoli používám Docker a oficiální NodeRED image, neměl jsem poslední verzi. Což bylo dost zvláštní.

Bohužel, inženýři z NodeRED se rozhodli pro opravdu vypečený tah. Původně se Docker container s NodeRED jmenoval nodered/node-red-docker, což jim už asi přestalo znít cool, takže repositář nechali ve staré verzi a založili nový, kde jsou další updaty. Ten se nyní jmenuje nodered/node-red. Bezva ne?

Takže pokud někdo používáte Dockerovaný NodeRED, zkontrolujte si repositáře. Dost dobře se totiž může stát, že používáte už obsolete pre-stable verzi 0.20.8 namísto aktuální 1.1.3. Po updatu na aktuální verzi a kompletní rebuild všech kontejnerů a promazání všech cachí začal i Zigbee2Mqtt plugin fungovat jak má. Tím byl vyřešen problém Zigbee2Mqtt.

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

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

Comments 27 comments

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ě:

Pushover aneb dokonalé notifikace

Pushover aneb dokonalé notifikace

Comments 20 comments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Namísto:

token=ajz8xt2fmbsnpigyyjw67xeoxuhjbx&user=xxxxxxxxxxxxx&message=HelloWorld

budeme posílat tento JSON.

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

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

V Postmanu to pak bude vypadat takto

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

Pushover v Loxone

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pushover v NodeRED

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

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

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

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

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

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

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

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

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

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

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

Netio – chytré zásuvky

Netio – chytré zásuvky

Comments 16 comments

V dnešním článku se chci podívat na první ze tří krabiček, které jsem dostal od firmy Netio k ostestování. Jsou to tři chytré zásuvky PowerCable REST, MQTT a Modbus. Jak názvy napovídají, první se ovládá pomocí REST protokolu (tzn http/https požadavky), druhá pomocí MQTT a třetí pomocí Modbus (Modbus over ethernet).

Zásuvky krom vzdáleného zapnutí/vypnutí umí měřit i aktuální zátěž, spotřebu, frekvenci a pár dalších veličin (přehled všech veličin zde).

Čeho si všimnete ihned po rozbalení je mohutnost celého provedení. Kabel má v průměru 8.5mm a je z opravdu pevého materiálu. Stejně tak obě koncovky jsou z pevného trvdého plastu a samotné pouzdro na relátka a elektroniku působí rovněž velmi bytelně.

Díky této robustnosti slibuje zařízení maximální spínaný proud 16A, tzn 3600W (celá specifikace dole na stránce zde). Už i z těchto hodnot jde vidět, že zařízení nekonkuruje levným dálkovým relé na spínání lampiček, ale cílí na spínání vysokoodběrových zařízení, jako jsou například těžební rigy, servery, elektro patrony či jiné vysokoodběrové zařízení.

Zprovoznění samotného zařízení je vcelku snadné. Při prvním zapnutí do sítě stisknete drobné malé tlačítko na krabičce (ideálně kancelářskou sponkou), čím zařízení přepnete do Wifi AP (Access point) režimu. To znamená, že zařízení začne na chvíli dělat wifi síť, na kterou se můžete připojit například pomocí mobilu a pomocí webového formuláře v něm nastvíte připojovací údaje do Vaší domácí wifi.

 

Po nakonfigurování a ověření funkčnosti wifi se pak zásuvka přepne z AP režimu zpět do jejího provozního režimu a provede připojení k Vaši síti. Od této chvíle je pak dostupná pod svou IP adresou stejně jako jakékoli jiné zařízení, co doma máte.

Po prvním připojení k zařízení doporučuji změnit heslo. Zařízení má tovární nastavení admin:admin, což nepovažuju úplně za šťastné. Vzhledem k tomu, že zařízení zná své vlastní sériové číslo (používá ho jako identifikaci AP sítě), tak by mohlo být výchozí heslo například toto sériové číslo. Tím by se alespoň částečně zamezilo případnému průniku do zařízení.

Krom změny hesla či přidání dalších uživatelů se v rozhraní nachází záložky pro nastavení aktuálního data a času, změnu wifi sítě, update firmware, různá nastavní zařízení.

Poslední záložka je pak log akcí, které zařízení provedlo. To mi přijde jako hodně dobrý nápad. Umožní to lepší hledání problému v případě, kdy se spínání nebude chovat dle očekávání.

Až po tuto část článku je vše stejné u všech tří zařízení. Všechny tři mají stejné webové rozhraní i konfiguraci a rozdíl je jen v záložce “M2M API Protocols”. Zde pak probíhá konfigurace jednotlivých protokolů.

V případě REST verze zásuvky si lze vybrat mezi XML API, JSON API a URL API. Zatímco první dvě zmíněné vyžadují sestavení ovládacího příkazu ve formě XML či JSON, třetí umožňuje ovládat zásuvku jen na základě URL adresy. Trochu nevýhoda je, že URL režim nenabízí možnost čtení stavových hodnot. V případě, kdy chce člověk číst stavy, je potřeba využít XML nebo JSON.

Druhá zásuvka ve verzi Modbus pak nabízí ovládání skrz Telnet či skrz Modbus over Ethernet.

Třetí zásuvke ve verzi MQTT pak nabízí přípojení přes MQTT-Flex nebo Netio Push. Z toho, co jsem pochopil dle dokumentace, tak MQTT-Flex je konfigurační nástavba nad MQTT, která umožní snažší nastavení ve formátu JSON, zatímco Netio-Push umožnuje periodické zasílání stavu zásuvky na uvedenou URL adresu.

Další věc, kterou musím pochválit, je dokumentace k zařízení i jednotlivým formátům. Málokdy se vidí, aby měly zařízení takto detailní a přehlednou dokumetnaci ke všemu, co zásuvky nabízí. V dokumentaci a stejně tak i ve webovém rozhraní jsou ke všem formátům i různé ukázky, jak zařízení ovládat, jak provést zapnutí, ukázka výstupního formátu, atd.

Jediné, co mi ohledně těchto tří zásuvek vrtá hlavou, je, proč jsou to vlastně tři typy, a ne jen jeden.

Ze SW pohledu si myslím, že by bylo možné nacpat všechny formáty dohromady a nechat tak uživatele, ať si formát zvolí a případně i v průběhu času změní dle potřeby. Krom tří hlavních formátů je to pak ale ještě jedna věc. Například MQTT verze umožňuje Netio-Push notifikace, což znamená periodické zasílání stavu zásuvek ve formátu Json nebo Xml.

Jenže toto umožňuje jen MQTT verze. Proč to neumožnuje i REST verze, kde v případě URL adresy by to naprosto elegantně vyřešilo chybějící možnost dotazování se na stav? Stejně tak si dovedu představit, že člověk začne na REST protokolu a později by chtěl přejít například na Modbus, což bohužel takto není možné. Pokusím se zjistit více přímo od firmy Netio.

A tím bych pro dnešek skončil. V příštím článku ukážu propojení všech tří zásuvek s Loxone. Ať už napřímo, nebo v případě JSON api či MQTT prostřednictvím NodeRED.

 

Edit:

Od firmy Netio jsem dostal možnost nabídnout slevu na případný nákup jejich zařízení. Pokud byste chtěli, zadejte kód “20procent” do nákupního formuláře k získání slevy 20% ;-).

Link na eshop https://shop.netio.eu/, sleva platí do konce ledna 2020.

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.

Představení Zigbee

Představení Zigbee

Comments 49 comments

Představte si bezdrátovou technologii, kterou lze ovládat světla, zásuvky, přijímat pomocí ní teploty, vlhkosti, kontakty oken a mnoho dalšího. Představte si technologii, kdy se spousta velkých výrobců konečně shodla na jednotném komunikačním formátu. Představte si Zigbee.

Asi takhle nějak by mohla znít reklama na Zigbee, kdyby se ovšem výrobci rozhodli, že chtějí, abyste to věděli. Jenže, věci se mají trošku jinak, a tak to nikdo takto nehlásá.

Spousta výrobců už dnes  totiž Zigbee podporuje, ale už moc nešíří, že to, co používají, je Zigbee. Každý totiž chce nabízet k jeho zařízením jen jeho vlastní bránu. A to proto, že brána pak krom samotného ovládání zařízení odesílá data o tom, jaká zařízení používáte, jak často je používáte, kolik jich máte, kde bydlíte a celkově vás takto šmíruje (a například Xiaomi gateway údajně otevírá na IPv6 protokolu dokonce root přístup pro internet do vašeho domu).

A kdo Zigbee podporuje? Například právě zmíněný Xiaomi, Philips, Osram, Ikea,… a spoustu dalších. Většinou se Vám je ale oficiální cestou nepodaří propojit mezi sebou.

Naštěstí je tu ale pak i ta neoficiální cesta. A to ta, kde si vytvoříte vlastní univerzální bránu.

Díky tomu zařízení nemohou nijak komunikovat s internetem, nikdo Vás tak nešpehuje a vy můžete připojit všechna zařízení do jedné Zigbee sítě. Takto připojená zařízení pak můžete ovládat z nějakého home-automation systému. V našem případě z Loxone.

A co teda Zigbee vlastně je a jak funguje?

Zigbee je komerční protokol, který si výrobci licencují a integrují do svých zařízení. Díky tomu pak můžete jejich světla ovládat dálkovým ovladačem, občas i mobilní aplikací. Proto Ikea může nabízet chytrá světla, Xiomi třeba čidla teploty. A nikdo z nich se nemusí starat o vývoj protokolu ani hardware nutnému k těmto funkcím.

Zigbee je bezdrátová technologie vytvořená tak, aby měla co nejmenší spotřebu. Vzduchem se přenáší jen ID zařízení a pár hodnot. A je na příjemci, aby tyto hodnoty zpracoval.

Navíc, ta zařízení, která jsou nonstop připojeny k elektrické síti, pak většinou fungují také jako opakovače, takže krom příjmu či odesílání informací ještě samy dále šíří Zigbee signál. Díky tomu lze signál dostat kamkoli po domě. Stačí pár chytrých žárovek nebo zásuvek a celý dům máte pokrytý.

A teď trochu negativ. Tím prvním je, že si to musíte zbastlit sami. Neexistuje totiž univerzální brána, která by toto vše uměla. Každý výrobce má bránu uzamčenou jen na vlastní zařízení a ovládat ji lze jen z jeho aplikace.

V praxi to tak znamená, že i když máte v domě vše zigbee, musíte stejně používat deset různých ovladačů nebo aplikací. Geniální, že ? 🙂

Takže je potřeba si koupit USB Zigbee stick, který umí přijímat a vysílat Zigbee a pak někde na RasperyPi, nebo třeba v Dockeru na NASu rozchodit Zigbee2mqtt software, který překládá Zigbee z/do MQTT transportního protokolu. A z něj pak pomocí NodeRED data překládat a posílat do Loxone a zpět z Loxone do MQTT.

Ale, není to nic hrozného. Když víte jak na to, je to vcelku snadné. Jen to chce trochu času a trochu práce :).

V současnosti mám rozběhanou Xiaomi kostku, Xiaomi teploměr s vlhkoměrem a Ikea žárovku se stmíváním.

Zatím mám vše rozchozeno v polních podmínkách na stole, ale postupně budu vše integrovat do domu. Spolu s tím budu i odstraňovat některé technologie z domu pryč.

Tou první jsou DMX Triaky. I když fungují supr, zabírájí v rozvaděči hodně místa a přijde mi zbytečné mixovat více různých technologií. Proto DMX Triaky nahradím chytrými žárovkami.

Triak stojí cca 800kč, chytrá žárovka 300kč. I když vyjde žárovka o něco dráž, ušetřím místo v rozvaděči a trochu ho zjednoduším. Takže snadná volba (pokud by někdo mé triaky chtěl, mám 3ks, z toho jeden používaný, dva zatím nezapojeny. Nechám je za 600kč za ks).

Další, co zjednoduším, budou zásuvky. OSRAM SmartPlug vypadá moc pěkně a lze ho zapojit kamkoli. Narozdíl od komplikovaného zapojování více okruhů v rámci místnosti a relátek v rozvaděči zařízení jen píchnu do hloupé zásuvky a je z ní chytrá zásuvka.

Využiju to všude tam, kde se zapínají drobné spotřebiče. Například zvlhčovačka vzduchu v ložnicích, zabiják komárů, nebo třeba vánoční osvětlení.

Co se týká čidel, tak teploměry mám pod vypínači na 1-wire a ty tam i nechám. Tam, kde ale teploměry nemám, využiju Xiaomi čidla. Například na půdě, v zahradní boudě a jinde, kde mne zajímá jaká je teplota, ale nemám tam nataženo dost kabelů, nebo by už 1-wire byl zbytečně dlouhý.

Tahle lednička za 3,000USD údajně už Zigbee podporuje (Samsung)

Věřím, že zařízeních bude do budoucna přibývat a třeba se objeví i složitejší spotřebiče, jako třeba trouba nebo lednička, která bude přes Zigbee ukazovat své stavy a půjde tím třeba i nějak ovládat. Zatím to vypadá, že výrobci Zigbee docela věří a stále přibývají jak další produkty, tak noví výrobci, kteří Zigbee podporují.

Oficiální prohlášení Loxone o Zigbee z roku 2015.

Je jen škoda, že Loxone jakožto technologie chytrého domu už delší dobu úmyslně ignoruje veškeré nové technologie jako je IoT, MQTT, Zigbe,… jen proto, aby mohlo prodávat svůj předražený LoxoneAir a tím tak zákazníky drželo ve své moci.

A to bude v dnešním představení vše. Jak vidíte, Zigbee vypadá jako nadějná technologie, nad kterou lze postavit nekritické systémy v domě a zároveň ušetřit nějaké to místo v rozdvaděči.

Článek o konfiguraci a rozchození Zigbee očekávejte záhy 🙂

PS: Pro ty co Vás to zaujalo, zatím si objednejte tyto věci na AliExpressu.

Pro výrobu Zigbee brány:

Čidla na vyzkoušení

 

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.