Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Fibaro Fibaro
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Rozproszony system pomiarów temperatury i nie tylko.

dktr 22 Wrz 2015 16:46 9198 27
  • Rozproszony system pomiarów temperatury i nie tylko.

    Założenie jest takie aby szybko i sprawnie zbierać dane z rozproszonych czujników i wyświetlać je w ładnej formie i mieć możliwość porównania wyników za pomocą wykresów.

    http://meteo.lipowa.net/temperatury2

    Do działania takiego systemu potrzebujemy serwer HTTP z php i publicznym adresem IP najlepiej z dostępem do shella/powłoki. Na tym serwerze musimy mieć skompilowane rrdtool - narzędzie do rysowania wykresów i obsługi bazy danych rrd.

    Strona z pomiarami to zwykłe html'owe tabelki gdzie każdy TD ma swój unikatowy ID który to potem zamieniany jest na wynik pomiaru za pomocą jquery.

    Wybór wykresu po kliknięciu w jego nazwę, gotowe "presety" poprzez klikanie w wykres lub górny pasek.

    Skąd się biorą wyniki na "głównym" serwerze?

    Czujniki to głownie routery z OpenWRT z podłączonymi czujnikami ds18b20 pod 1 z portów GPIO. W moim przypadku używam routerów TP-Link 740n.

    Po instalacji openwrt trzeba doinstalować paczki:

    Code:
    kmod-w1 kmod-w1-master-gpio kmod-w1-gpio-custom kmod-w1-slave-therm bc


    następnie ładujemy moduł

    Code:
    insmod w1-gpio-custom bus0=0,2,0


    bus=0,2,0 oznacza na którym GPIO mamy podłączony czujnik - to jest już zależne od posiadanego routera i tych informacji należy szukać w dokumentacji openwrt dla danego routera. Czujnik łączymy z GPIO i równolegle rezystor 4.7k do 3.3v tak zwany pullup.

    po załadowaniu modułu powinien pojawić się katalog
    Code:
    /sys/bus/w1/drivers/w1_slave_driver/

    a w nim kolejny katalog z numerem seryjnym czujnika.

    Teraz należy odczytać pomiar i wysłać go na "główny" serwer. Robi to taki skrypt podzielony na dwa mniejsze skrypty

    crc.sh - odczytuje poprawny wynik z ds18b20

    Code:

    #!/bin/sh

    sensor=$1
    if [ -f /sys/bus/w1/devices/$sensor/w1_slave ]
    then
    crc="NO"

    while [ $crc = "NO" ]
    do
    sensor_output=$(cat /sys/bus/w1/devices/$sensor/w1_slave | cut -c 30-)
    crc=$(echo $sensor_output | cut -c 7-10 )
    done
    temp_raw=$(echo $sensor_output | cut -c 11-)




    temp=$(echo "0.001 * $temp_raw" | bc)
    echo "$temp";
    fi


    następny skrypt wysyła dane na "główny serwer":

    Code:

    #!/bin/sh

    while :

    do

    t1=`/etc/dktr/crc.sh 28-000000dfe1e5`
    t2=`/etc/dktr/crc.sh 28-0000031bddc9`
    t3=`/etc/dktr/crc.sh 28-000003dac35e`

    if [ "$t1" != "" ];
    then
    wget -q -O /dev/null "http://192.168.2.40/load.php?val=$t1&id=c1"
    fi
    if [ "$t2" != "" ];
    then
    wget -q -O /dev/null "http://192.168.2.40/load.php?val=$t2&id=c2"
    fi
    if [ "$t3" != "" ];
    then
    wget -q -O /dev/null "http://192.168.2.40/load.php?val=$t3&id=c3"
    fi

    sleep 1
    done



    Jak można się domyślić działa to banalnie prosto, wget wywołuje plik load.php który to z parametru val odczytuje pomiar i zapisuje go do pliku o nazwie id w ramdisku na "głownym" serwerze.

    W ten sam sposób wysyłam inne pomiary:

    Status zamków w drzwiach sprawdzam zwykłą krańcówką zamontowaną w futrynie i podłączoną pod kolejne GPIO TP_linka.

    Pomiar napięcia, prądu, mocy czynnej, mocy biernej, mocy pozornej, cos fi odczytuje ze wskaźnika ORNO OR-WE504 podłączony pod komputer z x86 z oprogramowaniem modpoll do odczytu magistrali modbus.
    Fizycznie jest to interfejs USB-rs485 zrobiony na PL2303 i kilka dodatkowych elementów do kupienia u chińczyków za 5zł.

    Ciśnienie i wilgotność zrealizowałem na BMP180 i DHT11 podłączonymi do atmegi8 która przez uart połączona jest do TP_linka i wysyła dane w taki sam sposób jak temperaturę.
    Na zdjęciu wczesna beta jeszcze na płytce prototypowej, tak pozostało ale jest już ładnie umocowane wewnątrz.
    Rozproszony system pomiarów temperatury i nie tylko.

    Jak działa samo wyświetlanie można podpatrzeć w źródle strony.

    Dane dostarczane na główny serwer można czytać z innych aplikacji, np tasker na androida.
    Rozproszony system pomiarów temperatury i nie tylko.

    Lub z innych urządzeń - w tym przypadku TP Link z podłączonym wyświetlaczem VFD przez UART pobiera dane z "głownego" serwera (głownie chodziło o wskazania poboru mocy przez całe mieszkanie i motywowanie do oszczędzania)
    Rozproszony system pomiarów temperatury i nie tylko.


    Fajne!
  • Fibaro
  • #2 22 Wrz 2015 20:03
    wojlej
    Poziom 17  

    Podoba mi się idea i w ogóle że wszystko chodzi. Tylko nie wyobrażam sobie takiego systemu u mnie w domu. W każdym pokoju router, nawet w korytarzu, żeby sprawdzić zamknięte drzwi. Rozwiązanie super, ale trochę nieoptymalne jeżeli chodzi o komunikację.

  • Fibaro
  • #4 22 Wrz 2015 20:08
    wojlej
    Poziom 17  

    No właśnie, kwestia okablowania. Jeżeli w ścianach nie ma przewodów innych niż 230VAC, to ciężko takie rozwiązanie zaimplementować.

    Nie dałoby się tego zrobić na powiedzmy:
    DS18B20 + STM32 (lub AVR) + moduł WIFI

    i łączyć się do sieci domowej?

  • #6 22 Wrz 2015 20:11
    wojlej
    Poziom 17  

    I takie rozwiązanie jest już bardziej przystepne, można zrobić projekt jednej płytki i wykonać ją razy 10. Kwestia postawienia serwera.

  • #7 22 Wrz 2015 20:41
    tygrysss
    Poziom 21  

    Powiedz coś więcej o konfiguracji TASKER'a? Mam u siebie podobnie rozwiązane pomiary openwrt itd, ale o aplikacji tasker nie słyszałem.

  • Fibaro
  • #9 22 Wrz 2015 23:00
    masio24
    Poziom 10  

    Tym z IMiGW przydało by się.Nie wiedzą kiedy susza jest to by im znacznie ułatwiło sprawę ;)

  • #10 23 Wrz 2015 06:22
    Duch__
    Poziom 31  

    Szacunek za ilość zbieranych danych. Ja coś podobnego, ale na znacznie mniejszą skalę wykorzystuje atmegę32 + moduł ESP8266 który wysyła mi wyniki na thingspeak-a.

    Patrząc po ilości nazw powiedz ile tak naprawdę obiektów tym system obsługujesz aktualnie, oraz ile routerów wykorzystujesz.

  • #12 23 Wrz 2015 10:44
    maximus22_kr
    Poziom 18  

    Prezentuje się wspaniale. Oczywiście nie będzie problemu, gdy czujniki będą w lokalizacjach bardziej oddalonych od siebie? (Bez połączenia 2,4 lub 5 GHz)

    Może źle piszę, ale tajniki Linuksa są mi niestety nieznane (dlatego jestem skazany na thingspeak-a :-().

    Napisał Kolega, że potrzebna jest baza danych, a z tego:

    Cytat:
    wget wywołuje plik load.php który to z parametru val odczytuje pomiar i zapisuje go do pliku o nazwie id w ramdisku na "głownym" serwerze.

    wynika, że każdy czujnik ma swój plik na serwerze - akurat to rozwiązanie jest lepsze, bo jak coś pójdzie nie tak, to tylko z jednym plikiem jest problem, a nie z całą bazą danych.

  • #13 23 Wrz 2015 11:33
    dktr
    Poziom 17  

    Dokładnie tak, cyklicznie czujniki aktualizują swoje pliki w ramdisku, dodatkowo jeśli plik load.php wywołany przykładowo z parametrem load.php?id=c1&val=25 spowoduje powstanie dwóch plików na serwerze: c1.txt z wynikiem pomiaru i c1.nt z "czasem pomiaru w unixtime", to dzięki temu, jeśli któryś czujnik straci połączenie bądź nie wyśle odpowiednio często pomiaru, w tabeli wynik pojawia się jako szary - nie aktualny (ustawione 30 sek). A po najechaniu myszą na wynik pomiaru mamy dokładny czas pomiaru.

    Na głównym serwerze dodatkowo działa skrypt, który co kilka sekund aktualizuje bazę rrd - czyta wszystko z ramdisku i wrzuca do rrd - to jest tylko po to, aby rysować wykresy z możliwością nakładania ich na siebie, wcześniej miałem tak, że każdy czujnik miał swoją osobną bazę rrd, ale wtedy nie można mieszać razem pomiarów.

    Tak czujniki mogą się komunikować nawet po GPRS, to tylko kilka bajtów do przesłania.

  • #14 23 Wrz 2015 13:29
    maximus22_kr
    Poziom 18  

    Z GPRS też dobry pomysł - akurat eksperymentowałem z SIM800L ( cena niska, tylko Rx, Tx, Reset i zasilanie - w drugiej wersji wyprowadzony jeszcze mikrofon i głośnik ) i ładnie wysyłał mi emaile tylko przy użyciu komend AT. Nie wiem jak teraz taryfikują dane operatorzy ( kiedyś każde nowe połączenie to kolejna porcja danych do zapłacenia, nieważne ile się wykorzystało z poprzedniej sesji ), ale można podtrzymać sesje przez 24 godziny ( po 24 rozłączają )

  • #15 23 Wrz 2015 16:38
    Kużdo
    Poziom 20  

    Jak pierwszy raz zobaczyłem zrzut z tej strony, to się w tym zakochałem. Super wykonanie, mega przejrzyste, mega logiczne, no po prostu profesjonalnie. Sam od dawna myślałem o takim systemie kontroli domu i trzeba się kiedyś za to zabrać. Tak więc słowa uznania za dobrą robotę :)

  • #16 23 Wrz 2015 20:17
    Milek79
    Poziom 14  

    dktr napisał:
    to jest tylko po to, aby rysować wykresy z możliwością nakładania ich na siebie, wcześniej miałem tak, że każdy czujnik miał swoją osobną bazę rrd, ale wtedy nie można mieszać razem pomiarów.

    To nie ma nic do rzeczy.

    Ogólnie interfejs do oglądania tego bardzo fajny, ale źródło okropne.

  • #18 23 Wrz 2015 20:34
    Milek79
    Poziom 14  

    http://oss.oetiker.ch/rrdtool/doc/rrdgraph_data.en.html
    DEF:<vname>=<rrdfile>:<ds-name>:<CF>[:step=<step>][:start=<time>][:end=<time>][:reduce=<CF>][:daemon=<address>]
    W czym problem?

    Co oczywiście nie zmienia tego, że osobne rrd to też nie jest cudowne rozwiązanie, bo jak się dodaje/usuwa RRA to trzeba zmieniać w każdym pliku.

  • #19 23 Wrz 2015 20:38
    dktr
    Poziom 17  

    Obadam se to jeszcze, w zasadzie nic to nie zmienia, ale wiem ze był z tym jakiś problem. Fakt w kodzie jest straszny bałagan, ale to już powoli się zmienia - program ma około 7 lat i sporo się między czasie zmieniło i już od dłuższego czasu korci mnie przepisać od nowa wszystko jak należy, ale skoro działa... ;)

  • #20 24 Wrz 2015 00:23
    Kużdo
    Poziom 20  

    dktr napisał:
    ale skoro działa...

    Jak działa, to się nie rusza ;) Lepsze wrogiem dobrego ;)

    A na poważnie - o ile nie ma błędów bezpieczeństwa, to może być zrobione tak jak jest. Źródeł i tak nie oglądamy, liczy się efekt końcowy. Fakt, jak robię projekt dla klienta, to robię to ładnie i ze strony wizualnej, jak i to, co jest pod maską. Ale wystarczy posprawdzać kilka najpopularniejszych stron i łatwo idzie zauważyć, że wszędzie tam, gdzie jest prowadzona masówka jest bajzel. I nikt tego nie będzie poprawiał.
    A kolejna rzecz, to minimalizm. Jeżeli tym opisywanym bałaganem jest np. formatowanie wynikowego kodu, to to wszystko nie liczy się, gdy zechcemy ograniczać zużycie łącz, serwerów itp. Wystarczy użyć CloudFlare dla naszego bezpieczeństwa, zwiększenia dostępności oraz niezawodności, a przy okazji możemy zmniejszyć kod wynikowy strony (poprzez minimalizację skryptów, usuwanie formatowania kodu itp.). Oczywiście to samo możemy zrobić sami, ale po co.
    Więc jeżeli działa, to nie przejmowałbym się tym ;)

  • #21 24 Wrz 2015 09:44
    gbd.reg
    Poziom 20  

    Mógłbyś opisać trochę szerzej działanie serwera? Czy czujniki komunikują się z serwerem po jakimś API? Jest to zwykłe połączenie HTTP czy coś innego? W jakim formacie są wysyłane do serwera dane z czujników?

    Co się dzieje z pomiarami z czujników, gdy serwer jest chwilowo nieosiągalny? Są w jakiś sposób buforowane i wysyłane później na serwer? Serwer przechowuje faktyczny czas pomiaru czy może czas w którym odebrał dane z czujnika? I dlaczego zdecydowałeś się na zapis do plików tekstowych zamiast bezpośrednio do bazy danych?

  • #22 24 Wrz 2015 11:07
    dktr
    Poziom 17  

    Działanie serwera to bardzo prosta sprawa, tak jak pisałem, na urządzeniach robiących pomiar wywoływany jest cyklicznie skrypt który zwykłym linuksowym wget`em wywołuje plik load.php z serwera z odpowiednim parametrem w stylu id=, val=
    (wcześniej definiuje timeout na 5 sek w razie braku komunikacji.)

    Jeśli główny serwer jest nieosiągalny czujniki nie zaktualizują swoich danych i nie będzie dostępu do strony z pomiarami. Wyniki pomiarów przepadają nie są buforowane. Jeśli wynik pomiaru jest starszy niż 30 sek uznawany jest za nieaktualny i wyświetlany ostatni pomiar jako lekko szary - np w przypadku awarii czujnika łatwo to wyłapać.
    Rozproszony system pomiarów temperatury i nie tylko.

    Oparłem wszystko na plikach, ponieważ ułatwia mi to bardzo manipulacje wynikami pomiarów, ramdisk na którym trzymam pliki z pomiarami mam udostępniony przez sambę na inne systemy które korzystają z tych danych i nie muszę się martwić o jakiś klientów sql czy inne. Baza danych na tak mały projekt chyba bez celu.

  • #23 30 Wrz 2015 10:06
    gbd.reg
    Poziom 20  

    Baza danych nawet na tak mały projekt jest dobrym rozwiązaniem. Nie musi to od razu być serwer bazodanowy, może to być zwykły SQLite, a do plików możesz wykonywać eksport cyklicznie, jeśli jest to potrzebne.

    Dlaczego baza danych jest dobrym pomysłem? Jeśli zapisujesz również historyczne pomiary, zastosowanie bazy umożliwia szybkie wyliczenie np temperatury minimalnej i maksymalnej w danym okresie, temperatury średniej.

TME logo Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
TME Logo