[weewx-user] Ecowitt WH55 leak detector

[gjr80]

Was hoping to find somebody who has a WH55 connected to a GW1000 that could 
obtain some raw WH55 data from the GW1000 to help me tidy up a few things 
in the GW1000 driver. You don't need to be running the GW1000 driver with 
WeeWX but you do need to have WeeWX 3.7.0 or later installed and would have 
to run the GW1000 WeeWX driver directly (independent to WeeWX and without 
the need to stop WeeWX if it is running).

If anyone can help please post back here.

thanks,
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/c2b9540f-7c87-4266-95a6-464e7b61901dn%40googlegroups.com.

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

[gjr80]

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/343d6845-953c-43c1-8675-86d2121e9d8an%40googlegroups.com.

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

[Garry A Lockyer]

My experience is that when I recreate an include file for Belchertown on each 
archive cycle, as an extension to Belchertown or as a service, memory usage 
increases with each cycle and eventually errors start.  I’ve seen the error I 
reported in this string and unresponsive systems.  So, yes, I think there’s a 
problem.

The memory test service I provided starts out at about 45 MB and increases at 
about 3 MB per cycle.  I’ve seen WeeWx memory usage grow to over 1 GB!

I’m working on a new version of my extension, as a service, and will report 
back on its memory usage, hopefully within only a couple of days.

Thanks for all your help!

Regards,

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


> On Jan 9, 2021, at 19:11, vince  wrote:
> 
> If your memory usage is stable, is there a problem ?
> It's pretty typical after a weewx startup for the usage to go up a bit then 
> level off nicely.
> 
>> On Saturday, January 9, 2021 at 4:41:51 PM UTC-8 bell...@gmail.com wrote:
>> Garry,
>> I ran your test extension for a bit in my Ubuntu VM.  Doesn't appear to be 
>> leaking.
>>  16:42:24 {'mem_size': 338.53515625, 'mem_rss': 32.953125, 'mem_share': 
>> 11.28125}
>>  16:47:38 {'mem_size': 423.80859375, 'mem_rss': 47.75, 'mem_share': 
>> 11.796875}
>>  16:52:53 {'mem_size': 424.4140625, 'mem_rss': 48.2265625, 'mem_share': 
>> 11.796875}
>>  16:57:24 {'mem_size': 426.46875, 'mem_rss': 50.19921875, 'mem_share': 
>> 11.796875}
>>  17:02:32 {'mem_size': 426.46875, 'mem_rss': 50.21875, 'mem_share': 
>> 11.796875}
>>  17:07:20 {'mem_size': 427.1796875, 'mem_rss': 50.9921875, 'mem_share': 
>> 11.796875}
>>  17:12:27 {'mem_size': 427.1796875, 'mem_rss': 50.9921875, 'mem_share': 
>> 11.796875}
>>  17:17:26 {'mem_size': 427.1796875, 'mem_rss': 50.9921875, 'mem_share': 
>> 11.796875}
>>  17:22:24 {'mem_size': 427.1796875, 'mem_rss': 50.9921875, 'mem_share': 
>> 11.796875}
>>  17:27:19 {'mem_size': 424.6640625, 'mem_rss': 48.71875, 'mem_share': 
>> 11.796875}
>>  17:32:27 {'mem_size': 424.6640625, 'mem_rss': 48.71875, 'mem_share': 
>> 11.796875}
>>  17:37:17 {'mem_size': 424.5859375, 'mem_rss': 48.7109375, 'mem_share': 
>> 11.796875}
>>  17:42:21 {'mem_size': 424.58203125, 'mem_rss': 48.70703125, 'mem_share': 
>> 11.796875}
>>  17:47:24 {'mem_size': 424.984375, 'mem_rss': 49.140625, 'mem_share': 
>> 11.796875}
>>  17:52:21 {'mem_size': 424.984375, 'mem_rss': 49.140625, 'mem_share': 
>> 11.796875}
>>  17:57:15 {'mem_size': 425.05078125, 'mem_rss': 49.26953125, 'mem_share': 
>> 11.796875}
>>  18:02:11 {'mem_size': 425.05078125, 'mem_rss': 49.26953125, 'mem_share': 
>> 11.796875}
>>  18:07:13 {'mem_size': 425.1171875, 'mem_rss': 49.3359375, 'mem_share': 
>> 11.796875}
>>  18:12:14 {'mem_size': 425.1171875, 'mem_rss': 49.3359375, 'mem_share': 
>> 11.796875}
>>  18:17:12 {'mem_size': 425.21875, 'mem_rss': 49.4375, 'mem_share': 11.796875}
>>  18:22:10 {'mem_size': 425.09765625, 'mem_rss': 49.31640625, 'mem_share': 
>> 11.796875}
>>  18:27:13 {'mem_size': 425.0390625, 'mem_rss': 49.2578125, 'mem_share': 
>> 11.796875}
>>  18:32:15 {'mem_size': 425.0390625, 'mem_rss': 49.2578125, 'mem_share': 
>> 11.796875}
>>  18:37:15 {'mem_size': 425.03125, 'mem_rss': 49.25, 'mem_share': 11.796875}
>>  18:42:24 {'mem_size': 425.01953125, 'mem_rss': 49.2578125, 'mem_share': 
>> 11.796875}
>>  18:47:14 {'mem_size': 425.0078125, 'mem_rss': 49.24609375, 'mem_share': 
>> 11.796875}
>>  18:52:13 {'mem_size': 425.0078125, 'mem_rss': 49.24609375, 'mem_share': 
>> 11.796875}
>>  18:57:15 {'mem_size': 425.61328125, 'mem_rss': 49.8515625, 'mem_share': 
>> 11.796875}
>>  19:02:19 {'mem_size': 425.0078125, 'mem_rss': 49.2734375, 'mem_share': 
>> 11.796875}
>> 
>> When I have some time, I'll install on my test pi along with the Belchertown 
>> skin and Vince's mem extension and see if I see anything.
>> Yes, I enjoy a good memory 'puzzle'.
>> rich
>>> On Saturday, 9 January 2021 at 16:52:08 UTC-5 garrya...@gmail.com wrote:
>>> Many, many thanks!
>>> 
>>> Before I wrote the service to investigate the problem, I wrote a standalone 
>>> program to eliminate all WeeWX components.  It did NOT exhibit the problem.
>>> 
>>> Problem only seems to show up under WeeWX/Belchertown *and* if the include 
>>> file changes / is recreated.
>>> 
>>> Anyway, I really appreciate you looking into my problem.  I’m actively 
>>> working on a skin-independent service to read many RSS/Atom feeds and will 
>>> utilize your suggestions above.
>>> 
>>> Regards,
>>> 
>>> Garry Lockyer
>>> C: +1.250.689.0686
>>> E: ga...@lockyer.ca
>>> 
>>> 
> On Jan 9, 2021, at 12:39, bell...@gmail.com  wrote:
> 
 
>>> 
 Garry,
 I took your WxFeedsMemory.py and made some modifications.
 First, I changed the logging to simple print calls. this was just a 
 convenience for me to easily see what was going on.
 Second, I stole some code from Vince’s mem extension, 
 https://github.com/vinceskahan/vds-weewx-v3-mem-extension. I did this 
 because I am used to the 

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

[vince]

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/a15f62cd-9a24-49a5-8fcb-6d988063b73bn%40googlegroups.com.

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

[vince]

If your memory usage is stable, is there a problem ?
It's pretty typical after a weewx startup for the usage to go up a bit then 
level off nicely.

On Saturday, January 9, 2021 at 4:41:51 PM UTC-8 bell...@gmail.com wrote:

