Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Jarom Hatch]

I tried the 3.9.1 version and I get Could not get Weather Underground data. 
Exiting.

Curl still works, even for yesterday's data.  Tracing the script it doesn't 
appear to be actually attempting the download.  


On Wednesday, May 22, 2019 at 7:03:49 PM UTC-6, Leon Shaner wrote:
>
> Say, we need a tester who is still on 3.9.1 or there abouts to try this 
> out:
>
> https://raw.githubusercontent.com/UberEclectic/weewx/master/bin/wunderfixer
>
> Can't do anything to workaround WU's sporadic 404 and 503 errors, but at 
> least the 403 error should be gone.
>
> I was able to test the 4.0 / development version myself on both Python2 
> and 3, so hopefully Tom will merge that soon.  It's over here if you are 
> impatient.  =D
>
>
> https://raw.githubusercontent.com/UberEclectic/weewx/development/bin/wunderfixer
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 22, 2019, at 7:24 PM, Leon Shaner > 
> wrote:
>
> Hey WeeWX'ers!!!  =D
>
> I have a fix in the hopper.
>
> There's nothing that can be done for the occasional HTTP 404, or even 
> 503's I am now seeing, but the HTTP 403 was due to a change on WU's part 
> where they are rejecting certain HTTP User-Agent strings.  The fact that 
> they are putting Akamai in the middle is almost certainly a great thing re: 
> their scalability issues; however, they probably inherited some default 
> settings that filter "bots" and malware and such, which is likely why the 
> HTTP User-Agent now matters.
>
> I have set the User-Agent to "CURL" and it works.
> I have set it to "Mozilla" and it works.  I'm going with that one, since 
> it means Mosaic Killer, both of which were among the the very first 
> User-Agents I ever worked with, circa 1993 back before there was such as 
> thing as Netscape.  =D
>
> /ye-olde-farte mode off  ;-)
>
> My testing has so far been under Python3, but coincidentally (and not a 
> causation), WU started throwing HTTP 503's around the time that I tried 
> validating my code also under Python2.
>
> Everything is working against today's date.
> It's when I go after yesterday's date that I get the HTTP server error 503.
>
> I expect the 404's and 503's to go away eventually, but at least for now I 
> have a fix for the 403 (forbidden)'s, just based on the User-Agent string.
>
> I'll submit a change for wunderfixer both to the 3.9.x "master" and 4.0.x 
> "development" branches in a moment and reply back with direct links for 
> anyone who wants a fix sooner.  =D
>
> Isn't this fun?  =D
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 22, 2019, at 4:20 PM, Leon Shaner > 
> wrote:
>
> I'm still working on this.
> CURL is telling me they are not only using https, but also TLSv1.2.
> Here is a transcript, in case one of y'all beats me to the fix.  =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...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/DA01E425-B99A-4959-8FB2-B564A61B3E77%40isylum.org
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
> 
>
>
>
>
> Working from here:
> https://docs.python.org/2/library/ssl.html
>
> So far I have tried this, to no avail.
> Really just doing the "import ssl" and using https in the URL, and adding 
> context=ssl_context to the urllib.request.
>
> A snippet of that looks as follows, but still getting 403 forbidden.  :-(
>
> # For new WU interface which uses SSL and TLSv1.2
> import ssl
>
> ...
>
> _url = "
> https://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=%s; \
>"=%d=%d=%d=1" % (self.station, 
> dayRequested_tt[1],
>   dayRequested_tt[2], 
> dayRequested_tt[0])
>
> # specify TLSv1.2 and SSLv2, but not SSLv3
> ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
> ssl_context.options |= ssl.PROTOCOL_SSLv23
> ssl_context.options |= ssl.OP_NO_SSLv3
>
> try :
> # Hit the weather underground site:
> _wudata = urllib.request.urlopen(_url, context=ssl_context)
>
>
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 22, 2019, at 2:42 PM, Leon Shaner > 
> wrote:
>
> Jarom,
>
> CURL is pretty sophisticated in its ability to emulate browser state in 
> pretty much any way but JavaScript.  When it worked this morning, I saw 
> some cookies were involved.
> It may well be that the python way isn't handling that part.
> I don't know enough about how python fetches pages to work that out, but I 
> am very familiar with CURL, so if I can find a path that works 
> consistently, then I'll go back to the python to see 

[weewx-user] Re: Weather34 Template for WeeWX - New Major Update

[Jd D]

Hi,
Just downloaded the new update it does not display the main page and in the 
apache log file is the following

[Wed May 22 16:25:54.543403 2019] [:error] [pid 18454] [client 
192.168.0.39:59752] PHP Fatal error:  Uncaught Error: Call to undefined 
function mb_internal_encoding() in 
/var/www/html/pws_new/common.php:5\nStack trace:\n#0 
/var/www/html/pws_new/index.php(59): include_once()\n#1 {main}\n  thrown in 
/var/www/html/pws_new/common.php on line 5

Is something missing in the install since I could not find the function in 
any files.

Thanks
Jerry

On Wednesday, May 22, 2019 at 2:28:01 AM UTC-7, steeple ian wrote:
>
> A major new update for the Weather34 Template for WeeWX WX-HWS 
> (WX-UB40-RRW) as just been placed in the repository. This version is based 
> on its sibling MB-UB40-RRW and provides identical visual, functional and 
> performance experience.
>
> Some of the new or improved features are:-
>
>- New w34 skin
>- Harnesses the power of the WeeWX database to generate graphs and 
>statistical data.
>- New style pop-up weather almanacs.
>- Rainfall almanac reflects rain year settings in weewx.conf file.
>- Variable look-up table.
>- New addition charts.
>- New addition wind map.
>- New addition pop-up window links now visible in phone mode.
>- Auto adjusting pop-up windows for better viewing experience on smart 
>phones and smaller tablet devices.
>- Enhanced chart features.
>- Dark or light chart colour theme (set by Default Theme Color in 
>Settings).
>- Choice of 24hr or 12hr station main clock.
>- A more streamlined installation process.
>
>
>
> Due to the scale of the update and significant changes to settings files, 
> a new install will be required.
>
>
>
> A live demo can be seen at https://claydonsweather.org.uk
>
> Download from Github - https://github.com/steepleian/WX-HWS
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/d2fd12e9-6855-4c37-aef7-8890ab4327a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Leon Shaner]

Hey WeeWX'ers!!!  =D

I have a fix in the hopper.

There's nothing that can be done for the occasional HTTP 404, or even 503's I 
am now seeing, but the HTTP 403 was due to a change on WU's part where they are 
rejecting certain HTTP User-Agent strings.  The fact that they are putting 
Akamai in the middle is almost certainly a great thing re: their scalability 
issues; however, they probably inherited some default settings that filter 
"bots" and malware and such, which is likely why the HTTP User-Agent now 
matters.

I have set the User-Agent to "CURL" and it works.
I have set it to "Mozilla" and it works.  I'm going with that one, since it 
means Mosaic Killer, both of which were among the the very first User-Agents I 
ever worked with, circa 1993 back before there was such as thing as Netscape.  
=D

/ye-olde-farte mode off  ;-)

My testing has so far been under Python3, but coincidentally (and not a 
causation), WU started throwing HTTP 503's around the time that I tried 
validating my code also under Python2.

Everything is working against today's date.
It's when I go after yesterday's date that I get the HTTP server error 503.

I expect the 404's and 503's to go away eventually, but at least for now I have 
a fix for the 403 (forbidden)'s, just based on the User-Agent string.

I'll submit a change for wunderfixer both to the 3.9.x "master" and 4.0.x 
"development" branches in a moment and reply back with direct links for anyone 
who wants a fix sooner.  =D

Isn't this fun?  =D

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On May 22, 2019, at 4:20 PM, Leon Shaner  wrote:
> 
> I'm still working on this.
> CURL is telling me they are not only using https, but also TLSv1.2.
> Here is a transcript, in case one of y'all beats me to the fix.  =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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/DA01E425-B99A-4959-8FB2-B564A61B3E77%40isylum.org.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> 
> Working from here:
> https://docs.python.org/2/library/ssl.html
> 
> So far I have tried this, to no avail.
> Really just doing the "import ssl" and using https in the URL, and adding 
> context=ssl_context to the urllib.request.
> 
> A snippet of that looks as follows, but still getting 403 forbidden.  :-(
> 
> # For new WU interface which uses SSL and TLSv1.2
> import ssl
> 
> ...
> 
> _url = 
> "https://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=%s; \
>"=%d=%d=%d=1" % (self.station, 
> dayRequested_tt[1],
>   dayRequested_tt[2], 
> dayRequested_tt[0])
> 
> # specify TLSv1.2 and SSLv2, but not SSLv3
> ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
> ssl_context.options |= ssl.PROTOCOL_SSLv23
> ssl_context.options |= ssl.OP_NO_SSLv3
> 
> try :
> # Hit the weather underground site:
> _wudata = urllib.request.urlopen(_url, context=ssl_context)
> 
> 
> 
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
> 
>> On May 22, 2019, at 2:42 PM, Leon Shaner  wrote:
>> 
>> Jarom,
>> 
>> CURL is pretty sophisticated in its ability to emulate browser state in 
>> pretty much any way but JavaScript.  When it worked this morning, I saw some 
>> cookies were involved.
>> It may well be that the python way isn't handling that part.
>> I don't know enough about how python fetches pages to work that out, but I 
>> am very familiar with CURL, so if I can find a path that works consistently, 
>> then I'll go back to the python to see about how to implement same.
>> 
>> I was getting 404's in the browser even, when I looked at it earlier.
>> 
>> I'll keep working on it, but not too hard, so as to not get on their radar 
>> in any unwanted sort of way.  ;-)
>> 
>> Regards,
>> \Leon
>> --
>> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>> 
>>> On May 22, 2019, at 2:04 PM, Jarom Hatch  wrote:
>>> 
>>> Interesting, using curl sometimes I can it fine, but wunderfixer is always 
>>> getting a 403 Forbidden, as if it is actively being blocked...  When it 
>>> doesn't work in curl I get `HTTP/1.1 404 Not Found` and when it does work I 
>>> get `HTTP/1.1 200 OK`.  Curl never gets a 403 error.
>>> 
 On Wednesday, May 22, 2019 at 11:48:08 AM UTC-6, Jarom Hatch wrote:
 I was able to get it to work twice in my web browser, but as you said, it 
 is sporadic.  I don't ever recall them using Akamai before so that may 
 very well be a contributing factor.
 
 I wonder if we can find out the origin address and see what happens if we 
 can bypass Akamai...
 
> On Wednesday, May 22, 2019 at 7:35:18 AM UTC-6, Leon Shaner wrote:

Re: [weewx-user] Re: Add additional rain gauge via second data source

[engolling]

Hello,

of course I can give more details :-)

So as you know I'm augmenting some extra data to my archive records which I 
get from emulated davis loop packaged.
My file whichs contains always the latest data looks like this:
https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_Exp.txt
So there is written a signal name, a unit group and the actual data as csv.

The data is then augmented with the following script:
https://github.com/menachers/WeatherDuino/blob/master/WeeWx_Plugin/WeeWx_WeatherDuino_Logger_plugin.py
called as data service in the weewx.conf

record_generation is set to software, target_unit is set to metric.

The augmented data is in °C and most of the time it is saved to the 
database without being converted but sometimes a few datasets are double 
converted.

When record_generation is set to hardware the data is always converted, so 
I'm exporting the data in US units and weewx converts it back. This is no 
problem either.
But it is hard to handle when weewx jumps between no conversion and 
conversion.

Hopefully it is more clear now what I mean.

Regards,
engolling


Am Montag, 20. Mai 2019 00:49:56 UTC+2 schrieb gjr80:
>
> Hi,
>
> Perhaps you could give us some more details as to how the extra 
> temperature data is being obtained/provided/added to WeeWX, happy to see 
> code/data formats etc - code usually gives an unambiguous picture, 
> descriptions are often open to interpretation. I am having a little 
> difficulty understanding how the numeric data is always being received but 
> not the units, but perhaps that will become clear once you provide some 
> more detail.
>
> Gary
>
> On Monday, 20 May 2019 05:55:18 UTC+10, engolling wrote:
>>
>> Hello,
>>
>> me again :).
>> Thank you for your last answer Thomas. Works fine.
>>
>> Now I have a new "thing" I do not understand.
>> As discussed above I'm augmenting different data - also rain data to the 
>> archive records as described in the customization guide.
>>
>> I also augment temperature signals and sometimes they are converted to 
>> metric variables and sometimes not. The problem is the signal is already in 
>> °C and should be in °C, but if it is converted it looks like this:
>>
>>
>> 
>> The database is mertric. If I get for example a temperature of 22.61°C 
>> which should be imported into the database directly and it is most time. 
>> But sometimes I get -5.21°C (which is the result of the Farenheit Celsius 
>> conversion of 22.61°C).
>>
>> My Raspberry Pi has a bad WIFI internet connection and FTP often fails 
>> and it seems to be related to this.
>>
>> Could this be a reason and do you know how to handle the conversion?
>>
>> Regards,
>> engolling
>>
>> Am Dienstag, 7. Mai 2019 23:30:27 UTC+2 schrieb Thomas Keffer:
>>>
>>> Yes. That's certainly possible. 
>>>
>>> -tk
>>>
>>> On Tue, May 7, 2019 at 1:35 PM engolling  wrote:
>>>
 Hello together,

 it's me again with hopefully a last question...
 As you know I'm augmenting some extra data from my service to the WeeWx 
 archive records. But if archive records are loaded of the stations logger 
 this data (which is in the future) is also augmented.
 Is it possible to read the timestamp of the archive record beeing saved 
 at the moment and then decide if data should be augmented or not?
 Im thinking of a code like this:
 if dateTime_AugmentedData - event.record[dateTime] < 300:
--> augment_data





 Am Mittwoch, 3. April 2019 00:54:17 UTC+2 schrieb gjr80:
>
> Good that you have tracked down the issue. Running hardware record 
> generation on a Davis station has it advantages, though maybe not so 
> advantageous on emulated hardware.
>
> Regards plotting rain data from two sensors. The current WeeWX plot 
> engine will certainly allow you to plot two obs in a bar graph plot, 
> though 
> I expect the outcome will be one bar plotted over the top of the other. 
> Not 
> really what you are seeking. There is no option to plot the bars adjacent 
> to each other. It may be possible to modify the plot engine though I do 
> not 
> expect it would be a simple modification, the plot engine is fairly 
> rudimentary. You may need to use an external charting package which 
> should 
> easily do what you want, though this too will not be a turn key solution 
> as 
> you will need to generate the necessary data for the package as well as 
> integrate it into your web page(s).
>
> Gary
>
> On Wednesday, 3 April 2019 03:44:09 UTC+10, engolling wrote:
>>
>> Hi Gary,
>>
>> again thanks for your extended reply.
>> Meanwhile I added a lot of debugging code in the vantage driver and 
>> the WeatherDuino code and was able to find out the reason what happened.
>> Their 

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Doug Bo]

Hi Leon,

Agreed, I realize my post is a bit off topic but if WU continues to be less 
than reliable then perhaps other solutions might be viable?
Thanks for the reply, perhaps a new thread needs to be started by someone 
smarter than me about historical data search.

Good luck with your research & fix.  I'm a big WU fan and am sad they are 
slipping.  Thank you for trying to resolve the issue.  :)  

Thanks again,
Doug B.

On Wednesday, May 22, 2019 at 1:41:08 PM UTC-7, Leon Shaner wrote:
>
> Hey, Doug,
> Creating a front end to search your own local data would certainly be 
> doable.
> For sure, directing end-users to our own sites and letting them search our 
> historical data would be useful.
>
> But that wouldn't fix the problem at hand.  :-/
> The wunderfixer utility is there to query what data WU has on record from 
> your station and to re-upload any missing data.
> Basically if we can't fix this then it means WU will often be missing data 
> from time to time for various reasons.
> Really only WU should care and end-users who go to their site to look at 
> historical data.   So yeah, they should be invented to help, since they're 
> the ones missing the data, and the less reliable their data, the more 
> likely even end-users will begin to abandon using them.
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 22, 2019, at 4:33 PM, Doug Bo > 
> wrote:
>
> Sort of a noob question or maybe a feature request: how about adding a web 
> interface to search the database for historic weather data?  I grab the 
> wunderground data that I have uploaded to add to various farm records a few 
> months or even a year after the fact.  If WU is getting worse perhaps I 
> need another solution?
>
> Thanks,
> Doug B.
>
> On Tuesday, May 21, 2019 at 11:09:14 AM UTC-7, tds wrote:
>>
>> For the last three days, my daily cron job of wunderfixer have returned 
>> "503 Unavaialbe" (May 18), "404 Not Found" (May 19) and "403 Forbidden" 
>> (May 20).
>>
>> -- 
> 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...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/22591326-058f-4717-bdb4-2f91cd099e68%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/cab1516c-06fb-4dcf-80df-184565dc1db5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Leon Shaner]

Hey, Doug,
Creating a front end to search your own local data would certainly be doable.
For sure, directing end-users to our own sites and letting them search our 
historical data would be useful.

But that wouldn't fix the problem at hand.  :-/
The wunderfixer utility is there to query what data WU has on record from your 
station and to re-upload any missing data.
Basically if we can't fix this then it means WU will often be missing data from 
time to time for various reasons.
Really only WU should care and end-users who go to their site to look at 
historical data.   So yeah, they should be invented to help, since they're the 
ones missing the data, and the less reliable their data, the more likely even 
end-users will begin to abandon using them.

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On May 22, 2019, at 4:33 PM, Doug Bo  wrote:
> 
> Sort of a noob question or maybe a feature request: how about adding a web 
> interface to search the database for historic weather data?  I grab the 
> wunderground data that I have uploaded to add to various farm records a few 
> months or even a year after the fact.  If WU is getting worse perhaps I need 
> another solution?
> 
> Thanks,
> Doug B.
> 
>> On Tuesday, May 21, 2019 at 11:09:14 AM UTC-7, tds wrote:
>> For the last three days, my daily cron job of wunderfixer have returned "503 
>> Unavaialbe" (May 18), "404 Not Found" (May 19) and "403 Forbidden" (May 20).
>> 
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/22591326-058f-4717-bdb4-2f91cd099e68%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2B320D7A-2F1D-475D-810E-BCD69BB562E8%40isylum.org.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Doug Bo]

Sort of a noob question or maybe a feature request: how about adding a web 
interface to search the database for historic weather data?  I grab the 
wunderground data that I have uploaded to add to various farm records a few 
months or even a year after the fact.  If WU is getting worse perhaps I 
need another solution?

Thanks,
Doug B.

On Tuesday, May 21, 2019 at 11:09:14 AM UTC-7, tds wrote:
>
> For the last three days, my daily cron job of wunderfixer have returned 
> "503 Unavaialbe" (May 18), "404 Not Found" (May 19) and "403 Forbidden" 
> (May 20).
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/22591326-058f-4717-bdb4-2f91cd099e68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Leon Shaner]

I'm still working on this.CURL is telling me they are not only using https, but also TLSv1.2.Here is a transcript, in case one of y'all beats me to the fix.  =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.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/DA01E425-B99A-4959-8FB2-B564A61B3E77%40isylum.org.
For more options, visit https://groups.google.com/d/optout.
$ curl -L -v 
"https://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1;

  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying 23.7.182.137...
* TCP_NODELAY set
* Connected to www.wunderground.com (23.7.182.137) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [102 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2527 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [148 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=Georgia; L=Atlanta; O=TWC Product and Technology, LLC; 
OU=Digital; CN=www.weather.com
*  start date: Sep 25 00:00:00 2018 GMT
*  expire date: Nov 24 12:00:00 2019 GMT
*  subjectAltName: host "www.wunderground.com" matched cert's 
"*.wunderground.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert ECC Secure Server CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x6cea8)
} [5 bytes data]
> GET 
> /weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1
>  HTTP/1.1
> Host: www.wunderground.com
> User-Agent: curl/7.52.1
> Accept: */*
> 
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
} [5 bytes data]

  0 00 00 0  0  0 --:--:--  0:00:02 --:--:-- 0
  0 00 00 0  0  0 --:--:--  0:00:03 --:--:-- 0
  0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 0
  0 00 00 0  0  0 --:--:--  0:00:05 --:--:-- 0< 
HTTP/2 200 
< server: Apache/2.2.15 (CentOS)
< pragma: no-cache
< access-control-allow-origin: http://www.wunderground.com
< access-control-allow-credentials: true
< x-creationtime: 4.786
< content-type: text/html; charset=UTF-8
< cache-control: private, no-cache, must-revalidate
< expires: Wed, 22 May 2019 19:35:18 GMT
< date: Wed, 22 May 2019 19:35:18 GMT
< content-length: 19032
< set-cookie: DT=1558553713:13369:ip-10-226-235-63; path=/; expires=Fri, 
01-Jan-2020 00:00:00 GMT; domain=.wunderground.com
< set-cookie: 
Prefs=FAVS:1|WXSN:1|PWSOBS:1|WPHO:1|PHOT:1|RADC:0|RADALL:0|HIST0:NULL|GIFT:1|PHOTOTHUMBS:50|;
 path=/; expires=Fri, 01-Jan-2020 00:00:00 GMT; domain=.wunderground.com
< set-cookie: speedpin=4G; expires=Wed, 22-May-2019 20:05:18 GMT; path=/; 
domain=.wunderground.com; secure
< set-cookie: 
ci=TWC-Connection-Speed=4G=US=desktop=dna=wifi=US=42.3055=-83.1724=1000+=exempt;
 path=/; domain=.wunderground.com; secure
< property-id: drupal-prod
< x-requestsource: AkamaiProdProxy
< twc-privacy: exempt
< twc-geoip-latlong: 42.3055,-83.1724
< twc-geoip-country: US
< twc-device-class: desktop
< twc-locale-group: US
< twc-connection-speed: 4G
< x-requestsource: AkamaiDefaultDNA
< 
{ [105 bytes data]

Time,TemperatureF,DewpointF,PressureIn,WindDirection,WindDirectionDegrees,WindSpeedMPH,WindSpeedGustMPH,Humidity,HourlyPrecipIn,Conditions,Clouds,dailyrainin,SoftwareType,DateUTC
2019-05-22 
00:04:59,54,42.5,29.41,ENE,61,2.5,5.1,65,0,,,0,weewx-4.0.0a4,2019-05-22 
04:04:59,

2019-05-22 

Re: [weewx-user] Probably an OT Linux question, but:

[Leon Shaner]

Hey, Steve,

You're logged in as user pi.
When (re)starting weewx via a system service, such as "/etc/init.d/weewx 
restart" or "systemctl restart weewx" you have to elevate to root by one means 
or another.
The fact that it prompted you to pick a method of running under root is just a 
convenience.

Most people will just straight out run such a command under sudo which elevates 
to root for you, provided your user is allowed (which on RPI, the pi user, 
generally is allowed).

So what you wanted was:

$ sudo /etc/init.d/weewx restart

So if you never used to run it via "sudo" then you must have had an 
installation with some fancy permissions set to allow everything to be accessed 
by the pi user.
It's doable, but definitely not an out of the box config so if you had that 
working, you must have put a lot of effort into it a long time ago and maybe 
some "apt" kinds of commands reverted to the default "runs as root" paradigm?

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On May 22, 2019, at 12:20 PM, Steve2Q  wrote:
> 
> I SSH'd into my Pi to do a weewx restart;
> 
> I used to type /etc/init.d/weewx restart and the command just worked
> 
> Now it says the following:  
> 
> pi@raspberrypi:~ $ /etc/init.d/weewx restart
> [] Restarting weewx (via systemctl): weewx.service AUTHENTICATING FOR 
> org.freedesktop.systemd1.manage-units ===
> Authentication is required to restart 'weewx.service'.
> Multiple identities can be used for authentication:
>  1.  ,,, (pi)
>  2.  root
> Choose identity to authenticate as (1-2): 1
> Password:
> 
> when I choose #1 and type my password the command  executes
> 
> This just suddenly started with no changes that I made.
> 
> I know this may be way OT, but I have looked and could not find an answer 
> elsewhere.
> 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/6a38b5b3-1296-42ba-bea8-aeaa245fd0c1%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/680FCF93-378F-4E5F-B408-7D6E11FCC1E2%40isylum.org.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Weewx und Renkforce WH2315

[Günther Wrana]

Am Mittwoch, 22. Mai 2019 13:05:30 UTC+2 schrieb mwall:
>
> please try the wh23xx driver, not the fousb driver:
>
> https://github.com/matthewwall/weewx-wh23xx
>
> m
>

Danke für die Antwort.
Auf dem Lubuntu Laptop konnte ich den Treiber installieren.
Das ganze funktioniert auch.

Aber auf dem Raspberry konnte ich den Treiber nicht installieren und das 
mit dem

sudo wee_config --reconfigure


funktioniert auch nicht.

Ist da ein anderer Syntax?

Sonst passt alles ich kann meine Daten von der Renkforce jetzt auf 
Wunderground hochladen.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/8b8bd01f-b7b4-440a-ae07-04f0f9d8fdb2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Leon Shaner]

Jarom,

CURL is pretty sophisticated in its ability to emulate browser state in pretty 
much any way but JavaScript.  When it worked this morning, I saw some cookies 
were involved.
It may well be that the python way isn't handling that part.
I don't know enough about how python fetches pages to work that out, but I am 
very familiar with CURL, so if I can find a path that works consistently, then 
I'll go back to the python to see about how to implement same.

I was getting 404's in the browser even, when I looked at it earlier.

I'll keep working on it, but not too hard, so as to not get on their radar in 
any unwanted sort of way.  ;-)

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On May 22, 2019, at 2:04 PM, Jarom Hatch  wrote:
> 
> Interesting, using curl sometimes I can it fine, but wunderfixer is always 
> getting a 403 Forbidden, as if it is actively being blocked...  When it 
> doesn't work in curl I get `HTTP/1.1 404 Not Found` and when it does work I 
> get `HTTP/1.1 200 OK`.  Curl never gets a 403 error.
> 
>> On Wednesday, May 22, 2019 at 11:48:08 AM UTC-6, Jarom Hatch wrote:
>> I was able to get it to work twice in my web browser, but as you said, it is 
>> sporadic.  I don't ever recall them using Akamai before so that may very 
>> well be a contributing factor.
>> 
>> I wonder if we can find out the origin address and see what happens if we 
>> can bypass Akamai...
>> 
>>> On Wednesday, May 22, 2019 at 7:35:18 AM UTC-6, Leon Shaner wrote:
>>> For one thing, the URL of this form:
>>> 
>>> http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1
>>> 
>>> Is now redirecting to one using HTTPS:
>>> 
>>> https://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1
>>> 
>>> Also, the redirect itself takes an excruciatingly long time.
>>> So I just changed the URL to https directly...
>>> 
>>> The first time I tried any of the above using CURL this morning it worked, 
>>> but then after that I started getting:
>>> 
>>> An error occurred while processing your request.
>>> Reference #30.6f451160.1558531514.16ced4f6
>>> 
>>> It looks as if they've put some kind of Akamai proxy in the middle, which 
>>> is fine for static content, but not so fine for a query of this nature.  
>>> Strange that it worked for me the very first time.  It's almost as if the 
>>> Akamai "farm" has lost some "state" information and not all nodes have the 
>>> same content, so if you get stuck going through a bad node you get a bogus 
>>> response.
>>> 
>>> Attached is a transcript of a failed attempt.  I put SOMESTATION there only 
>>> after the fact.  The actual query was for my actual station, which used to 
>>> work.
>>> 
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/07ac6f86-ae4d-4854-8398-ce4ab8d846c1%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/3260F8E7-37D4-4737-999B-97522E324370%40isylum.org.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Second crash after 11 days

[Leon Shaner]

Hey, Steve,

I must have missed the context, but if you are looking at overall system memory 
growth, well, it's a normal / healthy thing for a Linux kernel to try to use as 
much memory as possible at all times, to keep from having to go back to disk 
for code pages as different processes context switch in/out of the scheduler.   
Even as memory is freed by a program, the kernel won't bother to go back and 
re-use free'd pages unless/until there are no more previously unused memory 
pages available.
At that point the kernel will run the free memory "scanner" to go through the 
list of freed pages to find some to allocate to some other program requesting 
memory.

In a healthy system with plenty of RAM the free memory scanner should rarely 
run.
If the scanner runs a lot, then that means memory pressure is high and so THERE 
would be your indication that you're running low on memory, not "free -m" 
indicating a high number (because a high number is a good/normal thing in 
Linux).

What you should be most concerned about is if the system is starting to 
actually use swap, because then that means that not only is the physical RAM 
full, and freed pages are constantly being turned over / re-used, but the 
kernel is ALSO having to dip into virtual memory by swapping out (to disk) 
things not currently running, and then swapping those things back in when the 
associated processes are brought back to the running state by the process 
scheduler.

I like to use "top" to see what's going on with swap usage, but you can also 
get the info via other ways, such as:

$ cat /proc/meminfo
$ vmstat

(Etc etc)...

As for how to track the *real* indicator of memory pressure, that being the 
free memory scanner running too frequently, I'd look to "sar" for that.

I didn't see mention of what platform you are on, but for me on RPI, I get sar 
via:

$ sudo apt-get install sysstat
(And enable it in "/etc/default/sysstat").

And then these go in root's cron, a la "sudo crontab -e"

# Enable SAR:
# Collect measurements at 10-minute intervals
0,10,20,30,40,50   * * * *   /usr/lib/sysstat/sa1
# Create daily reports and purge old files
0  0 * * *   /usr/lib/sysstat/sa2 -A



After sa1 has been running a few times (say, give it an hour) then you can use 
"sar -B" to see the "pgscand/s" statistics (and related).

Of course check "man sar" for more details.


Like I said I missed the context, but did you previously capture some data to 
suggest that weewxd is growing and growing in its memory consumption?

Here is a handy command you can use to check it:

$ ps -C weewxd -o comm,size,rss,vsize,%mem
COMMAND  SIZE   RSSVSZ %MEM
weewxd  88616 71816 102640 16.1

You can use "man ps" to understand what size and RSS is, but if those grow and 
grow and grow, then that's usually an indicator of a memory leak in the code.

If you run that ps command in a loop, checking it say once every 10 minutes you 
can do some math to gauge how much it is growing.

A la:

$ while [ 1 ] ; do
ps -C weewxd -o comm,size,rss,vsize,%mem
sleep 600
done | tee -a /var/tmp/weewxd_size.txt

Wouldn't be too hard to just show the delta in the numbers.
Lemme know if you're still reading this far and I'll take a few seconds to show 
such an example.  ;-)

Regards,
\Leon
--
Leon Shaner :: Dearborn, Michigan (iPad Pro)

> On May 22, 2019, at 12:14 PM, Steve2Q  wrote:
> 
> A little follow up. As the memory growth is still happening, I implemented a 
> script which runs the program free -m and does a little calculation to 
> determine if memory use is over 80% (or any % I want to use). If mem >80% 
> weewx is restarted. So at least it now will run unattended.
> 
> A new question with Steel Gauges. I did the re-installation of RTG on April 
> 9. I just noticed that the gauges themselves are working perfectly, the pop 
> up charts are showing April 9; they have not updated. I probably have the 
> wrong syntax somewhere?
> 
> Steve
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/aa2ae09d-6a65-4c1d-aff5-46332084ade7%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/170C7D38-46B5-4285-BFC4-C82807F8DB7B%40isylum.org.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Second crash after 11 days

[Steve2Q]

A little follow up. As the memory growth is still happening, I implemented 
a script which runs the program free -m and does a little calculation to 
determine if memory use is over 80% (or any % I want to use). If mem >80% 
weewx is restarted. So at least it now will run unattended.

A new question with Steel Gauges. I did the re-installation of RTG on April 
9. I just noticed that the gauges themselves are working perfectly, the pop 
up charts are showing April 9; they have not updated. I probably have the 
wrong syntax somewhere?

Steve

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/aa2ae09d-6a65-4c1d-aff5-46332084ade7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Probably an OT Linux question, but:

[Steve2Q]

Thanks, Vince...lost an old friend this past weekend...not thinking 
straight.

Just needed to put sudo in front of the command

On Wednesday, May 22, 2019 at 1:21:08 PM UTC-4, vince wrote:
>
> On Wednesday, May 22, 2019 at 9:20:16 AM UTC-7, Steve2Q wrote:
>
>> I know this may be way OT, but I have looked and could not find an answer 
>> elsewhere.
>>
>>
>>
> Try googling for your exact message:
> "*Authentication is required to restart 'weewx.service'. Multiple 
> identities can be used for authentication:*"
>
> There are lots of descriptions in the top hits Google returns.
>
> (hint - 'always' google for an unexpected message, you'll almost never be 
> the first person who saw 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5f6844c8-a4ae-4fdb-aa83-384fb78d743c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Jarom Hatch]

Interesting, using curl sometimes I can it fine, but wunderfixer is always 
getting a 403 Forbidden, as if it is actively being blocked...  When it 
doesn't work in curl I get `HTTP/1.1 404 Not Found` and when it does work I 
get `HTTP/1.1 200 OK`.  Curl never gets a 403 error.

On Wednesday, May 22, 2019 at 11:48:08 AM UTC-6, Jarom Hatch wrote:
>
> I was able to get it to work twice in my web browser, but as you said, it 
> is sporadic.  I don't ever recall them using Akamai before so that may very 
> well be a contributing factor.
>
> I wonder if we can find out the origin address and see what happens if we 
> can bypass Akamai...
>
> On Wednesday, May 22, 2019 at 7:35:18 AM UTC-6, Leon Shaner wrote:
>>
>> For one thing, the URL of this form:
>>
>>
>> http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1
>>
>> Is now redirecting to one using HTTPS:
>>
>>
>> https://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1
>>
>> Also, the redirect itself takes an excruciatingly long time.
>> So I just changed the URL to https directly...
>>
>> The first time I tried any of the above using CURL this morning it 
>> worked, but then after that I started getting:
>>
>> An error occurred while processing your request.
>>
>> Reference #30.6f451160.1558531514.16ced4f6
>> It looks as if they've put some kind of Akamai proxy in the middle, which 
>> is fine for static content, but not so fine for a query of this nature. 
>>  Strange that it worked for me the very first time.  It's almost as if the 
>> Akamai "farm" has lost some "state" information and not all nodes have the 
>> same content, so if you get stuck going through a bad node you get a bogus 
>> response.
>>
>> Attached is a transcript of a failed attempt.  I put SOMESTATION there 
>> only after the fact.  The actual query was for my actual station, which 
>> used to work.
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/07ac6f86-ae4d-4854-8398-ce4ab8d846c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Jarom Hatch]

I was able to get it to work twice in my web browser, but as you said, it 
is sporadic.  I don't ever recall them using Akamai before so that may very 
well be a contributing factor.

I wonder if we can find out the origin address and see what happens if we 
can bypass Akamai...

On Wednesday, May 22, 2019 at 7:35:18 AM UTC-6, Leon Shaner wrote:
>
> For one thing, the URL of this form:
>
>
> http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1
>
> Is now redirecting to one using HTTPS:
>
>
> https://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1
>
> Also, the redirect itself takes an excruciatingly long time.
> So I just changed the URL to https directly...
>
> The first time I tried any of the above using CURL this morning it worked, 
> but then after that I started getting:
>
> An error occurred while processing your request.
>
> Reference #30.6f451160.1558531514.16ced4f6
> It looks as if they've put some kind of Akamai proxy in the middle, which 
> is fine for static content, but not so fine for a query of this nature. 
>  Strange that it worked for me the very first time.  It's almost as if the 
> Akamai "farm" has lost some "state" information and not all nodes have the 
> same content, so if you get stuck going through a bad node you get a bogus 
> response.
>
> Attached is a transcript of a failed attempt.  I put SOMESTATION there 
> only after the fact.  The actual query was for my actual station, which 
> used to work.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0089a003-7709-4d4a-82c5-8cb54cc2dc1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Probably an OT Linux question, but:

[Steve2Q]

I SSH'd into my Pi to do a weewx restart;

I used to type /etc/init.d/weewx restart and the command just worked

Now it says the following:  

pi@raspberrypi:~ $ /etc/init.d/weewx restart
[] Restarting weewx (via systemctl): weewx.service AUTHENTICATING 
FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to restart 'weewx.service'.
Multiple identities can be used for authentication:
 1.  ,,, (pi)
 2.  root
Choose identity to authenticate as (1-2): 1
Password:

when I choose #1 and type my password the command  executes

This just suddenly started with no changes that I made.

I know this may be way OT, but I have looked and could not find an answer 
elsewhere.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/6a38b5b3-1296-42ba-bea8-aeaa245fd0c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Probably an OT Linux question, but:

[vince]

On Wednesday, May 22, 2019 at 9:20:16 AM UTC-7, Steve2Q wrote:

> I know this may be way OT, but I have looked and could not find an answer 
> elsewhere.
>
>
>
Try googling for your exact message:
"*Authentication is required to restart 'weewx.service'. Multiple 
identities can be used for authentication:*"

There are lots of descriptions in the top hits Google returns.

(hint - 'always' google for an unexpected message, you'll almost never be 
the first person who saw 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/af474367-4c9c-46b3-ab30-db38a2bb55d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Leon Shaner]

For one thing, the URL of this form:http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1Is now redirecting to one using HTTPS:https://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1Also, the redirect itself takes an excruciatingly long time.So I just changed the URL to https directly...The first time I tried any of the above using CURL this morning it worked, but then after that I started getting:An error occurred while processing your request.Reference #30.6f451160.1558531514.16ced4f6It looks as if they've put some kind of Akamai proxy in the middle, which is fine for static content, but not so fine for a query of this nature.  Strange that it worked for me the very first time.  It's almost as if the Akamai "farm" has lost some "state" information and not all nodes have the same content, so if you get stuck going through a bad node you get a bogus response.Attached is a transcript of a failed attempt.  I put SOMESTATION there only after the fact.  The actual query was for my actual station, which used to work.



-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/D629ECBA-956A-48D1-97F6-662D8A4EE70E%40isylum.org.
For more options, visit https://groups.google.com/d/optout.
curl -L -v 
"http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1;
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying 184.27.188.101...
* TCP_NODELAY set
* Connected to www.wunderground.com (184.27.188.101) port 80 (#0)
> GET 
> /weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1
>  HTTP/1.1
> Host: www.wunderground.com
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Server: AkamaiGHost
< Content-Length: 0
< Location: 
https://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1
< Cache-Control: max-age=0
< Expires: Wed, 22 May 2019 13:29:03 GMT
< Date: Wed, 22 May 2019 13:29:03 GMT
< Connection: keep-alive
< Set-Cookie: speedpin=4G; expires=Wed, 22-May-2019 13:59:03 GMT; path=/; 
domain=.wunderground.com; secure
< Set-Cookie: 
ci=TWC-Connection-Speed=4G=US=desktop=dna=wifi=US=42.3055=-83.1724=1000+=exempt;
 path=/; domain=.wunderground.com; secure
< Property-id: drupal-prod
< X-RequestSource: AkamaiProdProxy
< TWC-Privacy: exempt
< TWC-GeoIP-LatLong: 42.3055,-83.1724
< TWC-GeoIP-Country: US
< TWC-Device-Class: desktop
< TWC-Locale-Group: US
< TWC-Connection-Speed: 4G
< X-RequestSource: AkamaiDefaultDNA
< 
* Curl_http_done: called premature == 0

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
* Connection #0 to host www.wunderground.com left intact
* Issue another request to this URL: 
'https://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=SOMESTATION=5=22=2019=1'
*   Trying 184.27.188.101...
* TCP_NODELAY set
* Connected to www.wunderground.com (184.27.188.101) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [102 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2527 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [148 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=Georgia; L=Atlanta; O=TWC Product and Technology, LLC; 
OU=Digital; CN=www.weather.com
*  start date: Sep 25 00:00:00 2018 GMT
*  expire date: Nov 24 12:00:00 2019 GMT
*  subjectAltName: host "www.wunderground.com" matched cert's 
"*.wunderground.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert ECC Secure Server CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to 

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

[Miguel Angel Peña Morales]

I will post a cleaner log when I arrive home.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/44c4446e-72a3-4085-b17e-90f5ff52894a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Miguel Angel Peña Morales]

No, as I said, that's not the problem. I solved that yesterday. The 
intermittent data is the problem. I searched the web for the error in the data 
flow and I think I'm the only one...

Thanks anyway.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5673738a-cd0a-46f9-85ce-5a6956fc6d53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Weewx und Renkforce WH2315

[mwall]

please try the wh23xx driver, not the fousb driver:

https://github.com/matthewwall/weewx-wh23xx

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/4989204b-efa5-4aa8-b00f-27445e5a9370%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Weewx und Renkforce WH2315

[Günther Wrana]

Hallo

Ich habe diese Wetterstation Renkforce WH2315

Wenn jemand weis das diese Wetterstation mit weewx auf Lununtu oder 
Raspberry pi kompatibel ist da soll er mir sagen was ich falsch gemacht 
habe.



https://www.conrad.at/de/p/renkforce-wh2300-wh2315-funk-wetterstation-vorhersage-fuer-12-bis-24-stunden-1404262.html

Das Programm weewx habe ich auf einem Laptop mit Lubuntu 16.04 und 
einem raspberry pi 3 v1.2 installiert.

Ob das richtig installiert ist wies ich nicht aber es lässt sich starten 
und es startet.

Die Wetterstation wird auch nach Eingabe von lsusb im Terminal angezeigt.


modelleisenbahn@modelleisenbahn-LIFEBOOK-E-Series:~$ lsusb
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 10c4:8468 Cygnal Integrated Products, Inc. 
Bus 001 Device 002: ID 0846:9030 NetGear, Inc. WNA1100 Wireless-N 150 
[Atheros AR9271]
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
modelleisenbahn@modelleisenbahn-LIFEBOOK-E-Series:~$ 


Wenn ich dann weewx starte oder es schon gestartet ist wird folgendes 
angezeigt.


modelleisenbahn@modelleisenbahn-LIFEBOOK-E-Series:~$ sudo /etc/init.d/weewx 
start
[sudo] password for modelleisenbahn: 
 * Starting weewx weather system weewx   [ 
OK ] 
modelleisenbahn@modelleisenbahn-LIFEBOOK-E-Series:~$ sudo tail -f 
/var/log/syslog
May  5 11:24:55 modelleisenbahn-LIFEBOOK-E-Series weewx[2447]: engine: pid 
file is /var/run/weewx.pid
May  5 11:24:55 modelleisenbahn-LIFEBOOK-E-Series weewx[2451]: engine: 
Using configuration file /etc/weewx/weewx.conf
May  5 11:24:55 modelleisenbahn-LIFEBOOK-E-Series weewx[2451]: engine: 
Loading station type FineOffsetUSB (weewx.drivers.fousb)
May  5 11:24:55 modelleisenbahn-LIFEBOOK-E-Series weewx[2451]: fousb: 
driver version is 1.9
May  5 11:24:55 modelleisenbahn-LIFEBOOK-E-Series weewx[2451]: fousb: 
polling mode is PERIODIC
May  5 11:24:55 modelleisenbahn-LIFEBOOK-E-Series weewx[2451]: fousb: 
polling interval is 60
May  5 11:24:55 modelleisenbahn-LIFEBOOK-E-Series weewx[2451]: fousb: 
Cannot find USB device with Vendor=0x1941 ProdID=0x8021 Device=None
May  5 11:24:55 modelleisenbahn-LIFEBOOK-E-Series weewx[2451]: import of 
driver failed: Unable to find USB device ()
May  5 11:24:55 modelleisenbahn-LIFEBOOK-E-Series weewx[2451]: engine: 
Unable to load driver: Unable to find USB device
May  5 11:24:55 modelleisenbahn-LIFEBOOK-E-Series weewx[2451]:   
Exiting...



Nun habe ich in der weewx.conf etwas eingefügt wie in einer anderen Zeile 
beschrieben.

weewx StdReport exits if USB disconnected

# Keeping retrying!

loop_on_init = 1


Danach wird im Terminal alle 60 Sekunden folgendes angezeigt.


Unable to load driver: Unable to find USB device


Zum Abschluss ist diese Wetterstation mit weewx auslesbar oder nicht wenn 
ja was habe ich bei der Installation oder beim einstellen falsch gemacht.


Grüße Günther







 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/673cffd3-d8a4-43c6-9984-9d827c87b65f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: weewx report generation delayed ?

[wysiwyg]

Hi!

You are right, the delay is not critical, just a bit annoying:
I used to rely on page update ~20sec after each round 5min, now it's a bit 
more random (sometime one more minute as you can see in logs).
It's just disturbing when working a skin template ( sometime I just wait 
for next generation to see the results)
Or when an heavy rain/storm occurs suddenly and I'm curious to see 
measurements :-)

But it's nothing more than minor discomfort.

I don't want to increase  too much wind packet rate. It will be fast in 
case of wingust, but if no wind, I plan to emit only every 2 minutes to 
save battery.
It's because the sensor will be solar+battery and on the roofI dont 
want to climb there too much :-D, so I prefer keep a -very big- margin on 
battery to handle longer winter nights & cloudy weather.

But I can increase the barometer rate, It's not battery supplied.







Le mercredi 22 mai 2019 09:58:17 UTC+2, gjr80 a écrit :
>
> On Wednesday, 22 May 2019 17:28:21 UTC+10, wysiwyg wrote:
>>
>>
>> 2/ I think you have guess right with loop records:  The station is my own 
>> development, Today I have 2 hardware:
>> - one outdoor sensor (Temp, humi, rain, UV) emits every 150sec
>> - one indoor sensor (barometer, intemp) emits every 3 minutes.
>> Wind sensor will come soon, with higher emission rate, but only when 
>> there are some wind.
>>
>> That could explain the +/- 1 min delay I seen for report generation.
>>
>> So If I understand correctly, the only way to improve this is to increase 
>> emission rate of at least one sensor ? 
>> ...or to live with current situation  (It's not critical, just a bit 
>> annoying while working in skins)
>>
>
> I guess it depends on what you mean by improve, the only downside to 
> having that delay is that you are waiting a few extra seconds for your 
> reports to be generated. Your data is just as valid as the only data 
> included in a given archive record by WeeWX is loop data that was received 
> between the start and end of that given archive period. Perhaps when you 
> implement your wind sensor you could have your driver emit 'wind' loop 
> packets much more often. That is how the Davis stations operate (albeit 
> they use a complete not a partial loop packet), the wind sensor updates at 
> a much higher rate than the temperature, humidity and other sensors. The 
> Davis stations emit a loop packet every 2 odd seconds.
>
> Gary
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2a7a8830-1b05-42a7-9b1c-14a72196d327%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: New to weewx need some help

[Joe Santas]

May 22 17:45:40 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
unrecognized parameter uv=0
May 22 17:45:40 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
unrecognized parameter stationtype=EasyWeatherV1.3.2
May 22 17:45:40 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
unrecognized parameter weeklyrainin=0.000
May 22 17:45:40 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: raw 
packet: {'wind_speed': 4.0, 'wind_gust': 4.5, 'humidity_out': 54.0, 
'radiation': 0.0, 'rain': 0.0, 'dateTime': 1558511140, 'temperature_out': 
62.1, 'wind_dir': 25.0, 'rain_total': 0.0, 'usUnits': 1}
May 22 17:45:40 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
mapped packet: {'outHumidity': 54.0, 'radiation': 0.0, 'rain': 0.0, 
'dateTime': 1558511140, 'windDir': 25.0, 'outTemp': 62.1, 'windSpeed': 4.0, 
'windGust': 4.5, 'usUnits': 1}
May 22 17:45:40 UBUNTUMATE-1000H weewx[3154]: manager: Added record 
2019-05-22 17:45:00 AEST (1558511100) to database 'weewx.sdb'
May 22 17:45:40 UBUNTUMATE-1000H weewx[3154]: manager: Added record 
2019-05-22 17:45:00 AEST (1558511100) to daily summary in 'weewx.sdb'
May 22 17:45:41 UBUNTUMATE-1000H weewx[3154]: restx: WeatherCloud: wait 
interval (300 < 600) has not passed for record 2019-05-22 17:45:00 AEST 
(1558511100)
May 22 17:45:41 UBUNTUMATE-1000H weewx[3154]: reportengine: Running reports 
for latest time in the database.
May 22 17:45:41 UBUNTUMATE-1000H weewx[3154]: reportengine: Running report 
'SeasonsReport'
May 22 17:45:41 UBUNTUMATE-1000H weewx[3154]: reportengine: Found 
configuration file /etc/weewx/skins/Seasons/skin.conf for report 
'SeasonsReport'
May 22 17:45:41 UBUNTUMATE-1000H weewx[3154]: cheetahgenerator: using 
search list ['weewx.cheetahgenerator.Almanac', 
'weewx.cheetahgenerator.Station', 'weewx.cheetahgenerator.Current', 
'weewx.cheetahgenerator.Stats', 'weewx.cheetahgenerator.UnitInfo', 
'weewx.cheetahgenerator.Extras']
May 22 17:45:41 UBUNTUMATE-1000H weewx[3154]: manager: Daily summary 
version is 2.0
May 22 17:45:41 UBUNTUMATE-1000H weewx[3154]: restx: Wunderground-PWS: 
Published record 2019-05-22 17:45:00 AEST (1558511100)
May 22 17:45:42 UBUNTUMATE-1000H weewx[3154]: restx: AWEKAS: Published 
record 2019-05-22 17:45:00 AEST (1558511100)
May 22 17:45:42 UBUNTUMATE-1000H weewx[3154]: restx: PWSWeather: Published 
record 2019-05-22 17:45:00 AEST (1558511100)
May 22 17:45:43 UBUNTUMATE-1000H weewx[3154]: cheetahgenerator: Generated 8 
files for report SeasonsReport in 1.81 seconds
May 22 17:45:43 UBUNTUMATE-1000H weewx[3154]: manager: Daily summary 
version is 2.0
May 22 17:45:44 UBUNTUMATE-1000H weewx[3154]: imagegenerator: Generated 14 
images for SeasonsReport in 1.21 seconds
May 22 17:45:44 UBUNTUMATE-1000H weewx[3154]: copygenerator: copied 0 files 
to /var/www/html/weewx
May 22 17:45:44 UBUNTUMATE-1000H weewx[3154]: reportengine: Report 
'SmartphoneReport' not enabled. Skipping.
May 22 17:45:44 UBUNTUMATE-1000H weewx[3154]: reportengine: Report 
'MobileReport' not enabled. Skipping.
May 22 17:45:44 UBUNTUMATE-1000H weewx[3154]: reportengine: Report 
'StandardReport' not enabled. Skipping.
May 22 17:45:44 UBUNTUMATE-1000H weewx[3154]: reportengine: Report 'FTP' 
not enabled. Skipping.
May 22 17:45:44 UBUNTUMATE-1000H weewx[3154]: reportengine: Report 'RSYNC' 
not enabled. Skipping.
May 22 17:45:51 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
empty queue
May 22 17:46:41 UBUNTUMATE-1000H weewx[3154]: message repeated 5 times: [ 
interceptor: MainThread: empty queue]
May 22 17:46:44 UBUNTUMATE-1000H weewx[3154]: interceptor: ServerThread: 
POST: 
PASSKEY==EasyWeatherV1.3.2=2019-05-22+07:46:44=74.7=47=29.72=29.72=62.1=54=25=2.5_avg10m=0.0=3.4=5.8=0.000=0.000=0.000=0.000=0.000=0.000=0.000=0.00=0
May 22 17:46:44 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: raw 
data: 
PASSKEY=xxx=EasyWeatherV1.3.2=2019-05-22+07:46:44=74.7=47=29.72=29.72=62.1=54=25=2.5_avg10m=0.0=3.4=5.8=0.000=0.000=0.000=0.000=0.000=0.000=0.000=0.00=0
May 22 17:46:44 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
using rain_total 0.0 from yearlyrainin
May 22 17:46:44 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
unrecognized parameter eventrainin=0.000
May 22 17:46:44 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
unrecognized parameter baromrelin=29.72
May 22 17:46:44 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
unrecognized parameter maxdailygust=5.8
May 22 17:46:44 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
unrecognized parameter monthlyrainin=0.000
May 22 17:46:44 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
unrecognized parameter PASSKEY=xxx
May 22 17:46:44 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
unrecognized parameter humidityin=47
May 22 17:46:44 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
unrecognized parameter rainratein=0.000
May 22 17:46:44 UBUNTUMATE-1000H weewx[3154]: interceptor: MainThread: 
unrecognized parameter 

[weewx-user] Re: weewx report generation delayed ?

[gjr80]

On Wednesday, 22 May 2019 17:28:21 UTC+10, wysiwyg wrote:
>
>
> 2/ I think you have guess right with loop records:  The station is my own 
> development, Today I have 2 hardware:
> - one outdoor sensor (Temp, humi, rain, UV) emits every 150sec
> - one indoor sensor (barometer, intemp) emits every 3 minutes.
> Wind sensor will come soon, with higher emission rate, but only when there 
> are some wind.
>
> That could explain the +/- 1 min delay I seen for report generation.
>
> So If I understand correctly, the only way to improve this is to increase 
> emission rate of at least one sensor ? 
> ...or to live with current situation  (It's not critical, just a bit 
> annoying while working in skins)
>

I guess it depends on what you mean by improve, the only downside to having 
that delay is that you are waiting a few extra seconds for your reports to 
be generated. Your data is just as valid as the only data included in a 
given archive record by WeeWX is loop data that was received between the 
start and end of that given archive period. Perhaps when you implement your 
wind sensor you could have your driver emit 'wind' loop packets much more 
often. That is how the Davis stations operate (albeit they use a complete 
not a partial loop packet), the wind sensor updates at a much higher rate 
than the temperature, humidity and other sensors. The Davis stations emit a 
loop packet every 2 odd seconds.

Gary

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/a123f8b1-c468-4f01-9cbb-a4d6e3e0e3e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: weewx report generation delayed ?

[wysiwyg]

Hi !

Thank you Gary for your explanation!
I think you hit the bullseye (is it ok to say that ? English is not my 
mother-language).

Let me explain:
1/ Yes, I showed archive records logs, but report engine start right after 
record, so I assumed the record task as the reference for timings to trig 
"5 minutes tasks".

2/ I think you have guess right with loop records:  The station is my own 
development, Today I have 2 hardware:
- one outdoor sensor (Temp, humi, rain, UV) emits every 150sec
- one indoor sensor (barometer, intemp) emits every 3 minutes.
Wind sensor will come soon, with higher emission rate, but only when there 
are some wind.

That could explain the +/- 1 min delay I seen for report generation.

So If I understand correctly, the only way to improve this is to increase 
emission rate of at least one sensor ? 
...or to live with current situation  (It's not critical, just a bit 
annoying while working in skins)





Le mercredi 22 mai 2019 05:14:55 UTC+2, gjr80 a écrit :
>
> Actually, the log extract provided shows no information whatsoever 
> regarding reports, just database updates. Though a report thread should be 
> kicked off almost immediately after the database is updated. 
>
> Depending on the weather station capabilities and WeeWX configuration, you 
> may well not see archive records being saved at the same time. It takes the 
> arrival of a loop packet to cause WeeWX to check whether it is time to 
> synthesise or request an archive record. So if you have loop packets coming 
> in at irregular intervals, or there are long intervals between loop 
> packets, it is quite conceivable you will see archive records being saved 
> to database at different times each archive period and that the variation 
> in seconds could be as much as the maximum loop packet interval. If your 
> station has a very short loop packet interval you will find the archive 
> record is synthesised/obtained from the hardware much closer to the same 
> time each archive period. The key measure is the archive record time stamp 
> which in your case is remaining hard and fast on the 5 minute boundary 
>
> Gary
>
> On Wednesday, 22 May 2019 09:25:18 UTC+10, vince wrote:
>>
>> On Tuesday, May 21, 2019 at 1:04:19 PM UTC-7, wysiwyg wrote:
>>>
>>>
>>> But when looking my logs, I seems a bit irregular...(I considered "
>>> manager: Added record 2019-05-18 21:20:00 CEST (1558207200) to database 
>>> 'weewx.sdb'" 
>>> as starting point of 5 minute tasks).
>>>
>>> Is it expected? if not, what could cause this ?
>>>
>>>
>> What in particular do you think is wrong ?
>> The fact that it it's not literally a second or two after you expect 
>> things ?
>>
>> Without your crontab entries and 'much' more info about your configs, 
>> we're not going to be able to help much.
>> Looks like it's working to me.
>>  
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/86eb4201-3a3e-4eb0-a8ec-30fff5adcef6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: New to weewx need some help

[gjr80]

Those lines smell very much of WOW. Might want to disable WOW uploads as 
well as WeatherCloud.

Gary

On Wednesday, 22 May 2019 16:38:31 UTC+10, Gábor Szabados wrote:
>
> There is another issue too, where a messages is sent without yearly rain 
> as this one, where the daily rainin is used by intercetor. It should not 
> mix the yearly and daily measurements it should use only one of them which 
> exists in all messages. But when it uses the daily it zeros the total rail 
> so it will add next 2.25 or 2.48 as rain for the day. I think the statition 
> still send messages what it shouldn't be.
>
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: ServerThread: 
> GET: 
> siteid===2019-05-21%2021:40:33=54.3=47.7=78=30.34=34=5.4=6.9=0.00&
> *dailyrainin=0.00*=EasyWeatherV1.3.2
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> raw data: 
> siteid===2019-05-21%2021:40:33=54.3=47.7=78=30.34=34=5.4=6.9=0.00&
> *dailyrainin=0.00*=EasyWeatherV1.3.2
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> using rain_total 0.0 from dailyrainin
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> firmware EasyWeatherV1.3.2: baromin is barometer
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> unrecognized parameter rainin=0.00
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> ignored parameter softwaretype=EasyWeatherV1.3.2
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> unrecognized parameter siteid=
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> unrecognized parameter siteAuthenticationKey=
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> rain counter wraparound detected: *new=0.0* last=2.25
>
> Gábor
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/820d4075-15c4-4eaf-b14b-dbdd3a9d4282%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: New to weewx need some help

[Joe Santas]

I think its fixed.  Looks like by clearing the entries re the internet 
services wunderground and the others some how it retained them even though 
they were blanked out this is even after a restart of the unit.
The only way around it was to do a factory reset and seems to have done the 
trick.
Only thing that is not getting reported now is the barometer reading where 
it was previously.  Finally some progress... :)

May 22 17:12:17 UBUNTUMATE-1000H weewx[2847]: interceptor: MainThread: 
unrecognized parameter baromabsin=29.71
May 22 17:12:17 UBUNTUMATE-1000H weewx[2847]: interceptor: MainThread: 
unrecognized parameter tempinf=70.3
May 22 17:12:17 UBUNTUMATE-1000H weewx[2847]: interceptor: MainThread: 
unrecognized parameter uv=0
May 22 17:12:17 UBUNTUMATE-1000H weewx[2847]: interceptor: MainThread: 
unrecognized parameter stationtype=EasyWeatherV1.3.2
May 22 17:12:17 UBUNTUMATE-1000H weewx[2847]: interceptor: MainThread: 
unrecognized parameter weeklyrainin=0.000
May 22 17:12:17 UBUNTUMATE-1000H weewx[2847]: interceptor: MainThread: raw 
packet: {'wind_speed': 3.8, 'wind_gust': 4.5, 'humidity_out': 53.0, 
'radiation': 3.79, 'rain': 0.0, 'dateTime': 1558509137, 'temperature_out': 
64.2, 'wind_dir': 11.0, 'rain_total': 0.0, 'usUnits': 1}
May 22 17:12:17 UBUNTUMATE-1000H weewx[2847]: interceptor: MainThread: 
mapped packet: {'outHumidity': 53.0, 'radiation': 3.79, 'rain': 0.0, 
'dateTime': 1558509137, 'windDir': 11.0, 'outTemp': 64.2, 'windSpeed': 3.8, 
'windGust': 4.5, 'usUnits': 1}
May 22 17:12:27 UBUNTUMATE-1000H weewx[2847]: interceptor: MainThread: 
empty queue







On Wednesday, May 22, 2019 at 4:38:31 PM UTC+10, Gábor Szabados wrote:
>
> There is another issue too, where a messages is sent without yearly rain 
> as this one, where the daily rainin is used by intercetor. It should not 
> mix the yearly and daily measurements it should use only one of them which 
> exists in all messages. But when it uses the daily it zeros the total rail 
> so it will add next 2.25 or 2.48 as rain for the day. I think the statition 
> still send messages what it shouldn't be.
>
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: ServerThread: 
> GET: 
> siteid===2019-05-21%2021:40:33=54.3=47.7=78=30.34=34=5.4=6.9=0.00&
> *dailyrainin=0.00*=EasyWeatherV1.3.2
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> raw data: 
> siteid===2019-05-21%2021:40:33=54.3=47.7=78=30.34=34=5.4=6.9=0.00&
> *dailyrainin=0.00*=EasyWeatherV1.3.2
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> using rain_total 0.0 from dailyrainin
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> firmware EasyWeatherV1.3.2: baromin is barometer
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> unrecognized parameter rainin=0.00
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> ignored parameter softwaretype=EasyWeatherV1.3.2
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> unrecognized parameter siteid=
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> unrecognized parameter siteAuthenticationKey=
> May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: 
> rain counter wraparound detected: *new=0.0* last=2.25
>
> Gábor
>
>
> Joe Santas > ezt írta (időpont: 2019. 
> máj. 22., Sze 8:10):
>
>> Just tried disabling rapid fire but no change.  Its still incrementing as 
>> previously... That 2.2.x figure still pops up..  Not sure where its pulling 
>> this from
>> using rain_total 2.248
>>
>>
>> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
>> ignored parameter action=updateraw
>> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
>> unrecognized parameter weeklyrainin=0.00
>> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
>> raw packet: {'wind_speed': 2.7, 'humidity_in': 54.0, 'temperature_in': 
>> 72.7, 'barometer': 30.3, 'windchill': 70.9, 'dewpoint': 45.5, 
>> 'humidity_out': 40.0, 'uv': 0.0, 'radiation': 50.65, 'rain': 0.0, 
>> 'dateTime': 1558505079, 'temperature_out': 70.9, 'wind_dir': 17.0, 
>> 'rain_total': 
>> 2.25, 'usUnits': 1, 'wind_gust': 3.4}
>> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
>> mapped packet: {'barometer': 30.3, 'windchill': 70.9, 'dewpoint': 45.5, 
>> 'outHumidity': 40.0, 'UV': 0.0, 'radiation': 50.65, 'rain': 0.0, 
>> 'dateTime': 1558505079, 'windDir': 17.0, 'outTemp': 70.9, 'windSpeed': 2.7, 
>> 'inHumidity': 54.0, 'inTemp': 72.7, 'windGust': 3.4, 'usUnits': 1}
>> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: ServerThread: 
>> POST: 
>> PASSKEY==EasyWeatherV1.3.2=2019-05-22+06:04:39=72.7=54=30.30=29.69=70.9=40=17=2.7_avg10m=0.0=3.4=6.9=0.000=0.000=0.000=0.000=0.000=
>> 1.346=2.248=50.65=0
>> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
>> raw data: 

Re: [weewx-user] Re: New to weewx need some help

[Gábor Szabados]

There is another issue too, where a messages is sent without yearly rain as
this one, where the daily rainin is used by intercetor. It should not mix
the yearly and daily measurements it should use only one of them which
exists in all messages. But when it uses the daily it zeros the total rail
so it will add next 2.25 or 2.48 as rain for the day. I think the statition
still send messages what it shouldn't be.

May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: ServerThread:
GET:
siteid===2019-05-21%2021:40:33=54.3=47.7=78=30.34=34=5.4=6.9=0.00&
*dailyrainin=0.00*=EasyWeatherV1.3.2
May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread: raw
data:
siteid===2019-05-21%2021:40:33=54.3=47.7=78=30.34=34=5.4=6.9=0.00&
*dailyrainin=0.00*=EasyWeatherV1.3.2
May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread:
using rain_total 0.0 from dailyrainin
May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread:
firmware EasyWeatherV1.3.2: baromin is barometer
May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread:
unrecognized parameter rainin=0.00
May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread:
ignored parameter softwaretype=EasyWeatherV1.3.2
May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread:
unrecognized parameter siteid=
May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread:
unrecognized parameter siteAuthenticationKey=
May 22 07:40:34 UBUNTUMATE-1000H weewx[26366]: interceptor: MainThread:
rain counter wraparound detected: *new=0.0* last=2.25

Gábor


Joe Santas  ezt írta (időpont: 2019. máj. 22., Sze
8:10):

> Just tried disabling rapid fire but no change.  Its still incrementing as
> previously... That 2.2.x figure still pops up..  Not sure where its pulling
> this from
> using rain_total 2.248
>
>
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> ignored parameter action=updateraw
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter weeklyrainin=0.00
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: raw
> packet: {'wind_speed': 2.7, 'humidity_in': 54.0, 'temperature_in': 72.7,
> 'barometer': 30.3, 'windchill': 70.9, 'dewpoint': 45.5, 'humidity_out':
> 40.0, 'uv': 0.0, 'radiation': 50.65, 'rain': 0.0, 'dateTime': 1558505079,
> 'temperature_out': 70.9, 'wind_dir': 17.0, 'rain_total': 2.25, 'usUnits':
> 1, 'wind_gust': 3.4}
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> mapped packet: {'barometer': 30.3, 'windchill': 70.9, 'dewpoint': 45.5,
> 'outHumidity': 40.0, 'UV': 0.0, 'radiation': 50.65, 'rain': 0.0,
> 'dateTime': 1558505079, 'windDir': 17.0, 'outTemp': 70.9, 'windSpeed': 2.7,
> 'inHumidity': 54.0, 'inTemp': 72.7, 'windGust': 3.4, 'usUnits': 1}
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: ServerThread:
> POST:
> PASSKEY==EasyWeatherV1.3.2=2019-05-22+06:04:39=72.7=54=30.30=29.69=70.9=40=17=2.7_avg10m=0.0=3.4=6.9=0.000=0.000=0.000=0.000=0.000=
> 1.346=2.248=50.65=0
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: raw
> data:
> PASSKEY=B49D741DD8D21E1D5B657ADE7C3A9D91=EasyWeatherV1.3.2=2019-05-22+06:04:39=72.7=54=30.30=29.69=70.9=40=17=2.7_avg10m=0.0=3.4=6.9=0.000=0.000=0.000=0.000=0.000=
> 1.346=2.248=50.65=0
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> using rain_total 2.248 from yearlyrainin
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter eventrainin=0.000
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter baromrelin=30.30
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter maxdailygust=6.9
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter monthlyrainin=1.346
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter PASSKEY=
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter humidityin=54
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter rainratein=0.000
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter windspdmph_avg10m=0.0
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter hourlyrainin=0.000
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter baromabsin=29.69
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter tempinf=72.7
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter uv=0
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread:
> unrecognized parameter stationtype=EasyWeatherV1.3.2
> May 22 

Re: [weewx-user] Re: New to weewx need some help

[gjr80]

Hard to make say too much from such a short log extract. Did you restart 
WeeWX? Would be worthwhile seeing the log from a restart onwards covering a 
least a couple of archive periods.

Gary

On Wednesday, 22 May 2019 16:10:09 UTC+10, Joe Santas wrote:
>
> Just tried disabling rapid fire but no change.  Its still incrementing as 
> previously... That 2.2.x figure still pops up..  Not sure where its pulling 
> this from
> using rain_total 2.248
>
>
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> ignored parameter action=updateraw
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter weeklyrainin=0.00
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: raw 
> packet: {'wind_speed': 2.7, 'humidity_in': 54.0, 'temperature_in': 72.7, 
> 'barometer': 30.3, 'windchill': 70.9, 'dewpoint': 45.5, 'humidity_out': 
> 40.0, 'uv': 0.0, 'radiation': 50.65, 'rain': 0.0, 'dateTime': 1558505079, 
> 'temperature_out': 70.9, 'wind_dir': 17.0, 'rain_total': 2.25, 'usUnits': 
> 1, 'wind_gust': 3.4}
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> mapped packet: {'barometer': 30.3, 'windchill': 70.9, 'dewpoint': 45.5, 
> 'outHumidity': 40.0, 'UV': 0.0, 'radiation': 50.65, 'rain': 0.0, 
> 'dateTime': 1558505079, 'windDir': 17.0, 'outTemp': 70.9, 'windSpeed': 2.7, 
> 'inHumidity': 54.0, 'inTemp': 72.7, 'windGust': 3.4, 'usUnits': 1}
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: ServerThread: 
> POST: 
> PASSKEY==EasyWeatherV1.3.2=2019-05-22+06:04:39=72.7=54=30.30=29.69=70.9=40=17=2.7_avg10m=0.0=3.4=6.9=0.000=0.000=0.000=0.000=0.000=
> 1.346=2.248=50.65=0
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: raw 
> data: 
> PASSKEY=B49D741DD8D21E1D5B657ADE7C3A9D91=EasyWeatherV1.3.2=2019-05-22+06:04:39=72.7=54=30.30=29.69=70.9=40=17=2.7_avg10m=0.0=3.4=6.9=0.000=0.000=0.000=0.000=0.000=
> 1.346=2.248=50.65=0
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> using rain_total 2.248 from yearlyrainin
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter eventrainin=0.000
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter baromrelin=30.30
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter maxdailygust=6.9
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter monthlyrainin=1.346
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter PASSKEY=
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter humidityin=54
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter rainratein=0.000
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter windspdmph_avg10m=0.0
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter hourlyrainin=0.000
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter baromabsin=29.69
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter tempinf=72.7
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter uv=0
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter stationtype=EasyWeatherV1.3.2
> May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
> unrecognized parameter weeklyrainin=0.000
>
>
> On Wednesday, May 22, 2019 at 2:46:57 PM UTC+10, gjr80 wrote:
>>
>> Hi,
>>
>> Not an interceptor or ECOWITT HP2551 user but looking at your log1.txt 
>> log extract it appears that your station is sending both rapidfire as well 
>> as normal (non-rapidfire) updates. 
>>
>> Rapid fire:
>> May 22 07:40:02 UBUNTUMATE-1000H weewx[26366]: interceptor: ServerThread: 
>> GET: ID=IVICTORI1768==71.1=54.3=
>> 47.7=54.3=52=78=6.9&
>> windgustmph=8.1=40=29.73=30.34=0.00&
>> dailyrainin=0.00=0.00=1.35=2.25&
>> solarradiation=16.88=0=2019-05-21%2021:40:01=
>> EasyWeatherV1.3.2=updateraw=1=5
>>
>> normal:
>> May 22 07:40:18 UBUNTUMATE-1000H weewx[26366]: interceptor: ServerThread: 
>> POST: PASSKEY==EasyWeatherV1.3.2=2019-05-21+21:40
>> :17=71.4=52=30.34=29.73=
>> 54.3=78=18=5.4_avg10m=0.0&
>> windgustmph=6.9=15.9=0.000=0.000&
>> hourlyrainin=0.000=0.000=0.000=
>> 1.346=2.248=16.02=0
>>
>> This really shouldn't be an issue but if you have a look at the number of 
>> decimal places used for each rain related observation in each you will see 
>> the RF updates use 2 decimal places and the normal updates 3 decimal 
>> places. Consequently, when you have normal after a RF you get a rain 
>> counter wraparound detected and your rainfall has the wrapped around figure 
>> 

Re: [weewx-user] Re: New to weewx need some help

[Joe Santas]

Just tried disabling rapid fire but no change.  Its still incrementing as 
previously... That 2.2.x figure still pops up..  Not sure where its pulling 
this from
using rain_total 2.248


May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
ignored parameter action=updateraw
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter weeklyrainin=0.00
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: raw 
packet: {'wind_speed': 2.7, 'humidity_in': 54.0, 'temperature_in': 72.7, 
'barometer': 30.3, 'windchill': 70.9, 'dewpoint': 45.5, 'humidity_out': 
40.0, 'uv': 0.0, 'radiation': 50.65, 'rain': 0.0, 'dateTime': 1558505079, 
'temperature_out': 70.9, 'wind_dir': 17.0, 'rain_total': 2.25, 'usUnits': 
1, 'wind_gust': 3.4}
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
mapped packet: {'barometer': 30.3, 'windchill': 70.9, 'dewpoint': 45.5, 
'outHumidity': 40.0, 'UV': 0.0, 'radiation': 50.65, 'rain': 0.0, 
'dateTime': 1558505079, 'windDir': 17.0, 'outTemp': 70.9, 'windSpeed': 2.7, 
'inHumidity': 54.0, 'inTemp': 72.7, 'windGust': 3.4, 'usUnits': 1}
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: ServerThread: 
POST: 
PASSKEY==EasyWeatherV1.3.2=2019-05-22+06:04:39=72.7=54=30.30=29.69=70.9=40=17=2.7_avg10m=0.0=3.4=6.9=0.000=0.000=0.000=0.000=0.000=
1.346=2.248=50.65=0
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: raw 
data: 
PASSKEY=B49D741DD8D21E1D5B657ADE7C3A9D91=EasyWeatherV1.3.2=2019-05-22+06:04:39=72.7=54=30.30=29.69=70.9=40=17=2.7_avg10m=0.0=3.4=6.9=0.000=0.000=0.000=0.000=0.000=
1.346=2.248=50.65=0
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
using rain_total 2.248 from yearlyrainin
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter eventrainin=0.000
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter baromrelin=30.30
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter maxdailygust=6.9
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter monthlyrainin=1.346
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter PASSKEY=
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter humidityin=54
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter rainratein=0.000
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter windspdmph_avg10m=0.0
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter hourlyrainin=0.000
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter baromabsin=29.69
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter tempinf=72.7
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter uv=0
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter stationtype=EasyWeatherV1.3.2
May 22 16:04:39 UBUNTUMATE-1000H weewx[2069]: interceptor: MainThread: 
unrecognized parameter weeklyrainin=0.000


On Wednesday, May 22, 2019 at 2:46:57 PM UTC+10, gjr80 wrote:
>
> Hi,
>
> Not an interceptor or ECOWITT HP2551 user but looking at your log1.txt log 
> extract it appears that your station is sending both rapidfire as well as 
> normal (non-rapidfire) updates. 
>
> Rapid fire:
> May 22 07:40:02 UBUNTUMATE-1000H weewx[26366]: interceptor: ServerThread: 
> GET: ID=IVICTORI1768==71.1=54.3=47.7
> =54.3=52=78=6.9&
> windgustmph=8.1=40=29.73=30.34=0.00&
> dailyrainin=0.00=0.00=1.35=2.25&
> solarradiation=16.88=0=2019-05-21%2021:40:01=
> EasyWeatherV1.3.2=updateraw=1=5
>
> normal:
> May 22 07:40:18 UBUNTUMATE-1000H weewx[26366]: interceptor: ServerThread: 
> POST: PASSKEY==EasyWeatherV1.3.2=2019-05-21+21:40:
> 17=71.4=52=30.34=29.73=54.3
> =78=18=5.4_avg10m=0.0
> =6.9=15.9=0.000=0.000=
> 0.000=0.000=0.000=1.346&
> yearlyrainin=2.248=16.02=0
>
> This really shouldn't be an issue but if you have a look at the number of 
> decimal places used for each rain related observation in each you will see 
> the RF updates use 2 decimal places and the normal updates 3 decimal 
> places. Consequently, when you have normal after a RF you get a rain 
> counter wraparound detected and your rainfall has the wrapped around figure 
> added. If you have RF after normal you get 0.002 inches added. RF after RF 
> has no effect as both yearly rain fields are identical. I don't think using 
> any of the other rain fields will make a difference because the same 
> decimal places difference exist with both. 
>
> Maybe less than ideal but can you turn off RF updates on your station, 
> that would at last show if that cures the issue or not. If so, maybe