Przepisanie firmware do czujników smogu

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!

I tu tkwi właśnie błąd. Nie chodzi o to żeby wyganiać każdego kto ma uwagi do konkurencji.
Doskonale rozumiem czym jest NAM i wiem, że jest tworzony przez entuzjastów. Właśnie dlatego, żeby nie dokładać do interesu trzeba skupić się na jakości. Widzę ogromny potencjał projektu i obawiam się że może okazać się zbyt geekowski.
Gdybym umiał pomóc w developerce to bym już dawno to zrobił, ale mam inne możliwości, które mogły by pomóc projektowi, a do tego potrzeba jakości. Ostateczna decyzja i tak będzie należeć do deva.
Tyle i aż tyle.

O jakie dopracowanie podstaw Panu chodzi? Pozwoliłem sobie zerknąć na Pana posty i nigdzie nie widziałem aby zgłaszał pan problemy ze stacją.
Ps. nie musi być Pan programistą aby wesprzeć projekt. Zauwazył Pan że niektóre elementy w instrukcji sa nie czytele z punktu widzenia lajka, może spróbuje Pan zaktualizować instrukcję? Wspominał Pan o braku zaczepów, może Pan coś zaproponuje?
Ps2. Genialna obódowa z klocków lego:)

Nie musimy chyba sobie tu mówić per Pan. Przynajmniej nie trzeba mnie tak tytułować.
Co do uzupełnienia dokumentacji o montaż to mógłbym to zrobić, ale będzie już bez zdjęć (czujnik mam już zmontowany). Myślę, że może być to istotne szczególnie w kontekście istnienia wersji NAM już zlutowanej.
Co do zaczepów to sam nie mam pomysłu - mój jest wbity na szpilki z drutu…
Co do innego rodzaju pomocy to nie chcę tu pisać w sposób otwarty. Pisałem wcześniej do irukard w tej kwestii, ale bez odzewu - ponownie proszę o kontakt.
Jeszcze raz proszę o zrozumienie - piszę o tym wszystkim przez wzgląd na dobro i jakość projektu, który bardzo mi się podoba i powtórzę się - widzę jego ogromny potencjał. Nie dla krytyki samej w sobie.
Dobra kończmy tą dyskusję bo to nie jest właściwy wątek na to.

Wtrącę swoje 3 grosze :slight_smile:

Uważam, że takie forum jak to służy m.in. do wymiany opinii na temat tego:

  • co jest zrobione źle i wymaga poprawki
  • czego brakuje
  • co dla kogo jest priorytetem
  • co mogłoby być zrobione w dalszej przyszłości

Ale zawsze ostateczną decyzję podejmuje twórca projektu. To co tu jest napisane może być traktowane najwyżej jako sugestie. Zwłaszcza jeżeli piszą “odbiorcy” a nie “dostawcy” usług.

Ale osoby tworzące projekt są (wg moich obserwacji) podatne na sugestie :slight_smile:

Problem tylko taki, że ilość aktywnych uczestników tej dyskusji jest zdecydowanie za mała.
Projekt NAM i AQI.ECO zasługują na promocję…

1 polubienie

Przepraszam. Proszę nie przejmuj się. Ja już tak mam. Najpierw coś napiszę, po kilku dniach ponownie przeczytam i zastanawiam się po cholerę to właściwie pisałem.

I tu ściera się tradycyjne myślenie z naszym. Nam nie zależy konkurowaniu na rynku. Nam zależy na możliwie najlepszym produkcie z punktu widzenia Citizen Science.

To prawda. Dlatego pracujemy nad nowym firmware.

NAM to nie projekt non profit. Nettigo jest firmą i z czegoś musimy żyć. Ze sprzedaży zestawów finansujemy dalszy rozwój projektu. Masa kasy idzie na eksperymentowanie, dłubanie, próby, testy, porażki… :slight_smile: To co pokazujemy publicznie, to ta część, która nam wyszła. A tego co nie wyszło jest naprawdę sporo.

