Browsed by
Tag: quido

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

Aktualizace můstku Quido-Loxone

Aktualizace můstku Quido-Loxone

Nějak jsem úplně zapoměl veřejně oznámit novou aktualizaci na můj program pro propojení Quida (Papoucha) a Loxone. Díky tomu ale můžu po několika týdnech testování s klidným svědomím říct, že opravdu funguje vše jak má a nemusíte se případně bát aktualizovat :-).

Ovládání relátek na Quidovi

Nová verze obsahuje několik novinek. Tou první, hlavní, je možnost ovládat relátka na Quidovi. Relátka lze ovládat na všech modulech Quida, které relátka mají. Tzn jak na modulu 100/3, tak až po modul 2/32. Vše v ethernet verzi.

Drobná komplikace během vývoje nastala v omezení Loxonu zpracovávat operace asynchroně. Jelikož toto Loxone (PicoC) neumí, nelze zároveň poslouchat sockety a zároveň je odesílat. Z toho vyplívá, že v okamžiku spínání relé nemusí dorazit info o uvolnění tlačítka, což mělo za důsledek dost náhodné chování žaluzií 😉

Z tohoto důvodu je potřeba použít zvlášť komponentu “Loxone program” pro vstupy a zvlášť pro výstupy.  PicoC jako takový je stejný, jen se v hlavičce programu nastaví, zda obsluhuje vstupy nebo výstupy. Pokud vstupy nebo výstupy nepotřebujete, stačí použít jen jeden program takový, který potřebujete.

Relátka se ovládají přes připravené Loxone bloky. Na každý vzorec lze připojit až 4 vstupy pro relé a ty jsou pak napojeny na jeden společný Loxone program, který z nastavených hodnot relé sepne nebo rozepne.

Automaticky generované pakety

Druhá novinka je kompletní předělání vnitřností programu tak, abych už nemusel generovat ručně pakety, ale aby si program vše dělal sám. Na jednu stranu to ulehčí konfiguraci, na druhou stranu to dost zkomplikovalo SW. Bohužel, jelikož se každé relé spíná vždy jiným příkazem, nebylo zbytí. Jinak bych musel generovat až 40 paketů pro každého uživatele zvlášť, a to by mi mrdlo.

Díky tomu se ale i hodně zjednodušilo nastavení celého programu. Stačí zadat jen IP a port pro Loxone a pro Quida, nastavit režim programu (0/1 vstupy/výstupy) a hotovo.

Paměťová i procesorová optimalizace programu

Třetí novinka je, že je celý Loxone program zkomprimovaný. Jelikož už byl díky všem rozšířením a komentářům opravdu dlouhý, napsal jsem si komprimátor tak, aby z kódu zmizely všechny zbytečné komentáře a dlouhé názvy a program tak v Loxonu nezabíral zbytečně pamět (a i parser PicoC má tím pádem méně práce), takže program celkově méně zatěžuje Loxone.

Vypnutí zbytečných výstupů do logu

Poslední novinkou je pak odstranění některých výpisů do logu Loxone configu. Ty jsem tam měl z doby ladění a zůstaly i u některých z Vás. Bohužel, když se tam nechaly nějakou dobu, dokázaly pár MB dat v logu udělat. Pokud by se to týkalo i Vás, můžete logy promazat přes FTP přímo v Loxonu.

A to je vše

Tím končí soupis změn z aktuální verze. Pro ty z Vás, kteří si už program koupili, tak je aktualizace dostupná ve sdílené Dropbox složce tak jako dřív. Je aktualizovaný jak program, tak Loxone projekt, kde ve dvou záložkách najdete schéma pro vstupy a výstupy.

Pokud ještě program nemáte, ale čekali jste třeba právě na výstupy, neváhejte se mi ozvat na email [email protected]. Cena zůstává stále stejná, ačkoli je program opět o několik řádů vylepšený 😉

PS: Zároveň jsem aktualizoval i návod na původní stránce o Papouchovi – https://www.vodnici.net/2016/10/loxone-propojeni-s-modulem-quido-od-papoucha/

 

 

Quido na steroidech

Quido na steroidech

Tak tu máme první velkou aktualizaci SW pro Papouchova Quida. Jak jsem v předchozích článcích, původně bylo implementováno vše jen pro vstupy, ale výstupy jsem neřešil. A protože už je zájem i o výstupy, nedalo se nic dělat a hurá k parodii na C jazyk nazývanou PicoC :).

