Category: NAM

Posted on

NAMF-2020-46rcX

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.

Posted on

NAMF-2020-46rc7

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.

Posted on

ZE25a-O3 – pierwszy rzut oka na ozon.

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.

Posted on

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!

Posted on

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.

Posted on

Co z NAMami PRO?

Często dostajemy pytania o NAMy PRO. Nie ma ich bo są ciągle problemy z jakością Wemosów PRO. Niejako jest to nawet zabawne jak różne problemy się pojawiają, w zależności od fabryki. Albo nie działa zasilanie 5V, albo są problemy z WiFi na zewnętrznej antenie. Oprogramowanie rzucające wyjątkami w losowych momentach podczas komunikacji WiFI. Albo, dość ciekawe w sumie, niby wszystko działa, poza I2C. Przecież I2C jest realizowane programowo, ale jednak nie, Wemos działa wspaniale dopóki nie wsadzić go w NAMa i próbować zeskanować linie I2C. Cisza. Wsadzamy Wemosa D1 mini (zwykłego) – działa 🙂

Jeden z pierwszych prototypów NAM (częściowo) SMD

Cóż, nie będzie chyba już tych Wemosów. Ale sa na rynku od lat sprawdzone i zawsze działające układy ESP07s od AI Thinker. Ponieważ NAM z zewnętrzną anteną są potrzebne więc początkowo (nawet kilka prototypów było) chcieliśmy przejść na pełen montaż SMD. Ale… jak się okazało i tak od THT nie uciekniemy (albo inaczej – przejście na pełne SMD będzie wymagało znacznie większej liczby iteracji, by upewnić się że mechaniczna wytrzymałość złącz XH będzie wystarczająca) więc koszt takiej płytki poszedł za bardzo w górę i chwilowo projekt NAMa SMD został zawieszony. Drugim powodem jest to, że NAM SMD rozwiązywał tylko połowę problemów. Gotowe, zlutowane zestawy byłyby dostępne, ale nie rozwiązał by problemu braku dostępności kitów do samodzielnego lutowania.

Dlatego powstało coś co sobie nazwałem Bidamos. Skąd nazwa to chyba nie trzeba mówić? 🙂 Założenie jest takie – moduł THT formatem i pinami zgodny z Wemosem, mający zewnętrzną antenę. Dla obcięcia kosztów – bez konwertera USB/Serial ale chociaż przycisk do programowania 🙂 zostawiłem.

Jeden z prototypów. Codename Bidamos

Chińskie święto LNY spowodowało jednak opóźnienie. Plan był by zrobić pierwszą serię przed LNY ale w testach wyszedł drobny błąd w PCB, więc… Nauczony już doświadczeniem nie puszczam na produkcję nieprzetestowanych projektów, więc… czekamy na ostatnią iterację testów…

TL;DR – NAMy PRO będą jeszcze dostępne. Zarówno w wersji zlutowanej jak i do samodzielnego montażu.

Posted on

Wemos PRO – nie działa z pinu 5V

Ostatnio zaczęły do nas trafiać Wemosy PRO, które mają “drobny problem“. Cóż, okazuje się, że nie chcą (przeważnie) działać z gdy są zasilane przez pin 5V. Poza tym – wszystko gra. Braliśmy dostawy z dwóch różnych źródeł – i, niestety to samo.

Wygląda na to, że układ USB/Serial jest w zmienionej rewizji i gdy nie ma napięcia 5V z USB – startuje w jakimś nieustalonym stanie, przez co podaje na wejścia ESP8266 taką kombinację, która nie pozawala poprawnie się uruchomić.

Nie muszę pisać, że jest to dla nas spory kłopot, bo właśnie z pinu 5V Wemosy są zasilane w NAMach. I dlatego od dłuższego czasu nie mamy dla was w sprzedaży zestawów w wersji PRO. Niedawno wróciła do sprzedaży wersja PRO już zlutowana. Stało się to możliwe, dzięki drobnej przeróbce Wemosa.

Otóż, Vusb od pinu 5V jest oddzielone diodą, przez co napięcie z pinu 5V nie dostaje się do Vusb. Ma to sens, bo w momencie podłączenia kabla USB zapewnia separację między oboma sieciami.

Skoro w NAM nie korzystamy z gniazda USB, zdecydowaliśmy (do czasu znalezienia wersji Wemosa PRO, która będzie normalnie działać zasilana z pinu 5v), usunąć diodę i zastąpić ją zworką w zestawach z gotowym NAM. W tym tygodniu, powinny do nas dotrzeć inne warianty Wemosa PRO (z innym konwerterem USB/Serial) i mamy nadzieję, że będzie można z nich korzystać bez problemu.

Jednak jeśli masz takiego Wemosa, mającego taką przypadłość i możesz bezpiecznie użyć zworki (czyli nie korzystasz jednocześnie z zasilania 5V i USB) to pomoże Ci korzystać z takiego Wemosa.

Posted on

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

Posted on

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.

Posted on

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.