Vodnický blog

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

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

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.

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.

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.

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.

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?

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.

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.

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ů??

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

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

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