date:20210110

Another FAQ. Any time you see "except OSError, e:" you are trying to run 
python3 against legacy code that was only written to support python2.

You need to update your forecast extension to a current version, then 
you'll be fine.

On Sunday, January 10, 2021 at 4:31:09 PM UTC-8 WxManAJB wrote:

> Hi all...probably something very simple here, but I'm stuck...
>
> Just upgraded to 4.3.0 (setup.py method on raspbian stretch/python3) and 
> I'm getting the following error in my syslog:
>
> Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   
> self.loadServices(config_dict)
> Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__: File 
> "/home/weewx/bin/weewx/engine.py", line 161, in loadServices
> Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   obj = 
> weeutil.weeutil.get_object(svc)(self, config_dict)
> Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__: File 
> "/home/weewx/bin/weeutil/weeutil.py", line 1093, in get_object
> Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   mod = 
> __import__(module)
> Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__: File 
> "/home/weewx/bin/user/forecast.py", line 541
> Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   except 
> OSError, e:
> Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   
>   ^
> Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   
> SyntaxError: invalid syntax
> Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   Exiting.
>
> Anyone know how to fix?
>
> Thanks!
>
> A.J.
>

-- 
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/01a907be-a5b0-4c60-ab05-d9bec141f646n%40googlegroups.com.

Re: [weewx-user] Question on Weewx, Vantage Vue, and CWOP

2021-01-10 Thread Garry A Lockyer

All that will get you is an average of crap altitude!  😀

Any agreement between GPS altitude and true elevation is merely a coincidence.

Regards,

Garry Lockyer
C: +1.250.689.0686
E: ga...@lockyer.ca


> On Jan 10, 2021, at 18:33, Brent Dowell  wrote:
> 
> Yeah, The first time I got the altitude I used a garmin gps and left it 
> running to average the altitude For a while.
> 
> Guess I'm just going to learn to deal with it.
>> On Sunday, January 10, 2021 at 6:24:56 PM UTC-8 garrya...@gmail.com wrote:
>> And this document explains why GPS altitude sucks (to be polite!):
>> 
>> http://www.montereysar.org/SARMembersDocs/UsingaGarminGPSwithPaperLandMaps_Manual.pdf
>> 
>> Regards,
>> 
>> Garry Lockyer
>> C: +1.250.689.0686
>> E: ga...@lockyer.ca
>> 
>> 
 On Jan 10, 2021, at 18:05, Brent Dowell  wrote:
 
>>> 
>> 
>>> 
>>> Thanks again!
>>> 
 On Sunday, January 10, 2021 at 6:02:00 PM UTC-8 tke...@gmail.com wrote:
 The note Derived variables from Davis has a pretty good discussion of this.
 
> On Sun, Jan 10, 2021 at 5:38 PM Brent Dowell  wrote:
> Correct Altitude is entered.  
> 
> I'm getting an average error of 3.5 millibars.
> 
> My altitude is pretty close to the local airport, and I used a fairly 
> calm day to adjust my barometer to match that.  Our altitude is also 
> relatively close, i.e. the airport is 4403ft and I'm at 4410.  Althought 
> that 4410 could be off, I had used that for my altitude for years.
> 
> Took another reading via gps today and have adjusted that to 4293, which 
> seems like it could be a significant differences.
> 
> Thanks so much for your help in getting me to understand it.  I've 
> managed to learn to ignore the wind errors, as I live on a hillside and 
> don't see anyway my wind data will ever match.  if I need to do that for 
> barometer, I'll work on it. lol.
> 
> Would just like to figure out what I'm doing wrong.
> 
> 
> 
> 
> 1. That you have a Vantage console;
>  Vantage Vue Console
> 2. That you are using regular LOOP packets, not the newer LOOP2 packets;
>  loop_request = 1
> 3. That you are using hardware record generation.
>  prefer_hardware
> 
> From the wee_device command.
> 
> BAROMETER CALIBRATION DATA:
>   Current barometer reading:30.222 inHg
>   Altitude: 4293 feet
>   Dew point:24 F
>   Virtual temperature:  32 F
>   Humidity correction factor:   1.1
>   Correction ratio: 1.175
>   Correction constant:  +0.000 inHg
>   Gain: 0.000
>   Offset:   -16.000
>
> 
>> On Sunday, January 10, 2021 at 5:01:53 PM UTC-8 tke...@gmail.com wrote:
>> I'm assuming:
>> 
>> 1. That you have a Vantage console;
>> 2. That you are using regular LOOP packets, not the newer LOOP2 packets;
>> 3. That you are using hardware record generation.
>> 
>> If all this is true, then what's happening is that WeeWX is downloading 
>> altitude and temperature corrected barometric data (what pilots call 
>> QFF) from the console. However, CWOP wants pressure corrected only for 
>> altitude (not temperature; pilots call this QNH). So, WeeWX uses an 
>> algorithm to calculate that. This is then what is uploaded.
>> 
>> First thing is to make sure you have the correct altitude entered in 
>> your console. You will also want to know whether the console is applying 
>> any barometric corrections. Both can be checked using the utility 
>> wee_device, with the --info command.
>> 
>> wee_device --info
>> 
>> This will tell you what altitude your console thinks it's at, as well as 
>> any barometric calibration data.
>> 
>> -tk
>> 
>> 
>> 
>>> On Sun, Jan 10, 2021 at 4:24 PM Brent Dowell  wrote:
>>> I've been chasing my tail a bit trying to get my data that I upload to 
>>> CWOP to pass the madis checks, which, from what I've read is a bit 
>>> problematic.
>>> 
>>> My question though is what should I have my console set as far as 
>>> altitude and barometer reduction. Right now I have it set for my 
>>> correct altitude and am using the altimeter setting. My readings are 
>>> consistently 'low' compared to the madis QC Check.
>>> 
>>> It looks like to me that the values being uploaded are in fact low  
>>> (raw aprs data) and do not match whats on my console.  So it appears 
>>> that weewx must be doing some altimeter calculation on my data and is 
>>> sending that on to cwop? I'm wondering if I'm missing a setting 
>>> somewhere in my weewx config to accout for that?
>>> 
>>> Some of the research I've done on the issue talks about davis being a 
>>> bit of a pain

Re: [weewx-user] Re: skin Belchertown " earth Quake"

You just need to delete the earthquake.json file and it recreates next 
cycle.

On Monday, 11 January 2021 at 13:55:46 UTC+11 pedal...@gmail.com wrote:

> Yeah, apparently I needed to wait for the next refresh. It is functioning 
> properly now.
>
> Thanks for checking though. 
>
> On Sun, Jan 10, 2021, 1:56 PM Colin Larsen  wrote:
>
>>
>>
>> I just looked at your site and the distance is in miles as I would expect 
>> for the US. What part do you think is buggy?
>>
>> Colin
>>
>> On Mon, 11 Jan 2021 at 03:48, John Mora  wrote:
>>
>>> I am following these threads with interest as my Belchertown 
>>> "Earthquake" is working but not as I desire it to work. The skin installed 
>>> without a hitch and is running but the Eathquake  distance is in km instead 
>>> of miles and I also tried to change the earthquake_maxradiuskm setting from 
>>> 1000 to 2000 and the changes aren't being reflected in the output.
>>>
>>> I've tried making changes to belchertown.py (
>>> https://github.com/poblabs/weewx-belchertown/issues/422) and changing 
>>> the skin.conf by setting the belchertown_locale from auto to en_US.UTF-8 
>>> and doing the locale-gen command to no avail.
>>>
>>> I will continue to follow this thread hoping that there is some final 
>>> solution as to why the Earthquake is "buggy". Thanks to all who post, you 
>>> have been a great help in trying to figure this anomaly out.
>>>
>>> my site: http://weather.codetales.com
>>>
>>>
>>>
>>>
>>> On Saturday, January 9, 2021 at 7:34:41 PM UTC-5 Greg from Oz wrote:
>>>
 Yes I did that to but it made no difference.

 You can change the locale = (in the belchertown skin.conf) to 
 "*en_AU.UTF-8" 
 *and that works  but if you leave it as auto and do the regen then it 
 works as expected.


 On Sunday, 10 January 2021 at 10:12:38 UTC+11 colin@gmail.com 
 wrote:

> My simple fix for this was to make sure that in weewx.conf (or 
> skin.conf if you prefer) you have under the stanza
>
> [[belchertown]]
> [[[units]]]
> groups
>
> An entry that says 
>
> group_distance = km
>
>
>
> On Sun, 10 Jan 2021 at 11:12, Greg from Oz  wrote:
>
>> Run the command: locale
>>
>> See if *LC_MEASUREMENT *is in your units
>>
>> If it is like this: *LC_MEASUREMENT="en_US.UTF-8" *the the 
>> measurement units will be in US (miles)
>>
>> To regenerate all your locale settings run: *locale-gen*
>>
>> There is a lot of discussion here: 
>> https://groups.google.com/g/weewx-user/c/BckKUHu2_DQ/m/30YJPrKkBwAJ
>>
>>
>> On Sunday, 10 January 2021 at 06:48:26 UTC+11 sali...@gmail.com 
>> wrote:
>>
>>> hello,
>>> in which file, can I modify miles in kilometers.
>>>
>>> inside joint file
>>>
>>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/06af1676-3a27-4989-945d-af379f5b1647n%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+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/544e2f70-aecc-4199-87bd-f8cd0940d371n%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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/CACjxfUt9vbjdz4AYF-hNQ2BSHGGcK22BfrGX0uTLuHxkZ43Q8A%40mail.gmail.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/93a8daac-4b27-4105-a4f4-57e078313b2fn%40googlegroups.com.

Re: [weewx-user] Re: skin Belchertown " earth Quake"

2021-01-10 Thread Quad

Yeah, apparently I needed to wait for the next refresh. It is functioning
properly now.

Thanks for checking though.

On Sun, Jan 10, 2021, 1:56 PM Colin Larsen  wrote:

>
>
> I just looked at your site and the distance is in miles as I would expect
> for the US. What part do you think is buggy?
>
> Colin
>
> On Mon, 11 Jan 2021 at 03:48, John Mora  wrote:
>
>> I am following these threads with interest as my Belchertown "Earthquake"
>> is working but not as I desire it to work. The skin installed without a
>> hitch and is running but the Eathquake  distance is in km instead of miles
>> and I also tried to change the earthquake_maxradiuskm setting from 1000 to
>> 2000 and the changes aren't being reflected in the output.
>>
>> I've tried making changes to belchertown.py (
>> https://github.com/poblabs/weewx-belchertown/issues/422) and changing
>> the skin.conf by setting the belchertown_locale from auto to en_US.UTF-8
>> and doing the locale-gen command to no avail.
>>
>> I will continue to follow this thread hoping that there is some final
>> solution as to why the Earthquake is "buggy". Thanks to all who post, you
>> have been a great help in trying to figure this anomaly out.
>>
>> my site: http://weather.codetales.com
>>
>>
>>
>>
>> On Saturday, January 9, 2021 at 7:34:41 PM UTC-5 Greg from Oz wrote:
>>
>>> Yes I did that to but it made no difference.
>>>
>>> You can change the locale = (in the belchertown skin.conf) to "*en_AU.UTF-8"
>>> *and that works  but if you leave it as auto and do the regen then it
>>> works as expected.
>>>
>>>
>>> On Sunday, 10 January 2021 at 10:12:38 UTC+11 colin@gmail.com wrote:
>>>
 My simple fix for this was to make sure that in weewx.conf (or
 skin.conf if you prefer) you have under the stanza

 [[belchertown]]
 [[[units]]]
 groups

 An entry that says

 group_distance = km



 On Sun, 10 Jan 2021 at 11:12, Greg from Oz  wrote:

> Run the command: locale
>
> See if *LC_MEASUREMENT *is in your units
>
> If it is like this: *LC_MEASUREMENT="en_US.UTF-8" *the the
> measurement units will be in US (miles)
>
> To regenerate all your locale settings run: *locale-gen*
>
> There is a lot of discussion here:
> https://groups.google.com/g/weewx-user/c/BckKUHu2_DQ/m/30YJPrKkBwAJ
>
>
> On Sunday, 10 January 2021 at 06:48:26 UTC+11 sali...@gmail.com wrote:
>
>> hello,
>> in which file, can I modify miles in kilometers.
>>
>> inside joint file
>>
>> 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+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/06af1676-3a27-4989-945d-af379f5b1647n%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/544e2f70-aecc-4199-87bd-f8cd0940d371n%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/CACjxfUt9vbjdz4AYF-hNQ2BSHGGcK22BfrGX0uTLuHxkZ43Q8A%40mail.gmail.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/CAFwm8YBUy1gWZ1uGFUYzzG%2BOUnPdSsEa9ENT9wSp04cwegSHCw%40mail.gmail.com.

[weewx-user] Re: HP1000 - fetching historical data

2021-01-10 Thread Susan Mackay

Nothing special is required. 

What it *should* do is to look at the date of the last database entry when 
the driver starts up. It also looks at the data available on the HP1000 
console and checks to see if there is data there that is AFTER the last 
database entry date - if so it should  request that before going on to read 
the 'current' data.

There might be a bug in the section of code that is executed when the 
database is empty (I must admit that I tested this once only when I was 
getting this started). To make sure that the 'history' records are being 
read, I suggest that you stop the weewx code for a little while and then 
start it up again while looking at the system log. You should see messages 
that it is reading the history and then later that it is reading the 
current data. If it is doing this correctly, then it means there is a bug 
in the 'unpopulated database' section of my code.

If it is still not reading the historical data then I'll need to see the 
logs and try to dig a bit deeper.

(Minor point: is the Froggit HP100SE console exactly the same as the Fine 
Offset HP1000? I'm clutching at straws here...)

Susan

On Sunday, 10 January 2021 at 7:40:16 am UTC+11 corp...@peter-lohmann.ch 
wrote:

>
> Hi all,
>
> I've configured Susan Makay's HP1000 driver and am successfully using it 
> with my HP1000SE. Now the GitHub Readme mentions:
> *"If weeWx has not been used before, this can take a while (about an hour 
> for each year in the archive) but it means that the weather station 
> historical data is made avialable to weeWx."*
> This apparently does not happen for me. I only get current data, even 
> though my station holds data back to 2016. Is there anything special for me 
> to configure so that the old data is pulled from the station?
>
> Thanks!
> P.
>

-- 
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/c4ab14f6-cac9-41e4-8bd0-0c88fc13b47bn%40googlegroups.com.

Re: [weewx-user] Question on Weewx, Vantage Vue, and CWOP

Yeah, The first time I got the altitude I used a garmin gps and left it 
running to average the altitude For a while.

Guess I'm just going to learn to deal with it.
On Sunday, January 10, 2021 at 6:24:56 PM UTC-8 garrya...@gmail.com wrote:

> And this document explains why GPS altitude sucks (to be polite!):
>
>
> http://www.montereysar.org/SARMembersDocs/UsingaGarminGPSwithPaperLandMaps_Manual.pdf
>
> Regards,
>
> Garry Lockyer
> C: +1.250.689.0686 <(250)%20689-0686>
> E: ga...@lockyer.ca
>
>
> On Jan 10, 2021, at 18:05, Brent Dowell  wrote:
>
> 
>
>
> Thanks again!
>
> On Sunday, January 10, 2021 at 6:02:00 PM UTC-8 tke...@gmail.com wrote:
>
>> The note *Derived variables 
>> *
>>  from 
>> Davis has a pretty good discussion of this.
>>
>> On Sun, Jan 10, 2021 at 5:38 PM Brent Dowell  wrote:
>>
>>> Correct Altitude is entered.  
>>>
>>> I'm getting an average error of 3.5 millibars.
>>>
>>> My altitude is pretty close to the local airport, and I used a fairly 
>>> calm day to adjust my barometer to match that.  Our altitude is also 
>>> relatively close, i.e. the airport is 4403ft and I'm at 4410.  Althought 
>>> that 4410 could be off, I had used that for my altitude for years.
>>>
>>> Took another reading via gps today and have adjusted that to 4293, which 
>>> seems like it could be a significant differences.
>>>
>>> Thanks so much for your help in getting me to understand it.  I've 
>>> managed to learn to ignore the wind errors, as I live on a hillside and 
>>> don't see anyway my wind data will ever match.  if I need to do that for 
>>> barometer, I'll work on it. lol.
>>>
>>> Would just like to figure out what I'm doing wrong.
>>>
>>>
>>>
>>>
>>> 1. That you have a Vantage console;
>>>  Vantage Vue Console
>>> 2. That you are using regular LOOP packets, not the newer LOOP2 packets;
>>>  loop_request = 1
>>> 3. That you are using hardware record generation.
>>>  prefer_hardware
>>>
>>> From the wee_device command.
>>>
>>> BAROMETER CALIBRATION DATA:
>>>   Current barometer reading:30.222 inHg
>>>   Altitude: 4293 feet
>>>   Dew point:24 F
>>>   Virtual temperature:  32 F
>>>   Humidity correction factor:   1.1
>>>   Correction ratio: 1.175
>>>   Correction constant:  +0.000 inHg
>>>   Gain: 0.000
>>>   Offset:   -16.000
>>>
>>>
>>> On Sunday, January 10, 2021 at 5:01:53 PM UTC-8 tke...@gmail.com wrote:
>>>
 I'm assuming:

 1. That you have a Vantage console;
 2. That you are using regular LOOP packets, not the newer LOOP2 packets;
 3. That you are using hardware record generation.

 If all this is true, then what's happening is that WeeWX is downloading 
 altitude and temperature corrected barometric data (what pilots call QFF) 
 from the console. However, CWOP wants pressure corrected only for altitude 
 (not temperature; pilots call this QNH). So, WeeWX uses an algorithm to 
 calculate that. This is then what is uploaded.

 First thing is to make sure you have the correct altitude entered in 
 your console. You will also want to know whether the console is applying 
 any barometric corrections. Both can be checked using the utility 
 wee_device, 
 with the --info  
 command.

 *wee_device --info*

 This will tell you what altitude your console thinks it's at, as well 
 as any barometric calibration data.

 -tk



 On Sun, Jan 10, 2021 at 4:24 PM Brent Dowell  
 wrote:

> I've been chasing my tail a bit trying to get my data that I upload to 
> CWOP to pass the madis checks, which, from what I've read is a bit 
> problematic.
>
> My question though is what should I have my console set as far as 
> altitude and barometer reduction. Right now I have it set for my correct 
> altitude and am using the altimeter setting. My readings are consistently 
> 'low' compared to the madis QC Check.
>
> It looks like to me that the values being uploaded are in fact low  
> (raw aprs data) and do not match whats on my console.  So it appears that 
> weewx must be doing some altimeter calculation on my data and is sending 
> that on to cwop? I'm wondering if I'm missing a setting somewhere in my 
> weewx config to accout for that?
>
> Some of the research I've done on the issue talks about davis being a 
> bit of a pain because they out put the altimeter corrected data already 
> and 
> that setting altitude to 0 and using the altimeter reduction fixes it?
>
> Sorry about dredging up an old issue, but I couldn't find much recent 
> information on this.
>
> Thanks in advan

Re: [weewx-user] Question on Weewx, Vantage Vue, and CWOP

2021-01-10 Thread Garry A Lockyer

And this document explains why GPS altitude sucks (to be polite!):

http://www.montereysar.org/SARMembersDocs/UsingaGarminGPSwithPaperLandMaps_Manual.pdf

Regards,

Garry Lockyer
C: +1.250.689.0686
E: ga...@lockyer.ca


> On Jan 10, 2021, at 18:05, Brent Dowell  wrote:
> 
> 
> Thanks again!
> 
>> On Sunday, January 10, 2021 at 6:02:00 PM UTC-8 tke...@gmail.com wrote:
>> The note Derived variables from Davis has a pretty good discussion of this.
>> 
>>> On Sun, Jan 10, 2021 at 5:38 PM Brent Dowell  wrote:
>>> Correct Altitude is entered.  
>>> 
>>> I'm getting an average error of 3.5 millibars.
>>> 
>>> My altitude is pretty close to the local airport, and I used a fairly calm 
>>> day to adjust my barometer to match that.  Our altitude is also relatively 
>>> close, i.e. the airport is 4403ft and I'm at 4410.  Althought that 4410 
>>> could be off, I had used that for my altitude for years.
>>> 
>>> Took another reading via gps today and have adjusted that to 4293, which 
>>> seems like it could be a significant differences.
>>> 
>>> Thanks so much for your help in getting me to understand it.  I've managed 
>>> to learn to ignore the wind errors, as I live on a hillside and don't see 
>>> anyway my wind data will ever match.  if I need to do that for barometer, 
>>> I'll work on it. lol.
>>> 
>>> Would just like to figure out what I'm doing wrong.
>>> 
>>> 
>>> 
>>> 
>>> 1. That you have a Vantage console;
>>>  Vantage Vue Console
>>> 2. That you are using regular LOOP packets, not the newer LOOP2 packets;
>>>  loop_request = 1
>>> 3. That you are using hardware record generation.
>>>  prefer_hardware
>>> 
>>> From the wee_device command.
>>> 
>>> BAROMETER CALIBRATION DATA:
>>>   Current barometer reading:30.222 inHg
>>>   Altitude: 4293 feet
>>>   Dew point:24 F
>>>   Virtual temperature:  32 F
>>>   Humidity correction factor:   1.1
>>>   Correction ratio: 1.175
>>>   Correction constant:  +0.000 inHg
>>>   Gain: 0.000
>>>   Offset:   -16.000
>>>
>>> 
 On Sunday, January 10, 2021 at 5:01:53 PM UTC-8 tke...@gmail.com wrote:
 I'm assuming:
 
 1. That you have a Vantage console;
 2. That you are using regular LOOP packets, not the newer LOOP2 packets;
 3. That you are using hardware record generation.
 
 If all this is true, then what's happening is that WeeWX is downloading 
 altitude and temperature corrected barometric data (what pilots call QFF) 
 from the console. However, CWOP wants pressure corrected only for altitude 
 (not temperature; pilots call this QNH). So, WeeWX uses an algorithm to 
 calculate that. This is then what is uploaded.
 
 First thing is to make sure you have the correct altitude entered in your 
 console. You will also want to know whether the console is applying any 
 barometric corrections. Both can be checked using the utility wee_device, 
 with the --info command.
 
 wee_device --info
 
 This will tell you what altitude your console thinks it's at, as well as 
 any barometric calibration data.
 
 -tk
 
 
 
> On Sun, Jan 10, 2021 at 4:24 PM Brent Dowell  wrote:
> I've been chasing my tail a bit trying to get my data that I upload to 
> CWOP to pass the madis checks, which, from what I've read is a bit 
> problematic.
> 
> My question though is what should I have my console set as far as 
> altitude and barometer reduction. Right now I have it set for my correct 
> altitude and am using the altimeter setting. My readings are consistently 
> 'low' compared to the madis QC Check.
> 
> It looks like to me that the values being uploaded are in fact low  (raw 
> aprs data) and do not match whats on my console.  So it appears that 
> weewx must be doing some altimeter calculation on my data and is sending 
> that on to cwop? I'm wondering if I'm missing a setting somewhere in my 
> weewx config to accout for that?
> 
> Some of the research I've done on the issue talks about davis being a bit 
> of a pain because they out put the altimeter corrected data already and 
> that setting altitude to 0 and using the altimeter reduction fixes it?
> 
> Sorry about dredging up an old issue, but I couldn't find much recent 
> information on this.
> 
> Thanks in advance for any help.
 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/d425ef32-4da0-49e1-b2d4-fd21dffdfbaen%40googlegroups.com.
>>> 
>>> -- 
>>> You received this messag

Re: [weewx-user] Tabular reports??

2021-01-10 Thread Ralph Peters

Thanks Tom!  It appears that Firefox has the same restriction on opening
files that Google Chrome does.
Ralph

On Sun, Jan 10, 2021 at 6:03 PM Tom Keffer  wrote:

> See this thread:
> https://groups.google.com/g/weewx-user/c/0FYwX4KGLu0/m/bCjCUsZ_BgAJ
>
> On Sun, Jan 10, 2021 at 3:13 PM rpet...@gmail.com 
> wrote:
>
>> Hello,
>>
>> If I try to look at an annual tabular report like the one at
>> /var/www/weewx/html/NOAA/NOAA-2020.txt *from* the main web page (
>> /var/www/weewx/html/index.html) using the drop-down menu in the upper right
>> corner of the main page, it fails.  Alll I get is:
>>
>> Loading NOAA/NOAA-2020.txt
>>
>> and nothing else
>>
>> The file NOAA-2020.txt is there!  I can look at it and it seems OK.
>>
>> Has anyone else seen this problem?
>>
>> NOTE1:  These files are put on Dropbox so that I can see them anywhere.
>> I am looking at all of the files mentioned above from a Dropbox folder.
>> Everything else (graphics) works fine - see attachment
>>
>> NOTE2: I have tried this with both the latest firefox and the latest
>> chrome and get the same result!
>>
>> Ideas?
>>
>> Thanks,
>> Ralph Peters
>>
>> --
>> 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/e6862b6d-f636-46e6-afe1-149c488fcf49n%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/cB0Of0a7xOA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAPq0zEAFPXpcz5%2BJnagFixsCUpGJQc43eeS%2BaYeSt2Zk9N6c%3Dw%40mail.gmail.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/CABshPJo0_6i91vhCXOtrVe_Jv5Ak1DrZkTiV9JZfND%2BM0_pNbw%40mail.gmail.com.

Re: [weewx-user] Question on Weewx, Vantage Vue, and CWOP


Thanks again!

On Sunday, January 10, 2021 at 6:02:00 PM UTC-8 tke...@gmail.com wrote:

> The note *Derived variables 
> *
>  from 
> Davis has a pretty good discussion of this.
>
> On Sun, Jan 10, 2021 at 5:38 PM Brent Dowell  wrote:
>
>> Correct Altitude is entered.  
>>
>> I'm getting an average error of 3.5 millibars.
>>
>> My altitude is pretty close to the local airport, and I used a fairly 
>> calm day to adjust my barometer to match that.  Our altitude is also 
>> relatively close, i.e. the airport is 4403ft and I'm at 4410.  Althought 
>> that 4410 could be off, I had used that for my altitude for years.
>>
>> Took another reading via gps today and have adjusted that to 4293, which 
>> seems like it could be a significant differences.
>>
>> Thanks so much for your help in getting me to understand it.  I've 
>> managed to learn to ignore the wind errors, as I live on a hillside and 
>> don't see anyway my wind data will ever match.  if I need to do that for 
>> barometer, I'll work on it. lol.
>>
>> Would just like to figure out what I'm doing wrong.
>>
>>
>>
>>
>> 1. That you have a Vantage console;
>>  Vantage Vue Console
>> 2. That you are using regular LOOP packets, not the newer LOOP2 packets;
>>  loop_request = 1
>> 3. That you are using hardware record generation.
>>  prefer_hardware
>>
>> From the wee_device command.
>>
>> BAROMETER CALIBRATION DATA:
>>   Current barometer reading:30.222 inHg
>>   Altitude: 4293 feet
>>   Dew point:24 F
>>   Virtual temperature:  32 F
>>   Humidity correction factor:   1.1
>>   Correction ratio: 1.175
>>   Correction constant:  +0.000 inHg
>>   Gain: 0.000
>>   Offset:   -16.000
>>
>>
>> On Sunday, January 10, 2021 at 5:01:53 PM UTC-8 tke...@gmail.com wrote:
>>
>>> I'm assuming:
>>>
>>> 1. That you have a Vantage console;
>>> 2. That you are using regular LOOP packets, not the newer LOOP2 packets;
>>> 3. That you are using hardware record generation.
>>>
>>> If all this is true, then what's happening is that WeeWX is downloading 
>>> altitude and temperature corrected barometric data (what pilots call QFF) 
>>> from the console. However, CWOP wants pressure corrected only for altitude 
>>> (not temperature; pilots call this QNH). So, WeeWX uses an algorithm to 
>>> calculate that. This is then what is uploaded.
>>>
>>> First thing is to make sure you have the correct altitude entered in 
>>> your console. You will also want to know whether the console is applying 
>>> any barometric corrections. Both can be checked using the utility 
>>> wee_device, 
>>> with the --info  
>>> command.
>>>
>>> *wee_device --info*
>>>
>>> This will tell you what altitude your console thinks it's at, as well as 
>>> any barometric calibration data.
>>>
>>> -tk
>>>
>>>
>>>
>>> On Sun, Jan 10, 2021 at 4:24 PM Brent Dowell  wrote:
>>>
 I've been chasing my tail a bit trying to get my data that I upload to 
 CWOP to pass the madis checks, which, from what I've read is a bit 
 problematic.

 My question though is what should I have my console set as far as 
 altitude and barometer reduction. Right now I have it set for my correct 
 altitude and am using the altimeter setting. My readings are consistently 
 'low' compared to the madis QC Check.

 It looks like to me that the values being uploaded are in fact low  
 (raw aprs data) and do not match whats on my console.  So it appears that 
 weewx must be doing some altimeter calculation on my data and is sending 
 that on to cwop? I'm wondering if I'm missing a setting somewhere in my 
 weewx config to accout for that?

 Some of the research I've done on the issue talks about davis being a 
 bit of a pain because they out put the altimeter corrected data already 
 and 
 that setting altitude to 0 and using the altimeter reduction fixes it?

 Sorry about dredging up an old issue, but I couldn't find much recent 
 information on this.

 Thanks in advance for any help.

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

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-u

Re: [weewx-user] Question on Weewx, Vantage Vue, and CWOP

The note *Derived variables
*
from
Davis has a pretty good discussion of this.

On Sun, Jan 10, 2021 at 5:38 PM Brent Dowell  wrote:

> Correct Altitude is entered.
>
> I'm getting an average error of 3.5 millibars.
>
> My altitude is pretty close to the local airport, and I used a fairly calm
> day to adjust my barometer to match that.  Our altitude is also relatively
> close, i.e. the airport is 4403ft and I'm at 4410.  Althought that 4410
> could be off, I had used that for my altitude for years.
>
> Took another reading via gps today and have adjusted that to 4293, which
> seems like it could be a significant differences.
>
> Thanks so much for your help in getting me to understand it.  I've managed
> to learn to ignore the wind errors, as I live on a hillside and don't see
> anyway my wind data will ever match.  if I need to do that for barometer,
> I'll work on it. lol.
>
> Would just like to figure out what I'm doing wrong.
>
>
>
>
> 1. That you have a Vantage console;
>  Vantage Vue Console
> 2. That you are using regular LOOP packets, not the newer LOOP2 packets;
>  loop_request = 1
> 3. That you are using hardware record generation.
>  prefer_hardware
>
> From the wee_device command.
>
> BAROMETER CALIBRATION DATA:
>   Current barometer reading:30.222 inHg
>   Altitude: 4293 feet
>   Dew point:24 F
>   Virtual temperature:  32 F
>   Humidity correction factor:   1.1
>   Correction ratio: 1.175
>   Correction constant:  +0.000 inHg
>   Gain: 0.000
>   Offset:   -16.000
>
>
> On Sunday, January 10, 2021 at 5:01:53 PM UTC-8 tke...@gmail.com wrote:
>
>> I'm assuming:
>>
>> 1. That you have a Vantage console;
>> 2. That you are using regular LOOP packets, not the newer LOOP2 packets;
>> 3. That you are using hardware record generation.
>>
>> If all this is true, then what's happening is that WeeWX is downloading
>> altitude and temperature corrected barometric data (what pilots call QFF)
>> from the console. However, CWOP wants pressure corrected only for altitude
>> (not temperature; pilots call this QNH). So, WeeWX uses an algorithm to
>> calculate that. This is then what is uploaded.
>>
>> First thing is to make sure you have the correct altitude entered in your
>> console. You will also want to know whether the console is applying any
>> barometric corrections. Both can be checked using the utility wee_device,
>> with the --info 
>> command.
>>
>> *wee_device --info*
>>
>> This will tell you what altitude your console thinks it's at, as well as
>> any barometric calibration data.
>>
>> -tk
>>
>>
>>
>> On Sun, Jan 10, 2021 at 4:24 PM Brent Dowell  wrote:
>>
>>> I've been chasing my tail a bit trying to get my data that I upload to
>>> CWOP to pass the madis checks, which, from what I've read is a bit
>>> problematic.
>>>
>>> My question though is what should I have my console set as far as
>>> altitude and barometer reduction. Right now I have it set for my correct
>>> altitude and am using the altimeter setting. My readings are consistently
>>> 'low' compared to the madis QC Check.
>>>
>>> It looks like to me that the values being uploaded are in fact low  (raw
>>> aprs data) and do not match whats on my console.  So it appears that weewx
>>> must be doing some altimeter calculation on my data and is sending that on
>>> to cwop? I'm wondering if I'm missing a setting somewhere in my weewx
>>> config to accout for that?
>>>
>>> Some of the research I've done on the issue talks about davis being a
>>> bit of a pain because they out put the altimeter corrected data already and
>>> that setting altitude to 0 and using the altimeter reduction fixes it?
>>>
>>> Sorry about dredging up an old issue, but I couldn't find much recent
>>> information on this.
>>>
>>> Thanks in advance for any help.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/d425ef32-4da0-49e1-b2d4-fd21dffdfbaen%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/49100cc7-7e2f-478f-9065-f0f42a92db3bn%40goo

