I have the same sensor so I just did your experiment...
I would agree the sensor seems to now report a model of Acurite-606TX
today, or at least mine does. If you set debug=2 and run weewx you'll see
syslog entries like the following that pretty clearly indicates that the
model isn't known to the driver:
May 21 09:50:05 pi4p2 weewx[10114] DEBUG user.sdr: lines=['{"time" :
"2021-05-21 17:50:01", "model" : "Acurite-606TX", "id" : 240, "battery_ok"
: 0, "temperature_C" : 15.000, "mic" : "CHECKSUM"}\n']
May 21 09:50:05 pi4p2 weewx[10114] DEBUG user.sdr: parse_json: unknown
model Acurite-606TX
May 21 09:50:05 pi4p2 weewx[10114] DEBUG user.sdr: punt unrecognized
line '{"time" : "2021-05-21 17:50:01", "model" : "Acurite-606TX", "id" :
240, "battery_ok" : 0, "temperature_C" : 15.000, "mic" : "CHECKSUM"}#012'
The docs for the driver also pretty clearly indicate what to do if you see
this. Either add a new stanza to the driver or edit the one that is there.
What I did was change the IDENTIFIER in the Acurite606TxPacket(Packet)
routine in sdr.py to match what my hardware was emitting. Worked fine for
me..
I was also picking up lots of other sensors and stations around me so I
limited what the driver was listening for by using the -R 55 option in my
config ala:
[SDR]
# This section is for the software-defined radio driver.
#--- check the radio is working ---
# sudo PYTHONPATH=bin python3 bin/user/sdr.py --cmd="rtl_433 -M utc
-F json"
#
# out:['{"time" : "2021-05-21 17:30:23", "model" :
"Acurite-606TX", "id" : 240, "battery_ok" : 0, "temperature_C" : 14.600,
"mic" : "CHECKSUM"}\n']
# parsed: {'dateTime': 1621618223, 'usUnits': 16,
'temperature.240.Acurite606TXPacket': 14.6,
'battery.240.Acurite606TXPacket': 1}
#
# (this sensor is '-R 55' as reported by rtl_433 if you add the -R
option above and let it find the Acurite 606TX model identifier)
#
# The driver to use
driver = user.sdr
cmd = rtl_433 -M utc -F json -R 55
[[sensor_map]]
outTemp = temperature.240.Acurite606TXPacket
Lastly the docs for the driver also definitely say what to do in the
Environment section of the readme file so that weewx can find rtl_433 on
startup. I added /usr/local/bin to the PATH at the top of
/etc/init.d/weewx (I used the old init.d startup for my test) and it worked
fine. I also ran the unmodified init.d file after adding a symlink in
/usr/bin to point to the rtl_433 binary in /usr/local/bin and 'that' woked
too....so normal $PATH rules apply for your initial problem report.
I did not specify sudo in my weewx.conf as system startup things run as
root anyway, so no sudo is required.
Bottom line - I don't see anything that's not documented in the driver
instructions, but it does take a little fiddling to get it set up.
Save your weewx.conf offsite someplace for the next time and comment the
heck out of it to explain to future-you what you did and why :-)
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/98941663-bc3a-4932-b452-2f178c9560cbn%40googlegroups.com.
