RTL 433 - problemy z instalacją i konfiguracją

maciej1 · 3 Wrzesień 2024 16:11

Ja tylko napiszę, że dodatek w wersji 0.5.2 (ten standardowy, nie next) działa mi niezawodnie. W ogóle nigdy nie miałem z nim żadnych problemów, ale kilka wersji pominąłem (chyba wcześniej siedziałem na 0.4). Mam instalację na Proxmox, gdzie niebieski dongle RTL USB jest przekazany jako Device ID. Konfigurację mam w domyślnym pliku “rtl_433.conf.template”:

output mqtt://core-mosquitto:1883,user=addons,pass=bardzo_dlugie_haslo,retain=true
protocol -*
protocol 30
convert si
output kv
output json

Mam małe pytanie na marginesie: skąd dodatek zna użytkownika i hasło “addons”? Czy ten użytkownik wygenerował się podczas instalacji mosquitto i jest w jakiś sposób udostępniany innym dodatkom?

Lambada700 · 4 Wrzesień 2024 09:51

Ok, działa wszystko dobrze ponownie. Zadziałało po tym jak w dodatku rtl_433 next zmieniłem linijkę output na tą która jest w dokumentacji tego dodatku. Wcześniej używałem zwykłego rtl_433 więc brakowało fragmentu po devices=rtl_433, czyli: /9b13b3f4-rtl433/devices[/type][/model][/subtype][/channel][/id],events=rtl_433/9b13b3f4-rtl433/events,states=rtl_433/9b13b3f4-rtl433/states
Zwykły dodatek rtl_433 nie odbiera danych ze stacji, robi to tylko wersja next. Natomiast nie ma znaczenia czy używam Auto Discovery w wersji zwykłej czy next, dane z obu są przesyłane do MQTT

szopen · 4 Wrzesień 2024 10:00

Dodatek Auto Discovery nie bierze udziału w odbiorze telegramów, więc po powstaniu odpowiednich sensorów/encji można go wyłączyć…
On tylko jednorazowo publikuje odpowiednie tematy w brokerze MQTT, więc jeśli już coś raz zostało dodane, to nie wymaga dodawania ponownie, no chyba że pousuwamy te tematy, ale jeśli będzie stale włączony, to potrafią się dodawać “urządzenia-duchy” powstające z błędnie zdekodowanych telegramów (UWAGA niektóre stacje po wymianie baterii zmieniają swój identyfikator i w zasadzie tylko w takim wypadku potrzeba go uruchomić jeszcze raz, no ewentualnie gdy chcemy automatycznie dodać jakieś inne urządzenia które nasłuchał rtl_433).

angler · 4 Wrzesień 2024 10:07

To, że dane są przesyłane do brokera MQTT nie oznacza, muszą powstać encje w HA. Za ich tworzenie odpowiada mechanizm MQTT Discovery. Jeśli on nie zadziała, to encje nie zostaną automatycznie utworzone.

Lambada700 · 13 Listopad 2024 12:15

W logach HA pojawia się taki o to błąd:

Rejestrator: homeassistant.components.mqtt.models
Źródło: components/mqtt/models.py:366
integracja: MQTT (dokumentacja, Problemy)
Pierwsze zdarzenie: 13:07:30 (7 zdarzenia)
Ostatnio zalogowany: 13:09:10

