O co chodzi z RTL-SDR?

RTL-SDR to odbiornik radiowy USB (pierwotnie tunery do telewizji cyfrowej DVB-T), który dzięki społecznościowym sterownikom da się przerobić na uniwersalny odbiornik radiowy szerokiego pasma. W praktyce: jeden mały dongiel potrafi „słuchać” niemal wszystkiego, co nadaje w zakresie kilkudziesięciu MHz do ponad 1 GHz — w tym popularne pasma ISM 433 MHz i 868 MHz, na których pracuje mnóstwo czujników, stacji pogodowych, pilotów czy liczników mediów.

Do dekodowania tych transmisji służy otwarte narzędzie rtl_433 — program, który rozpoznaje kilkadziesiąt popularnych protokołów urządzeń i zamienia surowy sygnał radiowy na czytelny JSON.

Konfiguracja: Docker + MQTT

Całość postawiłem w Dockerze na swoim domowym serwerze:

services:
  rtl_433:
    image: bademux/rtl_433tomqtt:latest
    container_name: rtl_433
    restart: unless-stopped
    volumes:
      - ./rtl_433.conf:/etc/rtl_433/rtl_433.conf:ro
      - /etc/localtime:/etc/localtime:ro
    devices:
      - /dev/bus/usb:/dev/bus/usb
    environment:
      - TZ=Europe/Warsaw

Konfigurację samego rtl_433 trzymam w prostym pliku tekstowym — częstotliwość, wzmocnienie i adres brokera MQTT:

output mqtt://192.168.0.125:1883,user=xxx,pass=xxx,retain=0,events=rtl_433[/model][/id]
device 0
frequency 868.3M
gain 0
report_meta time:local

Dane z każdego wykrytego urządzenia trafiają na osobny temat MQTT (np. rtl_433/Bresser-7in1/44028), co ułatwia dalszą obróbkę. Aplikacja ma szablony sygnałów dla prawie 200 urządzeń. Moje Garni INT 5 jest rebrandem jednego z obsługiwanych nadajników Bresser – 7in1

Pułapka, na którą warto uważać: RTL-SDR Blog V4

Tu natrafiłem na najciekawszy problem całego projektu. Mój dongiel to nowsza wersja RTL-SDR Blog V4_, która wymaga specjalnego, poprawionego sterownika – standardowa biblioteka librtlsdr dostępna w repozytoriach Ubuntu go nie obsługuje w pełni. Efekt? Odbiornik „widział” sygnał (potwierdziłem to wizualnie w programie SDR++ na Macu — wyraźna smuga w waterfallu co ~12 sekund, dokładnie zgodnie z cyklem transmisji stacji), ale rtl_433 uparcie nic nie dekodował.

Rozwiązanie: zbudowanie sterownika ze źródeł producenta i podmienienie systemowej biblioteki:

git clone https://github.com/rtlsdrblog/rtl-sdr-blog
cd rtl-sdr-blog && mkdir build && cd build
cmake ../ -DINSTALL_UDEV_RULES=ON
make && sudo make install
sudo cp ../rtl-sdr.rules /etc/udev/rules.d/
sudo ldconfig

Po tej zmianie dane popłynęły od razu — pierwszy poprawny odczyt: temperatura, wilgotność, wiatr, opady, UV, wszystko z poprawną sumą kontrolną CRC.

Wniosek: jeśli masz nowszy dongiel RTL-SDR Blog V4, a program „widzi” sygnał, ale nic nie dekoduje — sprawdź wersję sterownika, zanim zaczniesz podejrzewać config czy antenę.

Przez to, że kompilowanie sterownika i robienie swojego obrazu nie było w moim planie to zostawiłem zainstalowany rtl_433 bezpośrednio w systemie. Kiedyś będzie czas to faktycznie przygotuję obraz pod odpowiedni kontener. Możliwe jest też, że ktoś to w międzyczasie zrobi

Przygotowanie pliku rtl_433.service do automatycznego uruchamiania aplikacji przy starcie systemu:

[Unit]
Description=rtl_433 - RTL-SDR generic RF receiver and decoder
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=linux_user
ExecStart=/usr/bin/rtl_433 -c /iot/rtl433/rtl_433.conf
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Uruchomienie serwisu:

sudo cp rtl_433.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable rtl_433
sudo systemctl start rtl_433

Integracja z Home Assistant

Zamiast automatycznego discovery, wybrałem prostsze podejście — zwykłe sensory MQTT z szablonami wyciągającymi konkretne wartości z JSON-a:

mqtt:
  sensor:
    - name: "Balkon Temperatura"
      state_topic: "rtl_433/Bresser-7in1/44028"
      value_template: "{{ value_json.temperature_C }}"
      unit_of_measurement: "°C"
      device_class: temperature
      state_class: measurement

Analogicznie dla wilgotności, wiatru, opadów i nasłonecznienia. Dodatkowo, template sensor zamienia kierunek wiatru ze stopni na czytelną różę wiatrów (N, NE, E…), żeby dashboard był bardziej czytelny na pierwszy rzut oka.

Stylizacja prezentacji danych

Tu dwie rzeczy do usprawnienia. Kierunek wiatru odbierany ze stacji jest w stopniach. Nie bardzo wiadomo w którą stronę wieje wiatr 252° Trzeba to sobie ograć template sensorem:

  - name: "Garni Kierunek Wiatru Róża"
    unique_id: balkon_bresser_wind_dir_rose
    state: >
      {% set deg = states('sensor.balkon_garni_kierunek_wiatru') | float(0) %}
      {% set kierunki = ['N','NNE','NE','ENE','E','ESE','SE','SSE',
                          'S','SSW','SW','WSW','W','WNW','NW','NNW'] %}
      {{ kierunki[ ((deg + 11.25) / 22.5) | int % 16 ] }}

W przyszłości chciałbym zrobić różę wiatru z obracającą się igłą i miniaturą mieszkania. Dzięki czemu będzie można od razu wyobrazić sobie, z której strony wieje wiatr

Drugi temat do dopieszczenia to opady. Miernik opadów nalicza narastająco opady. Nie zeruje ich co dobę, tydzień czy miesiąc. Tu Home Assistant przychodzi z pomocą i swoimi utility_meter:

utility_meter:
  balkon_opady_dzienne:
    source: sensor.balkon_garni_opady
    unique_id: balkon_opady_dzienne
    cycle: daily
  balkon_opady_miesieczne:
    source: sensor.balkon_garni_opady
    unique_id: balkon_opady_miesieczne
    cycle: monthly

W ten sposób mamy kolejne dwie encje, które agregują dane dzienne i miesięczne. Ułatwia to prezentację danych na dashboardach.

Kwestia zasięgu

Ostatnia przeszkoda była czysto fizyczna: dongiel stał w korytarzu, a stacja na balkonie — kilka metrów i ściana wystarczyły, żeby sygnał zniknął. Zamiast stawiać osobne urządzenie (miałem pod ręką wolne Raspberry Pi Zero, ale wolałem zostać przy jednym punkcie zarządzania), rozwiązaniem okazało się po prostu wydłużenie kabla USB w stronę balkonu i… zmiana wzmocnienia z ustawionego na sztywno na tryb automatyczny. Czasem najprostsze rozwiązanie leży najbliżej.

Co dalej

Ten sam dongiel, ten sam pipeline (rtl_433 → MQTT → Home Assistant) obsłuży w praktyce dowolne urządzenie nadające w pasmach ISM — kolejne czujniki, piloty, a nawet niektóre liczniki mediów (choć te bywają szyfrowane, o czym może przy okazji innego artykułu). Do obsługi 433 MHz osobno planuję jeszcze przerobiony Sonoff RF Bridge z firmware ESPHome — ale to już temat na kolejny wpis.

Masz w domu jakieś radiowe urządzenie, które chciałbyś wciągnąć do swojego Home Assistant? Napisz w komentarzu — może da się je podsłuchać tą samą metodą.

Budowa i wygląd mROW-02

Na początek sesja zdjęciowa i porównanie modułu z innymi dostępnymi na rynku. Jak widać nowa obudowa Zamel’a jest bardzo zgrabna i może walczyć o podium w kategorii rozmiar :). Otrzymany egzemplarz to wersja testowa rozesłana do forumowiczów w związku z tym nadruk nie jest jeszcze dopieszczony. Sama obudowa ze względu na zupełnie nową formę jest jeszcze nie do końca spasowana, przez co wydaje się delikatna. Kruchość konstrukcji potwierdzają wpisy kolegów na forum supli, którzy uszkadzają moduł przy próbie upakowania go z przewodami w puszcze.

mROW-02 podłączenie do HomeAssistant przez lokalnego brokera MQTT

Moduł ten tak samo zresztą jak Supla MEW-01 podłączony został do systemu automatyki za pośrednictwem protokołu MQTT. Przy pomocy tego protokołu podłączam wszystkie moduły jakie mają tą możliwość – urządzenia supla i wszystkie moje DIY na ESP. Dzięki czemu minimalizuję ilość niezbędnych integracji do absolutnego minimum.

mROW-02 jako sterownik fontanny

W mojej instalacji sterownik ten został wykorzystany do obsługi pompki fontanny, jej podświetlenia i pozostałego oświetlenia dekoracyjnego na balkonie. Oświetlenie dekoracyjne włącza się automatycznie po zmroku fontanna uruchamiana ręcznie.

Plan docelowy jest taki, żeby fontanna też była automatycznie uruchamiana przy pomocy czujnika ruchu po wyjściu na balkon. Niestety muszę najpierw zrobić system kontroli poziomu wody w fontannie aby uniknąć sytuacji, w której odpali się silnik bez wody w fontannie. Czujnik ruchu miałby też sterować lampami przy drzwiach sterowanymi przez inny moduł od Supla DIW-01. Lampy będą się zapalały po zmroku na 10% mocy a po wykryciu ruchu rozjaśniane do 100% mocy.

Instalacja

Miejsce na MEW w rozdzielnicy jest, ale że wymaga delikatnych przeróbek. Postanowiłem miernik podpiąć w trybie tymczasowym :P. Rozdzielnicę przebuduję w weekend. Musze pozbyć się dzwonka i przesunąć praktycznie wszystkie moduły.

Konfiguracja pod MQTT

Połączenie MEW-01 do aplikacji supla zajęło dosłownie chwile. Praktycznie nic nie trzeba było robić. Aplikacja po kliknięciu „dodaj urządzenie” wprowadziła ustawienie lokalnej sieci wifi do urządzenia i zrobiła co trzeba. 3 minutki i w aplikacji widziałem urządzenie i jego wskazania.

Ale jak wiadomo ja nie chcę korzystać z aplikacji a z lokalnego brokera MQTT

Aby tego dokonać trzeba na module przytrzymać przycisk config przez około 5 sekund aż dioda zacznie mrugać. Z pośród dostępnych sieci LAN pojawi się sieć stworzona przez MEW. Musimy się z nią połączyć dowolnym urządzeniem. Następnie uruchamiamy przeglądarkę i wpisujemy adres : 192.168.4.1 gdzie znajduje się panel konfiguracyjny modułu. Zmieniamy protokół z supla na MQTT i dajemy dane naszego brokera. Restart i już. MEW-01 wysyła wszystkie dane do mosquitto ( w moim przypadku )

Monitor energii MEW-01 w Home Assistant

Urządzenie bez najmniejszego problemu zostało wykryte razem ze swoimi wszystkimi encjami.

Kilka chwil i mamy gotowy piękny dashboard ze wskazaniami z naszego licznika Muszę jeszcze poza rozbitymi na fazy wskazaniami porobić sumaryczne wskaźniki. Plan na najbliższe dni. Muszę spisać stan licznika, aby mieć możliwość wyświetlania jego stanu po dodaniu wartości, które mewa od tej chwili będzie mierzyć. Będę mógł zweryfikować poprawność pomiaru z MEW-01 i licznika operatora.

Error :/

Niestety nie wszystko działa tak jakbyśmy tego chcieli. Raz na 10 minut MEW-01 gubi połączenie z MQTT i encje stają się niedostępne. Po chwili moduł łączy się ponownie i wszystko działa jak należy. Najgorsze jest to, że w czasie resetu MEW całe MQTT staje się niedostępne i nie działają pozostałe urządzenia działające na tym protokole.

Po konsultacji z supportem supla dostałem informację aby zaktualizować mosquitto do najnowszej wersji. Do tej pory działałem na 1.5.7 bo taka była najwyższa wersja dostępna w repozytorium debiana pod raspberry. Po krótkim boju mam aktualnie najwyższą dostępną wersję 2.0.11. Niestety nie rozwiązało to mojego problemu.

Kolejnym tropem do zbadania był fakt, że mew wysyła bardzo dużo danych – dużo i często. Trzeba było zrobić szybki remanent limitów w konfiguracji mosquitto. Tutaj też nie znalazłem nic do poprawy. Limity są domyślnie zdjęte, więc nie możliwe, żeby coś było w tym temacie źle skonfigurowane.

W dniu dzisiejszym ma pojawić się aktualizacja, dzięki której będzie możliwe ustawienie opóźnienia między odczytami wartości z miernika. Mam nadzieję, że to ustabilizuje pracę serwera MQTT i wszystkie problemy z tym związane. Dodatkowo mają pojawić się dodatkowe encje ze wskaźnikami ułatwiającymi diagnostykę jak np. siła sygnału wifi.

edit:
Problem został rozwiązany. Zrywanie połączenia nie było winą samego modułu a mojego routera. Posiadam FunBox6 od orange. Nie wiem czemu ale nie chcą moduły supla na nim pracować. Podłączenie MEW-01 przez osobny AP rozwiązało problem z przerwami w dostawie informacji do HA. Wszystko pięknie się wyświetla mogę teraz policzyć ile kawek dziennie piję Poniżej przedstawiam najbardziej aktualny widok mojej karty energetycznej:

Podsumowanie

Montaż i instalacja tego urządzenia jest bajecznie prosta. Nikt nie powinien mieć z nim większego problemu. Pamiętajmy jednak, że montaż najlepiej zlecić komuś kto ma do tego uprawnienia. Gdyby nie drobna niedogodność z zapychaniem MQTT nie miałbym się do czego przyczepić. Mam nadzieję, że zostanie to na dniach poprawione i zostanie tylko obserwować wskazania i optymalizować zużycie energii. Obserwowanie wskazań mewy na wykresach to czysta przyjemność. W przyszłości planuję pobawić się trochę z panelami słonecznymi także będzie okazja potestować MEWkę w dwóch kierunkach

Procedura aktualizacji supla:

• Podłącz moduł do cloud.supla.org – moduł powinien być widoczny i aktywny w aplikacji
• Przełącz moduł ponownie w tryb konfiguracji przytrzymując przycisk CONFIG przez min 5sek. Tak długo aż dioda zacznie szybko migać
• Moduł zacznie rozgłaszać swoją sieć. Połącz się z tą siecią WiFi rozpoczynającą się od nazwy „ZAMEL-…”
• Otwórz stronę konfiguratora dostępną po podłączeniu się do hotspota pod adresem: http://192.168.4.1
• Ustaw „Firmware update” na „YES” i jeżeli jeszcze tego nie zrobiłeś w poprzednim kroku zmień protokół z MQTT na supla i podaj odpowiednie dane dostępowe
• Zapisz i Uruchom ponownie moduł np. poprzez krótkie naciśnięcie przycisku CONFIG. Od pewnej wersji oprogramowania mamy już dostępny przycisk „Save & Restart”, który niewątpliwe sprawę ułatwia.