Automatizace závlahy – softwareová část

Automatizace závlahy – softwareová část

V minulém článku jsem popsal kompletní postup sestrojení automatické závlahy z Arduina, nyní tu zrekapituluju tu programovací část.

 

Začneme od NodeRED, takže vlastně trochu z prostředka. Dost se mi osvědčilo mít Wemosy co nejhloupější, stejně tak po Loxonu toho raději moc nechtít. Takže hlavní logiku mám v NodeRED, kde se dobře upravuje i testuje. Diagram ovládání jde vidět na obrázku nahoře. Defakto jen překlad Http volání do MQTT topiců a k tomu troška logiky.

Pro každý ventil mám v NodeRED jednu Http URL adresu, pomocí které ho ovládám. Takže například zapnutí vody z vodovodního řadu vypadá takto: http://nodered.dum/irrigation/input/water?state=on. Pokud zadám tuhle adresu, chytne ho tento node. Veškeré parametry za otazníkem převede do Json objektu a předá dál.  Takže z Http nodu vylézá objekt typu { “state” : “on” }.

Funkce Payload from state je zase vcelku jednoduchá. Jediné, co udělá, je, že ze vstupního objektu vyčte hodnotu “state” a tu pošle dál. Je to proto, že tato hodnota pak vstupuje do MQTT nodu, přes který se hodnota odešlě na MQTT server. Pokud bychom to propojili napřímo, vložil by se celý objekt.

Takže, jak jsem psal, z { “state”:”on” } se stává “on” a to se posílá do MQTT. Konkrétně jako topic “zavlaha/relay/0”. Pro každé relé mám udělaný samostatný topic, který pak wemosy naslouchají a podle toho relé nastavují. O tom dále.

Poslední, co by asi stálo za zmínění v NodeREDu, je hlídač na automatické vypnutí. Jakmile přijde jakýkoli příkaz na závlahu, automaticky se spouští counter, který automaticky vše po 60ti minutách vypne. Je to proto, že z Loxonu povel například nemusí dorazit a tak by se zalévalo donekonečna. Takto, dokud přicházejí povely, coutner se resetuje. A když nic nedorazí, pro jistotu se ještě vše vypne (PS: Je potřeba použít prvek trigger, nikoli delay. Delay se totiž dalším impulzem neresetuje, ale notifikuje pak všechny).

Od NodeREDu se teď posuňme k Loxonu. Opět, v Loxonu žádná magie. Jen hromada virtuálních výstupů, které volají definované HTTP endpointy. A k tomu pár časovačů, které pak dělají samotnou automatizaci.

 

Výstupy mám pak napojené na tlačítka, abych mohl v případě potřeby ovládat závlahu i ručně. A tlačítka jsou pak automatizované pomocí časovačů.

 

A to je celé kouzlo v Loxonu. Jen tupý program, co ukáže tlačítka a v daný čas ho spustí. To by snad Loxone neměl pokazit :)))). Výhledově pak ještě musím dodělat detekci deště a zautomatizovat napojení retenčky. Tam mne čeká ještě čidlo úrovně hladiny vodz. Takže se pak LoxConfig ještě trošku zkomplikuje.

A teď k Arduinu a programu pro Wemos. S ním ještě nejsem úplně spokojený a jestli si najdu čas, chtěl bych celou logiku ještě více zobecnit a zjednodušit. Logika pro relátka vychází z programu, co jsem měl pro ovládání vánočního stromečku. Ono je totiž téměř jedno, co člověk spíná.

Teda, skoro jedno. Původní program totiž fungoval tak, že poslouchal MQTT topic /christmastree/relaystate. Když přišel řetězec typu 0100100 tak podle toho věděl, že má vypnout první relé, zapnout druhé relé, vypnout třetí a čtvrté, zapnout páté,….. To je fajn, když ovládáte světýlka stromečku, ale naprd, když chcete v danou chvíli ovládat jen některá relé.

A tak jsem firmware upravil tak, že krom kompletního stavu umí ještě naslouchat na více různích topicách pro jednotlivá relé, konkrétně /rele-identifikator/rele/0-n. Takže pak jde například zapnout relé 5 tak, že do topicu /rele-identifikator/rele/5 zapíšeme buď 1, nebo “on”.

A podle toho, co za topic dorazí, se pak buď parsuje celý řetězec, nebo jen konkrétní relé. Krom úpravy na různé topicy ale bylo potřeba ještě vyřešit komplikace se dvěma Wemosama. Z pohledu MQTT jsem nechtěl topicy nijak odlišovat, takže bylo potřeba jednotlivé Wemosy naučit, od jakého indexu relátka obsluhují.

