Browsed by
Category: Loxone

Články zabývající se Loxone problematikou

Automatizace závlahy – hardwareová část

Automatizace závlahy – hardwareová část

To je děs, jak ten čas frčí. Koukám, že poslední článek je už zase měsíc starý. Ale bylo toho teď zas nějak moc. Pořádal jsem rozlučku, pak jsem dělal o týden později svědka a o další týden později jsme byli na týden u móóře. Konkretétně v Chorvatsku, kde se všichni asi už úplně zbláznili, protože zdražili na dvojnásobek a kvalitu služeb ještě zhoršili. No nic…

Ale k dnešnímu tématu. Už nějakou dobu mám hotovou závlahu po technologické stránce. Jen nějak furt nebyl čas a materiál na automatizaci. A tak jsem pořád chodil kroutit ventilama ručně :).

Něco málo z elektroniky jsem stihl ještě před dovolenou, ale první nasazení se nakonec uskutečnilo až dnes. Není to sice stále úplně hotové, ale už to umí zalévat a já to nebudu muset dělat ručně. Závlahu jsem postavil nad WemosD1 a relé boardem. Hlavice se mají ovládat pomocí 24V, ale stačí jim i 12V.

Bohužel, trochu jsem to nedomyslel s počtem okruhů. Ačkoli jich mám jen sedm, tak mám ještě dva vstupy (retenčka a vodovodní řad), což dělá celkem devět hlavic a tím pádem devět relé. No, takže 8-relé board byl málo. Takže 8+2 relátek. No a druhý problém byl s Wemosem. Devět výstupů se mi nepovedlo rozchodit. Výstup D4 je využívaný stavovou diodou a D8 mi stávkoval.

Takže bylo nutné nasadit wemosy dva :). Ale zase kdo to má, žejo, blbá závlaha řízená dvěma procesorama :).

O napájení se stará zdroj 12V/5A z Aliny (co jsem měřil, vypadá na tyhle účely dostatečně), k tomu pak DC-DC měnič na 12V-5V pro Wemosy a 12V přes relé na jednotlivé hlavice.

Vše pokusně pospojovat, ověřit funkčnost a otestovat, že se to do té krabičky nějak vejde :). Tou dobou jsem sice ještě nevěděl, jak to nakonec udělám, ale to mne nějak moc netrápilo a tak jsem pokračoval dál :).

Nakonec jsem koupil na relátka a Wemosy ještě o trochu vyšší krabičku a samostatné prostupky. Tou dobou jsem už tušil, jak asi komponenty v krabici rozmístím a tak jsem začal vrtat a skládat.

Abych nemusel všechno kompletovat v kuse až venku, připravil jsem si spoustu věcí pomocí různých spojek a konektorů. Takže jsem toho mohl většinu dodělat ještě u sebe v technické místnosti na stole a venku jsem pak už řešil “jen” konektory.

Tady jde vidět finální test komponent před kompletací krabičky. Nakonec jsem to vymyslel tak, že 8-relé board je přišroubovaný ke dnu krabice, zatímco 2-relé, 2x Wemos a DCDC měnič jsou přilepeny pomocí tavné pistole na bocích krabice.

Trochu jsem se bál, jak to bude držet a vypadat, ale je to naprosto supr. Pistole za pár dolarů z Aliny a kolik parády to udělalo.

Myslím, že by to mohlo držet navěky. Že dřív budu potřebovat něco vyměnit, než že by to pustilo. Oba Wemosy jsem si dal schválně USBčkem nahoru, protože ještě předpokládám update firmwaru (a updatu na dálku zas tak nevěřím).

Druhá krabička je pak o dost méně zajímavá. V ní je jen samotný zdroj, přívod 230V a odchozích 12V. Zatím mám zdroj připojený na klasickou 230V zásuvku, protože mne ještě čeká natahání elektriky ven přes chráničky, dozapojení v rozvaděči, atd. Takže zatím to mám napojené přes prodlužku (trošku na prasáka, no…).

