Loxone virtuální výstupy a jejich debugging
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.
curl http://api.pushover.net/1/messages.json -d "token=xxxxx&message=helloworld&user=xxxxx"
{"status":1,"request":"719ea7ef-f62d-456e-bb09-0708f24605b7"}
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,
Command for ON : http://192.168.0.226/api/xxxxx/lights/1/stateHTTP extensions for ON : host: 192.168.0.226\r\nContent-Type: application/json
HTTP POST command for ON : {“on”: true}
HTTP method for ON : PUTsame 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.
