Dnešní článek je první ze série tří článků pro začátečníky o tom, jak propojit Loxone s externími systémy. Dnes to bude o komunikaci REST API (tzn volání URL adresy vzdáleného zařízení), příště nás pak čeká ovládání zařízení přes ModbusTCP a nakonec pak ovládání skrz MQTT (kde je nutné využít externí NodeRED na převod požadavku do MQTT formátu). Všechny tři způsoby využití budu ukazovat na chytrých zásuvkách Netio, které tyto protokoly podporují.
Pro ty, co neví, co je REST protokol, tak zjednodušeně řečeno je to volání nějaké URL adresy a zpracování takové odpovědi. Typ REST požadavku může být buď klasický GET (to je, jako když zadáte nějakou url adresu do prohlížeče), POST (což je, když se odesílá třeba formulář na webové stránce), nebo pak již konkrétnější příkazy PUT/DELETE/PATCH, které se používají při úpravách dat skrz REST protokol.
Pro naše potřeby nám bude nyní stačit GET, jelikož Netio podporuje nastavování napřímo skrz REST URL ve formátu http://IP_ADRESA/netio.cgi?pass=heslo&output1=3&delay1=2000. Pokud bychom ale například chtěli nastavovat stav nikoli přes URL, ale přes JSON či XML, využili bychom příkazu POST, pomocí kterého bychom na adresu http://IP_ADRESA/netio.json posílali JSON soubor s instrukcí pro zapnutí. Jelikož se ale v Loxonu s JSON či XML nepracuje úplně nejlépe (rozuměj téměř nijak), zůstaneme raději u mnohem snazšího URL.
Takto nějak vypadá cíl našeho dnešního snažení. Krom samotného vypínače na zapnutí a vypnutí chytré zásuvky uděláme ještě tlačítko, které na 2 sekundy zásuvku zapne a poté zase vypne.
Jako první v Loxone Configu přidáme “Virtuální výstup”, který si pojmenujeme třeba NetioREST a zadáme mu Adresu http://192.168.1.98 (pozor, adresa nesmí končit lomítkem).
Dále pak přidáme “Příkaz virtuálního výstupu” do vytvořeního virtuálního výstupu. Ten si pojmenujeme třeba OnOff a vyplníme instrukci při zapnutí a vypnutí (pozor, musí začínat lomítkem). Příkaz k zapnutí/vypnutí má formát/netio.cgi?pass=Heslo&output_CISLO_VYSTUPU=STAV_VYSTUPU (podrobná dokumentace zde).
Krom samotného on/off pak přidáme ještě druhý příkaz na zapnutí zásuvky jen na 2 sekundy. To se dělá tak, že jako stav výstupu nastavíme hodnotu 3 a přidáme parametr “delay”. Přidáme tedy další “virtuální příkaz”, pojmenujeme ho třeba “Pulse” a jako instrukci pro zapnutí dáme /netio.cgi?pass=heslo&output1=3&delay1=2000. V tomto případě nebudeme dávat instrukci pro vypnutí, jelikož o vypnutí se postará zásuvka sama.
Takto vytvořené virtuální příkazy si pak nataháme do samotného Loxone plánu, kde je propojíme s tlačítkem a vypínačem. V případě On/off necháme tlačítko v režimu “vypínač”, zatímco v případě pulzního sepnutí nastavíme režim “tlačítko”.
A takto pak vypadá samotné zapínání/vypínání přes vypínač či tlačítko.
Jak vidíte, ovládání přes REST API není nic komplikovaného. Co bohužel v případě Loxone trochu komplikované je, je správně zadat ovládací URL. Více o tom, co všechno se může pokazit a jak takové chyby odladit jsem psal v dřívějším článku “Loxone virtuální vystupy a jejich debugging”.
K dnešnímu článku mne motivovaly události posledních dnů, kdy jsem ladil můstek mezi Loxone a Quidem. Níže popsané zkušenosti jsou s původním miniserverem verze 1. U verze 2 je mnohem silnější čtyřjádrový procesor s mnohem větším množstvím paměti a tak není s výkonem ani můstkem žádný problém.
Ovšem problém je to, že Loxone diky updatům stále více a více zhoršuje výkonnost miniserveru verze 1. To, že se s každou verzí snižuje výkon o cca 1-2%, je bohužel už známý a otestovaný fakt.
Ačkoli primárně řeším výkonnost PicoC kódu, tak problém už zdaleka není jen v bloku “Program” a případně mém můstku. Problém je už také s originálními Loxone extensions, kde přestávají fungovat například dvoukliky. A bohužel, jak ukážu v dnešním článku, problém už je tak velký, že se začínají rozsynchronizovávat i stavy prvků.
A o tom chci dneska psát. Je to něco, nad čím jsem strávil poslední dva týdny několik desítek hodin.
Problém začal vcelku nevinně. Jeden z uživatelů mého můstku reportoval, že když zkusí zapnout/vypnout více relé najednou, občas nezmění stav všech relé jak by mělo. Zdálo se to jako nesmysl.
Jako první jsem tipoval chyby v UDP či chybný Quido modul. Jenže tím to nebylo. Chovalo se tak více modulů a UDP pakety po prověření ve Wiresharku chodily správně.
Tak že by chyba v programu? Vždyť můstek mezi Loxone a Quidem již používají desítky lidí a nikdo doposud problém nehlásil a to mám zprávy, že jsou i tací, co na to pověsí třeba 3x-4x 2/32 Quido modul, tzn. ovládají 128 relátek skrz můstek a bez problémů.
A tak jsem hledal dál. Dokonce jsem volal do Papoucha, povedlo se mi spojit s hlavním vývojářem Quida, se kterým jsem si opravu pěkně pokecal. Navzájem jsme si sdělili chyby, o kterých víme, dokonce mám příslib, že bude snad i slíbená změna ve firmware na zrychlení vstupů. Jenže s tímto náhodným spínáním si ani u nich nevěděli rady.
A tak jsem do můstku dodělal další logování výstupů (defaultně vypnuto), abych přesně trasoval, co se z Loxone odešle. A tady, když se udělalo víc zapnout/vypnout operací, se začaly ukazovat chyby. Loxone občas odesílal naprosto jiná data, než jaká měl vzhledem k Loxconfigu mít.
Není možné, zdálo se. Jedno tlačítko, ze kterého vede 32 propojení na 8 logických členů AND, které pak vedou na jednotlivé vstupy v programu. Jak to, že když zmáčknu tlačítko, do programu jsou nastaveny různé hodnoty, a ne vždy samé 1 či 0?
Že by chyba v programu? Nebo PicoC? A jak to, že to na verzi 8.1.11.11 nedělá? A tak jsem hledal dál.
PicoC nabízí na práci se vstupy/výstupy programu jen pár funkcí. Funkci getinputevent(), která vrátí počet změněných vstupů programu a funkci getinput(n), která vrátí stav daného vstupu.
Program samotný nedělá v tomto ohledu nic složitého. Jelikož PicoC ani Loxone neumožnuje nějaké event-driven programování, neboli čekat na to, až se něco stane, je potřeba periodicky zjišťovat, že se na vstupu něco změnilo. To se dělá jednoduše takto:
Když se něco změní, funkce jednorázově vrátí pomocí getinputevent() seznam vstupů, kde se změna stala. Když se pak zavolá tato funkce znova, vrátí zase 0 do té doby, než se změní něco dalšího.
A tady je zakopaný pes. Teda, v případě Loxone asi spíš stádo bernardýnů.
Loxone je totiž už tak pomalý, že nezvládá v reálném čase nastavit stavy z tlačítka na všechny vstupy programu. To vede k situacím, kdy celá vnitřní logika Loxone je v naprosto nesynchronních a náhodných stavech, když část vstupů je již nastavena při stisku na 1, zatímco jiná část na 0.
A v okamžiku, kdy se program zeptá, co se na vstupech změnilo, Loxone vrátí jen tu část, která již nastavena je. Ačkoli je tedy všude nastavená binární 1, Loxone vrátí náhodně 0101101001… A co je horší, když už Loxone konečně milostivě donastaví i zbylé stavy, funkce getinputevent() již tyto změny nedetekuje. Tváří se, že už žádná další změna nenastala.
Pokud by někdo z Vás začal tento problém mít, je v můstku fix. Oprava spočívá v tom, že v případě, že Loxone detekuje změnu, tak se při dalším cyklu (po 100ms) natvrdo načtou znovu všechny vstupy (i když Loxone tvrdí, že k žádné změně nedošlo) a stav všech výstupů se znovu pošle do Quida. Díky tomu se nejpozději do 100ms opraví stav všech relátek. Bohužel, oprava může způsobit delší prodlevu při rychlém zapínání a vypínání relé. Takže nastavení c_resend_all_outputs používat až jako poslední možnost.
Jak jsem ale psal, nejde jen o můstek. Toto celé totiž znamená, že pokud máte složitější Loxconfig, může se dost dobře stát, že se Vám vše začne chovat úplně náhodně. Protože namísto toho, aby hodnoty na jednotlivých blocích byly v konzistentním stavu, může se stát, že část vstupů je již aktualizována a část ne.
Výstup na AND prvku vpravo může mít hodnotu FALSE i v případě, že je tlačítko zapnuto.
V extrému si to představte třeba tak, že přenos mezi bloky nahoře (každý čára) trvá 1 sekundu. Pokud na dané cestě bude více prvků, do cílové čáry (v tomto případě AND prvek) se spodní signál dostane o 2s dřív než signál na horní cestě, který jde přes dva NOT prvky.
Jenže díky tomu, jak je už stav pomalý, Loxone vyhodnotí AND nejprve tak, že I1=false a I2=true a za další 2sekundy pak I1=true, ale I2=false (protože tlačítko není stisknuto celé 2s, ale třeba méně). Tím pádem se může stát, že v logice budete vyhodnocovat nekompletní stavy, které Vám způsobí třeba chybné topení, vypnutí kritických relátek a kdovíco ještě.
Jak jsem psal, není to problém konkrétní verze Loxconfigu. Je to problém všech nových verzí Loxconfigu. Každá verze více a více zpomaluje Váš miniserver. Pro srovnání. Verze 8.1.11.11 zvládne v PicoC odbavit stovky událostí za sekundu. Ten stejný program nasazený na poslední verzi Loxconfigu (aktuálně 10.3.11.27) jich zvládne 1.5/sekundu. Ano, jeden a půl!.
Bohužel, na toto nemáte téměř šanci přijít. Když se Vám začnou věci chovat divně, těžko budete předpokládat, že je to způsobeno tím, že už je Loxone tak pomalý, že nezvládá ani elementární věci, jako je nastavování stavů prvků.
Dobře si proto rozmyslete, jestli opravdu potřebujete každou další zpackanou verzi, kterou Loxone vydá. Každá další verze totiž znamená, že se Vám celý Váš dům více a více zpomaluje. A nejde jen o to, jestli používáte můj můstek mezi Loxone a Quidem. To stejné se týká Vás, kdo používáte třeba dvouklik tlačítka na originálních Loxone komponentách (což je vcelku elementární věc), nebo třeba těch z Vás, kdo máte složitější Loxplany.
PS: Všechny výše uvedené změny jsou již dostupné v nové verzi můstku (verze v17). Verze je jako vždy ke stažení v Dropboxu.
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 :).
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).
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í.
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:
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.
Původně měl být dnešní článek o integraci služby Pushover s Loxone. Služba pushover umožnuje zasílat notifikace na libovolné zařízení (mobil/desktop) z libovolných služeb a aplikací. Jenže, jak už je u Loxone zvykem, ani toto se neobešlo bez několika hodin testování a ladění. Takže to bude zase jeden z dalších “Miluji Loxone – nesnáším Loxone” článků.
Článek totiž bude o celé té několikahodinové cestě, kdy jsem hledal, proč zas Loxone nefunguje tak, jak by člověk očekával. A když už sem s tím bojoval, přišlo mi to zajímavé na sepsání i pro ostatní. A tak tento článek bude nejen o tom, jak je s Loxone občas složité pořízení, ale hlavně o tom, jaké nástroje a programy použít, abyste tyto problémy dokázali vyřešit.
Ukážu, jak ladit virtuální http výstupy, na co si dát při jejich použití pozor a jak otestovat, jestli je chyba u Vás nebo v Loxone. A o Pushover notifikacích bude až další článek.
Co byste měli jako první při vytváření HTTP virtuálního výstupu otestovat je, zda máte vlastně správně cílovou URL a parametry. Úplně nejjednodušší je vyzkoušet to přes command-line příkaz curl.
S curl je to sice rychlé, ale občas může být příprava takového příkazu trochu složitější. A tak je lepší použít něco sofistikovanějšího, jako například Postman (aplikace je zdarma).
V Postmanu si můžete snadno připravit celý cílový request, spustit ho a vidět i pěkně naformátovanou odezvu na takový požadavek. Na obrázku nahoře jde vidět request do Pushoveru.
Postman toho umí mnohem víc než jen odesílat požadavky. Můžete si takové požadavky ukládat a zpětně se k nim vracet, dělat si kolekce příkazů, umožňuje dokonce automatické testovaní nad takovými požadavaky, atd. Já sám tam mám takto uložené všechny možné API requesty, takže když se po čase potřebuji k něčemu vrátit, hned vidím, jak mají požadavky vypadat.
V okamžiku, kdy máte dotaz otestovaný přes Postmana, přichází ta pekelná část. Rozchodit to v Loxone. A tak vytvoříte virtuální výstup a začnete zadávat. První pokus, do kolonky pojmenované “adresa” zadáte url adresu a ono se nic neděje. Loxone žádnou chybu neukáže, ale ani se nic nestane. Co teď? (konkrétní důvod této chyby je, že v kolonce adresa nesmí být adresa. Logické ne? Musí tam být jen protokol + server, tzn správně je https://api.pushover.net).
Předtím, než ukážu, jak přesně takovéhle chyby ladit, ukážu ještě jednu chybu, se kterou Vás Loxone obšťastní. Pokud totiž zadáte adresu serveru zakončenou lomítkem, můžete se jít také zahrabat. Opět se nic nestane, nebude nic fungovat, ale žádnou chybu Vám Loxone neukáže. Jediná správná varianta je správně je https://api.pushover.net
Tak, ale teď už k samotnému lazení. Snažíte se volat službu, u které nevíte, jestli jede správně, a snažíte se to volat z Loxone, kde víte, že bude určitě nějaký zádrhel. Řešením je použít službu, která Vám přesně ukáže, co (a jestli vůbec) z Loxone něco odchází. Tou službou je například https://requestbin.com/.
Na hlavní stránce si založte “Request bin”, pro který dostanete unikatání URL adresu, například https://enn9obu94ky0s.x.pipedream.net. Na tuto adresu nyní můžete nasměrovat výstup z Loxone a kdykoli něco Loxone odešle, vy uvidíte přesný tvar toho, co z něj vylezlo 🙂
Tím si jednak otestujete, že vlastně vůbec něco leze (což v případě prvních dvou ukázek špatně zadané url se vůbec neděje) a dále si ověříte, zda posílá data tak, jak jste si mysleli (což se také dost často neděje). Ukažme si to na příkladu.
Zajímalo Vás například někdy, co znamená “HTTP rozšíření při zapnutí” ? Nebo si nejste jisti tím, co znamená “Instrukce při zapnutí”? Nebo jak se odešle “Post příkaz při zapnutí”? Tak přesně k tomu je dobrý RequestBin (protože od specialistů z Loxone se v aplikaci ani dokumentaci nic kloudného nedozvíte).
Zde pak vidíte, co vlastně takto nakonfigurovaný výstup odešle. Najednou je jasné, že “HTTP rozšíření” jsou vlastně HTTP hlavičky (by je asi zabilo, kdyby to tam napsali), že POST příkaz se odešle jako POST s “náhodným” Content-type text/xml a že instrukce je URI adresa připojená za protokol+server zadaný u virtuálního výstupu. Zde máte zároveň také možnost zjistit, že například instrukce pro zapnutí MUSÍ začínat lomítkem, jinak se opět nic neodešle (protože pro Loxone je problém toto lomítko v případe absence doplnit).
Bohužel, v této ukázce pak vězí ještě jeden zakopaný pes. A tím je právě Content-Type. Ačkoli Vám Loxone umožní zadávat hlavičky, pokud zadáte Content-Type:application/json, tak ho Loxone vesele ignoruje. To Vás ale bohužel přivádí do míst, kam ani slunce nesvítí.
Ačkoli je do “HTTP rozšíření při zapnutí” aka HTTP hlaviček zadán “Content-type:application/json” a ačkoli je v POST příkazu zadán validní JSON příkaz, ta zelená věc zvaná Miniserver to odešle jako text/xml. No není to roztomilé? Je to roztomilé. A díky tomu Vám Pushover prostě fungovat nebude. A dost se divím, že člověk ještě nedostane od Pushoveru BAN za to, že je idiot :).
Ale tím stále nekončíme. Po hodině googlování a testování jsem najednou zjistil, že jsem schopný z Loxone odeslat příkaz v požadovaném content-type. Ptáte se jak? Nejprve se vrátím k curl. Jak vidíte, toto je odeslání stejného požadavku, o které se také snažím z Loxone. A jak vidíte, Content-type je zadán přesně tak, jako v Loxone. A jak můžete vidět na dalším obrázku, pokud to odešlu z curl, do RequestBINu to přijde v pořádku.
A nyní, screenshot z Loxone, kde už najednou příkaz zázračně funguje:
Vidíte ten markantní rozdíl? Vidíte, proč to najednou funguje? Že ne? Nedivím se Vám :). Důvodem je MEZERA za dvoujtečkou u content-type. Ačkoli nic takového dle standardu není potřeba a ačkoli to ani curl, ani postman nevyžaduje, u Loxonu to potřeba je. Pokud uděláte za dvoutečku mezeru, najednou Vám do RequestBinu začne chodit toto:
To je pecka, co? Přišel jsem na to jen díky uplné náhodě, že jsem testoval jiný problém, a tím je poslání více hlaviček. Narazil jsem na loxforu na tuto ukázku,
HTTP extensions for ON : host: 192.168.0.226\r\nContent-Type: application/json
HTTP POST command for ON : {“on”: true}
HTTP method for ON : PUT
same for OFF…
kde psali, že jim to jede a tak jsem začal zjišťovat, kde je zakopán pes. A to mě přivedlo k té mezeře. Takže, content type se odesílá, data se odesílají, jenže Pushover stále nejede.
Všechno už sedí 1:1 mezi Loxone i Postmanem a Loxone stále neodesílá. Je teda čas na hardcore-debugging. Přesunuju se i s notebookem do technické a připojuju se do fyzicky izolované sítě s Loxone (a Quidem). Pomoci Loxconfigu -> Diagnostika -> Debug-Info -> Síť – začínám odchytávat síťové pakety.
Výsledek na sebe nenechá dlouho čekat. Po odeslání požadavku na https://api.pushover.net z nějakého záhadného důvodu nefunguje SSL. A ačkoli na RequestBinu je rovněž https a tam to jede, takže asi zase nějaká specialita Loxonu. Naštěstí má pushover i http verzi, která sice není extra bezpečná (protože lze odchytit co za zprávy na ni budu posílat), ale na obecné notifikace typu “dveře otevřeny” mi to nevadí. Pokud by to byl problém, řešením by bylo přeposílat to přes NodeRED, který by přijal text a udělal z něj https Pushover notifikaci. Uvidíme, možná v příštím článku ukážu oba postupy.
A to je pro dnešek vše. Krásné čtyři hodiny strávené s Loxone jen proto, že nemají pořádné logy, neumějí pořádně notifikovat chyby a neumí si poradit ani se základní validací parametrů v Loxconfigu. Bomba.
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:
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.
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.
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.
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.
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:
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 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í).
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é.
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.
Jsou to dva rouky a fous, co jsme se nastěhovali do našeho domu. Chytrého a pasivního. A protože mám teď díky nemoci trochu času, rozhodl jsem se udělat sumarizaci a popsat naše zkušeností s chytrým domem, zhodnotit, co smysl mělo, co ne, co využíváme a co nikoli.
Hned z kraje řeknu, že chytrý dům je supr. Myslím, že každý, kdo to zkusí, už nebude chtít jinak. Na druhou stranu, je spousta věcí, které člověk musí při stavbě rozhodnout, aniž by věděl, jaké to vlastně bude. Do toho jsou jeho rozhodnutí ovlivňována mnoha směry, jak už cenou, zužujícími se financemi, nebo na druhé straně třeba Loxone partnerem, který Vás bude tlačit někam, kde je to výhodnější víc pro něj, než pro Vás.
Zároveň bych chtěl hned úvodem upozorňit, že zde prezentuju svůj vlastní názor, nikoli názor všech uživatelů chytrých domů. Určitě jsme v mnoha ohledech atypičtí, takže si z toho vemte jen to, co sedí na Vaše podmínky :). Takže, pojdmě na to.
Světla
Obrázek převzat ze stránek Loxone a jejich prezentace světel v domě
Začnu světly, protože to je takové dnešní synonymum chytrých domů. Bohužel. Namísto, aby se upřednostňovaly důležité věci, se na reklamní letáky cpou cool osvícené místnosti v různých barvách, intenzitách světla, světelných scénách atd.
My jsme zjistili, že je to pro nás zbytečné. Měl jsem v domě spoustu dimmerů, které umožňovaly nastavovat různé úrovně osvětlení. Ty jsem pak vyměnil za triaky, které to umí mnohem levněji než Loxone dimmer. A víte co, stejně to vůbec nevyužíváme. Když máme hlavní osvětlení, je tam proto, aby svítilo. Za celou dobu jsme nenašli moc případů, kdy jsme chtěli v obýváku nebo kuchyni ztlumit hlavní světlo.
Jasně, trochu se to hodilo chvíli v pokoji prcka, když jsme tam potřebovali mít jen trochu rozsvíceno, aby ho to nebudilo. Jenže, stejnou službu (a spíše lepší službu) udělá rozsvícené světlo na chodbě, které mu nesvítí přímo v pokoji.
A pak v koupelně. Když jdeme večer do koupelny, nechceme, aby svítilo světlo moc a nevzbudilo malého. Jenže, i to jsme nakonec vyřešili dočasnou slabou žárovkou, než dvěma úrovněma světel.
O barevných scénách nemluvě. Na letáku a v designovém domě to vypadá pěkně. Ale v domě s dětma, kdy potřebujete buď světla spousta, nebo tmu, je to k ničemu. Nemít děti a psa, pořádat párty jako na kolejích, asi bych světelné scény užil. Ale takto, vůbec. A tak moje DMX v rozvaděči zeje prázdnotou.
Je to asi dané i tím, že netrávíme žádný čas večer u televize a obyváku, že po večerech neholdujeme večírkům a návštěvám. Pak by se to asi využilo.
Každopádně, za mne doporučení. Nenechte si vnutit tunu DMX led pásků, ztlumovačů světel a dalších blbostí, co stojí hromadu peněz. Dodělat se to dá vždy a na začátku dost ušetříte, když si uděláte jen přípravu a technologii nenakoupíte. (navíc díky Zigbee technologii to půjde ještě snadněji, ale o tom níže).
Zásuvky
OSRAM Smart+ PLUG
Další oblíbený reklamní tah Loxone a jejich partnerů jsou chytré zásuvky. Udělat vše vypínací. Je to cool, je to super bezpečné, stoprocentně to využijete. Leda prd.
Naštěstí jsme odolali a zásuvek s přímým vypínáním udělali jen pár. Máme je na pračku a sušičku a venkovní zásuvky. Původně nám bylo doporučeno i vše v kuchyni, ideálně i ostatní technologie, v každém pokoji vypínatelný okruh, …
Blbost. Vymyslet systém, kdy se vám bude při odchodu z domu něco vypínat a něco ne je šíleně komplikované. Budete muset rozlišovat zásuvky, řešit jestli můžete zamknout, když zrovna perete, sušíte nebo vaříte.
Pračka se sušičkou nakonec zůstává neustále zapnutá. Stejně většinou nepereme když tu nejsme a když jo, má to nějaký důvod. A tak jsme ze začátku používali dálkové vypínání jen v případech, kdy sušičká pípala a my chtěli v klidu dokoukat film :).
Jak prcek vyrostl, využili jsme to ještě k jedné věci. Prcek s oblibou mačká tlačítka, jelikož ví, že se sušička i pračka rozsvítí. A tak jsme naprogramovali jedno z tlačítek v koupelně, aby oba spotřebiče klikem vyplo či zaplo. Na toto je to supr.
Jenže, toto se dá opět vyřešit jinak. Pomocí Zigbee protokolu se již dělají chytré zásuvky, které za cenu 400kč můžete píchnout do kterékoli jiné zásuvky a udělat ji chytrou. Namísto pracného tahání samostatných kabelů ke každému spotřebiči, samostatných relé v rozvaděči.
Jasně, někde to relé dává smysl (ta pračka je asi lepší na relé v rozvaděči), ale i to se dá připravit chytře. Namísto CYKY 3X2.5 natahejte CYKY 4×2.5. Tím budete mít do každého zásuvkuvého okruhu natažený o drát víc a když bude potřeba, použijete ho v budoucnu na spínání. A není potřeba to na začátek zbytečně hrotit (tenhle nápad není původem můj, ale od jednoho uživatele z diskuzního fóra).
Tlačítka a vypínače
Tady se jedná zase o opačný extrém. Loxone partneři i Loxone samotný se Vás bude snažit přesvědčit, že v domě stačí jen pár tlačítek, protože je přece inteligentní. A když budete potřebovat, máte přece mobilní aplikaci. Zase blbost.
Dám příklad na našich žaluziích. Máme obyváko-jídelno-kuchyň, kde máme 1x východní, 2x jižní a 1x západní žaluzii. Prý stačí jeden ovladač u vchodu do místnosti a tím budu ovládat všechny žaluzie. O zbytek se postará chytrý dům.
Ještě že jsme neposlechli!
Automatika žaluzií jé úžasná věc a nikdy nebudete chtít jinak. Každý den ráno se otevřou všechny žaluzie a funguje to jako budík. K večeru se zatáhnou a večer pak úplně uzavřou. Když je dům v zimním režimu, tak se žaluzie samy přes den vytáhnou, pokud slunce svítí víc než XY luxů. A v létě naopak zatáhou, aby se dům nepřehřál.
A to je opravdu super. Jenže, pak tu máte situace, kdy chcete vyjít na terasu jen jednou žaluzií a ostatní nechat zatáhlé. Nebo potřebujete pustit psa, protože se rozhodl vrátit domů zrovna tímhle oknem. Nebo nastavit jednu žaluzii více otevřenou, aby bylo doma více světla. atd.
Poslechnout Loxone partnera, musel bych na vše brát mobil. Naštěstí, trval jsem na svém. U hlavního vchodu do místnosti jsou dvě žaluziové tlačítka. Jedno ovládá všechny žaluzie. To když chci narychlo vše zatáhnout nebo třeba ráno otevřít, když vstáváme dřív než se dům probudí. A pak druhé tlačítko, které ovládá nejčastěji využívanou žaluzii u HS portálu. A dále pak u každého okna je samostatné tlačítko, které ovládá danou žaluzii.
Nebylo by větší pakárny, než chtít jit nějakým oknem a muset se vrátit na druhou stranu místnosti a tam si to otevřít, případně neustále lovit mobil. A stejně tak to máme v pracovně, kde je rovněž více žaluzíí. Zkrátka, u každých dvěří tlačítko na žaluzie a pak u vchodu do místnosti hlavní tlačítko. Pro nás ideál.
A to stejné je se světly. Nenechte si namluvit, že stačí jedno tlačitko na všechna světla. Že není správné ovládat každé světlo, ale přepínat scény. Že přeci naprogramujete scénu přes více světel a dům udělá vše ostatní.
Že klikem jedete scény, dvouklikem se vracíte, tříklikem vše zhasnete. Je to blbost. Krom toho, že se přepínání po scénách ovládá fakt blbě a stejně nikdy nebudete mít všechny kombinace, tak Vás za to bude chtít ještě Vaše žena zabít.
A nejde jen o scény místo rozsvěcení světel. Jde i o ty dvoukliky, trojkliky, držení nebo rychlé klikání a podobně. Není totiž nic horšího, než když Vaše žena místo trojkliku v noci udělá dvouklik a klik. Takže místo nočního osvícení rozsvítila celou chodbu oběma hlavníma světlama a tím vzbudila tenkrát naší jen měsíc starou ratolest.
To fakt nechcete. Dotáhnětě si raději o jeden FTP kabel k vypínačům více a dejte si tam o tlačiíko víc. Každá běžná funkce, ať je dostupná na jeden klik. Nevymýšlejte žádnou divočinu a hlavně, mějte to v celém domě jednotně.
Okenní kontakty
Další téma, kde se zřejmě s většinou Loxone partnerů neshodnu. Když jsem řekl, že chci každé okno zvlášť, koukal na mne ten můj jako na blázna. Proč potřebuju 15 samostatných informací, stačí přeci vědět, že je nějaké okno otevřené. Zbytek si ověříte vizuálně sami. Blbost.
Zaprvé, chci vědět které okno to je, aniž bych musel obejít celý dům. Co je ale důležitější, když máte info o každém okně zvlášť, dá se s tím dále čarovat. Například, když je léto, sedíte na terase a máte otevřené dveře na terasu, dost naštvě, když se vám po setmění žaluzie zavřou. Navíc, když třeba ani nemáte mobil u sebe :).
Když máte okenní kontakt, každé dveře blokují svou žaluzii a tím ji nedovolí stáhnout. Prosté, jednoduché elegantní. Ale toto Vám Loxone banda neporadí.
Jediné, co oni na tom vidí (když už si to sám vymyslíte), že bude 15 vstupů a tím pádem 2 extensiony. Ale i tam se pletou. Přesně proto jsem totiž tenkrát začal řešit Quido se 100 vstupy. Abych nemusel platit majlant Loxonu.
Elektroměry
Další ukázkou z pohledu Loxone zbytečné technologie jsou prý elektroměry. Proč měřit spotřebu každé místnosti či spotřebiče zvlášť. Vidíte přeci spotřebu celého domu. Nesmysl.
Za cenu 250kč můžete měřit každý okruh a tím hlídat spotřebiče. Odjedete pryč a Vaše žena neví, jestli vypla troubu, desku, žehličku? Namísto vracení se domů se podíváte na elektroměr daného spotřebiče či okruhu. Nevíte, jestli Vám už neodchází mrazák? Podíváte se na jeho průměrnou spotřebu a hned vidíte. Nevíte, kolik žere Váš nový spotřebič (třeba nová zvlhčovačka)? Nevíte, kolik třeba právě sežrala samoočistná procedura trouby, která ji rozehřála na bambilión stupňu a zuhelnatila veškeré nečistoty? Podíváte se na spotřebu dané místnosti (a zjistíte, že se trouba sama vyčistila za cca 5kč).
Jasně, měření se dá udělat ručně pomocí bazmektu za 300 Kč z Bauhausu. Jenže, nemáte srovnání s dřívějším stavem, nevidíte spotřebu na dálku a co si budeme vykládat, je to dost nepohodlné lézt třeba za linku a měřit spotřebu trouby. Takto za pár korun máte klid a přehled. A stačí k tomu elektroměr za pár korun a odpovídající množství vstupů, které opět můžete vyřešit Quidem.
Je pravda, že relé samo o sobě Vám spotřebič v případě zapnutí nevypne. Jenže, to byste museli mít relé na úplně vše v domě. A tohle relé pak bude 5 let ve stavu sepnutém, protože těžko ho budete jen tak z hecu vypínat a zapínat, když Vám to vymaže hodiny na spotřebiči. A co myslíte, když po pěti letech najednou budete potřebovat tohle relé rozpojit. Vsadíte si na to, že se to povede? To je lepší zavolat sousedům, kamarádům nebo rodině, na dálku jim odemkout Váš dům a poprosit je o vypnutí.
Teplotní, vlhkostní a jakákoli jiná čidla
SedTronic 1-wire moduly do vypinacu Unica
Další věcí jsou čidla všeho druhy. Podle Loxone partnera prý zbytečnost a co jsem s ním mluvil naposledy, říkal, že už to lidem prý úplně rozmlouvá. Že prý 20 údajů teplot, vlhkostí a dalších čísel z celého domu je zbytečnost, že se v tom ztrácí a nezajímá ho to.
Opět jsem jiného názoru. Za pár korun lze umístit teplotní senzor pod každý vypínač a co jsme třeba my podcenili, za dalších pár korun lze umístit senzor do každé mísnosti do podlahy (máme jen v koupelně).
Naštěstí díky koupelnovému senzoru, kde je také dlažba, můžeme alespoň odhadovat teploty ostatních podlahových ploch. A díky tomu na jaře a podzim přitápíme v chodbách podlahu. Aby byla příjemná na chůzi bez bačkor (nesnáším bačkory) a přitom to nepřehřívalo místnost. Když klesne teplota podlahy, chvilku ji nahřejeme. Za pár korun, ale komfort maximální.
Stejně tak čidla v místnostech. Jen díky tomu můžete optimalizovaně nastavit otvírání a zavírání žaluzií v zimě. Když nebudete vědět jak moc se místost ohřívá, děláte to naslepo. Ale když máte grafy, lépe se celý barák nastavuje do optimální polohy.
Naopak, je blbost si myslet, že budete regulovat teplotu v každé místnosti v pasivním domě. Pasivní dům se chová jako celek a díky VPC se teplota stejně rozprostře přes celý dům. Jediné okruhy, které využívám na zavření a otevření jsou právě zmíněné chodby, kde je dlažba. A pak v pracovně, kde se přes noc přitápí a přes den, kdy tam běží počítače vůbec netopí, jelikož tam bylo zbytečně horko.
Moje doporučení, nenechte si rozmluvit čidla po domě. I kdybyste se na to podívali jen párkrát za rok, je fajn vidět, na kolik Vám dům vytopilo slunce, jak rychle se dům ochlazuje, když v něm nejste, jak rychle se naopak vytápí tepelným čerpadlem, atd.
Multiroom Audio
Loxone music server
Další super-cool funkce, kterou Vám bude chtít Loxone nacpat. Jejich multiroom hudební server za bambilión je toho důvodem. Sám jsem měl vizi, že si multiroom hudbu udělám a nějakou přípravu na to mám udělanou. Nikdy jsem ale neplánoval na to použít Loxone komponenty.
Realita je ale taková, že to pravěpodobně nikdy nezrealizuju. Je to asi dobré, pokud opět máte tu krásnou designovou vilu, kterou Vám neboří Vaše ratolesti, ale bydlíte v ní sám, maximálně s nějakou milenkou a máte ji na párty. Pak je super si přes celý dům pustit jednu hudbu, udělat si k tomu designové osvětlení a užívat si krásné chvilky.
Bohužel, nevím jak vy, ale u nás to tak není. V obyváku běží prasátko Pepina, žena pracuje většinou bez hudby v kuchyni tak, aby dohlédla na prcka a já si do sluchátek pouštím Linkin Park, abych přebil ten občasný řev a mohl se soustředit na práci. Když je večer, pouštíme potichu cokoli, abychom malého satana nevzbudili. A když je pryč, pracujeme oba v pracovně a hudba nám stačí tam. Je jen málo situací, kdy bych si pustil hudbu přes celý dům.
Regulace a ovládání technologií v domě
Schéma řízení tepelného čerpadla dle vstupů čidel a interního programu
Něco, co je z mého pohledu jedno z největších přínosů chytrého domu, ale zároveň něco, co vlastně Loxone moc nepropaguje a partnerům se do toho moc nechce. Není to totiž sexy, dá to dost práce, není na tom žádná marže a musí se to umět. Ale, výsledek stojí za to.
Díky chytrému domu můžete naprogramovat cokoli. A vytápění je jedno z míst, které z toho může těžit nejvíce.
V každé místnosti máte tepelná čidla, víte, jestli je jaro, léto, podzim nebo zima. Víte, kolik chcete v domě mít stupňů, kolik by měla mít podlaha. A z tohodle všeho pak naše logika posílá řídící signály čerpadlu, aby dělalo přesně to, co chceme a nejelo jen na automatiku. Ovládá oběhová čerpadla podlahovky, když je dlažba studená, předává do něj průměrné teploty z relevantních místností, takže topí jen, když je zima v celém domě a ne jen v jedné místnosti, kde se třeba zrovna vyvětralo, ale jak napotvoru tam bylo vyvedeno čidlo z TČ.
Například v období, kdy ještě nemrzne, ale není už teplo, pak reguluju teplotu ne podle teploty místnosti, ale podlahy. Řídím to tak, že teplota vratné vody do TČ musí být XY. Takže udržuju beton a anhydrid nahřátý tak, aby místnost úplně nevychladla, kdyby se hodně ochladilo, ale zároveň se mi místnost nepřehřeje, když vyleze slunce.
A takových vychytávek se dá vyjmenouvat spousta. A pro každý dům to bude trochu jinak. Ale abyste je mohli realizovat, potřebujete vstupní data. Teploty místností, teploty podlahy, úroveň svítu slunce, větru,…
Takže moje doporučení, nenechte si rozmluvit, že nepotřebujete čidla v každé mísnosti. Čím víc čidel, tím víc souvislostí můžete najít a řídit.
Regulace okolí domu
Další velké uplatnění chytrého domu je regulace technologíí kolem domu. Například závlaha trávníku. Díky čidlům deště dům ví, kdy pršelo a kdy ne a podle toho zalévá trávník. K tomu čidlo množství vody v rentenční nádrži (ještě nemám namontováno, jen nakoupeno) a podle toho zalévá buď z retenčky, nebo z řadu.
Kromě trávníku samozřejmě také živý plot, truhlíky, záhony. Každý okruh může mít jiná pravidla, nepršelo dlouho? Zalít brest jednou týdně o něco déle. V záhonech mít třeba rozdílné zalévání dle růstového období. Nebo přidat přímo senzor vlhkosti půdy a zalévat podle toho.
Zkrátka, možnosti jsou obrovské. Jde jen o to si to vymyslet, mít dostatek senzorů a podle nich pak vše řídit.
Variabilita
Další obrovský benefit, který se moc v souvislosti s chytrými domy nezmiňuje. Dům plánujete, když Vám je X, možná ještě nemáte děti a máte nějakou vizi o Vašem životě. Než dům dostavíte, je Vám většinou X+2, spíš X+3. 3 roky jsou dlouhá doba a hodně se může změnit. Za nějakou dobu najednou budete mít děti. Nejprve malé, pak větší, pak puberťáky. A pak najednou bude v baráku klid, protože konečně šli do světa.
A tohle všechno byste měli zohlednit v době, kdy kreslíte Váš dům na papír, což je nereálné. Nevíte, co bude za technologie, nevíte, jaké budou mít děti potřeby. Můžou to být drobnosti, ale taky zásadní věci. A chytrý dům Vám umožní se tomu přizpůsobovat.
Máte prcka a nechcete rozsvěcet noční osvětlení,? Ok, přenastavíte dům. Chcete jedním kliknutím z ložnice zhasnou nebo rozsvítit prckovi lampičku, ok, nastavíte to tak. Potřebujete vypínat zásuvky u pračky, protože Vaše ratolesti se rozhodly pračku a sušičku přeprogravat na vesmírnou loď? Není problém. Chcete ratolesti budit žaluziema v jiný čas než Vás? Ok, lze nastavit.
A takových případů je milión. Jak budete postupovat Vašima životníma etapama, tak budete dům uzpůsobovat. A časem třeba konečeně přijde hlasové ovládání, tak ho do domu přidáte. Stejně tak můžete upravit tlačítka, použít k ovládání gyroskopické kostky (ty už mám objednané a hodně se na ně těšíme), atd. atd.
Zigbee
V nějakém dalším článku pak představím technologii Zigbee. Je to bezdrátový protokol, který využávají například čidla od Xiaomi, nebo žárovky a vybavení od Ikea, Philips a mnoho dalších. Díky jednotnému standardu tak není potřeba využívat děravých gateway (bran) od výrobců, ale lze vyrobit vlastní, uzavřenou, která bude se vším jednotně komunikovat.
Přes Zigbee lze například nastavovat jas žárovky, takže stačí ke světlům přivést jen 230V a jas se pak nastaví vzduchem. Stejně tak spínané zásuvky, nebo dodatečné teplotní a vlhkostní čidla. Nebo bezdrátová a bezdotyková tlačítka na Vašem pracovním stole na rozsvícení světla v místnosti. Opět, variabilita ohromná a bude záležet jen na tom, co člověk bude časem potřebovat.
Závěrem
Jak vidíte, je toho hodně. Dalo by se psát asi ještě další hodiny, ale myslím, že to hlavní jsem vystihl. Samozřejmě, že někdo možná podotkne, že všechno tohle jsou blbiny, bez kterých se dá normálně žít. Dá. Ale my nechceme stát 2 minuty u jednoho okna držíce tlačítko, abychom stáhli žaluzii a pak jít na další okno. Náš čas chceme využít smysluplněji.
V souhrnu jsme s domem opravdu spokojeni. Jsou holt jen věci, co jsme dělali zbytečně, nebo co jsme třeba podcenili. Jsou to ale naštěstí jen maličkosti a většina šla nebo půjde dodělat za pochodu.
Bohužel, stejně jako u ostatních věcí kolem stavby domu platí, že to, co během stavby uděláte za jednu jednotku času, po nastěhování budete dělat nejméně desetkrát déle :). Takže jestli můžu radit, udělejte toho co nejvíc před nastěhováním.
A to už bude opravdu vše. Pokud máte jakékoli jiné postřehy z využívání Vašeho domu, pište je dolu do komentářů!
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.
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.
Když jsem včera psal o tom, jak jsem přes zimu krásně nezvládl pohnout s žádnou elektronikou, úplně jsem zapoměl na jeden drobný úspěch.
Před nějakým časem se mi ozval jeden čtenář blogu, že spolu s kolegou navrhl a vyrobil zařízení Swifitch. On sám pak byl s náma i na minulém Loxone srazu, takže ho pár z Vás už i zná (především po jeho prezentaci, jak monitorovat přítomnost bluetooth na detekci blížící se manželky domů :)).
Zařízení samotné je takové wifi-relátko. Něco jako komerční sonoff, ale s důrazem na vyšší bezpečnost a nižší cenu :). Ačkoli sám razím teorii, že veškerá technologie má být v rozvaděči přes který je vše ovládáno, občas to prostě nejde. Nemluvím tu teď o hlavních světlech, žaluziích a dalších zařízeních, se kterýma člověk počítá už při stavbě. Spíše jde o ty drobné věci, které se třeba i s ročním nebo životním obdobím mění.
Například vánoční stromeček, osvětlení v okně, osvětlení prcka v pokoji nebo zvlhčovačka v ložnici. Prostě cokoli, co potřebujete automaticky zapínat a vypínat. Jasně, můžete mít každou zásuvku zvlášť ovládanou přes relé, ale je to většinou ekonomický nesmysl. Jenže pak nastanou chvíle, kdy by se to tak hodilo….
A na tyhle chvíle je tu zařízení Swifitch. Přivedete do něj 230V a ono se z něj jak samo napájí, tak přes wifi spíná výstupní 230V relé.
Konkrétně třeba ta zvlhčovačka v ložnici. Přes zimu máme dost suchý vzduch, ale pouštět zvhlčovačku každý den ručně je opruz. Navíc pak zbytečně běží až do rána, což je většinou zbytečné. Takže jsem použil Swifitch a přes Loxone naprogramoval automatické spouštění a vypínání. Krásné a elegantní řešení.
Navíc, swifitch si můžete postavit sami doma. Za pár korun (konkrétně cca 250kč), trochu času a šikovnosti máte supr zařízení na spínání čehokoli. Navíc se tím hezky procvičíte v pájení :)).
Já osobně jsem si z Aliexpressu a Seedstudia objednal materiál na 20ks. Je totiž skoro jedno, jestli objednáte 1ks, 10ks, nebo 20ks. Cenově vyjde výroba plošňáku + poštovné hodně podobně. A když už jsem se do toho tak opřel, rozhodl jsem se i vylepšit si pájecí stanici.
Na aliexpressu jsem objednal tuto . Cenově i s poštovným vyšla na 70USD a v čechách byla za týden. A musím říct, je fakt supr. Krom klasického pájení a možnosti nastavení přesné teploty má horký vzduch, který nepotřebujete, dokud ho nemáte. Jakmile ale jednou okusíte, tak nebudete chtít jinak. Super se s tím zatahujou izolační bužírky, opravují špatně připájené kontakty, nebo sundavají komponenty i celé čipy (například ESP čip z Wemos D1 desky).
Krom výše uvedeného je pak horký vzduch super na pájecí pastu. Nanesete pájeci pastu, ohřejete ji vzduchem a máte připájeny všechny kontakty krásně a čistě. S tím se teprve učím, ale je to jen o správném množství pasty a tepla.
Samotná výroba Swifitche je celkem snadná, objednáte plošnák a podle návodu ho osadíte komponentama. K naprogramování ESP čipu pak lze využít buď kontaktů přímo na plošnáku, nebo si z Wemos desky (ze které předtím sundáte ESP čip) uděláte programátor. Touto cestou jsem šel já.
A takhle pak vypadala moje první deska zkompletovaného swifitche. Pájení sice není na jedničku s hvězdičkou, ale já byl spokojen. A čím více jich vyrobíte, tím lepší to bude. Tady se musím zmínit o zajímavé chybě, kterou jsem během pájení udělal a kterou nebýt autora jsem zřejmě nevyřešil.
Na téhle fotce vidíte vedle sebe můj modrý a autorův červený plošňák. Jak můžete vidět, jsou naprosto identické, jenže ten jeho funguje a můj ne (překvapivě :)). Ani po třetí výměně ESP čipu (a tady se ten horkovzduch fakt hodil), desateru proměření a snad padesáti propájení všech kontaktů ten můj nefungoval stabilně.
Chvíli jel, pak najednou nekomunikoval, pak svítil, najednou ne, atd. A tak jsem udělal fotky obou ze všech stran a začli jsme řešit proč. Až při fakt důkladném ohledání jsme zjistili, že jsem otočil dva odpory o 90 stupňů. Kdo ví, co přesně to vlastně dělalo a jak to, že to vůbec fungovalo. Ale přitom taková blbost. A tady se fakt hodilo mít po ruce i funkční kus.
Po této opravě najednou začalo fungovat vše jak po másle. Nahrál jsem připravený firwmare, připojil jsem Swifitch na wifi a připojil ho k mému MQTT serveru.
Samotné propojení mezi MQTT a Loxone pak řeším opět přes NodeRED. V NodeRED mám udělaný HTTP endpoint, který Loxone zavolá s parametrem on/off na zapnutí/vypnutí daného swifitche.
Případně můžete využít služby SeedStudio, které krom výroby samotného plošňáku nabízí i službu osazení všech komponentů. Zkušenost s tím nemám, ale tuto volbu jsem tam viděl.
A jako poslední, nejjednodušší cesta, je kontaktovat přímo autora. Ten hotové swifitche také prodává za cenu 1000kč včetně krabičky a nahraného firwmaru. Za vybrané peníze momentálně vyvíjí další, mnohem sofistikovanější zařízení, kterým by chtěl konkurovat samotnému Loxonu ( a prý se s ním pochlubí na dalším Loxone srazu).
Osobně si myslím, že zakoupení jednoho zařízení je dobrý způsob, jak ho za jeho práci podpořit a zároveň vám zakoupený kus hodně pomůže při výrobě dalších, jelikož máte vzorový kousek, se kterým můžete vše porovnávat.
