Re: [weewx-user] Re: weewx stop working

[Damjan Hajsek]

Any help here please? I am stuck, nothing works.

Dne nedelja, 07. april 2019 21.57.30 UTC+2 je oseba Damjan Hajsek napisala:
>
> I have set debug = 3
> but there is all of log I have, I posted it already.
> my console is connected and working.
>
>
> Dne nedelja, 07. april 2019 20.56.17 UTC+2 je oseba vince napisala:
>>
>> On Sunday, April 7, 2019 at 11:23:59 AM UTC-7, Damjan Hajsek wrote:
>>>
>>> I have installed with setup.py.
>>> Now I am thinking to use rpm and database from old setup.
>>> Any idea what I need to do to transfer all what I need?
>>>


>> I think you need to slow down and stop changing things so we can try to 
>> help.
>>
>> I've run weewx on centos6 and centos7 from both rpm and setup.py and it 
>> works fine for the Simulator driver.
>>
>> If it previously worked and you didn't change anything, and it stopped 
>> working a few days ago, it is likely that it is not weewx nor the os.  It's 
>> more likely that you either lost connection to your database server (if it 
>> is on a second system) or to your station.   Set debug=1 in weewx.conf and 
>> restart weewx and provide more log info if it stops working again.
>>
>>
>>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Stupid question

[Greg from Oz]

Type history and hit enter and you will see what you did.

On Wednesday, 10 April 2019 07:01:39 UTC+10, Paul Bartholdi wrote:
>
> I did some thing stupid and wrong but what, probably typing to fast...
> Sorry,  what to do after this error produced when I want to restart the 
> service weewx (ubuntu). Paul
>
> manager: Starting backfill of daily summaries
> engine: Caught unrecoverable exception in engine:
>   lastUpdate(2019-04-09 22:25:00 CEST (1554841500)) > 
> lastRecord(2019-04-09 22:20:00 CEST (1554841200))
>   Traceback (most recent call last):
> File "/usr/share/weewx/weewx/engine.py", line 884, in main
>   engine = engine_class(config_dict)
> File "/usr/share/weewx/weewx/engine.py", line 78, in __init__
>   self.loadServices(config_dict)
> File "/usr/share/weewx/weewx/engine.py", line 142, in loadServices
>   self.service_obj.append(weeutil.weeutil._get_object(svc)(self, 
> config_dict))
> File "/usr/share/weewx/weewx/engine.py", line 500, in __init__
> ***  self.setup_database(config_dict)
> File "/usr/share/weewx/weewx/engine.py", line 617, in 
> setup_database
>   _nrecs, _ndays = dbmanager.backfill_day_summary() # 
> @UnusedVariable
> File "/usr/share/weewx/weewx/manager.py", line 1447, in 
> backfill_day_summary
>   timestamp_to_string(lastRecord)))
>   ViolatedPrecondition: lastUpdate(2019-04-09 22:25:00 CEST 
> (1554841500)) > lastRecord(2019-04-09 22:20:00 CEST (1554841200))
>
>  
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: make check up on data in order to auto-restart the weather console

[Pietro Benotto]

Ok. 
I'll try it as soon as I can. 

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] one computer to retrieve/store data, another to process/generate reports

[Liz]

On Tue, 9 Apr 2019 18:30:53 -0700 (PDT)
Your Name Here  wrote:

> And if someone can explain why my two topic posts haven't shown, that
> would be nice to know, too.
> 
> Thanks.

It's simple.
Gmail thinks you don't need to know about posts you have made.
We have got your emails.

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] one computer to retrieve/store data, another to process/generate reports

[Thomas Keffer]

Google thought your posts might be spam (perhaps because of your user
name??), so they were quarantined for a moderator to approve. That took a
couple days.

On Wed, Apr 10, 2019 at 3:31 AM Liz  wrote:

> On Tue, 9 Apr 2019 18:30:53 -0700 (PDT)
> Your Name Here  wrote:
>
> > And if someone can explain why my two topic posts haven't shown, that
> > would be nice to know, too.
> >
> > Thanks.
>
> It's simple.
> Gmail thinks you don't need to know about posts you have made.
> We have got your emails.
>
> --
> 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 weewx-user+unsubscr...@googlegroups.com.
> For more options, visit 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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] one computer to retrieve/store data, another to process/generate reports

[Your Name Here]

On Wednesday, April 10, 2019 at 5:31:14 AM UTC-5, Liz wrote:
>
> It's simple. 
> Gmail thinks you don't need to know about posts you have made. 
> We have got your emails. 
>

I found other people that couldn't find their posts (other groups), but 
those results were from several years ago. So I looked at the group using 
two other accounts that are unrelated to this one and the posts weren't 
showing there, either.

I had included a few more links in the original posts to give examples and 
I wonder if that is what triggered the hold. At least I was able to post a 
shortened version as a reply to my question from last month.

If my "missing" posts are going to be allowed, please use the second 
version of my question. I think it was the better version. Thanks.

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] one computer to retrieve/store data, another to process/generate reports

[Your Name Here]

On Thursday, March 14, 2019 at 4:42:59 PM UTC-5, Thomas Keffer wrote:
>
> Running WeeWX without generating reports is simple enough: just remove the 
> service weewx.engine.StdReport from the list of services to be run (option 
> report_services).
>
> Having the reports done by a separate program running on a VM is a little 
> more complicated. 
>
> The simplest option is to use wee_reports to do the report generation. You 
> could either have a crontab kick it off, or use some other signaling 
> mechanism to start wee_reports. This is completely satisfactory, except for 
> one detail: wee_reports would not have access to any new types introduced 
> by any extensions you might have. If you don't have any extensions that add 
> new types, then it's not a problem.
>

I want to thank you again for this solution. It has been working great for 
me and I'm able to try out things against current data without disrupting 
the gathering/storing of it. 

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Steel Guages and driver update question

[Steve Meltz]

