Mqtt - RTL_433 Topic umschreiben um Batteriewechsel leichter abzufangen

Da es mich gestört hat das meine Sensoren die ich über RTL_433 empfange die ID nach Batteriewechsel immer neu setzen und ich dann jedesmal die ID in meinen erstellten MQTT-Sensoren überall ändern musste habe ich mir eine Automation erstellt.

Diese fängt alle RTL_433 Topics ab ändert diese ab und versendet die Payload neu.

Bekannte Sensoren die ich schon angelegt habe werden per Topic rtl_433/Name/ angesprochen

Sensoren die nicht angelegt wurden werden unter rtl_433/unbekannter Sensor/ID abgelegt und lassen sich mit dem MQTT Explorer schnell finden.

Trigger ist die MQTT Nachricht “ rtl_433/rtl433vm/events/#”

danach wird per conditions abgefragt ob die ID schon vorhanden ist

falls ja wird der angepasste Topic mit der Orginal Payload wieder versandt.

falls nein wird ein Topic rtl_433/unbekannter Sensor /id erstellt und damit die Payload versandt.

alias: Mqtt umschreiben
description: ""
triggers:
  - alias: MQTT Nachricht RTL_433
    trigger: mqtt
    options:
      topic: rtl_433/rtl433vm/events/#
    id: "101"
    enabled: true
conditions: []
actions:
  - choose:
      - conditions:
          - alias: Schrank ID 114
            condition: template
            value_template: "{{trigger.payload_json.id == 114}}"
        sequence:
          - action: mqtt.publish
            metadata: {}
            data:
              evaluate_payload: false
              qos: 0
              retain: false
              topic: rtl_433/Schrank/
              payload: "{{ trigger.payload }}"
            enabled: true
        alias: Schrank 114
      - conditions:
          - alias: Aussen ID 149
            condition: template
            value_template: "{{trigger.payload_json.id == 149}}"
        sequence:
          - action: mqtt.publish
            metadata: {}
            data:
              evaluate_payload: false
              qos: 0
              retain: false
              topic: rtl_433/Aussen/
              payload: "{{ trigger.payload }}"
            enabled: true
        alias: Option Aussen 149
      - conditions:
          - alias: Dachboden ID 83
            condition: template
            value_template: "{{trigger.payload_json.id == 83}}"
        sequence:
          - action: mqtt.publish
            metadata: {}
            data:
              evaluate_payload: false
              qos: 0
              retain: false
              topic: rtl_433/Dachboden/
              payload: "{{ trigger.payload }}"
            enabled: true
        alias: Option Dachboden 83
      - conditions:
          - alias: Regenmesser ID 921824
            condition: template
            value_template: "{{trigger.payload_json.id == 921824}}"
        sequence:
          - action: mqtt.publish
            metadata: {}
            data:
              evaluate_payload: false
              qos: 0
              retain: false
              topic: rtl_433/Regenmesser/
              payload: "{{ trigger.payload }}"
            enabled: true
        alias: Option Regenmesser 921824
      - conditions:
          - alias: Gewächshaus ID 187
            condition: template
            value_template: "{{trigger.payload_json.id == 187}}"
        sequence:
          - action: mqtt.publish
            metadata: {}
            data:
              evaluate_payload: false
              qos: 0
              retain: false
              topic: rtl_433/Gewaechshaus/
              payload: "{{ trigger.payload }}"
            enabled: true
        alias: Option Gewächshaus 187
      - conditions:
          - alias: Wohnzimmer ID 96
            condition: template
            value_template: "{{trigger.payload_json.id == 96}}"
        sequence:
          - action: mqtt.publish
            metadata: {}
            data:
              evaluate_payload: false
              qos: 0
              retain: false
              topic: rtl_433/Wohnzimmer/
              payload: "{{ trigger.payload }}"
            enabled: true
        alias: Option Wohnzimmer 96
    default:
      - action: mqtt.publish
        metadata: {}
        data:
          evaluate_payload: false
          qos: 0
          retain: false
          topic: rtl_433/unbekannter Sensor/{{ trigger.payload_json.id }}/
          payload: "{{ trigger.payload }}"
        enabled: true
mode: parallel
max: 10

Mein Sensor wird dann so angelegt :

device habe ich gemacht da mit alle Werte des Sensors in einem Gerät erscheinen.

dazu muss nur der Identifiers gleich sein .