Re: [weewx-user] Question on Weewx, Vantage Vue, and CWOP

Correct Altitude is entered.  

I'm getting an average error of 3.5 millibars.

My altitude is pretty close to the local airport, and I used a fairly calm 
day to adjust my barometer to match that.  Our altitude is also relatively 
close, i.e. the airport is 4403ft and I'm at 4410.  Althought that 4410 
could be off, I had used that for my altitude for years.

Took another reading via gps today and have adjusted that to 4293, which 
seems like it could be a significant differences.

Thanks so much for your help in getting me to understand it.  I've managed 
to learn to ignore the wind errors, as I live on a hillside and don't see 
anyway my wind data will ever match.  if I need to do that for barometer, 
I'll work on it. lol.

Would just like to figure out what I'm doing wrong.




1. That you have a Vantage console;
 Vantage Vue Console
2. That you are using regular LOOP packets, not the newer LOOP2 packets;
 loop_request = 1
3. That you are using hardware record generation.
 prefer_hardware

>From the wee_device command.

BAROMETER CALIBRATION DATA:
  Current barometer reading:30.222 inHg
  Altitude: 4293 feet
  Dew point:24 F
  Virtual temperature:  32 F
  Humidity correction factor:   1.1
  Correction ratio: 1.175
  Correction constant:  +0.000 inHg
  Gain: 0.000
  Offset:   -16.000
   

On Sunday, January 10, 2021 at 5:01:53 PM UTC-8 tke...@gmail.com wrote:

> I'm assuming:
>
> 1. That you have a Vantage console;
> 2. That you are using regular LOOP packets, not the newer LOOP2 packets;
> 3. That you are using hardware record generation.
>
> If all this is true, then what's happening is that WeeWX is downloading 
> altitude and temperature corrected barometric data (what pilots call QFF) 
> from the console. However, CWOP wants pressure corrected only for altitude 
> (not temperature; pilots call this QNH). So, WeeWX uses an algorithm to 
> calculate that. This is then what is uploaded.
>
> First thing is to make sure you have the correct altitude entered in your 
> console. You will also want to know whether the console is applying any 
> barometric corrections. Both can be checked using the utility wee_device, 
> with the --info  
> command.
>
> *wee_device --info*
>
> This will tell you what altitude your console thinks it's at, as well as 
> any barometric calibration data.
>
> -tk
>
>
>
> On Sun, Jan 10, 2021 at 4:24 PM Brent Dowell  wrote:
>
>> I've been chasing my tail a bit trying to get my data that I upload to 
>> CWOP to pass the madis checks, which, from what I've read is a bit 
>> problematic.
>>
>> My question though is what should I have my console set as far as 
>> altitude and barometer reduction. Right now I have it set for my correct 
>> altitude and am using the altimeter setting. My readings are consistently 
>> 'low' compared to the madis QC Check.
>>
>> It looks like to me that the values being uploaded are in fact low  (raw 
>> aprs data) and do not match whats on my console.  So it appears that weewx 
>> must be doing some altimeter calculation on my data and is sending that on 
>> to cwop? I'm wondering if I'm missing a setting somewhere in my weewx 
>> config to accout for that?
>>
>> Some of the research I've done on the issue talks about davis being a bit 
>> of a pain because they out put the altimeter corrected data already and 
>> that setting altitude to 0 and using the altimeter reduction fixes it?
>>
>> Sorry about dredging up an old issue, but I couldn't find much recent 
>> information on this.
>>
>> Thanks in advance for any help.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/d425ef32-4da0-49e1-b2d4-fd21dffdfbaen%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/49100cc7-7e2f-478f-9065-f0f42a92db3bn%40googlegroups.com.

Re: [weewx-user] Tabular reports??

See this thread:
https://groups.google.com/g/weewx-user/c/0FYwX4KGLu0/m/bCjCUsZ_BgAJ

On Sun, Jan 10, 2021 at 3:13 PM rpet...@gmail.com 
wrote:

> Hello,
>
> If I try to look at an annual tabular report like the one at
> /var/www/weewx/html/NOAA/NOAA-2020.txt *from* the main web page (
> /var/www/weewx/html/index.html) using the drop-down menu in the upper right
> corner of the main page, it fails.  Alll I get is:
>
> Loading NOAA/NOAA-2020.txt
>
> and nothing else
>
> The file NOAA-2020.txt is there!  I can look at it and it seems OK.
>
> Has anyone else seen this problem?
>
> NOTE1:  These files are put on Dropbox so that I can see them anywhere.  I
> am looking at all of the files mentioned above from a Dropbox folder.
> Everything else (graphics) works fine - see attachment
>
> NOTE2: I have tried this with both the latest firefox and the latest
> chrome and get the same result!
>
> Ideas?
>
> Thanks,
> Ralph Peters
>
> --
> 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/e6862b6d-f636-46e6-afe1-149c488fcf49n%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/CAPq0zEAFPXpcz5%2BJnagFixsCUpGJQc43eeS%2BaYeSt2Zk9N6c%3Dw%40mail.gmail.com.

Re: [weewx-user] Question on Weewx, Vantage Vue, and CWOP

I'm assuming:

1. That you have a Vantage console;
2. That you are using regular LOOP packets, not the newer LOOP2 packets;
3. That you are using hardware record generation.

If all this is true, then what's happening is that WeeWX is downloading
altitude and temperature corrected barometric data (what pilots call QFF)
from the console. However, CWOP wants pressure corrected only for altitude
(not temperature; pilots call this QNH). So, WeeWX uses an algorithm to
calculate that. This is then what is uploaded.

First thing is to make sure you have the correct altitude entered in your
console. You will also want to know whether the console is applying any
barometric corrections. Both can be checked using the utility wee_device,
with the --info 
command.

*wee_device --info*

This will tell you what altitude your console thinks it's at, as well as
any barometric calibration data.

-tk

On Sun, Jan 10, 2021 at 4:24 PM Brent Dowell  wrote:

> I've been chasing my tail a bit trying to get my data that I upload to
> CWOP to pass the madis checks, which, from what I've read is a bit
> problematic.
>
> My question though is what should I have my console set as far as altitude
> and barometer reduction. Right now I have it set for my correct altitude
> and am using the altimeter setting. My readings are consistently 'low'
> compared to the madis QC Check.
>
> It looks like to me that the values being uploaded are in fact low  (raw
> aprs data) and do not match whats on my console.  So it appears that weewx
> must be doing some altimeter calculation on my data and is sending that on
> to cwop? I'm wondering if I'm missing a setting somewhere in my weewx
> config to accout for that?
>
> Some of the research I've done on the issue talks about davis being a bit
> of a pain because they out put the altimeter corrected data already and
> that setting altitude to 0 and using the altimeter reduction fixes it?
>
> Sorry about dredging up an old issue, but I couldn't find much recent
> information on this.
>
> Thanks in advance for any help.
>
> --
> 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/d425ef32-4da0-49e1-b2d4-fd21dffdfbaen%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/CAPq0zEDUbXKV8tXqmyKubdfYKTHAYWBQLVHGdxTBZS9HQiAR0A%40mail.gmail.com.

[weewx-user] 4.3.0 installation issue

2021-01-10 Thread WxManAJB

Hi all...probably something very simple here, but I'm stuck...

Just upgraded to 4.3.0 (setup.py method on raspbian stretch/python3) and 
I'm getting the following error in my syslog:

Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   
self.loadServices(config_dict)
Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__: File 
"/home/weewx/bin/weewx/engine.py", line 161, in loadServices
Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   obj = 
weeutil.weeutil.get_object(svc)(self, config_dict)
Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__: File 
"/home/weewx/bin/weeutil/weeutil.py", line 1093, in get_object
Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   mod = 
__import__(module)
Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__: File 
"/home/weewx/bin/user/forecast.py", line 541
Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   except 
OSError, e:
Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   
  ^
Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   SyntaxError: 
invalid syntax
Jan 10 19:25:23 wxstn1 weewx[566] CRITICAL __main__:   Exiting.

Anyone know how to fix?

Thanks!

A.J.

-- 
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/3f34a95c-81ae-470b-a405-3844c5d5a8a0n%40googlegroups.com.

[weewx-user] Question on Weewx, Vantage Vue, and CWOP

I've been chasing my tail a bit trying to get my data that I upload to CWOP 
to pass the madis checks, which, from what I've read is a bit problematic.

My question though is what should I have my console set as far as altitude 
and barometer reduction. Right now I have it set for my correct altitude 
and am using the altimeter setting. My readings are consistently 'low' 
compared to the madis QC Check.

It looks like to me that the values being uploaded are in fact low  (raw 
aprs data) and do not match whats on my console.  So it appears that weewx 
must be doing some altimeter calculation on my data and is sending that on 
to cwop? I'm wondering if I'm missing a setting somewhere in my weewx 
config to accout for that?

Some of the research I've done on the issue talks about davis being a bit 
of a pain because they out put the altimeter corrected data already and 
that setting altitude to 0 and using the altimeter reduction fixes it?

Sorry about dredging up an old issue, but I couldn't find much recent 
information on this.

Thanks in advance for any help.

-- 
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/d425ef32-4da0-49e1-b2d4-fd21dffdfbaen%40googlegroups.com.

Re: [weewx-user] Independent weewx backup script

This comes up very frequently as new weewx users come onboard.   Take a 
look back at the weewx-users archives for lots of previous (excellent) 
discussions for how to automate backing up your db and 'verifying' that the 
backup is restorable.

There's an old sysadmin credo saying that if you haven't tried a restore, 
you didn't really do a backup.  Believe it.  Been there.

There was a long discussion years ago (HERE) 
 where lots of folks 
went through the pros+cons and how they approach the problem.  The short 
answer is to use the 'pragma integrity_check' command in sqlite3 to 
validate your backups are good.   Other finding was that you probably don't 
need to shut weewx down to do a backup.

The canonical way at that time seemed to be:

   - copy your database to /var/tmp or something to make a copy of the 
   running db
   - use sqlite3 commands to dump 'that' to a text file
   - gzip the dump file up and save it someplace on another system
   - delete your scratch copy of the db

Lots of people have posted a variety of ways to do this with Dropbox, 
Amazon S3, and simple scp commands, so dig around in the archives a bit for 
some options.

FWIW, back then I found experimentally that a simple '*copy the database, 
then gzip the copy and save it'* was good enough.  I went back 100 backups 
and verified that all the backups were good, so I personally don't bother 
doing a .dump of the db to save a copy.  I just make a copy of the current 
db and compress+save the copy. The script I cooked up years ago that has 
always worked for me is (HERE) 
 on Github.

On Sunday, January 10, 2021 at 2:32:47 PM UTC-8 stelli...@gmail.com wrote:

> Good point. Doing all this without stopping weewx is much nicer. In fact, 
> after a year of data (in my case), the sqlite3 approach will not take that 
> long. I will try that as well.
>
> I see that data backup seems to be a hot topic...
>
> tke...@gmail.com schrieb am Sonntag, 10. Januar 2021 um 14:39:13 UTC+1:
>
>> Your approach will certainly work, but requires stopping weewxd for what 
>> could potentially be a long period of time, so you might miss a weather 
>> event.
>>
>> Another approach is to use the sqlite3 ".backup" command. Replace your 
>> tar command with
>>
>> tar czf $dest/$archive_file $backup_files2 $backup_files3 $backup_files4
>> sqlite3 $backup_files1 ".backup $dest/$backup_files1.backup"
>>
>> This avoids stopping weewxd, because the sqlite3 utility will take care 
>> of any necessary locking. However, it has the disadvantage that if sqlite3 
>> holds on to the lock for too long, a database write will get delayed and, 
>> ultimately, could time out, causing weewxd to restart.
>>
>> Finally, the most sophisticated approach is to incrementally back up the 
>> database. Take a look at this page on backing up a running database 
>> . It copies a number of database pages, 
>> then releases the lock, sleeps for a bit to allow other processes to gain 
>> access to the database, then goes on to the next set of pages. This allows 
>> the database to be backed up without stopping weewxd, and without the 
>> potential hazard of a database timeout.
>>
>> Something to think about...
>>
>> -tk
>>
>>
>>
>> On Sun, Jan 10, 2021 at 4:01 AM Jan Stelling  wrote:
>>
>>> For some time, I was looking for an easy and independent (from weewx) 
>>> way to automatically backup my weewx data, as I do not want to lose data if 
>>> the Micro SD breaks down.
>>> Recently, I found this small repo 
>>>  on github which only 
>>> contains a backup script file. It mounts a USB drive, stops weewx, creates 
>>> an archived backup of the most relevant user files and folders on the USB 
>>> drive, unmounts the drive and restarts weewx.
>>>
>>> This was almost perfect for me, but I had to introduce some changes to 
>>> make it suitable for my environment. I forked it 
>>>  to make it available for 
>>> others. It now does the following:
>>>
>>>1. Stop weewx
>>>2. Create an archived backup on a mounted network drive (under 
>>>/home/pi/Shares/Temp)
>>>3. Start weewx
>>>
>>> I tested it manually and running via crontab on my RasPi 3B.
>>>
>>> Maybe this is useful for some of you...
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/2671c065-719a-4435-9657-06841af8fed7n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this mes

Re: [weewx-user] 4.2 to 4.3 RPi not running anymore - installed on RPi with Deb

2021-01-10 Thread didier belin

Good evening,

since an update of weewx, here is a problem:

n 10 23:04:14 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:14 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:16 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:16 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:19 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:21 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:25 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
poll packet
Jan 10 23:04:25 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:26 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:29 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:29 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:31 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:31 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:34 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:34 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
push (broadcast) packet
Jan 10 23:04:36 weewx3 weewx [12717] INFO user.weatherlink_live: Emitting 
poll packet
at a (random) moment the poll packet stops and therefore no more data, I 
have to restart. any idea where the problem may come from? weewx or the 
WeatherLive Link?

Likewise for the belchertown skin, the almanac has disappeared and the 
graph representing the solar radiation only represents the measured value 
and no longer the predicted value (calculated via the pyepehem module) the 
two elements functioning before the update.

Le samedi 9 janvier 2021 à 21:27:24 UTC+1, gjr80 a écrit :