Takže, pro každý modul je samostatný ifdef, kde je definovan jeho mqtt client name (protože ten musí být pro každé zařízení unikátní), od kterého indexu relé tento modul obsluhuje, a které digitální výstupy jsou v jakém pořadí použity.

Jenže, to je přesně to,co se mi vůbec nelíbí. Toto bych chtěl předělat do nějaké online konfigurace, aby po prvním najetí šlo přes HTTP tuhle konfiguraci zadat a nemuselo se při flashování nahrávat vše napevno. Něco podobného už má vyřešený Martin Doubek pro svůj Swifitch. Takže mu na to budu muset mrknout a okopčit :))

Cílem je, abych měl jednotný firmware, který budu moct nahrát do jakéhokoli Wemosu a jen mu pak dynamicky nastavil, které výstupy ovládají která relátka, které topicy má poslouchat, atd. Dalším vylepšením pak ještě chci udělat, aby po sepnutí relé zapsal do nějakého dalšího topicu stav po sepnutí. Tzn aby bylo vidět, že akci opravdu provedl. Jestli se k tomu někdy dostanu, tak bych z toho pak udělal nějaký veřejný firmware, co by si každý mohl stáhnout a nahrát do Wemosu, aniž by musel bojovat s programováním.

 

 

Pomohl Vám náš blog? Chcete nás podpořit? I málo udělá radost 😉
Become a patron at Patreon!
0 0 votes
Hodnocení články
Subscribe
Notify of
guest

36 Komentáře
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Petr
Guest
Petr
5 years ago

Univerzální kód
Zdravím, měl bych lepší nápad než zadávat informace přes webové rozhraní. Co takhle když by se po zapnutí spojil s mqtt brokerem s dotazem: “jaká je moje konfigurace, když mám tuhle mac adresu na síťovce?”
MQTT mu odpoví: “v databázi jsem našel že tato…”

Má to trable, že v programu budeš mít napsaný heslo na wifi a případně i k MQTT
Ale jinak mi to přijde fajn, když se z jakého kdykoliv důvodu wemos restartuje tak hned dostane tu svou správnou konfiguraci do proměnných
Pokud bys nápad chtěl realizovat, můj mail velmi rád přijme ten kus kódu, nebo případně i návrh db kam ukládat ty konfigurace.
Jinak to budu muset vymyslet sám(snad to bude fungovat)

Klapalík
Guest
Klapalík
5 years ago

Zdravím, předem díky za super blog.
Při pročítání mě napadla taková otázka. Kdyby jste stavěl znovu, šel byste opět do Loxone nebo byste stavěl chytrý dům už na něčem jiném?

A také něco k tématu, neuvažoval jste při stavbě závlahy využit raději nějaký čip na rozšíření počtu výstupů místo dvou wemosů? Třeba SN74HC595N nebo něco jako toto: https://www.aliexpress.com/item/MCP23017-I2C-Interface-16bit-I-O-Extension-Module-Pin-Board-IIC-to-GIPO-Converter-25mA1-Drive/32846535877.html?spm=a2g0s.9042311.0.0.27424c4d3F7DT0 ?

Peťan
Guest
5 years ago
Reply to  L

Uvedený čip nemá žádnou vlastní inteligenci. Je to jen rozšíření výstupů (něco jako to Quido). Prostě se to připojí přes I2C k řídícímu obvodu (např. Wemos) a poskytuje 16 I/O. Stačilo by pak použít jeden Wemos a I/O rozšířit pomocí jedné, nebo více těchto (nebo podobných) desek.

Klapalík
Guest
Klapalík
5 years ago
Reply to  L

Přesně tak jsem to myslel, Wemos nevyhazovat, teda jen jeden. Na zbylý připojit dva shift-registry, každý po osmi výstupech. 10x SN74HC595N je za cca 0.6USD.
Wemos za 1USD? Můžu poprosit o odkaz?

msk
Guest
msk
5 years ago
Reply to  L

– na MCP-cku mam postavene vsetky moje boardy, masterboard je vlastne “to arduino” a ioboardy su potom len mcp-cka a pred/za nimi nejake to zrno (tranzistory, optoizolatory). A pokial ma wemos i2c (imho ma), tak k nemu pripojis 8 takychto mcp-cok a mas 128 io portov 😀

