Menu Zamknij

BedsideTableDisplay czyli zegar na szafkę nocną mocno z InfluxDB korzystający

Zegar to mój powracający od dawna projekt konstruktorsko-elektroniczny. Bieżąca iteracja zapisuje dane o temperaturze do InfluxDB (chwilowo just for fun) oraz pobiera dane ze stacji pogody.

Poprzednie iteracje zegara to zegar-beta – bazujący na arduino nano służący głównie jako budzik (alfa to niezrealizowany projekt olbrzymiego wyświetlacza), zegar-delta – zasadniczo RaspberryPi z wyświetlaczem oraz webgui do konfiguracji budzika i prymitywnym zbieraniem danych oraz zegar-gamma czyli powrót do korzeni w formie arduino, ale ze sterowaniem na pilota.

zegar-beta – pierwszy z serii

BedsideTableDisplay to przede wszystkim przedłużenie Nettigo Air Monitora oraz zegar. Niby dane można odczytać z telefonu ale wyświetlacz zawsze bardziej zachęca do spojrzenia na odczyty i docelowo ładniej się prezentuje.

BedsideTableDisplay (czyli teoretycznie zegar-epsilon)

Ponieważ postanowiłem że nie będę dodawał dodatkowych bridgy do łączności mikrokontroler-internet (np. bluetootha aktywnego w RaspberryPi) tylko wejdę w „IoT”.

Uznałem że skorzystam z tego samego modułu co NettigoAirMonitor, czyli Wemos D1 Pro – najładniej (z tych które wydziałem) upakowanego układu ESP8266. Konkretny model opisany jest na wiki Wemos. Cena to około 30zł, a więc również jest dobrze – tyle można zapłacić za arduino nano, a wartość dodana w postaci WiFi i procesora obsługującego bez problemu SSL w HTTPS jest ogromna.
Co prawda jest w Internecie trochę narzekania na obsługę ESP8266 w środowisku Arduino, ale da się to przeżyć.

Skoro mamy już WiFi warto dodać obsługę NTP żeby ręcznie zegara nie ustawiać. TimeLib to gotowa biblioteka do obsługi czasu w Arduino, ma też gotowca do obsługi NTP pod ESP8266 (konkretniej używając ESP8266WiFi.h). Dodałem do niego drobne usprawnienie – zapewnienie czasu innego niż 00:00 na starcie poprzez ponawianie zapytań.

UX zapewnia wyświetlacz OLED (niestety lekko mały, znacznie większych nie ma na rynku) i pilot na podczerwień – oszczędza to liczbę pinów i problemu z fizycznym umiejscowieniem przycisków, zwłaszcza w ew. obudowie.

Poza czujnikiem podczerwieni (VS1838B – taki był pod ręką) są jeszcze 2 sensory – fotorezystor (obsługiwany przez jedyny ADC w ESP8266) i klasyczny Dallas DS18B20 czyli termometr na OneWire.

Ważna uwaga o OneWire w ESP8266, a przynajmniej w Wemosie D1 mini pro – na pewno nie działa port D0 (brak obsługi przerwań) ale jedyny port na którym chciał ruszyć to D4 – kupiłem nawet trzeci czujnik myśląc że 2 poprzednie spaliłem złą polaryzacją napięcia…


Pinout dla Arduino, bowiem numery i możliwości portów to mała pułapka
źródło: https://escapequotes.net/wp-content/uploads/2016/02/d1-mini-esp8266-board-sh_fixled.jpg

Szkieletem konstrukcji są 2 płytki prototypowe 3x7cm, śruby łączące wspomniane płytki oraz nóżki. W kanapce między płytkami mamy przestrzeń na kable z górnej płytki łączące peryferia z mikrokontrolerem, dolna płytka nie ma żadnych elementów poza nóżkami. Zasilanie to port microUSB samej płytki Wemos.

Kod w C++ oczywiście trafił na Githuba. Ale co ze schematem? Szukałem długo narzędzia niezbyt dziecinnego (czyli bez klasycznych arduinowych kabelków i breadboarda) ale i takiego żebym je obsłużył. Ostateczny wybór to CircuitMaker od Altium. Jest co prawda tylko pod Windows, ale jako że nie ma za bardzo standardu pliku do schematów elektronicznych to uznałem że export do PDF/obrazka wystarczy na potrzeby projektu. Poza tym środowisko całkiem fajne gdyż mamy wbudowaną bazę elementów elektronicznych (w sumie jedyne środowisko które miało pinout ESP8266!), obsługę projektowania płytek drukowanych (export plików gerber) i system hostowania projektów – podobny do Thingverse (gdzie można trzymać projekty do druku 3D). Projekt części fizycznej BTD trafił zatem na CircuitMakera.

Schemat stworzony w CircuitMakerze

Co z tytułowym InfluxDB? Otóż dane z NettigoAirMonitor pobierane są właśnie z tej bazy danych. Otrzymuje ona też aktualne wartości temperatury i natężenia światła. Stąd tylko krok do wrzucenia pomiarów w Grafanę. Tu jeszcze jedna uwaga – Grafana wymaga zrobienia jednego Data Source na każdą bazę danych Influxa.

Jak InfluxDB to i Grafana

Dodaj komentarz