Od Raspberry Pi do sensora IoT w chmurze: MQTT, broker i dashboard w jednym popołudniu

Przez
Renata Michalski
-
0
68
3.7/5 - (3 votes)

Nawigacja:

Koncepcja projektu: od maliny do działającego sensora w chmurze

Co dokładnie ma powstać w jedno popołudnie

Cel jest prosty: Raspberry Pi odczytuje dane z sensora (np. temperatura), wysyła je przez MQTT do brokera w chmurze, a dane pojawiają się na dashboardzie WWW w czasie zbliżonym do rzeczywistego. Bez skomplikowanej elektroniki, bez pisania dziesiątek plików konfiguracyjnych.

Całość składa się z czterech kluczowych elementów:

  • Sensor podłączony do Raspberry Pi (np. DHT22, BME280, DS18B20).
  • Raspberry Pi jako klient MQTT, który publikuje dane z sensora.
  • Broker MQTT w chmurze (np. HiveMQ Cloud, EMQX Cloud, testowy broker publiczny lub własny Mosquitto na VPS).
  • Dashboard WWW, który subskrybuje wybrane topici i prezentuje dane (Node-RED Dashboard, Grafana, panel brokera lub prosty frontend).

Efekt końcowy: otwierasz stronę WWW i widzisz np. wykres temperatury z ostatnich godzin, aktualną wartość, ewentualnie historię z bazy, jeśli użyjesz bardziej rozbudowanego narzędzia.

Minimalne wymagania sprzętowe i sieciowe

Do takiego projektu wystarczy dowolny nowszy model Raspberry Pi:

  • Raspberry Pi 3B, 3B+ lub 4 (najwygodniejsze, stabilne Wi‑Fi, dobra wydajność).
  • Raspberry Pi Zero 2 W też da radę, ale praca przy pierwszej konfiguracji bywa wolniejsza.

Kluczowe wymagania:

  • Zasilanie – oryginalny lub dobrej jakości zasilacz 5V o odpowiedniej wydajności prądowej (dla Pi 3/4 zwykle 2,5–3 A).
  • Karta SD – minimum 16 GB, klasa 10, markowa (Unikanie no‑name znacząco zmniejsza ryzyko korupcji systemu).
  • Sieć – stałe połączenie z internetem: Ethernet (najstabilniejszy) lub Wi‑Fi.

Do podłączenia sensora wystarczą przewody typu dupont i podstawowa płytka stykowa, ale można wszystko zbudować też na samych przewodach, jeśli połączenia będą solidne.

Architektura przepływu danych IoT

Schemat przepływu danych w takim projekcie da się streścić w jednym ciągu:

Sensor → Raspberry Pi (skrypt) → klient MQTT → broker w chmurze → dashboard/subskrybent.

Rozbijając to na kroki:

  1. Sensor zwraca odczyt (np. temperatura w °C).
  2. Skrypt w Pythonie na Raspberry Pi pobiera odczyt.
  3. Ten sam skrypt tworzy wiadomość (payload) i publikuje ją do brokera MQTT na określony topic.
  4. Broker w chmurze przyjmuje wiadomość i utrzymuje połączenia z subskrybentami.
  5. Dashboard (np. Node-RED, Grafana lub panel brokera) subskrybuje topic i natychmiast dostaje nowe dane.

Dzięki modelowi publish/subscribe Raspberry Pi nie musi znać adresu dashboardu ani martwić się o jego dostępność – wysyła dane tylko do brokera.

Technologie użyte w projekcie

Oś projektu opiera się na prostych i dobrze udokumentowanych technologiach:

  • MQTT – lekki protokół komunikacyjny, idealny dla IoT.
  • Python – język skryptowy, w którym powstaje prosty klient MQTT i obsługa sensora.
  • Broker MQTT w chmurze – np. HiveMQ Cloud (darmowy tier), Mosquitto na małym VPS, EMQX Cloud.
  • Node-RED – narzędzie do „klikania” przepływów danych, z gotowym modułem dashboard.

Cały stack można zbudować wyłącznie na Raspberry Pi (broker lokalny, Node-RED i dashboard też na malinie), ale ustawienie brokera w chmurze daje efekt „prawdziwego IoT” – dane są dostępne z zewnątrz, z dowolnego miejsca.

Jakie umiejętności są potrzebne, a czego nie trzeba

Przydają się:

  • Podstawy Linuxa: logowanie przez SSH, kilka komend (cd, ls, sudo apt update itd.).
  • Minimalna znajomość Pythona lub gotowość do skopiowania gotowego przykładu i dostosowania kilku linii.
  • Orientacja w sieci: adres IP, port, pojęcie serwera i klienta.

Nie jest potrzebne:

  • Zaawansowane programowanie obiektowe, frameworki webowe, pełne DevOps.
  • Profesjonalna elektronika – wystarczy poziom hobbystyczny, umiejętność odczytu prostych schematów.
  • Zaawansowana administracja Linuxem – konfiguracja sprowadza się do kilku prostych plików i komend.

Przygotowanie Raspberry Pi pod projekt IoT

Wybór systemu: Raspberry Pi OS Lite czy pełny

