Author Topic: New Acurite Lightning Detector  (Read 18138 times)

0 Members and 1 Guest are viewing this topic.

Offline nincehelser

  • Forecaster
  • *****
  • Posts: 3337
New Acurite Lightning Detector
« on: August 16, 2016, 09:17:30 PM »
https://www.acurite.com/lightning-detector-with-temperature-and-humidity.html#"

It's not AcuLink compatible, but I imagine that might be coming.  It would be cool if it could gauge electrical storm intensity and let me know when it's a good time to go photograph lightning.

 [ You are not allowed to view attachments ]

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #1 on: September 30, 2016, 07:11:25 PM »
I've got one.  I bought only the sensor to play with.  I didn't get the console.  So I'm working a little blind with it.   It has tripped and beeped for thunderstorms.

Anyone else have one?

As the manual states, it's sensitive to RF.  Place it too close to something that emits a bit of RF, like right next the laptop, and it will trip into lightning mode as well as give an interference warning.

I'm working on adding support into rtl_433 for this.   It's similar to the tower sensor and the 5n1 that I've worked on.  I think I've worked out the ID, the humidity byte, the number of lightning strikes recorded so far.    However, I can't find a sensible representation of temperature in the message, so far.   I'm starting to wonder if it is possible that I got a unit with a defective temperature sensor.

I'd love to hear from anyone else who has one and has a rtl-sdr stick setup for rtl_433.

Offline tandy1000

  • Contributor
  • ***
  • Posts: 107
Re: New Acurite Lightning Detector
« Reply #2 on: September 30, 2016, 11:28:45 PM »
I've got one.  I bought only the sensor to play with.  I didn't get the console.  So I'm working a little blind with it.   It has tripped and beeped for thunderstorms.

Anyone else have one?

As the manual states, it's sensitive to RF.  Place it too close to something that emits a bit of RF, like right next the laptop, and it will trip into lightning mode as well as give an interference warning.

I'm working on adding support into rtl_433 for this.   It's similar to the tower sensor and the 5n1 that I've worked on.  I think I've worked out the ID, the humidity byte, the number of lightning strikes recorded so far.    However, I can't find a sensible representation of temperature in the message, so far.   I'm starting to wonder if it is possible that I got a unit with a defective temperature sensor.

I'd love to hear from anyone else who has one and has a rtl-sdr stick setup for rtl_433.

I'll happily buy one and help try to decode, if you give me some hints in decoding.  :grin: I have an rtl-sdr and would love to decode the Acurite BBQ thermometer. Learning how to decode the lightning sensor might help me out in the long run! I'd love to see rtl_433 be able to decode the full suite of Acurite stuff.
« Last Edit: September 30, 2016, 11:30:16 PM by tandy1000 »

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #3 on: October 01, 2016, 10:49:50 AM »
Right now rtl_433 decodes these acurite devices that I have:
  • The 5-n-1 weather station
  • 592TXR "Tower" Temperature/Humidity Sensor
  • 609TXC Temperature and Humidity Sensor
  • Acurite 986 Refrigerator / Freezer Thermometer

rtl_433 should also handle the 896 rain gauge, and the 606Tx temperature sensor but I have no direct experience with this.

Code: [Select]
2016-09-30 23:34:49 Acurite 5n1 sensor 0x0832 Ch A, Msg 31, Wind 18 kmph / 11.2 mph 45.0° NE (12), rain gauge 0.46 in.
2016-09-30 23:35:08 Acurite 5n1 sensor 0x0832 Ch A, Msg 38, Wind 25 kmph / 15.5 mph, 15.2 C 59.4 F 94 % RH
2016-09-30 23:35:17 Acurite tower sensor 0x2F15 Ch C: 18.5 C 65.3 F 75 % RH
2016-09-30 23:35:22 Acurite tower sensor 0x269C Ch B: 19.4 C 66.9 F 69 % RH


Currently my decoding for the lightning sensor looks like this:
Code: [Select]
2016-09-30 23:35:05 Acurite lightning 0x976F Ch B Msg Type 0x10: 856.7 C 1574.1 F 75 % RH - 80 97 6f 4b 90 ca 5f 0a 94

My guess at the format so far:
  • I haven't been able to figure out where temperature is
  • The first 3 bytes have the channel number, and ID
  • Humidity is in the 4th byte, 0x4b = 75
  • Status or message type appears to be a bit mask in the 5th byte.
  • I don't know what the 6th byte represents yet
  • The 7th byte is the number of lightning strikes detected. I'm currently not printing that yet.  It's a 7 bit counter.  Parity is used as in the other acurite messages.
  • I think the 8th byte might be estimated distance for the last lightning strike, but I'm guessing
  • The final byte is a simple checksum, which is working correctly.

The code for rtl_433 is on github https://github.com/merbanan/rtl_433.  In the README on that page you can see the list of devices that are currently being decoded.  I haven't submitted my code for the lightning detector yet since it's still experimental.

There is a repository of recorded signals for testing. https://github.com/merbanan/rtl_433_tests   I'll add some samples from my lightning detector soon.

There is a Google Group for rtl_433, it's very low traffic these days https://groups.google.com/forum/#!forum/rtl_433

I'd be happy to give some hints/help with the BBQ thermometer.  I don't own one.  Is it worth getting?  First step would be to get some recorded signals with as much info as to what should be in them (in other words, what's the reading on the display when the signal is captured.)

The code is easiest to build on a Linux box, It runs pretty well on a RPi these days.  It does build on windows but I'm not sure what the process is for building it. There is also a guy who periodically provides windows builds via his blog http://cognito.me.uk/computers/rtl_433-windows-binary-32-bit/.    The links in the blog post haven't been updated check http://cognito.me.uk/uploads/rtl433/ to see the files and the dates 32 bit: http://cognito.me.uk/uploads/rtl433/rtl433_win32_daily.zip  64 bit: http://cognito.me.uk/uploads/rtl433/rtl433_win64_daily.zip

Offline tandy1000

  • Contributor
  • ***
  • Posts: 107
Re: New Acurite Lightning Detector
« Reply #4 on: October 01, 2016, 12:42:19 PM »
Thanks rct! I do have rtl_433 running on a RasPi. I have so many 433mhz devices that I have to remove the antenna (leaving the base attached of course) and place the desired device next to it just to isolate the signal. But I've yet to try my hand at decoding.

I'll order the lightning sensor and get some data to you once I have it. I also have the Room Monitor, outdoor temp/hum, leak detector, soil probe - all in need of decoding!

As for the BBQ unit - I'm not even sure it broadcasts the temperature. The receiver is just a pager for near-done and done alerts. I really want a 4+ probe BBQ monitor. I've looked at the lot of homebrew and commercial solutions, none are quite what I want. That being easy/cheap to replace probes, and clearly parseable data. Most are Bluetooth, or cloud only, or proprietary probes, or some combo. If the Acurite does xmit temp data it would be ideal since the "per probe" cost is cheap, though having 4 LCD units near my smoker would take up a bit of space!

Offline Bushman

  • Forecaster
  • *****
  • Posts: 7549
    • Eagle Bay Weather
Re: New Acurite Lightning Detector
« Reply #5 on: October 01, 2016, 01:03:22 PM »
I use this in my smokers:  http://www.aginova.com/store/icelsius_wireless_bbq_dual  Nice unit.
Need low cost IP monitoring?  http://wirelesstag.net/wta.aspx?link=NisJxz6FhUa4V67/cwCRWA or PM me for 50% off Wirelesstags!!

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #6 on: October 01, 2016, 01:36:31 PM »
Thanks rct! I do have rtl_433 running on a RasPi. I have so many 433mhz devices that I have to remove the antenna (leaving the base attached of course) and place the desired device next to it just to isolate the signal. But I've yet to try my hand at decoding.

I'll order the lightning sensor and get some data to you once I have it. I also have the Room Monitor, outdoor temp/hum, leak detector, soil probe - all in need of decoding!

Ok, you win, you've got more devices then I do.   Would really like to see some sample signals from all of those other devices.  Removing the antenna to help isolate seems like a reasonable solution.  Hopefully having it so close won't distort the signal/overload the receiver.   Note: You might wind up needing to tweak the pulse widths a little bit once you've got the antenna reconnected and have the sensor placed away from the receiver.

What I do which isn't automated is I record for a while with
Code: [Select]
rtl_433 -p NN -a -t.    Then I run through the captured files with a for loop and send the output to a file.  Then I review the output looking to see what files didn't decode / might have the new device of interest.  So I do something like this:

Code: [Select]
for f in gfile*data; do echo ============ $F ============; rtl_433 -q -l 0 -r $f;echo " "; echo " ";done > /tmp/out.txt 2>&1

Offline tandy1000

  • Contributor
  • ***
  • Posts: 107
Re: New Acurite Lightning Detector
« Reply #7 on: October 01, 2016, 05:22:28 PM »
I can certainly provide data from the other sensors. They should be easier to decode since they are now decoded by the bridge and I'm capturing that traffic as well.

For whatever reason I never got rtl_433 working on my original RasPi. (it compiled/installed and runs, but never picks up any signals) Works fine on my RasPi2. I have some stuff to move off of that and I want to do a clean install, then I can get some data.

Maybe we should move to a new thread, apart from lightning sensor details?

Offline tandy1000

  • Contributor
  • ***
  • Posts: 107
Re: New Acurite Lightning Detector
« Reply #8 on: October 01, 2016, 05:22:47 PM »

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #9 on: October 02, 2016, 11:22:32 AM »
I can certainly provide data from the other sensors. They should be easier to decode since they are now decoded by the bridge and I'm capturing that traffic as well.

Great that should make it easier.

For whatever reason I never got rtl_433 working on my original RasPi. (it compiled/installed and runs, but never picks up any signals) Works fine on my RasPi2. I have some stuff to move off of that and I want to do a clean install, then I can get some data.

Maybe we should move to a new thread, apart from lightning sensor details?

Sure, I'm happy to move the RTL-SDR discussion where you think is appropriate.  I'm new to this forum.  If you think there should be a new topic or category, I'd be happy to participate here or on the rtl_433 google group.  Just let me know what you decide.

To respond to your RPi 1 vs. RPi 2 issue, the first thing that comes to mind is power,  The sticks with the R820T tuner consume a pretty good amount of power, ~350 ma, if you touch them they feel warm. The original RPi's could be problematic when it comes to power.  Also it helps to use a USB extension cable to get the radio and the antenna away from any noise generated by the RPi.   I've got RTL sticks running successfully on both an original (1st generation) RPi and a RPi 2.   You didn't mention if you are using the same stick on the two devices or two different ones.  I recommend figuring out what the tuning error is.  I've got some that are as far off as +/- 70 ppm.  That's 30 khz.  At the default rtl_433 sample rate of 250 Khz, that leaves on 125 khz of bandwidth on either side of the center frequency.   


Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #10 on: October 03, 2016, 06:10:39 PM »
FYI - my preliminary decoding of the lightning detector is now merged into the main rtl_433 repo.  So do a git pull and rebuild.  https://github.com/merbanan/rtl_433

Offline tandy1000

  • Contributor
  • ***
  • Posts: 107
Re: New Acurite Lightning Detector
« Reply #11 on: October 05, 2016, 05:51:18 PM »
Unfortunately it might be a couple of weeks before I can start playing around. But yeah maybe we can start up a new thread just so folks looking for lighting detector info aren't confused by our 433mhz talk.  :-P There's some good info in your posts however, wondering if mod could move them to a new thread?

Offline nincehelser

  • Forecaster
  • *****
  • Posts: 3337
Re: New Acurite Lightning Detector
« Reply #12 on: October 05, 2016, 07:14:58 PM »
I don't have a lightning sensor yet, but I do have all the parts lying around for setting up a 433_RTL setup on a Pi.

It would be nice if someone could post a "quickstart" tutorial on getting things set up and running.  It might get me motivated.

 :-P

Offline Bushman

  • Forecaster
  • *****
  • Posts: 7549
    • Eagle Bay Weather
Re: New Acurite Lightning Detector
« Reply #13 on: October 05, 2016, 09:57:27 PM »
Need low cost IP monitoring?  http://wirelesstag.net/wta.aspx?link=NisJxz6FhUa4V67/cwCRWA or PM me for 50% off Wirelesstags!!

Offline nincehelser

  • Forecaster
  • *****
  • Posts: 3337
Re: New Acurite Lightning Detector
« Reply #14 on: October 05, 2016, 10:06:52 PM »
This is a good place to start:  https://cdn-learn.adafruit.com/downloads/pdf/freq-show-raspberry-pi-rtl-sdr-scanner.pdf

Thanks, but I was thinking more of the RTL_433 specific stuff.

Offline nincehelser

  • Forecaster
  • *****
  • Posts: 3337
Re: New Acurite Lightning Detector
« Reply #15 on: October 05, 2016, 11:19:46 PM »
OK.  I've got it installed and initially running.

Here are my notes for compiling and installing.  Use them at your peril...  There could be typos or I could have forgotten something.

Problem: you have to be root or use sudo to execute the final rtl_433 command.  I thought I compiled with what I needed for a non-root user to run it, but apparently not.

Assumptions: Fresh installation of Raspbian Jessie

Install some packages we'll need:

Code: [Select]
$sudo apt-get install git
$sudo apt-get install cmake
$sudo apt-get install libusb-1.0-0-dev


Make a directory for a local git repository, then clone the source code we need:

Code: [Select]
$mkdir git
$cd git
 
$git clone git://github.com/merbanan/rtl_433
$git clone git://git.osmocom.org/rtl-sdr.git


Compile and install rtl-sdr:
 
Code: [Select]
$cd rtl-sdr
$mkdir build
$cd build
$cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON
$make
$sudo make install
$sudo ldconfig


Switch to the rtl_433 directory and compile and install.

Code: [Select]
$cd ..
$cd ..
$cd rtl_433
$mkdir build
$cd build
$cmake ../
$make
$sudo make install


Go to your home directory and do an initial test:

Code: [Select]
$cd ~
$sudo rtl_433 -G


I'm getting data... more than I expected, though.  I see my 5n1, but I also seem to be getting a lot of data from a "Danfoss CFR Thermostat".  Must be from a neighbor...

Offline tandy1000

  • Contributor
  • ***
  • Posts: 107
Re: New Acurite Lightning Detector
« Reply #16 on: October 05, 2016, 11:33:16 PM »
And here I was trying not to hijack George's lighting thread with 433 noise. :grin:  Ah well. That looks about right to me, though there's a slightly later version of libusb at libusb.info. The only other thing I had to do on my RasPi was disable the auto loading of some other devices such that detection of the rtl-sdr survives a reboot:

create /etc/modprodbe.d/no-rtl.conf :
        blacklist dvb_usb_rtl28xxu
        blacklist rtl2832
        blacklist rtl2830

Indeed it picks up a lot of stuff, amazing how much is in this frequency range!

Offline nincehelser

  • Forecaster
  • *****
  • Posts: 3337
Re: New Acurite Lightning Detector
« Reply #17 on: October 05, 2016, 11:38:58 PM »
Here's the hardware I'm using in case someone wants to pick up something they know will work:

https://www.amazon.com/gp/product/B009U7WZCA

 [ You are not allowed to view attachments ]

Offline nincehelser

  • Forecaster
  • *****
  • Posts: 3337
Re: New Acurite Lightning Detector
« Reply #18 on: October 06, 2016, 12:39:27 AM »
OK.  Here's a question about RTL_433.

If I specify protocol 09, I just see my 5n1 data, nice and simple.

However, if I specify protocol 39, which includes the lighting sensor, the 5n1 data is repeated 3 times.

Is that because the 5n1 is actually transmitting the data 3 times, or is it something with how the program is decoding the data?

Offline mwall

  • Contributor
  • ***
  • Posts: 135
Re: New Acurite Lightning Detector
« Reply #19 on: October 06, 2016, 08:03:13 AM »
OK.  Here's a question about RTL_433.

If I specify protocol 09, I just see my 5n1 data, nice and simple.

However, if I specify protocol 39, which includes the lighting sensor, the 5n1 data is repeated 3 times.

Is that because the 5n1 is actually transmitting the data 3 times, or is it something with how the program is decoding the data?

i see the same behavior.  have not had time to track down the source, so for now i made the weewx-sdr driver drop duplicate packets.

https://github.com/matthewwall/weewx-sdr

m

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #20 on: October 06, 2016, 02:46:29 PM »
If anyone here wants to create an rtl_433 topic (or group)   Just let us know and I will gladly respond there.   For what it's worth, rtl_433 handles more than Acurite devices.  I use it with Acurite, LaCrosse, and DSC security devices.   (There is also support for a number of weather devices from other manufacturers as well as many non-weather devices.)

OK.  Here's a question about RTL_433.

If I specify protocol 09, I just see my 5n1 data, nice and simple.

However, if I specify protocol 39, which includes the lighting sensor, the 5n1 data is repeated 3 times.

Is that because the 5n1 is actually transmitting the data 3 times, or is it something with how the program is decoding the data?

Yes, that was intentional.  First let me point out that protocol 39, (-R 39) handles the tower sensor, the 5-n-1, and lightning detector.  (The lightning detector support is still very preliminary.)

Be aware that there is a difference in wind direction interpretation between the original protocol 9 implementation, and my re-implementation.   Protocol 9 does a straight circular mapping.  Some people seem to feel that is correct.   Protocol 39 does a mapping using a modified gray code that matches the old aculink reporting and my 01512 display.   I believe some of the aculink parsers (ipwx, haculink, etc.) went through the same discovery process.  I don't know if there are two versions of the 5-n-1, or if the people who feel the original circular mapping is correct just haven't noticed.

Also, at times I've been suspicious that the wind speed formula is incorrect.  I haven't had a chance to do a good comparison now that my aculink has been migration to a smartHub to see if it is off, or it's a difference in averaging/smoothing.  Currently both decoders use the same code.
 
Regarding suppressing duplicate messages: The Acurite devices send the message multiple times in each message burst.  In a number of cases, the received signal strength indicator on acurite gear is not the actual signal level, or signal-to-noise ratio, but is an attempt indication of quality judging by the number of times the message was heard.    Note: IIRC, Protocol 9 will suppress duplicates, but assumes that only a single 5-n-1 will ever be heard.

I, and many others, running rtl_433 take the output of rtl_433 and pipe it into the something else to deal with storage, graphing, alerting, etc.  At this point my primary storage and graphing is RRDtool.  I've been thinking I should look into replacing or agumenting that with WeeWx, or something else, but I haven't done any research yet.

The consensus at this point is that rtl_433 should generally be handling the radio, demodulation, and decoding.   It's up to the consumers of the data to figure out if they want to suppress duplicates, or count them, do unit conversions, averaging, smoothing, etc.   Many of the newer decoders output structured data in your choice of CSV, JSON, or key-value pairs, and don't do duplicate suppression.   Some of the old decoders, would print the first message received, and ignore others received at the same time assuming those were duplicates.  With some of the protocols, there isn't enough error detection to be confident that a message has been correctly decoded.

Hope this helps,
--Rob



Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #21 on: October 06, 2016, 02:56:59 PM »

i see the same behavior.  have not had time to track down the source, so for now i made the weewx-sdr driver drop duplicate packets.

https://github.com/matthewwall/weewx-sdr

m

@mwall:

Cool.  Thanks for that.  I wasn't aware there was a weewx driver for rtl_433 yet.  I'll have to check that out.

I'll give you a heads up if I change any of the Acurite code. Are you watching the merbanan/rtl_433 github repo for changes?   I hope the structured data conversion doesn't cause too much churn with your code.  Unfortunately there aren't releases yet that could say you support.  Hopefully that will happen soon.

Also if you haven't you might want to join the rtl_433 google group.  The traffic is pretty low.


Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #22 on: October 06, 2016, 03:12:29 PM »
Here's the hardware I'm using in case someone wants to pick up something they know will work:

https://www.amazon.com/gp/product/B009U7WZCA

 [ You are not allowed to view attachments ]

For rtl_433, any of these NooElec, or RTL-SDR blog units should be fine.  I'm using two of the NooElec units for rtl_433.

If you haven't bought one yet, and think you'd might use it for other stuff too, I'd recommend one of the units with an SMA connector and a low PPM oscillator or TCXO.  They are only a few bucks more. 

There is a lot of good info on http://www.rtl-sdr.com/, including reviews and buyers guides.  At the moment, if I were buying one, I'd probably get the RTL-SDR Blog v3 unit with the 2 antennas, but they are out of stock on Amazon at the moment.




Offline nincehelser

  • Forecaster
  • *****
  • Posts: 3337
Re: New Acurite Lightning Detector
« Reply #23 on: October 06, 2016, 03:21:46 PM »
Protocol 9 does a straight circular mapping.  Some people seem to feel that is correct.   Protocol 39 does a mapping using a modified gray code that matches the old aculink reporting and my 01512 display.   I believe some of the aculink parsers (ipwx, haculink, etc.) went through the same discovery process.  I don't know if there are two versions of the 5-n-1, or if the people who feel the original circular mapping is correct just haven't noticed.

I'm pretty sure there's only the gray-code mapping.  It comes from a plastic optical encoder disc inside the 5n1.  It wouldn't make a lot of sense for them to change that for different production runs.

In any case, it's really easy to fool yourself that the "circular" mapping sorta works, but when you really look at it in a detailed, methodical fashion, the gray-code version is correct.

Quote
Regarding suppressing duplicate messages: The Acurite devices send the message multiple times in each message burst.  In a number of cases, the received signal strength indicator on acurite gear is not the actual signal level, or signal-to-noise ratio, but is an attempt indication of quality judging by the number of times the message was heard.    Note: IIRC, Protocol 9 will suppress duplicates, but assumes that only a single 5-n-1 will ever be heard.

Hmm... on the displays they subtract a bar every time an expected data packet is missed, when it drops to zero then the display starts rescanning. 

On the bridge/SmartHUB, there's an analog voltage on the RSSI pin of the radio module that represents the signal strength.  I don't know the details of how they are computing that, but the bridge's microcontroller converts that into an integer up to 4.

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #24 on: October 06, 2016, 03:25:12 PM »
OK.  I've got it installed and initially running.

Here are my notes for compiling and installing.  Use them at your peril...  There could be typos or I could have forgotten something.

Problem: you have to be root or use sudo to execute the final rtl_433 command.  I thought I compiled with what I needed for a non-root user to run it, but apparently not.

The UDEV rules you installed should fix that, but probably want take effect until after a reboot.

Quote
Compile and install rtl-sdr:
 
Code: [Select]
$cd rtl-sdr
$mkdir build
$cd build
$cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON
$make
$sudo make install
$sudo ldconfig


The above steps should take care of the device ownership, because it's installing a UDEV rule to deal with permissions.  Suggest rebooting here.


Quote
I'm getting data... more than I expected, though.  I see my 5n1, but I also seem to be getting a lot of data from a "Danfoss CFR Thermostat".  Must be from a neighbor...

Yes, that can happen.  Also, some protocols are prone to false positives.

To narrow things down, just enable the protocols you need.  Here are all the Acurite protocols

Code: [Select]
$ rtl_433 -q -R 10 -R 11 -R 39 -R 40 -R 54

I didn't enable 9, since the 5-n-1 is also covered by 39.

If you want to see the protocol numbers:

Code: [Select]
$ ./src/rtl_433 --help 2>&1 | egrep -i acurite
    [09]* Acurite 5n1 Weather Station
    [10]* Acurite 896 Rain Gauge
    [11]  Acurite 609TXC Temperature and Humidity Sensor
    [39]* Acurite 592TXR Temp/Humidity, 5n1 Weather Station, 6045 Lightning
    [40]* Acurite 986 Refrigerator / Freezer Thermometer
    [54]  Acurite 606TX Temperature Sensor