rtl_433
rtl_433 copied to clipboard
merbanan
Point me to Troubleshooting guide for RTL_433 and Acurite?
So been bouncing around forums for help, but groups pointed me to the source. I have an old 2013 MacBook Pro running Ubuntu 20.04 LTS (no MacOS), Noelec NESDR smart v4 bundle on extension cable using the 1' antenna that came with it, using docker image of hertzg/rtl_433:latest running. I have an Acurite 968 Fridge/Freezer sensors that I would like to read and port to Home Asst and then grow from there. Been following the recipe from https://www.kyleniewiada.org/blog/2021/10/affordable-water-leak-and-temp-monitoring/ and Kyle has been great at trying to help me (please reference our comments and my screenshots at bottom of the link), but we're at a loss.
Problem, I don't know if I have a hardware or software problem, or just a user ignorance problem, and don't know how to dissect this. $lsusb shows the device. $rtl_test runs but doesn't show any data output. When I run $rtl_433 and I power cycle the sensors, I will get a burst of data and nothing else thereafter. I tried searching the issues lists, but seems the posters are way over my head and I don't know where to go next. I really want this to work and any help is appreciated.
I would get no results (see attached). I expected to have TPMS sensors, my outdoor LaCrosse temp sensors, etc...but would get nothing. But if I would go remove and replace the batteries in my Acurite 986 sensors, I would get a battery message (see attached) and nothing else.
On Wed, Nov 17, 2021 at 1:14 PM Benjamin Larsson @.***> wrote:
What is the output of running only rtl_433 for a while?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/merbanan/rtl_433/issues/1882#issuecomment-971893010, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP4ROCBSZVMBN2VAQQJM5WTUMP5IVANCNFSM5IHXHQLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
--
Trey D. Lutrick
apologies, I tried attaching to my gmail email...let see if I can drag/drop in Github...
Ok, I ran the command for couple of minutes and got this..
.
How do I interpret this?
I think something must be wrong with my device or my understanding of how it works. I loaded CubicSDR on another MacBook running Catalina, and plugged the SDR in. It showed on the screen (see below), but would not Start and when I pressed Refresh, it no longer showed up as a device. There is no real "manual" or recipe to follow, so I'm shooting from the hip. Should I return this device or am I doing something wrong?
That's strange. It should show Generic RTL2832U OEM :: 00000001
Looks like the eeprom information is not read correctly, really looks like device trouble.
lsusb -v should show e.g.
Bus 020 Device 019: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0bda Realtek Semiconductor Corp.
idProduct 0x2838 RTL2838 DVB-T
bcdDevice 1.00
iManufacturer 1 Realtek
iProduct 2 RTL2838UHIDIR
iSerial 3 00000001
or if you don't want to install lsusb then ioreg -p IOUSB -w0 -l will show
| +-o RTL2838UHIDIR@
| {
| "USB Product Name" = "RTL2838UHIDIR"
| "USB Vendor Name" = "Realtek"
| "idVendor" = 3034
| "USB Serial Number" = "00000001"
Ok, quick update...for giggles, I disconnected the USB extension cable and plugged it in directly, and it came up. CubicSDR was able to see the device and I tuned to some local FM stations easily (see pict). Ok, so definitely a bad cable. Let me try again and see what I get...
.
OK, well I found a usb extension cable in my stock (that we all have) and it worked on CubicSDR. I plugged it in my Ubuntu/docker setup and nada...
Thoughts?
BTW, when I plugged it in with my other MacBook running CubicSDR, I tuned to the 433.92Mhz channel and would see a pulse every 30 seconds or so. So I "think" this tells me that a 433.Mhz sensor, possibly my Acurite 986 sensor, is transmitting, but receiving nothing in my Ubuntu/docker instance.
So, I don't know what's with this or what else to do to troubleshoot it. I have a lot of old Mac's that I've been having good luck repurposing and no PC's, so not a lot of hardware options for me.
I ran it on rtL433:latest and just protocol 41 to correspond to my Acurite 986 sensors and nothing...
So one question for my own edification...does the different size antennas have any impact on the 433.92Mhz protocol? I've got what appears to be a 1) ~6" stubby antenna (1/4 wave for 433Mhz?), 2) ~12" antenna (1/2 wave), and 3) retractable ~24" antenna. My Acurite transmitter is about 50' away from my Ubuntu/docker server rack. Unsure if any of this will have that much impact. 433Mhz should travel easily over that distance (I hope)
Can you try running with -A and with -S unknown and post the output/files. And you could also try to change the frequency ca 500kHz.
Absolutely! And I'd pee on a electrical outlet right now if you think it would work, but I'm embarrassed to say that I'm new to docker, and struggling with syntax around moving files in/out of containers. Let me see what I can figure out...stay tuned...
Ok, the docker file system was actually harder to figure out than I thought, but I got the rudimentary gist of it...
Most are empty, but there is a interference signal at 433.855 MHz. Your signal is exactly on 433.92 MHz. Drop https://triq.org/pdv/ on to see yourself.
Best to tune away to 434.5M
Also the signal you caught does not look like Acurite. It's an unknown 13 repeats of {25} 85 11 db 80 : 10000101 00010001 11011011 1 with -X 'n=name,m=OOK_PWM,s=232,l=648,r=7000,g=620'
It's likely an EV1521 encoder, something like a doorbell or motion sensor.
Best to grab the band for 60 seconds for an overview: -w myfile_433.92M_250k.cu8 -T 60
There is now also a section in the docs on how to analyze reception: https://triq.org/rtl_433/ANALYZE.html
Also I'm testing a visualization of dB level for noise and events on the HTTP UI. Might take some time to finalize though:
So sincere apologies, as I'm feeling extremely ignorant. I'm not sure where to go with anything you wrote me.
Step 1, I'm going to have to read up on how to analyze the .cu8 files. I'm curious why I have an Acurite 986 who's sensors communicates with it's magnetic display, but we're saying there is no data to indicate that it is? I wonder if the propagation power from those devices is so low that my SDR won't register it coming through the fridge/freezer, SDR ~50' away, & through walls? (Note: my Govee Water Leak Sensors just arrived, so I'll try to power one up and see if it registers)
Step 2, I'll read the https://triq.org/rtl_433/ANALYZE.html , so I can learn to decipher what/where signaling is "potentially" coming from. Maybe I'll glean something
I feel terrible in that I'm wasting you guy's time. This has gone from me trying to follow a recipe and capture the functionality of some low cost 433Mhz devices into Home Asst, to deep dive RF analytics.
No trouble. It's just that for most users it usually simply works and the basic steps are skipped. Now it's confusing to roll back to more fundamental steps. The first step is always "find the signal", "inspect the signal" ;)
@SolarCzar - A few comments relative the Acurite 986 and refrigerator/freezer sensors.
General:
- The "metal box" tends to reduce the transmitted signal by a significant amount.
- Orientation matters
- what's placed "in front" of the sensor (liquid, meat) can also absorb the signal. By "in front" I mean the imaginary line of sight between the sensor and your receiving antenna. Ideally there shouldn't be any "contents" of the freezer/refrigerator in that line of site.
Specific
- The Acurite 986 sensors have somewhat marginal signals and orientation (vertical vs. horizontal) seems to make a pretty big difference. I never cracked mine open, but based on the effects of changing the orientation of the sensor with respect to the receiving antenna, I suspect it might use a length of wire instead of a coil that would give a more general circular polarization of the transmitted signal.
- The newer Acurite 515 sensors seem to transmit a better signal
- The 986 only transmits once a minute.
- Acurite's spec's for distance are 75 feet. Reality is probably half of that. Other Acurite sensors that are meant for outdoor use specify 150 ft.
I did the original decoding for the 986 a long time ago. There have been many considerable structural improvements in rtl_433 since then. It's possible there might be better choices for demodulating that could do a better job of recovering the signal.
Some suggestions:
- Take the sensor out of the freezer/refrigerator while you are trying to find the signal and figure out what the signal looks like on the waterfall and roughly what frequency it transmits on. Note: the frequency will change with temperature.
- Try different orientations: Vertical, Horizontal of the sensor and your receiving antenna. If I remember correctly the antenna is near the bottom of the sensor. I believe I generally did best by making sure the bottom of the sensor was pointed towards where the receiver was.
- I don't have access to mine right now - What's the FCC ID? There might be some internal pictures as part of the FCC filing. See fccid.io - Here are the photos for the 515 - https://fccid.io/RNE00515TX/Internal-Photos/Internal-photos-4601689
Unrelated note: Thanks for the pointer's to Kyle's blog. I've been meaning to buy some water leak detectors. I will check out those Govee H5054 sensors, they look inexpensive enough. Would be interested to know how well they work after you get some experience with them.
Sorry guys, I was out of town for Thanksgiving, but back at it...
Thanks RCT...you hit the nail on the head. So good news, I think... and I feel stupid for not thinking about it, I removed one of the 986 sensors and placed it physically next to my server. And lo and behold, I got a reading...
So at least I know it functions. Problem is my Ubuntu server is in a network rack about 70' away and the signal has to propagate out the Frideg/Freezer and then through 2 walls. I guess it was wishful thinking to think that 433Mhz would travel further, but my mind was not considering the uplink RF power of the sensor itself. They probably designed it to just get within say 10-15' to the display module. I can actually place the sensor on top of the Fridge/Freezer and get a reading, but not inside. So it will propagate the 70', but the attenuation inside the Fridge/Freezer is too much.
So new question...is there a way to boost that signal or relay it? I can't move my network server rack, as it's built in with UPS power, HVAC, 1gb Fiber, etc... I have a really big 1 story house, so coverage may be of concern in this exercise. I guess I can look at some different antennas to mount on the SDR to improve it's receive signal, but then I will also pick up more noise. I'm currently using the telescoping one that's about 2 feet long. Have you guys encountered solutions for this? ideas?
I'm going to play with the Govee sensors in order to try and recover something of this activity, since they won't be in the meal box.
So new question...is there a way to boost that signal or relay it? I can't move my network server rack,
Things that can help: reduce the distance, improve your antenna, reduce noise, improve the signal, or some combination.
70 feet is a pretty big distance given how much the metal box of the fridge/freezer is going to attenuate the signal. I think I've had to have my receiver within half of that distance for the 986s.
Your network rack is not an ideal place for a radio receiver, there are plenty of things to produce RFI. You don't need a server to run rtl_433. I run most of my rtl_433 instances on RPis. I've got one an an RPI 1B+, another on a RPI 2. Put an RPi with an RTL-SDR some place central, use MQTT to deliver the messages to an MQTT broker on your server. I'm actually using two setups to cover all of my devices. They both connect to the same MQTT broker. I use a wildcard to subscribe to the MQTT topics, so as long as one host picks it up it all works.
Depending on the type of antennas used in the transmitter and receiver, orientation of the antennas with respect to each other can reduce the signal -- "polarization" loss. With my 986, I found trying different orientations was important for improving the signal. These days you can get rtl_433 to output stats on received signal levels, which should make experimentation easier.
Ok, good news. Took a different approach based on your guidance. Loaded on a Rpi 3+ and moved it closer to the Accurite sensors, and it began reading them. I guess at 70' away was just too far, even at 433Mhz. Ok, Great!
Entered the command to run it on the Rpi and send the sensor readings via MQTT to Home Asst.
$ rtl_433 -R 40 -R 41 -R 192 -F "mqtt://<mosquito IP address>:1883,user=<mqtt username>,pass=<password>,retain=1,devices=rtl_433[/model][/id],events=rtl_433[/model][/id]"
and got...
rtl_433 version 21.05-179-g21d7fade branch master at 202112130814 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Publishing MQTT data to <mosquito IP address> port 1883
Publishing device info to MQTT topic "rtl_433[/model][/id]".
Publishing events info to MQTT topic "rtl_433[/model][/id]".
Registered 3 out of 207 device decoding protocols [ 40-41 192 ]
Detached kernel driver
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
MQTT Connected...
MQTT Connection established.
Loaded the respective config.yaml file update for the sensors and followed Kyle's recipe at [https://www.kyleniewiada.org/blog/2021/10/affordable-water-leak-and-temp-monitoring/], but not receiving data, though I'm showing connected. I'm not an MQTT expert, but I have some Tasmota switches set up, so I know MQTT works. My question, is there a simple way to diagnose the MQTT message throughput? I'm trying to read on how to diagnose MQTT publish topics to determine what is being shared, but finding the material a little heady for me. Thoughts?
Disregard above...figured it out. In Kyle's yaml files, he mentions...
binary_sensor:
- platform: mqtt
state_topic: rtl_433/Acurite-986/54321/battery_ok
json_attributes_topic: rtl_433/Acurite-986/54321
I assumed the 54321 was some code reference, but in fact it's the sensor number. Mine is different and is 54245, so when I transposed those numbers...It Worked!!!
So things have been working great until today. Started getting SDR Healthcheck notification from Home Asst related to the Laundry Freezer sensor (Id 59755). As I started debugging the problem, I pulled up MQTT Explorer and the laundry sensor is changing the sensor number arbitrarily. Have you guys ever experienced this or know what that problem could be? I took a screen shot of MQTT Explorer...note the original and new incoming messages...
Note: I only have 2x Accurite-986 sensors, so all those MQTT messages in the file above are the sensors changing ID numbers.
The ID would change at startup. Is the battery giving up, occasionally resetting the sensor?
I popped out several times during my diagnosis. The batteries were new in December, but I took the liberty to change them now. Crap! I didn't realize the sensor ID changed with a battery replacement. So this means, I would have to identify the Sensor ID of the device every time a battery change occurs and update the configuration.yaml file in Home Asst.?
I changed the Sensor ID's and it's working...Is there a way to have Home Asst pull the most current Sensor ID following a battery change?
It a common problem, the ID may change and the channel might be duplicate. No way around that really. I'm using channels as identifier, but several neighbours have the same devices and there are collisions, I just ignore those sensors though.