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