Przepisanie firmware do czujników smogu

A czy nie dałoby się w miarę prosto zrobić ogólnie wykresów? Tzn z punktu widzenia użytkownika tak jak jest robione mapowanie, tylko poza obecnymi ‘temperature’ itp dodać np chart1 i byłby to taki wykres użytkownika, który sam by definiował co ma być wyświetlone.

Chodzi o to, że jeśli będą się pojawiały kolejne sensory/dane to za każdym razem jest wymagana Twoja interwencja w kod. A tak można by zrobić kilka wykresów użytkownika i on sam w konfiguracji by decydował co ma być wyświetlona na dodatkowych wykresach. Np jak już @irukard zrobi sensor promieniowania to już będzie gotowy mechanizm wyświetlania.
Ale nie wiem jak wygląda od zaplecza aqi.eco więc nie wiem czy to w miarę proste zadanie czy znacznie bardziej skomplikowane :wink:

1 polubienie

Wykres OK, ale ja bym również wrzucił dodatkowy rząd w tabelce tuż pod PM10. Brzmi logicznie i ma sens.

Cześć @netmaniac! Nie wiem czy pamiętasz, ale 9 lat temu współpracowaliśmy przy przenoszeniu kilku postów z mojego starego bloga https://newton.net.pl na https://starter-kit.nettigo.pl :slight_smile:

A czy nie dałoby się w miarę prosto zrobić ogólnie wykresów?

W tej chwili lista wartości które zapisujemy jest zdefiniowana na poziomie schematu bazy danych MySQL (listy kolumn). Taki stan rzeczy ma kilka zalet:

  • wydajność,
  • mniejsze użycie dysku,
  • łatwiejsza implementacja zbierania i agregacji danych.

I jedną podstawową wadę: trudność w dodawaniu nowych typów wartości.

Jak dotąd, z powodu zalet j/w (głównie prostoty implementacji) taki schemat się sprawdzał. Oczywiście, bardziej elegancko byłoby dać możliwość definiowania kolumn. Jest to jednak dość sporo pracy - pytanie, jak wiele osób skorzysta z nowej funkcji i czy się to opłaci: w sensie relacji ilość godzin spędzonych nad developmentem / zysk dla znacznej części użytkowników.

Obawiam się też nieco https://en.wikipedia.org/wiki/Inner-platform_effect - czy ostateczny efekt i tak nie będzie gorszy od zahardcodowania nowej kolumny np. CO2 i dodania wykresów w odpowiednim miejscu.

Rozumiem sugestie power-userów którzy chcieliby maksymalnie zwiększyć możliwości konfiguracji, ale są też głosy, że aqi.eco już teraz jest skomplikowne w użyciu od strony administracyjnej. Oczywiście można dodać nowe funkcje bez zwiększania komplikacji (wizardy, domyślnie konfiguracje, itd.) ale to sprawia, że implementacja ta będzie jeszcze bardziej kosztowna.

1 polubienie

Byłbym zainteresowany czujnikami H2S (siarkowodór) i SO2 (dwutlenek siarki). Czy wiesz, czego używa Airly?

Jak dokonać aktualizacji dla 2020 20 -czy to wersja beta? bo mam ustawione aktualizacje automatyczne
rozumiem ze forceUpdate i ok…? i wtedy jaka wersja się załaduje?

Nie, to tak nie działa. Po pierwsze w obecnej chwili przejście na NAMF-2020 oznacza całkowite zaoranie pamięci flash (SPIFFS) i konieczność konfiguracji od zera. Nowy FW to jedna wielka beta. Na tym etapie nie ma stabilnej wersji. Taka pojawi się jak rozprawimy się z zaszłościami historycznymi. FW jest wyposażony w narzędzia ułatwiające nam pisanie i debugowanie. W planie jest też mechanizm płynnego przejścia ze starej konfiguracji do nowej.

Przed migracją

Potrzebne będą:

  • Adres IP sensora
  • Hasło i SSID do sieci WiFi
  • Przydać się może ID sensora (w nagłówku strony sensora, obok logo Nettigo)
  • Sensor musi mieć włączoną opcję autoaktualizacji

Zadbaj o to aby znajdować się blisko sensora, by móc w czasie konfiguracji podłączyć do sieci WiFi utworzonej przez sensor.

