[weewx-user] Is there an option to disable use of SSL for pushing data to Weather Underground?

[Kevin Key]

Is there an option to disable use of SSL for pushing data to Weather 
Underground? I am getting nothing but errors and can no longer push to WU.

-- 
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/2fe3c602-7fe4-4116-a902-e1312ddad927%40googlegroups.com.

Re: [weewx-user] Wunderground Upload fails with SSL error started last night

[Kevin Key]

Where is this file located? 

On Thursday, January 30, 2020 at 2:36:53 PM UTC-8, Jarom Hatch wrote:
>
> Quick fix for me was to change the URLs in restx.py to http instead of 
> https.  That got it back updating.
>
> On Thursday, January 30, 2020 at 3:30:32 PM UTC-7, Jarom Hatch wrote:
>>
>> This happened to me as well.  Reinstalling the CA certs didn't help.  I 
>> can curl using -k (ignore cert) but weewx isn't playing nicely with the 
>> certs as they are right now.
>>
>> On Thursday, January 30, 2020 at 1:40:56 PM UTC-7, Thomas Keffer wrote:
>>>
>>> You're the second person in recent days who has had WU certificate 
>>> problems. 
>>>
>>> Most likely they've been monkeying around with their API, as they tend 
>>> to do, but it's also possible your machine has stale certificates. Try this:
>>>
>>> *sudo apt-get update*
>>> *sudo apt-get install --reinstall ca-certificates*
>>>
>>> This will refresh your cache of certificates.
>>>
>>> -tk
>>>
>>> On Thu, Jan 30, 2020 at 11:53 AM J B  wrote:
>>>
 Hi,
 I've had a PWS uploading to Wunderground with Weewx 3.9.2 on a 
 Raspberry Pi for several months. Yesterday the station randomly stopped 
 uploading to WU although my local database is still being updated. 
 Checking 
 the log shows the following:

 restx: Wunderground-PWS: Failed upload attempt 1: >>> CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)>

 Elsewhere in the log I found the actual URL that is being queried by 
 weewx and when I run that manually with curl I get the following:

 user@host:~$ curl -L "
 https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&;
 "
 curl: (60) SSL certificate problem: unable to get local issuer 
 certificate
 More details here: https://curl.haxx.se/docs/sslcerts.html

 curl performs SSL certificate verification by default, using a "bundle"
  of Certificate Authority (CA) public keys (CA certs). If the default
  bundle file isn't adequate, you can specify an alternate file
  using the --cacert option.
 If this HTTPS server uses a certificate signed by a CA represented in
  the bundle, the certificate verification probably failed due to a
  problem with the certificate (it might be expired, or the name might
  not match the domain name in the URL).
 If you'd like to turn off curl's verification of the certificate, use
  the -k (or --insecure) option.


 I've tried this on 2 other systems (another RPi and a CentOS VM) with 
 the same result. I'm not that familiar with SSL certificates but when I 
 check the one for weatherstation.wunderground.com one in my browser it 
 says "valid".

 Is anyone else having this problem? How can I fix this issue?

 Thanks in advance.

 -- 
 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/b444ed31-e887-45bf-9c06-ad995ea53494%40googlegroups.com
  
 
 .

>>>

-- 
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/21bc80cf-3265-45ea-afb8-3423d46c9ad8%40googlegroups.com.

[weewx-user] Re: rtupdate.wunderground.com certificate error

[Kevin Rowett]

I no longer get a ssl cert error. 

Now get this error:

restx: Wunderground-PWS: Failed to publish record 2020-01-30 20:08:00 PST 
(1580443680): Failed upload after 3 tries

KR


On Thursday, January 30, 2020 at 1:56:30 PM UTC-8, J B wrote:
>
> I just tried running the request that Weewx attempts manually via curl and 
> it still gives me a certificate error:
>
> curl: (60) SSL certificate problem: unable to get local issuer certificate
>
>
> Maybe there's some caching involved?
>
> On Thursday, January 30, 2020 at 1:51:28 PM UTC-8, Denny Page wrote:
>>
>> I received an email from Wunderground "Yes, there was a problem that has 
>> been resolved."
>>
>> While the certificate error has been resolved, it appears that the https 
>> head still is not accepting updates. The http head appears fully 
>> functional. I've reported the secondary problem to them.
>>
>

-- 
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/5e69ba68-d34a-4e16-b4d8-94a036e9d224%40googlegroups.com.

[weewx-user] Re: Confusion with need for WeatherLinkIP

[Andrew Milner]

the belfryboy logger works well for a fraction the price of the davis 
...



On Thursday, 30 January 2020 21:28:41 UTC+2, vince wrote:
>
> On Thursday, January 30, 2020 at 9:31:50 AM UTC-8, Kevin Davis wrote:
>
>> While I'm twiddling my thumbs waiting for my Davis station to show up, I 
>> realize I might be confused about the WeatherLinkIP accessory.  That is a 
>> required part to interface with the Pi/WeeWx or not?
>>
>
>
> You need 'something' to connect the Davis to the Pi.Easiest path is to 
> buy the Davis datalogger.
>
> What Greg said re: alternatives such as 3rd-party loggers or talking to 
> Davis servers the hard way etc. etc. :-)
>
> For me, just buying the Davis logger was the lowest blood pressure path 
> (although the darn thing should be $25 max not $110+ for what it does).
>

-- 
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/7a0d56c9-0a7a-480a-a238-ffafa1746e82%40googlegroups.com.

Re: [weewx-user] Wunderground Upload fails with SSL error started last night

[RobbH]

That seems to have worked for me, too.


On Thursday, January 30, 2020 at 5:36:53 PM UTC-5, Jarom Hatch wrote:
>
> Quick fix for me was to change the URLs in restx.py to http instead of 
> https.  That got it back updating.
>
> On Thursday, January 30, 2020 at 3:30:32 PM UTC-7, Jarom Hatch wrote:
>>
>> This happened to me as well.  Reinstalling the CA certs didn't help.  I 
>> can curl using -k (ignore cert) but weewx isn't playing nicely with the 
>> certs as they are right now.
>>
>> On Thursday, January 30, 2020 at 1:40:56 PM UTC-7, Thomas Keffer wrote:
>>>
>>> You're the second person in recent days who has had WU certificate 
>>> problems. 
>>>
>>> Most likely they've been monkeying around with their API, as they tend 
>>> to do, but it's also possible your machine has stale certificates. Try this:
>>>
>>> *sudo apt-get update*
>>> *sudo apt-get install --reinstall ca-certificates*
>>>
>>> This will refresh your cache of certificates.
>>>
>>> -tk
>>>
>>> On Thu, Jan 30, 2020 at 11:53 AM J B  wrote:
>>>
 Hi,
 I've had a PWS uploading to Wunderground with Weewx 3.9.2 on a 
 Raspberry Pi for several months. Yesterday the station randomly stopped 
 uploading to WU although my local database is still being updated. 
 Checking 
 the log shows the following:

 restx: Wunderground-PWS: Failed upload attempt 1: >>> CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)>

 Elsewhere in the log I found the actual URL that is being queried by 
 weewx and when I run that manually with curl I get the following:

 user@host:~$ curl -L "
 https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&;
 "
 curl: (60) SSL certificate problem: unable to get local issuer 
 certificate
 More details here: https://curl.haxx.se/docs/sslcerts.html

 curl performs SSL certificate verification by default, using a "bundle"
  of Certificate Authority (CA) public keys (CA certs). If the default
  bundle file isn't adequate, you can specify an alternate file
  using the --cacert option.
 If this HTTPS server uses a certificate signed by a CA represented in
  the bundle, the certificate verification probably failed due to a
  problem with the certificate (it might be expired, or the name might
  not match the domain name in the URL).
 If you'd like to turn off curl's verification of the certificate, use
  the -k (or --insecure) option.


 I've tried this on 2 other systems (another RPi and a CentOS VM) with 
 the same result. I'm not that familiar with SSL certificates but when I 
 check the one for weatherstation.wunderground.com one in my browser it 
 says "valid".

 Is anyone else having this problem? How can I fix this issue?

 Thanks in advance.

 -- 
 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/b444ed31-e887-45bf-9c06-ad995ea53494%40googlegroups.com
  
 
 .

