Keresés

Új hozzászólás Aktív témák

  • inf3rno

    nagyúr

    Sziasztok!

    Elég kezdő vagyok a témában. Van egy pár hőmérőm, páratartalom mérőm, kvarcom, kijelzőm, szeretnék összeszórni egy alap időjárás állomást, ami kiírja az időt meg az adatokat, ill. átküldi a logot wifin, ha bekapcsolom a gépet. Még RPI-hez vettem a szenzorokat, de nem volt időm belefogni az elektronikázásba. RPI-t sokallom ilyen kis feladathoz árban és teljesítményben is. Ugye működnek majd ezek ugyanúgy Arduino-val is? A wifi pajzs sokat fogyaszt, vagy elmegy egy aksival is vele huzamosabb ideig? Arra gondoltam, hogy valszeg a HTTP és polling kevesebbet fogyasztana, mint a websocket.

    Ti hogyan szoktátok összerakni a műanyag/fém borítását ezeknek az eszközöknek? Honnan szoktatok szenzorokat meg borítást venni? Hol éri meg magát az Arduino-t megvenni?

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz Gergosz2 #1350 üzenetére

    Ezt nem nagyon értem, vagyis nem tudom mit akarsz pontosan.

    Valami ilyesmire gondoltam, de csak néhány adattal. Ehhez gondolom valahogy ki kell marni a műanyagot, hogy belepasszoljon a kijelző.

    Ez a része viszont nekem magas, nem vagyok sem CNC-s, sem szobrász. Milyen eszközök kellenek hozzá? Vagy lehet hasonló dobozt készen is kapni?

    WIFI shiled eléggé zabálni fogja az akksidat .

    Hmm vajon lehet erre watt értéket is találni? Utánanézek.

    [ Szerkesztve ]

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    [link] Itt azt írják, hogy 25-50mA megy át az arduinon és 60-500mA a wifi shield-en használattól függően. (A feszültség gondolom 5V, de csak átfutottam az arduino spec-ét.) Szóval ha a wifi állandóan be van kapcsolva, akkor néhány óra alatt megehet egy 2000mAh-s aksit. Arra gondoltam, hogy teszek bele egy memóriát, amibe elmenti a logot, aztán majd onnan szinkronizálok bizonyos időközönként. Így nem kell állandóan mennie a wifinek. A másik megoldás, hogy rádióval oldom meg az adattovábbítást, ami jóval kevesebbet fogyaszt, de gondolom ott meg a sávszélesség van erősen lekorlátozva, és a géphez is kell venni (vagy forrasztani) valami kütyüt, hogy fogni tudja a jelet. A wifi egy fokkal univerzálisabbnak tűnik. Szeretném, ha hordozható lenne, és egy évig elmenne újratöltés nélkül. Ezt a részét gondolom majd ki kell tapasztalni.

    [ Szerkesztve ]

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz Gergosz2 #1353 üzenetére

    Köszi!

    Doboznál néztem egy csomó műanyagot, valamelyik drágább, mint maga az Arduino, aztán megakadt a szemem ezen a szög egyszerű megoldáson, ami RPI-hez van: [link]. A legvalószínűbb, hogy fából fogom kimarni a dobozt. A műanyaghoz 3d nyomtató vagy fröccsöntő kell, hogy egyedit tudj csinálni, a fémhez CNC vagy keresztapám, aki bádogos és kovács, esetleg kohó, a kőhöz sírköves, aki nem hiszem, hogy tud ilyen apró dolgokat, a fához meg asztalos ismerős. Nekem ezek közül a fa, ami természetesen jön, csak a gyúlékonysága miatt aggódok kicsit.

    Kijelző még nincs, van egy folyadékkristályos, olyasmi, mint ami a régi számológépeken szokott lenni. Nem biztos, hogy ezt teszem bele, lehet, hogy valami komolyabbra váltok inkább, és ezt meg felhasználom másik projekthez.

    Hmm van egy csomó 2.4ghz-es bluetooth usb dongle, azok nem működnének vele? (nagyon laikus vagyok a vezeték nélküli adatátvitel témában)

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz Gergosz2 #1359 üzenetére

    Én vinyót kötöttem rá usb-re, mert javítani kellett rajta valami nem szokványos hibát. Szög egyszerű volt az egész, egyik vezetéket erre kötjük, másikat meg erre, slussz. Még ezt is sikerült felcserélnem. Szóval nem lepődnék meg azon sem, ha a kapcsolási rajz jó lenne, de mégis rosszul lenne összerakva.

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz Gergosz2 #1369 üzenetére

    Jaja, ez a debug az elektronikában. Szoftvereknél is hasonlóan vidám, amikor 1 nap után rájössz, hogy hol volt a hiba. :D Btw. létezik elviekben valami hasonló a test driven development-hez elektronikában?

    (Ha nem lenne ismerős, kb annyit tesz, hogy kis lépésekben haladunk; először írunk egy tesztesetet, amit automatizáltan le tudunk futtatni, aztán utána írjuk meg a szoftvernek azt a kis részletét, ami átmegy a teszten (meg az összes már megírt teszten is), és ezt így váltogatjuk, amíg el nem készül a szoftver. Így gyakorlatilag azonnal kiderül, hogy hol van hiba, és nem kell utólag debuggolni, ami annál költségesebb, minél bonyolultabb a rendszer.)

    [ Szerkesztve ]

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz DougButabi #1394 üzenetére

    Nem tudom irányítástechnika terén mennyire vagy otthon, nézz utána a PID-nek meg a szabályozóköröknek. Mindenképp lesz valamennyi latency mire a kazán felfűti a lakást, szóval jól kell belőni a paramétereket, hogy ne állandó ki-be kapcsolgatás legyen az eredménye.

    Amin először kell elgondolkodnod az a biztonságtechnika, szóval hogy mi történik ha elromlik a szabályozód. Ha mondjuk felrobban a kazán, akkor jobb, ha bele sem kezdesz. Ha 30 fok lesz a lakásban és megromlik a lekvár, az még gondolom belefér. Azért egy failsafe-et érdemes betenni, ami jelzi, ha gond van, pl ha elmentek síelni a télen és a rendszer közben maxra járatja a kazánt, az nem túl kellemes.

    Ha elég jó a routered és csak pár szoba van, akkor meg tudod oldani úgy is, hogy veszel net kábeles szenzorokat, és csak rádugod őket a router-re, a program, amivel szabályozol meg a routeren fut. Vannak ugyanígy net kábeles meg wifis relék. Persze meg lehet csinálni arduino-val is, ha neked az valamiért jobban fekszik.

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz s3toraph #1485 üzenetére

    Ha vezeték nélkülit akarsz, akkor mindenképp kalkulálj vele, hogy a wifi sokat fogyaszt. Inkább rádiósan érdemes megcsinálni, vagy csak néha-néha sync-elsz wifin keresztül egy központi adatbázissal. Szerintem a kütyüre csak egy sima event log-ot tegyél, ami kb így néz ki: timestamp, sensor-id, sensor-data. Ezeket bizonyos időközönként elküldöd az adatbázisnak, amiben egy központi event storage-t csinálsz. Oda szépen lemented az eseményeket, meg a szenzor jellemzőket. Tegyél esemény hozzáadásra adatbázist trigger-t, ami projekciókat hív meg. A projekciókkal transzformálod az eseményeket valami szolgáltatás specifikus formába, pl hogy mennyi volt a napi átlaghőmérséklet, vagy hányszor nyitották a hónapban az ajtókat, stb.. Ha új projekciót adsz hozzá, akkor az összes event-en végigmehetsz visszamenőleg, ha úgy gondolod. A lényeg, hogy a nyers szenzor adat benne legyen egy event storage-ben, onnantól meg már kedved szerint alakíthatod, hogy a webszolgáltatás miről mekkora részletességű infot ad.

    Több dolgot is csinálhatsz. Ha netről látni szeretnéd az adatokat, akkor dyndns-el csinálhatsz egy otthoni HTTP szervert, amit majd állandóan csesztetni fognak a hackerek. Egy nodejs-nek azt mondják legalább 64MB memória kell, de szerintem apache + PHP is kb ugyanott lennél. SQL adatbázisnál valszeg postgresql-el tudnád megoldani a kevés memóriát. Sqlite is keveset foglal, de azzal nincs tapasztalatom, és amúgy sem igazán szeretem az olyan adatbázist, ami nem daemon-ként fut. Szóval ha webszervert és adatbázist akarsz, akkor legalább 256MB memória kell, és legalább 1.2GHz-es processzor, és ez tényleg valahol az alja lehet. Én most próbálok majd kihozni két 128MB, 0.8GHz-es gépből egy adatbázist és egy webszervert, de nem vagyok benne biztos, hogy az adatbázis részét meg tudom oldani ennyiből. Valszeg az is inkább csak event log lesz.

    A másik lehetőség, hogy veszel egy domaint meg egy hosting-ot, aztán annak az adatbázisában csinálod meg az event storage-edet, amibe bizonyos időközönként az itthoni kütyüről feltöltöd az adatokat. Ez egy sima HTTP POST-al mehet, a lényeg, hogy jelszavas legyen. Ha lehet, akkor érdemes TLS titkosítani is és legalább valami ingyenes gagyi certificatet beállítani, különben bárki képes lesz feltolni adatot, ha olyan kedve van. Ha ez nem számít, akkor mindegy. Elvileg lehetséges beállítani úgy is, hogy csak bizonyos helyről fogadjon titkosított adatot a szerver, de ebbe nem folytam bele. Van olyan lehetőség is, hogy digitálisan aláírod az adatcsomagjaidat, aztán FTP-vel felteszed a szerver egy mappájába, ami webről nem hozzáférhető. Ha stimmel a digitális aláírás, akkor feldolgozod a fájlt, ha meg nem, akkor eldobod. Így még ha megszerzik az FTP jelszót, akkor sem tudnak mit csinálni, mert a szerver automatikusan törli a feltöltött fájljaikat.

    Nagyjából ennyi, ha a kütyü lesz a webszerver meg az adatbázis is, akkor szerintem valami komolyabb rpi, ha meg csak adatot gyűjt, és sync-el a szerverrel, akkor meg arduino is elég lehet. Nekem legalábbis ez jött le, de nincs sok tapasztalatom ezekkel a kütyükket. Megtanulni szerintem egyiket sem lehet bonyolult. A költséghatékonyságot meg csak te tudod kiszámolni a fogyasztásból és az esetleges domain és szerver bérlésből.

    [ Szerkesztve ]

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz s3toraph #1488 üzenetére

    Én nem szoktam szerver üzemeltetéssel foglalkozni, ezért nem tudom, hogy mennyire biztonságos. Nekem sokkal kényelmesebb, ha más csinálja, én meg csak felteszem rá a kódomat. Annyit tudok, amikor dyndns-el próbálkoztam pár éve, akkor napi szinten próbálták feltörni a szervert. A kóddal kapcsolatban ha titkosítot az oldal, akkor egy basic http auth elég a beléptetéshez, és mivel csak GET-es kérések vannak, így kb nulla az esélye, hogy alkalmazáson keresztül feltörik. Azért szarvas hibákat ne kövess el, validáljad a bejövő paramétereket, meg ne tedd bele őket http header-be (aka header injection), ha az adott nyelv erre nincs felkészítve, és így tovább.

    Szerintem ne szaladj annyira előre. Koncentrálj inkább arra, hogy vezetékesen meglegyen, aztán csak utána kezdj el foglalkozni azzal, hogy vezeték nélkül meg tudod e csinálni. A szakdogád szempontjából szerintem lényegtelen, hogy vezetékes e vagy sem, és most az számít, hogy időre meglegyen.

    20 sec-re talán elég egy sima polling is, és nem kell sse vagy websockets, tesztelni kell, hogy mennyit bír a kütyü. Teljesen jó, ha mindent sd kártyára mentesz, és a kütyü csinálja a szervert is. Ha nem kell komoly funkcionalitás bele, ahogy írod, akkor felesleges külön adatbázis meg ilyesmi neki. Ha csak annyit csinálsz, hogy a fájlba mentesz, és a kliens oldalon parsolod a txt fájlokat és rajzolod ki a grafikonokat mondjuk d3.js-el, akkor menni fog arduinoval is. Ha nem csak napi és havi szintű lekérdezések vannak, hanem nagyon meg van bonyolítva a dolog, akkor kellhet egy adatbázis, de én úgy látom, hogy ekkora bonyolultságnál nincs szükséged rá, elég a fájlrendszer. Azt viszont nem tudom megítélni, hogy egy arduino elbír e egy log fájlt meg egy webszervert. Nekem eddig az jött le, hogy igen.

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz gyapo11 #1489 üzenetére

    Ahm, szóval ezek szerint az arduino gyenge webszervernek.

    Hmm [link] itt azt írják, hogy a titkosításra nem elég. Akkor marad az RPI vagy külön webszerver.

    [ Szerkesztve ]

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz gyapo11 #1492 üzenetére

    Akkor mégis igaz. Én nem hittem el, hogy tényleg csak kb memóriák vannak az arduinoban. Az rpi-ben 256 meg talán 512 mega is van. Ennyivel esélytelen szerintem webszervert futtatni. Egy nodejs is megeszik 64MB-ot. Én két 128 megás kütyün próbálok majd adatbázist meg webszervert fellőni, de abban is kételkedem, hogy elmegy e bármilyen normális adatbázis (nem sqlite) egy ilyen szerveren.

    [ Szerkesztve ]

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz gyapo11 #1497 üzenetére

    [link] Nagyjából az jön le, hogy RPI nagyon jó statikus tartalmak kiszolgálásában. Ha adtbázis meg komolyabb lekérdezések vannak, akkor meg hajlamos elfogyni a memória.

    @s3toraph

    Szerintem ennyi info alapján nem tudjuk pontosan megítélni, hogy mire kell tenni a webszerveredet. El kellene tervezned, hogy pontosan milyen lekérdezéseket fog támogatni a rendszer. Ezeket előre megírni teszt adatokkal, és tesztelni, hogy mekkora a memória igényük, cpu használatuk, stb. Utána te is meg fogod tudni mondani, hogy egy RPI a maga fél giga memóriájával alkalmas e a feladatra.

    Nekem az jött le, hogy csak napi meg havi szintű adatsorok kellenek, azt statikus csv fájlokból is ki lehet szolgálni, nem kell hozzá sem adatbázis, sem szűrés vagy query. Egyszerűen minden szenzornak csinálsz egy mappát, amiben 1-1 fájlban egy adott nap mérései lesznek, plusz mentesz heti és havi összesítőkbe is adatot nagyobb időközönként. A vezérlésnél is az jött le, hogy semmi komolyabb dolog nem lesz benne. Szóval én nem érzem úgy, hogy a webszerver része ne lenne megvalósítható egy apró gépen, és ehhez külön szervergép kellene. Persze, ha komolyabb szűrés kell a logokban, és muszáj adatbázisba tenni az egészet, akkor az már más. Ebben az esetben érdemes lenne megpróbálni, hogy egy ilyen célra kihegyezett postgresql hogyan teljesít egy pc-n. Ugyanúgy memória használat, stb... terén. Én azt hallottam, hogy 128 mega ramon elfér egy linux mellett egy postgresql. Ezen kívül vannak kis méretű nosql adatbázisok is, de azok nem hiszem, hogy query-ben komolyat tudnának. Konkurrens kérés sem lesz a szerver felé sok, szóval ez is inkább azt támasztja alá, hogy nem kell komoly vas neki.

    [ Szerkesztve ]

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz Babetta-X #1613 üzenetére

    Szvsz itt arról van szó, hogy aki felkért erre a munkára, az rajtad akarja megspórolni a professzionális cuccok árát. Mielőtt bármit elkezdenél, nézz utána, hogy ilyen kütyük készen rendszer kiépítéssel együtt mennyibe kerülnek, és ehhez igazítsad az áraidat, különben bukni fogsz a munkán; rengeteg időt rászánsz majd, kevés pénzért.

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz Babetta-X #1615 üzenetére

    Valszeg nem a 20-30e kategória ami professzionálisnak számít, hanem a 200-300e-es. Nem értek hozzá, csak az eddigi benyomásaim alapján mondom az árakat. Olcsó húsnak híg a leve, szokták volt mondani.

    szerk: úgy nézem 80k-ért már olyan kamerát kapsz, ami vízálló is, olcsóbbak lettek ezek a kütyük.

    [ Szerkesztve ]

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    Azért vannak itt nem gyenge dolgok is :DD :DD :DD
    [link]

    Itt is vannak jó cuccok, elég durva áron a többihez viszonyítva. [link]

    [ Szerkesztve ]

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    Nálam a nyakkendő viszi a pálmát! [link] Azt hiszem befejezem, mert már a munka rovására megy. Sok sikert! :DD

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz bacus #1642 üzenetére

    "Pl a vizes csapokat nem lehet sorba kötni.."
    Ezt kifejtenéd? :D

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz bacus #1646 üzenetére

    Nem a volt köztársasági elnök volt? :DD

    Ja hát a nyomás nem adódik össze attól, hogy sorba teszi a csapokat. Ez a locsoló tervezés külön szakma, nem biztos, hogy nekiállnék DIY módszerrel, talán pár hónap utánaolvasás után.

    Buliban hasznos! =]

  • inf3rno

    nagyúr

    válasz tvamos #1648 üzenetére

    Az itt a probléma, hogy a nyomás és a térfogatáram ugyanakkora marad, mert azonos nyomásúak a csapok (már ha vezetékes vízről jön mind), a cső átmérője meg nem lesz attól nagyobb, hogy sorba kötöd őket. Szóval hiába kötöd sorba a csapokat, 1-2 locsolófej leviszi annyira a nyomást, hogy utána a többire már nem jut elég, és nem nyílnak ki.

    Gondolom azt hitte a doki, hogy a nyomás és a feszültség hasonlóan működnek, amiben azért van valami, mert mindkettő intenzív mennyiség. Emlékeim szerint (bár már régen volt) a soros kapcsolásnál a feszültségek összeadódnak az áramerősség meg változatlan marad, a párhuzamosnál meg fordítva, az áramerősség adódik össze és a feszültség azonos marad. Gondolom a doki ennek analógiájára úgy gondolta, hogy párhuzamosan kapcsolt csapoknál a nyomás változatlan marad, és a térfogatáramok összeadódnak, illetve sorosra kapcsolt csapoknál a nyomások összeadódnak és a térfogatáram állandó marad. A valóságban a feszültség és a nyomás között nincs ilyen analógia, mert a nyomásnak nincs iránya szemben a feszültséggel. Ha sorba kötsz két azonos nyomású csapot, akkor egymást fogják akadályozni és a nyomás és a térfogatáram is változatlan marad. Ugyanez lehet a helyzet párhuzamosan kötött csapoknál is, bár ez utóbbiaknál a térfogatáram valóban megnőhet, ha növeljük a kimenő cső átmérőjét. Na legalábbis én így gondolom.

    Buliban hasznos! =]

Új hozzászólás Aktív témák