Bohužel z mého odhadu, že to bude fik fik za hoďku hotové nakonec dost sešlo. První problém byl, že ovládat jednotlivé relé znamená mít spoustu dalších různých řídících paketů, což by obnášelo spoustu manuálního generování. Takže nezbylo než se zanořit ještě hloubš do dokumentace a napsat si vlastní generátor a podepisovač paketů.

Výhoda je, že už nemusím připravovat pro nové uživatele pakety ručně, nevýhoda byla, že to vzalo hromadu času. Krom samotné implementace to hlavně chtělo zavést už i nějaké testování, protože lazení v Loxone program editoru je naprosté peklo (jako třeba proč nefunguje ani blbá klávesa PageUp-PageDown je mi záhadou).

Takže jsem si rozběhal projekt ve Visual Studiu, namockoval Loxone metody tak, aby nic nedělali, ale program šel zkompilovat a pustil se do rozšiřování. Kromě samotného podepisování, které je plné bitových operací, to chtělo ještě nějaké parsery na vyčtení dat z IP adresy, výpočty bitů pro stavy relé a hromadu dalších věcí, které už nabouchat jen od boku není úplně bezpečné.

Takže krom toho, že to jde kompilovat ve VS, čímž eliminuju zdlouhavý proces přes Loxone, tak jsem tam udělal ještě sadu spousty testů, které všechny tyhle metody před nasazením do Loxonu otestují.

Co se začíná ukazovat jako dost komplikace je fakt, že celý progam musí být jen v jednom souboru. Žádné pěkné oddělení, žádné objekty, žádná struktura. Pěkně všechno pod sebou, navíc ideálně v globálních proměných osekaných na dřeň, aby to žralo co nejméně paměti.

Takže je to ošklivý špagety kód. Navíc ručně optimalizovaný tak, aby se nikde nealokovala žádná pamět, ale používal se sdílený buffer, aby to žralo co nejméně procesoru a hlavně to nepadalo a prošlo to i tím příšerným PicoC interpretem.

Když bylo vše naprogramováno, přišlo na řadu první testování v reálném prostředí. Bohužel to hned odhalilo druhý velký problém. Ukázalo se, že moje myšlenka se sdíleným kódem pro vstupy i výstupy je mimo a že to takto nepůjde.

Problém totiž je, že PicoC neumí asynchroní čtení ze streamu. Takže stream buď čte, ale pak je program blokován čekáním a čtením, nebo nečte, a pak se pakety zkrátka nezpracují.

Původně jsem to měl tak, že se vždy jen zjistilo, jestli jsou nová data, když ne, zjistilo se, jestli je na vstupech nějaká změna. A když ne, znova se zjistili data, …..

Jenže, v okamžiku, kdy se zjišťovali vstupy, tak se třeba nenačetlo, že člověk pustil tlačítko žaluzie, a tak žaluzie sjížděla vesele dál. Nebo nezaregistroval stistknutí, nebo otevření okna,… Protože když nečetl, paket zůstal nevyslyšen.

A bohužel, toto nijak vyřešit nejde. Pročetl jsem dokumentaci, pročetl diskuze, a je to prostě tak. Takže jediné řešení jsou dvě smyčky. Jedna co načítá data z Papoucha, druhý co načítá vstupy z Loxonu.

A když dvě smyčky, tak dva Loxone programy. Takže pokud někdo budete chtít využít obě funkce, je nutné použít dva samostatné bloky. Když jen jednu z nich, druhý se použít nemusí.

A aby se program dobře nastavoval i distribuoval, je to udělané tak, že je program jeden a ten stejný a jen pomocí přepínače se nastavuje, jestli se má chovat jako Relé můstek nebo můstek pro Vstupy.

Celé nastavení programu tak nyní vypadá takto

char * c_remote_listen_address = "/dev/udp/192.168.1.254/10001";
char * c_remote_write_address = "/dev/udp/192.168.1.254/10002";

//pocet rele
unsigned int c_relays_count = 3;

//automaticky refreshnout stav vstupu pro pripad, ze se ztratil UDP paket s notifikaci (treba otevrene okno)
unsigned int c_auto_refresh_every_sec = 60;

//jak casto se detekuji vstupy kvuli rele. Cim mene, tim vice se bude zatezovat miniserver
unsigned int c_relay_check_period_msec = 100;