>>>

-- 
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/dcab8a61-8199-45c5-a45c-eebadef698a2%40googlegroups.com.

Re: [weewx-user] NOAA report

[Thomas Keffer]

Did you look in the NOAA templates and see what the pattern is? Just follow
the pattern. It will be something like $day.UV.max

UV is treated like any other observation type. See the section *Tags
* in the
Customizing Guide.

-tk


On Thu, Jan 30, 2020 at 4:53 PM Hector Valenzuela 
wrote:

> Hi, i added an UV sensor to my Davis Vantage Pro 2 and i have a raspberry
> pi 3 running weewx 3.5 and i want to add the UV report to NOAA template but
> i dont know.
>
> $day.UV.(,$NONE) something like that!
>
> --
> 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/7dcdd416-d2e5-46ff-b9ce-2691aae23fb0%40googlegroups.com
> 
> .
>

-- 
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/CAPq0zEAUDTv0v4Z25e0Gy85Hh2_NdWnEgjH1j7wfLnMeBZj0eA%40mail.gmail.com.

[weewx-user] NOAA report

[Hector Valenzuela]

Hi, i added an UV sensor to my Davis Vantage Pro 2 and i have a raspberry 
pi 3 running weewx 3.5 and i want to add the UV report to NOAA template but 
i dont know. 

$day.UV.(,$NONE) something like that!

-- 
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/7dcdd416-d2e5-46ff-b9ce-2691aae23fb0%40googlegroups.com.

Re: [weewx-user] Wunderground Upload fails with SSL error started last night

[Jarom Hatch]

Quick fix for me was to change the URLs in restx.py to http instead of 
https.  That got it back updating.

On Thursday, January 30, 2020 at 3:30:32 PM UTC-7, Jarom Hatch wrote:
>
> This happened to me as well.  Reinstalling the CA certs didn't help.  I 
> can curl using -k (ignore cert) but weewx isn't playing nicely with the 
> certs as they are right now.
>
> On Thursday, January 30, 2020 at 1:40:56 PM UTC-7, Thomas Keffer wrote:
>>
>> You're the second person in recent days who has had WU certificate 
>> problems. 
>>
>> Most likely they've been monkeying around with their API, as they tend to 
>> do, but it's also possible your machine has stale certificates. Try this:
>>
>> *sudo apt-get update*
>> *sudo apt-get install --reinstall ca-certificates*
>>
>> This will refresh your cache of certificates.
>>
>> -tk
>>
>> On Thu, Jan 30, 2020 at 11:53 AM J B  wrote:
>>
>>> Hi,
>>> I've had a PWS uploading to Wunderground with Weewx 3.9.2 on a Raspberry 
>>> Pi for several months. Yesterday the station randomly stopped uploading to 
>>> WU although my local database is still being updated. Checking the log 
>>> shows the following:
>>>
>>> restx: Wunderground-PWS: Failed upload attempt 1: >> CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)>
>>>
>>> Elsewhere in the log I found the actual URL that is being queried by 
>>> weewx and when I run that manually with curl I get the following:
>>>
>>> user@host:~$ curl -L "
>>> https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&;
>>> "
>>> curl: (60) SSL certificate problem: unable to get local issuer 
>>> certificate
>>> More details here: https://curl.haxx.se/docs/sslcerts.html
>>>
>>> curl performs SSL certificate verification by default, using a "bundle"
>>>  of Certificate Authority (CA) public keys (CA certs). If the default
>>>  bundle file isn't adequate, you can specify an alternate file
>>>  using the --cacert option.
>>> If this HTTPS server uses a certificate signed by a CA represented in
>>>  the bundle, the certificate verification probably failed due to a
>>>  problem with the certificate (it might be expired, or the name might
>>>  not match the domain name in the URL).
>>> If you'd like to turn off curl's verification of the certificate, use
>>>  the -k (or --insecure) option.
>>>
>>>
>>> I've tried this on 2 other systems (another RPi and a CentOS VM) with 
>>> the same result. I'm not that familiar with SSL certificates but when I 
>>> check the one for weatherstation.wunderground.com one in my browser it 
>>> says "valid".
>>>
>>> Is anyone else having this problem? How can I fix this issue?
>>>
>>> Thanks in advance.
>>>
>>> -- 
>>> 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/b444ed31-e887-45bf-9c06-ad995ea53494%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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/ee517063-e705-40a2-8edb-ac3122703679%40googlegroups.com.

Re: [weewx-user] Wunderground Upload fails with SSL error started last night

[Jarom Hatch]

This happened to me as well.  Reinstalling the CA certs didn't help.  I can 
curl using -k (ignore cert) but weewx isn't playing nicely with the certs 
as they are right now.

On Thursday, January 30, 2020 at 1:40:56 PM UTC-7, Thomas Keffer wrote:
>
> You're the second person in recent days who has had WU certificate 
> problems. 
>
> Most likely they've been monkeying around with their API, as they tend to 
> do, but it's also possible your machine has stale certificates. Try this:
>
> *sudo apt-get update*
> *sudo apt-get install --reinstall ca-certificates*
>
> This will refresh your cache of certificates.
>
> -tk
>
> On Thu, Jan 30, 2020 at 11:53 AM J B > 
> wrote:
>
>> Hi,
>> I've had a PWS uploading to Wunderground with Weewx 3.9.2 on a Raspberry 
>> Pi for several months. Yesterday the station randomly stopped uploading to 
>> WU although my local database is still being updated. Checking the log 
>> shows the following:
>>
>> restx: Wunderground-PWS: Failed upload attempt 1: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)>
>>
>> Elsewhere in the log I found the actual URL that is being queried by 
>> weewx and when I run that manually with curl I get the following:
>>
>> user@host:~$ curl -L "
>> https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&;
>> "
>> curl: (60) SSL certificate problem: unable to get local issuer certificate
>> More details here: https://curl.haxx.se/docs/sslcerts.html
>>
>> curl performs SSL certificate verification by default, using a "bundle"
>>  of Certificate Authority (CA) public keys (CA certs). If the default
>>  bundle file isn't adequate, you can specify an alternate file
>>  using the --cacert option.
>> If this HTTPS server uses a certificate signed by a CA represented in
>>  the bundle, the certificate verification probably failed due to a
>>  problem with the certificate (it might be expired, or the name might
>>  not match the domain name in the URL).
>> If you'd like to turn off curl's verification of the certificate, use
>>  the -k (or --insecure) option.
>>
>>
>> I've tried this on 2 other systems (another RPi and a CentOS VM) with the 
>> same result. I'm not that familiar with SSL certificates but when I check 
>> the one for weatherstation.wunderground.com one in my browser it says 
>> "valid".
>>
>> Is anyone else having this problem? How can I fix this issue?
>>
>> Thanks in advance.
>>
>> -- 
>> 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/b444ed31-e887-45bf-9c06-ad995ea53494%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/8135f05c-b72f-4241-bcb6-d830bbc1acc0%40googlegroups.com.