LoxTom
5 years ago

Obecne si myslim, ze dotaz ohledne zavlahy pouze nad Loxonem je ta prava otazka. Reseni spravy domu, ktere pouziva Loxone a jine vendory v jednom projektu se mi zda nespravne. Bud verim Loxone a verim, ze tato firma tu jeste dlouho bude nebo neverim a potom to cele stavim na necem jinem (risk management). V takovem pripade je ale otazka, zda nekdo jiny (externi dodavatel, rodina, …) bude schopen v soukromem projektu pokracovat v situaci, kdy ja uz toho nejsem schopen z jakehokoli duvodu. Stejne tak je dulezite, jestli je veden pri domacim pristupu spravny Project management, zda existuje dokumentace toho, co jsem vytvoril, atd…. Pokud nebudu schopen s privatnim resenim pokracovat a ani nikdo jiny, pak je otazka, zda dum bude i nadale fungovat a jak slozite (drahe) bude pripadne ho opetovne rozchodit – na jinem / stavajicim reseni. Z tohoto pohledu otazka, zda jeden komponent stoji $1 nebo $30 je irelevatni (jsou to jen drobne), protoze vyjadreno v penezich je spolehani na industrilani reseni, ktere supportuji exteni dodavatele na trhu vetsinou vyrazne levnejsi i kdyz ve vysledku bude stat statisice korun.

Peťan
Guest
5 years ago
Reply to  L

Zkoumal jste třeba systém Tecomat Foxtrot? Sám neznám Loxone..podle příspěvků v něm jde udělat sousta věcí. Já v Tecomatu programoval pár strojů, většinou v FBD (nějaké části v ST) a jednu jednoduchou, přes internet ovladatelnou elektroinstalaci.

Tento systém se taky používá pro automatizaci budov. Těžko říct, jestli by šel taky “znásilnit” pro ovládání Quida a podobných zařízení. Asi by taky bylo nutné dost toho dodělat.

Václav
Guest
Václav
5 years ago
Reply to  Peťan

Jenom doplním, že Tecomat nedávno přidalo podporu MQTT protokolu do Foxtrotu.

Václav
Guest
Václav
5 years ago
Reply to  L

Vycházel jsem z informací napsaných v jejich časopise:
https://www.tecomat.cz/modules/DownloadManager/download.php?alias=tecoinfo-39-cz
Všechny verze Foxtrotu by měly být stejné. Firmware se psát musí, podpora MQTT znamená, že je dostupná knihovna s funkcemi, které je možno volat.

LoxTom
5 years ago

Chapu vas postoj, ale nemejte mi to za zle, je to juniorsky pohled na svet jak funguje. Je to stejne, jako rikat: nebudu pouzivat Microsoft produkty, protoze z ruznych pohledu jsou spatne a “zdaleka” nedosahuji kvalit najekoho Open Source…. , vysledek je ten a existuje na to mnoho studii, za pouzivani takoveho reseni (= Linux, open source, …) je z hlediska TCO (Total cost of ownership) drazsi, nez pouzivat standardni produkty. Naposledy si takto nabehl Goverment v Cine, kdy rekli jasne – prechazime z Microsfot na Linux. Vysledek po nekolika letech je tristni a radi by se vratili, ale uz to neni tak jednoduche, protoze je to proste drahe. Nikdo nerika, ze Loxone nebo podobne firmy jsou perfektni solution pro vsechny, jen si myslim, ze v soucasne dobe, je to nejlevnejsi reseni a jak jsem jiz uvedl cena za HW (napr. onech 10k za Extension) jsou drobne v pripade jakehokoli nepredpokladaneho problemu. A Nejsem integrator a prodejce Loxone…:) Naopak. Resil jsem s jejich supportem mnoho technickych problemu, kde mi jednoduse rekli: vase pozadavky a vas config je natolik velky, ze narazite na nase limity a nejsme schopni je resit. Proto jsem musel mnoho svych pozadavku zredukovat a prepsat nekolikrat Config from scratch, abych se vesel do Memory a jinych limitu, ackoli dle jejich dokumentace by to mel system Loxone zvladat (velikost configu musi byt < 5MB), ale nezvlada (restartuje se nahodile a jine problem). Ptal jsem se tedy na reseni a odpoved byla jasna – pro takove zakazniky navrhujeme vzdy KNX a podobne systemy, ktere jsou postaveny na silnych a konfigurovatelnych HW komponetech, coz chapu jako jasnou odpoved, ale v takovem pripade se prave dostavame do situace, kdy Chytry dum skutecne stoji s takovym systemem 10 – 20% ceny domu, coz jsou velke miliony, ale chapu. ze by to fungovalo dobre, protoze na tom jsou postavene industrialni centra, hotely a jine komplexy a funguji bez problemu mnoho let. Jen ta cena je trochu vyssi. V tomto pripade jsem se rozhodl pro cely system od Loxone (a akceptoval rizika male firmy), protoze je skutecne (pokud pouzivam vsechny jejich komponenty) vyrazne levnejsi a "nekdo z ulice" = firma, ktera dela Loxone, mi bude schopna nabidnout spolupraci na maintenance stale za nizke naklady, pokud to nebudu schopen delat sam. Takze otazka pro mne nestoji, zda Loxone ani ci ne, ale jedina otazka je: Az bude Loxone koupen nekym jinym, coz se nepochybne drive, ci pozdeji stane, co bude novy vlastnik s celym produktem Loxone delat. Muze v dosavadnim business case pokracovat, ale to mu moc nevydela (i dnes Loxone jako firma vydelava male penize, protoze jejich komponenty jsou levne), a tak bud zarizne celkove Loxone jako takovy a nebo v lepsim pripade zpoplatni SW, ktery je nyni zdarma. A zde jsem jiz videl studie, kolik by takova licence mohla stat a jsou to nemale penize = postupne dorovnani se systemem KNX. Je to na delsi rozpravu, asi ta hospoda je je nejlepsi forum pro tyto diskuse, bohuzel se mi zatim nepostestilo se techto akci zucasnit.

