Did you set rapidfire = true in the [StdRESTful] [[Wunderground]] section of
your weewx.conf file?
# Set the following to True to have weewx use the WU "Rapidfire"
# protocol. Not all hardware can support it. See the User's Guide.
rapidfire = false
-----
Tom
> On Apr 10, 2019, at 1:41 PM, Leon Shaner <[email protected]> wrote:
>
> Working my way through one issue at a time with my new setup on RPI.
>
> With yesterday's fix for the the "non-positive" interval, my weewx started
> processing archive data from the WMR300A unit (going back to 2016), with the
> occasional datapoint from 2012 (which I suppose come from times that the unit
> was reset without batteries installed, since there were several 2012 dates at
> the beginning, then 2016 dates, then 2012 again, then 2016, which was
> processing at about 1 minutes worth, every 1 second, on my rather slow RPI
> Zero WH).
> Figured I would just let that catch up, however long it takes, even though I
> don't really care about data that far back.
>
> Meanwhile, that's just some of the history. I decided to move on to the
> really important stuff, now that the software appears to be working at the
> RPI <- WMR300A level. =D
>
> While the archive data backlog was being processed, I decided to check
> WUnderground to see if data was coming in and found that it was NOT.
>
> In the logs I can see:
>
> Apr 10 10:50:58 nixie weewx[2336]: restx: Wunderground-RF: Data for station
> KMIDEARB5 will be posted
>
>
> But no complaints about WU, despite the fact that no data was showing on the
> WU side.
> Likewise, there are also no proof-positive messages about posting
> successfully to WU. :S
>
> I decided to change to debug = 1 to see what is going on.
> For that I did a "sudo kill -HUP {pid}" where {pid} is the process ID of the
> weewxd process. I was happy to see that the kill -HUP convention worked for
> re-reading the conf file.
> Yay, you guys rock! =D
>
> Unexpectedly, the backlog archive processing from 2016 stopped after the HUP.
> After the HUP, I saw:
>
> Apr 10 13:58:37 nixie weewx[2336]: wmr300: reading records since 2018-12-31
> 06:16:00 EST (1546254960) (last_index=31 latest_index=32736)
>
> And unlike before when processing the 2016 data there aren't any
> minute-by-minute messages (displayed roughly once a second).
> No matter, I didn't care about the very old archive data anyway. :-/
>
> But still, there was no change in the Rapidfire posting to WU -- no data
> showing on the WU side.
>
> I had a look in the restx.py code and saw this mention:
> # The default is to not do an archive post if a rapidfire post
> # has been specified, but this can be overridden
> do_rapidfire_post = to_bool(_ambient_dict.pop('rapidfire', False))
> do_archive_post = to_bool(_ambient_dict.pop('archive_post',
> not do_rapidfire_post))
>
>
>
> So I took the hint and added this to my conf file:
>
> # Override default behavor and archive_post even when rapidfire = True
> archive_post = True
>
>
> Did another kill -HUP {pid} on weewxd, and now I see:
>
> Apr 10 13:58:37 nixie weewx[2336]: restx: Wunderground-PWS: Data for station
> KMIDEARB5 will be posted
> Apr 10 13:58:37 nixie weewx[2336]: restx: Wunderground-RF: Data for station
> KMIDEARB5 will be posted
>
>
> Great! =D
> (I guessed correctly, how to override the behavior)...
>
> And now I do see data being posted to WU. Yay!
> But I still want Rapidfire...
>
> Unexpectedly, after forcing the Wunderground-PWS on even when (attempting)
> using Wunderground-RF, now I do see positive-confirmation log messages about
> RF working!
>
> Apr 10 14:19:16 nixie weewx[2336]: restx: Wunderground-RF: Published record
> 2019-04-10 14:19:16 EDT (1554920356)
> Apr 10 14:19:16 nixie weewx[2336]: restx: Wunderground-RF: Published record
> 2019-04-10 14:19:16 EDT (1554920356)
> Apr 10 14:19:16 nixie weewx[2336]: restx: Wunderground-RF: Published record
> 2019-04-10 14:19:16 EDT (1554920356)
>
>
> I'm just happy that Rapidfire is now working! =D
>
> But can anybody explain why forcing PWS mode on was necessary for RF to start
> working?
>
> Or could it be that RF wasn't firing, because of the very old archive data
> processing? e.g. does restrx.py expect to be caught up on archive data
> before posting via RF?
>
> I half wondered if the kill -HUP (to turn on debug) which unexpectedly
> stopped processing the 2016 archive data might have been the key, moreso than
> forcing PWS mode on?
>
> Thoughts?
>
> --
> 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]
> <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
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].
For more options, visit https://groups.google.com/d/optout.