A tady už jsou pak další fotky z dneška, kdy jsem se pustil do instalace venkovní části. Postupně jsem si ven zvládl vynosit tak polovinu dílny, jelikož mi furt něco chybělo.

Nejdřív jsem udělal konektory na ventily v levém boxu. To ještě šlo, protože délka kabelů od ventilů byla dostatečná. Takže akorát propojit s konektorem a trochu zpacifikovat jednotlivé kabely, aby v tom byl pořádek.

Horší to bylo v pravém boxu. Tam už kabely nedosáhly, takže jsem to musel prodlužovat a ještě pak napojovat na konektory. To byl fakt opruz.

A takhle pak vypadalo pozapojování ventilů k relátkům.

A tady už první testování. Kupodivu všechno fungovalo hned napoprvé.

Jediný zádrhel je, že když se krabičky zavřely a daly nalevo od ventilů, došel wifi signál. Takže musí být momentálně krabička s Wemosama těsně pod víkem šachty, aby byla online. To ale výhledově vyřeším tak, že dám na půdu ještě jeden Unify AP a nasměruju ho na zahradu. Tím bych měl pokrýt vše i pro další čidla/ovládání, které plánuju.

A takhle vypadá výsledek. Ten červený kabel vlevo je ta zmiňovaná prodlužka. Ta teď bude dočasně vše napájet, než udělám finální venkovní elektriku. Pro jistou je to ještě zabalené v igelitu a zatažené stříbrnou izolepou. A to je pro teď vše. Pak už následovalo ladění SW a propojení s Loxonem. O tom v dalším článku.

 

Propojení dat z MQTT do Loxone pomocí HTTP vstupů

Propojení dat z MQTT do Loxone pomocí HTTP vstupů

Jak jsem psal v minulém článku, kde jsem bojoval s BigClownem, poslední fáze propojení (a vlastně i ta nejdůležitejší), je dostat data ze senzorů, která je posílají přes MQTT protokol do Loxone.

Není to nic složitého, ale napoprvé může člověk v několika místech narazit. V rámci článku budu předpokládat, že už máte nainstalovaný a rozchozený nějaký MQTT server (například Mosquitto) a že už Vám běhá NodeRED (třeba v NASu, RaspPI,…). Pokud ještě nemáte, mrkněte na moje články o NodeRED a Mosquitto, kde je instalace a použití popsáno.

Jako zdroj dat budu používat data z BigClown senzorů. Stejně tak jdou ale data simulovat napřímo pomocí příkazové řádku a příkazu mosquitto_pub. 

mosquitto_pub.exe -h dockerserver.dum -t node/kit-co2-monitor:0/co2-meter/1:0/concentration -m 10000

Takže například tímto příkazem simulujeme čidlo CO2 monitoru na zařízení s IDčkem 0 a posíláme data “concentration” s hodnotou 10000ppm (takže vlastně smrtící dávka :)) ).

A teď už k samotnému NodeRED. Abychom mohli data z MQTT přijmout a zpracovat, vložíme prvek Input – mqtt.

 

Po rozkliknutí prvku mqtt můžeme zadat několik vlastností. Name slouží jen k pojmenování v rámci diagramu, QoS je priorita služeb, která nás nezajímá. A pak Topic. Jako topic zadáme buď absolutní název topicu, nebo nějakou jeho masku. Maska funguje tak, že namísto jedné úrovně zadáme znak +, nebo místo více úrovní znak #. Takže pokud chceme chytat všechny zprávy, týkající se senzoru nula, může maska vypadat takto:

Pokud máme dvě zařízení, můžeme buď masku ještě více zobecnit, nebo přidat dva MQTT inputy a každému přiřadit jinou masku topicu. Já šel druhou cestou, jelikož se mi to více hodilo při ladění a testování.

Tím bychom měli data v NodeRED. Nyní musíme vyřešit, jak data předat do Loxonu. Jsou vlastně dvě cesty. Jedna je data do Loxonu nastavit, druhá pak nechat Loxone, aby si o data řekl. Dneska popíšu cesta, aby si o data Loxone řekl. Z tohoto důvodu si musíme data někam v NodeRED uložit a pak na základě Loxone dotazu mu hodnoty sdělit.