G'day Gary! Its been a while. As you know I was having a memory leak
problem which seems to be coming from the driver used with my Ultimeter.
Although the memory still increases, it is much less using an old version
rather than the one included with the Weewx update. Anyway, in trying to
track things down, I uninstalled Steel Gauges and RTGD. I spent several
hours yesterday getting them to work, but I found the help included in the
rtgd.py file very useful, so thank you. I think you may have to remove the
ability to use the Wundeground API, however. Mine no longer works, and the
WU website states that they no longer support personal weather station
API's (which I think is a terrible corporate decision..we supply a lot of
their data). I signed up for DarkSky and they allow free use of an API as
long as no more than 1000 requests/day are made. I am now watching memory
growth, and my next experiment may be (I saw how to do this somewhere on
the net) to put in some code which will stop/start Weewx when the memory
use exceeds some user defined level. More fun!

Oh, as part of the re installation of the Gauges, I commented out the Steel
Gauges section in weewx.conf, and everything seems to be working just fine.
Any reason to un-comment it?

Cheers, Steve

On Wed, May 23, 2018 at 7:20 PM gjr80  wrote:

> On Thursday, 24 May 2018 08:37:50 UTC+10, Steve2Q wrote:
>>
>> Gary..its working now!! Thank you. I plugged in my zipcode,
>>
>
> That's good to hear, ended up taking a bit longer than we thought but got
> there in the end. I need to make sure I capture all of this in the rtgd
> wiki.
>
>
>> and also added units = us as it appears to default to metric.
>>
>
> Sorry, the price you pay I guess for someone from Australia writing the
> code :)
>
>
>> Now let see how long WU keeps sending out the data!
>>
>
> Yes, will be interesting to see. I have already started work on sourcing
> the forecast text from elsewhere. Would ideally like to support our own
> Bureau of Meteorology (not much use for those outside of Australia though)
> but unfortunately BoM has very restrictive copyright terms. Plenty of other
> free sources available though.
>
> Gary
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/reHbE13IoyU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> For more options, visit 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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Fresh install of weewx 3.9.1 with WMR300A on RPI, Non-positive value for record field 'interval': 0.0

[Leon Shaner]

On Tuesday, April 9, 2019 at 5:09:02 PM UTC-4, mwall wrote:
>
> On Tuesday, April 9, 2019 at 4:42:17 PM UTC-4, Leon Shaner wrote:
>>
>>
>> On Tuesday, April 9, 2019 at 4:06:26 PM UTC-4, Leon Shaner wrote:
>>>
>>> Seeing several recent posts with a similar message with WMR200, but mine 
>>> is on a new install with an WMR300A.
>>> Any solutions?
>>>
>>
> looks like the wmr300 driver needs the same fix that we gave to the wmr200 
> driver - reject any historical records that have a negative interval.
>
> fixed at commit b5240b05
>



Thanks!  This is working!  =D
https://github.com/weewx/weewx/blob/master/bin/weewx/drivers/wmr300.py

 

>
>  
>
>> I can't figure where that 2012 year is coming from.  My RPI has the 
>> correct date and timezone for my US/Eastern local time.
>> My WMR300A itself also has the correct data and timezone (E as in 
>> US/Eastern). 
>>
>
> there are probably records in the station's data logger, and apparently 
> some of them are corrupt.
>
> m 
>


I did not see an option to purge archive records in the wmr300.py driver 
and I do not know how to do it from the WMR300A itself (other than full 
factory reset, which I hope to avoid). 

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Steel Guages and driver update question

[Tom Robertson]

Hi Steve,
If you supply data to WU then you can get a new API from them. Gary has update 
RTGD to use the new API and properly display the forecast on the LED ticker.  
Here are the instructions for getting a new key:

> First, if you are not logged into Weather Underground, you will need to do 
> so.  You must log in using the same email address as the PWS.  To do that, 
> go to wunderground.com, click on “my profile”, click on “member settings”, 
> and log in if you are not already.  
>  
> Then navigate on the screen to My Profile => Member Settings => API Keys.  
>  
> If you have a PWS registered, you will see a blank box below “Your API keys”. 
>  Agree to the new Terms and Conditions by clicking in the small box next to 
> “I agree”, click on the blue “GENERATE” box, and your new key will be 
> created.  
>  
> The key will be masked on the screen, but you can use the “Show” link below 
> the box to see it.  There is also another blue box, which, when clicked, 
> copies the key to your clipboard.  Also on this page is a link to the 
> documentation. 
>  
> If you do not have a PWS registered to your email address, you will not be 
> able to get a key.  


-
Tom

> On Apr 10, 2019, at 9:39 AM, Steve Meltz  wrote:
> 
> G'day Gary! Its been a while. As you know I was having a memory leak problem 
> which seems to be coming from the driver used with my Ultimeter. Although the 
> memory still increases, it is much less using an old version rather than the 
> one included with the Weewx update. Anyway, in trying to track things down, I 
> uninstalled Steel Gauges and RTGD. I spent several hours yesterday getting 
> them to work, but I found the help included in the rtgd.py file very useful, 
> so thank you. I think you may have to remove the ability to use the 
> Wundeground API, however. Mine no longer works, and the WU website states 
> that they no longer support personal weather station API's (which I think is 
> a terrible corporate decision..we supply a lot of their data). I signed up 
> for DarkSky and they allow free use of an API as long as no more than 1000 
> requests/day are made. I am now watching memory growth, and my next 
> experiment may be (I saw how to do this somewhere on the net) to put in some 
> code which will stop/start Weewx when the memory use exceeds some user 
> defined level. More fun!
> 
> Oh, as part of the re installation of the Gauges, I commented out the Steel 
> Gauges section in weewx.conf, and everything seems to be working just fine. 
> Any reason to un-comment it?
> 
> Cheers, Steve
> 
> On Wed, May 23, 2018 at 7:20 PM gjr80  wrote:
> On Thursday, 24 May 2018 08:37:50 UTC+10, Steve2Q wrote:
> Gary..its working now!! Thank you. I plugged in my zipcode,
> 
> That's good to hear, ended up taking a bit longer than we thought but got 
> there in the end. I need to make sure I capture all of this in the rtgd wiki.
>  
> and also added units = us as it appears to default to metric.
> 
> Sorry, the price you pay I guess for someone from Australia writing the code 
> :)
>  
> Now let see how long WU keeps sending out the data!
> 
> Yes, will be interesting to see. I have already started work on sourcing the 
> forecast text from elsewhere. Would ideally like to support our own Bureau of 
> Meteorology (not much use for those outside of Australia though) but 
> unfortunately BoM has very restrictive copyright terms. Plenty of other free 
> sources available though.
> 
> Gary
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "weewx-user" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/weewx-user/reHbE13IoyU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> weewx-user+unsubscr...@googlegroups.com.
> For more options, visit 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 weewx-user+unsubscr...@googlegroups.com.
> For more options, visit 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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Question on potential enhancement to wmr300.py driver enhancement regarding host date/time -> set WMR300 date/time

