[weewx-user] Success! How-to: Moving from one machine to another with v5 pip and rsync

[Chris Alemany]

Hi all.

I take up plenty of bandwidth with questions and things so I thought I’d share 
a success in case it helps others.
Last night I upgraded an old iMac and installed Debian 11 on it.
Today I moved my newly installed v5b10 pip venv over using rsync from a RPi 
(Debian) onto the iMac with just a few commands so I thought I’d share:

— All operations are on the destination (iMac) unless specified —

1) create a new user with same name and home path as old (eg. /home/weewx)

2) login to the new user and follow the v5 pip install method but *only* this 
steps. (I only tested this on Debian)
i) sudo apt update
ii) sudo apt install python3-pip -y
iii) sudo apt install python3-venv -y
iv) python3 -m venv ~/weewx-venv
v) source ~/weewx-venv/bin/activate
vi) python3 -m pip install weewx (see note* below)
vii) sudo cp ~/weewx-data/util/systemd/weewx.service /etc/systemd/system

note*: It is crucial to install weewx on the source in case there are subtle 
difference in the underlying systems. I ran up against this when weewx reported 
after rsync-ing that ephem was not installed when the system reported it was.

3) Use rsync to bring over only the files that have not been recreated on the 
new system. I transferred the entire user directory since it had other things I 
used and stored in support of weewx.
rsync -avz --ignore-existing we...@the.ip.address.here:/home/weewx/ 
/home/weewx/

4) If you have a remote server setup for web display, now is the time to make 
sure your passwordless ssh keys are in order from new weewx server to the 
remote server.

5) In a different terminal window, login to the *Old System* and Stop weewx

6) *On the Destination System* : Finalize the startup items and Start weewx
i) sudo systemctl daemon-reload
ii) sudo systemctl enable weewx
iii) sudo systemctl start weewx

You’re done.

As far as I’m concerned, this is a huge step up in terms of portability and 
ease of use for weewx. Congrats to all who are making v5 happen. Great work and 
thank you.

Chris

https://alberniweather.ca
https://mstdn.ca/@alberniweather.ca



-- 
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/E0555D5A-6311-4B5B-9F84-B781DF9F2B80%40gmail.com.

Re: [weewx-user] Re: formatting issue in cheetah

[vince]

Doh - delete that last < in the line above before the body of course...

On Friday, August 25, 2023 at 8:04:46 PM UTC-7 vince wrote:

> Did not help.  Is it possible there is something in the nginx 
> configuration 'or' the combination of python3/cheetah in the venv that 
> might be at fault ?   I'm running a v5 beta pip install FWIW.
>
> Here's the simplest example I can cook up.
> Simply try to show the units for something in group_concentration
>
> #errorCatcher Echo
>
> 
> 
>test page 
>   
>   
>   
>   This should look ok ==> $unit.label.pm2_5_cf_1<
>
> 
>
>
>
> On Friday, August 25, 2023 at 6:47:54 PM UTC-7 Tom Keffer wrote:
>
>> Your little test page is still being interpreted by Chrome as being 
>> encoded in "windows-1252". Try including a meta tag for the encoding:
>>
>> 
>> 
>>  test page 
>> 
>> 
>> 
>>
>> On Fri, Aug 25, 2023 at 6:08 PM vince  wrote:
>>
>>> No joy.
>>>
>>> Try "test.html" now for a far simpler variant.
>>> It'll take a few minutes for the rsync to update the public version.
>>>
>>> Here's the page source.
>>>
>>> 
>>>   
>>>test page 
>>>   
>>>
>>>   
>>>   
>>> 
>>>   
>>> AQI (current)
>>> 80.5
>>>   
>>>   
>>> AQI (last hour)
>>> 72.25
>>>   
>>>   
>>> AQI (last day)
>>> 76.80139372822299
>>>   
>>>   
>>> pm2_5_cf_1
>>> 25.960 
>>>  µg/m³
>>>   
>>> 
>>>   
>>>
>>> 
>>>
>>>
>>> On Friday, August 25, 2023 at 5:32:28 PM UTC-7 Tom Keffer wrote:
>>>
 The problem is the 'xmlns' declaration in your  tag. It is 
 causing metadata to be pulled in, which says that the character set is 
 "windows-1252".

 Change this



 *http://www.w3.org/1999/xhtml 
 ">  >>> profile="http://www.w3.org/2005/10/profile 
 ">*

 to this

 **
 *  *

 and I think your troubles will go away.

 -tk

 On Fri, Aug 25, 2023 at 4:29 PM Greg from Oz  wrote:

> I am in Australia and https://www.skahan.net/weewx/purpleair.html 
> works. So the Australian geo block is working OK.
> [image: Screenshot from 2023-08-26 09-25-36.png]
>
> On Saturday, 26 August 2023 at 09:10:00 UTC+10 Tom Keffer wrote:
>
>> Both the template and the skin configuration look fine.
>>
>> Despite being just down the road from you, I am unable to connect to 
>> your webserver.
>>
>>
>>
>> On Thu, Aug 24, 2023 at 5:15 PM vince  wrote:
>>
>>> URL that rsync uploads to is 
>>> https://www.skahan.net/weewx/purpleair.html - this will not be 
>>> available unless you're in US/CA/AU probably due to some geoip blocking 
>>> that I have set up on the ISP side to try to limit how many bots bang 
>>> on 
>>> the site.
>>>
>>> Same thing happens on chrome on mac os and iphone as well as Safari 
>>> on mac os.   The weewx host is a current RaspiOS pi4.   Adding the 
>>> encoding=utf_8 line didn't help, unfortunately.  The encoding was 
>>> previously set to html_entities in skin.conf
>>>
>>> I've attached the .tmpl file and skin.conf for the skin in case 
>>> there are obvious errors therein.  FWIW the skin is kinda ancient so 
>>> it's 
>>> possible I missed adding something along the way.
>>>
>>>
>>> On Thursday, August 24, 2023 at 3:58:44 PM UTC-7 Tom Keffer wrote:
>>>
 Internal to WeeWX, the label microgram_per_meter_cubed is 
 encoded in Unicode. To be included in a template, it has to be 
 converted to 
 an appropriate byte string using an encoding. By default, the Seasons 
 templates use html entities to do this encoding. The results will be 
 in 
 simple ASCII.

 Note: this is *separate* from the encoding used by the templates 
 themselves, which is generally UTF-8. This is what you're setting with 
 the 
 #encoding directive. This is useful if one were to include UTF-8 
 characters *directly 
 in the templates themselves*. But, that's not what's happening 
 here.

 The html entity encoding for the cube symbol is either "³", or 
 "³". For whatever reason, your Python installation is choosing 
 the 
 latter, which your browser does not seem to be capable of interpreting 
 as 
 the cube symbol. I've seen this happen when the file suffix is ".txt", 
 but 
 yours is ".html" (check!).

 It may be a browser specific thing. What browser are you using? 
 Perhaps you can point us to the page?

 One thing you can try is another encoding be

Re: [weewx-user] Re: formatting issue in cheetah

[vince]

Did not help.  Is it possible there is something in the nginx configuration 
'or' the combination of python3/cheetah in the venv that might be at fault 
?   I'm running a v5 beta pip install FWIW.

Here's the simplest example I can cook up.
Simply try to show the units for something in group_concentration

#errorCatcher Echo


   test page 
  
  
  
  This should look ok ==> $unit.label.pm2_5_cf_1<
   




On Friday, August 25, 2023 at 6:47:54 PM UTC-7 Tom Keffer wrote:

> Your little test page is still being interpreted by Chrome as being 
> encoded in "windows-1252". Try including a meta tag for the encoding:
>
> 
> 
>  test page 
> 
> 
> 
>
> On Fri, Aug 25, 2023 at 6:08 PM vince  wrote:
>
>> No joy.
>>
>> Try "test.html" now for a far simpler variant.
>> It'll take a few minutes for the rsync to update the public version.
>>
>> Here's the page source.
>>
>> 
>>   
>>test page 
>>   
>>
>>   
>>   
>> 
>>   
>> AQI (current)
>> 80.5
>>   
>>   
>> AQI (last hour)
>> 72.25
>>   
>>   
>> AQI (last day)
>> 76.80139372822299
>>   
>>   
>> pm2_5_cf_1
>> 25.960 
>>  µg/m³
>>   
>> 
>>   
>>
>> 
>>
>>
>> On Friday, August 25, 2023 at 5:32:28 PM UTC-7 Tom Keffer wrote:
>>
>>> The problem is the 'xmlns' declaration in your  tag. It is causing 
>>> metadata to be pulled in, which says that the character set is 
>>> "windows-1252".
>>>
>>> Change this
>>>
>>>
>>>
>>> *http://www.w3.org/1999/xhtml 
>>> ">  >> profile="http://www.w3.org/2005/10/profile 
>>> ">*
>>>
>>> to this
>>>
>>> **
>>> *  *
>>>
>>> and I think your troubles will go away.
>>>
>>> -tk
>>>
>>> On Fri, Aug 25, 2023 at 4:29 PM Greg from Oz  wrote:
>>>
 I am in Australia and https://www.skahan.net/weewx/purpleair.html 
 works. So the Australian geo block is working OK.
 [image: Screenshot from 2023-08-26 09-25-36.png]

 On Saturday, 26 August 2023 at 09:10:00 UTC+10 Tom Keffer wrote:

