BH1750 czyli o świetle i NAMie

Jak pisałem przy okazji NAMF-2020-46rc5 dodałem wstępną obsługę czujnika natężenia światła otoczenia – BH1750FVI, który w formie modułu jest dostępny na Nettigo. Podłączenie jest dość proste, bo sensor pracuje na szynie I2C, nie ma kolizji adresów, gładko. Ale podłączenie to jedno, a wystawienie go na światło to druga sprawa.

Najprościej (kwestia utrzymania względnej szczelności obudowy NAM, zwłaszcza od góry) byłoby zostawić sensor w środku. Ale czy jego wskazania będą miały jakiś sens? Zwłaszcza, że od długiego już czasu do każdego NAMa dodawana jest ochronna naklejka.

Dlatego, wyniki kilkudniowych testów! Jeden sensor został pozbawiony kopułki rozpraszającej światło i umieszczony pod pokrywką, na której jest standardowa naklejka. Drugi, przez rozszczelniona obudowę został wystawiony nad NAMem. Mówimy o dwóch różnych NAMach, wiszących jeden obok drugiego.

Oba NAMy znajdują się na wschodniej ścianie budynku, pod dachem, więc rozszczelnienie obudowy jednego nie stwarza problemu. Jaki rezultat?

Dzień słoneczny (31.03.2024)
Dzień pochmurny (3.04.2024)

OK. Pierwsze wyniki – stosunek odczytu wartości tego z BH1750 na zewnątrz do tego “pod” naklejką jest mniej więcej stały, między 8.1 a 8.8. Czyli np jak ten wewnątrz pokazuje 138 to ten na zewnątrz 1167 luxów. I zarówno w dzień słoneczny jak i pochmurny ten stosunek jest zachowany.

Wstępny wniosek? Spokojnie można wsadzić BH1750 do środka obudowy i nie przejmować się kłopotami z wyprowadzeniem sensora na zewnątrz. Bo uszczelnić nie tylko obudowę NAM trzeba jak i kopułkę BH1750 – która jest nałożona na wcisk i to taki niezbyt silny…. Wygląda na to, że rule of the thumb będzie – pomnożyć odczyt przez 8.5 jeśli sensor jest wewnątrz obudowy z naklejką. Muszę to przemyśleć, bo dotąd nie było takiej opcji “modyfikowania” odczytu.

Jeszcze trochę poobserwuję zachowania sensorów – raz, w słoneczny dzień dzielnik spadł do 7.5, ale wydaje mi się, że to było w momencie gdy słońce przestało już świecić bezpośrednio na “zewnętrznego” BH a ten schowany w obudowie był jeszcze w słońcu. To z oczywistych względów zaburzyło stosunek wartości odczytów z obu sensorów.

W kwestii czujników natężenia światła – dobra wiadomość jest też już taka, że niezawodne aqi.eco już wspiera odczyty natężenia światła! Dziękujemy!

NAMF-2020-46rc5

Dziś na serwerze z aktualizacjami umieściłem nowa wersję firmware. 46rc5 przynosi dwie istotne zmiany.

Czujnik BH1850FVI mierzy natężenie światła, było sporo pytań kiedy oficjalnie pojawi się dla niego wsparcie. No to już prawie oficjalnie, bo na razie tylko na kanale beta. Czujnik trzeba podłączyć do zasilania, I2C, żółty kabel może zostać luzem, będzie na domyślnym adresie 0x23.

Nie trzeba ustawiać adresu I2C, NAMF sam próbuje najpierw 0x23 a jeśli nie uda sie inicjalizacja to próbuje drugi adres, 0x5C.

Dane są zbierane i wysyłane do większości API (poza Sensor Community, bo ono nie obsługuje na razie takiej wielkości fizycznej). Pozostałe API nie korzystają jeszcze z tej wielkości. InfluxDB oczywiście przyjmie dane i jeśli masz np Grafanę, to zrobisz wykres.

Skoro większość API tego nie obsługuje, pojawia się pytanie po co? Dane są dostępne lokalnie (w /data.json), także świetnie się nadaje to do integrowania z Home Assistant czy Domoticz.

Druga zmiana jest dla wszystkich którzy lubią “więcej danych”. Od teraz NAMF mierzy czas potrzebny do wysłania danych dla każdego API – poza Sensor Community API. To ostatnie jeszcze nie jest mierzone, bo w odróżnieniu od pozostałych wysyłanie danych do SC jest bardziej rozrzucone po kodzie NAMF oraz wymaga oddzielnego wywołania dla każdej raportowanej wielkości fizycznej. Pomyślę też nad tym, ale na razie, dla pozostałych API podawany jest kod HTTP zwrócony przez API i czas ile całość zajęła (tylko dla ostatniego wywołania). Dane są dostępne tylko w interfejsie HTML, na stronie /status.

Co nowego z NAM?

Od pewnego czasu na biurku obok mnie leży sobie taki fioletowy gość.