Exception raised while updating state of sensor.bresser_7in1_43922_timestamp, topic: ‘rtl_433/9b13b3f4-rtl433/devices/Bresser-7in1/43922/time’ with payload: b’2024-11-13 13:07:55.320149’
Exception raised while updating state of sensor.bresser_7in1_43922_timestamp, topic: ‘rtl_433/9b13b3f4-rtl433/devices/Bresser-7in1/43922/time’ with payload: b’2024-11-13 13:08:07.820195’
Exception raised while updating state of sensor.bresser_7in1_43922_timestamp, topic: ‘rtl_433/9b13b3f4-rtl433/devices/Bresser-7in1/43922/time’ with payload: b’2024-11-13 13:08:32.827954’
Exception raised while updating state of sensor.bresser_7in1_43922_timestamp, topic: ‘rtl_433/9b13b3f4-rtl433/devices/Bresser-7in1/43922/time’ with payload: b’2024-11-13 13:08:57.836469’
Exception raised while updating state of sensor.bresser_7in1_43922_timestamp, topic: ‘rtl_433/9b13b3f4-rtl433/devices/Bresser-7in1/43922/time’ with payload: b’2024-11-13 13:09:10.331584’
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/components/mqtt/models.py”, line 366, in process_write_state_requests
entity.async_write_ha_state()
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 1007, in async_write_ha_state
self._async_write_ha_state()
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 1132, in _async_write_ha_state
self.__async_calculate_state()
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 1069, in __async_calculate_state
state = self._stringify_state(available)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 1013, in _stringify_state
if (state := self.state) is None:
^^^^^^^^^^
File “/usr/src/homeassistant/homeassistant/components/sensor/init.py”, line 597, in state
raise ValueError(
ValueError: Invalid datetime: sensor.bresser_7in1_43922_timestamp provides state ‘2024-11-13 13:07:30.313019’, which is missing timezone information

szopen · 13 Listopad 2024 12:36

@Lambada700
no i?

jeśli zamierzasz wstawiać gołe logi bez słowa komentarza, to zrób to w issue (ale i tak chyba autorzy pogonią Cię z takim pseudo-zgłoszeniem)

Lambada700 · 13 Listopad 2024 12:48

jakiś pomysł co może być przyczyną i jak go zlikwidować?

szopen · 13 Listopad 2024 12:53

Działało 2 miesiące i “nagle” przestało?
to się zastanów co zaktualizowałeś

angler · 11 Listopad 2025 22:43

To jest kontynuacja dla opisu rozwiązania problemu z innego tematu:

Co można z takim problemem zrobić?
Wyłączamy dodatek rtl_433 MQTT Auto Discovery odpowiedzialny za uruchomienie skryptu tworzącego urządzenie i encje sensorów w HA przez mechanizm MQTT Auto Discovery i przechodzimy na ręczne, samodzielne stworzenie tych encji w HA, poprzez własne zapisy w YAML.
Ale na początek musimy dokonać małej zmiany w pliku konfiguracji dodatku rtl_433 lub rtl_433 (next), zależnie kto co używa (dla obu AddOn to ten sam plik w tym samym katalogu). Kto nie tworzył tego pliku i działa na ustawieniach domyślnych może dowie się czegoś nowego.
W katalog rtl_433 tworzymy plik rtl_433.conf.template lub edytujemy jeśli już tam go mamy.

W tym pliku określamy podstawowe parametry, które determinują sposób działania oprogramowania rtl_433. Mój plik wygląda tak:

#output mqtt://${host}:${port},user=${username},pass=${password},retain=${retain},devices=rtl_433/9b13b3f4-rtl433/devices[/type][/model][/subtype][/channel][/id],events=rtl_433/9b13b3f4-rtl433/events,states=rtl_433/9b13b3f4-rtl433/states
output mqtt://${host}:${port},user=${username},pass=${password},retain=${retain},devices=rtl_433[/model][/channel]
report_meta time:iso:usec:tz
output kv

protocol 20
protocol 214
protocol 217

frequency   433.92M
convert     si
report_meta level

Pierwszy wiersz, który za komentowałem pochodził z dokumentacji dodatku rtl_433 (next)

Ten wiersz determinuje jak będzie wyglądał topic w mqtt wiadomości publikowanej przez rtl_433 (next):

output mqtt://${host}:${port},user=${username},pass=${password},retain=${retain},devices=rtl_433/9b13b3f4-rtl433/devices[/type][/model][/subtype][/channel][/id],events=rtl_433/9b13b3f4-rtl433/events,states=rtl_433/9b13b3f4-rtl433/states

A dokładnie to co znajduje się po devices=
I tu wkroczył ze swoim pomysłem @Mariusz_Woszczyński:

Na innym temacie

Kurde, skoro ten zapis definiuje topic:

devices=rtl_433/...]

to czy nie można ograniczyć się do nazwy stacji, ewentualnie kanału, który jest chyba stały dla danej stacji?
devices=rtl_433[/model][/channel]
Wtedy nie trzeba by było bawić się w zmiany po wymianie baterii i zmianie ID??

Tym sposobem znalazł rozwiązanie, które działa. Zmieniamy zapis dla mqtt w pliku konfiguracji rtl_433 na:

output mqtt://${host}:${port},user=${username},pass=${password},retain=${retain},devices=rtl_433[/model][/channel]

Teraz już do brokera płynie taki pakiet wiadomości, gdzie nie ma znaczenia (jak się okazuje) zmienne ID.

Na bazie tego możemy zbudować własne encje w HA, które pozostaną z nami dłużej, wraz ze statystyką odczytów.

angler · 11 Listopad 2025 22:48

Dokładam jeszcze garść kodu swojej konfiguracji w HA, tworzące sensory mojej stacji EMOS, po zmianie topic w rtl_433.

mqtt:
  sensor:
    - name: "Stacja temperatura"
      state_topic: "rtl_433/EMOS-E6016/1/temperature_C"
      value_template: '{{ value | round(2) }}'
      unit_of_measurement: "°C"
      unique_id: rtl_433_emos_temperature_C
      
    - name: "Stacja wilgotność"
      state_topic: "rtl_433/EMOS-E6016/1/humidity"
      value_template: '{{ value }}'
      unit_of_measurement: "%"
      icon: mdi:water-percent
      unique_id: rtl_433_emos_humidity
       
    - name: "Prędkość wiatru"
      state_topic: "rtl_433/EMOS-E6016/1/wind_avg_m_s"
      value_template: '{{ value }}' 
      unit_of_measurement: "m/s"
      icon: mdi:wind-turbine
      unique_id: rtl_433_emos_wind_avg_m_s
      
    - name: "Kierunek wiatru"
      state_topic: "rtl_433/EMOS-E6016/1/wind_dir_deg"
      value_template: '{{ value }}'
      unit_of_measurement: "°"
      icon: mdi:compass-rose
      unique_id: rtl_433_emos_wind_dir_deg

Mariusz_Woszczyński · 12 Listopad 2025 08:18

Idąc dalej zastanawiam się czy można to ogarnąć przy Auto Discovery, zmieniając zapis:

output mqtt://${host}:${port},user=${username},pass=${password},retain=${retain},devices=rtl_433/9b13b3f4-rtl433/devices[/type][/model][/subtype][/channel][/id],events=rtl_433/9b13b3f4-rtl433/events,states=rtl_433/9b13b3f4-rtl433/states

na:

output mqtt://${host}:${port},user=${username},pass=${password},retain=${retain},devices=rtl_433/9b13b3f4-rtl433/devices[/type][/model][/subtype][/channel],events=rtl_433/9b13b3f4-rtl433/events,states=rtl_433/9b13b3f4-rtl433/states

czyli de facto wywalając ID z output.
Zmieniłem, zresetowałem rtl_433 i Auio Discovery działa, utworzył nowe urządzenie, ale niestety z ID w nazwie (mimo usunięcia z output)… Skąd on to wziął?

angler · 12 Listopad 2025 08:36

Zapewne ze skryptu, który to robi. Należałoby go przeanalizować…, ale ja nie czuję się zupełnie kompetentny w tej materii.

Mariusz_Woszczyński · 12 Listopad 2025 08:41

me 2.
Ale kminiąc dalej, pomimo skryptu, w którym ID jest - skoro mam w rtl_433 output do zdefiniowania i tam mu wywalam ID, to Auto Discovery tego ID nie powinno dostawać.
Jedyna opcja, że sobie pamięta ostatni i taki przyjmuje…

angler · 12 Listopad 2025 08:47

To najlepiej sprawdzić w MQTT Explorer.

P.S.
To chyba to miejsce gdzie powstaje nazwa:

EDIT:
To ID jest publikowane w ładunku states wraz z pozostałymi odczytami.

Mariusz_Woszczyński · 12 Listopad 2025 08:51

tak, też to widziałem. Zresetowałem stacje, ID się zmieniło i nazwa w Auto Discovery też. Więc ewidentnie dostaje.

edit:
Niestety bez zmian w samym skrypcie nie da rady tego obejść. Moje testy z usuwaniem ID z output powierdzają tyle, że i tak za każdym razem tworzy się nowe urządzenie w mosquitto, ale brakuje danych (same stany nieznane), więc to ID musi być.

george1255 · 6 Luty 2026 05:05

Obecnie używam dongla sdr, dodatek Rtl_433. Ja postawiony na miniPC jako haOS.
wszystko działało dość sprawnie tylko mam go w kuchni nad lodówką, a widomo że czasami ktoś czymś dotknie antenki i ja przestawi. No i niema odczytów. Stoję często po godzinie i przestawiam ją co milimetry aby złapało odczyt. A i tak jest często lipa.

Mój config

output        log
verbose       4


device        0
sample_rate   250000
frequency     868.300M
gain          30
report_meta   level
report_meta   noise
report_meta   stats
report_meta   time:iso
report_meta   protocol

pulse_detect  autolevel
pulse_detect  magest


protocol      119
protocol      172
protocol      173


output        json
output        MQTT_DANE
convert       si

