Browsed by
Tag: papouch

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 – propojení s modulem Quido od Papoucha

Loxone – propojení s modulem Quido od Papoucha

Na této stránce najdete návod a Loxone program pro propojení modulu Quido ETH od firmy Papouch s Loxone miniserverem. Díky tomu lze výrazně ušetřit na digitálních vstupech i výstupech. Místo ceny 9.990 Kč za extension se 12+4 vstupy lze koupit za 10.285 Kč Quido modul se 100 vstupy, případně za 6100kč modul 2/32 se 32 relátky.

Program je určen pro síťovou ETH (ethernet) verzi, pro kterou není potřeba dokupovat další RS232/RS485 extension (za další 4249 Kč), která je jinak vyžadována pro připojení Quida či jiného modulu přes klasický Modbus protokol.

Program funguje tak, že dekóduje UDP signály z Quida a nastavuje stav předdefinovaným značkám (v základu pojmenované jako Quido-1 až Quido-100). Ty pak můžete v Loxone configu použít jako klasické digitální vstupy Loxone.

loxoneconfig_2016-09-26_16-05-37

Pro výstupy pak funguje tak, že přes vzorec se slučuje až 32 hodnot do vstupů programu, který poté zapíná/vypíná relátka.

Jak to celé funguje

V základním režimu funguje modul Quido s protokolem Modbus. Ten má ale svá omezení, a to především v rychosti a nutnosti dotazování místo notifikování (oznamování) změn. To pak zatěžuje Loxone miniserver a díky omezené rychlosti dotazování není schopen vždy správně vyhodnotit například stisknutí tlačítek.

Nabízený PicoC program pro Loxone tento problém řeší tak, že namísto dotazovacího Modbusu se využije notifikace změn vstupů pomocí UDP paketů a jejich následné dekódování na straně Loxone.

Z pohledu uživatele, tedy Vás, to znamená jen zakoupit Quido, nastavit správně Quido (viz návod níž) a do Loxone překopírovat bloky z dodaného Loxone souboru spolu s dodaným PicoC programem.

Jak získám přístup k nabízenému programu

Jelikož implementace mne stála nemálo času a nervů, rozhodl jsem se program nedat úplně zdarma. Cenu jsem nastavil tak, aby se Vám to ještě nevyplatilo lopotit se s tím sami a zároveň mně se vyplatilo tomu dělat stránky a nějakou podporu.

Proto jsem cenu nastavil na 2000Kč. Za tuto cenu získáte přístup k této i všem budoucím verzím programu.

Částku lze zaplatit buď přes PayPal nebo převodem na účet. Před samotnou transakcí mne kontaktujte na email [email protected], kde se pak domluvíme na zaslání souborů a případně dalších technických detailech.

Stav implementace

Nabízený program je kompatabilní se všemi ethernetovými (síťovými) variantami Quida od firmy Papouch.

Podporováno

  • podpora až 100 vstupového modulu
  • podpora modulu s až 32 výstupy
  • automatický refresh stavu vstupů pro případ ztráty paketu (konfigurovatelné)
  • v případě restartu Quida automatická obnova spojení i stavu vstupů
  • v případe restartu Loxone automatická obnova spojení i stavu vstupů

Omezení programu

  • nelze pracovat s hodnotou teploměru
  • jeden uživatel hlásil, že v poslední verzi Loxone 10 pozoruje zpoždění UDP paketů v případě, že delší dobu (~1 minutu) mačká tlačítko rychleji než 5x – 10x za sekundu (nikdo jiný to zatím nepotvrdil ani nepozoroval). Při hlubší analýze jsme s ním zjistili, že mu to dělá opravdu jen na verzi 10, v případě downgradu na 9 nebo 8.1 (kterou používám já) se zpomalení neděje. Pokud Quido hodláte používat na detekci stisku tlačítka, jako senzory oken, žaluziová tlačítka, atd. tak nikdy toto omezení nepotkáte. Pokud pro Vaši aplikaci potřebujete přijímat kontinuelně změny stavů rychleji než 5-10x za sekundu, tak v případě, že Váš Miniserveru bude toto zpoždění vykazovat, bude potřeba případně downgrade na nižší verzi, nebo používat nativní Loxone extension na tyto rychlé akce. Bohužel zatím nevíme, zda se jedná o chybu nebo záměr firmy Loxone. Více info o této situaci zde https://www.vodnici.net/community/loxone-a-arduino/quido-a-novy-loxone-config

