RTL 433 - problemy z instalacją i konfiguracją

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?

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 :slight_smile:

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).

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.

1 polubienie

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

@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)

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

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

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:

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.

2 polubienia

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
2 polubienia

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ął?

1 polubienie

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

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…

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.

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ć.