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 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.
To je děsivý. To na té 8.3 zůstanu už asi vážně navždy… 🙁
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 😉
diky, zajimave 🙂
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.
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.
Drsný. Jsem docela rád, že už se těmito loxoními duchy zabývat nemusím. 🙂
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] ———-
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 😉
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
to by byl ovsem argument. unlocknout ten linux, doinstalovat nodered, mqtt a dalsi 😉
presne to myslim 🙂 a nejaky vpn…… vymyslelo by se plno veci.. podle me to nebude nic sloziteho
zalezi co presne tam bezi, ale pokud by to bylo odvozene z nejake bezne distribuce, tak by to jit mohlo. nechme se prekvapit.
V dokumentaci je nějaká zmínka o telnetu
/dev/cfg/ftllocalonly
https://www.loxone.com/cscz/kb/api-webservices/
nešlo by to nejak skrze to ?
Ahoj, předem se velmi omlouvám za velké otravování, ale potřebuji si udělat trochu víc jasno. Váš blok sleduji už hodně dlouho a já osobně budu stavbu domu řešit v dubnu 2021, takže ohledně elektroinstalace a loxone mám ještě slušné mezery, ale díky Vám jsem se toho už hodně naučil. Bohužel mě trochu přepadl táta, který má už postavenou část hrubé stavby a ukacal jsem ho do loxone, aby se s nima spojil a vše prokonzultoval (momentálně tedy kabeláž atd.). Nicméně táta po mě bude chtít, abych vše vyřizoval já a s tím je trochu problém, jelikož nemám uplně vše od Vás ještě nastudované – ohledně loxone. (za tu dobu to tu hodně narostlo, a kvůli zastarávání technologií, věřím, že ne vše je již uplně aktuální – viz zigbee atd). A proto bych se Vás potřeboval zeptat na pár informací. Vím, že se Vám to nebude moc hodit, ale opravdu by mi to velmi pomohlo.
1) Měli bychom začít rovnou uvažovat nad pořízením 2. generace miniserveru? Nebo je lepší pořád 1. generace a downgradnout jí na 8? Vím, že zásadní rozdíl je právě u těch KNX, ale moc tomu ještě nerozumím a nevím, jestli KNX budeme potřebovat nebo ne.
2) Ohledně quida mi je to jasné, ale je možné jej napojit i na 2. generaci? Budeme potřebovat i nějaké originální extensiony, nebo je možné vše napojit rovnou na quida a díky tomu za extensiony ušetřit? Samozřejmě uvažujeme o zakoupení vašeho programu na propojení.
3) Už jsem to nakousl v bodě jedna. Mám docela bordel v těch světlech (originální loxone dimmer, DMX triaky čína, zigbee, KNX (jsem z toho jelen). Táta by samozřejmě u nějakých světel chtěl využít změnu intenzity a možná i barvy, ale drahé dimmery od Loxone, no nevím no. Mohl byste mi prosím nějak jednoduše poradit, co tedy použít na ta světla?. Samozřejmě jsem pochopil, že 2. generace nepodporuje KNX, takže je KNX technologie potřeba, nebo jak to zkrátka vyřešit?
4) Abych nepsal nějak moc otázek, vlastně jednoduše by mě zajímalo, co od Loxone má smysl originálně kupovat a co ne (co je možné nahradit něčím levnějším-viz další extension (Relay, modbus atd. – chápu, že tree a air jsou asi zbytečné pořizovat) – vím, že už je to tu na blogu napsané hodněkrát, ale, jak říkám, vše najít a udělat si v tom pořádek a jasno, je opravdu pakárna (opravdu nic ve zlém) a hlavně si to tak nějak sjednotit (Loxone komponenty). Nejvíce jasno mám v tom quidu.
Ještě jednou se moc omlouvám, samozřejmě bych byl ochoten za odpověď zaslat i nějakou kompenzaci, jelikož mi to teď hodně ušetří čas.
Děkuji moc 🙂 Matěj
PS: neobtěžoval bych Vás tím a snažil bych se tu vše nějak postupně dohledat, ale díky tátovi mě tlačí čas.
I k miniserveru v2 lze mít KNX, prodávají jej v podobě extension, ale ta cena je dost mimo. 🙁
Spoustu textu, spoustu otazek ;-). Pokusim se odpovedet, ale 100% reseni pro Vas nemam 😉
1) ovlivnuje to spoustu faktoru. pokud nebudete mit zadne KNX, sel bych do MS2, je o dost rychlejsi. pokud KNX budete mit a staci vam loxconfig v8 namisto v10, bezte do MS1. Pokud chcete v10 a chcete KNX, bezte do MS2+KNX extension. MS1 je hodne pomaly a na novejsi nez v8 verze se dle meho nehodi.
2) Quido funguje i s MS2 a diky vyssimu vykonu MS2 i o dost rychleji. Defakto na MS2 + V10 bezi zase jako driv bezel na MS1+V8. Urcite nenapojovat vse do Quida, je to porad externi technologie. Paterni a dulezite veci bych dal do Loxone, mene dulezite veci do Quida. Ale volba je samozrejme na Vas, lze jit i cestou miniserver MS2 a jen Quido moduly, ale v pripade nejakeho vypadku quida nebo treba nejakeho problemu ze strany Loxone to znamena, ze nepojede cely dum.
2b) “Samozřejmě uvažujeme o zakoupení vašeho programu na propojení.” Diky. Pro kazdy dum bude potreba vlastni licence, ale kazdy dum pak uz muze mit libovolny pocet Quido vstupnich ci vystupnich modulu.
3) toto prosim prostudujte a konzultujte na foru. toto je diskuze na spoustu hodin, ovlivnena spoustou faktoru. Sam mam zatim jen relatka + objimky a stale resim, jak to udelat. Moznosti je hrozne moc. Svetla mohou byt rele, mohou byt DMX, mohou byt pres zigbee,….
4) toto je zase strasne individualni a opravdu to nelze shrnout do jedne vety. Zalezi to na Vasi osobni statecnosti a financnich moznostech. Pokud se clovek boji hodne, at vse postavi na loxone ci KNX, pokud se neboji vubec, lze postavit dum v extremu na arduinu. Pokud se boji mene, lze Loxone+quido vyresit vse. jak sem psal nahore, osobne bych sel cestou loxone + jeden/dva extension pro paterni veci (svetla, atd) a vse ostatni, co muze klidne tyden nefungovat quidem (senzory oken, ovladani zaluzii,….).
Doufam, ze odpoved takto pomohla. Bohuzel, Vase dotazy jsou opravdu velmi obecne a nelze bez blizsich informaci rict presne, jak to mate udelat. Od toho jsou defakto Loxone partneri, kteri s dotycnym projdou celou stavbu a vse vyhodnoti. Samozrejme, ti nepristoupi na ruzne Quido moduly. Takze je potreba si vse sam prostudovat, zhodnotit plusy a minusy a nejak se rozhodnout. A obcas pocitat i s tim, ze v budoucnu budete nektere veci predelavat ;-).
Pokud nas chcete podporit, ucet pro prispevky je tento: 1012036013/3030 Dekujeme!
Jeste k dotazum dodam, ze presne na toto byly dobre Loxone hospody ;-). Na probrani seznamu Vasich dotazu by mozna tak-tak stacila jedna seance, spis dve. Je to opravdu velmi rozsahle tema a dotazy jsou tak obecne, ze se o nich lze bavit i nekolik hodin.
Bohuzel, dalsi Loxone hospoda je zatim v nedohlednu, takze bude muset stacit forum. Zkuste jeste trochu prostudovat forum a pak muzete konkretnejsi dotazy nahazet na forum. Je tam mnohem vice lidi, kteri do nekterych oblasti vidi i vice nez ja (treba konkretne svetla, v tech mam sam zatim stale zmatek).
Pokud muzu prispet – jeste zvazte teplotni senzory. Pak vychazi investice do 1wire, do DMX, Quido a je to resitelne pro instalaci v rodinnem dome. (pokud ne arduino). Jsou jedinci, co i relatka ovladaji pres DMX.
Ahoj, jen pro pradek tedy, takže pokud to bude druhá generace serveru (1. Mi táta řekl že nechce) tak cca 1 nebo 2 originální extensiony na vstupy 1 nebo 2 originální relay extension na vystupy a na teplotní vstupy 1 wire od loxone ? Četl jsem, že se tam mohou napojit všechny teplotní senzory. Musíme koupit i dmx extension (jelikož ho právě 2. Generace už v sobě nema)? Pak teda samozřejmě quido vstupy a výstupy na ne core systémy a zigbee. Pořád akorát moc nerozumím těm svetlum, jestli kupovat originál dimmer extension nebo jestli to řešit jinak (triak) o knx vim ještě uplne prd. Kdyžtak děkuji za odpověď. Chtěl jsem dotaz (nějakej obsáhlejší na toto téma napsat na fórum, ale ještě jsem se k tomu nedostal)
ja si myslim, ze 1x ext. vstupy a 1x ext vystupy na hlavni svetla by mohl stacit (za predpokladu, ze svetla budou on/off rele).
DMX potrebujete jen pokud chcete stmivana svetla, pripadne pokud budete neco ovladat pres DMX kontroler (jsou dokonce i rele na DMX, ale s tim nemam osobne zkusenost).
DMX v MS nebylo nikdy, vzdy se dokupovalo zvlast.
KNX != DMX. Mam pocit, ze KNX pouzivate jako zkratku ke svetlum. KNX je sbernice, na ktere se daji provozovat dalsi bloky podobne Loxone extension, jen je to prumyslovy format. Vetsinou jsou vstupy/vystupy na KNX drazsi nez Loxone, ale existuji i vyjimky. KNX se musi programovat externim SW, v nem se musi oadresovat jednotlive prvky a ty pak namapovat do Loxone. Z toho co pisete bych Vam doporucil asi KNX neresit, kor jestli budete mit MS2, kde je KNX modul dost drahy.
ad svetla, ja osobne pravdepodobne pujdu tak, ze zakladni svetla pres relatka (at uz extension, nebo quido), a pak stmivani/barvy/… pres zigbee. Kdyz nepojede zigbee, nic se nedeje, zapnout/vypnout pujdou vzdy pres rele. Tim padem usetrite na DMX ext.
pokud ale budete chtit intenzitu/barvu ovladat pres loxone do zigbee, je potreba rozchodit RaspberyPi zigbee gateway a pres NodeRED to propojit. Neni to uplne intuitivni, ale neni to nic hrozneho (navody zde na blogu).
Děkuju děkuju, tohle mi hodně pomohlo, omlouvám se, nějak jsem si právě zapletl zkratky knx a dmx. Zigbee gateway přes rapsbery jsem si tu už procital a věřím, že se mi to v budoucnu podaří nějak rozchodit do loxone díky vašemu super návodu. Stmivani a barvy světel právě taky beru jako něco navíc a kupovat kvůli tomu extension se mi právě nechce. Ještě jednou moc děkuju a knx fakt asi řešit nebudu. Pokud bych však v budoucnu z nějakého důvodu chtěl tak mohu jen přikoupit knx extension a knx vstupy atd.
Na KNX je dobrá Logic Machine – openrb.com, u nás prodává Premisa TZB. Server je docela dražší, ale má hodně periferií a je to vše programovatelné v Lue.
Děkuji moc za odpověď 🙂 samozřejmě, že na jeden dům jeden program, to je mi jasné. Něco na účet určitě pošlu. Hezký den
Zamalo. Jak jsem psal, zkuste poslat konkretnejsi dotazy na forum, tam se k tomu dostane mnohem vice lidi (lidem prijdou i emaily, zatimco tady to zapadne) a muzeme to i vic rozebrat. Takto pod clankem se to resi slozite.
Diky, prispevek dorazil. Jak jsem psal, kdyby bylo neco jeste potreba, hodte dotazy rovnou na forum. Pokusim se odpovedet, pripadne nekdo z dalsich. Je nas tam docela dost 😉
Dobře, raději to napíšu i tam. Jen ještě otázka, quidem lze nahradit i relay extension nebo?
Quido ma jak vstupni, tak vystupni moduly. vstupni ma maximalne 100/3 , tzn 100 vstupu a 3 vystupy a vystupni ma maximalne 2/32, tzn 2 vstupy a 32 vystupu.
ale POZOR, relatka na quidech nejsou zatezova na 230V, tzn pokud budete spinat 230V, potrebujete externi rele, ktere se bude ovladat pomoci Quido modulu.
Pro tyto ucely ma Quido take OC vystupni moduly (ale mam pocit, ze tam byly nejake zmeny a nevim co ted je nebo neni k dispozici)
No, tady se ukazuje slabina Loxone. To jsou malovátka v LoxPlanu. Je to jako když programujete něco ve windows a PicoC je BashShell. Pro pár základních přednastavených funkcí dobrý, ale dál se to neposunulo a lepší procesor a paměti zvedá i nároky na spotřebu a spolehlivost, Pěkný článek, díky!
Dobrý deň, čím je to spomaľovanie podľa vás spôsobené? Píšete, že každá nová verzia viedla k miernemu spomaleniu, tak mi napadá, či to nie je staré dobré kurvítko, aby klienti prechádzali na novší model.
Loxone aktuálne zvažujem do nového domu, ale som ohľadom toho veľmi skeptický, pretože chcem robustné riešenie a nie predražený zlý vtip, ktorý laguje pri dvojklikoch aj na ich vlastnej zbernici.
Dobry den. Vedli jsme o tom radu diskuzi a takhle zpetne si myslim, ze to umysl pravdepodobne nebyl, ale spise diletanstvi spolu s omezenymi moznostmi HW Miniserveru.
Ze zacatku, kdyz se zacal mustek zpomalovat, tak sme si rikali, jestli umyslne nesabotuji PicoC, aby ho lide prestali pouzivat. Ale kdyz zacal lagovat i samotny HW loxone, kdy i na jejich HW zlobil dvojklik, bylo jasne, ze to umysl nebude.
Problem byl, ze HW MS verze 1 je relativne slaby a Loxone namisto cesty univerzalniho LoxConfigu sel cestou milionu predpripravenych prvku a logiky pro jejich konkretni HW. Tim padem kazda dalsi verze LoxConfigu v sobe mela vice a vice balastu. Nedokazu rict, co konkretne zpomalilo MS i v pripade, ze clovek novou funkcionalitu nepouzival, ale MS se proste zpomaloval.
Mozna to bylo nove webove rozhrani, mozna postupna implementace nejakych bugfixu nebo zabezpeceni, tezko rict. Pritom napriklad HTTPS se Loxone dlouhe roky branil, protoze jim ho MS1 proste neutahl.
I proto predstavili MS2. Ten je po HW strance o dost vylepseny. Jde o quadcore namisto singlecoru, ma mnohem vice pameti a je o dost modernejsi. Bohuzel z nej Loxone odstranil KNX, ktery dost predstavil jako samostatny modul za nemale penize.
Pokud tedy planujete novy dum, bezte urcite do MS2. Vykon ma stejne jako MS1 zamlada, zvlada opet stovky impulzu a vse bezi jak ma. Bohuzel, pokud budete chtit pouzivat KNX prvky, budete si muset priplatit jednou tolik za KNX prvek.
Do budoucna ale urcite nejde rict, co bude. Je mozne, ze po case experti z Loxone zvladnou zaplacat i MS2 a dojde zase ke zpomalovani. Tentokrat mozna zamerne, nebo mozna omylem. Resenim ale vzdy je neupgradovat a zustat u verze, ktera cloveku vyhovuje.