Grower.cz je největší autorita v oblasti pěstování konopí na českém i slovenském internetu. Veškeré sekce jsou přístupné pro anonymní čtení. Pokud se nespokojíš s pouhou návštěvou a chceš se aktivně zapojit do diskusí ve fóru a na chatu, odpovídat na inzeráty a šifrovaně komunikovat s tisíci dalších pěstitelů soukromými vzkazy anebo se pochlubit svou fotogalerií - Registruj se! - Získáš inspiraci i cenné rady!
Jinak muj nazor je, ze to bude priserne nespolehlivy.
1. Kytce muze vyrust jen tenkej stonek - velmi obtizne se bude nastavovat kdy uz ma cidlo zareagovat a kdy ne. navic tohle nastaveni nebude stabilni, kytky muzou rust kazda trosku jinak a muzou byt umistene jinak.
2. Pohyb v pestirne muze znamenat reakci cidla - pujdes zastrihnout nebo rucne zalit a lampa ti zacne jezdit.
3. Samotny prvotni nastaveni cidla bude prekerka - aby drzelo, melo spravnej uhel (vzhledem k uhlu, kterej umi zabirat - cca 15st)
Vzhledem k tomuhle bych to zatim nechal jako nice to have feature a delal to az potom, co budeme mit hotovo a odzkouseno ostatni. Nedam to tedy do specifikace zatim. To ale neznamena, ze se na tom nemuze delat :-)
r-man: k bodu 1: Souhlasím, nebude to úplně jednoduché, ale chci to zkusit. Bude to třeba pořádně otestovat a nastavit. k b. 2: Tento problém by se dal ošetřit softwarově, ale až při testech. k b. 3: Taky souhlasím, takže rameno na kterém bude uchyceno ultrazvukové čidlo, by mělo mít několik kolínek, která by se dala všelijak nastavit a matkami pak utáhnout tak, aby se nastavení ramena zafixovalo. Dobrý podnět. Možná by dobře posloužila stavebnice Merkur. Dvě relátka by jsem potřeboval, aby lampa při sepnutí jednoho, jela nahoru a při sepnutí druhého, jela dolů. Nice to have feature a dělal to až potom.. mi úplně vyhovuje. Jinak by to snad ani nešlo. Je to třeba dělat postupně. Po tvých zkušenostech ze sestavování součástek, které jsi objednal, budu zřejmě taky nakupovat..
r-man "jednoho, jela nahoru a při sepnutí druhého jela dolů" ..jasně, to je o dost elegantnější řešení, na relátka jsem to měl napojené před lety, testoval jsem zvedač. Používal jsem motor přímo s převodovkou, takový podobný: http://www.gme.cz/motory-s-prevodov...35/#dokumentace
Fungovalo to dobře. Měl jsem to zapojené na této krabičce http://www.quasarelectronics.co.uk/...rd-with-box.htm
a nastavil jsem na každý den v období kdy to nejvíc roste časovač, aby lampa o kousek popojela. :-) Taky jsem tam měl napojené na časovač světlo ve skříni a čerpadlo na automatickou zálivku. Propojené s počítačem to bylo přes LPT port. Teplotu ve skříni jsem měřil pomocí tohoto: http://www.oceancontrols.com.au/KTA-145.html
Na dálku se to dalo ovládat pomocí vzdálené plochy. Celkem to šlapalo, dokud neodešel notebook s LPT portem, ale fotky nemám :-(
Ale neni moc spolehlivej. Pri zaplneni pameti presnate v PC ukazovat a muse se resetovat a vymazat data v PC. a nejdou zapojit dva najednou, ...teda jdou, ale jeden neukazuje nic.
Jo a Sysofte - jde zmenit nazev toho fora na to Growduino? Ja bych se pak fakt nerad dohadoval s Carlosem, ze jsme mu zneuzili nazev serveru bez dovoleni...
3.1 nerozumím tomu mapování, můžeš uvést nějaké příklady nebo pseudo-kód?
3.2 - čidla budou pojmenovaná přes web rozhraní - z toho vyplývá nutnost nějaké mapovacího mechanismu (funkce) v kódu pro arduino.
Možná by bylo jednodušší, kdyby vstupy a výstupy, které jsou uvedeny ve specifikaci byly prostě vždy na stejných pinech (např. 1 a 2 budou vždy lampy - když máš jen jednu, bude pin 2 prázdnej) - tím by odpadla nutnost toho pojmenovávání.
3.3 v první a druhé odrážce vidím kontradikci pokud mám předdefinované akce "zapni světlo na pin 1" jaký má smysl tyto jasně definované funkce pojmenovávat? Zůstal bych tedy u první odrážky a druhou vypustil.
3.3.1 časovače - tohle je potřeba dobře vymyslet, protože je to alfa a omega celého projektu. Myslím, že svůj (nezávislý) kalendář by mělo mít každé připojené zařízení (=výstupní, řídící piny), které má smysl časovat.
3.3.2,3.3.3 - akce prostředí. Jestli to správně chápu, tady (a u časovačů) začíná automatizace. Nastavím si parametry a growduino na základě čidel bude samo rozhodovat, kdy se spustí větrák (např.)
3.3.4+ alarmy. Tomuhle moc nerozumim. Alarmy obecně asi OK ale proč je mapovat? Maximálně bych při konfiguraci světla dovolil navíc aktivovat alarm (s parametrem interval) - možná myslíme to samé.
No, když na to koukám, vůbec nerozumím, co znamená to "mapování", které je v textu hojně užíváno.
Ještě k tomu technickému řešení. Z vlákna jsem pochopil, že se spíše kloníte k tomu mít "ovládací panel", rozhraní přímo na arduinu. Já si myslím, že to není dobrý nápad. Už jsem to někde psal, že mi přijde lepší mít stránku (to klikací rozhraní) někde odděleně a arduino bude sloužit jako API dostupné na internetu: pošleš mu požadavek "TEMPERATURE()" a dostaneš odpověď "26". Myslím, že i bez toho, aby bylo potřeba ještě navíc hostovat tuhle web stránku, bude kód pro arduino dost složitý. Navíc, pokud se stránka umístí přímo na arduino, padá výhoda API - nelze už nad ním postavit jiné rozhraní.
Ahoj, dostavam se k tomu az ted...
3.1. - melo by to vypadat treba jako kdyz si na AMD.com volis ovladace ke grafice. Kdyz najedesa neklikas na te strance mysi na support and drivers, tak se rozbali nabidka, kde jsou comboboxy. V tech jde postupne vybrat nejaka volba, pricemz se nezobrazuje volba, ktera neni mozna. Takze na Growduinu napred vyberes cidlo, pak k nemu akci a nakonec vystup. Je to trosku jasnejsi? Az budu kreslit webdesign, tak asi udelam tabulku kombinaci - co jde a co nejde k sobe.
3.2. Ano, to predpokladam. Resp. pokud by byly piny jasny pokazde, tak by to pojmenovanani bylo pouze pro usera, aby vedel kde co ma (treba v pripade, ze bude ovladat jednim growduinem dva roomy).
3.3. Tim je mysleno, ze user bude moci napriklad vybrat akci Casovac a pojmenovat si ji "Svetlo matkarna". Zase - aby vedel kde co ma.
3.3.1. Tady bych spis rekl, ze svuj kalendar bude mit kazda akce, kterou si user vybere a nastavi. Tak pak pojede podle toho kalendare=nastaveni.
3.3.2. a 3.3.3. Aaano :-)
3.3.4. Zase jde o to, ze alarmy pujde ruzne pojmenovavat, aby user vedel kde co ma. K nekterym akcim nebo cidlum alarm pujde mapovat, k jinym to treba user nebude chtit.
Zkusim to jeste trosku vysvetlit lip. Hlavne jak chapu to "mapovani":
Ja si predstavuju, ze kazdy cidlo a akce a alarm jsou vlastne jakysi moduly v tom programu, takovy kosticky lega. User si je muze poskladat podle svyho, jenom musi pasovat na sebe. Muse si je jakkoliv popsat a tim dosahnout urcite funkcionality.
Napriklad:
1. Naklika si "Funkci mereni" a pojmenuje si to treba "Teplota+vlhkost Room1"
2. K tomu si naklika "Akci prostredi" a v ni nastavi pozadovany parametry.
3. K tomu si naklika akci "Alarm", kde nastavi parametry kdy se ma upozornovat, kdy ma spustit alarm.
4. K tomu si naklika vystup rele a taky vystup graf, zase si je muze pojmenovat a nastavit jak chce. Rele bude spinat, graf bude grafovat.
5. A k tomu si naklika jeste vystup alarm, kde nastavi kam se alarm bude posilat.
Tyhle kroky jsou mezi sebou propojeny a tvori jakousi mapu - tomuhle ja rikam to "mapovani". Je to vlastne to napojeni jednotlivych modulu na sebe. Napsal jsem to trosku srozumitelneji?
Ještě k tomu technickému řešení. Z vlákna jsem pochopil, že se spíše kloníte k tomu mít "ovládací panel", rozhraní přímo na arduinu. Já si myslím, že to není dobrý nápad. Už jsem to někde psal, že mi přijde lepší mít stránku (to klikací rozhraní) někde odděleně a arduino bude sloužit jako API dostupné na internetu: pošleš mu požadavek "TEMPERATURE()" a dostaneš odpověď "26". Myslím, že i bez toho, aby bylo potřeba ještě navíc hostovat tuhle web stránku, bude kód pro arduino dost složitý. Navíc, pokud se stránka umístí přímo na arduino, padá výhoda API - nelze už nad ním postavit jiné rozhraní.
To je velka otazka. Ja si predstavuju, ze ta www stranka bude na Arduinu na tom LAN modulu na te karte a ma nejaky rozhrani. Tam v podstate bezi webserver, kterej posila pozadavky na rozhrani kodu Arduina bezicimu na tom CPU co to ma. To by znamenalo, ze pokud si k tomu nekdo nekoupi LAN modul, muze si napsat vlastni webserver a vlastni ovladani.
Nebo si to predstavuju jak Hurvinek valku? :-)
3.4.3 - poslat mail samo arduino určitě nedokáže. Umí webového klienta, takže může zavolat něco jako jinyserver.cz/posli-mail (+parametry jako adresát, předmět a zpráva)
Implemetace takové jednoduché služby na posílání upomínek je na pár řádek kódu, akorát je potřeba aby součástí webserveru byl SMTP server.
Tzn. tady by bylo dobry nastavit ve "Vystup Alarm" krome mailove adresy taky funkcni smtp server? Rekneme ze jsem nekde v siti, kde nejakej smtp server bezi, tak nastavim jeho adresu a pojede to?
Hele přečet jsem si tvoje komenty, ale musím tě zastavit už teď To arduino je strašně hloupé zařízení. Tvoje specifikace té řídící aplikace už nyní naplňuje zadání "středně složité webové aplikace". Jako prohlížeč je poměrně chytrej a dokáže uložit nějaká data, ale to cos tam popsal bude vyžadovat napsání klasické serverové aplikace i s databází. Zapomeň, že něco takového bude hostováno na tom ethernet shieldu
Myslím, že jsem pochopil, co myslíš tím mapováním (a ten nápad se mi líbí). Ale zrovna namodelovat tyto vztahy, aby to fungovalo tak, jak si představuješ, bude celkem obtížné. V javascriptu bych to tedy psát nechtěl (nebudu), v PHP to napsat umím.
Ale myslím, že je to pro začátek celkem overkill. V alfa-verzi bych začal s tím, že sensory a relátka budou na přesně daných pinech. Na tom se postaví ten ovládací panel, kde si piny pojmenuješ a budeš jim moci přiřazovat (mapovat) ty akce prostředí a alarmy + časovače.
je to generační válka, ale my ji vyhrajem... | hands can destroy - the same can help! | every single piece of stuff is good, unless you can't utilize it | ukbassradio.co.uk
"to cos tam popsal bude vyžadovat napsání klasické serverové aplikace i s databází"
--oops, ja jsem proste asi zvyklej z prace na Websphere+Oracle...asi jsem to trosku prepisknul. :-D
"sensory a relátka budou na přesně daných pinech"
--Jen se ujistim, jestli to chapu spravne. To znamena, ze napriklad pin 1-3 na Growduinu bude vzdy casovac a vzdy jedna jasne dana zasuvka/rele+stykac pro lampu. Pin 3-5 bude vzdy na cidlo na teplotu a vlhkost a u nej bude napevno dana funkce mereni a akce "Prostredi" a navic si k tomu budes moct zapnout grafovani a alarm. Taky to bude mit pevne dany vystupni piny pro zasuvky/rele pro ventilator a zvlhcovacku...Takhle nejak?
Ano, v zásadě jde o to, aby na konkrétních pinech sedělo vždy stejné zařízení - tím se to krapet zjednoduší.
Když budem vědět, co na jakém pinu je, bude opět jednodušší pro každé konkrétní zařízení (sensor nebo relé) vyjmenovat všechny povolené funkce - časovače, alarm mezních hodnot.
Co by v dokumentaci mělo být:
- vyjmenovat zařízení a které piny okupuje
- u každého zařízení (určit jeho obecný typ - napadá mě jen relé a sensor) vyjmenovat všechny jeho "akce" - zda je časovatelné, zda z něj může být graf, alarmy, ...
- u každého zařízení zkusit vymyslet povely - funkce k jeho ovládání (př. zapni, vypni, přečti hodnotu, ...)
K funkci "časování" mě napadá: udělejme to jednoduché. Mějme časovač v režimu 24 hodin jako pole hodnot:
[19:30 => ON, 06:30 => OFF] může být časovač pro lampu,
pro ventilaci by mohlo vypadat třeba takto: [19:20 => ON, 06:50 => OFF, 08:00 => ON, 08:30 => OFF, 09:30 => ON, 10:00 => OFF, atd.]
Kalendář je sice hezká věc, ale ve finále skončíš na tom, že třeba lampa i ventilace ti dva měsíce pojede každý den stejně. Proto bych pracoval spíš s "profily", prostě si uložíš takto nadefinovaná pole pod nějakým názvem. Přepnutím profilu se změní režim, podle kterého zařízení spíná.
Co by mělo umět arduino:
- v určeném intervalu periodicky odesílat hodnoty senzorů (ty se budou ukládat do DB)
- na požádání odečíst hodnotu senzoru nebo vrátit stav relé (on/off)
- přijmout a nastavit časovač pro konkrétní pin (kde to má smysl - relé)
- přijmout a nastavit alarm pro konkrétní pin (kde to má smysl - sensory)
- podle časovače spínat relé
- podle alarmu spínat relé (alarm tedy má přednost před časovačem, pokud jsou naměřené hodnoty mimo definované rozmezí)
- na požádání vypnout nebo zapnout konkrétní pin ("override", manuální režim, má přednost před alarmem i časovačem)
- na požádání pro konkrétní pin určit, zda je v režimu časovač, alarm nebo manuální režim
Komunikace s arduinem bude probíhat přes ethernet shield (formát požadavků = komunikační protokol bude upřesněn).
Alarm = akce prostředí - raději bych to ale nazval nějak jinak, protože jde o nějaký hlídač hodnot s automatickou korekcí. Jestli o tom bude uvědoměn uživatel (třeba mailem nebo SMS), je vedlejší.
je to generační válka, ale my ji vyhrajem... | hands can destroy - the same can help! | every single piece of stuff is good, unless you can't utilize it | ukbassradio.co.uk
tak taky pridam svoji spetku do cirkusu, letmo sem si prosel prispevky a verte nebo ne vidim v celem zadani jeden zasadni problem. Nejsou urceny rozsahy realizace - ani technicke, ani financni. Delam vyvoj elektroniky/automatizace a castecne i SW asi 5 let a zakladni chybou projektu je kdyz nenastavi limity a smer hned na zacatku, protoze pak delate deset ruznych reseni desekrat zmenene a rozsirene a z puvodni krabicky za 5tis, kterou jste pred dvema lety chteli mate nedoreseny kolos za 150tis. Vzdalene monitorovani je strasne rozsahla oblast automatizace, realizace z hotovych komponent renomovanych vyrobcu bude nad ramec financnich moznosti pri myslence personalniho vyuziti. Cokoliv jineho je technicky narocne. Osobne jsem se v minulosti systemem rizeni domaci pestirny zabyval, ale z pracovnich duvodu jsem musel projekt prerusit. Osobne bych navrhoval vytvorit 3 verze - pro chude /studenti a vsichni zewlouni/, pro mirne movite /vsichni co uz na sebe dreme sami/ a pak rich verzi pro ty co maji radi hi-tech a nevadi jim za to utracet. Jako srdce systemu bych u nejlevnejsi verze videl male embedded PC zalozene na ARM7 procesoru /napr. STM34F4/ s dotykacem. To se necha poridit okolo 2tis. U vyssich verzi uz bych uvazoval o necem vykonejsim - okolo 6tis se da poridit velmi propracovany HW zaklad.
Nejnizsi verzi bych videl s cenou do 5tis.
Stredni verzi do 15tis.
Nejvyssi verzi do 50tis.
Cene bude odpovidat robusnost provedeni a mnozstvi funkci a rizenych okruhu.
Mechanika, krabicky a kabelaz musi byt v provedeni do vlhkeho prostredi - cca koupelna, jeste lepe pro primy styk s vodou. U nejlevnejsi verze bych pocital s krabickou vne pestebniho prostoru.
Komunikace cidla - sber dat pres RS485, sber dat-server LAN, WLAN. Protokol na deviceNet /cidla - sber dat/ napr. ModBus, sber dat - server pres LAN, mozna taky jeste balit do ModBusu. Osobne bych radeji na deviceNet videl CAN/OpenCan/, ale to je dost slozita vec na implementaci, i pouziti uz neni uplne trivialni, takze se spis priklanim k ModBusu na RS485ce.
Napajeni sberu dat ze site, cidla vzdalene pres kabelaz /kabel FTP - 1.par na RS485, 3 zdvojene pary na napajeni/
Zkusim se v tydnu podivat na konkretni nabidky cidel, embedy na sber dat a rizeni cidel mam na stole, umi to pres ModBus a Ethernet povidat s PC, ma to barevnej dotykac.
Omlouvam se za zmatenost prispevku, zkusim sem behem tydne hodit konkretni navrhy reseni s nacenenim
To jsi asi četl špatně, protože technicky je to už nadefinované. Víceméně se už jen řeší druhy čidel, potažmo periferií, které se připojí na Arduino.
Cena našeho řešení se bude pohybovat - teď odhaduji - kolem 3 tisíc. Samozřejmě počítám jen cenu HW. Na SW a řízení projektu se podílejí dobrovolníci zadarmo.
Možná by se k tomu mohl vyjádřit r-man
je to generační válka, ale my ji vyhrajem... | hands can destroy - the same can help! | every single piece of stuff is good, unless you can't utilize it | ukbassradio.co.uk
Ka'n'ja > souhlasím a zároveň nesouhlasím. Také jsem dělal pár elektronických zakázek, spíše pro soukromníky, ale něco i pro firmy (smlouvou o dílo).
Vždy bylo určité původní očekávání, které s časem rostlo až do do nereálných výšin.
Podobně tomu bylo i u mé pilotní profese (programátor, analytik).
Souhlas - projekt není přesně specifikován a nejsou stanoveny limity.
Nesouhlas - z kontextu vyplývají limity. Nikdo si nepřeje profi průmyslový regulátor za tisíce s profesionálním provedením.
Nyní nerozebírejme ochranu proti prostředí, k té ale také dojdu.
Ale uvažovat v rovině čidel s přenosem dat z čidel po RS485 je spíše úsměvné.
I RS232 zvládne pěkných pár metrů tak proč počítat s desítkami až stovkami metrů (to RS485 zvládá)? To by měl být (dle zadání) rozsah od "mozku" k pěstiteli.
Vycházejme z nevysloveného - Projekt počítá spíše s "krabičkou" mimo stan (tedy ne velkopěstírnou v pronajatém bývalém kravíně), ze které vedou one-wire, analog, UART (či TTL UART) nebo I2C čidla na vzdálenost desítek centimetrů maximálně.
Pochopitelně je možno uvažovat i o výkonějším mozku než je Arduino. Třeba pořídit levný tablet a k němu I/O rozhraní, to je nejlevnější řešení a asi by zvládl i online kameru, ale proč? Tohle má být prcek na jednen stan/pěstírničku. Tohle nikdo neplánuje jako náhradu za zazděného vietnamského zahradníka pro tisíce rostlin.
18-12-2012 v 08:21 AM
pokud mám předdefinované akce "zapni světlo na pin 1" jaký má smysl tyto jasně definované funkce pojmenovávat? Zůstal bych tedy u první odrážky a druhou vypustil.
