Projekt czujnika jakości powietrza: od schematu po dashboard w chmurze

Po co własny czujnik jakości powietrza, skoro są gotowe?

Kontrola nad projektem zamiast czarnej skrzynki

Gotowe stacje do pomiaru jakości powietrza są wygodne, ale najczęściej zamknięte. Producent decyduje, jakie dane pokazuje, jak często są aktualizowane i gdzie są przechowywane. Przy własnym projekcie czujnika jakości powietrza kontrolujesz wszystko – od listy parametrów, przez sposób liczenia średnich, po to, jakie dane trafiają do chmury i na dashboard.

Własny sensor jakości powietrza pozwala dobrać czujniki do konkretnego zastosowania. Można pominąć pomiar, który nie ma sensu w danym miejscu (np. pyły w serwerowni) i skupić się na tych krytycznych (np. CO₂ w sali konferencyjnej). Daje to większą precyzję i pozwala ograniczyć koszt.

Dodatkowa korzyść to możliwość integracji z istniejącą infrastrukturą IoT. Dane z sensora można wysłać do własnego brokera MQTT, Home Assistanta czy Prometheusa, a nie do zewnętrznej chmury, której polityka może się w każdej chwili zmienić.

Przykładowe zastosowania domowe i profesjonalne

Najprostszy scenariusz to mieszkanie. Czujnik smogu przy oknie i w salonie pokazuje, kiedy nie warto wietrzyć, a kiedy można otworzyć okna. Dodatkowy pomiar CO₂ w sypialni pomaga zapanować nad sennością i bólami głowy wynikającymi z niedotlenienia.

W biurze własny IoT czujnik smogu i CO₂ może sterować systemem wentylacji. Zamiast włączać centralę według sztywnego harmonogramu, można ją uruchamiać przy przekroczeniu ustalonych progów. To realna oszczędność energii i większy komfort pracowników.

Warsztat czy pracownia to kolejne naturalne środowisko dla sensora. Pyły z szlifowania, opary farb, dym z lutowania – wszystko to da się monitorować. Dane historyczne pomagają udowodnić, że wdrożone filtry czy wyciągi działają (lub że trzeba je przerobić).

W szkole lub przedszkolu prosty dashboard w chmurze z czujników CO₂ uczy dzieci, czym jest wentylacja i jak wygląda „świeże powietrze” w liczbach. Równocześnie administracja ma argumenty w rozmowach o modernizacji instalacji.

Granice tanich komponentów i realny poziom trudności

Budżetowe czujniki środowiskowe mierzą przede wszystkim: temperaturę, wilgotność, ciśnienie, stężenie pyłów PM2.5/PM10 oraz wskaźniki jakości powietrza bazujące na lotnych związkach organicznych (VOC) i „ekwiwalentnym CO₂”. Prawdziwe pomiary chemiczne określonych gazów wymagają już dużo droższych sensorów i kalibracji laboratoryjnej.

Hobbystyczny projekt czujnika jakości powietrza nie będzie certyfikowanym przyrządem pomiarowym. Może jednak trzymać się rozsądnej dokładności w warunkach domowych, jeśli wybór elementów i oprogramowania będzie przemyślany. Dla wielu zastosowań kluczowa jest powtarzalność i trend, a nie absolutna, laboratoryjna wartość.

Od strony kompetencji wystarczy elektronika hobbystyczna na poziomie „Arduino + kilka modułów” i podstawy programowania w C++ lub MicroPython. Trudniejsze elementy – komunikacja MQTT, dashboard w chmurze, aktualizacje OTA – można wdrażać etapami, rozwijając projekt w miarę potrzeb.

Wymagania funkcjonalne i niefunkcjonalne – co to urządzenie ma umieć

Jakie parametry powietrza warto mierzyć w praktyce

W projekcie czujnika jakości powietrza najczęściej monitoruje się:

• PM2.5 / PM10 – frakcje pyłów zawieszonych; podstawowy wskaźnik smogu.
• VOC / TVOC – lotne związki organiczne, m.in. z farb, mebli, środków czystości.
• CO₂ i eCO₂ – faktyczne stężenie CO₂ (czujniki NDIR) oraz „ekwiwalent” CO₂ szacowany na podstawie VOC.
• Temperatura i wilgotność – wpływają na komfort, ale też na pracę innych czujników.
• Ciśnienie – przydatne mniej dla zdrowia, bardziej jako bonus meteorologiczny.

W typowym, domowym projekcie sensowny zestaw to: pyły (PMS5003 lub SDS011), BME280/BME680 dla temperatury, wilgotności i ciśnienia, oraz czujnik CO₂ NDIR typu MH‑Z19B lub Senseair S8. VOC traktuje się raczej jako wskaźnik „coś jest nie tak z powietrzem” niż dokładną analizę chemiczną.

Rozszerzone projekty dorzucają pomiar dodatkowych gazów (NO₂, O₃) czy hałasu. Na początek lepiej zbudować stabilny fundament na sprawdzonych, dobrze opisanych sensorach środowiskowych.

Częstotliwość pomiarów, wysyłka i buforowanie danych

Większość parametrów powietrza zmienia się dość wolno. Wyjątkiem mogą być pyły w warsztacie czy CO₂ w małym, szczelnym pomieszczeniu w czasie spotkania.

Rozsądne ustawienia dla sensora domowego:

• pomiar co 5–15 sekund,
• uśrednianie do 30–60 sekund,
• wysyłka danych do chmury co 30–60 sekund lub co parę minut, jeśli oszczędza się łącze i energię.

Przy braku internetu urządzenie nie powinno gubić danych. Prosty bufor w pamięci Flash lub w pliku (np. na SPIFFS/LittleFS) pozwala przechować kilkaset, a nawet kilka tysięcy rekordów. Po przywróceniu łączności firmware wysyła je „doganiając” serwer.

Opóźnienia na poziomie kilku sekund nie mają znaczenia dla monitoringu domowego. W projektach, które sterują wentylacją na podstawie CO₂ w czasie zbliżonym do rzeczywistego, warto utrzymywać sumaryczne opóźnienie (pomiar + obliczenia + wysyłka + decyzja) poniżej kilkunastu sekund.

Dokładność, powtarzalność i kalibracja domowa

Do zastosowań domowych kluczowa jest powtarzalność, nie tyle absolutna dokładność na poziomie badań laboratoryjnych. Jeżeli sensor pokazuje wartości nieidealne, ale stabilne, nadal daje wiarygodny obraz trendów i zmian.

Praktyczne założenia:

• temperatura: ±0,5–1°C,
• wilgotność: ±3–5% RH,
• CO₂: dokładność w zakresie kilkuset ppm przy czujniku NDIR,
• pyły: porównywalne wskazania z innymi, podobnymi sensorami w tym samym miejscu.

Najprostsza kalibracja to porównanie z referencją. Wystarczy wziąć własny czujnik i gotową, sprawdzoną stację pomiarową (albo sensor z tej samej serii co „wzorzec”), umieścić je obok siebie na kilka godzin i obliczyć prostą poprawkę offsetu w firmware.

Niektóre czujniki VOC i CO₂ eq (np. SGP30, CCS811) posiadają algorytmy automatycznej kalibracji bazowej (ABC). W środowisku, które jest przewietrzane, działają dość poprawnie. W pomieszczeniach stale zamkniętych warto rozważyć ręczną kalibrację w znanych warunkach (np. na zewnątrz przy założeniu, że CO₂ ≈ 400 ppm).

Wygoda obsługi i codzienne użytkowanie

Nawet najlepszy projekt czujnika jakości powietrza traci sens, jeśli jego obsługa jest uciążliwa. Użytkownik powinien w prosty sposób:

• skonfigurować Wi‑Fi bez kabla (np. przez tryb AP i stronę www),
• ustawić parametry MQTT lub adres serwera HTTP,
• zaktualizować firmware bez otwierania obudowy (OTA),
• sprawdzić stan urządzenia poprzez prosty interfejs – LED, diodę RGB, mały wyświetlacz.

Minimalistyczna, ale praktyczna opcja to pojedyncza dioda RGB z kodem kolorów: zielony – wszystko w normie, żółty – lekkie przekroczenia, czerwony – alarm. To wystarczy, by „rzucić okiem” na sytuację bez otwierania dashboardu w chmurze.

