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

Pomohl Vám náš blog? Chcete nás podpořit? I málo udělá radost 😉

8 thoughts on “Quido na steroidech

  1. Smekám před tebou, to je perfektní výsledek. Skoro už se mi chce Papoucha objednat ikdyž mi k němu chybí dům 🙂
    Jak to zahýbe s cenou za SW?

    1. Cenu menit nebudu. Ackoli uz jsem na tom stravil fakt hromadu casu, tak to necham takto. Takhle je ta cena imho v hladine, kterou lidi jsou ochotni zaplatit a zaroven pro mne to neni uplne nezajimave.

      Kdyz by to bylo treba 2500kc, tak uz je to v nepomeru vuci cene Quida. Ackoli samozrejme vyssich vydelky by byly prijemny, tak si nejsem jist, jeslti by to zase nesnizilo pocet zajemcu. To je to vecne dilema s pricingem 😉

  2. Co když bude chtít někdo použít více modulů Quido ? Bude muset zřejmě použít více PicoC programů pro ovládání více desek.. Kolik je omezení na počet programů – myslím, že existuje nějaké číslo, které počet programu omezuje (8?) ? Používáte Vy ve Vašem řešení PicoC programy i na něco jiného než na komunikaci s Quidem ?
    Díky.

    1. Bohuzel je to tak, vice Quido = vice programu.

      Teoreticky by slo udelat, ze by to naslouchalo na jednom portu pro vice Quido modulu, ale odesilani by bylo uz slozitejsi. A nejvetsi problem je ve vystupech, tam by pri 2x 100 vystupu byl uz totalni chaos 😉

      Stejne tak i program, pokud by byl pro vice quid najednou, by se o dost zkomplikoval. A ten PicoC mi uplne robustni neprijde, takze jsem rad, ze to funguje aspon takto ;-).

      Omezeni je pry 8, ale nekdo (tusim ze primo na Loxone podpore) mi rekli, ze pry to neni natvrdo, ale jen doporucene cislo. Ale jeste jsem to nezkousel

      1. Ok děkuji.. a používáte PicoC i na něco jiného než na komunikaci s Quidem ?
        Nebo se dají všechny funkce nacvakat klasicky a těch PicoC jinak vlastně není potřeba ?

        1. Zatim mam PicoC jen na Quida. Urcite by i rada jinych veci sla snadneji pres PicoC nez to mastit pres padesat modulu v Loxonu, ale psychologicky se bojim pridavat vic PicoC, “co kdybych je potreboval pozdeji”.

          Momentalne zvazuju jak vyresit ty zaluzie pres PicoC, ale na to to ma zase malo vystupu. Ale teoreticky jsem jsem vcera v dokumentaci narazil na vec, ze z PicoC jdou i nastavovat virtual input/output naprimo, coz by zvedlo o dost kapacitu jednoho PicoC programu (jen by musely byt nazvy natvrdo).

          float getio(char *str);
          Returns the value of the speciefied virtual input or a virtual output.
          Example:
          getio(“VI1”); // Returns the value of the virtual input VI1

          int setio(char *str,float value);
          Sets the value of the speciefied virtual input or a virtual output.
          Example:
          setio(“VI1”,6.33); // Sets the value of the virtual input VI1 to 6.33

  3. Joo, jak já se u toho navztekal, když jsem přišel na to, že tam nejsou logické chybějící bloky. Mimochodem čím parsuješ Loxone QDOčko?

Leave a Reply

Your email address will not be published. Required fields are marked *