A może to właśnie geekowska nisza jest siłą tego projektu. Airli, Chmurli, Smogli, Smrodli, Dymli, Śmierdźli… na rynku pojawiają się cały czas nowi gracze, których targetem jest użytkownik, który sobie takie urządzenie podłączy do prądu i koniec. Dane ma w apce i nic z nimi nie może zrobić. NAM w założeniu miał zachęcać do dłubania. Pewnie dlatego póki co nie ma gotowego urządzenia do kupienia, a jedynie zestawy. Takie urządzenie zapewne się pojawi prędzej czy później. Będzie śliczne, dopracowane i nie będzie mowy o sensownej rozbudowie.

Stabilność pracy nowego FW monitorujemy przez InfluxDB. W przyszłości w FW będzie ptaszek “wysyłaj dane diagnostyczne do Nettigo”.

Co do instrukcji, zgłaszajcie uwagi na bieżąco, będziemy aktualizować.

Co do zaczepów… chodzi to za mną od dawna. Usiądę zaraz i napiszę instrukcję jak wieszać NAMa.

Obecnie można powiesić NAMa na kilka sposobów. Na przykład:

  • 2 wkrętami z użyciem otworów w obudowie
  • na kołki rozporowe 6x30mm (wkładamy je od tyłu obudowy w otwory) - można wtedy przykręcić uchwyty w blachy, wydrukowane na drukarce, czy po prostu kawałek sklejki
  • plastikową obejmą od rur (chwytamy za komorę HECA)
  • na taśmę dwustronną 3M do szyby okna

<piękny offtopic w temacie o firmware>

W każdej chwili można taki projekt sforkować i pójść w swoją stronę. I tym samym stać się twórcą projektu.

Jesteśmy podatni na sugestie, prośby i wszelkie inne metody - łącznie z rozgrzanymi węglami.

Wracamy do tematu

LED Bar

Dodałem dzisiaj obsługę LED BARa do firmware :slight_smile: Kod może nie jest zbyt piękny, ale działa.

Piękne jest w tym systemie to, że LED Bar do działania potrzebuje naprawdę niewiele. Aby zapalić diody wystarczy wysłać po I2C krótką komendę:

A mini firmare LED Bara znajdziecie tutaj: https://github.com/irukard/NAM-I2C-RGB-LED-BAR/

Wydaje mi się, że taka linijka LED będzie lepsza niż wyświetlacz. Przynajmniej z daleka widać jakie jest powietrze. Oczywiście kod w formie obecnej to takie MVP. Trzeba oczywiście dodać do tego jakąś konfigurację jasności. Może wyznaczanie progów, zobaczymy.

Sprzęt: https://easyeda.com/nettigo/Nettigo-Air-Monitor-I2C-RGB-LED-Bar

Przy okazji powstał prosty interfejs do diod Neopixel na I2C :slight_smile: Obsługą diod zajmuje się ATtiny84A. Wybrałem ten układ bo go znamy z tinyBrd i prototypowanie jest wyjątkowo łatwe. Z dodatkowego osprzętu do działania potrzebuje jedynie kondensatora 1uF.

Otwiera to możliwość na nowe analogowe czujniki, które można obsłużyć po I2C bez konieczności angażowania ESP8266. I to właśnie jest modułowa budowa.

Hardware watchdog

Sprzęt jest gotowy. A przynajmniej jego pierwsza wersja. Firmware będzie niebawem. HW Watchdog potrafił resetować urządzenie co określony czas i w określonych warunkach. Może mierzyć napięcie na szynie 3V3 i 5V. Ma dostęp do I2C więc może się komunikować z NAMem.

Sprzęt: https://easyeda.com/nettigo/Nettigo-Air-Monitor-0.3-HW-Watchdog

1 polubienie

Skoro LED bar już jest w firmware, czekam na informację “od dzisiaj są dostępne płyty/zestawy do budowy LED bar” :slight_smile:

Troszkę, boli mnie to, że sprawdziłem wszystkie miejsca lutowania, które mogą mieć coś wspólnego z brakiem odczytów z SDS011 i niestety braki w odczytach nadal się pojawiają ( “-” w panelu i brak wartości w JSON przy czasie 5 minut między odczytami ). A bezpośrednio po update przez jeden dzień zachowywał się w miarę poprawnie. Dzisiaj przegina - w ciągu godziny brakuje nawet 3-4 odczytów. Wczoraj cały dzień poprawnie, niedziela w miarę. Sobota po update do wersji BETA - super i wszystko działało.

