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.
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)
Hehe, tak to mne pobavilo ;-))). Takze nejen ze muzu dat muj puvodni SW zdarma, ale dokonce muzu implementovat cizi kod na zakazku a jeste ho predat zdarma. No tak to se vyplati! 😉
No ale ted vazne. Toto reseni co pises je naprosty nesmysl. Jednak, MQTT mu nic neodpovi, musi mu odpovidat nejaky server. Mqtt je jen komunikacni kanal. Aby fungovalo to co pises, musel by se krom databazoveho serveru provozovat (a samozrejme napsat) jeste nejaky dalsi vlastni server, ktery bude na podobne dotazy poslouchat a odpovidat. K tomu pak samozrejme nutnost napsat jeste nejake administracni rozhrani, kde se bude vse spravovat.
Takze by to znamenalo tunu prace jen proto, aby se pak ovladalo i kdyby treba 10-20cidel, ktere pritom lze snadno jednorazove nakonfigurovat a pak uz bezi, protoze se na nich nikdy v budoucnu nic menit nebude.
Tezko rict, jestli to potrebujes pro nejaky svuj vetsi komercni produkt, ale ja to tak rozhodne zdarma implementovat nebudu 😉
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 ?
Stavet znovu, postavim nejspis vse na Quidech a Loxone jen jako ridici jednotka. Chovani i smer Loxone mi uz opravdu hodne vadi, jenze zaroven zatim nemaji zadnou lepsi konkurenci (nebo o zadne nevim). Takze bych postavil dum jeste vice nezavisly na jejich komponentach, abych pak mohl jen zmenit miniserver za nekoho jineho, kdo by byl vice otevreny a prijemny vuci uzivatelum.
Jakou vyhodu ma ten cip mit misto wemosu? Wemos stoji 1USD, ma rovnou v sobe i wifi (protoze on sam je wifi). Zatimco Vas cip je za 3$ a k tomu asi wifi nema ne? Tzn proc myslite, ze je lepsi? Kdyz uz bych menil, tak za nejaky vetsi wemos board (ne mini, ale klasik) co ma vice vystupu. Nebo treba arduino board. Nebo tak. Duvod proc jsem sel nad wemosem byl, ze uz ho mam vyzkouseny z jinych projektu a mam jich tu doma plno. Takze sem jen sahl do kufriku, dva vyndal a mohl stavet 😉
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.
A jo takhle, tak to je hodne dobre. To objednam a zkusim. Diky
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?
Myslel jsem to spis obrazne ten 1USD. Vsechno co stoji par $$ beru jak 1USD ;-).
Ja je kupuju kolem $2.50 – $2.80 tady http://s.click.aliexpress.com/e/c3Owxl7K
@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 😀
jojo i2c by mel umet, ale jeste sem netestoval. Ale to mcp urcite zkusim, zni to dobre ;-).
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.
Ufff ;-).
Predpokladam, ze jste Loxone integrator co ;-). A ze nemate rad vsechny ty bastly co tu na blogu popisuju, protoze to krati marze integratorum ;-). Protoze 10x extension je rozhodne lepsi nez 1x Quido ;-).
Ale k dotazu. Dokumentaci samozrejme mam, ale jen na kriticke systemy, tzn dum. Mate pravdu, ze dokumentace k zavlaze neni, ale to prave proto, ze je s domem spojena jen na dalku a neni to nic kritickeho.
Pokud bych mel zavlahu resit ala Loxone, znamenalo by to dalsi extension umistit primo k ventilum. Takze 10.000kc misto 500kc. Pokud reseni odejde a ja uz u toho nebudu, neni nic snazsiho nez ventily odpojit a zapojit na ne cokoli jineho. Je to prave o tom, ze je to snadne. Na druhe strane, pokud mam v rozvadeci Quida, je kazdyu vstup/vystup zdokumentavan v dokumentaci. Navic z nej vsechny IO vedou jeste na Krone svorku a pak kabelama, ktere jsou opet oznacene. (Ja vim, i Krone je urcite spatne, protoze neni od Loxonu. Jenze loxon dodvava jen ty debilni spojky, ktere zaberou pul rozvadece).
Bohuzel je to o tom, ze jsem Loxonu veril, kdyz jsem si vybiral co dam do domu a kdyz sem zacal stavet. Jenze to byl jste uplne jiny Loxone. To byl loxone, co ten Vami nenavideny bastl sam podporoval, co mel perfektni komunitu, ktera si pomahala, co mel komunitni forum, co mel super podporu. To nebyl ten kryptofasistickej Loxone co je ted, co nesnasi kazdeho, kdo da do domu neco jineho nez Loxone, co neni schopny delat support a kasle na sve uzivatele.
Takze ano, mate pravdu. Neverim Loxonu, nesnasim ho. Zustal sem na stare verzi, kdy bylo jeste UX zelene a pouzitelne, a ne to odporne co je ted. A uprinme doufam, ze se co nevidet objevi nejaky jiny system, ke kteremu bych treba i presel.
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.
Jenom doplním, že Tecomat nedávno přidalo podporu MQTT protokolu do Foxtrotu.
To zni dobre. Komponenta s nativnim MQTT by resila spoustu problemu
Koukal jsem na ten Foxtrot a nikde jsem na webu nenasel, ktere ten MQTT podporuji. To je ted univerzalni pro vsechny? A znamena to, ze se pro ne musi napsat FW stejne jako treba pro arduino, kde se ten MQTT vyuzije, nebo je na to uz primo nejaky FW hotovy a maji to ty moduly v sobe?
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.
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…..
Lol, dodnes si pamatam, ako na prezentacii v CB ich zamestnanec tvrdil, ze miniserver ma vykonu ze by mohol riadit atomovu elektraren 😀
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.
+ 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 …. 🙂
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.
Nemate nejake foto rozvadece? 😉 19x extension, to uz je docela masakr.
Jak velky dum a co vsechno tim ridite, pokud to neni tajne? 😉
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
Nekecej ;-). Zeby bylo i HTTPS? No tak to je na Loxone super vykon. To bude urcite miniserver za 50.000,- ;-))
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.
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.
No detinske….
Ja mam spis pocit, ze jsme kazdy z trochu jineho “sveta”. Z toho co pisete, tak naklady na Vas dum byly zrejme trochu jinde, nez na ten muj.
Stejne tak mi prijde, ze zatimco muj dum je relativne prcek, obycejny dum, tak ten Vas uz bude neco vetsiho (uz jen proto ze LoxConfig nestaci. Nedokazu si predstavit, co vsechno musite ridit a kolik modulu musite mit, ze i Loxone uznal, ze na to nestaci)
Uprimne, az bude jednou Bitcoin za milion a ja budu stavet svuj dalsi dum s neomezenym rozpoctem, bude mi ho stavet firma a ja nebudu muset resit penize, tak si necham vse udelat na zakazku a bude mi jedno, co to stoji.
A dam tam prave bud KNX, nebo nejakou jinou lepsi automatizaci a nebudu muset bastlit kazdou blbinu a setrit ;-).
Jenze ja ten muj stavel sam a slo mi o to postavahovat naklady bez ujmy na kvalite a komfortu.
Chapu, ze Vam prijde Arduino jako blbost. Je to o uhlu pohledu. Ja ho dal tam, kde mi prijde riziko a problemy odpovidajici cene. To hlavni je Loxone, to co neni kriticky jsou alternativy.
Vse je ale o tom, ze si to resim sam. Pokud bych firme rekl, ze chci neco nad arduinem, nebo aby se mi o to starala, tak mne posle nekam. Jenze, ja tu firmu nepotrebuju.
Pokud budu dum prodavat, nebo se mi nedejboze neco stane, vsechny arduina se muzou vzit a nahazet do popelnice. A nic se nestane. Jen nebudou fungovat druhotna nedulezita cidla, ktere mam stejne spis pro radost nez uzitek.
A v pripade zavlahy se vyhodi jedna krabicka a da tam pripadne treba original Hunter ridici jednotka, co to sepne dle casu a bude klid.
Proste, nic, co by nekdo nezvladl. Ale integrovat to do rozvadece, nebo nad tim postavit neco duleziteho, to je samozrejme blbost a souhlasim s tim.
Jinak ad budoucnost Loxone, myslim si, ze jakmile bude oblast vice zajimava, Google nebo nekdo jiny velky prijde s velkym OS resenim a jednotnym API. To zacnou dodrzovat vyrobci a stane se z toho mainstream, stejne jako v jinych oblastech techniky.
A tim se vse naopak vyrazne zlevni. Protoze platit mesicni poplatky za pouzivani vlastniho domu je nesmysl, na ktery jim pristoupi jen malokdo.
A jestli to zkusi Loxone, proste jen neupdatnu (tak jakt to nedelam uz ted). A pokud me budou chtit nejak donutit, komponenty vytrham a necham si vratit penize. Kdyz jsem Loxone kupoval, meli slogan “zdarma a navzdy zdarma”. Tzn, bylo by to poruseni kupniho ujednani. A o to by se uz dokazali postarat pravnici.
OK – toto zni rozumne.
Ok ;-). Kazdopadne se rad potkam na dalsim Loxone srazu!
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.
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…
Je vtipny, jak obhajujes predrazene veci od Loxone partneru, ale kdyz ti to udela nekdo druhy z jineho oboru, tak se ti to nelibi ;-)))))
Jinak naprosto souhlas, rainbird jednotka je predrazeny shit. Ale jak jsem psal, je to stejne jako s Loxone 😉
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…
bohuzel netusim, note-red-contrib-loxone nepouzivam, mam to napsane prave pres ty GETy.
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)