Jeśli bieżąca wersja software czujnika to NAMF-2019-019 (lub wcześniejsza) to trzeba zmienić zrestartować czujnik - jeśli jest włączona autoaktualizacja. Jeśli nie to trzeba ja włączyć.

Migracja

Wejdź na stronę http://IP.SENSORA/config.json Zwróci ona bieżącą konfigurację sensora jako JSON. Zapisz ją sobie. Jeśli po wejściu na http://IP.SENSORA/config.json dostajemy komunikat “not found” oznacza to, że obecnie w urządzeniu jest stara wersja oprogramowania. Wymuś aktualizację.

UWAGA! Ze względów bezpieczeństwa w konfiguracji tej nie ma hasła do sieci WiFi. Zostało zastąpione przez trzy gwiazdki. Dlatego ściągnięty JSON trzeba przed wgrywaniem poprawić, zastępując gwiazdki hasłem do sieci WiFi. Przykładowy fragment konfiguracji:

"wlanssid":"NAZWA SSID","wlanpwd":"***"

Zastąpić

"wlanssid":"NAZWA SSID","wlanpwd":"TWOJE HASŁO"

Uważaj aby nie zmienić formatu JSON, tylko wpisać hasło między cudzysłowowy. Należy wkleić cały JSON, nie pomijać żadnych pól.

Nie testowaliśmy czy biblioteka JSON poradzi sobie ze zmianą formatu (jeśli wpiszecie Enter lub spację przed czy po przecinku) lub jakimś błędem składniowym.

Jeśli w haśle występuje znak “ zastąpić go sekwencją \”

Teraz wejdź na stronę http://IP.SENSORA/forceUpdate i wypełnij pola:

  • HOST: beta.fw.nettigo.pl
  • PORT: 80
  • PATH: /NAMF-BOOT/

Kliknij ‘Zapisz i zrestartuj’. Czujnik ściągnie nowe oprogramowanie i wykasuje zawartość systemu plików w pamięci sensora. Dlatego po restarcie uruchomi się ponownie w trybie access-pointa (jak przy pierwszym uruchomieniu). Odszukaj sieć WiFi o nazwie NAM-ID_SENSORA. Po podłączeniu się do niej odwiedź adres http://192.168.4.1/configSave.json

W pole tekstowe wklej zapisaną wcześniej konfigurację (pamiętaj o wpisaniu właściwego hasła do WiFi). Kliknij ‘Save and restart’. Czujnik powinien zrestartować się i podłączyć się do właściwego WiFi. Następnie ściągnie najnowsze oprogramowanie, już w pełni funkcjonalne. Przy włączonej autoaktualizacji nie potrzeba żadnych dodatkowych kroków.

Oczywiście zamiast wklejania konfiguracji w configSave.json można skonfigurować sensor ręcznie, procedura nie uległa zmianie.

Jak rozpoznać udaną migrację

Po wejściu na stronę czujnika wersja powinna mieć format np NAMF-2020-NUMER. Oznacza to udaną migrację. Wersja NAMF-2020-boot to wersja pośrednia, nowy firmware, ale okrojone funkcjonalności Trzeba wymusić aktualizację. Jeśli wersja jest NAMF-2019-NUMER to jest stare oprogramowanie.

Jeżeli zobaczysz ikonki przy opcjach w głównym menu, to wiedz, że jesteś na nowym FW.

scrnli_2-03-2020_10-15-12

Strona z aktualnymi pomiarami ciągnie się długo… bo na dole są dane diagnostyczne.

scrnli_2-03-2020_10-17-01

W konfiguracji w sekcji "Czujnik WiFi pole Nazwa jest zarazem nazwą dla trybu Access Point (etap rozgłaszania własnej sieci), nazwą mDNS (Bonjour/Zeroconf) oraz nazwą dla serwera DHCP. A więc polskich znaków diakrytycznych używasz na własną odpowiedzialność.

scrnli_2-03-2020_10-19-04

Wyświetlacz znakowy wybiera się z rozwijanej listy. Jest też możliwość ustawienia mocy nadawczej urządzenia. W niektórych przypadkach zmniejszenie mocy może powodować wzrost stabilności.

