[weewx-user] Re: error 401 with import WU

[Sébastien F4GQK]

Hello,

Thanks for your help, I had put the password in my wd.conf file instead of 
the api key  

Seb

Le lundi 18 janvier 2021 à 00:27:53 UTC+1, gjr80 a écrit :

> I should also add can you double check your API key in /var/tmp/wu.conf 
> is correct by confirming it against the API key listed under the 'API Keys' 
> tab of 'Member Settings' when you login to your WU account.
>
> Gary
>
> On Monday, 18 January 2021 at 09:20:23 UTC+10 gjr80 wrote:
>
>> Thank you. It would appear the credentials you are using to access WU are 
>> not being accepted by WU. Currently there are three distinct pieces of 
>> information you will use in WeeWX to access WU. To post WeeWX data to WU 
>> you will use station ID or name and a password. These are defined in 
>> weewx.conf under [StdRESTful] [[Wunderground]]. If WeeWX is successfully 
>> uploading data to WU then these two parameters are correctly set.
>>
>> When using wee_import to download data from WU you need to use station 
>> ID or name again but his time you need an API key rather than a password. 
>> The API key must be obtained from WU separately is a hexadecimal string 32 
>> characters in length. You must define your station ID or name and API key 
>> in your import config file, in your case /var/tmp/wu.conf.
>>
>> Can you confirm that you have the correct API key against the api_key 
>> setting in /var/tmp/wu.conf and is it 32 hexadecimal characters in 
>> length?
>>
>> Also, could you please post future console output as text rather than as 
>> an image/screenshot, screenshots make life difficult for us, particularly 
>> when using mobile devices. There are a number of ways to do this, if you 
>> are unsure how you will find some guidance in the Help! posting to 
>> weewx-user 
>>  wiki 
>> article.
>>
>> Gary
>> On Sunday, 17 January 2021 at 06:24:49 UTC+10 f4...@f4gqk.fr wrote:
>>
>>> Hello,
>>>
>>> [image: error401.jpg]
>>>
>>>
>>> My version Weewx is : 4.3.0
>>>
>>> Thanks
>>>
>>> Sebastien - F4GQK 
>>>
>>> Le mardi 12 janvier 2021 à 20:30:37 UTC+1, gjr80 a écrit :
>>>
 Hi,

 Can you please post the exact output you are seeing when wee_import 
 fails. Also what version of WeeWX are you running?

 Gary
 On Wednesday, 13 January 2021 at 03:52:44 UTC+10 f4...@f4gqk.fr wrote:

> Hello,
>
> I am going to the following command:
>
>
>
> * wee_import --config=/etc/weewx/weewx.conf 
> --import-config=/var/tmp/wu.conf  *
>
> and I have a 401 error.
>
> *HTTP Error 401, Unauthorized*
>
> My station ID is OK on wunderground and my password is OK too.
>
> Does anyone have the same problem?
>
> Thank you and happy new year
>
> Sebastien 
>
>
>

-- 
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/b0d81718-1293-4e1f-99b3-0ea3d69c08ean%40googlegroups.com.

Re: [weewx-user] refresh screen

[John Smith]

I get the same error occasionally, which is annoying as it stops the page
from loading/refreshing, but it's a temp error which can be ignored.

On Tue, 19 Jan 2021 at 04:28, sali...@gmail.com  wrote:

> hi,
> I have sometime this error message when there is the screen refresh
>
> my Firefox browser is up todate !!
>
> do you know this issue ?
>
> thanks
>
> patrick
>
>
> --
> 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/89cef812-7b55-41da-869a-37a404b58ab8n%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/CAGTinV6OjadM-QeOTd2DbBskucPAbEe48N%2BCXfk5YdoiHzE5Jg%40mail.gmail.com.

[weewx-user] Re: GW1000 driver v0.2.0 release

[gjr80]

On Tuesday, 19 January 2021 at 09:42:36 UTC+10 ward...@gmail.com wrote:

> I've just got my WH45 and its working great with new driver thanks Gary. 
> I've noticed that the CO2 internal temp & humidity are coming through as 
> the curiously named "extraTemp17" and "extraHumid17" does that sound right? 


Correct, that was intentional. As you would be aware the GW1000 (and of 
course the API) supports up to eight WH31 TH sensors. These are referred to 
as temp1-8 in the API. The API also has provision for an additional eight 
temperature fields which are referred to in the API documentation as 
temp9-16 and consequently I have provided for them as temp9-16 in the 
GW1000 driver. The WH45 provided temperature data is referred to as 
'tf_co2' in the API but to avoid confusion and keep some consistency I have 
allocated the WH45 temperature field as temp17. Of course all of these 
tempx fields map to extraTempxx in the default field map. Interestingly, 
the GW1000 API does not support a second block of humidity fields 
(humid9-16). Again for consistency I have allocated the WH45 humidity field 
to humid17 (extraHumid17), this may cause some confusion but I felt it 
better to keep aligned with the approach used with the temperature fields.
 

> Also FYI at some point wiki sensor map page will need updating :-)
>

Thanks. Actually thought I had done that but it appears I did not. The 
tabulated field map on the Field map wiki page 
 has now been updated 
to reflect v0.2.0 of the driver. 

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/8e99476b-f64b-4a79-a8ac-e2a60a4e40ban%40googlegroups.com.

[weewx-user] Re: 4.1.1 - No module named 'Image'

[vince]

On Monday, January 18, 2021 at 7:17:27 PM UTC-8 cql...@gmail.com wrote:

> As for your question, I've set up an nfs share mounted to all 3 pi's, and 
> created a persistent volume for my archive and frontend. While I haven't 
> yet persisted my logs, that's probably a good idea, and wouldn't be too 
> hard. I've only had the cluster up and running for a couple weeks now, so 
> I'm definitely still learning a lot.
>

That's what's always stopped me here.  The cost/pain to have a quality NFS 
server exceeds the benefit of running kubernetes for me.

Although my quad 4GB pi4 cluster sure runs k3s nicely to say the least :-)

-- 
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/ff2c3c5b-d9fb-4bbf-bfb7-e66f6071a147n%40googlegroups.com.

[weewx-user] Re: Database Backup File not a Database Error

[vince]

On Monday, January 18, 2021 at 6:47:09 PM UTC-8 kdch...@gmail.com wrote:

> Now when I try to copy the unpacked sdb and pick up where I left off I get 
> a message that the file is not a database.  I have tried a couple of 
> archives from Dec and Jan.  All seem to be no good.  I did notice that when 
> I reinstalled weewx it is now version 4.3.0.  Could I be dealing with a 
> system version mismatch in the file or is there something wrong with my 
> backup process.  
>

Very likely a backup process issue, although the steps you mentioned looked 
good to me.

We'd need to see some actual logs or terminal errors to know for certain 
what you're actually seeing.

I guess what I'd do is:

   - grab a recent backup, copy it to a scratch directory
   - uncompress it to a .sdb file
   - run 'file' against the .sdb file
   - If it shows up as a sqlite3 db, then you can validate it with the 
   sqlite3 utility.


Good output looks like

# file weewx.sdb
weewx.sdb: SQLite 3.x database, last written using SQLite version 3026000

# echo "pragma integrity_check" | sqlite3 weewx.sdb
ok


-- 
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/b992ed82-a814-49fe-8479-8a826122af11n%40googlegroups.com.

[weewx-user] Re: 4.1.1 - No module named 'Image'

[cql...@gmail.com]

You're absolutely right - and this is the consequence of building off of 
someone else's docker image! Had I started the process from scratch, I 
probably would have started with a more fully featured base image.

As for your question, I've set up an nfs share mounted to all 3 pi's, and 
created a persistent volume for my archive and frontend. While I haven't 
yet persisted my logs, that's probably a good idea, and wouldn't be too 
hard. I've only had the cluster up and running for a couple weeks now, so 
I'm definitely still learning a lot.

On Monday, January 18, 2021 at 9:11:36 PM UTC-6 vince wrote:

> Your underlying issue is that you used a k8s image based on alpine and 
> python3-slim, so it's minimal and doesn't have the build requirements for 
> doing the pip install of Pillow.   That should be somewhat expected.   
> Unfortunately that's part and parcel of running minimal docker images.  I 
> suspect you might have gotten there a little easier if you just ran a 
> Debian-based base image (since there is already a package for PIL/Pillow 
> you could simply add), but I suspect it would be a much larger Docker image 
> result for your cluster.
>
> Unrelated question - what are you doing in k8s for persistent storage of 
> your archive and public_html trees, as well as for logging ?
>
> On Monday, January 18, 2021 at 6:47:51 PM UTC-8 cql...@gmail.com wrote:
>
>> After spending time in the Pillow github issues, I ended up getting this 
>> working by installing several packages:
>>
>>
>>
>> *RUN apt-get install zlib1g-dev libjpeg-dev build-essential -yRUN python 
>> -m pip install Pillow*
>>
>> This allows me to install pillow, have it recognized by python, and 
>> therefore build my belchertown frontend!
>> On Monday, January 18, 2021 at 4:56:42 AM UTC-6 cql...@gmail.com wrote:
>>
>>> Good point. Here are the startup logs  - 
>>> looks like it is running the python version I was expecting: 3.9.0. (Makes 
>>> sense since the base docker image is a python 3 base image)
>>>
>>> On Sunday, January 17, 2021 at 10:37:08 PM UTC-6 gjr80 wrote:
>>>
 Appreciate you have installed PIL under python3 but are you sure that 
 WeeWX is being run under python3 and not python2? I see nothing in what 
 you 
 have posted that confirms this one way or another. The python version is 
 logged when starting WeeWX. What does the log say when you start WeeWX?

 Gary

 On Monday, 18 January 2021 at 14:14:24 UTC+10 cql...@gmail.com wrote:

> Hey all,
> I've recently begun the process of migrating my existing weewx install 
> to my
> kubernetes cluster, using this base docker image 
> 
> I'm still getting used to the setup, but it seems to be pulling data 
> from my
> weather station and populating my sqlite db. However, I'm running into 
> problems
> generating images due to a ModuleNotFoundError. Below, take a look at 
> some of
> the results of my troubleshooting.
>
>
>- Here's my setup:
>
> root@weewx-84bfc8b796-gwrr7:/home/weewx# python --version
> Python 3.9.0
> root@weewx-84bfc8b796-gwrr7:/home/weewx# pip --version
> pip 20.2.3 from /opt/venv/lib/python3.9/site-packages/pip (python 3.9)
> root@weewx-84bfc8b796-gwrr7:/home/weewx# cat version.txt
> __version__ = "4.1.1"
>
>- Here's my weewx logs showing the ModuleNotFoundError 
>
>- I found a previous thread 
>discussing 
>this issue, but it didn't seem to describe successful workarounds. 
>- Here's the output from working through that thread 
>   
>- Looking at this issue outside the context of weewx, it seemed 
>reasonable to try to install pillow via pip, but doing so resulted in 
> this 
>long, ugly error 
>
> Wondering if anybody has navigated this issue before. Thanks!
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/ba7ac860-d3f7-4fd6-9092-aa8c46602debn%40googlegroups.com.

[weewx-user] Re: 4.1.1 - No module named 'Image'

[vince]

Your underlying issue is that you used a k8s image based on alpine and 
python3-slim, so it's minimal and doesn't have the build requirements for 
doing the pip install of Pillow.   That should be somewhat expected.   
Unfortunately that's part and parcel of running minimal docker images.  I 
suspect you might have gotten there a little easier if you just ran a 
Debian-based base image (since there is already a package for PIL/Pillow 
you could simply add), but I suspect it would be a much larger Docker image 
result for your cluster.

Unrelated question - what are you doing in k8s for persistent storage of 
your archive and public_html trees, as well as for logging ?

On Monday, January 18, 2021 at 6:47:51 PM UTC-8 cql...@gmail.com wrote:

> After spending time in the Pillow github issues, I ended up getting this 
> working by installing several packages:
>
>
>
> *RUN apt-get install zlib1g-dev libjpeg-dev build-essential -yRUN python 
> -m pip install Pillow*
>
> This allows me to install pillow, have it recognized by python, and 
> therefore build my belchertown frontend!
> On Monday, January 18, 2021 at 4:56:42 AM UTC-6 cql...@gmail.com wrote:
>
>> Good point. Here are the startup logs  - 
>> looks like it is running the python version I was expecting: 3.9.0. (Makes 
>> sense since the base docker image is a python 3 base image)
>>
>> On Sunday, January 17, 2021 at 10:37:08 PM UTC-6 gjr80 wrote:
>>
>>> Appreciate you have installed PIL under python3 but are you sure that 
>>> WeeWX is being run under python3 and not python2? I see nothing in what you 
>>> have posted that confirms this one way or another. The python version is 
>>> logged when starting WeeWX. What does the log say when you start WeeWX?
>>>
>>> Gary
>>>
>>> On Monday, 18 January 2021 at 14:14:24 UTC+10 cql...@gmail.com wrote:
>>>
 Hey all,
 I've recently begun the process of migrating my existing weewx install 
 to my
 kubernetes cluster, using this base docker image 
 
 I'm still getting used to the setup, but it seems to be pulling data 
 from my
 weather station and populating my sqlite db. However, I'm running into 
 problems
 generating images due to a ModuleNotFoundError. Below, take a look at 
 some of
 the results of my troubleshooting.


- Here's my setup:

 root@weewx-84bfc8b796-gwrr7:/home/weewx# python --version
 Python 3.9.0
 root@weewx-84bfc8b796-gwrr7:/home/weewx# pip --version
 pip 20.2.3 from /opt/venv/lib/python3.9/site-packages/pip (python 3.9)
 root@weewx-84bfc8b796-gwrr7:/home/weewx# cat version.txt
 __version__ = "4.1.1"

- Here's my weewx logs showing the ModuleNotFoundError 

- I found a previous thread 
discussing 
this issue, but it didn't seem to describe successful workarounds. 
- Here's the output from working through that thread 
   
- Looking at this issue outside the context of weewx, it seemed 
reasonable to try to install pillow via pip, but doing so resulted in 
 this 
long, ugly error 

 Wondering if anybody has navigated this issue before. Thanks!




-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/70173afb-5c5e-4209-91f2-41ab129fe119n%40googlegroups.com.

[weewx-user] Re: Multiple Weather Stations w/Fedora

[vince]