Chtel bych podekovat za vsechny informace, ktere jsou v tomto webu umozneny ke sdileni a vazim si toho, ale opet musim rici, ze nektere nazory na celkove reseni automatizace domu a celkove naklady jsou detinske…..

msk
Guest
msk
5 years ago
Reply to  LoxTom

Lol, dodnes si pamatam, ako na prezentacii v CB ich zamestnanec tvrdil, ze miniserver ma vykonu ze by mohol riadit atomovu elektraren 😀

LoxTom
5 years ago
Reply to  msk

Proto jsem se Loxone ptal (primo v Rakousku a primo od architektu Loxone) zda planuji nejakou “silnejsi” verzi Miniserveru, kdyz je tu “lehci verze – Miniserver Go”. Odpoved byla, ze ne, protoze je to komplikovane kvuli ladeni (vice pameti, jine CPU) a nechteji lezt do zeli silnejsim hracum s KNX a byt jejich konkurenci, protoze ti by je mohli jednoduse zrusit. Pro mne to byla dobra zprava – tim se totiz prodluzuje doba prodeje Loxone nekomu jinemu, ale soucasne jsem jim rekl, ze neni pravda, co je psano v jejich dokumentaci. Dnes totiz jeste nejsem na max. HW konfiguraci pripojenych periferii, kterou by mel Miniserver zvladat (dnes mam: 1 x Miniserver, 1 Air Base, 2 x DMX, 1 x Wire Extension, 1 x IR Extension, 1 x Dimmer Extension, 19 x Extension), a presto mam vykonostni problemy. Zde jsou potom nejdulezitejsi 2 parametry – velikost config souboru a pocet objektu v souboru < 3400). Ten druhy parametr nejsem schopen splnit ani po nekolikere prekonfiguraci a znacnem zjednoduseni (dnes mam 3900 objektu). Za objekty se povazuji i bloky typu "Comment", coz je mrzute, protoze Config bez patricnych komentaru se muze stat rychle neprehlednym. Podstatne pro tyto uvahy je i fakt, ze mit 2 miniservery neresi tuto situaci – pokud by clovek chtel mit porad jen 1 kompletni ovladatelske rozhrani. Toto je potreba si uvedomit, pokud planujete dalsi rozsirovani vasich projektu.

LoxTom
5 years ago
Reply to  LoxTom

+ jsem si myslel, ze chteji stavet sve reference na zakaznicich, kteri maji komplexni konfigurace, ale neni to tak. Bylo mi receno, ze takovi zakaznici jsou pro ne spise nocni murou, protoze odhaluji jejich ruzne slabiny a jejich main focus je na zakazniky s minimalnimi konfiguracemi, typicky statni sprava a rizeni malych infrastrukturalnich provozu (cistirny vod, ….), ktere navic dostavaji dotace od statu na “Automatizace” ….. Ja tomuto business modelu plne rozumim (potrebuji prodavat hodne Miniserveru), ale nepotesi to …. 🙂

