Raspberry pi DS18B20 logger hogyan?

Szeretnék csinálni raspberry pi-vel hőmérséklet adatrögzítőt. Olvasgattam már eleget a témában. DS18B20 is van valamerre a fiók mélyén. Van-e valakinek tapasztalata a témában. Lassan ott tartok, hogy nem tudom mivel kezdjem a kipróbálást. Amit eddig láttam az egyik sem volt még kész rendszer. Annak a felét sem tudta amiket szeretnék.
Amit szeretnék, hogy tudjon a kütyü az alábbiak lennének:
- 1-wire 18B20, 18S20 kezelése
- csak a málna elég legyen az adatrögzítéshez, külső szerver, internet ne kelljen
- max. 32 szenzor kezelése
- szenzorok elnevezése
- ne kelljen tápvonalat vinni, parazita táplálás. 2 vezetékre felfűzhető legyen az összes érzékelő
- min/max riasztás email-ben
- min/max riasztás GPIO-n, esetleg nyugtázással GPIO-n
- WEB-es kezelőfelület
- valamilyen SQL-es adattárolás (mySQL)
- választható mintavételi periódus
- grafikon és adattábla lekérdezés a WEB felületen
- kész, kis módosításokkal használható megoldás
Esetleg az alábbi dolgok is érdekelnének:
- 1-wire I/O kezelése
- SNMP adatlekérdezés
- eszközök felvétele WEB felületen

Mindenképp olyan megoldást keresnék, amit azonnal tudnék használni, esetleg csak kicsit kell módosítani.

Végső esetben a teljesen saját megoldás megírásától sem riadok vissza. Ez esetben szívesen veszek tippeket és tapasztalatokat, hogy mit hogy érdemes, vagy hogy nem érdemes megcsinálni.

Hozzászólások

" ne kelljen tápvonalat vinni, parazita táplálás."

Sok érzékelővel, hosszú vezetékkel szívni fogsz.
Örülj, ha 3 vezetéken nem lesz gond. Nálam ~20m gerincen, fa elrendezésben ment. Legtávolabb 30méterre volt az adatgyűjtőtől.
Parazitával többen szívtak, fele ekkora távon is.

Nem jól érted. Legtávolabb 30m volt (pl. 20m gerinc vége + 10m leágazás még onnan vagy a gerinc 15. méterénél megcsapolva + 15m leágazás onnan).

És nem annyit tud, hanem én annyival próbáltam, mivel nem volt tervem 5x megtekerni a kertesházban, logikusan elvezetve ennyi elég volt :)

Amúgy meg gyorsan tesztelhető, csak egy dob UTP kell hozzá. Egyik végére rápattintod az adatgyűjtőd, másikra a DS szenzort. Rögtön kiderül bírja-e a 100->200->300m -t.

Okosabban meg: utána kell nézni az 1Wire specikikációjának. Emlékeim szerint 100m még OK.

Csak ne felejtsd el letekerni azt a dob kábelt, mert dobozban tutira nem fog működni :)

Egyébként én viszonylag sokáig használtam pi-t, arduino kérdezte a szenzorokat,
a pi mysql-ben gyűjtötte, de hamar kinyirta az sd kártyát(kat).
Most az arduino egyből küldi egy neten lévő szerverre.
3 vezetékes módban nemcsak stabilabb, hosszabb, hanem gyorsabban is lekérdezhetők a szenzorok.

Valami tapasztalatod van vele?
A lentebb említett 1wire-I2C bridge-t kezeli?
Ki tudja szedni máshonnan is az adatokat, vagy csak 1 adott helyen várja és adott formátumban a hőmérséklet értékeket?
Adatlista is lekérhető lesz?
Vagy ennek a lekérdezését külön kell megírni?

Ki fogom próbálni, hogy mit tud ebben a környezetben.

Nekem azóta is működik a munin, raspberry és 1-wire párosítás. Most a mikroszkópos laborunkat figyeli, hogy milyen a hőmérséklet 4 ponton.
Amúgy ez az eleje a szenzor kezelés: https://gajdicookbook.wordpress.com/2014/07/13/raspberry-pi-sensing-tem…
Szerintem itt érdemes elkezdeni.

Raspberry-n úgy működik, hogy betöltöd a 1-wire overlay-t boot időben (a boot mappában van az overlays mappa). A /sys alatt megjelenik az összes felismert 1-wire eszköz, és azokat kell csak olvasni egy sima cat-tal. A formátum adott.