Do projektu sensora IoT w zupełności wystarczy Raspberry Pi OS Lite (bez środowiska graficznego). Praca odbywa się przez SSH, a wszystkie narzędzia (Python, klient MQTT) działają w konsoli.

Warianty:

  • Raspberry Pi OS Lite – mniej zasobów, szybciej działa, idealny do headless.
  • Raspberry Pi OS z desktopem – przydatny, jeśli ktoś woli konfigurację „po klikaniu”, ale nie jest konieczny.

Jeśli Raspberry Pi będzie działać jako „czarna skrzynka” gdzieś w szafce, tryb headless jest naturalnym wyborem.

Instalacja systemu Raspberry Pi OS

Najszybszy sposób to Raspberry Pi Imager. Kroki są zawsze te same:

  1. Ściągnij Raspberry Pi Imager na komputer (Windows, macOS, Linux).
  2. Włóż kartę microSD do czytnika.
  3. Wybierz w Imagerze system: Raspberry Pi OS Lite (32-bit).
  4. Wybierz kartę SD jako urządzenie docelowe.
  5. Skorzystaj z opcji „Advanced options” (ikona koła zębatego):
    • ustaw nazwę hosta (np. raspi-iot),
    • włącz SSH,
    • ustaw użytkownika i hasło,
    • skonfiguruj Wi‑Fi (SSID, hasło, kraj), jeśli nie używasz Ethernetu.
  6. Zapisz obraz i bezpiecznie wysuń kartę.

Po włożeniu karty do Raspberry Pi i podłączeniu zasilania urządzenie powinno uruchomić się i być dostępne po sieci w ciągu 1–2 minut.

Pierwsze logowanie przez SSH i podstawowe zabezpieczenia

Do logowania użyj:

  • ssh user@raspi-iot – jeśli Twoja sieć rozwiązuje nazwę hosta,
  • lub ssh user@<adres_IP>, jeśli widzisz adres w routerze lub użyjesz skanera sieci (np. nmap, aplikacje mobilne typu „Fing”).

Po pierwszym logowaniu:

  • zmień domyślne hasło, jeśli użyłeś domyślnego użytkownika pi,
  • uruchom sudo raspi-config i:
    • ustaw lokalizację (strefa czasowa, język),
    • zweryfikuj ustawienia sieci i interfejsów (np. I2C, 1‑Wire do sensorów).

Aktualizacja systemu i podstawowe pakiety

Po uruchomieniu warto system zaktualizować i doinstalować narzędzia, które przydadzą się wielokrotnie:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y git python3 python3-pip python3-venv 
                    mosquitto-clients net-tools htop

Przydają się:

  • mosquitto-clients – narzędzia do testów MQTT (mosquitto_pub, mosquitto_sub).
  • net-tools – np. ifconfig do sprawdzania adresu IP.
  • python3-pip – instalacja bibliotek Pythona z PyPI (np. paho-mqtt).

Konfiguracja sieci: Wi‑Fi, Ethernet, IP

Kilka praktycznych zasad:

  • Do stałego sensora lepszy jest Ethernet – mniej problemów z zasięgiem i stabilnością.
  • Przy Wi‑Fi sensowne jest albo ustawienie stałego IP, albo rezerwacji DHCP po stronie routera.

Aktualny adres IP możesz sprawdzić:

hostname -I

Jeśli chcesz ręcznie ustawić statyczny adres (np. dla Ethernetu), użyj dhcpcd.conf lub narzędzia w systemie (w nowszych wersjach Raspberry Pi OS – raspi-config ma odpowiednie opcje), ale na początek w zupełności wystarczy DHCP z rezerwacją w routerze.

Twarde zasady sprzętowe przy projektach IoT

Prosta checklista, która oszczędza wiele godzin frustracji:

  • Unikaj tanich zasilaczy USB, które „dają radę” tylko teoretycznie – niestabilne zasilanie powoduje losowe restarty i błędy na karcie SD.
  • Nie używaj kart SD z odzysku, z telefonów po kilku latach – ich żywotność może być na wyczerpaniu.
  • Przy dłuższej pracy 24/7 zadbaj o minimalne chłodzenie (radiator, mały wentylator przy Pi 4).
  • Nie odłączaj zasilania „na twardo” bez wcześniejszego sudo shutdown -h now – to częsty powód uszkodzeń systemu plików.

Co to jest MQTT i dlaczego pasuje do prostego IoT

Model publish/subscribe na przykładzie sensora i dashboardu

MQTT działa inaczej niż typowy model HTTP. Zamiast sytuacji „klient pyta – serwer odpowiada”, używa schematu publish/subscribe.

W uproszczeniu:

  • Sensor (Raspberry Pi) jest publikatorem – wysyła wiadomości na określony topic.
  • Dashboard jest subskrybentem – zapisuje się na dany topic i dostaje wszystko, co jest na niego publikowane.
  • Broker MQTT stoi pośrodku i łączy tych, którzy publikują, z tymi, którzy subskrybują.

Przykład: Raspberry Pi wysyła co 10 sekund temperaturę na topic dom/salon/temperatura, a Node-RED dashboard subskrybuje ten topic i wyświetla wartość na wykresie.

Podstawowe pojęcia MQTT