msk
Guest
msk
5 years ago
Reply to  LoxTom

Tak ja som videl nasadeny miniserver + 1x relay extension na postupne rozsvetcovanie halogenok vo vitrinach (aby nestartovali naraz a nevyrazili istic). Nic viac sa po nom nechcelo. Ze by tam niekto dal par casovych rele za stotinu ceny ani napad. Samozrejme admin heslo nikto nevedel, jedneho dna to cele lahlo, kupoval sa novy miniserver a robil som do toho novy loxplan :D.

Dáda
5 years ago
Reply to  L

na jinem foru psali, ze z tech bet loxconfigu zjistili, ze se chysta nova verze miniserveru. Mela bejt pry uz na jare. Ted prej na podzim by mohla byt a psali neco i o https, tak snad

LoxTom
5 years ago
Reply to  Dáda

To je zajimava zprava. To, co jsem psal je informace stara cca 3 roky, takze je skutecne mozne, ze dochazi k nejakym posunum. Btw. vykonostni problemy se skutecne castecne vyresily novymi verzemi LoxConfigu. Take jsem se jich ptal, kolik zakazniku ma “komplexnejsi” konfigurace a bylo mi receno, ze je to vzrustajici trend zvlaste v nemecky mluvicich zemich.

LoxTom
5 years ago
Reply to  L

Fotku mohu poslat, nemam ji u sebe, normalni rack, nic zvlastniho (jen znami rikaji, ze to u nas vypada jak v elektrarne…:)). Vetsi potiz je vsak skutecne v kvalitnim navrhu “automatizace” – pred stavbou domu. Elektrikari rikali, ze tolik kabelu nikdy v rodinnem dome netahali (cca 6 km dratu) a jim rikal, ze je temer jiste, ze toho je malo. To se bohuzel potvrdilo a take se potom hromada dotahovala + 10x Air zasuvka. Zdaleka mi neprijde, ze je to kompletni automatizace, zvlaste pak co chybi je AUDIO = Music server, takze zatim vaham – zde kvuli cene vlastniho HW a dalsich dratech pro repro….:). Na druhou stranu si myslim, ze prave AUDIO sluzby vyrazne zkvalitni celkovy pocit. Dnes napriklad pri centralnim zatazeni zaluzii mam 2 stavy, ktere svetelne reknou, zda jsou vsechna okna a dvere zavrene, ale jiste by bylo lepsi to audio, protoze by to i reklo, ktere konkretni okno zustalo otevrene. Tech aplikaci pro AUDIO mam vymysleno spousty a bylo by to prijemne.

LoxTom
5 years ago

OK – toto zni rozumne.

Dáda
5 years ago

Moc pekne. Jen pro info, mel jsem na pozemku cloveka co delaji zavlahy, aby mi to zkoukl a kdyz jsem mu nakonci rek, ze to chci propojit do loxonu a ze tu jejich jendotku rainbird nechci, tak mi rek ze pokud by to tak bylo, tak to delat nechteji, ze maji prace dost. Ze uz se nekolikrat spalili, ze jeden system nerek zavlaze ze ma kropit a za 14 dni zahrada uschla. Pak to firmy hazely na sebe a zkoncilo to u soudu.

killeriq
5 years ago
Reply to  Dáda

mal si mu povedat ze ty mas na pustanie ventilov manzelku pripadne deti 😀

Co si tie firmy uz dnes nevymyslia aby si kupil nejaku sracku co maju na sklade…

elpaso
4 years ago

cauves,
mam dotaz k tem GETu smerem k loxonu. Toto by mel resit node-red-contrib-loxone, ktery rovnou jede pres websockets a tedy by mel zajistit obousmernou komunikaci u “switche”

ale me to nefunguje, nevim proc… v nodered je loxone connected, ale kdyz switch z loxonu spojim se switchem v dashboardu nodered tak se mi to rozhodne nechova jako na https://github.com/codmpm/node-red-contrib-loxone na videu zde https://cloud.codm.de/nextcloud/index.php/s/hNO2hIgnGIDWGqM

switch proste nekomunikuje obousmerene…

elpaso
4 years ago

tak jsem to nakonec nasel…

https://ownsmarthome.de/2018/02/loxone-per-node-red-steuern/

funguje to dobre, ale furt je potreba malinko vic nez 2 bloky (4)

36
0
Would love your thoughts, please comment.x
()
x