Ha van kérdésed, akkor nyugodtan írj.

  • igen, plugint kell csinálni hozzá és a /etc/munin/plugins/ -ba rakni, config és paraméter nélkülit kb így:
    pi@raspberrypi ~ $ roomtemp config
    graph_title Room Temperature
    graph_args --base 1000 --lower-limit 0 --upper-limit 30 --rigid
    graph_vlabel roomtemp
    graph_category sensors
    roomtemp.label roomtemp
    roomtemp.warning 10:25
    roomtemp.critical 8:70
    roomtemp.min -20
    roomtemp.type GAUGE
    roomtemp.colour COLOUR1
    pi@raspberrypi ~ $ roomtemp
    roomtemp.value 23.2
  • az inputot onnan szeded ahonnan akarod a pluginoddal.
  • adatokat rrd toolal tarolja, lekerdezheto azzal vagy vannak egyeb toolok is:
    https://code.google.com/p/rrd2csv/
    kb ennyi:

    pi@raspberrypi ~ $ ./rrd2csv.pl -s e-20m /var/lib/munin/localdomain/localhost.localdomain-roomtemp-roomtemp-g.rrd
    42,
    08/28/2015 06:30:00,23.40
    08/28/2015 06:35:00,23.40
    08/28/2015 06:40:00,23.40
    08/28/2015 06:45:00,23.40
    08/28/2015 06:50:00,0.00

  • Nekem a 6. szenzor után (18m kábel) már problémáim voltak a vezeték hosszal, ha tényleg sokat szeretnél működtetni kell a 3 vezeték. A parazita üzemmód 3-4 DS18B20-al megy stabilan max 13-15 méteren (legalábbis ezt tapasztaltam). +3 méter kábel után nem mindig találta meg az összes DS18B20-at.

    Ahogy megoldottam : Egy egy Atmega 328P gyűjti a 12-14db DS18B20-ról (portonként 2-es 3-mas csoportokban) az infót. A málnabogyó pedig i2c-n kéri el az értékeket és a DS18B20 "MAC"-jeit.

    Amit leírtál azzal bütykölök feles szabad időben, kb egy éve. Ebben benne van a megoldás keresés, ötletelés, arduino-ba botlás, i2c kiismerés... 20*4-es LCD hozzá bütykölése... saját protokoll szerű izé kiötlése raspberry pi és arduino közé i2c-n.

    Sok az amit leírtál ... legalább is nekem. Lesz vele munkád.

    Proci85 is azt mondja hogy két vezetéken felejtsem is el, még 3 vezetéken is bajos. Hasonló dolog van amit te az Atmega-val megcsináltál.
    http://www.maximintegrated.com/en/products/interface/controllers-expand…
    Ezt néztem hozzá. Mivel a tervezési fázisban van csak a projekt. Lehet, ha túl sok idő kell rá, akkor annyiban is marad. Ezért hajlottam volna valami kész vagy félkész megoldás felé.
    Ezt a 1-wire to I2C bride-t pedig jó kérdés mennyire szeretné a program amit esetleg GPIO-ra írtak meg.
    I2C-re eléggé sok-minden felfűzhető. LCD (2x16), I/O (LED, csipogó, nyomógomb), LCD (grafikus).
    Tudom, hogy sok amit leírtam, de reménykedtem, hogy van valami projekt ami elérhető és megvalósítható és tudja java-részét ezeknek a dolgoknak.

    Szendvicspanelként egy I/O bővítő már régóta tervben van. I2C meghajtóval 5V-ra illesztve, 1-wire használható módon (valószínű ez a bridge IC lesz), RTC, akku kezelése (UPS-szerű, leállítás, állapot ellenőrzés), RS-485 vagy RS-232 választhatóan, security-eeprom (hardverkulcs, ezt még keresek), pár LED, nyomógomb, csipogó.

    A raspberry Pi i2c-n kommunikál az atmegával... az atmega 8 portján sorakoznak (pillanatnyilag csak 4 port foglalt) 2-es 3-mas csoportokban a DS18B20-ak. Így megoldottam a hosszú vezeték problémát. Mivel minden port egyesével tudja a maximális hosszt. Ezenfelül 5V-on működik, tapasztalat szerint az 5V-os 1W hálózat kb + 1/4~1/3-al tud hosszabbat.

    A raspberry Pi teljesen jól tudja az I2C-t így ez nem probléma, viszont nem az 1W-s progit kell használni a DS18B20-ak infói kinyerésére, hanem a i2cget és i2cset-et (vagy valami olyat ami ezt tudja)... Saját kis progit (inkább csak script) csaptam össze ami letölti az DS18B20 adatokat az atmegáról és viszi fel SQL-be.

    Viszont van olyan i2c-es hőmérő ami talán megfelelőbb volna neked.
    https://learn.adafruit.com/adafruit-mcp9808-precision-i2c-temperature-s…
    Az ára is több, hat ha ötlet...

    Ha gondolod szívesen elmesélem élőszóban, mit oldottam meg eddig, vagy milyen buktatóim voltak...

    kb: 100-150 lekérdezésenként valamiért kifagy az atmega ha a málnabogyó kérdezgeti i2c- keresztül...
    Viszont ha egy másik atmega kérdezgeti a selav-et akkor több hónapon át zavartalanul megy (percenként 1 lekérdezés az összes érzékélőre).

    Ez a problémám is ide vezethető vissza?

    Elsőre passzolok, ebben a témában lelkes ám tudatlan amatőr vagyok. Tennék egy próbát az I²C busz sebességének csökkentésével. Azt a hőmérőt nem ismerem, amiről fenn írtatok, de ha egy DHT22-t rákötök egy Arduino Nanóra és azt I²C-n kérdezem egy RPi-ről, akkor elég hasonló rendszert sikerült összekalapálni? Mondjuk a DHT22-t nem javasolt túl sűrűn lekérdezni. Mert ha ez jó, akkor teszek vele egy próbát.

    Ave, Saabi.

    A fagyásnak nincs köze a hőmérőhöz, ha simán csak lekérek adatot akkor is ez van.
    kb ~200byte percenként egyszer, ennyiben fér el az érzékelők "MAC"-je és értéke.

    A sebesség csökkentés nem jutott eszembe ... kösz infót. próbálkozom errefelé.

    I2C-hez atmegán wire.h-t használsz vagy valami egyebet?

    Mit gondolsz egy olyan megoldásról, hogy az atmega328 gyűjti a sok DS18B20-ról az adatokat és a Raspberry Pi-vel uart-on kommunikál egy RF transceiveren keresztül? Nem csináltam még ilyet, de most foglalkoztat a gondolat, mert kb 50 m-t kéne áthidalni és nem szeretnék kábelt húzni ekkora távon.

    Bár nem minden kritériumodnak felel meg, de én ezzel csinálok hasonlót: http://www.tinycontrol.pl/en/lan/podstawowe_wlasnosci.html

    1wire bus-on 6 érzékelőt alapból kezel, trigger-t, riasztást tud (e-mail, snmp-trap, saját digit kimenet, stb) - emiatt 1 nem elég 30 érzékelőhöz, viszont így csoportonként rövidebb a bus, az eszközök meg TCP/IP-n elbeszélgetnek.

    Az adatgyűjtést ugyan központosítani kell (én pl. egy virtual gépen check_mk-val figyelem snmp-n)

    -------------------------------^v-----------------------------------
    "Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

    A HW nem hiszem, hogy akadály lenne. Jó lenne, ha valaki beleásna kicsit a lelkébe, mert egy modulárisabb GPL FW-el sokmindent ki lehetne hozni belőle.

    -------------------------------^v-----------------------------------
    "Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

    :D pedig pont a HW az akadály. A mikrokontrolleren lévő program mindennel együtt pár KB lehet (max. 128 KB). A RAM 3KB. Hol szeretnéd tárolni 1 év adatait, pl. 10 perces felbontásban, 8 eszközről?
    Írhatsz rá te is programot, emlékem szerint PIC18F67J60 van benne. Csak ne csodálkozz, hogy egy Hello World el fog tartani egy darabig. Ezek a "dobozok" úgy jók ahogy vannak "gyárilag".

    Gyors utánaszámolással nekem az 1 év 8db és 10 perc számokkal 3,6MB jött ki, nem megabit hanem megabájt. Sok időm és kedvem sem volt keresgetni, de az első találtat ekkora méretben 6000 Ft körül jött szembe.
    A méret számolással még nem vettem figyelembe a lapméreteket, amivel célszerű számolni. Ez még tovább növelheti a méret. Majd ha minden kész van, kereshető a flash-ben az adat, tud belőle rajzolni, kezeli az SNMP-t, megy a webes része is, stb... akkor talán kész van.
    Nem évekig szeretném fejlesztgetni ezt a dolgot.
    Nekem egy kicsit egyszerűbbnek tűnik a málnás megoldás és testre-szabhatóbb.

    Két dologban is tévedtem!
    No, akkor online számolok egyet:

    1 év=365 nap x 24 óra x 6 (ez a tíz percenként==felbontás), azaz 52.560 tétel
    Az adat mérete:
    8db 0,2 fok felbontású hőmérőnél a -70..380 fok tartományban 2 bájt x 8 = 16 +
    A 52.560 tétel ábrázolásához log2(52760)->15,68 ->16bit ->2 bájt
    Összesen: 52.560*18=946080 bájt

    1 Mbájt=1048576
    Tehát marad 1048576-946080=102496, ami több mint 100kB. Ebben ízlés szerint leírhatod bazinagy XML-ben ;) a rekordok értelmezését/átalakítását, illetve a kezdő timestamp helyét és abszolút értéket.

    A flash ára pl.: M25P80-VMW6G - ha lemegyek a boltba, számlával 323Ft.

    Nem tudom mit értesz lapméreten. A fenti eszköz bájtonkén írható. A 256 bájtos méretű lapot 18 bájt /rekord esetén 15x kell írni+törölni évenként, azaz van néhány száz év tartalék.
    Maga a szerkezet - hőmérők nélkül, de rtc-vel együtt - megépíthető kb. 3500Ft-ból, és egy CR2032 elemrő legalább egy évig megy. Ha lekérdezés, grafikon, web stb. kell, akkor helyette lehet pl. PIC-MICRO-WEB is. (A flash olcsón kicserélhető nagyobbra/megépíthető olcsóbban.) Bár nem fér bele az sql szerver. ;)

    Nekem az idő bélyeg, mivel érzékelőnként lehet más periódus, az érzékelő ID-ja (csak belső 1 bájtos), és a 2 bájton tárolt hőfok, valami 9 bájtra jött ki esetenként.
    De amúgy meg eszembejutott, hogy amit próbálsz leírni az kb 10 éve itt van a polcon, DALLAS-nak van egy spec IC-je, csak áram kell rá. Benne van minden. Soros porton kiolvashatod, és ott is kell beállítani. De csak 1 hőmérési pontja van, ahol az IC van.
    A lényeg, programoztam nem is keveset és a mai napig programozok néha mikrovezérlőket. Pont ezért tudom, hogy most nem ez kell nekem.
    10-15 féle ethernetes PIC panel van, ami vagy dev., vagy prod., de nem ez kell.

    Még 1 dolog: többen írták, hogy a málna csak 8-10 DS szenzort tudott kezelni. Egyszerűen ennyit látott. Ennek nézz utána, nehogy ez legyen a szűk keresztmetszet. Ez 2 éve volt, nem tudom azóta változott-e. Nálam tisztán Arduinon már akkor is gond nélkül ment 2x ennyi is.

    Ha mindenkepp 2 vezeteken akarod, akkor megprobalkozhatsz azzal is (felteve, hogy 5V-rol eteted), hogy minden erzekelo melle teszel 1-1 diodat es kondit. A diodan keresztul toltod a kondit, az adja a tapot a homeronek, de egyebkent csak kommunikalnak a vezeteken az eszkozok. Ha hagysz idot a kondik feltoltesere, nem lesz gond a tappal. 3.3V-nal mar a dioda nyitofeszultsegebol adodo eses sok lenne, szoval kell az 5V. (a sima parazita mod is hasonloan mukodhet, de a homeron kivul tobb hely van a kondinak)

    --
    Hi, welcome to Fight Club.
    First of all, how did you hear about us?

    Nálam kb 200m kábelen van 10 szenzor, szigorúan line-ként kötve. Problémamentes.

    Az olvasgatások után meg sem próbáltam a 2 vezetéket UTP kábel volt, azon megy a mérőkhöz oda-vissza a kábel egy központi dobozos elosztón.

    OpenWrt alatt gyűjtöm az adatokat, egy Tp link 1043 nd volt kéznél. Fogyasztásban talán jobb is, mint a málna.