//rezim 0-INPUTS [digitalni vstupy], 1-OUTPUTS [rele]
unsigned int quido_bridge_mode = 1;

Jak je vidět, zmizelo nastavení paketů, to se dělá dynamicky. Jediné co je potřeba, je správně zadat IP adresu a počet relé, které Quido má (při větším čísle než kolik jich je k dispozici pak nefunguje žádné!). Jako poslední nastavení Nově pak jsou nastavení rezimu INPUTS a OUTPUTS a konstanta, která určuje, jak často se mají vstupy kontrolovat.

To je totiž další vykutálenost Loxonu. Namísto, aby se dalo říct “čekej, než se vstup změní”, tak se musí dělat “už se změnilo?”,”už?”,”už?”,… A čim častěji se ptá, tím víc to žere prostředky. A když se taková smyčka pustí bez uspání, žere 100% procesoru.

Takže jsem jako výchozí nastavil 100ms. Pokud by to bylo někomu málo, může si to vytunit, ale s rizikem, že to bude žrát více prostředků Loxonu. Imho si myslím, že 100ms je dostatečný fofr.

Co se týká blokového zapojení v Loxone configu, tak k tomu můžu říct jen jediné. Loxone programátoři by se nad sebou měli zamyslet a dodělat logické chybějící bloky. Nehápu, proč když Loxone nabízí Binární dekodér, nemá i logický protikus binární kodér. Nechápu, proč když se zeptám na podpoře, tak jim přijde logická odpověd “použijte vzorec”. A nechápu, proč když už doprd… mám použít vzorec, tak proč vzorec nemá aspoň osm vstupů, ale jen čtyři, takže to práci pekelně komplikuje.

Ale ok. Jedno přísloví říká, že na všechno je potřeba se koukat ne jako na problém, ale jako na příležitost, a tak jsem se té příležitosti chopil a poskládal to ze vzorců.

Samotné využití a napojení na reálný dům je pak už hodně jednoduché. Na vstupy vzorce se přivede 0 nebo 1 a vzorce spolu s programem dle toho zapnout dané relé. Pokud na vstup přivedete cokoli víc než 1, výsledek je random a nejspíš se nestane vůbec nic. Je to proto, že ve vzorci převádím binární 0 a 1 na číslo a třeba taková 2 v tom udělá dost brajgl :).

Níže je video ukázka jak to funguje, především pak rychlost. Podle mě je suprová ;-). Nedokážu si předtavit, že byste dokázali klikat rychleji, než kolik můstek zvládá Quida (Papoucha) ovládat.

Momentálně probíhá testování v mém domě, kdy se jednak testuje původní část na vstupy pomocí žaluzií a stavů oken. Výstupy pak testuju jen napojenou diodou v rozvaděči, protože jsem takto narychlo neměl žádný siloproud, co bych tam zapojil a přepojovat rozvaděč se mi nechtělo.

Pokud půjde všechno jak má, tak novou verzi pustím do světa do konce týdne. Odvážným majitelům předchozí verze klidně poskytnu dříve, ale jen na vlastní riziko :).

Loxone – čidla oken, impulzní vodoměr a Quido

Loxone – čidla oken, impulzní vodoměr a Quido

Článek nakonec vydávám s týdenním zpožděním, protože vzhledem k narození malého jsem ho tenkrát nestihl dopsat. Proto prosím berte časové údaje s rezervou 😉

Tak mám hotové další dvě věci v našem chytrém baráku. Už mi fungují čidla oken/dveří a naše dva vodoměry na vnitřní/venkovní vodu. A protože od víkendu už je delší doba, tak už jsem zase zapoměl na všechno to zlé, co mi Loxone prováděl, a zase ho jen bezmezně miluju 🙂

2016-09-22-11-44-01

Obě zmíněné věci jsem rozchodil přes Quida, což byl i hlavní důvod mých frustrací. Ale je tomu 3 dny a zatím vše funguje naprosto bezchybně.

Jo, a asi by stálo za zmínku, že můj Quido dostal ještě přední brnění, protože bez něho bylo všechno až moc nebezpečně přístupné a dost jsem se bál, že se tam stane nějaká nehoda.

2016-09-22-16-49-59