Tryb offline bywa równie ważny co połączenie z chmurą. Sensowne jest zachowanie lokalnej strony www na urządzeniu, pokazującej ostatnie pomiary i stan sensorów. Gdy broker MQTT czy internet padną, użytkownik nadal widzi dane w sieci lokalnej.

Kryteria niefunkcjonalne: bezpieczeństwo, energia, hałas, trwałość

Bezpieczeństwo w kontekście domowego czujnika jakości powietrza to głównie kwestia dostępu do sieci Wi‑Fi i do brokera MQTT/chmury. Urządzenie powinno korzystać z szyfrowania WPA2/WPA3, nie wystawiać otwartych portów bez autoryzacji i nie wysyłać haseł wprost po MQTT. Konfiguracja przez AP powinna być ograniczona w czasie lub zabezpieczona hasłem.

Zużycie energii jest kluczowe, jeśli sensor ma działać z zasilania bateryjnego. W większości projektów stacjonarnych wygodniejsze jest zasilanie sieciowe 5 V, co znacznie upraszcza projekt. Wciąż jednak warto ograniczyć zbędny pobór prądu (np. wygaszać wyświetlacz, usuwać niepotrzebne diody).

Hałas pojawia się, gdy czujnik pyłów wymaga aktywnego przepływu powietrza (wentylator). Część tańszych laserowych sensorów posiada własny wiatraczek, który może być słyszalny w nocy. Rozwiązaniem jest obniżenie częstotliwości pomiaru lub tryb nocny, w którym sensor wyłącza się lub mierzy rzadziej.

Trwałość zależy od jakości zasilacza, obudowy i warunków pracy. Lepiej unikać tanich zasilaczy USB niewiadomego pochodzenia, które potrafią wprowadzać zakłócenia. Obudowę dobrze jest dobrać tak, aby zapewniała rozsądny przepływ powietrza, ale chroniła przed kurzem, owadami i palcami dzieci.

Wybór platformy sprzętowej i czujników

Porównanie popularnych mikrokontrolerów i minikomputerów

W projekcie „projekt czujnika jakości powietrza: od schematu po dashboard w chmurze” najczęściej rozważa się cztery platformy:

Dla pojedynczego czujnika środowiskowego optymalny jest ESP32. Ma wystarczającą moc, Wi‑Fi, dużo GPIO, sprzętowe I²C/UART i sporą pamięć Flash. Daje też możliwość przyszłego rozszerzenia o Bluetooth (np. do konfiguracji z telefonu).

ESP8266 sprawdza się przy bardzo prostych projektach, ale ma mniej zasobów i bywa trudniejszy, gdy rośnie rozmiar firmware’u (webserwer, MQTT, OTA w jednym). Raspberry Pi (pełne) jest zbyt ciężkie energetycznie na pojedynczy sensor, ale świetne jako serwer lokalnej chmury lub agregator danych.

Dobór czujników: typy, interfejsy, biblioteki

Najpopularniejsze czujniki pod projekt czujnika jakości powietrza to:

• PMS5003 / PMS7003 – czujniki pyłów PM1/PM2.5/PM10, komunikacja UART, dobre wsparcie w społeczności.
• SDS011 – podobny zakres pomiaru pyłów, również UART, częściej stosowany w starszych stacjach smogowych.
• BME280 – temperatura, wilgotność, ciśnienie, interfejs I²C/SPI, stabilny i dobrze opisany.
• BME680 – rozszerzony BME280 o sensor gazów (VOC), I²C/SPI, wymaga biblioteki BSEC do sensownego wykorzystania VOC.
• SGP30 / CCS811 – pomiar VOC i CO₂ eq, I²C, nadają się do prostych wskaźników „zanieczyszczone / czyste”.
• MH‑Z19B – czujnik CO₂ NDIR, UART lub PWM, prosta integracja, dobra relacja cena–jakość.

Przy wyborze sensorów istotne są:

• Interfejs – I²C pozwala podłączyć wiele czujników na tych samych dwóch liniach, UART wymaga osobnych pinów, ale jest odporny na zakłócenia.
• Dokumentacja – przejrzysty datasheet i aplikacje przykładowe to ogromna pomoc przy integracji.
• Dostępność bibliotek – gotowe biblioteki dla Arduino/ESP-IDF/MicroPython przyspieszają start i zmniejszają liczbę błędów.
• Stabilność wyników – czujniki, które „pływają” z odczytem po każdym restarcie, generują więcej problemów niż pożytku.

Integracja kilku sensorów na jednej płytce

Jeden mikrokontroler często obsługuje kilka czujników jednocześnie. Trzeba wtedy zadbać o adresy I²C, liczbę UART‑ów i budżet prądowy.

Na magistrali I²C adresy niektórych układów są stałe. Gdy pojawi się konflikt (np. dwa identyczne czujniki o tym samym adresie), rozwiązaniem jest:

• zastosowanie ekspandera I²C lub multipleksera adresów,
• wybranie wariantu sensora z innym adresem (jeśli producent taki oferuje),
• przejście jednego z czujników na SPI, jeśli ma taki interfejs.

Przy większej liczbie urządzeń UART (np. PMS + MH‑Z19 + debug) ESP32 zapewnia kilka kontrolerów sprzętowych. Czasem wygodnie jest użyć jednego UART dla dwóch sensorów, ale tylko gdy transmisje są rzadkie i krótkie, a firmware dobrze rozpoznaje ramki.

Łączny pobór prądu wszystkich sensorów (szczególnie laserowych i NDIR) musi mieścić się w możliwościach zasilacza 5 V i przetwornicy 3,3 V. W razie wątpliwości lepiej policzyć zapas z marginesem 30–50% niż potem gonić losowe restarty.

Rozmieszczenie czujników w obudowie

Fizyczne ułożenie elementów potrafi zniszczyć nawet najlepszy schemat. Grzałki, stabilizatory liniowe i same mikrokontrolery podnoszą temperaturę lokalnie.

Dla sensora temperatury i wilgotności sensowne jest:

• odsunięcie go od ESP32 i przetwornicy DC/DC,
• zapewnienie bezpośredniego dostępu powietrza do otworu pomiarowego,
• oddzielenie od ścieżek z dużymi prądami (wentylatory, grzałki).

Czujnik pyłów zazwyczaj wymaga własnej komory i otworów w obudowie. Wlot i wylot powietrza nie powinny być zasłonięte ani zbyt blisko ściany czy sufitu. Dla domowego zastosowania dobrze sprawdza się ustawienie „na półce”, z możliwością swobodnego przepływu powietrza.

Projekt elektroniczny: schemat, zasilanie i prowadzenie sygnałów

Architektura zasilania

Typowy układ to zasilacz 5 V (ładowarka USB lub moduł AC/DC) oraz przetwornica 5 V → 3,3 V. Kluczowa jest stabilność i zapas mocy.

Praktyczny układ:

• 5 V dla czujników pyłów i CO₂ NDIR (często właśnie takie napięcie zasilania),
• 3,3 V dla ESP32 i czujników I²C (BME/BME680, SGP30 itd.),
• oddzielne kondensatory filtrujące przy każdym module, zwłaszcza przy sensorach laserowych.

Stabilizator 3,3 V warto dobrać w oparciu o szczytowy pobór prądu ESP32 (z Wi‑Fi) plus margines na resztę układu. Dla prostego sensora domowego często wystarcza 500–800 mA, ale przy większej liczbie modułów lepiej sięgnąć po 1–1,5 A.

Prowadzenie masy i sygnałów

Masa powinna być możliwie jednolita, najlepiej jako pełna płaszczyzna. Linie zasilające warto prowadzić grubszym śladem, oddzielając część „brudną” (wentylatory, przekaźniki) od „czystej” (mikrokontroler, I²C).

Dobre praktyki przy sygnałach cyfrowych:

• linia I²C możliwie krótka, z rezystorami podciągającymi blisko mastera,
• UART do czujników może być dłuższy, ale lepiej trzymać go z dala od linii zasilania wentylatora,
• przy przejściach między poziomami 5 V a 3,3 V stosować konwertery poziomów lub dzielniki rezystorowe.

Jeżeli czujnik pyłów ma własny wentylator sterowany PWM, linia sterująca nie powinna biec równolegle z I²C na dłuższym odcinku. Ogranicza to zakłócenia i „dziwne” skoki odczytów.

Ochrona wejść i interfejsów

Urządzenie zwykle pracuje latami, często podłączone do taniego zasilacza. Zabezpieczenia przed przepięciem i ESD zmniejszają ryzyko spektakularnej awarii.

Na wejściu 5 V przydaje się:

• bezpiecznik polimerowy (polyfuse) o prądzie nieco powyżej nominalnego,
• diody TVS do ochrony przed przepięciami z zasilacza.

Linie sygnałowe, które mogą wychodzić na zewnątrz (np. UART do modułu wyprowadzonego do innej obudowy), można zabezpieczyć małymi diodami ESD. Przy interfejsach do 5 V modułów stosuje się dodatkowo rezystory szeregowe ograniczające prąd.

Prototyp na płytce stykowej i przejście na PCB

Większość problemów da się złapać jeszcze na płytce stykowej lub prototypowej. Dobrze jest tam uruchomić:

• komunikację z każdym sensorem (I²C/UART),
• podstawową obsługę Wi‑Fi i MQTT/HTTP,
• logikę pomiar → uśrednianie → wysyłka.

Dopiero po kilkudniowych testach sensowne jest projektowanie PCB. Wersja pierwsza nie musi być finalna – często pojawiają się drobne poprawki: dodatkowa dioda LED, inny konektor, miejsce na jumper wyboru UART‑u.

Oprogramowanie mikrokontrolera: od „Hello sensor” do stabilnego firmware

Wybór środowiska i frameworka

Dla ESP32 najczęściej używa się dwóch opcji: Arduino Core lub ESP‑IDF. Arduino przyspiesza start, ESP‑IDF daje większą kontrolę i lepsze zarządzanie wielowątkowością.

Przy prostym urządzeniu domowym Arduino z dobrze poukładaną strukturą plików jest zwykle wystarczające. Jeśli projekt ma rosnąć (HTTP + MQTT + BLE + OTA + update konfiguracji), wygodniejsze okazuje się ESP‑IDF.

Struktura kodu i podział na moduły

Monolityczny plik z całym kodem szybko robi się nieczytelny. Wygodny podział to:

• moduł obsługi sensorów (drivers/),
• moduł komunikacji (mqtt_client.cpp / http_client.cpp),
• moduł konfiguracji (config.cpp),
• moduł logiki aplikacyjnej (app_logic.cpp).

Każdy czujnik ma własny interfejs: inicjalizacja, odczyt surowy, ewentualnie uśrednianie/kompensacja temperatury. Główna pętla nie powinna znać szczegółów protokołu I²C – ma tylko pytać o „aktualny stan powietrza”.

Stan maszyny zamiast „delay()”

Opóźnienia blokujące (delay()) kuszą prostotą, ale w projekcie z Wi‑Fi, MQTT i kilkoma sensorami prowadzą do niestabilności. Zamiast nich przydaje się prosta maszyna stanów oraz harmonogram oparty na millis()/timery.

Przykładowy cykl:

• co 5 sekund: odczyt danych z sensorów, zapis do struktury pomiarowej,
• co 30 sekund: uśrednienie i przygotowanie rekordu do wysyłki,
• co 30–60 sekund: wysyłka do brokera lub serwera HTTP,
• raz na kilka minut: zapis konfiguracji lub statystyk do Flash.

W ten sposób firmware reaguje na zdarzenia (czas, nowy pomiar, utrata Wi‑Fi), a nie „śpi” bezproduktywnie. To od razu przekłada się na szybsze działanie strony konfiguracyjnej i stabilniejsze połączenie MQTT.

Obsługa błędów i watchdog

Każdy element łańcucha – czujnik, Wi‑Fi, broker – może przestać odpowiadać. Zamiast zakładać, że wszystko działa, lepiej przewidzieć prostą politykę błędów.

Przykładowe mechanizmy:

• timeout na odczyt z sensora (jeśli po X ms brak ramki, oznacz pomiar jako nieważny),
• licznik nieudanych prób połączenia z Wi‑Fi/MQTT, po którym następuje restart modułu sieciowego lub całego MCU,
• watchdog sprzętowy i programowy, resetujący urządzenie przy zawieszeniu pętli głównej.

Logowanie błędów do prostego bufora w RAM lub do pliku (np. na LittleFS) pomaga przy diagnozie problemów po kilku miesiącach pracy.

Konfiguracja i aktualizacja OTA

Urządzenie zwykle działa poza biurkiem konstruktora, więc konfigurację trzeba dostarczyć drogą zdalną. Minimalny zestaw to:

• ustawienia Wi‑Fi (SSID, hasło),
• parametry MQTT/HTTP (adres, port, login, topiki/ścieżki),
• częstotliwość pomiaru i wysyłki,
• proste progi alarmowe (np. CO₂, PM2.5).

Przechowywanie konfiguracji w formacie JSON na Flash (np. /config.json) jest wygodne przy rozbudowie projektu. Strona WWW edytuje pola, firmware wczytuje całość przy starcie i waliduje.

OTA (Over‑The‑Air) znacząco skraca czas poprawek. Najprostszy wariant to aktualizacja z poziomu panelu WWW urządzenia (upload pliku .bin). Bardziej zaawansowany to OTA sterowane z serwera – mikrokontroler cyklicznie sprawdza, czy jest nowa wersja, pobiera ją przez HTTP/HTTPS i przełącza się na nową partycję.

Protokół i warstwa komunikacji IoT: MQTT, HTTP, a może coś innego?

Mqtt jako „domyślny” wybór

MQTT dobrze pasuje do małych urządzeń z ograniczonymi zasobami. Prosty model publish/subscribe ułatwia rozdzielenie roli sensora, dashboardu i automatyki domowej.

Przy jednym czujniku i własnym brokerze (np. Mosquitto na Raspberry Pi) konfiguracja jest nieskomplikowana. Istotne elementy to:

• jeden główny topic pomiarowy, np. home/air/room1/state,
• opcjonalny topic z konfiguracją i komendami, np. home/air/room1/cmd,
• jakość usługi QoS 1 dla najważniejszych pomiarów.

Payload jako JSON ułatwia integrację z Home Assistantem, Node‑RED czy własnym backendem. W typowym rekordzie znajdują się: timestamp, temperatura, wilgotność, CO₂, PM, VOC oraz flaga błędu.

HTTP/HTTPS i REST

HTTP / HTTPS bywa wygodny, gdy dane mają trafiać bezpośrednio do jednej aplikacji serwerowej lub usługi w chmurze. Urządzenie wysyła wtedy żądania POST/PUT z JSON‑em na ustalony endpoint.

Przykład prostego zapytania:

POST /api/measurements HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "device_id": "sensor-room1",
  "ts": 1680000000,
  "t": 22.1,
  "rh": 45.3,
  "co2": 650,
  "pm25": 18
}

HTTPS podnosi zużycie zasobów (RAM, Flash, CPU), ale chroni treść i dane logowania. ESP32 radzi sobie z TLS, lecz wymaga przemyślanego zarządzania certyfikatami i pamięcią.

UDP, CoAP i inne lekkie alternatywy

W prostych sieciach lokalnych można rozważyć protokoły oparte na UDP, takie jak CoAP. Zużywają mniej zasobów niż HTTP, mają prosty model request/response oraz tryb obserwacji (observation).

Minusem jest mniejsze wsparcie w gotowych dashboardach i mniejsza popularność w ekosystemie hobbystycznym. Często pojawia się konieczność pisania własnych „mostków” CoAP → MQTT/HTTP.

Bezpieczeństwo w warstwie transportowej

Bezpieczne połączenie wymaga uwierzytelniania i najlepiej szyfrowania. W praktyce używa się:

• MQTT z TLS (port 8883) i logowaniem użytkownik/hasło,
• HTTPs z tokenem w nagłówku (np. Bearer token),
• dodatkowej białej listy adresów IP po stronie serwera.

Na mikrokontrolerze trzeba wyważyć poziom bezpieczeństwa z ilością pamięci. Czasem sensownym kompromisem jest szyfrowane połączenie tylko w obrębie sieci domowej (np. własny broker MQTT z TLS), a resztę ruchu zabezpiecza firewall routera.

