Na taką zabaweczkę się ostatnio skusiłem:

Z jednej strony patrząc jest to ot taka sobie stacyjka pogodowa, summa summarum wychodząca cenowo trochę drożej od podobnych jej (pozornie) dziesiątków innych, poniewierających się w każdym sklepie z elektroniką domową. Co więc ją wyróżnia i czemu właśnie na nią się skusiłem? Ano, jednym z głównych powodów jest fakt, że pogodynka ta nie ma żadnych czujników, czy to zewnętrznych, czy wewnętrznych, pokazuje właściwie wszystkie istotne dane na temat bieżącej i przyszłej pogody (to, co widać na zdjęciu to tylko „ekran główny” z najistotniejszymi danymi, bardziej szczegółowe dane są dostępne na kolejnych „stronach”) obywając się całkowicie bez kłopotliwych przystawek do pomiaru temperatury zewnętrznej, czy siły i kierunku wiatru. Wszystko, co jej potrzebne ściąga sobie sama z internetu, bazując na sieci tysięcy publicznych stacji pogodowych tworzących społeczność Weather Underground.

Z mniejszymi lub większymi „klasycznymi” stacjami pogodowymi spotkał się chyba każdy. I zawsze jest z nimi problem. Najbardziej typowy: „a nie, ona teraz bzdury pokazuje, bo czujnik leży na parapecie, a jak tam świeci słońce, to jest cieplej”, ale jest całe mnóstwo innych, od zbyt krótkiego przewodu do czujnika zewnętrznego w tych najtańszych pogodynkach zaczynając, a na konieczności wymiany baterii i sensownego umieszczenia sensora w tych droższych kończąc. Te najdroższe stacje pogodowe mają w komplecie nawet przystawki do pomiaru siły i kierunku wiatru, ale powiedzmy sobie szczerze: kto w domowych warunkach jest w stanie zainstalować takie ustrojstwo tak, by jego wskazania były wiarygodne, nie zakłócone przez żadną ścianę, czy inną osłonę z żadnego kierunku wiatru?
Ta pogodynka problem eliminuje całkowicie – jakichkolwiek czujników brak, wszelakie dane zaciąga sobie ze strony Weather Underground, pokazując je dla takiej lokalizacji, jaką sobie wybierzemy, z tejże strony pobiera również prognozę pogody i wyświetla ją zarówno graficznie, jak i w formie dokładniejszego opisu, dostępnego „jednym kliknięciem”. Dla mnie bomba 🙂

Kilka słów na temat na ile te prognozy są wiarygodne – zbyt krótko się tym urządzeniem bawię, by składać tu jakieś ciężkie deklaracje, ale napiszę tyle, że z danych ciągniętych z serwisu Weather Underground od dwóch lat korzysta mój system nawadniania ogrodu, w którym zrobiłem to jako tymczasowe rozwiązanie, póki nie wykonam zewnętrznych czujników temperatury, opadów i wilgotności, ale owo tymczasowe rozwiązanie okazało się tak wygodne, skuteczne i niezawodne (tu zaraz będzie dygresja), że bardzo szybko zarzuciłem plany robienia jakichkolwiek własnych czujników, bowiem choćbym się wściekł, nie zrobiłbym tego lepiej (dygresja: oczywiście rozwiązanie takie jest skuteczne i niezawodne dopóty, dopóki nie braknie internetu, ale cóż, taki już los domów inteligentnych, internet ma być i koniec! Ale to jest temat na osobną dyskusję, pomińmy). Wracając do wiarygodności stacji jeszcze – od kilku dni porównuję jej prognozy z najbardziej dla mnie póki co wiarygodnym serwisem meteo, jakim jest Centrum ICM Uniwersytetu Warszawskiego (nie jest to prognoza, w której na mapie Polski mamy chmurki i słoneczka z podanymi temperaturami, ale jej zrozumienie jest dość proste, a sprawdzalność [godzinowa!] naprawdę duża, polecam mocno) i obie prognozy są dość zgodne, więc póki co jestem z zakupu zadowolony 🙂