W sumie wpadłem jeszcze na pomysł, by przepiąć SDS do złącza EXT i zobaczyć jak się zachowa na kabelkach.

W każdym razie, czekam na LED Bar.

<!offtopic mode!>
Co do zawieszenia NAM. Ja chciałem zawiesić na poręczy balkonu - do wewnątrz, żeby mieć opcję na LED bar :D, więc zakupiłem trochę śrub (w tym z płaską główką), dwa kątowniki w kształcie L i obejmę w kształcie U.
Trochę pracy przy imadle - z kątowników wyszedł prostokąt, dwie dziurki w obudowie na tylnej ścianie - dlatego śruby z płaską główką, bo idealnie chowają się za płytę NAM - w okolicach SDS, gdzie nie ma dużo lutów. Oczywiście dodatkowo je zabezpieczyłem w razie czego.
Teraz kiedy potrzebuję ściągnąć NAM, odkręcam dwie nakrętki od obudowy i mogę go brać na warsztat nawet w nocy :slight_smile:

EDIT:
Nie wiem jak to jest, ale wczoraj zmieniłem konfigurację na odczyty co 3 minuty i dzisiaj cały dzień odczyty bez pustych wartości z SDS011.

Witam, jako nowy, właśnie zmontowałem NAM i co najważniesze wisi już na domu i gada jak trzeba. Ale przy okazji mam od razu kilka pytań co do rozwoju tego cudu.

  • nad jakimi i czy już, czujnikami UV już myśleliście. Chętnie bym przeszedł na NAM, dziś używam jeden po z-wave umieszczony w rurce kanalizacyjnej zamkniętej od góry szkłem kwarcowym, ale to czujnik zintegorwany z PIR i LUX a ich “świecenie” prawie w niebo to lekkie marnotrawienie.
  • czy planujecie dodać korektę wskazań ciśnienia, temperatury (+/- drobne wartości na potrzeby ręcznej kalibracji czy na razie pozostawiacie to zewnętrzym apką userów)
    Tyle na początek, pomysł NAM super, z przyjemnością wydałem $ na to, a nie gotowe rozwiązania

W związku z dyskusją na temat czujnika CO2 kilka uwag.
Stężenie CO2 przed epoką przemysłowa wynosiło ok 280 ppm. Na skutek spalania przez nas paliw kopalnych w wyniku czego jest emitowane CO2 stężenie to systematycznie wzrasta i aktualnie przekroczyło 415 ppm. Są to pomiary ze stacji naukowych umieszczonych bardzo daleko, poza terenem zabudowanym. Można więc przyjąć jako aktualny poziom odniesienia. Najwięcej CO2 emitują elektrownie na paliwo kopalne i miasta, dlatego poziom CO2 tam jest większy. Rozumiem, ze czujnik CO2 właśnie ma nas informować jak się ma stężenie CO2 w okolicy w stosunku do stężenia ogólnoświatowego. Czym ta wartość zmierzona będzie większa, oznacza to , że mieszkańcy okolicy emitują dużo dwutlenku węgla i mocno przyczyniają się do zbliżającej się katastrofy klimatycznej. Chociaż łatwo się domyśleć , gdzie w Polsce jest największe stężenie dwutlenku węgla to potwierdzenie tego pomiarami będzie ciekawe.

A jak wyglądają plany dodania raportowania indexu UV, dla niego mamy normy i niestety nasze słoneczko czasami za mocno przebija się przez dziurawą atmosferę. Index UV w lecie jest nawet ważniejszy niż pm’y czy CO2. Jest parę tych czujników do wyboru z I2C. Obudowa to nie problem, a na hemertyczny wizjer może być wpasowane szkiełko kwarcowe. Ja dziś pobieram te dane dla https://zbojna-gora.aqi.eco/ z czujnika niezależnego od stacji bez rejestracji na aqi.eco.

Czy do logów da się zajrzeć przez webinterface? Mam całość za oknem na 1 piętrze i ciężko mi się w to wpiąć po serial/USB, a SDS mi co jakiś czas przestaje raportować…

Witam
Panowie po przepisaniu firmware ma obecnie Wersja NAMF-2020-boot
Jak zmusić do aktualizacji do najnowszej wersji ?
Temat załatwiony , sam pobrał po długim przemyśleniu do wersji 2020-30