Setting up an MQTT sensor using a wildcard in the topic

Configuration
1

I’m trying to set up an MQTT sensor but using a wildcard for the state topic. If I set the state topic without a wildcard ( state_topic: "rtl_433/Maverick-ET73x/13010/temperature_1_C") I can get the sensor to work.
If I set the state topic using a wildcard ( state_topic: "rtl_433/Maverick-ET73x/+/temperature_1_C") then the sensor shows as unavailable.
But even when it shows as unavailable, if I look at the MQTT debug info, it shows it is subscribed to rtl_433/Maverick-ET73x/+/temperature_1_C and it shows the last 10 messages with the expected payload. What am I doing wrong here?

1 Like
2

What I’m finding out is that you cannot use a wildcard topic in the availability topic, but it works in the state_topic and the json_attributes_topic

Here is a minimal example to explain:

The following code works:

mqtt:
  sensor:
    - name: "Food Temperature"
      unique_id: ivation_food_probe_temp
      state_topic: "rtl_433/Maverick-ET73x/+/temperature_1_C"
      value_template: "{{ value }}"
      json_attributes_topic: "rtl_433/Maverick-ET73x/+/time"
      json_attributes_template: "{{ {'test':value} | to_json }}"
      availability:
        topic: "rtl_433/Maverick-ET73x/63919/time"
        value_template: "online"

The following does not work, and results in a sensor that is “unavailable”. Note the only difference in this entire code block is the json_attributes_topic which has a wildcard (+) in place of 63919

  sensor:
    - name: "Food Temperature"
      unique_id: ivation_food_probe_temp
      state_topic: "rtl_433/Maverick-ET73x/+/temperature_1_C"
      value_template: "{{ value }}"
      json_attributes_topic: "rtl_433/Maverick-ET73x/+/time"
      json_attributes_template: "{{ {'test':value} | to_json }}"
      availability:
        topic: "rtl_433/Maverick-ET73x/+/time"
        value_template: "online"

So the question is, does anyone know if this is a bug or if this is desired behavior?

1 Like
3

I just ran into this issue - I’m running a fairly outdated version - 2023.8.2, so I’m hoping this is just a bug. I don’t see a reason why the availability topic would have a restriction on wildcards.

btw, I use the wildcard to setup to absorb multiple rtl433 radios. The topic name structure is such that the hostname is in there, so the wildcard goes in that section of the path.

4

It’s technically not a bug because the documentation doesn’t specify that wildcards should be supported. Instead, the support of wildcards in state_topic and json_attributes_topic is an undocumented feature.

I was going to see if I could figure out how to create a pull request and update the documentation but I haven’t made it that far.

5

One workaround for you might be to get the hostname removed from the topic structure and merge all the data together. In the MQTT command line argument passed into rtl433, you should be able to specify the topic structure you want using the devices parameter. Mine is, for example:

'-Fmqtt://192.168.1.1:1883,retain=1,user=myusername,pass=mypassword,devices=rtl_433[/model][/id]'
6

True, for now I’m opting to just use the hostname of one of the radio station on the availability topic. Technically, all station can receive all nodes, but I’m installing a few additional SDRs because the transmitter nodes are numerous and I’m starting to see dead spots, they are probably stepping on one another, etc. I like having separate “hostname” in the path because then I can tell which station the message is coming from for debugging purposes.

Also, the way I’m using availability topic in a config for a leak sensor is a very narrow case. These sensors don’t have a heartbeat message, so in order to avoid an “unavailable” on a system power cycle, I use the avail topic + retain flag in mqtt to make sure the just present the last known state.

It’s a bit convoluted, but it saves me the task of physically pressing a button on all the sensors when I reboot.