Browsed by
Tag: mustek

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.

 

Bugfix na kritickou chybu v Quido-Loxone můstku

Bugfix na kritickou chybu v Quido-Loxone můstku

Jak jsem už avizoval v Loxone hospodě, můj program pro spojení Quida a Loxone měl (ačkoli u Vás ještě má 😉 ) v sobě kritickou chybu.

Kritická je z toho pohledu, že když na ni dojde, dokáže sežrat 100% CPU Loxonu, přestanou fungovat všechny vstupy/výstupy a ještě to pekelně zpomalí celý Loxone systém. Být to od korporátu, budou tvrdit, že je to jen glitch, žádný velký problém 😉

Naštěst (ačkoli během fixování spíš bohužel) se chyba objeví tak jednou za měsíc a to jen když pořádně nakládáte Loxonu i Quidu, do toho si hrajete se síťovou kabeláží a občas zrestartujete router.

To je asi i důvod, proč mi to nikdo kupoduvi neomlátil o hlavu. Fix byl jednoduchý, stačilo restartnout Loxone a zase to fakt dlouho fungovalo. Nevýhoda byla, že každý pokus o opravu chyby znamenal upravit Loxone program a čekat.

Ale nakonec se podařilo. Chyba byla způsobená tím, že když se rozpadlo spojení mezi Loxone a Quidem, tak jsou tam opravné mechanismy co spojení opět navážou a získají aktuální data pro vstupy.

Jenže, v určité situaci se navázání spojení nepovedlo a namísto toho, aby se vynulovaly pointery na spojení, zůstaly plné. No, a pak už následoval kolotoč, kdy se neustále dokola spojovalo-ověřovalo-posílalo-spojovalo-ověřovalo-posílalo-…. a to pořád.

Naštěstí, stačilo přidat quido_udp_stream_read = NULL;, aby se spojení správně znova navázalo. A od té doby běhá vše jak má.

Testuju to u sebe momentálně cca 3 týdny, simuloval jsem mu výpadky a vše ok. Tak doufám, že to bylo ono 🙂

Kde stažení je aktualizace v Dropboxu tam, kde byl i původní program. Že je to správná verze poznáte tak, že v hlaviččce je Verze 25.1.2017 (v10).