[weewx-user] Re: WeeWX on Raspberry Pi Pico and MicroPython

[garrya...@gmail.com]

Davis Pro2 by USB.

On Thursday, December 23, 2021 at 8:06:59 PM UTC-8 vince wrote:

> On Thursday, December 23, 2021 at 6:02:57 PM UTC-8 garrya...@gmail.com 
> wrote:
>
>> With apologies if there is already a thread about this but will WeeWX run 
>> on a Raspberry Pi Pico with MicroPython?
>> If no one has actually tried it, and the consensus is that it 
>> might/should work, I might give it a try and report back.
>>
>>
> For starters - what kind of station do you have and how would you 
> interface it with a pico ?
>
> But I'd be a bit surprised if it met the python prerequisites for weewx, 
> specifically the imaging libraries and Cheetah.
>
>

-- 
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/9d70176d-2207-42ec-8711-946b86674a34n%40googlegroups.com.

[weewx-user] WeeWX on Raspberry Pi Pico and MicroPython

[garrya...@gmail.com]

With apologies if there is already a thread about this but will WeeWX run 
on a Raspberry Pi Pico with MicroPython?

If no one has actually tried it, and the consensus is that it might/should 
work, I might give it a try and report back.

Regards,

Garry

-- 
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/3e387cf9-5b5b-4aee-b20d-565551b0cecbn%40googlegroups.com.

Re: [weewx-user] PM2 - Process Manager 2 and WeeWX

[garrya...@gmail.com]

Thanks for the advice.  I will forego using PM2, or any other process 
manager, at this time, and give "netmon.sh" a try.

But!  Re: "if you can figure out a way to tell when (if) you need to touch 
weewx at all."  that's why I was hoping to use something like PM2 'casue it 
seems to me they figured it out.

Regards,

Garry

On Sunday, March 28, 2021 at 1:05:27 PM UTC-7 vince wrote:

> See if 
> https://github.com/vinceskahan/raspi-odds-and-ends/blob/master/netmon.sh 
> helps you any for trying to self-heal your wifi.  I haven't run it in years 
> since I fixed my home wifi setup by switching to Ubiquiti gear and 
> essentially out-radiating the badly configured neighbors, but it used to 
> work for me.   Probably needs a little tweaking for modern Raspbian but it 
> should be self-evident.
>
> I wouldn't run pm2 for what you're trying to do.  Maybe supervisord but 
> even that is way overkill.   Personally I'd do it in bash called 
> periodically from crontab if you can figure out a way to tell when (if) you 
> need to touch weewx at all.
>
> On Sunday, March 28, 2021 at 11:30:29 AM UTC-7 garrya...@gmail.com wrote:
>
>> Totally agree with your comments.
>>
>> I’m trying to handle network and remote server issues for a station I 
>> don’t have remote access to, and sometimes (depending on time of year) have 
>> to wait a few days before I can go onsite.  So I am trying to handle 
>> conditions external to WeeWX.
>>
>> One issue is Raspberry Pi OS “wlan0 carrier lost problem” (see 
>> https://www.raspberrypi.org/forums/viewtopic.php?t=233847 for a 
>> conversation).
>>
>> Even if I fix each problem as they arise, I’d like to have a “belts & 
>> suspenders” backup solution.
>>
>> Regards,
>>
>> Garry Lockyer
>> C: +1.250.689.0686 <(250)%20689-0686>
>> E: ga...@lockyer.ca
>>
>>
>> On Mar 28, 2021, at 11:18, Tom Keffer  wrote:
>>
>> 
>>
>> I don't know anything about PM2, but it would be useful to know where 
>> you're trying to get. Weewx is extremely stable and can literally run for 
>> years without rebooting. If it is crashing, it would be better to fix that 
>> problem, rather than use a process manager.
>>
>> On Sun, Mar 28, 2021 at 11:11 AM garrya...@gmail.com  
>> wrote:
>>
>>> PM2 (https://pm2.keymetrics.io/) is a process manager often associated 
>>> with node.js apps written in Java Script. It can also manage processes 
>>> written in Python (see: 
>>> https://pm2.io/blog/2018/09/19/Manage-Python-Processes).
>>>
>>> I was not able to get PM2 working with WeeWX - has anyone got it going?
>>>
>>> I was able to get the example 'hello.py' script working.
>>>
>>> When I tried 'sudo pm2 start /home/weewx/bin/weewxd' I got the following 
>>> error (viewed using 'sudo pm2 logs'):
>>>
>>> 1|weewxd  | /home/weewx/bin/weewxd:2
>>> 1|weewxd  | #
>>> 1|weewxd  | ^
>>> 1|weewxd  | SyntaxError: Invalid or unexpected token
>>> 1|weewxd  | at Module._compile 
>>> (internal/modules/cjs/loader.js:723:23)
>>> 1|weewxd  | at Object.Module._extensions..js 
>>> (internal/modules/cjs/loader.js:789:10)
>>> 1|weewxd  | at Module.load (internal/modules/cjs/loader.js:653:32)
>>> 1|weewxd  | at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
>>> 1|weewxd  | at Function.Module._load 
>>> (internal/modules/cjs/loader.js:585:3)
>>> 1|weewxd  | at Object. 
>>> (/usr/lib/node_modules/pm2/lib/ProcessContainerFork.js:33:23)
>>> 1|weewxd  | at Module._compile 
>>> (internal/modules/cjs/loader.js:778:30)
>>> 1|weewxd  | at Object.Module._extensions..js 
>>> (internal/modules/cjs/loader.js:789:10)
>>> 1|weewxd  | at Module.load (internal/modules/cjs/loader.js:653:32)
>>> 1|weewxd  | at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
>>> PM2   | App [weewxd:1] exited with code [1] via signal [SIGINT]
>>> PM2   | Script /home/weewx/bin/weewxd had too many unstable restarts 
>>> (16). Stopped. "errored"
>>>
>>> I suspected that was because PM2 uses the file extension to determine 
>>> the script language so I changed the name of 'weewxd' to 'weewxd.py'.  
>>> Things progressed a little further but I got:
>>>
>>> /root/.pm2/logs/weewxd-out.log last 15 lines:
>>> /root/.pm2/logs/weewxd-error.log last 15 lines:
>>> 0|weewxd   |   File &

Re: [weewx-user] PM2 - Process Manager 2 and WeeWX

[garrya...@gmail.com]

Sorry for late response.

Using a RPi Zero W so no chance to use wire.  In fact, virtually no chance 
to make any changes to network at remote site.

Regards,

Garry

On Sunday, March 28, 2021 at 1:03:52 PM UTC-7 tomn...@frontier.com wrote:

> Hi Gary,  esp. in a remote location like that, can you use ethernet 
> instead of wi-fi?  I ran into a similar problem recently with an RPi-zero 
> that was losing wi-fi, even though it's right across the room with nothing 
> in between.  From what I found researching solutions, in some cases, it 
> takes a reboot to recover.  In any case, I ended up writing a script that 
> will try the 2-3 non-boot things to recover wi-fi, and reboot when all else 
> fails.  I can share it, but it's got a few dependencies...
> Not positive it works, since the device seems to have stayed up since I 
> set it up in cron, and I haven't checked the system logs.  There were a 
> couple of other minor things I updated related to some boot warnings
> with wi-fi.
>
> Chris
>
> On Sunday, March 28, 2021 at 12:30:29 PM UTC-6 garrya...@gmail.com wrote:
>
>> Totally agree with your comments.
>>
>> I’m trying to handle network and remote server issues for a station I 
>> don’t have remote access to, and sometimes (depending on time of year) have 
>> to wait a few days before I can go onsite.  So I am trying to handle 
>> conditions external to WeeWX.
>>
>> One issue is Raspberry Pi OS “wlan0 carrier lost problem” (see 
>> https://www.raspberrypi.org/forums/viewtopic.php?t=233847 for a 
>> conversation).
>>
>> Even if I fix each problem as they arise, I’d like to have a “belts & 
>> suspenders” backup solution.
>>
>> Regards,
>>
>> Garry Lockyer
>> C: +1.250.689.0686 <(250)%20689-0686>
>> E: ga...@lockyer.ca
>>
>>
>> On Mar 28, 2021, at 11:18, Tom Keffer  wrote:
>>
>> 
>>
>> I don't know anything about PM2, but it would be useful to know where 
>> you're trying to get. Weewx is extremely stable and can literally run for 
>> years without rebooting. If it is crashing, it would be better to fix that 
>> problem, rather than use a process manager.
>>
>> On Sun, Mar 28, 2021 at 11:11 AM garrya...@gmail.com  
>> wrote:
>>
>>> PM2 (https://pm2.keymetrics.io/) is a process manager often associated 
>>> with node.js apps written in Java Script. It can also manage processes 
>>> written in Python (see: 
>>> https://pm2.io/blog/2018/09/19/Manage-Python-Processes).
>>>
>>> I was not able to get PM2 working with WeeWX - has anyone got it going?
>>>
>>> I was able to get the example 'hello.py' script working.
>>>
>>> When I tried 'sudo pm2 start /home/weewx/bin/weewxd' I got the following 
>>> error (viewed using 'sudo pm2 logs'):
>>>
>>> 1|weewxd  | /home/weewx/bin/weewxd:2
>>> 1|weewxd  | #
>>> 1|weewxd  | ^
>>> 1|weewxd  | SyntaxError: Invalid or unexpected token
>>> 1|weewxd  | at Module._compile 
>>> (internal/modules/cjs/loader.js:723:23)
>>> 1|weewxd  | at Object.Module._extensions..js 
>>> (internal/modules/cjs/loader.js:789:10)
>>> 1|weewxd  | at Module.load (internal/modules/cjs/loader.js:653:32)
>>> 1|weewxd  | at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
>>> 1|weewxd  | at Function.Module._load 
>>> (internal/modules/cjs/loader.js:585:3)
>>> 1|weewxd  | at Object. 
>>> (/usr/lib/node_modules/pm2/lib/ProcessContainerFork.js:33:23)
>>> 1|weewxd  | at Module._compile 
>>> (internal/modules/cjs/loader.js:778:30)
>>> 1|weewxd  | at Object.Module._extensions..js 
>>> (internal/modules/cjs/loader.js:789:10)
>>> 1|weewxd  | at Module.load (internal/modules/cjs/loader.js:653:32)
>>> 1|weewxd  | at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
>>> PM2   | App [weewxd:1] exited with code [1] via signal [SIGINT]
>>> PM2   | Script /home/weewx/bin/weewxd had too many unstable restarts 
>>> (16). Stopped. "errored"
>>>
>>> I suspected that was because PM2 uses the file extension to determine 
>>> the script language so I changed the name of 'weewxd' to 'weewxd.py'.  
>>> Things progressed a little further but I got:
>>>
>>> /root/.pm2/logs/weewxd-out.log last 15 lines:
>>> /root/.pm2/logs/weewxd-error.log last 15 lines:
>>> 0|weewxd   |   File "/home/weewx/bin/weewxd.py", line 20, in 
>>> 0|weewxd   | i

Re: [weewx-user] Re: Version 4.5.0 released

[garrya...@gmail.com]

Upgrading using "weewx-master.zip" appears to have worked perfectly!

Thanks Tom!

On Friday, April 2, 2021 at 10:03:53 AM UTC-7 tke...@gmail.com wrote:

> My apologies. Forgot that little step!
>
> On Fri, Apr 2, 2021 at 9:41 AM Tarmo  wrote:
>
>> I'm sure, it is just temporarily in 
>> weewx.com/downloads/development_versions/weewx-4.5.0.tar.gz
>>
>> On Friday, April 2, 2021 at 6:11:42 PM UTC+3 tke...@gmail.com wrote:
>>
>>> *Change log*
>>>
>>> The utility wee_database has new options --add-column, --rename-column, and
>>> --drop-columns for adding, renaming, and deleting columns in the database.
>>>
>>> New optional tag ".series()", for creating and formatting series in 
>>> templates.
>>> See the document series_tags.md in the docs subdirectory. This is still
>>> experimental and subject to change! Addresses issue #341.
>>>
>>> New optional tag ".json()" for formatting results as JSON.
>>>
>>> New optional tag ".round()". Useful for rounding results of .raw and .json 
>>> tags.
>>>
>>> Improved performance when calculating series using aggregation periods that 
>>> are
>>> multiples of a day.
>>>
>>> Changed NOAA reports to use the 'normalized_ascii' encoding instead of 
>>> 'utf8'
>>> (which did not display correctly for most browsers). Fixes issue #646.
>>>
>>> Plots longer than 2 years use a 6 month time increment.
>>>
>>> Uploads to PWSWeather and WOW now use HTTPS. Fixes issue #650.
>>>
>>> Fixed bug that prevented the Vantage driver from waiting before a wakeup 
>>> retry.
>>> Thanks to user Les Niles!
>>>
>>> Changed the way of expressing the old "wview" schema to the new V4 way.
>>> Hopefully, this will lead to fewer support issues. Fixes issue #651.
>>>
>>> Fixed problem where iterating over a time period without an aggregation 
>>> would
>>> wrongly include the record on the left.
>>>
>>> Fixed bug that caused the incorrect label to be applied to plots where the
>>> aggregation type changes the unit. Fixes issue #654.
>>>
>>> Plots now locate the x-coordinate in the middle of the aggregation interval 
>>> for
>>> all aggregation types (not just min, max, avg). Revisits PR #232.
>>>
>>> Added new time units 'unix_epoch_ms' and 'unix_epoch_ns', which are unix 
>>> epoch
>>> time in milliseconds and nanoseconds, respectively.
>>>
>>> The FTP uploader now calculates and saves a hash value for each uploaded 
>>> file.
>>> If it does not change, the file is not uploaded, resulting in significant
>>> time savings. PR #655. Thanks to user Karen!
>>>
>>> Updated the version of six.py included with WeeWX to 1.15.0. Fixes issue 
>>> #657.
>>>
>>> Option aggregate_interval can now be specified by using one of the 
>>> "shortcuts",
>>> that is, 'hour', 'day', 'week', 'month', or 'year'.
>>>
>>> Options "log_success" and "log_failure" are now honored by the StdArchive
>>> service.
>>>
>>>
>>> -- 
>> 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/b8711657-b4de-4c2a-b0c6-172e1eae1ee6n%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/d2127701-a135-488f--986d0c94c8b9n%40googlegroups.com.

[weewx-user] Re: Version 4.5.0 released

[garrya...@gmail.com]

Does a "get code" from github, which gets you "weewx-master.zip", get the 
exact same package as 
weewx.com/downloads/development_versions/weewx-4.5.0.tar.gz?

Going to try using "weewx-master.zip" . . .

Regards,

Garry


On Friday, April 2, 2021 at 9:41:28 AM UTC-7 Tarmo wrote:

> I'm sure, it is just temporarily in 
> weewx.com/downloads/development_versions/weewx-4.5.0.tar.gz
>
> On Friday, April 2, 2021 at 6:11:42 PM UTC+3 tke...@gmail.com wrote:
>
>> *Change log*
>>
>> The utility wee_database has new options --add-column, --rename-column, and
>> --drop-columns for adding, renaming, and deleting columns in the database.
>>
>> New optional tag ".series()", for creating and formatting series in 
>> templates.
>> See the document series_tags.md in the docs subdirectory. This is still
>> experimental and subject to change! Addresses issue #341.
>>
>> New optional tag ".json()" for formatting results as JSON.
>>
>> New optional tag ".round()". Useful for rounding results of .raw and .json 
>> tags.
>>
>> Improved performance when calculating series using aggregation periods that 
>> are
>> multiples of a day.
>>
>> Changed NOAA reports to use the 'normalized_ascii' encoding instead of 'utf8'
>> (which did not display correctly for most browsers). Fixes issue #646.
>>
>> Plots longer than 2 years use a 6 month time increment.
>>
>> Uploads to PWSWeather and WOW now use HTTPS. Fixes issue #650.
>>
>> Fixed bug that prevented the Vantage driver from waiting before a wakeup 
>> retry.
>> Thanks to user Les Niles!
>>
>> Changed the way of expressing the old "wview" schema to the new V4 way.
>> Hopefully, this will lead to fewer support issues. Fixes issue #651.
>>
>> Fixed problem where iterating over a time period without an aggregation would
>> wrongly include the record on the left.
>>
>> Fixed bug that caused the incorrect label to be applied to plots where the
>> aggregation type changes the unit. Fixes issue #654.
>>
>> Plots now locate the x-coordinate in the middle of the aggregation interval 
>> for
>> all aggregation types (not just min, max, avg). Revisits PR #232.
>>
>> Added new time units 'unix_epoch_ms' and 'unix_epoch_ns', which are unix 
>> epoch
>> time in milliseconds and nanoseconds, respectively.
>>
>> The FTP uploader now calculates and saves a hash value for each uploaded 
>> file.
>> If it does not change, the file is not uploaded, resulting in significant
>> time savings. PR #655. Thanks to user Karen!
>>
>> Updated the version of six.py included with WeeWX to 1.15.0. Fixes issue 
>> #657.
>>
>> Option aggregate_interval can now be specified by using one of the 
>> "shortcuts",
>> that is, 'hour', 'day', 'week', 'month', or 'year'.
>>
>> Options "log_success" and "log_failure" are now honored by the StdArchive
>> service.
>>
>>
>>

-- 
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/f2ad16d8-f56c-44ee-950c-8e6f5e902105n%40googlegroups.com.

[weewx-user] PM2 - Process Manager 2 and WeeWX

[garrya...@gmail.com]

PM2 (https://pm2.keymetrics.io/) is a process manager often associated with 
node.js apps written in Java Script. It can also manage processes written 
in Python (see: https://pm2.io/blog/2018/09/19/Manage-Python-Processes).

I was not able to get PM2 working with WeeWX - has anyone got it going?

I was able to get the example 'hello.py' script working.

When I tried 'sudo pm2 start /home/weewx/bin/weewxd' I got the following 
error (viewed using 'sudo pm2 logs'):

1|weewxd  | /home/weewx/bin/weewxd:2
1|weewxd  | #
1|weewxd  | ^
1|weewxd  | SyntaxError: Invalid or unexpected token
1|weewxd  | at Module._compile (internal/modules/cjs/loader.js:723:23)
1|weewxd  | at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:789:10)
1|weewxd  | at Module.load (internal/modules/cjs/loader.js:653:32)
1|weewxd  | at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
1|weewxd  | at Function.Module._load 
(internal/modules/cjs/loader.js:585:3)
1|weewxd  | at Object. 
(/usr/lib/node_modules/pm2/lib/ProcessContainerFork.js:33:23)
1|weewxd  | at Module._compile (internal/modules/cjs/loader.js:778:30)
1|weewxd  | at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:789:10)
1|weewxd  | at Module.load (internal/modules/cjs/loader.js:653:32)
1|weewxd  | at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
PM2   | App [weewxd:1] exited with code [1] via signal [SIGINT]
PM2   | Script /home/weewx/bin/weewxd had too many unstable restarts 
(16). Stopped. "errored"

I suspected that was because PM2 uses the file extension to determine the 
script language so I changed the name of 'weewxd' to 'weewxd.py'.  Things 
progressed a little further but I got:

/root/.pm2/logs/weewxd-out.log last 15 lines:
/root/.pm2/logs/weewxd-error.log last 15 lines:
0|weewxd   |   File "/home/weewx/bin/weewxd.py", line 20, in 
0|weewxd   | import configobj
0|weewxd   | ImportError: No module named configobj
0|weewxd   | Traceback (most recent call last):
0|weewxd   |   File "/home/weewx/bin/weewxd.py", line 20, in 
0|weewxd   | import configobj
0|weewxd   | ImportError: No module named configobj
0|weewxd   | Traceback (most recent call last):
0|weewxd   |   File "/home/weewx/bin/weewxd.py", line 20, in 
0|weewxd   | import configobj
0|weewxd   | ImportError: No module named configobj
0|weewxd   | Traceback (most recent call last):
0|weewxd   |   File "/home/weewx/bin/weewxd.py", line 20, in 
0|weewxd   | import configobj
0|weewxd   | ImportError: No module named configobj

I assume that WeeWx is starting up but the Python interpreter can't find 
the file for the the import, so perhaps something needs to be tweaked in 
PATH?  I don't want to change anything in that area with advice.

Starting/stopping WeeWX with '/etc/init.d/weewx' works perfectly.

Regards and thanks in advance,

Garry


-- 
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/830dc248-93ad-489e-b4d8-d2169332a318n%40googlegroups.com.

[weewx-user] Re: WXFeeds (Was BelchertownWxFeeds)

[garrya...@gmail.com]

I've removed all dependencies on the Belchertown Skin so now called this 
simply WXFeeds.

I've collapsed the WXFeeds Servers (Auth and Proxy) into a single server.

All sensitive information, for the extension and the server, can be stored 
in .env files.

Code is fairly stable - currently running 3 day test before deploying to 
production weather station.

Working on Australian BOM feeds (FTP and RSS).

Will upload to Github some day.  In the meantime, contact me for a copy.

Regards,

Garry
On Wednesday, December 30, 2020 at 8:17:17 PM UTC-8 garrya...@gmail.com 
wrote:

> Good Day All!
>
> WeeWx users using the Belchertown Skin may be interested in 
> BelchertownWxFeeds, an extension that retrieves weather and other 
> information from a variety of RSS/Atom endpoints, available on GitHub (with 
> apologies for amateurish loading on GitHub!).
>
> WxFeeds has two components:
>
>- 
>
>BelchertownWxFeeds.py and
>- 
>
>the WxFeeds proxy servers.
>
> Note: BelchertownWxFeeds only works with the weewx Belchertown skin.
>
> This program pulls weather (wx) information and other information from 
> multiple 
> sources (feeds).   
> <https://github.com/GarryALockyer/BelchertownWxFeeds#it-currently-supports>It 
> currently supports:
>
> - ATOM feeds from Environment Canada
>
>- weather conditions, forecasts, alerts, marine forecasts and public 
> alerts.
>
> - METARs and TAFS from NOAA NWS Aviation Weather Center.
>
> - Forecasts, including hourly forecasts, from NOAA NWS.
>
> - Alerts from NOAA NWS Storm Prediction Center (land and sea).
>
> - Hurricane information from NOAA NWS National Hurricane Center.
>
> - Road conditions from Drive BC.
>
> - Road conditions and other data from 511 Alberta.
>
>
> <https://github.com/GarryALockyer/BelchertownWxFeeds#wxfeeds-also-has-a-proxy-server-two-actually-to-authorize>WxFeeds
>  
> also has a proxy server (two actually!), one to Authorize access to the 
> proxy server and the other to proxy requests to services such as Google 
> Maps so that API keys are not in publically accessible web pages.  It is 
> not required to use the WXFeeds proxy servers.
>
> The extension, without the servers, can be installed using wee_extension, 
> assuming a setup.py installation of WeeWx.
>
> You should be able to see this extension in use at:
>
> Lockyer.ca/weather/OsoyoosLakeNorth East
>
> I currently use this station for development and testing so it might be 
> down periodically.
>
> Enjoy!
>
> Garry Lockyer
>
>
>
>

-- 
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/1a34bd36-d2b9-4c10-8497-60b5a759e5c0n%40googlegroups.com.

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

[garrya...@gmail.com]

The Cheetah folks have asked for a pure Cheetah method to reproduce the 
problem, which I do not have.

Perhaps someone else can assist them.

The issue report is 
at: https://github.com/CheetahTemplate3/cheetah3/issues/34

Regards,

Garry

On Wednesday, January 27, 2021 at 11:39:39 PM UTC-8 garrya...@gmail.com 
wrote:

>
> I just entered an issue against Cheetah3.
>
> On Saturday, January 23, 2021 at 7:47:59 AM UTC-8 wes...@gmail.com wrote:
>
>> has anyone filed an issue on the github project for cheetah?
>>
>>

-- 
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/07bac1e0-51ba-4f98-b02f-15a76532b121n%40googlegroups.com.

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

[garrya...@gmail.com]

I just entered an issue against Cheetah3.

On Saturday, January 23, 2021 at 7:47:59 AM UTC-8 wes...@gmail.com wrote:

> has anyone filed an issue on the github project for cheetah?
>
>

-- 
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/1394f15b-2eba-44f1-bfac-a6064f9b3dc3n%40googlegroups.com.

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

[garrya...@gmail.com]

It looks like the workaround Rich suggested works.

A couple of notes:

1. the generated filename must be in quotes (#include raw "generated file 
name")
- the Cheetah generator will throw an error if not.

2. There must not be 'raw' arguments in index.html.tmpl
- I left them in after previous debugging
- if they are in, the Cheetah generator will not parse the generated 
file and the Cheetah directive will 
  be display in the output HTML.

I will be putting a control in my extension to enable/disable this 
workaround.

Again, thanks to Rich and others for helping with this.

Regards,

Garry

On Wednesday, January 20, 2021 at 10:16:26 AM UTC-8 garrya...@gmail.com 
wrote:

> Thanks to Vince, Rich and all who took the time to investigate this 
> problem.
>
> Happy that it’s not WeeWX or Belchertown, two fine programs!
>
> I hope to release my WXFeeds service extension within the next few days.
>
> Regards,
>
> Garry
>
> On Wednesday, January 20, 2021 at 8:19:32 AM UTC-8 vince wrote:
>
>> Well FWIW, it's not Belchertown.I took my minimalist demo-skin and 
>> aded the one include line in it and boy does it grow.
>>
>> Two tests with a restart that's obvious.
>>
>> On Wednesday, January 20, 2021 at 7:07:23 AM UTC-8 garrya...@gmail.com 
>> wrote:
>>
>>> I haven’t made any changes yet but in thinking about your workaround, it 
>>> will be interesting to see if Cheetah actuality processes the included 
>>> include file or if it skips it because the outer include file’s attributes 
>>> are static.
>>>
>>> If Cheetah doesn’t process the inner include file, it still should be a 
>>> way to inject the ‘raw’ argument without having to edit ‘index.html.tmpl’. 
>>>  That is, my code would generate both the outer and inner include files 
>>> each cycle, with the outer include file containing the ‘raw’ argument as 
>>> you suggest.
>>>
>>> Regards,
>>>
>>> Garry Lockyer
>>> C: +1.250.689.0686 <(250)%20689-0686>
>>> E: ga...@lockyer.ca
>>>
>>>
>>> On Jan 20, 2021, at 06:24, bell...@gmail.com  wrote:
>>>
>>> Note, it is growing - just much slower.
>>>
>>>
>>>
>>> On Wednesday, 20 January 2021 at 09:13:35 UTC-5 bell...@gmail.com wrote:
>>>
>>>> Garry,
>>>> I might have a workaround for you. Wrap your html file in a template. 
>>>> something like this.
>>>> index.html.tmp (this is in the belchertown skin)
>>>> #include index_hook_after_charts.inc
>>>>
>>>> index_hook_after_charts.inc (this is the 'wrapper', naturally if you 
>>>> 'owned' index.html.tmpl you would not need it)
>>>> #include raw generated.html
>>>>
>>>> generated.html (the file you generate - name as you want)
>>>> your html
>>>>
>>>> I ran this on my loop 10,000 times and saw no appreciable memory 
>>>> increase and performed better too.
>>>> rich
>>>>
>>>> On Tuesday, 19 January 2021 at 22:45:42 UTC-5 garrya...@gmail.com 
>>>> wrote:
>>>>
>>>>> Many thanks to all for poking at this!
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Garry Lockyer
>>>>> C: +1.250.689.0686 <(250)%20689-0686>
>>>>> E: ga...@lockyer.ca
>>>>>
>>>>>
>>>>> On Jan 19, 2021, at 19:38, vince  wrote:
>>>>>
>>>>> Just a followup - I took belchertown out of the picture and used my 
>>>>> minimal demo-skin and added 'one line' that #include(d) a file generated 
>>>>> by 
>>>>> Garry's service, and it 'is' leaking memory albeit less quickly than the 
>>>>> belchertown example.
>>>>>
>>>>>
>>>>> I'll let it run overnight and we'll see what it looks like after 12 
>>>>> more hours running.   The VM is set to only 1GB RAM but I'm hoping if it 
>>>>> runs out it'll just go into swap and stay up.OS is debian 10 under 
>>>>> Vagrant/VirtualBox with 4.3.0 installed using python3 and setup.py
>>>>>
>>>>> Some mem.sdb output (date/time, units, interval, mem_size, mem_rss, 
>>>>> mem_share)...
>>>>>
>>>>> 1611109216 16 5 141.0625 71.734375 12.2734375
>>>>> 1611109516 16 5 142.5625 75.65234375 

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

[garrya...@gmail.com]

Thanks to Vince, Rich and all who took the time to investigate this problem.

Happy that it’s not WeeWX or Belchertown, two fine programs!

I hope to release my WXFeeds service extension within the next few days.

Regards,

Garry

On Wednesday, January 20, 2021 at 8:19:32 AM UTC-8 vince wrote:

> Well FWIW, it's not Belchertown.I took my minimalist demo-skin and 
> aded the one include line in it and boy does it grow.
>
> Two tests with a restart that's obvious.
>
> On Wednesday, January 20, 2021 at 7:07:23 AM UTC-8 garrya...@gmail.com 
> wrote:
>
>> I haven’t made any changes yet but in thinking about your workaround, it 
>> will be interesting to see if Cheetah actuality processes the included 
>> include file or if it skips it because the outer include file’s attributes 
>> are static.
>>
>> If Cheetah doesn’t process the inner include file, it still should be a 
>> way to inject the ‘raw’ argument without having to edit ‘index.html.tmpl’. 
>>  That is, my code would generate both the outer and inner include files 
>> each cycle, with the outer include file containing the ‘raw’ argument as 
>> you suggest.
>>
>> Regards,
>>
>> Garry Lockyer
>> C: +1.250.689.0686 <(250)%20689-0686>
>> E: ga...@lockyer.ca
>>
>>
>> On Jan 20, 2021, at 06:24, bell...@gmail.com  wrote:
>>
>> Note, it is growing - just much slower.
>>
>>
>>
>> On Wednesday, 20 January 2021 at 09:13:35 UTC-5 bell...@gmail.com wrote:
>>
>>> Garry,
>>> I might have a workaround for you. Wrap your html file in a template. 
>>> something like this.
>>> index.html.tmp (this is in the belchertown skin)
>>> #include index_hook_after_charts.inc
>>>
>>> index_hook_after_charts.inc (this is the 'wrapper', naturally if you 
>>> 'owned' index.html.tmpl you would not need it)
>>> #include raw generated.html
>>>
>>> generated.html (the file you generate - name as you want)
>>> your html
>>>
>>> I ran this on my loop 10,000 times and saw no appreciable memory 
>>> increase and performed better too.
>>> rich
>>>
>>> On Tuesday, 19 January 2021 at 22:45:42 UTC-5 garrya...@gmail.com wrote:
>>>
>>>> Many thanks to all for poking at this!
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Garry Lockyer
>>>> C: +1.250.689.0686 <(250)%20689-0686>
>>>> E: ga...@lockyer.ca
>>>>
>>>>
>>>> On Jan 19, 2021, at 19:38, vince  wrote:
>>>>
>>>> Just a followup - I took belchertown out of the picture and used my 
>>>> minimal demo-skin and added 'one line' that #include(d) a file generated 
>>>> by 
>>>> Garry's service, and it 'is' leaking memory albeit less quickly than the 
>>>> belchertown example.
>>>>
>>>>
>>>> I'll let it run overnight and we'll see what it looks like after 12 
>>>> more hours running.   The VM is set to only 1GB RAM but I'm hoping if it 
>>>> runs out it'll just go into swap and stay up.OS is debian 10 under 
>>>> Vagrant/VirtualBox with 4.3.0 installed using python3 and setup.py
>>>>
>>>> Some mem.sdb output (date/time, units, interval, mem_size, mem_rss, 
>>>> mem_share)...
>>>>
>>>> 1611109216 16 5 141.0625 71.734375 12.2734375
>>>> 1611109516 16 5 142.5625 75.65234375 12.3359375
>>>> 1611109816 16 5 144.0625 79.65625 12.3359375
>>>> 160116 16 5 145.5625 84.5234375 12.3359375
>>>> 160416 16 5 147.24609375 88.0859375 12.3359375
>>>> 160716 16 5 148.49609375 91.43359375 12.3359375
>>>> 161016 16 5 149.99609375 95.421875 12.3359375
>>>> 161316 16 5 151.49609375 100.3359375 12.3359375
>>>> 161616 16 5 152.99609375 103.8359375 12.3359375
>>>> 161916 16 5 154.49609375 107.51171875 12.3359375
>>>> 162216 16 5 155.99609375 111.5 12.3359375
>>>> 162516 16 5 157.24609375 116.0859375 12.3359375
>>>> 162816 16 5 158.74609375 119.5859375 12.3359375
>>>> 163116 16 5 160.24609375 123.24609375 12.3359375
>>>> 163416 16 5 161.74609375 127.234375 12.3359375
>>>> 163716 16 5 163.24609375 132.11328125 12.3359375
>>>>
>>>>
>>>>
>>>> On Tuesday, January 19, 2021 at 5:21:31 PM UTC-8 bell...@gmail.com 
>>>> wrote

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

[garrya...@gmail.com]

I wasn't happy leaving this is as is so I did some more testing.

I looked in /home/weewx/bin/user/belchertown.py for any mention of the 4 
include files it uses to add content - nothing there.

So, I looked in /home/weewx/skins/Belchertown/index.html.templ and found 4 
lines that reference the include files - they are of the form:

#if os.path.exists("index_hook_after_station_info.inc")


#include "index_hook_after_station_info.inc"


#end if
That caused me to look up the Cheetah '#include'  directive:

"7.6 #include

Syntax:
#include [raw] FILENAME_EXPR #include [raw] source=STRING_EXPR 

The #include directive is used to include text from outside the template 
definition. The text can come from an external file or from 
a $placeholder variable. When working with external files, Cheetah will 
monitor for changes to the included file and update as necessary.

This example demonstrates its use with external files:
#include "includeFileName.txt" 
The content of "includeFileName.txt" will be parsed for Cheetah syntax.

And this example demonstrates use with $placeholder variables:
#include source=$myParseText 
The value of $myParseText will be parsed for Cheetah syntax. This is not 
the same as simply placing the $placeholder tag ``$myParseText'' in the 
template definition. In the latter case, the value of $myParseText would 
not be parsed.

By default, included text will be parsed for Cheetah tags. The argument 
``raw'' can be used to suppress the parsing.

#include raw "includeFileName.txt" #include raw source=$myParseText 

Cheetah wraps each chunk of #include text inside a nested Template object. 
Each nested template has a copy of the main template's searchList. 
However, #set variables are visible across includes only if the defined 
using the #set global keyword.

All directives must be balanced in the include file. That is, if you start 
a #for or #if block inside the include, you must end it in the same 
include. (This is unlike PHP, which allows unbalanced constructs in include 
files.)"

I decided to insert the 'raw' argument into the 4 '#include' directives to 
see if anything changed.

After about 1 hour. memory usage did not grow above about 65 MB!

I just removed the 'raw' argument and restarted WeeWX.  After just a few 
minutes, memory usage is almost 300 MB and growing!

As before, the station website is at: 
https://lockyer.ca/weather/OsoyoosLakeNorthEast and the mem graphs are at 
https://lockyer.ca/weather/OsoyoosLakeNorthEast/mem.

So, I think I have conclusively shown  that the problem is within Cheetah 
and is related to it parsing an include file.

I'm going to re-insert the 'raw' arguments and carry on.

Should I report this issue to the Cheetah folks or is there someone closer 
to the Cheetah developers that can better do that?

Regards,

Garry


On Monday, January 18, 2021 at 9:27:42 AM UTC-8 garrya...@gmail.com wrote:

> Thanks!
>
> I think I've done all that I can to isolate the problem.
>
> I'm going to get back to finishing up development and add a cron entry to 
> restart WeeWX every 24 hours in the wee hours of the morning.
>
> I will be re-deploying a Davis Pro 2 system very soon (within the week) 
> and then deploying another Davis Pro 2 system shortly after that.  And 
> sometime after than, a couple of WeatherFlow Tempest systems.
>
> I'll post everything on GitHub soonest.
>
> Regards,
>
> Garry
> PS: Re: Ubuntu Desktop on RPi, I've been using it for development for the 
> last few days and it has not crashed or hung, so I think I'm going to stay 
> with it.  Only issue is wireless mouse lag (Raspberry Pi OS had 
> same/similar problem) and I've ordered a Logitech MK540 wireless 
> keyboard/mouse combo to see if newer hardwaere works better (than my dated 
> Microsoft mouse).
> On Sunday, January 17, 2021 at 5:40:15 PM UTC-8 vince wrote:
>
>> Restarted with your add-on plus belchertown both enabled - the RSS is 
>> nominally growing at 4 MB per 5-minute archive period.
>>
>> 1610928917 139.53125 63.97265625 15.453125
>> 1610929217 143.02734375 70.41796875 15.4921875
>> 1610929517 144.46484375 74.43359375 15.4921875
>> 1610929817 145.96484375 78.48046875 15.55078125
>> 1610930117 147.46484375 82.65625 15.58203125
>> 1610930417 149.09375 86.69921875 15.58203125
>> 1610930717 150.34375 90.55078125 15.58203125
>> 1610931017 151.84375 94.203125 15.24609375
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0e0bcf56-0fbf-441a-b143-397220f4978fn%40googlegroups.com.

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

[garrya...@gmail.com]

Thanks!

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

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

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

I'll post everything on GitHub soonest.

Regards,

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/85c007ce-0bf2-48a8-95f8-ea191f7d83een%40googlegroups.com.

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

[garrya...@gmail.com]

\
   + "%s\n" % roadCondition.get( 
"RoadwayName" )   \
   + "\n"  
\
   + "\n"  
 \
   + "Location 
Description: \n"\
   + "%s\n" % roadCondition.get( 
"LocationDescription" )   \
   + "\n"  
\
   + "\n"  
 \
   + "Primary 
Condition: \n"   \
   + "%s\n" % roadCondition.get( 
"Primary Condition" ) \
   + "\n"  
\
   + "\n"  
 \
   + "Id: \n"  
\
   + "%s\n" % roadCondition.get( "Id" 
)\
   + "\n"  
\
   + "\n"  
 \
   + "Area Name: \n"  
 \
   + "%s\n" % roadCondition.get( 
"AreaName" )  \
   + "\n"  
\
   + "\n"  
 \
   + "Last Updated: \n"
\
   + "%s\n" % roadCondition.get( 
"LastUpdated" )   \
   + "\n"  
\
   +   "\n"
 \
   + "\n"  
 \
   + "\n"

file.write( HTML )
file.flush()
os.fsync( file.fileno() )

del roadConditions
 
file.close()
del file

if directFileCreation == False:
# The include file should have been deleted above but 
# so that we don't get any exceptions because the destination 
# already exists, we'll delete it here, before a copy or rename.

if os.path.exists( includeFileName ) == True:
os.remove( includeFileName )

if copyFile == True:
shutil.copy2( tempFileName, includeFileName )
else:
os.replace( tempFileName, includeFileName )

response.close()
del response

session.close()
del session

self.log.info( "WXFeedsMemoryTest:" )
self.log.info( "Garbage collection after writing file:" )
    self.log.info( "Memory use before gc.collect():" )
x, y, z = gc.get_count()
self.log.info( "gc.get_count(): %d, %d, %d" % ( x, y, z ) )
self.log.info( "sys.getallocatedblocks(): %d" % 
sys.getallocatedblocks() )
#sys._clear_type_cache()
gc.collect()
self.log.info( "Memory use after gc.collect():" )
x, y, z = gc.get_count()
self.log.info( "gc.get_count(): %d, %d, %d" % ( x, y, z ) )
self.log.info( "sys.getallocatedblocks(): %d" % 
sys.getallocatedblocks() )
self.log.info( "" )

return
#


On Sunday, January 17, 2021 at 9:28:24 AM UTC-8 vince wrote:

> On Saturday, January 9, 2021 at 8:02:51 PM UTC-8 garrya...@gmail.com 
> wrote:
>
>> 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 continue to think you need to concentrate on what your code is doing and 
> your os configuration.
>
>- If you disable Belchertown and 'enable' your custom code that 
>generates the include file, does memory grow ?
>- You also haven't told us what hardware you're on.  Is it a pi ? 
> What os ?   What version ?
>- Your log says you're running python3.  Have you tried the same thing 
>on a python2 system ?
>- Can you duplicate the problem using just the Simulator driver and 
>your addition so we can try to replicate it ?
>
>
>  
>

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

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

[garrya...@gmail.com]

   
   - If you disable Belchertown and 'enable' your custom code that 
   generates the include file, does memory grow ?
  - Yes.  I just started at test run with WXFeedsMemoryTest.py 
  (attached here) and Belchertown enabled.  The station website is at: 
  https://lockyer.ca/weather/OsoyoosLakeNorthEast and the mem graphs 
  are  at: https://lockyer.ca/weather/OsoyoosLakeNorthEast/mem.
   - You also haven't told us what hardware you're on.  Is it a pi ?  What 
   os ?   What version ?
  - From an earlier post:
 - RPi 4 - 8 GB
 - Ubuntu Raspberry Pi OS 20.10
 - Python3 - 3.8.6
 - WeeWX 4.3
 - Belchertown 1.2
 - Problem was first noticed on RPi Zero W with Raspberry Pi OS 
  Lite.
  - Problem was reproduced on RPi 4 - 4 & 8 GB with Raspberry Pi OS 
  Desktop.
  - My extension was reduced to minimum code needed to reproduce the 
  problem - that code is attached.
   - Your log says you're running python3.  Have you tried the same thing 
   on a python2 system ?
  - No.  I have no interest in python2. :^))
   - Can you duplicate the problem using just the Simulator driver and your 
   addition so we can try to replicate it ?
  - The run I just started (about 11:30 AM PST) is using the Simulator 
  (rather than WeatherFlow).
   
On Sunday, January 17, 2021 at 9:28:24 AM UTC-8 vince wrote:

> On Saturday, January 9, 2021 at 8:02:51 PM UTC-8 garrya...@gmail.com 
> wrote:
>
>> 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 continue to think you need to concentrate on what your code is doing and 
> your os configuration.
>
>- If you disable Belchertown and 'enable' your custom code that 
>generates the include file, does memory grow ?
>- You also haven't told us what hardware you're on.  Is it a pi ? 
> What os ?   What version ?
>- Your log says you're running python3.  Have you tried the same thing 
>on a python2 system ?
>- Can you duplicate the problem using just the Simulator driver and 
>your addition so we can try to replicate it ?
>
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/910f9283-dd79-4122-b92e-14a11aa58a27n%40googlegroups.com.

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

[garrya...@gmail.com]

I haven't managed to package the "latest & greatest" up for others but I 
did do some testing.

It occurred to me that since my extension is now a service, not dependent 
on a skin, I could turn off a skin to see if that changed the problem.  So 
I disabled the Belchertown skin and restarted WeeWX.

And it looks like the problem has gone away, so at this time, it looks like 
the cause of the leak is associated with Belchertown, but I don't know 
enough (anything really!) to say whether it's about WeedWX calling 
Belchertown or Belchertown itself.

The station website at: https://lockyer.ca/weather/OsoyoosLakeNorthEast is 
no longer being updated ('cause Belchertown is disabled) but the mem graphs 
at: https://lockyer.ca/weather/OsoyoosLakeNorthEast/mem are.  The 
discontinuity of memory growth around 2:30 PM Saturday was caused by an 
poorly handled error for one of the feeds in my code - that's now fixed.  
The data before about midnight are for testing before I disabled 
Belchertown.  I'll probably re-enable Belchertown after a few hours.

In the morning, I will update my MemoryTest to provide the smallest / 
simplest code to demonstrate the problem and make it available for others 
to test with.

Thanks again for all your help,

Garry

On Saturday, January 16, 2021 at 1:29:35 PM UTC-8 garrya...@gmail.com wrote:

> Thanks, will do but later today.
>
>
> Regards,
>
> Garry Lockyer
> C: +1.250.689.0686 <(250)%20689-0686>
> E: ga...@lockyer.ca
>
>
> On Jan 16, 2021, at 11:09, bell...@gmail.com  wrote:
>
> 
>
>
> Garry,
> If you want me to run something, just make it available and give me some 
> instructions.
> rich
> On Saturday, 16 January 2021 at 12:25:33 UTC-5 garrya...@gmail.com wrote:
>
>> I've added the mem extension.  My test station, with a large number of 
>> feeds selected, is at: https://lockyer.ca/weather/OsoyoosLakeNorthEast
>>
>> mem graphs are at: https://lockyer.ca/weather/OsoyoosLakeNorthEast/mem
>>
>> Regards,
>>
>> Garry
>>
>> On Saturday, January 16, 2021 at 8:42:09 AM UTC-8 garrya...@gmail.com 
>> wrote:
>>
>>> Brief Update: January 16, 2021:
>>>
>>> I've pretty much finished moving my extension to a service.
>>>
>>> I started WeeWX at about midnight and at about 8:20 AM, memory usage has 
>>> grown to over 941MB!  Allocated blocks was at 4,245,722.
>>>
>>> So growing memory usage problem exists.
>>>
>>> Bill indicated above he ran my test code on Ubuntu so I set up a Ubuntu 
>>> Raspberry Pi Desktop system:
>>>
>>> RPi 4 - 6 GB
>>> Ubuntu Raspberry Pi OS 20.10
>>> Python3 - 3.8.6
>>> WeeWX 4.3
>>> Belchertown 1.2
>>>
>>> Later today I intend to add the mem extension.  Will report back 
>>> soonest!  I will also run things on Raspberrry Pi OS (but I have to build a 
>>> new one!).
>>>
>>> Regards,
>>>
>>> Garry
>>> PS: I *think* I'm going to continue all development on Ubuntu as it 
>>> seems more current - it has a later linux kernel and more current Python - 
>>> but I'm not sure it's otherwise better than Raspberry Pi OS.  Both OS's 
>>> have wireless mouse lag problems, fixed somewhat by changing 'mousepoll' 
>>> setting.  Installation of Ubuntu was easy and I managed to get it to boot 
>>> from a USB SSD.  In the first 8 hours or so, Ubuntu froze a couple of 
>>> times, so now I keep an ssh session open so that I can reboot.
>>>
>>> On Saturday, January 9, 2021 at 8:02:51 PM UTC-8 garrya...@gmail.com 
>>> wrote:
>>>
>>>> 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 <(250)%20689-0

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

[garrya...@gmail.com]

I've added the mem extension.  My test station, with a large number of 
feeds selected, is at: https://lockyer.ca/weather/OsoyoosLakeNorthEast

mem graphs are at: https://lockyer.ca/weather/OsoyoosLakeNorthEast/mem

Regards,

Garry

On Saturday, January 16, 2021 at 8:42:09 AM UTC-8 garrya...@gmail.com wrote:

> Brief Update: January 16, 2021:
>
> I've pretty much finished moving my extension to a service.
>
> I started WeeWX at about midnight and at about 8:20 AM, memory usage has 
> grown to over 941MB!  Allocated blocks was at 4,245,722.
>
> So growing memory usage problem exists.
>
> Bill indicated above he ran my test code on Ubuntu so I set up a Ubuntu 
> Raspberry Pi Desktop system:
>
> RPi 4 - 6 GB
> Ubuntu Raspberry Pi OS 20.10
> Python3 - 3.8.6
> WeeWX 4.3
> Belchertown 1.2
>
> Later today I intend to add the mem extension.  Will report back soonest!  
> I will also run things on Raspberrry Pi OS (but I have to build a new one!).
>
> Regards,
>
> Garry
> PS: I *think* I'm going to continue all development on Ubuntu as it seems 
> more current - it has a later linux kernel and more current Python - but 
> I'm not sure it's otherwise better than Raspberry Pi OS.  Both OS's have 
> wireless mouse lag problems, fixed somewhat by changing 'mousepoll' 
> setting.  Installation of Ubuntu was easy and I managed to get it to boot 
> from a USB SSD.  In the first 8 hours or so, Ubuntu froze a couple of 
> times, so now I keep an ssh session open so that I can reboot.
>
> On Saturday, January 9, 2021 at 8:02:51 PM UTC-8 garrya...@gmail.com 
> wrote:
>
>> 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 <(250)%20689-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 <(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.7

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

[garrya...@gmail.com]

Brief Update: January 16, 2021:

I've pretty much finished moving my extension to a service.

I started WeeWX at about midnight and at about 8:20 AM, memory usage has 
grown to over 941MB!  Allocated blocks was at 4,245,722.

So growing memory usage problem exists.

Bill indicated above he ran my test code on Ubuntu so I set up a Ubuntu 
Raspberry Pi Desktop system:

RPi 4 - 6 GB
Ubuntu Raspberry Pi OS 20.10
Python3 - 3.8.6
WeeWX 4.3
Belchertown 1.2

Later today I intend to add the mem extension.  Will report back soonest!  
I will also run things on Raspberrry Pi OS (but I have to build a new one!).

Regards,

Garry
PS: I *think* I'm going to continue all development on Ubuntu as it seems 
more current - it has a later linux kernel and more current Python - but 
I'm not sure it's otherwise better than Raspberry Pi OS.  Both OS's have 
wireless mouse lag problems, fixed somewhat by changing 'mousepoll' 
setting.  Installation of Ubuntu was easy and I managed to get it to boot 
from a USB SSD.  In the first 8 hours or so, Ubuntu froze a couple of 
times, so now I keep an ssh session open so that I can reboot.

On Saturday, January 9, 2021 at 8:02:51 PM UTC-8 garrya...@gmail.com wrote:

> 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 <(250)%20689-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 <(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

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

[garrya...@gmail.com]

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. 
>  Add in changes one-by-one.  If it goes sideways, revert to the last known 
> good and reverify that it stays good.
>  
>
> -- 
>
> 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/57a5bfc7-d0b4-4419-b178-6342564642edn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/57a5bfc7-d0b4-4419-b178-6342564642edn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>

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

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

[garrya...@gmail.com]

I just restarted weewx and memory usage dropped to about 15%!

I failed to note it in original post but CPU utilization was probably at 
about 50% consistently before weewx restart and dropped to <30% after 
restart.

Regards,

Garry

On Thursday, December 31, 2020 at 8:10:09 AM UTC-8 garrya...@gmail.com 
wrote:

>
>
> Weewx was started at about 10:30 PM on 2020-12-30.  Started logging 
> MemoryError at 06:53:39 AM 2020-12-31.  Here's one instance:
>
> 2020-12-31T07:30:19-08:00 LockyerHomeServer /weewxd: weatherflowudp: 
> MainThread: Listening for UDP broadcasts to IP address  on port 
> 50222, with timeout 90 and share_socket False...
> 2020-12-31T07:31:19-08:00 LockyerHomeServer /weewxd: weatherflowudp: 
> MainThread: Listening for UDP broadcasts to IP address  on port 
> 50222, with timeout 90 and share_socket False...
> 2020-12-31T07:32:29-08:00 LockyerHomeServer /weewxd: weatherflowudp: 
> MainThread: Listening for UDP broadcasts to IP address  on port 
> 50222, with timeout 90 and share_socket False...
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator: Generate failed with exception ' 'MemoryError'>'
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator:  Ignoring template 
> /home/weewx/skins/Belchertown/index.html.tmpl
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator:  Reason: 
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator:   Traceback (most recent call last):
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator: File 
> "/home/weewx/bin/weewx/cheetahgenerator.py", line 323, in generate
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator:   unicode_string = 
> compiled_template.respond()
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator: File 
> "_home_weewx_skins_Belchertown_index_html_tmpl.py", line 1273, in respond
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator: File 
> "/usr/lib/python3/dist-packages/Cheetah/Template.py", line 1685, in 
> _handleCheetahInclude
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator:   file=file)
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator: File 
> "/usr/lib/python3/dist-packages/Cheetah/Template.py", line 775, in compile
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator:   compiler.compile()
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator: File 
> "/usr/lib/python3/dist-packages/Cheetah/Compiler.py", line 1800, in compile
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator:   
> self._swallowClassCompiler(self._popActiveClassCompiler())
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator: File 
> "/usr/lib/python3/dist-packages/Cheetah/Compiler.py", line 1825, in 
> _swallowClassCompiler
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator:   classCompiler.cleanupState()
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator: File 
> "/usr/lib/python3/dist-packages/Cheetah/Compiler.py", line 1305, in 
> cleanupState
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator:   self._swallowMethodCompiler(methCompiler)
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator: File 
> "/usr/lib/python3/dist-packages/Cheetah/Compiler.py", line 1404, in 
> _swallowMethodCompiler
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator:   methodCompiler.cleanupState()
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator: File 
> "/usr/lib/python3/dist-packages/Cheetah/Compiler.py", line 1089, in 
> cleanupState
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator:   self.commitStrConst()
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator: File 
> "/usr/lib/python3/dist-packages/Cheetah/Compiler.py", line 494, in 
> commitStrConst
> 2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
> weewx.cheetahgenerator:    

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

[garrya...@gmail.com]

Weewx was started at about 10:30 PM on 2020-12-30.  Started logging 
MemoryError at 06:53:39 AM 2020-12-31.  Here's one instance:

2020-12-31T07:30:19-08:00 LockyerHomeServer /weewxd: weatherflowudp: 
MainThread: Listening for UDP broadcasts to IP address  on port 
50222, with timeout 90 and share_socket False...
2020-12-31T07:31:19-08:00 LockyerHomeServer /weewxd: weatherflowudp: 
MainThread: Listening for UDP broadcasts to IP address  on port 
50222, with timeout 90 and share_socket False...
2020-12-31T07:32:29-08:00 LockyerHomeServer /weewxd: weatherflowudp: 
MainThread: Listening for UDP broadcasts to IP address  on port 
50222, with timeout 90 and share_socket False...
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator: Generate failed with exception ''
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:  Ignoring template 
/home/weewx/skins/Belchertown/index.html.tmpl
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:  Reason: 
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:   Traceback (most recent call last):
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator: File 
"/home/weewx/bin/weewx/cheetahgenerator.py", line 323, in generate
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:   unicode_string = 
compiled_template.respond()
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator: File 
"_home_weewx_skins_Belchertown_index_html_tmpl.py", line 1273, in respond
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator: File 
"/usr/lib/python3/dist-packages/Cheetah/Template.py", line 1685, in 
_handleCheetahInclude
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:   file=file)
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator: File 
"/usr/lib/python3/dist-packages/Cheetah/Template.py", line 775, in compile
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:   compiler.compile()
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator: File 
"/usr/lib/python3/dist-packages/Cheetah/Compiler.py", line 1800, in compile
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:   
self._swallowClassCompiler(self._popActiveClassCompiler())
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator: File 
"/usr/lib/python3/dist-packages/Cheetah/Compiler.py", line 1825, in 
_swallowClassCompiler
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:   classCompiler.cleanupState()
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator: File 
"/usr/lib/python3/dist-packages/Cheetah/Compiler.py", line 1305, in 
cleanupState
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:   self._swallowMethodCompiler(methCompiler)
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator: File 
"/usr/lib/python3/dist-packages/Cheetah/Compiler.py", line 1404, in 
_swallowMethodCompiler
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:   methodCompiler.cleanupState()
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator: File 
"/usr/lib/python3/dist-packages/Cheetah/Compiler.py", line 1089, in 
cleanupState
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:   self.commitStrConst()
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator: File 
"/usr/lib/python3/dist-packages/Cheetah/Compiler.py", line 494, in 
commitStrConst
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:   body = escapedNewlineRE.sub('\\1\n', 
reprstr[i+1:-1])
2020-12-31T07:32:42-08:00 LockyerHomeServer weewx[2983] ERROR 
weewx.cheetahgenerator:   MemoryError
2020-12-31T07:33:19-08:00 LockyerHomeServer /weewxd: weatherflowudp: 
MainThread: Listening for UDP broadcasts to IP address  on port 
50222, with timeout 90 and share_socket False...
2020-12-31T07:34:19-08:00 LockyerHomeServer /weewxd: weatherflowudp: 
MainThread: Listening for UDP broadcasts to IP address  on port 
50222, with timeout 90 and share_socket False...

Here's the output of free at about 07:35 AM:

pi@LockyerHomeServer:/home/weewx $ free
  totalusedfree  shared  buff/cache  
 available
Mem:8012324 4059728 2206528  684728 1746068
 3011060
Swap:102396   0  102396

As you can see, this system ha

[weewx-user] BelchertownWxFeeds

[garrya...@gmail.com]

Good Day All!

WeeWx users using the Belchertown Skin may be interested in 
BelchertownWxFeeds, an extension that retrieves weather and other 
information from a variety of RSS/Atom endpoints, available on GitHub (with 
apologies for amateurish loading on GitHub!).

WxFeeds has two components:

   - 
   
   BelchertownWxFeeds.py and
   - 
   
   the WxFeeds proxy servers.
   
Note: BelchertownWxFeeds only works with the weewx Belchertown skin.

This program pulls weather (wx) information and other information from multiple 
sources (feeds).   
It 
currently supports:

- ATOM feeds from Environment Canada

   - weather conditions, forecasts, alerts, marine forecasts and public 
alerts.

- METARs and TAFS from NOAA NWS Aviation Weather Center.

- Forecasts, including hourly forecasts, from NOAA NWS.

- Alerts from NOAA NWS Storm Prediction Center (land and sea).

- Hurricane information from NOAA NWS National Hurricane Center.

- Road conditions from Drive BC.

- Road conditions and other data from 511 Alberta.

WxFeeds
 
also has a proxy server (two actually!), one to Authorize access to the 
proxy server and the other to proxy requests to services such as Google 
Maps so that API keys are not in publically accessible web pages.  It is 
not required to use the WXFeeds proxy servers.

The extension, without the servers, can be installed using wee_extension, 
assuming a setup.py installation of WeeWx.

You should be able to see this extension in use at:

Lockyer.ca/weather/OsoyoosLakeNorth East

I currently use this station for development and testing so it might be 
down periodically.

Enjoy!

Garry Lockyer



-- 
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/3e96fd07-0ec2-4096-9e17-468ba03910aen%40googlegroups.com.

[weewx-user] Syntax - install.py

[garrya...@gmail.com]

With the usual aplogies if this is documented somewhere and I didn't work 
hard enough to find it. . .

I'm working on getting my RSS/Atom feed extension (to the Belchertown skin) 
ready for release so want to fully utilize install.py.

Is there a description available for the syntax used in install.py?

Regards,

Garry

-- 
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/f76b1da4-72e9-4280-a831-bd47f4e773f0n%40googlegroups.com.