Pojawiła się też opcja włączenia Winsena MH-Z14A. Czy ma to sens w badaniu ilości CO2 na zewnątrz - czas pokaże. Na tym etapie zbieramy dane z Winsenów do InfluxDB. Jak będziemy mieć ich wystarczająco dużo, poddamy je analizie. Równocześnie monitorujemy temperaturę w środku obudowy (z użyciem DS18B20)

scrnli_2-03-2020_10-24-37

Wielkie dziękuje za szczegółowe informacje:-) chce własnie dokupić czujnik CO2.
Dla mnie jeszcze ważne aby wysyłać dane do domoticz i szukałem dużo ale nie znalazłem info jak to zrobić:-(
Czujnik pracuję od ponad tygodnia bez zarzutów na razie i korzystam z Aqi.eco do podglądu.
Całość projektu super!!!

Ja właśnie sobie piszę coś na kształt aqi.eco, żeby agregować swoje wszystkie czujniki w domu.
Całość pisana w .NET Core (jeszcze 2.2, bo taki hosting) + Vue + Vuetify.
Kierunek danych jest następujący: NAM (wysyła do) -> Moje API (wysyła do) -> aqi.eco.
Moje api może agregować wiele stron - do api dolatuje czysty JSON z czujnika, więc mogę z nim zrobić co tylko chcę.
Link do wersji mocno dev (moje domowe czujniki są ukryte i widoczne pod innym adresem): http://meteo.pkozak.aspnet.pl/

Przyznam się bez bicia, że chcę dążyć do czegoś w stylu api.eco w przypadku danych o czystości powietrza, tym bardziej, że teraz wykresy pokazują dane chwilowe - aqi agreguje dane.

Myślę, że mógłbyś coś nakodzić i odpalić tam gdzie masz postawiony domoticz -> czyli coś w moim stylu, jakieś api agregujące Twoje serwisy, czyli:
NAM -> Twoje API -> Domoticz i aqi.eco

https://nettigo.aqi.eco/pl/ogrod
https://nettigo.aqi.eco/pl/ogrod/graphs

Ostatecznie dodanie nowego pola w bazie poszło całkiem sprawnie:

2 polubienia

Fajne, tylko przydałaby się informacja co to znaczy :wink: czy to dużo, czy mało :wink:

Nie znalazłem żadnych norm dot. CO2 w atmosferze, jedynie takie mówiące o CO2 w zamkniętym pomieszczeniu (np. 600 ppm - granica odczuwania “świeżego powietrza”, pow. 1500 ppm - spadek koncentracji).

Z drugiej strony, nie chciałbym oznaczać aktualnych 473 ppm jako stanu niskiego, bo musimy - jako ludzkość - zrobić coś, żeby tę wartość zmniejszyć lub przynajmniej zahamować jej wzrost.

W związku z tym pomyślałem, że może lepszym miejscem dla wartości CO2 będzie pasek z informacjami pogodowymi:

https://nettigo.aqi.eco/pl/ogrod

1 polubienie

Tylko w tym momencie w pasku pogodowym wartość XXX ppm jest dla 99% odbiorców nic nie mówiącym kosmosem. Mnie również nic to nie mówi :slight_smile: Czy to jeszcze OK, czy już za dużo. Jakaś legenda czy też interpretacja wyniku musi tam być. Ja bym optował za pozostawieniem tego w poprzednim miejscu jako kolejny rząd w tabelce, ale z jakąś naszą interpretacją czy dużo czy mało/źle czy dobrze.

@irukard - możesz dodać kontekst dot. pomiaru CO2? Czy ta wartość ma służyć tylko zaspokojeniu ciekawości, informować o wysokim stężeniu (i zagrożeniu) w danej chwili podobnie do PM10 lub PM2.5, czy może informować bardziej długoterminowo. Jak Twoim zdaniem najlepiej tę wartość zaprezentować?

Zostaw tak jak jest. Dla mnie to wystarczające. Na wykresie jest literówka. Powinno być ppm nie ppe.

Co do kontekstu… dla nas pomiary CO2 to nowość. Ze zdrowotnego punktu widzenia mają sens w pomieszczeniach, ale nam zależy na pomiarach klimatycznych, dlatego staramy się zmodyfikować obsługę Winsensa tak aby się do tego nadawała. W teorii przy danych uśrednionych z miesiąca można by namierzyć dużych emiterów CO2. Zobaczymy co z tego wyjdzie.

A tak w ogóle - to wielkie dzięki za dodanie obsługi :smiley:

2 polubienia

Czy planujesz dodać czujniki NO2, SO2, CO, H2S?

@Tomek nie wiem czy trafiłeś na tę tabele.

Szczerze powiedziawszy to nie wiem czy jest sens w prezentacji stężenia CO2 w czujnikach umieszczonych na zewnątrz.
Po pierwsze nie ma żadnego punktu odniesienia (ustalonych norm) i nigdy nie będziemy wiedzieć czy dany poziom jest “zły” czy “dobry”.
Po drugie CO2 często pochodzi z procesów życiowych roślin i zwierząt. Jest więc dość prawdopodobne, że poziom CO2 będzie się wahać w cyklu dobowym w czasie wegetacji roślin. Wówczas interpretacja czy podwyższone poziomy (np. nocą) są odpowiednie może być utrudniona, zwłaszcza bez opisu tła i otoczenia czujnika (należałoby wtedy brać jakąś korektę).
Po trzecie - od dłuższego czasu dużo się mówi o ograniczeniu CO2 w powietrzu, ALE zazwyczaj odbywa się to poprzez przeliczenie emisji ogółem. Myślę więc, że te “delikatne” zmiany poziomów stężenia nie będą miały RZECZYWISTEGO odniesienia do celu ograniczenia emisji CO2 ogółem (przeliczeniowo).
Po czwarte należy zwracać uwagę na cel pomiaru jakości powietrza. Sama informacja o czymś nie wiele mówi, zwłaszcza dla osób bez wiedzy specjalistycznej, a dla zwykłego użytkownika będzie tylko liczbą. Stąd tak ważna interpretacja danych i odniesienie do konkretnych norm.
Po piąte mając na uwadze cel pomiarów (ocena jakości powietrza na zewnątrz) kluczowym jest dodawanie czujników dających pozostałe ISTOTNE informacje o jakości powietrza w odniesieniu do przepisów krajowych (ewentualnie europejskich). Dlatego priorytetowo należy traktować możliwości pomiaru tlenków azotu, siarki i tlenku węgla, jako tych pochodzących głównie ze spalania paliw w celach komunalnych i transportowych. Uzasadnienie jeszcze miałoby dodanie czujników benzo(a)pirenu lub fenoli, zwłaszcza w pobliżu terenów przemysłowych (i tu znów kłania się tło, kontekst, otoczenie czujnika).
Dodanie funkcjonalności mierzenia CO2 ma jedynie sens w pomieszczeniach zamkniętych, zwłaszcza z ograniczoną wentylacją (np. piwnice). W warunkach domowych, zwłaszcza tam gdzie używane są źródła ciepła w postaci pieców, kominków czy piecyków gazowych lepiej sprawdzi się czujnik CO, bo da konkretną informację. Niestety jest tu już silna konkurencja w postaci czujników “czadu”.
Podobnie rzecz ma się z H2S (siarkowodór) czy metanem, które pochodzą głównie z procesów gnilnych i czynności życiowych. Tu znów brak odniesienia w normach. Ważne jest również otoczenie oraz cel umieszczenia czujnika (może wcale użytkownikowi nie jest potrzebny tak rozbudowany czujnik jak NAM).
Fajnie, że NAM może obsługiwać też takie funkcje, ale uważam że należy skupić się na priorytetach i przeznaczeniu tego czujnika, a dopiero później dodawać “bajeranckie” funkcjonalności. Po prostu szkoda bezcennego czasu twórców/programistów na dodawanie różnorodnych funkcjonalności, nie dopracowując jednocześnie podstaw. Przepraszam za mój zbyt długi wywód.

Po pierwsze - dodanie czujnika CO2 jest opcjonalne. I jak masz NAMa w szklarni to zapewne docenisz.

Ależ mój drogi - proszę skup się zatem na tych priorytetach. Kod jest publicznie dostępny. W projektach open source w większości kierunek rozwoju wyznaczają osoby, które coś robią. Jeżeli potrzebujesz jakiegoś konkretnego czujnika, to przejrzyj co jest na rynku, wytypuj 5-10 sensorów do testów, przetestuj je i wybierz kompromis pomiędzy jakością pomiarów a ceną. Poprawność pomiarów możesz w części sytuacji sprawdzić spektrometrem ramanowskim. A taki możesz zbudować w piwnicy (choć to trochę zachodu). W innych sytuacjach potrzebny jest drogi sprzęt pomiarowy, a do takiego możesz mieć dostęp przez znajomości.

Wiedza na temat aktualnego stężenia CO2 zmierzonego metodą NDIR jest przydatna gdy poszukujesz korelacji z innymi czynnikami. Moim zdaniem pomiar CO2 jest też ważny z uwagi na kryzys klimatyczny. Uśrednione dane z całego roku mogą nam wiele powiedzieć na temat jak dany region dokłada swoją cegiełkę węglową. Może się okazać, że w ten sposób łatwiej będzie namierzyć nieuczciwych emiterów dwutlenku węgla.

Jak zapewne wiesz, NAM to Nettigo Air Monitor i nie ma w nazwie Air Quality. Nie skupiamy się tylko na jakości powietrza. Celem jest jego kompleksowe monitorowanie. Natomiast serwis AQI.ECO stworzony przez Tomka jest nastawiony na prezentację jakości powietrza w sposób rzetelny i przystępny.

Właśnie dlatego takie rzeczy jak pomiar CO2, NOx, UVA, UVB, O3, pomiar siły i kierunku wiatru, itp będą się pojawiały. Firmware staramy się przepisywać tak, aby nieużywane rzeczy nie zabierały cennej pamięci RAM mikrokontrolera. Układamy wszystko w modułach. A jak możesz podejrzewać wartościowy kod na licencji Open Source przyda się też w innych projektach.

Dla nas obsługa CO2 jest ważna w firmware, z uwagi na to, że część naszych czujników jest używana w pomieszczeniach użytkowych, magazynach, kotłowniach czy szklarniach. Dane z takich urządzeń nie trafiają do Sensors Community czy aqi.eco. Są najczęściej wysyłane wprost do InfluxDB i analizowane przez osoby z danych przedsiębiorstw. I chociaż społeczeństwo nie ma dostępu do takich danych, to firmy te finansują rozwój projektu kupując od nas czujniki.

Docelowo zamierzamy też stworzyć domową wersję NAMa. Dedykowaną tylko do wnętrz.

1 polubienie

Chyba źle mnie zrozumiałeś. Nie chodzi mi o krytykę dodawania nowych funkcjonalności i rozwój NAM.
Rozumiem, że obsługa CO2 może być ważna w niektórych sytuacjach i właśnie dlatego chodzi o priorytety, żebyś nie zawracał sobie głowy funkcjonalnościami pobocznymi.
Pomimo tego, że jestem laikiem i nie znam się na programowaniu tak abym był w stanie Wam pomóc, to rozumiem różnicę między NAM i Aqi.eco.
Myślę jednak o NAM jako produkcie, którym można konkurować na rynku, a tego nie da się osiągnąć bez konkretnych priorytetów. Czyli w pierwszej kolejności dopieszczenia tego co jest, a dopiero następnie rozbudowy.
Rozumiem też ideę modułowości i tu się zgadzam.
Jako Wasz klient chciałbym w pierwszej kolejności mieć produkt nie wymagający co chwilę obsługi, bo coś się zawiesza albo któryś moduł nie zbiera danych (co u mnie zdarza się zbyt często).
Bardzo lubię Wasz produkt i dobrze wiesz, że chcę go więcej u siebie, dlatego zależy mi na jakości.
Przepraszam jeśli obebrałeś to jako krytykę, ale kieruję się wyłącznie troską o projekt który lubię.

Długo zastanawiałe się co odpisać i nadal się zastanaswiam. System mi się zawiesił.
Wymagać czegoś od kogoś kto robi coś za swoje pieniądze w swoim czasie non profit to co najmniej niegrzeczne.
pprella jeżeli chcesz gotowy produkt to idź po Airly, tam nawet jak czujnik przestanie działać to stacja zrobi czary i pewnie będzie raportowała wyniki.

NAM jest opensource i mam nadzieje że zawsze będzie w wersji rozwojowej.
Dziekuje za podzielenie się projektem!