Jako první jsem rozcházel vodoměry. Tam to bylo docela snadné. Vodoměr má impulzní výstup, přes který se dá prohnat až 30V, takže 24V funguje naprosto skvěle. Vodoměr jsem si nechal upravit tak, aby tikal každý litr (ačkoli prý běžně stačí jendou za 10l, ale já to chtěl detailnější 😉 ).

2016-09-22-16-49-54

Vodoměry se pak v krabičce napojují na jednu CATynu spolu s 1-wire rozhraním z boileru a odtamtud pak rovnou do rozvaděče. Tam už jsou přivedené jako vstupy Quida a spokojeně tikají.

2016-09-22-16-50-42

Pak už jen nastavit v Loxone configu a statistky odběru vody byly hotové.

chrome_2016-09-27_18-43-53

O něco větší oříšek pak byly čidla oken, tam u6 té práce bylo na dva dny. Když jsme teď už kdysi dávno chystali rozvody elektriky, z každého okna jsme kabel z čidla svedli do instalační krabičky pod oknem, kde zároveň začínaly kabely svedené do rozvaděče.

2016-09-23-13-50-52

A protože jsme tenkrát nesehnali čtyřžilový kabel, vedou tam vždycky dva dvoužilové. Čtyřžilový proto, že dva jsou kontakt otevřeno/zavřeno a druhé dva pak tamper kontakt, že čidlo funguje v pořádku.

2016-09-23-13-56-20

Takže u každého okna bylo potřeba kabely zkrátit, oholit spojit, zaizolovat a zpátky zarolovat. Krásná odpočinká práce, jen to dost trvalo (mám pocit, že víc než půl dne).

2016-09-23-13-56-48

Opět jsem si nemohl vynachválit systém spojování přes dutinky. Protože pájet to, tak to dělám deset let.

2016-09-23-13-52-01

Když bylo nataháno, přesunul jsem se k rozvaděči. Tam bylo potřeba vymyslet, kde a jak to celé spojím a kudy svedu do Quida. Původně byly kabely ze zabezpečovačky od p. Hrubana připraveny nad rozvaděč.

2016-09-23-15-36-12-2

Bohužel část kabelů byla relativně krátká a celkově by se celé to veledílo dělalo nahoře složitě. A tak přišel nápad přesunout kabely pod rozvaděč. Chvilku jsem váhal, jestli tím něco nepokazím, ale podle mě to nevadí ;-).

2016-09-23-16-11-26

Pro jistotu jsem ale kabely neštípal, ale jen později smotal pod rozvaděčem, takže v případě potřeby se dají zase vytáhnout nahoru (už sice ne za lištama uvnitř, ale bokem vedle rozvaděče je na to místo).

2016-09-23-16-11-34

Po vytažení následovalo propípání těch, kterým se ztratilo značení. Naštěstí jich nebylo moc, takže to šlo dobře. Pak všechny zkrátit, oholit a roztřídit dle patra a typu (okno/tamper)

2016-09-23-18-25-57

Všchny okruhy tamperu jsem propojil do série za sebou v rámci každého patra. Je asi zbytečné, testovat dalšími 14ti vstupy, jeslti kabel funguje (na druhou stranu, mám pořád volných cca 70vstupů, takže i to by šlo 😉 ).

2016-09-23-18-37-40

Další na řadu pak přišlo propojení všech přívodních kabelů do okenních kontaktů. Dutinky opět neselhaly a můj poslední úlovek – master dutinka, zvládla spojit v rámci patra všechny kabely do sebe 😉

2016-09-23-18-57-02

Dalším krokem bylo svedení druhého vývodu kabelu z oken do CAT kabelu, ve kterém pak kontakty putují ke Quidovi. Opět dutinky, kleště a jedem ;-). Výsledek pro obě patra pak před zaizolováním vypadal takto.

2016-09-23-19-41-10

Pak natavit bužírky…

2016-09-23-20-04-03

Celé zaizolovat…

2016-09-23-20-06-53

Propojit přívodních 24V do okruhů dolního a horního patra pro tamper a okna…

2016-09-23-20-54-52

A celé ještě jednou zaizolovat, smotat a schovat pod rozvaděčem.

2016-09-27-18-08-57

Tím byla hotová dolní část a zbývalo už jen přivést CATyny (nakonec 3) ke Quidovi a opět napojit do svorek.

2016-09-23-21-26-57