> And it’s worth pointing out no matter how you do the install a copy of the 
> old (pre-upgrade) config file is retained (refer to the Upgrade Guide for 
> naming details) so it is a simple matter to compare/update config files if 
> any extras don’t seem to be working post upgrade.
>
> Gary
> On Sunday, 10 January 2021 at 04:10:58 UTC+10 vince wrote:
>
>> On Friday, January 8, 2021 at 10:02:38 PM UTC-8 misk...@gmail.com wrote:
>>
>>> What about making a python script to make the [apt-get] update work?
>>>
>>>
>> I'd suggest simply following the Upgrade Guide which says which 'two' 
>> commands to issue.
>> I think we're over-optimizing at this point.
>>
>> There are lots of ways to get there equally well.
>> Same thing happens on the RHEL-compatible side with yum vs. rpm commands 
>> that install/upgrade packages.
>>  
>>
>>

-- 
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/e772b9ae-19dc-451b-99bb-f73baad06b4cn%40googlegroups.com.

Re: [weewx-user] Re: skin Belchertown " earth Quake"

My site is here: https://weather.ubeaut.work/belchertown/
It shows km and km in the earthquake section.

On Monday, 11 January 2021 at 07:30:10 UTC+11 Greg from Oz wrote:

> Try deleting the earthquake.json file as the earthequake stuff gets 
> regenerated every 3 hours by default. So you might have to wait 3 hours 
> before noticing any changes.
>
> The json file will be recreated the next reporting run.
>
> The file is here: 
> /var/www/html//belchertown/json/earthquake.json
>
>
>
> On Monday, 11 January 2021 at 07:04:21 UTC+11 sali...@gmail.com wrote:
>
>> hello,
>>
>> I done your suggestion but it is always the samethings , earthquake in 
>> Miles.
>>
>> in my fil weewx.conf:
>>
>> [[[Extras]]]
>>
>> # General Site Defaults
>> belchertown_root_url = 
>> http://jurassikpat.ddns.net/weewx/belchertown
>> belchertown_locale = "auto"
>>
>>  Groups
>>
>> group_altitude = meter# Options are 'foot' or 'meter'
>> group_degree_day = degree_C_day# Options are 
>> 'degree_F_day'$
>> group_distance = km# Options are 'mile' or 'km'
>>
>> pi@raspberrypi:~ $ locale
>> LANG=fr_FR.UTF-8
>> LANGUAGE=fr_FR.UTF-8
>> LC_CTYPE="fr_FR.UTF-8"
>> LC_NUMERIC="fr_FR.UTF-8"
>> LC_TIME="fr_FR.UTF-8"
>> LC_COLLATE="fr_FR.UTF-8"
>> LC_MONETARY="fr_FR.UTF-8"
>> LC_MESSAGES="fr_FR.UTF-8"
>> LC_PAPER="fr_FR.UTF-8"
>> LC_NAME="fr_FR.UTF-8"
>> LC_ADDRESS="fr_FR.UTF-8"
>> LC_TELEPHONE="fr_FR.UTF-8"
>> LC_MEASUREMENT="fr_FR.UTF-8"
>> LC_IDENTIFICATION="fr_FR.UTF-8"
>> LC_ALL=fr_FR.UTF-8
>>
>> I don't understand
>>
>> patrick
>>
>>
>> Le 10/01/2021 à 01:34, Greg from Oz a écrit :
>>
>> Yes I did that to but it made no difference. 
>>
>> You can change the locale = (in the belchertown skin.conf) to "*en_AU.UTF-8" 
>> *and that works  but if you leave it as auto and do the regen then it 
>> works as expected.
>>
>>
>> On Sunday, 10 January 2021 at 10:12:38 UTC+11 colin@gmail.com wrote:
>>
>>> My simple fix for this was to make sure that in weewx.conf (or skin.conf 
>>> if you prefer) you have under the stanza
>>>
>>> [[belchertown]]
>>> [[[units]]]
>>> groups
>>>
>>> An entry that says 
>>>
>>> group_distance = km
>>>
>>>
>>>
>>> On Sun, 10 Jan 2021 at 11:12, Greg from Oz  wrote:
>>>
 Run the command: locale 

 See if *LC_MEASUREMENT *is in your units

 If it is like this: *LC_MEASUREMENT="en_US.UTF-8" *the the measurement 
 units will be in US (miles)

 To regenerate all your locale settings run: *locale-gen*

 There is a lot of discussion here: 
 https://groups.google.com/g/weewx-user/c/BckKUHu2_DQ/m/30YJPrKkBwAJ


 On Sunday, 10 January 2021 at 06:48:26 UTC+11 sali...@gmail.com wrote:

> hello,
> in which file, can I modify miles in kilometers.
>
> inside joint file
>
> 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+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/06af1676-3a27-4989-945d-af379f5b1647n%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+...@googlegroups.com.
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/c6dcdfc7-8a99-423e-bc06-8a5fbde0df1fn%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/a8826cec-1bb6-4882-8b9a-62adcade879an%40googlegroups.com.

[weewx-user] Re: weewx stopped Jan 1st, 2021

WOW !!! It works again! Thanks so much for your fast help!

vince schrieb am Sonntag, 10. Januar 2021 um 22:10:14 UTC+1:

> On Sunday, January 10, 2021 at 11:46:15 AM UTC-8 marb...@gmail.com wrote:
>
>> Jan 10 20:28:11 MyServer python2[28539]: weewx[28539] CRITICAL 
>> __main__:   IntervalError: Non-positive value for record field 
>> 'interval': 0
>> Jan 10 20:28:11 MyServer python2[28539]: weewx[28539] CRITICAL 
>> __main__:   Exiting.
>>
>>
>>
>
> There was just another thread about this a day or two ago.  You have to do 
> a little cleanup of your database to remove some odd old records.
>
> See https://groups.google.com/g/weewx-user/c/cPTRWVE2lBE/m/ejDCU-WMBgAJ 
> for details
>  
>

-- 
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/b1146dd9-99d2-46c2-ac12-a3001c5c7017n%40googlegroups.com.

Re: [weewx-user] Independent weewx backup script

2021-01-10 Thread Jan Stelling

Good point. Doing all this without stopping weewx is much nicer. In fact, 
after a year of data (in my case), the sqlite3 approach will not take that 
long. I will try that as well.

I see that data backup seems to be a hot topic...

tke...@gmail.com schrieb am Sonntag, 10. Januar 2021 um 14:39:13 UTC+1:

> Your approach will certainly work, but requires stopping weewxd for what 
> could potentially be a long period of time, so you might miss a weather 
> event.
>
> Another approach is to use the sqlite3 ".backup" command. Replace your tar 
> command with
>
> tar czf $dest/$archive_file $backup_files2 $backup_files3 $backup_files4
> sqlite3 $backup_files1 ".backup $dest/$backup_files1.backup"
>
> This avoids stopping weewxd, because the sqlite3 utility will take care of 
> any necessary locking. However, it has the disadvantage that if sqlite3 
> holds on to the lock for too long, a database write will get delayed and, 
> ultimately, could time out, causing weewxd to restart.
>
> Finally, the most sophisticated approach is to incrementally back up the 
> database. Take a look at this page on backing up a running database 
> . It copies a number of database pages, 
> then releases the lock, sleeps for a bit to allow other processes to gain 
> access to the database, then goes on to the next set of pages. This allows 
> the database to be backed up without stopping weewxd, and without the 
> potential hazard of a database timeout.
>
> Something to think about...
>
> -tk
>
>
>
> On Sun, Jan 10, 2021 at 4:01 AM Jan Stelling  wrote:
>
>> For some time, I was looking for an easy and independent (from weewx) way 
>> to automatically backup my weewx data, as I do not want to lose data if the 
>> Micro SD breaks down.
>> Recently, I found this small repo 
>>  on github which only 
>> contains a backup script file. It mounts a USB drive, stops weewx, creates 
>> an archived backup of the most relevant user files and folders on the USB 
>> drive, unmounts the drive and restarts weewx.
>>
>> This was almost perfect for me, but I had to introduce some changes to 
>> make it suitable for my environment. I forked it 
>>  to make it available for 
>> others. It now does the following:
>>
>>1. Stop weewx
>>2. Create an archived backup on a mounted network drive (under 
>>/home/pi/Shares/Temp)
>>3. Start weewx
>>
>> I tested it manually and running via crontab on my RasPi 3B.
>>
>> Maybe this is useful for some of you...
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/2671c065-719a-4435-9657-06841af8fed7n%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/34b8ea9d-78ff-472d-b4fb-513d6b7f6935n%40googlegroups.com.

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

2021-01-10 Thread Steven Sheeley

The newly displayed "sig_" values, i.e "  wh??_ch?_sig ", etc, indicate 
signal strength between the GW1000 and the sensor in "Bars" from 1 to 4 
bars of "strength" as seen on the wsview app when looking at the sensor 
page.

On Monday, January 11, 2021 at 6:12:43 AM UTC+11 vince wrote:

> Perfect.  Thanks.  That's what I was looking for.
>
> On Saturday, January 9, 2021 at 8:11:23 PM UTC-8 gjr80 wrote:
>
>> OK, maybe I am mis-reading your post and what you want/expect to 'see'. 
>> When I said "*displaying the GW1000 and sensor configuration information 
>> currently only available through the WS View app*" I meant everything 
>> you can access under the menu in the top right hand corner of the WS View 
>> App (believe that is the '*More*' menu in both the Android and Apple 
>> apps). The --get- command line options should correspond closely to the 
>> item names under the '*More*' menu and each should present the same info 
>> on screen as fund under the respective '*Menu*' sub-menu. You certainly 
>> should be able to see calibration offsets but of course not in --live-data 
>> or loop packets.
>>
>> The release notes from the v0.2.0 release on GitHub gives a better run 
>> down:
>>
>>- added --get-services command line option to display GW1000 
>>supported weather services settings
>>- added --get-pm25-offset command line option to display GW1000 PM2.5 
>>sensor offset settings
>>- added --get-mulch-offset command line option to display GW1000 
>>multi-channel TH sensor calibration settings
>>- added --get-soil-calibration command line option to display GW1000 
>>soil moisture sensor calibration settings
>>- added --get-calibration command line option to display GW1000 
>>sensor calibration settings
>>- renamed --rain-data command line option to --get-rain-data
>>
>>
>> Gary
>> On Sunday, 10 January 2021 at 13:15:58 UTC+10 vince wrote:
>>
>>> My gear is all working fine.  I probably misread your note a bit, 
>>> thinking that "*displaying the GW1000 and sensor configuration 
>>> information currently only available through the WS View app*" included 
>>> seeing the calibration offsets we do in their app after finding them buried 
>>> down in that brutal GUI they provide.   I did see the --sensors option 
>>> which was pretty interesting though.  No problems here at all.  Works 
>>> great.  Thanks.
>>>
>>> On Saturday, January 9, 2021 at 1:48:13 PM UTC-8 gjr80 wrote:
>>>
 On Sunday, 10 January 2021 at 07:37:10 UTC+10 vince wrote:

> On Saturday, January 9, 2021 at 12:20:38 PM UTC-8 gjr80 wrote:
>
>> On Sunday, 10 January 2021 at 05:44:27 UTC+10 vince wrote:
>>
>>> Works great here, thanks.   Also liked the wiki pages.
>>>
>>> I noted the new (?) _sig values in --live-data
>>>
>> Mine all show a value of 4
>>>
>> I'm assuming the values are 0-4 where 4 is best (???)
>>>
>> The Sensor battery states 
>>  
>> wiki page provides details on sensor battery states reported by the 
>> driver; 
>> basically the meaning depends on the sensor concerned.
>>
>
> Yes, saw that...but I was asking about the sig(nal?) status fields in 
> the new version.
>

 Yes you did, sorry too early here. The API documentation provides no 
 real info on what signal level means, my understanding is it is not a true 
 signal level like we normally understand signal level to be, but rather it 
 is an indicator of whether the most recent broadcasts have been received 
 from the sensor. But yes more is better.


> And are the calibration things available in the --live-data 
> information ?
> I have my sensors slightly calibrated, but don't see any of that info 
> in the --live-data output.
>
> GW1000 live sensor data: absbarometer: 1014.3, datetime: 1610218338, 
> humid1: 38, humid2: 41, inhumid: 39, intemp: 21.1, outhumid: 98, outtemp: 
> 1.4, relbarometer: 1025.8, soilmoist1: 38, temp1: 20.7, temp2: 19.7, 
> wh26_batt: 0, wh26_sig: 4, wh31_ch1_batt: 0, wh31_ch1_sig: 4, 
> wh31_ch2_batt: 0, wh31_ch2_sig: 4, wh51_ch1_batt: 0, wh51_ch1_sig: 4
>
> I guess I'm struggling a little with how to display all the new cool 
> stuff and what the units are, especially since the API isn't public yet 
> it 
> seems.
>

 Calibration data is not explicitly included in the —live-data output, 
 though any relevant calibration data should have been applied to sensor 
 data in the —live-data output. I have not explicitly tested that though. 
 What units do you have a problem with?
  
 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 th

[weewx-user] Re: weewx stopped Jan 1st, 2021

oops - sorry - it is /var/lib/weewx/weewx.sdb  if you installed via the 
packaged installer.

On Sunday, January 10, 2021 at 1:59:42 PM UTC-8 vince wrote:

> You spelled it wrong - it's /var/lib/weewx.sdb
> You might also need to preface your command with 'sudo'
>
>
> On Sunday, January 10, 2021 at 1:50:24 PM UTC-8 marb...@gmail.com wrote:
>
>> I have already read this thread. But I did not succeed. As written I have 
>> installed  sqlite3 but I can't get very far
>>
>>
>> linaro@MyServer:~$ sqlite3 /var/weewx/weedwx.sdb
>> SQLite version 3.11.0 2016-02-15 17:29:24
>> Enter ".help" for usage hints.
>> sqlite> select dateTime, datetime(dateTime, 'unixepoch', 'localtime'), 
>> interval from archive where interval<=0;
>> Error: unable to open database "/var/weewx/weedwx.sdb": unable to open 
>> database file
>> linaro@MyServer:~$ 
>>
>> vince schrieb am Sonntag, 10. Januar 2021 um 22:10:14 UTC+1:
>>
>>> On Sunday, January 10, 2021 at 11:46:15 AM UTC-8 marb...@gmail.com 
>>> wrote:
>>>
 Jan 10 20:28:11 MyServer python2[28539]: weewx[28539] CRITICAL 
 __main__:   IntervalError: Non-positive value for record field 
 'interval': 0
 Jan 10 20:28:11 MyServer python2[28539]: weewx[28539] CRITICAL 
 __main__:   Exiting.



>>>
>>> There was just another thread about this a day or two ago.  You have to 
>>> do a little cleanup of your database to remove some odd old records.
>>>
>>> See https://groups.google.com/g/weewx-user/c/cPTRWVE2lBE/m/ejDCU-WMBgAJ 
>>> for details
>>>  
>>>
>>

-- 
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/3dbdab02-f587-426a-b93f-4f7b75d70904n%40googlegroups.com.

[weewx-user] Re: weewx stopped Jan 1st, 2021

You spelled it wrong - it's /var/lib/weewx.sdb
You might also need to preface your command with 'sudo'


On Sunday, January 10, 2021 at 1:50:24 PM UTC-8 marb...@gmail.com wrote:

> I have already read this thread. But I did not succeed. As written I have 
> installed  sqlite3 but I can't get very far
>
>
> linaro@MyServer:~$ sqlite3 /var/weewx/weedwx.sdb
> SQLite version 3.11.0 2016-02-15 17:29:24
> Enter ".help" for usage hints.
> sqlite> select dateTime, datetime(dateTime, 'unixepoch', 'localtime'), 
> interval from archive where interval<=0;
> Error: unable to open database "/var/weewx/weedwx.sdb": unable to open 
> database file
> linaro@MyServer:~$ 
>
> vince schrieb am Sonntag, 10. Januar 2021 um 22:10:14 UTC+1:
>
>> On Sunday, January 10, 2021 at 11:46:15 AM UTC-8 marb...@gmail.com wrote:
>>
>>> Jan 10 20:28:11 MyServer python2[28539]: weewx[28539] CRITICAL 
>>> __main__:   IntervalError: Non-positive value for record field 
>>> 'interval': 0
>>> Jan 10 20:28:11 MyServer python2[28539]: weewx[28539] CRITICAL 
>>> __main__:   Exiting.
>>>
>>>
>>>
>>
>> There was just another thread about this a day or two ago.  You have to 
>> do a little cleanup of your database to remove some odd old records.
>>
>> See https://groups.google.com/g/weewx-user/c/cPTRWVE2lBE/m/ejDCU-WMBgAJ 
>> for details
>>  
>>
>

-- 
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/46f79fe7-0a74-42ac-a66f-a22cc8512ac3n%40googlegroups.com.

[weewx-user] Re: weewx stopped Jan 1st, 2021

I have already read this thread. But I did not succeed. As written I have 
installed  sqlite3 but I can't get very far

linaro@MyServer:~$ sqlite3 /var/weewx/weedwx.sdb
SQLite version 3.11.0 2016-02-15 17:29:24
Enter ".help" for usage hints.
sqlite> select dateTime, datetime(dateTime, 'unixepoch', 'localtime'), 
interval from archive where interval<=0;
Error: unable to open database "/var/weewx/weedwx.sdb": unable to open 
database file
linaro@MyServer:~$ 

vince schrieb am Sonntag, 10. Januar 2021 um 22:10:14 UTC+1:

> On Sunday, January 10, 2021 at 11:46:15 AM UTC-8 marb...@gmail.com wrote:
>
>> Jan 10 20:28:11 MyServer python2[28539]: weewx[28539] CRITICAL 
>> __main__:   IntervalError: Non-positive value for record field 
>> 'interval': 0
>> Jan 10 20:28:11 MyServer python2[28539]: weewx[28539] CRITICAL 
>> __main__:   Exiting.
>>
>>
>>
>
> There was just another thread about this a day or two ago.  You have to do 
> a little cleanup of your database to remove some odd old records.
>
> See https://groups.google.com/g/weewx-user/c/cPTRWVE2lBE/m/ejDCU-WMBgAJ 
> for details
>  
>

-- 
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/a1fe5974-9027-42de-8aac-c803436980d1n%40googlegroups.com.

[weewx-user] Re: weewx stopped Jan 1st, 2021

On Sunday, January 10, 2021 at 11:46:15 AM UTC-8 marb...@gmail.com wrote:

> Jan 10 20:28:11 MyServer python2[28539]: weewx[28539] CRITICAL 
> __main__:   IntervalError: Non-positive value for record field 
> 'interval': 0
> Jan 10 20:28:11 MyServer python2[28539]: weewx[28539] CRITICAL 
> __main__:   Exiting.
>
>
>

There was just another thread about this a day or two ago.  You have to do 
a little cleanup of your database to remove some odd old records.

See https://groups.google.com/g/weewx-user/c/cPTRWVE2lBE/m/ejDCU-WMBgAJ for 
details
 

-- 
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/80ac60ab-7f99-40b6-9550-547a8da520ccn%40googlegroups.com.

Re: [weewx-user] Independent weewx backup script

I use mysql and keep a week of files which are backed up to another server. 
I use the name of the day of the week and that way it overwrites the old 
file with the same name and you get a rolling 7 files.

#keep a weeks worth of weewx backups
/usr/bin/mysqldump --add-drop-table --user=root --password=password weewx  
>  $FILELOCATION/weewx-$(date +%A).sql

So you end up with 7 rolling files:
-rw-r--r--  1 root   root   512633446 Jan  8 23:15 weewx-Friday.sql
-rw-r--r--  1 root   root   511735369 Jan  4 23:15 weewx-Monday.sql
-rw-r--r--  1 root   root   512857289 Jan  9 23:15 weewx-Saturday.sql
-rw-r--r--  1 root   root   513079187 Jan 10 23:15 weewx-Sunday.sql
-rw-r--r--  1 root   root   512408576 Jan  7 23:15 weewx-Thursday.sql
-rw-r--r--  1 root   root   511958413 Jan  5 23:15 weewx-Tuesday.sql
-rw-r--r--  1 root   root   512183056 Jan  6 23:15 weewx-Wednesday.sql

Works well. I have restored lots of times with success.

On Monday, 11 January 2021 at 06:32:01 UTC+11 tke...@gmail.com wrote:

> On Sun, Jan 10, 2021 at 9:06 AM Timothy L  wrote:
>
>> For my own personal understanding as a newcomer I would like to ask how 
>> is it possible to lose a data record using a logger such as in the Vantage 
>> Pro 2 series that should report once weewx is restarted after the backup? 
>> Wouldn't the logger have recorded the weather event and then transferred 
>> that event once weewx has restarted? 
>>
>
> True enough for a Vantage station, but not all stations have a logger. In 
> fact, most don't.
>
>

-- 
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/97646840-76dc-4853-b1ce-0593e236c2b1n%40googlegroups.com.

Re: [weewx-user] Re: skin Belchertown " earth Quake"

Try deleting the earthquake.json file as the earthequake stuff gets 
regenerated every 3 hours by default. So you might have to wait 3 hours 
before noticing any changes.

The json file will be recreated the next reporting run.

The file is here: 
/var/www/html//belchertown/json/earthquake.json



On Monday, 11 January 2021 at 07:04:21 UTC+11 sali...@gmail.com wrote:

> hello,
>
> I done your suggestion but it is always the samethings , earthquake in 
> Miles.
>
> in my fil weewx.conf:
>
> [[[Extras]]]
>
> # General Site Defaults
> belchertown_root_url = 
> http://jurassikpat.ddns.net/weewx/belchertown
> belchertown_locale = "auto"
>
>  Groups
>
> group_altitude = meter# Options are 'foot' or 'meter'
> group_degree_day = degree_C_day# Options are 
> 'degree_F_day'$
> group_distance = km# Options are 'mile' or 'km'
>
> pi@raspberrypi:~ $ locale
> LANG=fr_FR.UTF-8
> LANGUAGE=fr_FR.UTF-8
> LC_CTYPE="fr_FR.UTF-8"
> LC_NUMERIC="fr_FR.UTF-8"
> LC_TIME="fr_FR.UTF-8"
> LC_COLLATE="fr_FR.UTF-8"
> LC_MONETARY="fr_FR.UTF-8"
> LC_MESSAGES="fr_FR.UTF-8"
> LC_PAPER="fr_FR.UTF-8"
> LC_NAME="fr_FR.UTF-8"
> LC_ADDRESS="fr_FR.UTF-8"
> LC_TELEPHONE="fr_FR.UTF-8"
> LC_MEASUREMENT="fr_FR.UTF-8"
> LC_IDENTIFICATION="fr_FR.UTF-8"
> LC_ALL=fr_FR.UTF-8
>
> I don't understand
>
> patrick
>
>
> Le 10/01/2021 à 01:34, Greg from Oz a écrit :
>
> Yes I did that to but it made no difference. 
>
> You can change the locale = (in the belchertown skin.conf) to "*en_AU.UTF-8" 
> *and that works  but if you leave it as auto and do the regen then it 
> works as expected.
>
>
> On Sunday, 10 January 2021 at 10:12:38 UTC+11 colin@gmail.com wrote:
>
>> My simple fix for this was to make sure that in weewx.conf (or skin.conf 
>> if you prefer) you have under the stanza
>>
>> [[belchertown]]
>> [[[units]]]
>> groups
>>
>> An entry that says 
>>
>> group_distance = km
>>
>>
>>
>> On Sun, 10 Jan 2021 at 11:12, Greg from Oz  wrote:
>>
>>> Run the command: locale 
>>>
>>> See if *LC_MEASUREMENT *is in your units
>>>
>>> If it is like this: *LC_MEASUREMENT="en_US.UTF-8" *the the measurement 
>>> units will be in US (miles)
>>>
>>> To regenerate all your locale settings run: *locale-gen*
>>>
>>> There is a lot of discussion here: 
>>> https://groups.google.com/g/weewx-user/c/BckKUHu2_DQ/m/30YJPrKkBwAJ
>>>
>>>
>>> On Sunday, 10 January 2021 at 06:48:26 UTC+11 sali...@gmail.com wrote:
>>>
 hello,
 in which file, can I modify miles in kilometers.

 inside joint file

 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+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/06af1676-3a27-4989-945d-af379f5b1647n%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+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/c6dcdfc7-8a99-423e-bc06-8a5fbde0df1fn%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/e978f5c5-ee76-4cac-aba4-bc5c141d1ff3n%40googlegroups.com.

[weewx-user] Re: Installation libpcap for Interceptor and Froggit WH6000 on rpi2

2021-01-10 Thread sc.lep...@gmail.com

 My own answer
  i try several solutions and the last is good  ;) 

Architecture armhf
wget 
http://ftp.fr.debian.org/debian/pool/main/p/python-pypcap/python-pypcap_1.1.2+debian-2.2_armhf.deb
dpkg  -i  python-pypcap_1.1.2+debian-2.2_armhf.deb


It's ok now   ;) 

Jan 10 21:06:22 raspberrypi interceptor.py: interceptor: MainThread: mode 
is sniff
Jan 10 21:06:22 raspberrypi interceptor.py: interceptor: MainThread: sniff 
iface=wlan0 promiscuous=0
Jan 10 21:06:22 raspberrypi interceptor.py: interceptor: MainThread: sniff 
filter 'src 192.168.0.36 and dst port 80'
Jan 10 21:06:22 raspberrypi interceptor.py: interceptor: MainThread: *pypcap 
(1.1)*
Jan 10 21:06:22 raspberrypi interceptor.py: interceptor: ServerThread: 
start sniff server
Jan 10 21:09:13 raspberrypi interceptor.py: interceptor: MainThread: mode 
is listen
Jan 10 21:09:13 raspberrypi interceptor.py: interceptor: MainThread: listen 
on :80
Jan 10 21:09:13 raspberrypi interceptor.py: interceptor: ServerThread: 
start tcp server
Jan 10 21:09:21 raspberrypi interceptor.py: interceptor: ServerThread: GET: 
ID=Station&PASSWORD=&action=updateraww&realtime=1&rtfreq=5&dateutc=now&baromin=30.95&tempf=32.0&humidity=95&windspeedmph=0&windgustmph=0&winddir=34&dewptf=30.7&rainin=0&dailyrainin=0&UV=0&indoortempf=68.0&indoorhumidity=52
Jan 10 21:09:21 raspberrypi interceptor.py: interceptor: MainThread: using 
rain_total 0.0 from dailyrainin

Thanks 
Stéphane
Le dimanche 10 janvier 2021 à 18:31:54 UTC+1, sc.lep...@gmail.com a écrit :

> and another log (from syslog)  
>
>
> Jan 10 15:17:05 raspberrypi interceptor.py: interceptor: MainThread: mode 
> is sniff
> Jan 10 15:17:05 raspberrypi interceptor.py: interceptor: MainThread: sniff 
> iface=wlan0 promiscuous=0
> Jan 10 15:17:05 raspberrypi interceptor.py: interceptor: MainThread: sniff 
> filter 'src 192.168.0.36 and dst port 80'
> Jan 10 15:17:05 raspberrypi interceptor.py: interceptor: MainThread: 
> *pylibpcap 
> (unknown)*
> Jan 10 15:17:05 raspberrypi interceptor.py: interceptor: ServerThread: 
> start sniff server
> Jan 10 15:17:34 raspberrypi interceptor.py: interceptor: MainThread: mode 
> is sniff
> Jan 10 15:17:34 raspberrypi interceptor.py: interceptor: MainThread: sniff 
> iface=wlan0 promiscuous=0
> Jan 10 15:17:34 raspberrypi interceptor.py: interceptor: MainThread: sniff 
> filter 'src 192.168.0.36 and dst port 80'
> Jan 10 15:17:34 raspberrypi interceptor.py: interceptor: MainThread:* 
> pylibpcap (unknown)*
> Jan 10 15:17:34 raspberrypi interceptor.py: interceptor: ServerThread: 
> start sniff server
> Jan 10 15:24:14 raspberrypi interceptor.py: interceptor: MainThread: mode 
> is sniff
> Jan 10 15:24:14 raspberrypi interceptor.py: interceptor: MainThread: sniff 
> iface=wlan0 promiscuous=0
> Jan 10 15:24:14 raspberrypi interceptor.py: interceptor: MainThread: sniff 
> filter 'src 192.168.0.36 and dst port 80'
> Jan 10 15:24:14 raspberrypi interceptor.py: interceptor: MainThread: 
> pylibpcap (unknown)
> Jan 10 15:24:14 raspberrypi interceptor.py: interceptor: ServerThread: 
> start sniff server
>
>
> Le dimanche 10 janvier 2021 à 14:50:29 UTC+1, sc.lep...@gmail.com a 
> écrit :
>
>>
>> Here is some  logs  :
>>
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: 
>> Initializing weewx version 4.2.0
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: Using 
>> Python 2.7.3 (default, Nov 24 2017, 21:13:24) #012[GCC 4.6.3]
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: Platform 
>> Linux-5.10.5-v7+-armv7l-with-debian-7.11
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: Locale is 
>> 'fr_FR.UTF-8'
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: PID file 
>> is /var/run/weewx-FROGGIT.pid
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO __main__: Using 
>> configuration file /home/weewx/FROGGIT.conf
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO __main__: Debug is 0
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO weewx.engine: 
>> Loading station type Interceptor (user.interceptor)
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
>> driver version is 0.53
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
>> device type: wu-client
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
>> mode is sniff
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
>> sniff iface=wlan0 promiscuous=0
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
>> sniff filter 'dst port 80'
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] ERROR weewx.engine: 
>> Import of driver failed: in method 'pcapObject_open_live', argument 2 of 
>> type 'char *' ()
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:  
>>  Traceback (most recent call last):
>> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:  
>>File "/home/weewx/

Re: [weewx-user] Re: skin Belchertown " earth Quake"

2021-01-10 Thread salinois


hello,

I done your suggestion but it is always the samethings , earthquake in 
Miles.


in my fil weewx.conf:

[[[Extras]]]

    # General Site Defaults
    belchertown_root_url = 
http://jurassikpat.ddns.net/weewx/belchertown

    belchertown_locale = "auto"

 Groups

    group_altitude = meter    # Options are 'foot' or 'meter'
    group_degree_day = degree_C_day    # Options are 
'degree_F_day'$

    group_distance = km    # Options are 'mile' or 'km'

pi@raspberrypi:~ $ locale
LANG=fr_FR.UTF-8
LANGUAGE=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=fr_FR.UTF-8

I don't understand

patrick


Le 10/01/2021 à 01:34, Greg from Oz a écrit :

Yes I did that to but it made no difference.

You can change the locale = (in the belchertown skin.conf) to 
"*en_AU.UTF-8" *and that works  but if you leave it as auto and do the 
regen then it works as expected.



On Sunday, 10 January 2021 at 10:12:38 UTC+11 colin@gmail.com wrote:

My simple fix for this was to make sure that in weewx.conf (or
skin.conf if you prefer) you have under the stanza

[[belchertown]]
[[[units]]]
groups

An entry that says

group_distance = km




On Sun, 10 Jan 2021 at 11:12, Greg from Oz  wrote:

Run the command: locale

See if *LC_MEASUREMENT *is in your units

If it is like this: *LC_MEASUREMENT="en_US.UTF-8" *the the
measurement units will be in US (miles)

To regenerate all your locale settings run: *locale-gen*
*
*
There is a lot of discussion here:
https://groups.google.com/g/weewx-user/c/BckKUHu2_DQ/m/30YJPrKkBwAJ