[weewx-user] Re: rtupdate.wunderground.com certificate error

[J B]

I just tried running the request that Weewx attempts manually via curl and 
it still gives me a certificate error:

curl: (60) SSL certificate problem: unable to get local issuer certificate


Maybe there's some caching involved?

On Thursday, January 30, 2020 at 1:51:28 PM UTC-8, Denny Page wrote:
>
> I received an email from Wunderground "Yes, there was a problem that has 
> been resolved."
>
> While the certificate error has been resolved, it appears that the https 
> head still is not accepting updates. The http head appears fully 
> functional. I've reported the secondary problem to them.
>

-- 
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/6595b863-76fd-40fc-a625-c93da3c7f012%40googlegroups.com.

[weewx-user] Re: rtupdate.wunderground.com certificate error

[Dave McCreath]

Snap! 

SSL Certificate issue resolved but data still not being accepted via https.

Webcam updates are getting through.

-- 
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/8de64d9b-b4f6-4080-b217-5f106f3d0dbc%40googlegroups.com.

[weewx-user] Re: rtupdate.wunderground.com certificate error

[Denny Page]

I received an email from Wunderground "Yes, there was a problem that has 
been resolved."

While the certificate error has been resolved, it appears that the https 
head still is not accepting updates. The http head appears fully 
functional. I've reported the secondary problem to them.

-- 
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/ef2bf4d6-b078-4a26-9737-b9b4a60312e7%40googlegroups.com.

Re: [weewx-user] Wunderground Upload fails with SSL error started last night

[Thomas Keffer]

You're the second person in recent days who has had WU certificate
problems.

Most likely they've been monkeying around with their API, as they tend to
do, but it's also possible your machine has stale certificates. Try this:

*sudo apt-get update*
*sudo apt-get install --reinstall ca-certificates*

This will refresh your cache of certificates.

-tk

On Thu, Jan 30, 2020 at 11:53 AM J B  wrote:

> Hi,
> I've had a PWS uploading to Wunderground with Weewx 3.9.2 on a Raspberry
> Pi for several months. Yesterday the station randomly stopped uploading to
> WU although my local database is still being updated. Checking the log
> shows the following:
>
> restx: Wunderground-PWS: Failed upload attempt 1:  CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)>
>
> Elsewhere in the log I found the actual URL that is being queried by weewx
> and when I run that manually with curl I get the following:
>
> user@host:~$ curl -L "
> https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&;
> "
> curl: (60) SSL certificate problem: unable to get local issuer certificate
> More details here: https://curl.haxx.se/docs/sslcerts.html
>
> curl performs SSL certificate verification by default, using a "bundle"
>  of Certificate Authority (CA) public keys (CA certs). If the default
>  bundle file isn't adequate, you can specify an alternate file
>  using the --cacert option.
> If this HTTPS server uses a certificate signed by a CA represented in
>  the bundle, the certificate verification probably failed due to a
>  problem with the certificate (it might be expired, or the name might
>  not match the domain name in the URL).
> If you'd like to turn off curl's verification of the certificate, use
>  the -k (or --insecure) option.
>
>
> I've tried this on 2 other systems (another RPi and a CentOS VM) with the
> same result. I'm not that familiar with SSL certificates but when I check
> the one for weatherstation.wunderground.com one in my browser it says
> "valid".
>
> Is anyone else having this problem? How can I fix this issue?
>
> Thanks in advance.
>
> --
> 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/b444ed31-e887-45bf-9c06-ad995ea53494%40googlegroups.com
> 
> .
>

-- 
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/CAPq0zEDHZiPk1MS9A40z3t0ykM%3DTDyd9fJ%2BKZOkf0cYojPEtfw%40mail.gmail.com.

[weewx-user] Re: rtupdate.wunderground.com certificate error

[J B]

Same problem here. Thanks for posting the response from WU.

-- 
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/f6336e3e-00f0-4d47-88ee-a51b4e2c3ef7%40googlegroups.com.

[weewx-user] Wunderground Upload fails with SSL error started last night

[J B]

Hi,
I've had a PWS uploading to Wunderground with Weewx 3.9.2 on a Raspberry Pi 
for several months. Yesterday the station randomly stopped uploading to WU 
although my local database is still being updated. Checking the log shows 
the following:

restx: Wunderground-PWS: Failed upload attempt 1: 

Elsewhere in the log I found the actual URL that is being queried by weewx 
and when I run that manually with curl I get the following:

user@host:~$ curl -L 
"https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?action=updateraw&;"
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.


I've tried this on 2 other systems (another RPi and a CentOS VM) with the 
same result. I'm not that familiar with SSL certificates but when I check 
the one for weatherstation.wunderground.com one in my browser it says 
"valid".

Is anyone else having this problem? How can I fix this issue?

Thanks in advance.

-- 
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/b444ed31-e887-45bf-9c06-ad995ea53494%40googlegroups.com.

[weewx-user] Re: Confusion with need for WeatherLinkIP

[vince]

On Thursday, January 30, 2020 at 9:31:50 AM UTC-8, Kevin Davis wrote:

> While I'm twiddling my thumbs waiting for my Davis station to show up, I 
> realize I might be confused about the WeatherLinkIP accessory.  That is a 
> required part to interface with the Pi/WeeWx or not?
>


You need 'something' to connect the Davis to the Pi.Easiest path is to 
buy the Davis datalogger.

What Greg said re: alternatives such as 3rd-party loggers or talking to 
Davis servers the hard way etc. etc. :-)

For me, just buying the Davis logger was the lowest blood pressure path 
(although the darn thing should be $25 max not $110+ for what it does).

-- 
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/08431c1b-13ff-4c92-b79a-abccb55773f0%40googlegroups.com.

Re: [weewx-user] Confusion with need for WeatherLinkIP

[Greg Troxel]

Kevin Davis  writes:

> While I'm twiddling my thumbs waiting for my Davis station to show up, I 
> realize I might be confused about the WeatherLinkIP accessory.  That is a 
> required part to interface with the Pi/WeeWx or not?

It is not, but you need some sort of datalogger.

THe Davis (Vantage Pro2, and I believe Vue) consoles record data but do
not come with a computer interface.  The standard approach is to use a
Weatherlink Serial or Weatherlink USB.  This is both something that
records data from the console and also provides an interface to a
computer.

http://www.weewx.com/docs/hardware.htm#vantage_notes