> Both the template and the skin configuration look fine.
>
> Despite being just down the road from you, I am unable to connect to 
> your webserver.
>
>
>
> On Thu, Aug 24, 2023 at 5:15 PM vince  wrote:
>
>> URL that rsync uploads to is 
>> https://www.skahan.net/weewx/purpleair.html - this will not be 
>> available unless you're in US/CA/AU probably due to some geoip blocking 
>> that I have set up on the ISP side to try to limit how many bots bang on 
>> the site.
>>
>> Same thing happens on chrome on mac os and iphone as well as Safari 
>> on mac os.   The weewx host is a current RaspiOS pi4.   Adding the 
>> encoding=utf_8 line didn't help, unfortunately.  The encoding was 
>> previously set to html_entities in skin.conf
>>
>> I've attached the .tmpl file and skin.conf for the skin in case there 
>> are obvious errors therein.  FWIW the skin is kinda ancient so it's 
>> possible I missed adding something along the way.
>>
>>
>> On Thursday, August 24, 2023 at 3:58:44 PM UTC-7 Tom Keffer wrote:
>>
>>> Internal to WeeWX, the label microgram_per_meter_cubed is encoded in 
>>> Unicode. To be included in a template, it has to be converted to an 
>>> appropriate byte string using an encoding. By default, the Seasons 
>>> templates use html entities to do this encoding. The results will be in 
>>> simple ASCII.
>>>
>>> Note: this is *separate* from the encoding used by the templates 
>>> themselves, which is generally UTF-8. This is what you're setting with 
>>> the 
>>> #encoding directive. This is useful if one were to include UTF-8 
>>> characters *directly 
>>> in the templates themselves*. But, that's not what's happening here.
>>>
>>> The html entity encoding for the cube symbol is either "³", or 
>>> "³". For whatever reason, your Python installation is choosing the 
>>> latter, which your browser does not seem to be capable of interpreting 
>>> as 
>>> the cube symbol. I've seen this happen when the file suffix is ".txt", 
>>> but 
>>> yours is ".html" (check!).
>>>
>>> It may be a browser specific thing. What browser are you using? 
>>> Perhaps you can point us to the page?
>>>
>>> One thing you can try is another encoding besides html entities. For 
>>> example, utf-8.
>>>
>>> *[CheetahGenerator]*
>>> *  encoding=utf_8 *
>>>
>>>
>>>
>>> On Thu, Aug 24, 2023 at 3:30 PM vince  wrote:
>>>
 Thanks.  No joy.

 Added to top of the file under the echo line ala...

 ## Copyright 2009-2018 Tom Keffer, Matthew Wall
>>>

Re: [weewx-user] Re: formatting issue in cheetah

[Tom Keffer]

Your little test page is still being interpreted by Chrome as being encoded
in "windows-1252". Try including a meta tag for the encoding:



 test page 




On Fri, Aug 25, 2023 at 6:08 PM vince  wrote:

> No joy.
>
> Try "test.html" now for a far simpler variant.
> It'll take a few minutes for the rsync to update the public version.
>
> Here's the page source.
>
> 
>   
>test page 
>   
>
>   
>   
> 
>   
> AQI (current)
> 80.5
>   
>   
> AQI (last hour)
> 72.25
>   
>   
> AQI (last day)
> 76.80139372822299
>   
>   
> pm2_5_cf_1
> 25.960
>  µg/m³
>   
> 
>   
>
> 
>
>
> On Friday, August 25, 2023 at 5:32:28 PM UTC-7 Tom Keffer wrote:
>
>> The problem is the 'xmlns' declaration in your  tag. It is causing
>> metadata to be pulled in, which says that the character set is
>> "windows-1252".
>>
>> Change this
>>
>>
>>
>> *http://www.w3.org/1999/xhtml
>> ">  > profile="http://www.w3.org/2005/10/profile
>> ">*
>>
>> to this
>>
>> **
>> *  *
>>
>> and I think your troubles will go away.
>>
>> -tk
>>
>> On Fri, Aug 25, 2023 at 4:29 PM Greg from Oz  wrote:
>>
>>> I am in Australia and https://www.skahan.net/weewx/purpleair.html
>>> works. So the Australian geo block is working OK.
>>> [image: Screenshot from 2023-08-26 09-25-36.png]
>>>
>>> On Saturday, 26 August 2023 at 09:10:00 UTC+10 Tom Keffer wrote:
>>>
 Both the template and the skin configuration look fine.

 Despite being just down the road from you, I am unable to connect to
 your webserver.



 On Thu, Aug 24, 2023 at 5:15 PM vince  wrote:

> URL that rsync uploads to is
> https://www.skahan.net/weewx/purpleair.html - this will not be
> available unless you're in US/CA/AU probably due to some geoip blocking
> that I have set up on the ISP side to try to limit how many bots bang on
> the site.
>
> Same thing happens on chrome on mac os and iphone as well as Safari on
> mac os.   The weewx host is a current RaspiOS pi4.   Adding the
> encoding=utf_8 line didn't help, unfortunately.  The encoding was
> previously set to html_entities in skin.conf
>
> I've attached the .tmpl file and skin.conf for the skin in case there
> are obvious errors therein.  FWIW the skin is kinda ancient so it's
> possible I missed adding something along the way.
>
>
> On Thursday, August 24, 2023 at 3:58:44 PM UTC-7 Tom Keffer wrote:
>
>> Internal to WeeWX, the label microgram_per_meter_cubed is encoded in
>> Unicode. To be included in a template, it has to be converted to an
>> appropriate byte string using an encoding. By default, the Seasons
>> templates use html entities to do this encoding. The results will be in
>> simple ASCII.
>>
>> Note: this is *separate* from the encoding used by the templates
>> themselves, which is generally UTF-8. This is what you're setting with 
>> the
>> #encoding directive. This is useful if one were to include UTF-8 
>> characters *directly
>> in the templates themselves*. But, that's not what's happening here.
>>
>> The html entity encoding for the cube symbol is either "³", or
>> "³". For whatever reason, your Python installation is choosing the
>> latter, which your browser does not seem to be capable of interpreting as
>> the cube symbol. I've seen this happen when the file suffix is ".txt", 
>> but
>> yours is ".html" (check!).
>>
>> It may be a browser specific thing. What browser are you using?
>> Perhaps you can point us to the page?
>>
>> One thing you can try is another encoding besides html entities. For
>> example, utf-8.
>>
>> *[CheetahGenerator]*
>> *  encoding=utf_8 *
>>
>>
>>
>> On Thu, Aug 24, 2023 at 3:30 PM vince  wrote:
>>
>>> Thanks.  No joy.
>>>
>>> Added to top of the file under the echo line ala...
>>>
>>> ## Copyright 2009-2018 Tom Keffer, Matthew Wall
>>> ## Distributed under terms of GPLv3.  See LICENSE.txt for your
>>> rights.
>>> #errorCatcher Echo
>>> #encoding UTF-8
>>>
>>> #set $periods = $to_list($DisplayOptions.get('periods', ['day',
>>> 'week', 'month', 'year']))
>>> #set $plot_groups = $to_list($DisplayOptions.get('plot_groups',
>>> ['tempdew', 'wind', 'rain']))
>>>
>>> ## use this span to determine whether there are any data to consider.
>>> #set $recent=$span($day_delta=30, boundary='midnight')
>>>
>>> 
>>> 
>>>   
>>> 
>>> $station.location
>>> 
>>> 
>>> #if $station.station_url
>>> 
>>> #e

Re: [weewx-user] Re: formatting issue in cheetah

[vince]

No joy.

Try "test.html" now for a far simpler variant.
It'll take a few minutes for the rsync to update the public version.

Here's the page source.


  
   test page 
  

  
  

  
AQI (current)
80.5
  
  
AQI (last hour)
72.25
  
  
AQI (last day)
76.80139372822299
  
  
pm2_5_cf_1
25.960 
 µg/m³
  

  
   



On Friday, August 25, 2023 at 5:32:28 PM UTC-7 Tom Keffer wrote:

> The problem is the 'xmlns' declaration in your  tag. It is causing 
> metadata to be pulled in, which says that the character set is 
> "windows-1252".
>
> Change this
>
>
>
> *http://www.w3.org/1999/xhtml 
> ">   profile="http://www.w3.org/2005/10/profile 
> ">*
>
> to this
>
> **
> *  *
>
> and I think your troubles will go away.
>
> -tk
>
> On Fri, Aug 25, 2023 at 4:29 PM Greg from Oz  wrote:
>
>> I am in Australia and https://www.skahan.net/weewx/purpleair.html works. 
>> So the Australian geo block is working OK.
>> [image: Screenshot from 2023-08-26 09-25-36.png]
>>
>> On Saturday, 26 August 2023 at 09:10:00 UTC+10 Tom Keffer wrote:
>>
>>> Both the template and the skin configuration look fine.
>>>
>>> Despite being just down the road from you, I am unable to connect to 
>>> your webserver.
>>>
>>>
>>>
>>> On Thu, Aug 24, 2023 at 5:15 PM vince  wrote:
>>>
 URL that rsync uploads to is 
 https://www.skahan.net/weewx/purpleair.html - this will not be 
 available unless you're in US/CA/AU probably due to some geoip blocking 
 that I have set up on the ISP side to try to limit how many bots bang on 
 the site.

 Same thing happens on chrome on mac os and iphone as well as Safari on 
 mac os.   The weewx host is a current RaspiOS pi4.   Adding the 
 encoding=utf_8 line didn't help, unfortunately.  The encoding was 
 previously set to html_entities in skin.conf

 I've attached the .tmpl file and skin.conf for the skin in case there 
 are obvious errors therein.  FWIW the skin is kinda ancient so it's 
 possible I missed adding something along the way.


 On Thursday, August 24, 2023 at 3:58:44 PM UTC-7 Tom Keffer wrote:

> Internal to WeeWX, the label microgram_per_meter_cubed is encoded in 
> Unicode. To be included in a template, it has to be converted to an 
> appropriate byte string using an encoding. By default, the Seasons 
> templates use html entities to do this encoding. The results will be in 
> simple ASCII.
>
> Note: this is *separate* from the encoding used by the templates 
> themselves, which is generally UTF-8. This is what you're setting with 
> the 
> #encoding directive. This is useful if one were to include UTF-8 
> characters *directly 
> in the templates themselves*. But, that's not what's happening here.
>
> The html entity encoding for the cube symbol is either "³", or 
> "³". For whatever reason, your Python installation is choosing the 
> latter, which your browser does not seem to be capable of interpreting as 
> the cube symbol. I've seen this happen when the file suffix is ".txt", 
> but 
> yours is ".html" (check!).
>
> It may be a browser specific thing. What browser are you using? 
> Perhaps you can point us to the page?
>
> One thing you can try is another encoding besides html entities. For 
> example, utf-8.
>
> *[CheetahGenerator]*
> *  encoding=utf_8 *
>
>
>
> On Thu, Aug 24, 2023 at 3:30 PM vince  wrote:
>
>> Thanks.  No joy.
>>
>> Added to top of the file under the echo line ala...
>>
>> ## Copyright 2009-2018 Tom Keffer, Matthew Wall
>> ## Distributed under terms of GPLv3.  See LICENSE.txt for your rights.
>> #errorCatcher Echo
>> #encoding UTF-8
>>
>> #set $periods = $to_list($DisplayOptions.get('periods', ['day', 
>> 'week', 'month', 'year']))
>> #set $plot_groups = $to_list($DisplayOptions.get('plot_groups', 
>> ['tempdew', 'wind', 'rain']))
>>
>> ## use this span to determine whether there are any data to consider.
>> #set $recent=$span($day_delta=30, boundary='midnight')
>>
>> 
>> 
>>   
>> 
>> $station.location
>> 
>> 
>> #if $station.station_url
>> 
>> #end if
>> 
>>   
>>
>>   
>> #include "titlebar.inc"
>>
>> And appended the AQI line to the footer to make it easier for me to 
>> find during testing...
>>
>> 
>>   $gettext("This station is controlled by WeeWX, an experimental weather software 
>> system written in Python.")
>>   AQI: 
>> $latest('pur

Re: [weewx-user] Re: formatting issue in cheetah

[Tom Keffer]

The problem is the 'xmlns' declaration in your  tag. It is causing
metadata to be pulled in, which says that the character set is
"windows-1252".

Change this



*http://www.w3.org/1999/xhtml
">  http://www.w3.org/2005/10/profile
">*

to this

**
*  *

and I think your troubles will go away.

-tk

On Fri, Aug 25, 2023 at 4:29 PM Greg from Oz  wrote:

> I am in Australia and https://www.skahan.net/weewx/purpleair.html works.
> So the Australian geo block is working OK.
> [image: Screenshot from 2023-08-26 09-25-36.png]
>
> On Saturday, 26 August 2023 at 09:10:00 UTC+10 Tom Keffer wrote:
>
>> Both the template and the skin configuration look fine.
>>
>> Despite being just down the road from you, I am unable to connect to your
>> webserver.
>>
>>
>>
>> On Thu, Aug 24, 2023 at 5:15 PM vince  wrote:
>>
>>> URL that rsync uploads to is https://www.skahan.net/weewx/purpleair.html
>>> - this will not be available unless you're in US/CA/AU probably due to some
>>> geoip blocking that I have set up on the ISP side to try to limit how many
>>> bots bang on the site.
>>>
>>> Same thing happens on chrome on mac os and iphone as well as Safari on
>>> mac os.   The weewx host is a current RaspiOS pi4.   Adding the
>>> encoding=utf_8 line didn't help, unfortunately.  The encoding was
>>> previously set to html_entities in skin.conf
>>>
>>> I've attached the .tmpl file and skin.conf for the skin in case there
>>> are obvious errors therein.  FWIW the skin is kinda ancient so it's
>>> possible I missed adding something along the way.
>>>
>>>
>>> On Thursday, August 24, 2023 at 3:58:44 PM UTC-7 Tom Keffer wrote:
>>>
 Internal to WeeWX, the label microgram_per_meter_cubed is encoded in
 Unicode. To be included in a template, it has to be converted to an
 appropriate byte string using an encoding. By default, the Seasons
 templates use html entities to do this encoding. The results will be in
 simple ASCII.

 Note: this is *separate* from the encoding used by the templates
 themselves, which is generally UTF-8. This is what you're setting with the
 #encoding directive. This is useful if one were to include UTF-8 
 characters *directly
 in the templates themselves*. But, that's not what's happening here.

 The html entity encoding for the cube symbol is either "³", or
 "³". For whatever reason, your Python installation is choosing the
 latter, which your browser does not seem to be capable of interpreting as
 the cube symbol. I've seen this happen when the file suffix is ".txt", but
 yours is ".html" (check!).

 It may be a browser specific thing. What browser are you using? Perhaps
 you can point us to the page?

 One thing you can try is another encoding besides html entities. For
 example, utf-8.

 *[CheetahGenerator]*
 *  encoding=utf_8 *



 On Thu, Aug 24, 2023 at 3:30 PM vince  wrote:

> Thanks.  No joy.
>
> Added to top of the file under the echo line ala...
>
> ## Copyright 2009-2018 Tom Keffer, Matthew Wall
> ## Distributed under terms of GPLv3.  See LICENSE.txt for your rights.
> #errorCatcher Echo
> #encoding UTF-8
>
> #set $periods = $to_list($DisplayOptions.get('periods', ['day',
> 'week', 'month', 'year']))
> #set $plot_groups = $to_list($DisplayOptions.get('plot_groups',
> ['tempdew', 'wind', 'rain']))
>
> ## use this span to determine whether there are any data to consider.
> #set $recent=$span($day_delta=30, boundary='midnight')
>
> 
> 
>   
> 
> $station.location
> 
> 
> #if $station.station_url
> 
> #end if
> 
>   
>
>   
> #include "titlebar.inc"
>
> And appended the AQI line to the footer to make it easier for me to
> find during testing...
>
> 
>   $gettext("This station is controlled by WeeWX, an experimental weather software system
> written in Python.")
>   AQI:
> $latest('purpleair_binding').aqi2_5.format(format_string="%.0f")
>  ($latest('purpleair_binding').pm2_5_cf_1.format(format_string="%.1f"))
>
>
> Result looks like:
>   This station is controlled by WeeWX , an
> experimental weather software system written in Python. AQI: 64 (17.9
> µg/m³)
>
> Output in the .html is:
>
>   This station is controlled by WeeWX,
> an experimental weather software system written in Python.
> AQI: 64(17.9 µg/m³)
>
> On Thursday, August 24, 2023 at 3:16:01 PM UTC-7 gjr80 wrote:
>
>> I notice the Seasons index.html.tmpl does not have a #encoding
>> directive (though the other Seasons .html.tmpl files do). Have you
>> tried adding a #encoding directive à la:
>>
>> #errorCatcher Echo #encoding UTF-8 
>>>

Re: [weewx-user] Specific Report Generation Periods

[Tom Keffer]

Is this what you're thinking? https://github.com/weewx/weewx/issues/91

On Fri, Aug 25, 2023 at 9:58 AM carter.hu...@gmail.com <
carter.humphrey...@gmail.com> wrote:

> Hi,
>
> I'm wondering if there is a way to have a report have a specific end time.
> For example, I'd like to create a 24 hour data summary ending at 7 am LT
> each day, rather than each day from midnight to midnight.
>
> I figured using a span and setting a specific report generation time would
> work, but that wouldn't back-fill any missing reports.
>
> Any 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/a5be1096-8846-46d5-8694-378c3f2dbd79n%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/CAPq0zED0%3DGk5SMtRmREsRU3AmEu9AjBxPQeu2bL-9LzuKhU5yg%40mail.gmail.com.

Re: [weewx-user] Re: formatting issue in cheetah

[Greg from Oz]

I am in Australia and https://www.skahan.net/weewx/purpleair.html works. So 
the Australian geo block is working OK.
[image: Screenshot from 2023-08-26 09-25-36.png]

On Saturday, 26 August 2023 at 09:10:00 UTC+10 Tom Keffer wrote:

> Both the template and the skin configuration look fine.
>
> Despite being just down the road from you, I am unable to connect to your 
> webserver.
>
>
>
> On Thu, Aug 24, 2023 at 5:15 PM vince  wrote:
>
>> URL that rsync uploads to is https://www.skahan.net/weewx/purpleair.html 
>> - this will not be available unless you're in US/CA/AU probably due to some 
>> geoip blocking that I have set up on the ISP side to try to limit how many 
>> bots bang on the site.
>>
>> Same thing happens on chrome on mac os and iphone as well as Safari on 
>> mac os.   The weewx host is a current RaspiOS pi4.   Adding the 
>> encoding=utf_8 line didn't help, unfortunately.  The encoding was 
>> previously set to html_entities in skin.conf
>>
>> I've attached the .tmpl file and skin.conf for the skin in case there are 
>> obvious errors therein.  FWIW the skin is kinda ancient so it's possible I 
>> missed adding something along the way.
>>
>>
>> On Thursday, August 24, 2023 at 3:58:44 PM UTC-7 Tom Keffer wrote:
>>
>>> Internal to WeeWX, the label microgram_per_meter_cubed is encoded in 
>>> Unicode. To be included in a template, it has to be converted to an 
>>> appropriate byte string using an encoding. By default, the Seasons 
>>> templates use html entities to do this encoding. The results will be in 
>>> simple ASCII.
>>>
>>> Note: this is *separate* from the encoding used by the templates 
>>> themselves, which is generally UTF-8. This is what you're setting with the 
>>> #encoding directive. This is useful if one were to include UTF-8 characters 
>>> *directly 
>>> in the templates themselves*. But, that's not what's happening here.
>>>
>>> The html entity encoding for the cube symbol is either "³", or 
>>> "³". For whatever reason, your Python installation is choosing the 
>>> latter, which your browser does not seem to be capable of interpreting as 
>>> the cube symbol. I've seen this happen when the file suffix is ".txt", but 
>>> yours is ".html" (check!).
>>>
>>> It may be a browser specific thing. What browser are you using? Perhaps 
>>> you can point us to the page?
>>>
>>> One thing you can try is another encoding besides html entities. For 
>>> example, utf-8.
>>>
>>> *[CheetahGenerator]*
>>> *  encoding=utf_8 *
>>>
>>>
>>>
>>> On Thu, Aug 24, 2023 at 3:30 PM vince  wrote:
>>>
 Thanks.  No joy.

 Added to top of the file under the echo line ala...

 ## Copyright 2009-2018 Tom Keffer, Matthew Wall
 ## Distributed under terms of GPLv3.  See LICENSE.txt for your rights.
 #errorCatcher Echo
 #encoding UTF-8

 #set $periods = $to_list($DisplayOptions.get('periods', ['day', 'week', 
 'month', 'year']))
 #set $plot_groups = $to_list($DisplayOptions.get('plot_groups', 
 ['tempdew', 'wind', 'rain']))

 ## use this span to determine whether there are any data to consider.
 #set $recent=$span($day_delta=30, boundary='midnight')

 
 
   
 
 $station.location
 
 
 #if $station.station_url
 
 #end if
 
   

   
 #include "titlebar.inc"

 And appended the AQI line to the footer to make it easier for me to 
 find during testing...

 
   $gettext("This station is controlled by WeeWX, an experimental weather software system 
 written in Python.")
   AQI: 
 $latest('purpleair_binding').aqi2_5.format(format_string="%.0f")   
  ($latest('purpleair_binding').pm2_5_cf_1.format(format_string="%.1f"))


 Result looks like:
   This station is controlled by WeeWX , an 
 experimental weather software system written in Python. AQI: 64 (17.9 
 µg/m³)

 Output in the .html is:

   This station is controlled by WeeWX, 
 an experimental weather software system written in Python.
 AQI: 64(17.9 µg/m³)

 On Thursday, August 24, 2023 at 3:16:01 PM UTC-7 gjr80 wrote:

> I notice the Seasons index.html.tmpl does not have a #encoding 
> directive (though the other Seasons .html.tmpl files do). Have you 
> tried adding a #encoding directive à la:
>
> #errorCatcher Echo #encoding UTF-8 
>
> Gary
>
> On Friday, 25 August 2023 at 07:19:12 UTC+10 vince wrote:
>
>> Well I can't explain it at all.  I appended the same .tmpl line at 
>> the bottom of index.html.tmpl for the Seasons skin (trusting Tom gets 
>> this 
>> stuff correctly) and I still see funny encoding in Safari + Chrome (mac) 
>> and in Chrome (iphone).   I can only guess it has something to do with 
>> the 
>> locale or i18n settings on the pi4 that weewx is running on, but I'm 
>>

Re: [weewx-user] FTP-TLS File transfer fails

[Tom Keffer]

Good to know. I've added your experience to the list of symptoms.

On Fri, Aug 25, 2023 at 7:34 AM Karl Napp  wrote:

> Thank's a lot,
> with
>
> *reuse_ssl = True *
> it works !
>
> Tom Keffer schrieb am Donnerstag, 24. August 2023 um 23:56:58 UTC+2:
>
>> I'm not sure what is going on. It's likely to be a server
>> configuration issue. One thing you can try is the "reuse_ssl" option.
>>
>> *[[FTP]]*
>>
>> * ... (as before)*
>> *reuse_ssl = True*
>>
>> On Thu, Aug 24, 2023 at 12:18 AM Karl Napp  wrote:
>>
>>> I don't know the FTP server, it's provided by DomainFactory.
>>> I using Python 3.9.2
>>> I have set debug = 2 in weewx.conf here is the ouput of syslog:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Aug 24 07:56:14 berryzero weewx[14238] DEBUG weewx.reportengine:
>>> Running report 'FTP'Aug 24 07:56:14 berryzero weewx[14238] DEBUG
>>> weewx.reportengine: Found configuration file /etc/weewx/skins/Ftp/skin.conf
>>> for report 'FTP'Aug 24 07:56:14 berryzero weewx[14238] DEBUG
>>> weewx.reportengine: Cannot read localization file
>>> /etc/weewx/skins/Ftp/lang/en.conf for report 'FTP': Config file not found:
>>> "/etc/weewx/skins/Ftp/lang/en.conf".Aug 24 07:56:14 berryzero weewx[14238]
>>> DEBUG weewx.reportengine:  Using defaults instead.Aug 24 07:56:14
>>> berryzero weewx[14238] DEBUG weeutil.ftpupload: Attempting secure
>>> connection to ossipage.de Aug 24 07:56:14 berryzero
>>> weewx[14238] DEBUG weeutil.ftpupload: Secure data connection to ossipage.de
>>> Aug 24 07:56:15 berryzero weewx[14238] DEBUG
>>> weeutil.ftpupload: 0 ./monthvolt.png
>>> d0881dfeb05b7be0f05f66b3d36f7baff02679c2b081990e738339851bc51bb6Aug 24
>>> 07:56:15 berryzero weewx[14238] ERROR weeutil.ftpupload: Failed uploading
>>> /var/www/html/weewx/monthvolt.png to server ossipage.de
>>> . Reason: '425 Unable to build data connection:
>>> Operation not permitted'Aug 24 07:56:15 berryzero weewx[14238] ERROR
>>> weewx.reportengine: ftpgenerator: (0): caught exception '>> 'ftplib.error_temp'>': 425 Unable to build data connection: Operation not
>>> permittedAug 24 07:56:15 berryzero weewx[14238] ERROR weewx.reportengine:
>>>     Traceback (most recent call last):Aug 24 07:56:15 berryzero
>>> weewx[14238] ERROR weewx.reportengine: File
>>> "/usr/share/weewx/weewx/reportengine.py", line 437, in runAug 24 07:56:15
>>> berryzero weewx[14238] ERROR weewx.reportengine:   n =
>>> ftp_data.run()Aug 24 07:56:15 berryzero weewx[14238] ERROR
>>> weewx.reportengine: File
>>> "/usr/share/weewx/weeutil/ftpupload.py", line 220, in runAug 24 07:56:15
>>> berryzero weewx[14238] ERROR weewx.reportengine: 
>>>  ftp_server.storbinary(stor_cmd, fd)Aug 24 07:56:15 berryzero weewx[14238]
>>> ERROR weewx.reportengine: File
>>> "/usr/lib/python3.9/ftplib.py", line 502, in storbinaryAug 24 07:56:15
>>> berryzero weewx[14238] ERROR weewx.reportengine:   return
>>> self.voidresp()Aug 24 07:56:15 berryzero weewx[14238] ERROR
>>> weewx.reportengine: File "/usr/lib/python3.9/ftplib.py",
>>> line 257, in voidrespAug 24 07:56:15 berryzero weewx[14238] ERROR
>>> weewx.reportengine:   resp = self.getresp()Aug 24 07:56:15
>>> berryzero weewx[14238] ERROR weewx.reportengine: File
>>> "/usr/lib/python3.9/ftplib.py", line 250, in getrespAug 24 07:56:15
>>> berryzero weewx[14238] ERROR weewx.reportengine:   raise
>>> error_temp(resp)Aug 24 07:56:15 berryzero weewx[14238] ERROR
>>> weewx.reportengine:   ftplib.error_temp: 425 Unable to build
>>> data connection: Operation not permittedAug 24 07:56:15 berryzero
>>> weewx[14238] DEBUG weeutil.ftpupload: Attempting secure connection to
>>> ossipage.de Aug 24 07:56:15 berryzero weewx[14238]
>>> DEBUG weeutil.ftpupload: Secure data connection to ossipage.de
>>> Aug 24 07:56:15 berryzero weewx[14238] DEBUG
>>> weeutil.ftpupload: 0 ./monthvolt.png
>>> d0881dfeb05b7be0f05f66b3d36f7baff02679c2b081990e738339851bc51bb6Aug 24
>>> 07:56:15 berryzero weewx[14238] ERROR weeutil.ftpupload: Failed uploading
>>> /var/www/html/weewx/monthvolt.png to server ossipage.de
>>> . Reason: '425 Unable to build data connection:
>>> Operation not permitted'Aug 24 07:56:15 berryzero weewx[14238] ERROR
>>> weewx.reportengine: ftpgenerator: (1): caught exception '>> 'ftplib.error_temp'>': 425 Unable to build data connection: Operation not
>>> permitted*
>>>
>>> Tom Keffer schrieb am Mittwoch, 23. August 2023 um 21:01:59 UTC+2:
>>>
 Do you know which FTP server this is?

 What version of Python are you using?

 Set debug=2, then try again. It will give additional information.

 -tk

 On Wed, Aug 23, 2023 at 9:01 AM Karl Napp  wrote:

> HI,
> I've ena

Re: [weewx-user] Just upgraded to 4.10.2 and Python3

[David Barto]

Backed off to 9.5.0 and the errors went away, however the png files are still 
not being generated.

The only errors in the log are:

Aug 25 16:20:12 Magrathea2 weewx[2226] ERROR weewx.rest]: PWSWeather: Failed to 
publish record 2023-08-25 16:18:00 PDT (1693005480): Failed upload after 3 tries
Aug 25 16:20:12 Magrathea2 weewx[2226] ERROR weewx.rest]: StationRegistry: 
Failed to publish record 2023-08-25 16:18:00 PDT (1693005480): Failed upload 
after 3 tries
Aug 25 16:20:12 Magrathea2 weewx[2226] ERROR weewx.rest]: Wunderground-PWS: 
Failed to publish record 2023-08-25 16:18:00 PDT (1693005480): Failed upload 
after 3 tries