Přidáme další dva prvky do našeho projektu. Tím prvním je prvek Debug. Ten slouží k tomu, že cokoli se do něj pošle, to on ukáže v debug okně. Ideální na ladění a ověření, že data z MQTT přicházejí. Náš testovací příkaz z mosquitto_pub se v NodeRED debugu zobrazí takto:

 

Druhý prvek je Function. Díky ní můžeme v NodeRED psát vlastní JavaScriptové funkce a pracovat s datama. V mém případě jsem si ji pojmenoval DataBuffer a to proto, že ukládá do bufferu všechny hodnoty z MQTT pro pozdější využití.

var dataObjectName;
if ( msg.topic.indexOf("kit-co2-monitor:0") != -1)
  dataObjectName = "BCG-data0";
else
  dataObjectName = "BCG-data1";

var dataObject = flow.get(dataObjectName);
if ( typeof(dataObject) == "undefined" )  
  dataObject = {};

var currentdate = new Date(); 
dataObject.lastModification = "" + currentdate.getFullYear() + (currentdate.getMonth() + 1) + currentdate.getDate() + currentdate.getHours() + currentdate.getMinutes();

if ( msg.topic.indexOf("humidity") != -1)
    dataObject.humidity = msg.payload;

if ( msg.topic.indexOf("temperature") != -1)
    dataObject.temperature = msg.payload;
    
if ( msg.topic.indexOf("pressure") != -1)
    dataObject.pressure = msg.payload;
    
if ( msg.topic.indexOf("altitude") != -1)
    dataObject.altitude = msg.payload;

if ( msg.topic.indexOf("concentration") != -1)
    dataObject.concentration = msg.payload;

if ( msg.topic.indexOf("voltage") != -1)
    dataObject.voltage = msg.payload;

flow.set(dataObjectName, dataObject);

msg = null;
return msg;

Program funguje tak, že nejprve zjistí, ze kterého čidla data přišla. To udělá tak, že v názvu Topicu vyhledá text “kit-co2-monitor:0”. Když tam text je, je to monitor0, když ne, je to monitor1. Název topicu je uložen v msg.topic.

Jako druhý krok pak vezme (a nebo vytvoří, pokud ještě neexistuje) objekt z flow contextu (jedná se o objekt sdílený v rámci jednoho projektu/záložky, nikoli celého NodeRED), do kterého hodnoty uložíme. Tím, že se jedná o flow objekt, budou data dostupná i v jiném prvku “Function”. Rozdíl mezi contextem, flow contextem a global contextem vysvětlen zde.

Následně pak už jen zjistíme, jaký typ hodnoty nám vlastně přišel a uložíme si ji do odpovídající proměnné v našem datovém objektu. K tomu si ještě uložíme informaci o tom, kdy jsme obdrželi poslední změnu hodnot z daného čidla. A to proto, abychom mohli monitorovat, kdy naposledy čidlo komunikovalo.

A tady je drobná obtíž s Loxonem. Bohužel, HTTP Inputs v Loxonu neumí textové hodnoty (debilní co), takže je potřeba to poslat jako číslo. Proto si poskládám číslo ala 201718121822, což znamena 2017-18-12 18:22.

Takže hodnoty máme uložené a nyní musíme naučit NodeRED, aby byl schopný hodnoty servírovat dál. Na to má naprosto super prvek Input – http. Pomocí něj si nadefinujete, na jakých URL adresách má nodeRED poslouchat a jaká data vracet. Takže například chceme, aby na adrese http://nodered.dum/bigclown/kit0 se vracely hodnoty z prvního čidla, na adrese http://nodered.dum/bigclown/kit1 pak z druhého čidla.

Jednoduché, že? Tímto jsme ho právě naučili poslouchat na zvolené adrese. Teď mu ještě nějak musíme předat data. Proto přidáme opět prvek Function a spojíme ho s obouma vstupama a zároveň výstup funkce spojíme s prvkem Output – http response. Ten je k tomu, aby se pro daný http požadavek vrátila nějaká data.

Jednoduché, elegantní :). Zbývá už jen napsat funkci DataGetter, která vezme uložená data z flow contextu a vrátí je na výstup:

var dataName;
if ( msg.req.originalUrl == "/bigclown/kit0" )
    dataName = "BCG-data0";
else
    dataName = "BCG-data1";

var dataObject = flow.get(dataName);

msg.payload = 
    "lastUpdate=" + dataObject.lastModification  +
    " humidity=" + dataObject.humidity +
    " temperature=" + dataObject.temperature +
    " pressure=" + dataObject.pressure +
    " altitude=" + dataObject.altitude +
    " concentration=" + dataObject.concentration +
    " voltage=" + dataObject.voltage;
    
return msg;

Ta funguje tak, že z originalUrl zjistíme, jaká data máme vrátit (jeslti čidlo 0 nebo 1). Data pak získáme pomoci flow.get() a sestavíme z nich textový řetězec v podobě name=value name1=value1….., který pak následně vrátíme jako msg.payload. V objekt msg pak data jdou do http-response, a zobrazí se jako http odpověď. Takže když pak zavoláme adresu http://nodered.dum/bigclown/kit0, jako odpověď získáme toto:

A tím jsme s NodeRED skončili. Data máme z MQTT načtena a umíme je vystavit dál. Zbývá už jen naučit Loxone si o data říct. Do projektu v Loxone Configu přidáme dva HTTP Virtuální vstupy,

které si pojmenujeme třeba BigClown kit 0 a BigClown kit 1.

A každému příkazu zadáme dotazovací url. V mém případě již zmiňovaný http://nodered.dum/bigclown/kit0 http://nodered.dum/bigclown/kit1

Do těchto virtuálních vstupů pak přidáme jednotlivé HTTP příkazy. Pro každou načítanou hodnotu jeden příkaz:

A každému příkazu řekneme, jak má hodnotu z textového řetězce vyparsovat, jak se má hodnota vypisovat, na kolik má být desetinných míst, jednotku, …

Takto například vypadá CO2 čidlo. Má rovnou zapnutou i statistiku, která se zaznamenává jednou za 10minut jakožto průměr hodnot. Parsování se provádí pomocí příkazu “concentration=\v”, je na jedno desetinné místo s jednotkou ppm (pomocí <v.1> ppm).

A to je vše. Tím máme hodnoty v Loxone :). Pro zajímavost, hodnoty Tepota/vlhkost jsou hodnoty z čidel od Sedtronicu, zatímco hodnoty z BigClowna jsou ty s označením “kit0”. Teplota i vlhkost se trošku liší, jelikož čidla Sedtronic jsou pod vypínačem ve zdi, zatímco čidlo BigClownu je vedle postele na stolku. Jde na tom občas hezky vidět, jak se rychleji zahřeje vzduch, než cihla :).

A to je pro teď vše. Příště zkusím dát dohromady ještě návod za pomoci virtuální vstupů. To zatím ještě nemám, protože mne to napadlo až teď při psaní článku :). Myslím, že by to také mělo také jít. Jen je otázka, jeslti nad tím půjdou i statistiky a další věci.

Pokus s Patreonem – podpořte nás

Pokus s Patreonem – podpořte nás

Po sérii pěti článků o zámkové dlažbě tu máme malou odbočku. Tentokrát se týká provozu našeho blogu a Vašeho případného zapojení 🙂

Po tom, co jsme psali o poděkování za víno, které nám dorazilo minulý týden, jsem dostal dalších několik mailů s díky a příslibem tekutého moku. Kromě toho dorazilo také několik podnětů, jak by se dala taková podpora lépe realizovat.

Read More Read More

Elektroměrový ráj, díl druhý

Elektroměrový ráj, díl druhý

Tak jsem dneska dodělal zbytek elektroměrů. A co Vám budu vyprávět, je to paráda 😉

Užitečnost a funkčnost původní instalace jsme ověřili už několikrát, naposledy pak o víkendu, kdy si I. nebyla jistá, jestli vypla varnou desku s připravovaným jídlem pro malého. A samozřejmě si na to vzpoměla ve chvíli, kdy jsme byli už daleko od domova.