> Garry,
> I ran your test extension for a bit in my Ubuntu VM.  Doesn't appear to be 
> leaking.
>  16:42:24 {'mem_size': 338.53515625, 'mem_rss': 32.953125, 'mem_share': 
> 11.28125}
>  16:47:38 {'mem_size': 423.80859375, 'mem_rss': 47.75, 'mem_share': 
> 11.796875}
>  16:52:53 {'mem_size': 424.4140625 <(424)%20414-0625>, 'mem_rss': 
> 48.2265625, 'mem_share': 11.796875}
>  16:57:24 {'mem_size': 426.46875, 'mem_rss': 50.19921875, 'mem_share': 
> 11.796875}
>  17:02:32 {'mem_size': 426.46875, 'mem_rss': 50.21875, 'mem_share': 
> 11.796875}
>  17:07:20 {'mem_size': 427.1796875, 'mem_rss': 50.9921875, 'mem_share': 
> 11.796875}
>  17:12:27 {'mem_size': 427.1796875, 'mem_rss': 50.9921875, 'mem_share': 
> 11.796875}
>  17:17:26 {'mem_size': 427.1796875, 'mem_rss': 50.9921875, 'mem_share': 
> 11.796875}
>  17:22:24 {'mem_size': 427.1796875, 'mem_rss': 50.9921875, 'mem_share': 
> 11.796875}
>  17:27:19 {'mem_size': 424.6640625 <(424)%20664-0625>, 'mem_rss': 
> 48.71875, 'mem_share': 11.796875}
>  17:32:27 {'mem_size': 424.6640625 <(424)%20664-0625>, 'mem_rss': 
> 48.71875, 'mem_share': 11.796875}
>  17:37:17 {'mem_size': 424.5859375 <(424)%20585-9375>, 'mem_rss': 
> 48.7109375, 'mem_share': 11.796875}
>  17:42:21 {'mem_size': 424.58203125, 'mem_rss': 48.70703125, 'mem_share': 
> 11.796875}
>  17:47:24 {'mem_size': 424.984375, 'mem_rss': 49.140625, 'mem_share': 
> 11.796875}
>  17:52:21 {'mem_size': 424.984375, 'mem_rss': 49.140625, 'mem_share': 
> 11.796875}
>  17:57:15 {'mem_size': 425.05078125, 'mem_rss': 49.26953125, 'mem_share': 
> 11.796875}
>  18:02:11 {'mem_size': 425.05078125, 'mem_rss': 49.26953125, 'mem_share': 
> 11.796875}
>  18:07:13 {'mem_size': 425.1171875, 'mem_rss': 49.3359375, 'mem_share': 
> 11.796875}
>  18:12:14 {'mem_size': 425.1171875, 'mem_rss': 49.3359375, 'mem_share': 
> 11.796875}
>  18:17:12 {'mem_size': 425.21875, 'mem_rss': 49.4375, 'mem_share': 
> 11.796875}
>  18:22:10 {'mem_size': 425.09765625, 'mem_rss': 49.31640625, 'mem_share': 
> 11.796875}
>  18:27:13 {'mem_size': 425.0390625, 'mem_rss': 49.2578125, 'mem_share': 
> 11.796875}
>  18:32:15 {'mem_size': 425.0390625, 'mem_rss': 49.2578125, 'mem_share': 
> 11.796875}
>  18:37:15 {'mem_size': 425.03125, 'mem_rss': 49.25, 'mem_share': 11.796875}
>  18:42:24 {'mem_size': 425.01953125, 'mem_rss': 49.2578125, 'mem_share': 
> 11.796875}
>  18:47:14 {'mem_size': 425.0078125, 'mem_rss': 49.24609375, 'mem_share': 
> 11.796875}
>  18:52:13 {'mem_size': 425.0078125, 'mem_rss': 49.24609375, 'mem_share': 
> 11.796875}
>  18:57:15 {'mem_size': 425.61328125, 'mem_rss': 49.8515625, 'mem_share': 
> 11.796875}
>  19:02:19 {'mem_size': 425.0078125, 'mem_rss': 49.2734375, 'mem_share': 
> 11.796875}
>
> When I have some time, I'll install on my test pi along with the 
> Belchertown skin and Vince's mem extension and see if I see anything.
> Yes, I enjoy a good memory 'puzzle'.
> rich
> On Saturday, 9 January 2021 at 16:52:08 UTC-5 garrya...@gmail.com wrote:
>
>> Many, many thanks!
>>
>> Before I wrote the service to investigate the problem, I wrote a 
>> standalone program to eliminate all WeeWX components.  It did NOT exhibit 
>> the problem.
>>
>> Problem only seems to show up under WeeWX/Belchertown *and* if the 
>> include file changes / is recreated.
>>
>> Anyway, I really appreciate you looking into my problem.  I’m actively 
>> working on a skin-independent service to read many RSS/Atom feeds and will 
>> utilize your suggestions above.
>>
>> Regards,
>>
>> Garry Lockyer
>> C: +1.250.689.0686 <(250)%20689-0686>
>> E: ga...@lockyer.ca
>>
>>
>> On Jan 9, 2021, at 12:39, bell...@gmail.com  wrote:
>>
>> 
>>
>> Garry,
>> I took your WxFeedsMemory.py and made some modifications.
>> First, I changed the logging to simple print calls. this was just a 
>> convenience for me to easily see what was going on.
>> Second, I stole some code from Vince’s mem extension, 
>> https://github.com/vinceskahan/vds-weewx-v3-mem-extension. I did this 
>> because I am used to the data it returns. (Note, I highly recommend this 
>> when debugging memory.)
>> Third, I added code so I could call your extension repeatedly in a loop.
>>
>> When I called new_archive_record 100 times there was a slight increase in 
>> memory, but nothing alarming. But it was slow, approximately 2 minutes a 
>> call.
>>
>> So, I commented out the flush and fsync calls and called 
>> new_archive_record 10,000 times. The slight increase seemed to stop around 
>> 6,000 calls.
>>
>> I’m wondering if the amount of time it takes to run is causing problems 
>> when run as a service. I plan to uncomment the code and run it as an 
>> extension. I’ll let you know what I see.
>> rich
>>
>> On Thursday, 7 January 2021 at 13:00:40 UTC-5 garrya...@gmail.com wrote:
>>
>>> After many 

[weewx-user] Tycon Systems, TP3000WC Requesting config help

[William Lucid]

Does anyone have this "ProWeatherStation" with weewx working?  

Oscar-Mint:~$ sudo tail -f /var/log/syslog 
[sudo] password for lucid:  
Jan  9 12:17:32 Oscar-Mint weewx[1686] INFO weewx.restx: PWSweather: 
Posting not enabled.
Jan  9 12:17:32 Oscar-Mint weewx[1686] INFO weewx.restx: CWOP: Posting not 
enabled.
Jan  9 12:17:32 Oscar-Mint weewx[1686] INFO weewx.restx: WOW: Posting not 
enabled.
Jan  9 12:17:32 Oscar-Mint weewx[1686] INFO weewx.restx: AWEKAS: Posting 
not enabled.
Jan  9 12:17:32 Oscar-Mint weewx[1686] INFO __main__: Starting up weewx 
version 4.3.0
Jan  9 12:17:32 Oscar-Mint weewx[1686] INFO weewx.engine: Clock error is 
-0.01 seconds (positive is fast)
Jan  9 12:17:32 Oscar-Mint weewx[1686] INFO weewx.engine: Using binding 
'wx_binding' to database 'weewx.sdb'
Jan  9 12:17:32 Oscar-Mint weewx[1686] INFO weewx.manager: Starting 
backfill of daily summaries
Jan  9 12:17:32 Oscar-Mint weewx[1686] INFO weewx.engine: Starting main 
packet loop.
Jan  9 12:17:34 Oscar-Mint dhclient[1183]: XMT: Renew on enp5s0, interval 
69140ms.
Jan  9 12:18:44 Oscar-Mint dhclient[1183]: XMT: Renew on enp5s0, interval 
134510ms.
Jan  9 12:20:14 Oscar-Mint weewx[1686] INFO weewx.manager: Added record 
2021-01-09 12:20:00 EST (1610212800) to database 'weewx.sdb'
Jan  9 12:20:14 Oscar-Mint weewx[1686] INFO weewx.manager: Added record 
2021-01-09 12:20:00 EST (1610212800) to daily summary in 'weewx.sdb'
Jan  9 12:20:15 Oscar-Mint weewx[1686] INFO weewx.cheetahgenerator: 
Generated 8 files for report SeasonsReport in 0.49 seconds
Jan  9 12:20:15 Oscar-Mint weewx[1686] INFO weewx.imagegenerator: Generated 
15 images for report SeasonsReport in 0.18 seconds
Jan  9 12:20:15 Oscar-Mint weewx[1686] INFO weewx.reportengine: Copied 5 
files to /home/weewx/public_html
Jan  9 12:20:58 Oscar-Mint dhclient[1183]: XMT: Renew on enp5s0, interval 
274170ms.
Jan  9 12:25:14 Oscar-Mint weewx[1686] INFO weewx.manager: Added record 
2021-01-09 12:25:00 EST (1610213100) to database 'weewx.sdb'
Jan  9 12:25:14 Oscar-Mint weewx[1686] INFO weewx.manager: Added record 
2021-01-09 12:25:00 EST (1610213100) to daily summary in 'weewx.sdb'
Jan  9 12:25:14 Oscar-Mint weewx[1686] INFO weewx.cheetahgenerator: 
Generated 8 files for report SeasonsReport in 0.20 seconds
Jan  9 12:25:14 Oscar-Mint weewx[1686] INFO weewx.imagegenerator: Generated 
15 images for report SeasonsReport in 0.17 seconds
Jan  9 12:25:14 Oscar-Mint weewx[1686] INFO weewx.reportengine: Copied 0 
files to /home/weewx/public_html
Jan  9 12:25:32 Oscar-Mint dhclient[1183]: XMT: Renew on enp5s0, interval 
536560ms.
Jan  9 12:30:14 Oscar-Mint weewx[1686] INFO weewx.manager: Added record 
2021-01-09 12:30:00 EST (1610213400) to database 'weewx.sdb'
Jan  9 12:30:14 Oscar-Mint weewx[1686] INFO weewx.manager: Added record 
2021-01-09 12:30:00 EST (1610213400) to daily summary in 'weewx.sdb'
Jan  9 12:30:14 Oscar-Mint weewx[1686] INFO weewx.cheetahgenerator: 
Generated 8 files for report SeasonsReport in 0.20 seconds
Jan  9 12:30:14 Oscar-Mint weewx[1686] INFO weewx.imagegenerator: Generated 
15 images for report SeasonsReport in 0.17 seconds
Jan  9 12:30:14 Oscar-Mint weewx[1686] INFO weewx.reportengine: Copied 0 
files to /home/weewx/public_html
Jan  9 12:31:36 Oscar-Mint systemd[1]: Starting Cleanup of Temporary 
Directories...
Jan  9 12:31:36 Oscar-Mint systemd[1]: Started Cleanup of Temporary 
Directories.
Jan  9 12:33:51 Oscar-Mint cinnamon-screensaver-pam-helper: pam_ecryptfs: 
seteuid error
Jan  9 12:34:29 Oscar-Mint dhclient[1183]: XMT: Renew on enp5s0, interval 
603860ms.
Jan  9 12:35:14 Oscar-Mint weewx[1686] INFO weewx.manager: Added record 
2021-01-09 12:35:00 EST (1610213700) to database 'weewx.sdb'
Jan  9 12:35:14 Oscar-Mint weewx[1686] INFO weewx.manager: Added record 
2021-01-09 12:35:00 EST (1610213700) to daily summary in 'weewx.sdb'
Jan  9 12:35:14 Oscar-Mint weewx[1686] INFO weewx.cheetahgenerator: 
Generated 8 files for report SeasonsReport in 0.21 seconds
Jan  9 12:35:14 Oscar-Mint weewx[1686] INFO weewx.imagegenerator: Generated 
15 images for report SeasonsReport in 0.17 seconds
Jan  9 12:35:14 Oscar-Mint weewx[1686] INFO weewx.reportengine: Copied 0 
files to /home/weewx/public_html

#

Oscar-Mint:~$ sudo weewxd /home/weewx/weewx.conf
LOOP:   2021-01-09 11:22:44 EST (1610209364) altimeter: 32.054993865, 
appTemp: 28.4601091875, barometer: 31.0, cloudbase: 2087.32317643, 
consBatteryVoltage: 12.0, dateTime: 1610209364, dewpoint: 27.2035609939, 
heatindex: 32.6785829702, heatingVoltage: 13.0281894277, humidex: 
32.6785829702, inDewpoint: 31.079533828, inHumidity: 29.999587, inTemp: 
63.000207, inTempBatteryStatus: 0, maxSolarRad: None, outHumidity: 
79.99969, outTemp: 32.6785829702, outTempBatteryStatus: 0, pressure: 
31.0, radiation: 973.768102831, rain: 0, rainBatteryStatus: 0, 
rainRate: 0, referenceVoltage: 11.7740206672, rxCheckPercent: 
87.4037735388, supplyVoltage: 

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

[bell...@gmail.com]

Garry,
I ran your test extension for a bit in my Ubuntu VM.  Doesn't appear to be 
leaking.
 16:42:24 {'mem_size': 338.53515625, 'mem_rss': 32.953125, 'mem_share': 
11.28125}
 16:47:38 {'mem_size': 423.80859375, 'mem_rss': 47.75, 'mem_share': 
11.796875}
 16:52:53 {'mem_size': 424.4140625, 'mem_rss': 48.2265625, 'mem_share': 
11.796875}
 16:57:24 {'mem_size': 426.46875, 'mem_rss': 50.19921875, 'mem_share': 
11.796875}
 17:02:32 {'mem_size': 426.46875, 'mem_rss': 50.21875, 'mem_share': 
11.796875}
 17:07:20 {'mem_size': 427.1796875, 'mem_rss': 50.9921875, 'mem_share': 
11.796875}
 17:12:27 {'mem_size': 427.1796875, 'mem_rss': 50.9921875, 'mem_share': 
11.796875}
 17:17:26 {'mem_size': 427.1796875, 'mem_rss': 50.9921875, 'mem_share': 
11.796875}
 17:22:24 {'mem_size': 427.1796875, 'mem_rss': 50.9921875, 'mem_share': 
11.796875}
 17:27:19 {'mem_size': 424.6640625, 'mem_rss': 48.71875, 'mem_share': 
11.796875}
 17:32:27 {'mem_size': 424.6640625, 'mem_rss': 48.71875, 'mem_share': 
11.796875}
 17:37:17 {'mem_size': 424.5859375, 'mem_rss': 48.7109375, 'mem_share': 
11.796875}
 17:42:21 {'mem_size': 424.58203125, 'mem_rss': 48.70703125, 'mem_share': 
11.796875}
 17:47:24 {'mem_size': 424.984375, 'mem_rss': 49.140625, 'mem_share': 
11.796875}
 17:52:21 {'mem_size': 424.984375, 'mem_rss': 49.140625, 'mem_share': 
11.796875}
 17:57:15 {'mem_size': 425.05078125, 'mem_rss': 49.26953125, 'mem_share': 
11.796875}
 18:02:11 {'mem_size': 425.05078125, 'mem_rss': 49.26953125, 'mem_share': 
11.796875}
 18:07:13 {'mem_size': 425.1171875, 'mem_rss': 49.3359375, 'mem_share': 
11.796875}
 18:12:14 {'mem_size': 425.1171875, 'mem_rss': 49.3359375, 'mem_share': 
11.796875}
 18:17:12 {'mem_size': 425.21875, 'mem_rss': 49.4375, 'mem_share': 
11.796875}
 18:22:10 {'mem_size': 425.09765625, 'mem_rss': 49.31640625, 'mem_share': 
11.796875}
 18:27:13 {'mem_size': 425.0390625, 'mem_rss': 49.2578125, 'mem_share': 
11.796875}
 18:32:15 {'mem_size': 425.0390625, 'mem_rss': 49.2578125, 'mem_share': 
11.796875}
 18:37:15 {'mem_size': 425.03125, 'mem_rss': 49.25, 'mem_share': 11.796875}
 18:42:24 {'mem_size': 425.01953125, 'mem_rss': 49.2578125, 'mem_share': 
11.796875}
 18:47:14 {'mem_size': 425.0078125, 'mem_rss': 49.24609375, 'mem_share': 
11.796875}
 18:52:13 {'mem_size': 425.0078125, 'mem_rss': 49.24609375, 'mem_share': 
11.796875}
 18:57:15 {'mem_size': 425.61328125, 'mem_rss': 49.8515625, 'mem_share': 
11.796875}
 19:02:19 {'mem_size': 425.0078125, 'mem_rss': 49.2734375, 'mem_share': 
11.796875}

When I have some time, I'll install on my test pi along with the 
Belchertown skin and Vince's mem extension and see if I see anything.
Yes, I enjoy a good memory 'puzzle'.
rich
On Saturday, 9 January 2021 at 16:52:08 UTC-5 garrya...@gmail.com wrote:

> Many, many thanks!
>
> Before I wrote the service to investigate the problem, I wrote a 
> standalone program to eliminate all WeeWX components.  It did NOT exhibit 
> the problem.
>
> Problem only seems to show up under WeeWX/Belchertown *and* if the include 
> file changes / is recreated.
>
> Anyway, I really appreciate you looking into my problem.  I’m actively 
> working on a skin-independent service to read many RSS/Atom feeds and will 
> utilize your suggestions above.
>
> Regards,
>
> Garry Lockyer
> C: +1.250.689.0686 <(250)%20689-0686>
> E: ga...@lockyer.ca
>
>
> On Jan 9, 2021, at 12:39, bell...@gmail.com  wrote:
>
> 
>
> Garry,
> I took your WxFeedsMemory.py and made some modifications.
> First, I changed the logging to simple print calls. this was just a 
> convenience for me to easily see what was going on.
> Second, I stole some code from Vince’s mem extension, 
> https://github.com/vinceskahan/vds-weewx-v3-mem-extension. I did this 
> because I am used to the data it returns. (Note, I highly recommend this 
> when debugging memory.)
> Third, I added code so I could call your extension repeatedly in a loop.
>
> When I called new_archive_record 100 times there was a slight increase in 
> memory, but nothing alarming. But it was slow, approximately 2 minutes a 
> call.
>
> So, I commented out the flush and fsync calls and called 
> new_archive_record 10,000 times. The slight increase seemed to stop around 
> 6,000 calls.
>
> I’m wondering if the amount of time it takes to run is causing problems 
> when run as a service. I plan to uncomment the code and run it as an 
> extension. I’ll let you know what I see.
> rich
>
> On Thursday, 7 January 2021 at 13:00:40 UTC-5 garrya...@gmail.com wrote:
>
>> After many hours of troubleshooting and testing, I think I have an idea 
>> what's happening.
>>
>> Background: I want to use weewx with the Belchertown skin and my 
>> extension that reads numerous RSS/Atom feeds  on a Pi Zero, with either a 
>> Davis Pro V2 or Weatherflow weather station.  I will eventually have four 
>> weather stations in my area.  I thought I had things working reasonably 
>> well so deployed one station.  It stopped working after about 3 days.  I 
>> can't access that 

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

[Greg from Oz]

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.

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

[Colin Larsen]

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+unsubscr...@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/CACjxfUvTFGcrSPDcw8-WLjdVH7qox%3D7ibaO_zvjVHM_-WmbKww%40mail.gmail.com.

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

[Greg from Oz]

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+unsubscr...@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.

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

[Garry A Lockyer]

Many, many thanks!

Before I wrote the service to investigate the problem, I wrote a standalone 
program to eliminate all WeeWX components.  It did NOT exhibit the problem.

Problem only seems to show up under WeeWX/Belchertown *and* if the include file 
changes / is recreated.

Anyway, I really appreciate you looking into my problem.  I’m actively working 
on a skin-independent service to read many RSS/Atom feeds and will utilize your 
suggestions above.

Regards,

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


> On Jan 9, 2021, at 12:39, bell...@gmail.com  wrote:
> 
> Garry,
> I took your WxFeedsMemory.py and made some modifications.
> First, I changed the logging to simple print calls. this was just a 
> convenience for me to easily see what was going on.
> Second, I stole some code from Vince’s mem extension, 
> https://github.com/vinceskahan/vds-weewx-v3-mem-extension. I did this because 
> I am used to the data it returns. (Note, I highly recommend this when 
> debugging memory.)
> Third, I added code so I could call your extension repeatedly in a loop.
> 
> When I called new_archive_record 100 times there was a slight increase in 
> memory, but nothing alarming. But it was slow, approximately 2 minutes a call.
> 
> So, I commented out the flush and fsync calls and called new_archive_record 
> 10,000 times. The slight increase seemed to stop around 6,000 calls.
> 
> I’m wondering if the amount of time it takes to run is causing problems when 
> run as a service. I plan to uncomment the code and run it as an extension. 
> I’ll let you know what I see.
> rich
> 
> 
> On Thursday, 7 January 2021 at 13:00:40 UTC-5 garrya...@gmail.com wrote:
>> After many hours of troubleshooting and testing, I think I have an idea 
>> what's happening.
>> 
>> Background: I want to use weewx with the Belchertown skin and my extension 
>> that reads numerous RSS/Atom feeds  on a Pi Zero, with either a Davis Pro V2 
>> or Weatherflow weather station.  I will eventually have four weather 
>> stations in my area.  I thought I had things working reasonably well so 
>> deployed one station.  It stopped working after about 3 days.  I can't 
>> access that system remotely so I built a very similar system (the next one 
>> to deploy) and it falso ailed due to lack of memory.  Weewx memory usage on 
>> my development system also increases over time - it can grow to over 1 GB in 
>> a few hours!
>> 
>> My extension was an extension to Belchetown based on the METAR extension.  
>> The extension created Belchertown index hook include files each archive 
>> cycle.  While researching this problem I re-read the weewx customization 
>> guide and noted that extensions should NOT be dependent on other extensions 
>> so I decided to re-write my extension as a service (which looks like a much 
>> cleaner solution) without any dependencies on Belchertown (other than 
>> include file names).  All I've done so far is create a service 
>> (WxFeedsMemoryTest.py) to test weewx/Belchertown memory consumption.
>> 
>> The Problem: weewx/Bechertown memory usage increases over time.  It starts 
>> out at about 45 MB and grows at about 3MB per archive period/cycle (using my 
>> test case).  A 512 MB Pi will exhaust memory within a few days.
>> 
>> It appears that the problem is associated with the creation of the 
>> Belchertown include files while weewx/Belchertown is running:
>> 
>> - if the include file is 'static' as in not (re)created while 
>> weewx/Belchertown is running, memory usage is static - it does not grow 
>> beyond about 50 MB.
>> 
>> - if the include file is 'dynamic' as in (re)created while weewx/Belchetown 
>> is running, memory usage increases.
>>   - if the include file is created once, and becomes 'static', memory usage 
>> increases and then stabilizes.
>>   - if the include file is recreated continuously (such as on each archive 
>> cycle), memory usage increases each cycle.
>> 
>> It does not appear to matter if the include file is created directly, or 
>> created as a temporary file and then copied or renamed.
>> 
>> The attached service (WxFeedsMemoryTest.py) can be used to demonstrate the 
>> problem.  Please see installation and use instructions within the 
>> WxFeedsMemoryTest.py.
>> 
>> I'm going to continue to work on moving my extension from "an extension to 
>> an extension" to a service in the hope that this memory problem can be 
>> resolved.
>> 
>> With apologies in advance if I'm doing something to cause the problem, 
>> please review, advise and let me know what I can do to avoid the problem.
>> 
>> Regards,
>> 
>> Garry
>> On Thursday, December 31, 2020 at 7:05:15 PM UTC-8 garrya...@gmail.com wrote:
>>> Got MemoryError after about 9 hours after restart.  Have removed cmon by 
>>> commenting out any mention of cmon in weewx.conf and restarted.
>>> 
>>> Regards,
>>> 
>>> Garry Lockyer
>>> Former DEC Product Support Engineer :^)
>>> Kepner-Tregoe Trained :^))
>>> C: +1.250.689.0686
>>> E: ga...@lockyer.ca

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