On Monday, January 18, 2021 at 5:11:03 PM UTC-8 Matt R wrote:

> Hi all, wondering if anyone has been able to get multiple weather stations 
> running using a RedHat based distro (CentOS, Fedora, etc)?
>
>
I'd say "some assembly required" for RH-based distros.

The weewx-multi script that comes under util/init.d in the .tgz file is 
Debian-specific and wouldn't work on a RH-based system.   That said, if you 
diffed the weewx.debian and weewx-multi scripts there, you would see the 
additions made to support running multiple instances.   You'd need to do 
similar modifications to do a "weewx-multi.redhat" (so to speak) similarly 
modified init script.

Definitely doable but you'd have to do the doing part.   I'm sure 
Tom+Matthew would love a pull request with a working init file for RH that 
supports multi.

-- 
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/21670126-141b-44b0-b8ea-1a40b2ab8209n%40googlegroups.com.

[weewx-user] Re: 4.1.1 - No module named 'Image'

[cql...@gmail.com]

After spending time in the Pillow github issues, I ended up getting this 
working by installing several packages:



*RUN apt-get install zlib1g-dev libjpeg-dev build-essential -yRUN python -m 
pip install Pillow*

This allows me to install pillow, have it recognized by python, and 
therefore build my belchertown frontend!
On Monday, January 18, 2021 at 4:56:42 AM UTC-6 cql...@gmail.com wrote:

> Good point. Here are the startup logs  - 
> looks like it is running the python version I was expecting: 3.9.0. (Makes 
> sense since the base docker image is a python 3 base image)
>
> On Sunday, January 17, 2021 at 10:37:08 PM UTC-6 gjr80 wrote:
>
>> Appreciate you have installed PIL under python3 but are you sure that 
>> WeeWX is being run under python3 and not python2? I see nothing in what you 
>> have posted that confirms this one way or another. The python version is 
>> logged when starting WeeWX. What does the log say when you start WeeWX?
>>
>> Gary
>>
>> On Monday, 18 January 2021 at 14:14:24 UTC+10 cql...@gmail.com wrote:
>>
>>> Hey all,
>>> I've recently begun the process of migrating my existing weewx install 
>>> to my
>>> kubernetes cluster, using this base docker image 
>>> 
>>> I'm still getting used to the setup, but it seems to be pulling data 
>>> from my
>>> weather station and populating my sqlite db. However, I'm running into 
>>> problems
>>> generating images due to a ModuleNotFoundError. Below, take a look at 
>>> some of
>>> the results of my troubleshooting.
>>>
>>>
>>>- Here's my setup:
>>>
>>> root@weewx-84bfc8b796-gwrr7:/home/weewx# python --version
>>> Python 3.9.0
>>> root@weewx-84bfc8b796-gwrr7:/home/weewx# pip --version
>>> pip 20.2.3 from /opt/venv/lib/python3.9/site-packages/pip (python 3.9)
>>> root@weewx-84bfc8b796-gwrr7:/home/weewx# cat version.txt
>>> __version__ = "4.1.1"
>>>
>>>- Here's my weewx logs showing the ModuleNotFoundError 
>>>
>>>- I found a previous thread 
>>>discussing 
>>>this issue, but it didn't seem to describe successful workarounds. 
>>>- Here's the output from working through that thread 
>>>   
>>>- Looking at this issue outside the context of weewx, it seemed 
>>>reasonable to try to install pillow via pip, but doing so resulted in 
>>> this 
>>>long, ugly error 
>>>
>>> Wondering if anybody has navigated this issue before. Thanks!
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/bb65b999-dca2-47a6-bd90-77e43e1c777an%40googlegroups.com.

[weewx-user] Database Backup File not a Database Error

[Kevin Chapman]

Hello,
I recently experienced a crash of weewx version 4.2.0.  I am still on the 
default Sqlite database.  I have been backing it up nightly since around 
November of last year.  Noob mistake is that I assumed the database file 
backups were good.  

My backup routine consisted of stopping weewx, taking a copy of the sdb 
file and gzipping it to a NAS archive.  Then starting the weewx system.  

Now when I try to copy the unpacked sdb and pick up where I left off I get 
a message that the file is not a database.  I have tried a couple of 
archives from Dec and Jan.  All seem to be no good.  I did notice that when 
I reinstalled weewx it is now version 4.3.0.  Could I be dealing with a 
system version mismatch in the file or is there something wrong with my 
backup process.  


-- 
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/3d88da27-9fa2-43e8-82fa-825cf692cfe7n%40googlegroups.com.

Re: [weewx-user] Re: Rain Rate Calc Problem?

[Neville Davis]

Hi using 
SELECT  dateTime,rain,rainRate
FROMarchive
WHERE   rain>0 order by dateTime desc limit 200;

the last 200 records for rain

On Tuesday, January 19, 2021 at 12:31:55 PM UTC+10 Neville Davis wrote:

> Hi
>
> Using sequel pro
>
> SELECT  dateTime,rain,rainRate
> FROMarchive
> WHERE   rainRate>0 order by dateTime desc limit 50;
>
> On Tuesday, January 19, 2021 at 11:55:55 AM UTC+10 Neville Davis wrote:
>
>> Hi
>> installed sqlite3 but when run I get nothing printed. the same query with 
>> rain I also get nothing printed, it just returns to sqlite3 prompt.
>> Nothing on console, user logs etc
>>
>> I am going to try the same query to see if I can get the data using 
>> Sequel Pro. I use this app to check my db usually.
>> I mention rainrate because that is in the Groups in weewx.conf...I have 
>> not edited that part of the file, in any of my versions of 
>> weewx.conf...just looking for any possible anomaly.
>> Nev
>>
>> On Tuesday, January 19, 2021 at 10:05:43 AM UTC+10 tke...@gmail.com 
>> wrote:
>>
>>> Your weewx.conf seems to be configured correctly. And, it's definitely 
>>> "rainRate" (not "rainrate"). Let's take a look at the database, using the 
>>> tools sqlite3. 
>>>
>>> You may have to install it:
>>>
>>> *sudo apt install sqlite3*
>>>
>>> *sqlite3 /home/weewx/archive/weewx.sdb*
>>> sqlite> *select 
>>> dateTime,datetime(dateTime,'unixepoch','localtime'),rain,rainRate from 
>>> archive where rainRate>0 order by dateTime desc limit 50;*
>>> sqlite> *.quit*
>>>
>>> This will print the last 50 non-zero rainRates. 
>>>
>>> -tk
>>>
>>>
>>> On Mon, Jan 18, 2021 at 3:39 PM Neville Davis  
>>> wrote:
>>>
 Hi I have the same problem...
 We have long periods without rain then it buckets down so I have only 
 recently started to notice it is always zero.
 I upgraded to 4.3 this month and had a reading of 2mm per hour after a 
 rain period...and thought the upgrade had fixed it. Then last evening a 
 large downpour approx 30mm in about 1 hour...rainRate = 0.0 mm per hour.
 I have checked [StdWXCalculate] and rainRate was prefer hardware ( mine 
 is a home brewed system, raspberry Pi with i2C sensors, without rainRate) 
 I 
 changed it to software calculation. Still zero.
 I then noticed this last post, but my groups have it at mm per hour... 
 I have noticed that the group has rainrate not rainRate, I checked some 
 old 
 weewx.confs back to may last year they are also rainrate??
 I started weewx directly and a copy of the consul log is attachedat 
 the beginning I also looked at old weewx.confs to see if I had made any 
 stuff ups...so this info is also in the console log.
 I also looked back into mySql db and this zero rainRate has been there 
 for sometime..except for this one time 2.0mm per hour. 
 If I set debug in weewx.conf what extra data will it show??
 Any suggestions...??

 Groups
 
 group_altitude = meter# Options are 'foot' or 
 'meter'
 group_degree_day = degree_C_day# Options are 
 'degree_F_day' or 'degree_C_day'
 group_distance = km# Options are 'mile' or 'km'
 group_pressure = hPa# Options are 'inHg', 'mmHg', 
 'mbar', or 'hPa'
 group_rain = mm# Options are 'inch', 'cm', or 'mm'
 group_rainrate = mm_per_hour# Options are 
 'inch_per_hour', 'cm_per_hour', or 'mm_per_hour'
 group_speed = km_per_hour# Options are 
 'mile_per_hour', 'km_per_hour', 'knot', or 'meter_per_second'
 group_speed2 = km_per_hour2# Options are 
 'mile_per_hour2', 'km_per_hour2', 'knot2', or 'meter_per_second2'
 group_temperature = degree_C# Options are 
 'degree_F' or 'degree_C'
 group_direction = degree_compass
 group_moisture = centibar
 group_percent = percent
 group_radiation = watt_per_meter_squared
 group_uv = uv_index
 group_volt = volt
 group_rpm = rpm

 [StdWXCalculate]
 
 [[Calculations]]
 # How to calculate derived quantities.  Possible values are:
 #  hardware- use the value provided by hardware
 #  software- use the value calculated by weewx
 #  prefer_hardware - use value provide by hardware if available,
 #  otherwise use value calculated by weewx
 
 pressure = prefer_hardware
 altimeter = prefer_hardware
 appTemp = prefer_hardware
 barometer = prefer_hardware
 beaufort = prefer_hardware
 cloudbase = prefer_hardware
 dewpoint = prefer_hardware
 ET = 

Re: [weewx-user] Re: Rain Rate Calc Problem?

[Neville Davis]

Hi

Using sequel pro

SELECT  dateTime,rain,rainRate
FROMarchive
WHERE   rainRate>0 order by dateTime desc limit 50;

On Tuesday, January 19, 2021 at 11:55:55 AM UTC+10 Neville Davis wrote:

> Hi
> installed sqlite3 but when run I get nothing printed. the same query with 
> rain I also get nothing printed, it just returns to sqlite3 prompt.
> Nothing on console, user logs etc
>
> I am going to try the same query to see if I can get the data using Sequel 
> Pro. I use this app to check my db usually.
> I mention rainrate because that is in the Groups in weewx.conf...I have 
> not edited that part of the file, in any of my versions of 
> weewx.conf...just looking for any possible anomaly.
> Nev
>
> On Tuesday, January 19, 2021 at 10:05:43 AM UTC+10 tke...@gmail.com wrote:
>
>> Your weewx.conf seems to be configured correctly. And, it's definitely 
>> "rainRate" (not "rainrate"). Let's take a look at the database, using the 
>> tools sqlite3. 
>>
>> You may have to install it:
>>
>> *sudo apt install sqlite3*
>>
>> *sqlite3 /home/weewx/archive/weewx.sdb*
>> sqlite> *select 
>> dateTime,datetime(dateTime,'unixepoch','localtime'),rain,rainRate from 
>> archive where rainRate>0 order by dateTime desc limit 50;*
>> sqlite> *.quit*
>>
>> This will print the last 50 non-zero rainRates. 
>>
>> -tk
>>
>>
>> On Mon, Jan 18, 2021 at 3:39 PM Neville Davis  
>> wrote:
>>
>>> Hi I have the same problem...
>>> We have long periods without rain then it buckets down so I have only 
>>> recently started to notice it is always zero.
>>> I upgraded to 4.3 this month and had a reading of 2mm per hour after a 
>>> rain period...and thought the upgrade had fixed it. Then last evening a 
>>> large downpour approx 30mm in about 1 hour...rainRate = 0.0 mm per hour.
>>> I have checked [StdWXCalculate] and rainRate was prefer hardware ( mine 
>>> is a home brewed system, raspberry Pi with i2C sensors, without rainRate) I 
>>> changed it to software calculation. Still zero.
>>> I then noticed this last post, but my groups have it at mm per hour... I 
>>> have noticed that the group has rainrate not rainRate, I checked some old 
>>> weewx.confs back to may last year they are also rainrate??
>>> I started weewx directly and a copy of the consul log is attachedat 
>>> the beginning I also looked at old weewx.confs to see if I had made any 
>>> stuff ups...so this info is also in the console log.
>>> I also looked back into mySql db and this zero rainRate has been there 
>>> for sometime..except for this one time 2.0mm per hour. 
>>> If I set debug in weewx.conf what extra data will it show??
>>> Any suggestions...??
>>>
>>> Groups
>>> 
>>> group_altitude = meter# Options are 'foot' or 'meter'
>>> group_degree_day = degree_C_day# Options are 
>>> 'degree_F_day' or 'degree_C_day'
>>> group_distance = km# Options are 'mile' or 'km'
>>> group_pressure = hPa# Options are 'inHg', 'mmHg', 
>>> 'mbar', or 'hPa'
>>> group_rain = mm# Options are 'inch', 'cm', or 'mm'
>>> group_rainrate = mm_per_hour# Options are 
>>> 'inch_per_hour', 'cm_per_hour', or 'mm_per_hour'
>>> group_speed = km_per_hour# Options are 
>>> 'mile_per_hour', 'km_per_hour', 'knot', or 'meter_per_second'
>>> group_speed2 = km_per_hour2# Options are 
>>> 'mile_per_hour2', 'km_per_hour2', 'knot2', or 'meter_per_second2'
>>> group_temperature = degree_C# Options are 'degree_F' 
>>> or 'degree_C'
>>> group_direction = degree_compass
>>> group_moisture = centibar
>>> group_percent = percent
>>> group_radiation = watt_per_meter_squared
>>> group_uv = uv_index
>>> group_volt = volt
>>> group_rpm = rpm
>>>
>>> [StdWXCalculate]
>>> 
>>> [[Calculations]]
>>> # How to calculate derived quantities.  Possible values are:
>>> #  hardware- use the value provided by hardware
>>> #  software- use the value calculated by weewx
>>> #  prefer_hardware - use value provide by hardware if available,
>>> #  otherwise use value calculated by weewx
>>> 
>>> pressure = prefer_hardware
>>> altimeter = prefer_hardware
>>> appTemp = prefer_hardware
>>> barometer = prefer_hardware
>>> beaufort = prefer_hardware
>>> cloudbase = prefer_hardware
>>> dewpoint = prefer_hardware
>>> ET = prefer_hardware
>>> heatindex = prefer_hardware
>>> humidex = prefer_hardware
>>> inDewpoint = prefer_hardware
>>> maxSolarRad = prefer_hardware
>>> rainRate = software
>>> windchill = prefer_hardware
>>> windrun = prefer_hardware
>>>
>>> This was the first recording of a rainRate for a long 