Zatímco postaru bychom se museli buď okamžitě otočit a jet zpátky, případně se stresovali po zbytek výletu, tentokrát stačilo jen mrknout na spotřebu varné desky a byl klid ;-).

Drobná nevýhoda 22 ks elektroměrů je, že potřebují 22 vstupů :). A ačkoli se Quido zatím stále drží, zbývá na něm už posledních 20 vstupů. A pak mne čeká další nákup ;-). Na druhou stranu, za tu cenu je to pecka. Kupovat to od Loxonu, tak si sakra rozmyslím každý elektroměr.

Zároveň si musím znovu pochválit tiskárnu na štítky. Díky ní mám všechno pěkně popsané a parádně se v tom orientuje. Jediné na co jsem nepřišel a co asi ta moje neumí je, aby se dal nastavit určitý rozměr a natisknout sérii štítků v kuse oddělených čárou (jako je to o patro níž na jističích, když to dělal p. Hruban). Ale co, stála jen 700, tak má holt omezení.

Pro elektroměry jsem v Loxone configu už vyhradil samostatnou stránku, a i tak je tam docela tlačka :)).

Ještě chci udělat ukazatel “celková známá spotřeba”, abych krom celkové spotřeby domu viděl,kolik jsou spotřebiče co jsou monitorované a kolik ty ostatní. Kdyby mi náhodou někde něco utíkalo, tak ať o tom vím.

A poslední novinka, dorazil mi multimetr z Aliexpressu. Za 29USD (~700Kc), automatické nastavení rozsahů, měří od základních věcí po teplotu, tranzistory, diody, kondenzátory, frekvence a kdo ví co ještě. U nás cena tak 1800Kč +.

Testoval jsem ho zatím jen dneska, ale přijde mi fakt supr (až na tu “lososovou” barvu ochraného krytu. Dalo by se říct, že je dost ošklivá 😉 ). Ale jinak měří supr, rozsahy zvládá měnit pěkně a rychle, teploměr funguje taky parádně.

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

Loxone – tipy&triky – jak získat UUID kteréhokoli prvku

Loxone – tipy&triky – jak získat UUID kteréhokoli prvku

Dneska (vlastně před chvilkou, a rovnou to píšu, protože jsem z toho fakt nadšen) se mi povedlu vskutku parádní kousek…. (a jestli mi někdo řekne, že jste to znali, nebo že to je někde popsáno, tak budu fakt naštvanej 😉 ).

Řešil jsem, jak propojit dohromady Roombu, MQTT, NodeRed, mé vlastní RoombaWalls a do toho Loxone. Cílem je, aby si Roomba uměla sama rozsvítit v dané místnosti a uměla si i sama zapnout virtuální zdi v okamžiku, kdy jsou potřeba.

Na rozsvěcení jsem se stále snažil zprovoznit Websockets (marně), Node-lox-mqtt-gateway (marně), případně pak nějak jednoduše přes virtuální HTTP vstupy/výstupy (lze, ale dost opruzoidně).

Až jsem se rozhodl trochu “blíž” podívat na Loxone webovou aplikaci, abych se podíval, jak vlastně oni komunikují s Loxonem. A tady jsem oběvil (alespoň pro mne) zlatý grál ;-).

Ačkoli v dokumentaci píší, že musíte definovat virtuální vstupy/výstupy pro komunikaci s venkem, není tomu tak úplně pravda. Stejně tak není pravda, že přes HTTP požadavek nelze zapnout napřímo dané světlo, aniž by člověk simuloval HW vstup Loxonu.

Je to totiž o tom, že každý prvek v LoxConfigu má vlastní Uuid. Tenhle Uuid zřejmě nejde zjistit v Loxone configu, teoreticky by asi šlo najít ho v Loxone programu v XML souboru, ale mnohem snáž to jde právě přes jejich web aplikaci.