[Leon Shaner]

While setting up weewx 3.9.1-1 for the first time ever, yesterday on a RPI, 
I saw some discrepant dates being reported.
That prompted me to check the date/time on the actual WMR300A, which I 
found to be more than an hour off of actual.
My RPI has the current date/time taken from NTP.
So my question is does anyone know if the WMR300A "api" allows for setting 
the date/time from the driver side?
I would like the wmr300.py driver to periodically adjust the time on the 
WMR300A if a time drift is detected.
Possible?

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Steel Guages and driver update question

[Steve Meltz]

Hi Tom. When I saw that the key I had was no longer working, I went through
the steps as stated in your email to generate a new key (I have been
registered with WU as a PWS for several years). When I plugged this new key
into the rtgd configuration,  I still had no info in the scroller. Maybe I
had to wait longer? For now, DarkSky is working and I will see how accurate
it is. I may go back to giving WU a try.

Thans, Steve

On Wed, Apr 10, 2019, 10:55 AM Tom Robertson  wrote:

> Hi Steve,
> If you supply data to WU then you can get a new API from them. Gary has
> update RTGD to use the new API and properly display the forecast on the LED
> ticker.  Here are the instructions for getting a new key:
>
> First, if you are not logged into Weather Underground, you will need to do
> so.  You must log in using the same email address as the PWS.  To do
> that, go to wunderground.com, click on “my profile”, click on “member
> settings”, and log in if you are not already.
>
> Then navigate on the screen to My Profile => Member Settings => API Keys.
>
> If you have a PWS registered, you will see a blank box below “Your API
> keys”.  Agree to the new Terms and Conditions by clicking in the small box
> next to “I agree”, click on the blue “GENERATE” box, and your new key will
> be created.
>
> The key will be masked on the screen, but you can use the “Show” link
> below the box to see it.  There is also another blue box, which, when
> clicked, copies the key to your clipboard.  Also on this page is a link to
> the documentation.
>
> If you do not have a PWS registered to your email address, you will not be
> able to get a key.
>
>
>
> -
> Tom
>
> On Apr 10, 2019, at 9:39 AM, Steve Meltz  wrote:
>
> G'day Gary! Its been a while. As you know I was having a memory leak
> problem which seems to be coming from the driver used with my Ultimeter.
> Although the memory still increases, it is much less using an old version
> rather than the one included with the Weewx update. Anyway, in trying to
> track things down, I uninstalled Steel Gauges and RTGD. I spent several
> hours yesterday getting them to work, but I found the help included in the
> rtgd.py file very useful, so thank you. I think you may have to remove
> the ability to use the Wundeground API, however. Mine no longer works, and
> the WU website states that they no longer support personal weather station
> API's (which I think is a terrible corporate decision..we supply a lot of
> their data). I signed up for DarkSky and they allow free use of an API as
> long as no more than 1000 requests/day are made. I am now watching memory
> growth, and my next experiment may be (I saw how to do this somewhere on
> the net) to put in some code which will stop/start Weewx when the memory
> use exceeds some user defined level. More fun!
>
> Oh, as part of the re installation of the Gauges, I commented out the
> Steel Gauges section in weewx.conf, and everything seems to be working just
> fine. Any reason to un-comment it?
>
> Cheers, Steve
>
> On Wed, May 23, 2018 at 7:20 PM gjr80  wrote:
> On Thursday, 24 May 2018 08:37:50 UTC+10, Steve2Q wrote:
> Gary..its working now!! Thank you. I plugged in my zipcode,
>
> That's good to hear, ended up taking a bit longer than we thought but got
> there in the end. I need to make sure I capture all of this in the rtgd
> wiki.
>
> and also added units = us as it appears to default to metric.
>
> Sorry, the price you pay I guess for someone from Australia writing the
> code :)
>
> Now let see how long WU keeps sending out the data!
>
> Yes, will be interesting to see. I have already started work on sourcing
> the forecast text from elsewhere. Would ideally like to support our own
> Bureau of Meteorology (not much use for those outside of Australia though)
> but unfortunately BoM has very restrictive copyright terms. Plenty of other
> free sources available though.
>
> Gary
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/reHbE13IoyU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> For more options, visit 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 weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/reHbE13IoyU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.goo

[weewx-user] Re: Question on potential enhancement to wmr300.py driver enhancement regarding host date/time -> set WMR300 date/time

[mwall]

On Wednesday, April 10, 2019 at 11:02:11 AM UTC-4, Leon Shaner wrote:
>
> So my question is does anyone know if the WMR300A "api" allows for setting 
> the date/time from the driver side?
> I would like the wmr300.py driver to periodically adjust the time on the 
> WMR300A if a time drift is detected.
> Possible?
>

no one has figured out how to do that yet, and it may not even be possible.

does the software that came with the station provide a way to set the 
station time from the software?  if so, then it might be possible to sniff 
the usb conversation then reverse engineer the protocol for setting the 
time.

but setting the time might be like resetting the rain counter - it is only 
possible by pushing buttons on the console.

if you could provide a list of all of the capabilities of the software that 
came with the station, that would provide us with a guide about what might 
be possible via the usb interface.  (everything we have done on the wmr300 
stations is based on sniffing the usb traffic then reverse engineering the 
protocols)

you might want to look at the comments at the beginning of wmr300.py - that 
is the best description of what we know and don't know about how those 
stations work.

(we try to do that with every driver so that everyone can benefit - even 
those who do not use weewx)

m

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Forecast from Met Office UK UKMO

