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.

Dokumentacja!

Przy pracy nad Nettigo Air Monitorem powstał serwis air.nettigo.pl, w którym zebraliśmy dokumentację dotyczącą NAM i nie tylko. Spełnił swoje zadanie, jednak z czasem aktualizacja i dodawanie nowych treści stało się kłopotliwe.

Dlatego po przeprowadzeniu kilku testów zdecydowaliśmy się na przeniesienie dokumentacji na serwis oparty o Wiki.js. W zasadzie pierwsza część migracji została zakończona, choć nie wszystkie treści jeszcze tam się znalazły.

Ale już oficjalnie możemy podać adres docs.nettigo.pl jako miejsce gdzie szukać dokumentacji do naszych projektów. Wersja anglojęzyczna też jest: https://docs.nettigo.pl/en/home

Jak wybrać zestaw NAM?

Zestawów Nettigo Air Monitor jest w naszej ofercie już sporo i dla osoby, która nie orientuje się w całym ekosystemie, może być trudne zrozumienie różnic między poszczególnymi zestawami.

Dlatego zaświtał nam w głowie taki rodzaj kreatora, który podpowie, jaki wybrać zestaw. Jeśli nie wiesz czy wybrać zestaw Sensor Community czy NAM, to spróbuj skorzystać z tego narzędzia:

https://nettigo.pl/articles/nam_selection_guide

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.

NAMF-2019 – problem z Luftdaten

Od 11-go sierpnia niektórzy z użytkowników NAMF-2019 zgłaszają problem z działaniem NAMa. Objaw jest taki, że nie pojawiają się żadne dane – ani w Luftdaten, ani w AQI.ECO czy innym API.

Wygląda na to, że 11-go sierpnia zmianie uległa część infrastruktury Luftdaten, rezultat jest taki, że NAMF-2019 bazowany na starym kodzie LD (fork sprzed 1,5 roku) podczas wysyłania danych do LD resetuje się.

Wstępne testy pokazują, że wyłączenie HTTPS przy wysyłaniu danych do LD pozwala sensorowi działać. Również upgrade do NAMF-2020 jak opisano wcześniej rozwiązuje problem (bez wyłączania HTTPS).

Wyłączenie HTTPS do Lufdaten tymczasowo rozwiązuje problem – docelowo – migracja do NAMF-2020

Sprawdzimy dokładniej przyczynę restartu oprogramowania NAMF-2019 ale sugerujemy migrację do NAMF-2020 jeśli to możliwe.

NAMF-2020-32 i NAMF-2019-021

Dziś na serwerach wylądowały nowe binarki, zarówno dla NAMF-2019 jak i NAMF-2020. Funkcjonalnie nie ma zmian dla 2020. W starej wersji wprowadziliśmy możliwość uaktualnienia do nowego firmware 2020.

UWAGA! Na razie rekomendujemy to tylko tym, którzy mają łatwy dostęp do sensora.

Zmiana NAMF-2019 (domyślnie dotąd instalowanego na sprzedawanych kitach w Nettigo) na NAMF-2020 oznacza zmianę układu systemu plików, potencjalnie może wyzerować konfigurację czujnika. Bezproblemowa migracja jest możliwa dzięki zapisowi konfigu w EEPROM, i pierwsze jego odczytanie stamtąd przez NAMF-2020. Nasze testy przeszły bez problemów i mam nadzieję, że na szerszej bazie nie wyjdą jakieś problemy.

Oczywiście jeśli chcesz update do 2020 – klikasz w pierwsze Zapisz i zrestartuj

Sugerujemy upgrade tylko jeśli możesz w razie czego łatwo skonfigurować sensor od nowa. Upgrade odbywa się przez wejście na stronę IP_SENSORA/forceUpdate i wybranie odpowiedniej opcji. Jeśli konfiguracja się nie zapisała w EEPROM na tej stronie będzie taka informacja (migracja wtedy oznacza na pewno wyzerowanie konfigu)

Tradycyjnie NAMF-2020-32 na GitHubie