Stačí otevřít aplikaci v Chrome, přes developer tools (F12) se podívat do záložky “Console” a zmáčknout tlačítko dle potřeby (nebo třeba kliknout na žaluzie, nebo cokoli jiného. A hle. Máte kompletní URL adresu s požadavkem, UUIDem tak, abyste daný příkaz mohli vykonat i odkudkoli jinde.

Tohle jsou třeba žaluzie. A není potřeba žádný debilní virtuální vstup navíc, není potřeba nic donastavovat v LoxConfigu a není potřeba se ani prosit na naprosto nekompetentní Loxone podpoře, kde jen tak mimochodem o adrese /jdev/sps/io nemají ani tušení, jelikož znají jen /dev/sps/io, pomocí které šahají jen na fyzické vstupy/výstupy HW, což je ale k programování dost nešikovné.

A takhle vypadá primitivní NodeRED program na rozsvícení světla. To šedé vlevo je prvek “Inject”, který generuje msg se zprávou “status”:”on”

A takhle pak vypadá HTTP request, pomocí kterého se posílá zpráva on/off do loxonu

A to je vše. A takto tím pádem jde ovládat cokoli uvnitř Loxone, aniž by se museloy na vše dělat virtuální vstupy tak, jak to doporučují EXPERTI z Loxone podpory.

PS: Jen tak mimochodem, NodeRED je masakr. Pokud by v Loxonu vytáhli hlavy ze svých pr*** a nabídli by NodeRED nativně jako nadstavbu, neměli by jejich systém naprosto konkurenci.

Díky kombinaci UUID bloků v LoxoneConfigu a programovacím možnostem NodeRED jdou efektivně naprogramovat věci, které by byly jinak nemožné (viz rozsvěcení místností dle průjezdy Roomby, ovládání virtuální zdí roomby jen když roomba jede,….)

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/

 

 

NodeRED – Propojení všeho se vším, od Arduina po Loxone

NodeRED – Propojení všeho se vším, od Arduina po Loxone

Jak jsem psal v předchozím článku, MQTT i NodeRed instaluji na Ubuntu linuxu. Jde ale rozběhat třeba i na Raspberry Pi  nebo Turrisu (OpenWRT).

Instalace NodeRED je relativně jednoduchá. Do ubuntu jsem musel nejprve doinstalovat aplikaci npm (což jsem zjistil, že je balíčkovací služba pro javascript) a následně pak pomocí npm aplikace nainstalovat NodeRED.

sudo apt-get install npm
sudo npm install -g --unsafe-perm node-red

Po samo-doinstalování obrovského množství dalších navazujícíh balíků měl začít fungovat příkaz `node-red`. Ale prdlajs. Takže další postup pak byl:

sudo apt-get install nodejs-legacy
node -v
##v4.2.6

sudo apt-get install npm
npm -v
##3.5.2

sudo npm install -g --unsafe-perm node-red node-red-admin

Dál bylo potřeba otevřít firewall port 1880, který node-red používá pro komunikaci

sudo ufw allow 1880
##Rules updated
##Rules updated (v6)

A pak už node-red konečně naběhl.

node-red

Welcome to Node-RED
===================

9 Dec 15:41:14 - [info] Node-RED version: v0.15.2
9 Dec 15:41:14 - [info] Node.js version: v4.2.6
9 Dec 15:41:14 - [info] Linux 4.4.0-53-generic x64 LE
9 Dec 15:41:14 - [info] Loading palette nodes
9 Dec 15:41:14 - [warn] ------------------------------------------------------
9 Dec 15:41:14 - [warn] [rpi-gpio] Info : Ignoring Raspberry Pi specific node
9 Dec 15:41:14 - [warn] ------------------------------------------------------
9 Dec 15:41:14 - [info] Settings file : /home/dev/.node-red/settings.js
9 Dec 15:41:14 - [info] User directory : /home/dev/.node-red
9 Dec 15:41:14 - [info] Flows file : /home/dev/.node-red/flows_home-server.json
9 Dec 15:41:14 - [info] Creating new flow file
9 Dec 15:41:14 - [info] Server now running at http://127.0.0.1:1880/
9 Dec 15:41:14 - [info] Starting flows
9 Dec 15:41:14 - [info] Started flows

Další krok je nastavení, aby se NodeRED spouštěl sám po startu. To už nebudu popisovat, protože bych jen kopíroval návod, podle kterého jsem postupoval. Ten jde najít v tomto super článku (bod 3 a dál).

Použití NodeRED

Tak jo, nainstalované to je, co teď s tím dál ;-). Vraťme se k naší ukázce z minulého článku o MQTT. V levym okně máme příkaz na poslání zprávy přes kanál(topic) hello/world. V pravém okně nahoře je pak příjemce této zprávy, abychom viděli, že vše funguje.

