Mam na działce trzy raspberry pi, każde wyposażone w standardową kamerę oraz czujnik BME 280 (temperatura/ciśnienie/wilgotność/.)
Ponieważ czujnik czasami szwankował co być może było spowodowane kiepskim montażem, a kamera robiła zdjęcia kiepskiej jakości, to sobie wymyśliłem upgrade. Konkretnie, że zmienię kamerę na OV5647/5MP z szerokokątnym obiektywem (175 stopni), a do BME 280 dodam niezawodny DS18B20, który wprawdzie mierzy tylko temperaturę ale za to dokładnie.
Połączenia wtyki czujników/GPIO są następujące:
Podłączyłem wszystko tym razem porządniej (a przynajmniej tak mi się wydaje.) Nowa kamera wymagała większej dziury i innego sposobu umocowania na pokrywie obudowy.
Dla przypomnienia: BME 280 testuje się czy działa wydając polecenie:
i2cdetect -y 1
Co powinno skutkować wypisaniem kilkudziesięciu kresek i liczby 76. Jeżeli są same kreski coś nie działa.
Czujnik DS18B20 z kolei powinien być widoczny tutaj:
ls -l /sys/bus/w1/devices/w1_bus_master1/
Tam powinien być numer czujnika, moim przypadku
jest to 28-4680e30264ff
. Temperaturę się czyta
po prostu
#!/bin/bash # Odczyt temperatury z zapisem do loga LOG_DIR=/home/pi/Logs/Digitemp SENS="28-4680e30264ff" TIME="`date "+%Y%m%d%H%M%S"`" TEMP="`cat /sys/bus/w1/devices/${S1}/w1_slave | tr '\n' ' '`" echo "$TIME;$SENS;$TEMP" >> $LOG_DIR/digitemp.log
Przy okazji przetestowałem też AHT10 (temperatura/wilgotność), który
działa ale z obsługą jest już słabo.
Znalazłem mianowicie skrypt w Pythonie drukujący temperaturę
z dokładnością do stopnia a innych skryptów, które by podawały dokładniej, nie udało mi się
uruchomić. W google zresztą podejrzanie mało informacji na temat
AHT10+raspberry
.
Przy okazji też przetestowałem patent na skonfigurowanie rpi z wieloma sieciami WiFi:
/etc/wpa_supplicant/wpa_supplicant.conf ##==== ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev update_config=1 network={ ssid="network1" psk="password1" id_str="id-string1" } network={ ssid="network2" psk="password2" id_str="id-string2" }
Teraz mogę sobie przynieść pi z działki, włączyć i mi się połączy z WiFi w domu też:-)
Dla przypomnienia moja nowa stacja to konsola WiFi o symbolu
DP1500 kupiona u Niemca (czyli w sklepie froggit.de): ze standardowym
zestawem czujników + czujnik pyłu zawieszonego DP200 (też
Froggita). BTW DP1500 to to samo co GW1000 firmy Ecowitt.
Zaś DP 200 Froggita to WH41 Ecowitta
(http://www.ecowitt.com/wifi_weather/83.html
), albo nawet
PM25 firmy AcuWeather
(https://www.ambientweather.com/ampm25.html
)
Zamiast konsoli kupiłem na OLX 5 calowy ekran (110 PLN) i podłączyłem do Raspberry Pi (bezproblemowo).
# konfiguruję (logowanie bez hasła) Boot Options -> Desktop/CLI -> Desktop Autologin/Desktop GUI # # start chromium-browser załadowanie pliku vi ~/.config/lxsession/LXDE-pi/autostart ## wpisuję @/usr/bin/chromium-browser --disable-restore-session-state \ file:///var/www/html/DP1500_live.html
Ekran jest dotykowy. Jak chcę obejrzeć dane pogodowe to dotykam i się wyświetla.
Że jednak brakowało konsoli, to w końcu jednak kupiłem Froggit HP 1000SE PRO (która jest klonem Ecowitt HP 2551). Froggit sprzedaje konsolę jako ersatz, bez niezbędnego specjalnego czujnika temperatury/wilgotności/ciśnienia. Sama stacja jest bowiem dumb -- nic nie mierzy. Ja miałem czujnik temperatury/wilgotności DP50, ale on nie mierzy ciśnienia. Musiałem dokupić oddzielnie ten specjalny, bo się nie dogadałem a dokumentacja/informacja jest w tym aspekcie mało jasna.
Konfigurowanie HP 1000SE PRO to już nie był żaden problem, bo stacja ma aż 8 klawiszy. Połączyłem ją z routerem a potem z dwoma serwisami: ecowitt.net (www.ecowitt.net; oglądanie wymaga zarejestrowania się w sieci ecowitt.net) oraz z WOW ( wow.metoffice.gov.uk)
Kiedyś kupiłem też inny czujnik pyłu zawieszonego (Nova SDS011) i też go podłączyłem do raspberry (bezproblemowo). Teraz przykręciłem go na ścianie obok DP 200 z zamiarem porównania odczytów.
Reasumując posiadam: starą stację WH 2080 działającą od +10 lat.
Nową stację DP1500/WH1000SE PRO oraz czujnik SDS101.
WH 2080 podłączona jest przez kabel USB
do Sheevaplug (to też zaszłość, planuję docelowo przejść na Raspberry)
a obsługiwania jest przez pywws
.
DP1500/WH1000SE podłączona jest przez router, przy czym DP1500 skonfigurowana
jest na serwer lokalny/weewx, a WH1000SE wysyła dane od razu do WOW/ecowitt.net.
Całość kosztował ponad 2500 PLN (wliczając starą stację WH2080). W sumie mogłem kupić HP1000SE PRO + DP200 za 330 EUR, a kupiłem na raty powyższe plus dodatkowy czujnik DP50/DP200 za 450 EUR. Przepłaciłem...
Po długich namysłach kupiłem nową stację (trzeba się rozwijać) pn DP 1500 SmartHub wifi Gateway (za 50 EUR). Jest to konsola bez ekranu z czujnikiem temperatury/ciśnienia i wilgotności (na metrowym kablu); przedmiot wielkości dużego pudełka od zapałek. Do tego pudełka dokupiłem:
Cenowo to wyszło tak (por www.froggit.de), że maszt + DP 1500 jest w zestawie za 135 EUR (czyli sam maszt kosztuje 85 EUR); czujnik DP 50 to następne 13 EUR (kupiłem dwa na wszelki wypadek); czujnik DP 200 aż 90 EUR. Razem wyszło około 250EUR czyli ponad 1100 PLN z wysyłką i płatnością przez PayPal, bo innej opcji nie ma (nikt nie mówił że będzie tanio)
Wszystko w niemieckiej firmie Froggit. BTW Froggit to klon produktów bardziej znanej firmy Ecowitt. To co Froggit sprzedaje jako DP1500 u Ecowitta nazywa się GW 1000. Są jeszcze inne firmy, które robią ten sprzęt pod inną marką.
W stacjach pogodowych standardem jest teraz wysyłanie danych
w chmurę. Nie ma natomiast możliwości bezpośredniego pobierania danych
z urządzenia. Co najwyżej można wysłać na własną chmurę.
Do tego konfiguruje się urządzenie przez smartfona za pomocą dedykowanej
aplikacji pn. WSView
.
Ot tak to sobie branża wymyśliła.
Średnio mi się to podoba, ale
po prostu urządzeń, z których można pobrać bezpośrednio dane w starym stylu
się nie produkuje (no nie do końca jest to prawdą: produkuje się to co
mam od 10 lat, ale
ja nie chę kupować jeszcze raz tej samej stacji). Skoro trzeba mieć własną chmurę, to trzeba ją założyć.
Na szczęście ponieważ potrzeba jest matką wynalazków, to w tej
sprawie inni ludzie już przygotowali stosowne rozwiązania.
Program weewx
, który tradycyjnie obsługiwał stacje,
że tak powiem
kablowe został uzupełniony o weewx-interceptor
,
który przechwytuje dane
wysyłane na (pseudo) własną chmurę.
No więc rozpakowałem to co przyszło z Niemiec. Skręciłem maszt z czujnikami wiatru/deszczu, nasłonecznienia. Czujnik PM2.5 przykręciłem do ściany we wnęce okiennej, żeby deszcz na niego nie kapał. Czujnik DP 50 wstawiłem do klatki meteo. Maszt umieściłem na dachu budynku 3 kondygnacyjnego (nie ma żadnych problemów z zasięgiem, a mieszkam na parterze.)
Ściągnąłem przez Google Play
aplikację WSView
.
Postępując zgodnie z procedurą
(opisaną w podręczniku) połączyłem się z konsolą, która zaczęła
pokazywać dane z czujników (na smartfonie). Uwaga: WSView
dość wolno się
łączy i na dokładkę wysyła mylące komunikaty o odrzuconych
połączeniach, co powoduje pewien niepokój. Nie należy w tym momencie
wykonywać nerwowych ruchów, tylko poczekać...
weeWX
(na RaspberryPi)Mając ustawione połączenie konsola-router można pójść dalej. Znowu jest to dokładnie opisane i co więcej opis jest zgodny ze stanem faktycznym (cf github.com/weewx/weewx/wiki/gw1000-recipe):
Instalujemy weeWX
(wybierając 'Simulator' jako 'station type').
Później należy zmienić 'station type' na 'Interceptor' uruchamiając wee_config --reconfigure
:
wget -qO - http://weewx.com/keys.html | sudo apt-key add - wget -qO - http://weewx.com/apt/weewx.list | sudo tee /etc/apt/sources.list.d/weewx.list sudo apt-get update sudo apt-get install weewx # shut down weeWX sudo /etc/init.d/weewx stop # install weewx-interceptor extension and enable the driver git clone https://github.com/matthewwall/weewx-interceptor.git sudo wee_extension --install weewx-interceptor sudo wee_config --reconfigure
Sprawdzenie czy interceptor
przechwytuje dane.
W oknie terminala uruchamiamy interceptor.py
ze wskazaniem
na port 8000:
PYTHONPATH=/usr/share/weewx python /usr/share/weewx/user/interceptor.py \ --device=fineoffset-bridge --port 8000 --debug
Uruchamiamy przeglądarkę, wpisujemy następujący URL (192.168.xx.xx to IP komputera z weeWXem):
http://192.168.xx.xx:8000/data/report?PASSKEY=XXX&stationtype=GW1000B_V1.5.5 &dateutc=2019-12-29+16:27:27&tempinf=67.1&humidityin=39 &baromrelin=30.138&baromabsin=30.138&freq=915M&model=GW1000
W oknie terminala z uruchomionym interceptor.py
powinno się
pojawić:
raw data: PASSKEY=XXX&stationtype=GW1000B_V1.5.5&dateutc=2019-12-29+16:27:27&tempinf=67.1 &humidityin=39&baromrelin=30.138&baromabsin=30.138&freq=915M&model=GW1000 raw packet: {'humidity_in': 39.0, 'temperature_in': 67.1, 'barometer': 30.138, 'usUnits': 1, 'dateTime': 1577636847} mapped packet: {'inHumidity': 39.0, 'barometer': 30.138, 'inTemp': 67.1, 'usUnits': 1, 'dateTime': 1577636847}
W aplikacji WSView
przechodzimy do strony 'Weather Services'.
Klikamy 'Next' aż wyświetli się 'Customized'. Na tej stronie wpisujemy IP komputera
z zainstalowanym weeWXem jako wartość pola 'Server IP/Hostname'.
Wpisujemy '/' jako wartość pola 'Path' oraz 8000 jako wartość pola 'Port'.
Domyślny upload jest ustawiony na 60 sekund (zmieniłem na 300).
Ustawienia weeWX są w pliku /etc/weewx/weewx.conf
. W szczególności
sekcja Interceptor
powinna wyglądać następująco:
[Interceptor] driver = user.interceptor device_type = fineoffset-bridge port = 8000
Uruchamianie/zatrzymanie/sprawdzanie usługi:
# Start weewx (as daemon) sudo /etc/init.d/weewx start # Stop weewx # sudo /etc/init.d/weewx stop # Check status # /etc/init.d/weewx status # systemctl status -l weewx # ls -l /etc/rc2.d
WeeWX zapisuje dane do bazy /var/lib/weewx/weewx.sdb
.
Można je oglądać uruchamiając:
sqlite3 /var/lib/weewx.sdb ## wyświetl wszystkie tabele .tables ## wyświetl schemat tabeli archive .schema archive PRAGMA table_info(archive); ## zawartość archive select * from archive; ## zakończ .q
Główną tabelą danych weeWXa
jest archive
:
sqlite> PRAGMA table_info(archive); select * from archive 0|dateTime|INTEGER|1||1 1|usUnits|INTEGER|1||0 2|interval|INTEGER|1||0 3|barometer|REAL|0||0 4|pressure|REAL|0||0 5|altimeter|REAL|0||0 6|inTemp|REAL|0||0 7|outTemp|REAL|0||0 8|inHumidity|REAL|0||0 9|outHumidity|REAL|0||0 10|windSpeed|REAL|0||0 11|windDir|REAL|0||0 12|windGust|REAL|0||0 13|windGustDir|REAL|0||0 14|rainRate|REAL|0||0 15|rain|REAL|0||0 16|dewpoint|REAL|0||0 17|windchill|REAL|0||0 18|heatindex|REAL|0||0 19|ET|REAL|0||0 20|radiation|REAL|0||0 21|UV|REAL|0||0 22|extraTemp1|REAL|0||0 23|extraTemp2|REAL|0||0 24|extraTemp3|REAL|0||0 25|soilTemp1|REAL|0||0 26|soilTemp2|REAL|0||0 27|soilTemp3|REAL|0||0 28|soilTemp4|REAL|0||0 29|leafTemp1|REAL|0||0 30|leafTemp2|REAL|0||0 31|extraHumid1|REAL|0||0 32|extraHumid2|REAL|0||0 33|soilMoist1|REAL|0||0 34|soilMoist2|REAL|0||0 35|soilMoist3|REAL|0||0 36|soilMoist4|REAL|0||0 37|leafWet1|REAL|0||0 38|leafWet2|REAL|0||0 39|rxCheckPercent|REAL|0||0 40|txBatteryStatus|REAL|0||0 41|consBatteryVoltage|REAL|0||0 42|hail|REAL|0||0 43|hailRate|REAL|0||0 44|heatingTemp|REAL|0||0 45|heatingVoltage|REAL|0||0 46|supplyVoltage|REAL|0||0 47|referenceVoltage|REAL|0||0 48|windBatteryStatus|REAL|0||0 49|rainBatteryStatus|REAL|0||0 50|outTempBatteryStatus|REAL|0||0 51|inTempBatteryStatus|REAL|0||0
Nie ma kolumny PM2.5 w szczególności.
To się samo robi. Trzeba tylko zarejestrować stację na ecowitt.net
podając MAC-adres urządzenia, ale ecowitt.net
nie udostępnia danych
publicznie.
Żeby oglądać zawartość ecowitt.net
trzeba się zalogować.
No a żeby się zalogować, to trzeba mieć konto. Inna sprawa że nie trzeba mieć stacji, żeby
mieć konto. Jest też stronka
pod adresem www.weewx.com/stations.html
z wykazem zarejestrowanych stacji obsługiwanych przez WeeWX.
Żeby tam zaistnieć trzeba
wstawić do /etc/weewx/weewx.conf
:
register_this_station = True station_url = http://pinkaccordions.homelinux.org/
Co jest opisane w dokumentacji WeeWXhttp://www.weewx.com/docs/usersguide.htm#station_registry
Nie ma kolumny PM2.5, ale interceptor.py
pobiera co trzeba bo na
ecowitt.net
są dane dotyczące PM2.5 tylko lokalnie nie są rejestrowane
w bazie. Wychodzi na to, że to WeeWx 'nie widzi' ekstra danych.
Jest oficjalny sposób na rozszerzenie schematu bazy
(http://www.weewx.com/docs/customizing.htm#add_archive_type
) ale ja póki co
zrobiłem to na szybko w ten sposób, że zmodyfikowałem działanie
/usr/share/weewx/user/interceptor.py
, który nie tylko wypisuje co przechwycił
(co zapewne przetwarza dalej weeWX), ale także zapisuje przechwycony
rekord do pliku tekstowego. W tym celu dodałem takie coś:
def genLoopPackets(self): last_ts = 0 while True: try: data = self._device.get_queue().get(True, self._queue_timeout) logdbg('raw data: %s' % data) ## LOG every 15 minutes nowMM = time.strftime("%M", time.gmtime()) if (nowMM == '00' or nowMM == "15" or nowMM == "30" or nowMM == "45"): ffex = open("/var/log/weewx_exlog.txt", "a+") ffex.write ('[WEEWX#RAW] %s\n' % data) ffex.close() ##loginf('[WEEWX#RAW]: %s' % data)
Co 15 minut, a dokładniej w 15/30/45 oraz zerowej minucie każdej godziny
zapisywany jest rekord danych do pliku /var/log/weewx_exlog.txt
.
cp interceptor.py interceptor_orig.py ## po zmodyfikowaniu interceptor.py w wyżej opisany sposób python -m py_compile interceptor.py
Standardowe raporty WeeWXa są w katalogu: /var/www/html/weewx
.
W sumie z nich nie korzystam, robię raport po swojemu
z pliku /var/log/weewx_exlog.txt
Dokładniej raport jest tworzony na komputerku bez dostępu do internetu a następnie co godzinę kopiowany na ten, który dostęp ma czyli na pinkaccordions.homelinux.org
W planach jest zakup ekranu LCD 5--7 cali do raspberry co będzie robił za wyświetlacz mojej stacji.
Minimalizowanie liczby zapisów (przeciwdziałanie zużyciu się karty SDHC)
https://github.com/weewx/weewx/wiki/Minimize-writes-on-SD-cards
.
W moim rpi mam Debiana w wersji Buster:
$sudo apt install python-selenium python3-selenium chromium-browser
Uruchamiam prosty skrypt, którego używam do pobierania zasobów z Internetu:
$selenium_get_www_page.py https://www.google.pl chrome not reachable
Po konsultacji z google znalazłem (radykalne) rozwiązanie. Należy zrobić downgrade relewantnych pakietów:
# Jakie są wersje dostępne: apt-cache madison chromium-chromedriver chromium-browser
Nie ma żadnych innych poza tymi, które mam zainstalowane, więc trzeba doinstalować z wersji Stretch:
# Należy dodać deb http://archive.raspberrypi.org/debian/ stretch main # do /etc/apt/sources.list apt-get update # Jakie są wersje dostępne teraz: apt-cache madison chromium-chromedriver chromium-browser chromium-chromedriver | 74.0.3729.157-rpt5 | \ http://archive.raspberrypi.org/debian buster/main armhf Packages ...
Instaluję stare wersje:
apt-get install chromium-chromedriver=72.0.3626.121-0+rpt4 chromium-browser=72.0.3626.121-0+rpt4 chromium-codecs-ffmpeg-extra=72.0.3626.121-0+rpt4 chromium-browser-l10n=72.0.3626.121-0+rpt4 apt-mark hold chromium-chromedriver chromium-browser chromium-codecs-ffmpeg-extra chromium-browser-l10n
Teraz skrypt selenium_get_www_page.py
działa.
Nafisa to arabskie imię żeńskie (i restauracja uzbecka w Elblągu, którą polecam) oraz nazwa mojego nowego serwerka uruchomionego na Raspberry Pi 3.
Do tej pory moje domowe serwery działały (od lat prawie 10) na sheevaPlug i cechowały się wysoką niezawodnością (uptime idący w setki dni; rekord 650 dni). Kiedyś już chciałem je przenieść na RPi, ale ówczesne modele RPi okazały się niedostatecznie reliable. Po nastu dniach następował zwis albo coś w tym stylu, więc dałem sobie spokój. Daję teraz RPi drugą szansę mając nadzieję, że nowe modele są bardziej niezawodne.
Instalacja przebiegła standardowo: ze strony
https://www.raspberrypi.org/downloads/raspbian/
pobieram Raspbian
Buster with desktop and recommended software. Pobieram też zalecany
program balenaEtcher
(https://www.raspberrypi.org/documentation/installation/installing-images/README.md
)
do utworzenia bootowalnej karty SDHC. Klikam, wybieram, zapisuje się.
Nawet szybko. Teraz teoretycznie jak się utworzy plik (z dowolną zawartością)
o nazwie ssh
w partycji boot to można już wkładać kartę do komputerka
i startować, ale ja chcę po WiFi więc i tak muszę hasło podać (też
można pewnie podać grzebiąc w plikach na karcie ale ja nie wiem jak),
więc podłączam RPi do telewizora, łączę z ruterem, zmieniam hasło
i włączam SSH (które jest domyślnie zablokowane)
Konfiguruję router i wszystko działa. Teraz standardowo apt update
.
Pora na zaistalowanie wszystkiego co używam na starym serwerze, więc sprawdzam co ja tam zainstalowałem:
sudo dpkg-query -l | awk '{print $2}'
Wybieram z listy te, które wyglądają na doinstalowane:
apt-get install sshfs vim mc ## Digitemp bo planuję podłączyć termometry 18B20 apt-get install digitemp flickcurl-utils \ flickrbackup fonts-texgyre fuse gpsbabel gphotofs apt-get install r-base r-base-core r-base-dev \ r-base-html r-cran-boot r-cran-class r-cran-cluster \ r-cran-codetools r-cran-foreign r-cran-kernsmooth r-cran-lattice r-cran-mass r-cran-matrix r-cran-mgcv r-cran-nlme r-cran-nnet \ r-cran-rpart r-cran-spatial r-cran-survival r-doc-html r-recommended apt-get install imagemagick imagemagick-6-common \ imagemagick-6.q16 ## tweepy używam do zdalnego wysłania twitów apt install python3-tweepy python-tweepy ## net::twitter używam do pobierania twitów apt install libnet-twitter-perl apt install texlive-base texlive-binaries \ texlive-extra-utils texlive-font-utils \ texlive-fonts-recommended texlive-generic-extra \ texlive-generic-recommended texlive-latex-base texlive-latex-extra \ texlive-latex-recommended texlive-xetex
Potem się okazuje, że jeszcze trzeba doinstalować
apt install apache2 apt install r-cran-gg1plot2 r-cran-reshape2 r-cran-reshape apt install libgeo-distance-perl libjson-perl libgeo-distance-perl
Sprawdzam czy apache działa (łącząc się z nafisa/). Działa... Kopiuję skrypty ze starego serwera. Modyfikuję. Testuję niektóre i nawet działają...
Plan jest taki żeby teraz mocno potestować RPi i zobaczyć czy działa niezawodnie (BTW testowana z pewnym skryptem w R okazała się prawie 2 razy szybsza.)