A když bylo propojeno, zbývalo to zapnout (a pak naprogramovat). A zapnutí je vždycky nejhorší…..

2016-09-23-21-34-36

Když jsem to v první chvíli uviděl, moje myšlenka byla “tyvole, nějaká chyba, snad to neshoří” ;-). Naštěstí žádná chyba, jen tím, že všechna okna byla zavřená, tak všechny kontakty byly nonstop sepnuté a tím pádem Quido notifikuje, že je kontakt sepnutý.

2016-09-24-14-39-52-3

Takže zapojeno by bylo, teď ještě SW. Takže jsem začal mapovat a pojmenovávat vstupy z Quida, to šlo dobře 😉

loxoneconfig_2016-09-27_18-21-09

A pak začal testovat, jestli se vše správně detekuje a ukazuje. No, tak tady už to bylo horší. Když jsem okno otevřel/zavřel, tak se nic nestalo. Což bylo fakt divný, protože diody správně zhasínaly a rozsvěcely se.

Co bylo zajímavé, když jsem klikl na žaluzii, stav oken se sám správně obnovil. No tak to už bylo úplně divné, takže jsem začal s hledáním problému. O cca hodinu později jsem zjistil, že jen prvních 60 vstupů pošle UDP paket při změně (a ten pošle stav všeho), zatímco zbývajících 40, na kterých jsou okna píchnuté, notifikaci neposílají.

loxoneconfig_2016-09-27_18-22-21

První myšlenka byla, že je Quido zabugovaný. Ale nedalo mi to a začal jsem pročítat manuál. Hned na začátku manálu je napsáno, že výchozí chování je, že se notifkace posílají všem vstupům. Hledal jsem, jestli to teda neni nějaké omezení pro 100 vstupovou variantu, ale také nic.

spinelterminal_2016-09-27_18-24-49

Chybu jsem nakonec zjistil až přes dokumentaci a specifikaci Spinel protokolu, kde je jeden z řídících příkazů sloužících k vyčtení nastavení notifikací. No, a co byste řekli. Bylo to nastaveno jen na prvních 60. Takže jsem pak další hoďku strávil tím, že jsem zjišťoval, jak sestavit UDP paket tak, aby přenastavil Quida (protože toto se nedá udělat přes webovou konfiguraci).

Naštěstí se povedlo a všechno začalo notifikovat. Ale byl to oser. A abych to už nemusel nikdy opakovat (a ani nikdo jiný, kdo pak o Quido podporu bude mít zájem), doprogramoval jsem to jako další feature do mého Loxone programu. Takže teď, kdykoli se inicializuje spojení, raději se pošle nastavovací paket.

{0x2A,0x61,0x00,0x13,0xFE,0xBA,0x10,0x01,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0x5D,0x0D}

A tak to zase vypadalo, že všechno funguje. Jenže jen do doby, než jsem zrestartoval Loxone miniserver (protože jsem nahrával další novou verzi). Po restartu totiž stav všech oken zmizel.

Stačila chvilka testování a důvod byl jasný. Quido posílá info jen při změně stavu. Jasný že. Jenže když se miniserver zrestartuje, tak se na Quidovi žádná změna nestala a tím pádem žádný stav není (a nějakou remanenci na stav programu jsem nenašel).

Takže zase zpět do dokumentace, tentokrát rozšířit program tak, aby se po restartu Loxonu zeptal Quida, jaký je aktuální stav. A když už se bude umět ptát, tak krom startu se bude ptát i jednou za minutu (nastavitelné), aby v případě ztráty paketu se informace nejpozději za 60s sama zaktualizovala.

{0x2A,0x61,0x00,0x05,0xFE,0xBB,0x31,0x85,0x0D};

A to je on, Spinel paket zjišťující stav Quida. Takže opět nejprve otestovat ve Spinel terminálu a když to běhalo, šup s tím do programu. Tím se program zase o něco nafoukl, ale zároveň stal zase o něco robustnější.

Poslední úprava, kterou jsem ten den dělal, bylo lepší filtrování zpráv z Quida. Jelikož si sám parsuju Spinel protokol, je potřeba správně odlišit jednotlivé zprávy. A protože jsem tenkrát udělal jen takový hala-bala parser (ale stačilo to), stala se mi v cca 2 ráno zajímavá věc.

