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].
For more options, visit https://groups.google.com/d/optout.