Which are un-important right now. I’ll fix that in a bit.

Other suggestions?

David

> On Aug 25, 2023, at 3:53 PM, vince  wrote:
> 
> If you google for your error message "AttributeError: type object 'ImageDraw' 
> has no attribute 'textsize' " you'll find an old thread about this
> https://groups.google.com/g/weewx-user/c/4qz0bwgna7g
> 
> 
> 
> On Friday, August 25, 2023 at 2:42:21 PM UTC-7 David Barto wrote:
>> On a new Mac, and I’m getting the following: 
>> 
>> AttributeError: type object 'ImageDraw' has no attribute 'textsize' 
>> Traceback (most recent call last): 
>> File "/Users/Shared/weewx-4.10.2/bin/weewx/reportengine.py", line 197, in 
>> run 
>> obj.start() 
>> File "/Users/Shared/weewx-4.10.2/bin/weewx/reportengine.py", line 385, in 
>> start 
>> self.run() 
>> File "/Users/Shared/weewx-4.10.2/bin/weewx/imagegenerator.py", line 42, in 
>> run 
>> self.gen_images(self.gen_ts) 
>> File "/Users/Shared/weewx-4.10.2/bin/weewx/imagegenerator.py", line 114, in 
>> gen_images 
>> image = plot.render() 
>> File "/Users/Shared/weewx-4.10.2/bin/weeplot/genplot.py", line 212, in 
>> render 
>> self._renderBottom(draw) 
>> File "/Users/Shared/weewx-4.10.2/bin/weeplot/genplot.py", line 404, in 
>> _renderBottom 
>> bottom_label_size = draw.textsize(self.bottom_label, font=bottom_label_font) 
>> File "/Users/Shared/weewx-4.10.2/bin/weeplot/genplot.py", line 646, in 
>> textsize 
>> return ImageDraw.ImageDraw.textsize(self, string, **options) 
>> 
>> Highs, lows look fine. 
>> 
>> Loop packets appear OK: 
>> LOOP: 2023-08-25 14:40:56 PDT (1692999656) 'altimeter': '29.931', 'appTemp': 
>> '88.20251678811093', 'bar_reduction': '2', 'barometer': '29.897', 
>> 'cloudbase': '4570.074962495151', 'dateTime': '1692999656', 'dayET': '0.0', 
>> 'dayRain': '0.0', 'dewpoint': '67.0', 'ET': 'None', 'heatindex': '87.0', 
>> 'hourRain': '0.0', 'humidex': '96.5974355268055', 'inDewpoint': 
>> '63.14965844190338', 'inHumidity': '56.0', 'inTemp': '80.3', 'maxSolarRad': 
>> '856.5713445507906', 'outHumidity': '58.0', 'outTemp': '83.6', 'pressure': 
>> '29.023', 'pressure_raw': '29.023', 'rain': '0.0', 'rain15': '0.0', 
>> 'rain24': '0.0', 'rainRate': '0.0', 'stormRain': '0.0', 'trendIcon': '-20', 
>> 'usUnits': '1', 'windchill': '84.0', 'windDir': '296.0', 'windGust': '8.0', 
>> 'windGust10': '11.0', 'windGustDir': '277.0', 'windGustDir10': '270.0', 
>> 'windrun': 'None', 'windSpeed': '3.0', 'windSpeed2': '4.0', 'windSpeed10': 
>> '5.6' 
>> LOOP: 2023-08-25 14:40:58 PDT (1692999658) 'altimeter': '29.931', 'appTemp': 
>> '88.20251678811093', 'bar_reduction': '2', 'barometer': '29.897', 
>> 'cloudbase': '4570.074962495151', 'dateTime': '1692999658', 'dayET': '0.0', 
>> 'dayRain': '0.0', 'dewpoint': '67.0', 'ET': 'None', 'heatindex': '87.0', 
>> 'hourRain': '0.0', 'humidex': '96.5974355268055', 'inDewpoint': 
>> '63.14965844190338', 'inHumidity': '56.0', 'inTemp': '80.3', 'maxSolarRad': 
>> '856.4989148817249', 'outHumidity': '58.0', 'outTemp': '83.6', 'pressure': 
>> '29.023', 'pressure_raw': '29.023', 'rain': '0.0', 'rain15': '0.0', 
>> 'rain24': '0.0', 'rainRate': '0.0', 'stormRain': '0.0', 'trendIcon': '-20', 
>> 'usUnits': '1', 'windchill': '84.0', 'windDir': '296.0', 'windGust': '8.0', 
>> 'windGust10': '11.0', 'windGustDir': '277.0', 'windGustDir10': '270.0', 
>> 'windrun': 'None', 'windSpeed': '3.0', 'windSpeed2': '4.0', 'windSpeed10': 
>> ‘5.6' 
>> 
>> 
>> So I’m not generating any images. 
>> 
>> David 
>> 
>> 
>> ...well over half of the time you spend working on a project (on the order 
>> of 70 percent) 
>> is spent thinking, and no tool, no matter how advanced, can think for you. 
>> Consequently, even if a tool did everything except the thinking for you -- 
>> if it wrote 100 percent of the code, 
>> wrote 100 percent of the documentation, did 100 percent of the testing, 
>> burned the CD-ROMs, 
>> put them in boxes, and mailed them to your customers -- the best you could 
>> hope for would 
>> be a 30 percent improvement in productivity. In order to do better than 
>> that, you have to 
>> change the way you think. 
>> --Fred Brooks 
>> David Barto 
>> ba...@kdbarto.org <> 
>> 
>> 
> 
> 
> -- 
> 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 