Kilka terminów, bez których dalsza konfiguracja jest trudna:

  • Broker – serwer MQTT, który pośredniczy w wymianie wiadomości.
  • Klient – każde urządzenie lub aplikacja łącząca się z brokerem (Raspberry Pi, dashboard, testowy klient na laptopie).
  • Topic – ścieżka tekstowa, coś jak „kanał”, np. dom/salon/temperatura.
  • Payload – treść wiadomości, najczęściej JSON, tekst lub liczba.
  • QoS – poziom gwarancji dostarczenia wiadomości (0, 1, 2).
  • Retain – flaga, czy ostatnia wiadomość na danym topicu ma być przechowana jako „stan bieżący”.
  • Keep-alive – mechanizm utrzymywania połączenia (okresowe pakiety „ping”).

MQTT kontra HTTP w projektach IoT

MQTT celuje w inne zastosowania niż klasyczne API HTTP:

  • Mniejsze narzuty – nagłówki są lekkie, nie ma pełnego HTTP/1.1 przy każdym żądaniu.
  • Stałe połączenie – urządzenie nawiązuje jedno połączenie do brokera i używa go wielokrotnie.
  • Lepiej znosi niestabilne łącza – działa dobrze przy słabym Wi‑Fi czy łączach mobilnych.
  • Łatwiejsze wzorce komunikacji – wiele subskrybentów może nasłuchiwać ten sam topic.

Dla prostego sensora wysyłającego dane co kilkanaście sekund MQTT jest naturalnym wyborem, a implementacja klienta w Pythonie sprowadza się do kilkunastu linii.

Poziomy QoS i kiedy wystarczy QoS 0

MQTT definiuje trzy poziomy QoS:

  • QoS 0 – „at most once”, brak potwierdzeń, minimalne opóźnienia.
  • QoS 1 – „at least once”, broker potwierdza otrzymanie wiadomości.
  • QoS 2 – „exactly once”, najbardziej złożony, rzadziej używany w prostych projektach.

Dla domowego sensora temperatury QoS 0 jest zwykle wystarczający. Jeśli jedna wiadomość zaginie, za kilka sekund przyjdzie kolejna. W przypadku krytycznych systemów (np. powiadomienia o zalaniu) można rozważyć QoS 1.

Wybór brokera MQTT: lokalnie czy w chmurze

Trzy scenariusze uruchomienia brokera

Przy prostym sensorze IoT realne są trzy warianty:

  • Broker lokalny na Raspberry Pi – wszystko działa w LAN, brak zależności od Internetu.
  • Broker na innym serwerze w sieci domowej – np. NAS, mini‑PC, VM.
  • Broker w chmurze – serwis typu MQTT as a Service lub własny VPS.

Do pierwszego projektu najprościej uruchomić brokera bezpośrednio na Raspberry Pi. Później łatwo przenieść konfigurację na maszynę w chmurze.

Kiedy wystarczy broker lokalny

Broker lokalny ma sens, gdy:

  • czujnik i dashboard działają w tej samej sieci (LAN lub VPN),
  • dane nie muszą być dostępne spoza domu/biura,
  • liczba urządzeń jest mała (kilka–kilkanaście klientów).

Do domowego monitoringu temperatury, wilgotności czy poboru prądu lokalny Mosquitto na Raspberry Pi jest szybszy do uruchomienia niż jakakolwiek chmura.

Broker w chmurze: plusy i minusy

W chmurze działają zarówno gotowe usługi MQTT (np. broker publiczny z ograniczeniami), jak i własne instancje na VPS (Mosquitto, EMQX, VerneMQ).

Zalety:

  • dostęp do danych z dowolnego miejsca bez kombinacji z przekierowaniem portów,
  • lepsza odporność na restarty routera czy zanik zasilania w domu,
  • łatwiejsza integracja z innymi usługami w chmurze (bazy danych, serwer aplikacji).

Wadą są dodatkowe koszty i konieczność zadbania o szyfrowanie (TLS) i autoryzację, bo broker stoi „na widoku” internetu.

Prosty kompromis: dwa brokery i bridge

Jeżeli projekt się rozrośnie, można użyć dwóch brokerów:

  • lokalnego (np. na Raspberry Pi) do komunikacji z sensorami,
  • zdalnego w chmurze dla aplikacji, które potrzebują dostępu z zewnątrz.

Między brokerami konfiguruje się bridge: wybrane topici z brokera lokalnego są przekazywane do chmury. Na start wystarczy jeden broker lokalny, ale warto wiedzieć, że skalowanie jest możliwe bez przeprojektowywania wszystkiego.

Zbliżenie na płytkę Raspberry Pi z widocznymi podzespołami i ścieżkami
Źródło: Pexels | Autor: Mathias Wouters

Uruchomienie i testy brokera MQTT (minimalna konfiguracja)

Instalacja Mosquitto na Raspberry Pi

Na Raspberry Pi z Raspberry Pi OS instalacja sprowadza się do jednej komendy:

sudo apt install -y mosquitto mosquitto-clients

Po instalacji serwer zwykle startuje automatycznie i nasłuchuje na porcie 1883 na wszystkich interfejsach.

Sprawdzenie, czy broker działa

Pierwszy szybki test:

sudo systemctl status mosquitto

W sekcji Active powinno być active (running). Jeśli nie jest uruchomiony:

sudo systemctl start mosquitto
sudo systemctl enable mosquitto

Drugi test – czy port nasłuchuje:

sudo netstat -tulpn | grep 1883

Minimalna konfiguracja Mosquitto

Domyślnie Mosquitto w Debianie/Raspberry Pi OS jest w miarę bezpieczny, ale często ma włączone ograniczenia dla anonimowych klientów, albo przeciwnie – wszystko otwarte bez hasła.

Plik główny:

/etc/mosquitto/mosquitto.conf

Dobry start to wyczyścić go i dodać prostą, czytelną konfigurację. Najpierw zrób kopię:

sudo mv /etc/mosquitto/mosquitto.conf /etc/mosquitto/mosquitto.conf.bak

Następnie utwórz nowy plik:

sudo nano /etc/mosquitto/mosquitto.conf

I wpisz:

listener 1883
allow_anonymous true
persistence true
persistence_location /var/lib/mosquitto/

Po zapisaniu pliku zrestartuj usługę:

sudo systemctl restart mosquitto

Dla domowego testu taka konfiguracja wystarczy. W sieci produkcyjnej trzeba wyłączyć allow_anonymous i włączyć hasła lub certyfikaty.

Test lokalny: mosquitto_pub / mosquitto_sub

Do szybkiego sprawdzenia brokera najlepiej użyć dwóch terminali SSH na Raspberry Pi.

W pierwszym terminalu uruchom subskrypcję:

mosquitto_sub -h localhost -t test/topic

W drugim wyślij wiadomość:

mosquitto_pub -h localhost -t test/topic -m "hello mqtt"

Jeżeli w pierwszym oknie pojawi się tekst hello mqtt, broker działa poprawnie.

Test z innego urządzenia w sieci

Kolejny krok to połączenie z laptopa lub innego komputera w LAN. Najpierw sprawdź IP Raspberry Pi:

hostname -I

Załóżmy, że adres to 192.168.1.50. Na laptopie z Linuxem/macOS:

mosquitto_sub -h 192.168.1.50 -t test/lan
mosquitto_pub -h 192.168.1.50 -t test/lan -m "test z laptopa"

Na Windows można użyć np. MQTT Explorer albo innych graficznych klientów MQTT. W tym przypadku jako host wpisujesz IP maliny i port 1883.

Dodanie prostego logowania brokera

Kiedy coś nie działa, logi bardzo pomagają. Do istniejącego pliku mosquitto.conf dopisz:

log_dest syslog
log_dest stdout
log_type error
log_type warning
log_type notice
log_type information

Po restarcie:

sudo systemctl restart mosquitto

Logi można podejrzeć:

journalctl -u mosquitto -f

Dzięki temu od razu widać błędne loginy, połączenia z niepoprawnego IP czy inne problemy.

Przełączenie na broker z hasłem (opcjonalnie)

Jeśli broker ma być wystawiony poza LAN lub w LAN, którym nie do końca ufamy, trzeba wyłączyć anonimowy dostęp.

Najpierw tworzysz plik haseł:

sudo mosquitto_passwd -c /etc/mosquitto/passwd sensor_user

Następnie zmieniasz konfigurację:

sudo nano /etc/mosquitto/mosquitto.conf

Przykładowa zawartość:

listener 1883
allow_anonymous false
password_file /etc/mosquitto/passwd
persistence true
persistence_location /var/lib/mosquitto/

Restart:

sudo systemctl restart mosquitto

Teraz każdy klient musi podać login i hasło, np.:

mosquitto_pub -h 192.168.1.50 -t test/auth -m "ok" -u sensor_user -P <hasło>

Podłączenie prostego sensora do Raspberry Pi (bez nadmiarowej elektroniki)

Wybór sensora: cyfrowy zamiast analogowego

Raspberry Pi nie ma wbudowanych wejść analogowych, więc najłatwiej zacząć od sensora cyfrowego, który komunikuje się po:

  • GPIO 1‑Wire (np. DS18B20 – czujnik temperatury),
  • I2C (np. BME280 – temperatura, wilgotność, ciśnienie),
  • SPI (mniej popularne w prostych projektach),
  • UART (np. niektóre czujniki jakości powietrza).

Dobrym „pierwszym” czujnikiem jest DS18B20 w wersji wodoodpornej lub moduł BME280. Obydwa mają gotowe biblioteki w Pythonie i nie wymagają kalibracji na start.

Przykład: podłączenie czujnika temperatury DS18B20 (1‑Wire)

Typowy moduł DS18B20 ma trzy przewody:

  • czerwony – VCC (3.3 V),
  • czarny – GND,
  • żółty/biały – DATA.

Prosty schemat połączeń:

  • DATA → GPIO4 (fizyczny pin 7),
  • VCC → 3.3 V (fizyczny pin 1),
  • GND → dowolny GND (np. fizyczny pin 6).

Czujnik DS18B20 wymaga jeszcze rezystora podciągającego 4.7 kΩ między VCC (3.3 V) a linią DATA. W praktyce najprościej kupić gotowy moduł na małej płytce – rezystor jest już wlutowany.

Aktywacja interfejsu 1‑Wire w systemie

Na Raspberry Pi interfejs 1‑Wire trzeba włączyć:

sudo raspi-config
  • Interface Options → 1-Wire → Enable.

Po wyjściu i restarcie:

sudo reboot

Po ponownym uruchomieniu sprawdź obecność modułów:

lsmod | grep w1

Sprawdzenie, czy DS18B20 jest widoczny w systemie

Wszystkie czujniki 1‑Wire pojawiają się w katalogu:

ls /sys/bus/w1/devices/

Powinno się tam pojawić coś w rodzaju:

28-00000xxxxxxx  w1_bus_master1

Odczyt surowych danych:

cat /sys/bus/w1/devices/28-00000xxxxxxx/w1_slave

W drugim wierszu na końcu jest t=XXXXXX, gdzie wartość to temperatura w tysięcznych części stopnia Celsjusza (np. t=21437 oznacza 21.437°C).

Prosty skrypt Pythona do odczytu DS18B20

Dla wygody lepiej napisać krótki skrypt, który:

  • wyszuka czujnik w katalogu 1‑Wire,
  • odczyta temperaturę i zwróci ją w stopniach Celsjusza jako float.

Utwórz katalog na projekt:

mkdir -p ~/iot-sensor
cd ~/iot-sensor

Plik ds18b20.py:

#!/usr/bin/env python3
import glob
import time

BASE_DIR = "/sys/bus/w1/devices/"

def _get_device_file():
    devices = glob.glob(BASE_DIR + "28-*")
    if not devices:
        raise RuntimeError("Nie znaleziono sensora DS18B20")
    return devices[0] + "/w1_slave"

def read_temp_c():
    device_file = _get_device_file()
    with open(device_file, "r") as f:
        lines = f.readlines()

    # jeśli CRC nie jest OK, poczekaj i spróbuj ponownie
    retries = 3
    while lines[0].strip()[-3:] != "YES" and retries > 0:
        time.sleep(0.2)
        with open(device_file, "r") as f:
            lines = f.readlines()
        retries -= 1

    if lines[0].strip()[-3:] != "YES":
        raise RuntimeError("Błąd odczytu z DS18B20")

    temp_pos = lines[1].find("t=")
    if temp_pos == -1:
        raise RuntimeError("Brak pola t= w odczycie")

    temp_string = lines[1][temp_pos+2:].strip()
    temp_c = float(temp_string) / 1000.0
    return temp_c

if __name__ == "__main__":
    print(f"{read_temp_c():.2f}")

Nadaj uprawnienia i przetestuj:

chmod +x ds18b20.py
./ds18b20.py

Powinieneś zobaczyć wartość temperatury z dwoma miejscami po przecinku.

Instalacja klienta MQTT w Pythonie

Do komunikacji z brokerem MQTT użyjemy biblioteki paho-mqtt:

python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install paho-mqtt

Skrypt: sensor publikujący temperaturę do MQTT

Kolejny plik w katalogu projektu: sensor_mqtt.py.

#!/usr/bin/env python3
import time
import json
from datetime import datetime

import paho.mqtt.client as mqtt

import ds18b20  # nasz moduł z odczytem temperatury

MQTT_BROKER = "localhost"   # lub IP brokera, np. "192.168.1.50"
MQTT_PORT = 1883
MQTT_TOPIC = "dom/salon/temperatura"
MQTT_CLIENT_ID = "raspi-sensor-1"

PUBLISH_INTERVAL = 10  # sekundy