On Sunday, 10 January 2021 at 06:48:26 UTC+11
sali...@gmail.com wrote:

hello,
in which file, can I modify miles in kilometers.

inside joint file

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+...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/weewx-user/06af1676-3a27-4989-945d-af379f5b1647n%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/c6dcdfc7-8a99-423e-bc06-8a5fbde0df1fn%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/0ed4bd34-5b66-22d7-fc54-06a3e4b4810d%40gmail.com.

[weewx-user] Re: weewx stopped Jan 1st, 2021

Thanks. debug is set to 1 - There is no /var/log/messages but here a few 
other infos:

tail -f /var/log/syslog
Jan 10 20:26:16 MyServer weewx[28539] DEBUG weewx.engine: Finished loading 
service weewx.engine.StdConvert
Jan 10 20:26:16 MyServer weewx[28539] DEBUG weewx.engine: Loading service 
weewx.engine.StdCalibrate
Jan 10 20:26:16 MyServer weewx[28539] DEBUG weewx.engine: Finished loading 
service weewx.engine.StdCalibrate
Jan 10 20:26:16 MyServer weewx[28539] DEBUG weewx.engine: Loading service 
weewx.engine.StdQC
Jan 10 20:26:16 MyServer weewx[28539] DEBUG weewx.engine: Finished loading 
service weewx.engine.StdQC
Jan 10 20:26:16 MyServer weewx[28539] DEBUG weewx.engine: Loading service 
weewx.wxservices.StdWXCalculate
Jan 10 20:26:16 MyServer weewx[28539] DEBUG weewx.manager: Daily summary 
version is 2.0
Jan 10 20:26:16 MyServer weewx[28539] INFO weewx.manager: Daily summaries 
at V2.0. Patching to V3.0
Jan 10 20:26:16 MyServer weewx[28539] INFO weewx.manager: 
recalculate_weights: Using database 'weewx.sdb'
Jan 10 20:26:16 MyServer weewx[28539] DEBUG weewx.manager: 
recalculate_weights: Tranche size 100
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: Caught 
unrecoverable exception:
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
Non-positive value for record field 'interval': 0
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
Traceback (most recent call last):
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: File 
"/usr/share/weewx/weewxd", line 148, in main
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
engine = weewx.engine.StdEngine(config_dict)
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: File 
"/usr/share/weewx/weewx/engine.py", line 93, in __init__
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
self.loadServices(config_dict)
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: File 
"/usr/share/weewx/weewx/engine.py", line 161, in loadServices
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   obj 
= weeutil.weeutil.get_object(svc)(self, config_dict)
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: File 
"/usr/share/weewx/weewx/wxservices.py", line 38, in __init__
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
self.db_manager = engine.db_binder.get_manager(data_binding=data_binding, 
initialize=True)
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: File 
"/usr/share/weewx/weewx/manager.py", line 534, in get_manager
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
self.manager_cache[data_binding] = open_manager(manager_dict, initialize)
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: File 
"/usr/share/weewx/weewx/manager.py", line 684, in open_manager
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
manager_dict['schema'])
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: File 
"/usr/share/weewx/weewx/manager.py", line 164, in open_with_create
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
dbmanager = cls(connection, table_name=table_name, schema=schema)
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: File 
"/usr/share/weewx/weewx/manager.py", line 831, in __init__
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
self.patch_sums()
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: File 
"/usr/share/weewx/weewx/manager.py", line 1255, in patch_sums
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
self.recalculate_weights(start_d=datetime.date(2020,6,1))
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: File 
"/usr/share/weewx/weewx/manager.py", line 1182, in recalculate_weights
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
self._do_tranche(mark_d, end_of_tranche_d, weight_fn, progress_fn)
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: File 
"/usr/share/weewx/weewx/manager.py", line 1215, in _do_tranche
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
weight = weight_fn(self, rec)
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__: File 
"/usr/share/weewx/weewx/manager.py", line 1366, in _calc_weight
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
"Non-positive value for record field 'interval': %s" % 
(record['interval'],))
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   
IntervalError: Non-positive value for record field 'interval': 0
Jan 10 20:28:11 MyServer weewx[28539] CRITICAL __main__:   Exiting.
Jan 10 20:39:01 MyServer CRON[28786]: (root) CMD (  [ -x 
/usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d 
/var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 
$(/usr/lib/php5

Re: [weewx-user] Independent weewx backup script

On Sun, Jan 10, 2021 at 9:06 AM Timothy L 
wrote:

> For my own personal understanding as a newcomer I would like to ask how is
> it possible to lose a data record using a logger such as in the Vantage Pro
> 2 series that should report once weewx is restarted after the backup?
> Wouldn't the logger have recorded the weather event and then transferred
> that event once weewx has restarted?
>

True enough for a Vantage station, but not all stations have a logger. In
fact, most don't.

-- 
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/CAPq0zEDsU6Bf56ZkQ2pJT4m9p%3DYaWuCR3aO%2BYF868H9pA0%2B75g%40mail.gmail.com.

Re: [weewx-user] Online update times

These updates are done on every archive interval. For a Davis instrument,
that archive interval is set by your hardware. To change it, either consult
your Davis documentation, or (easier) use the WeeWX tool wee_device with
the --set-interval option
.

On Sun, Jan 10, 2021 at 7:59 AM Roy G. Jackson  wrote:

> I recently purchased a Davis Instruments Vantage Vue weather station. I
> wanted to run it with a Raspberry Pi. I installed WeeWX on the Raspberry
> Pi. I have it reporting to Weather Underground and PWS. I have not yet been
> able to get it to report to CWOPS. My problem is the data only updates
> about once an hour. I have looked through the weewx.conf file and the
> configuration tools for Weather Underground and PWS. I can not find any
> place to change the time frame for updates. I have very limited experience
> with linux, so will need detailed explanations if changes need to be made
> to the Raspberry Pi software. Thanks in advance for any help that can be
> offered.
>
> --
> Roy G. Jackson KW4G
> Sebring, Florida USA
>
> --
> 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/b0d4744a-d5cb-de83-8221-586cd64856e4%40gmail.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/CAPq0zEC4TkFc-kp4-VTJZRJuK-gvhHD-m9jw2v1dDiyV9s_PdQ%40mail.gmail.com.

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

Perfect.  Thanks.  That's what I was looking for.

On Saturday, January 9, 2021 at 8:11:23 PM UTC-8 gjr80 wrote:

> OK, maybe I am mis-reading your post and what you want/expect to 'see'. 
> When I said "*displaying the GW1000 and sensor configuration information 
> currently only available through the WS View app*" I meant everything you 
> can access under the menu in the top right hand corner of the WS View App 
> (believe that is the '*More*' menu in both the Android and Apple apps). 
> The --get- command line options should correspond closely to the item 
> names under the '*More*' menu and each should present the same info on 
> screen as fund under the respective '*Menu*' sub-menu. You certainly 
> should be able to see calibration offsets but of course not in --live-data 
> or loop packets.
>
> The release notes from the v0.2.0 release on GitHub gives a better run 
> down:
>
>- added --get-services command line option to display GW1000 supported 
>weather services settings
>- added --get-pm25-offset command line option to display GW1000 PM2.5 
>sensor offset settings
>- added --get-mulch-offset command line option to display GW1000 
>multi-channel TH sensor calibration settings
>- added --get-soil-calibration command line option to display GW1000 
>soil moisture sensor calibration settings
>- added --get-calibration command line option to display GW1000 sensor 
>calibration settings
>- renamed --rain-data command line option to --get-rain-data
>
>
> Gary
> On Sunday, 10 January 2021 at 13:15:58 UTC+10 vince wrote:
>
>> My gear is all working fine.  I probably misread your note a bit, 
>> thinking that "*displaying the GW1000 and sensor configuration 
>> information currently only available through the WS View app*" included 
>> seeing the calibration offsets we do in their app after finding them buried 
>> down in that brutal GUI they provide.   I did see the --sensors option 
>> which was pretty interesting though.  No problems here at all.  Works 
>> great.  Thanks.
>>
>> On Saturday, January 9, 2021 at 1:48:13 PM UTC-8 gjr80 wrote:
>>
>>> On Sunday, 10 January 2021 at 07:37:10 UTC+10 vince wrote:
>>>
 On Saturday, January 9, 2021 at 12:20:38 PM UTC-8 gjr80 wrote:

> On Sunday, 10 January 2021 at 05:44:27 UTC+10 vince wrote:
>
>> Works great here, thanks.   Also liked the wiki pages.
>>
>> I noted the new (?) _sig values in --live-data
>>
> Mine all show a value of 4
>>
> I'm assuming the values are 0-4 where 4 is best (???)
>>
> The Sensor battery states 
>  
> wiki page provides details on sensor battery states reported by the 
> driver; 
> basically the meaning depends on the sensor concerned.
>

 Yes, saw that...but I was asking about the sig(nal?) status fields in 
 the new version.

>>>
>>> Yes you did, sorry too early here. The API documentation provides no 
>>> real info on what signal level means, my understanding is it is not a true 
>>> signal level like we normally understand signal level to be, but rather it 
>>> is an indicator of whether the most recent broadcasts have been received 
>>> from the sensor. But yes more is better.
>>>
>>>
 And are the calibration things available in the --live-data information 
 ?
 I have my sensors slightly calibrated, but don't see any of that info 
 in the --live-data output.

 GW1000 live sensor data: absbarometer: 1014.3, datetime: 1610218338, 
 humid1: 38, humid2: 41, inhumid: 39, intemp: 21.1, outhumid: 98, outtemp: 
 1.4, relbarometer: 1025.8, soilmoist1: 38, temp1: 20.7, temp2: 19.7, 
 wh26_batt: 0, wh26_sig: 4, wh31_ch1_batt: 0, wh31_ch1_sig: 4, 
 wh31_ch2_batt: 0, wh31_ch2_sig: 4, wh51_ch1_batt: 0, wh51_ch1_sig: 4

 I guess I'm struggling a little with how to display all the new cool 
 stuff and what the units are, especially since the API isn't public yet it 
 seems.

>>>
>>> Calibration data is not explicitly included in the —live-data output, 
>>> though any relevant calibration data should have been applied to sensor 
>>> data in the —live-data output. I have not explicitly tested that though. 
>>> What units do you have a problem with?
>>>  
>>> 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/f89edc7f-ac10-4195-98d8-132da75c7eb6n%40googlegroups.com.

[weewx-user] Re: weewx stopped Jan 1st, 2021

As always, we need to see some log files.

Set debug=1 in weewx.conf and restart weewx.   Then post excerpts from your 
/var/log/messages and /var/log/syslog (if your os has both) from the period 
when you started weewx until it failed.

On Sunday, January 10, 2021 at 10:35:10 AM UTC-8 marb...@gmail.com wrote:

>
> I am a desperately lost. On midnight 1st of Jan 2021 weewx stopped working 
> (well at least I did not see any more output generated on my weewx weather 
> webserver).
>
> The ubuntu 16.04 LTS system was running fine with weewx for about 5 years, 
> I use WMR300 weather station.
>
> I tried to read here in the group and tried several upgrades of python and 
> weewx and some more other ideas but I still can not get it to run... 
> Actually the true reason is, I do not exactly know what I am doing, I am 
> just not experienced enough to help myself.
>
> Is anyone here willing to guide me through the troubleshooting?
>
> Help is much appreciated!
>
> Markus
>
>

-- 
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/cca3fe1c-88f5-41c0-ba84-7567d5a078adn%40googlegroups.com.

Re: [weewx-user] Independent weewx backup script

2021-01-10 Thread peterq...@gmail.com

Trying it. Seems very slow compared to a file copy. Doing it one page at a 
time is really slow. Like 100x slower than a file copy. I don't have any 
sense as to the page size of this database. I'm probably going to end up 
doing 100 pages at a time. 

The example here 
https://docs.python.org/3/library/sqlite3.html#sqlite3.Connection.backup is 
trivial to implement. Cut and paste and change the filenames/paths trivial. 

I'm going to run the backup continuously in a loop on my dev system for a 
while today and if it runs without problems, I'll update my backup script 
to use it rather than a file copy.

On Sunday, January 10, 2021 at 7:22:43 AM UTC-8 tke...@gmail.com wrote:

> If the backup takes long enough, it could interfere with writing a record 
> to the database. Eventually, the write will time out, causing weewxd to 
> restart from the top. It won't crash weewxd (that is, cause it to exit), 
> nor corrupt the database, but the record would be lost. 
>
> That's the advantage of the incremental backup approach. The backup 
> process never holds a lock on the database for very long. Just a second or 
> two.
>
> BTW, the backup API 
>  is 
> now included in Python starting with V3.7. If you have a modern version of 
> Python, you don't have to write a C program to access the API.
>
> I'm hoping to inspire someone to write a simple script that would run once 
> a day using the backup API.
>
> -tk
>
>
>
> On Sun, Jan 10, 2021 at 7:13 AM David Levine  wrote:
>
>> I understand database consistency in a transactional database and I'm 
>> wondering about the risk of copying weewx.sdb without stopping weewx first. 
>> Would you possibly lose an in-flight transaction or might the entire sdb be 
>> inconsistent and unusable? An in-flight copy would seem to be similar to 
>> losing power to the device vs a graceful shutdown.  
>>
>> On Sunday, January 10, 2021 at 9:46:55 AM UTC-5 peterq...@gmail.com 
>> wrote:
>>
>>> I have a script that stops weewx, makes a local copy of the db restarts 
>>> weewx and then copies the backup to google drive. 
>>>
>>> The copy takes less than 2 minutes so I don't lose data. 
>>>
>>> On Sun, Jan 10, 2021, 5:39 AM Tom Keffer  wrote:
>>>
 Your approach will certainly work, but requires stopping weewxd for 
 what could potentially be a long period of time, so you might miss a 
 weather event.

 Another approach is to use the sqlite3 ".backup" command. Replace your 
 tar command with

 tar czf $dest/$archive_file $backup_files2 $backup_files3 $backup_files4
 sqlite3 $backup_files1 ".backup $dest/$backup_files1.backup"

 This avoids stopping weewxd, because the sqlite3 utility will take care 
 of any necessary locking. However, it has the disadvantage that if sqlite3 
 holds on to the lock for too long, a database write will get delayed and, 
 ultimately, could time out, causing weewxd to restart.

 Finally, the most sophisticated approach is to incrementally back up 
 the database. Take a look at this page on backing up a running database 
 . It copies a number of database 
 pages, then releases the lock, sleeps for a bit to allow other processes 
 to 
 gain access to the database, then goes on to the next set of pages. This 
 allows the database to be backed up without stopping weewxd, and without 
 the potential hazard of a database timeout.

 Something to think about...

 -tk

 On Sun, Jan 10, 2021 at 4:01 AM Jan Stelling  
 wrote:

> For some time, I was looking for an easy and independent (from weewx) 
> way to automatically backup my weewx data, as I do not want to lose data 
> if 
> the Micro SD breaks down.
> Recently, I found this small repo 
>  on github which only 
> contains a backup script file. It mounts a USB drive, stops weewx, 
> creates 
> an archived backup of the most relevant user files and folders on the USB 
> drive, unmounts the drive and restarts weewx.
>
> This was almost perfect for me, but I had to introduce some changes to 
> make it suitable for my environment. I forked it 
>  to make it available for 
> others. It now does the following:
>
>1. Stop weewx
>2. Create an archived backup on a mounted network drive (under 
>/home/pi/Shares/Temp)
>3. Start weewx
>
> I tested it manually and running via crontab on my RasPi 3B.
>
> Maybe this is useful for some of you...
>
> -- 
> You received this message because you are subscribed to the Google 
> Groups "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to weewx-user+...@googlegroups.com.
> To view

Re: [weewx-user] Re: skin Belchertown " earth Quake"

2021-01-10 Thread Colin Larsen

I just looked at your site and the distance is in miles as I would expect
for the US. What part do you think is buggy?

Colin

On Mon, 11 Jan 2021 at 03:48, John Mora  wrote:

> I am following these threads with interest as my Belchertown "Earthquake"
> is working but not as I desire it to work. The skin installed without a
> hitch and is running but the Eathquake  distance is in km instead of miles
> and I also tried to change the earthquake_maxradiuskm setting from 1000 to
> 2000 and the changes aren't being reflected in the output.
>
> I've tried making changes to belchertown.py (
> https://github.com/poblabs/weewx-belchertown/issues/422) and changing the
> skin.conf by setting the belchertown_locale from auto to en_US.UTF-8 and
> doing the locale-gen command to no avail.
>
> I will continue to follow this thread hoping that there is some final
> solution as to why the Earthquake is "buggy". Thanks to all who post, you
> have been a great help in trying to figure this anomaly out.
>
> my site: http://weather.codetales.com
>
>
>
>
> On Saturday, January 9, 2021 at 7:34:41 PM UTC-5 Greg from Oz wrote:
>
>> Yes I did that to but it made no difference.
>>
>> You can change the locale = (in the belchertown skin.conf) to "*en_AU.UTF-8"
>> *and that works  but if you leave it as auto and do the regen then it
>> works as expected.
>>
>>
>> On Sunday, 10 January 2021 at 10:12:38 UTC+11 colin@gmail.com wrote:
>>
>>> My simple fix for this was to make sure that in weewx.conf (or skin.conf
>>> if you prefer) you have under the stanza
>>>
>>> [[belchertown]]
>>> [[[units]]]
>>> groups
>>>
>>> An entry that says
>>>
>>> group_distance = km
>>>
>>>
>>>
>>> On Sun, 10 Jan 2021 at 11:12, Greg from Oz  wrote:
>>>
 Run the command: locale

 See if *LC_MEASUREMENT *is in your units

 If it is like this: *LC_MEASUREMENT="en_US.UTF-8" *the the measurement
 units will be in US (miles)

 To regenerate all your locale settings run: *locale-gen*

 There is a lot of discussion here:
 https://groups.google.com/g/weewx-user/c/BckKUHu2_DQ/m/30YJPrKkBwAJ


 On Sunday, 10 January 2021 at 06:48:26 UTC+11 sali...@gmail.com wrote:

> hello,
> in which file, can I modify miles in kilometers.
>
> inside joint file
>
> 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+...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/weewx-user/06af1676-3a27-4989-945d-af379f5b1647n%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/544e2f70-aecc-4199-87bd-f8cd0940d371n%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/CACjxfUt9vbjdz4AYF-hNQ2BSHGGcK22BfrGX0uTLuHxkZ43Q8A%40mail.gmail.com.

[weewx-user] weewx stopped Jan 1st, 2021


I am a desperately lost. On midnight 1st of Jan 2021 weewx stopped working 
(well at least I did not see any more output generated on my weewx weather 
webserver).

The ubuntu 16.04 LTS system was running fine with weewx for about 5 years, 
I use WMR300 weather station.

I tried to read here in the group and tried several upgrades of python and 
weewx and some more other ideas but I still can not get it to run... 
Actually the true reason is, I do not exactly know what I am doing, I am 
just not experienced enough to help myself.

Is anyone here willing to guide me through the troubleshooting?

Help is much appreciated!

Markus

-- 
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/f711ef78-6129-4863-9f44-1e27d8e97c9fn%40googlegroups.com.

Re: [weewx-user] weewx skipping report cycles

2021-01-10 Thread Kevin Davis

Your log didn’t attach, so I don’t know if you’re having the same issue I was 
running in to last week, but on a Pi, the DEBUG messages end up in 
/var/log/syslog, not messages.  

> On Jan 10, 2021, at 10:08 AM, Philipp  wrote:
> 
> Hi everyone,
> 
> I have had my weewx instance running for 3-4 months without any problems. I'm 
> using weewx-sdr to receive the data from my weather station and weewx then 
> generates the reports.
> I have kept my Raspberry Pi 4B with Debian up to date, which also means that 
> I have updated to weewx 4.2 and 4.3 respectively.
> 
> I have attached my weewx.conf as well as the debug log from /var/log/messages 
> with debug = 1. 
> Here's my problem: weewx is supposed to generate a report every 5 minutes but 
> it skips some of the reports - sometimes even more than just once. This 
> creates gaps of up to 20 minutes between the reports.
> 
> When running rtl_433 (or `sudo PYTHONPATH=/usr/share/weewx python 
> /usr/share/weewx/user/sdr.py --cmd="rtl_433 -f 868.3M -F json`) I do however 
> get messages from my station in intervals of around 30 secs. Therefore I 
> don't think that my weather station is the reason for the problem. It must be 
> something with weewx not working the way it should.
> I also checked if my system is overloaded but that's not the case. System 
> load is around 0.5. And after all I haven't changed anything on the Pi.
> 
> Any clues as to what might stop the reports from being generated?
> 
> Thanks in advance!
> Philipp
> -- 
> 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/842cd3c5-c811-4112-b532-3378563790d2n%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/3996C485-2BA8-434D-8FCC-78BAEB5C541D%40gmail.com.

[weewx-user] weewx skipping report cycles

2021-01-10 Thread Philipp

Hi everyone,

I have had my weewx instance running for 3-4 months without any problems.
I'm using weewx-sdr to receive the data from my weather station and weewx
then generates the reports.
I have kept my Raspberry Pi 4B with Debian up to date, which also means
that I have updated to weewx 4.2 and 4.3 respectively.

I have attached my weewx.conf as well as the debug log from
/var/log/messages with debug = 1.
Here's my problem: *weewx is supposed to generate a report every 5 minutes
but it skips some of the reports* - sometimes even more than just once.
This creates gaps of up to 20 minutes between the reports.

When running rtl_433 (or `sudo PYTHONPATH=/usr/share/weewx python
/usr/share/weewx/user/sdr.py --cmd="rtl_433 -f 868.3M -F json`) I do
however get messages from my station in intervals of around 30 secs.
Therefore I don't think that my weather station is the reason for the
problem. It must be something with weewx not working the way it should.
I also checked if my system is overloaded but that's not the case. System
load is around 0.5. And after all I haven't changed anything on the Pi.

Any clues as to what might stop the reports from being generated?

Thanks in advance!
Philipp

--
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/842cd3c5-c811-4112-b532-3378563790d2n%40googlegroups.com.

[weewx-user] Re: Installation libpcap for Interceptor and Froggit WH6000 on rpi2

2021-01-10 Thread sc.lep...@gmail.com

and another log (from syslog)  


Jan 10 15:17:05 raspberrypi interceptor.py: interceptor: MainThread: mode 
is sniff
Jan 10 15:17:05 raspberrypi interceptor.py: interceptor: MainThread: sniff 
iface=wlan0 promiscuous=0
Jan 10 15:17:05 raspberrypi interceptor.py: interceptor: MainThread: sniff 
filter 'src 192.168.0.36 and dst port 80'
Jan 10 15:17:05 raspberrypi interceptor.py: interceptor: MainThread: *pylibpcap 
(unknown)*
Jan 10 15:17:05 raspberrypi interceptor.py: interceptor: ServerThread: 
start sniff server
Jan 10 15:17:34 raspberrypi interceptor.py: interceptor: MainThread: mode 
is sniff
Jan 10 15:17:34 raspberrypi interceptor.py: interceptor: MainThread: sniff 
iface=wlan0 promiscuous=0
Jan 10 15:17:34 raspberrypi interceptor.py: interceptor: MainThread: sniff 
filter 'src 192.168.0.36 and dst port 80'
Jan 10 15:17:34 raspberrypi interceptor.py: interceptor: MainThread:* 
pylibpcap (unknown)*
Jan 10 15:17:34 raspberrypi interceptor.py: interceptor: ServerThread: 
start sniff server
Jan 10 15:24:14 raspberrypi interceptor.py: interceptor: MainThread: mode 
is sniff
Jan 10 15:24:14 raspberrypi interceptor.py: interceptor: MainThread: sniff 
iface=wlan0 promiscuous=0
Jan 10 15:24:14 raspberrypi interceptor.py: interceptor: MainThread: sniff 
filter 'src 192.168.0.36 and dst port 80'
Jan 10 15:24:14 raspberrypi interceptor.py: interceptor: MainThread: 
pylibpcap (unknown)
Jan 10 15:24:14 raspberrypi interceptor.py: interceptor: ServerThread: 
start sniff server


Le dimanche 10 janvier 2021 à 14:50:29 UTC+1, sc.lep...@gmail.com a écrit :

>
> Here is some  logs  :
>
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: 
> Initializing weewx version 4.2.0
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: Using 
> Python 2.7.3 (default, Nov 24 2017, 21:13:24) #012[GCC 4.6.3]
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: Platform 
> Linux-5.10.5-v7+-armv7l-with-debian-7.11
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: Locale is 
> 'fr_FR.UTF-8'
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: PID file 
> is /var/run/weewx-FROGGIT.pid
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO __main__: Using 
> configuration file /home/weewx/FROGGIT.conf
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO __main__: Debug is 0
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO weewx.engine: 
> Loading station type Interceptor (user.interceptor)
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
> driver version is 0.53
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
> device type: wu-client
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
> mode is sniff
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
> sniff iface=wlan0 promiscuous=0
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
> sniff filter 'dst port 80'
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] ERROR weewx.engine: 
> Import of driver failed: in method 'pcapObject_open_live', argument 2 of 
> type 'char *' ()
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
>    Traceback (most recent call last):
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
>  File "/home/weewx/bin/weewx/engine.py", line 109, in setupStation
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
>    self.console = loader_function(config_dict, self)
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
>  File "/home/weewx/bin/user/interceptor.py", line 315, in loader
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
>    return InterceptorDriver(**config_dict[DRIVER_NAME])
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
>  File "/home/weewx/bin/user/interceptor.py", line 2522, in __init__
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
>    self._device = 
> self.DEVICE_TYPES.get(self._device_type)(**stn_dict)
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
>  File "/home/weewx/bin/user/interceptor.py", line 728, in __init__
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
>    WUClient.Parser(), handler=WUClient.Handler, **stn_dict)
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
>  File "/home/weewx/bin/user/interceptor.py", line 427, in __init__
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
>    iface, pcap_filter, promiscuous)
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
>  File "/home/weewx/bin/user/interceptor.py", line 469, in __init__
> Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:

Re: [weewx-user] Independent weewx backup script

2021-01-10 Thread Timothy L

For my own personal understanding as a newcomer I would like to ask how is
it possible to lose a data record using a logger such as in the Vantage Pro
2 series that should report once weewx is restarted after the backup?
Wouldn't the logger have recorded the weather event and then transferred
that event once weewx has restarted? Thank you

On Sun, Jan 10, 2021, 9:22 AM Tom Keffer  wrote:

> If the backup takes long enough, it could interfere with writing a record
> to the database. Eventually, the write will time out, causing weewxd to
> restart from the top. It won't crash weewxd (that is, cause it to exit),
> nor corrupt the database, but the record would be lost.
>
> That's the advantage of the incremental backup approach. The backup
> process never holds a lock on the database for very long. Just a second or
> two.
>
> BTW, the backup API
>  is
> now included in Python starting with V3.7. If you have a modern version of
> Python, you don't have to write a C program to access the API.
>
> I'm hoping to inspire someone to write a simple script that would run once
> a day using the backup API.
>
> -tk
>
>
>
> On Sun, Jan 10, 2021 at 7:13 AM David Levine  wrote:
>
>> I understand database consistency in a transactional database and I'm
>> wondering about the risk of copying weewx.sdb without stopping weewx first.
>> Would you possibly lose an in-flight transaction or might the entire sdb be
>> inconsistent and unusable? An in-flight copy would seem to be similar to
>> losing power to the device vs a graceful shutdown.
>>
>> On Sunday, January 10, 2021 at 9:46:55 AM UTC-5 peterq...@gmail.com
>> wrote:
>>
>>> I have a script that stops weewx, makes a local copy of the db restarts
>>> weewx and then copies the backup to google drive.
>>>
>>> The copy takes less than 2 minutes so I don't lose data.
>>>
>>> On Sun, Jan 10, 2021, 5:39 AM Tom Keffer  wrote:
>>>
 Your approach will certainly work, but requires stopping weewxd for
 what could potentially be a long period of time, so you might miss a
 weather event.

 Another approach is to use the sqlite3 ".backup" command. Replace your
 tar command with

 tar czf $dest/$archive_file $backup_files2 $backup_files3 $backup_files4
 sqlite3 $backup_files1 ".backup $dest/$backup_files1.backup"

 This avoids stopping weewxd, because the sqlite3 utility will take care
 of any necessary locking. However, it has the disadvantage that if sqlite3
 holds on to the lock for too long, a database write will get delayed and,
 ultimately, could time out, causing weewxd to restart.

 Finally, the most sophisticated approach is to incrementally back up
 the database. Take a look at this page on backing up a running database
 . It copies a number of database
 pages, then releases the lock, sleeps for a bit to allow other processes to
 gain access to the database, then goes on to the next set of pages. This
 allows the database to be backed up without stopping weewxd, and without
 the potential hazard of a database timeout.

 Something to think about...

 -tk



 On Sun, Jan 10, 2021 at 4:01 AM Jan Stelling 
 wrote:

> For some time, I was looking for an easy and independent (from weewx)
> way to automatically backup my weewx data, as I do not want to lose data 
> if
> the Micro SD breaks down.
> Recently, I found this small repo
>  on github which only
> contains a backup script file. It mounts a USB drive, stops weewx, creates
> an archived backup of the most relevant user files and folders on the USB
> drive, unmounts the drive and restarts weewx.
>
> This was almost perfect for me, but I had to introduce some changes to
> make it suitable for my environment. I forked it
>  to make it available for
> others. It now does the following:
>
>1. Stop weewx
>2. Create an archived backup on a mounted network drive (under
>/home/pi/Shares/Temp)
>3. Start weewx
>
> I tested it manually and running via crontab on my RasPi 3B.
>
> Maybe this is useful for some of you...
>
> --
> You received this message because you are subscribed to the Google
> Groups "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/2671c065-719a-4435-9657-06841af8fed7n%40googlegroups.com
> 
> .
>
 --
 You received this message because you

Re: [weewx-user] Independent weewx backup script

2021-01-10 Thread David Levine

wee_database --backup
leveraging the data bindings in weewx.conf sounds like a beneficial 
core utility service that would then be called from a script/cron. 


On Sunday, January 10, 2021 at 10:22:43 AM UTC-5 tke...@gmail.com wrote:

> If the backup takes long enough, it could interfere with writing a record 
> to the database. Eventually, the write will time out, causing weewxd to 
> restart from the top. It won't crash weewxd (that is, cause it to exit), 
> nor corrupt the database, but the record would be lost. 
>
> That's the advantage of the incremental backup approach. The backup 
> process never holds a lock on the database for very long. Just a second or 
> two.
>
> BTW, the backup API 
>  is 
> now included in Python starting with V3.7. If you have a modern version of 
> Python, you don't have to write a C program to access the API.
>
> I'm hoping to inspire someone to write a simple script that would run once 
> a day using the backup API.
>
> -tk
>

-- 
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/f12fd696-9b4d-4ae0-9f28-900c8d858db4n%40googlegroups.com.

[weewx-user] Online update times

2021-01-10 Thread Roy G. Jackson


  
  
I recently purchased a Davis Instruments Vantage Vue weather
station. I wanted to run it with a Raspberry Pi. I installed WeeWX
on the Raspberry Pi. I have it reporting to Weather Underground and
PWS. I have not yet been able to get it to report to CWOPS. My
problem is the data only updates about once an hour. I have looked
through the weewx.conf file and the configuration tools for Weather
Underground and PWS. I can not find any place to change the time
frame for updates. I have very limited experience with linux, so
will need detailed explanations if changes need to be made to the
Raspberry Pi software. Thanks in advance for any help that can be
offered.
-- 
Roy G. Jackson KW4G
Sebring, Florida USA
  




