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

0 Members and 1 Guest are viewing this topic.

Offline rct

  • Member
  • *
  • Posts: 40
Re: New Acurite Lightning Detector
« Reply #25 on: October 06, 2016, 03:42:03 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.

I agree, I wouldn't think that would make sense.  I was just given those who think it is/was correct the benefit of a doubt.

Quote
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.

Agreed.

Quote
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.

Good to know, at this point, I don't remember where I got the impression that the RSSI interpretation was based on the number of successful receives.

Note on the 5-n-1, each message has a bit to indicate if it's the 1st, 2nd or 3rd copy.

Code: [Select]
// The sensor sends the same data three times, each of these have
// an indicator of which one of the three it is. This means the
// checksum and first byte will be different for each one.
// The bits 5,4 of byte 0 indicate which copy of the 65 bit data string
//  00 = first copy
//  01 = second copy
//  10 = third copy
//  1100 xxxx  = channel A 1st copy
//  1101 xxxx  = channel A 2nd copy
//  1110 xxxx  = channel A 3rd copy

The 592 tower and the 6045 lightning detector don't have this property.


Currently the decoders in rtl_433 don't have a notion of signal strength.   The Pulse Analyzer, enabled with -A, attempts to give some info based about signal levels and frequency offset.

Offline rct

  • Member
  • *
  • Posts: 40
Re: New Acurite Lightning Detector
« Reply #26 on: October 06, 2016, 03:53:31 PM »



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
[/code]

For rtl_433, it is probably irrelevant, but I've been using keenerd's rtl-sdr repo.  There are a bunch of patches and improvements to the other tools.

https://github.com/keenerd/rtl-sdr

(Add .git to that url for the clone line).

If you are interested in the changes see http://igg.kmkeen.com/

Offline mwall

  • Contributor
  • ***
  • Posts: 125
Re: New Acurite Lightning Detector
« Reply #27 on: October 06, 2016, 10:00:35 PM »
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.

my intent is to make weewx-sdr look for json output first, then fall back to text strings if it does not find json.

right now (06oct2016) the weewx-sdr driver only parses text strings from rtl_433

i would like to do it generically (i.e., using json) so that mapping observation names and sensor identifiers to database schema fields is simply a matter of entries in a configuration file.  unfortunately, not all of the rtl_433 decoders can emit json.

the mapping pattern i am using looks like this:

Code: [Select]
database_field = observation_label.sensor_identifier.packet_type
so you could distinguish between two different 5n1 clusters, or any number of t/h sensors, or a t/h acurite sensor versus a t/h hideki sensor.

that way you can listen for traffic from any number of sensors, possibly from different manufacturers, and put the results unambiguously into a single database.

another option is to combine data from multiple databases at report time; with weewx you could easily run multiple weewx instances, each with its own sdr, then combine databases at the reporting layer.

i imagine that some installations will prefer the former, others the latter.

m

Offline nincehelser

  • Forecaster
  • *****
  • Posts: 2081
    • nincehelser.com
Re: New Acurite Lightning Detector
« Reply #28 on: October 24, 2016, 01:33:46 AM »
@rct - Any new progress on the decoding of the lightning sensor?

I started taking a look at a lightning sensor device tonight (just the device, I have no display, so I'm flying blind).

Here are some things I've noticed:

There seem to be at least several message types.  They started changing fast when I put the sensor in my freezer.  They started changing fast when I took it out, too.

Temp has problems as you know.  It's translating to around 100C inside my freezer.  Maybe part of the temp is in the bits representing "message type"?

Somehow the "interference" signal needs to be accounted for.  Maybe that's a message type, but I don't understand why there would be so many message types.

The strike counter and distance don't make much sense as it doesn't seem to relate to any storm activity around me.

I guess I'll have to wait for some storm activity and see what happens.

Offline rct

  • Member
  • *
  • Posts: 40
Re: New Acurite Lightning Detector
« Reply #29 on: October 24, 2016, 01:13:07 PM »
@rct - Any new progress on the decoding of the lightning sensor?

I started taking a look at a lightning sensor device tonight (just the device, I have no display, so I'm flying blind).

I haven't been able to make too much more progress with the code.  I have some theories on the meaning of the bits, but I haven't been able to nail things down conclusively yet.  I too an flying blind.  I feel like I'm seeing behavior that I just don't understand or is just plain erratic.  I've worked out the decoding four other acurite devices and didn't have much trouble, though I had displays for those to confirm what I saw.

Hopefully now that you've got a sensor too we'll be able to compare notes and make more progress.  This will also force me to clean up my notes and share them.

Quote
Here are some things I've noticed:

There seem to be at least several message types.  They started changing fast when I put the sensor in my freezer.  They started changing fast when I took it out, too.

That's very interesting.  I haven't tried a freezer test yet.  I haven't seen enough variety in that byte to think it might be temperature.  Values I've seen are 0x11, 0x51, 0x41. 0x50.

Note: I believe the data bytes, the ones in the message between the ID bytes, and the checksum byte use parity checking, so only 7 bits are available for encoding information.  This is the same as the 5n1 and the tower.   

Did you capture the text output from rtl_433 when you did your freezer test? 

Currently I believe the 5th byte, which I'm printing as message type, is a bit mask.
  • 0x01 - Most of the time the LSB (0x01) is on, which I suspect is Battery Ok.   It went off when I dropped the voltage or current to fall below about 2.4 Vdc.  However, I've seen this bit off at a couple of other times that I don't understand
  • 0x10 - TBD
  • 0x40 - Transmitting every 8 seconds (lightning/interference detected)

Quote
Temp has problems as you know.  It's translating to around 100C inside my freezer.  Maybe part of the temp is in the bits representing "message type"?

It's possible.  I know the interpretation of temperature is completely wrong. I haven't seen the sort of incremental changes in the message type/status byte to make me suspect that it is a reading.  While I haven't done a fridge/freezer test yet, I would have expected to see some incremental changes that would be a clue for decoding.

Quote
Somehow the "interference" signal needs to be accounted for.  Maybe that's a message type, but I don't understand why there would be so many message types.

So far, I've tried observing the data when interference is present and when it's not.  I didn't see see a clear, simple bit flip that I recognized.  I don't remember if the console has an indication for interference or not, I seem to recall it doesn't.  See below about possible status bits in the "distance" byte.  The "distance byte" is where I see activity when creating interference.

Quote
The strike counter and distance don't make much sense as it doesn't seem to relate to any storm activity around me.

The strike counter, the 7th byte, has been pretty stable for me.  It increments only shorting after the unit beeps because it thinks lightning has been detected.  So I've been fairly confident about that.  The value remains the same across power ups.  I can occasionally trigger false positives by moving the sensor in very close proximity to my laptop and watch that value increment.

"Distance", the 8th byte, I'm currently guessing has both status bits and a distance (or strength?) value.  When powering up the unit, the value of distance is 0x9f, or 0x1f after removing the parity bit.  My current thinking is the lower 5 bits are the distance/strength value.   I think 0x1f indicates no value, or not valid.  My guess is that the bits 0x60 are status bits.   The spec for reporting the lightning distance is up to 25 miles or 40 km.  25 miles could be encoded in 5 bits (0x19) with a resolution of 1 mile.

I also believe there is a number of seconds delay between the beep and when the lightning strike counter is incremented.  During that time there are changes in the "distance" byte. My guess is that when the strike count is updated the "distance" byte is then valid.

Quote
I guess I'll have to wait for some storm activity and see what happens.

I have recordings from one thunderstorm.  Now that summer is over, I'm not sure when the next one will be.  It was a fairly quiet summer for us thunderstorm wise.   While we haven't had any storms, I think I've recorded output for the last several weeks or more.  I have to look through and analyze that for any clues.

One thing I've noticed is that the sensor trips into transmitting every 8 seconds every now and then, without ever beeping to indicate lightning or counting a strike.

Also, are you able to trigger any false positives with interference?

I'm interested in seeing any data you've captured.  (text output is fine since the data bytes are in each line.)

Thanks

Offline nincehelser

  • Forecaster
  • *****
  • Posts: 2081
    • nincehelser.com
Re: New Acurite Lightning Detector
« Reply #30 on: October 24, 2016, 04:23:31 PM »
I didn't record what happened during the "freezer test", but I can do it again.

What are the best command options to get what you need?
 
At the moment I'm not hearing much but my 5n1 and the lightning sensor.  My neighbor's thermostat data comes and goes.

Offline rct

  • Member
  • *
  • Posts: 40
Re: New Acurite Lightning Detector
« Reply #31 on: October 24, 2016, 07:44:38 PM »
Capturing the text output is good as it's printing all the raw bytes on each line.   I tend to use either `script -af file` to capture everything or:

Code: [Select]
rtl_433 -q -p NN -R 39 2>&1 | tee out-rtl-$(date +%Y%m%s-%H%M%S)

I'm pretty confident that the bytes are being demodulated correctly.  It's similar to the tower and the 5n1.

You could always capture the raw signal with `rtl_433 -a -t`, which will let you replay it later with -r but that can take a bit of space.




Offline nincehelser

  • Forecaster
  • *****
  • Posts: 2081
    • nincehelser.com
Re: New Acurite Lightning Detector
« Reply #32 on: October 24, 2016, 08:37:39 PM »
The attached file is actually in gzip format, not zip, so I could attach it.

Starting temp about 79F, placed in freezer at about 5F for about 10 minutes or so.

At top of the hour removed from freezer and continued monitoring where the temp was about 74F.

Hope this helps!


Offline rct

  • Member
  • *
  • Posts: 40
Re: New Acurite Lightning Detector
« Reply #33 on: October 24, 2016, 09:19:03 PM »
George, thanks for the data.   

So in the 5th byte of your data, the byte that I think is the status/message type, I only see 5 values, which isn't enough range for temperature.  1st column is number of occurrences.  2nd column is the value in hex.   3rd column is binary.  Note I believe the MSB to be used for parity.

Code: [Select]
     12 90    0b1001 0000
     18 11    0b0001 0001
    141 50    0b0101 0000
    170 cf    0b1100 1111
    180 4e    0b0100 1110

So 0x90 (0x10), 0x11, 0x50 are values I've seen in that field before, but 0xcf (0x4f) and 0x4e are new to me.    This is the progression that byte went through, where the first column is counting the number of occurrences.

Code: [Select]
     18 11
     12 90
     33 50
     81 cf
    180 4e
     89 cf
    108 50

Though it varied during what should have been the big changes in temperature, I'm not spotting any clues that make sense to me right now.


In your data, the byte that I think might be temperature had 49 different values ranging from 0x00 to 0x7d, after removing the parity bit.   That's too big of a range for a simple temperature encoding given it didn't hot enough to get to the maximum end.  So I'm still stumped on temperature.


As for the other values.  The strike counter is fixed at 5 which is plausible.  Don't know if it comes from the factory at 0 or not.   I've seen RFI generate false positives there.    The "distance" byte which probably has status bits in at least part of the upper nybble alternated between 0xc0 (0x40) and 0x60.   Though what is interesting, is it looks like it would send 0x60 for 1 transmission (message is sent 3 times), and then goes back to 0xc0 (0x40) for the next 9 - 15 transmissions.

Code: [Select]
    249 c0
      3 60
     36 c0
      3 60
     45 c0
      3 60
     23 c0
      3 60
     27 c0
      3 60
     30 c0
      3 60
     93 c0

« Last Edit: October 25, 2016, 10:41:43 AM by rct »

Offline rct

  • Member
  • *
  • Posts: 40
Re: New Acurite Lightning Detector
« Reply #34 on: October 24, 2016, 09:24:14 PM »
I went and checked the data I've been logging over the last few weeks.  I found some similar status bytes to George's that I wasn't expecting (values where the lower nybble isn't 0 or 1.

Code: [Select]
  12183 0f
  21562 11
  35632 cf
  44488 90
  61825 d1
 132089 50


I don't know what the lower nybble being 0xf represents.  My guess that the LSB (0x01) represented battery status, appears to be wrong.

Offline nincehelser

  • Forecaster
  • *****
  • Posts: 2081
    • nincehelser.com
Re: New Acurite Lightning Detector
« Reply #35 on: October 24, 2016, 09:45:50 PM »
As far as the count goes, it's always been 5.  I started reading it soon after putting in the batteries, so maybe that's from factory testing.

I haven't heard it beep or anything like that since I got it.


Offline tbrasel

  • Contributor
  • ***
  • Posts: 119
    • Northwest Arkansas Weather.com
Re: New Acurite Lightning Detector
« Reply #36 on: November 01, 2016, 03:39:21 PM »
I purchased one of these devices about a month ago & I am pleased with it. Someone mentioned about an "am radio" being just as good, I disagree now that I own both.

Was curious if anyone else here had profiled two parameters, one in which the device seems to be directional in receiving, & the other, height off the ground makes a difference toward how far the device picks-up a strike?

Best Regards
tbrasel

Bentonville Arkansas, USA
Hardware: Davis 6153 - Wireless Vantage Pro2 with FARS
Software: VWS V15.00
Website: https://www.nwarwx.com

Offline mwall

  • Contributor
  • ***
  • Posts: 125
Re: New Acurite Lightning Detector
« Reply #37 on: November 04, 2016, 01:21:28 AM »
rob,

here are more data for the lightning sensor.  let me know if there is a specific test that would help isolate the bytes.

the red light flashes every 4 or 5 seconds.  i see lines from rtl_433 every time the green light flashes, which is about every 8 seconds.  every once in awhile the thing starts beeping.

i have updated the weewx-sdr driver to recognize the lightning sensor.

do you know what the units are for distance?

m

Offline mwall

  • Contributor
  • ***
  • Posts: 125
Re: New Acurite Lightning Detector
« Reply #38 on: November 10, 2016, 10:25:23 AM »
rob,

would you consider refactoring the changes you made to rtl_433?

i think it would be better to keep the 5in1, lightning, and 592TXR output separate; getting three different types of packets for '-R 39' does not seem to be keeping with the rest of the rtl_433 design patterns.

my rtl_433 lists the following:

Registering protocol [9] "Acurite 5n1 Weather Station"
Registering protocol [10] "Acurite 896 Rain Gauge"
Registering protocol [11] "Acurite 609TXC Temperature and Humidity Sensor"
Registering protocol [39] "Acurite 592TXR Temp/Humidity, 5n1 Weather Station, 6045 Lightning"
Registering protocol [40] "Acurite 986 Refrigerator / Freezer Thermometer"
Registering protocol [54] "Acurite 606TX Temperature Sensor"

if it were refactored to the listing below, we would have much better control over the packets:

Registering protocol [9] "Acurite 5n1 Weather Station"
Registering protocol [10] "Acurite 896 Rain Gauge"
Registering protocol [11] "Acurite 609TXC Temperature and Humidity Sensor"
Registering protocol [39] "Acurite 592TXR Temp/Humidity"
Registering protocol [40] "Acurite 986 Refrigerator / Freezer Thermometer"
Registering protocol [54] "Acurite 606TX Temperature Sensor"
Registering protocol [XX] "Acurite 6045 Lightning"

then one could get just lightning packets, or just 5in1 packets.

m

Offline rct

  • Member
  • *
  • Posts: 40
Re: New Acurite Lightning Detector
« Reply #39 on: November 21, 2016, 10:10:05 AM »
rob,

would you consider refactoring the changes you made to rtl_433?

i think it would be better to keep the 5in1, lightning, and 592TXR output separate; getting three different types of packets for '-R 39' does not seem to be keeping with the rest of the rtl_433 design patterns.

[...]

then one could get just lightning packets, or just 5in1 packets.

m


Sorry for the delay, I didn't see this until now.  (I thought I was getting notified for this topic).

The rationale for the 3 acurite devices being handled by the same protocol is they use the same RF encoding with slight differences in message format that can be used to tell them apart.  If they were split into 3 separate protocols, they would still match, and all 3 would run each time.  They wouldn't output anything, but they'd do the same message envelope validate in each call back.

The ability to turn protocols on an off was added to rtl_433 to reduce CPU overhead and to ignore false positives.   The CPU overhead problem has been fixed, it used to be that every sample was iterated over for each enabled protocol.  Now the message is converted into pulses much earlier.  CPU usage on a 1st gen. RPi was then low enough that it could run with all protocols enabled.   Protocols in rtl_433 are still a bit more heavyweight then they should be.  There is some cleanup work that needs to be done there at some point.

What are the use cases where you've got multiple Acurite devices, but only want to see the output from a subset?

If you wanted to select/filter certain devices, why wouldn't that be handled in what ever consumed the output of rtl_433?

Each device type has a fixed string to identify the device type "Acurite tower sensor", "Acurite 5n1 sensor", "Acurite lightning". 

Also each devices decoded by the shared Acurite protocol 39 has a fixed ID that is on the order of 12-16 bits.  The consumer could select on that.   (A consumer might also want to select on Channel number.) 

Some of this should get easier with the conversion to structured data that will output JSON.   I think a Pull Request has recently been merged that makes the 592TXR tower sensor output JSON, but I haven't tried it yet.  I should follow suit and make the 5n1 have structured data output. 

I could see temporarily moving the lightning detector into it's own protocol because it's somewhat experimental. It's not likely to output structured data until I can get a better handle on decoding it.  Though once it's stabled, and outputting structured data, I'd probably want to put it back in the same group as the 5n1 and the tower for the reasons mentioned above.

I haven't had a chance to try WeeWx yet.  So I haven't run any of your WeeWx drivers.  I've got scripts parsing the output and putting it in RRDTool for graphing/storage and log files for other stuff (security).   I probably need to set up another rtl-sdr so I can try WeeWx without tearing down my stuff.

[rtl_433 topic - If someone familiar with the conventions for this forum sets up a topic, or an area, or whatever for rtl_433, I'd happily move this discussion there.  rtl_433 decodes other weather stations beyond Acurite.]

Offline mwall

  • Contributor
  • ***
  • Posts: 125
Re: New Acurite Lightning Detector
« Reply #40 on: November 21, 2016, 10:43:42 AM »
The rationale for the 3 acurite devices being handled by the same protocol is they use the same RF encoding with slight differences in message format that can be used to tell them apart.  If they were split into 3 separate protocols, they would still match, and all 3 would run each time.  They wouldn't output anything, but they'd do the same message envelope validate in each call back.

The ability to turn protocols on an off was added to rtl_433 to reduce CPU overhead and to ignore false positives.   The CPU overhead problem has been fixed, it used to be that every sample was iterated over for each enabled protocol.  Now the message is converted into pulses much earlier.  CPU usage on a 1st gen. RPi was then low enough that it could run with all protocols enabled.   Protocols in rtl_433 are still a bit more heavyweight then they should be.  There is some cleanup work that needs to be done there at some point.

What are the use cases where you've got multiple Acurite devices, but only want to see the output from a subset?

thanks for the explanation.  fixing the cpu overhead goes a long way toward making the selection of separate protocols moot.

however, selecting output from rtl_433 based on sensor, not protocol, is still useful.

one use case is that when i test for lightning sensor, any other sensor data just complicates things.  but that is a development use case, so not really a big deal.

the use case for support is a much bigger deal.  it is easier to explain to users "each type of sensor has its own number in rtl_433" rather than trying to explain "there are two different options for 5in1 packets, and if you just want to get lightning data you also have to get 5in1 and tower data, but not the same 5in1 data as the other 5in1"

from a user point of view, it does not matter which sensors share the same protocols, especially when the semantics of using rtl_433 are based on "choose a type of sensor" rather than "choose a protocol".  users see sensors and sensor models, not protocols or encoding/decoding.

If you wanted to select/filter certain devices, why wouldn't that be handled in what ever consumed the output of rtl_433?

Each device type has a fixed string to identify the device type "Acurite tower sensor", "Acurite 5n1 sensor", "Acurite lightning". 

Also each devices decoded by the shared Acurite protocol 39 has a fixed ID that is on the order of 12-16 bits.  The consumer could select on that.   (A consumer might also want to select on Channel number.) 

the weewx-sdr driver already does this using this construct:

database_field = <observation_name>.<sensor_identifier>.<sensor_type>

to map sensor output to fields in a database.

but once again from a user point of view, it is more difficult to filter when you're getting data from things you do not care about.

if someone is trying to set up a lightning sensor, but they're getting 5in1 packets from one neighbor and tower packets from another neighbor, that makes the configuration more difficult.

Some of this should get easier with the conversion to structured data that will output JSON.   I think a Pull Request has recently been merged that makes the 592TXR tower sensor output JSON, but I haven't tried it yet.  I should follow suit and make the 5n1 have structured data output. 

weewx-sdr will do json parsing if you ask for it from rtl_433 and the sensor parser emits json.  otherwise it falls back to parsing lines of text.

from my pov, having a stable output from the rtl_433 sensor is more important than whether that output is json or lines of text.  but it would be nice if everything did json (or nothing did json) so i don't have to maintain two different parsers for every sensor.

m

Offline rct

  • Member
  • *
  • Posts: 40
Re: New Acurite Lightning Detector
« Reply #41 on: November 21, 2016, 12:47:39 PM »

the weewx-sdr driver already does this using this construct:

database_field = <observation_name>.<sensor_identifier>.<sensor_type>

to map sensor output to fields in a database.

First, to help me understand, can you give some examples of what this configuration looks like for some of the Acurite devices?

If someone has (or can receive) more than 1 sensor, they need to be able to identify the device, right?   Typically after running for 2-3 minutes you should have seen all of the device IDs, channel numbers, etc. that would help identify the device.

What do you do for devices that change their ID's each time the batteries are changed?   (LaCrosse, some of the acurites, etc.)

Quote

from my pov, having a stable output from the rtl_433 sensor is more important than whether that output is json or lines of text.  but it would be nice if everything did json (or nothing did json) so i don't have to maintain two different parsers for every sensor.


I understand, you are in a difficult position here, with no stable (or 1.0) release  of rtL433 and things being in transition.  Benjamin (merbanan) has a plan for what he considers to be the 1.0 release criteria but hasn't shared it, yet.

The direction that has been agreed to is to try to convert all of the devices to structured output.  The expectation is that JSON ithe format that is most useful for consumers to parse, though CSV and key values pairs are also supported.  (Note: As of a month or two ago, there was a change that all devices that don't emit structured data are disabled by default.  Specifically enabling the protocol -R NN or -G is necessary to turn the deprecated one.

When a device is converted to use structured output, the old code for printing data is removed.   So I think once the decoders have been converted, you should deprecate your old parsers, they will only work with an older version of rtl_433.  Off the top of my head, I can't think of a good reason for your driver to run rtl_433 without '-F json'.   I think, but haven't given it that much thought yet, that the output you should support is JSON output for devices that support it and the legacy, pre-JSON output for devices you are interested in supporting.

Offline mwall

  • Contributor
  • ***
  • Posts: 125
Re: New Acurite Lightning Detector
« Reply #42 on: November 21, 2016, 01:06:44 PM »

the weewx-sdr driver already does this using this construct:

database_field = <observation_name>.<sensor_identifier>.<sensor_type>

to map sensor output to fields in a database.

First, to help me understand, can you give some examples of what this configuration looks like for some of the Acurite devices?

If someone has (or can receive) more than 1 sensor, they need to be able to identify the device, right?   Typically after running for 2-3 minutes you should have seen all of the device IDs, channel numbers, etc. that would help identify the device.

here are examples from the weewx-sdr readme:

Code: [Select]
# collect data from Acurite 986 fridge/freezer sensor set 1R and 2F
[SDR]
    driver = user.sdr
    [[sensor_map]]
        extraTemp1 = temperature.1R.Acurite986Packet
        extraTemp2 = temperature.2F.Acurite986Packet

# collect data from Acurite 06002RM t/h sensor 3067
[SDR]
    driver = user.sdr
    [[sensor_map]]
        inTemp = temperature.3067.AcuriteTowerPacket
        inHumidity = humidity.3067.AcuriteTowerPacket

as you noted, one must identifiy the sensors before creating the map.  you could do that by running rtl_433 directly, but if you run the weewx-sdr driver directly you get the observations, identifiers, and types in a more obvious format.

details are in the readme on github:

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

feedback is most welcome!

What do you do for devices that change their ID's each time the batteries are changed?   (LaCrosse, some of the acurites, etc.)

that is a problem for which we do not yet have a solution.

if there are no conflicting sensors, then a general match will work, for example:

Code: [Select]
outTemp = temperature_out.*.*
but if there are two sensors of the same model whose IDs change, then you have a problem.

Offline rct

  • Member
  • *
  • Posts: 40
Re: New Acurite Lightning Detector
« Reply #43 on: November 22, 2016, 06:57:53 PM »

here are examples from the weewx-sdr readme:

Code: [Select]
# collect data from Acurite 986 fridge/freezer sensor set 1R and 2F
[SDR]
    driver = user.sdr
    [[sensor_map]]
        extraTemp1 = temperature.1R.Acurite986Packet
        extraTemp2 = temperature.2F.Acurite986Packet

# collect data from Acurite 06002RM t/h sensor 3067
[SDR]
    driver = user.sdr
    [[sensor_map]]
        inTemp = temperature.3067.AcuriteTowerPacket
        inHumidity = humidity.3067.AcuriteTowerPacket


Thanks for that, I had missed that in the README.  There are several things that are interesting to me about that example.

First, the 986 Fridge/Freezer sensors -- It's great to see that someone besides me is using that.    Are you using it with weesx?   Are you using it for room temperatures or frdige/freezer/kegerator/etc.?

Note: There is a small problem with the demodulator that causes it to miss the message repeater if the final bit of the CRC is a 1.  As long as the first copy of the message is received intact there is no problem.

For the 592 Tower sensor I see you are using the device ID, which is fixed.  On the 986 I see you are using the 1R/2F designation, as the device ID.  That's essentially a fixed channel number.  (When I convert that to JSON, I'll put that info in the Chennel number.)   The 986 device has an ID (12-16 bits) but it changes at each battery change.  So unless I'm missing something, if more than 1 set of 986 sensors were in range of the receiver there would be a conflict.

I'll have to spend some time getting weewx running.





Offline tandy1000

  • Senior Member
  • **
  • Posts: 85
Re: New Acurite Lightning Detector
« Reply #44 on: November 26, 2016, 11:39:20 PM »
I finally sat down last night to update my code for the SmartHub. Guess I should have done that some time ago, given now nicely parseable it is. I now have 2 Room Monitors with the leak detectors, plus one of the outdoor sensors and the spot-check sensor attached. I believe I have 17 sensors in total if you count my neighbor's 3N1.  :shock: :-P

I'm now ready to participate in anything rtl_433 related; looks like there is still work to do with the lightning detector? Given the seasonal change, is it feasible to decode w/o actual lightning? George, I see you looked at the chip specs, wondering if it's possible to simulate whatever the chip is trying to detect.


Offline n7qnm

  • Member
  • *
  • Posts: 3
Re: New Acurite Lightning Detector
« Reply #45 on: February 17, 2017, 02:19:45 PM »
I've got one of these and the temperature reading isn't correct.   It's been in my shop all day, where the temp is a pretty constant 73 degrees F.   I put fresh batteries in it this morning, and the "temperature" that RTL-433 returns stared at 2 and has now risen to 27.

I'm using WeeWx and Matt Wall's SDR driver.

Can someone confirm that this combination SHOULD be working, before I call Acurite?

Thanks!

Clay Jackson

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 714
  • K2BIG
Re: New Acurite Lightning Detector
« Reply #46 on: February 17, 2017, 02:55:28 PM »
Did you try running rtl_433 standalone to see what it is receiving?  Have you updated rtl_433 in the past month, since the change to JSON?????
WU Gold Stars for everyone! :lol:

Offline tbrasel

  • Contributor
  • ***
  • Posts: 119
    • Northwest Arkansas Weather.com
Re: New Acurite Lightning Detector
« Reply #47 on: February 17, 2017, 03:14:09 PM »
The temperature on mine is off by around 3 degrees or just a hair less.

Although I purchased it for the lightning detection, which works well for myself.
Best Regards
tbrasel

Bentonville Arkansas, USA
Hardware: Davis 6153 - Wireless Vantage Pro2 with FARS
Software: VWS V15.00
Website: https://www.nwarwx.com

Offline n7qnm

  • Member
  • *
  • Posts: 3
Re: New Acurite Lightning Detector
« Reply #48 on: February 17, 2017, 05:24:08 PM »
Thanks for the responses!   Yes, I'm using the JSON version of rtl; and, if I look at the raw data,it's doing the same rise (in C, of course). 

In any case, talked to Acurite, they asked for the QC number on the battery cover, and then said "we'd like to send you a new one".  So, apparently something's going on.   I asked the tech and all she said was, "we have a number of sensors from this lot behaving this way, don't know why".

Clay

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 714
  • K2BIG
Re: New Acurite Lightning Detector
« Reply #49 on: February 17, 2017, 06:57:02 PM »
Out of curiosity, what was the magic QC number?????
WU Gold Stars for everyone! :lol:

 

anything