[Phil Owers]

On Sunday, April 7, 2019 at 4:18:53 PM UTC+1, Phil Owers wrote:
>
> Hi All
>
> My forecast comes from the UK Met Office and I don't seem to get the full 
> forecast.
>
> If you view 
> http://sheringhamweather.ddns.net/forecast/single-stripQnap.html I just 
> get a days short summary with no forecast and looking in the forecast.sdb I 
> view what I receive
>
>
> But if I go to 
>
>
> http://datapoint.metoffice.gov.uk/public/data/val/wxfcs/all/xml/354731?res=3hourly&key=
> 8f916e8d-7477-4198-8ecc-ae764ff7bb84
>
> It shows me what I should get.
>
> Anybody help me to where Im going wrong please
>
> Thanks Phil
>
> Let me explain this another way
>
Using UK Met office  I don't get any forecast icons in the display.  
Looking under the met office 3hr definitions they send out a weather type 
an example is below
Weather types 
ValueDescription
NA Not available 
0 Clear night 
1 Sunny dayThe description goes up to a VALUE of 30

Looking in the forecast.sdb I don't see any of the above, the database has 
a clouds field name but it has a NULL value.
So my question is does anybody else download from UKMO and have the same 
problem or is it just me
Thanks Phil

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [weewx-user] Steel Guages and driver update question

[Tom Robertson]

Steve,
I assume you are using the latest RTGD version 0.3.7 released 7 days ago.  I 
found the WU forecast to be more detailed than the DarkSky forecast.

This is what my weewx.conf looks like under the [RealtimeGaugeData] [[WU]].  It 
is slightly different from before.  I believe my API key is around 32 
characters now.  Gary told me to use the PWS name instead of the coordinates 
for the location.

[[WU]]
  
api_key =
units = e
language = en-US
interval = 1800
api_lockout_period = 60
max_tries = 3
location = pws:KALALBER13
debug = 0

-
Tom

> On Apr 10, 2019, at 10:14 AM, Steve Meltz  wrote:
> 
> Hi Tom. When I saw that the key I had was no longer working, I went through 
> the steps as stated in your email to generate a new key (I have been 
> registered with WU as a PWS for several years). When I plugged this new key 
> into the rtgd configuration,  I still had no info in the scroller. Maybe I 
> had to wait longer? For now, DarkSky is working and I will see how accurate 
> it is. I may go back to giving WU a try. 
> 
> Thans, Steve 
> 
> On Wed, Apr 10, 2019, 10:55 AM Tom Robertson  > wrote:
> Hi Steve,
> If you supply data to WU then you can get a new API from them. Gary has 
> update RTGD to use the new API and properly display the forecast on the LED 
> ticker.  Here are the instructions for getting a new key:
> 
>> First, if you are not logged into Weather Underground, you will need to do 
>> so.  You must log in using the same email address as the PWS.  To do that, 
>> go to wunderground.com , click on “my profile”, 
>> click on “member settings”, and log in if you are not already.  
>>  
>> Then navigate on the screen to My Profile => Member Settings => API Keys.  
>>  
>> If you have a PWS registered, you will see a blank box below “Your API 
>> keys”.  Agree to the new Terms and Conditions by clicking in the small box 
>> next to “I agree”, click on the blue “GENERATE” box, and your new key will 
>> be created.  
>>  
>> The key will be masked on the screen, but you can use the “Show” link below 
>> the box to see it.  There is also another blue box, which, when clicked, 
>> copies the key to your clipboard.  Also on this page is a link to the 
>> documentation. 
>>  
>> If you do not have a PWS registered to your email address, you will not be 
>> able to get a key.  
> 
> 
> -
> Tom
> 
>> On Apr 10, 2019, at 9:39 AM, Steve Meltz > > wrote:
>> 
>> G'day Gary! Its been a while. As you know I was having a memory leak problem 
>> which seems to be coming from the driver used with my Ultimeter. Although 
>> the memory still increases, it is much less using an old version rather than 
>> the one included with the Weewx update. Anyway, in trying to track things 
>> down, I uninstalled Steel Gauges and RTGD. I spent several hours yesterday 
>> getting them to work, but I found the help included in the rtgd.py file very 
>> useful, so thank you. I think you may have to remove the ability to use the 
>> Wundeground API, however. Mine no longer works, and the WU website states 
>> that they no longer support personal weather station API's (which I think is 
>> a terrible corporate decision..we supply a lot of their data). I signed up 
>> for DarkSky and they allow free use of an API as long as no more than 1000 
>> requests/day are made. I am now watching memory growth, and my next 
>> experiment may be (I saw how to do this somewhere on the net) to put in some 
>> code which will stop/start Weewx when the memory use exceeds some user 
>> defined level. More fun!
>> 
>> Oh, as part of the re installation of the Gauges, I commented out the Steel 
>> Gauges section in weewx.conf, and everything seems to be working just fine. 
>> Any reason to un-comment it?
>> 
>> Cheers, Steve
>> 
>> On Wed, May 23, 2018 at 7:20 PM gjr80 > > wrote:
>> On Thursday, 24 May 2018 08:37:50 UTC+10, Steve2Q wrote:
>> Gary..its working now!! Thank you. I plugged in my zipcode,
>> 
>> That's good to hear, ended up taking a bit longer than we thought but got 
>> there in the end. I need to make sure I capture all of this in the rtgd wiki.
>>  
>> and also added units = us as it appears to default to metric.
>> 
>> Sorry, the price you pay I guess for someone from Australia writing the code 
>> :)
>>  
>> Now let see how long WU keeps sending out the data!
>> 
>> Yes, will be interesting to see. I have already started work on sourcing the 
>> forecast text from elsewhere. Would ideally like to support our own Bureau 
>> of Meteorology (not much use for those outside of Australia though) but 
>> unfortunately BoM has very restrictive copyright terms. Plenty of other free 
>> sources available though.
>> 
>> Gary
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "weewx-user" group.
>> To un

Re: Re: [weewx-user] Steel Guages and driver update question

[Steve Meltz]