Niby dobrze znajomy widok, a jednak nie tylko kolor się nie zgadza. Ten Wemos jakiś dziwny… Ano, bo to jest Wemos ESP32 D1 mini. Jak sama nazwa wskazuje, zamiast ESP8266 na pokładzie jest ESP32. Podstawowy układ pinów jest zachowany, ale sama płytka jest większa i ma dodatkowe piny. Jeśli miejsce pozwala (bo płytka ma większe rozmiary, aby zmieściły się dodatkowe piny) to można użyć go tam gdzie Wemosa z ESP8266 dostając nowe możlwości.

A jakich to możliwości szukamy? No cóż, zmieniać procesor na ESP32 dla samego zmieniania nie ma specjalnego sensu. Taki NAM nie różniłby się istotnie od zwykłego, no można by dodać Bluetooth, ale to trochę na siłę.

Ten NAM z ESP32 D1 mini powstał by przetestować czy uda sie uruchomić NAMF na platformie ESP32. No i poszło dość szybko, wersja bardzo beta okrojona z kilku właściwości działa od kilku dni. Teraz mając wersję firmware na ESP32 można przeprowadzić właściwe testy.

A testy te, oznaczają użycie gotowych modułów opartych o ESP32. Konkretnie Wireless Stick Lite od Helteca oraz ESP32 PoE z Olimexu. Mają one doprowadzić nas do NAM w wersji 0.4, która będzie korzystała z tych modułów jako bazowych (zamiast Wemosa). I tak, z Wireless Stick Lite będziemy mieli radio LoRa a z ESP32 PoE – port Ethernet z zasilaniem PoE.

Te dwa warianty chyba były najczęściej postulowane przez wielu użytkowników. Próby które prowadziliśmy z ESP8266 by dodać do niego radio LoRa lub Ethernet doprowadziły nas do wniosku, że lepsze będzie oparcie się o gotowe, sprawdzone platformy. A takie są na ESP32.

Główne założenia dla serii NAM 0.4 są następujące:

  • tak zwany “form factor” zostaje bez zmian – obudowa Kradexa Z59JpH
  • podstawowe czujniki też zostają – czyli SDS011/HECA/BME280
  • prawdopodobnie nie uda się zmieścić LCD znakowego, ale mamy pewne pomysły czym go zastąpić
  • poza standardowym WiFi w zależności od wariantu będzie możliwość skorzystania z LoRaWAN lub Ethernet z PoE

Koniec z NAMF w starszej wersji (2019)

Po wypuszczeniu wersji NAMF-2020-45 wczoraj również rozpoczęliśmy migrację starszych sensorów NAM, które działały na oprogramowaniu wprost odziedziczonym po Luftdaten. Wersje NAMF-2019-x dziś, do końca dnia powinny zaktualizować się do NAMF-2020-45.

NAMF-2020-45

Wczoraj została opublikowana nowa wersja NAMF-2020-45. Istotną zmianą (na która liczymy) powinno być obniżenie poziomu błędów w odczycie danych z SDS011. W wersji -44 była ona zdecydowanie za wysoka. Z testów na sensorach działających na wersjach beta -45 poprawa powinna być wyraźna.

Z mniejszych zmian to w konfiguracji sensora wprowadzony został wyróżnik opcji zaawansowanych. Takimi były np czas pomiarów i rozgrzewki SDS011. Takie ustawienia są teraz domyślnie ukryte, trzeba kliknąć w przycisk by je zobaczyć. W ten sposób podkreślamy, że nie ma potrzeby w podstawowej konfiguracji ustawiania tych wartości.

Zaawansowane opcje pojawiły się też dla HECA – pozwalają na ustawienie progów wilgotności dla których włącza i wyłącza się grzałka. Znowu – sugerujemy nie zmieniać tych wartości, jeśli nie macie istotnej potrzeby (dlatego pola te też są domyślnie ukryte).

Pojawiła się opcja przywrócenia starszej wersji oprogramowania. Dostępna jest przez stronę /rollback .

Te NAMy, które mają LCD mogą teraz wyłączyć również wyświetlanie informacji o urządzeniu czyli – można wyświetlać tylko dane z sensorów. Jeśli włączy się wyświetlanie tylko dla jednego (np SDS011) wówczas na wyświetlaczu będą prezentowane tylko te dane.

NAMF-2020-44

W poprzedni czwartek, 6 października na serwery trafiła nowa wersja firmware NAMF. Poza poprawkami błędów, zawiera dwie istotne zmiany.

Dla tych, którzy już mają swoje NAM uruchomione, dostrzegą przede wszystkim nową wersję strony konfiguracyjnej sensora. Wydaje się że teraz jest znacznie bardziej czytelna i uporządkowana.

Druga istotna zmiana – jeśli sensor wejdzie w tryb konfiguracyjny (np pierwsze uruchomienie) to sieć WiFi jest zabezpieczona domyślnym hasłem. Nazwa sieci (domyślna) nie uległa zmianie – NAM-XXXX gdzie XXXX jest identyfikatorem ESP8266 (chip ID) a hasło to nettigo.pl To są wartości domyślne, można zmienić w konfiguracji.