angler · 6 Luty 2026 05:14

A prosiłem…

george1255 · 6 Luty 2026 06:11

Na specjalne życzenie @angler temat ciągnę tutaj

Obecnie używam dongla sdr, dodatek Rtl_433. Ja postawiony na miniPC jako haOS.
wszystko działało dość sprawnie tylko mam go w kuchni nad lodówką, a widomo że czasami ktoś czymś dotknie antenki i ja przestawi. No i niema odczytów. Stoję często po godzinie i przestawiam ją co milimetry aby złapało odczyt. A i tak jest często lipa.

Mój config

output        log
verbose       4


device        0
sample_rate   250000
frequency     868.300M
gain          30
report_meta   level
report_meta   noise
report_meta   stats
report_meta   time:iso
report_meta   protocol

pulse_detect  autolevel
pulse_detect  magest


protocol      119
protocol      172
protocol      173


output        json
output        MQTT_DANE
convert       si

Odczyty powinny być co 12s a są co godzinę, albo dłużej

W logach RTL_433 mam tylko

[rtl_433] Auto Level: Current noise level -38.6 dB, estimated noise -38.5 dB
[rtl_433] Auto Level: Current noise level -38.5 dB, estimated noise -38.5 dB
’’’

szopen · 6 Luty 2026 12:58

OFF TOPIC

To nie jest żadne czyjeś “widzi mi się”, tylko zasady umożliwiające utrzymanie jako-takiego porządku na forum.

a teraz do sedna

Czyli masz albo intensywne zakłócenia, albo krytycznie niski poziom sygnału ze stacji (ewentualnie i to, i to).

Generalnie kuchnia z dużym AGD, które tłumi sygnał i które często jest źródłem zakłóceń, to jedno z gorszych miejsc na instalację sprzętu do nasłuchu radiowego.
Musisz rozważyć 2 rozwiązania (i 3. jako opcja gdyby kombo 2 pierwszych nie pomogło)

przeniesienie instalacji HA (wraz donglem) w takie miejsce w domu by było wolne od zakłóceń i od tej strony domu, gdzie masz widok na stację pogodową (lub miałbyś go gdyby ściana nie zasłaniała)
użyć przedłużacza USB i czegoś co umożliwi stabilny montaż dongla
antena zewnętrzna na pasmo 868MHz (montaż po stronie stacji pogodowej)

Spotykałem się już z pomysłami montażu stacji pogodowych na dachu (to za to jedno z gorszych miejsc z powodu zafałszowania wskazań, ale jeśli to właścicielowi nie przeszkadza… byleby nie wysyłać danych pogodowych do serwisów online), gdzie odbiornik jest centralnie poniżej stacji - wtedy zwykle pomaga zmiana polaryzacji anteny z pionowej na poziomą…

Gdy odbierzesz poprawny sygnał ustal z którego dekodera korzysta (masz 3 różne w konfiguracji) - moim zdaniem powinieneś używać tylko jeden z nich (ustal który, prawdopodobnie 119 lub 172) to jest wprawdzie tylko optymalizacja dekodowania (ale czasem są kombinacje, które utrudniają właściwe dekodowanie sygnału, nie sądzę, że to ten przypadek, skoro twierdzisz, że w optymalnych warunkach masz telegramy co 12s, mimo to sugeruję wybrać tylko właściwe dekodery, tj. raczej tylko jeden z nich)

    [119]  Bresser Weather Center 5-in-1
…
    [172]  Bresser Weather Center 6-in-1, 7-in-1 indoor, soil, new 5-in-1, 3-in-1 wind gauge, Froggit WH6000, Ventus C8488A
    [173]  Bresser Weather Center 7-in-1, Air Quality PM2.5/PM10 7009970, CO2 7009977, HCHO/VOC 7009978 sensors

I jeszcze jedno - jeśli odbiór się pogorszył przy ostatnich mrozach, to należy wymienić ogniwa zasilające w stacji (możesz poczekać na ocieplenie i zobaczyć czy się zregenerują po wzroście temperatury), przy wymianie sugeruję ogniwa litowe, bo są znacznie bardziej odporne na mróz od zwykłych alkalicznych - u nas łatwe do kupienia to Varta, ale producent nie jest ważny tylko rodzaj chemii.

PS posty wyżej zostały przeniesione tutaj, by nie zachęcały innych do odjeżdżania tak daleko od tematu…

szopen · 7 Luty 2026 15:46

Post został podzielony na nowy temat: BresserWeatherSensorReceiver