def main():
    client = mqtt.Client(client_id=MQTT_CLIENT_ID, clean_session=True)
    # jeśli używasz użytkownika/hasła na brokerze:
    # client.username_pw_set("sensor_user", "TajneHaslo")

    client.connect(MQTT_BROKER, MQTT_PORT, keepalive=60)
    client.loop_start()

    try:
        while True:
            temp_c = ds18b20.read_temp_c()
            payload = {
                "timestamp": datetime.utcnow().


Uzupełnienie skryptu: publikacja JSON z timestampem



Dokończmy plik sensor_mqtt.py, tak aby wysyłał proste JSON-y z temperaturą i czasem.



#!/usr/bin/env python3
import time
import json
from datetime import datetime, timezone

import paho.mqtt.client as mqtt

import ds18b20  # nasz moduł z odczytem temperatury

MQTT_BROKER = "localhost"   # lub IP brokera, np. "192.168.1.50"
MQTT_PORT = 1883
MQTT_TOPIC = "dom/salon/temperatura"
MQTT_CLIENT_ID = "raspi-sensor-1"

PUBLISH_INTERVAL = 10  # sekundy

def main():
    client = mqtt.Client(client_id=MQTT_CLIENT_ID, clean_session=True)
    # jeśli używasz użytkownika/hasła na brokerze:
    # client.username_pw_set("sensor_user", "TajneHaslo")

    client.connect(MQTT_BROKER, MQTT_PORT, keepalive=60)
    client.loop_start()

    try:
        while True:
            temp_c = ds18b20.read_temp_c()
            payload = {
                "timestamp": datetime.now(timezone.utc).isoformat(),
                "temperature_c": round(temp_c, 2),
                "sensor_id": MQTT_CLIENT_ID,
            }
            client.publish(MQTT_TOPIC, json.dumps(payload), qos=0, retain=False)
            print(f"Wysłano: {payload}")
            time.sleep(PUBLISH_INTERVAL)
    except KeyboardInterrupt:
        print("Przerwano przez użytkownika")
    finally:
        client.loop_stop()
        client.disconnect()

if __name__ == "__main__":
    main()

Test lokalny można wykonać tak jak wcześniej, subskrybując temat:
mosquitto_sub -h localhost -t dom/salon/temperatura

Po uruchomieniu ./sensor_mqtt.py w subskrypcji powinny pojawiać się kolejne linie JSON z temperaturą.
Uruchamianie sensora w tle jako usługi systemd

Ręczne odpalanie skryptu po każdym restarcie szybko staje się uciążliwe. Lepiej zrobić z niego usługę systemową.

Najpierw upewnij się, że wirtualne środowisko jest w stałej lokalizacji, np. /home/pi/iot-sensor/.venv, a skrypt w /home/pi/iot-sensor/sensor_mqtt.py.

Plik jednostki systemd:
sudo nano /etc/systemd/system/iot-sensor.service

Przykładowa zawartość:
[Unit]
Description=Raspberry Pi DS18B20 MQTT sensor
After=network-online.target
Wants=network-online.target

[Service]
User=pi
WorkingDirectory=/home/pi/iot-sensor
Environment="PATH=/home/pi/iot-sensor/.venv/bin"
ExecStart=/home/pi/iot-sensor/.venv/bin/python /home/pi/iot-sensor/sensor_mqtt.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Następnie przeładuj konfigurację i włącz usługę:
sudo systemctl daemon-reload
sudo systemctl enable iot-sensor
sudo systemctl start iot-sensor

Status i logi:
systemctl status iot-sensor
journalctl -u iot-sensor -f

Od tej chwili sensor startuje automatycznie po reboocie i co kilka sekund wysyła dane do brokera.
Dashboard do podglądu sensora: Node-RED na Raspberry Pi
Instalacja Node-RED

Najprostszy dashboard dla MQTT można zrobić na samym Raspberry Pi, korzystając z Node-RED.

Instalacja skryptem zalecanym przez twórców:
bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/update-nodejs-and-nodered)

Po instalacji:
sudo systemctl enable nodered.service
sudo systemctl start nodered.service

Domyślnie edytor Node-RED jest dostępny pod adresem:
http://<IP_RASPBERRY_PI>:1880
Dodanie wsparcia dla dashboardu w Node-RED

Aby narysować prosty wykres i wskaźnik, potrzebne są węzły dashboardu.

W przeglądarce otwórz edytor, wejdź w menu (trzy kreski w prawym górnym rogu) → Manage palette → Install i wyszukaj:
  • node-red-dashboard

Zainstaluj pakiet. Po chwili w lewym panelu pojawią się nowe węzły z sekcji „dashboard”.
Prosty flow: MQTT IN → parser JSON → wskaźnik temperatury

Pierwszy dashboard może składać się z trzech elementów:
  • węzeł mqtt in,
  • węzeł json,
  • węzeł gauge (z dashboardu).

Kolejne kroki:
  1. Przeciągnij na płótno węzeł mqtt in (z sekcji „input”).
  2. Podwójne kliknięcie → w polu Server wybierz + add new mqtt-broker....
  3. W konfiguracji wpisz adres brokera (np. localhost lub 192.168.1.50), port 1883, zapisz.
  4. W polu Topic wpisz dom/salon/temperatura.

Następnie:
  1. Przeciągnij węzeł json (sekcja „function”). Pozostaw domyślną konfigurację (konwersja tekstu do obiektu).
  2. Przeciągnij węzeł gauge (sekcja „dashboard”).
  3. W jego ustawieniach:
    • w polu Group utwórz nową grupę, np. Dom > Salon,
    • w polu Label wpisz np. Temperatura,
    • ustaw zakres, np. 0 do 40,
    • w polu Value format wpisz {{msg.payload.temperature_c}}.

Połącz węzły:
[mqtt in] --> [json] --> [gauge]

Kliknij Deploy w prawym górnym rogu.

Dashboard będzie dostępny pod adresem:
http://<IP_RASPBERRY_PI>:1880/ui

Jeśli sensor działa i publikuje dane, wskaźnik temperatury powinien aktualizować się co kilka sekund.
Dodanie wykresu historycznego

Aby podejrzeć zmiany temperatury w czasie, można dodać węzeł chart.

W edytorze:
  1. Przeciągnij węzeł chart (dashboard).
  2. W konfiguracji wybierz tę samą grupę co dla wskaźnika.
  3. Ustaw typ na Line chart, etykietę np. Temperatura (wykres).
  4. Pozostaw domyślne parametry ilości punktów i zakresu czasu.

Teraz trzeba ustandaryzować format wejścia. Najprościej użyć węzła function pomiędzy json a chart.

Dodaj węzeł function z następującym kodem:
// zakładamy, że msg.payload.temperature_c to float
msg.topic = "temperatura";
msg.payload = msg.payload.temperature_c;
return msg;

Połącz:
[mqtt in] --> [json] --> [function] --> [chart]

Możesz też rozwidlić dane, aby jednocześnie zasilać wskaźnik i wykres:
[mqtt in] --> [json] --> [gauge]
                      
                       --> [function] --> [chart]

Po wdrożeniu flow i kilku minutach działania pojawi się czytelny wykres temperatury.
Konfiguracja Node-RED z brokerem z hasłem

Jeśli wcześniej włączyłeś uwierzytelnianie na brokerze, trzeba podać dane logowania również w Node-RED.

W edytorze otwórz konfigurację węzła mqtt in, kliknij przy brokerze ikonę ołówka, następnie:
  • w sekcji Security wpisz Username i Password (np. sensor_user),
  • zapisz konfigurację i ponownie kliknij Deploy.

Jeśli dane są poprawne, status węzła mqtt in zmieni się na connected.
Wystawienie sensora i dashboardu do chmury
Udostępnienie brokera MQTT do Internetu (wariant z tunelowaniem)

Bezpośrednie otwieranie portu 1883 na routerze bywa ryzykowne. Bezpieczniejszy jest tunel przez usługę typu reverse proxy lub dedykowany broker w chmurze.

Jeden z prostszych wariantów to lokalny broker na Raspberry Pi, a w chmurze dodatkowy broker, do którego malina łączy się jako klient i przekazuje dane.
Bridge MQTT: łączenie lokalnego brokera z chmurowym

Mosquitto potrafi działać jako bridge – przekazywać tematy do innego brokera.

Załóżmy, że masz konto w chmurowym brokerze, który nasłuchuje pod adresem cloud.example.com na porcie 8883 (TLS) i wymaga logowania.

Dodaj plik konfiguracyjny bridge:
sudo nano /etc/mosquitto/conf.d/bridge.conf

Przykładowa minimalna konfiguracja:
connection raspi-to-cloud
address cloud.example.com:8883

topic dom/# out 0

remote_username sensor_user
remote_password SuperTajneHaslo

bridge_cafile /etc/ssl/certs/ca-certificates.crt
bridge_insecure false

start_type automatic
try_private false
notifications false

Ta konfiguracja wysyła wszystkie tematy zaczynające się od dom/ do brokera w chmurze. Oczywiście adres, port i dane logowania trzeba dopasować do wybranej usługi.

Po zapisaniu:
sudo systemctl restart mosquitto
journalctl -u mosquitto -f

W logach powinna pojawić się informacja o połączeniu bridge. Z drugiej strony (np. w panelu chmurowego brokera lub przez klienta MQTT) powinny być widoczne te same dane sensora, które idą lokalnie.
Prosty dashboard w chmurze (przykład: Cloud MQTT + MQTT Explorer)

Wiele komercyjnych brokerów oferuje własne panele i wykresy. Jeśli jednak usługa takiego panelu nie ma, można użyć dowolnego klienta MQTT z obsługą historii, np. MQTT Explorer zainstalowanego na laptopie.

Konfiguracja w MQTT Explorer:
  • Host: adres chmurowego brokera,
  • Port: np. 8883,
  • Username / Password: jak w bridge,
  • w zakładce SSL włączyć Use TLS i wskazać zaufany CA (lub zaakceptować certyfikat, zależnie od usługi).

Po połączeniu w drzewie tematów powinno pojawić się dom/salon/temperatura, z którego można od razu odczytywać JSON-y z sensora.
Przeniesienie dashboardu na zewnętrzny serwer

Jeśli Node-RED ma być dostępny spoza LAN, zamiast wystawiać port 1880 na routerze lepiej zainstalować Node-RED na VPS lub w wybranej platformie PaaS i połączyć go z tym samym brokerem chmurowym.

Schemat:
  • Raspberry Pi → lokalny broker (Mosquitto)
  • Mosquitto (bridge) → broker w chmurze
  • Node-RED na VPS → broker w chmurze → dashboard dostępny publicznie

W takim układzie malina nie musi mieć publicznego IP, a jedynym elementem wystawionym do Internetu jest broker SaaS i ewentualnie serwer z Node-RED.
Rozszerzanie projektu o kolejne sensory i tematy
Struktura tematów dla wielu pomieszczeń

Gdy pojawiają się kolejne maliny i czujniki, przydaje się czytelna konwencja nazw tematów.

Przykładowy schemat:
dom/<pomieszczenie>/<typ_sensora>/<metryka>

Na przykład:
  • dom/salon/temperatura/value
  • dom/salon/wilgotnosc/value
  • dom/sypialnia/temperatura/value

W takim wariancie sensor publikuje pod precyzyjnym tematem, a dashboard może subskrybować wiele tematów naraz, używając wildcardów, np. dom/+/temperatura/value.
Modyfikacja skryptu sensora pod nową strukturę

