[weewx-user] ecowitt ws80

[Graham Eddy]

the top of my ecowitt ws80 (the light sensor) has partly filled with 
condensation and stopped working. the rest of the ws80 is still working. is 
this ‘expected’ of an exposed ws80 (how else to get UV?) or is it a fault 
(demand a replacement)?

Graham Eddy

-- 
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/A823A248-BDBF-4DA2-ABF3-6FAB4EB33F0F%40gmail.com.

[weewx-user] Re: loop data with fineoffsetusb weather station

[gjr80]

Yes, the FineOffsetUSB driver emits loop packets just as the simulator does 
it’s just that they are emitted much less frequently. You might find the 
FineOffsetUSB 
section  of the Hardware 
Guide  helpful.

Gary
On Thursday, 21 January 2021 at 08:18:56 UTC+10 hobbyl...@gmail.com wrote:

> can we have loop data with fineoffsetusb weather station for example 
> wh1080 , like the simulator generating?

-- 
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/b82b6843-036c-4d01-9b50-11edae2a271bn%40googlegroups.com.

[weewx-user] yearwindvec calculation problem

[jerry...@gmail.com]

I noticed that something recently has gone wrong with my year wind vector 
graphic.  The y axis is broken.  This seems to have happened around the 
transition to 4.3
The monthwindvec graphic is ok

[image: monthwindvec.png]
but the yearwindvec y axis is scaled about 100 times too large
[image: yearwindvec.png]
Going back to V 4.2 on Dec 31, everything was normal
[image: dec31yearwindvec.png]
This is running on macOS 10.15.7 (Catalina) with Python 3.9.1
Any ideas where to look for fixes?

-- 
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/9aa6d4a4-8d32-4709-b1e5-b11e24a9048fn%40googlegroups.com.

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

[Neville Davis]

HI
At the end of testing..starting from only seasons skin, MQTT disabled etc, 
direct run weewx, all the way to fully operational and not once did the 
rainRate cease to operate including shutdowns reboots etc. Simply could 
not fault it.
We have had now rainfall last couple of days so I was able to clean the db 
archive and dailies for the last two days for rain and rainRate.
Just have to keep an eye on it I guess...reminds me so often as an 
electronics tech called to some navigation gear by an operator reporting 
faults and nothing found...I thought I had left that behind a couple of 
decades ago :) .

Neville


On Wednesday, January 20, 2021 at 11:01:02 AM UTC+10 Neville Davis wrote:

> I don't have any rain calculations or gathering in my script for 
> PiWeather...just looks at the other sensors NOT rain.
> I am currently going through a test and with only Seasons skin and running 
>  weewx directly rainRate is calculatedcould not wait for weekend :)
> As I look at the scrolling data the rainRate calc is reducing (as it 
> should be no more bucket tips) I will get back to you if I find anything 
> significant.
>
> Neville
>
> On Wednesday, January 20, 2021 at 10:21:49 AM UTC+10 tke...@gmail.com 
> wrote:
>
>> That's all fine, so long as the field 'rain' comes from a single source. 
>> Which one is it? 
>>
>> On Tue, Jan 19, 2021 at 2:10 PM Neville Davis  
>> wrote:
>>
>>> Hi just revisited my weewx.conf I believe I only have one driver 
>>> PiWeather, the OWFS is configured as a service as per the instructions in 
>>> owfs.py..
>>> 
>>> Place this file, owfs.py, in the weewx 'user' directory
>>> or wee_extension will install it there.
>>>
>>> To use as a driver:
>>>
>>> [Station]
>>> station_type = OWFS
>>>
>>> To use as a service:
>>>
>>> [Engine]
>>> [[Service]]
>>> data_services = user.owfs.OWFSService
>>>
>>> My weewx.conf has
>>> [Engine]
>>> # The following section specifies which services should be run and 
>>> in what order.
>>> [[Services]]
>>> prep_services = weewx.engine.StdTimeSynch
>>> data_services = user.owfs.OWFSService, user.aircon.AirconService
>>> process_services = weewx.engine.StdConvert, 
>>> weewx.engine.StdCalibrate, weewx.engine.StdQC, 
>>> weewx.wxservices.StdWXCalculate
>>> xtype_services = weewx.wxxtypes.StdWXXTypes, 
>>> weewx.wxxtypes.StdPressureCooker, weewx.wxxtypes.StdRainRater, 
>>> weewx.wxxtypes.StdDelta
>>> archive_services = weewx.engine.StdArchive
>>> restful_services = weewx.restx.StdStationRegistry, 
>>> weewx.restx.StdWunderground, weewx.restx.StdPWSweather, 
>>> weewx.restx.StdCWOP, weewx.restx.StdWOW, weewx.restx.StdAWEKAS, 
>>> user.mqtt.MQTT, user.twitter.Twitter
>>> report_services = weewx.engine.StdPrint, weewx.engine.StdReport
>>>
>>> In data services I also have a service  to collect temperature data from 
>>> our aircon system to display within the skin as well as OWFS..
>>> As to what is seen in the log about this, is way above my pay grade:)
>>>
>>> What is interesting about all this was that when I upgraded to 4.3 this 
>>> month, for that day, rainRate was recorded. 
>>> I will do the rain test as well as full restarts to see if anything pops 
>>> up.
>>> The biggest change to my system of recent months has been the addition 
>>> of a MQTT broker for the Belchertown skin...I did have some issues with 
>>> rain being displayed in cm not mm and there is an addition to the MQTT 
>>> section in weewx.conf to correct this...at that time I had also a section 
>>> for rainRate but disabled it to try and fault find this 
>>> problemCoincidence??? 
>>> I will also disable any other skins and use just the Standard skin to 
>>> ensure there is nothing happening there.
>>>
>>> Neville
>>>
>>> On Wednesday, January 20, 2021 at 6:45:51 AM UTC+10 Neville Davis wrote:
>>>
 Hi
 I have been using this configuration for several years..The overall 
 hardware design is my own...I am a hardware guy more then a software type 
 but had some experience with sql years ago (I am 76) and wanted use 
 replication to backup to my local nas, so I migrated to Mysql when I built 
 this system about 4 years agoPiWeather is the driver I built to handle 
 the data derived from my i2C sensors, Davis masthead wind gear, my FARS 
 external temp sensor, and FARS fan speed monitor (to detect failure) etc. 
 I 
 could not work out the best way to get the one wire rain bucket data into 
 weewx.In the end it appears I do the both as drivers as you saybut 
 it has never given me any trouble..and I didn’t know any better :).
 Before I saw this post I was planning to do as you suggest ( add water 
 and observe) and see what that gives me. We are expecting a fine day on 
 the 
 weekend I will do it then.
 So to get only a single driver..I am not sure how to do that I will 
 give it some 

[weewx-user] Re: Need help: Bresser Weather 6in1 Pro WiFi and weewx Interceptor

[galfert]

The tool to import from WU is built into WeeWX. It is called wee_import. 
There may be an update for it though that is not part of WeeWXnot sure. 
I've actually never used it.

I don't know what the data limit is nor how much you need to import. I 
suppose you could do it in chunks if necessary. You'll never have to pay 
even after a year. The API key that you get as a contributor is just 
limited per day to 500 queries and 10 times per minute. Don't ask me to 
explain that. That is what I read and I don't have more details. I'm sure 
that you'll learn more as you learn to work with the wee_import. You should 
be able to grab all of your history. It may take a while but I don't see 
why it wouldn't be possible.



On Wednesday, January 20, 2021 at 3:13:53 PM UTC-5 Steinwolf wrote:

> Sorry I cannot edit my previous post - So here as additional question - Do 
> you maybe have the link to the weewx extension? Didn't find it here 
> https://github.com/weewx/weewx/wiki.
>
> Steinwolf schrieb am Mittwoch, 20. Januar 2021 um 21:03:43 UTC+1:
>
>> Oh Ok. So I think I maybe misunderstood some posts I found online. So I 
>> dont pay anything aslong as I dont download the data to frequently? In some 
>> postings they say, that you have to pay after one year anyway.
>> I saw the API thing before, but here you can only download the real time 
>> data, I guess. For me it would be enough to download all data once a month 
>> or so. Is this possible?
>>
>> Whatever - I would prefer to have a self-managed datalogger for many 
>> reasons.
>> The most important reason is, that I would also see the inside 
>> temperature which is not possible because of " privacy policies". Also 
>> there is one more temp-sensor, which also dont show up.
>> And to have "everything in my hands".
>>
>> So can anyone help me?
>>
>> BR,
>> Steinwolf
>> galfert schrieb am Sonntag, 17. Januar 2021 um 17:12:55 UTC+1:
>>
>>> It is not true that WU doesn't let you download your own data. The 
>>> confusion is that you can't download data the old way with a .csv download 
>>> file. The new way to download your own data is to use an API key that you 
>>> can generate under your account setting. Then you must use this new API 
>>> method to download your data. There is even a WeeWX extension to use this 
>>> new method that has been created.
>>>
>>> The reason for this change is that before anyone could download any 
>>> amount of data and there were no controls to limit bandwidth usage. With 
>>> the new API key method you are limited in the amount of bandwidth you can 
>>> use on a monthly basis. This limits bandwidth abuse and it allows WU to 
>>> better run their servers and reduce costs. If you are a business and you 
>>> were previously downloading tons of data from WU, then those efforts have 
>>> been blocked. You'll now have to purchase a commercial license in order to 
>>> continue to download the amounts of data that you were before. You could 
>>> say that a few bad apples with their abuse ruined the simplicity of the 
>>> previous .csv download method. There were a few years where WU servers were 
>>> hardly ever up. Sure things are not still perfect with WU but they 
>>> certainly are a lot better than they were before these controls were 
>>> implemented.
>>>
>>>
>>>
>>>
>>> On Sunday, January 17, 2021 at 10:41:11 AM UTC-5 Steinwolf wrote:
>>>
 Hello,
 I need help with the Bresser 6in1 Pro Wifi. (sends data to 
 WeatherUnderground). Unfortunatelly it is the "stupid" not FINEOffset 
 version, so I have to use the interceptor, but I'm unable to get the 
 interceptor working. 
 I'm really unhappy with WU (now they even dont let you download your 
 own data!) and thats why I will use weewx. 
 By the way - this whole raspbian, linux,... thing is also new to me, so 
 I struggle with this all and can only do things I found on the internet. 
 So 
 please, in case you write back, dont think I know anything - tell me like 
 I'm a litte kid or so ;)

 My setup: 
 Bresser Weather 6in1 Pro WiFi (the one with the display) (IP 
 192.168.188.60- I guess, because the Bresser configuration site is here)
 Raspberry Pi3 (with weewx, interceptor and apache)
 Fritz.Box as router

 IPs: 
 Bresser Weather IP 192.168.188.60 (I guess, because the Bresser 
 configuration site is here) 
 Raspbi IP LAN 192.168.188.34, IP WLan  192.168.188.35 
 (raspbiweather.fritz.box also works) 
 FritzBox IP (as gateway?) 192.168.188.1

 The problem:
 I permanently get this error:

 pi@raspbiWeather:~ $ sudo /etc/init.d/weewx status
 ● weewx.service - LSB: weewx weather system
Loaded: loaded (/etc/init.d/weewx; generated)
Active: active (exited) since Sun 2021-01-17 13:50:40 GMT; 3s ago
  Docs: man:systemd-sysv-generator(8)
   Process: 2410 ExecStart=/etc/init.d/weewx start (code=exited, 
 status=0/SUCCESS)

 Jän 17 

[weewx-user] loop data with fineoffsetusb weather station

[Δημήτρης Βήχος]

can we have loop data with fineoffsetusb weather station for example wh1080 
, like the simulator generating?

-- 
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/ecb7b8f6-42b4-45e7-b97f-e04869fc1094n%40googlegroups.com.

Re: [weewx-user] Re: No module named wmr200 (Weewx 4.3.0)

[John Kline]

I don’t recommend reverting to 4.2 as it has some issues.

The problem you are describing now is do to some issues in your db; 
specifically, intervals of 0 (4.3 is less forgiving).  I found a thread to 
address it from Jan 6.  I’ve pasted Tom’s response below.  Rather than deleting 
records, if you know what the correct interval should be, you could update the 
records.

Good heavens. That's a lot. I wonder where they all came from?

No matter. Here's how to fix (and sorry for giving you the wrong path to the 
database).

# First stop weewx
sudo systemctl stop weewx

cd /var/lib/weewx

# Make a backup:
sudo cp weewx.sdb weewx.sdb.backup

# Delete all records where interval equals zero:
sudo sqlite3 weewx.sdb
sqlite> delete from archive where interval==0;
sqlite> .quit

# Restart weewx
sudo systemctl start weewx

If you get this error again, there is something wrong with the configuration of 
your system.

-tk

> On Jan 20, 2021, at 1:56 PM, Invisible Man  wrote:
> 
> Ok, I see WMR200 has been removed in December 2020, and is now an extension.
> I install the extension, and I get more errors
> 
> -- Logs begin at Wed 2021-01-20 16:50:14 CET. --
> Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__:   
>   File "/usr/share/weewx/weewx/manager.py", line 1255, in patch_sums
> Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__:   
> self.recalculate_weights(start_d=datetime.date(2020,6,1))
> Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__:   
>   File "/usr/share/weewx/weewx/manager.py", line 1182, in recalculate_weights
> Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__:   
> self._do_tranche(mark_d, end_of_tranche_d, weight_fn, progress_fn)
> Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__:   
>   File "/usr/share/weewx/weewx/manager.py", line 1215, in _do_tranche
> Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__:   
> weight = weight_fn(self, rec)
> Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__:   
>   File "/usr/share/weewx/weewx/manager.py", line 1366, in _calc_weight
> Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__:   
> "Non-positive value for record field 'interval': %s" % 
> (record['interval'],))
> Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__:   
> IntervalError: Non-positive value for record field 'interval': 0
> Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__:   
> Exiting.
> 
> I'm really unhappy about that :( 
> When you upgrade, you expect things to work, not things to get broken. If I 
> had known, I wouldn't have upgraded.
> How can I revert to 4.2.0 ?
> 
> 
> 
>> On Wednesday, January 20, 2021 at 10:46:32 PM UTC+1 Invisible Man wrote:
>> 
>> Hey! What's happening?! I've upgraded weewx 4.2.0 to 4.3.0 (on a Raspberry 
>> Pi) and I get this error !
>> 
>> ```
>> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Initializing 
>> weewx version 4.3.0
>> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Using Python 
>> 2.7.16 (default, Oct 10 2019, 22:02:15
>>  [GCC 8.3.0]
>> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Platform 
>> Linux-5.4.72-v7+-armv7l-with-debian-10.7
>> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Locale is 
>> 'en_GB.UTF-8'
>> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: PID file is 
>> /var/run/weewx.pid
>> Jan 20 22:33:39 vegan weewx[6520]: Starting weewx weather system: weewx.
>> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] INFO __main__: Using 
>> configuration file /etc/weewx/weewx.conf
>> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] INFO __main__: Debug is 1
>> Jan 20 22:33:39 vegan systemd[1]: Started LSB: weewx weather system.
>> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] DEBUG __main__: 
>> Initializing engine
>> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] INFO weewx.engine: Loading 
>> station type WMR200 (weewx.drivers.wmr2
>> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: Caught 
>> unrecoverable exception:
>> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:  
>>  No module named wmr200
>> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:  
>>  Traceback (most recent call last):
>> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:  
>>File "/usr/share/weewx/weewxd", lin
>> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:  
>>  engine = weewx.engine.StdEngine(c
>> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:  
>>File "/usr/share/weewx/weewx/engine
>> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:  
>>  self.setupStation(config_dict)
>> Jan 20 

[weewx-user] Re: No module named wmr200 (Weewx 4.3.0)

[Invisible Man]

Ok, I see WMR200 has been removed in December 2020, and is now an extension.
I install the extension, and I get more errors

-- Logs begin at Wed 2021-01-20 16:50:14 CET. --
Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__: 
File "/usr/share/weewx/weewx/manager.py", line 1255, in patch_sums
Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__: 
  self.recalculate_weights(start_d=datetime.date(2020,6,1))
Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__: 
File "/usr/share/weewx/weewx/manager.py", line 1182, in 
recalculate_weights
Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__: 
  self._do_tranche(mark_d, end_of_tranche_d, weight_fn, progress_fn)
Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__: 
File "/usr/share/weewx/weewx/manager.py", line 1215, in _do_tranche
Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__: 
  weight = weight_fn(self, rec)
Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__: 
File "/usr/share/weewx/weewx/manager.py", line 1366, in _calc_weight
Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__: 
  "Non-positive value for record field 'interval': %s" % 
(record['interval'],))
Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__: 
  IntervalError: Non-positive value for record field 'interval': 0
Jan 20 22:53:44 vegan python2[7867]: weewx[7867] CRITICAL __main__: 
  Exiting.

I'm really unhappy about that :( 
When you upgrade, you expect things to work, not things to get broken. If I 
had known, I wouldn't have upgraded.
How can I revert to 4.2.0 ?



On Wednesday, January 20, 2021 at 10:46:32 PM UTC+1 Invisible Man wrote:

>
> Hey! What's happening?! I've upgraded weewx 4.2.0 to 4.3.0 (on a Raspberry 
> Pi) and I get this error !
>
> ```
> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: 
> Initializing weewx version 4.3.0
> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Using 
> Python 2.7.16 (default, Oct 10 2019, 22:02:15
>  [GCC 8.3.0]
> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Platform 
> Linux-5.4.72-v7+-armv7l-with-debian-10.7
> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Locale is 
> 'en_GB.UTF-8'
> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: PID file 
> is /var/run/weewx.pid
> Jan 20 22:33:39 vegan weewx[6520]: Starting weewx weather system: weewx.
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] INFO __main__: Using 
> configuration file /etc/weewx/weewx.conf
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] INFO __main__: Debug is 1
> Jan 20 22:33:39 vegan systemd[1]: Started LSB: weewx weather system.
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] DEBUG __main__: 
> Initializing engine
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] INFO weewx.engine: 
> Loading station type WMR200 (weewx.drivers.wmr2
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: Caught 
> unrecoverable exception:
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
>   No module named wmr200
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
>   Traceback (most recent call last):
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
> File "/usr/share/weewx/weewxd", lin
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
>   engine = weewx.engine.StdEngine(c
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
> File "/usr/share/weewx/weewx/engine
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
>   self.setupStation(config_dict)
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
> File "/usr/share/weewx/weewx/engine
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
>   __import__(driver)
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
>   ImportError: No module named wmr200
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
>   Exiting.
> ```
>
> and indeed there is no longer wmr200 in /usr/share/weewx/weewx/drivers.
> Now only wmr100 or wmr300.py ?!
>

-- 
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/cb8ae32c-e1ce-41cb-9940-689d5ba0ea50n%40googlegroups.com.

Re: [weewx-user] No module named wmr200 (Weewx 4.3.0)

[John Kline]

See the 4.3 change log here:
https://github.com/weewx/weewx/releases

The WMR200 driver is no longer supported. An unsupported version can be found
at https://github.com/weewx/weewx-wmr200. Support for LaCrosse WS23xx and
Oregon WMR300 will continue.


> On Jan 20, 2021, at 1:46 PM, Invisible Man  wrote:
> 
> 
> Hey! What's happening?! I've upgraded weewx 4.2.0 to 4.3.0 (on a Raspberry 
> Pi) and I get this error !
> 
> ```
> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Initializing 
> weewx version 4.3.0
> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Using Python 
> 2.7.16 (default, Oct 10 2019, 22:02:15
>  [GCC 8.3.0]
> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Platform 
> Linux-5.4.72-v7+-armv7l-with-debian-10.7
> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Locale is 
> 'en_GB.UTF-8'
> Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: PID file is 
> /var/run/weewx.pid
> Jan 20 22:33:39 vegan weewx[6520]: Starting weewx weather system: weewx.
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] INFO __main__: Using 
> configuration file /etc/weewx/weewx.conf
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] INFO __main__: Debug is 1
> Jan 20 22:33:39 vegan systemd[1]: Started LSB: weewx weather system.
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] DEBUG __main__: Initializing 
> engine
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] INFO weewx.engine: Loading 
> station type WMR200 (weewx.drivers.wmr2
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: Caught 
> unrecoverable exception:
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:   
> No module named wmr200
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:   
> Traceback (most recent call last):
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:   
>   File "/usr/share/weewx/weewxd", lin
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:   
> engine = weewx.engine.StdEngine(c
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:   
>   File "/usr/share/weewx/weewx/engine
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:   
> self.setupStation(config_dict)
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:   
>   File "/usr/share/weewx/weewx/engine
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:   
> __import__(driver)
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:   
> ImportError: No module named wmr200
> Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__:   
> Exiting.
> ```
> 
> and indeed there is no longer wmr200 in /usr/share/weewx/weewx/drivers.
> Now only wmr100 or wmr300.py ?!
> -- 
> 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/0754b53c-a6b1-4d9d-8924-2b627122f182n%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/F639BCAA-10A9-4BE0-9F88-061CE915854A%40johnkline.com.

[weewx-user] No module named wmr200 (Weewx 4.3.0)

[Invisible Man]

Hey! What's happening?! I've upgraded weewx 4.2.0 to 4.3.0 (on a Raspberry 
Pi) and I get this error !

```
Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: 
Initializing weewx version 4.3.0
Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Using 
Python 2.7.16 (default, Oct 10 2019, 22:02:15
 [GCC 8.3.0]
Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Platform 
Linux-5.4.72-v7+-armv7l-with-debian-10.7
Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: Locale is 
'en_GB.UTF-8'
Jan 20 22:33:39 vegan python2[6532]: weewx[6532] INFO __main__: PID file is 
/var/run/weewx.pid
Jan 20 22:33:39 vegan weewx[6520]: Starting weewx weather system: weewx.
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] INFO __main__: Using 
configuration file /etc/weewx/weewx.conf
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] INFO __main__: Debug is 1
Jan 20 22:33:39 vegan systemd[1]: Started LSB: weewx weather system.
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] DEBUG __main__: 
Initializing engine
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] INFO weewx.engine: Loading 
station type WMR200 (weewx.drivers.wmr2
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: Caught 
unrecoverable exception:
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
  No module named wmr200
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
  Traceback (most recent call last):
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
File "/usr/share/weewx/weewxd", lin
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
  engine = weewx.engine.StdEngine(c
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
File "/usr/share/weewx/weewx/engine
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
  self.setupStation(config_dict)
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
File "/usr/share/weewx/weewx/engine
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
  __import__(driver)
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
  ImportError: No module named wmr200
Jan 20 22:33:39 vegan python2[6536]: weewx[6536] CRITICAL __main__: 
  Exiting.
```

and indeed there is no longer wmr200 in /usr/share/weewx/weewx/drivers.
Now only wmr100 or wmr300.py ?!

-- 
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/0754b53c-a6b1-4d9d-8924-2b627122f182n%40googlegroups.com.

[weewx-user] Re: Need help: Bresser Weather 6in1 Pro WiFi and weewx Interceptor

[Steinwolf]

Sorry I cannot edit my previous post - So here as additional question - Do 
you maybe have the link to the weewx extension? Didn't find it here 
https://github.com/weewx/weewx/wiki.

Steinwolf schrieb am Mittwoch, 20. Januar 2021 um 21:03:43 UTC+1:

> Oh Ok. So I think I maybe misunderstood some posts I found online. So I 
> dont pay anything aslong as I dont download the data to frequently? In some 
> postings they say, that you have to pay after one year anyway.
> I saw the API thing before, but here you can only download the real time 
> data, I guess. For me it would be enough to download all data once a month 
> or so. Is this possible?
>
> Whatever - I would prefer to have a self-managed datalogger for many 
> reasons.
> The most important reason is, that I would also see the inside temperature 
> which is not possible because of " privacy policies". Also there is one 
> more temp-sensor, which also dont show up.
> And to have "everything in my hands".
>
> So can anyone help me?
>
> BR,
> Steinwolf
> galfert schrieb am Sonntag, 17. Januar 2021 um 17:12:55 UTC+1:
>
>> It is not true that WU doesn't let you download your own data. The 
>> confusion is that you can't download data the old way with a .csv download 
>> file. The new way to download your own data is to use an API key that you 
>> can generate under your account setting. Then you must use this new API 
>> method to download your data. There is even a WeeWX extension to use this 
>> new method that has been created.
>>
>> The reason for this change is that before anyone could download any 
>> amount of data and there were no controls to limit bandwidth usage. With 
>> the new API key method you are limited in the amount of bandwidth you can 
>> use on a monthly basis. This limits bandwidth abuse and it allows WU to 
>> better run their servers and reduce costs. If you are a business and you 
>> were previously downloading tons of data from WU, then those efforts have 
>> been blocked. You'll now have to purchase a commercial license in order to 
>> continue to download the amounts of data that you were before. You could 
>> say that a few bad apples with their abuse ruined the simplicity of the 
>> previous .csv download method. There were a few years where WU servers were 
>> hardly ever up. Sure things are not still perfect with WU but they 
>> certainly are a lot better than they were before these controls were 
>> implemented.
>>
>>
>>
>>
>> On Sunday, January 17, 2021 at 10:41:11 AM UTC-5 Steinwolf wrote:
>>
>>> Hello,
>>> I need help with the Bresser 6in1 Pro Wifi. (sends data to 
>>> WeatherUnderground). Unfortunatelly it is the "stupid" not FINEOffset 
>>> version, so I have to use the interceptor, but I'm unable to get the 
>>> interceptor working. 
>>> I'm really unhappy with WU (now they even dont let you download your own 
>>> data!) and thats why I will use weewx. 
>>> By the way - this whole raspbian, linux,... thing is also new to me, so 
>>> I struggle with this all and can only do things I found on the internet. So 
>>> please, in case you write back, dont think I know anything - tell me like 
>>> I'm a litte kid or so ;)
>>>
>>> My setup: 
>>> Bresser Weather 6in1 Pro WiFi (the one with the display) (IP 
>>> 192.168.188.60- I guess, because the Bresser configuration site is here)
>>> Raspberry Pi3 (with weewx, interceptor and apache)
>>> Fritz.Box as router
>>>
>>> IPs: 
>>> Bresser Weather IP 192.168.188.60 (I guess, because the Bresser 
>>> configuration site is here) 
>>> Raspbi IP LAN 192.168.188.34, IP WLan  192.168.188.35 
>>> (raspbiweather.fritz.box also works) 
>>> FritzBox IP (as gateway?) 192.168.188.1
>>>
>>> The problem:
>>> I permanently get this error:
>>>
>>> pi@raspbiWeather:~ $ sudo /etc/init.d/weewx status
>>> ● weewx.service - LSB: weewx weather system
>>>Loaded: loaded (/etc/init.d/weewx; generated)
>>>Active: active (exited) since Sun 2021-01-17 13:50:40 GMT; 3s ago
>>>  Docs: man:systemd-sysv-generator(8)
>>>   Process: 2410 ExecStart=/etc/init.d/weewx start (code=exited, 
>>> status=0/SUCCESS)
>>>
>>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>>> weewx.engine:   self._server = Consumer.TCPServer(address, 
>>> port, handler)
>>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>>> weewx.engine: File "/usr/share/weewx/user/interceptor.py", line 
>>> 584, in __init__
>>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>>> weewx.engine:   TCPServer.__init__(self, (address, int(port)), 
>>> handler)
>>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>>> weewx.engine: File "/usr/lib/python3.7/socketserver.py", line 
>>> 452, in __init__
>>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>>> weewx.engine:   self.server_bind()
>>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>>> weewx.engine: File 

[weewx-user] Re: Need help: Bresser Weather 6in1 Pro WiFi and weewx Interceptor

[Steinwolf]

Oh Ok. So I think I maybe misunderstood some posts I found online. So I 
dont pay anything aslong as I dont download the data to frequently? In some 
postings they say, that you have to pay after one year anyway.
I saw the API thing before, but here you can only download the real time 
data, I guess. For me it would be enough to download all data once a month 
or so. Is this possible?

Whatever - I would prefer to have a self-managed datalogger for many 
reasons.
The most important reason is, that I would also see the inside temperature 
which is not possible because of " privacy policies". Also there is one 
more temp-sensor, which also dont show up.
And to have "everything in my hands".

So can anyone help me?

BR,
Steinwolf
galfert schrieb am Sonntag, 17. Januar 2021 um 17:12:55 UTC+1:

> It is not true that WU doesn't let you download your own data. The 
> confusion is that you can't download data the old way with a .csv download 
> file. The new way to download your own data is to use an API key that you 
> can generate under your account setting. Then you must use this new API 
> method to download your data. There is even a WeeWX extension to use this 
> new method that has been created.
>
> The reason for this change is that before anyone could download any amount 
> of data and there were no controls to limit bandwidth usage. With the new 
> API key method you are limited in the amount of bandwidth you can use on a 
> monthly basis. This limits bandwidth abuse and it allows WU to better run 
> their servers and reduce costs. If you are a business and you were 
> previously downloading tons of data from WU, then those efforts have been 
> blocked. You'll now have to purchase a commercial license in order to 
> continue to download the amounts of data that you were before. You could 
> say that a few bad apples with their abuse ruined the simplicity of the 
> previous .csv download method. There were a few years where WU servers were 
> hardly ever up. Sure things are not still perfect with WU but they 
> certainly are a lot better than they were before these controls were 
> implemented.
>
>
>
>
> On Sunday, January 17, 2021 at 10:41:11 AM UTC-5 Steinwolf wrote:
>
>> Hello,
>> I need help with the Bresser 6in1 Pro Wifi. (sends data to 
>> WeatherUnderground). Unfortunatelly it is the "stupid" not FINEOffset 
>> version, so I have to use the interceptor, but I'm unable to get the 
>> interceptor working. 
>> I'm really unhappy with WU (now they even dont let you download your own 
>> data!) and thats why I will use weewx. 
>> By the way - this whole raspbian, linux,... thing is also new to me, so I 
>> struggle with this all and can only do things I found on the internet. So 
>> please, in case you write back, dont think I know anything - tell me like 
>> I'm a litte kid or so ;)
>>
>> My setup: 
>> Bresser Weather 6in1 Pro WiFi (the one with the display) (IP 
>> 192.168.188.60- I guess, because the Bresser configuration site is here)
>> Raspberry Pi3 (with weewx, interceptor and apache)
>> Fritz.Box as router
>>
>> IPs: 
>> Bresser Weather IP 192.168.188.60 (I guess, because the Bresser 
>> configuration site is here) 
>> Raspbi IP LAN 192.168.188.34, IP WLan  192.168.188.35 
>> (raspbiweather.fritz.box also works) 
>> FritzBox IP (as gateway?) 192.168.188.1
>>
>> The problem:
>> I permanently get this error:
>>
>> pi@raspbiWeather:~ $ sudo /etc/init.d/weewx status
>> ● weewx.service - LSB: weewx weather system
>>Loaded: loaded (/etc/init.d/weewx; generated)
>>Active: active (exited) since Sun 2021-01-17 13:50:40 GMT; 3s ago
>>  Docs: man:systemd-sysv-generator(8)
>>   Process: 2410 ExecStart=/etc/init.d/weewx start (code=exited, 
>> status=0/SUCCESS)
>>
>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>> weewx.engine:   self._server = Consumer.TCPServer(address, 
>> port, handler)
>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>> weewx.engine: File "/usr/share/weewx/user/interceptor.py", line 
>> 584, in __init__
>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>> weewx.engine:   TCPServer.__init__(self, (address, int(port)), 
>> handler)
>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>> weewx.engine: File "/usr/lib/python3.7/socketserver.py", line 
>> 452, in __init__
>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>> weewx.engine:   self.server_bind()
>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>> weewx.engine: File "/usr/lib/python3.7/socketserver.py", line 
>> 466, in server_bind
>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>> weewx.engine:   self.socket.bind(self.server_address)
>> Jän 17 13:50:40 raspbiWeather python3[2426]: weewx[2426] CRITICAL 
>> weewx.engine:   OSError: [Errno 99] Die angeforderte Adresse kann 
>> nicht 

Re: [weewx-user] How to limit syslog logging

[LeaF]

So taking your advice, I looked into the bme280wx.py file and noticed that 
there were a number of places where it was writing out information to 
various file; syslog, debug and user.  When I commented those lines out, 
voila no more excessive logging. 
Thanks again tk
Lee

On Wednesday, January 20, 2021 at 10:58:46 AM UTC-8 tke...@gmail.com wrote:

> Those things are generally set in /etc/rsyslog.d
>
> On Wed, Jan 20, 2021 at 10:54 AM LeaF  wrote:
>
>> tk
>> Thanks for the observation.  I'll do some snooping around the bme280 and 
>> see what I can find. 
>>
>> (It's not only syslog getting overwhelmed with entries, but debug and 
>> user log files are filled with the same info)
>>
>> Thanks
>> Lee
>>
>> On Wednesday, January 20, 2021 at 10:50:01 AM UTC-8 tke...@gmail.com 
>> wrote:
>>
>>> It looks like an extension you are using, bme280, is what is creating 
>>> the chatter. Unfortunately, from the little log snippet you gave, it does 
>>> not appear to be WeeWX V4 compliant, so muzzling it will not be as easy as 
>>> a weewx.conf setting. You could ask the author to update it to V4, then you 
>>> could follow the directions in the Wiki article *WeeWX V4 and logging 
>>> *.
>>>
>>> OTOH, fortunately, it looks like the log entry is a debug entry, so 
>>> setting debug=0 in weewx.conf should help reduce the number of entries.
>>>
>>> -tk
>>>
>>>
>>>
>>> On Wed, Jan 20, 2021 at 10:39 AM LeaF  wrote:
>>>
 I have a question regarding what goes into the /var/log/syslog file.

 I’m running the latest version of weewx on a Raspberry Pi 4.  My 
 station is a Peet Bros Ultimeter 100. I also added a Adafruit BME280 
 breakout board to measure pressure and humidity.  

 This all works very well.  Thank you

 When I run sudo tail -f /var/log/syslog, there appears to be three 
 entries per second being written to the log file.  So as you can 
 imagine, the log file has a lot of info that I don’t want in there.  Any 
 errors are being written to weewx.log file.

 How can I limit what is going to the log file so they don’t grow so 
 large?  I looked at rsyslog.conf, but don’t know if this is the 
 correct place to limit the log entries. 

 Example, one entry into log file:

  Jan 20 10:22:47 WeatherPi /weewxd: bme280: {'dateTime': 1611166967, 
 'usUnits': 1, 'windSpeed': 0.0, 'windDir': 55.058796, 'outTemp': 
 38.304, 'rain_total': 0.5, 'barometer': None, 'inTemp': None, 
 'outHumidity': 77.02371597125266, 'inHumidity': None, 'day_of_year': 19, 
 'minute_of_day': 620, 'daily_rain': 0.0, 'wind_average': 0.0, 'rain': 0.0, 
 'pressure': 29.53154056121909}

 Thanks for your help.

 Lee

 -- 
 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/7c9cae95-4bcd-4dd6-b293-2113d6a5054cn%40googlegroups.com
  
 
 .

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/08c304c3-aa29-4a12-a1ac-d0824643d2f7n%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/1ca1f295-9116-4ade-bccc-8ec496f8688dn%40googlegroups.com.

Re: [weewx-user] How to limit syslog logging

[Tom Keffer]

Those things are generally set in /etc/rsyslog.d

On Wed, Jan 20, 2021 at 10:54 AM LeaF  wrote:

> tk
> Thanks for the observation.  I'll do some snooping around the bme280 and
> see what I can find.
>
> (It's not only syslog getting overwhelmed with entries, but debug and user
> log files are filled with the same info)
>
> Thanks
> Lee
>
> On Wednesday, January 20, 2021 at 10:50:01 AM UTC-8 tke...@gmail.com
> wrote:
>
>> It looks like an extension you are using, bme280, is what is creating the
>> chatter. Unfortunately, from the little log snippet you gave, it does not
>> appear to be WeeWX V4 compliant, so muzzling it will not be as easy as a
>> weewx.conf setting. You could ask the author to update it to V4, then you
>> could follow the directions in the Wiki article *WeeWX V4 and logging
>> *.
>>
>> OTOH, fortunately, it looks like the log entry is a debug entry, so
>> setting debug=0 in weewx.conf should help reduce the number of entries.
>>
>> -tk
>>
>>
>>
>> On Wed, Jan 20, 2021 at 10:39 AM LeaF  wrote:
>>
>>> I have a question regarding what goes into the /var/log/syslog file.
>>>
>>> I’m running the latest version of weewx on a Raspberry Pi 4.  My
>>> station is a Peet Bros Ultimeter 100. I also added a Adafruit BME280
>>> breakout board to measure pressure and humidity.
>>>
>>> This all works very well.  Thank you
>>>
>>> When I run sudo tail -f /var/log/syslog, there appears to be three
>>> entries per second being written to the log file.  So as you can
>>> imagine, the log file has a lot of info that I don’t want in there.  Any
>>> errors are being written to weewx.log file.
>>>
>>> How can I limit what is going to the log file so they don’t grow so
>>> large?  I looked at rsyslog.conf, but don’t know if this is the correct
>>> place to limit the log entries.
>>>
>>> Example, one entry into log file:
>>>
>>>  Jan 20 10:22:47 WeatherPi /weewxd: bme280: {'dateTime': 1611166967,
>>> 'usUnits': 1, 'windSpeed': 0.0, 'windDir': 55.058796, 'outTemp':
>>> 38.304, 'rain_total': 0.5, 'barometer': None, 'inTemp': None,
>>> 'outHumidity': 77.02371597125266, 'inHumidity': None, 'day_of_year': 19,
>>> 'minute_of_day': 620, 'daily_rain': 0.0, 'wind_average': 0.0, 'rain': 0.0,
>>> 'pressure': 29.53154056121909}
>>>
>>> Thanks for your help.
>>>
>>> Lee
>>>
>>> --
>>> 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/7c9cae95-4bcd-4dd6-b293-2113d6a5054cn%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/08c304c3-aa29-4a12-a1ac-d0824643d2f7n%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/CAPq0zEBRktGszyjmbSAhaeRv9LJzmt-wyw_eXixfJ0P3535YEw%40mail.gmail.com.

Re: [weewx-user] How to limit syslog logging

[LeaF]

tk
Thanks for the observation.  I'll do some snooping around the bme280 and 
see what I can find. 

(It's not only syslog getting overwhelmed with entries, but debug and user 
log files are filled with the same info)

Thanks
Lee

On Wednesday, January 20, 2021 at 10:50:01 AM UTC-8 tke...@gmail.com wrote:

> It looks like an extension you are using, bme280, is what is creating the 
> chatter. Unfortunately, from the little log snippet you gave, it does not 
> appear to be WeeWX V4 compliant, so muzzling it will not be as easy as a 
> weewx.conf setting. You could ask the author to update it to V4, then you 
> could follow the directions in the Wiki article *WeeWX V4 and logging 
> *.
>
> OTOH, fortunately, it looks like the log entry is a debug entry, so 
> setting debug=0 in weewx.conf should help reduce the number of entries.
>
> -tk
>
>
>
> On Wed, Jan 20, 2021 at 10:39 AM LeaF  wrote:
>
>> I have a question regarding what goes into the /var/log/syslog file.
>>
>> I’m running the latest version of weewx on a Raspberry Pi 4.  My station 
>> is a Peet Bros Ultimeter 100. I also added a Adafruit BME280 breakout board 
>> to measure pressure and humidity.  
>>
>> This all works very well.  Thank you
>>
>> When I run sudo tail -f /var/log/syslog, there appears to be three 
>> entries per second being written to the log file.  So as you can 
>> imagine, the log file has a lot of info that I don’t want in there.  Any 
>> errors are being written to weewx.log file.
>>
>> How can I limit what is going to the log file so they don’t grow so large?  
>> I looked at rsyslog.conf, but don’t know if this is the correct place to 
>> limit the log entries. 
>>
>> Example, one entry into log file:
>>
>>  Jan 20 10:22:47 WeatherPi /weewxd: bme280: {'dateTime': 1611166967, 
>> 'usUnits': 1, 'windSpeed': 0.0, 'windDir': 55.058796, 'outTemp': 
>> 38.304, 'rain_total': 0.5, 'barometer': None, 'inTemp': None, 
>> 'outHumidity': 77.02371597125266, 'inHumidity': None, 'day_of_year': 19, 
>> 'minute_of_day': 620, 'daily_rain': 0.0, 'wind_average': 0.0, 'rain': 0.0, 
>> 'pressure': 29.53154056121909}
>>
>> Thanks for your help.
>>
>> Lee
>>
>> -- 
>> 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/7c9cae95-4bcd-4dd6-b293-2113d6a5054cn%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/08c304c3-aa29-4a12-a1ac-d0824643d2f7n%40googlegroups.com.

Re: [weewx-user] How to limit syslog logging

[Tom Keffer]

It looks like an extension you are using, bme280, is what is creating the
chatter. Unfortunately, from the little log snippet you gave, it does not
appear to be WeeWX V4 compliant, so muzzling it will not be as easy as a
weewx.conf setting. You could ask the author to update it to V4, then you
could follow the directions in the Wiki article *WeeWX V4 and logging
*.

OTOH, fortunately, it looks like the log entry is a debug entry, so setting
debug=0 in weewx.conf should help reduce the number of entries.

-tk



On Wed, Jan 20, 2021 at 10:39 AM LeaF  wrote:

> I have a question regarding what goes into the /var/log/syslog file.
>
> I’m running the latest version of weewx on a Raspberry Pi 4.  My station
> is a Peet Bros Ultimeter 100. I also added a Adafruit BME280 breakout board
> to measure pressure and humidity.
>
> This all works very well.  Thank you
>
> When I run sudo tail -f /var/log/syslog, there appears to be three entries
> per second being written to the log file.  So as you can imagine, the log
> file has a lot of info that I don’t want in there.  Any errors are being
> written to weewx.log file.
>
> How can I limit what is going to the log file so they don’t grow so large?
> I looked at rsyslog.conf, but don’t know if this is the correct place to
> limit the log entries.
>
> Example, one entry into log file:
>
>  Jan 20 10:22:47 WeatherPi /weewxd: bme280: {'dateTime': 1611166967,
> 'usUnits': 1, 'windSpeed': 0.0, 'windDir': 55.058796, 'outTemp':
> 38.304, 'rain_total': 0.5, 'barometer': None, 'inTemp': None,
> 'outHumidity': 77.02371597125266, 'inHumidity': None, 'day_of_year': 19,
> 'minute_of_day': 620, 'daily_rain': 0.0, 'wind_average': 0.0, 'rain': 0.0,
> 'pressure': 29.53154056121909}
>
> Thanks for your help.
>
> Lee
>
> --
> 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/7c9cae95-4bcd-4dd6-b293-2113d6a5054cn%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/CAPq0zECcXdfBenZ8Jhunn4s%3D%3DuB3DArb5u%2BO4eB1B6TyKH6j9g%40mail.gmail.com.

[weewx-user] How to limit syslog logging

[LeaF]

 

I have a question regarding what goes into the /var/log/syslog file.

I’m running the latest version of weewx on a Raspberry Pi 4.  My station is 
a Peet Bros Ultimeter 100. I also added a Adafruit BME280 breakout board to 
measure pressure and humidity.  

This all works very well.  Thank you

When I run sudo tail -f /var/log/syslog, there appears to be three entries 
per second being written to the log file.  So as you can imagine, the log 
file has a lot of info that I don’t want in there.  Any errors are being 
written to weewx.log file.

How can I limit what is going to the log file so they don’t grow so large?  I 
looked at rsyslog.conf, but don’t know if this is the correct place to 
limit the log entries. 

Example, one entry into log file:

 Jan 20 10:22:47 WeatherPi /weewxd: bme280: {'dateTime': 1611166967, 
'usUnits': 1, 'windSpeed': 0.0, 'windDir': 55.058796, 'outTemp': 
38.304, 'rain_total': 0.5, 'barometer': None, 'inTemp': None, 
'outHumidity': 77.02371597125266, 'inHumidity': None, 'day_of_year': 19, 
'minute_of_day': 620, 'daily_rain': 0.0, 'wind_average': 0.0, 'rain': 0.0, 
'pressure': 29.53154056121909}

Thanks for your help.

Lee

-- 
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/7c9cae95-4bcd-4dd6-b293-2113d6a5054cn%40googlegroups.com.

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

[garrya...@gmail.com]

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

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

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

Regards,

Garry

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

> Well FWIW, it's not Belchertown.I took my minimalist demo-skin and 
> aded the one include line in it and boy does it grow.
>
> Two tests with a restart that's obvious.
>
> On Wednesday, January 20, 2021 at 7:07:23 AM UTC-8 garrya...@gmail.com 
> wrote:
>
>> I haven’t made any changes yet but in thinking about your workaround, it 
>> will be interesting to see if Cheetah actuality processes the included 
>> include file or if it skips it because the outer include file’s attributes 
>> are static.
>>
>> If Cheetah doesn’t process the inner include file, it still should be a 
>> way to inject the ‘raw’ argument without having to edit ‘index.html.tmpl’. 
>>  That is, my code would generate both the outer and inner include files 
>> each cycle, with the outer include file containing the ‘raw’ argument as 
>> you suggest.
>>
>> Regards,
>>
>> Garry Lockyer
>> C: +1.250.689.0686 <(250)%20689-0686>
>> E: ga...@lockyer.ca
>>
>>
>> On Jan 20, 2021, at 06:24, bell...@gmail.com  wrote:
>>
>> Note, it is growing - just much slower.
>>
>>
>>
>> On Wednesday, 20 January 2021 at 09:13:35 UTC-5 bell...@gmail.com wrote:
>>
>>> Garry,
>>> I might have a workaround for you. Wrap your html file in a template. 
>>> something like this.
>>> index.html.tmp (this is in the belchertown skin)
>>> #include index_hook_after_charts.inc
>>>
>>> index_hook_after_charts.inc (this is the 'wrapper', naturally if you 
>>> 'owned' index.html.tmpl you would not need it)
>>> #include raw generated.html
>>>
>>> generated.html (the file you generate - name as you want)
>>> your html
>>>
>>> I ran this on my loop 10,000 times and saw no appreciable memory 
>>> increase and performed better too.
>>> rich
>>>
>>> On Tuesday, 19 January 2021 at 22:45:42 UTC-5 garrya...@gmail.com wrote:
>>>
 Many thanks to all for poking at this!


 Regards,

 Garry Lockyer
 C: +1.250.689.0686 <(250)%20689-0686>
 E: ga...@lockyer.ca


 On Jan 19, 2021, at 19:38, vince  wrote:

 Just a followup - I took belchertown out of the picture and used my 
 minimal demo-skin and added 'one line' that #include(d) a file generated 
 by 
 Garry's service, and it 'is' leaking memory albeit less quickly than the 
 belchertown example.


 I'll let it run overnight and we'll see what it looks like after 12 
 more hours running.   The VM is set to only 1GB RAM but I'm hoping if it 
 runs out it'll just go into swap and stay up.OS is debian 10 under 
 Vagrant/VirtualBox with 4.3.0 installed using python3 and setup.py

 Some mem.sdb output (date/time, units, interval, mem_size, mem_rss, 
 mem_share)...

 1611109216 16 5 141.0625 71.734375 12.2734375
 1611109516 16 5 142.5625 75.65234375 12.3359375
 1611109816 16 5 144.0625 79.65625 12.3359375
 160116 16 5 145.5625 84.5234375 12.3359375
 160416 16 5 147.24609375 88.0859375 12.3359375
 160716 16 5 148.49609375 91.43359375 12.3359375
 161016 16 5 149.99609375 95.421875 12.3359375
 161316 16 5 151.49609375 100.3359375 12.3359375
 161616 16 5 152.99609375 103.8359375 12.3359375
 161916 16 5 154.49609375 107.51171875 12.3359375
 162216 16 5 155.99609375 111.5 12.3359375
 162516 16 5 157.24609375 116.0859375 12.3359375
 162816 16 5 158.74609375 119.5859375 12.3359375
 163116 16 5 160.24609375 123.24609375 12.3359375
 163416 16 5 161.74609375 127.234375 12.3359375
 163716 16 5 163.24609375 132.11328125 12.3359375



 On Tuesday, January 19, 2021 at 5:21:31 PM UTC-8 bell...@gmail.com 
 wrote:

> Ok, my standalone testcase was wrong. I think I have a valid one here, 
> https://github.com/bellrichm/experiments
> It just calls Cheetah.Template.Template in a loop.  If the include 
> file modified attribute does not change, all seems stable. If it changes, 
> memory usage seems to grow.
> rich
>
> On Tuesday, 19 January 2021 at 19:16:46 UTC-5 tke...@gmail.com wrote:
>
>> I'm not quite following this discussion.
>>
>> With Cheetah, you can compile the template and save the results. I 
>> believe this is what monitors the changed status of #include files. But, 
>> that's not the way WeeWX uses templates. It compiles, evaluates, then 
>> throws the results away. 
>>
>> If you use the "raw" directive in an #include, then the file will not 
>> be parsed. So, how can any $ directives work?
>>
>> Or, does Belchertown work differently?
>>
>> -tk
>>
>> On Tue, Jan 19, 2021 at 3:55 PM bell...@gmail.com  
>> 

Re: [weewx-user] Re: Huge Rainrate

[Tom Keffer]

Ah, there you go. Unless you ask for it, that's not what is going to get
plotted or reported.

On Wed, Jan 20, 2021 at 8:38 AM Karen K  wrote:

> It was the "max" field.
>
> tke...@gmail.com schrieb am Mittwoch, 20. Januar 2021 um 16:15:16 UTC+1:
>
>> Do you recall which field in archive_day_rainRate showed the high value?
>> The schema for that table is
>>
>> CREATE TABLE archive_day_rainRate (dateTime INTEGER NOT NULL UNIQUE
>> PRIMARY KEY, min REAL, mintime INTEGER, max REAL, maxtime INTEGER, sum
>> REAL, count INTEGER, wsum REAL, sumtime INTEGER);
>>
>> If you were looking at column 'max', it would be the maximum value seen
>> during the archive period. This could have come from some LOOP packet. When
>> you rebuild the daily summaries, this value would not be used,
>> explaining your results.
>>
>> -tk
>>
>>
>>
>> On Wed, Jan 20, 2021 at 7:08 AM Karen K  wrote:
>>
>>> Your are right. I looked for "rainrate" but it is "rainRate" (case
>>> sensitive). And "rainRate" is set from the data the WeatherLinkLive device
>>> sends. So it is nothing inside weewx.
>>>
>>> On the other hand the huge value in the summeries table (that the topic
>>> started with) did not come out of the device. And it disappeared by the
>>> rebuild of the daily summeries.
>>>
>>> tke...@gmail.com schrieb am Mittwoch, 20. Januar 2021 um 13:40:34 UTC+1:
>>>
 I'm not familiar with the WeatherLink, but if it's like the other Davis
 products, it emits its own version of rainRate.

 By default, this is what will get used unless you have weewx calculate
 it in software. See the section [[Calculations]]
  in
 weewx.conf

 On Wed, Jan 20, 2021 at 4:32 AM Karen K  wrote:

> The new value was much lower, but still very high. So I looked into
> the database and found that:
>
> sqlite> select dateTime,rain,rainrate from archive where
> dateTime>161096 and dateTime<1610964000;
> 1610960100|0.0|0.0
> 1610960400|0.0|0.0
> 1610960700|0.0|0.0
> 1610961000|0.0|0.0
> 1610961300|0.0|0.0
> 1610961600|0.0|0.0
> 1610961900|0.015748031496063|5.79576771653542
> 1610962200|0.0|0.0666010498687663
> 1610962500|0.0|0.0385498687664041
> 1610962800|0.0|0.0131233595800525
> 1610963100|0.0|0.0
> 1610963400|0.0|0.0
> 1610963700|0.0|0.0
> sqlite>
>
> As I did not find the word 'rainrate' within the driver file
> weatherlinkliveudp.py I guess that the rainrate value is calculated by
> weewx.
> I still wonder what causes those high values.
>
> Karen K schrieb am Mittwoch, 20. Januar 2021 um 13:12:11 UTC+1:
>
>> Now I found time to run
>>   wee_database --rebuild-daily --from=2021-01-17
>> After that, the value was much lower.
>>
>> Karen K schrieb am Dienstag, 19. Januar 2021 um 23:25:07 UTC+1:
>>
>>> Since yesterday I see a huge maximum monthly rainrate of 1280 mm/h.
>>> So I searched the database using sqlite3 command. In archive table 
>>> there is
>>> no such high value. But in archive_day_rainrate table I found a value of
>>> 50.3937007874016. If that were in inch/h, than it would correspond to 
>>> the
>>> value above. It is one single value on 2021-01-18 at midnight 
>>> (00:00:00).
>>>
>>> The next highest value in that table is 1.0931764433. It is much
>>> smaller.
>>>
>>> I wonder if that has to do with the time switching from 23:55:00 to
>>> 00:00:00 in that very archive interval.
>>>
>>> It is version 4.2.0. No other problems observed.
>>>
>>> Is that a known issue?
>>>
>>> I will try to re-calculate summaries tomorrow.
>>>
>>> --
> 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/5ce72e9c-dc29-450b-8478-7e510a4eb65an%40googlegroups.com
> 
> .
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-user+...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/b4d73f19-e627-480b-a389-3b3d91f44a22n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop 

[weewx-user] Re: From MQTT to WeeWX

[Tarmo]

That was easy. Thank you very much, Rich.

On Wednesday, January 20, 2021 at 4:34:20 PM UTC+2 bell...@gmail.com wrote:

> After installation, you will need to update the MQTTSubscribeService to 
> look something like this.
> [MQTTSubscribeService]
> host = replace with your broker
> # any other MQTT options you need, like port, user, password, etc.
>
> [[message_callback]]
>  type = individual
>
> [[topics]]
> unit_system = METRIC
> use_topic_as_fieldname = true
>
> [[[rtl_433/lab/devices/Solight-TE44/1/4/temperature_C]]]
> name = outTemp
> [[[rtl_433/lab/devices/LaCrosse-WS2310/242/humidity]]]
> name = outHumidity
>
> On Wednesday, 20 January 2021 at 06:32:34 UTC-5 Tarmo wrote:
>
>> Update on example payload:
>> {"time":"2021-01-20 
>> 13:28:57","model":"Solight-TE44","id":4,"channel":1,"temperature_C":-7.1,"mic":"CRC"}
>> {"time":"2021-01-20 
>> 13:29:20","model":"LaCrosse-WS2310","id":242,"humidity":78}
>>
>>
>> On Wednesday, January 20, 2021 at 9:44:52 AM UTC+2 Tarmo wrote:
>>
>>> The topics are
>>> rtl_433/lab/devices/Solight-TE44/1/4/temperature_C
>>> rtl_433/lab/devices/LaCrosse-WS2310/242/humidity
>>>
>>> How do I get example payload? I am running Mosquitto.
>>>
>>> On Wednesday, January 20, 2021 at 12:50:02 AM UTC+2 bell...@gmail.com 
>>> wrote:
>>>
 Yeah, it has become a bit complicated.  If you post your topic and an 
 example payload we should be able to get you up and running pretty quickly.
 rich

 On Tuesday, 19 January 2021 at 17:08:18 UTC-5 Tarmo wrote:

> We have a temporary situation here where the Vantage station is not 
> available. Meanwhile, I have access to the MQTT broker with all the 
> measurements from another station.
>
> I would like to keep the Vantage driver running for inside temperature 
> and humidity and add a service augmenting station data with outside 
> measurements from MQTT.
>
> Which service do you recommend for this task? I have briefly looked at 
> Rich's WeeWX-MQTTSubscribe 
>  which looks 
> complicated for a simple query to fetch *outTemp* and *outHumidity* from 
> MQTT and add these to the archive.
>
> Thank you in advance!
>


-- 
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/483715af-0fd8-450f-839c-e3fdbf449bdfn%40googlegroups.com.

Re: [weewx-user] Re: Huge Rainrate

[Karen K]

It was the "max" field.

tke...@gmail.com schrieb am Mittwoch, 20. Januar 2021 um 16:15:16 UTC+1:

> Do you recall which field in archive_day_rainRate showed the high value? 
> The schema for that table is
>
> CREATE TABLE archive_day_rainRate (dateTime INTEGER NOT NULL UNIQUE 
> PRIMARY KEY, min REAL, mintime INTEGER, max REAL, maxtime INTEGER, sum 
> REAL, count INTEGER, wsum REAL, sumtime INTEGER);
>
> If you were looking at column 'max', it would be the maximum value seen 
> during the archive period. This could have come from some LOOP packet. When 
> you rebuild the daily summaries, this value would not be used, 
> explaining your results.
>
> -tk
>
>
>
> On Wed, Jan 20, 2021 at 7:08 AM Karen K  wrote:
>
>> Your are right. I looked for "rainrate" but it is "rainRate" (case 
>> sensitive). And "rainRate" is set from the data the WeatherLinkLive device 
>> sends. So it is nothing inside weewx.
>>
>> On the other hand the huge value in the summeries table (that the topic 
>> started with) did not come out of the device. And it disappeared by the 
>> rebuild of the daily summeries. 
>>
>> tke...@gmail.com schrieb am Mittwoch, 20. Januar 2021 um 13:40:34 UTC+1:
>>
>>> I'm not familiar with the WeatherLink, but if it's like the other Davis 
>>> products, it emits its own version of rainRate. 
>>>
>>> By default, this is what will get used unless you have weewx calculate 
>>> it in software. See the section [[Calculations]] 
>>>  in 
>>> weewx.conf
>>>
>>> On Wed, Jan 20, 2021 at 4:32 AM Karen K  wrote:
>>>
 The new value was much lower, but still very high. So I looked into the 
 database and found that:

 sqlite> select dateTime,rain,rainrate from archive where 
 dateTime>161096 and dateTime<1610964000; 
 1610960100|0.0|0.0 
 1610960400|0.0|0.0 
 1610960700|0.0|0.0 
 1610961000|0.0|0.0 
 1610961300|0.0|0.0 
 1610961600|0.0|0.0 
 1610961900|0.015748031496063|5.79576771653542 
 1610962200|0.0|0.0666010498687663 
 1610962500|0.0|0.0385498687664041 
 1610962800|0.0|0.0131233595800525 
 1610963100|0.0|0.0 
 1610963400|0.0|0.0 
 1610963700|0.0|0.0 
 sqlite> 

 As I did not find the word 'rainrate' within the driver file 
 weatherlinkliveudp.py I guess that the rainrate value is calculated by 
 weewx.
 I still wonder what causes those high values.

 Karen K schrieb am Mittwoch, 20. Januar 2021 um 13:12:11 UTC+1:

> Now I found time to run 
>   wee_database --rebuild-daily --from=2021-01-17
> After that, the value was much lower.
>
> Karen K schrieb am Dienstag, 19. Januar 2021 um 23:25:07 UTC+1:
>
>> Since yesterday I see a huge maximum monthly rainrate of 1280 mm/h. 
>> So I searched the database using sqlite3 command. In archive table there 
>> is 
>> no such high value. But in archive_day_rainrate table I found a value of 
>> 50.3937007874016. If that were in inch/h, than it would correspond to 
>> the 
>> value above. It is one single value on 2021-01-18 at midnight 
>> (00:00:00). 
>>
>> The next highest value in that table is 1.0931764433. It is much 
>> smaller.
>>
>> I wonder if that has to do with the time switching from 23:55:00 to 
>> 00:00:00 in that very archive interval.
>>
>> It is version 4.2.0. No other problems observed.
>>
>> Is that a known issue?
>>
>> I will try to re-calculate summaries tomorrow.
>>
>> -- 
 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/5ce72e9c-dc29-450b-8478-7e510a4eb65an%40googlegroups.com
  
 
 .

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/b4d73f19-e627-480b-a389-3b3d91f44a22n%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 

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

[vince]

Well FWIW, it's not Belchertown.I took my minimalist demo-skin and aded 
the one include line in it and boy does it grow.

Two tests with a restart that's obvious.

On Wednesday, January 20, 2021 at 7:07:23 AM UTC-8 garrya...@gmail.com 
wrote:

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

 On Tuesday, 19 January 2021 at 19:16:46 UTC-5 tke...@gmail.com wrote:

> I'm not quite following this discussion.
>
> With Cheetah, you can compile the template and save the results. I 
> believe this is what monitors the changed status of #include files. But, 
> that's not the way WeeWX uses templates. It compiles, evaluates, then 
> throws the results away. 
>
> If you use the "raw" directive in an #include, then the file will not 
> be parsed. So, how can any $ directives work?
>
> Or, does Belchertown work differently?
>
> -tk
>
> On Tue, Jan 19, 2021 at 3:55 PM bell...@gmail.com  
> wrote:
>
>> I agree that something does not seem quite right with Cheetah’s 
>> ‘monitoring’ of include files. I took a different approach.
>> First, I wrote a simple WeeWX service that would perform the ‘touch’ 
>> command against the large file and a simple template that included the 
>> large file. When the file modified attribute changed, I observed the 
>> memory 
>> growth, otherwise all 

Re: [weewx-user] Re: weewx 4.3.0 uses Python 2.7 instead of Python 3

['Rene' via weewx-user]

Thank you very much, the pointer to /etc/default/weewx was the solution. I 
changed the entry from python2 to python3. This then revealed after a 
restart of weewx an error within the forecast extension which led me to 
update the extension which removed the error and finally reports are 
generated again (plus weewx now runs on a current version of python).

tke...@gmail.com schrieb am Mittwoch, 20. Januar 2021 um 13:26:48 UTC+1:

> The file /etc/default/weewx controls which version of Python to use. Look 
> in there.
>
> However, it will not work unless the Python 3 prerequisites have been 
> installed. If they have not, then you are better off following the 
> instructions in the WeeWX Debian guide 
> :
>
> wget -qO - https://weewx.com/apt/weewx-python3.list | sudo tee 
> /etc/apt/sources.list.d/weewx.list
> sudo apt-get update
> sudo apt-get install weewx
>
>
>
> On Wed, Jan 20, 2021 at 3:59 AM 'Rene' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> Just to add that Python 3 works:
>>
>> root@brix:~# python3 --version
>> Python 3.6.9
>>
>> Rene schrieb am Mittwoch, 20. Januar 2021 um 12:56:27 UTC+1:
>>
>>> Hi all,
>>> I'm running weewx 4.3.0 and it still uses Python 2.7 although I have 
>>> installed Python 3 and /usr/bin/weewxd contains:
>>>
>>> #!/bin/sh
>>> app=weewxd
>>>
>>> # Get the weewx location and interpreter.  Default to something sane, but
>>> # look for overrides from the system defaults.
>>> WEEWX_BINDIR=/home/weewx/bin
>>> WEEWX_PYTHON=python3
>>> [ -r /etc/default/weewx ] && . /etc/default/weewx
>>> $WEEWX_PYTHON $WEEWX_BINDIR/$app $*
>>>
>>> From syslog:
>>>
>>> Jan 20 12:47:42 brix systemd[1]: Starting weewx weather system...
>>> Jan 20 12:47:42 brix weewx[26249] INFO __main__: Initializing weewx 
>>> version 4.3.0
>>> Jan 20 12:47:42 brix weewx[26249] INFO __main__: Using Python 2.7.17 
>>> (default, Sep 30 2020, 13:38:04) #012[GCC 7.5.0]
>>> Jan 20 12:47:42 brix weewx[26249] INFO __main__: Platform 
>>> Linux-4.15.0-130-generic-x86_64-with-Ubuntu-18.04-bionic
>>> Jan 20 12:47:42 brix weewx[26249] INFO __main__: Locale is 'de_DE.UTF-8'
>>> Jan 20 12:47:42 brix weewx[26249] INFO __main__: PID file is 
>>> /var/run/weewx.pid
>>> Jan 20 12:47:42 brix weewx[26257] INFO __main__: Using configuration 
>>> file /etc/weewx/weewx.conf
>>> Jan 20 12:47:42 brix weewx[26257] INFO __main__: Debug is 0
>>>
>>> I was looking into the logs because on January 5th weewx stopped 
>>> generating reports. It runs fine otherwise, uploads data to WU and sends 
>>> data with MQTT but no more reports. I think it was the day when I upgraded 
>>> weewx from 4.2.0 to 4.3.0 and wanted to try now if Python 3 fixes the 
>>> issue. There are no errors from weewx in the log.
>>>
>> -- 
>> 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/8982f04c-da2d-4c3f-9686-f06bde9fe16an%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/5a6ed5aa-4264-4a51-81fe-3ce09ca1adafn%40googlegroups.com.

Re: [weewx-user] Re: Huge Rainrate

[Tom Keffer]

Do you recall which field in archive_day_rainRate showed the high value?
The schema for that table is

CREATE TABLE archive_day_rainRate (dateTime INTEGER NOT NULL UNIQUE PRIMARY
KEY, min REAL, mintime INTEGER, max REAL, maxtime INTEGER, sum REAL, count
INTEGER, wsum REAL, sumtime INTEGER);

If you were looking at column 'max', it would be the maximum value seen
during the archive period. This could have come from some LOOP packet. When
you rebuild the daily summaries, this value would not be used,
explaining your results.

-tk



On Wed, Jan 20, 2021 at 7:08 AM Karen K  wrote:

> Your are right. I looked for "rainrate" but it is "rainRate" (case
> sensitive). And "rainRate" is set from the data the WeatherLinkLive device
> sends. So it is nothing inside weewx.
>
> On the other hand the huge value in the summeries table (that the topic
> started with) did not come out of the device. And it disappeared by the
> rebuild of the daily summeries.
>
> tke...@gmail.com schrieb am Mittwoch, 20. Januar 2021 um 13:40:34 UTC+1:
>
>> I'm not familiar with the WeatherLink, but if it's like the other Davis
>> products, it emits its own version of rainRate.
>>
>> By default, this is what will get used unless you have weewx calculate it
>> in software. See the section [[Calculations]]
>>  in weewx.conf
>>
>> On Wed, Jan 20, 2021 at 4:32 AM Karen K  wrote:
>>
>>> The new value was much lower, but still very high. So I looked into the
>>> database and found that:
>>>
>>> sqlite> select dateTime,rain,rainrate from archive where
>>> dateTime>161096 and dateTime<1610964000;
>>> 1610960100|0.0|0.0
>>> 1610960400|0.0|0.0
>>> 1610960700|0.0|0.0
>>> 1610961000|0.0|0.0
>>> 1610961300|0.0|0.0
>>> 1610961600|0.0|0.0
>>> 1610961900|0.015748031496063|5.79576771653542
>>> 1610962200|0.0|0.0666010498687663
>>> 1610962500|0.0|0.0385498687664041
>>> 1610962800|0.0|0.0131233595800525
>>> 1610963100|0.0|0.0
>>> 1610963400|0.0|0.0
>>> 1610963700|0.0|0.0
>>> sqlite>
>>>
>>> As I did not find the word 'rainrate' within the driver file
>>> weatherlinkliveudp.py I guess that the rainrate value is calculated by
>>> weewx.
>>> I still wonder what causes those high values.
>>>
>>> Karen K schrieb am Mittwoch, 20. Januar 2021 um 13:12:11 UTC+1:
>>>
 Now I found time to run
   wee_database --rebuild-daily --from=2021-01-17
 After that, the value was much lower.

 Karen K schrieb am Dienstag, 19. Januar 2021 um 23:25:07 UTC+1:

> Since yesterday I see a huge maximum monthly rainrate of 1280 mm/h. So
> I searched the database using sqlite3 command. In archive table there is 
> no
> such high value. But in archive_day_rainrate table I found a value of
> 50.3937007874016. If that were in inch/h, than it would correspond to the
> value above. It is one single value on 2021-01-18 at midnight (00:00:00).
>
> The next highest value in that table is 1.0931764433. It is much
> smaller.
>
> I wonder if that has to do with the time switching from 23:55:00 to
> 00:00:00 in that very archive interval.
>
> It is version 4.2.0. No other problems observed.
>
> Is that a known issue?
>
> I will try to re-calculate summaries tomorrow.
>
> --
>>> 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/5ce72e9c-dc29-450b-8478-7e510a4eb65an%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/b4d73f19-e627-480b-a389-3b3d91f44a22n%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/CAPq0zECuHFWgRLwLO6ivSqGifjXD0VFVupHzEFpfUDz7Q5zq%3DA%40mail.gmail.com.

Re: [weewx-user] Re: Huge Rainrate

[Karen K]

Your are right. I looked for "rainrate" but it is "rainRate" (case 
sensitive). And "rainRate" is set from the data the WeatherLinkLive device 
sends. So it is nothing inside weewx.

On the other hand the huge value in the summeries table (that the topic 
started with) did not come out of the device. And it disappeared by the 
rebuild of the daily summeries. 

tke...@gmail.com schrieb am Mittwoch, 20. Januar 2021 um 13:40:34 UTC+1:

> I'm not familiar with the WeatherLink, but if it's like the other Davis 
> products, it emits its own version of rainRate. 
>
> By default, this is what will get used unless you have weewx calculate it 
> in software. See the section [[Calculations]] 
>  in weewx.conf
>
> On Wed, Jan 20, 2021 at 4:32 AM Karen K  wrote:
>
>> The new value was much lower, but still very high. So I looked into the 
>> database and found that:
>>
>> sqlite> select dateTime,rain,rainrate from archive where 
>> dateTime>161096 and dateTime<1610964000; 
>> 1610960100|0.0|0.0 
>> 1610960400|0.0|0.0 
>> 1610960700|0.0|0.0 
>> 1610961000|0.0|0.0 
>> 1610961300|0.0|0.0 
>> 1610961600|0.0|0.0 
>> 1610961900|0.015748031496063|5.79576771653542 
>> 1610962200|0.0|0.0666010498687663 
>> 1610962500|0.0|0.0385498687664041 
>> 1610962800|0.0|0.0131233595800525 
>> 1610963100|0.0|0.0 
>> 1610963400|0.0|0.0 
>> 1610963700|0.0|0.0 
>> sqlite> 
>>
>> As I did not find the word 'rainrate' within the driver file 
>> weatherlinkliveudp.py I guess that the rainrate value is calculated by 
>> weewx.
>> I still wonder what causes those high values.
>>
>> Karen K schrieb am Mittwoch, 20. Januar 2021 um 13:12:11 UTC+1:
>>
>>> Now I found time to run 
>>>   wee_database --rebuild-daily --from=2021-01-17
>>> After that, the value was much lower.
>>>
>>> Karen K schrieb am Dienstag, 19. Januar 2021 um 23:25:07 UTC+1:
>>>
 Since yesterday I see a huge maximum monthly rainrate of 1280 mm/h. So 
 I searched the database using sqlite3 command. In archive table there is 
 no 
 such high value. But in archive_day_rainrate table I found a value of 
 50.3937007874016. If that were in inch/h, than it would correspond to the 
 value above. It is one single value on 2021-01-18 at midnight (00:00:00). 

 The next highest value in that table is 1.0931764433. It is much 
 smaller.

 I wonder if that has to do with the time switching from 23:55:00 to 
 00:00:00 in that very archive interval.

 It is version 4.2.0. No other problems observed.

 Is that a known issue?

 I will try to re-calculate summaries tomorrow.

 -- 
>> 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/5ce72e9c-dc29-450b-8478-7e510a4eb65an%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/b4d73f19-e627-480b-a389-3b3d91f44a22n%40googlegroups.com.

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

[Garry A Lockyer]

I haven’t made any changes yet but in thinking about your workaround, it will 
be interesting to see if Cheetah actuality processes the included include file 
or if it skips it because the outer include file’s attributes are static.

If Cheetah doesn’t process the inner include file, it still should be a way to 
inject the ‘raw’ argument without having to edit ‘index.html.tmpl’.  That is, 
my code would generate both the outer and inner include files each cycle, with 
the outer include file containing the ‘raw’ argument as you suggest.

Regards,

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


> On Jan 20, 2021, at 06:24, bell...@gmail.com  wrote:
> 
> Note, it is growing - just much slower.
> 
>> On Wednesday, 20 January 2021 at 09:13:35 UTC-5 bell...@gmail.com wrote:
>> Garry,
>> I might have a workaround for you. Wrap your html file in a template. 
>> something like this.
>> index.html.tmp (this is in the belchertown skin)
>> #include index_hook_after_charts.inc
>> 
>> index_hook_after_charts.inc (this is the 'wrapper', naturally if you 'owned' 
>> index.html.tmpl you would not need it)
>> #include raw generated.html
>> 
>> generated.html (the file you generate - name as you want)
>> your html
>> 
>> I ran this on my loop 10,000 times and saw no appreciable memory increase 
>> and performed better too.
>> rich
>> 
>>> On Tuesday, 19 January 2021 at 22:45:42 UTC-5 garrya...@gmail.com wrote:
>>> Many thanks to all for poking at this!
>>> 
>>> 
>>> Regards,
>>> 
>>> Garry Lockyer
>>> C: +1.250.689.0686
>>> E: ga...@lockyer.ca
>>> 
>>> 
> On Jan 19, 2021, at 19:38, vince  wrote:
> 
 Just a followup - I took belchertown out of the picture and used my 
 minimal demo-skin and added 'one line' that #include(d) a file generated 
 by Garry's service, and it 'is' leaking memory albeit less quickly than 
 the belchertown example.
>>> 
 
 I'll let it run overnight and we'll see what it looks like after 12 more 
 hours running.   The VM is set to only 1GB RAM but I'm hoping if it runs 
 out it'll just go into swap and stay up.OS is debian 10 under 
 Vagrant/VirtualBox with 4.3.0 installed using python3 and setup.py
 
 Some mem.sdb output (date/time, units, interval, mem_size, mem_rss, 
 mem_share)...
 
 1611109216 16  5   141.062571.734375   12.2734375
 1611109516 16  5   142.562575.65234375 12.3359375
 1611109816 16  5   144.062579.6562512.3359375
 160116 16  5   145.562584.5234375  12.3359375
 160416 16  5   147.2460937588.0859375  12.3359375
 160716 16  5   148.4960937591.43359375 12.3359375
 161016 16  5   149.9960937595.421875   12.3359375
 161316 16  5   151.49609375100.3359375 12.3359375
 161616 16  5   152.99609375103.8359375 12.3359375
 161916 16  5   154.49609375107.5117187512.3359375
 162216 16  5   155.99609375111.5   12.3359375
 162516 16  5   157.24609375116.0859375 12.3359375
 162816 16  5   158.74609375119.5859375 12.3359375
 163116 16  5   160.24609375123.2460937512.3359375
 163416 16  5   161.74609375127.234375  12.3359375
 163716 16  5   163.24609375132.1132812512.3359375
 
 
 
> On Tuesday, January 19, 2021 at 5:21:31 PM UTC-8 bell...@gmail.com wrote:
> Ok, my standalone testcase was wrong. I think I have a valid one here, 
> https://github.com/bellrichm/experiments
> It just calls Cheetah.Template.Template in a loop.  If the include file 
> modified attribute does not change, all seems stable. If it changes, 
> memory usage seems to grow.
> rich
> 
>> On Tuesday, 19 January 2021 at 19:16:46 UTC-5 tke...@gmail.com wrote:
>> I'm not quite following this discussion.
>> 
>> With Cheetah, you can compile the template and save the results. I 
>> believe this is what monitors the changed status of #include files. But, 
>> that's not the way WeeWX uses templates. It compiles, evaluates, then 
>> throws the results away. 
>> 
>> If you use the "raw" directive in an #include, then the file will not be 
>> parsed. So, how can any $ directives work?
>> 
>> Or, does Belchertown work differently?
>> 
>> -tk
>> 
>>> On Tue, Jan 19, 2021 at 3:55 PM bell...@gmail.com  
>>> wrote:
>>> I agree that something does not seem quite right with Cheetah’s 
>>> ‘monitoring’ of include files. I took a different approach.
>>> First, I wrote a simple WeeWX service that would perform the ‘touch’ 
>>> command against the large file and a simple template that included the 
>>> large file. When the file modified attribute changed, I observed 

[weewx-user] Re: From MQTT to WeeWX

[bell...@gmail.com]

After installation, you will need to update the MQTTSubscribeService to 
look something like this.
[MQTTSubscribeService]
host = replace with your broker
# any other MQTT options you need, like port, user, password, etc.

[[message_callback]]
 type = individual

[[topics]]
unit_system = METRIC
use_topic_as_fieldname = true

[[[rtl_433/lab/devices/Solight-TE44/1/4/temperature_C]]]
name = outTemp
[[[rtl_433/lab/devices/LaCrosse-WS2310/242/humidity]]]
name = outHumidity

On Wednesday, 20 January 2021 at 06:32:34 UTC-5 Tarmo wrote:

> Update on example payload:
> {"time":"2021-01-20 
> 13:28:57","model":"Solight-TE44","id":4,"channel":1,"temperature_C":-7.1,"mic":"CRC"}
> {"time":"2021-01-20 
> 13:29:20","model":"LaCrosse-WS2310","id":242,"humidity":78}
>
>
> On Wednesday, January 20, 2021 at 9:44:52 AM UTC+2 Tarmo wrote:
>
>> The topics are
>> rtl_433/lab/devices/Solight-TE44/1/4/temperature_C
>> rtl_433/lab/devices/LaCrosse-WS2310/242/humidity
>>
>> How do I get example payload? I am running Mosquitto.
>>
>> On Wednesday, January 20, 2021 at 12:50:02 AM UTC+2 bell...@gmail.com 
>> wrote:
>>
>>> Yeah, it has become a bit complicated.  If you post your topic and an 
>>> example payload we should be able to get you up and running pretty quickly.
>>> rich
>>>
>>> On Tuesday, 19 January 2021 at 17:08:18 UTC-5 Tarmo wrote:
>>>
 We have a temporary situation here where the Vantage station is not 
 available. Meanwhile, I have access to the MQTT broker with all the 
 measurements from another station.

 I would like to keep the Vantage driver running for inside temperature 
 and humidity and add a service augmenting station data with outside 
 measurements from MQTT.

 Which service do you recommend for this task? I have briefly looked at 
 Rich's WeeWX-MQTTSubscribe 
  which looks 
 complicated for a simple query to fetch *outTemp* and *outHumidity* from 
 MQTT and add these to the archive.

 Thank you in advance!

>>>

-- 
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/294d1fd0-4826-402d-9cc8-29c80a83689fn%40googlegroups.com.

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

[Garry A Lockyer]

Very clever!  Thanks!!

I’ll give it a try in a few hours.

Regards,

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


> On Jan 20, 2021, at 06:24, bell...@gmail.com  wrote:
> 
> Note, it is growing - just much slower.
> 
>> On Wednesday, 20 January 2021 at 09:13:35 UTC-5 bell...@gmail.com wrote:
>> Garry,
>> I might have a workaround for you. Wrap your html file in a template. 
>> something like this.
>> index.html.tmp (this is in the belchertown skin)
>> #include index_hook_after_charts.inc
>> 
>> index_hook_after_charts.inc (this is the 'wrapper', naturally if you 'owned' 
>> index.html.tmpl you would not need it)
>> #include raw generated.html
>> 
>> generated.html (the file you generate - name as you want)
>> your html
>> 
>> I ran this on my loop 10,000 times and saw no appreciable memory increase 
>> and performed better too.
>> rich
>> 
>>> On Tuesday, 19 January 2021 at 22:45:42 UTC-5 garrya...@gmail.com wrote:
>>> Many thanks to all for poking at this!
>>> 
>>> 
>>> Regards,
>>> 
>>> Garry Lockyer
>>> C: +1.250.689.0686
>>> E: ga...@lockyer.ca
>>> 
>>> 
> On Jan 19, 2021, at 19:38, vince  wrote:
> 
 Just a followup - I took belchertown out of the picture and used my 
 minimal demo-skin and added 'one line' that #include(d) a file generated 
 by Garry's service, and it 'is' leaking memory albeit less quickly than 
 the belchertown example.
>>> 
 
 I'll let it run overnight and we'll see what it looks like after 12 more 
 hours running.   The VM is set to only 1GB RAM but I'm hoping if it runs 
 out it'll just go into swap and stay up.OS is debian 10 under 
 Vagrant/VirtualBox with 4.3.0 installed using python3 and setup.py
 
 Some mem.sdb output (date/time, units, interval, mem_size, mem_rss, 
 mem_share)...
 
 1611109216 16  5   141.062571.734375   12.2734375
 1611109516 16  5   142.562575.65234375 12.3359375
 1611109816 16  5   144.062579.6562512.3359375
 160116 16  5   145.562584.5234375  12.3359375
 160416 16  5   147.2460937588.0859375  12.3359375
 160716 16  5   148.4960937591.43359375 12.3359375
 161016 16  5   149.9960937595.421875   12.3359375
 161316 16  5   151.49609375100.3359375 12.3359375
 161616 16  5   152.99609375103.8359375 12.3359375
 161916 16  5   154.49609375107.5117187512.3359375
 162216 16  5   155.99609375111.5   12.3359375
 162516 16  5   157.24609375116.0859375 12.3359375
 162816 16  5   158.74609375119.5859375 12.3359375
 163116 16  5   160.24609375123.2460937512.3359375
 163416 16  5   161.74609375127.234375  12.3359375
 163716 16  5   163.24609375132.1132812512.3359375
 
 
 
> On Tuesday, January 19, 2021 at 5:21:31 PM UTC-8 bell...@gmail.com wrote:
> Ok, my standalone testcase was wrong. I think I have a valid one here, 
> https://github.com/bellrichm/experiments
> It just calls Cheetah.Template.Template in a loop.  If the include file 
> modified attribute does not change, all seems stable. If it changes, 
> memory usage seems to grow.
> rich
> 
>> On Tuesday, 19 January 2021 at 19:16:46 UTC-5 tke...@gmail.com wrote:
>> I'm not quite following this discussion.
>> 
>> With Cheetah, you can compile the template and save the results. I 
>> believe this is what monitors the changed status of #include files. But, 
>> that's not the way WeeWX uses templates. It compiles, evaluates, then 
>> throws the results away. 
>> 
>> If you use the "raw" directive in an #include, then the file will not be 
>> parsed. So, how can any $ directives work?
>> 
>> Or, does Belchertown work differently?
>> 
>> -tk
>> 
>>> On Tue, Jan 19, 2021 at 3:55 PM bell...@gmail.com  
>>> wrote:
>>> I agree that something does not seem quite right with Cheetah’s 
>>> ‘monitoring’ of include files. I took a different approach.
>>> First, I wrote a simple WeeWX service that would perform the ‘touch’ 
>>> command against the large file and a simple template that included the 
>>> large file. When the file modified attribute changed, I observed the 
>>> memory growth, otherwise all was stable. Also, when the file was not 
>>> ‘touched’ the Cheetah processing was noticeably faster.
>>> Next I wrote a standalone program to run a loop that ran the touch 
>>> command and invoke Cheetah.  I ran it 3 times. Each time around loop 
>>> 90, the memory growth stopped and the processing was fast as though 
>>> Cheetah was using cached data. 
>>> I am back to running under WeeWX to see if it will level 

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

[bell...@gmail.com]

Note, it is growing - just much slower.

On Wednesday, 20 January 2021 at 09:13:35 UTC-5 bell...@gmail.com wrote:

> Garry,
> I might have a workaround for you. Wrap your html file in a template. 
> something like this.
> index.html.tmp (this is in the belchertown skin)
> #include index_hook_after_charts.inc
>
> index_hook_after_charts.inc (this is the 'wrapper', naturally if you 
> 'owned' index.html.tmpl you would not need it)
> #include raw generated.html
>
> generated.html (the file you generate - name as you want)
> your html
>
> I ran this on my loop 10,000 times and saw no appreciable memory increase 
> and performed better too.
> rich
>
> On Tuesday, 19 January 2021 at 22:45:42 UTC-5 garrya...@gmail.com wrote:
>
>> Many thanks to all for poking at this!
>>
>>
>> Regards,
>>
>> Garry Lockyer
>> C: +1.250.689.0686 <(250)%20689-0686>
>> E: ga...@lockyer.ca
>>
>>
>> On Jan 19, 2021, at 19:38, vince  wrote:
>>
>> Just a followup - I took belchertown out of the picture and used my 
>> minimal demo-skin and added 'one line' that #include(d) a file generated by 
>> Garry's service, and it 'is' leaking memory albeit less quickly than the 
>> belchertown example.
>>
>>
>> I'll let it run overnight and we'll see what it looks like after 12 more 
>> hours running.   The VM is set to only 1GB RAM but I'm hoping if it runs 
>> out it'll just go into swap and stay up.OS is debian 10 under 
>> Vagrant/VirtualBox with 4.3.0 installed using python3 and setup.py
>>
>> Some mem.sdb output (date/time, units, interval, mem_size, mem_rss, 
>> mem_share)...
>>
>> 1611109216 16 5 141.0625 71.734375 12.2734375
>> 1611109516 16 5 142.5625 75.65234375 12.3359375
>> 1611109816 16 5 144.0625 79.65625 12.3359375
>> 160116 16 5 145.5625 84.5234375 12.3359375
>> 160416 16 5 147.24609375 88.0859375 12.3359375
>> 160716 16 5 148.49609375 91.43359375 12.3359375
>> 161016 16 5 149.99609375 95.421875 12.3359375
>> 161316 16 5 151.49609375 100.3359375 12.3359375
>> 161616 16 5 152.99609375 103.8359375 12.3359375
>> 161916 16 5 154.49609375 107.51171875 12.3359375
>> 162216 16 5 155.99609375 111.5 12.3359375
>> 162516 16 5 157.24609375 116.0859375 12.3359375
>> 162816 16 5 158.74609375 119.5859375 12.3359375
>> 163116 16 5 160.24609375 123.24609375 12.3359375
>> 163416 16 5 161.74609375 127.234375 12.3359375
>> 163716 16 5 163.24609375 132.11328125 12.3359375
>>
>>
>>
>> On Tuesday, January 19, 2021 at 5:21:31 PM UTC-8 bell...@gmail.com wrote:
>>
>>> Ok, my standalone testcase was wrong. I think I have a valid one here, 
>>> https://github.com/bellrichm/experiments
>>> It just calls Cheetah.Template.Template in a loop.  If the include file 
>>> modified attribute does not change, all seems stable. If it changes, memory 
>>> usage seems to grow.
>>> rich
>>>
>>> On Tuesday, 19 January 2021 at 19:16:46 UTC-5 tke...@gmail.com wrote:
>>>
 I'm not quite following this discussion.

 With Cheetah, you can compile the template and save the results. I 
 believe this is what monitors the changed status of #include files. But, 
 that's not the way WeeWX uses templates. It compiles, evaluates, then 
 throws the results away. 

 If you use the "raw" directive in an #include, then the file will not 
 be parsed. So, how can any $ directives work?

 Or, does Belchertown work differently?

 -tk

 On Tue, Jan 19, 2021 at 3:55 PM bell...@gmail.com  
 wrote:

> I agree that something does not seem quite right with Cheetah’s 
> ‘monitoring’ of include files. I took a different approach.
> First, I wrote a simple WeeWX service that would perform the ‘touch’ 
> command against the large file and a simple template that included the 
> large file. When the file modified attribute changed, I observed the 
> memory 
> growth, otherwise all was stable. Also, when the file was not ‘touched’ 
> the 
> Cheetah processing was noticeably faster.
> Next I wrote a standalone program to run a loop that ran the touch 
> command and invoke Cheetah.  I ran it 3 times. Each time around loop 90, 
> the memory growth stopped and the processing was fast as though Cheetah 
> was 
> using cached data. 
> I am back to running under WeeWX to see if it will level off like it 
> does standalone. I am also wading through the Cheetah  code and 
> documentation.  As of now, I thoroughly confused. 
> rich
>
> On Tuesday, 19 January 2021 at 15:55:38 UTC-5 garrya...@gmail.com 
> wrote:
>
>> I wasn't happy leaving this is as is so I did some more testing.
>>
>> I looked in /home/weewx/bin/user/belchertown.py for any mention of 
>> the 4 include files it uses to add content - nothing there.
>>
>> So, I looked in /home/weewx/skins/Belchertown/index.html.templ and 
>> found 4 lines that reference the include files - they are of the form:
>>
>>

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

[bell...@gmail.com]

Garry,
I might have a workaround for you. Wrap your html file in a template. 
something like this.
index.html.tmp (this is in the belchertown skin)
#include index_hook_after_charts.inc

index_hook_after_charts.inc (this is the 'wrapper', naturally if you 
'owned' index.html.tmpl you would not need it)
#include raw generated.html

generated.html (the file you generate - name as you want)
your html

I ran this on my loop 10,000 times and saw no appreciable memory increase 
and performed better too.
rich

On Tuesday, 19 January 2021 at 22:45:42 UTC-5 garrya...@gmail.com wrote:

> Many thanks to all for poking at this!
>
>
> Regards,
>
> Garry Lockyer
> C: +1.250.689.0686 <(250)%20689-0686>
> E: ga...@lockyer.ca
>
>
> On Jan 19, 2021, at 19:38, vince  wrote:
>
> Just a followup - I took belchertown out of the picture and used my 
> minimal demo-skin and added 'one line' that #include(d) a file generated by 
> Garry's service, and it 'is' leaking memory albeit less quickly than the 
> belchertown example.
>
>
> I'll let it run overnight and we'll see what it looks like after 12 more 
> hours running.   The VM is set to only 1GB RAM but I'm hoping if it runs 
> out it'll just go into swap and stay up.OS is debian 10 under 
> Vagrant/VirtualBox with 4.3.0 installed using python3 and setup.py
>
> Some mem.sdb output (date/time, units, interval, mem_size, mem_rss, 
> mem_share)...
>
> 1611109216 16 5 141.0625 71.734375 12.2734375
> 1611109516 16 5 142.5625 75.65234375 12.3359375
> 1611109816 16 5 144.0625 79.65625 12.3359375
> 160116 16 5 145.5625 84.5234375 12.3359375
> 160416 16 5 147.24609375 88.0859375 12.3359375
> 160716 16 5 148.49609375 91.43359375 12.3359375
> 161016 16 5 149.99609375 95.421875 12.3359375
> 161316 16 5 151.49609375 100.3359375 12.3359375
> 161616 16 5 152.99609375 103.8359375 12.3359375
> 161916 16 5 154.49609375 107.51171875 12.3359375
> 162216 16 5 155.99609375 111.5 12.3359375
> 162516 16 5 157.24609375 116.0859375 12.3359375
> 162816 16 5 158.74609375 119.5859375 12.3359375
> 163116 16 5 160.24609375 123.24609375 12.3359375
> 163416 16 5 161.74609375 127.234375 12.3359375
> 163716 16 5 163.24609375 132.11328125 12.3359375
>
>
>
> On Tuesday, January 19, 2021 at 5:21:31 PM UTC-8 bell...@gmail.com wrote:
>
>> Ok, my standalone testcase was wrong. I think I have a valid one here, 
>> https://github.com/bellrichm/experiments
>> It just calls Cheetah.Template.Template in a loop.  If the include file 
>> modified attribute does not change, all seems stable. If it changes, memory 
>> usage seems to grow.
>> rich
>>
>> On Tuesday, 19 January 2021 at 19:16:46 UTC-5 tke...@gmail.com wrote:
>>
>>> I'm not quite following this discussion.
>>>
>>> With Cheetah, you can compile the template and save the results. I 
>>> believe this is what monitors the changed status of #include files. But, 
>>> that's not the way WeeWX uses templates. It compiles, evaluates, then 
>>> throws the results away. 
>>>
>>> If you use the "raw" directive in an #include, then the file will not be 
>>> parsed. So, how can any $ directives work?
>>>
>>> Or, does Belchertown work differently?
>>>
>>> -tk
>>>
>>> On Tue, Jan 19, 2021 at 3:55 PM bell...@gmail.com  
>>> wrote:
>>>
 I agree that something does not seem quite right with Cheetah’s 
 ‘monitoring’ of include files. I took a different approach.
 First, I wrote a simple WeeWX service that would perform the ‘touch’ 
 command against the large file and a simple template that included the 
 large file. When the file modified attribute changed, I observed the 
 memory 
 growth, otherwise all was stable. Also, when the file was not ‘touched’ 
 the 
 Cheetah processing was noticeably faster.
 Next I wrote a standalone program to run a loop that ran the touch 
 command and invoke Cheetah.  I ran it 3 times. Each time around loop 90, 
 the memory growth stopped and the processing was fast as though Cheetah 
 was 
 using cached data. 
 I am back to running under WeeWX to see if it will level off like it 
 does standalone. I am also wading through the Cheetah  code and 
 documentation.  As of now, I thoroughly confused. 
 rich

 On Tuesday, 19 January 2021 at 15:55:38 UTC-5 garrya...@gmail.com 
 wrote:

> I wasn't happy leaving this is as is so I did some more testing.
>
> I looked in /home/weewx/bin/user/belchertown.py for any mention of the 
> 4 include files it uses to add content - nothing there.
>
> So, I looked in /home/weewx/skins/Belchertown/index.html.templ and 
> found 4 lines that reference the include files - they are of the form:
>
> #if os.path.exists("index_hook_after_station_info.inc")
> 
> 
> #include "index_hook_after_station_info.inc"
> 
> 
>   

[weewx-user] Re: GW1000 poll interval settings / limitations

[gjr80]

There is no formal lower limit for the polling interval, though in reality 
it is effectively one second plus the time it takes for the driver to poll 
the GW1000, obtain the required data emit the loop packet (the one second 
limit comes from a one second delay in the loop that polls the GW1000). 
It's hard to put a value on the time taken to poll the GW1000 and emit the 
loop packet, largely because the driver runs the data gathering in a 
separate thread and queues data to the driver. I did some rough testing 
tonite on a RPi3B and a VM on my laptop and the driver thread was obtaining 
the necessary data from the GW1000 and presenting it within 0.05 to 0.7 
seconds. I think that puts a practical lower limit around 2 seconds.

I have not tested the driver at such low polling intervals, other than 
setting the laptop VM just now to poll every two seconds. The driver and 
WeeWX appear to continue to operate correctly though I would hardly call 
this a conclusive test. You may well be able to drop the polling interval 
to 0 for 'as fast as possible' operation but I have not tested this.

You are correct that socket timeouts, retry wait and max tries may have an 
impact, it really depends on your system and network. I can't vouch for 
what dropping these to zero will do, this could cause a crash should a 
timeout or retry occur. The other thing to bear in mind is that there is 
not just one call to the GW1000 API to obtain the data for a loop packet. 
There are multiple calls (I can think of at least three and potentially 
there are more), so if there is any contention on your network then you may 
experience multiple timeouts, retries etc.

I guess at the end of the day it's a case of suck it and see. I would 
suggest running WeeWX directly so you can see the loop packets and their 
timestamps (and data).

Gary
On Wednesday, 20 January 2021 at 18:05:53 UTC+10 ward...@gmail.com wrote:

> Question about shortening the poll interval an implications / 
> recommendations...
> My setup is I’ve got 2x GW1000’s both reading lots of “shared” sensors but 
> one reading at WS80 and one reading a WS68. I then have 2x Raspberry Pi’s 
> concurrently, both running the API in driver mode and receiving data from 
> each GW1000 separately into separate Weewx 4 DBs on each Pi. 
>
> My objective is to ensure that all the wind sensor’s data at the reporting 
> frequency it is produced (I mean seconds, not MHz) is captured and loaded 
> into weewx, so that it can get the statistics correct for max/mean etc over 
> the standard 5 min report periods. Otherwise AFAIK some sensor dat is lost 
> as the GW1000’s only make available the latest sensor data readings to own 
> stream services, if the frequency of that push/pull is lower than the 
> sensor frequency (see https://www.wxforum.net/index.php?topic=41201.0).
>
> So... I was planning to set the poll_interval of the API pointing at the 
> “WS80’s GW1000” to say 4s or 5s (WS80 updates every 4.8s), and the “WS68’s 
> GW1000” to 16s (WS68 updates every 16.5s).
>
> I could not see any restrictions on doing this in the wiki/docs, but I was 
> potentially concerned in overloading the servers particularly the GW1000’s. 
> I was wondering 
> - if this is feasible (e.g. no lower limit?), 
> - if you have tested this at higher frequencies, and 
> - if you have any recommendations on doing this or not, or other settings 
> changes with higher frequencies? E.g. socket_timeout, max_tries, retry_wait 
> (all which I was planning on leaving as-is)
>
> Thanks!
>

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

Re: [weewx-user] Re: Huge Rainrate

[Tom Keffer]

I'm not familiar with the WeatherLink, but if it's like the other Davis
products, it emits its own version of rainRate.

By default, this is what will get used unless you have weewx calculate it
in software. See the section [[Calculations]]
 in weewx.conf

On Wed, Jan 20, 2021 at 4:32 AM Karen K  wrote:

> The new value was much lower, but still very high. So I looked into the
> database and found that:
>
> sqlite> select dateTime,rain,rainrate from archive where
> dateTime>161096 and dateTime<1610964000;
> 1610960100|0.0|0.0
> 1610960400|0.0|0.0
> 1610960700|0.0|0.0
> 1610961000|0.0|0.0
> 1610961300|0.0|0.0
> 1610961600|0.0|0.0
> 1610961900|0.015748031496063|5.79576771653542
> 1610962200|0.0|0.0666010498687663
> 1610962500|0.0|0.0385498687664041
> 1610962800|0.0|0.0131233595800525
> 1610963100|0.0|0.0
> 1610963400|0.0|0.0
> 1610963700|0.0|0.0
> sqlite>
>
> As I did not find the word 'rainrate' within the driver file
> weatherlinkliveudp.py I guess that the rainrate value is calculated by
> weewx.
> I still wonder what causes those high values.
>
> Karen K schrieb am Mittwoch, 20. Januar 2021 um 13:12:11 UTC+1:
>
>> Now I found time to run
>>   wee_database --rebuild-daily --from=2021-01-17
>> After that, the value was much lower.
>>
>> Karen K schrieb am Dienstag, 19. Januar 2021 um 23:25:07 UTC+1:
>>
>>> Since yesterday I see a huge maximum monthly rainrate of 1280 mm/h. So I
>>> searched the database using sqlite3 command. In archive table there is no
>>> such high value. But in archive_day_rainrate table I found a value of
>>> 50.3937007874016. If that were in inch/h, than it would correspond to the
>>> value above. It is one single value on 2021-01-18 at midnight (00:00:00).
>>>
>>> The next highest value in that table is 1.0931764433. It is much
>>> smaller.
>>>
>>> I wonder if that has to do with the time switching from 23:55:00 to
>>> 00:00:00 in that very archive interval.
>>>
>>> It is version 4.2.0. No other problems observed.
>>>
>>> Is that a known issue?
>>>
>>> I will try to re-calculate summaries tomorrow.
>>>
>>> --
> 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/5ce72e9c-dc29-450b-8478-7e510a4eb65an%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/CAPq0zEBWj%2B_vGR3GK0SudFu8svrMdw2%2BmxzuVMEho8fAuytHHQ%40mail.gmail.com.

[weewx-user] Re: Huge Rainrate

[Karen K]

>From /etc/weewx.conf:

[Station]
station_type = WeatherLinkLiveUDP

# Options for extension 'WeatherLinkLiveUDP' 
[WeatherLinkLiveUDP] 
wll_ip = XXX.XXX.XXX.XXX 
poll_interval = 10 
driver = user.weatherlinkliveudp 
hardware = Davis Vantage Pro2

Karen K schrieb am Mittwoch, 20. Januar 2021 um 13:32:08 UTC+1:

> The new value was much lower, but still very high. So I looked into the 
> database and found that:
>
> sqlite> select dateTime,rain,rainrate from archive where 
> dateTime>161096 and dateTime<1610964000; 
> 1610960100|0.0|0.0 
> 1610960400|0.0|0.0 
> 1610960700|0.0|0.0 
> 1610961000|0.0|0.0 
> 1610961300|0.0|0.0 
> 1610961600|0.0|0.0 
> 1610961900|0.015748031496063|5.79576771653542 
> 1610962200|0.0|0.0666010498687663 
> 1610962500|0.0|0.0385498687664041 
> 1610962800|0.0|0.0131233595800525 
> 1610963100|0.0|0.0 
> 1610963400|0.0|0.0 
> 1610963700|0.0|0.0 
> sqlite> 
>
> As I did not find the word 'rainrate' within the driver file 
> weatherlinkliveudp.py I guess that the rainrate value is calculated by 
> weewx.
> I still wonder what causes those high values.
>
> Karen K schrieb am Mittwoch, 20. Januar 2021 um 13:12:11 UTC+1:
>
>> Now I found time to run 
>>   wee_database --rebuild-daily --from=2021-01-17
>> After that, the value was much lower.
>>
>> Karen K schrieb am Dienstag, 19. Januar 2021 um 23:25:07 UTC+1:
>>
>>> Since yesterday I see a huge maximum monthly rainrate of 1280 mm/h. So I 
>>> searched the database using sqlite3 command. In archive table there is no 
>>> such high value. But in archive_day_rainrate table I found a value of 
>>> 50.3937007874016. If that were in inch/h, than it would correspond to the 
>>> value above. It is one single value on 2021-01-18 at midnight (00:00:00). 
>>>
>>> The next highest value in that table is 1.0931764433. It is much 
>>> smaller.
>>>
>>> I wonder if that has to do with the time switching from 23:55:00 to 
>>> 00:00:00 in that very archive interval.
>>>
>>> It is version 4.2.0. No other problems observed.
>>>
>>> Is that a known issue?
>>>
>>> I will try to re-calculate summaries tomorrow.
>>>
>>>

-- 
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/7b4ff860-16bd-48f5-9d22-37e13662eb3bn%40googlegroups.com.

[weewx-user] Re: Huge Rainrate

[Karen K]

The new value was much lower, but still very high. So I looked into the 
database and found that:

sqlite> select dateTime,rain,rainrate from archive where 
dateTime>161096 and dateTime<1610964000; 
1610960100|0.0|0.0 
1610960400|0.0|0.0 
1610960700|0.0|0.0 
1610961000|0.0|0.0 
1610961300|0.0|0.0 
1610961600|0.0|0.0 
1610961900|0.015748031496063|5.79576771653542 
1610962200|0.0|0.0666010498687663 
1610962500|0.0|0.0385498687664041 
1610962800|0.0|0.0131233595800525 
1610963100|0.0|0.0 
1610963400|0.0|0.0 
1610963700|0.0|0.0 
sqlite> 

As I did not find the word 'rainrate' within the driver file 
weatherlinkliveudp.py I guess that the rainrate value is calculated by 
weewx.
I still wonder what causes those high values.

Karen K schrieb am Mittwoch, 20. Januar 2021 um 13:12:11 UTC+1:

> Now I found time to run 
>   wee_database --rebuild-daily --from=2021-01-17
> After that, the value was much lower.
>
> Karen K schrieb am Dienstag, 19. Januar 2021 um 23:25:07 UTC+1:
>
>> Since yesterday I see a huge maximum monthly rainrate of 1280 mm/h. So I 
>> searched the database using sqlite3 command. In archive table there is no 
>> such high value. But in archive_day_rainrate table I found a value of 
>> 50.3937007874016. If that were in inch/h, than it would correspond to the 
>> value above. It is one single value on 2021-01-18 at midnight (00:00:00). 
>>
>> The next highest value in that table is 1.0931764433. It is much 
>> smaller.
>>
>> I wonder if that has to do with the time switching from 23:55:00 to 
>> 00:00:00 in that very archive interval.
>>
>> It is version 4.2.0. No other problems observed.
>>
>> Is that a known issue?
>>
>> I will try to re-calculate summaries tomorrow.
>>
>>

-- 
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/5ce72e9c-dc29-450b-8478-7e510a4eb65an%40googlegroups.com.

Re: [weewx-user] Re: weewx 4.3.0 uses Python 2.7 instead of Python 3

[Tom Keffer]

The file /etc/default/weewx controls which version of Python to use. Look
in there.

However, it will not work unless the Python 3 prerequisites have been
installed. If they have not, then you are better off following the
instructions in the WeeWX Debian guide
:

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



On Wed, Jan 20, 2021 at 3:59 AM 'Rene' via weewx-user <
weewx-user@googlegroups.com> wrote:

> Just to add that Python 3 works:
>
> root@brix:~# python3 --version
> Python 3.6.9
>
> Rene schrieb am Mittwoch, 20. Januar 2021 um 12:56:27 UTC+1:
>
>> Hi all,
>> I'm running weewx 4.3.0 and it still uses Python 2.7 although I have
>> installed Python 3 and /usr/bin/weewxd contains:
>>
>> #!/bin/sh
>> app=weewxd
>>
>> # Get the weewx location and interpreter.  Default to something sane, but
>> # look for overrides from the system defaults.
>> WEEWX_BINDIR=/home/weewx/bin
>> WEEWX_PYTHON=python3
>> [ -r /etc/default/weewx ] && . /etc/default/weewx
>> $WEEWX_PYTHON $WEEWX_BINDIR/$app $*
>>
>> From syslog:
>>
>> Jan 20 12:47:42 brix systemd[1]: Starting weewx weather system...
>> Jan 20 12:47:42 brix weewx[26249] INFO __main__: Initializing weewx
>> version 4.3.0
>> Jan 20 12:47:42 brix weewx[26249] INFO __main__: Using Python 2.7.17
>> (default, Sep 30 2020, 13:38:04) #012[GCC 7.5.0]
>> Jan 20 12:47:42 brix weewx[26249] INFO __main__: Platform
>> Linux-4.15.0-130-generic-x86_64-with-Ubuntu-18.04-bionic
>> Jan 20 12:47:42 brix weewx[26249] INFO __main__: Locale is 'de_DE.UTF-8'
>> Jan 20 12:47:42 brix weewx[26249] INFO __main__: PID file is
>> /var/run/weewx.pid
>> Jan 20 12:47:42 brix weewx[26257] INFO __main__: Using configuration file
>> /etc/weewx/weewx.conf
>> Jan 20 12:47:42 brix weewx[26257] INFO __main__: Debug is 0
>>
>> I was looking into the logs because on January 5th weewx stopped
>> generating reports. It runs fine otherwise, uploads data to WU and sends
>> data with MQTT but no more reports. I think it was the day when I upgraded
>> weewx from 4.2.0 to 4.3.0 and wanted to try now if Python 3 fixes the
>> issue. There are no errors from weewx in the log.
>>
> --
> 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/8982f04c-da2d-4c3f-9686-f06bde9fe16an%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/CAPq0zEDTTGHUkr62W2AnT5J9pTaaVEWUey2gz_6EQYQha%2Bwy-Q%40mail.gmail.com.

[weewx-user] Re: Huge Rainrate

[Karen K]

Now I found time to run 
  wee_database --rebuild-daily --from=2021-01-17
After that, the value was much lower.

Karen K schrieb am Dienstag, 19. Januar 2021 um 23:25:07 UTC+1:

> Since yesterday I see a huge maximum monthly rainrate of 1280 mm/h. So I 
> searched the database using sqlite3 command. In archive table there is no 
> such high value. But in archive_day_rainrate table I found a value of 
> 50.3937007874016. If that were in inch/h, than it would correspond to the 
> value above. It is one single value on 2021-01-18 at midnight (00:00:00). 
>
> The next highest value in that table is 1.0931764433. It is much 
> smaller.
>
> I wonder if that has to do with the time switching from 23:55:00 to 
> 00:00:00 in that very archive interval.
>
> It is version 4.2.0. No other problems observed.
>
> Is that a known issue?
>
> I will try to re-calculate summaries tomorrow.
>
>

-- 
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/1888c8d4-7aa3-4b1d-8862-e07a3e377931n%40googlegroups.com.

[weewx-user] Re: weewx 4.3.0 uses Python 2.7 instead of Python 3

['Rene' via weewx-user]

Just to add that Python 3 works:

root@brix:~# python3 --version
Python 3.6.9

Rene schrieb am Mittwoch, 20. Januar 2021 um 12:56:27 UTC+1:

> Hi all,
> I'm running weewx 4.3.0 and it still uses Python 2.7 although I have 
> installed Python 3 and /usr/bin/weewxd contains:
>
> #!/bin/sh
> app=weewxd
>
> # Get the weewx location and interpreter.  Default to something sane, but
> # look for overrides from the system defaults.
> WEEWX_BINDIR=/home/weewx/bin
> WEEWX_PYTHON=python3
> [ -r /etc/default/weewx ] && . /etc/default/weewx
> $WEEWX_PYTHON $WEEWX_BINDIR/$app $*
>
> From syslog:
>
> Jan 20 12:47:42 brix systemd[1]: Starting weewx weather system...
> Jan 20 12:47:42 brix weewx[26249] INFO __main__: Initializing weewx 
> version 4.3.0
> Jan 20 12:47:42 brix weewx[26249] INFO __main__: Using Python 2.7.17 
> (default, Sep 30 2020, 13:38:04) #012[GCC 7.5.0]
> Jan 20 12:47:42 brix weewx[26249] INFO __main__: Platform 
> Linux-4.15.0-130-generic-x86_64-with-Ubuntu-18.04-bionic
> Jan 20 12:47:42 brix weewx[26249] INFO __main__: Locale is 'de_DE.UTF-8'
> Jan 20 12:47:42 brix weewx[26249] INFO __main__: PID file is 
> /var/run/weewx.pid
> Jan 20 12:47:42 brix weewx[26257] INFO __main__: Using configuration file 
> /etc/weewx/weewx.conf
> Jan 20 12:47:42 brix weewx[26257] INFO __main__: Debug is 0
>
> I was looking into the logs because on January 5th weewx stopped 
> generating reports. It runs fine otherwise, uploads data to WU and sends 
> data with MQTT but no more reports. I think it was the day when I upgraded 
> weewx from 4.2.0 to 4.3.0 and wanted to try now if Python 3 fixes the 
> issue. There are no errors from weewx in the log.
>

-- 
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/8982f04c-da2d-4c3f-9686-f06bde9fe16an%40googlegroups.com.

[weewx-user] weewx 4.3.0 uses Python 2.7 instead of Python 3

['Rene' via weewx-user]

Hi all,
I'm running weewx 4.3.0 and it still uses Python 2.7 although I have 
installed Python 3 and /usr/bin/weewxd contains:

#!/bin/sh
app=weewxd

# Get the weewx location and interpreter.  Default to something sane, but
# look for overrides from the system defaults.
WEEWX_BINDIR=/home/weewx/bin
WEEWX_PYTHON=python3
[ -r /etc/default/weewx ] && . /etc/default/weewx
$WEEWX_PYTHON $WEEWX_BINDIR/$app $*

>From syslog:

Jan 20 12:47:42 brix systemd[1]: Starting weewx weather system...
Jan 20 12:47:42 brix weewx[26249] INFO __main__: Initializing weewx version 
4.3.0
Jan 20 12:47:42 brix weewx[26249] INFO __main__: Using Python 2.7.17 
(default, Sep 30 2020, 13:38:04) #012[GCC 7.5.0]
Jan 20 12:47:42 brix weewx[26249] INFO __main__: Platform 
Linux-4.15.0-130-generic-x86_64-with-Ubuntu-18.04-bionic
Jan 20 12:47:42 brix weewx[26249] INFO __main__: Locale is 'de_DE.UTF-8'
Jan 20 12:47:42 brix weewx[26249] INFO __main__: PID file is 
/var/run/weewx.pid
Jan 20 12:47:42 brix weewx[26257] INFO __main__: Using configuration file 
/etc/weewx/weewx.conf
Jan 20 12:47:42 brix weewx[26257] INFO __main__: Debug is 0

I was looking into the logs because on January 5th weewx stopped generating 
reports. It runs fine otherwise, uploads data to WU and sends data with 
MQTT but no more reports. I think it was the day when I upgraded weewx from 
4.2.0 to 4.3.0 and wanted to try now if Python 3 fixes the issue. There are 
no errors from weewx in the log.

-- 
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/46dbbd6f-2689-4462-8b73-6575bc5e2b55n%40googlegroups.com.

[weewx-user] Re: From MQTT to WeeWX

[Tarmo]

Update on example payload:
{"time":"2021-01-20 
13:28:57","model":"Solight-TE44","id":4,"channel":1,"temperature_C":-7.1,"mic":"CRC"}
{"time":"2021-01-20 
13:29:20","model":"LaCrosse-WS2310","id":242,"humidity":78}


On Wednesday, January 20, 2021 at 9:44:52 AM UTC+2 Tarmo wrote:

> The topics are
> rtl_433/lab/devices/Solight-TE44/1/4/temperature_C
> rtl_433/lab/devices/LaCrosse-WS2310/242/humidity
>
> How do I get example payload? I am running Mosquitto.
>
> On Wednesday, January 20, 2021 at 12:50:02 AM UTC+2 bell...@gmail.com 
> wrote:
>
>> Yeah, it has become a bit complicated.  If you post your topic and an 
>> example payload we should be able to get you up and running pretty quickly.
>> rich
>>
>> On Tuesday, 19 January 2021 at 17:08:18 UTC-5 Tarmo wrote:
>>
>>> We have a temporary situation here where the Vantage station is not 
>>> available. Meanwhile, I have access to the MQTT broker with all the 
>>> measurements from another station.
>>>
>>> I would like to keep the Vantage driver running for inside temperature 
>>> and humidity and add a service augmenting station data with outside 
>>> measurements from MQTT.
>>>
>>> Which service do you recommend for this task? I have briefly looked at 
>>> Rich's WeeWX-MQTTSubscribe 
>>>  which looks 
>>> complicated for a simple query to fetch *outTemp* and *outHumidity* from 
>>> MQTT and add these to the archive.
>>>
>>> Thank you in advance!
>>>
>>

-- 
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/c160afaf-2fa0-4eb7-a167-173d93e31e6an%40googlegroups.com.

Re: [weewx-user] Re: Wmr 200 rain gauge replacement

[Johann Destombes]

Thanks everyone, 
I will definitly look at the Ecowitt GW1000 solution. 



Le mardi 19 janvier 2021 à 19:11:56 UTC+1, tke...@gmail.com a écrit :

> Just to pile on, let me mention the WMR200 is no longer supported by 
> WeeWX. The API and driver are too frustrating.
>
> On Tue, Jan 19, 2021 at 9:04 AM galfert  wrote:
>
>> Going from a WMR200 to a Netatmo is just one bad decision after another. 
>> If you need something within a reasonable price range that is compatible 
>> with WeeWX then look into the Ecowitt GW1000 and its vast amount of sensor 
>> options.
>>
>> If your WMR200 has had its rain gauge stop working then I think it is 
>> about time to replace the whole thing. You aren't getting very good data 
>> from the other sensors of the the WMR200 anyway. Its like that old TV that 
>> just stinks but you won't get rid of if because it isn't broken. Sometimes 
>> it is just time to replace the whole thing to gain many other benefits. I 
>> wish my neighbor would replace their WMR200. Just look at how his station 
>> sticks out like a sore thumb compared to everyone else. This is because the 
>> barometric resolution of the WMR200 is just atrocious at +-1 hPa. The other 
>> sensors are nothing great either. Even the more economical Ecowitt stations 
>> have greatly surpassed the technological capabilities of the WMR200. Its a 
>> generational thing. The Fine Offset clones from back in the WRM200 hey day 
>> were not great either.
>>
>>
>> [image: Bad CWOP neighbor.jpg]
>>
>> On Tuesday, January 19, 2021 at 8:02:47 AM UTC-5 mjenk...@gmail.com 
>> wrote:
>>
>>> I had the worst luck with the WMR rain gauge.  The antenna reception is 
>>> just terrible at best. 
>>> II tried this and it helped some..   
>>> https://images37.fotosik.pl/164/db3fd6d70e345043med.jpg
>>>
>>> I just kept it closer to the house than the weather station.
>>>
>>>
>>> On Tuesday, January 19, 2021 at 5:34:47 AM UTC-6 jdest...@gmail.com 
>>> wrote:
>>>
 Hi everyone,
 I am using Weewx on an rpi3 and my WMR200 station for a while now. The 
 WMR200 station is working quite well exept the rain gauge who don't want 
 to 
 work outside. I figure it out to sync correctly inside my house but 
 outside 
 the station lose sync after few hours.

 I looked for a replacement but I think the rain gauge PCR800 is no 
 longuer manufactured by Oregon scientific. I am look for a rain gauge who 
 can work with my actual setup, I read that the Natatmo rain gauge is OK 
 with Weewx. 

 Is that true ? and is there another solution to record rain ?

 Thanks in advance! 
 Sorry for my poor English
 --
 Johann


 -- 
>> 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/f47e2c91-4538-4b1d-a774-4a21d195b65cn%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/f708dce6-04c6-4a07-9e48-5faf176aa37fn%40googlegroups.com.

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

[Mike Revitt]

I am in the process of industrialising my backups, but this script works 
from the command line and may give you an idea of how to backup your 
database without having to stop and start weewx. I will shortly have a post 
up on how to do this once I have it working properly

On Wednesday, January 20, 2021 at 3:39:11 AM UTC peterq...@gmail.com wrote:

> I don't know anything, but I can google...
>
> https://stackoverflow.com/questions/311691/importing-a-sqlite3-dump-back-into-the-database
>
>
> On Tue, Jan 19, 2021 at 7:35 PM Kevin Chapman  wrote:
>
>> Ok the file command is showing the backups to be large ASCII files.  The 
>> backup command script is using the sqlite3 .dump command.  The ascii files 
>> are the SQL commands to rebuild the file.  Here is the code.
>>
>>
>> echo 'stop the weewx daemon and wait 30 seconds'
>> sudo /usr/sbin/service weewx stop
>> retn_code=$?
>> if [ $retn_code -ne 0 ]; then
>>   exit 7
>> fi
>>
>> sleep 30s
>>
>> echo 'dump sqlite3 database'
>> echo '.dump' | sqlite3 $WEEWX_DB | gzip -c > $DUMP_FILE
>>
>> echo 'restart the weewx daemon'
>> sudo /usr/sbin/service weewx start
>>
>> I am not good with sqlite.  I have read a few different sites talking 
>> about how to read a dump file into a database.  So far I am not having luck 
>> recovering my database.  If anyone has a site they trust or have a quick 
>> command for recovering sqlite dump files it would be much appreciated.  So 
>> far when I run sqlite3   and then .read   It seems to run 
>> but in about 30 seconds ends at the prompt with no errors on screen and the 
>> database file is empty.  
>>
>> Thank you all for your input and time.  
>>
>> On Monday, January 18, 2021 at 9:20:59 PM UTC-6 vince wrote:
>>
>>> On Monday, January 18, 2021 at 6:47:09 PM UTC-8 kdch...@gmail.com wrote:
>>>
 Now when I try to copy the unpacked sdb and pick up where I left off I 
 get a message that the file is not a database.  I have tried a couple of 
 archives from Dec and Jan.  All seem to be no good.  I did notice that 
 when 
 I reinstalled weewx it is now version 4.3.0.  Could I be dealing with a 
 system version mismatch in the file or is there something wrong with my 
 backup process.  

>>>
>>> Very likely a backup process issue, although the steps you mentioned 
>>> looked good to me.
>>>
>>> We'd need to see some actual logs or terminal errors to know for certain 
>>> what you're actually seeing.
>>>
>>> I guess what I'd do is:
>>>
>>>- grab a recent backup, copy it to a scratch directory
>>>- uncompress it to a .sdb file
>>>- run 'file' against the .sdb file
>>>- If it shows up as a sqlite3 db, then you can validate it with the 
>>>sqlite3 utility.
>>>
>>>
>>> Good output looks like
>>>
>>> # file weewx.sdb
>>> weewx.sdb: SQLite 3.x database, last written using SQLite version 3026000
>>>
>>> # echo "pragma integrity_check" | sqlite3 weewx.sdb
>>> ok
>>>
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/52eb0a6c-a7d1-4fcf-9f22-717f6bfe22fdn%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Peter Quinn
> (415)794-2264 <(415)%20794-2264>
>

-- 
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/eec4ea11-5bc5-4296-a1f3-d6b10ea5a38en%40googlegroups.com.
#!/bin/env python3
#---
# Routine Name: weeUpdate.py
# Author:   Mike Revitt
# Date: 19/03/2020
#
# Revision HistoryPush Down List
# ---
# Date| Name| Description
# +-+
# | |
# 17/01/2021  | M Revitt| Initial version
#-+-+
# Description:  Takes a backup of a running SQLite3 database
#
# Issues:   None
#
# 

[weewx-user] Re: Generate failed with exception ''

[Mike Revitt]

Thanks all,

You gave me the pointers on where to look and the issue was the sed command 
I was using, it as also updating group_altitude

sed -i "s:altitude =.*:altitude = $WEEWX_ALTITUDE:g"
/home/weewx/weewx.conf
Changing it to 

sed -i "s: altitude =.*: altitude = $WEEWX_ALTITUDE:g"
/home/weewx/weewx.conf

fixed the problem.

I was also meaning to send you a note Vince as I did indeed create my 
User-Data script off of your script and was going to say I had an 
improvement for you over the sed commands you use. These now work and are


sed -i 's: location =.*: location = "'"$WEEWX_NAME"'":g' 
/home/weewx/weewx.conf
sed -i "s: longitude =.*: longitude = $WEEWX_LONGITUDE:g" 
/home/weewx/weewx.conf
sed -i "s: latitude =.*: latitude = $WEEWX_LATITUDE:g" 
/home/weewx/weewx.conf
sed -i "s: altitude =.*: altitude = $WEEWX_ALTITUDE:g" 
/home/weewx/weewx.conf
sed -i "s: archive_interval =.*: archive_interval = 60:g" 
/home/weewx/weewx.conf

The space after the colon is very important as I discovered.

This is my User-Data script if you are interested, also sets up the 
environment and installs RDP so I can Remote Desktop in

On Tuesday, January 19, 2021 at 6:23:34 PM UTC vince wrote:

> Just a guess but did you mess with which units or locale settings ?   
> You're in the UK, correct ?
>
> If you can try a test, run my debian10 provisioner script (link) 
> 
>  after 
> stopping weewx and moving your existing /home/weewx tree aside.  This will 
> also install+configure nginx so you might want to comment out those parts 
> of the script if you already have your webserver installed+setup.
>
>

-- 
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/657da236-3d2c-4538-bfda-b636aa47df23n%40googlegroups.com.


UserData-Debian-WeeWX.sh
Description: application/shellscript

[weewx-user] GW1000 poll interval settings / limitations

[Paul Ward]

Question about shortening the poll interval an implications / 
recommendations...
My setup is I’ve got 2x GW1000’s both reading lots of “shared” sensors but 
one reading at WS80 and one reading a WS68. I then have 2x Raspberry Pi’s 
concurrently, both running the API in driver mode and receiving data from 
each GW1000 separately into separate Weewx 4 DBs on each Pi. 

My objective is to ensure that all the wind sensor’s data at the reporting 
frequency it is produced (I mean seconds, not MHz) is captured and loaded 
into weewx, so that it can get the statistics correct for max/mean etc over 
the standard 5 min report periods. Otherwise AFAIK some sensor dat is lost 
as the GW1000’s only make available the latest sensor data readings to own 
stream services, if the frequency of that push/pull is lower than the 
sensor frequency (see https://www.wxforum.net/index.php?topic=41201.0).

So... I was planning to set the poll_interval of the API pointing at the 
“WS80’s GW1000” to say 4s or 5s (WS80 updates every 4.8s), and the “WS68’s 
GW1000” to 16s (WS68 updates every 16.5s).

I could not see any restrictions on doing this in the wiki/docs, but I was 
potentially concerned in overloading the servers particularly the GW1000’s. 
I was wondering 
- if this is feasible (e.g. no lower limit?), 
- if you have tested this at higher frequencies, and 
- if you have any recommendations on doing this or not, or other settings 
changes with higher frequencies? E.g. socket_timeout, max_tries, retry_wait 
(all which I was planning on leaving as-is)

Thanks!

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