-- 
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/b0d4744a-d5cb-de83-8221-586cd64856e4%40gmail.com.

Re: [weewx-user] Independent weewx backup script

If the backup takes long enough, it could interfere with writing a record
to the database. Eventually, the write will time out, causing weewxd to
restart from the top. It won't crash weewxd (that is, cause it to exit),
nor corrupt the database, but the record would be lost.

That's the advantage of the incremental backup approach. The backup process
never holds a lock on the database for very long. Just a second or two.

BTW, the backup API
 is
now included in Python starting with V3.7. If you have a modern version of
Python, you don't have to write a C program to access the API.

I'm hoping to inspire someone to write a simple script that would run once
a day using the backup API.

-tk



On Sun, Jan 10, 2021 at 7:13 AM David Levine  wrote:

> I understand database consistency in a transactional database and I'm
> wondering about the risk of copying weewx.sdb without stopping weewx first.
> Would you possibly lose an in-flight transaction or might the entire sdb be
> inconsistent and unusable? An in-flight copy would seem to be similar to
> losing power to the device vs a graceful shutdown.
>
> On Sunday, January 10, 2021 at 9:46:55 AM UTC-5 peterq...@gmail.com wrote:
>
>> I have a script that stops weewx, makes a local copy of the db restarts
>> weewx and then copies the backup to google drive.
>>
>> The copy takes less than 2 minutes so I don't lose data.
>>
>> On Sun, Jan 10, 2021, 5:39 AM Tom Keffer  wrote:
>>
>>> Your approach will certainly work, but requires stopping weewxd for what
>>> could potentially be a long period of time, so you might miss a weather
>>> event.
>>>
>>> Another approach is to use the sqlite3 ".backup" command. Replace your
>>> tar command with
>>>
>>> tar czf $dest/$archive_file $backup_files2 $backup_files3 $backup_files4
>>> sqlite3 $backup_files1 ".backup $dest/$backup_files1.backup"
>>>
>>> This avoids stopping weewxd, because the sqlite3 utility will take care
>>> of any necessary locking. However, it has the disadvantage that if sqlite3
>>> holds on to the lock for too long, a database write will get delayed and,
>>> ultimately, could time out, causing weewxd to restart.
>>>
>>> Finally, the most sophisticated approach is to incrementally back up the
>>> database. Take a look at this page on backing up a running database
>>> . It copies a number of database pages,
>>> then releases the lock, sleeps for a bit to allow other processes to gain
>>> access to the database, then goes on to the next set of pages. This allows
>>> the database to be backed up without stopping weewxd, and without the
>>> potential hazard of a database timeout.
>>>
>>> Something to think about...
>>>
>>> -tk
>>>
>>>
>>>
>>> On Sun, Jan 10, 2021 at 4:01 AM Jan Stelling 
>>> wrote:
>>>
 For some time, I was looking for an easy and independent (from weewx)
 way to automatically backup my weewx data, as I do not want to lose data if
 the Micro SD breaks down.
 Recently, I found this small repo
  on github which only
 contains a backup script file. It mounts a USB drive, stops weewx, creates
 an archived backup of the most relevant user files and folders on the USB
 drive, unmounts the drive and restarts weewx.

 This was almost perfect for me, but I had to introduce some changes to
 make it suitable for my environment. I forked it
  to make it available for
 others. It now does the following:

1. Stop weewx
2. Create an archived backup on a mounted network drive (under
/home/pi/Shares/Temp)
3. Start weewx

 I tested it manually and running via crontab on my RasPi 3B.

 Maybe this is useful for some of you...

 --
 You received this message because you are subscribed to the Google
 Groups "weewx-user" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to weewx-user+...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/weewx-user/2671c065-719a-4435-9657-06841af8fed7n%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+...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/CAPq0zEDK%3DkX-zkzewA%2B%2BDXzOkBPMLBUPHaVgJ69qYbaYWNUGzw%40mail.gmail.com
>>> 
>>> .

Re: [weewx-user] Independent weewx backup script

2021-01-10 Thread David Levine

I understand database consistency in a transactional database and I'm 
wondering about the risk of copying weewx.sdb without stopping weewx first. 
Would you possibly lose an in-flight transaction or might the entire sdb be 
inconsistent and unusable? An in-flight copy would seem to be similar to 
losing power to the device vs a graceful shutdown.  

On Sunday, January 10, 2021 at 9:46:55 AM UTC-5 peterq...@gmail.com wrote:

> I have a script that stops weewx, makes a local copy of the db restarts 
> weewx and then copies the backup to google drive. 
>
> The copy takes less than 2 minutes so I don't lose data. 
>
> On Sun, Jan 10, 2021, 5:39 AM Tom Keffer  wrote:
>
>> Your approach will certainly work, but requires stopping weewxd for what 
>> could potentially be a long period of time, so you might miss a weather 
>> event.
>>
>> Another approach is to use the sqlite3 ".backup" command. Replace your 
>> tar command with
>>
>> tar czf $dest/$archive_file $backup_files2 $backup_files3 $backup_files4
>> sqlite3 $backup_files1 ".backup $dest/$backup_files1.backup"
>>
>> This avoids stopping weewxd, because the sqlite3 utility will take care 
>> of any necessary locking. However, it has the disadvantage that if sqlite3 
>> holds on to the lock for too long, a database write will get delayed and, 
>> ultimately, could time out, causing weewxd to restart.
>>
>> Finally, the most sophisticated approach is to incrementally back up the 
>> database. Take a look at this page on backing up a running database 
>> . It copies a number of database pages, 
>> then releases the lock, sleeps for a bit to allow other processes to gain 
>> access to the database, then goes on to the next set of pages. This allows 
>> the database to be backed up without stopping weewxd, and without the 
>> potential hazard of a database timeout.
>>
>> Something to think about...
>>
>> -tk
>>
>>
>>
>> On Sun, Jan 10, 2021 at 4:01 AM Jan Stelling  wrote:
>>
>>> For some time, I was looking for an easy and independent (from weewx) 
>>> way to automatically backup my weewx data, as I do not want to lose data if 
>>> the Micro SD breaks down.
>>> Recently, I found this small repo 
>>>  on github which only 
>>> contains a backup script file. It mounts a USB drive, stops weewx, creates 
>>> an archived backup of the most relevant user files and folders on the USB 
>>> drive, unmounts the drive and restarts weewx.
>>>
>>> This was almost perfect for me, but I had to introduce some changes to 
>>> make it suitable for my environment. I forked it 
>>>  to make it available for 
>>> others. It now does the following:
>>>
>>>1. Stop weewx
>>>2. Create an archived backup on a mounted network drive (under 
>>>/home/pi/Shares/Temp)
>>>3. Start weewx
>>>
>>> I tested it manually and running via crontab on my RasPi 3B.
>>>
>>> Maybe this is useful for some of you...
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/2671c065-719a-4435-9657-06841af8fed7n%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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/CAPq0zEDK%3DkX-zkzewA%2B%2BDXzOkBPMLBUPHaVgJ69qYbaYWNUGzw%40mail.gmail.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/fa03941e-6ea2-41fb-bf62-998ea49651ddn%40googlegroups.com.

Re: [weewx-user] Re: skin Belchertown " earth Quake"

2021-01-10 Thread John Mora

I am following these threads with interest as my Belchertown "Earthquake" 
is working but not as I desire it to work. The skin installed without a 
hitch and is running but the Eathquake  distance is in km instead of miles 
and I also tried to change the earthquake_maxradiuskm setting from 1000 to 
2000 and the changes aren't being reflected in the output.

I've tried making changes to belchertown.py 
(https://github.com/poblabs/weewx-belchertown/issues/422) and changing the 
skin.conf by setting the belchertown_locale from auto to en_US.UTF-8 and 
doing the locale-gen command to no avail.

I will continue to follow this thread hoping that there is some final 
solution as to why the Earthquake is "buggy". Thanks to all who post, you 
have been a great help in trying to figure this anomaly out.

my site: http://weather.codetales.com

On Saturday, January 9, 2021 at 7:34:41 PM UTC-5 Greg from Oz wrote:

> Yes I did that to but it made no difference.
>
> You can change the locale = (in the belchertown skin.conf) to "*en_AU.UTF-8" 
> *and that works  but if you leave it as auto and do the regen then it 
> works as expected.
>
>
> On Sunday, 10 January 2021 at 10:12:38 UTC+11 colin@gmail.com wrote:
>
>> My simple fix for this was to make sure that in weewx.conf (or skin.conf 
>> if you prefer) you have under the stanza
>>
>> [[belchertown]]
>> [[[units]]]
>> groups
>>
>> An entry that says 
>>
>> group_distance = km
>>
>>
>>
>> On Sun, 10 Jan 2021 at 11:12, Greg from Oz  wrote:
>>
>>> Run the command: locale
>>>
>>> See if *LC_MEASUREMENT *is in your units
>>>
>>> If it is like this: *LC_MEASUREMENT="en_US.UTF-8" *the the measurement 
>>> units will be in US (miles)
>>>
>>> To regenerate all your locale settings run: *locale-gen*
>>>
>>> There is a lot of discussion here: 
>>> https://groups.google.com/g/weewx-user/c/BckKUHu2_DQ/m/30YJPrKkBwAJ
>>>
>>>
>>> On Sunday, 10 January 2021 at 06:48:26 UTC+11 sali...@gmail.com wrote:
>>>
 hello,
 in which file, can I modify miles in kilometers.

 inside joint file

 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+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/06af1676-3a27-4989-945d-af379f5b1647n%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/544e2f70-aecc-4199-87bd-f8cd0940d371n%40googlegroups.com.

Re: [weewx-user] Independent weewx backup script

2021-01-10 Thread p q

I have a script that stops weewx, makes a local copy of the db restarts
weewx and then copies the backup to google drive.

The copy takes less than 2 minutes so I don't lose data.

On Sun, Jan 10, 2021, 5:39 AM Tom Keffer  wrote:

> Your approach will certainly work, but requires stopping weewxd for what
> could potentially be a long period of time, so you might miss a weather
> event.
>
> Another approach is to use the sqlite3 ".backup" command. Replace your tar
> command with
>
> tar czf $dest/$archive_file $backup_files2 $backup_files3 $backup_files4
> sqlite3 $backup_files1 ".backup $dest/$backup_files1.backup"
>
> This avoids stopping weewxd, because the sqlite3 utility will take care of
> any necessary locking. However, it has the disadvantage that if sqlite3
> holds on to the lock for too long, a database write will get delayed and,
> ultimately, could time out, causing weewxd to restart.
>
> Finally, the most sophisticated approach is to incrementally back up the
> database. Take a look at this page on backing up a running database
> . It copies a number of database pages,
> then releases the lock, sleeps for a bit to allow other processes to gain
> access to the database, then goes on to the next set of pages. This allows
> the database to be backed up without stopping weewxd, and without the
> potential hazard of a database timeout.
>
> Something to think about...
>
> -tk
>
>
>
> On Sun, Jan 10, 2021 at 4:01 AM Jan Stelling 
> wrote:
>
>> For some time, I was looking for an easy and independent (from weewx) way
>> to automatically backup my weewx data, as I do not want to lose data if the
>> Micro SD breaks down.
>> Recently, I found this small repo
>>  on github which only
>> contains a backup script file. It mounts a USB drive, stops weewx, creates
>> an archived backup of the most relevant user files and folders on the USB
>> drive, unmounts the drive and restarts weewx.
>>
>> This was almost perfect for me, but I had to introduce some changes to
>> make it suitable for my environment. I forked it
>>  to make it available for
>> others. It now does the following:
>>
>>1. Stop weewx
>>2. Create an archived backup on a mounted network drive (under
>>/home/pi/Shares/Temp)
>>3. Start weewx
>>
>> I tested it manually and running via crontab on my RasPi 3B.
>>
>> Maybe this is useful for some of you...
>>
>> --
>> 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/2671c065-719a-4435-9657-06841af8fed7n%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/CAPq0zEDK%3DkX-zkzewA%2B%2BDXzOkBPMLBUPHaVgJ69qYbaYWNUGzw%40mail.gmail.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/CAA1SM20LJQNAtSdKe9KQFfEO_DdNL6DkGifJURQKKO%2Bu-%2B6Pbw%40mail.gmail.com.

[weewx-user] Re: Installation libpcap for Interceptor and Froggit WH6000 on rpi2

2021-01-10 Thread sc.lep...@gmail.com


Here is some  logs  :

Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: 
Initializing weewx version 4.2.0
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: Using 
Python 2.7.3 (default, Nov 24 2017, 21:13:24) #012[GCC 4.6.3]
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: Platform 
Linux-5.10.5-v7+-armv7l-with-debian-7.11
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: Locale is 
'fr_FR.UTF-8'
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11691] INFO __main__: PID file is 
/var/run/weewx-FROGGIT.pid
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO __main__: Using 
configuration file /home/weewx/FROGGIT.conf
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO __main__: Debug is 0
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO weewx.engine: Loading 
station type Interceptor (user.interceptor)
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
driver version is 0.53
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
device type: wu-client
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
mode is sniff
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
sniff iface=wlan0 promiscuous=0
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] INFO user.interceptor: 
sniff filter 'dst port 80'
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] ERROR weewx.engine: Import 
of driver failed: in method 'pcapObject_open_live', argument 2 of type 
'char *' ()
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
   Traceback (most recent call last):
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
 File "/home/weewx/bin/weewx/engine.py", line 109, in setupStation
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
   self.console = loader_function(config_dict, self)
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
 File "/home/weewx/bin/user/interceptor.py", line 315, in loader
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
   return InterceptorDriver(**config_dict[DRIVER_NAME])
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
 File "/home/weewx/bin/user/interceptor.py", line 2522, in __init__
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
   self._device = 
self.DEVICE_TYPES.get(self._device_type)(**stn_dict)
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
 File "/home/weewx/bin/user/interceptor.py", line 728, in __init__
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
   WUClient.Parser(), handler=WUClient.Handler, **stn_dict)
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
 File "/home/weewx/bin/user/interceptor.py", line 427, in __init__
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
   iface, pcap_filter, promiscuous)
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
 File "/home/weewx/bin/user/interceptor.py", line 469, in __init__
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
   self.sniffer.open_live(iface, snaplen, pval, timeout_ms)
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
 File "/usr/lib/python2.7/dist-packages/pcap.py", line 108, in 
open_live
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
   def open_live(self, *args): return 
_pcap.pcapObject_open_live(self, *args)
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL weewx.engine:
   TypeError: in method 'pcapObject_open_live', argument 2 of type 
'char *'
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL __main__: Unable 
to load driver: in method 'pcapObject_open_live', argument 2 of type 'char 
*'
Jan 10 14:47:28 raspberrypi weewx-FROGGIT[11696] CRITICAL __main__:
   Exiting...


Can someone  help me . 
Thanks


Le samedi 9 janvier 2021 à 22:39:27 UTC+1, sc.lep...@gmail.com a écrit :

> Hello 
> I want to use Interceptor Wifi for  my Froggit Station .
>
> I try to install librairy libpcap on my rpi2
>
> I use all these but nok  ;-( 
>
>1. sudo pip install pypcap 
>2. sudo apt-get install python-libpcap 
>3. sudo apt-get install libcap-dev 
>
>
> So i try to find another way  : 
>
> wget 
> http://ftp.de.debian.org/debian/pool/main/p/python-libpcap/python-libpcap_0.6.4-1_armhf.deb
>
>
> And installation by dkpg  :
>  dpkg -i python-libpcap_0.6.4-1_armhf.deb
>
> Can someone tell me if my libpcap will work fine ? 
>
> Thansk a lot 
> Best regards 
> Stéphane
>

-- 
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 weew

Re: [weewx-user] Independent weewx backup script