mqtt:
  sensor:
    - name: "Schrank_Luftfeuchtigkeit"
      unique_id: Schrank_hum
      device_class: humidity
      state_class: measurement
      state_topic: "rtl_433/Schrank/"
      value_template: "{{ value_json.humidity }}"
      unit_of_measurement: "%"
      device:
        identifiers: 12345
        name: Schrankthermometer
        manufacturer: Bresser
        model: Nexus-TH
        
    - name: "Schrank_Temperatur"
      unique_id: Schrank_Temp
      device_class: temperature
      state_class: measurement
      state_topic: "rtl_433/Schrank/"
      value_template: "{{ value_json.temperature_C }}"
      unit_of_measurement: "°C"
      device:
        identifiers: 12345
        name: Schrankthermometer
        
    - name: "Schrank_batterie"
      unique_id: Schrank_batterie
      state_topic: "rtl_433/Schrank/"
      value_template: > 
        {% if value_json.battery_ok == 1 %} 
          Okay
        {% else %} 
          wechseln 
        {% endif %}

Sollte sich die ID des Sensors nach dem Batteriewechsel ändern muss ich nur die ID bei der Condition Schrank anpassen und alles läuft wieder.

1 „Gefällt mir“

Ein toller Beitrag, danke!

Ich spiele auch mit RTL-HAOS die letzten Tage umher und erst heute wurde ich mir des Problems beim Batteriewechsel eines Funkthermometers bewußt. Statistik “weg”, Template-Sensoren und Automatisation, die sich auf den Entity-Namen beziehen gehen nicht mehr und letztlich zeichnet der Rekorder wieder munter auf was ich vorher per exclude ausgeschlossen hatte … und sogar mehr weil vorher deaktiviere Geräte-Entities beim neuen Gerät wieder aktiviert sind. Wie ärgerlich das Ganze.

Ich habe noch folgende Baustelle:

  • Ich lasse alle Renault-Funksensoren durch, will aber eigentlich nur 2.
  • Alle neuen Renaults deaktiviere ich noch regelmäßig (in der Annahme, daß dann wirklich nur die neuen Renault-Funksignale ankommen und ich immer weniger deaktivieren muß)
  • Nach 3 Wochen RTL-HAOS Erfahrung kommen dennoch so viele Renaults hinzu (wir haben 4 in Nachbarschaft), daß ich an meiner vorigen Annahme zweifele. Soviel Lieferantenwagen können das doch nicht sein? Ggf. senden alte Renaults auch nur mit neuer ID wie im Falle des Batteriewechsels. Andererseits, die beiden gewollten Renaults senden verläßlich auch nachdem sie unterwegs waren.

Ich stehe sowieso kurz vor dem Wechsel von Black- zu Whitelist. Ggf. erledigt sich das Thema. Hast Du hier Erfahrungen?

Haben deine Renaults eindeutige ID ?

Dann reicht es doch nur die beiden umzuschreiben und die anderen in unbekannt laufen zu lassen.

Ich habe überlesen das du das RTL Haos nutzt.

Da hilft dir meine Automation ja nicht wirklich da dort die Sensoren automatisch angelegt werden, während ich mit der Orginal rtl_sdr arbeite die in einer vm läuft.

Dadurch kann ich meine Sensoren selber anlegen wie ich will

Ein eindeutiger Vorteil :+1:

Und besser als die manuellen Schritte, die ich mir gerade als Erinnerung aufgeschrieben habe.
Ich kopiere sie hier rein falls jemand sich dem Funkthema erstmals widmen will und die Erleichterung Deines Ansatzes bzw. Workarounds besser sieht. Sag Bescheid wenn Du das als Zuschütten siehst, dann lösche ich den Beitrag morgen wieder.

Manuelle Schritte nach Batteriewechsel

  1. Namen der alten Entities notieren, z.B. “funkthermometer_u” für
  • sensor.funkthermometer_u_humidity
  • sensor.funkthermometer_u_temperature
  • binary_sensor.funkthermometer_u_battery_low
  • sensor.funkthermometer_u_channel
  • sensor.funkthermometer_u_signal_rssi
  1. Altes Gerät in HA löschen (Statistik bleibt vorerst erhalten)
  2. Neues Gerät umbenennen in Namen vom alten, z.B. funkthermometer_u
  3. Neuem Gerät gleichen Metadaten (Bereich, Tags) geben wie dem alten
  4. Unnötige neue Geräte-Entities deaktivieren
  5. Oben rechts “Entities neu erstellen” (Damit werden alle Entities mit neuem (altem) Namen erstellt)
  6. Jeden neuen Sensor überprüfen ob er auch Statistik vor dem Batteriewechsel anzeigt. In diesem Fall funktionieren auch wieder Automatisationen, Sensoren und Recorder-Excludes.
  7. In der Zeit zwichen Batterie-Einsetzen und Umbennen wurde Statistik mit den neuen Entity-Namen geschrieben. Die kann man unter Entwicklerwerkzeuge → Statistik → Pobleme beheben löschen. Dieser Zeitraum fehlt natürlich in der alten/neuen Statistik.
1 „Gefällt mir“