Záruka

Záruka je na funkčnost v době nákupu. Pokud se Vám můstek nepodaří rozchodit, tak Vám s tím pomohu.

Bohužel, ale není možné dát jakoukoli záruku na to, že bude můstek fungovat s další budoucí verzí. Loxone si může usmyslet cokoli a stejně jako zabil Modbus může zabít UDP. Pokud chcete záruku, kupte si original Loxone příslušenství. Pokud mít vstupy za 10% ceny, kupte si Qudio a můj můstek, ale počítejte s tím, že v nejhorším případě zůstanete u nějaké poslední verze bez dalšího updatu. Osobně si myslím, že to nevadí. Sám používám doma starší verzi, jelikož mi více vyhovuje staré zelene v8 rozhraní, než to nové černé dlaždicové.

Ohlášené a nevyřešené problémy programu

  • v současnosti nejsou známy žádné problémy

Návod

Pro rozchození komunikace je potřeba nastavit zvlášť modul Quido a zvlášť Loxone miniserver. Jako první nastavte například Quido, jako druhé Loxone (pořadí nehraje žádnou roli). Po nastavení obou zařízení začne komunikace okamžitě fungovat.

Návod nastavení Quida

Pro správné propojení Quida a Loxone je potřeba nastavit Quido modul do režimu UDP komunikace s fixní IP adresou.

chrome_2016-09-26_16-01-15

  1. IP adresa zařízení. Zde zadejte IP adresu pro modul Quido. Tuto adresu je pak potřeba nastavit do Loxone programu
  2. Port, na kterém bude Quido naslouchat pro řídící UDP pakety, zde nastavte 10002
  3. Režim Quida. Zde je potřeba nastavit UDP
  4. IP adresa Loxone Vašeho miniserveru
  5. UDP port, na kterém bude Loxone naslouchat. Nastavte 10001
  6. Dejte uložit a vyčkejte na restart Quida

Návod pro nastavení Loxone

  1. ze souboru Quido-loxone.loxone zkopírujte obsah záložky Quido do Vašeho programuloxoneconfig_2016-09-26_16-10-03
  2. V případě, že máte zájem také o ovládání výstupu, zkopírujte z druhé záložky také bloky pro výstupy
  3. ze souboru Quido-loxone.h zkopírujte obsah do komponenty “Program”.  chrome_2016-09-26_16-18-32
  4. Stejný program zkopírujte také do bloku program pro ovládání výstupů.
  5. V obou programech upravte hodnotu konstant c_remote_listen_address aby obsahovala IP adresu a port Vašeho Quida tak, jak jste ji nastavili v bodě 1) a 5) v návodu “Jak nastavit Quido”
  6. upravte hodnotu konstanty c_remote_write_address aby obsahovala Vaši IP adresu a port Vašeho Quida tak, jak jste ji nastavili v bodě 1) a 2) v návodu “Jak nastavit Quido”
  7. V případě potřeby můžete změnit hodnotu c_auto_refresh_every_sec, která určuje, jak často se kontroluje stav Quido vstupů.
  8. Dále můžete upravit hodnotu c_relay_check_period_msec, která určuje, jak často se kontrolují stavy vstupů
  9. A jako poslední, pomocí konstanty quido_bridge_mode nastavte, jestli má program běžet v řežimu VSTUPŮ (hodnota 0) nebo VÝSTUPŮ (hodnota 1).
  10. Uložte změny do Miniserveru Loxone a vyčkejte na restart.

Ukázky funkčnosti

Changelog (seznam změn)

Seznam změn a čísla verzí programu QuidoLoxoneBridge.

Ver Popis změny Change description
v12 (2018/11/22) Přidána kontrola CR bytu na konci UDP a kontrola CRC celého paketu kvůli prevenci kolizím Added check for ending CR byte and calculation of CRC checksum of whole packet
v11 (2018/10/30) Upravena maska na registraci naslouchacího režimu. Pro 60/3 Quida hlásilo Quido chybu ack3 neplatná data. Updated bit mask for registration to listening mode. 60/3 quido reports error ack3 error data
v10 Odstraňena kritická chyba v opravě spadlého spojení, která mohla způsobit 100% vytížení CPU Critical bugfix in connector method. Sometime program can takes 100% cpu
v9 Odstraňeny debug hlášky aby neplnily zbytečně logy Removed debug outputs to save log sizes
v8 Optimalizace(komprimace) velikosti programu Optimization of program to reduce memory footprint
v7 Ovládání až 32 výstupů (relé) Ability to control up to 32 outputs (relays)
v6 Automatická obnova vstupů každých x sekund Automatic refresh of inputs every x seconds
v5 Rozšíření parseru aby zpracovával jen správné 0x0D události State parser filtration to only 0x0D notifications
v4 Automatické nastavení Quida aby automaticky notifikoval všech 100 vstupů Automatic initial setup of inputs to notify over UDP/TCP
v3 Rozšíření na práci se 100 vstupy Ability to read all 100 inputs
v2 Základní funkce pro čtení stavu vstupu Basic functions for reading state-change notifications
v1 Testovací verze Initial test case

Mé články o Quidu

Tady je seznam článků, kde jsem popisoval jak Quida používám u sebe doma:

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í 😉

 

Loxone- tentokráte žaluzie po papoušsku

Loxone- tentokráte žaluzie po papoušsku

Tak jsem si dal další dva dny zapojování a programování. A musím řict, že i když mne občas Loxone vytáčí svou zbytečnou omezeností/nedokonalostí, celkově jsem z chytrého domu fakt nadšen.

2016-08-18-10-15-40

Jelikož jsme si rozplánovali hafo ovladačů na žaluzie po celém domě, došli jsme k číslu 36 digitálních vstupů. Kupovat to od Loxone, tak je náš rodinný rozpočet chudší o 40.000,- a to už je slušná sumička, co se dá například investovat do P2P ;-).

2016-08-19-16-27-08

Takže jsem trochu googlil a jak jsem psal už dřív, našel jsem a půjčil jsem si na zkoušku od Papoucha jejich modul Quido 100/3 Ethernet, tzn 100vstupů, 3 výstupy, komunikace před LAN za bratru 10.000Kč a ještě bez nutnosti kupovat od Loxone jejich RS modul za tuším 4000Kč.

Asi už jsem také psal, že standardně funguje Quido přes protokol LAN Modbus, který je nevhodný na klasická tlačítka. Je to z důvodu, že se dotazuje jednou za 0.1s, což je při kliku na tlačítko málo. Jelikož je Quido připojený přes Ethernet, jde přepnout do různých dalších režimů (HTTP dotazování, TCP client, TCP server, UDP server) a protože v Loxone jdou psát mini-programy, začal jsem ladit komunikaci.

2016-09-07-12-42-59

První verze byla hotová za necelé dva dny. Díky první verzi jsem si ověřil rychlost komunikace a hlavně to, že celý koncept, co jsem si vymyslel, jde realizovat. Pak jsem nechal Quida chvilku u ledu a věnoval se ostatním věcem na domě.

Znovu se na něj dostalo až včera. To když jsme se rozhodli, že už je pomalu čas přestat neustále vytahovat mobil kdykoli chceme někde vysunout či zasunout žaluzii. Je přeci jen trochu opruz před každým koupáním neustále tahat mobil.

2016-09-19-19-54-30

A tak jsem se dal do díla. Než jsem se pustil do zapojování samotného, bylo potřeba ještě doladit nějaké mouchy na mé implementaci komunikace Quido -> Loxone. Jedna z much, že když se Loxone nebo Papouch restartoval, zatímco ten druhý ne, tak nějak spolu přestaly komunikovat.

Taková ta klasická drobnost, kdy po čase Vaše přítelkyně/žena bude potřebovat zatáhnout žaluzii a ono to nepůjde. Stane se to 2x, 3x, 4x a najednou její WAF (wife-acceptance-factor) klesne k bodu mrazu, celý Papouch, Loxone a možná i vy budete muset letět z domu (a poznámka, že může shodit jistič Papoucha/Loxonu a vše restartovat většinou nepomáhá).

2016-09-19-19-55-00

