Loxone virtuální výstupy a jejich debugging

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.

Toto je špatně, v adrese nesmí být celá URL adresa, ale jen protokol + adresa serveru.

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

 

Toto je ukázka, jak ne. V adrese nesmí být koncové lomítko!

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.

Pomohl Vám náš blog? Chcete nás podpořit? I málo udělá radost 😉

36 thoughts on “Loxone virtuální výstupy a jejich debugging

    1. V tomto clanku sem to nechtěl resit, bude to obsahem toho dalšího. Ale duvodu je opravdu hodne. Od lepsi sorsvy notifikaci, pres jednotny system na vice sluzbach az po moznost pouzivat notifikace i kdyz ma loxone ban na pripojeni do internetu (na loxone domeny) z duvodu bezpečnosti i stability.

    2. Naviv, obsahem clanku nejsou notifikace, ale jak ladit http výstupy obecně. Nejde jen o notifikace, ale o napojeni smarthome na externi komponenty.

    1. Jj, bohuzel klasika. Proto mne to uz ani moc neprekvapilo a sel sem rovnou debugovat ;-).

      Ad pushover, je fakt dobry. Jen co budu mit chvilku, sepisu ten druhej clanek s ukazkama.

      Co je pecka, muzes si jednotlivym zpravam nastavit ruzne zvuky a zaroven nastavit pravidla, ze v klidovem rezimu chodi jen prioritni zpravy a zbytek mlci.

      1. Good tesim sa (a potom si naimplementujem nieco vlastne nad dockerom tak ako mam zigbee, nech nemusim riesit nodepicored).

  1. Bojuji ted taky s vyrtualnim vystupem.

    Da se nejakym zpusobem predat textova hodnota jako parametr pro volani instrukci po zapnuti?

    Priklad pouziti: Budicek Sonos

    Mam pripraveny v Loxone string: Aktualni den, predpoved pocasi + uvitani.

    Pomoci Sonos Api je mozne volat Text to Spech:

    Zprava po spusteni:
    Mistnost/say//cs/70

    Hodnotu “” potrebuji nahradit prave vystupem ze statusu. (trigger pro vyrtualni vystup)

    1. Toto sem původně take chtel, ale neprisel sem na to jak. Jedina cesta mne napadla pres PicoC, ale to by to cele desne zkomplikovalo. Takže v případě slozenych retezcu s hodnotama budu asi pouzivat NoderRed. Ale mozna to jde i jinak 🙂

      1. Já mám když odcházím z domu POST command:
        “Home was armed. Enjoy your trip, temperature outside is degrees.”
        Což funguje krásně – ale nejde tam vložit string, jde jen číselná hodnota. Posílám to teda na openhab REST api, který to láduje do Echo repráčku, ale to bude pro SONOS stejné. Složitější věci řeším přes vlastní Alexa skill nebou routine.

        1. Koukám, že to tu nebere ostré html závorky. POST COMMAND má být:
          “Home was armed. Enjoy your trip, temperature outside is (v.1) degrees.”, kde nahradíte kulaté za ostré závorky. Virtuální výstup se pak netrigruje logickou jedničkou, ale analogovou hodnotou. Posílám jí tam přes Analogue memory block a ten trigruju tlačítkem (takže by to nefungovalo, kdyby předchozí teplota byla stejná jako ta aktuální, ale to mě netrápí).

  2. Dneska taky řeším http výstup. Mám tam modul pro osvětlení, kde nastavím okruh na RGB a jako výstup chci použít virtual output. Problém je v tom, že jsem nenašel jako použít hodnoty co jdou do toho http request.

    Mám rest servisu kam bych chtel poslat něco jako http://server/api/led1/{red}/{green}/{blue} a aby si to vzalo hodnotu co jde z toho bloku osvětlení.

    1. Ted asi nechapu, jeslti je to dotaz, nebo jen povzdychnuti ;-). Bez specifikace toho, co cilove zarizeni pozaduje za pozadavek je tezke radit 😉

        1. Ajo, uz rozumim. No, tak to je presne to, co si myslim, ze loxone neumi 😉

          Zrejme by jeste slo nejak predat nejakou integer hodnotu, jelikoz v napovede je \1 \2 \3 \4 na predani 1-4 byte hodnoty, ale jak predat treba string, na to sem neprisel. Natoz jak rozparsovat 3 hodnoty a ty predat do adresy.

          Toto by slo asi resit tak, ze se na tyto 3 hodnoty dostanes z venku pres json pozadavek stejne jako to dela webove rozhrani, to pak rozparsovat pres nodered a predat dal.

  3. Nevím jak to přesně vypadá ale na RGB výstupu bloku osvětlení je celé číslo, které se přepočítává následovně:
    %-hodnota červené + %-hodnota zelené*1000 + %-hodnota modré *1000000

    1. aha, tak tim by to slo rozdelit na 3 cisla. ale nevim, jak z toho pak udelat jeden URL dotaz. protoze v LoxConfigu imho neni zadne sprintf(“%s/%s/%s”) napriklad. To by se to muselo tahat pres PicoC a to je zas overkill

    2. Je to %, alebo 0-255? Je to davno co som to skumal a nepamatam si to, mozno sa mi to pletie so zigbee.

      Inak to cislo nemusis ani riesit matematicky, rozdelis to po 3 znaky a mas hotovo :D.

    1. Mas pravdu. 0-255 bolo u ikea zigbee ledky. Nejaku dobu som bol nasrany ze svieti nejak slabo na deklarovanu wataz, nez som si neuvedomil, ze tam posielam 100 a nie 255 :D.

    1. zkousel jste krok za krokem clanek? mate rozchozene prikazy z postmana? A zkousel jste simulovat volani z Loxone do simulatoru http? Take postnete fotky jak to mate presne v loxone nastaveno, pak pujde pomoct.

    1. Zopakuju uz co jsem psal. Je potreba dle clanku si rozchodit posilani dat z Loxone do simulatoru, aby bylo videt co loxone posila.

      a pak zkouset, jak vypada vysledny dotaz a jestli vypada jak ma.

        1. Cetl jste vubec ten clanek?

          Cituji:
          >>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/.

          Nezlobte se, ale pokud vy nedokazete vynalozit ani trochu sveho casu, abyste si procetl to, co zde zdarma nabizim, tak ja opravdu nebudu venovat svuj cas do toho, abych resil Vase logy z Loxone, ktere navic jak pisu v clanku, jsou uplne k nicemu.

              1. Tim padem je potreba pres Curl nebo postmana poslat pozadavek do simulatoru, podivat se jak vypada a pak ten stejny pozadavek nastavit v Loxone.

                pokud je tam autorizace, posilaji se nejake hlavicky, ktere bude potreba nastavit do sekce s hlavickama (viz clanek)

  4. Já tohle řešil před půl rokem (dost podobně – api vyžadovalo json content type) ale na ten trik s mezerou jsem teda nepřišel. Díky!!

  5. Dobrej článek … ještě bych doplnil o další “tweak”, kdy je nutné např. jednotlivé hlavičky oddělovat pomocí Carriage return a Line Feed, tedy \r\n (např.\r\nContent-Type: application/json), pokud vkládám do příkazu proměnnou hlavičku.

    Toto jsem řešil nedávno při nastavování ovládání robot. sekačky Bosch..

Leave a Reply to Petr Cancel reply

Your email address will not be published. Required fields are marked *


Subscribe without commenting