Andrew thanks for the reply, I found by taking out the time parameter & changing convert to customary it worked on all my temperature sensors. Previously I had one sensor giving me temperature_F and all the others temperature_C, crazy. But now they are all _F.
1 Like
hello,
well since the last Hassio Update my rtl stick stopped working… stick work on other machine… don’t know what changed or what happed to the system but i’ll can’t get it to work again. on other raspberry and my Mac it works well with same config and also connects to mqtt and sends the data as before when connected to the hassio Pi …
config:
gain 0
frequency 868.30M
hop_interval 600
ppm_error 0
sample_rate 1024k
report_meta time:unix
protocol 172 # Bresser Weather Center 6-in-1 (newer 5-in-1)
protocol 173 # Bresser Weather Center 7-in-1
output mqtt://192.168.178.142:1883,user=xxx,pass=xxx,retain=1,devices=rtl_433/bresser51
output kv
don’t get any output except this:
Starting rtl_433 with rtl_433.conf…
[rtl_433] rtl_433 version nightly-7-gecb0b361 branch master at 202303131601 inputs file rtl_tcp RTL-SDR
[rtl_433] Use -h for usage help and see https://triq.org/ for documentation.
[rtl_433]
[rtl_433] New defaults active, use “-Y classic -s 250k” if you need the old defaults
[rtl_433]
[rtl_433] MQTT: Publishing MQTT data to 192.168.178.142 port 1883
[rtl_433] MQTT: Publishing device info to MQTT topic “rtl_433/bresser51”.
[rtl_433] [Protocols] Registered 2 out of 243 device decoding protocols [ 172-173 ]
[rtl_433] Detached kernel driver
[rtl_433] Found Rafael Micro R820T tuner
[rtl_433] [SDR] Using device 0: Nooelec, NESDR SMArt v5, SN: 00000001, “Generic RTL2832U OEM”
[rtl_433] [R82XX] PLL not locked!
[rtl_433] Allocating 15 zero-copy buffers
don’t know but maybe has to do with power management? not enough power … but i’ll use a powered hub 3A … so that’s not the issues and it worked very well before…
if someone has a idea… many thx
M.
well what i’ll found out so far…
rtl_433 on Hassio is different to other platforms…
- i’ll notice that i’ll have much better and stronger signal if i’ll use my Mac with same hardware and same config…
- do know but it is different and also behaves different… maybe different compiled?
why is the signal reception on Pi with rtl_433 and Hassio not so good as on a Pi with RTL_SDR self compiled but same config?
i’ll noticed a difference from beginning but now i’m absolute sure there is a difference … reception of the signal is weak with Hassio and rtl_433 … if use same config and use another computer it is much better … signal strength … can put my Bresser 50m away and get signal… with all devices…
but NOT with Hassio on Pi and rtl_433 with MQTT … same pi just self compiled and bam much better reception…
something is wrong with this…
you all can repeat those steps… just use another computer and see signal strength …
wonder that no one made this discovery…
M.
I haven’t noticed this myself, and I’m a macOS user too. Is it possible that there’s some sort of interference with your Pi? What happens if you add a short USB extension cable to move the RTL away from the Pi?
I would be surprised if the version of rtl_433 makes a difference, but you can check by installing the “next” addon as well to compare between the last tag and any changes since.
If you are having power supply problems, I believe that Raspberry Pi Power Supply Checker - Home Assistant is installed by default and would alert you. But if not, you can add that to double check.
hey,
thx for quick reply…
did some test’s…
when my rtl sticks (Noolec) & (dab-t) are in raspberry Pi … the receiving is not so good as when i’ll use them on my Mac … doesn’t matter which stick i’ll use… it’s not the stick nor the power or anything …
it’s the rtl sdr on pi…
On my Mac I’ll don’t need extra power for those sticks… also the signal is double strong then on Hassio Pi … don’t know but everyone can test and check the RSSI …
my guess is that the raspberry sdr is missing or has something different in settings that it doesn’t receive so well…
btw. i have usb hub with 3a power… also extra cable between USB Stick and computer… with or without … same same same… Raspberry PI …not good signal… Mac OS X → very good signal…
my Station is outdoors 25 meter away from home… the bresser station always receive the signal… but the stick not… if put in another computer Mac or PC all is working again also with long distance…
most users don’t have a long distance to the sensor… all i’ll saw was max 10 meter… that works always… you don’t even need a antenna … lol… but if you put the sensor 25 meter away you have the issues … but only on Raspberry Pi … on Hassio and on my other too… did a fresh install and compile… but still the same… also rtl_433 next has still the same bug!?
so conclusion after 3 day’s checking… it’s RTL_SDR on Pi that has issues with signal strength.
i’ll give up on it because i’ll don’t know what and how to change to make it work…
use now a mac mini for those sticks… and can go 50 meter away from station… no problem… with PI around 15 meter max …
and again: nobody does notice because all are much closer to the receiver… or does someone have 25 m + between station and sensor?
thx
M.
Hi all! It was briefly discussed much earlier up thread, but I’m wondering if anyone else has run into and/or solved the issue of randomly generated sensor IDs? I have a number of Accurate 606TX sensors, and a battery change will cause new sensor ID to be generated, at which point I currently need to re-run MQTT auto-discovery and re-map sensors in my HASS setup. Would love a cleaner solution if one exists.
Hello,
That’s a recurrent issue with 433mhz sensors, your best chance is to create a topic match on the model name and eventually the channel or other criterias if you have.
made some more tests…
definitive the PI has not so good reception as another computer (Mac)
i’ll cleaned all build from source … and using rtl_433 on my Mac i’ll have much better Signal as when using it (fresh build) on two different Raspberry Pi 3+
with Pi i’ll have to keep a distance around 10-15m
with my MacBookPro i’ll can go more than 50 meter away and it’s still working fine… nooo signal loss …
don’t know where the different is but the Debian build of rtl_433 sucks on Raspberry …
M.
I checked out the MQTT payload and it looks like I don’t have much to go on other than that random ID in terms of uniquely identifying a specific sensor where I have multiple instances of that same sensor.
device_class: temperature
name: Acurite-606TX-134-T
unit_of_measurement: °C
value_template: '{{ value|float|round(1) }}'
state_class: measurement
state_topic: rtl_433/9b13b3f4-rtl433/devices/Acurite-606TX/134/temperature_C
unique_id: Acurite-606TX-134-T
device:
identifiers:
- Acurite-606TX-134
name: Acurite-606TX-134
model: Acurite-606TX
manufacturer: rtl_433
platform: mqtt
Am I missing anything or am I resigned to updating sensor entries whenever batteries are replaced?
I have this issue with my rain meter as well. I wonder how the display units handle it? Since it’s a counter, I don’t think they can just ignore the ID because two rain meters in range would mess those readings up.
Otherwise, I’ve wondered what it would take to write something that works with the MQTT integration to easily update IDs and paths when they do change. Lets say you change batteries, then run the autodiscovery integration - perhaps a form in HA could be used to indicate “replace this device with that device” that rewrites all of the topics.
Could you share the payload, just in case something come to my mind seeing it.
New to HA and rtl_433
I can see a populated topic in MQTT Explorer but can’t seem to get that communicating to HA.
I am running a Mac w the rtl_sdr connected - this device is receiving info from a few environment devices and some home things.
the Mac is also publishing this data to MQTT
from the Mac terminal - when mqtt is not enabled (shows the info being received from the usb)
then I run the command in Mac terminal to publish to mqtt -
I can see this via mqtt explorer
however - when I go to HA - im not seeing this.
im running the Mosquito broker add on, the rtl_433 add on, and the rtl_433 mqtt auto discovery add on. and setting-devices-mqtt.
im running the default config in mosquito broker add on - I have a set username and password in mqtt_433 auto discovery - with a host of mqtt_host, and rtl topic of - rtl_433/+/events, and discovery prefix of homeassistant.
any suggestions?
Your mqtt reporting configuration isn’t right. It should look like this:
Just remove devices= and you should be good to go.
Ty. How and where do I do that?
In the very first line of your screencap, it ends with ,devices... - delete everything past the password and it will use a default setup for devices instead.
now I see this
if that is right, then the next step is getting this into home assistant mqtt - still not being auto discovered
changed the rtl_topic in rtl_433 mqtt auto discovery - and now I seem to find the devices in the mqtt integration.
however next issue -
- whereas I am seeing the variables on the devices in mqtt explorer
I am not seeing all of those variables in home assistant
I am running my RTL_433 to log Acurite temp sensors on a Raspberry Pi Zero and I would like to send the data to HA. I tried this:
rtl_433 -F “mqtt://ipaddress:1883,user=homeassistant,pass=password,retain=1,devices=homeassistant”
The RPi shows it is connected to the HA MQTT broker and I can see the messages coming in on HA when I listen in the MQTT integration. However, I thought that HA MQTT would create new devices based on these messages from the Acurite temperature sensors. Is this not as simple as I hoped?
P.S. I am not using the addin as I cannot run the RTL stick on the RPi because I cannot run it on the HA machine
I put the screen shot above referencing how HA is missing some of the data reported by one of my sensors - and how that sensor is correctly capturing data as per mqtt explorer…
in the rtl_433 mqtt auto discovery add on that I am using - here’s is what I see in the logs…
DEBUG:paho.mqtt.client:Sending PUBLISH (d0, q0, r1, m140), ‘b’homeassistant/sensor/Fineoffset-WH45-15799/Fineoffset-WH45-15799-H/config’’, … (422 bytes)
INFO:root:Published Fineoffset-WH45/15799: time, battery_ok, temperature_C, humidity
INFO:root:Skipped Fineoffset-WH45/15799: pm2_5_ug_m3, pm10_ug_m3, co2_ppm, ext_power
where the skipped parts are what im looking for
ty for the help here. I see in the prior posts the “skipped” dynamic is resolved by updating the python script or manually publishing a topic to configure the device.
which one of these is easiest and can you postally point me in the direction of some instructions on how do to this - understanding that im a novice.