It seems people also configure weewx to talk to a weatherlink IP over
IP, locally, which works more or less the same way.  I have avoided
things like the weatherlink IP because it seems they end up requiring a
connection to the cloud, aka someone else's computer that is doing what
someone else wants, instead of what I want.

-- 
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/rmia76424pg.fsf%40s1.lexort.com.

[weewx-user] Re: rtupdate.wunderground.com certificate error

[Dave McCreath]

Looks like WU are onto this, see attached from 
apicommunity.wunderground.com/.


-- 
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/5629582a-dfe1-4f7a-9e36-500b600498c7%40googlegroups.com.

[weewx-user] Confusion with need for WeatherLinkIP

[Kevin Davis]

Dumb question.

While I'm twiddling my thumbs waiting for my Davis station to show up, I 
realize I might be confused about the WeatherLinkIP accessory.  That is a 
required part to interface with the Pi/WeeWx or not?

-- 
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/29143bd6-63a1-442b-93d6-50cf20642cef%40googlegroups.com.

[weewx-user] Recommended iPad skins?

[Stinkpot]

Hi all,

I'm hoping to use an old iPad as a weewx console. Can folks recommend skins 
that might be attractive and well-suited? I've seen the neowx and 
Belchertown ones, as well as the general WeeWx Showcase page, and I'll be 
trying those out. Still, I'd welcome recommendations on iPad-specific ones 
I may have missed. 

Many 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/25e09987-c68b-47cd-b413-aada86e2daea%40googlegroups.com.

[weewx-user] Re: rtupdate.wunderground.com certificate error

[Kevin Rowett]

About 22:00 UTC Jan 29, I started getting this error:

restx: Wunderground-PWS: Unexpected exception of type 
weewx[598]: restx: Wunderground-PWS: Thread exiting. Reason: hostname 
'weatherstation.wunderground.com' doesn't match either of '*.prod-pw
s-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-.us-south.containers.appdomain.cloud',
 
'prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-.us-south.cont
ainers.appdomain.cloud', 
'prod-pws-ng-546567.us-south.containers.appdomain.cloud'

KR


-- 
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/df742b3c-d981-4ddb-9053-4fcb3de2fd47%40googlegroups.com.

[weewx-user] Re: rtupdate.wunderground.com certificate error

[Denny Page]

I also started seeing this. You can also see the error 
here: 
https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php

The certificate that is up there is a 90 day Let's Encrypt certificate, 
with no alternate names at all. Essentially a bogus certificate.

I reported it to Wundergound support around 17:00 yesterday. Still no 
response...



On Thursday, January 30, 2020 at 7:57:14 AM UTC-8, Brice Ruth wrote:
>
> Just a heads up (I've reported this to wunderground) -
>
> It looks like the SSL/TLS certificate for `rtupdate.wunderground.com` is 
>> incorrect or the API has been compromised in some way. Accessing `
>> https://rtupdate.wunderground.com` in a browser such as Chrome yields a 
>> security warning: NET::ERR_CERT_COMMON_NAME_INVALID and the `weewx` 
>> software used to upload data to wunderground reports `hostname '
>> rtupdate.wunderground.com' doesn't match either of '*.
>> prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-.us-south.containers.appdomain.cloud',
>>  
>> 'prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-.u
>> s-south.containers.appdomain.cloud', 
>> 'prod-pws-ng-546567.us-south.containers.appdomain.cloud'` - maybe the DNS 
>> was switched to a new API endpoint but the SSL/TLS certificate that matches 
>> the DNS name wasn't configured correctly?
>>
>  
>
> This is blocking all weather station updates to `rtupdate.wunderground.com` 
>> that are using secure transport (which should be required because security 
>> credentials are passed in the requests).
>
>
>

-- 
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/5c715fd6-06a9-47b8-8e81-769ac725bd54%40googlegroups.com.

[weewx-user] Re: wanted: users with ecowitt gw1000 wifi bridge

[James Berry]

Just to confirm that it just rained a bit and the new changes in 0.53 caused 
the rain to register on my HP2551 :-)

-- 
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/91c2176f-b8c2-455b-9790-495008e7d7e3%40googlegroups.com.

[weewx-user] rtupdate.wunderground.com certificate error

[Brice Ruth]

Just a heads up (I've reported this to wunderground) -

It looks like the SSL/TLS certificate for `rtupdate.wunderground.com` is 
> incorrect or the API has been compromised in some way. Accessing 
> `https://rtupdate.wunderground.com` in a browser such as Chrome yields a 
> security warning: NET::ERR_CERT_COMMON_NAME_INVALID and the `weewx` 
> software used to upload data to wunderground reports `hostname 
> 'rtupdate.wunderground.com' doesn't match either of '*.
> prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-.us-south.containers.appdomain.cloud',
>  
> 'prod-pws-ng-546567-997b58a668d15d562a6bed58ea7c5f9e-.u
> s-south.containers.appdomain.cloud', 
> 'prod-pws-ng-546567.us-south.containers.appdomain.cloud'` - maybe the DNS 
> was switched to a new API endpoint but the SSL/TLS certificate that matches 
> the DNS name wasn't configured correctly?
>
 

This is blocking all weather station updates to `rtupdate.wunderground.com` 
> that are using secure transport (which should be required because security 
> credentials are passed in the requests).


-- 
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/0619e1ef-8a4b-49d1-8983-c6f413e31006%40googlegroups.com.

Re: [weewx-user] Re: WeeWX Beta 4.0.0b10 + vantage + LOOP1 = missing altimeter value

[Paul R Anderson]

Verified Gary's commit fixed altimeter issue under Python 2.7.16,
and  Python 3.7.3 values now being saved to database. Ever if the method
changes i'am sure it will be fine.

Sidenote seemed like the perfect time to try the new  wee_database
--calc-missing utility It of course worked perfectly and calculated all the
missing altimeter fields in my database. Great job!

Paul

On Thu, Jan 30, 2020 at 7:44 AM Thomas Keffer  wrote:

> Good sleuthing!
>
> The solution is a lot simpler: svc_dict is actually an ordered dictionary
> (specifically, a ConfigObj.section). So, all we have to do is make sure
> they are listed in the correct order in DEFAULTS_INI. Right now, they are
> in alphabetical order.
>
> -tk
>
> On Thu, Jan 30, 2020 at 1:00 AM gjr80  wrote:
>
>> OK, had another look and I see the problem; the changes in the 'Bad
>> commit' inadvertently caused WeeWX to try to calculate altimeter before
>> pressure and since altimeter is dependent on pressure that causes a
>> problem if pressure does not exist (as is the case on a Davis system
>> using other than LOOP2). I have applied a fix to the 4.0 code base, guess
>> we will see if that survives Tom's critical eye, but either way 4.0 will
>> have the problem fixed.
>>
>> Well spotted and thanks.
>>
>> Gary
>>
>> On Thursday, 30 January 2020 14:05:24 UTC+10, gjr80 wrote:
>>>
>>> I just updated to the latest 4.0 code and ran it under python3 with the
>>> simulator providing only barometer out of the three pressures (for the
>>> purposes of this exercise this is closely resembles the Davis loop packet).
>>> altimeter was not calculated for each loop packet; however, it was
>>> calculated for and appeared in each archive record. Coupled with the
>>> changes in the 'First_Know_Bad_commit' being of a cosmetic nature only I am
>>> not convinced yet there is an issue in the code base. Nothing seems out of
>>> place in your log or config, can you run WeeWX directly
>>>  and provide
>>> screen captures of the console output making sure we see at least one
>>> archive record (lines starting with REC:) and the loop packets (lines
>>> starting with LOOP:) leading up to the archive record.
>>>
>>> Gary
>>>
>>> On Wednesday, 29 January 2020 13:04:54 UTC+10, Paul Anderson wrote:

 Hi All,
 First off huge fan of WeeWx it is amazing software written by an
 unbelievable group of developers ! Thank you all for your tireless effects
 and dedication.

 Running Beta 4  version  4.0.0b10
 Hardware Vantage Pro 2
 Set to use LOOP1 so WeeWx needs to calculate altimeter as it's not in
 LOOP1.
 Unfortunately it seems to silently fail to calculate altimeter, if used
 in a tag it returns as na.
 And a sqlite query returns:
 Note the missing altimeter values.
 sqlite> select datetime, barometer,altimeter,pressure from archive
 order by datetime desc limit 5;
 1580259900|29.792||29.6113663568201

 I know this is going to sound crazy, the issue seems to have began at
 this commit:
 I'm sure that Halloween Goblins were somehow involved :)

 First Know Bad commit
 Document parameters of WXCalculate.__init__

 https://github.com/weewx/weewx/commit/bb130bb55c3c941c9160388161198ada199b3032
 @tkeffer
 tkeffer committed on Oct 31, 2019

 Last Know Good commit
 Don't bail on a type until you have to.

 https://github.com/weewx/weewx/commit/2286aece0abdaa2d1fc67e7da0627a620b9673ff
 @tkeffer
 tkeffer committed on Oct 30, 2019

 Ran each commit with the same weewx.conf
 Logged the run and put a sqlite query at the bottom.

 Because I had such a difficult time believing it has gone unnoticed so
 long looked for some evidence beyond my own setup. TK your DW3693 station
 stopped sending altimeter data to CWOP on 2019-11-09T23:10:00Z
 CWOP hasn't seen a Pressure reading from DW3693 since then.
 I'm guessing that you updated to First Know Bad commit at that time or
 Switched from LOOP2 to LOOP1 at that time?
 LAST Barometric Pressure to CWOP Nov 9 23:00 Z

 Station Date_Time  altimeter   air_temp
 _ID
 D3693,2019-11-09T22:20:00Z,30.16,55.99,71.0
 D3693,2019-11-09T22:30:00Z,30.16,55.99,70.0
 D3693,2019-11-09T22:40:00Z,30.17,55.99,70.0
 D3693,2019-11-09T22:50:00Z,30.16,55.99,70.0
 D3693,2019-11-09T23:00:00Z,30.16,55.99,70.0
 D3693,2019-11-09T23:10:00Z,,55.99,70.0
 D3693,2019-11-09T23:15:00Z,,55.99,71.0
 D3693,2019-11-09T23:25:00Z,,55.0,71.0
 D3693,2019-11-09T23:35:00Z,,55.0,71.0
 D3693,2019-11-09T23:45:00Z,,55.0,73.0


 Thanks,
 Paul

 Attached
 4.0.0b10.log.txt
 Last_Know_Good_Commit_2286a.log.txt
 First_Know_Bad_commit_bb130.log.txt
 weewx.conf.txt









 --
>> You received this message because you are subscribed to the Google Gr

[weewx-user] Re: wanted: users with ecowitt gw1000 wifi bridge

[Vetti52]

Tuesday, 30. January 2020 01:21:32 UTC+1 mwall wrote :
>
> [Interceptor]
> ...
> [[sensor_map_extensions]]
> txBatteryStatus = wh65_battery
>
> that way you get all the standard mappings, and just override the 
> txBatteryStatus
>
> m 
>

That's right, and I will do that. However, actually this is not the only 
change, I have made.
In summary there are these modifications:
class Consumer(object):
...
  DEFAULT_SENSOR_MAP = {
... 
  'rainEvent': 'rain_event',
  'txBatteryStatus': 'wh65_battery',
...

class EcowittClient(Consumer):
...
LABEL_MAP = { 
  'baromrelin': 'barometer',
...
  'eventrainin': 'rain_event',

IGNORED_LABELS = [
'PASSKEY', 'dateutc', 'stationtype', 'model', 'freq', # 
'baromrelin',
'maxdailygust', 'hourlyrainin', 'dailyrainin', #'eventrainin', 
 

I tried to put these mappings into the sensor map extensions, but I failed. 
Neither relative pressure nor rain event showed up. Maybe again you can 
help.
Unless I cannot put all of it into the extensions in weewx.conf, I prefer 
not to mess up with editing at two places but track my modifications in 
interceptor.py only.

-- 
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/7ecd2ebd-0e0c-42fd-8d6a-487e86d72cb0%40googlegroups.com.

[weewx-user] Re: wanted: users with ecowitt gw1000 wifi bridge

[Vetti52]

Tuesday, 30. January 2020 01:21:32 UTC+1 mwall wrote :
>
> [Interceptor]
> ...
> [[sensor_map_extensions]]
> txBatteryStatus = wh65_battery
>
> that way you get all the standard mappings, and just override the 
> txBatteryStatus
>
> m 
>

That's right, and I will do that. However, actually this is not the only 
change, I have made.
In summary there are these modifications:
class Consumer(object):
...
  DEFAULT_SENSOR_MAP = {
... 
  'rainEvent': 'rain_event',
  'txBatteryStatus': 'battery',
...

class EcowittClient(Consumer):
...
LABEL_MAP = { 
  'baromrelin': 'barometer',
...
  'eventrainin': 'rain_event',

IGNORED_LABELS = [
'PASSKEY', 'dateutc', 'stationtype', 'model', 'freq', # 
'baromrelin',
'maxdailygust', 'hourlyrainin', 'dailyrainin', #'eventrainin', 
 

I tried to put these mappings into the sensor map extensions, but I failed. 
Neither relative pressure nor rain event showed up. Maybe again you can 
help.
Unless I cannot put all of it into the extensions in weewx.conf, I prefer 
not to mess up with editing at two places but track my modifications in 
interceptor.py only.

-- 
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/9c4bebc5-7298-47a9-acd8-0a480303cf54%40googlegroups.com.

Re: [weewx-user] alarm.py question

[Thomas Keffer]

Oh, and be sure to set up a udev script to avoid port switching problems.
See the section *Installing a udev script
* in the User's Guide.

On Thu, Jan 30, 2020 at 4:55 AM Thomas Keffer  wrote:

> The easiest would probably to set up a logwatch
> . It's a better tool for
> these kinds of system problems.
>
> -tk
>
> On Thu, Jan 30, 2020 at 2:27 AM Roebert Akraks  wrote:
>
>> Hello,
>>
>> I use the email alarm extention which basically works as it is designed.
>> As soon as a value gets out of range, I get an email. I don't know why, but
>> this week, the usb-serial converter for the station got disconnected
>> (syslog shows ttyUSB0 disconnected, and afterwards showed up as ttyUSB1).
>> Therefore my driver started throwing error messages in the log, but I did
>> not get any email messages.
>>
>> I guess the problem here is, that no value was out of range, because
>> there simply was no value. The archive records don't contain the values to
>> check, the database shows NONE for most of the values.
>>
>>
>> Is there an (easy) way to catch a a problem like this and get notified?
>>
>>
>>
>> ---
>> About my station:
>> I built the station myself, because I have access to professional
>> temperature measurement equipment and I want to be albe to calibrate the
>> temperature sensor in a dry block calibrator. This is difficult or
>> impossible with the standard (consumer) weatherstation hardware. I wrote a
>> driver to read the (live - no data storage on the station) values with
>> modbus over a RS485 interface. It was running for almost a year without any
>> problems, until the USB converter caused a problem.
>>
>> --
>> 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/64f3d748-f16f-42f6-b572-11c31599b2c4%40googlegroups.com
>> 
>> .
>>
>

-- 
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/CAPq0zEBR7ff3JcHcF18yia%3D4U0JeAhrtF4Uo_LqY08J-CZ954g%40mail.gmail.com.

Re: [weewx-user] alarm.py question

[Thomas Keffer]

The easiest would probably to set up a logwatch
. It's a better tool for
these kinds of system problems.

-tk

On Thu, Jan 30, 2020 at 2:27 AM Roebert Akraks  wrote:

> Hello,
>
> I use the email alarm extention which basically works as it is designed.
> As soon as a value gets out of range, I get an email. I don't know why, but
> this week, the usb-serial converter for the station got disconnected
> (syslog shows ttyUSB0 disconnected, and afterwards showed up as ttyUSB1).
> Therefore my driver started throwing error messages in the log, but I did
> not get any email messages.
>
> I guess the problem here is, that no value was out of range, because there
> simply was no value. The archive records don't contain the values to check,
> the database shows NONE for most of the values.
>
>
> Is there an (easy) way to catch a a problem like this and get notified?
>
>
>
> ---
> About my station:
> I built the station myself, because I have access to professional
> temperature measurement equipment and I want to be albe to calibrate the
> temperature sensor in a dry block calibrator. This is difficult or
> impossible with the standard (consumer) weatherstation hardware. I wrote a
> driver to read the (live - no data storage on the station) values with
> modbus over a RS485 interface. It was running for almost a year without any
> problems, until the USB converter caused a problem.
>
> --
> 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/64f3d748-f16f-42f6-b572-11c31599b2c4%40googlegroups.com
> 
> .
>

-- 
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/CAPq0zEDPRwa39_dcCSd7oqnmd3TubKqtWgyhqTg8dWM-%3DnZ%3Dow%40mail.gmail.com.

Re: [weewx-user] Re: WeeWX Beta 4.0.0b10 + vantage + LOOP1 = missing altimeter value

[Thomas Keffer]

Good sleuthing!

The solution is a lot simpler: svc_dict is actually an ordered dictionary
(specifically, a ConfigObj.section). So, all we have to do is make sure
they are listed in the correct order in DEFAULTS_INI. Right now, they are
in alphabetical order.

-tk

On Thu, Jan 30, 2020 at 1:00 AM gjr80  wrote:

> OK, had another look and I see the problem; the changes in the 'Bad
> commit' inadvertently caused WeeWX to try to calculate altimeter before
> pressure and since altimeter is dependent on pressure that causes a
> problem if pressure does not exist (as is the case on a Davis system
> using other than LOOP2). I have applied a fix to the 4.0 code base, guess
> we will see if that survives Tom's critical eye, but either way 4.0 will
> have the problem fixed.
>
> Well spotted and thanks.
>
> Gary
>
> On Thursday, 30 January 2020 14:05:24 UTC+10, gjr80 wrote:
>>
>> I just updated to the latest 4.0 code and ran it under python3 with the
>> simulator providing only barometer out of the three pressures (for the
>> purposes of this exercise this is closely resembles the Davis loop packet).
>> altimeter was not calculated for each loop packet; however, it was
>> calculated for and appeared in each archive record. Coupled with the
>> changes in the 'First_Know_Bad_commit' being of a cosmetic nature only I am
>> not convinced yet there is an issue in the code base. Nothing seems out of
>> place in your log or config, can you run WeeWX directly
>>  and provide
>> screen captures of the console output making sure we see at least one
>> archive record (lines starting with REC:) and the loop packets (lines
>> starting with LOOP:) leading up to the archive record.
>>
>> Gary
>>
>> On Wednesday, 29 January 2020 13:04:54 UTC+10, Paul Anderson wrote:
>>>
>>> Hi All,
>>> First off huge fan of WeeWx it is amazing software written by an
>>> unbelievable group of developers ! Thank you all for your tireless effects
>>> and dedication.
>>>
>>> Running Beta 4  version  4.0.0b10
>>> Hardware Vantage Pro 2
>>> Set to use LOOP1 so WeeWx needs to calculate altimeter as it's not in
>>> LOOP1.
>>> Unfortunately it seems to silently fail to calculate altimeter, if used
>>> in a tag it returns as na.
>>> And a sqlite query returns:
>>> Note the missing altimeter values.
>>> sqlite> select datetime, barometer,altimeter,pressure from archive order
>>> by datetime desc limit 5;
>>> 1580259900|29.792||29.6113663568201
>>>
>>> I know this is going to sound crazy, the issue seems to have began at
>>> this commit:
>>> I'm sure that Halloween Goblins were somehow involved :)
>>>
>>> First Know Bad commit
>>> Document parameters of WXCalculate.__init__
>>>
>>> https://github.com/weewx/weewx/commit/bb130bb55c3c941c9160388161198ada199b3032
>>> @tkeffer
>>> tkeffer committed on Oct 31, 2019
>>>
>>> Last Know Good commit
>>> Don't bail on a type until you have to.
>>>
>>> https://github.com/weewx/weewx/commit/2286aece0abdaa2d1fc67e7da0627a620b9673ff
>>> @tkeffer
>>> tkeffer committed on Oct 30, 2019
>>>
>>> Ran each commit with the same weewx.conf
>>> Logged the run and put a sqlite query at the bottom.
>>>
>>> Because I had such a difficult time believing it has gone unnoticed so
>>> long looked for some evidence beyond my own setup. TK your DW3693 station
>>> stopped sending altimeter data to CWOP on 2019-11-09T23:10:00Z
>>> CWOP hasn't seen a Pressure reading from DW3693 since then.
>>> I'm guessing that you updated to First Know Bad commit at that time or
>>> Switched from LOOP2 to LOOP1 at that time?
>>> LAST Barometric Pressure to CWOP Nov 9 23:00 Z
>>>
>>> Station Date_Time  altimeter   air_temp
>>> _ID
>>> D3693,2019-11-09T22:20:00Z,30.16,55.99,71.0
>>> D3693,2019-11-09T22:30:00Z,30.16,55.99,70.0
>>> D3693,2019-11-09T22:40:00Z,30.17,55.99,70.0
>>> D3693,2019-11-09T22:50:00Z,30.16,55.99,70.0
>>> D3693,2019-11-09T23:00:00Z,30.16,55.99,70.0
>>> D3693,2019-11-09T23:10:00Z,,55.99,70.0
>>> D3693,2019-11-09T23:15:00Z,,55.99,71.0
>>> D3693,2019-11-09T23:25:00Z,,55.0,71.0
>>> D3693,2019-11-09T23:35:00Z,,55.0,71.0
>>> D3693,2019-11-09T23:45:00Z,,55.0,73.0
>>>
>>>
>>> Thanks,
>>> Paul
>>>
>>> Attached
>>> 4.0.0b10.log.txt
>>> Last_Know_Good_Commit_2286a.log.txt
>>> First_Know_Bad_commit_bb130.log.txt
>>> weewx.conf.txt
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
> 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/688dcca9-89e1-4c13-a3ea-51e0a728c079%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe fr

[weewx-user] alarm.py question

[Roebert Akraks]

Hello,

I use the email alarm extention which basically works as it is designed. As 
soon as a value gets out of range, I get an email. I don't know why, but 
this week, the usb-serial converter for the station got disconnected 
(syslog shows ttyUSB0 disconnected, and afterwards showed up as ttyUSB1). 
Therefore my driver started throwing error messages in the log, but I did 
not get any email messages.

I guess the problem here is, that no value was out of range, because there 
simply was no value. The archive records don't contain the values to check, 
the database shows NONE for most of the values.


Is there an (easy) way to catch a a problem like this and get notified?



---
About my station:
I built the station myself, because I have access to professional 
temperature measurement equipment and I want to be albe to calibrate the 
temperature sensor in a dry block calibrator. This is difficult or 
impossible with the standard (consumer) weatherstation hardware. I wrote a 
driver to read the (live - no data storage on the station) values with 
modbus over a RS485 interface. It was running for almost a year without any 
problems, until the USB converter caused a problem.

-- 
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/64f3d748-f16f-42f6-b572-11c31599b2c4%40googlegroups.com.

[weewx-user] Re: raspberry pi reinstall (full remove + reinstall) problems

[gjr80]

Hi,

When did you copy weewx.conf from GitHub? I'm guessing it was in the last 
few hours. If so you have inadvertently been caught up in the release 
preparations for WeeWX 4.0 and you have ended up with a default WeeWX 4.0 
weewx.conf. That will cause problems for a pre-4.0 install. You don't say 
what WeeWX version you are using, but if it's 3.9.2 then try this weewx.conf 
. If it's 
an earlier version again just change the 3.9.2 in the link address to the 
version number you are using.

Gary

On Thursday, 30 January 2020 18:18:28 UTC+10, Tim St. Clair wrote:
>
> I have raspbian on a pi3b with previously working FineOffsetUSB wh1080 
> station. I broke several things with some bad updates and at the same time 
> the batteries on the usb unit went flat. After changing them the station 
> appeared to be in the lockup problem (similar to 
> https://github.com/weewx/weewx/wiki/FineOffset-USB-lockup).
>
> I did a full apt-get remove / autoremove / removed the configs and data 
> folders, rebooted, updated and apt-get install weewx again. This did not 
> generate any errors.
>
> the /etc/weewx/weewx.conf file was not written at all.
>
> I stopped the weewx service, then I copied it out of the conf off github (
> https://raw.githubusercontent.com/weewx/weewx/master/weewx.conf) and 
> created it, then I modified the conf to have my station details plus these 
> details (copied from http://weewx.com/docs/usersguide.htm#[FineOffsetUSB]
> ):
>
> debug = 1
>
> [Station]
> station_type = FineOffsetUSB
>
> [StdArchive]
> record_generation = software
>
> [FineOffsetUSB]
> model = WH1010
> polling_mode = PERIODIC
> polling_interval = 60
>
>
> manually trying to run weewx with this config yields:
>
> pi@raspberrypi:/etc/weewx $ sudo weewxd ./weewx.conf
> Traceback (most recent call last):
>   File "/usr/bin/weewxd", line 64, in 
> weewx.engine.main(options, args)
>   File "/usr/share/weewx/weewx/engine.py", line 888, in main
> engine = engine_class(config_dict)
>   File "/usr/share/weewx/weewx/engine.py", line 72, in __init__
> self.setupStation(config_dict)
>   File "/usr/share/weewx/weewx/engine.py", line 90, in setupStation
> driver = config_dict[stationType]['driver']
>   File "/usr/lib/python2.7/dist-packages/configobj.py", line 554, in 
> __getitem__
> val = dict.__getitem__(self, key)
> KeyError: 'driver'
>
> Modifying the config so that the driver is specified in the FineOffsetUSB 
> section
>
>  driver = weewx.drivers.fousb
>
> then re-running the program manually now yields
>
> pi@raspberrypi:/etc/weewx $ sudo weewxd ./weewx.conf 
> Traceback (most recent call last):
>   File "/usr/bin/weewxd", line 64, in 
> weewx.engine.main(options, args)
>   File "/usr/share/weewx/weewx/engine.py", line 888, in main
> engine = engine_class(config_dict)
>   File "/usr/share/weewx/weewx/engine.py", line 78, in __init__
> self.loadServices(config_dict)
>   File "/usr/share/weewx/weewx/engine.py", line 142, in loadServices
> self.service_obj.append(weeutil.weeutil._get_object(svc)(self, 
> config_dict))
>   File "/usr/share/weewx/weewx/engine.py", line 500, in __init__
> self.setup_database(config_dict)
>   File "/usr/share/weewx/weewx/engine.py", line 608, in setup_database
> dbmanager = self.engine.db_binder.get_manager(self.data_binding, 
> initialize=True)
>   File "/usr/share/weewx/weewx/manager.py", line 871, in get_manager
> default_binding_dict=defaults)
>   File "/usr/share/weewx/weewx/manager.py", line 1002, in 
> get_manager_dict_from_config
> manager_dict['schema'] = weeutil.weeutil._get_object(schema_name)
>   File "/usr/share/weewx/weeutil/weeutil.py", line 1107, in _get_object
> mod = __import__(module)
> ImportError: No module named wview_extended
>
> I can't get the config to run. Worried that it didn't install properly 
> even after a full reinstall and wondering why not.
>
>
>
>

-- 
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/3babd12e-2ebe-44d6-af86-4d62c7cbab2d%40googlegroups.com.

[weewx-user] Re: WeeWX Beta 4.0.0b10 + vantage + LOOP1 = missing altimeter value

[gjr80]

OK, had another look and I see the problem; the changes in the 'Bad commit' 
inadvertently caused WeeWX to try to calculate altimeter before pressure 
and since altimeter is dependent on pressure that causes a problem if 
pressure does not exist (as is the case on a Davis system using other than 
LOOP2). I have applied a fix to the 4.0 code base, guess we will see if 
that survives Tom's critical eye, but either way 4.0 will have the problem 
fixed.

Well spotted and thanks.

Gary

On Thursday, 30 January 2020 14:05:24 UTC+10, gjr80 wrote:
>
> I just updated to the latest 4.0 code and ran it under python3 with the 
> simulator providing only barometer out of the three pressures (for the 
> purposes of this exercise this is closely resembles the Davis loop packet). 
> altimeter was not calculated for each loop packet; however, it was 
> calculated for and appeared in each archive record. Coupled with the 
> changes in the 'First_Know_Bad_commit' being of a cosmetic nature only I am 
> not convinced yet there is an issue in the code base. Nothing seems out of 
> place in your log or config, can you run WeeWX directly 
>  and provide 
> screen captures of the console output making sure we see at least one 
> archive record (lines starting with REC:) and the loop packets (lines 
> starting with LOOP:) leading up to the archive record.
>
> Gary
>
> On Wednesday, 29 January 2020 13:04:54 UTC+10, Paul Anderson wrote:
>>
>> Hi All,
>> First off huge fan of WeeWx it is amazing software written by an 
>> unbelievable group of developers ! Thank you all for your tireless effects 
>> and dedication. 
>>
>> Running Beta 4  version  4.0.0b10
>> Hardware Vantage Pro 2
>> Set to use LOOP1 so WeeWx needs to calculate altimeter as it's not in 
>> LOOP1.
>> Unfortunately it seems to silently fail to calculate altimeter, if used 
>> in a tag it returns as na.
>> And a sqlite query returns:
>> Note the missing altimeter values.
>> sqlite> select datetime, barometer,altimeter,pressure from archive order 
>> by datetime desc limit 5;
>> 1580259900|29.792||29.6113663568201
>>
>> I know this is going to sound crazy, the issue seems to have began at 
>> this commit:
>> I'm sure that Halloween Goblins were somehow involved :) 
>>
>> First Know Bad commit
>> Document parameters of WXCalculate.__init__
>>
>> https://github.com/weewx/weewx/commit/bb130bb55c3c941c9160388161198ada199b3032
>> @tkeffer
>> tkeffer committed on Oct 31, 2019
>>
>> Last Know Good commit
>> Don't bail on a type until you have to.
>>
>> https://github.com/weewx/weewx/commit/2286aece0abdaa2d1fc67e7da0627a620b9673ff
>> @tkeffer
>> tkeffer committed on Oct 30, 2019
>>
>> Ran each commit with the same weewx.conf
>> Logged the run and put a sqlite query at the bottom.
>>
>> Because I had such a difficult time believing it has gone unnoticed so 
>> long looked for some evidence beyond my own setup. TK your DW3693 station 
>> stopped sending altimeter data to CWOP on 2019-11-09T23:10:00Z
>> CWOP hasn't seen a Pressure reading from DW3693 since then.
>> I'm guessing that you updated to First Know Bad commit at that time or 
>> Switched from LOOP2 to LOOP1 at that time?
>> LAST Barometric Pressure to CWOP Nov 9 23:00 Z
>>
>> Station Date_Time  altimeter   air_temp
>> _ID
>> D3693,2019-11-09T22:20:00Z,30.16,55.99,71.0
>> D3693,2019-11-09T22:30:00Z,30.16,55.99,70.0
>> D3693,2019-11-09T22:40:00Z,30.17,55.99,70.0
>> D3693,2019-11-09T22:50:00Z,30.16,55.99,70.0
>> D3693,2019-11-09T23:00:00Z,30.16,55.99,70.0
>> D3693,2019-11-09T23:10:00Z,,55.99,70.0
>> D3693,2019-11-09T23:15:00Z,,55.99,71.0
>> D3693,2019-11-09T23:25:00Z,,55.0,71.0
>> D3693,2019-11-09T23:35:00Z,,55.0,71.0
>> D3693,2019-11-09T23:45:00Z,,55.0,73.0 
>>
>>
>> Thanks,
>> Paul
>>
>> Attached
>> 4.0.0b10.log.txt
>> Last_Know_Good_Commit_2286a.log.txt
>> First_Know_Bad_commit_bb130.log.txt
>> weewx.conf.txt
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

-- 
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/688dcca9-89e1-4c13-a3ea-51e0a728c079%40googlegroups.com.

[weewx-user] raspberry pi reinstall (full remove + reinstall) problems

[Tim St. Clair]

I have raspbian on a pi3b with previously working FineOffsetUSB wh1080 
station. I broke several things with some bad updates and at the same time 
the batteries on the usb unit went flat. After changing them the station 
appeared to be in the lockup problem (similar 
to https://github.com/weewx/weewx/wiki/FineOffset-USB-lockup).

I did a full apt-get remove / autoremove / removed the configs and data 
folders, rebooted, updated and apt-get install weewx again. This did not 
generate any errors.

the /etc/weewx/weewx.conf file was not written at all.

I stopped the weewx service, then I copied it out of the conf off github 
(https://raw.githubusercontent.com/weewx/weewx/master/weewx.conf) and 
created it, then I modified the conf to have my station details plus these 
details (copied from http://weewx.com/docs/usersguide.htm#[FineOffsetUSB]):

debug = 1

[Station]
station_type = FineOffsetUSB

[StdArchive]
record_generation = software

[FineOffsetUSB]
model = WH1010
polling_mode = PERIODIC
polling_interval = 60


manually trying to run weewx with this config yields:

pi@raspberrypi:/etc/weewx $ sudo weewxd ./weewx.conf
Traceback (most recent call last):
  File "/usr/bin/weewxd", line 64, in 
weewx.engine.main(options, args)
  File "/usr/share/weewx/weewx/engine.py", line 888, in main
engine = engine_class(config_dict)
  File "/usr/share/weewx/weewx/engine.py", line 72, in __init__
self.setupStation(config_dict)
  File "/usr/share/weewx/weewx/engine.py", line 90, in setupStation
driver = config_dict[stationType]['driver']
  File "/usr/lib/python2.7/dist-packages/configobj.py", line 554, in 
__getitem__
val = dict.__getitem__(self, key)
KeyError: 'driver'

Modifying the config so that the driver is specified in the FineOffsetUSB 
section

 driver = weewx.drivers.fousb

then re-running the program manually now yields

pi@raspberrypi:/etc/weewx $ sudo weewxd ./weewx.conf 
Traceback (most recent call last):
  File "/usr/bin/weewxd", line 64, in 
weewx.engine.main(options, args)
  File "/usr/share/weewx/weewx/engine.py", line 888, in main
engine = engine_class(config_dict)
  File "/usr/share/weewx/weewx/engine.py", line 78, in __init__
self.loadServices(config_dict)
  File "/usr/share/weewx/weewx/engine.py", line 142, in loadServices
self.service_obj.append(weeutil.weeutil._get_object(svc)(self, 
config_dict))
  File "/usr/share/weewx/weewx/engine.py", line 500, in __init__
self.setup_database(config_dict)
  File "/usr/share/weewx/weewx/engine.py", line 608, in setup_database
dbmanager = self.engine.db_binder.get_manager(self.data_binding, 
initialize=True)
  File "/usr/share/weewx/weewx/manager.py", line 871, in get_manager
default_binding_dict=defaults)
  File "/usr/share/weewx/weewx/manager.py", line 1002, in 
get_manager_dict_from_config
manager_dict['schema'] = weeutil.weeutil._get_object(schema_name)
  File "/usr/share/weewx/weeutil/weeutil.py", line 1107, in _get_object
mod = __import__(module)
ImportError: No module named wview_extended

I can't get the config to run. Worried that it didn't install properly even 
after a full reinstall and wondering why not.



-- 
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/611c8406-f1ac-42d9-bb06-aef995c0437a%40googlegroups.com.