Jak jsem tak ladil předchozí dva problémy, poslal jsem Quidovi testovací UDP zprávu, která měla vrátit stav zařízení, jeho jméno, adresu a další blbiny. Problém byl, že to vrátil do Loxonu, kde byl můj nedokonalý Spinel parser a ten si to vyložil tak, že někdo právě namačkal v náhodém pořadí všechny žaluzie po celém domě (protože tlačítka na žaluzie jsou také pověšené na Quidovi).

Takže docela veselo, když se začaly žaluzie všechny najednou vysouvat, otvírat a zase zavírat podle toho, co zrovna za stav přicházelo od Quida ;-). Chvilku trvalo, než jsem to zastavil, ale nikdo nasraný od sousedů nepřišel.

chrome_2016-09-27_18-36-06

Takže i to jsem později vyladil tak, aby už parser zohledňoval opravdu jen zprávy, co jsou pro něj, navíc jsem tam přidal podporu podepisování paketů, takže i pozná, které jsou jeho a které případně něčeho jiného.

loxoneconfig_2016-09-27_18-41-15

Poslední věc pak bylo ještě správně zvizualizovat stavy oken, ale to už byla docela brnkačka. Akorát při vytváření logiky “celé patro uzavřeno” jsem si trochu povzdechl, proč nemůžou být AND/OR bloky udělané pro více vstupů než dva. Asi zase nějaká sadomasochistická stránka Loxone vývojářů, co raději obrovský vývojový blok, než malé přehledné bloky 😉

chrome_2016-09-27_18-39-46

A takto to vypadá pak ve vizualizaci. Naprosto suprové, hlavně na kontrolu při odchodu z domu. Do budoucna pak plánuju napojit to na nějakou diodu, případně pípnutí, aby člověk věděl, jestli je to ok a nemusel koukat do mobilu.

A to je pro teď asi vše. Všechno už funguje, jak má, a nevypadá to na nějaké komplikace. Je možné, že při připojování dalších věcí zase na něco narazím, ale pro teď se zdá být podpora Quida stabilní.

Miluju Loxone, nesnáším Loxone

Miluju Loxone, nesnáším Loxone

Loxone je plný rozporuplných věcí. A to se pak bohužel přenáší i na jeho uživatele a programátory.

loxoneconfig_2016-09-24_11-52-38

Z pohledu uživatele je systém na první pohled dokonalý a úžasný. Jde s ním dělat naprosto cokoli, od rozsvěcení žárovek po regulaci spokojenosti drahé polovičky v domě.

Jakmile si člověk oťuká Loxone a vyzkouší si roli uživatele, začne chtít vylepšovat systém skrz Loxone config. Na první pohled to pořád vypadá růžově, všechno se dá naklikat, všechno je snadné.

loxoneconfig_2016-09-24_11-53-40

A tak propojíte svou první žárovku, paráda, jednoduché jak facka. A tak přitvrdíte. Žaluzie. Super, propojeno, žaluzie jedou. A tak ještě přitvrdíte, chci tlačítkem natočit žaluzie do polohy 30% aby dovnitř nešlo vidět, ale pořád bylo uvnitř dost světla.

A najednou ledová sprcha, pot na zátylku, nepřijemné pocity, ale žaluzie nic. Kde je problém? Prostě to nejde. Najednou jste vystoupili ze zóny “Loxone to připravil” do zóny “Takto to dle Loxone nemáte používat” a jste v háji.

A tak hledáte, googlíte, zkoušíte a nic. A najednou najdete dva vstupy na prvku žaluzie “Alp, All” s popisem “Analogový vstup pozice žaluzií %” a “Analogový vstup pozice lamel žaluzií v %”. A najednou vám začne zase svítit sluníčko, začnete mít pozitivní náladu….. ale jen do chvíle, než přijde ještě více ledová sprcha a ještě více se na ten systém naserete.

2016-09-24_11-57-43

Proč? Protože tyhle dva vstupy nejdou použít. A to proto, že v Loxone měl někdo pocit, že to nebudete potřebovat. Tyto vstupy jsou určeny pro nadřazené systémy, kdy tyto systémy absolutně převezmou kontrolu. Takže jakmile vstupy napojíte, přestanou fungovat ostatní tlačítka (teda ony nepřestanou, jen po tom, co je zmáčnete, se žaluzie stejně vrátí do předtím nastaveného stavu).