Zmieńmy temat i payload w sensor_mqtt.py, aby lepiej pasowały do większego systemu.
Najczęściej zadawane pytania (FAQ)
Jakie Raspberry Pi wybrać do prostego sensora IoT z MQTT?
Najwygodniej użyć Raspberry Pi 3B, 3B+ lub 4 – mają stabilne Wi‑Fi, dobrą wydajność i poradzą sobie z brokerem, klientem MQTT i ewentualnie Node‑RED. Do prostego sensora, który tylko publikuje dane, wystarczy też Raspberry Pi Zero 2 W, trzeba się jednak liczyć z wolniejszą pracą przy pierwszej konfiguracji.
Starszych modeli lepiej unikać do pracy 24/7 z Wi‑Fi. Jeśli masz do wyboru, bierz wersję z Ethernetem i podłącz ją kablem – oszczędzisz sobie problemów z zasięgiem.
Jaki sensor temperatury najlepiej podłączyć do Raspberry Pi?
Do amatorskiego projektu wystarczą czujniki typu DHT22, BME280 lub DS18B20. DS18B20 dobrze sprawdza się przy kablu kilku metrów (np. pomiar na zewnątrz), a BME280 dodatkowo mierzy wilgotność i ciśnienie, więc przyda się przy bardziej rozbudowanym dashboardzie.
DHT22 jest popularny i tani, ale bywa mniej stabilny niż BME280. Wybór sensora wpływa tylko na fragment kodu w Pythonie – reszta przepływu MQTT pozostaje taka sama.
Czy broker MQTT musi być w chmurze, czy mogę trzymać wszystko na Raspberry Pi?
Nie musi być w chmurze. Cały stack (broker Mosquitto, Node‑RED, dashboard) da się uruchomić lokalnie na Raspberry Pi. Taki wariant jest prostszy na start, ale dostęp do danych będzie wymagał połączenia z Twoją siecią domową (VPN, tunel itp.).
Broker w chmurze (HiveMQ Cloud, EMQX Cloud, własny VPS z Mosquitto) daje „prawdziwe IoT”: możesz otworzyć dashboard z dowolnego miejsca bez kombinowania z przekierowaniem portów i dynamicznym DNS.
Jakie minimalne wymagania sprzętowe i sieciowe muszę spełnić?
Potrzebujesz Raspberry Pi (3B/3B+/4 lub Zero 2 W), dobrej jakości zasilacza 5 V o wydajności 2,5–3 A, karty microSD min. 16 GB (klasa 10, markowa) i stałego dostępu do internetu przez Ethernet lub Wi‑Fi. Do podłączenia sensora wystarczą przewody dupont i ewentualnie mała płytka stykowa.
Przy pracy 24/7 zadbaj o chłodzenie (radiator, mały wentylator przy Pi 4) i unikaj twardego odłączania zasilania – zawsze używaj komendy shutdown. To mocno ogranicza ryzyko uszkodzenia systemu plików na karcie SD.
Jakich umiejętności potrzebuję, żeby w jedno popołudnie zrobić sensor IoT z MQTT?
Wystarczą podstawy Linuxa (logowanie SSH, kilka komend typu cd, ls, sudo apt update), minimalna znajomość Pythona lub gotowość do skopiowania krótkiego skryptu oraz ogólna orientacja w sieci (IP, port, różnica między klientem a serwerem). To bardziej składanie klocków niż pisanie dużego programu od zera.
Nie musisz umieć zaawansowanego programowania obiektowego, administracji serwerami ani projektowania elektroniki. Proste schematy podłączenia DHT22 czy BME280 z opisem pinów w zupełności wystarczą.
Dlaczego do sensora IoT lepiej użyć MQTT niż HTTP?
MQTT jest lekki, działa w modelu publish/subscribe i został zaprojektowany pod urządzenia o ograniczonych zasobach. Raspberry Pi tylko publikuje dane do brokera, a dashboard subskrybuje topic – urządzenie nie musi wiedzieć, gdzie stoi dashboard ani ile jest odbiorców.
Przy HTTP trzeba by utrzymywać serwer na Raspberry Pi lub cyklicznie „pchać” dane do konkretnego endpointu. MQTT upraszcza to do jednego połączenia z brokerem i jest bardziej odporne na chwilowe zaniki sieci.
Czy dam radę zrobić dashboard bez pisania własnej aplikacji webowej?
Tak. Najszybciej zrobisz to w Node‑RED z modułem dashboard – tam „klikasz” przepływ danych: subskrypcja MQTT → widget wykresu → widget wartości. Alternatywnie możesz użyć Grafany lub wbudowanego panelu wybranego brokera w chmurze.
W praktyce często wystarczy jeden wykres i jedna liczba na start, np. temperatura z ostatnich kilku godzin. Z czasem możesz dodać kolejne widżety, historię z bazy danych czy kilka topiców z różnych sensorów.
Bibliografia
  • MQTT Version 3.1.1 Plus Errata 01. OASIS (2019) – Specyfikacja protokołu MQTT, model publish/subscribe, pojęcia klient/broker
  • MQTT Essentials – A Lightweight IoT Protocol. HiveMQ – Wprowadzenie do MQTT, topiki, QoS, zastosowania w IoT
  • Raspberry Pi Documentation – Raspberry Pi OS. Raspberry Pi Foundation – Oficjalne informacje o Raspberry Pi OS, wariant Lite, konfiguracja systemu
  • Node-RED User Guide and Documentation. OpenJS Foundation – Opis Node-RED, tworzenie przepływów, moduł dashboard do wizualizacji danych
  • Eclipse Mosquitto – Documentation. Eclipse Foundation – Opis brokera Mosquitto, narzędzia mosquitto_pub i mosquitto_sub do testów MQTT
Dla ciekawskich – więcej materiałów: