Author Topic: Wunderground Rapid Fire  (Read 4434 times)

0 Members and 1 Guest are viewing this topic.

Offline wxwatching

  • Member
  • *
  • Posts: 14
Wunderground Rapid Fire
« 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

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 809
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #1 on: January 12, 2017, 06:04:34 PM »
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.....
WU Gold Stars for everyone! :lol:

Offline wxwatching

  • Member
  • *
  • Posts: 14
Re: Wunderground Rapid Fire
« Reply #2 on: January 13, 2017, 08:15:26 AM »
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

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 809
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #3 on: January 13, 2017, 07:38:46 PM »
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.....
WU Gold Stars for everyone! :lol:

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 809
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #4 on: January 13, 2017, 07:41:21 PM »
Here's a little more info, from the Acu-Rite section here:

http://www.wxforum.net/index.php?topic=31068.0
WU Gold Stars for everyone! :lol:

Offline mwall

  • Contributor
  • ***
  • Posts: 126
Re: Wunderground Rapid Fire
« Reply #5 on: January 13, 2017, 10:29:34 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?

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

Offline mwall

  • Contributor
  • ***
  • Posts: 126
Re: Wunderground Rapid Fire
« Reply #6 on: January 13, 2017, 10:35:25 PM »
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.

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 809
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #7 on: January 14, 2017, 10:22:22 AM »
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.....
WU Gold Stars for everyone! :lol:

Offline mwall

  • Contributor
  • ***
  • Posts: 126
Re: Wunderground Rapid Fire
« Reply #8 on: January 14, 2017, 10:33:38 AM »
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.

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 809
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #9 on: January 14, 2017, 11:31:08 AM »
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:

Code: [Select]
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.....
WU Gold Stars for everyone! :lol:

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 809
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #10 on: January 14, 2017, 11:39:00 AM »
As a side note, this is my sensor maps from /etc/weewx/weewx.conf:

Code: [Select]
[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

WU Gold Stars for everyone! :lol:

Offline mwall

  • Contributor
  • ***
  • Posts: 126
Re: Wunderground Rapid Fire
« Reply #11 on: January 14, 2017, 11:41:51 AM »
but here is what syslog had from the last crash a few days ago:

Code: [Select]
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.

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 809
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #12 on: January 14, 2017, 03:09:34 PM »
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

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.....
WU Gold Stars for everyone! :lol:

Offline mwall

  • Contributor
  • ***
  • Posts: 126
Re: Wunderground Rapid Fire
« Reply #13 on: January 14, 2017, 03:35:59 PM »
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.

Offline wxwatching

  • Member
  • *
  • Posts: 14
Re: Wunderground Rapid Fire
« Reply #14 on: January 14, 2017, 04:16:02 PM »
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

Offline mwall

  • Contributor
  • ***
  • Posts: 126
Re: Wunderground Rapid Fire
« Reply #15 on: January 14, 2017, 04:45:19 PM »
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

Offline wxwatching

  • Member
  • *
  • Posts: 14
Re: Wunderground Rapid Fire
« Reply #16 on: January 14, 2017, 04:50:27 PM »
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

Offline mwall

  • Contributor
  • ***
  • Posts: 126
Re: Wunderground Rapid Fire
« Reply #17 on: January 14, 2017, 04:50:42 PM »
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 :)

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 809
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #18 on: January 14, 2017, 05:34:28 PM »
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? ;)



FWIW, the clock on my Pi is synced by NTP, and appears to be correct.....
WU Gold Stars for everyone! :lol:

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 809
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #19 on: January 14, 2017, 08:29:35 PM »
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:

Code: [Select]
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.]
« Last Edit: January 14, 2017, 08:56:04 PM by vreihen »
WU Gold Stars for everyone! :lol:

Offline wxwatching

  • Member
  • *
  • Posts: 14
Re: Wunderground Rapid Fire
« Reply #20 on: January 14, 2017, 10:22:29 PM »
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
Quote
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

Offline mwall

  • Contributor
  • ***
  • Posts: 126
Re: Wunderground Rapid Fire
« Reply #21 on: January 14, 2017, 10:49:24 PM »
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.

Offline mwall

  • Contributor
  • ***
  • Posts: 126
Re: Wunderground Rapid Fire
« Reply #22 on: January 16, 2017, 10:58:48 AM »
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

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 809
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #23 on: January 16, 2017, 02:37:31 PM »
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.....
 
WU Gold Stars for everyone! :lol:

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 809
  • K2BIG
Re: Wunderground Rapid Fire
« Reply #24 on: January 16, 2017, 03:59:01 PM »
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.....
WU Gold Stars for everyone! :lol: