WXforum.net
Weather Software => WeeWX Software => Topic started by: wxwatching on January 12, 2017, 01:34:31 PM
-
I have setup Weewx on RPi2 running Raspbian Jessie. I have an Acurite 5-in-1 with the model 01036 console display. Wunderground is configured but since switching over to Weewx from VIS Reader, the data reported to Wunderground is inconsistent. I have rapid fire option set to true. Any thoughts on how to get a consistent reporting of the data? You can take a look at the weather station here:
https://www.wunderground.com/personal-weather-station/dashboard?ID=KNCDUNN5#history/tdata/s20170112/e20170112/mdaily
Regards,
AB
-
For what it's worth, I just set up a very similar set up except I'm using an SDR instead of the Acu-Rite console for input. When I enabled WU rapid fire in weewx, it seemed like WU was only receiving half the record every time it sent an update. WU also seemed like it was having a nervous breakdown, as if it was receiving three different stations' updates at the same time. (With WU's other recent problems, who knows if this was weewx or just another WU glitch?)
Anyway, I have not dug into it any deeper at the moment, but turning off rapid fire at least got it to upload complete records. I recall reading something in the manual about certain weather stations not being supported in rapid fire mode, and it would probably be worth checking to see if the Acu-Rite USB consoles are among them.....
-
I have since heard there is a solution to the problem and will be available in a future release of Weewx. You mentioned you don't use the console but SDR. Do you have any detailed info on that setup and have you found it better than using Acurite's console.
Regards,
AB
-
I am currently feeding WU using a USB-connected 1035 console connected to MeteoBridge. The barometer module in the console is fried, and I don't want to spend another dime on the current generation of Acu-Rite hardware. (I also have a smartHUB, but it stopped working last fall and I haven't been motivated to try and bring it back from the dead yet again.)
Ironically, setting up the Pi and using an SDR means that I don't have a barometer again! I purchased a BMP-280 i2c module, and hooked it up inside the Pi. The Acu-Rite SDR interface that I'm using is not 100% reliable, and more or less weewx needs to be re-started every few days. One of the issues I believe is that the rain counter goes back to zero, and the driver seems have issues handling that situation.
As long as your console is working fine via USB, I would suggest just sticking with that instead of tinkering with the SDR stuff until it matures a bit more.....
-
Here's a little more info, from the Acu-Rite section here:
http://www.wxforum.net/index.php?topic=31068.0 (http://www.wxforum.net/index.php?topic=31068.0)
-
I have setup Weewx on RPi2 running Raspbian Jessie. I have an Acurite 5-in-1 with the model 01036 console display. Wunderground is configured but since switching over to Weewx from VIS Reader, the data reported to Wunderground is inconsistent. I have rapid fire option set to true. Any thoughts on how to get a consistent reporting of the data?
some weather station hardware sends 'complete' packets - a value for every sensor in each data transmission. other hardware sends 'partial' packets - a subset of all sensor readings in each transmission.
the acurite consoles emit partial packets. the sdr picks up individual sensors, so it too emits partial packets. (all of the wmr stations emit partial packets too)
wu rapidfire does not know how to handle partial packets.
there was a patch applied to weewx in november 2016 that caches data specifically to work around the wu rapidfire (mis)behavior. this patch will be in the next weewx release, or you can use it now by pulling the restx.py module from the weewx repository.
m
-
The Acu-Rite SDR interface that I'm using is not 100% reliable, and more or less weewx needs to be re-started every few days. One of the issues I believe is that the rain counter goes back to zero, and the driver seems have issues handling that situation.
is weewx crashing? please post the exception stack and log so we can diagnose and fix.
normal uptimes for weewx are measured in months or years, not days.
-
some weather station hardware sends 'complete' packets - a value for every sensor in each data transmission. other hardware sends 'partial' packets - a subset of all sensor readings in each transmission.
the acurite consoles emit partial packets. the sdr picks up individual sensors, so it too emits partial packets. (all of the wmr stations emit partial packets too)
wu rapidfire does not know how to handle partial packets.
Yup, this is exactly what I observed when I enabled rapid-fire. I was somewhat surprised that weewx did not use the last sensor readings it received to fill in the blanks for a rapid-fire post, but I'll admit that I haven't really dug into the LOOP logic to see if past sensor readings are even available at that time.....
-
some weather station hardware sends 'complete' packets - a value for every sensor in each data transmission. other hardware sends 'partial' packets - a subset of all sensor readings in each transmission.
the acurite consoles emit partial packets. the sdr picks up individual sensors, so it too emits partial packets. (all of the wmr stations emit partial packets too)
wu rapidfire does not know how to handle partial packets.
Yup, this is exactly what I observed when I enabled rapid-fire. I was somewhat surprised that weewx did not use the last sensor readings it received to fill in the blanks for a rapid-fire post, but I'll admit that I haven't really dug into the LOOP logic to see if past sensor readings are even available at that time.....
the weewx engine itself is stateless. if possible, the drivers are stateless too, but they usually have to retain some information such as rain total. the uploading services are all stateless. unfortunately, we had to add some state (caching) to deal with wu rapidfire.
normally this kind of caching is not desirable. for example, when you hook weewx up to a real-time display (e.g., using MQTT and websockets), you don't want to wait for sensor A before you see the output from sensor B. it is much better to see the observation from each sensor as soon as it is available.
-
is weewx crashing? please post the exception stack and log so we can diagnose and fix.
It seems to always stop during rain events, but I do not know if this is just coincidence or what. Even when it does run through the rain event, the rain totals it counts do not seem to match what MeteoBridge is logging from an attached Acu-Rite USB console. (Last storm was 0.13" on MB, but only 0.05 on weewx.)
Since I have my own self-butchered code in play for the barometer module and have not updated weewx or supporting packages since mid-December, I did not want to waste anyone's time asking for support until I have had a chance to update everything and get a better grasp on exactly what's happening. I'm currently running weewx in the foreground to try and capture the console output when the problem happens, but here is what syslog had from the last crash a few days ago:
Jan 11 01:15:19 WXpi3 weewx[11243]: manager: added record 2017-01-11 01:15:00 EST (1484115300) to database 'weewx'
Jan 11 01:15:19 WXpi3 rsyslogd-2007: action 'action 17' suspended, next retry is Wed Jan 11 01:16:49 2017 [try http://www.rsyslog.com/e/2007 ]
Jan 11 01:15:19 WXpi3 weewx[11243]: manager: added record 2017-01-11 01:15:00 EST (1484115300) to daily summary in 'weewx'
Jan 11 01:15:21 WXpi3 weewx[11243]: cheetahgenerator: Generated 14 files for report StandardReport in 2.09 seconds
Jan 11 01:15:22 WXpi3 weewx[11243]: genimages: Generated 12 images for StandardReport in 1.06 seconds
Jan 11 01:15:22 WXpi3 weewx[11243]: reportengine: copied 0 files to /var/www/html/weewx
Jan 11 01:17:01 WXpi3 rsyslogd-2007: action 'action 17' suspended, next retry is Wed Jan 11 01:18:31 2017 [try http://www.rsyslog.com/e/2007 ]
Jan 11 01:17:01 WXpi3 CRON[18162]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jan 11 01:20:19 WXpi3 weewx[11243]: manager: added record 2017-01-11 01:20:00 EST (1484115600) to database 'weewx'
Jan 11 01:20:19 WXpi3 rsyslogd-2007: action 'action 17' suspended, next retry is Wed Jan 11 01:21:49 2017 [try http://www.rsyslog.com/e/2007 ]
Jan 11 01:20:19 WXpi3 weewx[11243]: manager: added record 2017-01-11 01:20:00 EST (1484115600) to daily summary in 'weewx'
Jan 11 01:20:21 WXpi3 weewx[11243]: cheetahgenerator: Generated 14 files for report StandardReport in 2.13 seconds
Jan 11 01:20:22 WXpi3 weewx[11243]: genimages: Generated 12 images for StandardReport in 1.03 seconds
Jan 11 01:20:22 WXpi3 weewx[11243]: reportengine: copied 0 files to /var/www/html/weewx
Jan 11 01:21:33 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: unknown message format: '2017-01-11 06:21:33 Acurite 5n1 sensor 0x0824 Ch C, rain counter reset o
r wrapped around (old 1, new 0)#012'
Jan 11 01:21:33 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: no match for type 31: 'Wind 10 kmph / 6.2 mph 202.5° SSW (7), rain gauge -0.01 in.'
Jan 11 01:21:33 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: rain since reset: 0.0
Jan 11 01:21:33 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: no match for type 31: 'Wind 10 kmph / 6.2 mph 202.5° SSW (7), rain gauge -0.01 in.'
Jan 11 01:21:33 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: rain since reset: 0.0
Jan 11 01:21:36 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: no match for type 31: 'Wind 10 kmph / 6.2 mph 202.5° SSW (7), rain gauge -0.01 in.'
Jan 11 01:22:09 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: rain since reset: 0.01
Jan 11 01:22:09 WXpi3 rsyslogd-2007: action 'action 17' suspended, next retry is Wed Jan 11 01:23:39 2017 [try http://www.rsyslog.com/e/2007 ]
Jan 11 01:25:28 WXpi3 weewx[11243]: manager: added record 2017-01-11 01:25:00 EST (1484115900) to database 'weewx'
Jan 11 01:25:28 WXpi3 rsyslogd-2007: action 'action 17' suspended, next retry is Wed Jan 11 01:26:58 2017 [try http://www.rsyslog.com/e/2007 ]
Jan 11 01:25:28 WXpi3 weewx[11243]: manager: added record 2017-01-11 01:25:00 EST (1484115900) to daily summary in 'weewx'
Jan 11 01:25:30 WXpi3 weewx[11243]: cheetahgenerator: Generated 14 files for report StandardReport in 2.14 seconds
Jan 11 01:25:31 WXpi3 weewx[11243]: genimages: Generated 12 images for StandardReport in 1.03 seconds
Jan 11 01:25:31 WXpi3 weewx[11243]: reportengine: copied 0 files to /var/www/html/weewx
Jan 11 01:29:40 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: unknown message format: '2017-01-11 06:29:40 Acurite 5n1 sensor 0x0824 Ch C, rain counter reset o
r wrapped around (old 1, new 0)#012'
Jan 11 01:29:40 WXpi3 rsyslogd-2007: action 'action 17' suspended, next retry is Wed Jan 11 01:31:10 2017 [try http://www.rsyslog.com/e/2007 ]
Jan 11 01:29:40 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: no match for type 31: 'Wind 16 kmph / 9.9 mph 202.5° SSW (7), rain gauge -0.01 in.'
Jan 11 01:29:40 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: rain since reset: 0.0
Jan 11 01:29:40 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: no match for type 31: 'Wind 16 kmph / 9.9 mph 202.5° SSW (7), rain gauge -0.01 in.'
Jan 11 01:29:40 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: rain since reset: 0.0
Jan 11 01:29:43 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: no match for type 31: 'Wind 16 kmph / 9.9 mph 202.5° SSW (7), rain gauge -0.01 in.'
Jan 11 01:30:16 WXpi3 weewx[11243]: sdr: MainThread: Acurite5n1Packet: rain since reset: 0.0
Jan 11 01:30:16 WXpi3 weewx[11243]: engine: Shutting down StdReport thread
Jan 11 01:30:16 WXpi3 weewx[11243]: sdr: MainThread: shutdown process rtl_433 -q -U -G
Jan 11 01:30:36 WXpi3 weewx[11243]: engine: Caught unrecoverable exception in engine:
Jan 11 01:30:36 WXpi3 weewx[11243]: **** global name 'value' is not defined
Jan 11 01:30:36 WXpi3 weewx[11243]: **** Traceback (most recent call last):
Jan 11 01:30:36 WXpi3 weewx[11243]: **** File "/usr/share/weewx/weewx/engine.py", line 847, in main
Jan 11 01:30:36 WXpi3 weewx[11243]: **** engine.run()
Jan 11 01:30:36 WXpi3 weewx[11243]: **** File "/usr/share/weewx/weewx/engine.py", line 186, in run
Jan 11 01:30:36 WXpi3 weewx[11243]: **** for packet in self.console.genLoopPackets():
Jan 11 01:30:36 WXpi3 weewx[11243]: **** File "/usr/share/weewx/user/sdr.py", line 1008, in genLoopPackets
Jan 11 01:30:36 WXpi3 weewx[11243]: **** self._calculate_deltas(packet)
Jan 11 01:30:36 WXpi3 weewx[11243]: **** File "/usr/share/weewx/user/sdr.py", line 1026, in _calculate_deltas
Jan 11 01:30:36 WXpi3 weewx[11243]: **** label, pkt[label], self._counter_values.get(label))
Jan 11 01:30:36 WXpi3 weewx[11243]: **** File "/usr/share/weewx/user/sdr.py", line 1037, in _calculate_delta
Jan 11 01:30:36 WXpi3 weewx[11243]: **** " new: %s old: %s" % (label, value, last_value))
Jan 11 01:30:36 WXpi3 weewx[11243]: **** NameError: global name 'value' is not defined
Jan 11 01:30:36 WXpi3 weewx[11243]: **** Exiting.
I noticed from the changelog this morning that an update to sdr.py was posted earlier this week addressing the Acu-Rite interface, and I want to give that a shot and try to determine whether the problem is with the SDR hardware, sdr.py, or rtl_433 before formally asking for help.....
-
As a side note, this is my sensor maps from /etc/weewx/weewx.conf:
[SDR]
# This section is for the software-defined radio driver.
# The driver to use
driver = user.sdr
# log_unknown_sensors = True
# log_unmapped_sensors = True
cmd = rtl_433 -q -U -G
path = /usr/local/bin
[[sensor_map]]
windDir = wind_dir.0824.Acurite5n1Packet
windSpeed = wind_speed.0824.Acurite5n1Packet
outTemp = temperature.0824.Acurite5n1Packet
outHumidity = humidity.0824.Acurite5n1Packet
rainTotal = rain_total.0824.Acurite5n1Packet
[[deltas]]
rain = rainTotal
-
but here is what syslog had from the last crash a few days ago:
Jan 11 01:30:36 WXpi3 weewx[11243]: **** File "/usr/share/weewx/user/sdr.py", line 1037, in _calculate_delta
Jan 11 01:30:36 WXpi3 weewx[11243]: **** " new: %s old: %s" % (label, value, last_value))
Jan 11 01:30:36 WXpi3 weewx[11243]: **** NameError: global name 'value' is not defined
Jan 11 01:30:36 WXpi3 weewx[11243]: **** Exiting.
fixed at commit f33c6ef as weewx-sdr version 0.14
I noticed from the changelog this morning that an update to sdr.py was posted earlier this week addressing the Acu-Rite interface, and I want to give that a shot and try to determine whether the problem is with the SDR hardware, sdr.py, or rtl_433 before formally asking for help.....
there are some changes coming in rtl_433 that put all acurite sensor output into json format. as soon as that is stable and tested, i will update weewx-sdr to handle the new json. it will remain backward-compatible in case you have an older version of rtl_433.
-
there was a patch applied to weewx in november 2016 that caches data specifically to work around the wu rapidfire (mis)behavior. this patch will be in the next weewx release, or you can use it now by pulling the restx.py module from the weewx repository.
I just installed the above patch, along with the updated sdr.py code. After shutting down MeteoBridge and re-enabling WU rapid-fire from weewx, it appears to be sending complete posts to WU. (WU is still having spasms where it seems to be toggling between two different post records as I watch the station on WU, but that may just be them given the many other issues they've been having recently.)
https://www.wunderground.com/personal-weather-station/dashboard?ID=KNYMONTG4#history (https://www.wunderground.com/personal-weather-station/dashboard?ID=KNYMONTG4#history)
I'm going to leave weewx feeding my WU uploads for now, to see if having a working barometer gets my gold star back.
Related question - Where does WU get the weather station software information field from? I don't remember setting it, and it still reads meteobridge at the moment.....
-
Related question - Where does WU get the weather station software information field from? I don't remember setting it, and it still reads meteobridge at the moment.....
as per the wu upload protocol:
http://wiki.wunderground.com/index.php/PWS_-_Upload_Protocol
each HTTP GET includes the client identifier as 'softwaretype=weewx-x.y.z' - there is nothing for you to set.
if wu is showing meteobridge when you are uploading using weewx, then that is a wu bug.
-
you can use it now by pulling the restx.py module from the weewx repository.
I did pulled the restx.py module and re-enabled rapid fire. While it seems to have improved the consistency of the reports to WU, the wind gust data does not show any data at all in the table view. Only if I disable rapid fire does the wind gust have data. Having used VIS Reader by Valley Systems for quite some time, I never really saw an issue with the rapid fire reporting while using VIS Reader. VIS Reader also supports 18-Second Data to CSV by subscription. I assume there must be some way for it to work. I haven't yet delved too deeply into the code of Weewx, but I can appreciate those who have and have worked hard to make it what it is at present.
Thanks,
AB
-
you can use it now by pulling the restx.py module from the weewx repository.
I did pulled the restx.py module and re-enabled rapid fire. While it seems to have improved the consistency of the reports to WU, the wind gust data does not show any data at all in the table view. Only if I disable rapid fire does the wind gust have data. Having used VIS Reader by Valley Systems for quite some time, I never really saw an issue with the rapid fire reporting while using VIS Reader. VIS Reader also supports 18-Second Data to CSV by subscription. I assume there must be some way for it to work.
the acurite stations do not measure or emit windGust. so if you see windGust, then something else is fabricating that value. this explanation might help:
https://github.com/weewx/weewx/wiki/windgust
from your description, it sounds like wu fills in windGust with max(windSpeed) when you do not use rapid-fire, but does not do that when you use rapid-fire. (yet another undocumented wu behavior)
if you saw windGust when using VIS Reader and rapid-fire, then VIS Reader must have been fabricating it.
m
-
I also notice that CWOP display panel shows a wind gust, even with Weewx, and it may well be that it is taking the highest recorded wind speed.
AB
-
btw, the issues of 'what is wind gust?' and 'cache or no cache?' are not trivial. they're not rocket science, but if you're trying to record data accurately, these subtleties matter. getting it 'right' has been especially important in weewx since weewx supports so many different kinds of hardware.
it just takes us awhile since we're doing this for fun :)
-
if wu is showing meteobridge when you are uploading using weewx, then that is a wu bug.
I'm guessing that they have the uploading software name cached, and it will update itself sooner or later.
Speaking of WU bugs, this rapid-fire glitch just popped up on my station. Did WU invent time travel? ;)
(http://i791.photobucket.com/albums/yy193/vreihen/c0fd3fed-205e-4bae-84aa-43c8172f07ff_zpsmrbh9hy3.png)
FWIW, the clock on my Pi is synced by NTP, and appears to be correct.....
-
Well, that lasted a long time! #-o Both rtl_433 and weewx were running for about 3 hours, and then it seems like they stopped talking to each other despite both still running according to ps.
I decided to grab the latest rtl_433 source and re-build it to replace the 12/18/2016 version that I was running. Now, whenever I start weewx, it does not write *anything* to the console, but logged the following in syslog:
Jan 14 20:14:57 WXpi3 weewx[1741]: manager: Starting backfill of daily summaries
Jan 14 20:14:57 WXpi3 weewx[1741]: manager: Daily summaries up to date
Jan 14 20:14:57 WXpi3 weewx[1741]: restx: StationRegistry: Registration not requested.
Jan 14 20:14:57 WXpi3 weewx[1741]: restx: Wunderground-RF: Data for station KNYMONTG4 will be posted
Jan 14 20:14:57 WXpi3 weewx[1741]: restx: PWSweather: Posting not enabled.
Jan 14 20:14:57 WXpi3 weewx[1741]: restx: CWOP: Posting not enabled.
Jan 14 20:14:57 WXpi3 weewx[1741]: restx: WOW: Posting not enabled.
Jan 14 20:14:57 WXpi3 weewx[1741]: restx: AWEKAS: Posting not enabled.
Jan 14 20:14:57 WXpi3 weewx[1741]: engine: Starting up weewx version 3.6.2
Jan 14 20:14:57 WXpi3 weewx[1741]: engine: Starting main packet loop.
Jan 14 20:15:05 WXpi3 weewx[1741]: sdr: MainThread: Acurite5n1Packet: unrecognized data: '2017-01-15 01:15:05 :#011Acurite 5n1 sensor#012'
Jan 14 20:15:05 WXpi3 weewx[1741]: sdr: MainThread: Acurite5n1Packet: unrecognized data: '2017-01-15 01:15:05 :#011Acurite 5n1 sensor#012'
Jan 14 20:15:08 WXpi3 weewx[1741]: sdr: MainThread: Acurite5n1Packet: unrecognized data: '2017-01-15 01:15:05 :#011Acurite 5n1 sensor#012'
I'm falling back to the previous rtl_433 for now, and falling back to MeteoBridge WU updates again until I figure this out.....
[edit - It appears that the output format from rtl_433 has changed significantly since last month's code. I guess that's why there were sdr.py commits this week for adding JSON to the Acu-Rite driver? Since adding a -F json to the rtl_433 command didn't work with today's sdr.py, I'm staying back with the older rtl_433 until sdr.py's JSON is ready.]
-
the acurite stations do not measure or emit windGust. so if you see windGust, then something else is fabricating that value. this explanation might help:
https://github.com/weewx/weewx/wiki/windgust
from your description, it sounds like wu fills in windGust with max(windSpeed) when you do not use rapid-fire, but does not do that when you use rapid-fire. (yet another undocumented wu behavior)
if you saw windGust when using VIS Reader and rapid-fire, then VIS Reader must have been fabricating it.
Thanks for the further explanation. I also saw this explanation of Acurite by nincehelser:
http://www.wxforum.net/index.php?topic=25705.0
The "wind gust" data displayed on wunderground is a function of the software you're using to send data to wunderground. Acurite hardware does not report "wind gust", only wind speed every 18 seconds. (At the risk of getting overly-technical, the speed transmitted is the highest speed seen during the last 18-seconds using a 4-second sampling window)
What most software seems to be reporting to wunderground is the highest speed reported over the last 10 minutes. That "10 minutes" doesn't seem to be a fixed rule. Your software may use a different time period. It is noted on wunderground's upload protocol page as: "windgustmph - [mph current wind gust, using software specific time period]".
Reading over the AcuRite station data table at http://weewx.com/docs/hardware.htm#acurite, I gather that Wind Gust is neither handled by Acurite Hardware nor by Weewx or the Acurite Driver. Would there be any value in cases like this, to add as a user option in the driver to do something like stated above and calculate a "wind gust" based on the speed transmitted as the highest speed seen during the last 18-seconds using a 4-second sampling window (or such like).
I can appreciate the statement, "Accuracy is one of the primary goals of weeWX," and it is as it should be. Perhaps a calculated "wind gust" could be placed as an option to either turn on or off based on user preference.
AB
-
I can appreciate the statement, "Accuracy is one of the primary goals of weeWX," and it is as it should be. Perhaps a calculated "wind gust" could be placed as an option to either turn on or off based on user preference.
it is quite likely that windGust will be added to the list of derived values that are calculated by StdWXCalculate:
https://github.com/weewx/weewx/issues/198
so if the hardware does not provide it, weewx will calculate it.
-
I decided to grab the latest rtl_433 source and re-build it to replace the 12/18/2016 version that I was running. Now, whenever I start weewx, it does not write *anything* to the console, but logged the following in syslog:
this should be addressed by weewx-sdr version 0.15 (after commit 32f31ce)
it has json support for acurite tower and 5-in-1 packets. it does not have json support for acurite 986 or lightning packets (i'm not sure if json-ification of 986 packets has happened yet in rtl_433). it also has json support for some new hideki and lacrosse decoders.
you'll probably want to use '-F json' all the time now.
tested against rtl_433 and rtl-sdr as of 15jan2017.
hopefully rtl_433 will get a version number someday...
m
-
I just grabbed the absolute latest sdr.py and put it in place with the current rtl_433 and -F json, but it did not seem to be receiving LOOP packets. Ran sdr.py standalone (per the fine documentation), and found out that rtl_433 apparently changed from sending the sensor address in hex to decimal. Adjusted my sensor addresses, and all appears to be operating normally in JSON mode.
You may want to put a note about the sensor address changing into the sdr.py file as a gotcha. Also, the copyright year in the header comments was still listed as 2016 in the sdr.py file that I just grabbed.....
-
Ugh! That didn't last long. :( I'm generating pressure and inTemp from a Service that I wrote, since the 5-in-1 doesn't have a barometer. For some reason, the new JSON code is apparently taking "none" from the LOOP packets rather than the service's data for pressure. inTemp still seems to be working. Falling back to non-JSON, since I have an appointment that I have to leave for right now.....
-
Ugh! That didn't last long. :( I'm generating pressure and inTemp from a Service that I wrote, since the 5-in-1 doesn't have a barometer. For some reason, the new JSON code is apparently taking "none" from the LOOP packets rather than the service's data for pressure. inTemp still seems to be working. Falling back to non-JSON, since I have an appointment that I have to leave for right now.....
how are you injecting pressure into loop packets? weewx-sdr reports only what it gets from the hardware, and nothing has changed in that respect. if you add a pressure to a loop packet emitted by weewx-sdr, then something else must be modifying your pressure (is the pressure outside of the calibration limits? check the log)
weewx-sdr v0.16 should help with identifiers (commit 7907dd0): it will try to make every acurite identifier uppercase hex (instead of decimal). it also deals with some random sensor output such as 'DSC Contact ESN: FFFFFF' that recently popped up in my neighborhood (the formatting is different from other sensors).
unfortunately i cannot guarantee everything works for every type of sensor until we get actual json output from rtl_433 - and apparently my neighbors don't have that many different kinds of sensors :)
its kind of funny to see the output from tire pressure gauges when a truck drives by - it should be easy to use the identifiers to see which trucks pass regularly. or the door/window open-and-close sensors for the neighbor's security system.
m
-
how are you injecting pressure into loop packets?
Through a custom service that I hacked together, based on the example pond.py:
data_services = user.i2c.i2cService
if you add a pressure to a loop packet emitted by weewx-sdr, then something else must be modifying your pressure (is the pressure outside of the calibration limits? check the log)
Yup, that's the problem! My custom code was sending mbar and degrees C numbers, and something was converting them to inHg and degrees F. For some reason, this conversion stopped with the new rtl_433/sdr.py combo, triggering the range error. It only seems to happen with JSON mode on the newer rtl_433 binary, and feeding sdr.py from the December rtl_433 binary in non-JSON apparently did the conversions *unsolicited* to fix the wrong units.
Anyway, the behavior of today's sdr.py is correct in not trying to fix my bad data. I'll do the conversions to imperial units in my custom service code, so that it is outputting data in weewx's default units.....
Signed,
Captain Coredump :-)
-
Anyway, the behavior of today's sdr.py is correct in not trying to fix my bad data. I'll do the conversions to imperial units in my custom service code, so that it is outputting data in weewx's default units.....
your service should check the unit system of the packet/record to which it is adding data (the 'usUnits' field), and use units in that unit system. usUnits will be either weewx.METRICWX, weewx.METRIC, or weewx.US.
weewx-sdr might emit packets in METRICWX, METRIC, or US - it depends on what it gets from the sensors.
this is another inconsistency in rtl_433 that is slowly getting cleaned up. some decoders were emitting metric units, others both metric and us. rtl_433 has a flag now to indicate which units you want. i'm not sure if it works yet across all decoders.
m
-
I now obviously need to clean up my own service code to account for units.
Weewx stopped uploading to WU again overnight. Both rtl_433 and weewx were still running, and there were no errors logged in either syslog or on the console. When I went to fall back to MeteoBridge/USB again, MB had a red text warning that it had not seen a rain record in over an hour. I started up rtl_433 to check the OTA data, and sure enough my 5-in-1 wasn't sending anything but type 38 packets for the 5+ minutes that I let it run. After power-cycling the 5-in-1, both MB and rtl_433 started receiving type 31 packets again. Weewx was also happy when I re-started it after the 5-in-1 power cycle.
I am at wit's end with my Acu-Rite hardware reliability at this point, and this failure may be the last straw that forces me to ditch it all for another solution.....
-
I just made the tweak to my service code so that it is sending the expected imperial units, downloaded/installed sdr.py v0.17, and changed back to -F json. The sensor iD's are back to hex, and the pressure/inTemp from my custom service is importing properly. Keeping my fingers crossed that everything keeps running now.
Regarding the rain_total, I was running the December rtl_433 against sdr.py 0.15 all day. MeteoBridge, two Acu-Rite consoles, and even the newer rtl_433 I'm running measured 0.36 inches of rain. When I stopped weewx to do the above updates, it had only measured 0.11 inches (when the others were reading 0.34 inches). Don't know if this is another units problem or something that was already fixed in one of the supporting packages, but rain_total was under-reported by over 50% yet again. Of course it just stopped raining, so I can't test it again until mother nature cooperates..... #-o
-
We had another 0.08 inches of rain here after midnight. Both weewx and MeteoBridge finally agree with that number! Whatever was wrong with the rain_total was fixed by going JSON with the absolute latest rtl_433 (downloaded/built last night) and sdr.py 0.17.
Wish that I could say there was great joy in Whoville, but the USB link to the SDR took a dump a few hours ago:
Jan 18 04:18:07 WXpi3 kernel: [33389.799736] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.799828] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.799922] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800011] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800110] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800210] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800337] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800453] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800569] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800602] usb 1-1.4: USB disconnect, device number 4
Jan 18 04:18:07 WXpi3 kernel: [33390.036685] usb 1-1.4: new high-speed USB device number 5 using dwc_otg
Jan 18 04:18:08 WXpi3 kernel: [33390.546729] usb 1-1.4: new high-speed USB device number 7 using dwc_otg
Jan 18 04:18:08 WXpi3 kernel: [33390.658119] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=2838
Jan 18 04:18:08 WXpi3 kernel: [33390.658134] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 18 04:18:08 WXpi3 kernel: [33390.658141] usb 1-1.4: Product: RTL2838UHIDIR
Jan 18 04:18:08 WXpi3 kernel: [33390.658148] usb 1-1.4: Manufacturer: Realtek
Jan 18 04:18:08 WXpi3 kernel: [33390.658154] usb 1-1.4: SerialNumber: 00000001
Jan 18 04:18:08 WXpi3 systemd-udevd[3203]: failed to execute '/lib/udev/mtp-probe' 'mtp-probe /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4 1 7': No such file or directory
I've got a new Pi and SDR arriving tomorrow to rule out the hardware, since this does not appear to be the same issue as mentioned with earlier USB code in the sdr.py readme.....
-
We had another 0.08 inches of rain here after midnight. Both weewx and MeteoBridge finally agree with that number! Whatever was wrong with the rain_total was fixed by going JSON with the absolute latest rtl_433 (downloaded/built last night) and sdr.py 0.17.
excellent news!
Wish that I could say there was great joy in Whoville, but the USB link to the SDR took a dump a few hours ago:
Jan 18 04:18:07 WXpi3 kernel: [33389.799736] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.799828] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.799922] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800011] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800110] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800210] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800337] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800453] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800569] usb 1-1.4: usbfs: usb_submit_urb returned -121
Jan 18 04:18:07 WXpi3 kernel: [33389.800602] usb 1-1.4: USB disconnect, device number 4
Jan 18 04:18:07 WXpi3 kernel: [33390.036685] usb 1-1.4: new high-speed USB device number 5 using dwc_otg
Jan 18 04:18:08 WXpi3 kernel: [33390.546729] usb 1-1.4: new high-speed USB device number 7 using dwc_otg
Jan 18 04:18:08 WXpi3 kernel: [33390.658119] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=2838
Jan 18 04:18:08 WXpi3 kernel: [33390.658134] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 18 04:18:08 WXpi3 kernel: [33390.658141] usb 1-1.4: Product: RTL2838UHIDIR
Jan 18 04:18:08 WXpi3 kernel: [33390.658148] usb 1-1.4: Manufacturer: Realtek
Jan 18 04:18:08 WXpi3 kernel: [33390.658154] usb 1-1.4: SerialNumber: 00000001
Jan 18 04:18:08 WXpi3 systemd-udevd[3203]: failed to execute '/lib/udev/mtp-probe' 'mtp-probe /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4 1 7': No such file or directory
I've got a new Pi and SDR arriving tomorrow to rule out the hardware, since this does not appear to be the same issue as mentioned with earlier USB code in the sdr.py readme.....
that looks like a usb reset, but without a nice recovery.
thanks for the feedback!
m
-
For archival purposes, I changed the SDR hardware and weewx has run for 3 days straight (including a rain/sleet Nor'easter) with no issues. The SDR that I was originally using was online for three years straight as my Dump_1090 ADS-B decoder before that, so it was probably time to toss it anyway given how hot they run at times.
I'm confident enough in weewx's stability at this point to enable it for WU posts again in place of MeteoBridge, and hope that having the barometer back online will get my gold star back.....
-
Just checking for an update since it's been a while since this post was active. I too have an Acurite 5-in-1 sensor and am using an SDR with a NooElec RTL_SDR stick. Everything works great, but was wondering about the Rapid Fire issue, if that has been fixed. I'm using WeeWx v3.8.