Takže jsem strávil další kus dne tím, že jsem ošetřoval všechny ty stavy, kdy se může něco pokazit. Když se odmlčí Loxone, když Papouch, když přijdou blbá data, když přijde moc dat nebo málo. Znáte to, opruz, blbě se to testuje, ale udělat se to kvůli drahým polovičkám musí ;-).

Ale povedlo se, teda myslím. Všechno, co mě napadlo a co šlo nasimulovat, jsem vyzkoušel a prošlo. Jestli to bude opravdu tak, to se uvidí časem. Přeci jen, pořád je celý dům ve verzi 1.0 beta.

loxoneconfig_2016-09-20_21-42-04

Když byl hotový software, šlo se na hardware. Nejprve připojit žaluziové tlačítka, zaznamenat do dokumentace, který kabel je na co připojený, pak naplánovat propojení Krone svorek v rozvaděči a všechno stáhnout dolů k modulu papoucha a tam pak už jen stažené kabely napojit do 36 svorek (na obrázku -32, 4 jsem dodělával až dnes).

2016-09-19-16-05-43

Na závěr pak jen v Loxone propojit výstupy z Quida protokolu na jednotlivé akce u žaluzií.

loxoneconfig_2016-09-20_21-45-29

Pak už zbývalo zase jen to poslední. Všechno poslat do miniserveru a otestovat to. A světe div se, všechno opravdu fungovalo (pár spínačů blblo, ale vždy to byl jen povolený nebo nedocvaklý drát). A zase to dalo domu další nový rozměr. Najednou se kromě všech těch mobilních blbinek dají narychlo zaklopit/otevřít žaluzie i postaru tlačítkem, paráda.

2016-09-19-16-11-39

Od včerejška jsme pak ještě ladili, co které tlačítko přesně dělá. Například při vstupu do obyváku první tlačítko hýbe všema čtyřma žaluziema, takže po ránu lze osvětlit celou místnost najednou. Impozantní zážitek.

2016-09-19-16-13-16

Druhé tlačítko pak například zvedá jen žaluzii u HS portálu, jelikož je to nejvytíženější žaluzka. Jednak kvůli našemu chození, hlavně pak ale kvůli naší psí madmoisel, která se tamtudy občas prostě musí jít podívat ven.

A to je z žaluzií a Papoucha asi tak vše. Možná poslední věc na závěr. Už jsem dostal několik dotazů ohledně darování/prodání software na propojení Loxone-Quido. Jelikož naprogramovat to vzalo cca 30h práce a určitě s tím ještě nějaká práce bude, rozhodl jsem se tento SW nedávat úplně zdarma.

2016-08-19-13-44-06

Moje představa je taková, že na blogu budu postupně uveřejňovat všechny své rozšíření a vychytávky. Ty jednodušší budou zdarma, ty složitější za peníze (ať už Papouch, nebo do budoucna třeba NFC přístupový modul, …). Každé takové rozšíření bude mít detailní návod se screenshoty, kde půjde vidět jak nastavit externi zařízení (Quida) a jak Loxone a k tomu fotky jak to vypadá v praxi. A pokud to Vás, čtenáře zaujme, dole pod takovým návodem bude nějaký platební systém, který v případě platby postkytne pak už konkrétní SW do Loxone (a všechny budoucí aktualizace).

Co se ceny týká, pro Quido-Loxone komunikaci ji zatím vidím na 1500Kč. Přemýšlel jsem, kolik bych za to tak dal já, abych se s tím nemusel drbat a 1500Kč mi přišlo akorát. 2000Kč bych už asi váhal a pod 1000Kč bych si toho zase nevážil ;-).

Navíc to ušetří hromadu peněz pokud to přepočítáme na Loxone prvky – 100vstupů Loxone = 10.000Kč * 7 (12digitálních vstupů+4analogové), tzn 70,000kč oproti 10.280Kč za Papoucha + 1500Kč za SW.

Dejte mi do commentů schválně vědět, co si o tom myslíte. Mně to přijde férové, ale možná se pletu. Pokud bude větší zájem, urychlil bych návod a rovnou to vystavil. Pokud ne, s dotyčnýma zájemcema to vyřeším kdyžtak zatím bokem a k návodum bych se vrátil časem ;-).