date:20201223

So the weewx python code says it is using the Ryan and Stolzenbach model, 
which has a few approximations that don't work well in some cases, and it 
looks like this is one of them.

I've attached a plot comparing 3 insolation models predicting global 
horizontal irradiation.
Bird and Hulstrom 1991
Bras 1992
and  Ryan and Stolzenbach  1972

B&H has a lot more parameters to account for, but I have just thrown in the 
date/location for Boston, using whatever parameters were in the 
spreadsheet, and come up with the following comparison.
I used the B&H predictions for modelling my solar PV system and found it 
gives very close results - or at least it did before my system got a bit 
older.  However R&S also gives results that aren't too bad in my location.

I have the code in php, but no spare time at the moment to convert to 
python.

On Tuesday, 22 December 2020 at 2:19:29 am UTC+10 t...@tom.org wrote:

> kk, glad you corroborated my observations. I am no expert in this for 
> sure. I am just tired of all of the comments I get from visitors to the 
> website about how my readings exceed theoretical max. I could remove the 
> max, but that doesn't seem fun.
>
> I do not have the expertise to validate the way weewx calculates it nor am 
> I even competent in Python, but for those who may, here is a link to the 
> code:
>
>
> https://github.com/weewx/weewx/blob/d91635f3bc429f906d1f084c6a6bc8ee09fa1a27/bin/weewx/wxformulas.py#L332
>
>
>
> On Sunday, December 20, 2020 at 1:26:31 PM UTC-5 kk44...@gmail.com wrote:
>
>> I found that thread interesting, so I added the column "maxSolarRad", 
>> too. 
>>
>> [image: dayradiation.png]
>> Readings of the console and the WeatherLinkLive device are quite the 
>> same. And the readings of "radiation" are higher than "maxSolarRad". The 
>> values I upload to the local weather network are well in the range of other 
>> stations nearby.
>>
>>
>> Greg Troxel schrieb am Sonntag, 20. Dezember 2020 um 17:58:01 UTC+1:
>>
>>>
>>> Greg Troxel  writes: 
>>>
>>> > Can someone share how to add maxSolarRad (when it is in the db) to the 
>>> > graphs for the traditional skin? Can I graph radiation, max 
>>> (observed), 
>>> > and theory all at once, having three? 
>>>
>>> The answer is to just add it and label it; it comes out in green after 
>>> radiation in blue and max in red. Pro Tip: add it after radiation_max, 
>>> which is the max of local observations, and don't stick the line after 
>>> the radiation_max header and the 4 lines defining how max should be. 
>>>
>>>
>>> [[[dayradiation]]] 
>>> radiation 
>>> radiation_max 
>>> data_type = radiation 
>>> aggregate_type = max 
>>> aggregate_interval = 3600 
>>> label = max 
>>> maxSolarRad 
>>> label = theory 
>>>
>>

-- 
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/1bf064d3-bac9-4ed0-928c-5730d7af051bn%40googlegroups.com.

Re: [weewx-user] Re: Solar Radiation > Theoretical Max

I should have looked a bit more closely before posting!  I used the solrad 
excel code from Uni Washington.
I had adjusted my B&H parameters to represent quite clean air but forgot to 
match the Bras and RS code from default.
If I:

   1. reset the BH turbidity params to default,
   2. adjust the Bras param down to 1.6 and
   3. adjust the RS param to 0.84,

 then the curves are close to normalised at peak.  The RS curve is still a 
somewhat poor representation at dawn and dusk, while Bras is probably close 
enough to BH that it's not worth the extra effort.  
The main advantage with B&H is the atmospheric moisture, which I think 
contributes significantly, but differently from the atmospheric turbidity 
parameters and changes the shape of the curve. So a single parameter cannot 
account for all variables.
The safest bet might be to adjust the parameter for clear skies and then 
say that is an upper limit.

On Wednesday, 23 December 2020 at 6:31:47 pm UTC+10 Cameron D wrote:

> So the weewx python code says it is using the Ryan and Stolzenbach model, 
> which has a few approximations that don't work well in some cases, and it 
> looks like this is one of them.
>
> I've attached a plot comparing 3 insolation models predicting global 
> horizontal irradiation.
> Bird and Hulstrom 1991
> Bras 1992
> and  Ryan and Stolzenbach  1972
>
> B&H has a lot more parameters to account for, but I have just thrown in 
> the date/location for Boston, using whatever parameters were in the 
> spreadsheet, and come up with the following comparison.
> I used the B&H predictions for modelling my solar PV system and found it 
> gives very close results - or at least it did before my system got a bit 
> older.  However R&S also gives results that aren't too bad in my location.
>
> I have the code in php, but no spare time at the moment to convert to 
> python.
>
> On Tuesday, 22 December 2020 at 2:19:29 am UTC+10 t...@tom.org wrote:
>
>> kk, glad you corroborated my observations. I am no expert in this for 
>> sure. I am just tired of all of the comments I get from visitors to the 
>> website about how my readings exceed theoretical max. I could remove the 
>> max, but that doesn't seem fun.
>>
>> I do not have the expertise to validate the way weewx calculates it nor 
>> am I even competent in Python, but for those who may, here is a link to the 
>> code:
>>
>>
>> https://github.com/weewx/weewx/blob/d91635f3bc429f906d1f084c6a6bc8ee09fa1a27/bin/weewx/wxformulas.py#L332
>>
>>
>>
>> On Sunday, December 20, 2020 at 1:26:31 PM UTC-5 kk44...@gmail.com wrote:
>>
>>> I found that thread interesting, so I added the column "maxSolarRad", 
>>> too. 
>>>
>>> [image: dayradiation.png]
>>> Readings of the console and the WeatherLinkLive device are quite the 
>>> same. And the readings of "radiation" are higher than "maxSolarRad". The 
>>> values I upload to the local weather network are well in the range of other 
>>> stations nearby.
>>>
>>>
>>> Greg Troxel schrieb am Sonntag, 20. Dezember 2020 um 17:58:01 UTC+1:
>>>

 Greg Troxel  writes: 

 > Can someone share how to add maxSolarRad (when it is in the db) to 
 the 
 > graphs for the traditional skin? Can I graph radiation, max 
 (observed), 
 > and theory all at once, having three? 

 The answer is to just add it and label it; it comes out in green after 
 radiation in blue and max in red. Pro Tip: add it after radiation_max, 
 which is the max of local observations, and don't stick the line after 
 the radiation_max header and the 4 lines defining how max should be. 


 [[[dayradiation]]] 
 radiation 
 radiation_max 
 data_type = radiation 
 aggregate_type = max 
 aggregate_interval = 3600 
 label = max 
 maxSolarRad 
 label = theory 

>>>

-- 
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/0d468847-eed9-4d9d-9649-4937a5e61901n%40googlegroups.com.

Re: [weewx-user] Re: Solar Radiation > Theoretical Max

And then I forgot the attachment!


On Wednesday, 23 December 2020 at 7:18:31 pm UTC+10 Cameron D wrote:

> I should have looked a bit more closely before posting!  I used the solrad 
> excel code from Uni Washington.
> I had adjusted my B&H parameters to represent quite clean air but forgot 
> to match the Bras and RS code from default.
> If I:
>
>1. reset the BH turbidity params to default,
>2. adjust the Bras param down to 1.6 and
>3. adjust the RS param to 0.84,
>
>  then the curves are close to normalised at peak.  The RS curve is still a 
> somewhat poor representation at dawn and dusk, while Bras is probably close 
> enough to BH that it's not worth the extra effort.  
> The main advantage with B&H is the atmospheric moisture, which I think 
> contributes significantly, but differently from the atmospheric turbidity 
> parameters and changes the shape of the curve. So a single parameter cannot 
> account for all variables.
> The safest bet might be to adjust the parameter for clear skies and then 
> say that is an upper limit.
>
> On Wednesday, 23 December 2020 at 6:31:47 pm UTC+10 Cameron D wrote:
>
>> So the weewx python code says it is using the Ryan and Stolzenbach model, 
>> which has a few approximations that don't work well in some cases, and it 
>> looks like this is one of them.
>>
>> I've attached a plot comparing 3 insolation models predicting global 
>> horizontal irradiation.
>> Bird and Hulstrom 1991
>> Bras 1992
>> and  Ryan and Stolzenbach  1972
>>
>> B&H has a lot more parameters to account for, but I have just thrown in 
>> the date/location for Boston, using whatever parameters were in the 
>> spreadsheet, and come up with the following comparison.
>> I used the B&H predictions for modelling my solar PV system and found it 
>> gives very close results - or at least it did before my system got a bit 
>> older.  However R&S also gives results that aren't too bad in my location.
>>
>> I have the code in php, but no spare time at the moment to convert to 
>> python.
>>
>> On Tuesday, 22 December 2020 at 2:19:29 am UTC+10 t...@tom.org wrote:
>>
>>> kk, glad you corroborated my observations. I am no expert in this for 
>>> sure. I am just tired of all of the comments I get from visitors to the 
>>> website about how my readings exceed theoretical max. I could remove the 
>>> max, but that doesn't seem fun.
>>>
>>> I do not have the expertise to validate the way weewx calculates it nor 
>>> am I even competent in Python, but for those who may, here is a link to the 
>>> code:
>>>
>>>
>>> https://github.com/weewx/weewx/blob/d91635f3bc429f906d1f084c6a6bc8ee09fa1a27/bin/weewx/wxformulas.py#L332
>>>
>>>
>>>
>>> On Sunday, December 20, 2020 at 1:26:31 PM UTC-5 kk44...@gmail.com 
>>> wrote:
>>>
 I found that thread interesting, so I added the column "maxSolarRad", 
 too. 

 [image: dayradiation.png]
 Readings of the console and the WeatherLinkLive device are quite the 
 same. And the readings of "radiation" are higher than "maxSolarRad". The 
 values I upload to the local weather network are well in the range of 
 other 
 stations nearby.


 Greg Troxel schrieb am Sonntag, 20. Dezember 2020 um 17:58:01 UTC+1:

>
> Greg Troxel  writes: 
>
> > Can someone share how to add maxSolarRad (when it is in the db) to 
> the 
> > graphs for the traditional skin? Can I graph radiation, max 
> (observed), 
> > and theory all at once, having three? 
>
> The answer is to just add it and label it; it comes out in green after 
> radiation in blue and max in red. Pro Tip: add it after radiation_max, 
> which is the max of local observations, and don't stick the line after 
> the radiation_max header and the 4 lines defining how max should be. 
>
>
> [[[dayradiation]]] 
> radiation 
> radiation_max 
> data_type = radiation 
> aggregate_type = max 
> aggregate_interval = 3600 
> label = max 
> maxSolarRad 
> label = theory 
>