Re: [weewx-user] WeeWX v5 pip Install into venv

[Greg from Oz]

I am running V5 and I put all my venv files into /opt so I have to remember 
to run the full path:
EG sudo /opt/weewx/weewx-venv/bin/wee_reports 
--config=/opt/weewx/weewx-data/weewx.conf

To use the venv I run :source /opt/weewx/weewx-venv/bin/activate
also if you want to exit the venv type the command: *deactivate*

Like Tom said the systemctl uses the full path:
ExecStart=/opt/weewx/weewx-venv/bin/python3 
/opt/weewx/weewx-venv/lib/python3.11/site-packages/weewxd.py 
/opt/weewx/weewx-data/weewx.conf

I am running weewx as root user but my config files have my user 
permissions and ownership.

On Saturday, 26 August 2023 at 09:12:48 UTC+10 Tom Keffer wrote:

> Running the venv's binaries (versus activation) is completely acceptable. 
> Indeed, that's what the systemctl unit file does.
>
> On Fri, Aug 25, 2023 at 3:27 AM Greg Troxel  wrote:
>
>> Graham Eddy  writes:
>>
>> > use ‘python3 -m venv ~/venv’ to create the environment in ~/venv.
>> > then in your shell run ’source ~/venv/bin/activate’ to set up the shell 
>> environment (initialised python bindary, PYTHONPATH etc). i put this in my 
>> ~/.bashrc
>> >
>> > a key trick is that running the initialised python binary 
>> (~/venv/bin/python3) on its own sucks in the environment - really, really 
>> handy in systemctl unit files
>> > ⊣GE⊢
>>
>> I have never activated a venv and always been puzzled by this being the
>> standard approach.  Simply running the venv' python binary, either
>> explicitly on the command line, or via a #!, has been entirely fine.  I
>> have home assistant working this way, which is super comlicated compared
>> to weewx.
>>
>> I also run, when in the venv dir
>>
>>   bin/pip install foo
>>
>> which runs the venv's pip which uses the venv's python.
>>
>> I'm glad to hear that there is no special 'have to activate' rule about
>> weewx.
>>
>>
>>
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/rmi1qfre7t2.fsf%40s1.lexort.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/f60c2332-6151-48d3-8573-3d282460355bn%40googlegroups.com.

Re: [weewx-user] WeeWX v5 pip Install into venv

[Tom Keffer]

Running the venv's binaries (versus activation) is completely acceptable.
Indeed, that's what the systemctl unit file does.

On Fri, Aug 25, 2023 at 3:27 AM Greg Troxel  wrote:

> Graham Eddy  writes:
>
> > use ‘python3 -m venv ~/venv’ to create the environment in ~/venv.
> > then in your shell run ’source ~/venv/bin/activate’ to set up the shell
> environment (initialised python bindary, PYTHONPATH etc). i put this in my
> ~/.bashrc
> >
> > a key trick is that running the initialised python binary
> (~/venv/bin/python3) on its own sucks in the environment - really, really
> handy in systemctl unit files
> > ⊣GE⊢
>
> I have never activated a venv and always been puzzled by this being the
> standard approach.  Simply running the venv' python binary, either
> explicitly on the command line, or via a #!, has been entirely fine.  I
> have home assistant working this way, which is super comlicated compared
> to weewx.
>
> I also run, when in the venv dir
>
>   bin/pip install foo
>
> which runs the venv's pip which uses the venv's python.
>
> I'm glad to hear that there is no special 'have to activate' rule about
> weewx.
>
>
>
>
> --
> 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/rmi1qfre7t2.fsf%40s1.lexort.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/CAPq0zEDPagn7x_3sTzXexEdWyGXozGNGJ2-xcV6G88FE9fRh7w%40mail.gmail.com.

Re: [weewx-user] Re: formatting issue in cheetah

[Tom Keffer]

Both the template and the skin configuration look fine.

Despite being just down the road from you, I am unable to connect to your
webserver.



On Thu, Aug 24, 2023 at 5:15 PM vince  wrote:

> URL that rsync uploads to is https://www.skahan.net/weewx/purpleair.html
> - this will not be available unless you're in US/CA/AU probably due to some
> geoip blocking that I have set up on the ISP side to try to limit how many
> bots bang on the site.
>
> Same thing happens on chrome on mac os and iphone as well as Safari on mac
> os.   The weewx host is a current RaspiOS pi4.   Adding the encoding=utf_8
> line didn't help, unfortunately.  The encoding was previously set to
> html_entities in skin.conf
>
> I've attached the .tmpl file and skin.conf for the skin in case there are
> obvious errors therein.  FWIW the skin is kinda ancient so it's possible I
> missed adding something along the way.
>
>
> On Thursday, August 24, 2023 at 3:58:44 PM UTC-7 Tom Keffer wrote:
>
>> Internal to WeeWX, the label microgram_per_meter_cubed is encoded in
>> Unicode. To be included in a template, it has to be converted to an
>> appropriate byte string using an encoding. By default, the Seasons
>> templates use html entities to do this encoding. The results will be in
>> simple ASCII.
>>
>> Note: this is *separate* from the encoding used by the templates
>> themselves, which is generally UTF-8. This is what you're setting with the
>> #encoding directive. This is useful if one were to include UTF-8 characters 
>> *directly
>> in the templates themselves*. But, that's not what's happening here.
>>
>> The html entity encoding for the cube symbol is either "³", or
>> "³". For whatever reason, your Python installation is choosing the
>> latter, which your browser does not seem to be capable of interpreting as
>> the cube symbol. I've seen this happen when the file suffix is ".txt", but
>> yours is ".html" (check!).
>>
>> It may be a browser specific thing. What browser are you using? Perhaps
>> you can point us to the page?
>>
>> One thing you can try is another encoding besides html entities. For
>> example, utf-8.
>>
>> *[CheetahGenerator]*
>> *  encoding=utf_8 *
>>
>>
>>
>> On Thu, Aug 24, 2023 at 3:30 PM vince  wrote:
>>
>>> Thanks.  No joy.
>>>
>>> Added to top of the file under the echo line ala...
>>>
>>> ## Copyright 2009-2018 Tom Keffer, Matthew Wall
>>> ## Distributed under terms of GPLv3.  See LICENSE.txt for your rights.
>>> #errorCatcher Echo
>>> #encoding UTF-8
>>>
>>> #set $periods = $to_list($DisplayOptions.get('periods', ['day', 'week',
>>> 'month', 'year']))
>>> #set $plot_groups = $to_list($DisplayOptions.get('plot_groups',
>>> ['tempdew', 'wind', 'rain']))
>>>
>>> ## use this span to determine whether there are any data to consider.
>>> #set $recent=$span($day_delta=30, boundary='midnight')
>>>
>>> 
>>> 
>>>   
>>> 
>>> $station.location
>>> 
>>> 
>>> #if $station.station_url
>>> 
>>> #end if
>>> 
>>>   
>>>
>>>   
>>> #include "titlebar.inc"
>>>
>>> And appended the AQI line to the footer to make it easier for me to find
>>> during testing...
>>>
>>> 
>>>   $gettext("This station is controlled by >> href='https://weewx.com'>WeeWX,
>>> an experimental weather software system written in Python.")
>>>   AQI:
>>> $latest('purpleair_binding').aqi2_5.format(format_string="%.0f")
>>>  ($latest('purpleair_binding').pm2_5_cf_1.format(format_string="%.1f"))
>>>
>>>
>>> Result looks like:
>>>   This station is controlled by WeeWX , an
>>> experimental weather software system written in Python. AQI: 64 (17.9
>>> µg/m³)
>>>
>>> Output in the .html is:
>>>
>>>   This station is controlled by WeeWX,
>>> an experimental weather software system written in Python.
>>> AQI: 64(17.9 µg/m³)
>>>
>>> On Thursday, August 24, 2023 at 3:16:01 PM UTC-7 gjr80 wrote:
>>>
 I notice the Seasons index.html.tmpl does not have a #encoding
 directive (though the other Seasons .html.tmpl files do). Have you
 tried adding a #encoding directive à la:

 #errorCatcher Echo #encoding UTF-8 

 Gary

 On Friday, 25 August 2023 at 07:19:12 UTC+10 vince wrote:

> Well I can't explain it at all.  I appended the same .tmpl line at the
> bottom of index.html.tmpl for the Seasons skin (trusting Tom gets this
> stuff correctly) and I still see funny encoding in Safari + Chrome (mac)
> and in Chrome (iphone).   I can only guess it has something to do with the
> locale or i18n settings on the pi4 that weewx is running on, but I'm just
> guessing completely at this point.
>
> On Thursday, August 24, 2023 at 12:54:21 PM UTC-7 Karen K wrote:
>
>> Unfortunately the greek my character and the cubic symbol are not
>> US-ASCII. So they have the 8th bit set. There are different methods to do
>> that. The older one is ISO 8859, where one byte is always one character.
>> The newer one is UTF-8 where o

Re: [weewx-user] Just upgraded to 4.10.2 and Python3

[David Barto]

Thanks, My searching the archives didn’t find it.

David

> On Aug 25, 2023, at 3:53 PM, vince  wrote:
> 
> If you google for your error message "AttributeError: type object 'ImageDraw' 
> has no attribute 'textsize' " you'll find an old thread about this
> https://groups.google.com/g/weewx-user/c/4qz0bwgna7g
> 
> 
> 
> On Friday, August 25, 2023 at 2:42:21 PM UTC-7 David Barto wrote:
>> On a new Mac, and I’m getting the following: 
>> 
>> AttributeError: type object 'ImageDraw' has no attribute 'textsize' 
>> Traceback (most recent call last): 
>> File "/Users/Shared/weewx-4.10.2/bin/weewx/reportengine.py", line 197, in 
>> run 
>> obj.start() 
>> File "/Users/Shared/weewx-4.10.2/bin/weewx/reportengine.py", line 385, in 
>> start 
>> self.run() 
>> File "/Users/Shared/weewx-4.10.2/bin/weewx/imagegenerator.py", line 42, in 
>> run 
>> self.gen_images(self.gen_ts) 
>> File "/Users/Shared/weewx-4.10.2/bin/weewx/imagegenerator.py", line 114, in 
>> gen_images 
>> image = plot.render() 
>> File "/Users/Shared/weewx-4.10.2/bin/weeplot/genplot.py", line 212, in 
>> render 
>> self._renderBottom(draw) 
>> File "/Users/Shared/weewx-4.10.2/bin/weeplot/genplot.py", line 404, in 
>> _renderBottom 
>> bottom_label_size = draw.textsize(self.bottom_label, font=bottom_label_font) 
>> File "/Users/Shared/weewx-4.10.2/bin/weeplot/genplot.py", line 646, in 
>> textsize 
>> return ImageDraw.ImageDraw.textsize(self, string, **options) 
>> 
>> Highs, lows look fine. 
>> 
>> Loop packets appear OK: 
>> LOOP: 2023-08-25 14:40:56 PDT (1692999656) 'altimeter': '29.931', 'appTemp': 
>> '88.20251678811093', 'bar_reduction': '2', 'barometer': '29.897', 
>> 'cloudbase': '4570.074962495151', 'dateTime': '1692999656', 'dayET': '0.0', 
>> 'dayRain': '0.0', 'dewpoint': '67.0', 'ET': 'None', 'heatindex': '87.0', 
>> 'hourRain': '0.0', 'humidex': '96.5974355268055', 'inDewpoint': 
>> '63.14965844190338', 'inHumidity': '56.0', 'inTemp': '80.3', 'maxSolarRad': 
>> '856.5713445507906', 'outHumidity': '58.0', 'outTemp': '83.6', 'pressure': 
>> '29.023', 'pressure_raw': '29.023', 'rain': '0.0', 'rain15': '0.0', 
>> 'rain24': '0.0', 'rainRate': '0.0', 'stormRain': '0.0', 'trendIcon': '-20', 
>> 'usUnits': '1', 'windchill': '84.0', 'windDir': '296.0', 'windGust': '8.0', 
>> 'windGust10': '11.0', 'windGustDir': '277.0', 'windGustDir10': '270.0', 
>> 'windrun': 'None', 'windSpeed': '3.0', 'windSpeed2': '4.0', 'windSpeed10': 
>> '5.6' 
>> LOOP: 2023-08-25 14:40:58 PDT (1692999658) 'altimeter': '29.931', 'appTemp': 
>> '88.20251678811093', 'bar_reduction': '2', 'barometer': '29.897', 
>> 'cloudbase': '4570.074962495151', 'dateTime': '1692999658', 'dayET': '0.0', 
>> 'dayRain': '0.0', 'dewpoint': '67.0', 'ET': 'None', 'heatindex': '87.0', 
>> 'hourRain': '0.0', 'humidex': '96.5974355268055', 'inDewpoint': 
>> '63.14965844190338', 'inHumidity': '56.0', 'inTemp': '80.3', 'maxSolarRad': 
>> '856.4989148817249', 'outHumidity': '58.0', 'outTemp': '83.6', 'pressure': 
>> '29.023', 'pressure_raw': '29.023', 'rain': '0.0', 'rain15': '0.0', 
>> 'rain24': '0.0', 'rainRate': '0.0', 'stormRain': '0.0', 'trendIcon': '-20', 
>> 'usUnits': '1', 'windchill': '84.0', 'windDir': '296.0', 'windGust': '8.0', 
>> 'windGust10': '11.0', 'windGustDir': '277.0', 'windGustDir10': '270.0', 
>> 'windrun': 'None', 'windSpeed': '3.0', 'windSpeed2': '4.0', 'windSpeed10': 
>> ‘5.6' 
>> 
>> 
>> So I’m not generating any images. 
>> 
>> David 
>> 
>> 
>> ...well over half of the time you spend working on a project (on the order 
>> of 70 percent) 
>> is spent thinking, and no tool, no matter how advanced, can think for you. 
>> Consequently, even if a tool did everything except the thinking for you -- 
>> if it wrote 100 percent of the code, 
>> wrote 100 percent of the documentation, did 100 percent of the testing, 
>> burned the CD-ROMs, 
>> put them in boxes, and mailed them to your customers -- the best you could 
>> hope for would 
>> be a 30 percent improvement in productivity. In order to do better than 
>> that, you have to 
>> change the way you think. 
>> --Fred Brooks 
>> David Barto 
>> ba...@kdbarto.org <> 
>> 
>> 
> 
> 
> -- 
> 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/64684198-6473-4a3d-b690-f6af373a61c5n%40googlegroups.com
>  
> .

...well over half of the time you spend working on a project (on the order of 
70 percent)
is spent thinking, and no tool, no matter how advanced, can think for you.
Consequently, even if a tool did everything except the thinking for you -- if 
it wrote 100 percent of the co

[weewx-user] Re: Just upgraded to 4.10.2 and Python3

[vince]

If you google for your error message "*AttributeError: type object 
'ImageDraw' has no attribute 'textsize' *" you'll find an old thread about 
this
https://groups.google.com/g/weewx-user/c/4qz0bwgna7g



On Friday, August 25, 2023 at 2:42:21 PM UTC-7 David Barto wrote:

> On a new Mac, and I’m getting the following:
>
> AttributeError: type object 'ImageDraw' has no attribute 'textsize'
> Traceback (most recent call last):
> File "/Users/Shared/weewx-4.10.2/bin/weewx/reportengine.py", line 197, in 
> run
> obj.start()
> File "/Users/Shared/weewx-4.10.2/bin/weewx/reportengine.py", line 385, in 
> start
> self.run()
> File "/Users/Shared/weewx-4.10.2/bin/weewx/imagegenerator.py", line 42, in 
> run
> self.gen_images(self.gen_ts)
> File "/Users/Shared/weewx-4.10.2/bin/weewx/imagegenerator.py", line 114, 
> in gen_images
> image = plot.render()
> File "/Users/Shared/weewx-4.10.2/bin/weeplot/genplot.py", line 212, in 
> render
> self._renderBottom(draw)
> File "/Users/Shared/weewx-4.10.2/bin/weeplot/genplot.py", line 404, in 
> _renderBottom
> bottom_label_size = draw.textsize(self.bottom_label, 
> font=bottom_label_font)
> File "/Users/Shared/weewx-4.10.2/bin/weeplot/genplot.py", line 646, in 
> textsize
> return ImageDraw.ImageDraw.textsize(self, string, **options)
>
> Highs, lows look fine.
>
> Loop packets appear OK:
> LOOP: 2023-08-25 14:40:56 PDT (1692999656) 'altimeter': '29.931', 
> 'appTemp': '88.20251678811093', 'bar_reduction': '2', 'barometer': 
> '29.897', 'cloudbase': '4570.074962495151', 'dateTime': '1692999656', 
> 'dayET': '0.0', 'dayRain': '0.0', 'dewpoint': '67.0', 'ET': 'None', 
> 'heatindex': '87.0', 'hourRain': '0.0', 'humidex': '96.5974355268055', 
> 'inDewpoint': '63.14965844190338', 'inHumidity': '56.0', 'inTemp': '80.3', 
> 'maxSolarRad': '856.5713445507906', 'outHumidity': '58.0', 'outTemp': 
> '83.6', 'pressure': '29.023', 'pressure_raw': '29.023', 'rain': '0.0', 
> 'rain15': '0.0', 'rain24': '0.0', 'rainRate': '0.0', 'stormRain': '0.0', 
> 'trendIcon': '-20', 'usUnits': '1', 'windchill': '84.0', 'windDir': 
> '296.0', 'windGust': '8.0', 'windGust10': '11.0', 'windGustDir': '277.0', 
> 'windGustDir10': '270.0', 'windrun': 'None', 'windSpeed': '3.0', 
> 'windSpeed2': '4.0', 'windSpeed10': '5.6'
> LOOP: 2023-08-25 14:40:58 PDT (1692999658) 'altimeter': '29.931', 
> 'appTemp': '88.20251678811093', 'bar_reduction': '2', 'barometer': 
> '29.897', 'cloudbase': '4570.074962495151', 'dateTime': '1692999658', 
> 'dayET': '0.0', 'dayRain': '0.0', 'dewpoint': '67.0', 'ET': 'None', 
> 'heatindex': '87.0', 'hourRain': '0.0', 'humidex': '96.5974355268055', 
> 'inDewpoint': '63.14965844190338', 'inHumidity': '56.0', 'inTemp': '80.3', 
> 'maxSolarRad': '856.4989148817249', 'outHumidity': '58.0', 'outTemp': 
> '83.6', 'pressure': '29.023', 'pressure_raw': '29.023', 'rain': '0.0', 
> 'rain15': '0.0', 'rain24': '0.0', 'rainRate': '0.0', 'stormRain': '0.0', 
> 'trendIcon': '-20', 'usUnits': '1', 'windchill': '84.0', 'windDir': 
> '296.0', 'windGust': '8.0', 'windGust10': '11.0', 'windGustDir': '277.0', 
> 'windGustDir10': '270.0', 'windrun': 'None', 'windSpeed': '3.0', 
> 'windSpeed2': '4.0', 'windSpeed10': ‘5.6'
>
>
> So I’m not generating any images.
>
> David
>
>
> ...well over half of the time you spend working on a project (on the order 
> of 70 percent)
> is spent thinking, and no tool, no matter how advanced, can think for you.
> Consequently, even if a tool did everything except the thinking for you -- 
> if it wrote 100 percent of the code,
> wrote 100 percent of the documentation, did 100 percent of the testing, 
> burned the CD-ROMs,
> put them in boxes, and mailed them to your customers -- the best you could 
> hope for would
> be a 30 percent improvement in productivity. In order to do better than 
> that, you have to
> change the way you think.
> --Fred Brooks
> David Barto
> ba...@kdbarto.org
>
>
>

-- 
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/64684198-6473-4a3d-b690-f6af373a61c5n%40googlegroups.com.

[weewx-user] Station repaired

[Neville Davis]

Hi
I have finally repaired most of my install and new info included in my 
weewx Wiki page for a station with i2C sensors. Still more work to be done 
but here is a link to my station.
https://bit.ly/44v9302

Nev

-- 
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/6786f05f-6a67-4dd2-a31f-c63fd3426ad4n%40googlegroups.com.

[weewx-user] Just upgraded to 4.10.2 and Python3

[David Barto]

On a new Mac, and I’m getting the following:

AttributeError: type object 'ImageDraw' has no attribute 'textsize'
Traceback (most recent call last):
  File "/Users/Shared/weewx-4.10.2/bin/weewx/reportengine.py", line 197, in run
obj.start()
  File "/Users/Shared/weewx-4.10.2/bin/weewx/reportengine.py", line 385, in 
start
self.run()
  File "/Users/Shared/weewx-4.10.2/bin/weewx/imagegenerator.py", line 42, in run
self.gen_images(self.gen_ts)
  File "/Users/Shared/weewx-4.10.2/bin/weewx/imagegenerator.py", line 114, in 
gen_images
image = plot.render()
  File "/Users/Shared/weewx-4.10.2/bin/weeplot/genplot.py", line 212, in render
self._renderBottom(draw)
  File "/Users/Shared/weewx-4.10.2/bin/weeplot/genplot.py", line 404, in 
_renderBottom
bottom_label_size = draw.textsize(self.bottom_label, font=bottom_label_font)
  File "/Users/Shared/weewx-4.10.2/bin/weeplot/genplot.py", line 646, in 
textsize
return ImageDraw.ImageDraw.textsize(self, string, **options)

Highs, lows look fine.

Loop packets appear OK:
LOOP:   2023-08-25 14:40:56 PDT (1692999656) 'altimeter': '29.931', 'appTemp': 
'88.20251678811093', 'bar_reduction': '2', 'barometer': '29.897', 'cloudbase': 
'4570.074962495151', 'dateTime': '1692999656', 'dayET': '0.0', 'dayRain': 
'0.0', 'dewpoint': '67.0', 'ET': 'None', 'heatindex': '87.0', 'hourRain': 
'0.0', 'humidex': '96.5974355268055', 'inDewpoint': '63.14965844190338', 
'inHumidity': '56.0', 'inTemp': '80.3', 'maxSolarRad': '856.5713445507906', 
'outHumidity': '58.0', 'outTemp': '83.6', 'pressure': '29.023', 'pressure_raw': 
'29.023', 'rain': '0.0', 'rain15': '0.0', 'rain24': '0.0', 'rainRate': '0.0', 
'stormRain': '0.0', 'trendIcon': '-20', 'usUnits': '1', 'windchill': '84.0', 
'windDir': '296.0', 'windGust': '8.0', 'windGust10': '11.0', 'windGustDir': 
'277.0', 'windGustDir10': '270.0', 'windrun': 'None', 'windSpeed': '3.0', 
'windSpeed2': '4.0', 'windSpeed10': '5.6'
LOOP:   2023-08-25 14:40:58 PDT (1692999658) 'altimeter': '29.931', 'appTemp': 
'88.20251678811093', 'bar_reduction': '2', 'barometer': '29.897', 'cloudbase': 
'4570.074962495151', 'dateTime': '1692999658', 'dayET': '0.0', 'dayRain': 
'0.0', 'dewpoint': '67.0', 'ET': 'None', 'heatindex': '87.0', 'hourRain': 
'0.0', 'humidex': '96.5974355268055', 'inDewpoint': '63.14965844190338', 
'inHumidity': '56.0', 'inTemp': '80.3', 'maxSolarRad': '856.4989148817249', 
'outHumidity': '58.0', 'outTemp': '83.6', 'pressure': '29.023', 'pressure_raw': 
'29.023', 'rain': '0.0', 'rain15': '0.0', 'rain24': '0.0', 'rainRate': '0.0', 
'stormRain': '0.0', 'trendIcon': '-20', 'usUnits': '1', 'windchill': '84.0', 
'windDir': '296.0', 'windGust': '8.0', 'windGust10': '11.0', 'windGustDir': 
'277.0', 'windGustDir10': '270.0', 'windrun': 'None', 'windSpeed': '3.0', 
'windSpeed2': '4.0', 'windSpeed10': ‘5.6'


So I’m not generating any images.

David


...well over half of the time you spend working on a project (on the order of 
70 percent)
is spent thinking, and no tool, no matter how advanced, can think for you.
Consequently, even if a tool did everything except the thinking for you -- if 
it wrote 100 percent of the code,
wrote 100 percent of the documentation, did 100 percent of the testing, burned 
the CD-ROMs,
put them in boxes, and mailed them to your customers -- the best you could hope 
for would
be a 30 percent improvement in productivity. In order to do better than that, 
you have to
change the way you think.
--Fred Brooks
David Barto
ba...@kdbarto.org


-- 
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/7F93D007-969C-4EFE-8F8B-0A66D270BA06%40kdbarto.org.

[weewx-user] Wrapping Custom Content on the Belchertown front page

[MikeQ]

I am using index_hook_after_forecast.inc on the Belchertown front page to 
add two rows with two columns of METARs (four total METARs).  Here is my 
.inc file:

METARs
https://www.aviationweather.gov/taf/data?ids=KEUL,KBOI,KWMC,KMEV,KSCK&format=raw&metars=off&layout=on";>TAFs

  
$KONO_metar
$KEUL_metar
  
  
$KBOI_metar
$KMEV_metar
  


As you shrink the width of the browser window, the text will wrap in the 
 elements to keep both columns visible in the widow, but not all the 
way down to iPhone screen size. On an iPhone 7 about half of the right 
column is cut-off.  The rest of the front page text wraps correctly and 
remains visible on the iPhone 7.

Anyone know how I should re-write my HTML above so it also wraps properly 
on an iPhone screen?

-- 
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/a345e696-81cb-48b0-8cb3-ca8a77f76ba6n%40googlegroups.com.

[weewx-user] Specific Report Generation Periods

[carter.hu...@gmail.com]

Hi,

I'm wondering if there is a way to have a report have a specific end time. 
For example, I'd like to create a 24 hour data summary ending at 7 am LT 
each day, rather than each day from midnight to midnight.

I figured using a span and setting a specific report generation time would 
work, but that wouldn't back-fill any missing reports.

Any 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/a5be1096-8846-46d5-8694-378c3f2dbd79n%40googlegroups.com.

[weewx-user] weewx multi undo

[Joachim Puttkammer]

I can't convert weewx multi back to a simple weewx.

I have replaced /etc/default/weewx-multi with weewx

WEEWX_PYTHON=python3
WEEWX_PYTHON_ARGS=
WEEWX_BINDIR=/usr/share/weewx
WEEWX_BIN=/usr/bin/weewxd
WEEWX_CFG=/etc/weewx/weewx.conf

also copied the multi-weewx.conf to weewx.conf

What is still missing?

-- 
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/8cc5ad9d-1fbf-43c2-a86d-866dd4a3264an%40googlegroups.com.

Re: [weewx-user] FTP-TLS File transfer fails

[Karl Napp]

Thank's a lot,
with 

*reuse_ssl = True *
it works !

Tom Keffer schrieb am Donnerstag, 24. August 2023 um 23:56:58 UTC+2:

> I'm not sure what is going on. It's likely to be a server 
> configuration issue. One thing you can try is the "reuse_ssl" option.
>
> *[[FTP]]*
>
> * ... (as before)*
> *reuse_ssl = True*
>
> On Thu, Aug 24, 2023 at 12:18 AM Karl Napp  wrote:
>
>> I don't know the FTP server, it's provided by DomainFactory. 
>> I using Python 3.9.2
>> I have set debug = 2 in weewx.conf here is the ouput of syslog:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Aug 24 07:56:14 berryzero weewx[14238] DEBUG weewx.reportengine: Running 
>> report 'FTP'Aug 24 07:56:14 berryzero weewx[14238] DEBUG 
>> weewx.reportengine: Found configuration file /etc/weewx/skins/Ftp/skin.conf 
>> for report 'FTP'Aug 24 07:56:14 berryzero weewx[14238] DEBUG 
>> weewx.reportengine: Cannot read localization file 
>> /etc/weewx/skins/Ftp/lang/en.conf for report 'FTP': Config file not found: 
>> "/etc/weewx/skins/Ftp/lang/en.conf".Aug 24 07:56:14 berryzero weewx[14238] 
>> DEBUG weewx.reportengine:  Using defaults instead.Aug 24 07:56:14 
>> berryzero weewx[14238] DEBUG weeutil.ftpupload: Attempting secure 
>> connection to ossipage.de Aug 24 07:56:14 berryzero 
>> weewx[14238] DEBUG weeutil.ftpupload: Secure data connection to ossipage.de 
>> Aug 24 07:56:15 berryzero weewx[14238] DEBUG 
>> weeutil.ftpupload: 0 ./monthvolt.png 
>> d0881dfeb05b7be0f05f66b3d36f7baff02679c2b081990e738339851bc51bb6Aug 24 
>> 07:56:15 berryzero weewx[14238] ERROR weeutil.ftpupload: Failed uploading 
>> /var/www/html/weewx/monthvolt.png to server ossipage.de 
>> . Reason: '425 Unable to build data connection: 
>> Operation not permitted'Aug 24 07:56:15 berryzero weewx[14238] ERROR 
>> weewx.reportengine: ftpgenerator: (0): caught exception '> 'ftplib.error_temp'>': 425 Unable to build data connection: Operation not 
>> permittedAug 24 07:56:15 berryzero weewx[14238] ERROR weewx.reportengine:   
>>     Traceback (most recent call last):Aug 24 07:56:15 berryzero 
>> weewx[14238] ERROR weewx.reportengine: File 
>> "/usr/share/weewx/weewx/reportengine.py", line 437, in runAug 24 07:56:15 
>> berryzero weewx[14238] ERROR weewx.reportengine:   n = 
>> ftp_data.run()Aug 24 07:56:15 berryzero weewx[14238] ERROR 
>> weewx.reportengine: File 
>> "/usr/share/weewx/weeutil/ftpupload.py", line 220, in runAug 24 07:56:15 
>> berryzero weewx[14238] ERROR weewx.reportengine:  
>>  ftp_server.storbinary(stor_cmd, fd)Aug 24 07:56:15 berryzero weewx[14238] 
>> ERROR weewx.reportengine: File 
>> "/usr/lib/python3.9/ftplib.py", line 502, in storbinaryAug 24 07:56:15 
>> berryzero weewx[14238] ERROR weewx.reportengine:   return 
>> self.voidresp()Aug 24 07:56:15 berryzero weewx[14238] ERROR 
>> weewx.reportengine: File "/usr/lib/python3.9/ftplib.py", 
>> line 257, in voidrespAug 24 07:56:15 berryzero weewx[14238] ERROR 
>> weewx.reportengine:   resp = self.getresp()Aug 24 07:56:15 
>> berryzero weewx[14238] ERROR weewx.reportengine: File 
>> "/usr/lib/python3.9/ftplib.py", line 250, in getrespAug 24 07:56:15 
>> berryzero weewx[14238] ERROR weewx.reportengine:   raise 
>> error_temp(resp)Aug 24 07:56:15 berryzero weewx[14238] ERROR 
>> weewx.reportengine:   ftplib.error_temp: 425 Unable to build 
>> data connection: Operation not permittedAug 24 07:56:15 berryzero 
>> weewx[14238] DEBUG weeutil.ftpupload: Attempting secure connection to 
>> ossipage.de Aug 24 07:56:15 berryzero weewx[14238] 
>> DEBUG weeutil.ftpupload: Secure data connection to ossipage.de 
>> Aug 24 07:56:15 berryzero weewx[14238] DEBUG 
>> weeutil.ftpupload: 0 ./monthvolt.png 
>> d0881dfeb05b7be0f05f66b3d36f7baff02679c2b081990e738339851bc51bb6Aug 24 
>> 07:56:15 berryzero weewx[14238] ERROR weeutil.ftpupload: Failed uploading 
>> /var/www/html/weewx/monthvolt.png to server ossipage.de 
>> . Reason: '425 Unable to build data connection: 
>> Operation not permitted'Aug 24 07:56:15 berryzero weewx[14238] ERROR 
>> weewx.reportengine: ftpgenerator: (1): caught exception '> 'ftplib.error_temp'>': 425 Unable to build data connection: Operation not 
>> permitted*
>>
>> Tom Keffer schrieb am Mittwoch, 23. August 2023 um 21:01:59 UTC+2:
>>
>>> Do you know which FTP server this is?
>>>
>>> What version of Python are you using?
>>>
>>> Set debug=2, then try again. It will give additional information.
>>>
>>> -tk
>>>
>>> On Wed, Aug 23, 2023 at 9:01 AM Karl Napp  wrote:
>>>
 HI,
 I've enabled the FTP over TLS as described in the user's guide. When 
 the FTP Upload starts  weewx returns with ERRORS
  Here is a snippet  syslog output:

 Aug 23 16:50:

Re: [weewx-user] WeeWX v5 pip Install into venv

[Greg Troxel]

Graham Eddy  writes:

> use ‘python3 -m venv ~/venv’ to create the environment in ~/venv.
> then in your shell run ’source ~/venv/bin/activate’ to set up the shell 
> environment (initialised python bindary, PYTHONPATH etc). i put this in my 
> ~/.bashrc
>
> a key trick is that running the initialised python binary 
> (~/venv/bin/python3) on its own sucks in the environment - really, really 
> handy in systemctl unit files
> ⊣GE⊢

I have never activated a venv and always been puzzled by this being the
standard approach.  Simply running the venv' python binary, either
explicitly on the command line, or via a #!, has been entirely fine.  I
have home assistant working this way, which is super comlicated compared
to weewx.

I also run, when in the venv dir

  bin/pip install foo

which runs the venv's pip which uses the venv's python.

I'm glad to hear that there is no special 'have to activate' rule about
weewx.


 

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