Jak pomalý je Loxone? Hodně!

Jak pomalý je Loxone? Hodně!

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.

 

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

13 thoughts on “Jak pomalý je Loxone? Hodně!

    1. vypada to tak. pochybuju, ze to pro MS1 budou uz nejak vyrazne optimalizovat, kdyz ted budou vsem cpat MS2.

      Ten ma o dost lepsi HW a snad par let vydrzi, nez to zase takhle zprasi. Ale updatovat to fakt nebudu, protoze potrebuju i KNX a to bych se nedoplatil.

      Takze pro mne taky 8x forever 😉

  1. Pokial skutocne ten push-not-not-and robi to co popisujes, tak to by snad ani neslo vyvojarov loxone sw nazvat programatormi, ale uplnymi amaterskymi kokotmi. Je to uz dlha doba co som programoval svoj proof-of-concept noloxone, ale presne tento problem s predbiehanim sprav som musel pokryt ako uplne prvu a elementarnu vec, pretoze to tak bije do oci ze az. Riesenie je kupodivu uplne trivialne – KAZDY blok musi pri KAZDEJ zmene svojich vstupov (alebo vnutorneho stavu) vyslat spravu na vystup. Ta sprava sa spracuje nasledovnym blokom a ten znovu vysle novy vystup. A takto dokola. To samozrejme moze sposobit dalsi nepekny problem – stav posledneho prvku sa moze na velmi kratky cas prepnut do nechcenej hodnoty (tak ako postupne dotekaju informacie z jednotlivych vetvi). Tymto ale principialne trpia vsetky taketo kreslitka, urcite aj nodered. Uplna eliminacia tohoto problemu by (teoreticky) mohla byt riesitelna jedinym sposobom – tie spravy by netiekli z lava doprava, ale z prava do lava. Tzn. AND by sa opytal na (oboch vstupoch) prvkov pred nim, aky ze maju stav (a tento dotaz by sa kaskadovo siril az k tomu push buttonu). Az v momente ked by prisla posledna odpoved z poslednej vetvy, vyhodnotil by sa ten AND. Neviem domylsiet dopad na vykon, ale ak sa k tomu niekedy vratim, skusim to takto reimplementovat a uvidime.

    1. Imho to do ted neresili, protoze vykon loxone byl dostatecny a pripadne nekonzistence se vzdy hned doresili.

      Ten priklad s NOT-NOT byla ukazka na vysvetlenou, to otestovano nemam.

      Co ale otestovano mam je ten priklad 1 tlactiko, z toho 32 linek do tech vzorcu, z nich 8 linek do programu.

      a v nem smycka po 100ms a nacteni dat ze vstupu. A tam kdyz se to pusti, tak to rozhodne neukazuje bud same jednicky, nebo same 0. Ale naprosto nahodne 010110011 s tim, ze i kdyz se to necha dobehnout, tak uz nikdy nedojde do stavu 0000 ci 1111.

      Mozna, ze nad tema AND operacema maji jeste nejake dalsi CRC. Ale moc se mi nezda, ze by pro AND meli opatreni a pro vstupy do programu ne.

      Jenze tim se dostavame i k tomu nesmyslu, ze namisto nejake push-event se musi v PicoC volat while (true) {} a defakto tim zbytecne zatezovat loxone.

  2. Pěkný článek.. já jsem rovnou přešel na nový MS2 a starý prodal. Tady už snad běží nějaký linux …
    mělo by snad nějak přistupovat skrze telnet nebo ssh
    Na ftp je tam
    220———- Welcome to Pure-FTPd [privsep] [TLS] ———-

    1. no, kez by to bylo tak snadne. Jelikoz pouzivam i KNX, tak by to byla docela raketa. Takze zustavam u 8.xxx, ktera je rychla a dostatecna a ma i KNX 😉

      1. jasný chápu, od nějaké té 8ky se v Rakousku mění lidi a vývoj je jaký je…
        Uvidíme, až ten MS2 někdo otevře, pak třeba pujde instalovat balicky a pujde vymyslet plno veci

            1. zalezi co presne tam bezi, ale pokud by to bylo odvozene z nejake bezne distribuce, tak by to jit mohlo. nechme se prekvapit.

Leave a Reply

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


Subscribe without commenting