Tom..Thank you! I am not sure why my 1st attempt at using my new API didn't
work. Maybe because I used my lat/long instead of my PWS ID? Anyway, you
are correct that WU is much more detailed than DS. Now to change back the
HTML file so the bottom left attributes are correct.

Steve

On Wed, Apr 10, 2019 at 1:05 PM Tom Robertson  wrote:

> Steve,
> I assume you are using the latest RTGD version 0.3.7 released 7 days ago.
> I found the WU forecast to be more detailed than the DarkSky forecast.
>
> This is what my weewx.conf looks like under the [RealtimeGaugeData]
> [[WU]].  It is slightly different from before.  I believe my API key is
> around 32 characters now.  Gary told me to use the PWS name instead of the
> coordinates for the location.
>
> [[WU]]
> api_key =
> units = e
> language = en-US
> interval = 1800
> api_lockout_period = 60
> max_tries = 3
> location = pws:KALALBER13
> debug = 0
>
> -
> Tom
>
> On Apr 10, 2019, at 10:14 AM, Steve Meltz  wrote:
>
> Hi Tom. When I saw that the key I had was no longer working, I went
> through the steps as stated in your email to generate a new key (I have
> been registered with WU as a PWS for several years). When I plugged this
> new key into the rtgd configuration,  I still had no info in the scroller.
> Maybe I had to wait longer? For now, DarkSky is working and I will see how
> accurate it is. I may go back to giving WU a try.
>
> Thans, Steve
>
> On Wed, Apr 10, 2019, 10:55 AM Tom Robertson  wrote:
>
>> Hi Steve,
>> If you supply data to WU then you can get a new API from them. Gary has
>> update RTGD to use the new API and properly display the forecast on the LED
>> ticker.  Here are the instructions for getting a new key:
>>
>> First, if you are not logged into Weather Underground, you will need to
>> do so.  You must log in using the same email address as the PWS.  To do
>> that, go to wunderground.com, click on “my profile”, click on “member
>> settings”, and log in if you are not already.
>>
>> Then navigate on the screen to My Profile => Member Settings => API Keys.
>>
>>
>> If you have a PWS registered, you will see a blank box below “Your API
>> keys”.  Agree to the new Terms and Conditions by clicking in the small box
>> next to “I agree”, click on the blue “GENERATE” box, and your new key will
>> be created.
>>
>> The key will be masked on the screen, but you can use the “Show” link
>> below the box to see it.  There is also another blue box, which, when
>> clicked, copies the key to your clipboard.  Also on this page is a link to
>> the documentation.
>>
>> If you do not have a PWS registered to your email address, you will not
>> be able to get a key.
>>
>>
>>
>> -
>> Tom
>>
>> On Apr 10, 2019, at 9:39 AM, Steve Meltz  wrote:
>>
>> G'day Gary! Its been a while. As you know I was having a memory leak
>> problem which seems to be coming from the driver used with my Ultimeter.
>> Although the memory still increases, it is much less using an old version
>> rather than the one included with the Weewx update. Anyway, in trying to
>> track things down, I uninstalled Steel Gauges and RTGD. I spent several
>> hours yesterday getting them to work, but I found the help included in the
>> rtgd.py file very useful, so thank you. I think you may have to remove
>> the ability to use the Wundeground API, however. Mine no longer works, and
>> the WU website states that they no longer support personal weather station
>> API's (which I think is a terrible corporate decision..we supply a lot of
>> their data). I signed up for DarkSky and they allow free use of an API as
>> long as no more than 1000 requests/day are made. I am now watching memory
>> growth, and my next experiment may be (I saw how to do this somewhere on
>> the net) to put in some code which will stop/start Weewx when the memory
>> use exceeds some user defined level. More fun!
>>
>> Oh, as part of the re installation of the Gauges, I commented out the
>> Steel Gauges section in weewx.conf, and everything seems to be working just
>> fine. Any reason to un-comment it?
>>
>> Cheers, Steve
>>
>> On Wed, May 23, 2018 at 7:20 PM gjr80  wrote:
>> On Thursday, 24 May 2018 08:37:50 UTC+10, Steve2Q wrote:
>> Gary..its working now!! Thank you. I plugged in my zipcode,
>>
>> That's good to hear, ended up taking a bit longer than we thought but got
>> there in the end. I need to make sure I capture all of this in the rtgd
>> wiki.
>>
>> and also added units = us as it appears to default to metric.
>>
>> Sorry, the price you pay I guess for someone from Australia writing the
>> code :)
>>
>> Now let see how long WU keeps sending out the data!
>>
>> Yes, will be interesting to see. I have already started work on sourcing
>> the forecast text from elsewhere. Would ideally like to support our own
>> Bureau of Meteorology (not much use for those outside of Australia though)
>> but unfortunately BoM has very restrictive copyright terms. Plenty of other
>> free sources available though.
>>
>> Gary
>

[weewx-user] Wunderground Rapidfire not working for WMR300A (but started working after forcing PWS mode on in addition to RF)

[Leon Shaner]

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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Wunderground Rapidfire not working for WMR300A (but started working after forcing PWS mode on in addition to RF)

[Tom Robertson]

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  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 weewx-user+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> 

[weewx-user] Re: Wunderground Rapidfire not working for WMR300A (but started working after forcing PWS mode on in addition to RF)

[Leon Shaner]

On Wednesday, April 10, 2019 at 2:41:24 PM UTC-4, Leon Shaner wrote:
>
> [snip]
> 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?
>

Oh, BOY!  :S
I thought I'd try to answer my own question by going back to "archive_post 
= False" behavior to see if RF mode stopped or continued.
Well RF mode did stop.  But confoundedly when I then went back to 
archive_post = True, RF mode stopped.
Upon further inspection, RF mode did resume about 10 minutes later:

Apr 10 14:53:24 nixie weewx[371]: wmr300: reading records since 2019-04-10 
14:45:00 EDT (1554921900) (last_index=31 latest_index=32736)
Apr 10 14:53:24 nixie weewx[371]: manager: Daily summary version is 2.0
Apr 10 14:53:24 nixie weewx[371]: manager: Daily summary version is 2.0
Apr 10 15:03:23 nixie weewx[371]: wmr300: get history complete: count=0 
last_index=32735 latest_index=32736
Apr 10 15:03:23 nixie weewx[371]: engine: Starting main packet loop.
Apr 10 15:03:24 nixie weewx[371]: wmr300: dump history is disabled
Apr 10 15:03:24 nixie weewx[371]: wmr300: possible missed rain event: 
new=10160.0 old=None
Apr 10 15:03:24 nixie weewx[371]: wmr300: rain=None rain_total=10160.0 
last_rain=None
Apr 10 15:03:24 nixie weewx[371]: wmr300: rain counter at maximum, reset 
required
Apr 10 15:03:24 nixie weewx[371]: restx: Wunderground-RF: Published record 
2019-04-10 15:03:24 EDT (1554923004)
Apr 10 15:03:24 nixie weewx[371]: restx: Wunderground-RF: Published record 
2019-04-10 15:03:24 EDT (1554923004)
Apr 10 15:03:24 nixie weewx[371]: restx: Wunderground-RF: Published record 
2019-04-10 15:03:25 EDT (1554923005)


NOTE to Self:  Reset the rain counter...

Meanwhile,

On the Wunderground side the Graph data stopped at the point where I 
disabled archive_post and didn't resume until 10 minutes later, but at last 
look was 5 minutes behind.  :-(

When I look at the WU "Table" data I see:

April 10, 2019
TimeTemperatureDew PointHumidityWindSpeedGustPressurePrecip. Rate.Precip. 
Accum.UVSolar

Invalid Date:undefined Date 51F 38F 61% NNE 4.0mph 7.0mph 29.12in 0.00in 
0.00in w/m² 

Invalid Date:undefined Date 51F 38F 62% NE 4.0mph 7.0mph 29.12in 0.00in 0.00
in w/m² 

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Wunderground Rapidfire not working for WMR300A (but started working after forcing PWS mode on in addition to RF)

[Leon Shaner]

Yes, Tom, I have "rapidfire = True" as confirmed by:

Apr 10 14:53:23 nixie weewx[371]: restx: Wunderground-RF: Data for station 
KMIDEARB5 will be posted


Thanks! =D

On Wednesday, April 10, 2019 at 3:02:37 PM UTC-4, Tom Robertson wrote:
>
> 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
> [snip]
>
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Wunderground Rapidfire not working for WMR300A (but started working after forcing PWS mode on in addition to RF)

[Tom Robertson]

I don’t think that proves you have rapidfire turned on.  I get the same thing 
in my log file and I do not have rapidfire turned on.  That just means you have 
set up this section to turn on uploading to WU .  The section I posted earlier 
turns on rapidfire.  It is a two part process.  The one below turns on the WU 
upload function and one I posted earlier turns on rapidfire.

   [[Wunderground]]
# This section is for configuring posts to the Weather Underground.

# If you wish to do this, set the option 'enable' to true,
# and specify a station (e.g., 'KORHOODR3') and password.
# To guard against parsing errors, put the password in quotes.
enable = true
station = KALALBER13
password = X

-
Tom

> On Apr 10, 2019, at 2:20 PM, Leon Shaner  wrote:
> 
> Yes, Tom, I have "rapidfire = True" as confirmed by:
> 
> Apr 10 14:53:23 nixie weewx[371]: restx: Wunderground-RF: Data for station 
> KMIDEARB5 will be posted
> 
> 
> Thanks! =D
> 
> On Wednesday, April 10, 2019 at 3:02:37 PM UTC-4, Tom Robertson wrote:
> 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
> [snip]
> 
> 
> -- 
> 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 weewx-user+unsubscr...@googlegroups.com 
> .
> For more options, visit 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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Wunderground Rapidfire not working for WMR300A (but started working after forcing PWS mode on in addition to RF)

[Leon Shaner]

I should clarify that for WU Rapidfire to work, I did also have to set 
archive_post = True again, but it was only after 10 minutes that data 
started showing up in the WU Graphs.

Even so, every record on the WU side under the Table data view continues to 
show the error/warning:
Invalid Date:undefined Date
Data on the WU side is now up-to-date, within the last 1-minute time-frame. 
 So at least things are reasonably functional.
I do want archive mode anyway, so I can re-sync to WU if connectivity to WU 
is ever interrupted.
I just thought it odd that Rapidfire didn't work without archive_post also 
enabled, since the default behavior is for those two post methods to be 
mutually exclusive.  :-/


On Wednesday, April 10, 2019 at 3:14:52 PM UTC-4, Leon Shaner wrote:
>
> On Wednesday, April 10, 2019 at 2:41:24 PM UTC-4, Leon Shaner wrote:
>>
>> [snip]
>> On the Wunderground side the Graph data stopped at the point where I 
>> disabled archive_post and didn't resume until 10 minutes later, but at last 
>> look was 5 minutes behind.  :-(
>>
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Question on potential enhancement to wmr300.py driver enhancement regarding host date/time -> set WMR300 date/time

[Leon Shaner]

Hey, wall,

Thanks for the reply.  I never did install their very old Windows XP 
software, since I only have Mac, Linux, Raspian available.
Interestingly enough, I did just notice that they now sell for $60 some 
software that claims to run on RPI, but the say the software is sold as is, 
no refunds.
It does have a 30 day trial, though.  I might check it out to see if it can 
do two things:

1) accept configuration info like LAT/LONG, timezone, and periodic time 
drift updates a la NTP from host -> WMR300.
2) reset archive data (without a total factory-reset) 

I kinda doubt they'd bother with #1, since it's supposed to get its clock 
info from RF/over-the-air like so many of their products.
But that doesn't explain why it was off by about an hour and a half.

Incidentally, I did remember that even from day one this WMR300 always 
incorrectly reported the sunset time, which was off by exactly an hour 
unless I switched from auto to manual and forced DST to on.  I just filed a 
support request with them about it.  Maybe they'll advise about new 
firmware with a fix and then I can ask them how to get access to any newer 
utility for updating said firmware.   I'll report back if that goes 
anywhere.  =D

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Question on potential enhancement to wmr300.py driver enhancement regarding host date/time -> set WMR300 date/time

[Leon Shaner]

I shoulda RTFM'd.  ;-)
I saw elsewhere that weewx was telling me that the maximum rain counter was 
exceeded and needed to be reset.
I touched the rainfall section on the WMR300A and saw a "MEM" button at the 
bottom, which I then touched and held and the rain data reset.
Turns out, ALL the data reset.  Which is fine by me.
I probably should have reset the data at least once a year and certainly 
before trying out weewx with the unit (since it was taking forever to 
process data going back to 2016).

On Wednesday, April 10, 2019 at 3:51:26 PM UTC-4, Leon Shaner wrote:
>
> [snip]
>
 

> 2) reset archive data (without a total factory-reset) 
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Fresh install of weewx 3.9.1 with WMR300A on RPI, Non-positive value for record field 'interval': 0.0

[Leon Shaner]

I shoulda RTFM'd.  ;-)
I saw elsewhere that weewx was telling me that the maximum rain counter was 
exceeded and needed to be reset.
I touched the rainfall section on the WMR300A and saw a "MEM" button at the 
bottom, which I then touched and held and the rain data reset.
Turns out, ALL the data reset.  Which is fine by me.
I probably should have reset the data at least once a year and certainly 
before trying out weewx with the unit (since it was taking forever to 
process data going back to 2016).


On Wednesday, April 10, 2019 at 10:54:53 AM UTC-4, Leon Shaner wrote:
>
>
>
> On Tuesday, April 9, 2019 at 5:09:02 PM UTC-4, mwall wrote:
>>
>> On Tuesday, April 9, 2019 at 4:42:17 PM UTC-4, Leon Shaner wrote:
>>>
>>> [snip]
>>>
>> there are probably records in the station's data logger, and apparently 
>> some of them are corrupt.
>>
>> m 
>>
>
>
> I did not see an option to purge archive records in the wmr300.py driver 
> and I do not know how to do it from the WMR300A itself (other than full 
> factory reset, which I hope to avoid). 
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Wunderground Rapidfire not working for WMR300A (but started working after forcing PWS mode on in addition to RF)

[Leon Shaner]

Thanks again, Tom.

I should have been more clear by stating, YES, I did check the setting, AND 
it is ALSO evidenced by the log.

You must be running some other version of the software, because the log 
definitely DOES follow/correspond to "rapidfire = true" for me.

Showing here:

*pi@nixie*:*/usr/share/weewx $* egrep 'rapidfire|archive_post' /etc/weewx/
weewx.conf

   *rapidfire* = True

   # Override default behavor and *archive_post* even when *rapidfire* 
= True


   *archive_post* = True



Log after restart (grep KMIDEARB5 /var/log/syslog), and allowing some 
time...
Apr 10 16:40:01 nixie weewx[1348]: restx: Wunderground-PWS: Data for 
station KMIDEARB5 will be posted
Apr 10 16:40:01 nixie weewx[1348]: restx: Wunderground-RF: Data for station 
KMIDEARB5 will be posted
NOTE: Wunderground-PWS corresponds to "archive_post = True" and 
Wunderground-RF corresponds to rapidfire = True


Now then, if I deliberately disable rapidfire, a la:

*pi@nixie*:*/usr/share/weewx $* egrep 'rapidfire|archive_post' /etc/weewx/
weewx.conf

   *rapidfire* = False

   # Override default behavor and *archive_post* even when *rapidfire* = 
True


   *archive_post* = True



THEN, the log after restart (grep KMIDEARB5 /var/log/syslog), and allowing 
some time...
Apr 10 16:41:56 nixie weewx[1436]: restx: Wunderground-PWS: Data for 
station KMIDEARB5 will be posted
NOTE:  No reference to Wunderground-RF


And if I put it back to both enabled:

*pi@nixie*:*/usr/share/weewx $* egrep 'rapidfire|archive_post' /etc/weewx/
weewx.conf

   *rapidfire* = True

   # Override default behavor and *archive_post* even when *rapidfire* = 
True


   *archive_post* = True



Then, finally, the log after restart (grep KMIDEARB5 /var/log/syslog), and 
allowing some time...
Apr 10 16:44:08 nixie weewx[1517]: restx: Wunderground-PWS: Data for 
station KMIDEARB5 will be posted
Apr 10 16:44:08 nixie weewx[1517]: restx: Wunderground-RF: Data for station 
KMIDEARB5 will be posted

Those two log records definitely follow the archive_post and rapidfire 
settings when set to True, but only if debug = 1, and upon restart of the 
weewx service.


*I'm still stuck with needing both to be set to True for rapid fire to 
actually work.*
*AND WU is complaining about invalid dates in the table view on their side.*


On Wednesday, April 10, 2019 at 3:27:33 PM UTC-4, Tom Robertson wrote:
>
> I don’t think that proves you have rapidfire turned on.  I get the same 
> thing in my log file and I do not have rapidfire turned on.  That just 
> means you have set up this section to turn on uploading to WU .  The 
> section I posted earlier turns on rapidfire.  It is a two part process. 
>  The one below turns on the WU upload function and one I posted earlier 
> turns on rapidfire.
>
> [[Wunderground]]
> # This section is for configuring posts to the Weather Underground.
> # If you wish to do this, set the option 'enable' to true,
> # and specify a station (e.g., 'KORHOODR3') and password.
> # To guard against parsing errors, put the password in quotes.
> enable = true
> station = KALALBER13
> password = X
>
> -
> Tom
>
> On Apr 10, 2019, at 2:20 PM, Leon Shaner > 
> wrote:
>
> Yes, Tom, I have "rapidfire = True" as confirmed by:
>
> Apr 10 14:53:23 nixie weewx[371]: restx: Wunderground-RF: Data for station 
> KMIDEARB5 will be posted
>
>
> Thanks! =D
> [snip]
>
>
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Wunderground Rapidfire not working for WMR300A (but started working after forcing PWS mode on in addition to RF)

[Leon Shaner]

Stop the press!

The invalid date in the WU table on the WU side is entirely a WU bug on the 
Safari web browser!
Chrome displays the times, correctly!

Original problem remains re: needing to explicitly set "archive_post = 
True" in addition to "rapidfire = True" for rapidfire to actually work.

Probably a bug, but I'm going to give it a rest, because I want both 
enabled anyway.  =D

On Wednesday, April 10, 2019 at 5:02:26 PM UTC-4, Leon Shaner wrote:
>
> [snip]
>
>
> *I'm still stuck with needing both to be set to True for rapid fire to 
> actually work.*
> *AND WU is complaining about invalid dates in the table view on their 
> side.*
>
>
>

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [weewx-user] Steel Guages and driver update question

[Steve2Q]

Found this on the Weather Cat website:

The whole point of installing the SteelSeries Gauges on your website is for 
you to have fun! Experiment with them and enjoy the journey. Studies have 
shown that when you have the SteelSeries Gauges on your website, your 
children will have more respect for you and your grandchildren will love 
you more. Your wife will thank you for spending so much time on your 
computer. The neighbors will check your website more frequently. One user's 
brother told him that the gauges look way better than the weather site 
maintained by the local television station. While your mileage may vary, 
one thing is for certain - the weather will enjoy hanging around your 
anemometer and rain collector cup after you implement the SteelSeries 
Gauges. 

-- 
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [weewx-user] Steel Guages and driver update question

[gjr80]

Steve,

I think Tom covered it pretty well. One thing to note is the new API takes 
a different approach to how you specify the location for which you want the 
forecast. Previously you could specify a PWS code now its geocode 
(lat/long), ICAO code, IATA code, place ID and postal key (limited 
countries). Rtgd should default to your stations lat/long if no valid 
location setting is found so the easiest thing is probably to just remove 
the location = x line altogether. I suspect Tom's PWS code is a hang 
over form the and old rtgd. As you noted there is useful info in the 
comments in rtgd.py,it is likely more up to date than anything in the 
associated wiki.

You asked about commenting out the SteelGauges section in weewx.conf. The 
reason we do this is that you have two services producing gauge-data.txt; 
the SteelSeries skin will produce gauge-data.txt each report cycle and the 
rtgd extension will produce gauge-data.txt (up to) on receipt of every loop 
packet. That in itself is not a problem but if you have both of those 
services set to save gauge-data.txt in the same location you might see some 
off behaviour on your gauges (gauges jumping around at odd times etc). 
Worst case you could have both services try to write to the same file at 
the same time and that could cause WeeWX to complain. It also makes it 
easier to fault find if you only have one service creating a file. The 
other approach you can take is to have the SteelSeries skin save it's 
version of gauge-data.txt somewhere WeeWX won't see it, eg /var/tmp. One 
final thing, the SteelSeries skin also serves some other purposes, on 
startup it copies the javascript and css files required by the SteelSeries 
Gauges to your public_html directory as well as generating the html page 
the gauges are displayed on. You may wish to keep some or all of these 
running. So my advice is to just disable the generation of gauge-data.txt 
rather than the whole skin. The rtgd documentation probably does not make 
that point very clearly.

Gary

On Thursday, 11 April 2019 03:28:36 UTC+10, Steve2Q wrote:
>
> Tom..Thank you! I am not sure why my 1st attempt at using my new API 
> didn't work. Maybe because I used my lat/long instead of my PWS ID? Anyway, 
> you are correct that WU is much more detailed than DS. Now to change back 
> the HTML file so the bottom left attributes are correct.
>
> Steve
>
> On Wed, Apr 10, 2019 at 1:05 PM Tom Robertson  > wrote:
>
>> Steve,
>> I assume you are using the latest RTGD version 0.3.7 released 7 days 
>> ago.  I found the WU forecast to be more detailed than the DarkSky forecast.
>>
>> This is what my weewx.conf looks like under the [RealtimeGaugeData] 
>> [[WU]].  It is slightly different from before.  I believe my API key is 
>> around 32 characters now.  Gary told me to use the PWS name instead of the 
>> coordinates for the location.
>>
>> [[WU]]
>> api_key =
>> units = e
>> language = en-US
>> interval = 1800
>> api_lockout_period = 60
>> max_tries = 3
>> location = pws:KALALBER13
>> debug = 0
>>
>> -
>> Tom
>>
>> On Apr 10, 2019, at 10:14 AM, Steve Meltz > 
>> wrote:
>>
>> Hi Tom. When I saw that the key I had was no longer working, I went 
>> through the steps as stated in your email to generate a new key (I have 
>> been registered with WU as a PWS for several years). When I plugged this 
>> new key into the rtgd configuration,  I still had no info in the scroller. 
>> Maybe I had to wait longer? For now, DarkSky is working and I will see how 
>> accurate it is. I may go back to giving WU a try. 
>>
>> Thans, Steve 
>>
>> On Wed, Apr 10, 2019, 10:55 AM Tom Robertson > > wrote:
>>
>>> Hi Steve,
>>> If you supply data to WU then you can get a new API from them. Gary has 
>>> update RTGD to use the new API and properly display the forecast on the LED 
>>> ticker.  Here are the instructions for getting a new key:
>>>
>>> First, if you are not logged into Weather Underground, you will need to 
>>> do so.  You must log in using the same email address as the PWS.  To do 
>>> that, go to wunderground.com, click on “my profile”, click on “member 
>>> settings”, and log in if you are not already.  
>>>  
>>> Then navigate on the screen to My Profile => Member Settings => API 
>>> Keys.  
>>>  
>>> If you have a PWS registered, you will see a blank box below “Your API 
>>> keys”.  Agree to the new Terms and Conditions by clicking in the small box 
>>> next to “I agree”, click on the blue “GENERATE” box, and your new key will 
>>> be created.  
>>>  
>>> The key will be masked on the screen, but you can use the “Show” link 
>>> below the box to see it.  There is also another blue box, which, when 
>>> clicked, copies the key to your clipboard.  Also on this page is a link to 
>>> the documentation. 
>>>  
>>> If you do not have a PWS registered to your email address, you will not 
>>> be able to get a key.  
>>>
>>>
>>>
>>> -
>>> Tom
>>>
>>> On Apr 10, 2019, at 9:39 AM, Steve Meltz > 
>>> wrote:
>>>