-- 
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/ef4b8a0b-110b-4e48-bb2e-50ebae8c8277n%40googlegroups.com.

Re: [weewx-user] Re: Solar Radiation > Theoretical Max

Very useful, Cameron.

It looks like the R-S curve is quite a bit lower, maybe as much as 20%
lower, at dawn and dusk, which seems to be when people are experiencing
values higher than maxSolarRad.

On Wed, Dec 23, 2020 at 1:19 AM Cameron D  wrote:

> And then I forgot the attachment!
>
>
> On Wednesday, 23 December 2020 at 7:18:31 pm UTC+10 Cameron D wrote:
>
>> I should have looked a bit more closely before posting!  I used the
>> solrad excel code from Uni Washington.
>> I had adjusted my B&H parameters to represent quite clean air but forgot
>> to match the Bras and RS code from default.
>> If I:
>>
>>1. reset the BH turbidity params to default,
>>2. adjust the Bras param down to 1.6 and
>>3. adjust the RS param to 0.84,
>>
>>  then the curves are close to normalised at peak.  The RS curve is still
>> a somewhat poor representation at dawn and dusk, while Bras is probably
>> close enough to BH that it's not worth the extra effort.
>> The main advantage with B&H is the atmospheric moisture, which I think
>> contributes significantly, but differently from the atmospheric turbidity
>> parameters and changes the shape of the curve. So a single parameter cannot
>> account for all variables.
>> The safest bet might be to adjust the parameter for clear skies and then
>> say that is an upper limit.
>>
>> On Wednesday, 23 December 2020 at 6:31:47 pm UTC+10 Cameron D wrote:
>>
>>> So the weewx python code says it is using the Ryan and
>>> Stolzenbach model, which has a few approximations that don't work well in
>>> some cases, and it looks like this is one of them.
>>>
>>> I've attached a plot comparing 3 insolation models predicting global
>>> horizontal irradiation.
>>> Bird and Hulstrom 1991
>>> Bras 1992
>>> and  Ryan and Stolzenbach  1972
>>>
>>> B&H has a lot more parameters to account for, but I have just thrown in
>>> the date/location for Boston, using whatever parameters were in the
>>> spreadsheet, and come up with the following comparison.
>>> I used the B&H predictions for modelling my solar PV system and found it
>>> gives very close results - or at least it did before my system got a bit
>>> older.  However R&S also gives results that aren't too bad in my location.
>>>
>>> I have the code in php, but no spare time at the moment to convert to
>>> python.
>>>
>>> On Tuesday, 22 December 2020 at 2:19:29 am UTC+10 t...@tom.org wrote:
>>>
 kk, glad you corroborated my observations. I am no expert in this for
 sure. I am just tired of all of the comments I get from visitors to the
 website about how my readings exceed theoretical max. I could remove the
 max, but that doesn't seem fun.

 I do not have the expertise to validate the way weewx calculates it nor
 am I even competent in Python, but for those who may, here is a link to the
 code:


 https://github.com/weewx/weewx/blob/d91635f3bc429f906d1f084c6a6bc8ee09fa1a27/bin/weewx/wxformulas.py#L332



 On Sunday, December 20, 2020 at 1:26:31 PM UTC-5 kk44...@gmail.com
 wrote:

> I found that thread interesting, so I added the column "maxSolarRad",
> too.
>
> [image: dayradiation.png]
> Readings of the console and the WeatherLinkLive device are quite the
> same. And the readings of "radiation" are higher than "maxSolarRad". The
> values I upload to the local weather network are well in the range of 
> other
> stations nearby.
>
>
> Greg Troxel schrieb am Sonntag, 20. Dezember 2020 um 17:58:01 UTC+1:
>
>>
>> Greg Troxel  writes:
>>
>> > Can someone share how to add maxSolarRad (when it is in the db) to
>> the
>> > graphs for the traditional skin? Can I graph radiation, max
>> (observed),
>> > and theory all at once, having three?
>>
>> The answer is to just add it and label it; it comes out in green
>> after
>> radiation in blue and max in red. Pro Tip: add it after
>> radiation_max,
>> which is the max of local observations, and don't stick the line
>> after
>> the radiation_max header and the 4 lines defining how max should be.
>>
>>
>> [[[dayradiation]]]
>> radiation
>> radiation_max
>> data_type = radiation
>> aggregate_type = max
>> aggregate_interval = 3600
>> label = max
>> maxSolarRad
>> label = theory
>>
> --
> 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/ef4b8a0b-110b-4e48-bb2e-50ebae8c8277n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to t

Re: [weewx-user] NWS Radar Changes

2020-12-23 Thread Mark Jenks

I just sent an email to NWS.  I'll let you know the response if I get one..

Good Morning!

For years, there have been many many people who have linked your radar 
images and loops to their PWS (Personal weather station) websites.  I 
currently use weewx @ http://weather.mjenks.net
With the new radar, this is no longer possible, and the .gz versions just 
aren't good enough quality.  So I have to use someone else's radar now.

It sure would be nice if you could provide an iframe code snipped that we 
could embed into our webpages.Or at least recreate the images and loops.

This is what I have been using that no longer works.

radar_img = http://radar.weather.gov/ridge/lite/N0R/GRB_loop.gif
radar_url = 
http://radar.weather.gov/ridge/radar.php?product=NCR&rid=GRB&loop=yes

Thank you!

Mark Jenks
Station ID - DW7584

On Tuesday, December 22, 2020 at 4:20:17 PM UTC-6 chri...@gmail.com wrote:

> Thank you for looking into this folks. It sounds as though they have gone 
> the same route as Environment Canada did a long time ago now.  No more 
> animated gifs available, instead they build the animations on the fly with 
> overlays and a repository of images. The best I could do for Environment 
> Canada radars was to create a shell script that runs on the web server cron 
> that guesses at the current time stamp for the latest image and saves it to 
> my webserver.
>
> Less than great.
>
> It sure would be nice if they could just provide an iframe code snipped 
> that we could embed into our webpages.
> Alas.
> Cheers
> Chris
> On Saturday, December 19, 2020 at 9:59:31 AM UTC-8 peterq...@gmail.com 
> wrote:
>
>> I hooked up the NWS gif and it's worse than useless. It's hours old and 
>> shows nothing, flashes clutter, and repeats. Now, it should show nothing 
>> but the flashing of clutter is super annoying. 
>>
>> As much as I'm pissed at WU, I'm going to use their gif while it's 
>> available.
>>
>> On Sat, Dec 19, 2020 at 7:17 AM wfs...@gmail.com  
>> wrote:
>>
>>> Yes John kind of crummy images and I just tried mine for KILX and it is 
>>> two hours behind the current UTC.
>>>
>>> On Friday, December 18, 2020 at 11:56:56 AM UTC-6 jo...@johnkline.com 
>>> wrote:
>>>
 The loops in https://radar.weather.gov/ridge/lite/ 
  seem to be up to 
 date today.

 For example:
 https://radar.weather.gov/ridge/lite/KMUX_loop.gif

 As such, that’s also an option, although these gifs are tough to get 
 used to.

 On Dec 18, 2020, at 9:38 AM, John Kline  wrote:

 This thread has a nice solution (see URL below):

 https://www.wxforum.net/index.php?topic=40980.0

 Terms of use:
 https://www.wunderground.com/company/legal

 (In the following URL, substitute your radar station for OAX.  Set 
 weewx.conf’s Seasons radar_img value to this.)

 https://radblast.wunderground.com/cgi-bin/radar/WUNIDS_map?station=OAX&brand=wui&num=18&delay=15&type=N0R&frame=0&scale=1.000&noclutter=0&showstorms=0&showlabels=1&severe=1&rainsnow=0&lightning=0&smooth=0

 On Dec 17, 2020, at 10:00 PM, John Kline  wrote:

 Although the directory listing here shows old timestamps:
 https://radar.weather.gov/ridge/lite/

 The loop is being updated (albeit still a few hours old and I’m not a 
 fan of this radar imagery):
 https://radar.weather.gov/ridge/lite/KMUX_loop.gif

 Although not part of the loop, this image is only about 30m old:
 https://radar.weather.gov/ridge/lite/KMUX_1.gif

 It’s not clear one could determine which file has the latest image.  
 Maybe this will improve over time and the _0.gif will have the latest gif 
 (and/or the loop will be updated regularly).

 On Dec 17, 2020, at 4:18 PM, John Kline  wrote:

 I’ve been grappling with this.  It is annoying.  The “new site” is 
 maddening to interact with: https://radar.weather.gov/

 There’s a FAQ about the change here:
 https://www.weather.gov/radarfaq

 The FAQ tells one where files can be downloaded.  I’ve started to look 
 at them (they are gzipped), but, so far, I haven’t found anything 
 acceptable to use.  I’m seeing a single color overlay (with no base map).  
 Still looking, but this is an awful change.

 John

 On Dec 17, 2020, at 4:05 PM, peterq...@gmail.com  
 wrote:

 I use the old standard skin (modified). The NWS radar site changed 
 today and the optional radar graphic no longer works. Has anyone dug into 
 this and figured out how to get the new site to work?

 It's no big deal if not - I'll take a look myself and post something 
 once I find out how to make it work with the new site.

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

Re: [weewx-user] NWS Radar Changes

2020-12-23 Thread Mark Jenks

Email contact information here:
https://www.weather.gov/radarfaq

On Wednesday, December 23, 2020 at 7:10:50 AM UTC-6 Mark Jenks wrote:

> I just sent an email to NWS.  I'll let you know the response if I get one..
>
> 
>
> Good Morning!
>
> For years, there have been many many people who have linked your radar 
> images and loops to their PWS (Personal weather station) websites.  I 
> currently use weewx @ http://weather.mjenks.net
> With the new radar, this is no longer possible, and the .gz versions just 
> aren't good enough quality.  So I have to use someone else's radar now.
>
> It sure would be nice if you could provide an iframe code snipped that we 
> could embed into our webpages.Or at least recreate the images and loops.
>
> This is what I have been using that no longer works.
>
> radar_img = http://radar.weather.gov/ridge/lite/N0R/GRB_loop.gif
> radar_url = 
> http://radar.weather.gov/ridge/radar.php?product=NCR&rid=GRB&loop=yes
>
> Thank you!
>
> Mark Jenks
> Station ID - DW7584
>
> On Tuesday, December 22, 2020 at 4:20:17 PM UTC-6 chri...@gmail.com wrote:
>
>> Thank you for looking into this folks. It sounds as though they have gone 
>> the same route as Environment Canada did a long time ago now.  No more 
>> animated gifs available, instead they build the animations on the fly with 
>> overlays and a repository of images. The best I could do for Environment 
>> Canada radars was to create a shell script that runs on the web server cron 
>> that guesses at the current time stamp for the latest image and saves it to 
>> my webserver.
>>
>> Less than great.
>>
>> It sure would be nice if they could just provide an iframe code snipped 
>> that we could embed into our webpages.
>> Alas.
>> Cheers
>> Chris
>> On Saturday, December 19, 2020 at 9:59:31 AM UTC-8 peterq...@gmail.com 
>> wrote:
>>
>>> I hooked up the NWS gif and it's worse than useless. It's hours old and 
>>> shows nothing, flashes clutter, and repeats. Now, it should show nothing 
>>> but the flashing of clutter is super annoying. 
>>>
>>> As much as I'm pissed at WU, I'm going to use their gif while it's 
>>> available.
>>>
>>> On Sat, Dec 19, 2020 at 7:17 AM wfs...@gmail.com  
>>> wrote:
>>>
 Yes John kind of crummy images and I just tried mine for KILX and it is 
 two hours behind the current UTC.

 On Friday, December 18, 2020 at 11:56:56 AM UTC-6 jo...@johnkline.com 
 wrote:

> The loops in https://radar.weather.gov/ridge/lite/ 
>  seem to be up to 
> date today.
>
> For example:
> https://radar.weather.gov/ridge/lite/KMUX_loop.gif
>
> As such, that’s also an option, although these gifs are tough to get 
> used to.
>
> On Dec 18, 2020, at 9:38 AM, John Kline  wrote:
>
> 
>
> This thread has a nice solution (see URL below):
>
> https://www.wxforum.net/index.php?topic=40980.0
>
> Terms of use:
> https://www.wunderground.com/company/legal
>
> (In the following URL, substitute your radar station for OAX.  Set 
> weewx.conf’s Seasons radar_img value to this.)
>
>
> https://radblast.wunderground.com/cgi-bin/radar/WUNIDS_map?station=OAX&brand=wui&num=18&delay=15&type=N0R&frame=0&scale=1.000&noclutter=0&showstorms=0&showlabels=1&severe=1&rainsnow=0&lightning=0&smooth=0
>
>
> On Dec 17, 2020, at 10:00 PM, John Kline  wrote:
>
> 
> Although the directory listing here shows old timestamps:
> https://radar.weather.gov/ridge/lite/
>
> The loop is being updated (albeit still a few hours old and I’m not a 
> fan of this radar imagery):
> https://radar.weather.gov/ridge/lite/KMUX_loop.gif
>
> Although not part of the loop, this image is only about 30m old:
> https://radar.weather.gov/ridge/lite/KMUX_1.gif
>
> It’s not clear one could determine which file has the latest image.  
> Maybe this will improve over time and the _0.gif will have the latest gif 
> (and/or the loop will be updated regularly).
>
> On Dec 17, 2020, at 4:18 PM, John Kline  wrote:
>
> 
> I’ve been grappling with this.  It is annoying.  The “new site” is 
> maddening to interact with: https://radar.weather.gov/
>
> There’s a FAQ about the change here:
> https://www.weather.gov/radarfaq
>
> The FAQ tells one where files can be downloaded.  I’ve started to look 
> at them (they are gzipped), but, so far, I haven’t found anything 
> acceptable to use.  I’m seeing a single color overlay (with no base map). 
>  
> Still looking, but this is an awful change.
>
> John
>
> On Dec 17, 2020, at 4:05 PM, peterq...@gmail.com  
> wrote:
>
> I use the old standard skin (modified). The NWS radar site changed 
> today and the optional radar graphic no longer works. Has anyone dug into 
> this and figured out how to get the ne

Re: [weewx-user] Re: ecowitt sensor autodiscovery and soilMoist units

gjr80  writes:

> *cb* stands for *centibar* and is (I believe) a measure of the soil water 
> tension or the level of moisture held in the soil. Davis soil moisture 
> sensors read in centibars. Strictly speaking I guess that fields that 
> contain Ecowitt soil moisture data should be moved from *group_moisture* to 
> *group_percent*, though given there is no real need for inter-unit 
> conversion (à la temperature or speed) and they use the same default format 
> there is not much to be gained. True, the default unit label is different 
> but that can be easily overridden.

Soil moisture is very complicated.   It sounds like Davis sensors are on
the pro end of things with an absolute calibration.

I have a WH51, not hooked up to weewx, and find that the % readings are
useful over time to compare to other readings, but don't seem to have
absolute calibration.

When digging into this there are two moisture levels of primary interest
for any particular soil type and ay particular plant:

  wilting level: the level below which the plant is unhappy due to dry

  saturation: the level you get to when the dirt/plant is in a long
  soaking rain, more or less

For my plant, those were about 22% and 40% with the default calibration
of the WH51 receiver.  One can adjust those to make that range read 0 to
100, but I think that's only adjusting the display.

I do think it would be good that Ecowitt % values not be mislabled as
centibar, if my assumption they aren't centibar is correct.

Some reading for those with a lot of Copious Spare Time.   I'm not
qualified to judge this, but it comes across as being from people that
know what they are doing.

https://www.metergroup.com/environment/articles/what-is-soil-moisture-science-behind-the-measurement/

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

signature.asc
Description: PGP signature

Re: [weewx-user] Re: ecowitt sensor autodiscovery and soilMoist units


The quick summary of that tl;dr page is that there are two separate
concepts:

  Volumetric Water Content (VWC), which is the fraction of any volume of
  soil that is water.  This is dimensionless, and typically in %.

  Water potential, reported as pressure

The wilting level of a plant depends on water potential, and the
relationship between VWC and water potential is highly dependent on soil
type.

Field capacity is the moisture after soaking and draining (but not
evaporation or plant use, I think).

With my WH51, it seems reasonably clear that it's trying to measure VMC,
and my experimentally determined 22%/40% makes sense.

The Davis sensor is very clearly water potential with a negative sign,
termed "suction" and in pressure units.  The spec sheet says:

  
https://www.davisinstruments.com/product_documents/weather/spec_sheets/6440_SS.pdf
  https://irrometer.com/sensors.html

  The Soil Moisture/Temperature Station converts the electrical
  resistance reading from the sensor into a calibrated reading of
  centibars of soil water suction with a range from 0 (wettest) to 200
  (driest) centibars.


The metergroup page gives an example of -0.3 Mpa, or -300 000 Pa.
Midrange in Davis is 100 cb which is 1 bar, and mulitplying by 100 000
Pa/bar gets -100 000 Pa.  This doesn't quite line up as the example is
1.5x the top range, but it could be that typical soil for a
non-irrigated tree is much drier than for crops.


Architecturally, weewx should have separate column names with associated
units for VWC and either suction or water potential, deciding on
positive/negative.  That's my theory right now and I'm sticking to it
for at least an hour!

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


signature.asc
Description: PGP signature

Re: [weewx-user] Re: Solar Radiation > Theoretical Max

That is part of it, but some of the early morning examples are up to 500% 
different, although with very small values.  In those cases I still suspect 
there is extra scattered radiation from the surroundings, whether it be 
trees or buildings.
I wonder also if the sensor type may change results slightly.
There may also be a calibration error, due to the different spectral energy 
distribution comparing dawn and midday, or perhaps even simple nonlinearity 
near zero output. These are not research-grade instruments that most of us 
are using.
If you add all that in with ozone, water vapour and particulates of 
different sizes, all of which change seasonally and daily, you will never 
expect precise agreement.

Here's another example - I left the RS and Bras models with the same values 
as previous, and changed the BH model to ignore just ozone, water vapour 
and particulates.
That gave the solid line. Then I set albedo for the full snow cover and the 
result was  the dashed line.

So, the "theoretical curve" for around Boston is anywhere in that range of 
curves, or it could be even lower in moderately polluted skies.
On Wednesday, 23 December 2020 at 10:51:08 pm UTC+10 tke...@gmail.com wrote:

> Very useful, Cameron.
>
> It looks like the R-S curve is quite a bit lower, maybe as much as 20% 
> lower, at dawn and dusk, which seems to be when people are experiencing 
> values higher than maxSolarRad.
>
> On Wed, Dec 23, 2020 at 1:19 AM Cameron D  wrote:
>
>> And then I forgot the attachment!
>>
>>
>> On Wednesday, 23 December 2020 at 7:18:31 pm UTC+10 Cameron D wrote:
>>
>>> I should have looked a bit more closely before posting!  I used the 
>>> solrad excel code from Uni Washington.
>>> I had adjusted my B&H parameters to represent quite clean air but forgot 
>>> to match the Bras and RS code from default.
>>> If I:
>>>
>>>1. reset the BH turbidity params to default,
>>>2. adjust the Bras param down to 1.6 and
>>>3. adjust the RS param to 0.84,
>>>
>>>  then the curves are close to normalised at peak.  The RS curve is still 
>>> a somewhat poor representation at dawn and dusk, while Bras is probably 
>>> close enough to BH that it's not worth the extra effort.  
>>> The main advantage with B&H is the atmospheric moisture, which I think 
>>> contributes significantly, but differently from the atmospheric turbidity 
>>> parameters and changes the shape of the curve. So a single parameter cannot 
>>> account for all variables.
>>> The safest bet might be to adjust the parameter for clear skies and then 
>>> say that is an upper limit.
>>>
>>> On Wednesday, 23 December 2020 at 6:31:47 pm UTC+10 Cameron D wrote:
>>>
 So the weewx python code says it is using the Ryan and 
 Stolzenbach model, which has a few approximations that don't work well in 
 some cases, and it looks like this is one of them.

 I've attached a plot comparing 3 insolation models predicting global 
 horizontal irradiation.
 Bird and Hulstrom 1991
 Bras 1992
 and  Ryan and Stolzenbach  1972

 B&H has a lot more parameters to account for, but I have just thrown in 
 the date/location for Boston, using whatever parameters were in the 
 spreadsheet, and come up with the following comparison.
 I used the B&H predictions for modelling my solar PV system and found 
 it gives very close results - or at least it did before my system got a 
 bit 
 older.  However R&S also gives results that aren't too bad in my location.

 I have the code in php, but no spare time at the moment to convert to 
 python.

 On Tuesday, 22 December 2020 at 2:19:29 am UTC+10 t...@tom.org wrote:

> kk, glad you corroborated my observations. I am no expert in this for 
> sure. I am just tired of all of the comments I get from visitors to the 
> website about how my readings exceed theoretical max. I could remove the 
> max, but that doesn't seem fun.
>
> I do not have the expertise to validate the way weewx calculates it 
> nor am I even competent in Python, but for those who may, here is a link 
> to 
> the code:
>
>
> https://github.com/weewx/weewx/blob/d91635f3bc429f906d1f084c6a6bc8ee09fa1a27/bin/weewx/wxformulas.py#L332
>
>
>
> On Sunday, December 20, 2020 at 1:26:31 PM UTC-5 kk44...@gmail.com 
> wrote:
>
>> I found that thread interesting, so I added the column "maxSolarRad", 
>> too. 
>>
>> [image: dayradiation.png]
>> Readings of the console and the WeatherLinkLive device are quite the 
>> same. And the readings of "radiation" are higher than "maxSolarRad". The 
>> values I upload to the local weather network are well in the range of 
>> other 
>> stations nearby.
>>
>>
>> Greg Troxel schrieb am Sonntag, 20. Dezember 2020 um 17:58:01 UTC+1:
>>
>>>
>>> Greg Troxel  writes: 
>>>
>>> > Can someone share how to add maxSolarRad (when

Re: [weewx-user] Cydia pomonella

2020-12-23 Thread Andy

I will be glad to test this when you get it going.

Andy

On Thursday, December 17, 2020 at 1:22:15 PM UTC-8 charlescu...@gmail.com 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, 17 Dec 2020 12:26:56 -0800
> Tom Keffer  wrote:
>
> > get_series() is used by the image generator, not the Cheetah
> > generator. It's used to create plot lines. See line 176 in
> > imagegenerator.py
> > <
> https://github.com/weewx/weewx/blob/master/bin/weewx/imagegenerator.py#L176
> >
>
> I see. Thanks.
>
> - -- 
> .. Be Seeing You,
> .. Chuck Rhode, Sheboygan, WI, USA
> .. Weather: http://LacusVeris.com/WX
> .. 31° — Wind Calm — Sky overcast.
>
> -BEGIN PGP SIGNATURE-
>
> iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCX9vL+wAKCRBg2/xipKOW
> UmjzAJ9mhx1M/86VP2KfIK7rfmeK5DyQ8wCeL8CNtj9vg0UvG+oDpcYqmE0SjJ4=
> =5Rub
> -END PGP SIGNATURE-
>

-- 
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/5944244c-8982-47de-ab2b-2aaa7bcc9941n%40googlegroups.com.

Re: [weewx-user] Re: Installation at remote site using RPi and VNC?

2020-12-23 Thread Andy

I just set up an open-vpn server and a raspberrypi as the vpn client. The 
pi will try to reconnect if the connection dropped.

Andy
On Tuesday, December 15, 2020 at 11:29:53 AM UTC-8 Sunray wrote:

> Correction, the wind direction problem affected only the data archived in 
> the WLIP logger before Weewx came on line. 
>
> But another issue is that the Weewx traffic seems to block the WLIP logger 
> from doing its regular uploading of data to Davis Weatherlink.com. Any 
> advice on this ?
>
> On Tuesday, 15 December 2020 at 18:39:22 UTC+2 Sunray wrote:
>
>> Progress report : Success!
>>
>> I was able to visit the cabin today for two hours (cold!) and installed 
>> the RPI  hardware. After some headscratching due to a security camera on 
>> the same LAN, I was able to establish a RealVNC Connect session between the 
>> RPI connected by cable on the cabin's LAN and my laptop running on my 
>> cellphone's wifi hotspot. This enabled me to find out all necessary IP 
>> addresses including the Vantage Vue's Weatherlink IP address, which I 
>> needed for the WeeWx setup. 
>>
>> I then did the reconfiguration of WeeWx from Simulator to Vantage Vue but 
>> did not manage to get a html update. A reduction of the Vantage's archiving 
>> interval from 2 hours to 5 minutes did not help. I could, however, using 
>> the weewxd command see that the LOOP packets now originated from the 
>> weather station and not simulated. So it looked promising!
>>
>> Back home, error messages suggested database errors. After some study I 
>> changed in the config file: 
>>
>>- Driver model_type changed from 2 to 1 
>>- Archive record generation from hardware to software. 
>>
>> After these changes the html generation works fine!
>>
>>  
>>
>> Thank you everyone for your advice and suggestions! I have one immediate 
>> issue - the wind direction graphs only display on a 16-point scale (22.5 
>> degrees intervals). 
>>
>> My next project will be to try to implement a realtime wind display 
>> (displaying each LOOP packet's data - advice welcome!) and to publish the 
>> weather data in a safe way.
>>
>> On Thursday, 10 December 2020 at 21:49:56 UTC+2 vince wrote:
>>
>>> Indeed.   I used to fail2ban ssh attempts from other than my home ip 
>>> 'one' address.  I had over 100 countries hitting me, with the vast majority 
>>> the usual APT countries we've all read about.   That said, geoip fencing is 
>>> an inexact science and it's not that hard to make it look like a different 
>>> source address.
>>>
>>> I only let in US+CA+AU to my website due to too many attacks, by adding 
>>> geoip fencing to nginx which is pretty easy to set up.   I also have a 
>>> custom fail2ban to ban anybody trying to look for php/wordpress stuff as 
>>> that's a big attack vector by the bots and script kiddies attacking 
>>> websites.
>>>
>>> I've locked myself out of my AWS box a couple times via messing up 
>>> fail2ban blocks of ssh incoming, requiring me to just nuke+rebuild it, so I 
>>> probably need another solution there.   Thinking of just permitting my LAN 
>>> ip there once again, if I can come up with a second path in just-in-case.  
>>> Maybe I'll try WireGuard there and let my home box tunnel into the cloud 
>>> VM.  Maybe.  I'll have to think about it some more.
>>>
>>> It's an arms race and it's tiring even needing to fight 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/e9e9bb13-cefc-43ac-8927-5ddda089e829n%40googlegroups.com.

Re: [weewx-user] Re: Corrupted Memory card. Now I lost 6 months of data?

2020-12-23 Thread Joe

I appreciate the responses.  I'm having trouble updating to the newest 
version now so I'm not sure what went wrong overall.

On Monday, December 21, 2020 at 3:08:42 PM UTC-6 vince wrote:

> (sigh - sqlite3 db in my previous post, of course...)
>

-- 
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/d3cca3aa-689c-45a4-a9f7-eb2937e9e44dn%40googlegroups.com.

Re: [weewx-user] Re: Corrupted Memory card. Now I lost 6 months of data?

On Wednesday, December 23, 2020 at 7:42:49 AM UTC-8 Joe wrote:

>  I'm having trouble updating to the newest version now so I'm not sure 
> what went wrong overall.
>

In the absence of seeing any logs we don't either.

-- 
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/85bc1b66-061c-4213-a503-2ab2021f0f9an%40googlegroups.com.

[weewx-user] MQTT SSL Problems

Hello,
I am trying to run MQTT throug SSL. 
Before everything was working, as soon I have added Let's Encrypt 
certificate to my webpage jastrabie.online, Belchertown skin and weather34 
too autoupdate was not working.
Problem is, HTTPS page cant handle HTTP MQTT, it throws an error.
So I started to reconfigure my MQTT to use SSL. I used this manual from 
author of Belchertown 
skin: https://obrienlabs.net/how-to-setup-your-own-mqtt-broker/

weewx.conf:
[[MQTT]]
server_url = mqtt://pi:@jastrabie.online:8883/
topic = weather
unit_system = METRIC
binding = archive, loop
aggregation = aggregate
[[[tls]]]
tls_version = tlsv1
ca_certs = /etc/ssl/certs/ca-certificates.crt

tail -f shows this:
WeeWX weewx[18183] ERROR weewx.restx: MQTT: Failed to publish record 
2020-12-23 16:47:00 CET (1608738420): Failed upload after 3 tries

When I comment the whole [[[tls]]] section, MQTT then is like:
Dec 23 16:56:33 WeeWX weewx[19872] ERROR user.mqtt: publish failed for 
weather/loop: 4
Dec 23 16:56:33 WeeWX weewx[19872] INFO weewx.restx: MQTT: Published record 
2020-12-23 16:56:00 CET (1608738960)

if I run:
sudo netstat -tulpn | grep -E '8883|9001' 
result is:
tcp0  0 0.0.0.0:90010.0.0.0:*   LISTEN  
3722/mosquitto  
tcp0  0 0.0.0.0:88830.0.0.0:*   LISTEN  
3722/mosquitto  

Belchertown skin.conf:
# MQTT Websockets defaults
mqtt_websockets_enabled = 1
mqtt_websockets_host = "192.168.1.17"
mqtt_websockets_port = 9001
mqtt_websockets_ssl = 1
mqtt_websockets_topic = "weather/loop"
disconnect_live_website_visitor = 180


what I am doing wrong?

WeeWX4.2.0, Belchertown 1.2.0, Raspberry Pi, https://jastrabie.online

Thank you for help!
Miso, Slovakia



-- 
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/e1b9bcc9-0d66-4d76-b1f0-c13969e92931n%40googlegroups.com.

[weewx-user] Re: Build of weewx on M1 Mac

2020-12-23 Thread geoffs...@gmail.com

Hi Chris,

I had a problem with the python install as I had the system install, the 
python installer version and a Pyenv version. I got rid of the python 
installer version and killed all of the symlinks in the /usr/local/ folder 
and then installed Pyenv to install 3.9.1. I then set Pyenv global to 3.9.1 
and was able to get python3 -V to spit out 3.9.1 and /usr/bin/env python to 
open 3.9.1. This was the key. When I built weewx, it at first had the 
shebang in the file pointing to the python installed by the python 
installer. This is why if I started it from Terminal it worked fine, but 
using Launchctl, it was looking for a python install that didn't exist. 
Look at the #! first line of weewxd to make sure it points to an accessible 
python 3.9.1 location. Since I had build weewx several times, I didn't 
realize that a script was made for each build and it was just reinstalling 
that script each time rather than looking for the updated python and making 
a new pointer to the updated python. If you get rid of the weewx-4.2.0 
folder and unzip it again, you will get rid of the versions that it has 
already made. Hope this helps. Finally got it to work as it should once the 
!# in all of the weewx files pointed to the correct python install. It 
looks like weewx uses /usr/bin/env python to determine what to write in the 
files, so if you do /usr/bin/env python in the terminal it should open the 
3.9.1 version of python. If not, you need to get that working before 
running a fresh setup.py install. Hope this helps.

On Tuesday, December 22, 2020 at 10:38:31 AM UTC-8 chri...@gmail.com wrote:

> I have not been able to convince MacOS 11.1 to allow me to use launchctl 
> for weewx either and I am on an Intel machine.
> I'll keep trying on my end.  Did you have any trouble getting all the 
> requirements for weewx included in python 3.9.1? I got stuck part way 
> through and had to go back to 3.8.6
>
> Cheers
> Chris
> On Monday, December 21, 2020 at 11:48:44 AM UTC-8 geoffs...@gmail.com 
> wrote:
>
>> Setup pyenv using Homebrew M1 experimental version and then installed 
>> python 3.9.1
>> Then installed all necessary libraries. Needed to use homebrew to install 
>> FreeType and libjpeg to get a working Pillow install.
>>
>> can be started as a daemon using 
>>
>> cd /Users/Shared/weewx
>> python3 ./bin/weewxd weewx.conf -d
>> Runs as native on M1 ARM64 arch
>> *weewx[1269] INFO __main__: Initializing weewx version 4.2.0*
>> *weewx[1269] INFO __main__: Using Python 3.9.1 (default, Dec 21 2020, 
>> 07:33:29) *
>> *[Clang 12.0.0 (clang-1200.0.32.28)]*
>> *weewx[1269] INFO __main__: Platform macOS-11.1-arm64-arm-64bit*
>> *weewx[1269] INFO __main__: Locale is 'en_US.UTF-8'*
>> *weewx[1269] INFO __main__: PID file is /var/run/weewx.pid*
>> *weewx[1288] INFO __main__: Using configuration file weewx.conf*
>> *weewx[1288] INFO __main__: Debug is 0*
>>
>>  
>> Still will not start from launchctl
>> get:
>>
>> Dec 21 10:58:10 Mac-mini com.apple.xpc.launchd[1] 
>> (com.weewx.weewxd[893]): Service could not initialize: 20C69: xpcproxy + 
>> 23696 [839][D05D0576-CE1E-3530-B74C-0EB266FFBFDD]: 0x2
>>
>> Dec 21 10:58:10 Mac-mini com.apple.xpc.launchd[1] 
>> (com.weewx.weewxd[893]): Service exited with abnormal code: 78
>>
>> Any ideas on how to set up launchctl start 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/c8d36687-35c4-4fc3-9c15-cdf2bfe5af26n%40googlegroups.com.

[weewx-user] Belchertown Skin Highchart Rounding Battery Values

2020-12-23 Thread Al P

I have had weewx installed for a week or so, and loving it.
I've started playing with Belchertown and like the look of it, but I've hit 
a minor problem.

I would like to chart a voltage value to 3 decimal places. Why you ask? 
Because I've recently installed a WeatherFlow Tempest in an overcast 
climate and I really want to see how much/little sunshine it takes for it 
to charge!

I have the sensor value mapped to supplyVoltage, and have created a chart 
in the Seasons skin that shows the precision I'm looking for, but when 
using the same field in the Belchertown charts it only ever shows to 2 
decimal places.
The value definitely has 3 decimal places, I have printed the current value 
to my footer.

Anyone able help me find where it does this?

Cheers,
 Alan

-- 
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/c3df9092-7a04-4d86-9211-da55b57c4484n%40googlegroups.com.

Re: [weewx-user] Re: Build of weewx on M1 Mac

2020-12-23 Thread Christopher Joseph Alemany

Ah! That makes sense! It felt like it all was coming down to different python 
versions. What a mess python has become! I will endeavour to clean it up as you 
suggest. Thanks for the pointers!

“They always tell me it takes time. How much more time do you want...for your 
progress?”
James Baldwin

Chris Alemany
3854 6th Ave
Port Alberni, BC
V9Y4M2
h:250-723-0889
w: 250-753-3245 x2106
e: chris...@gmail.com
w: www.chrisalemany.ca
w: www.alberniweather.ca
w: www.vifreightbyrail.ca

> On Dec 23, 2020, at 08:06, geoffs...@gmail.com  wrote:
> 
> Hi Chris,
> 
> I had a problem with the python install as I had the system install, the 
> python installer version and a Pyenv version. I got rid of the python 
> installer version and killed all of the symlinks in the /usr/local/ folder 
> and then installed Pyenv to install 3.9.1. I then set Pyenv global to 3.9.1 
> and was able to get python3 -V to spit out 3.9.1 and /usr/bin/env python to 
> open 3.9.1. This was the key. When I built weewx, it at first had the shebang 
> in the file pointing to the python installed by the python installer. This is 
> why if I started it from Terminal it worked fine, but using Launchctl, it was 
> looking for a python install that didn't exist. Look at the #! first line of 
> weewxd to make sure it points to an accessible python 3.9.1 location. Since I 
> had build weewx several times, I didn't realize that a script was made for 
> each build and it was just reinstalling that script each time rather than 
> looking for the updated python and making a new pointer to the updated 
> python. If you get rid of the weewx-4.2.0 folder and unzip it again, you will 
> get rid of the versions that it has already made. Hope this helps. Finally 
> got it to work as it should once the !# in all of the weewx files pointed to 
> the correct python install. It looks like weewx uses /usr/bin/env python to 
> determine what to write in the files, so if you do /usr/bin/env python in the 
> terminal it should open the 3.9.1 version of python. If not, you need to get 
> that working before running a fresh setup.py install. Hope this helps.
> 
>> On Tuesday, December 22, 2020 at 10:38:31 AM UTC-8 chri...@gmail.com wrote:
>> I have not been able to convince MacOS 11.1 to allow me to use launchctl for 
>> weewx either and I am on an Intel machine.
>> I'll keep trying on my end.  Did you have any trouble getting all the 
>> requirements for weewx included in python 3.9.1? I got stuck part way 
>> through and had to go back to 3.8.6
>> 
>> Cheers
>> Chris
>>> On Monday, December 21, 2020 at 11:48:44 AM UTC-8 geoffs...@gmail.com wrote:
>>> Setup pyenv using Homebrew M1 experimental version and then installed 
>>> python 3.9.1
>>> Then installed all necessary libraries. Needed to use homebrew to install 
>>> FreeType and libjpeg to get a working Pillow install.
>>> 
>>> can be started as a daemon using 
>>> 
>>> cd /Users/Shared/weewx
>>> python3 ./bin/weewxd weewx.conf -d
>>> Runs as native on M1 ARM64 arch
>>> weewx[1269] INFO __main__: Initializing weewx version 4.2.0
>>> weewx[1269] INFO __main__: Using Python 3.9.1 (default, Dec 21 2020, 
>>> 07:33:29) 
>>> [Clang 12.0.0 (clang-1200.0.32.28)]
>>> weewx[1269] INFO __main__: Platform macOS-11.1-arm64-arm-64bit
>>> weewx[1269] INFO __main__: Locale is 'en_US.UTF-8'
>>> weewx[1269] INFO __main__: PID file is /var/run/weewx.pid
>>> weewx[1288] INFO __main__: Using configuration file weewx.conf
>>> weewx[1288] INFO __main__: Debug is 0
>>> 
>>>  
>>> Still will not start from launchctl
>>> get:
>>> Dec 21 10:58:10 Mac-mini com.apple.xpc.launchd[1] (com.weewx.weewxd[893]): 
>>> Service could not initialize: 20C69: xpcproxy + 23696 
>>> [839][D05D0576-CE1E-3530-B74C-0EB266FFBFDD]: 0x2
>>> 
>>> Dec 21 10:58:10 Mac-mini com.apple.xpc.launchd[1] (com.weewx.weewxd[893]): 
>>> Service exited with abnormal code: 78
>>> 
>>> Any ideas on how to set up launchctl start 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/c8d36687-35c4-4fc3-9c15-cdf2bfe5af26n%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/35023C60-CC9B-4725-859A-9A95186B1C93%40gmail.com.

[weewx-user] Re: Belchertown Skin Highchart Rounding Battery Values

On Wednesday, December 23, 2020 at 8:28:11 AM UTC-8 Al P wrote:

> I would like to chart a voltage value to 3 decimal places. Why you ask? 
> Because I've recently installed a WeatherFlow Tempest in an overcast 
> climate and I really want to see how much/little sunshine it takes for it 
> to charge!
>
>
Are you 'sure' the unit reports to three decimal points ?
My recollection is WF gear only reports to two (but my memory might be 
hazy).

Remember, an archive record is an average of the data received over that 
archive period, so the average of a 2-digit actual measurement will seem to 
be a many-digit value.

But that said, if you look in skin.conf you will see a section called 
StringFormats where you can set it to any number of digits you 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/91e18e4f-1934-42cf-8195-4af74b5bce7cn%40googlegroups.com.

Re: [weewx-user] MQTT SSL Problems


Hard to say what's wrong, but use mosquitto_publish to test.   I have
the emqtt extension publishing to mqtt/tls just fine and I do not run
mqtt w/o ssl at all.

Turn on logging on th broker, and look with tcpdump.

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


signature.asc
Description: PGP signature

[weewx-user] Re: Belchertown Skin Highchart Rounding Battery Values

2020-12-23 Thread Al P

Yep, I can see 3 digits in the UDP packets, and as I mentioned I can see 
the 3 digits in the chart in the seasons skin. I've also added the current 
value to my footer and can see the 3 digits there. It's only in the chart 
that it seems to round to 2 digits. The stringformat is already %.3f for 
the rest of it to work.

On Wednesday, 23 December 2020 at 19:51:13 UTC vince wrote:

> On Wednesday, December 23, 2020 at 8:28:11 AM UTC-8 Al P wrote:
>
>> I would like to chart a voltage value to 3 decimal places. Why you ask? 
>> Because I've recently installed a WeatherFlow Tempest in an overcast 
>> climate and I really want to see how much/little sunshine it takes for it 
>> to charge!
>>
>>
> Are you 'sure' the unit reports to three decimal points ?
> My recollection is WF gear only reports to two (but my memory might be 
> hazy).
>
> Remember, an archive record is an average of the data received over that 
> archive period, so the average of a 2-digit actual measurement will seem to 
> be a many-digit value.
>
> But that said, if you look in skin.conf you will see a section called 
> StringFormats where you can set it to any number of digits you 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/94dc8486-03e4-497f-8083-7547f5d32ff8n%40googlegroups.com.

[weewx-user] updating missing data fields in the weewx database - can I use wee_import ?

2020-12-23 Thread Rainer Lang

Hi,

I'm about to close gaps in my data history (due to system downtime and
also historical data from my pre-weewx times).
Adding missing records is nicely described and looks rather simple and
straightforward.

However, I don't know how to handle the update of already existing records.
E.g. due to missing information my radiation data in the DB are missing
while all other sensor data are already stored.

Can I use wee_import the same way I do for importing new records ?

If so, what data do I have to provide ? Only the content of the
to-be-updated fields or the whole record (i.e. values for all fields).

Or, does it not work with wee_import and I have to do it differently ?
If so, how ?

Another question indirectly related to the import of history data.

How do I display earlier years (in day, week, month, year aggregation
like in the current year ?) beyond the scarce reports to be chosen in
the "upper right corner" ?

Will I have to create a sort of history skin where I can select date,
week, month, year and based on this selection the picture generator will
provide the graphics ?

Or does some such"piece" already exist (fully, partially, ...) ?

Please advise.

Thanks
Rainer

--
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/974a328a-d3e2-ee1c-c216-b90f0cc6653e%40gmail.com.

Re: [weewx-user] MQTT SSL Problems

Thank you Greg,
so I have tried:
pi@WeeWX:~ $ mosquitto_pub -h localhost -p 8883 -t "weather/test" -m "hello 
world. this is to the weather topic with authentication" -u "pi" -P 
"" -d
Client mosqpub|24614-WeeWX sending CONNECT
Error: The connection was lost.

with port 1883 it works:

pi@WeeWX:~ $ mosquitto_pub -h localhost -p 1883 -t "weather/test" -m "hello 
world. this is to the weather topic with authentication" -u "pi" -P " 
 " -d
Client mosqpub|24645-WeeWX sending CONNECT
Client mosqpub|24645-WeeWX received CONNACK (0)
Client mosqpub|24645-WeeWX sending PUBLISH (d0, q0, r0, m1, 'weather/test', 
... (61 bytes))
Client mosqpub|24645-WeeWX sending DISCONNECT

mosquitto_sub is like:
pi@WeeWX:~ $ mosquitto_sub -h localhost -p 8883 -t weather/# -d
Client mosqsub|24569-WeeWX sending CONNECT
Client mosqsub|24569-WeeWX sending CONNECT

again, with port 1883 it works:
pi@WeeWX:~ $ mosquitto_sub -h localhost -p 1883 -t weather/# -d
Client mosqsub|24659-WeeWX sending CONNECT
Client mosqsub|24659-WeeWX received CONNACK (0)
Client mosqsub|24659-WeeWX sending SUBSCRIBE (Mid: 1, Topic: weather/#, 
QoS: 0)
Client mosqsub|24659-WeeWX received SUBACK
Subscribed (mid: 1): 0

I have installed tcpdump, which parameters am I looking for?

Thanks,
Michal

Dátum: streda 23. decembra 2020, čas: 20:55:28 UTC+1, odosielateľ: Greg 
Troxel

>
> Hard to say what's wrong, but use mosquitto_publish to test. I have
> the emqtt extension publishing to mqtt/tls just fine and I do not run
> mqtt w/o ssl at all.
>
> Turn on logging on th broker, and look with tcpdump.
>

-- 
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/862a3a2c-b345-48b4-b13c-839f503f124bn%40googlegroups.com.

Re: [weewx-user] MQTT SSL Problems

2020-12-23 Thread mh081...@gmail.com

Hi,

have you set tlsv12 in weewx.conf under [[MQTT]] Section?

Like 



misk...@gmail.com schrieb am Mittwoch, 23. Dezember 2020 um 22:36:27 UTC+1:

> Thank you Greg,
> so I have tried:
> pi@WeeWX:~ $ mosquitto_pub -h localhost -p 8883 -t "weather/test" -m 
> "hello world. this is to the weather topic with authentication" -u "pi" -P 
> "" -d
> Client mosqpub|24614-WeeWX sending CONNECT
> Error: The connection was lost.
>
> with port 1883 it works:
>
> pi@WeeWX:~ $ mosquitto_pub -h localhost -p 1883 -t "weather/test" -m 
> "hello world. this is to the weather topic with authentication" -u "pi" -P 
> "  " -d
> Client mosqpub|24645-WeeWX sending CONNECT
> Client mosqpub|24645-WeeWX received CONNACK (0)
> Client mosqpub|24645-WeeWX sending PUBLISH (d0, q0, r0, m1, 
> 'weather/test', ... (61 bytes))
> Client mosqpub|24645-WeeWX sending DISCONNECT
>
> mosquitto_sub is like:
> pi@WeeWX:~ $ mosquitto_sub -h localhost -p 8883 -t weather/# -d
> Client mosqsub|24569-WeeWX sending CONNECT
> Client mosqsub|24569-WeeWX sending CONNECT
>
> again, with port 1883 it works:
> pi@WeeWX:~ $ mosquitto_sub -h localhost -p 1883 -t weather/# -d
> Client mosqsub|24659-WeeWX sending CONNECT
> Client mosqsub|24659-WeeWX received CONNACK (0)
> Client mosqsub|24659-WeeWX sending SUBSCRIBE (Mid: 1, Topic: weather/#, 
> QoS: 0)
> Client mosqsub|24659-WeeWX received SUBACK
> Subscribed (mid: 1): 0
>
> I have installed tcpdump, which parameters am I looking for?
>
> Thanks,
> Michal
>
> Dátum: streda 23. decembra 2020, čas: 20:55:28 UTC+1, odosielateľ: Greg 
> Troxel
>
>>
>> Hard to say what's wrong, but use mosquitto_publish to test. I have 
>> the emqtt extension publishing to mqtt/tls just fine and I do not run 
>> mqtt w/o ssl at all. 
>>
>> Turn on logging on th broker, and look with tcpdump. 
>>
>

-- 
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/5760431e-1448-414c-a217-d6c8b92e74e2n%40googlegroups.com.

Re: [weewx-user] MQTT SSL Problems

2020-12-23 Thread mh081...@gmail.com

I mean


[[MQTT]]
server_url = mqtt://pi:password@url:8883/
topic = weather
unit_system = METRIC
binding = archive, loop
aggregation = aggregate
log_success = False
log_failure = True
[[[tls]]]
tls_version = tlsv12
ca_certs = /etc/ssl/certs/ca-certificates.crt
[[[inputs]]]
dayRain
name = dayRain_mm
units = mm
rainRate
name = rainRate_mm_per_hour
units = mm_per_hour


mh081...@gmail.com schrieb am Mittwoch, 23. Dezember 2020 um 22:44:59 UTC+1:

> Hi,
>
> have you set tlsv12 in weewx.conf under [[MQTT]] Section?
>
> Like 
>
>
>
> misk...@gmail.com schrieb am Mittwoch, 23. Dezember 2020 um 22:36:27 
> UTC+1:
>
>> Thank you Greg,
>> so I have tried:
>> pi@WeeWX:~ $ mosquitto_pub -h localhost -p 8883 -t "weather/test" -m 
>> "hello world. this is to the weather topic with authentication" -u "pi" -P 
>> "" -d
>> Client mosqpub|24614-WeeWX sending CONNECT
>> Error: The connection was lost.
>>
>> with port 1883 it works:
>>
>> pi@WeeWX:~ $ mosquitto_pub -h localhost -p 1883 -t "weather/test" -m 
>> "hello world. this is to the weather topic with authentication" -u "pi" -P 
>> "  " -d
>> Client mosqpub|24645-WeeWX sending CONNECT
>> Client mosqpub|24645-WeeWX received CONNACK (0)
>> Client mosqpub|24645-WeeWX sending PUBLISH (d0, q0, r0, m1, 
>> 'weather/test', ... (61 bytes))
>> Client mosqpub|24645-WeeWX sending DISCONNECT
>>
>> mosquitto_sub is like:
>> pi@WeeWX:~ $ mosquitto_sub -h localhost -p 8883 -t weather/# -d
>> Client mosqsub|24569-WeeWX sending CONNECT
>> Client mosqsub|24569-WeeWX sending CONNECT
>>
>> again, with port 1883 it works:
>> pi@WeeWX:~ $ mosquitto_sub -h localhost -p 1883 -t weather/# -d
>> Client mosqsub|24659-WeeWX sending CONNECT
>> Client mosqsub|24659-WeeWX received CONNACK (0)
>> Client mosqsub|24659-WeeWX sending SUBSCRIBE (Mid: 1, Topic: weather/#, 
>> QoS: 0)
>> Client mosqsub|24659-WeeWX received SUBACK
>> Subscribed (mid: 1): 0
>>
>> I have installed tcpdump, which parameters am I looking for?
>>
>> Thanks,
>> Michal
>>
>> Dátum: streda 23. decembra 2020, čas: 20:55:28 UTC+1, odosielateľ: Greg 
>> Troxel
>>
>>>
>>> Hard to say what's wrong, but use mosquitto_publish to test. I have 
>>> the emqtt extension publishing to mqtt/tls just fine and I do not run 
>>> mqtt w/o ssl at all. 
>>>
>>> Turn on logging on th broker, and look with tcpdump. 
>>>
>>

-- 
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/1a9c2be5-be0e-4ad1-9443-6b08c6132544n%40googlegroups.com.

Re: [weewx-user] MQTT SSL Problems

Wow!
that *tlsv12* has really helped! now tail -f is showing no errors.
just to be sure -  server_url = mqtt://pi:password@url:8883/ 
URL can be localhost, or should I use my https:// webpage 
"jastrabie.online"? 

My Belchertown settings still does not work:
# MQTT Websockets defaults
mqtt_websockets_enabled = 1
mqtt_websockets_host = "jastrabie.online"
mqtt_websockets_port = 9001
mqtt_websockets_ssl = 1
mqtt_websockets_topic = "weather/loop"
disconnect_live_website_visitor = 180

webpage debugger shows this:
WebSocket connection to 'wss://jastrabie.online:9001/mqtt' failed: 
Connection closed before receiving a handshake response
d._doConnect @ paho-mqtt.min.js:37
d.connect @ paho-mqtt.min.js:31
Client.connect @ paho-mqtt.min.js:70
connect @ belchertown.js?1608760733:1308
(anonymous) @ (index):156
l @ jquery.min.js:2
c @ jquery.min.js:2

Thank you!
Michal

Dátum: streda 23. decembra 2020, čas: 22:47:56 UTC+1, odosielateľ: 
mh081...@gmail.com

> I mean
>
>
> [[MQTT]]
> server_url = mqtt://pi:password@url:8883/
> topic = weather
> unit_system = METRIC
> binding = archive, loop
> aggregation = aggregate
> log_success = False
> log_failure = True
> [[[tls]]]
> tls_version = tlsv12
> ca_certs = /etc/ssl/certs/ca-certificates.crt
> [[[inputs]]]
> dayRain
> name = dayRain_mm
> units = mm
> rainRate
> name = rainRate_mm_per_hour
> units = mm_per_hour
>
>
> mh081...@gmail.com schrieb am Mittwoch, 23. Dezember 2020 um 22:44:59 
> UTC+1:
>
>> Hi,
>>
>> have you set tlsv12 in weewx.conf under [[MQTT]] Section?
>>
>> Like 
>>
>>
>>
>> misk...@gmail.com schrieb am Mittwoch, 23. Dezember 2020 um 22:36:27 
>> UTC+1:
>>
>>> Thank you Greg,
>>> so I have tried:
>>> pi@WeeWX:~ $ mosquitto_pub -h localhost -p 8883 -t "weather/test" -m 
>>> "hello world. this is to the weather topic with authentication" -u "pi" -P 
>>> "" -d
>>> Client mosqpub|24614-WeeWX sending CONNECT
>>> Error: The connection was lost.
>>>
>>> with port 1883 it works:
>>>
>>> pi@WeeWX:~ $ mosquitto_pub -h localhost -p 1883 -t "weather/test" -m 
>>> "hello world. this is to the weather topic with authentication" -u "pi" -P 
>>> "  " -d
>>> Client mosqpub|24645-WeeWX sending CONNECT
>>> Client mosqpub|24645-WeeWX received CONNACK (0)
>>> Client mosqpub|24645-WeeWX sending PUBLISH (d0, q0, r0, m1, 
>>> 'weather/test', ... (61 bytes))
>>> Client mosqpub|24645-WeeWX sending DISCONNECT
>>>
>>> mosquitto_sub is like:
>>> pi@WeeWX:~ $ mosquitto_sub -h localhost -p 8883 -t weather/# -d
>>> Client mosqsub|24569-WeeWX sending CONNECT
>>> Client mosqsub|24569-WeeWX sending CONNECT
>>>
>>> again, with port 1883 it works:
>>> pi@WeeWX:~ $ mosquitto_sub -h localhost -p 1883 -t weather/# -d
>>> Client mosqsub|24659-WeeWX sending CONNECT
>>> Client mosqsub|24659-WeeWX received CONNACK (0)
>>> Client mosqsub|24659-WeeWX sending SUBSCRIBE (Mid: 1, Topic: weather/#, 
>>> QoS: 0)
>>> Client mosqsub|24659-WeeWX received SUBACK
>>> Subscribed (mid: 1): 0
>>>
>>> I have installed tcpdump, which parameters am I looking for?
>>>
>>> Thanks,
>>> Michal
>>>
>>> Dátum: streda 23. decembra 2020, čas: 20:55:28 UTC+1, odosielateľ: Greg 
>>> Troxel
>>>

 Hard to say what's wrong, but use mosquitto_publish to test. I have 
 the emqtt extension publishing to mqtt/tls just fine and I do not run 
 mqtt w/o ssl at all. 

 Turn on logging on th broker, and look with tcpdump. 

>>>

-- 
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/31a79675-a503-4997-9abf-b8611b869763n%40googlegroups.com.

[weewx-user] extension installer sleight of hand question

One of the things that we see FAQs about for many extensions, in particular
the combination of weewx-mqtt and Belchertown, is related to what to
edit+add in weewx.conf to salt to taste, so to speak.

I was thinking it might be helpful to be able to insert relatively large
commented-out blocks of config file into a section, to aid folks in knowing
what to tweak to do frequently desired things, and to do this as part of an
extension being installed.

For example, using the weewx-mqtt extension as an example...

By default it adds:
[[MQTT]]
server_url = INSERT_SERVER_URL_HERE

But to do MQTT for Belchertown realtime stats you need to (a) edit the
server_url line and (b) add a few more lines so the result is:

[[MQTT]]
server_url = mqtt://192.168.1.123:1883
topic = weather
binding = archive, loop
aggregation = aggregate
log_success = false

Is it possible to easily extend install.py to insert a block of additional
lines, commented out, into the right place(s) as part of installing the
extension ? I was thinking that some better enhanced 'uncomment this to
do that' stuff for a lot of extensions might make it easier for folks to
figure out.

I know it's easy to hack on the install.py to add 'uncommented' things.
I'm looking to have it also be able to insert comments into that area.
Even being able to read in an external file'o'comments might be good
enough if that's possible as an alternative.

[[MQTT]]
server_url = mqtt://192.168.1.123:1883
#--- uncomment the lines below if you use MQTT with Belchertown
#--- and make sure your Belchertown skin references weather/loop
#--- as the MQTT topic
#
# topic = weather
# binding = archive, loop
# aggregation = aggregate
# log_success = false

Yes I know it's also possible to expect people to RTFM but sometimes TFM
get a bit cryptic. I was thinking some inline 'comment this out to do
that' things would be helpful if the extension installer had a way to do
that.

Ideas ?

Re: [weewx-user] MQTT SSL Problems

I have proofed, that
pi@WeeWX:~ $ mosquitto_sub -h jastrabie.online -p 8883 -t weather/# -d 
--tls-version tlsv1.2 --cafile /etc/ssl/certs/ca-certificates.crt
works!
so now only setup the belchertown correctly?

Dátum: streda 23. decembra 2020, čas: 23:05:28 UTC+1, odosielateľ: miso k

> Wow!
> that *tlsv12* has really helped! now tail -f is showing no errors.
> just to be sure -  server_url = mqtt://pi:password@url:8883/ 
> URL can be localhost, or should I use my https:// webpage 
> "jastrabie.online"? 
>
> My Belchertown settings still does not work:
> # MQTT Websockets defaults
> mqtt_websockets_enabled = 1
> mqtt_websockets_host = "jastrabie.online"
> mqtt_websockets_port = 9001
> mqtt_websockets_ssl = 1
> mqtt_websockets_topic = "weather/loop"
> disconnect_live_website_visitor = 180
>
> webpage debugger shows this:
> WebSocket connection to 'wss://jastrabie.online:9001/mqtt' failed: 
> Connection closed before receiving a handshake response
> d._doConnect @ paho-mqtt.min.js:37
> d.connect @ paho-mqtt.min.js:31
> Client.connect @ paho-mqtt.min.js:70
> connect @ belchertown.js?1608760733:1308
> (anonymous) @ (index):156
> l @ jquery.min.js:2
> c @ jquery.min.js:2
>
> Thank you!
> Michal
>
> Dátum: streda 23. decembra 2020, čas: 22:47:56 UTC+1, odosielateľ: 
> mh081...@gmail.com
>
>> I mean
>>
>>
>> [[MQTT]]
>> server_url = mqtt://pi:password@url:8883/
>> topic = weather
>> unit_system = METRIC
>> binding = archive, loop
>> aggregation = aggregate
>> log_success = False
>> log_failure = True
>> [[[tls]]]
>> tls_version = tlsv12
>> ca_certs = /etc/ssl/certs/ca-certificates.crt
>> [[[inputs]]]
>> dayRain
>> name = dayRain_mm
>> units = mm
>> rainRate
>> name = rainRate_mm_per_hour
>> units = mm_per_hour
>>
>>
>> mh081...@gmail.com schrieb am Mittwoch, 23. Dezember 2020 um 22:44:59 
>> UTC+1:
>>
>>> Hi,
>>>
>>> have you set tlsv12 in weewx.conf under [[MQTT]] Section?
>>>
>>> Like 
>>>
>>>
>>>
>>> misk...@gmail.com schrieb am Mittwoch, 23. Dezember 2020 um 22:36:27 
>>> UTC+1:
>>>
 Thank you Greg,
 so I have tried:
 pi@WeeWX:~ $ mosquitto_pub -h localhost -p 8883 -t "weather/test" -m 
 "hello world. this is to the weather topic with authentication" -u "pi" -P 
 "" -d
 Client mosqpub|24614-WeeWX sending CONNECT
 Error: The connection was lost.

 with port 1883 it works:

 pi@WeeWX:~ $ mosquitto_pub -h localhost -p 1883 -t "weather/test" -m 
 "hello world. this is to the weather topic with authentication" -u "pi" -P 
 "  " -d
 Client mosqpub|24645-WeeWX sending CONNECT
 Client mosqpub|24645-WeeWX received CONNACK (0)
 Client mosqpub|24645-WeeWX sending PUBLISH (d0, q0, r0, m1, 
 'weather/test', ... (61 bytes))
 Client mosqpub|24645-WeeWX sending DISCONNECT

 mosquitto_sub is like:
 pi@WeeWX:~ $ mosquitto_sub -h localhost -p 8883 -t weather/# -d
 Client mosqsub|24569-WeeWX sending CONNECT
 Client mosqsub|24569-WeeWX sending CONNECT

 again, with port 1883 it works:
 pi@WeeWX:~ $ mosquitto_sub -h localhost -p 1883 -t weather/# -d
 Client mosqsub|24659-WeeWX sending CONNECT
 Client mosqsub|24659-WeeWX received CONNACK (0)
 Client mosqsub|24659-WeeWX sending SUBSCRIBE (Mid: 1, Topic: weather/#, 
 QoS: 0)
 Client mosqsub|24659-WeeWX received SUBACK
 Subscribed (mid: 1): 0

 I have installed tcpdump, which parameters am I looking for?

 Thanks,
 Michal

 Dátum: streda 23. decembra 2020, čas: 20:55:28 UTC+1, odosielateľ: Greg 
 Troxel

>
> Hard to say what's wrong, but use mosquitto_publish to test. I have 
> the emqtt extension publishing to mqtt/tls just fine and I do not run 
> mqtt w/o ssl at all. 
>
> Turn on logging on th broker, and look with tcpdump. 
>


-- 
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/8d70924c-03e3-40da-9c7b-6dfea6d02644n%40googlegroups.com.

Re: [weewx-user] MQTT SSL Problems

On Wednesday, December 23, 2020 at 2:05:28 PM UTC-8 misk...@gmail.com wrote:

> just to be sure -  server_url = mqtt://pi:password@url:8883/ 
> URL can be localhost, or should I use my https:// webpage 
> "jastrabie.online"? 
>

Never localhost

Always use the MQTT broker's ip address or hostname or ideally FQDN

In your example, 'jastrable.online' hopefully is a fully qualified domain 
name, but I've never heard of that domain and it doesn't resolve for me 
here.I'd suggest initially using your MQTT broker system's ip address 
there for initial testing to know that the broker config works.  Then move 
later to putting in the fully qualified domain name that ip resolves to as 
step 2.

-- 
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/2deddf4e-50d1-41f8-b47d-134e5246ec11n%40googlegroups.com.

Re: [weewx-user] extension installer sleight of hand question

I guess I'm not understanding this. If you create a config section for the
installer, it will be faithfully reproduced as it gets injected into
weewx.conf, including any comments.

As an example, take a look at install.py
 for
weewx-nmea-xdr .

Or, am I missing something?

-tk

On Wed, Dec 23, 2020 at 2:20 PM vince  wrote:

> One of the things that we see FAQs about for many extensions, in
> particular the combination of weewx-mqtt and Belchertown, is related to
> what to edit+add in weewx.conf to salt to taste, so to speak.
>
> I was thinking it might be helpful to be able to insert relatively large
> commented-out blocks of config file into a section, to aid folks in knowing
> what to tweak to do frequently desired things, and to do this as part of an
> extension being installed.
>
> For example, using the weewx-mqtt extension as an example...
>
> By default it adds:
> [[MQTT]]
> server_url = INSERT_SERVER_URL_HERE
>
> But to do MQTT for Belchertown realtime stats you need to (a) edit the
> server_url line and (b) add a few more lines so the result is:
>
> [[MQTT]]
> server_url = mqtt://192.168.1.123:1883
> topic = weather
> binding = archive, loop
> aggregation = aggregate
> log_success = false
>
> Is it possible to easily extend install.py to insert a block of additional
> lines, commented out, into the right place(s) as part of installing the
> extension ?   I was thinking that some better enhanced 'uncomment this to
> do that' stuff for a lot of extensions might make it easier for folks to
> figure out.
>
> I know it's easy to hack on the install.py to add 'uncommented' things.
> I'm looking to have it also be able to insert comments into that area.
> Even being able to read in an external file'o'comments might be good enough
> if that's possible as an alternative.
>
> [[MQTT]]
> server_url = mqtt://192.168.1.123:1883
> #--- uncomment the lines below if you use MQTT with Belchertown
> #--- and make sure your Belchertown skin references weather/loop
> #--- as the MQTT topic
> #
> #  topic = weather
> # binding = archive, loop
> # aggregation = aggregate
> # log_success = false
>
> Yes I know it's also possible to expect people to RTFM but sometimes TFM
> get a bit cryptic.   I was thinking some inline 'comment this out to do
> that' things would be helpful if the extension installer had a way to do
> that.
>
> Ideas ?
>
> --
> 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/e8243a7f-d32e-4555-93d7-37c58e72ce2dn%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/CAPq0zEBaT5QmqppjkzCiDj8ZEtM-VMN77BauEGQWhgEbUs9tuQ%40mail.gmail.com.

Re: [weewx-user] MQTT SSL Problems


it is FQDN -  jastrabie.online - look at the letter behind B
so i let the host as it is. 
is my port correct -9001?
SSL should be 1 as "On", or should be the TLS protocol version - 1.2, or 
even 12?

# MQTT Websockets defaults
mqtt_websockets_enabled = 1
mqtt_websockets_host = "jastrabie.online"
mqtt_websockets_port = 9001
mqtt_websockets_ssl = 1
mqtt_websockets_topic = "weather/loop"
disconnect_live_website_visitor = 180


Dátum: streda 23. decembra 2020, čas: 23:27:40 UTC+1, odosielateľ: vince

> On Wednesday, December 23, 2020 at 2:05:28 PM UTC-8 misk...@gmail.com 
> wrote:
>
>> just to be sure -  server_url = mqtt://pi:password@url:8883/ 
>> URL can be localhost, or should I use my https:// webpage 
>> "jastrabie.online"? 
>>
>
> Never localhost
>
> Always use the MQTT broker's ip address or hostname or ideally FQDN
>
> In your example, 'jastrable.online' hopefully is a fully qualified domain 
> name, but I've never heard of that domain and it doesn't resolve for me 
> here.I'd suggest initially using your MQTT broker system's ip address 
> there for initial testing to know that the broker config works.  Then move 
> later to putting in the fully qualified domain name that ip resolves to as 
> step 2.
>
>
>  
>

-- 
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/6e2042d8-6d34-4f82-81f9-2fd499d0ee14n%40googlegroups.com.

Re: [weewx-user] MQTT SSL Problems

maybe i am using different certificates for both - MQTT pub:

[[[tls]]]
tls_version = tlsv12
ca_certs = /etc/ssl/certs/ca-certificates.crt

and what is defined in /etc/mosquitto/conf.d/myconfig.conf 

...
# Insecure mqtt to localhost only, and secure mqtt
listener 1883 localhost
listener 8883
certfile /etc/letsencrypt/live/jastrabie.online/cert.pem
cafile /etc/letsencrypt/live/jastrabie.online/chain.pem
keyfile /etc/letsencrypt/live/jastrabie.online/privkey.pem
protocol mqtt

# websockets
listener 9001
certfile /etc/letsencrypt/live/jastrabie.online/cert.pem
cafile /etc/letsencrypt/live/jastrabie.online/chain.pem
keyfile /etc/letsencrypt/live/jastrabie.online/privkey.pem
protocol websockets

am I right/wrong?
Miso


Dátum: streda 23. decembra 2020, čas: 23:49:18 UTC+1, odosielateľ: miso k

>
> it is FQDN -  jastrabie.online - look at the letter behind B
> so i let the host as it is. 
> is my port correct -9001?
> SSL should be 1 as "On", or should be the TLS protocol version - 1.2, or 
> even 12?
>
>
> # MQTT Websockets defaults
> mqtt_websockets_enabled = 1
> mqtt_websockets_host = "jastrabie.online"
> mqtt_websockets_port = 9001
> mqtt_websockets_ssl = 1
> mqtt_websockets_topic = "weather/loop"
> disconnect_live_website_visitor = 180
>
>
> Dátum: streda 23. decembra 2020, čas: 23:27:40 UTC+1, odosielateľ: vince
>
>> On Wednesday, December 23, 2020 at 2:05:28 PM UTC-8 misk...@gmail.com 
>> wrote:
>>
>>> just to be sure -  server_url = mqtt://pi:password@url:8883/ 
>>> URL can be localhost, or should I use my https:// webpage 
>>> "jastrabie.online"? 
>>>
>>
>> Never localhost
>>
>> Always use the MQTT broker's ip address or hostname or ideally FQDN
>>
>> In your example, 'jastrable.online' hopefully is a fully qualified domain 
>> name, but I've never heard of that domain and it doesn't resolve for me 
>> here.I'd suggest initially using your MQTT broker system's ip address 
>> there for initial testing to know that the broker config works.  Then move 
>> later to putting in the fully qualified domain name that ip resolves to as 
>> step 2.
>>
>>
>>  
>>
>

-- 
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/e0ee582b-db53-425b-95b3-545a092b7f37n%40googlegroups.com.

Re: [weewx-user] extension installer sleight of hand question

On Wednesday, December 23, 2020 at 2:48:37 PM UTC-8 Tom Keffer wrote:

> I guess I'm not understanding this. If you create a config section for the 
> installer, it will be faithfully reproduced as it gets injected into 
> weewx.conf, including any comments. 
>
> As an example, take a look at install.py 
>  for 
> weewx-nmea-xdr .
>
>
Perfect.
Exactly what I was hoping to do.

Neither Belchertown (here 
) nor 
weewx-mqtt (here 
) do it 
that way.
Your way is way slicker.
 

> Or, am I missing something?
>
>
Not in the least.

Thanks a bunch !

-- 
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/7abfafed-bdbe-42a3-a41d-22e5ffcfffddn%40googlegroups.com.

Re: [weewx-user] Cydia pomonella

2020-12-23 Thread Chuck Rhode

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 23 Dec 2020 07:34:40 -0800 (PST)
Andy  wrote:

> I will be glad to test this when you get it going.

Actually, as of yesterday, it *is* going.  I have a Cheetah template
that prints reports for selected insect-development models.  I just
haven't packaged it as a WeeWX extension, yet.  I'm working on
cumulative growing degree day graphs.  I expect this part of the
effort to extend through Ground Hog Day before I can turn to package
details.  The Good Lord willin' and the creek don't rise, the
extension should be ready for the next growing season.

- -- 
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather:  http://LacusVeris.com/WX
.. 44° — Wind SW 26 mph — Sky mostly clear.

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCX+PjrgAKCRBg2/xipKOW
UmS0AJ4veo/htou5GfY3tjNywOtng91caACdGzkX+K2de8+EXVEh3xD0YCEOagM=
=E2Eq
-END PGP SIGNATURE-

-- 
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/20201223184117.69d4e375%40wealthy.

Re: [weewx-user] extension installer sleight of hand question

Now that I look at the actual code, my approach doesn't always work!  It
will not preserve comments at the root level. For example:

# This is a comment
[SectionA]
  # Comment on option1
  option1 = foo
  option2 = bar  # Inline comment about option2

The highlighted comment would not get preserved. The others would.

Fixed in commit 98eef9b



On Wed, Dec 23, 2020 at 4:04 PM vince  wrote:

> On Wednesday, December 23, 2020 at 2:48:37 PM UTC-8 Tom Keffer wrote:
>
>> I guess I'm not understanding this. If you create a config section for
>> the installer, it will be faithfully reproduced as it gets injected into
>> weewx.conf, including any comments.
>>
>> As an example, take a look at install.py
>>  for
>> weewx-nmea-xdr .
>>
>>
> Perfect.
> Exactly what I was hoping to do.
>
> Neither Belchertown (here
> )
> nor weewx-mqtt (here
> ) do it
> that way.
> Your way is way slicker.
>
>
>> Or, am I missing something?
>>
>>
> Not in the least.
>
> Thanks a bunch !
>
> --
> 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/7abfafed-bdbe-42a3-a41d-22e5ffcfffddn%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/CAPq0zECxPuLRLfURYynuwgyasPCD1vDf%3DaCG2fg8vfqmF59AVw%40mail.gmail.com.

[weewx-user] new google groups - ugh

Am I the only person who has lost their 'reply to author' pick in the new 
not-improved google groups ?   The top-post default is also beyond annoying.

Does anybody have an alternate way to get the group that works in a browser 
or a Mac client ?I'd prefer to not have to enable getting a zillion 
emails, the old groups interface was far more effective.

(Tom/Matthew - have you thought about the Github 'Discussions' feature as a 
possibility for possibly moving from Google Groups at some day down the 
road ?)

-- 
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/055ebc85-ec2c-4a19-a269-080bafb8eec8n%40googlegroups.com.

Re: [weewx-user] new google groups - ugh

Thought about it, but decided to stay put. Personally, I like the email
interface. Makes searching and integration with my development tools much
easier.

On Wed, Dec 23, 2020 at 5:25 PM vince  wrote:

> Am I the only person who has lost their 'reply to author' pick in the new
> not-improved google groups ?   The top-post default is also beyond annoying.
>
> Does anybody have an alternate way to get the group that works in a
> browser or a Mac client ?I'd prefer to not have to enable getting a
> zillion emails, the old groups interface was far more effective.
>
> (Tom/Matthew - have you thought about the Github 'Discussions' feature as
> a possibility for possibly moving from Google Groups at some day down the
> road ?)
>
> --
> 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/055ebc85-ec2c-4a19-a269-080bafb8eec8n%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/CAPq0zECshCYZh3vR05LMNfszm5bOoqNhf2w-nVaNxHLN%2Bk5Sdw%40mail.gmail.com.

Re: [weewx-user] new google groups - ugh