Ahh good, thanks a lot for that detailed anwser !
That may depend on the sensor.
Some sensors call it ID, others SID, sensor_ID, etc. and there are other variations.
I know they are working on standardizing these in the rtl_433 - and I expect this is to allow just what you are asking.
So, currently it depends on the sensor… if it has an ID that matches what rtl_433 recognizes, I believe it will already be added - if it does not (or instances it calls the ID “sensor_ID”) then the program doesn’t recognize it.
You can use an MQTT client to see what is being published to know if it is being used. If it is not, you can take a look at the repo and find your sensor to see what the ID is being sent as. Then, if you are experienced enough, you could do a pull request to fix it - or you could put in an issue request to have it fixed. I see the most recent commit was to fix this for a few different sensors (commit #1034).
- DeadEnd
I guess I’m confused, I see the sensor’s ID in the message but I would like it to be in the topic.
In my testing of the new -F MQTT, All my sensor’s publish to /rtl_433 which would then require logic to separate them in Home Assistant. Seems inefficient. Hopefully I’m missing something in my understanding.
I’m using this:
rtl_433 -R 40 -C customary -F mqtt://192.168.1.10:1883,events=/rtl433
would like something like this
rtl_433 -R 40 -C customary -F mqtt://192.168.1.10:1883,opt=id,events=/rtl433,topic=id
This is what i have for the id:
- platform: mqtt
state_topic: “homeassistant/sensor/temperature/Acurite_tower_sensor/15664”
name: “Temp ext”
unit_of_measurement: ‘°C’
value_template: ‘{{ value_json.temperature_C }}’
If you can’t find a way to include the sensor’s ID in the topic, I can offer you the “logic to separate them” from the topic’s message.
The solution is a single, simple automation that serves as a demultiplexer. It subscribes to a single topic and separates it into multiple topics, one unique topic for each sensor.
@Kronyx what does your rtl_433 command look like?
@123, that’s exactly what I was coding in my head, lol
thanks
The DEVICES of the rtl_433 breaks the values of the EVENT into single published values.
To start, I would remove the EVENTS flag and just let rtl_433 run its defaults.
With the default setup you will see events, devices, and states.
This will let you see the full range of what it publishes.
From here you can limit and modify the topics to fit what you want.
From what you have already stated, I believe you will want to use DEVICES instead of EVENTS.
But again, I would suggest using the defaults first and go from there.
Thanks for the info @123.
Its good to see that rtl_433 is maturing.
Built in mqtt was not available when I hacked together the hassio addon for rtl_433.
Please don’t quote me out of context. You left out this important qualifier:
If you can’t find a way to include the sensor’s ID in the topic, I can offer you the “logic to separate them” from the topic’s message.
Apologies, I didn’t read it correctly and missed your point.
I will remove it.
1 Like
I ran the default as you suggested and I see all the transactions it’s publishing but nowhere do I see the ID field in the topic.
It generates:
rtl_433/hassbian/events which contains the ID in json format in the message
and it also generates:
rtl_433/hassbian/devices/Acurite_tower_sensor/A/id
but nowhere do I get
rtl_433/hassbian/devices/111111
So if I have 10 temperature sensors the -F MQTT method would have a hard time telling them all apart. This is where I would need a automation like @123 suggested to separate them out.
There’s an open PR to allow rtl_433 append the ID to the topic’s name.
Quick question:
When is the last time you updated from the repo?
The reason I ask is that specifically the Acurite Tower sensor code was updated 7 days ago to fix the ID fields as I mentioned above. If your pull is older than that, you could try updating to see if that gets you the ID field.
My sensors actually have the same issue - currently the ID being reported is a subtype… I just checked the repo though and realized I also need to pull an update to fix this.
Anyway… see if that is the case - hopefully it is so you have an easy fix 
I updated my container and my ID is still not being used in the Topic.
I am reading through the files related to my sensor, but I’m not very good with this yet.
It is pulling in a field for me, but it is the same on all sensors - not the unique ID.
Anyway, hopefully yours works after an update as the acurite is more popular than what I am using ( Digoo DG-R8S).
… did some more reading and realized that the “ID” that is passed from my sensor is actually a type and either 5 or 9. there is another Random ID (RID) that is almost unique, but sounds like it is generated each time the batteries are replaced… so the topic would change after battery changes… this wouldn’t be too often, but is not ideal. So I expect knowing that, they intentionally left the ID out of the topic.
Depending on your sensor - if it has the same random ID that might explain why it was left off the topic.
Quick question though, you said:
this has the channel and then ID after the model - is this a different ID or the one you are trying to get in the temp/humidity topics?
If it is the correct ID, is the CHANNEL on all of the DEVICE topics?
If these are both true, there is a setting to do ID before CHANNEL.
If the default is repeating the channel currently for all device topics, switching to ID before CHANNEL might get it to repeat the ID for all device topics.
I am mostly just brainstorming on this - but it makes sense to me 
.
Okay, I know I’m spamming this topic - but I think I am finding useful information.
I did some more reading on the output_mqtt.c file and I MIGHT have found an answer!
the usechannel is what I mentioned previously, here is a snippet from the readme:
usechannel=replaceid|afterid|beforeid|no
I then checked the output_mqtt, and found the default:
mqtt->use_channel = USE_CHANNEL_REPLACE_ID;
I am going to try and test this, but I believe the solution is to set the usechannel so that it does not replace the ID.
UPDATE:
Success!
Add one of the following three as an argument:
usechannel=afterid
usechannel=beforeid
usechannel=no
As long as you don’t use replaceid you should get your ID in all your device topics!
Before
After
Learning as I go, but happy that I believe I have found a solution for you @Kronyx @cyn .
2 Likes
The PR is requesting a topic name containing the sensor’s id whose payload contains all data as a JSON dictionary.
For example:
topic: rtl433/events/sensor/13839
payload: {"time":"2019-05-07 08:01:50", "model":"Acurite tower sensor", "id":13839, "sensor_id":13839, "channel":"C", "temperature_C":25.200, "humidity":35, "battery_low":0}
The only advantage of this, over what is currently available (shown above in DeadEnd’s post), is if there is a need for a sensor to acquire more than one parameter.
For example, if you want the temperature and the channel both then have to be in the payload. A sensor can only subscribe to one topic so if temperature and channel are in separate topics, it will only be able to subscribe to one or the other but not both.
1 Like
@DeadEnd and @123 Thank you so much for your efforts, this command works for me
rtl_433 -M newmodel -R 40 -C customary -F mqtt://192.168.1.10:1883,usechannel=no
it generates
rtl_433/hassbian/devices/Acurite-5n1/2143/id
rtl_433/hassbian/devices/Acurite-5n1/2143/temperature_F
rtl_433/hassbian/devices/Acurite-5n1/2143/humidity
etc (one transaction for every value found)
Thank You
Thanks for the info, helped me ALMOST get it working. Newer versions of rtl_433 fail on “usechannel” option. I ended up removing the option and adding the following:
devices=rtl_433[/model][/subtype][/id][/channel]"
It formats out to: (and other fields)
"rtl_433/Acurite-5n1/56/959/A/humidity"