Thanks for your answer!
I changed the configuration file
frequency 868M
convert si
verbose 2
protocol 119
protocol 172
protocol 173
output kv
output mqtt://192.168.1.113:1883,user=XXX,pass=XXX,retain=1
and I have such a result
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
Starting rtl_433 -c /config/rtl_433/rtl_433.conf.template
[21:57:17] WARNING: rtl_433 now supports automatic configuration and multiple radios. The rtl_433_conf_file option is deprecated. See the documentation for migration instructions.
rtl_433 version 21.12-101-g9eec4611 branch at 202204282249 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
New defaults active, use "-Y classic -s 250k" for the old defaults!
Registering protocol [119] "Bresser Weather Center 5-in-1"
Registering protocol [172] "Bresser Weather Center 6-in-1, 7-in-1 indoor, new 5-in-1, 3-in-1 wind gauge, Froggit WH6000, Ventus C8488A"
Registering protocol [173] "Bresser Weather Center 7-in-1"
Publishing MQTT data to 192.168.1.113 port 1883
Publishing device info to MQTT topic "rtl_433/8c985c30-rtl433/devices[/type][/model][/subtype][/channel][/id]".
Publishing events info to MQTT topic "rtl_433/8c985c30-rtl433/events".
Publishing states info to MQTT topic "rtl_433/8c985c30-rtl433/states".
Registered 3 out of 218 device decoding protocols
Found 1 device(s)
trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Found Fitipower FC0012 tuner
Using device 0: Generic RTL2832U OEM
Exact sample rate is: 1000000.026491 Hz
Sample rate set to 1000000 S/s.
Bit detection level set to 0.0 (Auto).
Tuner gain set to Auto.
Reading samples in async mode...
Tuned to 868.000MHz.
Allocating 15 zero-copy buffers
MQTT Connected...
baseband_demod_FM: low pass filter for 1000000 Hz at cutoff 200000 Hz, 5.0 us
MQTT Connection established.
If you aren’t seeing anything after that line, then it means your radio likely isn’t picking up any signals or it’s not working correctly. Otherwise, by adding output kv you’d see tables of messages rtl_433 has decoded.
first, thank you so much for your help, I am still stuck on this problem but after doing some research I found 2 possible solutions. 1- create my own custom addon based on the rtl_433_autodiscovery that will have add my keys/entities. 2- manually configure the sensors in YAML. but I’ve been trying to do that for a week now, I don’t know how to make the connection between the created yaml entities and my published sensor. I think it’s not woking because my entities haven’t been published to MQTT.
someone help
Confirm rtl_433 is picking up the signal from your sensor by adding output kv to your rtl_433 configuration. That will get it to print out a table to the logs on messages it gets.
If that’s good, use MQTT explorer to confirm that the state topic you have above is the correct one and that messages are being published there.
Confirm that the payloads you have set are actually strings, and should be wrapped in quotes, and not integers, which wouldn’t be.
Once you’ve confirmed rtl_433 is passing data to the mqtt topic correctly, you can use MQTT explorer to toggle the closed state for testing without having to open and close a door by hand.
Check Home Assistant logs for any mqtt-related errors.
No, that’s not normal, but if the sensor is actually transmitting those frames then everything is working “correctly”. You would need to write some custom code to “debounce” those messages in between rtl_433 and publishing to the mqtt broker.
Hello,
Could the add-on be updated or there is any way to change the rtl_433 bin by my side?
The reason is that there is a commit for the EMOS-6016 that, in my case, makes the difference detecting or not this sensor.
With the version in the addon is a matter of luck getting it. Stoping the addon and, running a shell of rtl_433 latest version works correctly. After this, if I stop the rtl_433 shell and run the addon again, sometimes the EMOS-6016 gets into the game, other times it doesn’t, but at some point it will go undetected for hours.
To mention, that sometimes I don’t get any data from the addon after a poweroff (like others in previous posts) and the previous trick, makes rtl_433 addon back to life, but the EMOS-6016 could be back or not…
In my template.conf file I just enabled the protocols I want to listen to.
So, I would like to run the latest version of rtl_433 inside the addon to get the data of this sensor with reliability (now it goes off for hours)
Best regards
I’ll plan on rolling a new release today. It would certainly add support for the new protocol, but it may not solve your issues with drops if that’s an issue of your radio getting the signal in the first place.
Thanks for the new update! I have a small suggestion for the next one.
A lot of add-ons have an icon.png with some color in them, so that when the add-on is running the icon appears in color on the add-on page. When the add-on is not running, it appears in grayscale. (It looks like this is a default behavior of HA, since all the other community add-ons have a single, colored icon.png file)
Since the icon.png for these two add-ons are already grayscale images, there is no way to tell if the add-ons are running from the add-ons page.
Adding a bit of color to the icon, even something simple like a green bar would fix this, at least as far as I can tell (though I’d suggest someone with some design sense make a better version than mine)
Hi,
Is it possible to add a custom protocol, or at least see the raw data? I have a 433mhz movement sensor which I know transmits clear text. I would like to see if i can capture the packet - is this possible with this add on?
It’s going to be much easier to do that type of investigation outside of Home Assistant. rtl_433 has great docs at rtl_433 | rtl_433 and many modes to attempt somewhat automatic decoding of data.
As far as i can read and understand github you are actually the guy for rtl_433 and autodiscovery questions and support ?
the addon installation is since may basing on precompiled images so no way to implement rtl_433 changes on installation. is it possible to find/receive at pre version which downloads the source and compiles locally ?
When I started contributing to the addon, it originally compiled rtl_433 when the image was installed by building the entire Dockerfile locally. But, this also made support really difficult because the “same” version of the addon could have different final results. Also, it made installs slow for slower devices.
I understand WHY you switched to images install but i actually use a modified radiohead driver and a modified rtl_433_mqtt_hass.py within rtl_433 to create own sensors using 433 with lower power consumption than Wlan. Radiohead’s default output normally is useless for HomeAssistant so i choose that to modify and implement my own usage. Actually the installation is a bit tricky while i replace both files (rtl_433 and rtl_433_mqtt_hass.py) within HomeAssistant. I would like to create an own repo on git
(more flexible than locally) with a copy of rtl_433 and autodiscovery for easier testing and installation on my PI’s .
Auto discovery has no version archive so i can’t download a previous version , that’s why i asked you for.
I have a little problem.
I had this working impeccably on a bresser 5-1 weather station, but ffrom one moment to the next it stopped updating the sensors.
Assuming your screenshot is up to date, mqtt explorer is showing data from two days ago. That would mean we can probably rule out Home Assistant or the bridge script.
As a first step, you can add output kv to your config. If nothing shows up in the addon logs, then you know rtl_433 isn’t detecting a signal. In that case, I’d check batteries and make sure that you don’t accidentally have the protocol disabled in your configuration file.
Well, first I put that configuration in the file, and nothing appeared.
Then I removed the weather station from the base, changed the batteries and it worked.
Now you’re updating me.
The station has an interior base, in which it updated the values in that base.
The batteries were not discharged, they were just cold (I have rechargeable batteries, are not the most suitable but they were in the station for 1 month) but it was reporting to the interior base.
But for now it’s resolved. I’m going to buy lithium batteries to put in. Before putting the weather station on top of the roof.