A důvod? Protože když propojíte vstup Alp/All, tak na tento vstup přivádíte hodnotu 0-100 a už nejde přivádět hodnota “NULL” (“Vyp”). Proč? Protože to asi lidem v Loxone přijde zbytečné.

A tak napíšete na podporu, tam vám jen potvrdí vaši teorii, že Loxone neumí pracovat s hodnotou Null, leda tak, že je vstup odpojen. WTF. Proč nemůžu nastavit konstantu Null a přivést ji tam? Protože si to v Loxone nepřáli.

A tak se smíříte s tím, že zatím žaluzie budete ovládat tak, jak Steve Jobs, ehm pardon, jiný technokratický diktátor vymyslel, a nebudete mít možnost si to upravit komplet podle svého.

loxoneconfig_2016-09-24_11-53-11

Na druhou stranu vás hřeje vědomí, že až budete mít čas, napíšete si bokem vlastní komponentu žaluzie a přes virtuální vstupy ji propojíte do Loxone napřímo na prvek “ovládání žaluzií”. A to je zase něco, proč pak Loxone zpátky milujete. Protože ačkoli klikací nástroj je oškubaný a nedokonalý, stále tam jsou virtuální vstupy, přes které můžete Loxone ovládat z čehokoli jiného (včetně Papouchova Quida) a pak tyto virtuální vstupy propojit kam budete pořebovat.

loxoneconfig_2016-09-24_12-02-15

A tak se s tím sžijete, říkáte si, že to není tak hrozné a po čase se pustíte do dalšího rozšiřování. Například začnete propojovat Vaše tepelné čerpadlo přes Modbus rozhraní. A ze začátku zase vše úžasné, vše připravené. Než to opravdu použijete.

loxoneconfig_2016-09-24_12-03-48

Věřili byste tomu, že v Loxone jsou takový diletanti, že pro analogové senzory vyčítané z Modbusu můžete nastavit Byte-ordering (little/big endian), zatímco když pak tu STEJNOU hodnotu chcete nastavit zpět přes Modbus, tak toto nastavit nejde???? Takže pokud modbus používá jiné než Loxone-ví-to-nejlíp-co-potřebujete nastavení, tak jste v háji a můžete hodnoty jen číst a né zapisovat?

loxoneconfig_2016-09-24_12-04-17

Nebo třeba, že když použijete digitální aktor, tak v případě přivedení stavu 1 se do modbusu zapíše 1B plný jedniček a nejde to změnit? Teď si říkáte, že to nevadí. Jenže ono to pekelně vadí. A to proto, že Modbus nepoužívá 1B, ale 2B datové bloky, takže Loxone nastaví “1111 1111 0000 0000” hodnotu a pokud zařízení testuje jedničku z prava doleva (jsme opět u endinu), tak je Vám digitální aktor totálně k prdu. A pak nezbývá, než to ojebat tak, že uděláte analogový aktor, konstany, přepínače a pošlete to na výstup.

loxoneconfig_2016-09-24_12-04-56

A reakce Loxone supportu? Že prý, pokud by Modbus zařízení bylo vyrobeno správně, tak mu to musí stačit. Takže Loxone developeři už asi sežrali moudrost světa (nebo minimálně tu Jobsovu) a rozhodli se, že budou jiným developerům říkat, že jejich sytémy jsou špatné. A na otázku, proč si pro digitální aktor nemohu nastavit výstupní hodntu, tak na tu jsem odpověd nedostal vůbec.

A tak Vám to zase zkazí ten pocit z dobrého systému. Zase stačilo tak málo, aby někdo trochu přemýšlel, možná to nedejbože i zkusil někde použít a mohlo to fungovat tak krásně. Jenže ne, zase problém.

loxoneconfig_2016-09-24_12-05-40

A jak tak zkoušíte věci ojebávat (pardon ohýbat), tak zjišťujete další a další omezení. Třeba, že Loxone má binární dekodér, ale už jaksi nemají binární kodér. Ten si prý mohu vytvořit sérií AND hradel. Ano mohu, ale proč? Proč panebože proč to tam nemohou mít. To nikoho nenapadlo, že když použiju binární rozklad, tak budu chtít asi použít i binární skládání?

Celé trápení je pak završeno naprosto tragickou podporou interpretovaného C jazyka v Loxone komponentách. První, naprosto pošahaný problém je, že na celý miniserver můžete vytvořit jen 8 (slovy OSM) C-programů. V době, kdy můj mobil umí multitasking a má výkon několiksetkrát převyšující počítač, co doletěl na měsíc, neumí Loxone miniserver více než osm mini prográmků??