Re: [weewx-user] Re: Rain Rate Calc Problem?

[Neville Davis]

Hi
installed sqlite3 but when run I get nothing printed. the same query with 
rain I also get nothing printed, it just returns to sqlite3 prompt.
Nothing on console, user logs etc

I am going to try the same query to see if I can get the data using Sequel 
Pro. I use this app to check my db usually.
I mention rainrate because that is in the Groups in weewx.conf...I have not 
edited that part of the file, in any of my versions of weewx.conf...just 
looking for any possible anomaly.
Nev

On Tuesday, January 19, 2021 at 10:05:43 AM UTC+10 tke...@gmail.com wrote:

> Your weewx.conf seems to be configured correctly. And, it's definitely 
> "rainRate" (not "rainrate"). Let's take a look at the database, using the 
> tools sqlite3. 
>
> You may have to install it:
>
> *sudo apt install sqlite3*
>
> *sqlite3 /home/weewx/archive/weewx.sdb*
> sqlite> *select 
> dateTime,datetime(dateTime,'unixepoch','localtime'),rain,rainRate from 
> archive where rainRate>0 order by dateTime desc limit 50;*
> sqlite> *.quit*
>
> This will print the last 50 non-zero rainRates. 
>
> -tk
>
>
> On Mon, Jan 18, 2021 at 3:39 PM Neville Davis  
> wrote:
>
>> Hi I have the same problem...
>> We have long periods without rain then it buckets down so I have only 
>> recently started to notice it is always zero.
>> I upgraded to 4.3 this month and had a reading of 2mm per hour after a 
>> rain period...and thought the upgrade had fixed it. Then last evening a 
>> large downpour approx 30mm in about 1 hour...rainRate = 0.0 mm per hour.
>> I have checked [StdWXCalculate] and rainRate was prefer hardware ( mine 
>> is a home brewed system, raspberry Pi with i2C sensors, without rainRate) I 
>> changed it to software calculation. Still zero.
>> I then noticed this last post, but my groups have it at mm per hour... I 
>> have noticed that the group has rainrate not rainRate, I checked some old 
>> weewx.confs back to may last year they are also rainrate??
>> I started weewx directly and a copy of the consul log is attachedat 
>> the beginning I also looked at old weewx.confs to see if I had made any 
>> stuff ups...so this info is also in the console log.
>> I also looked back into mySql db and this zero rainRate has been there 
>> for sometime..except for this one time 2.0mm per hour. 
>> If I set debug in weewx.conf what extra data will it show??
>> Any suggestions...??
>>
>> Groups
>> 
>> group_altitude = meter# Options are 'foot' or 'meter'
>> group_degree_day = degree_C_day# Options are 
>> 'degree_F_day' or 'degree_C_day'
>> group_distance = km# Options are 'mile' or 'km'
>> group_pressure = hPa# Options are 'inHg', 'mmHg', 
>> 'mbar', or 'hPa'
>> group_rain = mm# Options are 'inch', 'cm', or 'mm'
>> group_rainrate = mm_per_hour# Options are 
>> 'inch_per_hour', 'cm_per_hour', or 'mm_per_hour'
>> group_speed = km_per_hour# Options are 
>> 'mile_per_hour', 'km_per_hour', 'knot', or 'meter_per_second'
>> group_speed2 = km_per_hour2# Options are 
>> 'mile_per_hour2', 'km_per_hour2', 'knot2', or 'meter_per_second2'
>> group_temperature = degree_C# Options are 'degree_F' 
>> or 'degree_C'
>> group_direction = degree_compass
>> group_moisture = centibar
>> group_percent = percent
>> group_radiation = watt_per_meter_squared
>> group_uv = uv_index
>> group_volt = volt
>> group_rpm = rpm
>>
>> [StdWXCalculate]
>> 
>> [[Calculations]]
>> # How to calculate derived quantities.  Possible values are:
>> #  hardware- use the value provided by hardware
>> #  software- use the value calculated by weewx
>> #  prefer_hardware - use value provide by hardware if available,
>> #  otherwise use value calculated by weewx
>> 
>> pressure = prefer_hardware
>> altimeter = prefer_hardware
>> appTemp = prefer_hardware
>> barometer = prefer_hardware
>> beaufort = prefer_hardware
>> cloudbase = prefer_hardware
>> dewpoint = prefer_hardware
>> ET = prefer_hardware
>> heatindex = prefer_hardware
>> humidex = prefer_hardware
>> inDewpoint = prefer_hardware
>> maxSolarRad = prefer_hardware
>> rainRate = software
>> windchill = prefer_hardware
>> windrun = prefer_hardware
>>
>> This was the first recording of a rainRate for a long timebut only 
>> once right after upgrade to 4.3.
>> [image: Screen Shot 2021-01-19 at 9.06.21 am.png]
>>
>> On Monday, January 18, 2021 at 8:10:01 AM UTC+10 bana...@gmail.com wrote:
>>
>>> It may be of interest to you that I had problems with the rain rate 
>>> being reported as 0.00 all the time.
>>> I 

Re: [weewx-user] Re: New internet provider - now ftp doesn't work

[Tom Keffer]

Well, that sucks. It works nicely on my end.

So, it must be something on your end. Perhaps your firewall, or some IPv6
issue, which I am totally unqualified to diagnose. The only thing I can
suggest is to try testing your connection to see if it is IPv6 ready:
https://test-ipv6.com/

Other than that, I'm out of ideas.

-tk

On Mon, Jan 18, 2021 at 5:24 PM Rich Strle  wrote:

> No joy
>
> I tried  reuse_ssl = True here:
>
> # To upload files from something other than what HTML_ROOT is set
> # to above, specify a different HTML_ROOT here.
> #HTML_ROOT = /var/www/html/weewx
>
> reuse_ssl = True
>
> # Most FTP servers use port 21
> port = 21
>
> # Set to 1 to use passive mode, zero for active mode
> passive = 1
>
> And closer to the bottom of the FTP section.
>
> Jan 17 23:50:27 pi-weather weewx[429] DEBUG weewx.reportengine: Found
> configuration file /etc/weewx/skins/Ftp/skin.conf for report 'FTP'
> Jan 17 23:50:28 pi-weather weewx[429] DEBUG weeutil.ftpupload: Attempting
> connection to www.cliffandbuster.com
> Jan 17 23:50:33 pi-weather weewx[429] DEBUG weeutil.ftpupload: Connected
> to www.cliffandbuster.com
> Jan 17 23:50:33 pi-weather weewx[429] ERROR weeutil.ftpupload: Failed
> uploading /var/www/html/weewx/yearradiation.png to server
> www.cliffandbuster.com. Reason: '229 Extended Passive Mode Entered
> (|||50223|)'
> Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
> ftpgenerator: (0): caught exception '': 229
> Extended Passive Mode Entered (|||50223|)
> Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
>    Traceback (most recent call last):
> Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
>  File "/usr/share/weewx/weewx/reportengine.py", line 331, in run
> Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
>    n = ftp_data.run()
> Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
>  File "/usr/share/weewx/weeutil/ftpupload.py", line 163, in run
> Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
>    ftp_server.storbinary(stor_cmd, fd)
> Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
>  File "/usr/lib/python3.7/ftplib.py", line 504, in storbinary
> Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
>    with self.transfercmd(cmd, rest) as conn:
> Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
>  File "/usr/lib/python3.7/ftplib.py", line 399, in transfercmd
>
>
> On Monday, January 18, 2021 at 5:46:12 PM UTC-6 tke...@gmail.com wrote:
>
>> [Rich sent me his credentials via a private email.]
>>
>> As soon as I tried FTP to Rich's server, I recognized the problem. The
>> server is using Pure-FTPd, which reuses SSL connections. The Python library
>> has a bug
>> 
>> that prevents this. WeeWX V4.1.0 and greater have a workaround for the bug.
>> To activate, add option reuse_ssl and set it to true.
>>
>> [[FTP]]
>> ...
>> reuse_ssl = True
>>
>> See if that helps.
>>
>> -tk
>>
>> On Mon, Jan 18, 2021 at 9:39 AM Rich Strle  wrote:
>>
>>> Status: Resolving address of www.cliffandbuster.com
>>> Status: Connecting to 107.180.51.77:21...
>>> Status: Connection established, waiting for welcome message...
>>> Status: Initializing TLS...
>>> Status: Verifying certificate...
>>> Status: TLS connection established.
>>> Status: Logged in
>>> Status: Retrieving directory listing of "/"...
>>> Status: Directory listing of "/" successful
>>> Status: Resolving address of www.cliffandbuster.com
>>> Status: Connecting to 107.180.51.77:21...
>>> Status: Connection established, waiting for welcome message...
>>> Status: Initializing TLS...
>>> Status: Verifying certificate...
>>> Status: TLS connection established.
>>> Status: Logged in
>>> Status: Starting upload of /var/www/html/weewx/image.jpg
>>> Status: File transfer successful, transferred 49,150 bytes in 1 second
>>> Status: Retrieving directory listing of "/"...
>>> Status: Directory listing of "/" successful
>>>
>>> I disconnected and reconnected. Does filezilla trust the site now so
>>> we're not seeing all of the connection comments?
>>>
>>> On Monday, January 18, 2021 at 10:37:24 AM UTC-6 tke...@gmail.com wrote:
>>>
 That's pretty much what I'm thinking, but I'm trying to get the
 evidence from Filezilla. It should say that as it negotiates with the
 server.

 FTP is 40 year old technology. It's amazing that there are still so
 many incompatible versions out there.

 On Mon, Jan 18, 2021 at 8:34 AM Les Niles  wrote:

> The server is responding to the PASV command by entering extended
> passive mode EPSV, which apparently is a legal response but which
> weewx/ftplib is not handling correctly. (I don’t have access to the 

Re: [weewx-user] Re: New internet provider - now ftp doesn't work

[Rich Strle]

No joy

I tried  reuse_ssl = True here:

# To upload files from something other than what HTML_ROOT is set
# to above, specify a different HTML_ROOT here.
#HTML_ROOT = /var/www/html/weewx

reuse_ssl = True

# Most FTP servers use port 21
port = 21

# Set to 1 to use passive mode, zero for active mode
passive = 1

And closer to the bottom of the FTP section.

Jan 17 23:50:27 pi-weather weewx[429] DEBUG weewx.reportengine: Found 
configuration file /etc/weewx/skins/Ftp/skin.conf for report 'FTP'
Jan 17 23:50:28 pi-weather weewx[429] DEBUG weeutil.ftpupload: Attempting 
connection to www.cliffandbuster.com
Jan 17 23:50:33 pi-weather weewx[429] DEBUG weeutil.ftpupload: Connected to 
www.cliffandbuster.com
Jan 17 23:50:33 pi-weather weewx[429] ERROR weeutil.ftpupload: Failed 
uploading /var/www/html/weewx/yearradiation.png to server 
www.cliffandbuster.com. Reason: '229 Extended Passive Mode Entered 
(|||50223|)'
Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine: 
ftpgenerator: (0): caught exception '': 229 
Extended Passive Mode Entered (|||50223|)
Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
   Traceback (most recent call last):
Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
 File "/usr/share/weewx/weewx/reportengine.py", line 331, in run
Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
   n = ftp_data.run()
Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
 File "/usr/share/weewx/weeutil/ftpupload.py", line 163, in run
Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
   ftp_server.storbinary(stor_cmd, fd)
Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
 File "/usr/lib/python3.7/ftplib.py", line 504, in storbinary
Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
   with self.transfercmd(cmd, rest) as conn:
Jan 17 23:50:33 pi-weather weewx[429] ERROR weewx.reportengine:
 File "/usr/lib/python3.7/ftplib.py", line 399, in transfercmd


On Monday, January 18, 2021 at 5:46:12 PM UTC-6 tke...@gmail.com wrote:

> [Rich sent me his credentials via a private email.]
>
> As soon as I tried FTP to Rich's server, I recognized the problem. The 
> server is using Pure-FTPd, which reuses SSL connections. The Python library 
> has a bug 
> 
>  
> that prevents this. WeeWX V4.1.0 and greater have a workaround for the bug. 
> To activate, add option reuse_ssl and set it to true.
>
> [[FTP]]
> ...
> reuse_ssl = True
>
> See if that helps.
>
> -tk
>
> On Mon, Jan 18, 2021 at 9:39 AM Rich Strle  wrote:
>
>> Status: Resolving address of www.cliffandbuster.com
>> Status: Connecting to 107.180.51.77:21...
>> Status: Connection established, waiting for welcome message...
>> Status: Initializing TLS...
>> Status: Verifying certificate...
>> Status: TLS connection established.
>> Status: Logged in
>> Status: Retrieving directory listing of "/"...
>> Status: Directory listing of "/" successful
>> Status: Resolving address of www.cliffandbuster.com
>> Status: Connecting to 107.180.51.77:21...
>> Status: Connection established, waiting for welcome message...
>> Status: Initializing TLS...
>> Status: Verifying certificate...
>> Status: TLS connection established.
>> Status: Logged in
>> Status: Starting upload of /var/www/html/weewx/image.jpg
>> Status: File transfer successful, transferred 49,150 bytes in 1 second
>> Status: Retrieving directory listing of "/"...
>> Status: Directory listing of "/" successful
>>
>> I disconnected and reconnected. Does filezilla trust the site now so 
>> we're not seeing all of the connection comments?
>>
>> On Monday, January 18, 2021 at 10:37:24 AM UTC-6 tke...@gmail.com wrote:
>>
>>> That's pretty much what I'm thinking, but I'm trying to get the evidence 
>>> from Filezilla. It should say that as it negotiates with the server. 
>>>
>>> FTP is 40 year old technology. It's amazing that there are still so many 
>>> incompatible versions out there.
>>>
>>> On Mon, Jan 18, 2021 at 8:34 AM Les Niles  wrote:
>>>
 The server is responding to the PASV command by entering extended 
 passive mode EPSV, which apparently is a legal response but which 
 weewx/ftplib is not handling correctly. (I don’t have access to the code 
 right now so can’t be more precise about where to fix.) The difference is 
 that in EPSV mode the server doesn’t return an IP, just a port number. 
 (The 
 line “host, port = self.makepasv()” is not going to work.) 

 Apparently passive mode has been the default for ftplib since python 
 2.1, so maybe just skip trying to change to PASV entirely?

   -Les


 On Jan 18, 2021, at 7:21 AM, Rich 

[weewx-user] Multiple Weather Stations w/Fedora

[Matt R]

Hi all, wondering if anyone has been able to get multiple weather stations 
running using a RedHat based distro (CentOS, Fedora, etc)?

I've been able to successfully run multiple with a Debian distro leveraging 
Matthew Wall's weewx-multi script here:  
https://github.com/weewx/weewx/wiki/weewx-multi.

I've been working my way through making adjustments as necessary.  However, 
before I get too far down the rabbit hole I thought I'd check to see if 
anyone has come out the other side with a working script or knows this'd be 
a dead end endeavor.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/e0ef6e9d-fb8d-4e69-9425-b8007598055fn%40googlegroups.com.

Re: [weewx-user] Re: Rain Rate Calc Problem?

[Tom Keffer]

Your weewx.conf seems to be configured correctly. And, it's definitely
"rainRate" (not "rainrate"). Let's take a look at the database, using the
tools sqlite3.

You may have to install it:

*sudo apt install sqlite3*

*sqlite3 /home/weewx/archive/weewx.sdb*
sqlite> *select
dateTime,datetime(dateTime,'unixepoch','localtime'),rain,rainRate from
archive where rainRate>0 order by dateTime desc limit 50;*
sqlite> *.quit*

This will print the last 50 non-zero rainRates.

-tk


On Mon, Jan 18, 2021 at 3:39 PM Neville Davis 
wrote:

> Hi I have the same problem...
> We have long periods without rain then it buckets down so I have only
> recently started to notice it is always zero.
> I upgraded to 4.3 this month and had a reading of 2mm per hour after a
> rain period...and thought the upgrade had fixed it. Then last evening a
> large downpour approx 30mm in about 1 hour...rainRate = 0.0 mm per hour.
> I have checked [StdWXCalculate] and rainRate was prefer hardware ( mine is
> a home brewed system, raspberry Pi with i2C sensors, without rainRate) I
> changed it to software calculation. Still zero.
> I then noticed this last post, but my groups have it at mm per hour... I
> have noticed that the group has rainrate not rainRate, I checked some old
> weewx.confs back to may last year they are also rainrate??
> I started weewx directly and a copy of the consul log is attachedat
> the beginning I also looked at old weewx.confs to see if I had made any
> stuff ups...so this info is also in the console log.
> I also looked back into mySql db and this zero rainRate has been there for
> sometime..except for this one time 2.0mm per hour.
> If I set debug in weewx.conf what extra data will it show??
> Any suggestions...??
>
> Groups
>
> group_altitude = meter# Options are 'foot' or 'meter'
> group_degree_day = degree_C_day# Options are
> 'degree_F_day' or 'degree_C_day'
> group_distance = km# Options are 'mile' or 'km'
> group_pressure = hPa# Options are 'inHg', 'mmHg',
> 'mbar', or 'hPa'
> group_rain = mm# Options are 'inch', 'cm', or 'mm'
> group_rainrate = mm_per_hour# Options are
> 'inch_per_hour', 'cm_per_hour', or 'mm_per_hour'
> group_speed = km_per_hour# Options are
> 'mile_per_hour', 'km_per_hour', 'knot', or 'meter_per_second'
> group_speed2 = km_per_hour2# Options are
> 'mile_per_hour2', 'km_per_hour2', 'knot2', or 'meter_per_second2'
> group_temperature = degree_C# Options are 'degree_F'
> or 'degree_C'
> group_direction = degree_compass
> group_moisture = centibar
> group_percent = percent
> group_radiation = watt_per_meter_squared
> group_uv = uv_index
> group_volt = volt
> group_rpm = rpm
>
> [StdWXCalculate]
>
> [[Calculations]]
> # How to calculate derived quantities.  Possible values are:
> #  hardware- use the value provided by hardware
> #  software- use the value calculated by weewx
> #  prefer_hardware - use value provide by hardware if available,
> #  otherwise use value calculated by weewx
>
> pressure = prefer_hardware
> altimeter = prefer_hardware
> appTemp = prefer_hardware
> barometer = prefer_hardware
> beaufort = prefer_hardware
> cloudbase = prefer_hardware
> dewpoint = prefer_hardware
> ET = prefer_hardware
> heatindex = prefer_hardware
> humidex = prefer_hardware
> inDewpoint = prefer_hardware
> maxSolarRad = prefer_hardware
> rainRate = software
> windchill = prefer_hardware
> windrun = prefer_hardware
>
> This was the first recording of a rainRate for a long timebut only
> once right after upgrade to 4.3.
> [image: Screen Shot 2021-01-19 at 9.06.21 am.png]
>
> On Monday, January 18, 2021 at 8:10:01 AM UTC+10 bana...@gmail.com wrote:
>
>> It may be of interest to you that I had problems with the rain rate being
>> reported as 0.00 all the time.
>> I eventually tracked this down to the weewx.conf file having cm/hr rather
>> than mm/hr as the measurement required. This was in the Units Group section
>> of Standard Report and Defaults lower down.
>>
>> On Saturday, 26 December 2020 at 02:02:22 UTC+13 jbel...@gmail.com wrote:
>>
>>> I do appreciate the guess, but I know they’re all using the stone conf
>>> file since there’s only one! :-)
>>>
>>> Sent from my iPhone
>>>
>>> On Dec 24, 2020, at 6:56 PM, Tom Keffer  wrote:
>>>
>>> 
>>>
>>> Hard to say without seeing the log, but if I had to hazard a guess, I'd
>>> say you're not consistently using the same copy of weewx.conf for all runs.
>>> One of the copies does not have rainRate in [StdWXCalculate].
>>>
>>> But, that's just a 

Re: [weewx-user] Re: New internet provider - now ftp doesn't work

[Tom Keffer]

[Rich sent me his credentials via a private email.]

As soon as I tried FTP to Rich's server, I recognized the problem. The
server is using Pure-FTPd, which reuses SSL connections. The Python library
has a bug

that prevents this. WeeWX V4.1.0 and greater have a workaround for the bug.
To activate, add option reuse_ssl and set it to true.

[[FTP]]
...
reuse_ssl = True

See if that helps.

-tk

On Mon, Jan 18, 2021 at 9:39 AM Rich Strle  wrote:

> Status: Resolving address of www.cliffandbuster.com
> Status: Connecting to 107.180.51.77:21...
> Status: Connection established, waiting for welcome message...
> Status: Initializing TLS...
> Status: Verifying certificate...
> Status: TLS connection established.
> Status: Logged in
> Status: Retrieving directory listing of "/"...
> Status: Directory listing of "/" successful
> Status: Resolving address of www.cliffandbuster.com
> Status: Connecting to 107.180.51.77:21...
> Status: Connection established, waiting for welcome message...
> Status: Initializing TLS...
> Status: Verifying certificate...
> Status: TLS connection established.
> Status: Logged in
> Status: Starting upload of /var/www/html/weewx/image.jpg
> Status: File transfer successful, transferred 49,150 bytes in 1 second
> Status: Retrieving directory listing of "/"...
> Status: Directory listing of "/" successful
>
> I disconnected and reconnected. Does filezilla trust the site now so we're
> not seeing all of the connection comments?
>
> On Monday, January 18, 2021 at 10:37:24 AM UTC-6 tke...@gmail.com wrote:
>
>> That's pretty much what I'm thinking, but I'm trying to get the evidence
>> from Filezilla. It should say that as it negotiates with the server.
>>
>> FTP is 40 year old technology. It's amazing that there are still so many
>> incompatible versions out there.
>>
>> On Mon, Jan 18, 2021 at 8:34 AM Les Niles  wrote:
>>
>>> The server is responding to the PASV command by entering extended
>>> passive mode EPSV, which apparently is a legal response but which
>>> weewx/ftplib is not handling correctly. (I don’t have access to the code
>>> right now so can’t be more precise about where to fix.) The difference is
>>> that in EPSV mode the server doesn’t return an IP, just a port number. (The
>>> line “host, port = self.makepasv()” is not going to work.)
>>>
>>> Apparently passive mode has been the default for ftplib since python
>>> 2.1, so maybe just skip trying to change to PASV entirely?
>>>
>>>   -Les
>>>
>>>
>>> On Jan 18, 2021, at 7:21 AM, Rich Strle  wrote:
>>>
>>> 
>>> Command: TYPE I
>>> Trace: CFtpControlSocket::OnReceive()
>>> Response: 200 TYPE is now 8-bit binary
>>> Trace: CFtpRawTransferOpData::ParseResponse() in state 1
>>> Trace: CControlSocket::SendNextCommand()
>>> Trace: CFtpRawTransferOpData::Send() in state 2
>>> Command: PASV
>>> Trace: CFtpControlSocket::OnReceive()
>>> Response: 200 TYPE is now 8-bit binary
>>> Trace: CFtpRawTransferOpData::ParseResponse() in state 1
>>> Trace: CControlSocket::SendNextCommand()
>>> Trace: CFtpRawTransferOpData::Send() in state 2
>>> Command: PASV
>>> Trace: CFtpControlSocket::OnReceive()
>>> Response: 227 Entering Passive Mode (107,180,51,77,196,142)
>>> Trace: CFtpRawTransferOpData::ParseResponse() in state 2
>>> Trace: CControlSocket::SendNextCommand()
>>> Trace: CFtpRawTransferOpData::Send() in state 4
>>> Trace: Binding data connection source IP to control connection source
>>> IP 192.168.12.117
>>> Command: STOR yearbarometer.png
>>> Trace: CTransferSocket::OnConnect
>>> Trace: CTlsSocketImpl::Handshake()
>>> Trace: Trying to resume existing TLS session.
>>> Trace: CTlsSocketImpl::ContinueHandshake()
>>> Trace: CFtpControlSocket::OnReceive()
>>> Response: 227 Entering Passive Mode (107,180,51,77,197,217)
>>> Trace: CFtpRawTransferOpData::ParseResponse() in state 2
>>> Trace: CControlSocket::SendNextCommand()
>>> Trace: CFtpRawTransferOpData::Send() in state 4
>>> Trace: Binding data connection source IP to control connection source
>>> IP 192.168.12.117
>>> Command: STOR yearhilow.png
>>>
>>> On Monday, January 18, 2021 at 7:16:26 AM UTC-6 tke...@gmail.com wrote:
>>>
 Good to hear that Filezilla is working. We can use it to understand
 what the server is doing.

 Using Filezilla, go into its "Settings" (under the "Edit" menu). Then
 the "Debug" tab. There's a drop down list of message levels. Default is "0
 - None". Set it to "3- Verbose". Then click "OK".

 [image: image.png]

 Then use Filezilla again to transfer some files. This time, watch the
 window at top that tells you what Filezilla is doing. See if the client
 (Filezilla, in this case) is negotiating with the server. Tell us what you
 see, or, better, copy and paste it into a post.



 On Sun, Jan 17, 2021 at 7:33 PM Rich Strle  wrote:

> Jan 17 21:30:44 

[weewx-user] Re: GW1000 driver v0.2.0 release

[Paul Ward]

I've just got my WH45 and its working great with new driver thanks Gary. 
I've noticed that the CO2 internal temp & humidity are coming through as 
the curiously named "extraTemp17" and "extraHumid17" does that sound right? 
Also FYI at some point wiki sensor map page will need updating :-)

On Saturday, January 9, 2021 at 11:47:59 AM UTC gjr80 wrote:

> I have released v0.2.0 on GitHub 
> . 
>
> This main feature of this release is support for the WH45 Indoor CO2 PM2.5 
> PM10 Temperature and Humidity 5-in-1 Air Quality Sensor. If you have a WH45 
> sensor and it has been linked to your GW1000 v0.2.0 of the driver should 
> automatically pick up and emit the WH45 sensor data.
>
> v0.2.0 also sees changes in the naming of the 24 hour average particulate 
> concentration fields. Unfortunately this will mean anyone that is using 
> these fields will need to make one or more changes to their WeeWX 
> installation. I have outlined the changes and which users need to make 
> changes and how to make the necessary changes in a wiki article Changes 
> to 24 hour average particulate concentration field names 
> .
>  
> If you have a WH41, WH43 or WH45 sensor and use the 24 hour average 
> particulate concentration fields in any way I strongly suggest you 
> thoroughly read the linked wiki article.
>
> The majority of the other changes in v0.2.0 relate to running the driver 
> directly, in particular displaying the GW1000 and sensor configuration 
> information currently only available through the WS View app.
>
> Those that installed v0.1.0 via wee_extension can upgrade to v0.2.0 as 
> follows:
>
> $ wget -P /var/tmp 
> https://github.com/gjr80/weewx-gw1000/releases/download/v0.2.0/gw1000-0.2.0.tar.gz
> $ wee_extension --install=/var/tmp/gw1000-0.2.0.tar.gz
>
> Note: wee_extension may require the use of sudo the path to wee_extension 
> as applicable.
>
> Gary
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/6a98ac83-e73a-46b2-8154-44fcf565cc9fn%40googlegroups.com.

Re: [weewx-user] Errors in 4.3

[Tom Keffer]

If you're on buster, then it's simple enough to switch to Python 3.
Basically, just follow the directions in the Debian guide
:

wget -qO - https://weewx.com/apt/weewx-python3.list | sudo tee
/etc/apt/sources.list.d/weewx.list
sudo apt-get update
sudo apt-get install weewx



On Mon, Jan 18, 2021 at 9:33 AM Clay Jackson  wrote:

> Don't know WHERE I got Squeeze - just checked and confirmed; it's Buster,
> so would definitely like to at least try to get rid of python 2.
>
> On the rain = prefer_hardware, I looked at my old config files, and it
> seems it's "bounced" back and forth, probably depending on what version of
> sdr I had..   I honestly can't remember why.
>
> On Sunday, January 17, 2021 at 6:12:24 AM UTC-8 tke...@gmail.com wrote:
>
>> The type 'totalRain' has been in the code for a long time. What I'm
>> wondering about is where did the line
>>
>> rain = prefer_hardware
>>
>> come from.
>>
>> If you are still on squeeze, you're best off staying with Python 2. Not
>> all of the Python 3 pre-requisites are available through the repositories.
>>
>> -tk
>>
>> On Sat, Jan 16, 2021 at 8:31 PM Clay Jackson  wrote:
>>
>>> OK - thanks.  Had a bit of a scare when I corrupted my config file and
>>> NOTHING would start.   I commented rain and rainRate out of StdWXCaiculate
>>> and looks good now.  I AM getting an N/A in RanRate om the disp;lay, but
>>> that's OK for the time being.   Will check when we  next get rain to see
>>> what happens.
>>>
>>>  It would be nice to know where totalRain came from - I tried grep'ing
>>> for it in all the .py files and only found it in accum and units.  Before I
>>> posted, I actually commented those lines out and that did NOT work. Any
>>> thoughts on that?
>>>
>>> Also, I notice from the log I'm still using Python 2, which is what
>>> /usr/bin/python points to by default on squeeze, which is what I'm running
>>> right now.  Are there notes on how to force weewx to use python3?
>>>
>>> Thanks!
>>>
>>>
>>>
>>>
>>> On Sat, Jan 16, 2021 at 5:36 PM Tom Keffer  wrote:
>>>
 Try removing the line

 rain = prefer_hardware

 It's what's causing the StdWXCalculate service to try and calculate a
 value.

 I wonder where that line came from. I don't recall it ever being part
 of weewx.conf

 -tk

 On Sat, Jan 16, 2021 at 4:58 PM Clay Jackson 
 wrote:

> I'm using an Accurite 5n1 - this has been working since early 3.x;
> just stopped in 4.3,  I AM using my 4.2 config files and skins.
>
> [StdWXCalculate]
>
> [[Calculations]]
> # Derived quantities are calculated by this service. Possible
> values are:
> #  hardware- use the value provided by hardware
> #  software- use the value calculated by weewx
> #  prefer_hardware - use value provide by hardware if
> available,
> #  otherwise use value calculated by weewx
>
> pressure = prefer_hardware
> barometer = prefer_hardware
> altimeter = software
> windchill = software
> heatindex = software
> dewpoint = software
> inDewpoint = prefer_hardware
> rainRate = prefer_hardware
> rain = prefer_hardware
> ET = software
> maxSolarRad = prefer_hardware
> cloudbase = prefer_hardware
> humidex = prefer_hardware
> appTemp = prefer_hardware
> windrun = prefer_hardware
>
>
> On Sat, Jan 16, 2021 at 4:45 PM Tom Keffer  wrote:
>
>> Normally, the driver does it, but if asked, WeeWX can calculate
>> 'rain' from cumulative quantities such as totalRain, by taking a
>> difference.
>>
>> Your configuration file seems to be asking to do so, but totalRain is
>> not available. As for why it's asking, that's not clear.
>>
>> What does the section [StdWXCalculate] in your file weewx.conf look
>> like?
>>
>>
>> On Sat, Jan 16, 2021 at 4:17 PM Clay Jackson 
>> wrote:
>>
>>> I just upgraded (through apt update, using raspbian) to 4.3.0 and am
>>> seeing the following error.
>>> Jan 16 15:59:12 Weather weewx[17287] INFO __main__: PID file is
>>> /var/run/weewx.pid
>>> Jan 16 15:59:12 Weather weewx[17275]: Starting weewx weather system:
>>> weewx.
>>> Jan 16 15:59:12 Weather weewx[17291] INFO __main__: Using
>>> configuration file /etc/weewx/weewx.conf
>>> Jan 16 15:59:12 Weather weewx[17291] INFO __main__: Debug is 0
>>> Jan 16 15:59:12 Weather weewx[17291] INFO weewx.engine: Loading
>>> station type SDR (user.sdr)
>>> Jan 16 15:59:12 Weather weewx[17291] INFO user.sdr: driver version
>>> is 0.78
>>> Jan 16 15:59:12 Weather weewx[17291] INFO user.sdr: sensor map is
>>> {u'windDir': u'wind_dir.04C9.Acurite5n1PacketV2', u'windSpeed':

Re: [weewx-user] Re: New internet provider - now ftp doesn't work

[Rich Strle]

Status: Resolving address of www.cliffandbuster.com
Status: Connecting to 107.180.51.77:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing of "/"...
Status: Directory listing of "/" successful
Status: Resolving address of www.cliffandbuster.com
Status: Connecting to 107.180.51.77:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Starting upload of /var/www/html/weewx/image.jpg
Status: File transfer successful, transferred 49,150 bytes in 1 second
Status: Retrieving directory listing of "/"...
Status: Directory listing of "/" successful

I disconnected and reconnected. Does filezilla trust the site now so we're 
not seeing all of the connection comments?

On Monday, January 18, 2021 at 10:37:24 AM UTC-6 tke...@gmail.com wrote:

> That's pretty much what I'm thinking, but I'm trying to get the evidence 
> from Filezilla. It should say that as it negotiates with the server. 
>
> FTP is 40 year old technology. It's amazing that there are still so many 
> incompatible versions out there.
>
> On Mon, Jan 18, 2021 at 8:34 AM Les Niles  wrote:
>
>> The server is responding to the PASV command by entering extended passive 
>> mode EPSV, which apparently is a legal response but which weewx/ftplib is 
>> not handling correctly. (I don’t have access to the code right now so can’t 
>> be more precise about where to fix.) The difference is that in EPSV mode 
>> the server doesn’t return an IP, just a port number. (The line “host, port 
>> = self.makepasv()” is not going to work.) 
>>
>> Apparently passive mode has been the default for ftplib since python 2.1, 
>> so maybe just skip trying to change to PASV entirely?
>>
>>   -Les
>>
>>
>> On Jan 18, 2021, at 7:21 AM, Rich Strle  wrote:
>>
>> 
>> Command: TYPE I
>> Trace: CFtpControlSocket::OnReceive()
>> Response: 200 TYPE is now 8-bit binary
>> Trace: CFtpRawTransferOpData::ParseResponse() in state 1
>> Trace: CControlSocket::SendNextCommand()
>> Trace: CFtpRawTransferOpData::Send() in state 2
>> Command: PASV
>> Trace: CFtpControlSocket::OnReceive()
>> Response: 200 TYPE is now 8-bit binary
>> Trace: CFtpRawTransferOpData::ParseResponse() in state 1
>> Trace: CControlSocket::SendNextCommand()
>> Trace: CFtpRawTransferOpData::Send() in state 2
>> Command: PASV
>> Trace: CFtpControlSocket::OnReceive()
>> Response: 227 Entering Passive Mode (107,180,51,77,196,142)
>> Trace: CFtpRawTransferOpData::ParseResponse() in state 2
>> Trace: CControlSocket::SendNextCommand()
>> Trace: CFtpRawTransferOpData::Send() in state 4
>> Trace: Binding data connection source IP to control connection source IP 
>> 192.168.12.117
>> Command: STOR yearbarometer.png
>> Trace: CTransferSocket::OnConnect
>> Trace: CTlsSocketImpl::Handshake()
>> Trace: Trying to resume existing TLS session.
>> Trace: CTlsSocketImpl::ContinueHandshake()
>> Trace: CFtpControlSocket::OnReceive()
>> Response: 227 Entering Passive Mode (107,180,51,77,197,217)
>> Trace: CFtpRawTransferOpData::ParseResponse() in state 2
>> Trace: CControlSocket::SendNextCommand()
>> Trace: CFtpRawTransferOpData::Send() in state 4
>> Trace: Binding data connection source IP to control connection source IP 
>> 192.168.12.117
>> Command: STOR yearhilow.png
>>
>> On Monday, January 18, 2021 at 7:16:26 AM UTC-6 tke...@gmail.com wrote:
>>
>>> Good to hear that Filezilla is working. We can use it to understand what 
>>> the server is doing.
>>>
>>> Using Filezilla, go into its "Settings" (under the "Edit" menu). Then 
>>> the "Debug" tab. There's a drop down list of message levels. Default is "0 
>>> - None". Set it to "3- Verbose". Then click "OK".
>>>
>>> [image: image.png]
>>>
>>> Then use Filezilla again to transfer some files. This time, watch the 
>>> window at top that tells you what Filezilla is doing. See if the client 
>>> (Filezilla, in this case) is negotiating with the server. Tell us what you 
>>> see, or, better, copy and paste it into a post.
>>>
>>>
>>>
>>> On Sun, Jan 17, 2021 at 7:33 PM Rich Strle  wrote:
>>>
 Jan 17 21:30:44 pi-weather weewx[429] ERROR weeutil.ftpupload: Failed 
 uploading /var/www/html/weewx/yearradiation.png to server 
 www.cliffandbuster.com. Reason: '229 Extended Passive Mode Entered 
 (|||50458|)'
 Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
 ftpgenerator: (2): caught exception '': 229 
 Extended Passive Mode Entered (|||50458|)
 Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
    Traceback (most recent call last):
 Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
  File "/usr/share/weewx/weewx/reportengine.py", line 331, in run
 Jan 17 21:30:45 pi-weather weewx[429] 

Re: [weewx-user] Errors in 4.3

[Clay Jackson]

Don't know WHERE I got Squeeze - just checked and confirmed; it's Buster, 
so would definitely like to at least try to get rid of python 2.   

On the rain = prefer_hardware, I looked at my old config files, and it 
seems it's "bounced" back and forth, probably depending on what version of 
sdr I had..   I honestly can't remember why.

On Sunday, January 17, 2021 at 6:12:24 AM UTC-8 tke...@gmail.com wrote:

> The type 'totalRain' has been in the code for a long time. What I'm 
> wondering about is where did the line
>
> rain = prefer_hardware
>
> come from. 
>
> If you are still on squeeze, you're best off staying with Python 2. Not 
> all of the Python 3 pre-requisites are available through the repositories.
>
> -tk
>
> On Sat, Jan 16, 2021 at 8:31 PM Clay Jackson  wrote:
>
>> OK - thanks.  Had a bit of a scare when I corrupted my config file and 
>> NOTHING would start.   I commented rain and rainRate out of StdWXCaiculate 
>> and looks good now.  I AM getting an N/A in RanRate om the disp;lay, but 
>> that's OK for the time being.   Will check when we  next get rain to see 
>> what happens.  
>>
>>  It would be nice to know where totalRain came from - I tried grep'ing 
>> for it in all the .py files and only found it in accum and units.  Before I 
>> posted, I actually commented those lines out and that did NOT work. Any 
>> thoughts on that?
>>
>> Also, I notice from the log I'm still using Python 2, which is what 
>> /usr/bin/python points to by default on squeeze, which is what I'm running 
>> right now.  Are there notes on how to force weewx to use python3?
>>
>> Thanks!
>>
>>
>>
>>
>> On Sat, Jan 16, 2021 at 5:36 PM Tom Keffer  wrote:
>>
>>> Try removing the line 
>>>
>>> rain = prefer_hardware
>>>
>>> It's what's causing the StdWXCalculate service to try and calculate a 
>>> value.
>>>
>>> I wonder where that line came from. I don't recall it ever being part of 
>>> weewx.conf
>>>
>>> -tk
>>>
>>> On Sat, Jan 16, 2021 at 4:58 PM Clay Jackson  wrote:
>>>
 I'm using an Accurite 5n1 - this has been working since early 3.x; just 
 stopped in 4.3,  I AM using my 4.2 config files and skins.

 [StdWXCalculate]

 [[Calculations]]
 # Derived quantities are calculated by this service. Possible 
 values are:
 #  hardware- use the value provided by hardware
 #  software- use the value calculated by weewx
 #  prefer_hardware - use value provide by hardware if available,
 #  otherwise use value calculated by weewx

 pressure = prefer_hardware
 barometer = prefer_hardware
 altimeter = software
 windchill = software
 heatindex = software
 dewpoint = software
 inDewpoint = prefer_hardware
 rainRate = prefer_hardware
 rain = prefer_hardware
 ET = software
 maxSolarRad = prefer_hardware
 cloudbase = prefer_hardware
 humidex = prefer_hardware
 appTemp = prefer_hardware
 windrun = prefer_hardware


 On Sat, Jan 16, 2021 at 4:45 PM Tom Keffer  wrote:

> Normally, the driver does it, but if asked, WeeWX can calculate 'rain' 
> from cumulative quantities such as totalRain, by taking a difference. 
>
> Your configuration file seems to be asking to do so, but totalRain is 
> not available. As for why it's asking, that's not clear.
>
> What does the section [StdWXCalculate] in your file weewx.conf look 
> like?
>
>
> On Sat, Jan 16, 2021 at 4:17 PM Clay Jackson  
> wrote:
>
>> I just upgraded (through apt update, using raspbian) to 4.3.0 and am 
>> seeing the following error. 
>> Jan 16 15:59:12 Weather weewx[17287] INFO __main__: PID file is 
>> /var/run/weewx.pid
>> Jan 16 15:59:12 Weather weewx[17275]: Starting weewx weather system: 
>> weewx.
>> Jan 16 15:59:12 Weather weewx[17291] INFO __main__: Using 
>> configuration file /etc/weewx/weewx.conf
>> Jan 16 15:59:12 Weather weewx[17291] INFO __main__: Debug is 0
>> Jan 16 15:59:12 Weather weewx[17291] INFO weewx.engine: Loading 
>> station type SDR (user.sdr)
>> Jan 16 15:59:12 Weather weewx[17291] INFO user.sdr: driver version is 
>> 0.78
>> Jan 16 15:59:12 Weather weewx[17291] INFO user.sdr: sensor map is 
>> {u'windDir': u'wind_dir.04C9.Acurite5n1PacketV2', u'windSpeed': 
>> u'wind_speed.04C9.Acurite5n1PacketV2', u'outTemp': 
>> u'temperature.04C9.Acurite5n1PacketV2', u'outHumidity': 
>> u'humidity.04C9.Acurite5n1PacketV2', u'rain_total': 
>> u'rain_total.04C9.Acurite5n1PacketV2', u'txBatteryStatus': 
>> u'battery.04C9.Acurite5n1PacketV2', u'inTemp': 
>> u'temperature.4:0.AmbientF007THPacket', u'inHumidity': 
>> u'humidity.4:0.AmbientF007THPacket', u'lightning_distance': 
>> 

Re: [weewx-user] Register your WeeWX station!

[salinois]

ok Tom

I saw your post about the picture in Weewx Map Station

bye

Patrick

Le 17/01/2021 à 17:18, Tom Keffer a écrit :
Patrick, not sure what you are referring to. The discussion above 
about providing a .png file is just a proposal.


On Sun, Jan 17, 2021 at 8:07 AM salinois > wrote:


hi

it is obligatory a file with extension .png ?

patrick

Le 17/01/2021 à 15:46, Tom Keffer a écrit :

Entirely possible. I've created issue #3
 to track.

On Sun, Jan 17, 2021 at 4:38 AM Δημήτρης Βήχος
mailto:hobbyline...@gmail.com>> wrote:

i have my weather station since december 2020 , i had set
registration to true , after restarting weewx.but until now
dont show in map. i wonder if the problem is the greek
characters  of station name. the rest greek stations on map
have english names. i had same issue in noaa reports and
solved that setting from ascii to utf 8 in skin conf. i dont
know how to solve this and i want to see my station in map.

Στις Κυριακή, 11 Οκτωβρίου 2020 στις 9:18:04 μ.μ. UTC+3, ο
χρήστης tke...@gmail.com  έγραψε:

It's something we've talked about.

On Sun, Oct 11, 2020 at 10:50 AM Brent Fraser
 wrote:

How about allowing the station to optionally specify
the image url?

[station]
   station_image=url =
http://mydomain/station_image.png


That should off-load the image creation.

On Thursday, October 8, 2020 at 5:51:33 AM UTC-6
tke...@gmail.com wrote:

Unfortunately, we have suspended preview
snapshots. It was just taking too much memory,
which would cause weewx.com
 to hang. Maybe later!

On Thu, Oct 8, 2020 at 4:38 AM Didier Decoodt
 wrote:

Hi Tom

I have registered my station, it's OK but I
have not a preview image when I select the
station
An idea?
image.png
Didier

Le jeu. 8 oct. 2020 à 13:20, Tom Keffer
 a écrit :

Why not just middle-button click?

On Thu, Oct 8, 2020 at 12:29 AM Greg from
Oz  wrote:

Hi Tom,

Is there a way to put right click on
the url of the web cam links in the
http://weewx.com/stations.html
?

The reason I ask is because when I
click on a link to have a look at
that web site and then press the back
button it goes back to the zoomed out
view and then I have to move the map
and zoom in all over again.

If I could right click I could select
open in a new tab and then I don't
have to zoom and pan every time.

I think this option was available
ages ago.

Thanks

On Thursday, 8 October 2020 00:46:44
UTC+11, Tom Keffer wrote:

Unfortunately, we have suspended
preview snapshots. It was just
taking too much memory, which
would cause weewx.com
 to hang. Maybe
later!

On Tue, Oct 6, 2020 at 12:40 PM
Vetti52  wrote:

being registered, but...
when opening the station on
the map, there is no preview
picture. I am afraid, that
for URLs containing windy.com
 a preview
is not available, right? I
could establish another URL,
which, however is 

[weewx-user] refresh screen

[sali...@gmail.com]

hi,
I have sometime this error message when there is the screen refresh

my Firefox browser is up todate !!

do you know this issue ?

thanks

patrick


-- 
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/89cef812-7b55-41da-869a-37a404b58ab8n%40googlegroups.com.

Re: [weewx-user] Re: ERROR weewx.cheetahgenerator: **** MemoryError

[garrya...@gmail.com]

Thanks!

I think I've done all that I can to isolate the problem.

I'm going to get back to finishing up development and add a cron entry to 
restart WeeWX every 24 hours in the wee hours of the morning.

I will be re-deploying a Davis Pro 2 system very soon (within the week) and 
then deploying another Davis Pro 2 system shortly after that.  And sometime 
after than, a couple of WeatherFlow Tempest systems.

I'll post everything on GitHub soonest.

Regards,

Garry
PS: Re: Ubuntu Desktop on RPi, I've been using it for development for the 
last few days and it has not crashed or hung, so I think I'm going to stay 
with it.  Only issue is wireless mouse lag (Raspberry Pi OS had 
same/similar problem) and I've ordered a Logitech MK540 wireless 
keyboard/mouse combo to see if newer hardwaere works better (than my dated 
Microsoft mouse).
On Sunday, January 17, 2021 at 5:40:15 PM UTC-8 vince wrote:

> Restarted with your add-on plus belchertown both enabled - the RSS is 
> nominally growing at 4 MB per 5-minute archive period.
>
> 1610928917 139.53125 63.97265625 15.453125
> 1610929217 143.02734375 70.41796875 15.4921875
> 1610929517 144.46484375 74.43359375 15.4921875
> 1610929817 145.96484375 78.48046875 15.55078125
> 1610930117 147.46484375 82.65625 15.58203125
> 1610930417 149.09375 86.69921875 15.58203125
> 1610930717 150.34375 90.55078125 15.58203125
> 1610931017 151.84375 94.203125 15.24609375
>
>

-- 
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/85c007ce-0bf2-48a8-95f8-ea191f7d83een%40googlegroups.com.

Re: [weewx-user] Re: New internet provider - now ftp doesn't work

[Tom Keffer]

That's pretty much what I'm thinking, but I'm trying to get the evidence
from Filezilla. It should say that as it negotiates with the server.

FTP is 40 year old technology. It's amazing that there are still so many
incompatible versions out there.

On Mon, Jan 18, 2021 at 8:34 AM Les Niles  wrote:

> The server is responding to the PASV command by entering extended passive
> mode EPSV, which apparently is a legal response but which weewx/ftplib is
> not handling correctly. (I don’t have access to the code right now so can’t
> be more precise about where to fix.) The difference is that in EPSV mode
> the server doesn’t return an IP, just a port number. (The line “host, port
> = self.makepasv()” is not going to work.)
>
> Apparently passive mode has been the default for ftplib since python 2.1,
> so maybe just skip trying to change to PASV entirely?
>
>   -Les
>
>
> On Jan 18, 2021, at 7:21 AM, Rich Strle  wrote:
>
> 
> Command: TYPE I
> Trace: CFtpControlSocket::OnReceive()
> Response: 200 TYPE is now 8-bit binary
> Trace: CFtpRawTransferOpData::ParseResponse() in state 1
> Trace: CControlSocket::SendNextCommand()
> Trace: CFtpRawTransferOpData::Send() in state 2
> Command: PASV
> Trace: CFtpControlSocket::OnReceive()
> Response: 200 TYPE is now 8-bit binary
> Trace: CFtpRawTransferOpData::ParseResponse() in state 1
> Trace: CControlSocket::SendNextCommand()
> Trace: CFtpRawTransferOpData::Send() in state 2
> Command: PASV
> Trace: CFtpControlSocket::OnReceive()
> Response: 227 Entering Passive Mode (107,180,51,77,196,142)
> Trace: CFtpRawTransferOpData::ParseResponse() in state 2
> Trace: CControlSocket::SendNextCommand()
> Trace: CFtpRawTransferOpData::Send() in state 4
> Trace: Binding data connection source IP to control connection source IP
> 192.168.12.117
> Command: STOR yearbarometer.png
> Trace: CTransferSocket::OnConnect
> Trace: CTlsSocketImpl::Handshake()
> Trace: Trying to resume existing TLS session.
> Trace: CTlsSocketImpl::ContinueHandshake()
> Trace: CFtpControlSocket::OnReceive()
> Response: 227 Entering Passive Mode (107,180,51,77,197,217)
> Trace: CFtpRawTransferOpData::ParseResponse() in state 2
> Trace: CControlSocket::SendNextCommand()
> Trace: CFtpRawTransferOpData::Send() in state 4
> Trace: Binding data connection source IP to control connection source IP
> 192.168.12.117
> Command: STOR yearhilow.png
>
> On Monday, January 18, 2021 at 7:16:26 AM UTC-6 tke...@gmail.com wrote:
>
>> Good to hear that Filezilla is working. We can use it to understand what
>> the server is doing.
>>
>> Using Filezilla, go into its "Settings" (under the "Edit" menu). Then the
>> "Debug" tab. There's a drop down list of message levels. Default is "0 -
>> None". Set it to "3- Verbose". Then click "OK".
>>
>> [image: image.png]
>>
>> Then use Filezilla again to transfer some files. This time, watch the
>> window at top that tells you what Filezilla is doing. See if the client
>> (Filezilla, in this case) is negotiating with the server. Tell us what you
>> see, or, better, copy and paste it into a post.
>>
>>
>>
>> On Sun, Jan 17, 2021 at 7:33 PM Rich Strle  wrote:
>>
>>> Jan 17 21:30:44 pi-weather weewx[429] ERROR weeutil.ftpupload: Failed
>>> uploading /var/www/html/weewx/yearradiation.png to server
>>> www.cliffandbuster.com. Reason: '229 Extended Passive Mode Entered
>>> (|||50458|)'
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>> ftpgenerator: (2): caught exception '': 229
>>> Extended Passive Mode Entered (|||50458|)
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    Traceback (most recent call last):
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  File "/usr/share/weewx/weewx/reportengine.py", line 331, in run
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    n = ftp_data.run()
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  File "/usr/share/weewx/weeutil/ftpupload.py", line 163, in run
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    ftp_server.storbinary(stor_cmd, fd)
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  File "/usr/lib/python3.7/ftplib.py", line 504, in storbinary
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    with self.transfercmd(cmd, rest) as conn:
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  File "/usr/lib/python3.7/ftplib.py", line 399, in transfercmd
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    return self.ntransfercmd(cmd, rest)[0]
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  File "/usr/lib/python3.7/ftplib.py", line 359, in ntransfercmd
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    host, port = self.makepasv()
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  

Re: [weewx-user] Re: New internet provider - now ftp doesn't work

[Les Niles]

The server is responding to the PASV command by entering extended passive mode 
EPSV, which apparently is a legal response but which weewx/ftplib is not 
handling correctly. (I don’t have access to the code right now so can’t be more 
precise about where to fix.) The difference is that in EPSV mode the server 
doesn’t return an IP, just a port number. (The line “host, port = 
self.makepasv()” is not going to work.) 

Apparently passive mode has been the default for ftplib since python 2.1, so 
maybe just skip trying to change to PASV entirely?

  -Les


> On Jan 18, 2021, at 7:21 AM, Rich Strle  wrote:
> 
> 
> Command:  TYPE I
> Trace:CFtpControlSocket::OnReceive()
> Response: 200 TYPE is now 8-bit binary
> Trace:CFtpRawTransferOpData::ParseResponse() in state 1
> Trace:CControlSocket::SendNextCommand()
> Trace:CFtpRawTransferOpData::Send() in state 2
> Command:  PASV
> Trace:CFtpControlSocket::OnReceive()
> Response: 200 TYPE is now 8-bit binary
> Trace:CFtpRawTransferOpData::ParseResponse() in state 1
> Trace:CControlSocket::SendNextCommand()
> Trace:CFtpRawTransferOpData::Send() in state 2
> Command:  PASV
> Trace:CFtpControlSocket::OnReceive()
> Response: 227 Entering Passive Mode (107,180,51,77,196,142)
> Trace:CFtpRawTransferOpData::ParseResponse() in state 2
> Trace:CControlSocket::SendNextCommand()
> Trace:CFtpRawTransferOpData::Send() in state 4
> Trace:Binding data connection source IP to control connection source 
> IP 192.168.12.117
> Command:  STOR yearbarometer.png
> Trace:CTransferSocket::OnConnect
> Trace:CTlsSocketImpl::Handshake()
> Trace:Trying to resume existing TLS session.
> Trace:CTlsSocketImpl::ContinueHandshake()
> Trace:CFtpControlSocket::OnReceive()
> Response: 227 Entering Passive Mode (107,180,51,77,197,217)
> Trace:CFtpRawTransferOpData::ParseResponse() in state 2
> Trace:CControlSocket::SendNextCommand()
> Trace:CFtpRawTransferOpData::Send() in state 4
> Trace:Binding data connection source IP to control connection source 
> IP 192.168.12.117
> Command:  STOR yearhilow.png
> 
>> On Monday, January 18, 2021 at 7:16:26 AM UTC-6 tke...@gmail.com wrote:
>> Good to hear that Filezilla is working. We can use it to understand what the 
>> server is doing.
>> 
>> Using Filezilla, go into its "Settings" (under the "Edit" menu). Then the 
>> "Debug" tab. There's a drop down list of message levels. Default is "0 - 
>> None". Set it to "3- Verbose". Then click "OK".
>> 
>> 
>> 
>> Then use Filezilla again to transfer some files. This time, watch the window 
>> at top that tells you what Filezilla is doing. See if the client (Filezilla, 
>> in this case) is negotiating with the server. Tell us what you see, or, 
>> better, copy and paste it into a post.
>> 
>> 
>> 
>>> On Sun, Jan 17, 2021 at 7:33 PM Rich Strle  wrote:
>>> Jan 17 21:30:44 pi-weather weewx[429] ERROR weeutil.ftpupload: Failed 
>>> uploading /var/www/html/weewx/yearradiation.png to server 
>>> www.cliffandbuster.com. Reason: '229 Extended Passive Mode Entered 
>>> (|||50458|)'
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> ftpgenerator: (2): caught exception '': 229 
>>> Extended Passive Mode Entered (|||50458|)
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>>   Traceback (most recent call last):
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> File "/usr/share/weewx/weewx/reportengine.py", line 331, in run
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>>   n = ftp_data.run()
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> File "/usr/share/weewx/weeutil/ftpupload.py", line 163, in run
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>>   ftp_server.storbinary(stor_cmd, fd)
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> File "/usr/lib/python3.7/ftplib.py", line 504, in storbinary
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>>   with self.transfercmd(cmd, rest) as conn:
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> File "/usr/lib/python3.7/ftplib.py", line 399, in transfercmd
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>>   return self.ntransfercmd(cmd, rest)[0]
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> File "/usr/lib/python3.7/ftplib.py", line 359, in ntransfercmd
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>>   host, port = self.makepasv()
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>>> File 

Re: [weewx-user] Re: New internet provider - now ftp doesn't work

[Tom Keffer]

What we want to see is the earlier chatter: where the client negotiates
with the server.

On Mon, Jan 18, 2021 at 7:21 AM Rich Strle  wrote:

> Command: TYPE I
> Trace: CFtpControlSocket::OnReceive()
> Response: 200 TYPE is now 8-bit binary
> Trace: CFtpRawTransferOpData::ParseResponse() in state 1
> Trace: CControlSocket::SendNextCommand()
> Trace: CFtpRawTransferOpData::Send() in state 2
> Command: PASV
> Trace: CFtpControlSocket::OnReceive()
> Response: 200 TYPE is now 8-bit binary
> Trace: CFtpRawTransferOpData::ParseResponse() in state 1
> Trace: CControlSocket::SendNextCommand()
> Trace: CFtpRawTransferOpData::Send() in state 2
> Command: PASV
> Trace: CFtpControlSocket::OnReceive()
> Response: 227 Entering Passive Mode (107,180,51,77,196,142)
> Trace: CFtpRawTransferOpData::ParseResponse() in state 2
> Trace: CControlSocket::SendNextCommand()
> Trace: CFtpRawTransferOpData::Send() in state 4
> Trace: Binding data connection source IP to control connection source IP
> 192.168.12.117
> Command: STOR yearbarometer.png
> Trace: CTransferSocket::OnConnect
> Trace: CTlsSocketImpl::Handshake()
> Trace: Trying to resume existing TLS session.
> Trace: CTlsSocketImpl::ContinueHandshake()
> Trace: CFtpControlSocket::OnReceive()
> Response: 227 Entering Passive Mode (107,180,51,77,197,217)
> Trace: CFtpRawTransferOpData::ParseResponse() in state 2
> Trace: CControlSocket::SendNextCommand()
> Trace: CFtpRawTransferOpData::Send() in state 4
> Trace: Binding data connection source IP to control connection source IP
> 192.168.12.117
> Command: STOR yearhilow.png
>
> On Monday, January 18, 2021 at 7:16:26 AM UTC-6 tke...@gmail.com wrote:
>
>> Good to hear that Filezilla is working. We can use it to understand what
>> the server is doing.
>>
>> Using Filezilla, go into its "Settings" (under the "Edit" menu). Then the
>> "Debug" tab. There's a drop down list of message levels. Default is "0 -
>> None". Set it to "3- Verbose". Then click "OK".
>>
>> [image: image.png]
>>
>> Then use Filezilla again to transfer some files. This time, watch the
>> window at top that tells you what Filezilla is doing. See if the client
>> (Filezilla, in this case) is negotiating with the server. Tell us what you
>> see, or, better, copy and paste it into a post.
>>
>>
>>
>> On Sun, Jan 17, 2021 at 7:33 PM Rich Strle  wrote:
>>
>>> Jan 17 21:30:44 pi-weather weewx[429] ERROR weeutil.ftpupload: Failed
>>> uploading /var/www/html/weewx/yearradiation.png to server
>>> www.cliffandbuster.com. Reason: '229 Extended Passive Mode Entered
>>> (|||50458|)'
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>> ftpgenerator: (2): caught exception '': 229
>>> Extended Passive Mode Entered (|||50458|)
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    Traceback (most recent call last):
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  File "/usr/share/weewx/weewx/reportengine.py", line 331, in run
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    n = ftp_data.run()
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  File "/usr/share/weewx/weeutil/ftpupload.py", line 163, in run
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    ftp_server.storbinary(stor_cmd, fd)
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  File "/usr/lib/python3.7/ftplib.py", line 504, in storbinary
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    with self.transfercmd(cmd, rest) as conn:
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  File "/usr/lib/python3.7/ftplib.py", line 399, in transfercmd
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    return self.ntransfercmd(cmd, rest)[0]
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  File "/usr/lib/python3.7/ftplib.py", line 359, in ntransfercmd
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    host, port = self.makepasv()
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  File "/usr/lib/python3.7/ftplib.py", line 337, in makepasv
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    host, port = parse227(self.sendcmd('PASV'))
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>  File "/usr/lib/python3.7/ftplib.py", line 845, in parse227
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    raise error_reply(resp)
>>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>>    ftplib.error_reply: 229 Extended Passive Mode Entered (|||50458|)
>>> Jan 17 21:30:45 pi-weather weewx[429] DEBUG weewx.reportengine: Report
>>> 'RSYNC' not enabled. Skipping.
>>>
>>>
>>> On Sunday, January 17, 2021 at 9:28:38 PM UTC-6 Rich Strle wrote:
>>>
 I 

Re: [weewx-user] Re: New internet provider - now ftp doesn't work

[Rich Strle]

Command: TYPE I
Trace: CFtpControlSocket::OnReceive()
Response: 200 TYPE is now 8-bit binary
Trace: CFtpRawTransferOpData::ParseResponse() in state 1
Trace: CControlSocket::SendNextCommand()
Trace: CFtpRawTransferOpData::Send() in state 2
Command: PASV
Trace: CFtpControlSocket::OnReceive()
Response: 200 TYPE is now 8-bit binary
Trace: CFtpRawTransferOpData::ParseResponse() in state 1
Trace: CControlSocket::SendNextCommand()
Trace: CFtpRawTransferOpData::Send() in state 2
Command: PASV
Trace: CFtpControlSocket::OnReceive()
Response: 227 Entering Passive Mode (107,180,51,77,196,142)
Trace: CFtpRawTransferOpData::ParseResponse() in state 2
Trace: CControlSocket::SendNextCommand()
Trace: CFtpRawTransferOpData::Send() in state 4
Trace: Binding data connection source IP to control connection source IP 
192.168.12.117
Command: STOR yearbarometer.png
Trace: CTransferSocket::OnConnect
Trace: CTlsSocketImpl::Handshake()
Trace: Trying to resume existing TLS session.
Trace: CTlsSocketImpl::ContinueHandshake()
Trace: CFtpControlSocket::OnReceive()
Response: 227 Entering Passive Mode (107,180,51,77,197,217)
Trace: CFtpRawTransferOpData::ParseResponse() in state 2
Trace: CControlSocket::SendNextCommand()
Trace: CFtpRawTransferOpData::Send() in state 4
Trace: Binding data connection source IP to control connection source IP 
192.168.12.117
Command: STOR yearhilow.png

On Monday, January 18, 2021 at 7:16:26 AM UTC-6 tke...@gmail.com wrote:

> Good to hear that Filezilla is working. We can use it to understand what 
> the server is doing.
>
> Using Filezilla, go into its "Settings" (under the "Edit" menu). Then the 
> "Debug" tab. There's a drop down list of message levels. Default is "0 - 
> None". Set it to "3- Verbose". Then click "OK".
>
> [image: image.png]
>
> Then use Filezilla again to transfer some files. This time, watch the 
> window at top that tells you what Filezilla is doing. See if the client 
> (Filezilla, in this case) is negotiating with the server. Tell us what you 
> see, or, better, copy and paste it into a post.
>
>
>
> On Sun, Jan 17, 2021 at 7:33 PM Rich Strle  wrote:
>
>> Jan 17 21:30:44 pi-weather weewx[429] ERROR weeutil.ftpupload: Failed 
>> uploading /var/www/html/weewx/yearradiation.png to server 
>> www.cliffandbuster.com. Reason: '229 Extended Passive Mode Entered 
>> (|||50458|)'
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine: 
>> ftpgenerator: (2): caught exception '': 229 
>> Extended Passive Mode Entered (|||50458|)
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>    Traceback (most recent call last):
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>  File "/usr/share/weewx/weewx/reportengine.py", line 331, in run
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>    n = ftp_data.run()
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>  File "/usr/share/weewx/weeutil/ftpupload.py", line 163, in run
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>    ftp_server.storbinary(stor_cmd, fd)
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>  File "/usr/lib/python3.7/ftplib.py", line 504, in storbinary
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>    with self.transfercmd(cmd, rest) as conn:
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>  File "/usr/lib/python3.7/ftplib.py", line 399, in transfercmd
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>    return self.ntransfercmd(cmd, rest)[0]
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>  File "/usr/lib/python3.7/ftplib.py", line 359, in ntransfercmd
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>    host, port = self.makepasv()
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>  File "/usr/lib/python3.7/ftplib.py", line 337, in makepasv
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>    host, port = parse227(self.sendcmd('PASV'))
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>  File "/usr/lib/python3.7/ftplib.py", line 845, in parse227
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>    raise error_reply(resp)
>> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>>    ftplib.error_reply: 229 Extended Passive Mode Entered (|||50458|)
>> Jan 17 21:30:45 pi-weather weewx[429] DEBUG weewx.reportengine: Report 
>> 'RSYNC' not enabled. Skipping.
>>
>>
>> On Sunday, January 17, 2021 at 9:28:38 PM UTC-6 Rich Strle wrote:
>>
>>> I installed FileZilla and was able to use the same user name and 
>>> password to upload files from /var/www/html/weewx/ to the same spot on 

Re: [weewx-user] Re: FINE OFFSET WH2900 / Ambient Weather WS-2902

[S R]

i put in the network network, but i can't get the interceptor.py debug to 
run. keeps falling over on the driver import line


On Monday, January 18, 2021 at 12:14:07 PM UTC+1 lang@googlemail.com 
wrote:

> I suggest that you first get weewx running with the interceptor driver in 
> a simple "normal" test environment.
> e.g. weewx host and console in the same subnet, no other fancy network and 
> virtualization constructions.
>
> Once that works, start changing step by step the test environment towards 
> your finally planned setup and 
> work out the issues on the path. Imho only such a systematic approach will 
> lead you to the goal.
>
> Many of your questions seem to come from your complex environment, and as 
> long as you don' find anyone
> who completely understands your architecture (who would probably need a 
> scheme, description, picture),
> the components used, their impact etc., you will most likely not get the 
> proper answers. 
>
> I suggest moving from simple to complex.
> epair0b is obviously a freenas speciality ...
>
> On 18.01.2021 12:00, S R wrote:
>
> I see in interceptor.py the default interface is DEFAULT_IFACE = 'eth0'
> if i do ifconfig in the shell to the jail, the interface is  'epair0b'
>
> should i be changing the interface? 
> still can't the debug to work. 
>
> On Monday, January 18, 2021 at 8:55:28 AM UTC+1 S R wrote:
>
>> i figured out the utf-8 issue. weewx.conf has to be in utf, but i made 
>> the mistake of editing in the shell with edit. once i used geany and change 
>> the encoding back to utf-8 it came good. 
>>
>> current status is; 
>> - console updates both ecowitt and wunderground online every minute. 
>> - config using ecowitt protocol with custom config pointing to local 
>> freenas jail / weewx server - path = index.php?
>> - using seasons default report 
>> - weewx is not upating and pfsense is showing me below with a packet 
>> capture, but no rules are blocking.
>> - i have tcp options enabled on both rules (WEEWX and WH2900C are on 
>> different VLANs)
>>
>> 222.968670WH2900CWEEWXTCP5820150 → 8080 [SYN] 
>> Seq=0 Win=5840 Len=0 MSS=1460
>> 232.969709WEEWXWH2900CTCP548080 → 20150 [RST, 
>> ACK] Seq=1 Ack=1 Win=0 Len=0
>>
>>
>> On Sunday, January 17, 2021 at 8:54:36 PM UTC+1 lang@googlemail.com 
>> wrote:
>>
>>> As a workaround I would remove / replace your suspects - change 
>>> "Umlaute", if any, from Ä -> AE, Ö -->OE, Ü --> UE, accents just omit them 
>>> and leave the vowels without them.
>>> They will anyway only appear in temporary graphs. Then figure out your 
>>> UTF-8 issue and fix it, while your weewx could already run and archive data.
>>> On 17.01.2021 19:59, S R wrote:
>>>
>>> thanks for the clarification. i will switch the protocol to ecowitt, but 
>>> the more immediate problem is the UTF-8 error which is now preventing weewx 
>>> from starting.
>>>
>>> On Sunday, January 17, 2021 at 4:30:38 PM UTC+1 galfert wrote:
>>>
 This thread started with the discussion being around the Ambient 
 WS-2902 and that is totally different despite looking like the same unit. 
 This is because Ambient is the only Fine Offset clone reseller that 
 changes 
 the firmware and they limit options. The Ambient version does not let you 
 upload to custom server address. The confusion here is that my response 
 was 
 because I thought you had and Ambient branded unit. Since you don't have 
 an 
 Ambient branded unit you do have the option to send to a custom server 
 using both WU and Ecowitt protocols. The WU protocol is limited and only 
 sends the basic set of sensors. The Ecowitt protocol allows you to send a 
 lot more optional sensors like PM2.5, soil moisture, extra temp/hum 
 sensorsetc. But still you'll have to configure the Interceptor driver 
 to match the protocol type that you set in you WH2900C for uploading to 
 your custom server.  

 The GW1000 though is still a more elegant and newer solution. 

 * The newest Ambient WS-2902 firmware finally after many years does 
 gain the ability to send to a custom serverBUT it is not WU protocol 
 and it is not Ecowitt protocolit is Ambientweather.net protocol and 
 enough significant differences that the Interceptor driver will not work. 
 This newest firmware is not yet officially supported by Ambient. They 
 haven't yet release the updated awnet mobile app to enable turning and 
 configuring this option. All of these complexities and changing nature of 
 the situation makes it difficult to explain the situation to cover all 
 possible scenarios...what model you have and whom it is from and what 
 firmware version you are running and all the different supporting 
 protocols 
 that are possible. 

 Using pfsense to capture and forward packets is really unnecessary for 
 anyone with a non-Ambient WH2900Cas 

Re: [weewx-user] Re: New internet provider - now ftp doesn't work

[Tom Keffer]

Good to hear that Filezilla is working. We can use it to understand what
the server is doing.

Using Filezilla, go into its "Settings" (under the "Edit" menu). Then the
"Debug" tab. There's a drop down list of message levels. Default is "0 -
None". Set it to "3- Verbose". Then click "OK".

[image: image.png]

Then use Filezilla again to transfer some files. This time, watch the
window at top that tells you what Filezilla is doing. See if the client
(Filezilla, in this case) is negotiating with the server. Tell us what you
see, or, better, copy and paste it into a post.



On Sun, Jan 17, 2021 at 7:33 PM Rich Strle  wrote:

> Jan 17 21:30:44 pi-weather weewx[429] ERROR weeutil.ftpupload: Failed
> uploading /var/www/html/weewx/yearradiation.png to server
> www.cliffandbuster.com. Reason: '229 Extended Passive Mode Entered
> (|||50458|)'
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
> ftpgenerator: (2): caught exception '': 229
> Extended Passive Mode Entered (|||50458|)
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>    Traceback (most recent call last):
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>  File "/usr/share/weewx/weewx/reportengine.py", line 331, in run
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>    n = ftp_data.run()
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>  File "/usr/share/weewx/weeutil/ftpupload.py", line 163, in run
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>    ftp_server.storbinary(stor_cmd, fd)
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>  File "/usr/lib/python3.7/ftplib.py", line 504, in storbinary
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>    with self.transfercmd(cmd, rest) as conn:
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>  File "/usr/lib/python3.7/ftplib.py", line 399, in transfercmd
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>    return self.ntransfercmd(cmd, rest)[0]
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>  File "/usr/lib/python3.7/ftplib.py", line 359, in ntransfercmd
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>    host, port = self.makepasv()
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>  File "/usr/lib/python3.7/ftplib.py", line 337, in makepasv
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>    host, port = parse227(self.sendcmd('PASV'))
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>  File "/usr/lib/python3.7/ftplib.py", line 845, in parse227
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>    raise error_reply(resp)
> Jan 17 21:30:45 pi-weather weewx[429] ERROR weewx.reportengine:
>    ftplib.error_reply: 229 Extended Passive Mode Entered (|||50458|)
> Jan 17 21:30:45 pi-weather weewx[429] DEBUG weewx.reportengine: Report
> 'RSYNC' not enabled. Skipping.
>
>
> On Sunday, January 17, 2021 at 9:28:38 PM UTC-6 Rich Strle wrote:
>
>> I installed FileZilla and was able to use the same user name and password
>> to upload files from /var/www/html/weewx/ to the same spot on my webserver.
>> I did get an error message Hostname does not match certificate but I've
>> gotten that before...
>>
>> On Sunday, January 17, 2021 at 7:24:45 PM UTC-6 tke...@gmail.com wrote:
>>
>>> Can you FTP using Filezilla? The goal here is to see if it's some
>>> firewall / network/ provider issue, or a problem peculiar to the Python FTP
>>> library.
>>>
>>> On Sun, Jan 17, 2021 at 10:04 AM Rich Strle  wrote:
>>>
 My bad, the ftp in whew still doesn't work. The Access Point only has
 an IPv6 number listed, it doesn't have an IPv4 number listed. My website
 provider only allows 1 sftp account at the root level and I was trying to
 avoid using that.

 On Sunday, January 17, 2021 at 11:41:18 AM UTC-6 Rich Strle wrote:

> I spoke with t-mobile again. They didn't say they did anything but all
> of a sudden ftp started working. I will continue to monitor.
>
> On Sunday, January 17, 2021 at 10:50:19 AM UTC-6 galfert wrote:
>
>> Anyone care to google "T-Mobile FTP"  You'll see that this is an
>> issue for everyone! My recommendation is to try to instead use SFTP.
>>
>>
>> On Sunday, January 17, 2021 at 11:41:25 AM UTC-5 Rich Strle wrote:
>>
>>> I did as instructed. Attached is the log file after I made the
>>> change. I have a call into my provider to see if they are IPV6.
>>>
>>>
>>>
>>> On Sunday, January 17, 2021 at 10:17:33 AM UTC-6 tke...@gmail.com
>>> wrote:
>>>
 You definitely want passive mode (passive=1).

 Two things:

 1. By any chance, is your new provider using IPV6 (instead of

Re: [weewx-user] Re: FINE OFFSET WH2900 / Ambient Weather WS-2902

[Rainer Lang]

I suggest that you first get weewx running with the interceptor driver 
in a simple "normal" test environment.
e.g. weewx host and console in the same subnet, no other fancy network 
and virtualization constructions.


Once that works, start changing step by step the test environment 
towards your finally planned setup and
work out the issues on the path. Imho only such a systematic approach 
will lead you to the goal.


Many of your questions seem to come from your complex environment, and 
as long as you don' find anyone
who completely understands your architecture (who would probably need a 
scheme, description, picture),
the components used, their impact etc., you will most likely not get the 
proper answers.


I suggest moving from simple to complex.
epair0b is obviously a freenas speciality ...

On 18.01.2021 12:00, S R wrote:

I see in interceptor.py the default interface is DEFAULT_IFACE = 'eth0'
if i do ifconfig in the shell to the jail, the interface is 'epair0b'

should i be changing the interface?
still can't the debug to work.

On Monday, January 18, 2021 at 8:55:28 AM UTC+1 S R wrote:

i figured out the utf-8 issue. weewx.conf has to be in utf, but i
made the mistake of editing in the shell with edit. once i used
geany and change the encoding back to utf-8 it came good.

current status is;
- console updates both ecowitt and wunderground online every minute.
- config using ecowitt protocol with custom config pointing to
local freenas jail / weewx server - path = index.php?
- using seasons default report
- weewx is not upating and pfsense is showing me below with a
packet capture, but no rules are blocking.
- i have tcp options enabled on both rules (WEEWX and WH2900C are
on different VLANs)

22    2.968670    WH2900C    WEEWX    TCP    58    20150 → 8080
[SYN] Seq=0 Win=5840 Len=0 MSS=1460
23    2.969709    WEEWX    WH2900C TCP    54    8080 → 20150 [RST,
ACK] Seq=1 Ack=1 Win=0 Len=0


On Sunday, January 17, 2021 at 8:54:36 PM UTC+1
lang@googlemail.com wrote:

As a workaround I would remove / replace your suspects -
change "Umlaute", if any, from Ä -> AE, Ö -->OE, Ü --> UE,
accents just omit them and leave the vowels without them.
They will anyway only appear in temporary graphs. Then figure
out your UTF-8 issue and fix it, while your weewx could
already run and archive data.

On 17.01.2021 19:59, S R wrote:

thanks for the clarification. i will switch the protocol to
ecowitt, but the more immediate problem is the UTF-8 error
which is now preventing weewx from starting.

On Sunday, January 17, 2021 at 4:30:38 PM UTC+1 galfert wrote:

This thread started with the discussion being around the
Ambient WS-2902 and that is totally different despite
looking like the same unit. This is because Ambient is
the only Fine Offset clone reseller that changes the
firmware and they limit options. The Ambient version does
not let you upload to custom server address. The
confusion here is that my response was because I thought
you had and Ambient branded unit. Since you don't have an
Ambient branded unit you do have the option to send to a
custom server using both WU and Ecowitt protocols. The WU
protocol is limited and only sends the basic set of
sensors. The Ecowitt protocol allows you to send a lot
more optional sensors like PM2.5, soil moisture, extra
temp/hum sensorsetc. But still you'll have to
configure the Interceptor driver to match the protocol
type that you set in you WH2900C for uploading to your
custom server.

The GW1000 though is still a more elegant and newer
solution.

* The newest Ambient WS-2902 firmware finally after many
years does gain the ability to send to a custom
serverBUT it is not WU protocol and it is not Ecowitt
protocolit is Ambientweather.net protocol and enough
significant differences that the Interceptor driver will
not work. This newest firmware is not yet officially
supported by Ambient. They haven't yet release the
updated awnet mobile app to enable turning and
configuring this option. All of these complexities and
changing nature of the situation makes it difficult to
explain the situation to cover all possible
scenarios...what model you have and whom it is from and
what firmware version you are running and all the
different supporting protocols that are possible.

Using pfsense to capture and forward packets is really
unnecessary for anyone with a non-Ambient WH2900Cas
it 

Re: [weewx-user] Re: FINE OFFSET WH2900 / Ambient Weather WS-2902

[S R]

I see in interceptor.py the default interface is DEFAULT_IFACE = 'eth0'
if i do ifconfig in the shell to the jail, the interface is  'epair0b'

should i be changing the interface? 
still can't the debug to work. 

On Monday, January 18, 2021 at 8:55:28 AM UTC+1 S R wrote:

> i figured out the utf-8 issue. weewx.conf has to be in utf, but i made the 
> mistake of editing in the shell with edit. once i used geany and change the 
> encoding back to utf-8 it came good. 
>
> current status is; 
> - console updates both ecowitt and wunderground online every minute. 
> - config using ecowitt protocol with custom config pointing to local 
> freenas jail / weewx server - path = index.php?
> - using seasons default report 
> - weewx is not upating and pfsense is showing me below with a packet 
> capture, but no rules are blocking.
> - i have tcp options enabled on both rules (WEEWX and WH2900C are on 
> different VLANs)
>
> 222.968670WH2900CWEEWXTCP5820150 → 8080 [SYN] 
> Seq=0 Win=5840 Len=0 MSS=1460
> 232.969709WEEWXWH2900CTCP548080 → 20150 [RST, ACK] 
> Seq=1 Ack=1 Win=0 Len=0
>
>
> On Sunday, January 17, 2021 at 8:54:36 PM UTC+1 lang@googlemail.com 
> wrote:
>
>> As a workaround I would remove / replace your suspects - change 
>> "Umlaute", if any, from Ä -> AE, Ö -->OE, Ü --> UE, accents just omit them 
>> and leave the vowels without them.
>> They will anyway only appear in temporary graphs. Then figure out your 
>> UTF-8 issue and fix it, while your weewx could already run and archive data.
>> On 17.01.2021 19:59, S R wrote:
>>
>> thanks for the clarification. i will switch the protocol to ecowitt, but 
>> the more immediate problem is the UTF-8 error which is now preventing weewx 
>> from starting.
>>
>> On Sunday, January 17, 2021 at 4:30:38 PM UTC+1 galfert wrote:
>>
>>> This thread started with the discussion being around the Ambient WS-2902 
>>> and that is totally different despite looking like the same unit. This is 
>>> because Ambient is the only Fine Offset clone reseller that changes the 
>>> firmware and they limit options. The Ambient version does not let you 
>>> upload to custom server address. The confusion here is that my response was 
>>> because I thought you had and Ambient branded unit. Since you don't have an 
>>> Ambient branded unit you do have the option to send to a custom server 
>>> using both WU and Ecowitt protocols. The WU protocol is limited and only 
>>> sends the basic set of sensors. The Ecowitt protocol allows you to send a 
>>> lot more optional sensors like PM2.5, soil moisture, extra temp/hum 
>>> sensorsetc. But still you'll have to configure the Interceptor driver 
>>> to match the protocol type that you set in you WH2900C for uploading to 
>>> your custom server.  
>>>
>>> The GW1000 though is still a more elegant and newer solution. 
>>>
>>> * The newest Ambient WS-2902 firmware finally after many years does gain 
>>> the ability to send to a custom serverBUT it is not WU protocol and it 
>>> is not Ecowitt protocolit is Ambientweather.net protocol and enough 
>>> significant differences that the Interceptor driver will not work. This 
>>> newest firmware is not yet officially supported by Ambient. They haven't 
>>> yet release the updated awnet mobile app to enable turning and configuring 
>>> this option. All of these complexities and changing nature of the situation 
>>> makes it difficult to explain the situation to cover all possible 
>>> scenarios...what model you have and whom it is from and what firmware 
>>> version you are running and all the different supporting protocols that are 
>>> possible. 
>>>
>>> Using pfsense to capture and forward packets is really unnecessary for 
>>> anyone with a non-Ambient WH2900Cas it has a built in simple to 
>>> configure "Customized" server upload feature.
>>>
>>>
>>>
>>> On Sunday, January 17, 2021 at 7:32:03 AM UTC-5 sjr4...@gmail.com wrote:
>>>
 For the record, mine is a Chinese Mi-Sol WH2900C. It is a copy of the 
 Fine Offset WH2900 or the Ecowitt WS2950. Indeed, the unit requires a 
 connection to Ecowitt to set the Time/Date and automatically downloaded 
 the 
 EasyWeather 1.56 firmware update from Ecowitt. 

 I haven't got the outdoor setup done yet, while i play with getting the 
 unit up and running. but Ecowitt, shows my indoor temperature and pressure 
 on the home page. I use pfsense so can run a packet capture if it helps. 
 Since editing the weewx.conf file, i am getting the utf-8 problem. I guess 
 this is related to me using European accented characters in my editors 
 which are UTF-8. So that leaves me with two questions;
 1) how to have it accept the UTF-8 characters
 2) you mentioned not getting all the sensor data, unless using Ecowitt. 
 In view, that i am. Can you tell me what additional parameters i need in 
 the config file please.



 On Sunday, 

[weewx-user] Re: 4.1.1 - No module named 'Image'

[cql...@gmail.com]

Good point. Here are the startup logs  - 
looks like it is running the python version I was expecting: 3.9.0. (Makes 
sense since the base docker image is a python 3 base image)

On Sunday, January 17, 2021 at 10:37:08 PM UTC-6 gjr80 wrote:

> Appreciate you have installed PIL under python3 but are you sure that 
> WeeWX is being run under python3 and not python2? I see nothing in what you 
> have posted that confirms this one way or another. The python version is 
> logged when starting WeeWX. What does the log say when you start WeeWX?
>
> Gary
>
> On Monday, 18 January 2021 at 14:14:24 UTC+10 cql...@gmail.com wrote:
>
>> Hey all,
>> I've recently begun the process of migrating my existing weewx install to 
>> my
>> kubernetes cluster, using this base docker image 
>> 
>> I'm still getting used to the setup, but it seems to be pulling data from 
>> my
>> weather station and populating my sqlite db. However, I'm running into 
>> problems
>> generating images due to a ModuleNotFoundError. Below, take a look at 
>> some of
>> the results of my troubleshooting.
>>
>>
>>- Here's my setup:
>>
>> root@weewx-84bfc8b796-gwrr7:/home/weewx# python --version
>> Python 3.9.0
>> root@weewx-84bfc8b796-gwrr7:/home/weewx# pip --version
>> pip 20.2.3 from /opt/venv/lib/python3.9/site-packages/pip (python 3.9)
>> root@weewx-84bfc8b796-gwrr7:/home/weewx# cat version.txt
>> __version__ = "4.1.1"
>>
>>- Here's my weewx logs showing the ModuleNotFoundError 
>>
>>- I found a previous thread 
>>discussing this 
>>issue, but it didn't seem to describe successful workarounds. 
>>- Here's the output from working through that thread 
>>   
>>- Looking at this issue outside the context of weewx, it seemed 
>>reasonable to try to install pillow via pip, but doing so resulted in 
>> this 
>>long, ugly error 
>>
>> Wondering if anybody has navigated this issue before. Thanks!
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/87696c82-0062-4944-9dd0-34ba356b3102n%40googlegroups.com.