V pravo dole pak nasloucháme nové zprávě “bye/world”. Jak jde vidět z následujících screenshotů, při poslání zprávy na “hello/world” se tato zpráva ukáže i na “bye/world”. Jak to?

Protože NodeRED ;-). Jako první jsem pro otestování funkčnosti NodeRED a jeho napojení na MQTT udělal jednoduché přeposlání přijaté zprávy z jednoho kanálu na druhý.

A takhle to vypadá v NodeRED. Vlevo je MQTT consumer, nastavený tak, aby naslouchal topic hello/world

V pravo pak MQTT publisher, který přijatou zprávu pošle po kanálu (topicu) bye/world.

Dole pak mám ještě debug výstup, který zobrazuje přijaté zprávy.

A co loxone, jde to propojit?

No jasně! ;-). Pro testování jsem použil zatím jen REST Api loxone, ale NodeRED podporuje i websockets, navíc jsou pro Loxone už naprogramované přímo rozšíření pro NodeRED (viz dále).

Nyní nám ale pro jednoduchý test stačí RestAPI. Upravíme diagram tak, aby po přijetí jakékoli zprávy v topicu hello/world se nám rozsvítilo (nebo zhaslo) světlo v pracovně. To je cool ne? 😉

Samotné nastavení HTTP požadavku vypadá nějak takto. Nic složitého, jen se zavolá HTTP GET na adrese /dev/sps/io/WebApiTest/PulseDown.

Co se týká URL adresy, tak Loxone dokumentace stojí za starou bačkoru. Podle návodu by měla být adresa /prikaz/control/hodnota, coz ale /dev/sps/io/INPUT/PRIKAZ rozhodne není.

Touto url říkáme, že chceme na virtuální vstup “WebApiTest” poslat Impuls Down-Up. V Loxonu tak musíme tento virtuální vstup vytvořit a propojit se světlem.

A to je všechno. Nyní, kdykoli se objeví zpráva, světlo se přepne. Naprostá paráda. Nevím jak vy ostatní, ale já jsem nadšen. Těch možností, k čemu se to využít, je totiž neomezeně. Díky kombinaci NodeRED+Loxone tak jde do Loxonu dostat spoustu nových dat, od Arduino senzorů, dat z externích databází až po informace z Twitteru, Email nebo cokoli jiného vás jen napadne.

Co dál

NodeRED má obrovskou komunitu a kromě základních bloků (Nodes) má parádní knihovn dalších rozšíření – http://flows.nodered.org/. Jsou tam například i bloky na komunikaci s Modbus, KNX nebo Loxone.

Nyní to chce pořádně vyzkoušet a pohrát si s tím víc. V základu mám ověřeno, že vše funguje. Nyní zkusím zprovoznit nad Arduinem nějaký ten senzor a přes MQTT-NodeRed ho posílat do Loxonu. A uvidíme, jak to bude šlapat. Co jsem zatím testoval, tak problémy žádné, ale běží mi to jen chvilku.

Pokud ale vše pojede opravdu jak má a bude to 100% stabilní, vidím v tom obrovský potenciál. Navíc v případě, že by Loxone pokračoval se svými gestapáckými manýry a ještě více uzavíral jeho systém, tak se takto dá udělat kompletní rozšíření a defakto z architektury “Loxone je ten hlavní” udělat “NodeRED je ten hlavní” a Loxone mít jen jako podružný systém.

Použité linky

forumlink
Link na diskuzní fórum o Loxonu a Arduinu

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