[gjr80]

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/6f9751cc-3da4-4c2b-a574-30c23f0b190en%40googlegroups.com.

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

[sc.lep...@gmail.com]

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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/b2aa9219-d161-47e9-a808-47ed67dbc9f7n%40googlegroups.com.

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

[vince]

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.

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.

-- 
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/4a77fd8b-cbd6-4b4d-a968-a052b7eb255bn%40googlegroups.com.

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

[Rainer Lang]

Hi Vince,
as far as I can tell there is no gap between WSView app (FW 1.6.3) and 
the data provided by the new driver.


I already had a pre-release version installed as my weewx installation 
crashed with my new WH45 sensors.
(That's the last line in the wiki update by Gary - the program shouldn't 
crash when meeting a sensor it doesn't know).


And the pre-release worked fine. Haven't tried the final release yet.

On 09.01.2021 20:44, 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 (???)

What else is now available that was previously only in the WS View app ?

unrelated - I have a minimalist skin for EcoWitt 
at https://github.com/vinceskahan/weewx-ecowitt-skin if anybody is 
interested...


On Saturday, January 9, 2021 at 3:47:59 AM UTC-8 gjr80 wrote:

I have released v0.2.0 on GitHub
.

This main feature of this release is support for the WH45 Indoor
CO2 PM2.5 PM10 Temperature and Humidity 5-in-1 Air Quality Sensor.
If you have a WH45 sensor and it has been linked to your GW1000
v0.2.0 of the driver should automatically pick up and emit the
WH45 sensor data.

v0.2.0 also sees changes in the naming of the 24 hour average
particulate concentration fields. Unfortunately this will mean
anyone that is using these fields will need to make one or more
changes to their WeeWX installation. I have outlined the changes
and which users need to make changes and how to make the necessary
changes in a wiki article Changes to 24 hour average particulate
concentration field names

.
If you have a WH41, WH43 or WH45 sensor and use the 24 hour
average particulate concentration fields in any way I strongly
suggest you thoroughly read the linked wiki article.

The majority of the other changes in v0.2.0 relate to running the
driver directly, in particular displaying the GW1000 and sensor
configuration information currently only available through the WS
View app.

Those that installed v0.1.0 via wee_extension can upgrade to
v0.2.0 as follows:

$ wget -P /var/tmp

https://github.com/gjr80/weewx-gw1000/releases/download/v0.2.0/gw1000-0.2.0.tar.gz


$ wee_extension --install=/var/tmp/gw1000-0.2.0.tar.gz

Note: wee_extension may require the use of sudo the path to
wee_extension as applicable.

Gary

--
You received this message because you are subscribed to the Google 
Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to weewx-user+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/12972026-34e3-4f8f-ab50-e9309c706fa7n%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/4c7ed1b5-b82a-874b-3fd5-11af4eb4bd5b%40gmail.com.

[weewx-user] HP1000 - fetching historical data

['P L' via weewx-user]

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/aac3051f-dfc7-4ab7-9d0e-c7d74fa1e29an%40googlegroups.com.

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

[bell...@gmail.com]

Garry,
I took your WxFeedsMemory.py and made some modifications.
First, I changed the logging to simple print calls. this was just a 
convenience for me to easily see what was going on.
Second, I stole some code from Vince’s mem extension, 
https://github.com/vinceskahan/vds-weewx-v3-mem-extension. I did this 
because I am used to the data it returns. (Note, I highly recommend this 
when debugging memory.)
Third, I added code so I could call your extension repeatedly in a loop.

When I called new_archive_record 100 times there was a slight increase in 
memory, but nothing alarming. But it was slow, approximately 2 minutes a 
call.

So, I commented out the flush and fsync calls and called new_archive_record 
10,000 times. The slight increase seemed to stop around 6,000 calls.

I’m wondering if the amount of time it takes to run is causing problems 
when run as a service. I plan to uncomment the code and run it as an 
extension. I’ll let you know what I see.
rich

On Thursday, 7 January 2021 at 13:00:40 UTC-5 garrya...@gmail.com wrote:

> After many hours of troubleshooting and testing, I think I have an idea 
> what's happening.
>
> Background: I want to use weewx with the Belchertown skin and my extension 
> that reads numerous RSS/Atom feeds  on a Pi Zero, with either a Davis Pro 
> V2 or Weatherflow weather station.  I will eventually have four weather 
> stations in my area.  I thought I had things working reasonably well so 
> deployed one station.  It stopped working after about 3 days.  I can't 
> access that system remotely so I built a very similar system (the next one 
> to deploy) and it falso ailed due to lack of memory.  Weewx memory usage on 
> my development system also increases over time - it can grow to over 1 GB 
> in a few hours!
>
> My extension was an extension to Belchetown based on the METAR extension.  
> The extension created Belchertown index hook include files each archive 
> cycle.  While researching this problem I re-read the weewx customization 
> guide and noted that extensions should NOT be dependent on other extensions 
> so I decided to re-write my extension as a service (which looks like a much 
> cleaner solution) without any dependencies on Belchertown (other than 
> include file names).  All I've done so far is create a service 
> (WxFeedsMemoryTest.py) to test weewx/Belchertown memory consumption.
>
> The Problem: weewx/Bechertown memory usage increases over time.  It starts 
> out at about 45 MB and grows at about 3MB per archive period/cycle (using 
> my test case).  A 512 MB Pi will exhaust memory within a few days.
>
> It appears that the problem is associated with the creation of the 
> Belchertown include files while weewx/Belchertown is running:
>
> - if the include file is 'static' as in not (re)created while 
> weewx/Belchertown is running, memory usage is static - it does not grow 
> beyond about 50 MB.
>
> - if the include file is 'dynamic' as in (re)created while 
> weewx/Belchetown is running, memory usage increases.
>   - if the include file is created once, and becomes 'static', memory 
> usage increases and then stabilizes.
>   - if the include file is recreated continuously (such as on each archive 
> cycle), memory usage increases each cycle.
>
> It does not appear to matter if the include file is created directly, or 
> created as a temporary file and then copied or renamed.
>
> The attached service (WxFeedsMemoryTest.py) can be used to demonstrate the 
> problem.  Please see installation and use instructions within the 
> WxFeedsMemoryTest.py.
>
> I'm going to continue to work on moving my extension from "an extension to 
> an extension" to a service in the hope that this memory problem can be 
> resolved.
>
> With apologies in advance if I'm doing something to cause the problem, 
> please review, advise and let me know what I can do to avoid the problem.
>
> Regards,
>
> Garry
> On Thursday, December 31, 2020 at 7:05:15 PM UTC-8 garrya...@gmail.com 
> wrote:
>
>> Got MemoryError after about 9 hours after restart.  Have removed cmon by 
>> commenting out any mention of cmon in weewx.conf and restarted.
>>
>> Regards,
>>
>> Garry Lockyer
>> Former DEC Product Support Engineer :^)
>> Kepner-Tregoe Trained :^))
>> C: +1.250.689.0686 <(250)%20689-0686>
>> E: ga...@lockyer.ca
>>
>>
>> On Dec 31, 2020, at 11:44, vince  wrote:
>>
>> On Thursday, December 31, 2020 at 11:39:39 AM UTC-8 garrya...@gmail.com 
>> wrote:
>>
>>> Re: editing the Belchertown skin, nope haven’t touched it, *other than 
>>> interfacing with it via the include files (as generated by my 
>>> BelchertownWxFeeds extension)*.  When all the endpoints (for testing) 
>>> are enabled index.html is about 1.8MB, so perhaps that’s causing the 
>>> problem.  I can easily reduce / eliminate endpoints and prefer to do that 
>>> before eliminating the Belchertown skin.
>>>
>>>
>> There it is.  You touched it :-)
>>
>> Usual debugging rules apply.   Reset it to a baseline unmodified config. 
>>  

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

[gjr80]

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/f4da8ed5-2326-4ac0-a75b-c5c84bd0951cn%40googlegroups.com.

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

[gjr80]

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
>

Whoops, included in the release notes but forgot to mention that one here.

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.


> What else is now available that was previously only in the WS View app ?
>

Essentially the supported weather service settings and sensor calibration 
settings, specifically PM2.5 sensor offset settings, multi-channel TH 
sensor calibration settings, soil moisture sensor calibration settings and 
sensor 
calibration settings. I think most if not all of the things you see under 
‘More’ menu in the top right corner of app when looking at a GW1000 can now 
be displayed. And due to the nature of the API and the link to the GW1000 
these can all be accessed by running the driver directly while WeeWX and 
the driver are also running.

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/4e119816-c0f9-445f-83b4-684248e5158cn%40googlegroups.com.

[weewx-user] skin Belchertown " earth Quake"

[sali...@gmail.com]

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/f50ab270-49e3-4bb8-8726-da8d3b957734n%40googlegroups.com.

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

[vince]

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 (???)

What else is now available that was previously only in the WS View app ?

unrelated - I have a minimalist skin for EcoWitt 
at https://github.com/vinceskahan/weewx-ecowitt-skin if anybody is 
interested...

On Saturday, January 9, 2021 at 3:47:59 AM UTC-8 gjr80 wrote:

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

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

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

[vince]

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/b06a875b-4ac0-41c6-9a4b-d0b108abb309n%40googlegroups.com.

Re: [weewx-user] Latest WeeWX 4.3.0 SQL optimizations may return invalid results

[Michael Sanphillipo]

Sorry for posting here. I had the null values before that you helped me 
with, so I wasn't sure if this was another issue. Thanks for checking them. 

On Saturday, January 9, 2021 at 1:02:13 PM UTC-5 tke...@gmail.com wrote:

> Oh, sorry! I had just assumed they were from you. 
>
> Michael: those results look fine. Why? Is there a concern?
>
> -t
>
> On Sat, Jan 9, 2021 at 9:54 AM Arend  wrote:
>
>> Hello Tom,
>>
>> That last query is not mine (please check the names/e-mail adresses), I 
>> am not sure why he is posting his query here but the output seems to be ok. 
>> :-)
>>
>> Arend
>>
>> Op zaterdag 9 januari 2021 om 17:44:29 UTC+1 schreef tke...@gmail.com:
>>
>>> Those are very different results from the ones you showed before. You'll 
>>> have to be the judge of whether minimums were around 2.4, or around 26.24. 
>>> That's a big difference, so it should be fairly obvious.
>>>
>>> -tk
>>>
>>> On Sat, Jan 9, 2021 at 7:03 AM Michael Sanphillipo  
>>> wrote:
>>>
 Tom, here are my results. Do these look okay?

 1548937162|2019-01-31 00:00:00|2.4
 1548910187|2019-01-30 00:00:00|6.4
 1549090774|2019-02-02 00:00:00|6.6
 1548998381|2019-02-01 00:00:00|7.5
 1548071996|2019-01-21 00:00:00|10.0
 1548160788|2019-01-22 00:00:00|10.8
 1517661600|2018-02-03 00:00:00|11.2
 1516278240|2018-01-18 00:00:00|11.6
 1516013940|2018-01-15 00:00:00|13.1
 1581768000|2020-02-15 00:00:00|13.3
 1515933960|2018-01-14 00:00:00|13.5
 1517401200|2018-01-31 00:00:00|13.6
 1547554197|2019-01-15 00:00:00|13.6
 1579610280|2020-01-21 00:00:00|13.8
 1547528389|2019-01-14 00:00:00|15.3
 1548046482|2019-01-20 00:00:00|15.3
 1551946191|2019-03-07 00:00:00|15.3
 1549800883|2019-02-10 00:00:00|15.9
 1576836720|2019-12-20 00:00:00|16.0
 1579582320|2020-01-20 00:00:00|16.0


 On Friday, January 8, 2021 at 5:03:00 PM UTC-5 Arend wrote:

> Adding that extra testing for NOT NULL did the trick. All dates (as 
> far as I can tell) are now correctly retreived.
>
> Op vrijdag 8 januari 2021 om 22:33:50 UTC+1 schreef tke...@gmail.com:
>
>> It appears that you have a null value for mintime in your database. 
>> Most likely the problem is that you have no data for 2019-12-15 and 
>> 2019-12-17. 
>>
>> I suspect the older query worked because MIN(value) ignores values, 
>> while ordering by value does not.
>>
>> This is a bug: the query should check for non null values. I've 
>> created issue 635  to 
>> track, and (hopefully) fixed in commit 5fbe0d5 
>> 
>> .
>>
>> Could you please try this version of xtypes.py 
>> 
>> ?
>>
>> Thanks for your help.
>>
>> On Fri, Jan 8, 2021 at 12:49 PM Arend  wrote:
>>
>>> SELECT mintime, from_unixtime(dateTime), min from 
>>> archive_day_outTemp order by min asc, mintime asc limit 20;
>>>
>>> Database weewx
>>>
>>>  mintime  from_unixtime(dateTime)  min
>>>
>>> NULL 2019-12-15 00:00:00   NULL
>>>
>>> NULL 2019-12-17 00:00:00   NULL
>>>
>>> 16067062352020-11-30 00:00:00   26.24
>>>
>>> 15855519002020-03-30 00:00:00   27.32
>>>
>>> 16066899872020-11-29 00:00:00   27.5
>>>
>>> 15751884002019-12-01 00:00:00   27.86
>>>
>>> 15857247002020-04-01 00:00:00   28.94
>>>
>>> 15755337002019-12-05 00:00:00   29.66
>>>
>>> 15856392002020-03-31 00:00:00   30.02
>>>
>>> 15742407002019-11-20 00:00:00   30.56
>>>
>>> 15808905002020-02-05 00:00:00   30.92
>>>
>>> 16076328002020-12-10 00:00:00   31.279998
>>>
>>> 15751539002019-11-30 00:00:00   31.28
>>>
>>> 15795981002020-01-21 00:00:00   31.28
>>>
>>> 15850299002020-03-24 00:00:00   31.46
>>>
>>> 16094798292021-01-01 00:00:00   31.46
>>>
>>> 15752553002019-12-02 00:00:00   31.82
>>>
>>> 15849453002020-03-23 00:00:00   31.82
>>>
>>> 15851169002020-03-25 00:00:00   31.82
>>>
>>> 16076412102020-12-11 00:00:00   31.82
>>> Op vrijdag 8 januari 2021 om 21:18:54 UTC+1 schreef tke...@gmail.com
>>> :
>>>
 Then adapt as necessary. Use from_unixtime() instead of datetime() 
 in the select statement.

 On Fri, Jan 8, 2021 at 11:49 AM Arend  wrote:

> Hello Tom,
>
> I am using MySQL database.
>
> Arend
>
> Op vrijdag 8 januari 2021 om 20:18:20 UTC+1 schreef 

Re: [weewx-user] Latest WeeWX 4.3.0 SQL optimizations may return invalid results

[Tom Keffer]

Oh, sorry! I had just assumed they were from you.

Michael: those results look fine. Why? Is there a concern?

-t

On Sat, Jan 9, 2021 at 9:54 AM Arend  wrote:

> Hello Tom,
>
> That last query is not mine (please check the names/e-mail adresses), I am
> not sure why he is posting his query here but the output seems to be ok. :-)
>
> Arend
>
> Op zaterdag 9 januari 2021 om 17:44:29 UTC+1 schreef tke...@gmail.com:
>
>> Those are very different results from the ones you showed before. You'll
>> have to be the judge of whether minimums were around 2.4, or around 26.24.
>> That's a big difference, so it should be fairly obvious.
>>
>> -tk
>>
>> On Sat, Jan 9, 2021 at 7:03 AM Michael Sanphillipo 
>> wrote:
>>
>>> Tom, here are my results. Do these look okay?
>>>
>>> 1548937162|2019-01-31 00:00:00|2.4
>>> 1548910187|2019-01-30 00:00:00|6.4
>>> 1549090774|2019-02-02 00:00:00|6.6
>>> 1548998381|2019-02-01 00:00:00|7.5
>>> 1548071996|2019-01-21 00:00:00|10.0
>>> 1548160788|2019-01-22 00:00:00|10.8
>>> 1517661600|2018-02-03 00:00:00|11.2
>>> 1516278240|2018-01-18 00:00:00|11.6
>>> 1516013940|2018-01-15 00:00:00|13.1
>>> 1581768000|2020-02-15 00:00:00|13.3
>>> 1515933960|2018-01-14 00:00:00|13.5
>>> 1517401200|2018-01-31 00:00:00|13.6
>>> 1547554197|2019-01-15 00:00:00|13.6
>>> 1579610280|2020-01-21 00:00:00|13.8
>>> 1547528389|2019-01-14 00:00:00|15.3
>>> 1548046482|2019-01-20 00:00:00|15.3
>>> 1551946191|2019-03-07 00:00:00|15.3
>>> 1549800883|2019-02-10 00:00:00|15.9
>>> 1576836720|2019-12-20 00:00:00|16.0
>>> 1579582320|2020-01-20 00:00:00|16.0
>>>
>>>
>>> On Friday, January 8, 2021 at 5:03:00 PM UTC-5 Arend wrote:
>>>
 Adding that extra testing for NOT NULL did the trick. All dates (as far
 as I can tell) are now correctly retreived.

 Op vrijdag 8 januari 2021 om 22:33:50 UTC+1 schreef tke...@gmail.com:

> It appears that you have a null value for mintime in your database.
> Most likely the problem is that you have no data for 2019-12-15 and
> 2019-12-17.
>
> I suspect the older query worked because MIN(value) ignores values,
> while ordering by value does not.
>
> This is a bug: the query should check for non null values. I've
> created issue 635  to
> track, and (hopefully) fixed in commit 5fbe0d5
> 
> .
>
> Could you please try this version of xtypes.py
> 
> ?
>
> Thanks for your help.
>
> On Fri, Jan 8, 2021 at 12:49 PM Arend  wrote:
>
>> SELECT mintime, from_unixtime(dateTime), min from archive_day_outTemp
>> order by min asc, mintime asc limit 20;
>>
>> Database weewx
>>
>>  mintime  from_unixtime(dateTime)  min
>>
>> NULL 2019-12-15 00:00:00   NULL
>>
>> NULL 2019-12-17 00:00:00   NULL
>>
>> 16067062352020-11-30 00:00:00   26.24
>>
>> 15855519002020-03-30 00:00:00   27.32
>>
>> 16066899872020-11-29 00:00:00   27.5
>>
>> 15751884002019-12-01 00:00:00   27.86
>>
>> 15857247002020-04-01 00:00:00   28.94
>>
>> 15755337002019-12-05 00:00:00   29.66
>>
>> 15856392002020-03-31 00:00:00   30.02
>>
>> 15742407002019-11-20 00:00:00   30.56
>>
>> 15808905002020-02-05 00:00:00   30.92
>>
>> 16076328002020-12-10 00:00:00   31.279998
>>
>> 15751539002019-11-30 00:00:00   31.28
>>
>> 15795981002020-01-21 00:00:00   31.28
>>
>> 15850299002020-03-24 00:00:00   31.46
>>
>> 16094798292021-01-01 00:00:00   31.46
>>
>> 15752553002019-12-02 00:00:00   31.82
>>
>> 15849453002020-03-23 00:00:00   31.82
>>
>> 15851169002020-03-25 00:00:00   31.82
>>
>> 16076412102020-12-11 00:00:00   31.82
>> Op vrijdag 8 januari 2021 om 21:18:54 UTC+1 schreef tke...@gmail.com:
>>
>>> Then adapt as necessary. Use from_unixtime() instead of datetime()
>>> in the select statement.
>>>
>>> On Fri, Jan 8, 2021 at 11:49 AM Arend  wrote:
>>>
 Hello Tom,

 I am using MySQL database.

 Arend

 Op vrijdag 8 januari 2021 om 20:18:20 UTC+1 schreef
 tke...@gmail.com:

> Thanks. Not sure what is happening, but let's take a look at your
> database. I'm assuming you are using SQLite, and that you used a 
> package
> installer. You may have to install the tool sqlite3 first
>
> sudo apt-get install sqlite3
>
> Then
>
> *sqlite3 /var/lib/weewx/weewx.sdb*

Re: [weewx-user] Latest WeeWX 4.3.0 SQL optimizations may return invalid results

[Arend]

Hello Tom,

That last query is not mine (please check the names/e-mail adresses), I am 
not sure why he is posting his query here but the output seems to be ok. :-)

Arend

Op zaterdag 9 januari 2021 om 17:44:29 UTC+1 schreef tke...@gmail.com:

> Those are very different results from the ones you showed before. You'll 
> have to be the judge of whether minimums were around 2.4, or around 26.24. 
> That's a big difference, so it should be fairly obvious.
>
> -tk
>
> On Sat, Jan 9, 2021 at 7:03 AM Michael Sanphillipo  
> wrote:
>
>> Tom, here are my results. Do these look okay?
>>
>> 1548937162|2019-01-31 00:00:00|2.4
>> 1548910187|2019-01-30 00:00:00|6.4
>> 1549090774|2019-02-02 00:00:00|6.6
>> 1548998381|2019-02-01 00:00:00|7.5
>> 1548071996|2019-01-21 00:00:00|10.0
>> 1548160788|2019-01-22 00:00:00|10.8
>> 1517661600|2018-02-03 00:00:00|11.2
>> 1516278240|2018-01-18 00:00:00|11.6
>> 1516013940|2018-01-15 00:00:00|13.1
>> 1581768000|2020-02-15 00:00:00|13.3
>> 1515933960|2018-01-14 00:00:00|13.5
>> 1517401200|2018-01-31 00:00:00|13.6
>> 1547554197|2019-01-15 00:00:00|13.6
>> 1579610280|2020-01-21 00:00:00|13.8
>> 1547528389|2019-01-14 00:00:00|15.3
>> 1548046482|2019-01-20 00:00:00|15.3
>> 1551946191|2019-03-07 00:00:00|15.3
>> 1549800883|2019-02-10 00:00:00|15.9
>> 1576836720|2019-12-20 00:00:00|16.0
>> 1579582320|2020-01-20 00:00:00|16.0
>>
>>
>> On Friday, January 8, 2021 at 5:03:00 PM UTC-5 Arend wrote:
>>
>>> Adding that extra testing for NOT NULL did the trick. All dates (as far 
>>> as I can tell) are now correctly retreived.
>>>
>>> Op vrijdag 8 januari 2021 om 22:33:50 UTC+1 schreef tke...@gmail.com:
>>>
 It appears that you have a null value for mintime in your database. 
 Most likely the problem is that you have no data for 2019-12-15 and 
 2019-12-17. 

 I suspect the older query worked because MIN(value) ignores values, 
 while ordering by value does not.

 This is a bug: the query should check for non null values. I've created 
 issue 635  to track, and 
 (hopefully) fixed in commit 5fbe0d5 
 
 .

 Could you please try this version of xtypes.py 
 
 ?

 Thanks for your help.

 On Fri, Jan 8, 2021 at 12:49 PM Arend  wrote:

> SELECT mintime, from_unixtime(dateTime), min from archive_day_outTemp 
> order by min asc, mintime asc limit 20;
>
> Database weewx
>
>  mintime  from_unixtime(dateTime)  min
>
> NULL 2019-12-15 00:00:00   NULL
>
> NULL 2019-12-17 00:00:00   NULL
>
> 16067062352020-11-30 00:00:00   26.24
>
> 15855519002020-03-30 00:00:00   27.32
>
> 16066899872020-11-29 00:00:00   27.5
>
> 15751884002019-12-01 00:00:00   27.86
>
> 15857247002020-04-01 00:00:00   28.94
>
> 15755337002019-12-05 00:00:00   29.66
>
> 15856392002020-03-31 00:00:00   30.02
>
> 15742407002019-11-20 00:00:00   30.56
>
> 15808905002020-02-05 00:00:00   30.92
>
> 16076328002020-12-10 00:00:00   31.279998
>
> 15751539002019-11-30 00:00:00   31.28
>
> 15795981002020-01-21 00:00:00   31.28
>
> 15850299002020-03-24 00:00:00   31.46
>
> 16094798292021-01-01 00:00:00   31.46
>
> 15752553002019-12-02 00:00:00   31.82
>
> 15849453002020-03-23 00:00:00   31.82
>
> 15851169002020-03-25 00:00:00   31.82
>
> 16076412102020-12-11 00:00:00   31.82
> Op vrijdag 8 januari 2021 om 21:18:54 UTC+1 schreef tke...@gmail.com:
>
>> Then adapt as necessary. Use from_unixtime() instead of datetime() in 
>> the select statement.
>>
>> On Fri, Jan 8, 2021 at 11:49 AM Arend  wrote:
>>
>>> Hello Tom,
>>>
>>> I am using MySQL database.
>>>
>>> Arend
>>>
>>> Op vrijdag 8 januari 2021 om 20:18:20 UTC+1 schreef tke...@gmail.com
>>> :
>>>
 Thanks. Not sure what is happening, but let's take a look at your 
 database. I'm assuming you are using SQLite, and that you used a 
 package 
 installer. You may have to install the tool sqlite3 first

 sudo apt-get install sqlite3

 Then

 *sqlite3 /var/lib/weewx/weewx.sdb*
 sqlite> *select mintime, 
 datetime(dateTime,'unixepoch','localtime'), min from 
 archive_day_outTemp 
 order by min asc, mintime asc limit 20;*
 sqlite> *.quit*

 Let me know what you get.

 -tk

Re: [weewx-user] Latest WeeWX 4.3.0 SQL optimizations may return invalid results

[Tom Keffer]

Those are very different results from the ones you showed before. You'll
have to be the judge of whether minimums were around 2.4, or around 26.24.
That's a big difference, so it should be fairly obvious.

-tk

On Sat, Jan 9, 2021 at 7:03 AM Michael Sanphillipo 
wrote:

> Tom, here are my results. Do these look okay?
>
> 1548937162|2019-01-31 00:00:00|2.4
> 1548910187|2019-01-30 00:00:00|6.4
> 1549090774|2019-02-02 00:00:00|6.6
> 1548998381|2019-02-01 00:00:00|7.5
> 1548071996|2019-01-21 00:00:00|10.0
> 1548160788|2019-01-22 00:00:00|10.8
> 1517661600|2018-02-03 00:00:00|11.2
> 1516278240|2018-01-18 00:00:00|11.6
> 1516013940|2018-01-15 00:00:00|13.1
> 1581768000|2020-02-15 00:00:00|13.3
> 1515933960|2018-01-14 00:00:00|13.5
> 1517401200|2018-01-31 00:00:00|13.6
> 1547554197|2019-01-15 00:00:00|13.6
> 1579610280|2020-01-21 00:00:00|13.8
> 1547528389|2019-01-14 00:00:00|15.3
> 1548046482|2019-01-20 00:00:00|15.3
> 1551946191|2019-03-07 00:00:00|15.3
> 1549800883|2019-02-10 00:00:00|15.9
> 1576836720|2019-12-20 00:00:00|16.0
> 1579582320|2020-01-20 00:00:00|16.0
>
>
> On Friday, January 8, 2021 at 5:03:00 PM UTC-5 Arend wrote:
>
>> Adding that extra testing for NOT NULL did the trick. All dates (as far
>> as I can tell) are now correctly retreived.
>>
>> Op vrijdag 8 januari 2021 om 22:33:50 UTC+1 schreef tke...@gmail.com:
>>
>>> It appears that you have a null value for mintime in your database. Most
>>> likely the problem is that you have no data for 2019-12-15 and 2019-12-17.
>>>
>>> I suspect the older query worked because MIN(value) ignores values,
>>> while ordering by value does not.
>>>
>>> This is a bug: the query should check for non null values. I've created
>>> issue 635  to track, and
>>> (hopefully) fixed in commit 5fbe0d5
>>> 
>>> .
>>>
>>> Could you please try this version of xtypes.py
>>> 
>>> ?
>>>
>>> Thanks for your help.
>>>
>>> On Fri, Jan 8, 2021 at 12:49 PM Arend  wrote:
>>>
 SELECT mintime, from_unixtime(dateTime), min from archive_day_outTemp
 order by min asc, mintime asc limit 20;

 Database weewx

  mintime  from_unixtime(dateTime)  min

 NULL 2019-12-15 00:00:00   NULL

 NULL 2019-12-17 00:00:00   NULL

 16067062352020-11-30 00:00:00   26.24

 15855519002020-03-30 00:00:00   27.32

 16066899872020-11-29 00:00:00   27.5

 15751884002019-12-01 00:00:00   27.86

 15857247002020-04-01 00:00:00   28.94

 15755337002019-12-05 00:00:00   29.66

 15856392002020-03-31 00:00:00   30.02

 15742407002019-11-20 00:00:00   30.56

 15808905002020-02-05 00:00:00   30.92

 16076328002020-12-10 00:00:00   31.279998

 15751539002019-11-30 00:00:00   31.28

 15795981002020-01-21 00:00:00   31.28

 15850299002020-03-24 00:00:00   31.46

 16094798292021-01-01 00:00:00   31.46

 15752553002019-12-02 00:00:00   31.82

 15849453002020-03-23 00:00:00   31.82

 15851169002020-03-25 00:00:00   31.82

 16076412102020-12-11 00:00:00   31.82
 Op vrijdag 8 januari 2021 om 21:18:54 UTC+1 schreef tke...@gmail.com:

> Then adapt as necessary. Use from_unixtime() instead of datetime() in
> the select statement.
>
> On Fri, Jan 8, 2021 at 11:49 AM Arend  wrote:
>
>> Hello Tom,
>>
>> I am using MySQL database.
>>
>> Arend
>>
>> Op vrijdag 8 januari 2021 om 20:18:20 UTC+1 schreef tke...@gmail.com:
>>
>>> Thanks. Not sure what is happening, but let's take a look at your
>>> database. I'm assuming you are using SQLite, and that you used a package
>>> installer. You may have to install the tool sqlite3 first
>>>
>>> sudo apt-get install sqlite3
>>>
>>> Then
>>>
>>> *sqlite3 /var/lib/weewx/weewx.sdb*
>>> sqlite> *select mintime,
>>> datetime(dateTime,'unixepoch','localtime'), min from archive_day_outTemp
>>> order by min asc, mintime asc limit 20;*
>>> sqlite> *.quit*
>>>
>>> Let me know what you get.
>>>
>>> -tk
>>>
>>>
>>>
>>> On Fri, Jan 8, 2021 at 10:01 AM Arend  wrote:
>>>
 After upgrading from WeeWX 4.1.1 to 4.3.0 Invalid dates started to
 show up for mintime.

 In this Belchertown thread the issue is reported by multiple users.

 https://github.com/poblabs/weewx-belchertown/issues/517

 After replacing the SQL optimizations with the previous "mintime"
 SQL strings from 

Re: [weewx-user] AQI graph

[Tom Keffer]

You'll have to ask someone more familiar with AQI and the Belchertown skin.

On Sat, Jan 9, 2021 at 6:42 AM Didier Decoodt 
wrote:

> OK Thanks
> The value is defined in belchertown.py file, how do you put it in archive
> record?
> (sorry for all my questions...)
>
> Le sam. 9 janv. 2021 à 14:36, Tom Keffer  a écrit :
>
>> If the value appears in the archive record under the same name, it will
>> automatically be inserted into the database.
>>
>> On Sat, Jan 9, 2021 at 5:15 AM Didier Decoodt 
>> wrote:
>>
>>> Yes, this is the procedure for adding a new field in database, but how
>>> to insert the value of $aqi variable into this database?
>>>
>>>
>>> Le sam. 9 janv. 2021 à 13:53, Tom Keffer  a écrit :
>>>
 Have you checked the section *Adding a new type to the database
 * in the
 Customizing Guide?

 On Sat, Jan 9, 2021 at 3:26 AM didier@gmail.com <
 didier.deco...@gmail.com> wrote:

> Hi
>
> I have now the Air Quality Indice in Belchertown skin, and I would
> like if it is possible to add this information into mysqlite database in
> order to create a graph.
>
> Is it difficult? Have you a procedure to add an additional data and
> which files I have to modify?
>
> Many thanks
>
> Didier
> https://meteo-auffargis.decoodt.eu
>
> --
> 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/3720516f-0b16-4786-835a-f5e16e2514e7n%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/CAPq0zEB5ao1hE70M%2Bue_NYc9UcLkh8WkQ4ub-Y3zKr3Lsc8NUQ%40mail.gmail.com
 
 .

>>>
>>>
>>> --
>>> Quel temps fait-il à Auffargis  ?
>>>
>>> --
>>> 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/CAAvt3%3DT1%2B3MZw8W0C6SR5GW8vHr%3DYfPMf1TAHM2x5xwtMD_o7A%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/CAPq0zEDGQ9sa2mhR1xqr9wtbwHMupsi-qBbxmhVJp8fXydKfAw%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Quel temps fait-il à Auffargis  ?
>
> --
> 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/CAAvt3%3DQ9OQwsunRTkLyVsmP_HRnbj3KZY0C%3Dn_6rDqrS%2Bby9Mg%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/CAPq0zECNbmvEOnTjJi7PiiRP4TTVCqZq3NBArTNOpQDr2xwOCg%40mail.gmail.com.

Re: [weewx-user] Latest WeeWX 4.3.0 SQL optimizations may return invalid results

[Michael Sanphillipo]

Tom, here are my results. Do these look okay?

1548937162|2019-01-31 00:00:00|2.4
1548910187|2019-01-30 00:00:00|6.4
1549090774|2019-02-02 00:00:00|6.6
1548998381|2019-02-01 00:00:00|7.5
1548071996|2019-01-21 00:00:00|10.0
1548160788|2019-01-22 00:00:00|10.8
1517661600|2018-02-03 00:00:00|11.2
1516278240|2018-01-18 00:00:00|11.6
1516013940|2018-01-15 00:00:00|13.1
1581768000|2020-02-15 00:00:00|13.3
1515933960|2018-01-14 00:00:00|13.5
1517401200|2018-01-31 00:00:00|13.6
1547554197|2019-01-15 00:00:00|13.6
1579610280|2020-01-21 00:00:00|13.8
1547528389|2019-01-14 00:00:00|15.3
1548046482|2019-01-20 00:00:00|15.3
1551946191|2019-03-07 00:00:00|15.3
1549800883|2019-02-10 00:00:00|15.9
1576836720|2019-12-20 00:00:00|16.0
1579582320|2020-01-20 00:00:00|16.0


On Friday, January 8, 2021 at 5:03:00 PM UTC-5 Arend wrote:

> Adding that extra testing for NOT NULL did the trick. All dates (as far as 
> I can tell) are now correctly retreived.
>
> Op vrijdag 8 januari 2021 om 22:33:50 UTC+1 schreef tke...@gmail.com:
>
>> It appears that you have a null value for mintime in your database. Most 
>> likely the problem is that you have no data for 2019-12-15 and 2019-12-17. 
>>
>> I suspect the older query worked because MIN(value) ignores values, while 
>> ordering by value does not.
>>
>> This is a bug: the query should check for non null values. I've created 
>> issue 635  to track, and 
>> (hopefully) fixed in commit 5fbe0d5 
>> 
>> .
>>
>> Could you please try this version of xtypes.py 
>> 
>> ?
>>
>> Thanks for your help.
>>
>> On Fri, Jan 8, 2021 at 12:49 PM Arend  wrote:
>>
>>> SELECT mintime, from_unixtime(dateTime), min from archive_day_outTemp 
>>> order by min asc, mintime asc limit 20;
>>>
>>> Database weewx
>>>
>>>  mintime  from_unixtime(dateTime)  min
>>>
>>> NULL 2019-12-15 00:00:00   NULL
>>>
>>> NULL 2019-12-17 00:00:00   NULL
>>>
>>> 16067062352020-11-30 00:00:00   26.24
>>>
>>> 15855519002020-03-30 00:00:00   27.32
>>>
>>> 16066899872020-11-29 00:00:00   27.5
>>>
>>> 15751884002019-12-01 00:00:00   27.86
>>>
>>> 15857247002020-04-01 00:00:00   28.94
>>>
>>> 15755337002019-12-05 00:00:00   29.66
>>>
>>> 15856392002020-03-31 00:00:00   30.02
>>>
>>> 15742407002019-11-20 00:00:00   30.56
>>>
>>> 15808905002020-02-05 00:00:00   30.92
>>>
>>> 16076328002020-12-10 00:00:00   31.279998
>>>
>>> 15751539002019-11-30 00:00:00   31.28
>>>
>>> 15795981002020-01-21 00:00:00   31.28
>>>
>>> 15850299002020-03-24 00:00:00   31.46
>>>
>>> 16094798292021-01-01 00:00:00   31.46
>>>
>>> 15752553002019-12-02 00:00:00   31.82
>>>
>>> 15849453002020-03-23 00:00:00   31.82
>>>
>>> 15851169002020-03-25 00:00:00   31.82
>>>
>>> 16076412102020-12-11 00:00:00   31.82
>>> Op vrijdag 8 januari 2021 om 21:18:54 UTC+1 schreef tke...@gmail.com:
>>>
 Then adapt as necessary. Use from_unixtime() instead of datetime() in 
 the select statement.

 On Fri, Jan 8, 2021 at 11:49 AM Arend  wrote:

> Hello Tom,
>
> I am using MySQL database.
>
> Arend
>
> Op vrijdag 8 januari 2021 om 20:18:20 UTC+1 schreef tke...@gmail.com:
>
>> Thanks. Not sure what is happening, but let's take a look at your 
>> database. I'm assuming you are using SQLite, and that you used a package 
>> installer. You may have to install the tool sqlite3 first
>>
>> sudo apt-get install sqlite3
>>
>> Then
>>
>> *sqlite3 /var/lib/weewx/weewx.sdb*
>> sqlite> *select mintime, datetime(dateTime,'unixepoch','localtime'), 
>> min from archive_day_outTemp order by min asc, mintime asc limit 20;*
>> sqlite> *.quit*
>>
>> Let me know what you get.
>>
>> -tk
>>
>>
>>
>> On Fri, Jan 8, 2021 at 10:01 AM Arend  wrote:
>>
>>> After upgrading from WeeWX 4.1.1 to 4.3.0 Invalid dates started to 
>>> show up for mintime.
>>>
>>> In this Belchertown thread the issue is reported by multiple users.
>>>
>>> https://github.com/poblabs/weewx-belchertown/issues/517
>>>
>>> After replacing the SQL optimizations with the previous "mintime" 
>>> SQL strings from WeeWX 4.1.1 the problem was solved.
>>>
>>> Screenshot using optimized (4.3.0) SQL showing invalid dates using 
>>> "mintime":
>>>
>>> [image: weewx_belchertown_records_invalid_dates.png]
>>>
>>> Replacing the relevant "mintime" code in xtypes.py with SQL strings 
>>> from 4.1.1:
>>>
>>> [image: agg_sql_dict.png]
>>> [image: daily_sql_dict.png]
>>>
>>> Now the previous 

Re: [weewx-user] AQI graph

[Didier Decoodt]

OK Thanks
The value is defined in belchertown.py file, how do you put it in archive
record?
(sorry for all my questions...)

Le sam. 9 janv. 2021 à 14:36, Tom Keffer  a écrit :

> If the value appears in the archive record under the same name, it will
> automatically be inserted into the database.
>
> On Sat, Jan 9, 2021 at 5:15 AM Didier Decoodt 
> wrote:
>
>> Yes, this is the procedure for adding a new field in database, but how to
>> insert the value of $aqi variable into this database?
>>
>>
>> Le sam. 9 janv. 2021 à 13:53, Tom Keffer  a écrit :
>>
>>> Have you checked the section *Adding a new type to the database
>>> * in the
>>> Customizing Guide?
>>>
>>> On Sat, Jan 9, 2021 at 3:26 AM didier@gmail.com <
>>> didier.deco...@gmail.com> wrote:
>>>
 Hi

 I have now the Air Quality Indice in Belchertown skin, and I would like
 if it is possible to add this information into mysqlite database in order
 to create a graph.

 Is it difficult? Have you a procedure to add an additional data and
 which files I have to modify?

 Many thanks

 Didier
 https://meteo-auffargis.decoodt.eu

 --
 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/3720516f-0b16-4786-835a-f5e16e2514e7n%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/CAPq0zEB5ao1hE70M%2Bue_NYc9UcLkh8WkQ4ub-Y3zKr3Lsc8NUQ%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Quel temps fait-il à Auffargis  ?
>>
>> --
>> 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/CAAvt3%3DT1%2B3MZw8W0C6SR5GW8vHr%3DYfPMf1TAHM2x5xwtMD_o7A%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/CAPq0zEDGQ9sa2mhR1xqr9wtbwHMupsi-qBbxmhVJp8fXydKfAw%40mail.gmail.com
> 
> .
>


-- 
Quel temps fait-il à Auffargis  ?

-- 
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/CAAvt3%3DQ9OQwsunRTkLyVsmP_HRnbj3KZY0C%3Dn_6rDqrS%2Bby9Mg%40mail.gmail.com.

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

[miso]

Tom, I meant apt-get. My mistake.
miso


so 9. 1. 2021 o 13:49 Tom Keffer  napísal(a):

> Not sure what you mean. Upgrades should be done through apt-get, not dpkg.
>
> On Fri, Jan 8, 2021 at 10:02 PM miso  wrote:
>
>> I had this issue already before. As inexperienced user, I reinstalled the
>> whole Raspberry again. What about making a python script to make the dpkg
>> update work?
>>
>> miso
>>
>>
>> pi 8. 1. 2021 o 20:41 vince  napísal(a):
>>
>>> On Friday, January 8, 2021 at 10:48:50 AM UTC-8 Tom Keffer wrote:
>>>
 I've had the same experience. But, as I understand it, the script that
 runs the "keep your weewx.conf" file is supplied by Debian. It's not
 something that we can control. Matthew is the expert on this.

>>>
>>> Thanks.  Just to clarify, I'm not asking for any code change, just a bit
>>> more explanation in the docs re: what happens if you answer each way.
>>>
>>> Maybe somebody other than Matthew could work it if so inclined.
>>>
>>> How'bout I add an issue to get it on a to-do list for possibily someday
>>> ?
>>>
>>> --
>>> 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/uCY_K9_gAqw/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/edb7a7ba-2565-417d-9b7a-471c8bbd3b87n%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/CAJ0Y92B0%3DLO4bfFnSjyr81yPh3Lyg-HOC2FuZfzgQjH93LVivw%40mail.gmail.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/uCY_K9_gAqw/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/CAPq0zEBKb-QjhTOxy8vnE9x3owpudiCK67RzUUKC4%2BRYjpchJg%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/CAJ0Y92Ahhy93-pNxXgdDAWOqBUGcYz3%2BSc5Tqnc6_XiCCfAkkQ%40mail.gmail.com.

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

[Nate Bargmann]

* On 2021 09 Jan 06:50 -0600, Tom Keffer wrote:
> Not sure what you mean. Upgrades should be done through apt-get, not dpkg.

Actually, since Stretch and especially with Buster (Debian 10), 'apt'
should be used in favor of 'apt-get' which is more low level.

apt can even be used to install a manually downloaded package, e.g. 
'apt install ./foo-1.2.3.deb' and it will handle installing the
dependencies assuming they are available in the configured archives.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

-- 
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/20210109134710.6mtc7ejgkkbnv2sb%40n0nb.us.


signature.asc
Description: PGP signature

Re: [weewx-user] AQI graph

[Tom Keffer]

If the value appears in the archive record under the same name, it will
automatically be inserted into the database.

On Sat, Jan 9, 2021 at 5:15 AM Didier Decoodt 
wrote:

> Yes, this is the procedure for adding a new field in database, but how to
> insert the value of $aqi variable into this database?
>
>
> Le sam. 9 janv. 2021 à 13:53, Tom Keffer  a écrit :
>
>> Have you checked the section *Adding a new type to the database
>> * in the
>> Customizing Guide?
>>
>> On Sat, Jan 9, 2021 at 3:26 AM didier@gmail.com <
>> didier.deco...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> I have now the Air Quality Indice in Belchertown skin, and I would like
>>> if it is possible to add this information into mysqlite database in order
>>> to create a graph.
>>>
>>> Is it difficult? Have you a procedure to add an additional data and
>>> which files I have to modify?
>>>
>>> Many thanks
>>>
>>> Didier
>>> https://meteo-auffargis.decoodt.eu
>>>
>>> --
>>> 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/3720516f-0b16-4786-835a-f5e16e2514e7n%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/CAPq0zEB5ao1hE70M%2Bue_NYc9UcLkh8WkQ4ub-Y3zKr3Lsc8NUQ%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Quel temps fait-il à Auffargis  ?
>
> --
> 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/CAAvt3%3DT1%2B3MZw8W0C6SR5GW8vHr%3DYfPMf1TAHM2x5xwtMD_o7A%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/CAPq0zEDGQ9sa2mhR1xqr9wtbwHMupsi-qBbxmhVJp8fXydKfAw%40mail.gmail.com.

Re: [weewx-user] AQI graph

[Didier Decoodt]

Yes, this is the procedure for adding a new field in database, but how to
insert the value of $aqi variable into this database?


Le sam. 9 janv. 2021 à 13:53, Tom Keffer  a écrit :

> Have you checked the section *Adding a new type to the database
> * in the
> Customizing Guide?
>
> On Sat, Jan 9, 2021 at 3:26 AM didier@gmail.com <
> didier.deco...@gmail.com> wrote:
>
>> Hi
>>
>> I have now the Air Quality Indice in Belchertown skin, and I would like
>> if it is possible to add this information into mysqlite database in order
>> to create a graph.
>>
>> Is it difficult? Have you a procedure to add an additional data and which
>> files I have to modify?
>>
>> Many thanks
>>
>> Didier
>> https://meteo-auffargis.decoodt.eu
>>
>> --
>> 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/3720516f-0b16-4786-835a-f5e16e2514e7n%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/CAPq0zEB5ao1hE70M%2Bue_NYc9UcLkh8WkQ4ub-Y3zKr3Lsc8NUQ%40mail.gmail.com
> 
> .
>


-- 
Quel temps fait-il à Auffargis  ?

-- 
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/CAAvt3%3DT1%2B3MZw8W0C6SR5GW8vHr%3DYfPMf1TAHM2x5xwtMD_o7A%40mail.gmail.com.

Re: [weewx-user] AQI graph

[Tom Keffer]

Have you checked the section *Adding a new type to the database
* in the
Customizing Guide?

On Sat, Jan 9, 2021 at 3:26 AM didier@gmail.com <
didier.deco...@gmail.com> wrote:

> Hi
>
> I have now the Air Quality Indice in Belchertown skin, and I would like if
> it is possible to add this information into mysqlite database in order to
> create a graph.
>
> Is it difficult? Have you a procedure to add an additional data and which
> files I have to modify?
>
> Many thanks
>
> Didier
> https://meteo-auffargis.decoodt.eu
>
> --
> 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/3720516f-0b16-4786-835a-f5e16e2514e7n%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/CAPq0zEB5ao1hE70M%2Bue_NYc9UcLkh8WkQ4ub-Y3zKr3Lsc8NUQ%40mail.gmail.com.

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

[Tom Keffer]

Not sure what you mean. Upgrades should be done through apt-get, not dpkg.

On Fri, Jan 8, 2021 at 10:02 PM miso  wrote:

> I had this issue already before. As inexperienced user, I reinstalled the
> whole Raspberry again. What about making a python script to make the dpkg
> update work?
>
> miso
>
>
> pi 8. 1. 2021 o 20:41 vince  napísal(a):
>
>> On Friday, January 8, 2021 at 10:48:50 AM UTC-8 Tom Keffer wrote:
>>
>>> I've had the same experience. But, as I understand it, the script that
>>> runs the "keep your weewx.conf" file is supplied by Debian. It's not
>>> something that we can control. Matthew is the expert on this.
>>>
>>
>> Thanks.  Just to clarify, I'm not asking for any code change, just a bit
>> more explanation in the docs re: what happens if you answer each way.
>>
>> Maybe somebody other than Matthew could work it if so inclined.
>>
>> How'bout I add an issue to get it on a to-do list for possibily someday ?
>>
>>
>> --
>> 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/uCY_K9_gAqw/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/edb7a7ba-2565-417d-9b7a-471c8bbd3b87n%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/CAJ0Y92B0%3DLO4bfFnSjyr81yPh3Lyg-HOC2FuZfzgQjH93LVivw%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/CAPq0zEBKb-QjhTOxy8vnE9x3owpudiCK67RzUUKC4%2BRYjpchJg%40mail.gmail.com.

[weewx-user] GW1000 driver v0.2.0 release

[gjr80]

I have released v0.2.0 on GitHub 
. 

This main feature of this release is support for the WH45 Indoor CO2 PM2.5 
PM10 Temperature and Humidity 5-in-1 Air Quality Sensor. If you have a WH45 
sensor and it has been linked to your GW1000 v0.2.0 of the driver should 
automatically pick up and emit the WH45 sensor data.

v0.2.0 also sees changes in the naming of the 24 hour average particulate 
concentration fields. Unfortunately this will mean anyone that is using 
these fields will need to make one or more changes to their WeeWX 
installation. I have outlined the changes and which users need to make 
changes and how to make the necessary changes in a wiki article Changes to 
24 hour average particulate concentration field names 
.
 
If you have a WH41, WH43 or WH45 sensor and use the 24 hour average 
particulate concentration fields in any way I strongly suggest you 
thoroughly read the linked wiki article.

The majority of the other changes in v0.2.0 relate to running the driver 
directly, in particular displaying the GW1000 and sensor configuration 
information currently only available through the WS View app.

Those that installed v0.1.0 via wee_extension can upgrade to v0.2.0 as 
follows:

$ wget -P /var/tmp 
https://github.com/gjr80/weewx-gw1000/releases/download/v0.2.0/gw1000-0.2.0.tar.gz
$ wee_extension --install=/var/tmp/gw1000-0.2.0.tar.gz

Note: wee_extension may require the use of sudo the path to wee_extension 
as applicable.

Gary

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

[weewx-user] AQI graph

[didier....@gmail.com]

Hi

I have now the Air Quality Indice in Belchertown skin, and I would like if 
it is possible to add this information into mysqlite database in order to 
create a graph.

Is it difficult? Have you a procedure to add an additional data and which 
files I have to modify?

Many thanks

Didier
https://meteo-auffargis.decoodt.eu

-- 
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/3720516f-0b16-4786-835a-f5e16e2514e7n%40googlegroups.com.