Samo urządzenie jest ukoronowaniem prac pewnego szwajcarskiego blogera. Człowiek ma na swojej stronie kilka ciekawych projektów budowanych w oparciu o moją ostatnią Wielką Miłość, jaką jest moduł ESP8266 i jak nietrudno zauważyć, dość mocno drążył też temat stacji pogodowych. Temat musiał być owocny, bowiem z projektów opisanych u niego wyrastały kolejne, aż wreszcie ktoś (nie za bardzo wiem, kto to, skrywa się za tajemniczą nazwą AZSMZ i jest chyba jakimś producentem związanym z Aliexpress) stworzył kombajnik będący właściwie kompletną platformą do uruchomienia własnej pogodynki. Zadanie jest w sumie proste, ponieważ jednak wymaga ono przedarcia się przez kilka stron rozsianych po internetach i zebrania do kupy nie zawsze spójnych informacji, pozwolę sobie to zebrać w jednym miejscu.

Tak oto wygląda samo urządzenie w stanie „fabrycznie nowe” (źródło zdjęcia: aliexpress, widoczny na zdjęciu akumulator kupujemy oddzielnie):

A oto, co potrafi: kolejne ekrany dostępne po naciśnięciu przycisku (górny przycisk z lewej strony, ten niższy to „reset”) albo po pacnięciu palcem w ekran wersji z touchpadem:

Co potrzebne:

1. Moduł stacji pogodowej. Do kupienia np. tutaj, w chwili, gdy to piszę, są dostępne dwie wersje, z touchpadem za 29$ lub bez touchpada za 24$. Ceny jednakże się dość dynamicznie zmieniają, miesiąc temu, gdy kupowałem swoją wersję, kosztowała mnie 29$, o touchpadzie nie było mowy. Z lektury blogu twórcy i komentarzy pod nim wiem, że touchpad sprawia (sprawiał) trochę problemów, więc z jednej strony dobrze, że go nie mam, z drugiej jednak – wiadomo, gadżeciarstwo tkwi w człowieku i szczerzy zęby.
2. zasilanie: wystarczy dowolna ładowarka do telefonu, wszystko co trzeba, to wtyczka micro USB „z prądem”.
3. akumulatorek Li-Pol. Nie jest niezbędny, ale przyda się, choćby dla uniezależnienia działania pogodynki od tego, czy ładowarki akurat ktoś nie zabierze celem pilnego podładowania telefonu. Byle oddał na czas i będzie ok 🙂 Akumulatorek w zasadzie może być dowolny (w granicach zdrowego rozsądku!), przykładowy, który tutaj się nada.
4. jakaś obudowa – tu już pełna dowolność, zależnie co kto może/potrafi/chce. 
5. zainstalowana na komputerze platforma Arduino IDE i podstawowa wiedza na temat jej używania.
6. własny profil na https://www.wunderground.com/ i pobrany z niego API key. Wystarczy podstawowe, darmowe konto, z ograniczeniem do 500 odczytów na dobę.

Oprogramowanie i konfiguracja

Moduł przychodzi z już wgranym oprogramowaniem, ale z uwagi na konieczność dodania doń własnych ustawień i tak trzeba to zrobić od nowa, z oryginalnym softem więc wystarczy, jeśli tylko urządzenie włączymy na próbę, by sprawdzić, czy działa. Oznaką działania będzie próba łączenia się z siecią WIFI, raczej nie powinniśmy oczekiwać niczego więcej. My zaś musimy ściągnąć sobie soft stąd:

https://github.com/cxandy/esp8266-weather-station-color

Ściągamy, rozpakowujemy i otwieramy w Arduino IDE. Albo dowolnej innej platformie potrafiącej pracować z C++ dla ESP8266, jednakże Arduino IDE jest tu o tyle korzystne, że rozumie użyty w sofcie sposób podawania portów procesora (D0, D1, D2, itd.), podczas gdy np. Visual Studio wymaga podania numerów GPIO i trzeba to niestety przeedytować. 
To, co nas interesuje, zawiera się właściwie w całości w pliku settings.h i tenże plik należy przeedytować. Poniżej w punktach omówię sekcję pliku, które wymagają modyfikacji:

1. wifi settings – oczywiście podajemy SSID i hasło naszej sieci:

   1 2 3

   // Setup #define WIFI_SSID "moja SSID" #define WIFI_PASS "hasło"

   // Setup #define WIFI_SSID "moja SSID" #define WIFI_PASS "hasło"

2. Tu definiujemy, co ile aktualizują się informacje pogodowe (domyślne 10 minut jest ok), możemy też ustawić czas po którym włączy się screensaver albo (po małych przeróbkach, o których niżej) urządzenie wróci do wyświetlania ekranu głównego: 

   1 2	const int UPDATE_INTERVAL_SECS = 10 * 60; // Update every 10 minutes const int SLEEP_INTERVAL_SECS = 60; // Going to Sleep or screen saver after idle times, set 0 for dont sleep.

   const int UPDATE_INTERVAL_SECS = 10 * 60; // Update every 10 minutes const int SLEEP_INTERVAL_SECS = 60; // Going to Sleep or screen saver after idle times, set 0 for dont sleep.

3. dość istotne miejsce z uwagi na fakt, że soft ściągnięty z githuba jest ustawiony do obsługi płytki SQUIX, trzeba to przestawić na AZSMZ. Czyli ma być tak, jak poniżej:

   1 2	//#define BOARD SQUIX #define BOARD AZSMZ_1_1

   //#define BOARD SQUIX #define BOARD AZSMZ_1_1

4. touchpad. Jeśli jest, nie ruszamy, jeśli nie ma, pierwszą linijkę należy „wyłączyć”, jak poniżej:

   1 2 3

   // #define HAVE_TOUCHPAD #define TOUCH_CS D3 #define TOUCH_IRQ D4

   // #define HAVE_TOUCHPAD #define TOUCH_CS D3 #define TOUCH_IRQ D4

5. Dodatkowy czujnik temperatury na LM75. Można podłączyć, pogodynka wtedy będzie na ekranie głównym pokazywać temperaturę z tego czujnika. Jeśli czujnika nie mamy, należy „wyłączyć” jego definicję (jak poniżej), inaczej można się zdziwić podobnie, jak ja się zdziwiłem pierwszego dnia, gdy pogodynka mnie przekonywała, że w Warszawie mamy właśnie 29 stopni 🙂

   1 2 3

   // #define LM75 #define SDA_PIN 0 #define SCL_PIN 2

   // #define LM75 #define SDA_PIN 0 #define SCL_PIN 2

6. Wunderground. Tu właściwie wszystko widać, łącznie z podanym sposobem szybkiego sprawdzenia, czy nasze API oraz wybrane ustawienia działają. Należy zdecydować się, gdzie mieszkamy, podać swoje API i tyle.

   1 2 3 4 5 6 7 8 9

   // Wunderground Settings // To check your settings first try them out in your browser: // http://api.wunderground.com/api/WUNDERGROUND_API_KEY/conditions/q/WUNDERGROUND_COUNTTRY/WUNDERGROUND_CITY.json // e.g. http://api.wunderground.com/api/808ba87ed77c4511/conditions/q/CH/Zurich.json const String DISPLAYED_CITY_NAME = "Warsaw"; const String WUNDERGRROUND_API_KEY = "---twój API---"; const String WUNDERGRROUND_LANGUAGE = "EN"; const String WUNDERGROUND_COUNTRY = "PL"; const String WUNDERGROUND_CITY = "WARSAW";

   // Wunderground Settings // To check your settings first try them out in your browser: // http://api.wunderground.com/api/WUNDERGROUND_API_KEY/conditions/q/WUNDERGROUND_COUNTTRY/WUNDERGROUND_CITY.json // e.g. http://api.wunderground.com/api/808ba87ed77c4511/conditions/q/CH/Zurich.json const String DISPLAYED_CITY_NAME = "Warsaw"; const String WUNDERGRROUND_API_KEY = "---twój API---"; const String WUNDERGRROUND_LANGUAGE = "EN"; const String WUNDERGROUND_COUNTRY = "PL"; const String WUNDERGROUND_CITY = "WARSAW";

7. Strefa czasowa – szczęśliwie Szwajcaria póki co jest w tej samej strefie, co Polska, więc póki nie uda nam się wyjść z kretynizmu zwanego Zmianą Czasu i na stałe zostać przy czasie letnim, ustawień domyślnych nie trzeba ruszać:

   1 2 3

   #define UTC_OFFSET + 1 struct dstRule StartRule = {"CEST", Last, Sun, Mar, 2, 3600}; // Central European Summer Time = UTC/GMT +2 hours struct dstRule EndRule = {"CET", Last, Sun, Oct, 2, 0}; // Central European Time = UTC/GMT +1 hour

   #define UTC_OFFSET + 1 struct dstRule StartRule = {"CEST", Last, Sun, Mar, 2, 3600}; // Central European Summer Time = UTC/GMT +2 hours struct dstRule EndRule = {"CET", Last, Sun, Oct, 2, 0}; // Central European Time = UTC/GMT +1 hour

8. drobiazgi o chyba oczywistym przeznaczeniu, można zostawić tak, jak są, no chyba, że jest na sali wielbiciel systemu imperialnego, wolący podawać czas w systemie 12godzinnym, a parametry pogodowe czytać w funtach na cal, milach na godzinę i Fahrenheitach, wtedy wystarczy zmienić poniższe definicje na przeciwne 🙂

   1 2 3 4

   // values in metric or imperial system? bool IS_METRIC = true; // Change for 12 Hour/ 24 hour style clock bool IS_STYLE_12HR = false;

   // values in metric or imperial system? bool IS_METRIC = true; // Change for 12 Hour/ 24 hour style clock bool IS_STYLE_12HR = false;

9. ostatnia, bardzo ważna sprawa: źródło czasu astronomicznego. Tu podajemy serwery NTP. Domyślnie mamy serwery szwajcarskie, które owszem, działają, ale… są daleko. Czemu warto je zmienić na inne i czemu na konkretne adresy IP, a nie na ich nazwy – za chwilę napiszę więcej, póki co – propozycja, jak można to ustawić, by było lepiej:

   1 2	// change for different ntp (time servers) #define NTP_SERVERS "80.50.231.226", "91.212.242.20", "217.96.29.26"

   // change for different ntp (time servers) #define NTP_SERVERS "80.50.231.226", "91.212.242.20", "217.96.29.26"

I to by było na tyle, jeśli chodzi o konfigurację urządzenia wymaganą do jego poprawnego działania. Zmodyfikowany plik należy zapisać, całość softu skompilować i wgrać do ESP8266, upewniając się wcześniej, pod jakim numerem portu urządzenie się zgłosiło i takiż port ustawiając w opcjach Arduino IDE. Jeśli wszystko poszło jak należy, urządzenie powinno się połączyć z siecią wifi, pobrać sobie co trzeba i zacząć to wyświetlać.

UWAGA: co 10 minut (czas ustawiony w punkcie 2) urządzenie od nowa pobiera dane z sieci. Proces ten nie odbywa się w tle (szkoda w sumie), jest on wizualizowany paskami postępu pojawiającymi się na ekranie i wygląda to tak, że w pierwszej chwili byłem przekonany, że urządzenie się spontanicznie co jakiś czas resetuje. Otóż nie, te codziesięciominutowe kilkusekundowe akcje odświeżania to normalny objaw pracy urządzenia.

Zmiany, zmiany, zmiany…

Jedną ze wspanialszych cech tej pogodynki jest fakt, że cały jej kod źródłowy mamy do dyspozycji, możemy go dowolnie modyfikować, zmieniać… no wszystko możemy. W tym możemy też i zmienić wszystko to, co w obecnej formie projektu drażni i wydaje się niedopracowane. I o tym też chciałbym… 