loxoneconfig_2016-09-24_12-06-25

Kde se proboha vzala ta magická konstanta 8? To taky postavili stroj, co jim po tisíce letech čekání sdělil jedno číslo a to pak zakódovali natvrdo do Loxone? Proč tam není omezení třeba dle paměti, nebo dle výkonu, nebo doháje cokoli, co má význam. A né OSM.

Další problem s C interpertem je, že interpretuje, co se mu zachce, a ignoruje základní pravidla jazyka C. Kdybyste se rozhodli začít v tom programovat (a to jakože se určitě rozhodnete, protože Vám stejně nic jiného nezbyde), tak prosím vězte, že ten úžasný Pico-C interpret má následující vady:

  • dva C-like komentáře pod sebou, tzn //první , //druhý způsobí, že všechny následující řádky jsou ignorovány a program nefunguje a neřekne proč
  • hvězdičkový komentář /* xxx */ ukončený dvěma hvězdičkama, tzn /** xx **/ způsobí, že následující program nefunguje
  • statement break sloužící k opuštění právě prováděného cyklu způsobí, že opustí vše, co jen lze opustit jde. Takže je schopný vyskočit přes dva for cykly, while i cokoli jiného. Takže break lze použít jen v hlavním cyklu ve funkci, pak je potřeba uměle udělat druhou fci.
  • slovo CONST je sprosté slovo a když ho použijete, dostanete za něj vynadáno
  • slovo STATIC není sprosté slovo, nic Vám neřekne, ale nefunguje, takže taková statická proměná je pak klasická proměná na stacku. Takže se budete dost divit, že si nepamatuje hodnotu
  • pokud na jeden řádek za sebe naskládáte příliš mnoho parametrů, program náhodně skočí na libovolný řádek níže. Takže pokud napíšete fci printf(“debug %x,%x,%x…”,v1,v2,…), místo, aby Vám to pomohlo, začnete hrát takové GOTO BINGO.
  • Samotnou kapitolou je C editor v Loxone. I na Atari800XE byl lepší editor. Ta věc neumí CTRL-LEFT/RIGHT na označení textu, když dáte CTRL+DEL, tak se obsah nehodí do clipboardu, o undo/redo také neslyšeli, věčně se tomu rozpadá obarvování textu, takže buď je vše string, nebo comment. Editor je dobrý tak maximálně na otevření kódu a i to je peklo, protože scrollbary nefungujou jako jinde, ale musí se jen tahat (nefunguje klik).

Kdybych se snažil, asi najdu hromadu dalších věcí. Ale mé podvědomí je podle mě už dávno vytěsnilo, jinak bych si to tady hodil na kabelu od klávesnice. Je to hrůza.

Jenže pak se tím prokoušete, to, co by ve Visual Studiu trvalo 10 minut, uděláte za 2hodiny, ale ono to začne fungovat. Konkrétně teď mluvím o další verzi Quido podpoře, která už umí průběžný refresh stavu, správné nastavení masky eventů, inicializaci stavu při zapnutí Loxone později než Papoucha atd. A najednou je všechno zase dobré.

chrome_2016-09-24_12-07-08

A to je vlastně to, o čem měl být tenhle článek původně. Za poslední dva dny jsem udělal detekci otevřených oken, rozšířil Loxone, aby to celé komunikovalo, propojil Loxone s tepelným čerpadlem a k tomu napojil vodoměry. Jen mě to stálo hromadu nervů, ale když je to hotové, zase ten Loxone miluju ;-).

chrome_2016-09-24_12-07-52

Je zkrátka jen škoda, že vývojáři Loxone nevystrčí své hlavy z prdelí sales-departmentu a místo aby řešili nové, dementnější a ještě dražší komponenty ala Loxone-Air a Loxone-Tree, se raději nevěnují tomu, jak z jejich systému udělat robustní základ pro budoucí rozšířování. Jenže v tom holt není tolik peněz, jako prodat BFUčkům vypínač za 5000kč.

PS: Všem, co čekali nějaký intelektuálnější článek, se omlouvám, ale musel sem si ulevit.  Samostatné články o jednotlivých věcech budou následovat, jen co mi to můj duševní stav dovolí 😉