Strategia wysyłki danych i buforowanie

W trybie normalnym urządzenie wysyła bieżące dane co kilkadziesiąt sekund. Przy braku internetu przełącza się w tryb buforowania: dopisuje rekordy do pamięci Flash lub systemu plików.

Prosty schemat zarządzania buforem:

• pierścień (ring buffer) z N rekordami stałej długości,
• dwa wskaźniki: „head” (ostatni zapisany) i „tail” (następny do wysyłki),
• nadpisywanie najstarszych danych po zapełnieniu bufora.

Po przywróceniu łączności firmware najpierw wysyła rekordy z bufora, potem wraca do trybu „bieżącego”. Przy MQTT można umówić się na osobny topic historyczny lub oznaczać rekordy flagą „backfill”.

Integracja z dashboardem i systemami automatyki

Docelowo dane trafiają do narzędzia wizualizacyjnego i ewentualnego systemu automatyki. W projektach domowych często pada wybór na:

• Home Assistant (MQTT / HTTP),
• Node‑RED z bazą danych (InfluxDB, TimescaleDB),

Najczęściej zadawane pytania (FAQ)

Po co budować własny czujnik jakości powietrza, skoro są gotowe stacje?

Gotowe stacje traktują pomiary jak „czarną skrzynkę” – to producent decyduje, jakie dane widzisz, jak często są aktualizowane i gdzie lądują w chmurze. Przy własnym projekcie sam ustalasz listę mierzonych parametrów, algorytmy uśredniania, częstotliwość wysyłki i miejsce przechowywania danych.

Masz też pełną kontrolę nad integracją z resztą swojej infrastruktury: możesz wysyłać dane do własnego brokera MQTT, Home Assistanta, Prometheusa czy prostego API HTTP, bez zależności od polityki zewnętrznej platformy. Dodatkowo dobierasz sensory pod konkretne zastosowanie, więc nie płacisz za pomiary, które w danym miejscu są zbędne.

Jakie parametry powietrza naprawdę warto mierzyć w domu lub biurze?

W typowym projekcie domowym sensowny zestaw obejmuje: pyły PM2.5/PM10 (smog), temperaturę, wilgotność, ciśnienie oraz CO₂ mierzony czujnikiem NDIR. Do tego opcjonalnie wskaźnik VOC/TVOC jako „alarm”, że w powietrzu pojawiły się lotne związki z farb, klejów czy środków czystości.

W biurze i salach spotkań kluczowy jest CO₂, bo dobrze pokazuje potrzebę wietrzenia lub zwiększenia wentylacji. W warsztacie priorytetem będą pyły i opary, a w szkole – czytelny podgląd CO₂ na prostym dashboardzie, żeby łatwo pokazać dzieciom, jak zmienia się jakość powietrza w czasie lekcji.

Jakie czujniki wybrać do hobbystycznego sensora jakości powietrza?

Do pomiaru pyłów popularne są moduły PMS5003 lub SDS011. Temperaturę, wilgotność i ciśnienie wygodnie obsłuży BME280 lub BME680. Do wiarygodnego CO₂ warto użyć czujnika NDIR, np. MH‑Z19B lub Senseair S8.

VOC/TVOC możesz dodać przez czujniki typu BME680, SGP30 czy CCS811, ale dobrze traktować je jako wskaźnik „coś się zmieniło w powietrzu”, a nie pełną analizę chemiczną. Na początek lepiej zbudować stabilny zestaw na kilku sprawdzonych modułach niż rozpraszać się na rzadziej używane gazy.

Jak często mierzyć i wysyłać dane z czujnika jakości powietrza?

W większości zastosowań domowych wystarczy pomiar co 5–15 sekund i uśrednianie wyników do interwału 30–60 sekund. Samą wysyłkę do chmury można ograniczyć do co 30–60 sekund, a przy łączach mobilnych nawet co kilka minut.

Wyjątkiem są małe, szczelne pomieszczenia (np. sala konferencyjna), gdzie CO₂ rośnie szybko, oraz warsztaty, w których pył potrafi skoczyć w kilka sekund. Jeśli na podstawie danych sterujesz wentylacją, dobrze trzymać całkowite opóźnienie (od pomiaru do decyzji) poniżej kilkunastu sekund.

Jakiej dokładności mogę się spodziewać po tanim, własnym czujniku powietrza?

Przy rozsądnym doborze komponentów można uzyskać: temperaturę w granicach ±0,5–1°C, wilgotność ±3–5% RH i CO₂ z błędem rzędu kilkuset ppm. Dla zastosowań domowych ważniejsza jest stabilność i powtarzalność wskazań niż laboratoryjna zgodność z absolutną wartością.

Prosta domowa kalibracja polega na porównaniu wskazań z referencją – np. z uznaną stacją zewnętrzną lub innym sensorem tej samej serii. Po kilku godzinach pomiarów obok siebie można wprowadzić w firmware prostą poprawkę offsetu, żeby zbliżyć się do „wzorca”.

Czy budowa własnego sensora jakości powietrza jest trudna dla początkującego?

Wystarczy znajomość elektroniki na poziomie „Arduino + kilka modułów” i podstawy programowania w C++ lub MicroPythonie. Najpierw można uruchomić sam odczyt pomiarów lokalnie, potem dodać wysyłkę MQTT/HTTP, a na końcu funkcje takie jak OTA czy dashboard w chmurze.

Projekt da się rozwijać etapami: od prostego pudełka z diodą RGB pokazującą stan powietrza, po pełnoprawny węzeł IoT spięty z Home Assistantem. Dzięki temu nie trzeba opanować wszystkiego naraz, tylko dokładać kolejne klocki w miarę rosnących potrzeb.

Jak zadbać o bezpieczeństwo i wygodę obsługi własnego czujnika IoT?

Podstawy to szyfrowane Wi‑Fi (WPA2/WPA3), brak otwartych, niezabezpieczonych portów oraz niewysyłanie haseł „wprost” po MQTT. Tryb konfiguracji przez własny punkt dostępowy (AP) dobrze ograniczyć czasowo lub zabezpieczyć hasłem, żeby nikt z zewnątrz nie przejął urządzenia.

Dla wygody użytkownika przydaje się konfiguracja Wi‑Fi i MQTT z poziomu przeglądarki, aktualizacje OTA bez otwierania obudowy oraz prosty sygnał stanu (dioda RGB lub mały wyświetlacz). Nawet przy braku internetu warto mieć lokalną stronę www na samym urządzeniu, pokazującą ostatnie pomiary i status sensorów.

Opracowano na podstawie

• WHO global air quality guidelines: particulate matter (PM2.5 and PM10), ozone, nitrogen dioxide, sulfur dioxide and carbon monoxide. World Health Organization (2021) – Normy i wpływ PM2.5/PM10 oraz gazów na zdrowie
• Ambient (outdoor) air pollution. World Health Organization – Skutki zdrowotne zanieczyszczeń powietrza i znaczenie monitoringu
• ASHRAE Standard 62.1 – Ventilation for Acceptable Indoor Air Quality. ASHRAE (2019) – Wymagania jakości powietrza i wentylacji w budynkach
• Indoor Air Quality Guidelines for Selected Pollutants. World Health Organization Regional Office for Europe (2010) – Wytyczne WHO dla zanieczyszczeń w pomieszczeniach
• Guidelines for Indoor Air Quality: Carbon Dioxide. Health Canada (2021) – Zalecane poziomy CO₂ i interpretacja pomiarów
• Non-dispersive infrared (NDIR) gas sensors: principles and applications. Elsevier (2013) – Zasada działania i dokładność czujników CO₂ NDIR
• Evaluation of low-cost sensors for ambient PM2.5 monitoring. U.S. Environmental Protection Agency (2019) – Ocena dokładności i powtarzalności tanich czujników pyłu
• Air Quality Sensors: Performance Metrics and Calibration Methods. National Institute of Standards and Technology (2018) – Metody kalibracji i oceny czujników jakości powietrza
• BME280 Combined Humidity and Pressure Sensor – Datasheet. Bosch Sensortec (2018) – Parametry techniczne i dokładność pomiaru T/RH/ciśnienia