from:"Cameron D"

Thanks Matthew,
I just wasn't sure if I was missing something with my eccentric 
installation.
Cameron.

On Monday 12 February 2024 at 12:05:10 am UTC+10 matthew wall wrote:

> hi cameron,
>
> i'm working on this, hopefully to appear in the 5.0.3 release (or 5.1 if 
> tom and gary are faster on their work to other parts of weewx).
>
> redhat has one convention, debian has a different convention.  on top of 
> that, we are trying to (1) migrate any sysv installations on an obviously 
> systemd system, (2) continue to support sysv installations where no systemd 
> exists, and (3) respect any weewx-multi installations, whether they are 
> sysv or systemd.
>
> m
>
>

-- 
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/9d339f4d-ae23-425e-ab0f-ab08f1a0fc1dn%40googlegroups.com.

[weewx-user] Re: Noob Question

If you are referring to the vector direction, that is the default - note 
the North pointer at bottom left.
If you have a strongly dominant westerly wind then you probably want to 
leave it like that, otherwise there is a setting in the skin config file to 
"fix" it.


On Sunday 11 February 2024 at 11:00:27 pm UTC+10 Nick Name wrote:

> Following epic session finally have WeeWx up and running. Learned much & 
> happy with this software.
>
> Vanilla RaspberryPi -> Vantage Pro2 -> Clean install WeeWx, Zero 
> customisation.
>
> Have repeated above about three time too get here so have learned a bit 
> about the overall process.
>
> I have one tiny issue and I wonder if anyone has seen similar and could 
> offer pointer.
> Attached image is of wind graphs from current running setup.[image: 
> screenshot 2024-02-11 at 09.29.10.png]
> "Something" does not look right to me! This being a vanilla install I 
> thought I would ask before I get into ANY "investigation".
>
> Hope above makes sense.
> Thanks for any suggestions.
> Regards.
> Frank C.
>

-- 
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/4ec22fb8-69e9-489b-bb38-39c6d72f3798n%40googlegroups.com.

[weewx-user] Is there any way to tell dpkg/apt that you are running a weewx-multi via systemd?

The problems I am seeing are:

An upgrade does not automatically stop the running services - I try to 
manually stop them first, but occasionally I do not even notice a new weewx 
among the other packages.

I have standard weewx config as a simulator, so it does not matter if it 
runs, but I prefer it not to. However, if I mask the weewx service, then 
dpkg configure fails and tries to complete configuration every time it runs.
If I disable weewx.service, then dpkg always re-enables it and starts it.

I can see that if a sysV-init version is running, then the scripts could 
presumably handle it, but is there a way to configure the system so the 
install scripts know to do something different for a multi-system?

-- 
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/c4e189d9-9cc1-4151-ab50-36c97905fadbn%40googlegroups.com.

[weewx-user] Re: dpkg: error processing package weewx (--configure):

The "string to float" exception can happen if you lose the separator 
character (comma) between station latitude and longitude, or perhaps have 
some extra spurious character.  I don't know what happens for different 
languages.

When dpkg configure fails then it will again attempt to complete the 
configuration every time apt upgrade runs. That will be why it is running 
again even if you have already "installed" the latest version.

Instead of fully reinstalling, you should just try *dpkg --configure -a*
On Friday 9 February 2024 at 1:37:23 am UTC+10 Daniel Fourlas wrote:

> Journal begins at Thu 2022-09-22 06:17:24 EEST, ends at Thu 2024-02-08 
> 17:35:55 EET. --
> Oct 23 02:19:57 SunSDR-pi4 systemd[1]: Starting LSB: weewx weather 
> system...
> Oct 23 02:19:57 SunSDR-pi4 python3[11888]: weewx[11888] INFO __main__: 
> Initializing weewx version 4.10.2
> Oct 23 02:19:57 SunSDR-pi4 python3[11888]: weewx[11888] INFO __main__: 
> Using Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
>[GCC 10.2.1 20210110]
> Oct 23 02:19:57 SunSDR-pi4 python3[11888]: weewx[11888] INFO __main__: 
> Located at /bin/python3
> Oct 23 02:19:57 SunSDR-pi4 python3[11888]: weewx[11888] INFO __main__: 
> Platform Linux-6.1.21-v8+-aarch64-with-glibc2.31
> Oct 23 02:19:57 SunSDR-pi4 python3[11888]: weewx[11888] INFO __main__: 
> Locale is 'en_GB.UTF-8'
> Oct 23 02:19:57 SunSDR-pi4 python3[11888]: weewx[11888] INFO __main__: 
> Using configuration file /etc/weewx/weewx.conf
> Oct 23 02:19:57 SunSDR-pi4 python3[11888]: weewx[11888] INFO __main__: 
> Debug is 0
> Oct 23 02:19:57 SunSDR-pi4 python3[11888]: weewx[11888] INFO __main__: PID 
> file is /var/run/weewx.pid
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] INFO weewx.engine: 
> Loading station type Ultimeter (weewx.drivers.ultimeter)
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] INFO 
> weewx.drivers.ultimeter: Driver version is 0.6
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] INFO 
> weewx.drivers.ultimeter: Using serial port /dev/ttyUSB0
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] CRITICAL __main__: 
> Caught unrecoverable exception:
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] CRITICAL __main__: 
>   could not convert string to float: 
> '___>
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] CRITICAL __main__: 
>   Traceback (most recent call last):
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] CRITICAL __main__: 
> File "/usr/share/weewx/weewxd", line 148, in main
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] CRITICAL __main__: 
>   engine = weewx.engine.StdEngine(config_dict)
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] CRITICAL __main__: 
> File "/usr/share/weewx/weewx/engine.py", line 84, in __init__
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] CRITICAL __main__: 
>   self.stn_info = weewx.station.StationInfo(self.console, 
> **config_dict['Station'])
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] CRITICAL __main__: 
> File "/usr/share/weewx/weewx/station.py", line 51, in __init__
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] CRITICAL __main__: 
>   self.latitude_f  = float(stn_dict['latitude'])
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] CRITICAL __main__: 
>   ValueError: could not convert string to float: 
> '___>
> Oct 23 02:19:57 SunSDR-pi4 python3[11891]: weewx[11891] CRITICAL __main__: 
>   Exiting.
> Oct 23 02:19:57 SunSDR-pi4 weewx[11877]: Starting weewx weather system: 
> weewx.
> Oct 23 02:19:57 SunSDR-pi4 systemd[1]: Started LSB: weewx weather system.
> Oct 23 02:21:25 SunSDR-pi4 systemd[1]: Stopping LSB: weewx weather 
> system...
> Oct 23 02:21:25 SunSDR-pi4 weewx[12401]: Stopping weewx weather system: 
> weewx not running
> Oct 23 02:21:25 SunSDR-pi4 systemd[1]: weewx.service: Succeeded.
> Oct 23 02:21:25 SunSDR-pi4 systemd[1]: Stopped LSB: weewx weather system.
>
>
> Daniel Fourlas schrieb am Donnerstag, 8. Februar 2024 um 17:29:16 UTC+2:
>
>> Many Tnx for the info, now i fid this!
>>
>> Now give a unique URL for the station. A Weather Underground 
>> URL such as https://www.wunderground.com/dashboard/pws/KORPORT12 will do.
>> Unique URL: https://stationsweb.awekas.at/index.php?id=34255
>> Saving configuration file /etc/weewx/weewx.conf
>> Traceback (most recent call last):
>>   File "/usr/lib/python3.9/shutil.py", line 806, in move
>> os.rename(src, real_dst)
>> PermissionError: [Errno 13] Permission denied: '/etc/weewx/weewx.conf' -> 
>> '/etc/weewx/weewx.conf.20240208172027'
>>
>> During handling of the above exception, another exception occurred:
>>
>> Traceback (most recent call last):
>>   File "/usr/share/weewx/weectl.py", line 74, in 
>> main()
>>

Re: [weewx-user] Slow Report Generation after Upgrade from 4.10.2 to 5..0

2024-01-19 Thread 'Cameron D' via weewx-user



On Friday 19 January 2024 at 4:37:05 am UTC+10 vince wrote:


The pattern so far seems to be (a) Belchertown and (b) certain drivers that 
might not have complete measurement sets.   I see Acurite and Interceptor 
in a couple reports if I remember correctly.


 No, it is *any *skin that tries to plot the derived parameters - the 
common factor is if they are not in the DB. I reported the same with the 
default standard Seasons skin.

-- 
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/0283c3df-33c9-4318-93a0-123c411083a2n%40googlegroups.com.

[weewx-user] Re: v5.0 main loop exiting/restarting constantly and very slow/misses readings

2024-01-18 Thread 'Cameron D' via weewx-user

There might be two separate issues - I had the slow reports, but not 
associated with restarting  weewx.

What happens if you disable the reports ? does weewx runs happily or still 
restart?

On Thursday 18 January 2024 at 8:14:23 pm UTC+10 Richard Whitcombe wrote:

> I accidentally updated to v5.0 (Debian apt update) and since then my 
> install has basically been broken and i cant seem to work out why.
>
> Running on a RaPi for years with no issue, using Belchertown skin.
>
> What im seeing now is the service seems to start fine, but after each 5 
> min cycle the entire thread seems to kill itself and reload/reinitialise 
> from scratch.
>
> In logs:
>
> INFO weewx.cheetahgenerator: Generated 12 files for report StandardReport 
> in 188.04 seconds
> Jan 18 10:03:28  weewxd[420]: INFO weewx.reportengine: Copied 39 
> files to /var/www/html/weewx
> Jan 18 10:05:24  weewxd[420]: INFO weewx.manager: Added record 
> 2024-01-18 10:05:00 GMT (1705572300) to database 'weewx.sdb'
> Jan 18 10:05:24  weewxd[420]: INFO weewx.manager: Added record 
> 2024-01-18 10:05:00 GMT (1705572300) to daily summary in 'weewx.sdb'
> Jan 18 10:05:29  weewxd[420]: INFO weewx.engine: Main loop 
> exiting. Shutting engine down.
> Jan 18 10:05:29  weewxd[420]: INFO weewx.engine: Shutting down 
> StdReport thread
> Jan 18 10:05:49  weewxd[420]: INFO user.interceptor: shutting down 
> server thread
> Jan 18 10:05:50  weewxd[420]: INFO weewx.cheetahgenerator: 
> Generated 12 files for report Belchertown in 136.37 seconds
>
>
> Jan 18 10:07:49  weewxd[420]: INFO __main__: retrying...
> Jan 18 10:07:49  weewxd[420]: INFO weewx.engine: Loading station 
> type Interceptor (user.interceptor)
> Jan 18 10:07:49  weewxd[420]: INFO user.interceptor: driver 
> version is 0.60
> Jan 18 10:07:49  weewxd[420]: INFO user.interceptor: device type: 
> observer
> Jan 18 10:07:49  weewxd[420]: INFO user.interceptor: hardware 
> name: weatherstation via interceptor
> Jan 18 10:07:49  weewxd[420]: INFO user.interceptor: mode is listen
> Jan 18 10:07:49  weewxd[420]: INFO user.interceptor: listen on 
> :8090
> Jan 18 10:07:49  weewxd[420]: INFO user.interceptor: sensor map: 
> {'pressure': 'pressure', 'barometer': 'barometer', 'outHumidity': 
> 'humidity_out', 'inHumidity': 'humidity_in', 'outTemp': 'temperature_out', 
> 'inTemp': 'temperature_in', 'windSpeed': 'wind_speed', 'windGust': 
> 'wind_gust', 'windDir': 'wind_dir', 'windGustDir': 'wind_gust_dir', 
> 'radiation': 'solar_radiation', 'dewpoint': 'dewpoint', 'windchill': 
> 'windchill', 'rain': 'rain', 'rainRate': 'rain_rate', 'UV': 'uv', 
> 'txBatteryStatus': 'battery', 'extraTemp1': 'temperature_1', 'extraTemp2': 
> 'temperature_2', 'extraTemp3': 'temperature_3', 'extraHumid1': 
> 'humidity_1', 'extraHumid2': 'humidity_2', 'soilTemp1': 
> 'soil_temperature_1', 'soilTemp2': 'soil_temperature_2', 'soilMoist1': 
> 'soil_moisture_1', 'soilMoist2': 'soil_moisture_2', 'soilMoist3': 
> 'soil_moisture_3', 'soilMoist4': 'soil_moisture_4', 'leafWet1': 
> 'leafwetness_1', 'leafWet2': 'leafwetness_2', 'pm2_5': 'pm2_5', 
> 'extraTemp4': 'temperature_4', 'extraTemp5': 'temperature_5', 'extraTemp6': 
> 'temperature_6', 'extraTemp7': 'temperature_7', 'extraTemp8': 
> 'temperature_8', 'extraHumid3': 'humidity_3', 'extraHumid4': 'humidity_4', 
> 'extraHumid5': 'humidity_5', 'extraHumid6': 'humidity_6', 'extraHumid7': 
> 'humidity_7', 'extraHumid8': 'humidity_8', 'soilTemp3': 
> 'soil_temperature_3', 'soilTemp4': 'soil_temperature_4'}
> Jan 18 10:07:49  weewxd[420]: INFO weewx.engine: StdConvert target 
> unit is 0x1
> Jan 18 10:07:49  weewxd[420]: INFO weewx.wxservices: 
> StdWXCalculate will use data binding wx_binding
> Jan 18 10:07:49  weewxd[420]: INFO weewx.engine: Archive will use 
> data binding wx_binding
> Jan 18 10:07:49  weewxd[420]: INFO weewx.engine: Record generation 
> will be attempted in 'hardware'
> Jan 18 10:07:49  weewxd[420]: INFO weewx.engine: Using archive 
> interval of 300 seconds (specified in weewx configuration)
> Jan 18 10:07:49  weewxd[420]: INFO weewx.restx: StationRegistry: 
> Station will be registered.
> Jan 18 10:07:49  weewxd[420]: INFO weewx.restx: Wunderground-PWS: 
> Data for station  will be posted
> Jan 18 10:07:49  weewxd[420]: INFO weewx.restx: PWSweather: No 
> config info. Skipped.
> Jan 18 10:07:49  weewxd[420]: INFO weewx.restx: CWOP: Posting not 
> enabled.
> Jan 18 10:07:49  weewxd[420]: INFO weewx.restx: WOW: Data for 
> station XX will be posted
> Jan 18 10:07:49  weewxd[420]: INFO weewx.restx: AWEKAS: Posting 
> not enabled.
> Jan 18 10:07:49  weewxd[420]: INFO user.windy: version is 0.7
> Jan 18 10:07:49  weewxd[420]: INFO user.windy: Data will be 
> uploaded to https://stations.windy.com/pws/update
> Jan 18 10:07:49  weewxd[420]: INFO weewx.engine: 'pyephem' 
> detected, extended almanac data is available
> Jan 18 10:07:49  weewxd[420]: INFO __main__: Starting up weewx 
> version 5.0.0
>
>
> The end result of this is it isnt getting regular,

Re: [weewx-user] V5.0.0 available

2024-01-15 Thread 'Cameron D' via weewx-user



On Monday 15 January 2024 at 10:46:24 am UTC+10 matthew wall wrote:

Any gotchas on moving from the betas to the release? I'm using the pip 
method.


pip seems to handle the beta/rc labels ok (unlike dpkg/apt, which seems to 
be having issues with 'rc') 


In case anyone is interested, to force a "downgrade" from the rc  using 
apt, just apt-get install weewx=5.0.0-1

-- 
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/b16cc194-f058-47af-9563-ecc995aff06an%40googlegroups.com.

Re: [weewx-user] WEEWX_ROOT partly failing

2024-01-06 Thread 'Cameron D' via weewx-user

The current docs for V4.10 as well as 5.0 say that "a *relative *path" for 
HTML_ROOT or SKIN_ROOT is below WEEWX_ROOT.  
If you define either as an *absolute* path (i.e. beginning with a "/"), 
then WEEWX_ROOT is ignored.

On Saturday 6 January 2024 at 6:53:06 pm UTC+10 Michael Waldor wrote:

> Maybe best is to illustrate my setup with the Linux commands to create it 
> (in reality I didi it somehow different because differen hosts are 
> involved):
> WEEWX_ROOT=~/weewx-debug
> mkdir $WEEWX_ROOT
> cd $WEEWX_ROOT
> (cd /; tar zcvf - usr/share/weewx)|tar zxvf -
> (cd /; tar zcvf - etc/weewx)|tar zxvf -
> mkdir -p var/www/html/weewx
> mkdir -p var/lib/weewx
> cp /var/lib/weewx/*.sdb var/lib/weewx
>
> Within etc/weewx/weewx.conf I modified
> WEEWX_ROOT = /home/MyHome/weewx-debug
> ...
> SQLITE_ROOT = /home/MyHome/weewx-debug/var/lib/weewx
>
> I enabled debug = 1 
> I did NOT change SKIN_ROOT and HTML_ROOT since the (maybe outdated) 
> comments from weewx.conf say
>
> # Where the skins reside, relative to WEEWX_ROOT
> SKIN_ROOT = /etc/weewx/skins
> 
> # Where the generated reports should go, relative to WEEWX_ROOT
> HTML_ROOT = /var/www/html/weewx
>
> Maybe simply those comments are misleading? For my debugging I simply 
> created symbolic links for skins and www. Probabely I should have changed 
> SKIN_ROOT and HTML_ROOT instead? Just tested it right now - and YES it 
> worked. Thus only the comments are wrong. Setting
> SKIN_ROOT = /home/MyHome/weewx-debug/etc/weewx/skins
> HTML_ROOT = /home/MyHome/weewx-debug/var/www/html/weewx
> works fine without additional symbolic links!
>
> From my perspective this is better as compared to the (hidden) use of 
> WEEWX_ROOT. Thus maybe one only should correct the misleading comments 
> within default weewx.conf?
>
> Regards, Michael
>
> Tom Hogland schrieb am Samstag, 6. Januar 2024 um 02:35:53 UTC+1:
>
>> Michael - 
>>
>> WEEWX_ROOT is the root folder under which all the other folders live 
>> (such as HTML_ROOT or SKIN_ROOT). My WEEWX_ROOT is /, SKIN_ROOT is 
>> /etc/weewx/skins and HTML_ROOT is /var/www/html/weewx. Your skins would be 
>> in WEEWX_ROOT/SKIN_ROOT and your weather files will generate into 
>> WEEWX_ROOT/HTML_ROOT.
>>
>> What do you have SKIN_ROOT and HTML_ROOT set to? And do those folders 
>> exist within the WEEWX_ROOT folder you created?
>>
>> Tom
>>
>> On Friday, January 5, 2024 at 2:56:29 PM UTC-9 Tom Keffer wrote:
>>
>>> Could you try again? I don't understand the point you are making. 
>>>
>>> On Fri, Jan 5, 2024 at 7:59 AM 'Michael Waldor' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
 Maybe my understanding of WEEWX_ROOT is wrong. But partly it worked 
 thus I assume it is not working everywhere. I did set WEEWX_ROOT within 
 weewx.conf onto some directory and copied a full weewx 4.6.2 installation 
 over there. But the following folders were not found

 WEEWX_ROOT/etc/weewx/skins
 WEEWX_ROOT/var/www/html/weewx

 I could fix that by introducing proper links like e.g.
 mkdir /etc/weewx
 cd !$
 ln -s WEEWX_ROOT/etc/weewx/skin
 cd /var
 ln -s WEEWX_ROOT/var/www

 It's really a minor issue, but maybe it should be fixed sometimes.

 Regards, Michael

 -- 
 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/d6931dc9-214c-4a75-b1ae-b2bd063b2ca5n%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/487d9df0-4640-4b85-9715-005e172c42a9n%40googlegroups.com.

Re: [weewx-user] column create/rename error "ModuleNotFoundError: No module named 'user'"

2023-12-29 Thread 'Cameron D' via weewx-user

Matthew has just announced a pip release of rc2, which probably fixes the 
user module path problem in weectl.


On Friday 29 December 2023 at 11:35:11 pm UTC+10 steepleian wrote:

> I have an identical error when using weectl report run with v5rc1
> https://claydonsweather.org.uk
>
> On 29 Dec 2023, at 13:27, 'neutrino' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
> 
>
> Hello everyone,
> I try to modify my existing database after upgrading to v5.
> Get these errors:
>
> (weewx-venv) xxx@###:~/weewx-data$ weectl database add-column test
> Using configuration file /home/jnz/weewx-data/weewx.conf
> Traceback (most recent call last):
>   File "/home/xxx/weewx-venv/bin/weectl", line 8, in 
> sys.exit(main())
>   File "/home/xxx/weewx-venv/lib/python3.10/site-packages/weectl.py", line 
> 66, in main
> namespace.func(namespace)
>   File 
> "/home/xxx/weewx-venv/lib/python3.10/site-packages/weectllib/__init__.py", 
> line 96, in dispatch
> namespace.action_func(config_dict, namespace)
>   File 
> "/home/xxx/weewx-venv/lib/python3.10/site-packages/weectllib/database_cmd.py",
>  
> line 342, in add_column
> weectllib.database_actions.add_column(config_dict,
>   File 
> "/home/xxx/weewx-venv/lib/python3.10/site-packages/weectllib/database_actions.py",
>  
> line 157, in add_column
> manager_dict = weewx.manager.get_manager_dict_from_config(config_dict, 
> db_binding)
>   File 
> "/home/xxx/weewx-venv/lib/python3.10/site-packages/weewx/manager.py", line 
> 886, in get_manager_dict_from_config
> manager_dict['schema'] = weeutil.weeutil.get_object(schema_name)
>   File 
> "/home/xxx/weewx-venv/lib/python3.10/site-packages/weeutil/weeutil.py", 
> line 1404, in get_object
> module = importlib.import_module(module_name)
>   File "/usr/lib/python3.10/importlib/__init__.py", line 126, in 
> import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1050, in _gcd_import
>   File "", line 1027, in _find_and_load
>   File "", line 992, in 
> _find_and_load_unlocked
>   File "", line 241, in 
> _call_with_frames_removed
>   File "", line 1050, in _gcd_import
>   File "", line 1027, in _find_and_load
>   File "", line 1004, in 
> _find_and_load_unlocked
> *ModuleNotFoundError: No module named 'user'*
>
> Any ideas?
> Thanks!
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/ae5b4963-63a5-46e8-bb16-e0d8b2099203n%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/bf5c9efa-e429-46fd-ae30-86a45c9738aan%40googlegroups.com.

[weewx-user] Weewx docs offline

2023-12-27 Thread 'Cameron D' via weewx-user

The website at https://weewx.com/docs/ redirects 
to  https://weewx.com/docs/4.10, which returns a 404.
Likewise, my previous tabs  that were sitting on  V5 docs returned a 404 
when I refreshed them.

I thought it might have been an upgrade in process, but it's been an hout 
or two now.

-- 
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/458ac74a-6201-4182-9082-7a7b50883282n%40googlegroups.com.

[weewx-user] Re: Keep losing nameserver on ubuntu 22.04

2023-12-17 Thread 'Cameron D' via weewx-user

yes, definitely not a weeex problem.
You have not given us anything to go on, as there are  dozens of 
combinations of installations that will influence this.  For example  
"*Resolv.conf 
seems to be a simlink to something else*" is about as vague as you can 
possibly get.


   1. When you say "my dns servers" do you really mean *you *are running 
   local DNS servers?, or do you mean ... "the external DNS servers my system 
   needs to use."?
   2. check out the documentation for systemd-resolved 
   

 - 
   it sounds like you are using this systemd utility.  There are many ways to 
   operate it
   3. if you remove the symlink at /etc/resolv.conf and replace with a text 
   file the information you want then systemd should leave it alone and assume 
   you are managing everything.
   4. are you running dhcp to give out details to your weewx system?  the 
   dhcp client will want to update DNS server details and needs to be 
   compatible with however your resolver operates.

Your best bet is to google for some guides, however be aware that  some 
will not be correct if they don't match your networking/server setup.

On Friday 15 December 2023 at 10:54:06 pm UTC+10 bgra...@umw.edu wrote:

> Hello,
> Weewx 4.10.2 has been running fine but suddenly stopped FTPing to the main 
> site. After checking, I found that my dns servers were missing. After 
> putting them back, it ran normally for a few hours and then FTP stopped 
> again because dns had disappeared. Not sure what is happening here as weewx 
> is running fine. Resolv.conf seems to be a simlink to something else and 
> can’t be edited. Using webmin to reset the dns servers only works for a 
> short while.
> I realize this probably isn’t a weewx problem but I’m completely stumped 
> as to how to fix the problem. Any help or suggestions would be greatly 
> appreciated. Thanks in advance.
> Cheers,
> Bob
>

-- 
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/025120d2-2673-431c-82ac-01e6bbb9018dn%40googlegroups.com.

Re: [weewx-user] Skin with multiple bindings - an odd restriction

2023-11-14 Thread 'Cameron D' via weewx-user

Thanks Tom,
the workaround in the index template file works well for my purposes.

Sorry - I searched for it, but either used the wrong search terms or didn't 
look back quite far enough.
Cameron.
On Sunday, 12 November 2023 at 11:11:57 pm UTC+10 Tom Keffer wrote:

> This is a known issue with the Seasons skin. See Issue #803 
> <https://github.com/weewx/weewx/issues/803>.
>
> Unfortunately, the self-provisioning feature only checks the default 
> binding (wx_binding), not any other bindings. You have to include the plot 
> manually.
>
> -tk
>
> On Sat, Nov 11, 2023 at 7:05 AM 'Cameron D' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> I have been running a dual-weewx setup for nearly a year, having added an 
>> Ecowitt system mainly for air quality, with a separate custom DB.
>> I have been running two separate skins, based on Seasons, with a few 
>> charts including binding from the other DB.
>> I thought I should really do it properly, and just set up a single skin 
>> with everything I wanted, but I am having problems when there are no data 
>> required from the default binding.
>>
>> Initially I thought that it was failing *whenever *there was no  data 
>> from  the default binding, but it seems stranger than that.
>> The simplest example is co2:  The following stanza fails to produce 
>> anything:
>>
>> [[[dayco2]]]
>> data_binding = "ecowitt_binding"
>> co2
>>
>> However, the following works...
>>
>> [[[dayco2]]]
>> data_binding = "ecowitt_binding"
>> co2
>> barometer
>>
>> Note that I am using the ecowitt binding for all data, and the ecowitt 
>> barometer fields are empty, so the plot I get is only for the CO2.
>>
>> So, from the combinations that I have tried,  it seems that
>>
>>1. you *can *do a plot containing data only in the secondary binding 
>>- sometimes
>>2. you *cannot *do a plot if none of the data names exist in the 
>>default binding.
>>3. At least one of the data types named inside square brackets *must 
>>exist in  the default binding*, irrespective of whichever binding 
>>supplies the data.
>>4. I could not  trick it by specifying a known name, such as 
>>"inTemp" and then overriding with "data_type = co2"
>>
>> -- 
>> 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/1fe20e91-1de5-459c-8a45-77deb7c2753fn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/1fe20e91-1de5-459c-8a45-77deb7c2753fn%40googlegroups.com?utm_medium=email_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 visit 
https://groups.google.com/d/msgid/weewx-user/91b12bdb-61d2-4bcf-9236-2aba38fd380cn%40googlegroups.com.

[weewx-user] Skin with multiple bindings - an odd restriction

2023-11-11 Thread 'Cameron D' via weewx-user

I have been running a dual-weewx setup for nearly a year, having added an
Ecowitt system mainly for air quality, with a separate custom DB.
I have been running two separate skins, based on Seasons, with a few charts
including binding from the other DB.
I thought I should really do it properly, and just set up a single skin
with everything I wanted, but I am having problems when there are no data
required from the default binding.

Initially I thought that it was failing *whenever *there was no data from
the default binding, but it seems stranger than that.
The simplest example is co2: The following stanza fails to produce
anything:

[[[dayco2]]]
data_binding = "ecowitt_binding"
co2

However, the following works...

[[[dayco2]]]
data_binding = "ecowitt_binding"
co2
barometer

Note that I am using the ecowitt binding for all data, and the ecowitt
barometer fields are empty, so the plot I get is only for the CO2.

So, from the combinations that I have tried, it seems that

1. you *can *do a plot containing data only in the secondary binding -
sometimes
2. you *cannot *do a plot if none of the data names exist in the default
binding.
3. At least one of the data types named inside square brackets *must
exist in the default binding*, irrespective of whichever binding
supplies the data.
4. I could not trick it by specifying a known name, such as
"inTemp" and then overriding with "data_type = co2"

--
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/1fe20e91-1de5-459c-8a45-77deb7c2753fn%40googlegroups.com.

[weewx-user] Re: Display of measured values in the terminal? RPI

2023-10-20 Thread 'Cameron D' via weewx-user

For a simple command line tool, use the sqlite3 program and provide a 
command like..
 SELECT * FROM archive ORDER BY dateTime DESC LIMIT 10;
will print the last 10 rows.  Or to get a bit fancier replace the '*' with 
just the fields you are interested in...
 SELECT dateTime, datetime( dateTime, 'unixepoch') as dt,  outTemp, etc 
FROM archive ORDER BY dateTime DESC LIMIT 10;

On Thursday, 19 October 2023 at 11:35:42 pm UTC+10 karlch...@googlemail.com 
wrote:

> Hi,
>
> I have an installation of weewx running on a raspberry pi - and would now 
> like to check remotely via the terminal whether all measured values are 
> recorded, or which measured values were currently retrieved by weewx from a 
> Davis 2 Pro. 
> Unfortunately I can't find a command which allows this in the terminal - 
> or is there a debug command which can display all measured values or 
> transferred data? Would be a great advantage for troubleshooting if you 
> could quickly take a look at the values via terminal.
>
> VNC or similar is unfortunately not an option - as I only have terminal 
> access - and need to find out why the data of the soil moisture sensors are 
> not retrieved from meteotemplate.
>

-- 
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/306160dd-8698-42e8-9f0e-9529ccb1b33dn%40googlegroups.com.

Re: [weewx-user] #!/bin/sh does not equal #!/bin/bash

2023-09-12 Thread 'Cameron D' via weewx-user

>>>  More than anyone wanted to know!  ??
Well, no - it is just what I wanted to know, only it's a bit too late.
The recent Debian 12 upgrade broke an embarrassingly large fraction of my 
cron scripts. Even though the scripts were #!/bin/sh, the bashisms were 
still working, so I had assumed they were posix-compatible.

Those links look like something I should investigate, thank you.
Cameron.

On Tuesday, 12 September 2023 at 12:33:33 pm UTC+10 Nate Bargmann wrote:

> * On 2023 11 Sep 20:50 -0500, gary@gmail.com wrote:
> > How's this related to WeeWX? I use a systemd timer to backup the 
> database. 
> > That one works a treat as I used bash, not sh
>
> It really depends on the distribution. Some use Bash as the login and
> system shell by symlinking it to /bin/sh. When called as 'sh' Bash
> mostly restricts itself to POSIX defined sh behavior. So-called
> Bashisms (Bash extensions to sh grammar) are turned off and scripts
> written to take advantage of Bashisms will have errors.
>
> Several releases ago Debian went one step further and set dash (Debian
> Almquist Shell) as the default system shell as noted:
>
> https://wiki.debian.org/Shell
>
> Converting a script with Bashisms to dash (sh) can be trivial or not.
> To aid in that process Debian offers checkbashisms:
>
> https://manpages.debian.org/bookworm/devscripts/checkbashisms.1.en.html
>
> Debian's choices filter down to Raspberry Pi OS and other derivatives
> such as Armbian and Ubuntu flavors..
>
> It is up to the script author/maintainer/distribution which shell to
> support. Some distributions have their system shell scripts written
> with the #!/bin/bash shebang. It is worth noting that beginning with
> Debian 12 (Bookworm) Bash can no longer be set as the system shell
> by running 'dpkg-reconfigure dash'. Of course manually editing the
> symlink can be done but there may be unexpected results with system
> scripts now written for Dash.
>
> More than anyone wanted to know!
>
> - 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/ebec42ce-240e-4c4d-a27d-95ddca6f7b2en%40googlegroups.com.

Re: [weewx-user] WeeWX in an RV?

2023-07-30 Thread 'Cameron D' via weewx-user

This would be my suggestion as well.  Certainly use a dedicated DB for the 
task, then populate it according to the effort you want to put into it.
Options would be:

   - custom GPS unit along the lines Vince suggested
   - use a normal in-car GPS unit that records your tracks and 
   download/export data each day.  I combine my car and walking gps tracks for 
   geotagging photos.
   - manually enter data once a day

When I do long trips, I often take a simple handheld temp/RH logger that I 
download occasionally - every few days.
I also have a second table with one row per day, where I manually enter 
comments about where the device was located and anything unusual that might 
have influenced the results.  Probably less necessary in an RV with fixed 
locations, but my logger might end up left inside the tent, outside the 
tent, or left inside the car on different days.  This table could also 
double as a more general diary.

On Sunday, 30 July 2023 at 6:39:28 am UTC+10 vince wrote:

> On Saturday, July 29, 2023 at 1:11:25 PM UTC-7 Stefan Gliessmann wrote:
>
> That would work. But I would miss out on the location and elevation data … 
> I would like to include location in a database …
>
>
> Sure. Get a GPS module for your pi and write a little script to seed a 
> custom field in the db.   Shouldn't be a big deal.  Just write to a 
> secondary sqlite db.
>
>  
>

-- 
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/1f0d9996-8190-4e8b-9ca4-42db7753ff37n%40googlegroups.com.

[weewx-user] Re: wind direction average issue + idea

2023-06-16 Thread 'Cameron D' via weewx-user

When I look at my year chart, winter months tend to westerly, while summer 
clusters SE or NE.
It sounds as if you might have a problem in your database.
For no wind, the speed value should be zero and the direction NULL.

Is it possible that you are recording a small positive speed instead of 
zero speed and this would allow a zero for direction instead of null?

Can you examine the database values?

On Friday, 16 June 2023 at 5:54:05 am UTC+10 Kevin Crivelli wrote:

> I kinda want to try and tackle the wind direction average problem that we 
> often see when we go to longer range charts such as months & years. When 
> the wind isn't blowing it tends to take a reading of "north" and that skews 
> the averages data. 
>
> My idea is to set a min in the [[MinMax]] section for wind to 1 instead of 
> 0
>
> and maybe set something in corrections like I do for lightning something 
> like 
>
> windDir = windDir if  windSpeed < 1 else None
>
> has anyone tried anything like this and if so how were the results? did it 
> mess up your data or help reign it in better like I hope to do
>

-- 
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/894d2717-8d47-45bc-a565-6a151547a108n%40googlegroups.com.

[weewx-user] Re: Increasing image size within Seasons skin

2023-03-08 Thread 'Cameron D' via weewx-user

I do the image size change at the top level, so that all images are the 
same size.  I am not sure what happens if only one image is larger.

I tested with Firefox (windows x64) and Apache server.

Use F12 and inspect where the size directive is coming from, if you feel 
brave.

On Wednesday, 8 March 2023 at 10:42:40 pm UTC+10 Michael Waldor wrote:

>
> Thanks for your quich reply. Changing the image size works fine in 
> skin.conf, but modifing seasons.css (for testing purpose at 
> /var/www/html/weewx being served by nginx) had no effect. Mayby cached 
> within firefox dspite reload?
>
> This is my current (testing) status within skin.conf - image sizes 
> currently intentionally commented:
>
> [[[daytempdew]]]   
>  
> # image_width = 600   
>   
> #image_height = 180   
>  
> outTemp   
>  
> data_type = outTemp  
> data_binding = wx_binding
> dewpoint  
> data_type = dewpoint  
> data_binding = wx_binding 
> forecast_outTemp 
> data_type = outTemp  
> label = ' '   
>   
> data_binding = dwd_binding
> color = blue   
>
> forecast_dewpoint 
> data_type = dewpoint  
> label = ' ' 
> data_binding = dwd_binding     
> color = red   
>   
> Cameron D schrieb am Mittwoch, 8. März 2023 um 13:33:09 UTC+1:
>
>> 1. edit the width in skin.conf
>> 2. edit the value in seasons.css for #history_widget  (where it says to 
>> match the skin.conf value)
>> 3. copy the css file into place (I forgot that!)
>> 4. ctrl-refresh to get full reload.
>>
>> On Wednesday, 8 March 2023 at 8:52:17 pm UTC+10 Michael Waldor wrote:
>>
>> ...
>>
>> Next I wanted to increase the image size form the default 500px to 600px. 
>> Again trivial by adding image_width within some image in skin.conf. Works 
>> fine, the created image has the requested width of 600. But it is shrunk to 
>> 500px probadely by seasons.css. I tried to modify seasons.css within 
>> history_widget (from 500px to 600px). Modifing the css seems to have no 
>> effect on the rendering (tried to reload the web page after changing css at 
>> server location).
>>
>> ...
>>
>>

-- 
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/27dd23c1-b122-4ca5-b06c-3d939a1f01a6n%40googlegroups.com.

[weewx-user] Re: Increasing image size within Seasons skin

2023-03-08 Thread 'Cameron D' via weewx-user

1. edit the width in skin.conf
2. edit the value in seasons.css for #history_widget  (where it says to 
match the skin.conf value)
3. copy the css file into place (I forgot that!)
4. ctrl-refresh to get full reload.

On Wednesday, 8 March 2023 at 8:52:17 pm UTC+10 Michael Waldor wrote:

...
Next I wanted to increase the image size form the default 500px to 600px. 
Again trivial by adding image_width within some image in skin.conf. Works 
fine, the created image has the requested width of 600. But it is shrunk to 
500px probadely by seasons.css. I tried to modify seasons.css within 
history_widget (from 500px to 600px). Modifing the css seems to have no 
effect on the rendering (tried to reload the web page after changing css at 
server location).
...

-- 
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/0333ff27-b0d9-4d15-b6bd-ae3063285218n%40googlegroups.com.

Re: [weewx-user] Re: Trouble viewing new data column(s)

2023-01-19 Thread 'Cameron D' via weewx-user

I hope this is not a real example you are suggesting -  part_per_million  
would be a concentration, which already has an implied volume component 
according to whether it is in air, water etc.   A unit of  
 part_per_million_per_cubic_meter does not make any sense to me. 

On Wednesday, 18 January 2023 at 7:31:52 pm UTC+10 steep...@btinternet.com 
wrote:

> Gary,
> Follow up question from me in a similar vein. What is the correct way to 
> add a completely new measurement group to WeeWX, for example 
> part_per_million_per_cubic_meter?
> Ian
>
> Sent from my iPad.
>
> On 17 Jan 2023, at 05:20, gjr80  wrote:
>
> If you add a new observation to the database you need to tell WeeWX what 
> unit group it belongs to in order to be able to effectively use the 
> formatting and unit conversion capabilities of the WeeWX tag system in 
> reports. For example, if you add a field that is a pressure once WeeWX 
> knows the new field is a pressure WeeWX knows what default formatting to 
> apply, the correct unit label and you can use the formatting and unit 
> conversion aspects of the tag system to change the format/convert units in 
> a WeeWX report template. If WeeWX does not know what unit group the 
> observation belongs to you just get the raw value from the database (which 
> is typically a float with many decimal places - ie what you are seeing now).
>
>
> There are a number of ways to assign an observation to a unit group. In 
> your case the easiest approach is to add a few lines of code to 
> /home/weewx/bin/user/extensions.py (or /usr/share/weewx/user/extensions.py 
> if you installed WeeWX as a package). Try adding the following to the 
> bottom of extensions.py:
>
> import weewx.units
> weewx.units.obs_group_dict['waterTemp'] = 'group_temperature'
> weewx.units.obs_group_dict['tideHeight'] = 'group_length'
>
> (group_temperature was the obvious choice for waterTemp; tideHeight could 
> be group_length, group_altitude, group_rain or group_distance. The 
> deciding factor here is the available units for each group - if you look at 
> the Units  appendix to the 
> Customisation Guide you will see what I mean)
>
> You will need to restart WeeWX for the changes to take effect. The 
> extensions.py code is run at WeeWX startup and the above lines will make 
> the appropriate unit group assignments for your new fields. You should now 
> be able to use tags based on waterTemp and tideHeight in your reports. 
> You will find some further info on assigning unit groups in the Customising 
> units and unit groups 
>  section of the 
> Customisation Guide. You will also find information on the WeeWX tag system 
> in the Tags  section of the 
> Customisation Guide.
>
> A couple of notes about units.
>
> For the WeeWX tag system to correctly and consistently display observation 
> values and units you need to ensure the data you are adding to the database 
> is in the correct units. How you do this depends on how you are inserting 
> data into the database. If you are using a WeeWX service to augment loop 
> packets (the preferred approach) then your service needs to take cognisance 
> of the unit system (ie WeeWX field usUnits) of the loop packet being 
> augmented and add waterTemp and tideHeight to the loop packet using the 
> appropriate units for the unit group each observation belongs to for the 
> unit system used by the loop packet. For example, if the loop packet uses 
> US customary units (ie usUnits = 0) then waterTemp would need to be in 
> Fahrenheit and tideHeight in inches. Once you do this WeeWX takes care of 
> everything else. You will find information on the unit systems, unit groups 
> and units used by WeeWX in the Units 
>  appendix to the 
> Customisation Guide.
>
> If you are directly inserting data in the WeeWX database (not the 
> preferred approach) then it is up to you to ensure that the values are 
> inserted using units applicable to the database unit system and the unit 
> group used for each observation.
>
> Apologies for the long response but the WeeWX tag/unit/formatting system 
> has a lot of moving parts and you need to have them all correctly 
> configured or you will have problems.
>
> Gary
> On Tuesday, 17 January 2023 at 07:19:24 UTC+10 ja...@runser.net wrote:
>
>> Incremental progress. As described above but with the addition of a 
>> restart I have data in the statistics section but still N/A for Water Temp 
>> in "Current Conditions". Further, the data in statistics is formatted as 
>> "00.00" instead of the hoped-for "00.00  °F". I've walked through the 
>> template and inc files but still can't find the right building blocks. I 
>> even tried changing the waterTemp column from a double to a double(4,2) but 
>> am still getting all the extra zeros.
>>
>> On Monday, January 16, 2023

[weewx-user] Re: Dedicated user account for weewx?

2023-01-18 Thread 'Cameron D' via weewx-user

There are notes on various aspects to this in the weewk wiki 


On Wednesday, 18 January 2023 at 9:23:29 am UTC+10 Wayne wrote:

> Hello - I am a new weewx user with medium proficiency in linux. Running on 
> a Raspberry Pi 4 installed from DEB package.
>
> Is there any benefit to creating a superuser account specifically for 
> weewx instead of running as "root"? It seems to me it would be a better 
> practice for using rsync to transfer files to an http server on another 
> machine. Or maybe it's not worth the effort. Comments??
>

-- 
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/d6825005-bee3-42b6-8e8a-6a81c62b02cen%40googlegroups.com.

Re: [weewx-user] Re: weewx server?

2023-01-06 Thread 'Cameron D' via weewx-user

Are you saying that you have a registered domain name (and that is as far 
as you have gone), or that you have a web server that is already 
successfully serving other pages to the public internet? 
 What exactly is that raspberry pi doing?  If it is serving web pages, is 
it the same machine that is running weewx?

On Friday, 6 January 2023 at 6:35:21 pm UTC+10 kb3...@gmail.com wrote:

> Lots of info.  Thanks.  I  have a website domain already and use a 
> raspberry pi for this.  I apparently just can't seem to get it to show 
> other than on the local network.  
>
> On Thursday, January 5, 2023 at 12:13:20 PM UTC-5 pannetron wrote:
>
>> If you host a public website from a personal Linux server, as I do, look 
>> into using fail2ban as a way to detect and block some bad actor bots.  My 
>> implementation currently has about 2500 IPs blocked because they were 
>> looking for typical webserver security flaws.
>>
>> On Wednesday, January 4, 2023 at 11:11:49 AM UTC-7 do...@dougjenkins.com 
>> wrote:
>>
>>> Glad some of you find this useful.
>>>
>>> I have been using this method since it came out this summer (July 2022). 
>>> I run my infrastructure (Web Server, WeeWX, MQTT, MariaDB) as containers in 
>>> one stack in its own network all in Docker. I do this to limit what the 
>>> cloudflare tunnel can access on my network (just WeeWx stuff). All of this 
>>> works in docker in one stack and one YAML file!
>>>
>>> Like Tom Lawerence mentioned in the video I attached, you have to put 
>>> Cloudflare in your "circle of trust" as you are depending on them for both 
>>> the client and server/edge side of the tunnel. You have to make that 
>>> determination on your own if you are comfortable with that.
>>>
>>> As other methods mentioned here, they are all great alternatives. I was 
>>> not aware adafriut offered a dashboard to present your data. That can be a 
>>> good alternative than going through the hassle of hosting a full website 
>>> for your station.
>>>
>>> If I get a free moment in a few weeks, I can post a step-by-step article 
>>> on onboarding your WeeWX weather station as a public website using 
>>> Cloudflare. I think it can help a lot of users who struggle with the 
>>> network & security setup.
>>>
>>> DDJ
>>>
>>> On Wed, Jan 4, 2023 at 12:49 PM vince  wrote:
>>>
 On Tuesday, January 3, 2023 at 6:41:01 PM UTC-8 do...@dougjenkins.com 
 wrote:

> If you are willing to roll up your sleeves and get technical, serving 
> your website at home can be done safely and securely without changing 
> your 
> firewall. There are some steps to do, but at the end it will save you 
> money 
> and it will give you some real-world IT experience.
>
>
 Very cool - thanks for the pointer to the video.  I hadn't previously 
 figured out the Zero Trust terminology enough to try the tunnel stuff. 
 I'll 
 have to try the tunnel thing too 

 For the original poster, Doug's steps 1-3 are very easy.  I'd 
 previously done that using Google Domains ($12/year).

 Note - you probably still want to possibly harden your weewx webserver 
 a bit.  There are zillions of bots trying to attack web servers 
 'especially' all things WordPress.  If you go just with a vanilla weewx 
 setup you're likely in very good shape straight out of the box.  Cool 
 cheap 
 option for sure.

 -- 
 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/56afd382-a9ba-49e7-831f-2813872d6db0n%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/fdc5e744-6983-4527-a87d-38f0ff76793an%40googlegroups.com.

[weewx-user] Re: Multi-station system adding ecowitt components - clarification requested

2022-12-17 Thread 'Cameron D' via weewx-user

Gary,
The main missing data were everything from the WH45 except CO2.  Also 
battery, signal and everages. I presume there was no intention of storing 
the 24-hour averages as weewx does its own averaging.
I am using weewx 4.9.1 with  gw1000 v 0.5.0b5.

PM10 in the wview_extended schema is known as 'pm10_0', while the gw1000 
driver always shows it as 'pm10'
PM2.5 in  the wview_extended schema is known as 'pm2_5', while the gw1000 
driver shows it as 'pm2_55' in test-driver and test-service modes or pm255 
in live mode.
Temp and Humidity from the WH45 are also missing (numbered extra-17 in the 
test-driver output)

for installation, I simply copied over the gw1000.py file (and api_data.py) 
into the weewx/user directory. then ran *wee_config   --install  *to create 
a config file from scratch.  I didn't use wee_extension, so not sure if 
anything was missed out there.
Cameron.

On Sunday, 18 December 2022 at 4:03:45 pm UTC+10 gjr80 wrote:

> On Sunday, 18 December 2022 at 15:03:16 UTC+10 Cameron D wrote:
>
>> I noticed that I still need to do remapping in the driver version with 
>> the full database otherwise half the data are missing.  Unless I missed a 
>> step somewhere.  In any case I tend to prefer to define my own DB structure 
>> so I will carry on down that road (for the time being).
>>
>
> Would be interested to know what data was missing?  I probably should have 
> clarified that sensor battery and signal states would need db schema 
> additions or a mapping change to map them to the existing db fields as the 
> view_extended schema includes a limited number of generic signal/battery 
> status fields for sensors. All the primary sensor values for the sensors 
> you listed (eg humidity, temperature PM2.5 etc) should automatically be 
> saved to database with no changes required. 
>
> 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/bd638036-c73c-44b6-be72-8ff786cb6b34n%40googlegroups.com.

[weewx-user] Re: Multi-station system adding ecowitt components - clarification requested

2022-12-17 Thread 'Cameron D' via weewx-user

Thanks everybody,
I am trying the multi approach as it seems cleaner.

 It turns out the systemd changes were trivial - easier than init.d.  I'll 
add something to the wiki when I have finished.

I noticed that I still need to do remapping in the driver version with the 
full database otherwise half the data are missing.  Unless I missed a step 
somewhere.  In any case I tend to prefer to define my own DB structure so I 
will carry on down that road (for the time being).

-- 
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/8f19806f-d84b-4236-ac94-59b06e84f334n%40googlegroups.com.

[weewx-user] Multi-station system adding ecowitt components - clarification requested

2022-12-16 Thread 'Cameron D' via weewx-user

My Oregon WMR300 is still happily chugging away generating weather data and
I thought I'd augment it with some air-quality sensors.
The easiest in my situation seemed to be an Ecowitt WH45 CO2/particle
sensor with a GW1100 gateway, and a WH31 temp/RH sensor thrown in for
almost nothing.
So my new system reports:
1 x barometer
3 x temperature
3 x humidity
1 each CO2, PM2.5, PM10.
sundry battery and signal strengths

One of my requirements is to have some plots containing data from both
systems on the one chart.

There seem to be two choices for driver - the Ecowitt (GW1000) and the
interceptor. Are there any strong reasons to choose one over the other?

There also seem to be two choices for implementation:
1. using weewx_multi and keep everything separate. Then use the multiple
binding technique in one skin to incorporate all data in a single report.
2. use the GW1000 code *as a service* in a single instance of weewx, with a
single database.

The second method seems in some ways simpler, but am I right in thinking I
would need to remap many of the names to avoid clashes with data from the
WMR300?

If I choose weewx_multi - is there a suitable systemd unit file I can use
as a template?

Thanks.
Cameron.

--
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/5b5b227f-59e7-4c78-b0a6-7a7906ec7633n%40googlegroups.com.

Re: [weewx-user] Lose connection to data until reboot

2022-09-20 Thread 'Cameron D' via weewx-user

I think the numbers vary a lot with the system architecture.  My numbers 
are for Intel x64 - RSS is half yours while VM_total is double.  Then 
again, I run only Seasons skin.

However, when I had the memory leak it was all due to data increment 
(showing up as RSS).  The jump in total while RSS is stable could be 
loading more code, so I expect  it should only happen once or twice then 
stabilise.  We need to see longer term trends.

On Wednesday, 21 September 2022 at 10:15:29 am UTC+10 vince wrote:

> Your graphs make no sense unless your os is somehow misconfigured.  The 
> mem_size is 3x or more what I'd expect.  The mem_rss and mem_share look 
> reasonable.   Did you do something to your os setup that alters how it 
> handles memory ?
>
> Here's mine from a pi4 with a lot of skins including Belchertown, MQTT 
> subscribe, MQTT publish, and some custom stuff I wrote for here.  I show 
> slight memory usage growth (bottom-left graph) in the almost 4 weeks since 
> I built a clean pi and moved my old setup over to it, but given I have a 
> 4GB pi4 I'm expecting/hoping that I'm good for a long long time.  Units are 
> in MB.
>
> [image: Screen Shot 2022-09-20 at 5.05.00 PM.png]
>
> Another way of working this one would be to (temporarily) switch back to 
> the simulator driver, restart weewx, and let it run for a day and see if it 
> has the expected under 100 MB of RAM usage.  That might hone in on your 
> driver being the culprit.
>
> On Tuesday, September 20, 2022 at 3:14:58 PM UTC-7 joh...@kd2gyo.com 
> wrote:
>
>> Vince - thank you. I've installed the memory util and it's working great. 
>> Screenshot below.
>>
>> I'm running the absolute basic config I think (or at least I thought) - 
>> basic skin (one of the default options) and only extension I think (or 
>> additional driver) is the WeatherLinkLive.
>>
>> [image: image.png]
>>
>>
>> On Tue, Sep 20, 2022 at 12:47 PM vince  wrote:
>>
>>> On Tuesday, September 20, 2022 at 8:27:00 AM UTC-7 joh...@kd2gyo.com 
>>> wrote:
>>>
>>>> Thanks Cameron - I see that now in the log, any pointers on how I could 
>>>> try and find that mem leak?
>>>>
>>>> On Tue, Sep 20, 2022 at 9:33 AM 'Cameron D' via weewx-user <
>>>> weewx...@googlegroups.com> wrote:
>>>>
>>>>> looking at the last line of the log, weewx had been allocated VM 
>>>>> totalling 21GB, RSS 14GB.  Killing everything else is not going to make 
>>>>> much difference.
>>>>>
>>>>>
>>> The only way is to step all the way back to square one and disable 
>>> 'everything' you have enabled and then reenable them one-by-one until you 
>>> can figure out the offending piece of the puzzle.Are you running a 
>>> large number of skins and extensions and other add-ons perhaps and one is 
>>> running amok ?  You haven't mentioned what you actually have installed and 
>>> enabled.
>>>
>>> People run weewx on systems with as low as 128 MB of RAM, so this one is 
>>> highly unusual to say the least.
>>>
>>> If it helps any, I have a small extension that will save the weewx 
>>> memory usage to a separate db and create a minimal skin+graphs of just that 
>>> - see github (link) 
>>> <https://github.com/vinceskahan/vds-weewx-v3-mem-extension> if you want 
>>> to automate getting some data easily.
>>>
>>>
>>> -- 
>>> 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/yJNYSpx-ihI/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> weewx-user+...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/0f0d9f38-151f-4e91-bd2f-12eac8869611n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/0f0d9f38-151f-4e91-bd2f-12eac8869611n%40googlegroups.com?utm_medium=email_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 visit 
https://groups.google.com/d/msgid/weewx-user/fb50731d-ff2a-43c1-8902-d71c30922276n%40googlegroups.com.

Re: [weewx-user] Lose connection to data until reboot

2022-09-20 Thread 'Cameron D' via weewx-user

I have been tracking my memory usage in Weewx for some years.  I was seeing 
slow memory leak until 10 months ago.  Since then VM total has bounced 
between  290 or 350 MB - it would start at 290 then after some time jump to 
350 and stay there until reboot. For the last 5 months has been a flat 
290MB.

I'd start looking at those step increments and see if they coincide with 
any particular events.

On Wednesday, 21 September 2022 at 8:14:58 am UTC+10 joh...@kd2gyo.com 
wrote:

> Vince - thank you. I've installed the memory util and it's working great. 
> Screenshot below.
>
> I'm running the absolute basic config I think (or at least I thought) - 
> basic skin (one of the default options) and only extension I think (or 
> additional driver) is the WeatherLinkLive.
>
> [image: image.png]
>
>
> On Tue, Sep 20, 2022 at 12:47 PM vince  wrote:
>
>> On Tuesday, September 20, 2022 at 8:27:00 AM UTC-7 joh...@kd2gyo.com 
>> wrote:
>>
>>> Thanks Cameron - I see that now in the log, any pointers on how I could 
>>> try and find that mem leak?
>>>
>>> On Tue, Sep 20, 2022 at 9:33 AM 'Cameron D' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
>>>> looking at the last line of the log, weewx had been allocated VM 
>>>> totalling 21GB, RSS 14GB.  Killing everything else is not going to make 
>>>> much difference.
>>>>
>>>>
>> The only way is to step all the way back to square one and disable 
>> 'everything' you have enabled and then reenable them one-by-one until you 
>> can figure out the offending piece of the puzzle.Are you running a 
>> large number of skins and extensions and other add-ons perhaps and one is 
>> running amok ?  You haven't mentioned what you actually have installed and 
>> enabled.
>>
>> People run weewx on systems with as low as 128 MB of RAM, so this one is 
>> highly unusual to say the least.
>>
>> If it helps any, I have a small extension that will save the weewx memory 
>> usage to a separate db and create a minimal skin+graphs of just that - see 
>> github (link) <https://github.com/vinceskahan/vds-weewx-v3-mem-extension> 
>> if you want to automate getting some data easily.
>>
>>
>> -- 
>> 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/yJNYSpx-ihI/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/0f0d9f38-151f-4e91-bd2f-12eac8869611n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/0f0d9f38-151f-4e91-bd2f-12eac8869611n%40googlegroups.com?utm_medium=email_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 visit 
https://groups.google.com/d/msgid/weewx-user/7416736b-0a56-4d34-a50c-3979941367a0n%40googlegroups.com.

Re: [weewx-user] Lose connection to data until reboot

2022-09-20 Thread 'Cameron D' via weewx-user

looking at the last line of the log, weewx had been allocated VM totalling 
21GB, RSS 14GB.  Killing everything else is not going to make much 
difference.

On Tuesday, 20 September 2022 at 11:28:43 pm UTC+10 jo...@johnkline.com 
wrote:

> You still have the problem that something is eating all of your memory.
>
> Assuming you got the process ID correct, something(s) else will be killed. 
>
> On Sep 20, 2022, at 3:40 AM, Johnnie Walker  wrote:
>
> 
>
> Hi John/Tom - many thanks to you both.
>
> On the server instance: running on normal PC hardware, 16GB RAM, Ubuntu 
> Server (think 20.04). I wrote "-1000" to /proc/PROC_ID/oom_score_adj - and 
> we'll see what happens from here. Server mainly used for internal websites, 
> also runs Ubiquiti Unifi Controller.
>
> Tom - I had thought I needed the WLL to serve data to weewx over the LAN, 
> so figured [WeatherLinkLive] in weewx.conf. Have just now checked the file 
> and I have both [Vantage] and [WeatherLinkLive] sections configured. It 
> sounds as if I could remove the WeatherLink one? Am remembering I used a 
> plugin initially to link to the WLL, maybe that's obsolete now.
>
> Both sections copied in below from conf file.
>
> Thanks - JW
>
>
> [Vantage]
> # This section is for the Davis Vantage series of weather stations.
>
> # Connection type: serial or ethernet
> #  serial (the classic VantagePro)
> #  ethernet (the WeatherLinkIP or Serial-Ethernet bridge)
> type = ethernet
>
> # If the connection type is serial, a port must be specified:
> #   Debian, Ubuntu, Redhat, Fedora, and SuSE:
> # /dev/ttyUSB0 is a common USB port name
> # /dev/ttyS0   is a common serial port name
> #   BSD:
> # /dev/cuaU0   is a common serial port name
> port = /dev/ttyUSB0
>
> # If the connection type is ethernet, an IP Address/hostname is 
> required:
> host = 192.168.1.210
>
> ##
> # The rest of this section rarely needs any attention.
> # You can safely leave it "as is."
> ##
>
> # Serial baud rate (usually 19200)
> baudrate = 19200
>
> # TCP port (when using the WeatherLinkIP)
> tcp_port = 2
>
> # TCP send delay (when using the WeatherLinkIP):
> tcp_send_delay = 0.5
>
> # The type of LOOP packet to request: 1 = LOOP1; 2 = LOOP2; 3 = both
> loop_request = 1
>
> # The id of your ISS station (usually 1). If you use a wind meter 
> connected
> # to a anemometer transmitter kit, use its id
> iss_id = 1
>
> # How long to wait for a response from the station before giving up (in
> # seconds; must be greater than 2)
> timeout = 4
>
> # How long to wait before trying again (in seconds)
> wait_before_retry = 1.2
>
> # How many times to try before giving up:
> max_tries = 4
>
> # Vantage model Type: 1 = Vantage Pro; 2 = Vantage Pro2
> model_type = 2
>
> # The driver to use:
> driver = weewx.drivers.vantage
>
> ..
>
> [WeatherLinkLive]
> driver = user.weatherlink_live
> host = 192.168.1.210
> polling_interval = 10
> mapping = th:1, th_indoor, baro, rain:1, wind:1, thw:1, thsw:1, 
> windchill:1
>
>
> On Mon, Sep 19, 2022 at 9:38 PM Tom Keffer  wrote:
>
>> I agree with John that this is an out-of-memory problem, but I wonder why 
>> you are getting the offset in humidity during the down time. Is this an 
>> artifact of using WeatherLinkLive? Indeed, why are you using WLL? Why not 
>> just go to the VP2 directly?
>>
>> On Mon, Sep 19, 2022 at 6:25 PM 'John Kline' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> Correction, the file is /proc//oom-score-adj
>>>
>>> On Sep 19, 2022, at 6:23 PM, John Kline  wrote:
>>>
>>> 
>>> It doesn’t look like you are losing the connection to your Vantage 
>>> Pro2.  Rather, the kernel is killing WeeWX because you’re running of of 
>>> memory.
>>>
>>> You could write -1000 to the /proc//oom-kill-adj 
>>> file to keep it from killing WeeWX, but then something else will be killed 
>>> to free up memory.
>>>
>>> What are you running WeeWX on?  How much memory?  What else is running?
>>>
>>> On Sep 19, 2022, at 6:10 PM, Johnnie Walker  wrote:
>>>
>>> Hi,
>>> I'd had a recurring issue for some months that the weewx service loses 
>>> connection to my Davis Vantage Pro2 / WeatherLink. Basic solution has been 
>>> to reboot which brings things back into action, although I lose the data 
>>> for the period during which the problem occurred. Shows up as breaks in the 
>>> charts (for example):
>>> [image: dayhum.png]
>>> I have some breaks that are 1-2 days or more if I was on travel and 
>>> didn't realize until I returned.
>>> I just took time to search /var/log/syslog for the instance that 
>>> happened today - log is copied in below. And it looks like an out of memory 
>>> error, so the process is killed. (Log is grep'd for "weewx" , I copied in

[weewx-user] Oregon WMR300 and battery on external sensor.

2022-06-17 Thread 'Cameron D' via weewx-user

This is just a bit of information for other WMR300 owners who might also
come across this issue. There is (I hope) no problem to solve, although
there is a question for other WMR300 owners - can you see the battery
status for the external sensor unit?

The external sensors of my system have been on the roof for about 6 years
with no problem apart from cleaning out the rain gauge occasionally after
the filters mysteriously disappear.
Recently it stopped transmitting, so I had a look - battery (AA Ni-MH) was
showing 1.3V but the test points on the PCB were showing about 0.5V, so I
gave a slight clean by rotating the battery and it sprang back to life.
For a few days.
I then started getting dropouts starting almost precisely at 16:35 each
evening, for 5 nights out of 6. But then, after about 30 to 60 minutes it
would spontaneously start up again and work as normal all night.
This is *not *the behaviour I would expect from a degrading battery - it
drops out after a day of charging, but happily provides power all night.
I plugged in the windows software to see if it gave me better information.
I gave the contacts a more thorough clean, and the battery terminals and
pcb test points both reported the same voltage (about 1.3V).
I then noticed the sudden appearance of the battery status indicator on
the PC and also on the console (but only after I select the "today" portion
of the screen). The PC showed (judging by the icon) the battery was 25%,
while the console seemed to show it was flat. Then the battery status
disappeared and I could not get it back.
I replaced it with a recently fully charged eneloop and, after a few
minutes, it showed the same battery status levels that it had before - i.e.
nearly flat. After an hour charging in full sunlight I brought it back
inside the house and the cell terminals and pcb test point both registered
1.45V.
I have not since then seen any battery status indication on the console or
the windows software. It seems to only report it just after being powered
on again. That might go some way to explain why I could never identify the
signal in the USB data stream.

But why does it show most problems when it should be at its highest charge
level but no problem after powering the system all night? I can only
guess it is somehow getting confused as it tries to transition from solar
power to battery power.

--
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/861f8fba-340e-437b-a46a-234089e0b0e6n%40googlegroups.com.

[weewx-user] Re: Modify the database for a new archive interval

2022-03-04 Thread 'Cameron D' via weewx-user

I have modified the wiki following this discussion.

On Thursday, 3 March 2022 at 10:47:51 pm UTC+10 f4n...@gmail.com wrote:

> There is a guide in the weewx wiki on how to consolidate the data in the 
> database for a new (higher) interval:
>
>
> https://github.com/weewx/weewx/wiki/Data-Consolidation---changing-sampling-interval
>
> Will this also work the other way around, from 5 to 1 or from 2 to 1 
> minute?
>
> Or could i use a simpler code that just fills the new, empty minutes in 
> between with duplicate data of the minutes around it? To not have any 
> abrupt gaps in between.
>
> I use the sqlite database
>

-- 
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/c1b83d55-2c2a-443b-a506-54dcd9ad6596n%40googlegroups.com.

Re: [weewx-user] Clean your rain gauges

2022-03-01 Thread 'Cameron D' via weewx-user

Funnily enough that just happened to me, but I lost a bit more than you.

The original filter went missing at some stage, so I also used the cut-off 
stainless steel tea-strainer.  That also went missing, so I suspect some 
thieving bird. The next one will be glued in.

A bit over a week ago I noticed the measured output fading away and decided 
I would inspect it as soon as the rain stopped. That was yesterday - and it 
had 3 seeds almost exactly spherical and just the right size to jam in the 
hole. I blame birds for that also, because there is no nearby tree from 
which they could have fallen, short of being in a cyclone.

The collector was full, and registered  a bit over 100 mm as it drained, 
which means I lost over 500mm of rainfall. Yes, last week gave us more than 
our entire rainfall for 2019.
On Tuesday, 1 March 2022 at 11:58:53 am UTC+10 graha...@gmail.com wrote:

> please send some of it to here in *south*east australia, vegetation is 
> crispy
>
> > On 1 Mar 2022, at 6:54 am, Tim Tuck  wrote:
> > 
> > LOL - you can have some of ours - we have too much now, the flooding is 
> getting ridiculous!
> > 
> > Tim on the East Coast of Australia.
> > 
> > 
> > On 1/3/22 06:35, p q wrote:
> >> sigh. I remember rain.
> >> 
> >> Greetings from California
> >> 
> > 
> > -- 
> > 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/7fe22c31-825b-b320-2332-68db5c6be356%40skybase.net
> .
>
>

-- 
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/28c2f406-9fcc-4022-bccb-9ffd797d1f79n%40googlegroups.com.

[weewx-user] Re: High CPU usage with Mysql and GW100 driver

So what is unusual about lightning_distance and PM2.5?
Are you asking it to plot them, but have no data?

It is quite possible to migrate your data between mysql and sqlite3, but 
that will not make much difference to your problem - your weewx system 
seems to be stuck in a loop trying to get that lightning and PM2.5 data.

On Wednesday, 26 January 2022 at 8:53:42 pm UTC+10 carlo74 wrote:

> I activate MySql log and now I see thousand and thousand of row like this 
> for "lightning_distance" "pm2_5" and "pm10_0"
>
> 2022-01-26T10:45:26.498249Z   20 QuerySELECT 
> avg(lightning_distance) FROM archive WHERE dateTime > 1641246300 AND 
> dateTime <= 1641246600 AND lightning_distance IS NOT NULL
> 2022-01-26T10:37:18.348249Z   16 QuerySELECT avg(pm2_5) 
> FROM archive WHERE dateTime > 1671106500 AND dateTime <= 1671106800 AND 
> pm2_5 IS NOT NULL
>
> Now I stop log file because in half an hour the file is 150MB >> HUGE !!!
>
> What can I do?
> Thanks
> Carlo
> Il giorno mercoledì 26 gennaio 2022 alle 10:12:01 UTC+1 Cameron D ha 
> scritto:
>
>> I withdraw that question - having installed htop and used tree mode I can 
>> see far more mysqld and weewx processes
>>
>> On Wednesday, 26 January 2022 at 6:51:45 pm UTC+10 Cameron D wrote:
>>
>>> Is it normal in your setup to have two weewxd processes? And two 
>>> mysqlds.  I run MariaDB so not exactly the same, but I only have one of 
>>> each.
>>>
>>> Have you checked memory usage to see you are not paging/swapping?
>>>
>>>
>>> On Tuesday, 25 January 2022 at 9:04:35 pm UTC+10 carlo74 wrote:
>>>
>>>> All server software update to the last version:
>>>> mysqld 8.0.27
>>>> weewx 4.5.1
>>>> GW1000 0.4.1
>>>>
>>>> I have a high CPU usage all the day at 50/60/70% of CPU. Why?
>>>>
>>>> [image: htop.jpg]
>>>>
>>>> [image: cockpit.jpg]
>>>>
>>>> and on syslog, sometimes:
>>>>
>>>> pcp-pmie[1855]: High aggregate context switch rate 10453ctxsw/s@server
>>>>
>>>> Today, after this message on syslog, my server crash and stop working:
>>>>
>>>> pcp-pmie[1749]: High aggregate context switch rate 9416ctxsw/s@server
>>>> pcp-pmie[1749]: High average processor utilization 97%util@server
>>>> pcp-pmie[1749]: High per CPU processor utilization 97%util[cpu0]@server 
>>>> 97%util[cpu1]@server
>>>>
>>>> Can you help me?
>>>> Thanks
>>>> Carlo
>>>>
>>>

-- 
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/a6578dc6-80f7-4958-8501-a0d1483f69fen%40googlegroups.com.

[weewx-user] Re: High CPU usage with Mysql and GW100 driver

I withdraw that question - having installed htop and used tree mode I can 
see far more mysqld and weewx processes

On Wednesday, 26 January 2022 at 6:51:45 pm UTC+10 Cameron D wrote:

> Is it normal in your setup to have two weewxd processes? And two mysqlds.  
> I run MariaDB so not exactly the same, but I only have one of each.
>
> Have you checked memory usage to see you are not paging/swapping?
>
>
> On Tuesday, 25 January 2022 at 9:04:35 pm UTC+10 carlo74 wrote:
>
>> All server software update to the last version:
>> mysqld 8.0.27
>> weewx 4.5.1
>> GW1000 0.4.1
>>
>> I have a high CPU usage all the day at 50/60/70% of CPU. Why?
>>
>> [image: htop.jpg]
>>
>> [image: cockpit.jpg]
>>
>> and on syslog, sometimes:
>>
>> pcp-pmie[1855]: High aggregate context switch rate 10453ctxsw/s@server
>>
>> Today, after this message on syslog, my server crash and stop working:
>>
>> pcp-pmie[1749]: High aggregate context switch rate 9416ctxsw/s@server
>> pcp-pmie[1749]: High average processor utilization 97%util@server
>> pcp-pmie[1749]: High per CPU processor utilization 97%util[cpu0]@server 
>> 97%util[cpu1]@server
>>
>> Can you help me?
>> Thanks
>> Carlo
>>
>

-- 
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/46d2c198-7461-4431-ae2e-3d08e442f82bn%40googlegroups.com.

[weewx-user] Re: corrupt mysql?

Firstly, you would want to rule out that phpMyAdmin is not the problem.
Try the same commands with mysql shell/client or even with mysql workbench 
on a windows system.

On Tuesday, 25 January 2022 at 5:47:42 pm UTC+10 lop...@gmail.com wrote:

> Hi everyone
>
> my weewx mysql database is acting weird.
>
> I've logged into phpmysql and I'm getting the following error, no matter 
> what table I'm trying to open
>
> *Warning* in ./libraries/sql.lib.php#613
>  count(): Parameter must be an array or an object that implements Countable
>
> *Backtrace*
>
> ./libraries/sql.lib.php#2128: PMA_isRememberSortingOrder(array)
> ./libraries/sql.lib.php#2062: PMA_executeQueryAndGetQueryResponse(
> array,
> boolean true,
> string 'weewx',
> string 'archive_day_appTemp',
> NULL,
> NULL,
> NULL,
> NULL,
> NULL,
> NULL,
> string '',
> string './themes/pmahomme/img/',
> NULL,
> NULL,
> NULL,
> string 'SELECT * FROM `archive_day_appTemp`',
> NULL,
> NULL,
> )
> ./sql.php#221: PMA_executeQueryAndSendQueryResponse(
> array,
> boolean true,
> string 'weewx',
> string 'archive_day_appTemp',
> NULL,
> NULL,
> NULL,
> NULL,
> NULL,
> NULL,
> string '',
> string './themes/pmahomme/img/',
> NULL,
> NULL,
> NULL,
> string 'SELECT * FROM `archive_day_appTemp`',
> NULL,
> NULL,
> )
>
> Can anyone help me out to fix this?
>

-- 
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/4d50837f-c818-42b4-bd83-2875ab4e6fd6n%40googlegroups.com.

[weewx-user] Re: High CPU usage with Mysql and GW100 driver

Is it normal in your setup to have two weewxd processes? And two mysqlds.  
I run MariaDB so not exactly the same, but I only have one of each.

Have you checked memory usage to see you are not paging/swapping?


On Tuesday, 25 January 2022 at 9:04:35 pm UTC+10 carlo74 wrote:

> All server software update to the last version:
> mysqld 8.0.27
> weewx 4.5.1
> GW1000 0.4.1
>
> I have a high CPU usage all the day at 50/60/70% of CPU. Why?
>
> [image: htop.jpg]
>
> [image: cockpit.jpg]
>
> and on syslog, sometimes:
>
> pcp-pmie[1855]: High aggregate context switch rate 10453ctxsw/s@server
>
> Today, after this message on syslog, my server crash and stop working:
>
> pcp-pmie[1749]: High aggregate context switch rate 9416ctxsw/s@server
> pcp-pmie[1749]: High average processor utilization 97%util@server
> pcp-pmie[1749]: High per CPU processor utilization 97%util[cpu0]@server 
> 97%util[cpu1]@server
>
> Can you help me?
> Thanks
> Carlo
>

-- 
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/787bab4e-2665-4eb4-9a0c-76518097fdb8n%40googlegroups.com.

Re: [weewx-user] When did the blast wave of the eruption "hit" your station? - extract your data

2022-01-22 Thread 'Cameron D' via weewx-user

Thanks morrowwm - much better to work from one source.

If anybody is needing to use the mysql version you should be warned that 
there is a ridiculously large number of mysql connector packages, and the 
one I used under Debian 10 is not packaged in Debian 11.
I tried one of the Debian 11 ones and the error handling codes are reported 
differently, so the easiest way out would be to just delete those lines and 
just print the print(err).
Drop me a line if you need help on that.

Cameron.

On Sunday, 23 January 2022 at 5:16:45 am UTC+10 morr...@gmail.com wrote:

> Did an update to my script at: 
> https://github.com/morrowwm/weewx_tonga_browse
>
> Mostly incorporating additions from Cameron (thanks!)
>
> All parameters you likely want to set are near the top of the script.
>
>1. support for mysql (untested, I don't have a mysql based weewx 
>installation)
>2. calculation and display of all three initial arrival, arrival from 
>opposite direction, and second arrival after one trip around the globe
>3. highlighting of the three events with grey bars
>4. cubic spline curve fit of raw data and use of that fit to remove 
>the base pressure variations. The new smoothing_hours parameter can be 
> used 
>to control how close the fit is. 
>5. changed the display of data to highlight the extracted events and 
>subdue the original data, other cosmetic changes
>
> I had a data outage about 26 hours after the event, we're quite a distance 
> from Tonga, plus a major storm was clearing out in our area. So not 
> obviously anything unusual happened.
>
> Some scientist might be interested in the arrival times of all this data, 
> though.
> [image: hunga_tonga.png]
>
>

-- 
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/db6b198e-5fb4-4cea-8ae5-b7a1a0925a4an%40googlegroups.com.

Re: [weewx-user] When did the blast wave of the eruption "hit" your station? - extract your data

I don't understand the physics of it. As per the last few postings the 
speed of sound may be variable enough to show up here.

I would just tinker with the speed of sound parameter and see if you can 
make all peaks look sensible. At least you have data at a good frequency.



On Friday, 21 January 2022 at 4:21:36 pm UTC+10 ti...@skybase.net wrote:

> Hi Cameron,
>
> Beut! - that worked a treat - thanks :)
>
> I've also noticed that the return pulse highlight appears to be off, see 
> pic below. Or is it meant to be like that ?
>
> thanks
>
> Tim
>
>
>
>

-- 
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/700bfa67-e531-4906-85d0-2ef9c9f88206n%40googlegroups.com.

Re: [weewx-user] When did the blast wave of the eruption "hit" your station? - extract your data

I assume your DB is storing in US units - mine is metricWX (I knew one day 
it would be useful to have done that!)
One easy way is to modify the queries yourself - where the  query (2 
queries in my code)  specifies "barometer", replace with 
"barometer * 33.8639 as barometer"

On Friday, 21 January 2022 at 3:36:31 pm UTC+10 ti...@skybase.net wrote:

> Hi all,
>
> The script works well on my data but the pressure readout is in inHg 
> rather than hPa. 
>
> Can an option be inserted to have hPa computed before plotting ?
>
> thanks
>
> Tim
>
>

-- 
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/a6b52952-3ace-4a2c-91f6-b71d5611b7cdn%40googlegroups.com.

Re: [weewx-user] When did the blast wave of the eruption "hit" your station? - extract your data

There are certainly uncertainties in the barometric data timings. My system 
is probably a worst case - it only reports a value every 15 minutes, and I 
don't know if that is an average of the previous 15 minutes or just a 
snapshot reading at the transition time. So for me 20 minutes is within the 
uncertainty.
Also, I don't know if it is expected, but the  pulses that travelled 
further show only the negative part, which comes after the positive. So 
there is extra lag in that.

I derived a speed by fitting data to Australian bureau charts, and they 
only show 30 minute samples, so my speed is hardly definitive.  I would 
expect it to vary a bit around the globe.  The average speed I derived from 
the first peak alone was 0.30 m/s, so that is either an indicator of the 
uncertainty in the fitting or that the average speed increased as it 
progressed.
On Friday, 21 January 2022 at 2:05:49 pm UTC+10 storm...@gmail.com wrote:

> Yes, the image files are being produced. Only thing I noticed was the 
> arrival time for the opposite pulse is off by approx. 20 minutes according 
> to the actual PWS data, this could be due to the wave speeding up or 
> slowing down as it made its way around the globe.  Right now I'm using your 
> default settings.
>
> On Thursday, January 20, 2022 at 10:40:36 PM UTC-5 Cameron D wrote:
>
>> the RankWarning is just a warning, you should still have image files 
>> produced.  I expect the polyfit it just ignores higher order terms and just 
>> returns a quadratic.
>>
>> That is because the polynomial is a poor representation of the 
>> background, and the spline fit works better, if you get the parameters 
>> correct.
>>
>> Initially you are better just to view the results without trend removal.  
>> If the peaks  do not stand out then  background removal is unlikely to help 
>> much.
>> Also, with my code,  make sure you start with oversampling set to 1. Only 
>> adjust it if you see a stair-step effect.
>>
>> On Friday, 21 January 2022 at 1:09:28 pm UTC+10 storm...@gmail.com wrote:
>>
>>> Modified the query and added the print statement as suggested by Cameron 
>>> D and here are the results:
>>>
>>> *Morrowwn Script:*
>>>
>>> raspberrypi:~/Desktop/Tonga $ python3 tonga_barometer.py
>>> distance to eruption 13293.9 km arrival at 1642261629 (2022-01-15 
>>> 10:47:08)
>>> select datetime, barometer from archive where datetime > 1642172400 and 
>>> datetime < 1642693629 order by dateTime;
>>> Traceback (most recent call last):
>>>   File "tonga_barometer.py", line 47, in 
>>> coeff = np.polyfit(xdata, ydata, 2)
>>>   File "/usr/lib/python3/dist-packages/numpy/lib/polynomial.py", line 
>>> 590, in polyfit
>>> y = NX.asarray(y) + 0.0
>>> TypeError: unsupported operand type(s) for +: 'NoneType' and 'float'
>>>
>>>
>>> *Cameron D Script*:
>>>
>>> raspberrypi:~/Desktop/Tonga $ python3 tonga_baro.py
>>> distance to eruption 12255.7 km arrival at 1642258384 (2022-01-15 
>>> 09:53:04)
>>>   opposite pulse arrival at 1642306911 (2022-01-15 23:21:50)
>>>   second time around pulse arrival at 1642383509 (2022-01-16 
>>> 20:38:29)
>>> query returned 96 data points
>>> query returned 96 data points
>>> query returned 95 data points
>>> tonga_baro.py:108: RankWarning: Polyfit may be poorly conditioned
>>>   coeff = np.polyfit(xdata, ydata, 5 )
>>>
>>> Note: LAT/Long and speed of sound are identical in both scripts.
>>> On Thursday, January 20, 2022 at 9:27:13 PM UTC-5 Cameron D wrote:
>>>
>>>> and add a debug printout for how many result lines there are after ...
>>>> result = cursor.fetchall()
>>>> add the line:
>>>> 
>>>> *print( "query returned {} data points".format(len(result)))*
>>>>
>>>> On Friday, 21 January 2022 at 12:21:59 pm UTC+10 Cameron D wrote:
>>>>
>>>>> To eliminate NULL data points use a query like:
>>>>> select datetime, barometer from archive where datetime > 1642172400 
>>>>> and datetime < 1642693629* and barometer is not null *order by 
>>>>> dateTime;
>>>>>  You could add the part in bold into the query in the python script.
>>>>>
>>>>> Of course, if they are all null...
>>>>>
>>>>> On Friday, 21 January 2022 at 12:14:44 pm UTC+10 storm...@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> Download th

Re: [weewx-user] When did the blast wave of the eruption "hit" your station? - extract your data

the RankWarning is just a warning, you should still have image files 
produced.  I expect the polyfit it just ignores higher order terms and just 
returns a quadratic.

That is because the polynomial is a poor representation of the background, 
and the spline fit works better, if you get the parameters correct.

Initially you are better just to view the results without trend removal.  
If the peaks  do not stand out then  background removal is unlikely to help 
much.
Also, with my code,  make sure you start with oversampling set to 1. Only 
adjust it if you see a stair-step effect.

On Friday, 21 January 2022 at 1:09:28 pm UTC+10 storm...@gmail.com wrote:

> Modified the query and added the print statement as suggested by Cameron D 
> and here are the results:
>
> *Morrowwn Script:*
>
> raspberrypi:~/Desktop/Tonga $ python3 tonga_barometer.py
> distance to eruption 13293.9 km arrival at 1642261629 (2022-01-15 10:47:08)
> select datetime, barometer from archive where datetime > 1642172400 and 
> datetime < 1642693629 order by dateTime;
> Traceback (most recent call last):
>   File "tonga_barometer.py", line 47, in 
> coeff = np.polyfit(xdata, ydata, 2)
>   File "/usr/lib/python3/dist-packages/numpy/lib/polynomial.py", line 590, 
> in polyfit
> y = NX.asarray(y) + 0.0
> TypeError: unsupported operand type(s) for +: 'NoneType' and 'float'
>
>
> *Cameron D Script*:
>
> raspberrypi:~/Desktop/Tonga $ python3 tonga_baro.py
> distance to eruption 12255.7 km arrival at 1642258384 (2022-01-15 09:53:04)
>   opposite pulse arrival at 1642306911 (2022-01-15 23:21:50)
>   second time around pulse arrival at 1642383509 (2022-01-16 20:38:29)
> query returned 96 data points
> query returned 96 data points
> query returned 95 data points
> tonga_baro.py:108: RankWarning: Polyfit may be poorly conditioned
>   coeff = np.polyfit(xdata, ydata, 5 )
>
> Note: LAT/Long and speed of sound are identical in both scripts.
> On Thursday, January 20, 2022 at 9:27:13 PM UTC-5 Cameron D wrote:
>
>> and add a debug printout for how many result lines there are after ...
>> result = cursor.fetchall()
>> add the line:
>> 
>> *print( "query returned {} data points".format(len(result)))*
>>
>> On Friday, 21 January 2022 at 12:21:59 pm UTC+10 Cameron D wrote:
>>
>>> To eliminate NULL data points use a query like:
>>> select datetime, barometer from archive where datetime > 1642172400 and 
>>> datetime < 1642693629* and barometer is not null *order by dateTime;
>>>  You could add the part in bold into the query in the python script.
>>>
>>> Of course, if they are all null...
>>>
>>> On Friday, 21 January 2022 at 12:14:44 pm UTC+10 storm...@gmail.com 
>>> wrote:
>>>
>>>> Download the latest script from 
>>>> https://github.com/morrowwm/weewx_tonga_browse. Beside installing the 
>>>> Python Modules Vince stated above, I needed to also install  
>>>> python3-scipy. I do have data between 1642172400 and 1642693629; 
>>>> except for a couple "null" in that time period.   So when I run the 
>>>> script, 
>>>> I get the following error.
>>>>
>>>> raspberrypi:~/Desktop/Tonga $ python3 tonga_barometer.py
>>>> distance to eruption 13293.9 km arrival at 1642261629 (2022-01-15 
>>>> 10:47:08)
>>>> select datetime, barometer from archive where datetime > 1642172400 and 
>>>> datetime < 1642693629 order by dateTime;
>>>> Traceback (most recent call last):
>>>>   File "tonga_barometer.py", line 47, in 
>>>> coeff = np.polyfit(xdata, ydata, 2)
>>>>   File "/usr/lib/python3/dist-packages/numpy/lib/polynomial.py", line 
>>>> 590, in polyfit
>>>> y = NX.asarray(y) + 0.0
>>>> TypeError: unsupported operand type(s) for +: 'NoneType' and 'float'
>>>>
>>>> There should be a way to check for "null" data within the time period.
>>>> On Thursday, January 20, 2022 at 8:12:55 PM UTC-5 Cameron D wrote:
>>>>
>>>>> yes, definitely looks like there is no data.
>>>>> I have attached another version of mine, in which the trend line is 
>>>>> disabled by default, but I suspect that would just delay the inevitable 
>>>>> and 
>>>>> it would crash trying to do the plot.
>>>>>
>>>>> I also fixed up a few plotting errors in my code to do with the 
>>>>> mysteries (to me) of layer ordering.
>>>>> I also had a bac

Re: [weewx-user] When did the blast wave of the eruption "hit" your station? - extract your data

and add a debug printout for how many result lines there are after ...
result = cursor.fetchall()
add the line:

*print( "query returned {} data points".format(len(result)))*

On Friday, 21 January 2022 at 12:21:59 pm UTC+10 Cameron D wrote:

> To eliminate NULL data points use a query like:
> select datetime, barometer from archive where datetime > 1642172400 and 
> datetime < 1642693629* and barometer is not null *order by dateTime;
>  You could add the part in bold into the query in the python script.
>
> Of course, if they are all null...
>
> On Friday, 21 January 2022 at 12:14:44 pm UTC+10 storm...@gmail.com wrote:
>
>> Download the latest script from 
>> https://github.com/morrowwm/weewx_tonga_browse. Beside installing the 
>> Python Modules Vince stated above, I needed to also install  
>> python3-scipy. I do have data between 1642172400 and 1642693629; except 
>> for a couple "null" in that time period.   So when I run the script, I get 
>> the following error.
>>
>> raspberrypi:~/Desktop/Tonga $ python3 tonga_barometer.py
>> distance to eruption 13293.9 km arrival at 1642261629 (2022-01-15 
>> 10:47:08)
>> select datetime, barometer from archive where datetime > 1642172400 and 
>> datetime < 1642693629 order by dateTime;
>> Traceback (most recent call last):
>>   File "tonga_barometer.py", line 47, in 
>> coeff = np.polyfit(xdata, ydata, 2)
>>   File "/usr/lib/python3/dist-packages/numpy/lib/polynomial.py", line 
>> 590, in polyfit
>> y = NX.asarray(y) + 0.0
>> TypeError: unsupported operand type(s) for +: 'NoneType' and 'float'
>>
>> There should be a way to check for "null" data within the time period.
>> On Thursday, January 20, 2022 at 8:12:55 PM UTC-5 Cameron D wrote:
>>
>>> yes, definitely looks like there is no data.
>>> I have attached another version of mine, in which the trend line is 
>>> disabled by default, but I suspect that would just delay the inevitable and 
>>> it would crash trying to do the plot.
>>>
>>> I also fixed up a few plotting errors in my code to do with the 
>>> mysteries (to me) of layer ordering.
>>> I also had a background bar showing either side of expected arrival - in 
>>> this version I have now changed that to start at the expected arrival and 
>>> stop 1 hour later.
>>>
>>> On Friday, 21 January 2022 at 3:29:36 am UTC+10 bgra...@umw.edu wrote:
>>>
>>>> Hello,
>>>> Not being a programmer, I probably shouldn't have messed with this, but 
>>>> being curious...
>>>>
>>>> I tried the code posted on github as well as the one by Cameron D. In 
>>>> both cases I got the following error:
>>>> ```
>>>> root@n4mrv:/home/bg/weewx_tonga_browse-main# python3 ./tonga.py   [file 
>>>> from Cameron D]
>>>>
>>>> distance to eruption 12056.6 km arrival at 1642258360 (2022-01-15 
>>>> 09:52:39)
>>>>   opposite pulse arrival at 1642308921 (2022-01-15 23:55:21)
>>>>   second time around pulse arrival at 1642385471 (2022-01-16 
>>>> 21:11:10)
>>>> Traceback (most recent call last):
>>>>   File "./tonga.py", line 178, in 
>>>> plot_burst( cursor, arrival_time, hour_span, "primary" )
>>>>   File "./tonga.py", line 54, in plot_burst
>>>> coeff = np.polyfit(xdata, ydata, background_order )
>>>>   File "<__array_function__ internals>", line 180, in polyfit
>>>>   File 
>>>> "/usr/local/lib/python3.8/dist-packages/numpy/lib/polynomial.py", line 
>>>> 638, 
>>>> in polyfit
>>>> raise TypeError("expected non-empty vector for x")
>>>> TypeError: expected non-empty vector for x
>>>> ```
>>>> I added my lat/lon information but may have missed something else I 
>>>> need to change. Python modules were installed as directed. Copy of 
>>>> weewx.sdb is in the same directory as the program.
>>>> Thanks.
>>>> Bob
>>>> On Wednesday, January 19, 2022 at 10:32:49 AM UTC-5 morr...@gmail.com 
>>>> wrote:
>>>>
>>>>> On Wednesday, January 19, 2022 at 12:42:04 a.m. UTC-4 Cameron D wrote:
>>>>>
>>>>>>
>>>>>>- as you get closer to the equator, tidal changes dominate the 
>>>>>>baseline in that timescale - I tried higher order polynomials, but 
>>>>>> they are 
>>>>>>next to useless.
>>>>>>
>>>>>> I also had little luck with higher order polynomials to remove the 
>>>>> general trend.
>>>>>
>>>>> I've put the script here: 
>>>>> https://github.com/morrowwm/weewx_tonga_browse
>>>>>
>>>>

-- 
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/29f6da88-32e8-488c-ba98-348ca63c893cn%40googlegroups.com.

Re: [weewx-user] When did the blast wave of the eruption "hit" your station? - extract your data

To eliminate NULL data points use a query like:
select datetime, barometer from archive where datetime > 1642172400 and 
datetime < 1642693629* and barometer is not null *order by dateTime;
 You could add the part in bold into the query in the python script.

Of course, if they are all null...

On Friday, 21 January 2022 at 12:14:44 pm UTC+10 storm...@gmail.com wrote:

> Download the latest script from 
> https://github.com/morrowwm/weewx_tonga_browse. Beside installing the 
> Python Modules Vince stated above, I needed to also install  
> python3-scipy. I do have data between 1642172400 and 1642693629; except 
> for a couple "null" in that time period.   So when I run the script, I get 
> the following error.
>
> raspberrypi:~/Desktop/Tonga $ python3 tonga_barometer.py
> distance to eruption 13293.9 km arrival at 1642261629 (2022-01-15 10:47:08)
> select datetime, barometer from archive where datetime > 1642172400 and 
> datetime < 1642693629 order by dateTime;
> Traceback (most recent call last):
>   File "tonga_barometer.py", line 47, in 
> coeff = np.polyfit(xdata, ydata, 2)
>   File "/usr/lib/python3/dist-packages/numpy/lib/polynomial.py", line 590, 
> in polyfit
> y = NX.asarray(y) + 0.0
> TypeError: unsupported operand type(s) for +: 'NoneType' and 'float'
>
> There should be a way to check for "null" data within the time period.
> On Thursday, January 20, 2022 at 8:12:55 PM UTC-5 Cameron D wrote:
>
>> yes, definitely looks like there is no data.
>> I have attached another version of mine, in which the trend line is 
>> disabled by default, but I suspect that would just delay the inevitable and 
>> it would crash trying to do the plot.
>>
>> I also fixed up a few plotting errors in my code to do with the mysteries 
>> (to me) of layer ordering.
>> I also had a background bar showing either side of expected arrival - in 
>> this version I have now changed that to start at the expected arrival and 
>> stop 1 hour later.
>>
>> On Friday, 21 January 2022 at 3:29:36 am UTC+10 bgra...@umw.edu wrote:
>>
>>> Hello,
>>> Not being a programmer, I probably shouldn't have messed with this, but 
>>> being curious...
>>>
>>> I tried the code posted on github as well as the one by Cameron D. In 
>>> both cases I got the following error:
>>> ```
>>> root@n4mrv:/home/bg/weewx_tonga_browse-main# python3 ./tonga.py   [file 
>>> from Cameron D]
>>>
>>> distance to eruption 12056.6 km arrival at 1642258360 (2022-01-15 
>>> 09:52:39)
>>>   opposite pulse arrival at 1642308921 (2022-01-15 23:55:21)
>>>   second time around pulse arrival at 1642385471 (2022-01-16 
>>> 21:11:10)
>>> Traceback (most recent call last):
>>>   File "./tonga.py", line 178, in 
>>> plot_burst( cursor, arrival_time, hour_span, "primary" )
>>>   File "./tonga.py", line 54, in plot_burst
>>> coeff = np.polyfit(xdata, ydata, background_order )
>>>   File "<__array_function__ internals>", line 180, in polyfit
>>>   File "/usr/local/lib/python3.8/dist-packages/numpy/lib/polynomial.py", 
>>> line 638, in polyfit
>>> raise TypeError("expected non-empty vector for x")
>>> TypeError: expected non-empty vector for x
>>> ```
>>> I added my lat/lon information but may have missed something else I need 
>>> to change. Python modules were installed as directed. Copy of weewx.sdb is 
>>> in the same directory as the program.
>>> Thanks.
>>> Bob
>>> On Wednesday, January 19, 2022 at 10:32:49 AM UTC-5 morr...@gmail.com 
>>> wrote:
>>>
>>>> On Wednesday, January 19, 2022 at 12:42:04 a.m. UTC-4 Cameron D wrote:
>>>>
>>>>>
>>>>>- as you get closer to the equator, tidal changes dominate the 
>>>>>baseline in that timescale - I tried higher order polynomials, but 
>>>>> they are 
>>>>>next to useless.
>>>>>
>>>>> I also had little luck with higher order polynomials to remove the 
>>>> general trend.
>>>>
>>>> I've put the script here: 
>>>> https://github.com/morrowwm/weewx_tonga_browse
>>>>
>>>

-- 
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/b6f1a858-e46f-4cf0-9b43-e09b1c7a3e98n%40googlegroups.com.

Re: [weewx-user] When did the blast wave of the eruption "hit" your station? - extract your data

yes, definitely looks like there is no data.
I have attached another version of mine, in which the trend line is 
disabled by default, but I suspect that would just delay the inevitable and 
it would crash trying to do the plot.

I also fixed up a few plotting errors in my code to do with the mysteries 
(to me) of layer ordering.
I also had a background bar showing either side of expected arrival - in 
this version I have now changed that to start at the expected arrival and 
stop 1 hour later.

On Friday, 21 January 2022 at 3:29:36 am UTC+10 bgra...@umw.edu wrote:

> Hello,
> Not being a programmer, I probably shouldn't have messed with this, but 
> being curious...
>
> I tried the code posted on github as well as the one by Cameron D. In both 
> cases I got the following error:
> ```
> root@n4mrv:/home/bg/weewx_tonga_browse-main# python3 ./tonga.py   [file 
> from Cameron D]
>
> distance to eruption 12056.6 km arrival at 1642258360 (2022-01-15 09:52:39)
>   opposite pulse arrival at 1642308921 (2022-01-15 23:55:21)
>   second time around pulse arrival at 1642385471 (2022-01-16 21:11:10)
> Traceback (most recent call last):
>   File "./tonga.py", line 178, in 
> plot_burst( cursor, arrival_time, hour_span, "primary" )
>   File "./tonga.py", line 54, in plot_burst
> coeff = np.polyfit(xdata, ydata, background_order )
>   File "<__array_function__ internals>", line 180, in polyfit
>   File "/usr/local/lib/python3.8/dist-packages/numpy/lib/polynomial.py", 
> line 638, in polyfit
> raise TypeError("expected non-empty vector for x")
> TypeError: expected non-empty vector for x
> ```
> I added my lat/lon information but may have missed something else I need 
> to change. Python modules were installed as directed. Copy of weewx.sdb is 
> in the same directory as the program.
> Thanks.
> Bob
> On Wednesday, January 19, 2022 at 10:32:49 AM UTC-5 morr...@gmail.com 
> wrote:
>
>> On Wednesday, January 19, 2022 at 12:42:04 a.m. UTC-4 Cameron D wrote:
>>
>>>
>>>- as you get closer to the equator, tidal changes dominate the 
>>>baseline in that timescale - I tried higher order polynomials, but they 
>>> are 
>>>next to useless.
>>>
>>> I also had little luck with higher order polynomials to remove the 
>> general trend.
>>
>> I've put the script here: https://github.com/morrowwm/weewx_tonga_browse
>>
>

-- 
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/71655988-a5d6-4771-bb56-12fa455f24f2n%40googlegroups.com.
import time
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.dates as mdates
from geopy import distance

#DB="sqlite3"
DB="mysql"
if DB == "sqlite3":
import sqlite3
else:
import sys
import mysql.connector as MysqlConnector
from mysql.connector import errorcode as msqlerrcode
db_user="weewx"
db_pwd="insert-your-password"
db_name="weewx"

# change as needed - (latitude, longitude)
home = (44.8032, -63.6204)


# some barometers only change their reading every nth record in the database
# set oversampling = 1 if the barometer can change every archive record.
# set oversampling = 2 if the barometer updates every 10 minutes but you have a 5 minute sample period
oversampling = 1

# this will remove background if you have a smoothly varying long-term barometer trend
plot_trends=False
# order of polynomial fitted to background
background_order = 2

# you should not need to edit anything below here
# ===

def plot_burst( cursor, pulse_time, span, order ):
start_time = 3600*(pulse_time // 3600 - span)  # start at an even hour
xmax_hours = pulse_time + span*3600 
query = "select datetime, barometer from archive where datetime > %.0f and datetime < %.0f order by dateTime;" %\
( start_time, xmax_hours )
cursor.execute(query)

result = cursor.fetchall()

xdata = []
ydata = []
tdata = []

rowcount = 0
for row in result:
rowcount += 1
if rowcount % oversampling == 0:
xdata.append(row[0])
tdata.append(mdates.datestr2num(time.strftime("%Y-%m-%d %H:%M:%S", time.localtime(row[0]
ydata.append(row[1])
   
peakt = [mdates.datestr2num(time.strftime("%Y-%m-%d %H:%M:%S", time.localtime( pulse_time+ 1800 )))]
plotx_range = (
mdates.datestr2num(time.strftime(&

Re: [weewx-user] When did the blast wave of the eruption "hit" your station? - extract your data

2022-01-18 Thread 'Cameron D' via weewx-user

Thanks for that obsession. I was wondering how to start learning about 
plotting in python.  I've not got very far.
What I have done in the attached version is:

   - add option towork with mysql db
   - plot first 3 pulse times.
   - added a background grey bar for 3 min either side of hte expected time.
   - also a wide-scale plot covering them all.
   - as you get closer to the equator, tidal changes dominate the baseline 
   in that timescale - I tried higher order polynomials, but they are next to 
   useless.

This version generates 4 png files.[image: Hunga_Tonga_return.png]
I was even able to see a small dip at the expected time it was making its 
second pass around (as seen in the image). The dip far left is the opposite 
direction pulse.
On Wednesday, 19 January 2022 at 3:40:46 am UTC+10 morr...@gmail.com wrote:

> I may be starting to obsess a bit, but give the attached python script a 
> try. You may have to install additional modules, e.g. geopy and sqlite3.
>
> 1. On line 9, specify your location
> 2. On line 14, specify the range of hours you want to examine, around the 
> event.
> 3. On line 25, you may need to adjust the query if your pressure data is 
> not in the barometer column of the archive table
> 3. Move to the directory containing your weewx.sdb database, or on line 
> 22, specify its full path.
> 4. Run the script
>
> The script calculates the distance from the eruption to your location, the 
> travel time to your location at the speed of sound, and then queries and 
> plots, and saves the barometer data for a time range around the estimated 
> arrival time. It also remove any linear trend and plots the difference from 
> that linear trend. 
>
> Follow up with any improvements!
>
> Mine looks like this:
> [image: hunga_tonga.png]
>

-- 
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/a6ffa761-afcb-4d12-be4d-776a91d2788fn%40googlegroups.com.
import time
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.dates as mdates
from geopy import distance

#DB="sqlite3"
DB="mysql"
if DB == "sqlite3":
import sqlite3
else:
import sys
import mysql.connector
from mysql.connector import errorcode as msqlerrcode
db_user="weewx"
db_pwd="insert-your-password"
db_name="weewx"

# change as needed
home = (44.8032, -63.62038)

# some barometers only change their reading every nth record in the database
# set oversampling = 1 if the barometer can change every archive record.
# set oversampling = 2 if the barometer updates every 10 minutes but you have a 5 minute sample period
oversampling = 1

# order of polynomial fitted to background
background_order = 2

# you should not need to edit anything below here
# ===

def plot_burst( cursor, pulse_time, span, order ):
query = "select datetime, barometer from archive where datetime > %.0f and datetime < %.0f order by dateTime;" %\
( pulse_time - span*3600, pulse_time + span*3600)
cursor.execute(query)

result = cursor.fetchall()

xdata = []
ydata = []
tdata = []

rowcount = 0
for row in result:
rowcount += 1
if rowcount % oversampling == 0:
xdata.append(row[0])
tdata.append(mdates.datestr2num(time.strftime("%Y-%m-%d %H:%M:%S", time.localtime(row[0]
ydata.append(row[1])
   
peakt = [mdates.datestr2num(time.strftime("%Y-%m-%d %H:%M:%S", time.localtime( pulse_time )))]
# remove any linear trend
coeff = np.polyfit(xdata, ydata, background_order )
trend = np.polyval(coeff, xdata)

fig, ax = plt.subplots()

date_formatter = mdates.DateFormatter('%m-%d %H:%M')
ax.tick_params(axis="x", rotation=90)
ax.xaxis.set_major_formatter(date_formatter)

fig.subplots_adjust(bottom=0.2)

ax2 = ax.twinx()
ax2.set_axis_off()
ax2.bar( peakt, [1] , width=0.25/span, color="lightgrey" )  

ax.plot(tdata, ydata, color="paleturquoise", linewidth=3)

ax2=ax.twinx()
ax2.plot(tdata, ydata - trend, marker="+", linewidth=1)

#plt.show()
# save the plot as a file
filename = "./Hunga_Tonga_" + order + ".png"
fig.savefig( filename, format='png', dpi=100, bbox_inches='tight')

#plt.show()


def plot_all( cursor, e_time, pulse_time1, pulse_time2, pulse_time3, span ):
query = "select datetime, barometer from archive where datetime > %.0f and datetime < %.0f order by dateTime;" %\
( e_time - span*3600, pulse_time3 + span*3600)
cursor.execute(query)

result = cursor.fetchall()

xdata = []
ydata = []
tdata = []

rowcount = 0
for row in result:
rowcount += 1
if rowcount % oversampling == 0:

[weewx-user] Re: safety of wind instruments on metal pole on roof?

2022-01-18 Thread 'Cameron D' via weewx-user

I decided to use PVC pipe, about 50mm dia. extending 2.5m above the roof 
line. Lighter to handle and not too flexible.
The cable is easily run down the middle, to the wireless transmitter, which 
is mounted on a wooden pole.

I don't know if it would make much difference in enticing lightning to 
strike, but as Karen said once the ionized path is created no vapourization 
of the wire is going to stop it.  Neighbours of my mother had a bit of 
electronic kit attached to their back wall with a small wire running 
upwards - I forget the details. The wire vapourized all right, but not 
without scattering bits of circuit board and components all over their yard.
Luckily, no fire resulted.  There are plenty of high gum trees nearby, and 
TV aerials with metal masts protruding from the roof.

On Tuesday, 18 January 2022 at 6:03:47 am UTC+10 morr...@gmail.com wrote:

> Not strictly weewx related, but:
>
> Any safety concerns with mounting my wind speed and direction instruments 
> on a 1.25" galvanized steel pole, 6 feet above the roof line? 
>
> I currently have a prototype anemometer about 20 feet in the air. It's 
> well away from our house so solar powered, which is proving a challenge.
>
> We get a bit of lightning here, but there are tall trees near our house, 
> and I've never heard of a direct hit in the neighborhood.
>
> Thanks for any experience/anecdotes.
>

-- 
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/40f6017c-adc9-4915-84ce-62262c9b1d8an%40googlegroups.com.

Re: [weewx-user] Re: When did the blast wave of the eruption "hit" your station?

2022-01-16 Thread 'Cameron D' via weewx-user

I did the same, since by the time I looked it had disappeared from the 
daily plot.
I am 3300km from the volcano (East coast Australia).
Unfortunately my station only updates the barometer value every 15 minutes, 
so there is only a single point at the "peak", a value back around average, 
then the next reading is the negative pulse.
[image: Hunga-Tonga-volcano-barometer-trace.png]
I've plotted about a week, to get an idea how much noise there usually is 
in the data. The first red arrow is the primary pulse and the second wave, 
a bit less than 30 hours later.
I wondered whether the stuff indicated by the green arrow was more 
eruptions, but then realised it was a band of thunderstorms passing over..

I also looked at barometer plots from the Australian weather Bureau and did 
a crude plot of timing vs distance. From Norfolk Island to Perth gives us a 
range from 2000 and 7000 km from the volcano...

[image: Hunga-Tonga-volcano-timing.png]
Those results are only reported every 30 minutes, so the error bars would 
be rather big.
On Monday, 17 January 2022 at 1:51:43 pm UTC+10 ln77 wrote:

> I had to pull the data out of the database and plot it in a spreadsheet. 
> Taking a second look, I found the long-path pulse also. The second trip 
> around should be about 32-36 hours later; I haven’t looked for that yet. 
>
> -Les
>
>

-- 
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/347e66cc-b6a5-4449-a26a-19405f92446cn%40googlegroups.com.

Re: [weewx-user] Re: Slow Response Time

2021-12-15 Thread 'Cameron D' via weewx-user

Take Vince's advice.  Many routers just cannot do this.  I must admit I am 
baffled by the very long time - it should be fast or not at all.

In addition, you are mixing IPv4 and IPv6 in your tests, but the ddns.net 
service returns IPv4 only.  Your weewx system is accessible from the 
outside world using IPv4, but not if I use either IPv6 address you showed, 
so I suspect you need changed firewall rules for that.
If you had a full IPv6 pathway then it does not need NAT and should work 
from anywhere.

On Thursday, 16 December 2021 at 7:13:28 am UTC+10 vince wrote:

> You're killing yourself here on something that seems like a nice-to-have 
> and not a need-to-have. At some point the time-value of your labor and 
> blood pressure exceeds the nice-to-have for stuff like this.
>
> Is there a reason you can't just save a bookmark with the ip address of 
> weewx on your LAN and use 'that' when you are on your LAN ?
>
> Internet=>LAN works, which is the hard part.  Take the 95% win perhaps ?
>
>

-- 
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/0ff8d834-f112-4636-b762-4811740bcf97n%40googlegroups.com.

[weewx-user] Re: Run weewx as just a collector, run the reports on a different server (mysql database backend)

2021-10-04 Thread 'Cameron D' via weewx-user

I had something like this for a while - but not exactly the same.
The VM with the wamp server did not have USB device access, so my solution 
was
1. weewx collects on one machine
2. writes to DB on the VM
3. weewx on the original machine generates reports by writing to a shared 
network drive that the apache server can see.
4. view reports by accessing the web server on the VM.

The only slightly tricky bit is getting the permissions right.

On Monday, 4 October 2021 at 6:45:55 am UTC+10 ad5...@gmail.com wrote:

> Hi All,
>
> I have weewx setup and working perfectly on my raspberrypi, but I wish to 
> change it so that it just runs as a collector.
> I'm writing to a mysql database on a VM on my NAS.
> I don't want it to generate any files or reports etc on the raspberrypi.
>
> I would like to then run weewx on another server to generate the reports. 
> Is this possible?
>
> Cheers
> Ad

-- 
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/32fe9703-b25c-4680-b74b-31ac11f8d862n%40googlegroups.com.

[weewx-user] Re: Trouble getting GW1000 driver to work

2021-09-25 Thread 'Cameron D' via weewx-user

I am pretty sure the semicolon is *not *what you want with Bourne shell 
syntax.

   1. with no semicolon, the variable is placed in the environment of the 
   program being executed
   2. with a semicolon, it is a simple assignment to a variable in the 
   environment of the current shell and is *not *passed onto the program 
   being executed

I tend to make things clearer by assigning/exporting it to the environment 
on a line on its own, then run the command and then, if necessary, remove 
it if it is going to interfere with subsequent commands.

On Saturday, 25 September 2021 at 4:39:38 am UTC+10 matthew wall wrote:

> actually, i get the same behavior with either bash or ksh, at least on an 
> old macos system (10.14.6) - the semicolon is necessary.  same thing on a 
> modern debian system.
>
> so i guess the semicolon is necessary!  all the many times i have done 
> that before i must have been in the PYTHONPATH directory, or in a directory 
> that weewx resolves in its sys/os path magic at the beginning of each entry 
> point.
>

-- 
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/8847ad7a-d203-496b-9865-78332a12f395n%40googlegroups.com.

[weewx-user] Re: How are these readings possible?

2021-05-31 Thread 'Cameron D' via weewx-user

yet another possibility is hardware issues.  I recently had sudden spikes 
to 65°C, but they were more obviously a hardware fault as they were 
followed by a few minutes of null data.
Suspects might be developing corrosion in contacts, or creatures traversing 
the circuit boards.

How frequently is this happening to you?

On Monday, 31 May 2021 at 7:42:47 pm UTC+10 enu...@gmail.com wrote:

>
> If I understand well how weewx works on my station, every 48s a loop 
> packet arrives and I suppose that by making an average of those loop 
> packets every 5 minutes it writes to the database.
> How can I have a temperature graph at 20ºC and suddenly find peaks at 43º? 
> That would imply that 6 packets have arrived with data very out of the 
> correct which seems very unlikely, perhaps one for any reason that alters 
> the average somewhat and that I suppose can be filtered with StdQC but how 
> can  be saved in the database a temperature of 43 ° C in 5 minutes.
> What is the explanation?
>

-- 
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/27123113-a4d9-4d2c-9a74-4e8455a3288en%40googlegroups.com.

Re: [weewx-user] Re: Aussearch error accessing the BOM

2021-05-30 Thread 'Cameron D' via weewx-user

Yes, I "entered into the conversation" a couple of weeks ago.  So far it's 
been very one-sided.
The impression I got from the introductory pages was that they are only 
interested in commercial opportunities.

On Sunday, 30 May 2021 at 9:13:37 am UTC+10 Darryn Capes-Davis wrote:

> Great. Good to see everyone working again. Hopefully we are in the clear 
> for a while to come. I did enter into the form BOM points you towards and 
> have started a conversation as to why assets that are available via a 
> browser and not available to well behaved scripts, and what is the 
> legislative restriction that they are following. Nothing back yet.
>
> Get Outlook for iOS 
> --
> *From:* weewx...@googlegroups.com  on behalf 
> of Neville Davis 
> *Sent:* Sunday, May 30, 2021 9:00:13 AM
> *To:* weewx-user 
> *Subject:* Re: [weewx-user] Re: Aussearch error accessing the BOM 
>  
> Had deleted files, now have restarted json files now generated. 
>
> [image: Screen Shot 2021-05-30 at 8.56.16 am.png]
>
> Thanks Darryn
>
> On Sunday, May 30, 2021 at 8:46:59 AM UTC+10 Darryn Capes-Davis wrote:
>
> Hi Neville,
>
> You may need to empty files in /var/lib/weewx/aussearch. Also make sure 
> you have restarted weewx. 
>
> Cheers
>
> Darryn
>
> --
> *From:* weewx...@googlegroups.com  on behalf 
> of Neville Davis 
> *Sent:* Sunday, May 30, 2021 8:43:18 AM
> *To:* weewx-user 
> *Subject:* [weewx-user] Re: Aussearch error accessing the BOM 
>  
> Darryn 
>
> new aussearch.py installed (large no of changes since my feb install 
> compared with BBedit) 
> Still not working...the json files are not being generated, the xml files 
> are OKin /var/lib/weewx/aussearch.
>
> logs show
>
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: Caught 
> unrecoverable exception in generator 
> 'weewx.cheetahgenerator.CheetahGenerator'
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
>   maximum recursion depth exceeded
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
>   Traceback (most recent call last):
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
> File "/home/weewx/bin/weewx/reportengine.py", line 196, in run
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
>   obj.start()
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
> File "/home/weewx/bin/weewx/reportengine.py", line 281, in start
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
>   self.run()
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
> File "/home/weewx/bin/weewx/cheetahgenerator.py", line 149, in run
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
>   self.initExtensions(gen_dict[section_name])
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
> File "/home/weewx/bin/weewx/cheetahgenerator.py", line 193, in 
> initExtensions
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
>   self.search_list_objs.append(class_(self))
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
> File "/home/weewx/bin/user/aussearch.py", line 213, in __init__
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
>   self.refresh_time = 
> float(self.generator.skin_dict['AusSearch']['refresh_time'])
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
> File "/home/weewx/bin/user/aussearch.py", line 535, in __init__
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
>   (self.local_file_path, check_datetime))
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
> File "/home/weewx/bin/user/aussearch.py", line 548, in __getattr__
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
>   syslog.syslog(syslog.LOG_DEBUG, "aussearch: json file does not 
> exist: %s" %
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
> File "/home/weewx/bin/user/aussearch.py", line 548, in __getattr__
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
>   syslog.syslog(syslog.LOG_DEBUG, "aussearch: json file does not 
> exist: %s" %
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
> File "/home/weewx/bin/user/aussearch.py", line 548, in __getattr__
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
>   syslog.syslog(syslog.LOG_DEBUG, "aussearch: json file does not 
> exist: %s" %
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine: 
> [Previous line repeated 491 more times]
> May 30 08:30:24 raspberrypi weewx[700] ERROR weewx.reportengine:

[weewx-user] Re: Weewx and wmr300 no rain accumulation

2021-04-14 Thread 'Cameron D' via weewx-user

Looks like it discarded my post - apologies if this gets duplicated.

Of course, stop weewx while doing the reset.

In case you can't find the manual, the reset process is:
press the "rain" area on the console 2 or 3 times until it shows 
"accumulated" rainfall.  The date area will show you when the counter was 
started.
At this stage there will be a "mem" button on the bottom row.  Press and 
hold that until the accumulated rainfall shows zero.

restart weewx, and the log should now tell you  " possible missed rain 
event: new=0.0 old=None".

I just did this myself as an experiment.

On Thursday, 15 April 2021 at 9:57:14 am UTC+10 Cameron D wrote:

> Hi Paul,
> that line is red is the clue - the only rain value logged by the device is 
> the accumulated measurement.
> The counter has an internal limit that you have reached (10 metres), which 
> Oregon in their wisdom decided would be enough for anybody.
>
> We know of no software method to reset the value, so you need to consult 
> the manual to use the touchpad on the console to reset the counter. 
>
> On Wednesday, 14 April 2021 at 5:23:36 pm UTC+10 paul.l...@gmail.com 
> wrote:
>
>> Hi all, 
>>
>> I am using for some time weewx  on my wmr300 Oregon scientific meteo 
>> station . I am on all updates running weewx 4.5.1 and Belchertown skin.
>>
>> From some time my rain rate is indicating :
>>
>> Wind 0.7 m/s from 59° (ENE) 
>> Rain Rate 1.5 mm/h 
>> Inside Temperature 24.3°C 
>>
>> but on accumulated values is only showing zero 
>>
>> Today's Rain 0.0 mm 
>> High Rain Rate 3.3 mm/h at 08:45:00 
>> High Wind 2.1 m/s from 87° at 03:30:00 
>>
>> in the logs I found an indication 
>>
>> INFO weewx.engine: Starting main packet loop.
>> Apr 14 10:04:23 meteopi weewx[719] INFO weewx.drivers.wmr300: possible 
>> missed rain event: new=10160.0 old=None
>> Apr 14 10:04:23 meteopi weewx[719] INFO weewx.drivers.wmr300: rain 
>> counter at maximum, reset required
>> Apr 14 10:04:43 meteopi weewx[719] INFO weewx.drivers.wmr300: history 
>> buffer at 6.32% (2100)
>>
>> How can I solve the problem ?
>>
>> Paul 
>>
>>
>>
>>

-- 
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/9f2f2961-9328-477e-a25f-18d662462329n%40googlegroups.com.

[weewx-user] Re: Weewx and wmr300 no rain accumulation

2021-04-14 Thread 'Cameron D' via weewx-user

Hi Paul,
that line is red is the clue - the only rain value logged by the device is 
the accumulated measurement.
The counter has an internal limit that you have reached (10 metres), which 
Oregon in their wisdom decided would be enough for anybody.

We know of no software method to reset the value, so you need to consult 
the manual to use the touchpad on the console to reset the counter. 

On Wednesday, 14 April 2021 at 5:23:36 pm UTC+10 paul.l...@gmail.com wrote:

> Hi all, 
>
> I am using for some time weewx  on my wmr300 Oregon scientific meteo 
> station . I am on all updates running weewx 4.5.1 and Belchertown skin.
>
> From some time my rain rate is indicating :
>
> Wind 0.7 m/s from 59° (ENE) 
> Rain Rate 1.5 mm/h 
> Inside Temperature 24.3°C 
>
> but on accumulated values is only showing zero 
>
> Today's Rain 0.0 mm 
> High Rain Rate 3.3 mm/h at 08:45:00 
> High Wind 2.1 m/s from 87° at 03:30:00 
>
> in the logs I found an indication 
>
> INFO weewx.engine: Starting main packet loop.
> Apr 14 10:04:23 meteopi weewx[719] INFO weewx.drivers.wmr300: possible 
> missed rain event: new=10160.0 old=None
> Apr 14 10:04:23 meteopi weewx[719] INFO weewx.drivers.wmr300: rain 
> counter at maximum, reset required
> Apr 14 10:04:43 meteopi weewx[719] INFO weewx.drivers.wmr300: history 
> buffer at 6.32% (2100)
>
> How can I solve the problem ?
>
> Paul 
>
>
>
>

-- 
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/be0f1271-aebf-4df8-b994-0d04b8bf2f3bn%40googlegroups.com.

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

2021-04-05 Thread 'Cameron D' via weewx-user

Yes - I think the issue is only with the update process and there are just 
too many potential situations for the update script to be comprehensive.
I would suggest you replace the old file before the next update.  I have 
previously shot myself in the foot by "cleaning up" after an installation - 
things I learned to do with rpm installs don't work with .debs.

On Tuesday, 6 April 2021 at 10:56:43 am UTC+10 PJO wrote:

> Well, in principle one *should *be able to delete an old init.d file; my 
> understanding is that your original advice was correct. The problem appears 
> to have been an assumption that the init.d file would still be in place and 
> available for use by the update procedure. I can restore it if necessary 
> before the next update.
> On Tuesday, April 6, 2021 at 1:31:49 AM UTC+1 Cameron D wrote:
>
>> Hi PJO,
>> I have changed the "advice" in the wiki relating to custom systemd unit 
>> files and init.d files. Sorry.  I can't recall the situation that led to 
>> that advice, but once the custom unit file is working properly then the 
>> init.d file is simply ignored.
>>
>> On Sunday, 4 April 2021 at 10:57:35 pm UTC+10 PJO wrote:
>>
>>> Yes, you're right I removed /etc/init.d/weewx -- when I switched to 
>>> using systemd ; I didn't realize this would still be needed. In fact, I 
>>> followed advice here <https://github.com/weewx/weewx/wiki/systemd> that 
>>> leaving this in place was not a good idea.
>>>  
>>> Attached are copies of the original and bad weewx.conf files and a file 
>>> listing (from which I've deleted git related things to do with the skin 
>>> I've been working on).
>>>
>>> I didn't mention it earlier because I hadn't realized it yet, but fyi 
>>> other problems I encountered were
>>>
>>> 1. issues with my copy of sensors.inc from the Seasons skin (see issue 
>>> <https://github.com/gjr80/weewx-gw1000/issues/35>)
>>> 2. as result of my not checking things properly before restarting I 
>>> ended up with some bad records until I reverted to the original weewx.conf 
>>> file because of a changed schema
>>>
>>> Lessons learned: switch to Seasons before running the update if using 
>>> sensors.inc; verify weewx.conf changes properly (first time I've had an 
>>> issue).
>>>
>>> On Sunday, April 4, 2021 at 1:25:50 PM UTC+1 t...@tom.org wrote:
>>>
>>>> Interesting that Belchertown 1.2 is working for you. Everything works 
>>>> great on 4.4.0 but reporting (downloading the Aeris forecast) fails on 
>>>> 4.5.1. I filed a bug in the Belchertown GitHub repo.
>>>>
>>>> On Saturday, April 3, 2021 at 11:44:31 PM UTC-4 nevilled...@gmail.com 
>>>> wrote:
>>>>
>>>>> Hi
>>>>> Just updated my system to 4.5.1 without problems.
>>>>> For information also running Belchertown skin v 1.2 python 3 with OWFS 
>>>>> rain bucket.. all good
>>>>>
>>>>> Neville
>>>>>
>>>>> On Sunday, April 4, 2021 at 12:19:58 PM UTC+10 mksm...@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> I am sure about this finding 
>>>>>> when using "sudo nano /etc/weewx/weewx.conf" the file shows 4.4.0
>>>>>> syslog shows "INFO __main__: Starting up weewx version 4.5.1"
>>>>>> web page also shows 4.5.1
>>>>>>
>>>>>> On Sunday, April 4, 2021 at 4:53:54 AM UTC+3 tke...@gmail.com wrote:
>>>>>>
>>>>>>> Hmmm, the upgrade process should have upgraded the version number in 
>>>>>>> weewx.conf. Are you sure you're looking at the right one? If you did a 
>>>>>>> Debian install it should be at /etc/weewx/weewx.conf.
>>>>>>>
>>>>>>> There were no changes to weewx.conf, so, if it comes to it, you can 
>>>>>>> just change the version number. But, it would be useful to know what 
>>>>>>> happened.
>>>>>>>
>>>>>>> On Sat, Apr 3, 2021 at 6:44 PM Mks Mk  wrote:
>>>>>>>
>>>>>>>> the update to 4.5.1 worked for me this time but have one issue that 
>>>>>>>> weewx.conf shows  version  4.4.0 but the generated web page shows 
>>>>>>>> WeeWX 
>>>>>>>> version 4.5.1
>>>>>>>> can I change weewx.conf line to 4.5.1 or keep it as is?
>>>>>&g

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

2021-04-05 Thread 'Cameron D' via weewx-user

Hi PJO,
I have changed the "advice" in the wiki relating to custom systemd unit 
files and init.d files. Sorry.  I can't recall the situation that led to 
that advice, but once the custom unit file is working properly then the 
init.d file is simply ignored.

On Sunday, 4 April 2021 at 10:57:35 pm UTC+10 PJO wrote:

> Yes, you're right I removed /etc/init.d/weewx -- when I switched to using 
> systemd ; I didn't realize this would still be needed. In fact, I followed 
> advice here  that leaving 
> this in place was not a good idea.
>  
> Attached are copies of the original and bad weewx.conf files and a file 
> listing (from which I've deleted git related things to do with the skin 
> I've been working on).
>
> I didn't mention it earlier because I hadn't realized it yet, but fyi 
> other problems I encountered were
>
> 1. issues with my copy of sensors.inc from the Seasons skin (see issue 
> )
> 2. as result of my not checking things properly before restarting I ended 
> up with some bad records until I reverted to the original weewx.conf file 
> because of a changed schema
>
> Lessons learned: switch to Seasons before running the update if using 
> sensors.inc; verify weewx.conf changes properly (first time I've had an 
> issue).
>
> On Sunday, April 4, 2021 at 1:25:50 PM UTC+1 t...@tom.org wrote:
>
>> Interesting that Belchertown 1.2 is working for you. Everything works 
>> great on 4.4.0 but reporting (downloading the Aeris forecast) fails on 
>> 4.5.1. I filed a bug in the Belchertown GitHub repo.
>>
>> On Saturday, April 3, 2021 at 11:44:31 PM UTC-4 nevilled...@gmail.com 
>> wrote:
>>
>>> Hi
>>> Just updated my system to 4.5.1 without problems.
>>> For information also running Belchertown skin v 1.2 python 3 with OWFS 
>>> rain bucket.. all good
>>>
>>> Neville
>>>
>>> On Sunday, April 4, 2021 at 12:19:58 PM UTC+10 mksm...@gmail.com wrote:
>>>
 I am sure about this finding 
 when using "sudo nano /etc/weewx/weewx.conf" the file shows 4.4.0
 syslog shows "INFO __main__: Starting up weewx version 4.5.1"
 web page also shows 4.5.1

 On Sunday, April 4, 2021 at 4:53:54 AM UTC+3 tke...@gmail.com wrote:

> Hmmm, the upgrade process should have upgraded the version number in 
> weewx.conf. Are you sure you're looking at the right one? If you did a 
> Debian install it should be at /etc/weewx/weewx.conf.
>
> There were no changes to weewx.conf, so, if it comes to it, you can 
> just change the version number. But, it would be useful to know what 
> happened.
>
> On Sat, Apr 3, 2021 at 6:44 PM Mks Mk  wrote:
>
>> the update to 4.5.1 worked for me this time but have one issue that 
>> weewx.conf shows  version  4.4.0 but the generated web page shows WeeWX 
>> version 4.5.1
>> can I change weewx.conf line to 4.5.1 or keep it as is?
>>
>> On Friday, April 2, 2021 at 11:32:40 PM UTC+3 tke...@gmail.com wrote:
>>
>>> Version 4.5.1 out.
>>>
>>> My apologies.
>>>
>>> On Fri, Apr 2, 2021 at 1:12 PM Tom Keffer  wrote:
>>>
 My mistake. I knew there was a reason why we didn't transition the 
 old wview schema to the new V4 style!

 I should have a dot-dot release out later today. 

 -tk

 On Fri, Apr 2, 2021 at 12:14 PM Mks Mk  wrote:

> the upgrade to 4.5 from 4.4 failed and weewx is broken please 
> advice
> used these commands for upgrade
> sudo apt update
> apt list --upgradable  (4.5 was showing)
> sudo apt full-upgrade
> then I answered "N" to the upgrade select to keep my old files
>
> Apr  2 21:31:49 raspberrypi systemd[1]: Starting LSB: weewx 
> weather system...
> Apr  2 21:31:49 raspberrypi weewx[1049]: Starting weewx weather 
> system: weewxTraceback (most recent call last):
> Apr  2 21:31:49 raspberrypi weewx[1049]:   File 
> "/usr/share/weewx/weewxd", line 29, in 
> Apr  2 21:31:49 raspberrypi weewx[1049]: import user.extensions
> Apr  2 21:31:49 raspberrypi weewx[1049]:   File 
> "/usr/share/weewx/user/extensions.py", line 20, in 
> Apr  2 21:31:49 raspberrypi weewx[1049]: schema_extended = 
> schemas.wview.schema + [('lightning_strikes', 'REAL'), 
> ('avg_distance', 
> 'REAL')]
> Apr  2 21:31:49 raspberrypi weewx[1049]: TypeError: unsupported 
> operand type(s) for +: 'dict' and 'list'
> Apr  2 21:31:49 raspberrypi weewx[1049]:  failed!
> Apr  2 21:31:49 raspberrypi systemd[1]: weewx.service: Control 
> process exited, code=exited, status=1/FAILURE
> Apr  2 21:31:49 raspberrypi systemd[1]: weewx.service: Failed with 
> result 'exit-code'.
> Apr  2 21:31:49 raspberrypi systemd[1]:

[weewx-user] minor bug in wind averaging and gusts - possibly only WMR300

2021-03-07 Thread 'Cameron D' via weewx-user

Weewx 4.4.0.
I noticed recently an incorrect assumption by the weewx code - if the 
archive value for wind gust is less than the "wind speed" value then it 
sets wind gust and gust direction to be equal to the wind speed.
This is incorrect behaviour, at least for the WMR300, because the reported 
wind speed is actually the 10-minute average, and *applies to the previous 
10-minute interval*, (since it can't predict the future). After the storm 
cell passes, for example, it is quite feasible for the current gust to the 
less than the "current" wind speed.  I noticed this while looking at my 92 
km/h max gust recently.

I don't know how many other weather stations this situation would apply to, 
so it might not be of much general relevance.

In separate news, I have realised the WMR300 console does a really poor job 
of calculating average wind speed, so I will try to modify the driver code 
to allow weewx to do the averaging.

-- 
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/7156aea8-dc1a-4d3c-8a0c-1d68ec9063b3n%40googlegroups.com.

Re: [weewx-user] Re: Solar Radiation > Theoretical Max

That is part of it, but some of the early morning examples are up to 500% 
different, although with very small values.  In those cases I still suspect 
there is extra scattered radiation from the surroundings, whether it be 
trees or buildings.
I wonder also if the sensor type may change results slightly.
There may also be a calibration error, due to the different spectral energy 
distribution comparing dawn and midday, or perhaps even simple nonlinearity 
near zero output. These are not research-grade instruments that most of us 
are using.
If you add all that in with ozone, water vapour and particulates of 
different sizes, all of which change seasonally and daily, you will never 
expect precise agreement.

Here's another example - I left the RS and Bras models with the same values 
as previous, and changed the BH model to ignore just ozone, water vapour 
and particulates.
That gave the solid line. Then I set albedo for the full snow cover and the 
result was  the dashed line.

So, the "theoretical curve" for around Boston is anywhere in that range of 
curves, or it could be even lower in moderately polluted skies.
On Wednesday, 23 December 2020 at 10:51:08 pm UTC+10 tke...@gmail.com wrote:

> Very useful, Cameron.
>
> It looks like the R-S curve is quite a bit lower, maybe as much as 20% 
> lower, at dawn and dusk, which seems to be when people are experiencing 
> values higher than maxSolarRad.
>
> On Wed, Dec 23, 2020 at 1:19 AM Cameron D  wrote:
>
>> And then I forgot the attachment!
>>
>>
>> On Wednesday, 23 December 2020 at 7:18:31 pm UTC+10 Cameron D wrote:
>>
>>> I should have looked a bit more closely before posting!  I used the 
>>> solrad excel code from Uni Washington.
>>> I had adjusted my B parameters to represent quite clean air but forgot 
>>> to match the Bras and RS code from default.
>>> If I:
>>>
>>>1. reset the BH turbidity params to default,
>>>2. adjust the Bras param down to 1.6 and
>>>3. adjust the RS param to 0.84,
>>>
>>>  then the curves are close to normalised at peak.  The RS curve is still 
>>> a somewhat poor representation at dawn and dusk, while Bras is probably 
>>> close enough to BH that it's not worth the extra effort.  
>>> The main advantage with B is the atmospheric moisture, which I think 
>>> contributes significantly, but differently from the atmospheric turbidity 
>>> parameters and changes the shape of the curve. So a single parameter cannot 
>>> account for all variables.
>>> The safest bet might be to adjust the parameter for clear skies and then 
>>> say that is an upper limit.
>>>
>>> On Wednesday, 23 December 2020 at 6:31:47 pm UTC+10 Cameron D wrote:
>>>
>>>> So the weewx python code says it is using the Ryan and 
>>>> Stolzenbach model, which has a few approximations that don't work well in 
>>>> some cases, and it looks like this is one of them.
>>>>
>>>> I've attached a plot comparing 3 insolation models predicting global 
>>>> horizontal irradiation.
>>>> Bird and Hulstrom 1991
>>>> Bras 1992
>>>> and  Ryan and Stolzenbach  1972
>>>>
>>>> B has a lot more parameters to account for, but I have just thrown in 
>>>> the date/location for Boston, using whatever parameters were in the 
>>>> spreadsheet, and come up with the following comparison.
>>>> I used the B predictions for modelling my solar PV system and found 
>>>> it gives very close results - or at least it did before my system got a 
>>>> bit 
>>>> older.  However R also gives results that aren't too bad in my location.
>>>>
>>>> I have the code in php, but no spare time at the moment to convert to 
>>>> python.
>>>>
>>>> On Tuesday, 22 December 2020 at 2:19:29 am UTC+10 t...@tom.org wrote:
>>>>
>>>>> kk, glad you corroborated my observations. I am no expert in this for 
>>>>> sure. I am just tired of all of the comments I get from visitors to the 
>>>>> website about how my readings exceed theoretical max. I could remove the 
>>>>> max, but that doesn't seem fun.
>>>>>
>>>>> I do not have the expertise to validate the way weewx calculates it 
>>>>> nor am I even competent in Python, but for those who may, here is a link 
>>>>> to 
>>>>> the code:
>>>>>
>>>>>
>>>>> https://github.com/weewx/weewx/blob/d91635f3bc429f906d1f084c6a6bc8ee09fa1a27/bin/weewx/wxformulas.py#L3

Re: [weewx-user] Re: Solar Radiation > Theoretical Max

And then I forgot the attachment!


On Wednesday, 23 December 2020 at 7:18:31 pm UTC+10 Cameron D wrote:

> I should have looked a bit more closely before posting!  I used the solrad 
> excel code from Uni Washington.
> I had adjusted my B parameters to represent quite clean air but forgot 
> to match the Bras and RS code from default.
> If I:
>
>1. reset the BH turbidity params to default,
>2. adjust the Bras param down to 1.6 and
>3. adjust the RS param to 0.84,
>
>  then the curves are close to normalised at peak.  The RS curve is still a 
> somewhat poor representation at dawn and dusk, while Bras is probably close 
> enough to BH that it's not worth the extra effort.  
> The main advantage with B is the atmospheric moisture, which I think 
> contributes significantly, but differently from the atmospheric turbidity 
> parameters and changes the shape of the curve. So a single parameter cannot 
> account for all variables.
> The safest bet might be to adjust the parameter for clear skies and then 
> say that is an upper limit.
>
> On Wednesday, 23 December 2020 at 6:31:47 pm UTC+10 Cameron D wrote:
>
>> So the weewx python code says it is using the Ryan and Stolzenbach model, 
>> which has a few approximations that don't work well in some cases, and it 
>> looks like this is one of them.
>>
>> I've attached a plot comparing 3 insolation models predicting global 
>> horizontal irradiation.
>> Bird and Hulstrom 1991
>> Bras 1992
>> and  Ryan and Stolzenbach  1972
>>
>> B has a lot more parameters to account for, but I have just thrown in 
>> the date/location for Boston, using whatever parameters were in the 
>> spreadsheet, and come up with the following comparison.
>> I used the B predictions for modelling my solar PV system and found it 
>> gives very close results - or at least it did before my system got a bit 
>> older.  However R also gives results that aren't too bad in my location.
>>
>> I have the code in php, but no spare time at the moment to convert to 
>> python.
>>
>> On Tuesday, 22 December 2020 at 2:19:29 am UTC+10 t...@tom.org wrote:
>>
>>> kk, glad you corroborated my observations. I am no expert in this for 
>>> sure. I am just tired of all of the comments I get from visitors to the 
>>> website about how my readings exceed theoretical max. I could remove the 
>>> max, but that doesn't seem fun.
>>>
>>> I do not have the expertise to validate the way weewx calculates it nor 
>>> am I even competent in Python, but for those who may, here is a link to the 
>>> code:
>>>
>>>
>>> https://github.com/weewx/weewx/blob/d91635f3bc429f906d1f084c6a6bc8ee09fa1a27/bin/weewx/wxformulas.py#L332
>>>
>>>
>>>
>>> On Sunday, December 20, 2020 at 1:26:31 PM UTC-5 kk44...@gmail.com 
>>> wrote:
>>>
>>>> I found that thread interesting, so I added the column "maxSolarRad", 
>>>> too. 
>>>>
>>>> [image: dayradiation.png]
>>>> Readings of the console and the WeatherLinkLive device are quite the 
>>>> same. And the readings of "radiation" are higher than "maxSolarRad". The 
>>>> values I upload to the local weather network are well in the range of 
>>>> other 
>>>> stations nearby.
>>>>
>>>>
>>>> Greg Troxel schrieb am Sonntag, 20. Dezember 2020 um 17:58:01 UTC+1:
>>>>
>>>>>
>>>>> Greg Troxel  writes: 
>>>>>
>>>>> > Can someone share how to add maxSolarRad (when it is in the db) to 
>>>>> the 
>>>>> > graphs for the traditional skin? Can I graph radiation, max 
>>>>> (observed), 
>>>>> > and theory all at once, having three? 
>>>>>
>>>>> The answer is to just add it and label it; it comes out in green after 
>>>>> radiation in blue and max in red. Pro Tip: add it after radiation_max, 
>>>>> which is the max of local observations, and don't stick the line after 
>>>>> the radiation_max header and the 4 lines defining how max should be. 
>>>>>
>>>>>
>>>>> [[[dayradiation]]] 
>>>>> radiation 
>>>>> radiation_max 
>>>>> data_type = radiation 
>>>>> aggregate_type = max 
>>>>> aggregate_interval = 3600 
>>>>> label = max 
>>>>> maxSolarRad 
>>>>> label = theory 
>>>>>
>>>>

-- 
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/ef4b8a0b-110b-4e48-bb2e-50ebae8c8277n%40googlegroups.com.

Re: [weewx-user] Re: Solar Radiation > Theoretical Max

I should have looked a bit more closely before posting!  I used the solrad 
excel code from Uni Washington.
I had adjusted my B parameters to represent quite clean air but forgot to 
match the Bras and RS code from default.
If I:

   1. reset the BH turbidity params to default,
   2. adjust the Bras param down to 1.6 and
   3. adjust the RS param to 0.84,

 then the curves are close to normalised at peak.  The RS curve is still a 
somewhat poor representation at dawn and dusk, while Bras is probably close 
enough to BH that it's not worth the extra effort.  
The main advantage with B is the atmospheric moisture, which I think 
contributes significantly, but differently from the atmospheric turbidity 
parameters and changes the shape of the curve. So a single parameter cannot 
account for all variables.
The safest bet might be to adjust the parameter for clear skies and then 
say that is an upper limit.

On Wednesday, 23 December 2020 at 6:31:47 pm UTC+10 Cameron D wrote:

> So the weewx python code says it is using the Ryan and Stolzenbach model, 
> which has a few approximations that don't work well in some cases, and it 
> looks like this is one of them.
>
> I've attached a plot comparing 3 insolation models predicting global 
> horizontal irradiation.
> Bird and Hulstrom 1991
> Bras 1992
> and  Ryan and Stolzenbach  1972
>
> B has a lot more parameters to account for, but I have just thrown in 
> the date/location for Boston, using whatever parameters were in the 
> spreadsheet, and come up with the following comparison.
> I used the B predictions for modelling my solar PV system and found it 
> gives very close results - or at least it did before my system got a bit 
> older.  However R also gives results that aren't too bad in my location.
>
> I have the code in php, but no spare time at the moment to convert to 
> python.
>
> On Tuesday, 22 December 2020 at 2:19:29 am UTC+10 t...@tom.org wrote:
>
>> kk, glad you corroborated my observations. I am no expert in this for 
>> sure. I am just tired of all of the comments I get from visitors to the 
>> website about how my readings exceed theoretical max. I could remove the 
>> max, but that doesn't seem fun.
>>
>> I do not have the expertise to validate the way weewx calculates it nor 
>> am I even competent in Python, but for those who may, here is a link to the 
>> code:
>>
>>
>> https://github.com/weewx/weewx/blob/d91635f3bc429f906d1f084c6a6bc8ee09fa1a27/bin/weewx/wxformulas.py#L332
>>
>>
>>
>> On Sunday, December 20, 2020 at 1:26:31 PM UTC-5 kk44...@gmail.com wrote:
>>
>>> I found that thread interesting, so I added the column "maxSolarRad", 
>>> too. 
>>>
>>> [image: dayradiation.png]
>>> Readings of the console and the WeatherLinkLive device are quite the 
>>> same. And the readings of "radiation" are higher than "maxSolarRad". The 
>>> values I upload to the local weather network are well in the range of other 
>>> stations nearby.
>>>
>>>
>>> Greg Troxel schrieb am Sonntag, 20. Dezember 2020 um 17:58:01 UTC+1:
>>>
>>>>
>>>> Greg Troxel  writes: 
>>>>
>>>> > Can someone share how to add maxSolarRad (when it is in the db) to 
>>>> the 
>>>> > graphs for the traditional skin? Can I graph radiation, max 
>>>> (observed), 
>>>> > and theory all at once, having three? 
>>>>
>>>> The answer is to just add it and label it; it comes out in green after 
>>>> radiation in blue and max in red. Pro Tip: add it after radiation_max, 
>>>> which is the max of local observations, and don't stick the line after 
>>>> the radiation_max header and the 4 lines defining how max should be. 
>>>>
>>>>
>>>> [[[dayradiation]]] 
>>>> radiation 
>>>> radiation_max 
>>>> data_type = radiation 
>>>> aggregate_type = max 
>>>> aggregate_interval = 3600 
>>>> label = max 
>>>> maxSolarRad 
>>>> label = theory 
>>>>
>>>

-- 
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/0d468847-eed9-4d9d-9649-4937a5e61901n%40googlegroups.com.

Re: [weewx-user] Re: Solar Radiation > Theoretical Max