W związku z tym, że nie wszystkie dane niezbędne do pełnej komunikacji z LoRaWAN były zachowywane po restarcie, a część tych danych jest trudna do wydobycia z wnętrzności biblioteki, na razie tryb pracy w LoRaWAN nieco został zmieniony.
Aktywacja (OTAA) będzie robiona po każdym restarcie, dopóki problem z zachowywaniem parametrów sesji nie zostanie rozwiązany. Aktywacja nie będzie przeprowadzana zaraz po starcie (by uniknąć generowania zbędnych żądań przyłączenia się do sieci) tylko dopiero przed wysłaniem danych. A dane (uśrednione) będą wysyłane co 5 pomiar.
Wcześniejsza wersja 47rc3 poprawiała dwa błędy związane z sygnałem alarmu na pin 7 restartera SDS.
Dziś na serwer trafiły pliki binarne dla wersji NAMF-47rc2 (oczywiście – w kanale aktualizacji beta). Przynosi ona dość istotne nowości. Pierwsza, którą docenią zwłaszcza ci którzy mają rekuperację w swoich domach.
Jeśli Twój NAM wyposażysz w restartera SDS011 to w konfiguracji SDS możesz ustawić alarm włączający się zadaną wartość PM2.5 lub PM10.
Uwaga – umknął mi fakt, że zmieniłem pin 1 na pin 7, więc opis w konfiguracji nie jest właściwy, ale że odkryłem to po wystawieniu binarek, to dopiero w wersji rc3 to się zmieni. Przy takich ustawieniach pin 7 restartera (na drabince golpin pin najbliżej zielonej diody) przejdzie w stan wysoki przy 55 µg/m³ a wyłączy się ponownie gdy PM2.5 spadnie do 45 µg/m³. Można wybrać PM10 jako wartość do śledzenia. Alarm sygnalizowany jest przez stan wysoki na tym pinie (czyli 3.3V).
Jeżeli masz w domu mechaniczną wentylację możesz w ten sposób otrzymać informację o potrzebie jej wyłączenia gdy powietrze jest złej jakości. Wyprowadź ten sygnał na zewnątrz (nie zapomni o “pobraniu” również GND ze złącza EXT lub któregoś z gniazd HX) i możesz sterować urządzeniem.
Podobne rozwiązanie możesz osiągnąć korzystając z automatyki domowej (czy to Home Assistant czy Domoticz), są też gotowe komercyjne rozwiązania. Tutaj przewagą jest prostota – jeśli nie masz HA/Domoticza to też będzie działać. Jako że działa to lokalnie, nie wymaga to dostępu do chmury jak to ma w przypadku niektórych rozwiązań które spotkasz u konkurencji.
LoRaWAN
Pojawił się oczekiwany przez niektórych od dłuższego czasu zestaw NAM 0.4 – oparty o ESP32 i działający w LoRaWAN. Zestaw jest jeszcze w wersji beta, ale jeśli ktoś jest mocno zainteresowany przetestowaniem – to zapraszam. Wersja NAMF-47rc2 pozwala już skorzystać z LoRaWANu – wystarczy że jesteś w zasięgu sieci The Things Network. Druga dobra wiadomość dotycząca TTN jest taka, że poza byciem w zasięgu nie potrzebujesz dodatkowej infrastruktury – Tomek Rękawek, autor serwisu aqi.eco dodał integrację, która pozwala wysyłać dane z TTN do aqi.eco! Ale o szczegółach, to napiszę na Starter Kit, opisując konfigurację. Na razie dostępna jest instrukcja lutowania zestawu NAM 0.4.
DNMS – walcz z hałasem!
Kolejna duża nowość – to wsparcie dla DNMS! Digital Noise Measurement Sensor to jest, jak sama nazwa wskazuje, czujnik mierzący natężenie hałasu. No i od wersji 47rc2 jest już obsługiwany przez NAM.
Na dokładkę – lada dzień w sprzedaży u nas pojawi się zestaw do zlutowania, który pozwoli zbudować taki czujnik.
Uważni obserwatorzy (wiem że tacy są 🙂 ) zauważyli pewnie to pojawienie się literki a przy numerze wersji. Został poprawiony jeden drobny błąd – format danych Prometheus. Od dłuższego czasu wkradł się tam jeden nadmiarowy znak, psujący wszystko.
Format Prometheus jest odziedziczony po kodzie Sensor Community i chyba nie jest u nas intensywnie wykorzystywany (dlatego dopiero po długim czasie ten nadmiarowy nawiasik wyszedł na jaw), ale przy tej okazji sprawdziłem dokładniej czym jest Prometheus.
I muszę powiedzieć jako zwolennik rozwiązań open source, że spodobał mi się 🙂 Jest to system zbierania danych nieco podobny do InfluxDB. Można poczytać więcej na stronach Prometheusa.
Po pewnym poślizgu, kilka dni temu na serwerze pojawiła się w końcu nowa wersja NAMF. W skrócie, co się zmieniło:
jest procedura resetu do ustawień fabrycznych – 3krotne naciśnięcie reset w krótkich odstępach czasu (ok 5-10 sekund) spowoduje wymazanie całej konfiguracji
jeśli masz w swoim NAM LCD możesz skonfigurować wygaszanie podświetlenie w określonych godzinach. Gdy LCD świeci ci w okno możesz go np od północy do 6 rano wyłączyć (podświetlenie)
BH1750 – sensor natężenia światła otoczenia jest obsługiwany
LoRaWAN – tu trochę się chwalę, bo jeszcze wersja płytki/sensora współpracująca z LoRaWAN nie jest publicznie dostępna, ale wersja NAMF-2020-46 przyniosła wiele potrzebnych zmian by wreszcie ją upublicznić. Plan jest by była dostępna (wersja LoRaWAN) jeszcze w tym roku.
Dziś rano trafiły na serwer nowe binaria, z wersją NAMF-2020-46. Niestety po kilku godzinach z analizy logów wyniknęło, że jakaś niewielka część NAMów, która dokonała aktualizacji wpadła w pętlę restartów.
Przywrócona została poprzednia wersja i problem ustał. Będziemy analizować przyczyny, by postarać się ustalić czy to problem był powszechny czy dotyczył tylko niewielkiej grupy. Jednakże ze względu na okres urlopowy u nas – kolejnego podejścia do wypuszczenia wersji NAMF-2020-46 można spodziewać się dopiero na koniec września.
Ponieważ zmienił się sposób zapisu konfiguracji LCD – jeśli twój sensor nie wyświetla nic na LCD – może zdarzył sie zaktualizować i po powrocie do wersji -45a “zgubił” ustawienia. Po prostu skonfiguruj LCD ponownie.
Powinna już być wersja stabilna NAMF-2020-46, jednak zamiast tego pojawi się jeszcze kilka wersji 46rcX. Dlaczego? Przyznam się, nie śledziłem tego parametru dokładnie, dopiero przed wypuszczeniem NAMF-2020-46 sprawdziłem statystyki. Od wersji NAMF-2020-46rc6 znacznie wzrosła liczba błedów sum kontrolnych w komunikacji z SDS011.
Eksperymentowałem z ustawieniami które mogły na to wpłynąć na sensorach w naszym labie, ale… mimo że jest ich niemal 10 szt to dane zebrane są dość niejednoznaczne. By przyspieszyć zbieranie danych zdecydowałem się wypuścić parę wariantów na linię beta by zebrać więcej danych w krótkim czasie.
Dlatego w tym tygodniu można się spodziewać kilku wersji beta, oraz możliwe że nawet pewne cofnięcie. W tej chwili jest rc10, jeśli poprawa nie będzie zadowalająca – jutro będzie jeszcze rc11 i może rc12 pod koniec tygodnia. Może się zdarzyć powrót do wcześniejszej wersji by zebrać kolejne dane.
Dlatego, do osób które mają wersje beta włączone – jeśli zaniepokoi was częsta zmiana wersji, to mam nadzieję, że ten wpis wam to wytłumaczy.
Gdy znajdę przyczynę tego wzrostu i uda się zbić poziom błędów – pojawi się wersja stabilna.
Zmiana drobna, ale przydatna. Od teraz pojawiać się będą linki do pomocy w konfiguracji NAM. W tej chwili jest to symbol kompasu, który wiedzie do stron z krótkim opisem. Np jak ten.
Czemu kompas? Bo ikonki użyte przez NAMF oparte są o symbole dostępne w Unicode. I jakoś nie znalazłem lepszego. Jest ładny znak zapytania, ale biały na biały to tak słabo, a czerwony – nie bardzo pasuje.
Opiera się to o system stron które są generowane razem z kodem na GitHubie. Zaletą jest prostota całości, a struktura pozwala na utrzymywanie różnych wersji językowych. Na razie jest tylko struktura, nad tłumaczeniami (oraz rozszerzeniem listy tematów) to jeszcze muszę popracować 🙂
Wadą jest to, że skoro pliki pomocy są na GitHubie to niezbędny jest dostęp do internetu. W momencie gdy konfiguruje się pierwszy raz NAMa i ma się połączenie z AP w NAM, zwykle nie ma dostępu do sieci, ale to już zależy od ustawień telefonu.
I tak, zaraz będzie jeszcze wersje rc8, bo byłem przekonany, że wersja rc7 obejmuje wszystkie niezbędne tłumaczenia/napisy jeśli chodzi o języki, a jednak nie, więc lada moment będzie rc8. I na podstawie tego będzie pewnie już wersja stabilna.
Z innych zmian – dokończona została implementacja czujnika światła BH1750.
Co dalej?
Następne wersje będą miał zmienioną nieco numerację. Skoro jest i tak obecnie jedna linia oprogramowania, z numeru wersji “wyleci” 2020, czyli po NAMF-2020-46 następna wersja to będzie NAMF-47.
W wersja 47 to będzie przede wszystkim – dokończenie wersji ESP32 z LoRa (i może Ethernet, ale to nie jest główny cel). Z sensorów – pierwsze testy Winsen ZE25A są bardzo ciekawe, więc mam zamiar dodać obsługę tego sensora O3 do NAM.
Od niedawna w naszej ofercie jest nowy sensor Winsena – ZE25a-O3. Jest to sensor O3, czyli ozonu. Jak w opisie produktu wspomniałem, jakiś rok temu testowaliśmy ZE27-O3. Jednak tamten mający rozdzielczość 10 ppb (o ile dobrze pamiętam) to nie było to na co czekałem.
ZE25a-03 ma tą zaletę, że jego protokół UART jest wspólny z ZE27, więc mogłem skorzystać ze kodu napisanego rok temu podczas testów ZE27. Wystarczyło skorzystać z rozebranego NAMa jako platformy testowej, trochę gorącego kleju, ucięcie kabla dołączonego do sensora i proszę:
Po kilku godzinach działania (wartości w ppb):
W najbliższych planach – wsadzić dla porównania ZE27 obok i zobaczyć jak wyglądają odczyty. Drugi test – to wziąć kolejny sensor ZE27 i wystawić w pobliżu ruchliwej drogi. W tej chwili, sensor jest wystawiony w miejscu gdzie źródeł ozonu specjalnie nie ma. Ogród, z dala od ruchu samochodowego.
Dziś tego nie zdążyłem zrobić, ale na ile rozumiem specyfikę pomiaru trzeba dodać czujnik temperatury i ciśnienia, bo te dwie wartość wprost wpływają na przeliczenie wartości ppb na µg/m³.
Nikt pytania na razie nie zadaje, ale… skoro na płycie NAMa jest test, to czy planuję umieszczenie wsparcia w NAMF?
Nie powiem, jest to interesujący parametr. O3 w naszym otoczeniu to głównie wynik rozpadu tlenków azotu (NOx) ze spalin pod wpływem światła słonecznego. Nie trzeba mówić, że latem może to być problem w terenie gdzie występuje ruch samochodowy.
Temat chyba jest warty zbadania, bo jeśli dobrze liczę to wskazania na poziomie 105 ppb przy obecnym ciśnieniu i temperaturze to ok 200 µg/m³. Sporo.
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!
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.