Szczegółowa lista zmian jak zawsze w pliku Versions w repozytorium NAMF.

NAMF-2020-41

Wczoraj na serwerach wylądowała wersja NAMF-2020-41. Zawiera kilka poprawek (Winsen MHZ14A znowu działa, LED BAR przywrócony do życia).

Dla użytkowników zlutowanego sensora NAM ważna opcja – BMP180 jest w tym zestawie zlutowany oddzielnie i powinien być umieszczony w obudowie NAMa. Dlatego pojawiła się dodatkowa opcja w konfiguracji dla takiego zestawu. Po jej zaznaczeniu temperatura z BMP180 nie będzie wysyłana do API. Jako że wewnątrz obudowy, to jest wyższa o kilka/kilkanaście stopni, więc nie ma co karmić złymi danymi API.

Nowa opcja konfiguracyjna

Dane diagnostyczne

Poczynając od tej wersji podstawowe dane diagnostyczne są wysyłane do Nettigo (zajętość pamięci, siła sygnału WiFi, ewentualne błędy w komunikacji z SDS itp). Szczegółowa lista zbieranych danych jest w repozytorium: https://github.com/nettigo/namf/blob/master/diagnostic.md

Można wyłączyć wysyłanie danych, jednak prosimy o pozostawienie tego, gdyż informacje zbierane o NAMach pozwolą nam tworzyć lepsze oprogramowanie.

NAMF-2020-37 – głównie poprawki błędów

Wczoraj pojawiła się na serwerach nowa wersja, oznaczona nr 37. Na blogu pominęliśmy informację o wersji 36, więc gwoli kronikarskiego obowiązku – wersja ta oparta jest o nowszy Arduino Core i oferuje poprawione wysyłanie danych do Sensor Community.

Wersja 37 z funkcjonalnych zmian zawiera nową podstronę /status na której można zapoznać się z informacjami z wnętrzności systemu. Dzięki temu strona z wynikami (/values) jest teraz czystsza i zawiera tylko informacje o odczytach.

Wersja 37 też zawiera sporo poprawek, oraz jeżeli korzystasz z Influxa – więcej danych zostanie wysłanych do tej bazy. Między innymi wersja oprogramowania, nazwa sensora.

Przepisaliśmy od zera obsługę SDS011, co pozwoli dodać ciekawe opcje konfiguracyjne. Kod ten dotąd był dostępny przez uaktualnienia na kanale alfa, ale już najbliższa wersja beta (38rc1) będzie zawierała ten nowy kod. W tej chwili to jest możliwość ustawiania czasu pracy “rozgrzewki” SDS przed pomiarem i czasu przez który jest robiony pomiar. Będzie go można wydłużyć zbierając więcej próbek.

Gdy wersja 38 będzie opublikowana w wersji finalnej, planujemy dokonać automatycznej migracji starszych sensorów z NMAF-2019 na linię 2020.

NAMF-2020-35 – Wyświetlacz dla nowych sensorów

Dziś na serwerach update wylądowały binaria nowej wersji NAMF, tym razem seria NAMF-2020-35. Poza usunięciem kilku oczywistych błędów, ta wersja zawiera kilka nowych rzeczy.

Parę wersji temu wprowadziliśmy nowego zarządcę w kodzie. Nie wszystkie sensory zostały na niego przeniesione. W tej wersji została zmigrowana do nowego zarządcy obsługa czujnika poziomu CO2 – Winsen MHZ14A (opis instalacji). Jednocześnie ten sensor może teraz wyświetlać dane na wyświetlaczu LCD (jeśli oczywiście NAM jest w niego wyposażony). Również SPS30 (dokładny czujnik Sensiriona do pyłów zawieszonych) może wyświetlać dane na LCD.

Dla piszących kod na platformie NAM – dużym ułatwieniem powinno być upload_config.ini W nim można ustawić parametry do wgrywania kodu. Np adres IP i hasło jeśli korzystać chcą ze zdalnego wgrywania kodu. W zasadzie, chyba każde ustawienie środowiska Platformio może zostać tam nadpisane. Plik jest w .gitignore więc wystarczy skopiować upload_config.ini.example i go wyedytować. Zmiany tak wprowadzone będą tylko obowiązywać na jednym komputerze, nie będą wrzucane do repozytorium GITa.

NAMF-2020-33

Dziś ukazało się stabilne wydanie oprogramowania NAMF oznaczone NAMF-2020-33. Funkcjonalnych zmian brak, poprawione błędy.

Pierwszy – firmware teraz respektuje ustawienie automatycznej aktualizacji (dotąd ukatualniał się za każdym razem gdy była nowa wersja, niezależnie od ustawienia opcji).

Dwa błędy dotyczyły sensora SPS30 – od teraz liczba cząstek mniejszych niż 0.5µm jest zapisywana i podawana w odczycie. Dotąd to było zawsze 0. Od teraz też włączenie obsługi SPS30 w NAMie w którym nie ma podłączonego SPSa nie blokuje całości.