1. Screensaver. Jest obecny w pierwotnej wersji, polega on na tym, że po upływie ustawionego w punkcie 2 czasu urządzenie zamiast widocznych na zdjęciach informacji zaczyna wyświetlać latający po ekranie zegarek. Dla mnie kompletny bezsens, bo na zużycie energii to wpływa podejrzewam w bardzo nieznacznym stopniu, kwestii zużywania wyświetlacza TFT chyba też w znaczącym stopniu to nie zmieni, natomiast pozbawia nas zasadniczej funkcji urządzenia: możliwości odczytania informacji „jednym rzutem oka”. Oczywiście screensaver można wyłączyć, ustawiając jego czas na 0 i tak też od razu zrobiłem, jednakże uwidoczniła się wtedy inna bolączka: gdy kliknąwszy przycisk zmieniłem ekran główny na inną stronę (choćby celem sprawdzenia szczegółowej prognozy), owa strona sobie zostawała na stałe, chcąc wrócić do głównej trzeba było się na nią mozolnie przeklikać. To aż się prosiło o zmianę i oczywiście zostało od razu zmienione. Należy mianowicie wyedytować główny plik programu: esp8266-weather-station-color.ino i odnaleźć w nim oraz zmodyfikować poniższy fragment:

   1 2 3 4 5 6 7 8

   if (SLEEP_INTERVAL_SECS && millis() - timerPress >= SLEEP_INTERVAL_SECS * 1000){ // after 2 minutes go to sleep #ifdef DEEP_SLEEP [...] #else // screen = screenCount; //original code -> screensaver screen = 0; //my modification -> go to main screen #endif }

   if (SLEEP_INTERVAL_SECS && millis() - timerPress >= SLEEP_INTERVAL_SECS * 1000){ // after 2 minutes go to sleep #ifdef DEEP_SLEEP [...] #else // screen = screenCount; //original code -> screensaver screen = 0; //my modification -> go to main screen #endif }

   Na przykładzie widać i zmienioną w komentarz oryginalną linijkę (5) i moją zmianę w linii 6, ale wystarczy, jeśli słowo screenCount zmienimy na wartość 0, oczywiście nie zapominając o średniku na końcu.

2. Serwery czasu. Tu ujawnia się pewna słabość obecnej wersji urządzenia. Polega ona na tym, że co ustawiony czas (10 minut) odbywa się aktualizacja, a jej wynik jest wstawiany jako nowe dane, niezależnie od tego, co tym wynikiem tak naprawdę jest. Serwery czasu dostępne przez internet są wynalazkiem genialnym, ale przez genialność swą również niezwykle popularnym i bywa, zwłaszcza w przypadku popularnych serwerów, że mocno obleganym. Dlatego zdarza się czasem, że wysłane doń zapytanie nie doczekuje się odpowiedzi w sensownym terminie – bo serwer akurat zbyt zajęty, bo jakiś problem w sieci (zresztą niekoniecznie po stronie serwera, równie dobrze reszta domowników pracując na tym samym łączu może akurat filmy w HD oglądać 😉 i mamy łącze przytkane). Niestety, w zaimplementowanym tutaj sposobie obsługi odczytu brak odpowiedzi jest traktowany również jako odpowiedź o wartości zerowej. I takąż odpowiedzią jest aktualizowana data i godzina naszego urządzenia. Co dla użytkownika oznacza tyle, że po takiej aktualizacji jego pogodynka zacznie twierdzić, że jest 1 stycznia 1970 roku, godzina 00:00. I to, niestety, zdarza się regularnie. Tym częściej, im bardziej oblegane bądź trudniej dostępne serwery NTP się poda w settings.h, punkt 9. Druga rzecz to podawanie serwerów „po nazwie”, jak to sugeruje oryginalny plik settings.h (gdzie linijka ta wygląda tak: #define NTP_SERVERS „0.ch.pool.ntp.org”, „1.ch.pool.ntp.org”, „2.ch.pool.ntp.org” ) – rozwinięcie tych nazw do adresów IP to znów jest realna strata czasu i możliwa wpadka, tym razem ze strony serwera DNS. Dlatego też podając niezbędne modyfikacje settings.h zasugerowałem podanie serwerów NTP bezpośrednio jako adresów IP. można skopiować te „moje”, można wstawić własne –  co kto lubi.
   Gdzie zaś tu propozycja zmiany? No właśnie tu: „coś” z tym trzeba zrobić. Np. dodać warunek sprawdzający, czy odpowiedź z serwera NTP jest poprawna i aktualizować czas i datę tylko jeśli taka będzie. Usiłowałem to zrobić samodzielnie, niestety chyba zbyt cienki jeszcze w C++ jestem, bo w pierwszym podejściu nie udało mi się rozgryźć sposobu działania odczytu czasu na tyle, by go modyfikować. Niemniej, z lektury komentarzy na blogu twórcy oraz na jego githubie wiem, że nad tym problemem pracują, zarówno on, jak i paru zapaleńców, więc chyba nie będę rzeźbił, sobie siądę i spokojnie poczekam na poprawkę 🙂 
3. Łączność z Weather Underground – u mnie ten problem jeszcze nie wystąpił, ale z komentarzy wspomnianych wyżej wiem, że identyczny problem, jak z aktualizacją czasu dotyczy też i aktualizacji pogody. I też nad tym pracują 🙂
4. Aktualizacje w tle. Przy sprawnie działającej sieci proces aktualizacji trwa co prawda 2-3 sekundy i nawet, gdy spoglądając na pogodynkę akurat się trafi na ten moment, nie jest problemem chwilę zaczekać, ale jednak fajnie byłoby, gdyby aktualizacja odbywała się w tle. Nawet kosztem chwilowego zamrożenia wyświetlacza. Nad tym warto byłoby pomyśleć…
5. Spolszczenie. Niby bezproblemowe, wystarczy w settings.h, w punkcie 6 zmienić wartość LANGUAGE na PL. Tyle, że wtedy mamy problem po pierwsze z polskimi znakami, więc trzebaby podmienić pliczek z fontami, po drugie – i tak część danych z wunderground schodzi po angielsku, więc tak czy tak będziemy mieli na ekranie miks polskoangielski. Szczerze mówiąc nie wiem, czy jest sens.
6. Cokolwiek. Bo tak. Pogodynka jest tak po prawdzie samodzielnie działającym komputerkiem z dostępem do internetu i właściwie tylko od nas zależy, co jeszcze będzie robić i co wyświetlać. W niedawnej dyskusji z kolegą padły np. takie pomysły, jak wyświetlanie aktualnych imienin albo, jeśli komuś mało codziennych absurdów, aktualnego paska z TVP Info 🙂 Kwestia tylko znalezienia źródła danych do wyświetlania i dopracowania ich pobierania i wrzucania na ekran. I tu jest właściwie pełna dowolność, można dorzucić osobny „ekran” z własnymi rzeczami do wyświetlania, można przeorganizować ekran główny, np. usuwając grafikę z fazami księżyca oraz ich tekstowy opis (jeśli ktoś nie ma predyspozycji do bycia wilkołakiem, fazy księżyca może nie są dlań aż tak istotne, by być na ekranie głównym) i tam wstawić coś własnego – zasadniczy plik softu jest zrobiony tak przejrzyście i schludnie, że naprawdę, nie jest problemem się przezeń przegryźć.

Obudowa

No, tutaj to już naprawdę, co kto lubi, co kto może i co potrafi. Jako przykład ekstremalny – obudówka znaleziona na Thingiverse:

I moja, w ulubionym ostatnio stylu „nagrobkowym” 😉 rzecz jasna drukowana na 3D, zaprojektowana trochę „na kolanie”, bo jakoś nie miałem pomysłu na bardziej wymyślną formę. Ale może coś wykombinuję jeszcze 🙂

Moja pogodynka nie ma touchpada, więc musiałem dorobić guziczek do naciskania przycisku zmiany stron ekranu, wytoczyłem go z kawałka gwoździa, delikatnie poszerzony z tyłu siedzi w otworze, oparty o oryginalny przycisk, nie wypadnie.