Re: [weewx-development] 4.0.0b18: Error in python3 setup build

[Thomas Keffer]

You either don't have setuptools installed, or you have an old version.

python3 -m pip install --upgrade setuptools

Frankly, I'm finding setuptools more of a pain than a help and am thinking
of abandoning it.

-tk

On Mon, Apr 13, 2020 at 3:01 PM Pat  wrote:

> Not sure why I'm seeing this today, I haven't seen it with other builds.
> weewx seems to be working fine regardless?
>
> root@nebula:~/weewx-4.0.0b18# python3 setup.py build
> /usr/lib/python3.6/distutils/dist.py:261: UserWarning: Unknown
> distribution option: 'long_description_content_type'
>   warnings.warn(msg)
> running build
> running build_py
> running build_scripts
>
>
>
> Then python3 setup.py install runs it's install
>
> root@nebula:~/weewx-4.0.0b18# service weewx status
> ● weewx.service - LSB: weewx weather system
>Loaded: loaded (/etc/init.d/weewx; generated)
>Active: active (running) since Mon 2020-04-13 17:58:05 EDT; 1min 53s
> ago
>  Docs: man:systemd-sysv-generator(8)
>   Process: 20137 ExecStop=/etc/init.d/weewx stop (code=exited, status=0/
> SUCCESS)
>   Process: 20159 ExecStart=/etc/init.d/weewx start (code=exited, status=0/
> SUCCESS)
> Tasks: 8 (limit: 4702)
>CGroup: /system.slice/weewx.service
>└─20187 /usr/bin/python3 /home/weewx/bin/weewxd --daemon --
> pidfile=/var/run/weewx.pid /home/weewx/weewx.conf
>
>
> Apr 13 17:58:05 nebula weewx[20182] INFO __main__: Initializing weewx
> version 4.0.0b18
> Apr 13 17:58:05 nebula weewx[20182] INFO __main__: Using Python 3.6.9
> (default, Nov  7 2019, 10:44:02) #012[GCC 8.3.0]
> Apr 13 17:58:05 nebula weewx[20182] INFO __main__: Platform
> Linux-4.15.0-96-generic-x86_64-with-Ubuntu-18.04-bionic
> Apr 13 17:58:05 nebula weewx[20182] INFO __main__: Locale is 'C.UTF-8'
> 
> Apr 13 17:58:10 nebula /weewxd[20187]: restx: MQTT: desired unit system is
> US
> Apr 13 17:58:10 nebula /weewxd[20187]: restx: MQTT: network 
> encryption/authentication
> will be attempted
> Apr 13 17:58:10 nebula /weewxd[20187]: restx: Windy: version is 0.31
> Apr 13 17:58:10 nebula /weewxd[20187]: restx: Windy: Data will be
> uploaded to https://stations.windy.com/pws/update
> Apr 13 17:58:10 nebula weewxd[20187]: weewx[20187] INFO __main__: Starting
> up weewx version 4.0.0b18
> Apr 13 17:58:12 nebula weewxd[20187]: weewx[20187] INFO weewx.engine:
> Clock error is -0.11 seconds (positive is fast)
> Apr 13 17:58:12 nebula weewxd[20187]: weewx[20187] INFO weewx.engine:
> Using binding 'wx_binding' to database 'weewx'
> Apr 13 17:58:12 nebula weewxd[20187]: weewx[20187] INFO weewx.manager:
> Starting backfill of daily summaries
> Apr 13 17:58:14 nebula weewxd[20187]: weewx[20187] INFO weewx.engine:
> Starting main packet loop.
>
> Something I should be concerned with?
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/10a705db-4c93-423f-8f68-96fcbecfb9d7%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] Some variables are not calculated automatically in version 4.0.0b18

[Thomas Keffer]

Take a look: it's in not only changes.txt, but also the *Upgrading Guide.*

Luc, let me remind you: this is *beta* software. Don't use it if you're
worried about data loss.

-tk

On Sun, Apr 12, 2020 at 10:34 AM Lucas Heijst  wrote:

> Tom,
>
> OK, clear. I’m fine with that.
>
> Could you please make a note in the changes document that this feature has
> gone and that one manually must add the corresponding lines to the
> weewx.conf file?
>
> Now, unfortunately, I miss 14 days of values for humidex, appTemp,
> cloudbase, windrun and maxSolarRad.
>
> Luc
>
> On Sunday, 12 April 2020 13:40:40 UTC-3, Tom Keffer wrote:
>>
>> It  was removed because not all weewx installations deal with weather. It
>> makes no sense to try and calculate 'barometer' in an installation that
>> monitors energy use.
>>
>> On Sun, Apr 12, 2020 at 8:24 AM Lucas Heijst  wrote:
>>
>>> Sorry Tom,
>>>
>>> I was wrong. The change happened between version 4.0.0a4 and 4.0.0b13
>>> (the versions in between I didn't download)
>>>
>>> Version 4.0.0a4 had in wxservices a section _dispatch_list which 'did
>>> the trick' of the automatic calculations, see below.
>>> So my question is: why is this feature removed?
>>>
>>> Luc
>>>
>>> Part of wxservices 4.0.0.a4
>>> ==
>>> # these are the quantities that this service knows how to calculate
>>> _dispatch_list = [
>>> 'pressure', # pressure must be before altimeter
>>> 'barometer',
>>> 'altimeter',
>>> 'windchill',
>>> 'heatindex',
>>> 'dewpoint',
>>> 'inDewpoint',
>>> 'rainRate',
>>> 'maxSolarRad',
>>> 'cloudbase',
>>> 'humidex',
>>> 'appTemp',
>>> #'beaufort',
>>> 'ET',
>>> 'windrun',
>>> ]
>>> ==
>>>
>>>
>>> On Sunday, 12 April 2020 12:00:03 UTC-3, Tom Keffer wrote:

 Luc, download the file weewx-4.0.0b18.tar.gz
 
 from the weewx downloads directory. The entries are not commented out. I
 don't know where you got your copy.

 I'll check into cloudbase.

 -tk


 On Sun, Apr 12, 2020 at 7:55 AM Lucas Heijst  wrote:

> See the differences of both versions of wxservices in the attachment.
>
> As an example how it used to work in version 4.0.0b14 and earlier:
> To have the value of 'cloudbase' calculated automatically, you had to
> add the field 'cloudbase' to the database.
> No other actions were needed.
>
> Since the change in wxservices.py (4.0.0b17 and later) you have to add
> the line:
> cloudbase = prefer_hardware
> yourself to the [[Calculations]] section of weewx.conf
>
> Luc
>
> On Sunday, 12 April 2020 11:39:52 UTC-3, Tom Keffer wrote:
>>
>> Not sure what you are referring to. If you look at the current
>> version of weewx.conf
>> , as well as
>> the version in the weewx-4.0.0b18.tar.gz tarball, the options are not
>> commented out.
>>
>> -tk
>>
>> On Sun, Apr 12, 2020 at 6:39 AM Lucas Heijst 
>> wrote:
>>
>>> Tom,
>>>
>>> In version 4.0.0b18 the follwing settings are commented out in
>>> wxservices:
>>>
>>> [[Calculations]]
>>> # Order matters! Type 'pressure' must come before
>>> 'altimeter' and 'barometer'
>>> # pressure = prefer_hardware
>>> # altimeter = prefer_hardware
>>> # appTemp = prefer_hardware
>>> # barometer = prefer_hardware
>>> # beaufort = prefer_hardware
>>> # cloudbase = prefer_hardware
>>> # dewpoint = prefer_hardware
>>> # ET = prefer_hardware
>>> # heatindex = prefer_hardware
>>> # humidex = prefer_hardware
>>> # inDewpoint = prefer_hardware
>>> # maxSolarRad = prefer_hardware
>>> # rainRate = prefer_hardware
>>> # windchill = prefer_hardware
>>> # windrun = prefer_hardware
>>>
>>> While they were not commented out in version 4.0.0.b14 and earlier.
>>>
>>> As a result the values of cloudbase, maxSolarRad, appTemp, humidex
>>> (and others) are nor calculated automatically anymore in version 
>>> 4.0.0b18
>>> I had to add them explicitely in the [Calculations] section of
>>> weewx.conf.
>>>
>>> What is the reason of this change?
>>>
>>> Luc
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-development" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to weewx-de...@googlegroups.com.
>>> To view this discussion on the web visit
>>> 

Re: [weewx-development] Weewx update checks weewx.conf, but no other weewx*.conf files.

[Thomas Keffer]

It's possible to do it using the tool wee_config. For example (NOT TESTED):

cd /home/weewx
python3 ./bin/wee_config --upgrade --config=weewx_vpro.conf
--dist-config=weewx.conf.4.0.0b18 --output=weewx_vpro_conf.new

# (Check over weewx_vpro_conf.new, then)

mv weewx_vpro.conf weewx_vpro.conf.backup
mv weewx_vpro.conf.new weewx_vpro.conf


-tk

On Sun, Apr 12, 2020 at 8:41 AM Lucas Heijst  wrote:

> Tom,
>
> On several of my systems more than one weewx instance is run, so I have
> created a weewx.conf for each instance like:
> weewx_vpro.conf (vantage driver)
> weewx_mstk.conf (meteostick driver)
> weewx_klim.conf (klimalogg driver)
> weewx_rtld.conf (rtldavis driver)
> weewx_tfrc.conf (tfrec driver)
> weewx_mben.conf (modbus energy driver)
> weewx_cmon.conf (computer monitor driver)
>
> With an update of weewx only the file 'weewx.conf' is checked and changed.
>
> Would it be difficult to check and change all weewx*.conf files in the
> /home/weewx directory as well?
> Now I have to rename them one by one to weewx.conf, do the upgrade and
> rename them back afterwards.
>
> Luc
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/a62bc30b-2fea-48e0-be73-1f59c66bb9e2%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] Some variables are not calculated automatically in version 4.0.0b18

[Thomas Keffer]

It  was removed because not all weewx installations deal with weather. It
makes no sense to try and calculate 'barometer' in an installation that
monitors energy use.

On Sun, Apr 12, 2020 at 8:24 AM Lucas Heijst  wrote:

> Sorry Tom,
>
> I was wrong. The change happened between version 4.0.0a4 and 4.0.0b13 (the
> versions in between I didn't download)
>
> Version 4.0.0a4 had in wxservices a section _dispatch_list which 'did the
> trick' of the automatic calculations, see below.
> So my question is: why is this feature removed?
>
> Luc
>
> Part of wxservices 4.0.0.a4
> ==
> # these are the quantities that this service knows how to calculate
> _dispatch_list = [
> 'pressure', # pressure must be before altimeter
> 'barometer',
> 'altimeter',
> 'windchill',
> 'heatindex',
> 'dewpoint',
> 'inDewpoint',
> 'rainRate',
> 'maxSolarRad',
> 'cloudbase',
> 'humidex',
> 'appTemp',
> #'beaufort',
> 'ET',
> 'windrun',
> ]
> ==
>
>
> On Sunday, 12 April 2020 12:00:03 UTC-3, Tom Keffer wrote:
>>
>> Luc, download the file weewx-4.0.0b18.tar.gz
>> 
>> from the weewx downloads directory. The entries are not commented out. I
>> don't know where you got your copy.
>>
>> I'll check into cloudbase.
>>
>> -tk
>>
>>
>> On Sun, Apr 12, 2020 at 7:55 AM Lucas Heijst  wrote:
>>
>>> See the differences of both versions of wxservices in the attachment.
>>>
>>> As an example how it used to work in version 4.0.0b14 and earlier:
>>> To have the value of 'cloudbase' calculated automatically, you had to
>>> add the field 'cloudbase' to the database.
>>> No other actions were needed.
>>>
>>> Since the change in wxservices.py (4.0.0b17 and later) you have to add
>>> the line:
>>> cloudbase = prefer_hardware
>>> yourself to the [[Calculations]] section of weewx.conf
>>>
>>> Luc
>>>
>>> On Sunday, 12 April 2020 11:39:52 UTC-3, Tom Keffer wrote:

 Not sure what you are referring to. If you look at the current version
 of weewx.conf ,
 as well as the version in the weewx-4.0.0b18.tar.gz tarball, the options
 are not commented out.

 -tk

 On Sun, Apr 12, 2020 at 6:39 AM Lucas Heijst  wrote:

> Tom,
>
> In version 4.0.0b18 the follwing settings are commented out in
> wxservices:
>
> [[Calculations]]
> # Order matters! Type 'pressure' must come before 'altimeter'
> and 'barometer'
> # pressure = prefer_hardware
> # altimeter = prefer_hardware
> # appTemp = prefer_hardware
> # barometer = prefer_hardware
> # beaufort = prefer_hardware
> # cloudbase = prefer_hardware
> # dewpoint = prefer_hardware
> # ET = prefer_hardware
> # heatindex = prefer_hardware
> # humidex = prefer_hardware
> # inDewpoint = prefer_hardware
> # maxSolarRad = prefer_hardware
> # rainRate = prefer_hardware
> # windchill = prefer_hardware
> # windrun = prefer_hardware
>
> While they were not commented out in version 4.0.0.b14 and earlier.
>
> As a result the values of cloudbase, maxSolarRad, appTemp, humidex
> (and others) are nor calculated automatically anymore in version 4.0.0b18
> I had to add them explicitely in the [Calculations] section of
> weewx.conf.
>
> What is the reason of this change?
>
> Luc
>
> --
> You received this message because you are subscribed to the Google
> Groups "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to weewx-de...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/8604aa4a-9efd-403f-ab41-079c4836d447%40googlegroups.com
> 
> .
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-de...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-development/8ee34c40-f1d5-4f04-b593-b430d471d8b3%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.

Re: [weewx-development] Some variables are not calculated automatically in version 4.0.0b18

[Thomas Keffer]

Luc, download the file weewx-4.0.0b18.tar.gz

from the weewx downloads directory. The entries are not commented out. I
don't know where you got your copy.

I'll check into cloudbase.

-tk


On Sun, Apr 12, 2020 at 7:55 AM Lucas Heijst  wrote:

> See the differences of both versions of wxservices in the attachment.
>
> As an example how it used to work in version 4.0.0b14 and earlier:
> To have the value of 'cloudbase' calculated automatically, you had to add
> the field 'cloudbase' to the database.
> No other actions were needed.
>
> Since the change in wxservices.py (4.0.0b17 and later) you have to add the
> line:
> cloudbase = prefer_hardware
> yourself to the [[Calculations]] section of weewx.conf
>
> Luc
>
> On Sunday, 12 April 2020 11:39:52 UTC-3, Tom Keffer wrote:
>>
>> Not sure what you are referring to. If you look at the current version of
>> weewx.conf , as
>> well as the version in the weewx-4.0.0b18.tar.gz tarball, the options are
>> not commented out.
>>
>> -tk
>>
>> On Sun, Apr 12, 2020 at 6:39 AM Lucas Heijst  wrote:
>>
>>> Tom,
>>>
>>> In version 4.0.0b18 the follwing settings are commented out in
>>> wxservices:
>>>
>>> [[Calculations]]
>>> # Order matters! Type 'pressure' must come before 'altimeter'
>>> and 'barometer'
>>> # pressure = prefer_hardware
>>> # altimeter = prefer_hardware
>>> # appTemp = prefer_hardware
>>> # barometer = prefer_hardware
>>> # beaufort = prefer_hardware
>>> # cloudbase = prefer_hardware
>>> # dewpoint = prefer_hardware
>>> # ET = prefer_hardware
>>> # heatindex = prefer_hardware
>>> # humidex = prefer_hardware
>>> # inDewpoint = prefer_hardware
>>> # maxSolarRad = prefer_hardware
>>> # rainRate = prefer_hardware
>>> # windchill = prefer_hardware
>>> # windrun = prefer_hardware
>>>
>>> While they were not commented out in version 4.0.0.b14 and earlier.
>>>
>>> As a result the values of cloudbase, maxSolarRad, appTemp, humidex (and
>>> others) are nor calculated automatically anymore in version 4.0.0b18
>>> I had to add them explicitely in the [Calculations] section of
>>> weewx.conf.
>>>
>>> What is the reason of this change?
>>>
>>> Luc
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-de...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-development/8604aa4a-9efd-403f-ab41-079c4836d447%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/8ee34c40-f1d5-4f04-b593-b430d471d8b3%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEBL-u%2Bv8uW83N9tWqBJ2udXyP66uDgDx4MfVVje2ZTb4A%40mail.gmail.com.

Re: [weewx-development] Some variables are not calculated automatically in version 4.0.0b18

[Thomas Keffer]

Not sure what you are referring to. If you look at the current version of
weewx.conf , as well
as the version in the weewx-4.0.0b18.tar.gz tarball, the options are not
commented out.

-tk

On Sun, Apr 12, 2020 at 6:39 AM Lucas Heijst  wrote:

> Tom,
>
> In version 4.0.0b18 the follwing settings are commented out in wxservices:
>
> [[Calculations]]
> # Order matters! Type 'pressure' must come before 'altimeter' and
> 'barometer'
> # pressure = prefer_hardware
> # altimeter = prefer_hardware
> # appTemp = prefer_hardware
> # barometer = prefer_hardware
> # beaufort = prefer_hardware
> # cloudbase = prefer_hardware
> # dewpoint = prefer_hardware
> # ET = prefer_hardware
> # heatindex = prefer_hardware
> # humidex = prefer_hardware
> # inDewpoint = prefer_hardware
> # maxSolarRad = prefer_hardware
> # rainRate = prefer_hardware
> # windchill = prefer_hardware
> # windrun = prefer_hardware
>
> While they were not commented out in version 4.0.0.b14 and earlier.
>
> As a result the values of cloudbase, maxSolarRad, appTemp, humidex (and
> others) are nor calculated automatically anymore in version 4.0.0b18
> I had to add them explicitely in the [Calculations] section of weewx.conf.
>
> What is the reason of this change?
>
> Luc
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/8604aa4a-9efd-403f-ab41-079c4836d447%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEDkE8iKLQOGh9UpgQV%3DGOhpc%3DAXk3qH_Wh6rz-hXjBYhQ%40mail.gmail.com.

Re: [weewx-development] weewx-historical

[Thomas Keffer]

Good idea. Thanks, Paul!

Commit 5441bec



On Wed, Apr 8, 2020 at 11:19 AM Paul Anderson  wrote:

> This is great I love it!
> Wondering if you would consider extending it slightly with 2 additional
> tags?
>
> historical_min_avg
> historical_max_avg
>
> As mentioned earlier Probably only useful if your database covers many
> years.
> I have done so on my local copy and like it because I can now produce
> output like this:
>
> *Today's Climatological Summary*
> Climatological Period 2006 To 2019
> Normal High Temp 52.7°F
> Normal Low Temp 35.6°F
> Normal Avg Temp 43.9°F
> Record High Temp 66.0°F in 2013
> Record Low Temp 26.1°F in 2011
>
> Attached are my changes.
> Please note I have tested it with sqlite , it seems to produce sane
> expected results. Not test with mysql.
>
> Thanks,
> Paul
>
>
> On Monday, April 6, 2020 at 8:49:42 PM UTC-4, Tom Keffer wrote:
>>
>> Relief! I was hoping there wasn't something subtle that I was missing.
>>
>> On Mon, Apr 6, 2020 at 5:38 PM Vince Skahan  wrote:
>>
>>>
>>> I can confirm this is what was happening
>>> Set my VM to PDT and rebuilt daily and the right results are coming out
>>> now.
>>> Thanks Tom !
>>>
>>> On Sunday, April 5, 2020 at 4:33:24 PM UTC-7, Tom Keffer wrote:

 That's what I'm thinking. It recorded the high for UTC day 6-Apr-2007,
 not local day.

 On Sun, Apr 5, 2020 at 3:52 PM Vince Skahan  wrote:

> It probably more than likely that when I ran rebuild daily after
> extending my schema for v4 that the vm I did that on was utc and running
> off old archive data that was in PDT.
>
> Given the UTC-8 here, if the high was after 4pm local (not unusual)
> wouldn't that be a day offset?  Or would it be the other day off ? Darn
> timezones...
>
>>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-de...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-development/1e8fa790-5373-4459-81b8-da128f4a10c2%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/8cbeb74f-0de9-455f-87e2-6dd99b5c1971%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEBQnic%3DsJ4Tk1wrvVKoPaDfjXTGHyvdN1SiEOO9anRe_Q%40mail.gmail.com.

Re: [weewx-development] weewx-historical

[Thomas Keffer]

Relief! I was hoping there wasn't something subtle that I was missing.

On Mon, Apr 6, 2020 at 5:38 PM Vince Skahan  wrote:

>
> I can confirm this is what was happening
> Set my VM to PDT and rebuilt daily and the right results are coming out
> now.
> Thanks Tom !
>
> On Sunday, April 5, 2020 at 4:33:24 PM UTC-7, Tom Keffer wrote:
>>
>> That's what I'm thinking. It recorded the high for UTC day 6-Apr-2007,
>> not local day.
>>
>> On Sun, Apr 5, 2020 at 3:52 PM Vince Skahan  wrote:
>>
>>> It probably more than likely that when I ran rebuild daily after
>>> extending my schema for v4 that the vm I did that on was utc and running
>>> off old archive data that was in PDT.
>>>
>>> Given the UTC-8 here, if the high was after 4pm local (not unusual)
>>> wouldn't that be a day offset?  Or would it be the other day off ? Darn
>>> timezones...
>>>

>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/1e8fa790-5373-4459-81b8-da128f4a10c2%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEAUsGuaciNekr1RYTnQGF6eUfw%3DLcz8nqq4O%3D6VXV_ETg%40mail.gmail.com.

Re: [weewx-development] weewx-historical

[Thomas Keffer]

OK, I've updated the extension to work with MySQL.

Find it here:
https://github.com/tkeffer/weewx-historical/archive/weewx-historical-0.2.0.tar.gz

-tk

On Sat, Apr 4, 2020 at 4:38 AM Thomas Keffer  wrote:

> Silly me. I don't know what made me think this would work with MySQL ---
> it does not have an equivalent of strftime().
>
> Let me see what I can do.
>
> -tk
>
> On Sat, Apr 4, 2020 at 3:23 AM Hartmut Schweidler 
> wrote:
>
>> Hallo Tom,
>>
>> Today I installed the Historical extension,  the extension does not work
>> with a MYSQL database.
>> my Weewx version 4.0.0b18
>>
>>
>> Max Temp 
>> $day.outTemp.historical_max
>>  im Jahre $day.outTemp.historical_maxtime.format("%Y")
>>
>> an in syslog
>>
>> Apr  4 12:21:12 wetter weewx-weewx[10525] DEBUG user.xrainno: MyXRainNo
>> SLE executed in 1.774 seconds
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>> Generate failed with exception ''
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>  Ignoring template /home/weewx/skins/Basics/trend.html.tmpl
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>  Reason: not enough arguments for format string
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   Traceback (most recent call last):
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>> File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line
>> 238, in execute
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   query = query % args
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   TypeError: not enough arguments for format string
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>> 
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   During handling of the above exception, another exception occurred:
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>> 
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   Traceback (most recent call last):
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>> File "/home/weewx/bin/weedb/mysql.py", line 52, in guarded_fn
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   return fn(*args, **kwargs)
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>> File "/home/weewx/bin/weedb/mysql.py", line 262, in execute
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   self.cursor.execute(mysql_string, tuple(sql_tuple))
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>> File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line
>> 240, in execute
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   self.errorhandler(self, ProgrammingError, str(m))
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>> File "/usr/lib/python3/dist-packages/MySQLdb/connections.py",
>> line 52, in defaulterrorhandler
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   raise errorclass(errorvalue)
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   _mysql_exceptions.ProgrammingError: not enough arguments for
>> format string
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>> 
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   During handling of the above exception, another exception occurred:
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>> 
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   Traceback (most recent call last):
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>> File "/home/weewx/bin/weewx/cheetahgenerator.py", line 323, in
>> generate
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>>   unicode_string = compiled_template.respond()
>> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>> File "_home_weewx_skins_Basics_trend_html_tmpl.py", line 422, in
>> respond
>> Apr  4 12:21

Re: [weewx-development] weewx-historical

[Thomas Keffer]

That's what I'm thinking. It recorded the high for UTC day 6-Apr-2007, not
local day.

On Sun, Apr 5, 2020 at 3:52 PM Vince Skahan  wrote:

> It probably more than likely that when I ran rebuild daily after extending
> my schema for v4 that the vm I did that on was utc and running off old
> archive data that was in PDT.
>
> Given the UTC-8 here, if the high was after 4pm local (not unusual)
> wouldn't that be a day offset?  Or would it be the other day off ? Darn
> timezones...
>
> On Sun, Apr 5, 2020, 3:46 PM Vince Skahan  wrote:
>
>> Actually looks possible.
>>
>> https://www.almanac.com/weather/history/WA/Seattle/2007-04-07
>>
>> Pre jan 2009 I had a LaCrosse that tended to read a few degrees hot in
>> the sun, so yes I could see that date being 75+ here.
>>
>>
>> On Sun, Apr 5, 2020, 3:40 PM Thomas Keffer  wrote:
>>
>>> OK, there's the problem. For whatever reason, the column `maxtime` in
>>> the daily summaries for 5-Apr-2007 has the high temperature for the next
>>> day, 6-Apr-2007.
>>>
>>> This pattern seems to occur sporadically for many other years.
>>>
>>> Do you suppose that your computer was running UTC when the daily
>>> summaries were rebuilt?
>>>
>>> Was your weather station vacationing in Miami in 2007? A high of 79 for
>>> April has got to be very unusual for Seattle! :-)
>>>
>>> -tk
>>>
>>>
>>> -tk
>>>
>>> On Sun, Apr 5, 2020 at 3:23 PM Vince Skahan 
>>> wrote:
>>>
>>>> On Sunday, April 5, 2020 at 3:20:17 PM UTC-7, Tom Keffer wrote:
>>>>>
>>>>> OK, that matches what the historical extension is giving.
>>>>>
>>>>> A few more selects to try
>>>>>
>>>>>
>>>>>
>>>> root@debian:/home/weewx/archive# sqlite3 weewx.sdb
>>>> SQLite version 3.7.13 2012-06-11 02:05:22
>>>> Enter ".help" for instructions
>>>> Enter SQL statements terminated with a ";"
>>>> sqlite> select date(dateTime,'unixepoch','localtime'),
>>>> datetime(`maxtime`,'unixepoch','localtime'),`max` from archive_day_outTemp
>>>> where strftime("%m-%d", dateTime,'unixepoch','localtime')='04-05';
>>>> 2007-04-05|2007-04-06 16:34:00|79.0
>>>> 2008-04-05|2008-04-06 11:29:00|51.3
>>>> 2009-04-05|2009-04-06 17:00:00|71.17
>>>> 2010-04-05|2010-04-06 14:05:00|52.42
>>>> 2011-04-05|2011-04-05 17:50:00|47.7
>>>> 2012-04-05|2012-04-06 16:20:00|55.0
>>>> 2013-04-05|2013-04-05 17:05:00|53.7
>>>> 2014-04-05|2014-04-06 16:45:00|58.4
>>>> 2015-04-05|2015-04-06 16:50:00|57.6
>>>> 2016-04-05|2016-04-06 16:10:00|65.9
>>>> 2017-04-05|2017-04-06 16:25:00|59.6
>>>> 2018-04-05|2018-04-06 16:25:00|68.3
>>>> 2019-04-05|2019-04-06 16:15:00|55.5
>>>> 2020-04-05|2020-04-05 12:22:41|56.6
>>>> sqlite> select datetime(dateTime,'unixepoch','localtime'),outTemp from
>>>> archive where dateTime >1175756400 and dateTime<=1175842800 order by
>>>> outTemp desc limit 1;
>>>> 2007-04-05 17:14:00|72.5
>>>> sqlite> select datetime(dateTime,'unixepoch','localtime'),outTemp from
>>>> archive where dateTime >1175842800 and dateTime<=1175929200 order by
>>>> outTemp desc limit 1;
>>>> 2007-04-06 16:34:00|79.0
>>>> sqlite>
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "weewx-development" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to weewx-development+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/weewx-development/23c39c35-2257-4cbc-a78b-5462c73abc9c%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/weewx-development/23c39c35-2257-4cbc-a78b-5462c73abc9c%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>

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

Re: [weewx-development] weewx-historical

[Thomas Keffer]

OK, there's the problem. For whatever reason, the column `maxtime` in the
daily summaries for 5-Apr-2007 has the high temperature for the next day,
6-Apr-2007.

This pattern seems to occur sporadically for many other years.

Do you suppose that your computer was running UTC when the daily summaries
were rebuilt?

Was your weather station vacationing in Miami in 2007? A high of 79 for
April has got to be very unusual for Seattle! :-)

-tk


-tk

On Sun, Apr 5, 2020 at 3:23 PM Vince Skahan  wrote:

> On Sunday, April 5, 2020 at 3:20:17 PM UTC-7, Tom Keffer wrote:
>>
>> OK, that matches what the historical extension is giving.
>>
>> A few more selects to try
>>
>>
>>
> root@debian:/home/weewx/archive# sqlite3 weewx.sdb
> SQLite version 3.7.13 2012-06-11 02:05:22
> Enter ".help" for instructions
> Enter SQL statements terminated with a ";"
> sqlite> select date(dateTime,'unixepoch','localtime'),
> datetime(`maxtime`,'unixepoch','localtime'),`max` from archive_day_outTemp
> where strftime("%m-%d", dateTime,'unixepoch','localtime')='04-05';
> 2007-04-05|2007-04-06 16:34:00|79.0
> 2008-04-05|2008-04-06 11:29:00|51.3
> 2009-04-05|2009-04-06 17:00:00|71.17
> 2010-04-05|2010-04-06 14:05:00|52.42
> 2011-04-05|2011-04-05 17:50:00|47.7
> 2012-04-05|2012-04-06 16:20:00|55.0
> 2013-04-05|2013-04-05 17:05:00|53.7
> 2014-04-05|2014-04-06 16:45:00|58.4
> 2015-04-05|2015-04-06 16:50:00|57.6
> 2016-04-05|2016-04-06 16:10:00|65.9
> 2017-04-05|2017-04-06 16:25:00|59.6
> 2018-04-05|2018-04-06 16:25:00|68.3
> 2019-04-05|2019-04-06 16:15:00|55.5
> 2020-04-05|2020-04-05 12:22:41|56.6
> sqlite> select datetime(dateTime,'unixepoch','localtime'),outTemp from
> archive where dateTime >1175756400 and dateTime<=1175842800 order by
> outTemp desc limit 1;
> 2007-04-05 17:14:00|72.5
> sqlite> select datetime(dateTime,'unixepoch','localtime'),outTemp from
> archive where dateTime >1175842800 and dateTime<=1175929200 order by
> outTemp desc limit 1;
> 2007-04-06 16:34:00|79.0
> sqlite>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/23c39c35-2257-4cbc-a78b-5462c73abc9c%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEDZZQ%3D8y2Qrztx%2BT%2BVH2mmWZBOOFVDYcNSa%2BThMRtVSZw%40mail.gmail.com.

Re: [weewx-development] weewx-historical

[Thomas Keffer]

OK, that matches what the historical extension is giving.

A few more selects to try

select date(dateTime,'unixepoch','localtime'),
datetime(`maxtime`,'unixepoch','localtime'),`max` from archive_day_outTemp
where strftime("%m-%d", dateTime,'unixepoch','localtime')='04-05';
select datetime(dateTime,'unixepoch','localtime'),outTemp from archive
where dateTime >1175756400 and dateTime<=1175842800 order by outTemp desc
limit 1;
select datetime(dateTime,'unixepoch','localtime'),outTemp from archive
where dateTime >1175842800 and dateTime<=1175929200 order by outTemp desc
limit 1;




On Sun, Apr 5, 2020 at 1:09 PM Vince Skahan  wrote:

> 2007-04-05|79.0
> 2008-04-05|51.3
> 2009-04-05|71.17
> 2010-04-05|52.42
> 2011-04-05|47.7
> 2012-04-05|55.0
> 2013-04-05|53.7
> 2014-04-05|58.4
> 2015-04-05|57.6
> 2016-04-05|65.9
> 2017-04-05|59.6
> 2018-04-05|68.3
> 2019-04-05|55.5
> 2020-04-05|56.6
>
>
> On Sun, Apr 5, 2020 at 1:02 PM Thomas Keffer  wrote:
>
>> can you try the query directly?
>>
>> select date(dateTime,'unixepoch','localtime'), `max` from
>> archive_day_outTemp where strftime("%m-%d",
>> dateTime,'unixepoch','localtime')='04-05';
>>
>> This will tell us the max for each year on 5 April.
>>
>> -tk
>>
>> On Sun, Apr 5, 2020 at 10:37 AM Vince Skahan 
>> wrote:
>>
>>> Finally got around to installing this - too fun !
>>>
>>> Possible bug report - my historical max day as reported by the extention
>>> is off by a day in the extension vs. the NOAA report.
>>>
>>> Look at  https://www.skahan.net/weewx/index.html in the Current
>>> Conditions section of the table for the Historical high and compare it with
>>> the NOAA reports for that month.   The extension reports things as 79.0 F
>>> today (April 5) when the NOAA report has that for April 6.   Off by one
>>> error or a timezone anomaly perhaps ?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-development+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-development/c3f7bd0f-45ea-47a6-9a92-fb52b11594a9%40googlegroups.com
>>> <https://groups.google.com/d/msgid/weewx-development/c3f7bd0f-45ea-47a6-9a92-fb52b11594a9%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>
> --
> -  vinceska...@gmail.com 
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEDxcG1eaKdXZ3LtGyyky%2B9ux7y_-FjSKJJu5k8Y7oTCxA%40mail.gmail.com.

Re: [weewx-development] Reportgenerator 'hangs' with vector plot

[Thomas Keffer]

I had the same issue with my webhost. After 5 years of arguing with them, I
gave up and went to AWS Lightsail .
Cheaper, faster, and I can do anything I want with my instance. Much
happier now.

-tk

On Sun, Apr 5, 2020 at 12:38 PM Lucas Heijst  wrote:

> Vince,
>
> My ISP in the Netherlands doesn't allow the use of rsync.
>
> Luc
>
> On Sunday, 5 April 2020 14:45:40 UTC-3, Vince Skahan wrote:
>>
>> On Friday, April 3, 2020 at 6:56:58 PM UTC-7, Vince Skahan wrote:
>>>
>>> On Friday, April 3, 2020 at 5:24:21 PM UTC-7, Lucas Heijst wrote:
>>>
>>> ftpgenerator: Ftp'd 79 files in 89.01 seconds
>>>
>>>
>>> Also switching from ftp to rsync will dramatically improve how long it
>>> takes to upload things to your remote site.
>>>
>>>
>> Luc - just a data point - this is from my Seagate Dockstar which is a
>> 128MB RAM pogoplug, so far slower than even a model-B pi.  Remote host is
>> my Amazon AWS Lightsail instance on Internet.
>>
>> weeutil.rsyncupload: rsync'd 67 files (962749 bytes) in 1.60 seconds
>>
>>
>> Suggest trying to switch to rsync to perhaps spin your processing up a
>> bit.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/b76e7a49-5817-490e-b2a3-f6f5e8a345e9%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEDvMKcdCX0gESigvupQJCmfaV%2By8TK0kj0Bv5CY3wGfXw%40mail.gmail.com.

Re: [weewx-development] weewx-historical

[Thomas Keffer]

can you try the query directly?

select date(dateTime,'unixepoch','localtime'), `max` from
archive_day_outTemp where strftime("%m-%d",
dateTime,'unixepoch','localtime')='04-05';

This will tell us the max for each year on 5 April.

-tk

On Sun, Apr 5, 2020 at 10:37 AM Vince Skahan  wrote:

> Finally got around to installing this - too fun !
>
> Possible bug report - my historical max day as reported by the extention
> is off by a day in the extension vs. the NOAA report.
>
> Look at  https://www.skahan.net/weewx/index.html in the Current
> Conditions section of the table for the Historical high and compare it with
> the NOAA reports for that month.   The extension reports things as 79.0 F
> today (April 5) when the NOAA report has that for April 6.   Off by one
> error or a timezone anomaly perhaps ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/c3f7bd0f-45ea-47a6-9a92-fb52b11594a9%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] Reportgenerator 'hangs' with vector plot

[Thomas Keffer]

Before you get too excited, make sure the fix still gives the right answer.
It uses a different query strategy.

On Sat, Apr 4, 2020 at 6:17 AM Glenn McKechnie 
wrote:

> Well, that fixed it on this machine!
>
> Back to the 16% mysqld usage with both 'aggregate_type = max' and
> 'aggregate_interval = 300' reinstated in skin.conf
>
> Wouldn't have a fix as smooth as that for covid-19 would you?
>
>
>
> On 04/04/2020, Thomas Keffer  wrote:
> > Luc, could you try the attached version of xtypes.py and see if it makes
> > any difference?
> >
> > -tk
> >
> > On Sat, Apr 4, 2020 at 5:10 AM Lucas Heijst 
> wrote:
> >
> >> Tom, Vince, Glenn,
> >>
> >> Glenn,
> >> Yes, I use external mariadb5 databases.
> >> And no, during the creation of the vector plots the memory use of weewx
> >> is
> >> not much (2.7 %).
> >> Changing the aggregate_interval has effect, but is not the main cause.
> >>
> >> Tom, Vince, Glenn,
> >> The main cause of the slow vector calculation is the aggregate_type =
> max
> >> on windgustvec.
> >> Without the max aggregation all 5 vector plots (6h, day, week, month,
> >> year) took together 24 seconds.
> >>
> >> Generated 76 images for report vproReport in 113.71 seconds
> >>
> >> Luc
> >>
> >> =
> >> [[[hourwindvec]]]
> >> windvec
> >> plot_type  = vector
> >> windgustvec
> >> plot_type  = vector
> >> ###aggregate_type = max
> >> ###aggregate_interval = 900# == 15 min
> >>
> >> [[[daywindvec]]]
> >> windvec
> >> plot_type= vector
> >> windgustvec
> >> plot_type= vector
> >> ###aggregate_type   = max
> >> ###aggregate_interval   = 3600# == 1 hour
> >>
> >> [[[weekwindvec]]]
> >> windvec
> >> plot_type= vector
> >> windgustvec
> >> plot_type= vector
> >> ###aggregate_type   = max
> >>
> >> [[[monthwindvec]]]
> >> windvec
> >> plot_type= vector
> >> windgustvec
> >> plot_type= vector
> >> ###aggregate_type   = max
> >> ###aggregate_interval   = 3600# == 1 hour
> >>
> >> [[[yearwindvec]]]
> >> windvec
> >> plot_type= vector
> >> windgustvec
> >> plot_type= vector
> >> ###aggregate_type   = max
> >> =
> >>
> >>
> >>
> >>
> >> On Friday, 3 April 2020 22:33:50 UTC-3, Glenn McKechnie wrote:
> >>>
> >>> (Sigh, and to the list)
> >>>
> >>> Luc,
> >>>
> >>> I notice a "Launch of report thread aborted: existing report thread
> >>> still running"
> >>>
> >>> Do you use mysql (mariadb)?
> >>> If you do, does its CPU usage (from top) increase?
> >>>
> >>> If so try dropping the aggregate interval = 900 and see if there is a
> >>> difference
> >>>
> >>> On 04/04/2020, Lucas Heijst  wrote:
> >>> > Tom,
> >>> >
> >>> > There was not much info in the syslog, thats why I didnt send it.
> >>> > I included the syslog this time.
> >>> >
> >>> > I was wrong: the reportgenerator didn't hang, only it is VERY slow
> >>> >
> >>> > First I generated all other plots: 71 images in 90 seconds
> >>> > Generated 71 images for report vproReport in 89.58 seconds
> >>> >
> >>> > Then I added a 6-hour vector plot. Extra time for that 6h plot: 70
> >>> seconds
> >>> > Generated 72 images for report vproReport in 159.32 seconds
> >>> >
> >>> > Then added a 24-hour vector plot. Extra time for that 24h vector plot
> >>> 266
> >>> > seconds
> >>> > Generated 73 images for re

Re: [weewx-development] Reportgenerator 'hangs' with vector plot

[Thomas Keffer]

Luc, could you try the attached version of xtypes.py and see if it makes
any difference?

-tk

On Sat, Apr 4, 2020 at 5:10 AM Lucas Heijst  wrote:

> Tom, Vince, Glenn,
>
> Glenn,
> Yes, I use external mariadb5 databases.
> And no, during the creation of the vector plots the memory use of weewx is
> not much (2.7 %).
> Changing the aggregate_interval has effect, but is not the main cause.
>
> Tom, Vince, Glenn,
> The main cause of the slow vector calculation is the aggregate_type = max
> on windgustvec.
> Without the max aggregation all 5 vector plots (6h, day, week, month,
> year) took together 24 seconds.
>
> Generated 76 images for report vproReport in 113.71 seconds
>
> Luc
>
> =
> [[[hourwindvec]]]
> windvec
> plot_type  = vector
> windgustvec
> plot_type  = vector
> ###aggregate_type = max
> ###aggregate_interval = 900# == 15 min
>
> [[[daywindvec]]]
> windvec
> plot_type= vector
> windgustvec
> plot_type= vector
> ###aggregate_type   = max
> ###aggregate_interval   = 3600# == 1 hour
>
> [[[weekwindvec]]]
> windvec
> plot_type= vector
> windgustvec
> plot_type= vector
> ###aggregate_type   = max
>
> [[[monthwindvec]]]
> windvec
> plot_type= vector
> windgustvec
> plot_type= vector
> ###aggregate_type   = max
> ###aggregate_interval   = 3600# == 1 hour
>
> [[[yearwindvec]]]
> windvec
> plot_type= vector
> windgustvec
> plot_type= vector
> ###aggregate_type   = max
> =
>
>
>
>
> On Friday, 3 April 2020 22:33:50 UTC-3, Glenn McKechnie wrote:
>>
>> (Sigh, and to the list)
>>
>> Luc,
>>
>> I notice a "Launch of report thread aborted: existing report thread
>> still running"
>>
>> Do you use mysql (mariadb)?
>> If you do, does its CPU usage (from top) increase?
>>
>> If so try dropping the aggregate interval = 900 and see if there is a
>> difference
>>
>> On 04/04/2020, Lucas Heijst  wrote:
>> > Tom,
>> >
>> > There was not much info in the syslog, thats why I didnt send it.
>> > I included the syslog this time.
>> >
>> > I was wrong: the reportgenerator didn't hang, only it is VERY slow
>> >
>> > First I generated all other plots: 71 images in 90 seconds
>> > Generated 71 images for report vproReport in 89.58 seconds
>> >
>> > Then I added a 6-hour vector plot. Extra time for that 6h plot: 70
>> seconds
>> > Generated 72 images for report vproReport in 159.32 seconds
>> >
>> > Then added a 24-hour vector plot. Extra time for that 24h vector plot
>> 266
>> > seconds
>> > Generated 73 images for report vproReport in 425.79 seconds
>> >
>> > Estimated time for the other vector plots:
>> > week vector plot 31 minutes
>> > month vector plot: 137 minutes
>> > year vector plot: 27 hours
>> >
>> > Luc
>> >
>> >
>> > On Friday, 3 April 2020 20:13:16 UTC-3, Tom Keffer wrote:
>> >>
>> >> Worked fine for me.
>> >>
>> >> Luc: you know better. We need a log! Perhaps the ReportGenerator is
>> not
>> >> finishing before the next report is due? Perhaps the program
>> segfaulted?
>> >> Who knows without a log?
>> >>
>> >> -tk
>> >> [image: image.png]
>> >>
>> >> On Fri, Apr 3, 2020 at 4:09 PM Lucas Heijst > >> > wrote:
>> >>
>> >>> Currently running weewx 4.0.0b18.
>> >>>
>> >>> The reportgenerator hangs (it never finishes) during calculating of
>> the
>> >>> section below.
>> >>>
>> >>> [[[hourwindvec]]]
>> >>> windvec
>> >>> plot_type  = vector
>> >>> windgustvec
>> >>> plot_type  = vector
>> >>> aggregate_type = max
>> >>> aggregate_interval = 900# == 15 min
>> >>>
>> >>> Luc
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google
>> Groups
>> >>>
>> >>> "weewx-development" group.
>> >>> To unsubscribe from this group and stop receiving emails from it,
>> send an
>> >>>
>> >>> email to weewx-de...@googlegroups.com .
>> >>> To view this discussion on the web visit
>> >>>
>> https://groups.google.com/d/msgid/weewx-development/601f87df-cbe7-482c-bf49-722a7a5de7bd%40googlegroups.com
>> >>>
>> >>> <
>> https://groups.google.com/d/msgid/weewx-development/601f87df-cbe7-482c-bf49-722a7a5de7bd%40googlegroups.com?utm_medium=email_source=footer>
>>
>> >>> .
>> >>>
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "weewx-development" group.

Re: [weewx-development] weewx-historical

[Thomas Keffer]

Silly me. I don't know what made me think this would work with MySQL --- it
does not have an equivalent of strftime().

Let me see what I can do.

-tk

On Sat, Apr 4, 2020 at 3:23 AM Hartmut Schweidler 
wrote:

> Hallo Tom,
>
> Today I installed the Historical extension,  the extension does not work
> with a MYSQL database.
> my Weewx version 4.0.0b18
>
>
> Max Temp 
> $day.outTemp.historical_max
>  im Jahre $day.outTemp.historical_maxtime.format("%Y")
>
> an in syslog
>
> Apr  4 12:21:12 wetter weewx-weewx[10525] DEBUG user.xrainno: MyXRainNo
> SLE executed in 1.774 seconds
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> Generate failed with exception ''
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>  Ignoring template /home/weewx/skins/Basics/trend.html.tmpl
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>  Reason: not enough arguments for format string
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   Traceback (most recent call last):
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 238
> , in execute
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   query = query % args
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   TypeError: not enough arguments for format string
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> 
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   During handling of the above exception, another exception occurred:
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> 
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   Traceback (most recent call last):
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> File "/home/weewx/bin/weedb/mysql.py", line 52, in guarded_fn
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   return fn(*args, **kwargs)
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> File "/home/weewx/bin/weedb/mysql.py", line 262, in execute
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   self.cursor.execute(mysql_string, tuple(sql_tuple))
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 240
> , in execute
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   self.errorhandler(self, ProgrammingError, str(m))
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> File "/usr/lib/python3/dist-packages/MySQLdb/connections.py",
> line 52, in defaulterrorhandler
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   raise errorclass(errorvalue)
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   _mysql_exceptions.ProgrammingError: not enough arguments for format
> string
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> 
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   During handling of the above exception, another exception occurred:
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> 
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   Traceback (most recent call last):
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> File "/home/weewx/bin/weewx/cheetahgenerator.py", line 323, in
> generate
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   unicode_string = compiled_template.respond()
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> File "_home_weewx_skins_Basics_trend_html_tmpl.py", line 422, in
> respond
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> File "/usr/lib/python3/dist-packages/Cheetah/Template.py", line
> 1707, in _handleCheetahInclude
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   self._CHEETAH__cheetahIncludes[_includeID].respond(trans)
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> File
> "cheetah__home_weewx_skins_Standard_hes_current_inc_1585994730_8648148_88513.py"
> , line 114, in respond
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> File "/home/weewx/bin/weewx/tags.py", line 347, in __getattr__
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
>   return self._do_query(aggregate_type)
> Apr  4 12:21:12 wetter weewx-weewx[10525] ERROR weewx.cheetahgenerator:
> File 

Re: [weewx-development] Reportgenerator 'hangs' with vector plot

[Thomas Keffer]

Worked fine for me.

Luc: you know better. We need a log! Perhaps the ReportGenerator is not
finishing before the next report is due? Perhaps the program segfaulted?
Who knows without a log?

-tk
[image: image.png]

On Fri, Apr 3, 2020 at 4:09 PM Lucas Heijst  wrote:

> Currently running weewx 4.0.0b18.
>
> The reportgenerator hangs (it never finishes) during calculating of the
> section below.
>
> [[[hourwindvec]]]
> windvec
> plot_type  = vector
> windgustvec
> plot_type  = vector
> aggregate_type = max
> aggregate_interval = 900# == 15 min
>
> Luc
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/601f87df-cbe7-482c-bf49-722a7a5de7bd%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEAHtjAMtN12TcY8Em%2B-w1_n%3DD%3DSpypXD7wWJ93-haNtRA%40mail.gmail.com.

Re: [weewx-development] weewx-historical

[Thomas Keffer]

I had forgotten that, in the absence of anything else, XType plot
aggregations leverage individual scalar aggregations. So, to plot
historical highs and lows, I didn't have to write any code, just get the
skin.conf spec right. Using this:

[[[yearhilow]]]
  image_width = 800
  image_height = 500
  hi
data_type = outTemp
aggregate_type = max
label = High
  low
data_type = outTemp
aggregate_type = min
label = Low
  hist_hi
data_type = outTemp
aggregate_type = historical_max
marker_type = cross
line_type = none
label = Historical High
  hist_lo
data_type = outTemp
aggregate_type = historical_min
marker_type = cross
line_type = none
label = Historical Low Temperature

yields this. This is for 12 years of data.

[image: image.png]

On Mon, Mar 30, 2020 at 8:46 PM gjr80  wrote:

> Not sure I like where this whole Xtypes thing is going. I have a perfectly
> good SLE that does half as much as this with 50% more lines of code that I
> will now have to retire. :)
>
> Gary
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/5f4aa21e-997c-4486-9ddc-cffb9b6433d7%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEBwMZoYmuQZRxw2W%2BUZh8G4DZqxmd-w5U8Hu%2B7HWoEvow%40mail.gmail.com.

[weewx-development] Re: weewx-historical

[Thomas Keffer]

On Mon, Mar 30, 2020 at 9:27 PM Praveen Chandrasekaran <
praveen.c...@gmail.com> wrote:

> Hi,
>
> Can it also be used to give historical highs/lows for a month?
>
> Regards,
> Praveen
>

Not as written, but it would not be very hard to add that feature.

-tk

On Mon, Mar 30, 2020 at 4:36 PM Thomas Keffer  wrote:

> This is a new extension that nicely shows the power of the new XTypes
> extensions in V4.0.
>
> https://github.com/tkeffer/weewx-historical
>
> It creates new aggregation types that allows you to use tags such as
>
> Max temperature for this day: $day.outTemp.historical_max in
> $day.outTemp.historical_maxtime.format("%Y")
>
> This would result in something like:
>
> Max temperature for this day: 64.8°F in 2013
>
>
> Probably only useful if your database covers many years.
>
> Tested on sqlite only. In theory, it should work on MySQL/MariaDB.
>
> My intention is to eventually extend it so it will work for plots as well.
>
> For more about XTypes:
> https://github.com/weewx/weewx/wiki/WeeWX-V4-user-defined-types
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEAT%2Bv5L5r_51YeBc2kycSWrHpzrKiUsb%3DZdYmHz2bSKww%40mail.gmail.com.

[weewx-development] weewx-historical

[Thomas Keffer]

This is a new extension that nicely shows the power of the new XTypes
extensions in V4.0.

https://github.com/tkeffer/weewx-historical

It creates new aggregation types that allows you to use tags such as

Max temperature for this day: $day.outTemp.historical_max in
$day.outTemp.historical_maxtime.format("%Y")

This would result in something like:

Max temperature for this day: 64.8°F in 2013


Probably only useful if your database covers many years.

Tested on sqlite only. In theory, it should work on MySQL/MariaDB.

My intention is to eventually extend it so it will work for plots as well.

For more about XTypes:
https://github.com/weewx/weewx/wiki/WeeWX-V4-user-defined-types

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zECHHV3GUXALxna2a9RVS2n%3DiHL9PSfQe%3D9jObqExgTr2Q%40mail.gmail.com.

Re: [weewx-development] Memory leak in StdReport?

[Thomas Keffer]

1. You are getting memory leaks in 4.0.0 running both Python 2 and Python 3?

2. The biggest architectural differences between v3.9 and v4.0 is in how
derived types are handled (V4 uses the new extensible type system) and in
how strings are handled (v4 uses unicode), The former is pure Python. The
latter is not, but I've got to assume that the Python Software Foundation
has thoroughly debugged that code.

3. Cheetah uses an underlying C library ("NameMapper"). It's possible they
screwed up something in their Python 3 port.

That's all I can think of off the top of my head.

-tk


On Sun, Mar 29, 2020 at 5:11 PM Lucas Heijst  wrote:

> Tom,
>
> I I forgot to say these same set of programs and webcam cronjob were
> running since a year now with weewx 3.9.1, raspian stretch and python2.
> Now they are running weewx 4.00b16-17, raspbian stretch and python2 or
> python3 with the memory problems mentioned.
>
> Luc
>
> On Sunday, 29 March 2020 21:03:03 UTC-3, Lucas Heijst wrote:
>>
>> Tom,
>>
>> Due to memory grow my system crashed after 9-10 days. So I wrote here
>> that I would implement a cron job to restart my system after 5 days.
>> Vice Skahan convinced me to trace down the cause of the memory leaks and
>> that I did.
>>
>> No more, no less.
>>
>> Luc
>>
>> On Sunday, 29 March 2020 20:54:56 UTC-3, Tom Keffer wrote:
>>>
>>> I'm sorry, Luc, not trying to be difficult, but what is your question? I
>>> can't possibly debug your memory leak, especially with the complicated set
>>> of drivers and skins you are running.
>>>
>>> WeeWX itself does not have any memory leaks that I'm aware of. It is
>>> 100% Python, and Python uses garbage collection. If there are circular
>>> references, it can take a while for the interpreter to find unused and
>>> recycle memory, but WeeWX does not use any circular references.
>>>
>>> Here's an example <http://www.threefools.org/weewx/status/index.html>
>>> of a station that has been running continuously for well over a year.
>>> Present memory use is VIRT=75060 RES=37736 SHR=7144. So, very long runtimes
>>> are possible without leaks.
>>>
>>> Net-net, if there are leaks, I am pretty confident they are in the
>>> underlying C libraries.
>>>
>>> -tk
>>>
>>> On Sun, Mar 29, 2020 at 3:50 PM Lucas Heijst  wrote:
>>>
>>>> Tom,
>>>>
>>>> I have experienced two types of memory leak.
>>>> 1. In cronjobs when defining variables without unset them afterwards.
>>>> 2. With weewx reports (mben with 84+ generated graphs each run).
>>>>
>>>> Luc
>>>>
>>>> On Sunday, 29 March 2020 19:10:52 UTC-3, Tom Keffer wrote:
>>>>>
>>>>> By the way, in my experience, these leaks are caused by underlying "C"
>>>>> libraries or, occasionally, by failure of PIL to release graphics resource
>>>>> (such as font handles).
>>>>>
>>>>> On Sun, Mar 29, 2020 at 3:09 PM Thomas Keffer 
>>>>> wrote:
>>>>>
>>>>>> I'm not following. I thought you said you could get rid of the leak
>>>>>> by doing the unsets. If so, is there still a problem?
>>>>>>
>>>>>>
>>>>>> On Sun, Mar 29, 2020 at 8:41 AM Lucas Heijst 
>>>>>> wrote:
>>>>>>
>>>>>>> Tom,
>>>>>>>
>>>>>>> Currently running weewx 4.0.0b17 and analysing the memory leak in my
>>>>>>> pi31 system.
>>>>>>> On the system runs two weewx instances (mben and tfrc) and a
>>>>>>> 5-minute webcam cronjob.
>>>>>>>
>>>>>>> The memory leak of my webcam cronjob task was caused by creating
>>>>>>> variables like:
>>>>>>> WEBCAM_ID=3
>>>>>>> CAMERA=picamera$WEBCAM_ID
>>>>>>> DATETIME=$(date +"%Y-%m-%d %H:%M:%S")
>>>>>>> EPOCH=$(date +"%s")
>>>>>>> ...
>>>>>>>
>>>>>>> The used memory is freed by:
>>>>>>> unset WEBCAM_ID
>>>>>>> unset CAMERA
>>>>>>> unset DATETIME
>>>>>>> unset EPOCH
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>>> The memory leak of the weewx instances mben and tfrc are caused by
>

Re: [weewx-development] Memory leak in StdReport?

[Thomas Keffer]

I'm sorry, Luc, not trying to be difficult, but what is your question? I
can't possibly debug your memory leak, especially with the complicated set
of drivers and skins you are running.

WeeWX itself does not have any memory leaks that I'm aware of. It is 100%
Python, and Python uses garbage collection. If there are circular
references, it can take a while for the interpreter to find unused and
recycle memory, but WeeWX does not use any circular references.

Here's an example <http://www.threefools.org/weewx/status/index.html> of a
station that has been running continuously for well over a year. Present
memory use is VIRT=75060 RES=37736 SHR=7144. So, very long runtimes are
possible without leaks.

Net-net, if there are leaks, I am pretty confident they are in the
underlying C libraries.

-tk

On Sun, Mar 29, 2020 at 3:50 PM Lucas Heijst  wrote:

> Tom,
>
> I have experienced two types of memory leak.
> 1. In cronjobs when defining variables without unset them afterwards.
> 2. With weewx reports (mben with 84+ generated graphs each run).
>
> Luc
>
> On Sunday, 29 March 2020 19:10:52 UTC-3, Tom Keffer wrote:
>>
>> By the way, in my experience, these leaks are caused by underlying "C"
>> libraries or, occasionally, by failure of PIL to release graphics resource
>> (such as font handles).
>>
>> On Sun, Mar 29, 2020 at 3:09 PM Thomas Keffer  wrote:
>>
>>> I'm not following. I thought you said you could get rid of the leak by
>>> doing the unsets. If so, is there still a problem?
>>>
>>>
>>> On Sun, Mar 29, 2020 at 8:41 AM Lucas Heijst  wrote:
>>>
>>>> Tom,
>>>>
>>>> Currently running weewx 4.0.0b17 and analysing the memory leak in my
>>>> pi31 system.
>>>> On the system runs two weewx instances (mben and tfrc) and a 5-minute
>>>> webcam cronjob.
>>>>
>>>> The memory leak of my webcam cronjob task was caused by creating
>>>> variables like:
>>>> WEBCAM_ID=3
>>>> CAMERA=picamera$WEBCAM_ID
>>>> DATETIME=$(date +"%Y-%m-%d %H:%M:%S")
>>>> EPOCH=$(date +"%s")
>>>> ...
>>>>
>>>> The used memory is freed by:
>>>> unset WEBCAM_ID
>>>> unset CAMERA
>>>> unset DATETIME
>>>> unset EPOCH
>>>> ...
>>>>
>>>>
>>>> The memory leak of the weewx instances mben and tfrc are caused by the
>>>> weewx reporting tasks, see data below:
>>>>
>>>> -
>>>> used  time
>>>>  mem
>>>> - -
>>>> 73348 10:30
>>>> 95504 11:07
>>>> 48576 11:38 no webcam, no mben, no tfrc (no increase of memory)
>>>> 56136 11:41 mben without modbus read and modbus service
>>>> 57384 11:43
>>>> 57876 11:44
>>>> 58360 11:45
>>>> 64836 11:47 used memory increased with 6476 due to mben31 report
>>>> 64572 11:48
>>>> 64560 11:49
>>>> 64548 11:50
>>>> 66240 11:51 used memory increased with 1692 due to mben31 report
>>>> 55808 11:53 mben without mben31 report
>>>> 56092 11:54
>>>> 55828 11:55
>>>> 55808 11:56
>>>> 56000 11:57
>>>> 56000 11:58
>>>> 56516 11:59
>>>> 56772 12:00
>>>> 56164 12:02 mben now with modbus service (fully functional; without
>>>> reporting)
>>>> 56436 12:03
>>>> 55920 12:04
>>>> 76056 12:09 mben without mben31 report; tfrc started without tfrc31
>>>> report
>>>> 76388 12:10
>>>> 77084 12:11
>>>> 77248 12:12
>>>> 77432 12:13
>>>> 77312 12:14
>>>> 76908 12:15
>>>> 76976 12:16
>>>> 77268 12:21
>>>> 77248 12:24 hardly any increase of used memory the last 15 minutes
>>>> -
>>>>
>>>> When all reports are disabled, the memory leak on my system is
>>>> practically zero.
>>>>
>>>> Attached the skin settings of mben31.
>>>>
>>>> Any clue how reduce this memory leak?
>>>>
>>>> Luc
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "weewx-development" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to weewx-de...@googlegroups.com.
>>>> To view this discussion on the web visit
>>

Re: [weewx-development] Memory leak in StdReport?

[Thomas Keffer]

By the way, in my experience, these leaks are caused by underlying "C"
libraries or, occasionally, by failure of PIL to release graphics resource
(such as font handles).

On Sun, Mar 29, 2020 at 3:09 PM Thomas Keffer  wrote:

> I'm not following. I thought you said you could get rid of the leak by
> doing the unsets. If so, is there still a problem?
>
>
> On Sun, Mar 29, 2020 at 8:41 AM Lucas Heijst  wrote:
>
>> Tom,
>>
>> Currently running weewx 4.0.0b17 and analysing the memory leak in my pi31
>> system.
>> On the system runs two weewx instances (mben and tfrc) and a 5-minute
>> webcam cronjob.
>>
>> The memory leak of my webcam cronjob task was caused by creating
>> variables like:
>> WEBCAM_ID=3
>> CAMERA=picamera$WEBCAM_ID
>> DATETIME=$(date +"%Y-%m-%d %H:%M:%S")
>> EPOCH=$(date +"%s")
>> ...
>>
>> The used memory is freed by:
>> unset WEBCAM_ID
>> unset CAMERA
>> unset DATETIME
>> unset EPOCH
>> ...
>>
>>
>> The memory leak of the weewx instances mben and tfrc are caused by the
>> weewx reporting tasks, see data below:
>>
>> -
>> used  time
>>  mem
>> - -
>> 73348 10:30
>> 95504 11:07
>> 48576 11:38 no webcam, no mben, no tfrc (no increase of memory)
>> 56136 11:41 mben without modbus read and modbus service
>> 57384 11:43
>> 57876 11:44
>> 58360 11:45
>> 64836 11:47 used memory increased with 6476 due to mben31 report
>> 64572 11:48
>> 64560 11:49
>> 64548 11:50
>> 66240 11:51 used memory increased with 1692 due to mben31 report
>> 55808 11:53 mben without mben31 report
>> 56092 11:54
>> 55828 11:55
>> 55808 11:56
>> 56000 11:57
>> 56000 11:58
>> 56516 11:59
>> 56772 12:00
>> 56164 12:02 mben now with modbus service (fully functional; without
>> reporting)
>> 56436 12:03
>> 55920 12:04
>> 76056 12:09 mben without mben31 report; tfrc started without tfrc31 report
>> 76388 12:10
>> 77084 12:11
>> 77248 12:12
>> 77432 12:13
>> 77312 12:14
>> 76908 12:15
>> 76976 12:16
>> 77268 12:21
>> 77248 12:24 hardly any increase of used memory the last 15 minutes
>> -
>>
>> When all reports are disabled, the memory leak on my system is
>> practically zero.
>>
>> Attached the skin settings of mben31.
>>
>> Any clue how reduce this memory leak?
>>
>> Luc
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-development+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-development/d91724fe-da46-4b4e-9913-59f55aa91657%40googlegroups.com
>> <https://groups.google.com/d/msgid/weewx-development/d91724fe-da46-4b4e-9913-59f55aa91657%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEBusZ0vLVJzOf3NpCXYsCKAHny7G5ZD0W5KxJ%2BukSyPSg%40mail.gmail.com.

Re: [weewx-development] Memory leak in StdReport?

[Thomas Keffer]

I'm not following. I thought you said you could get rid of the leak by
doing the unsets. If so, is there still a problem?


On Sun, Mar 29, 2020 at 8:41 AM Lucas Heijst  wrote:

> Tom,
>
> Currently running weewx 4.0.0b17 and analysing the memory leak in my pi31
> system.
> On the system runs two weewx instances (mben and tfrc) and a 5-minute
> webcam cronjob.
>
> The memory leak of my webcam cronjob task was caused by creating variables
> like:
> WEBCAM_ID=3
> CAMERA=picamera$WEBCAM_ID
> DATETIME=$(date +"%Y-%m-%d %H:%M:%S")
> EPOCH=$(date +"%s")
> ...
>
> The used memory is freed by:
> unset WEBCAM_ID
> unset CAMERA
> unset DATETIME
> unset EPOCH
> ...
>
>
> The memory leak of the weewx instances mben and tfrc are caused by the
> weewx reporting tasks, see data below:
>
> -
> used  time
>  mem
> - -
> 73348 10:30
> 95504 11:07
> 48576 11:38 no webcam, no mben, no tfrc (no increase of memory)
> 56136 11:41 mben without modbus read and modbus service
> 57384 11:43
> 57876 11:44
> 58360 11:45
> 64836 11:47 used memory increased with 6476 due to mben31 report
> 64572 11:48
> 64560 11:49
> 64548 11:50
> 66240 11:51 used memory increased with 1692 due to mben31 report
> 55808 11:53 mben without mben31 report
> 56092 11:54
> 55828 11:55
> 55808 11:56
> 56000 11:57
> 56000 11:58
> 56516 11:59
> 56772 12:00
> 56164 12:02 mben now with modbus service (fully functional; without
> reporting)
> 56436 12:03
> 55920 12:04
> 76056 12:09 mben without mben31 report; tfrc started without tfrc31 report
> 76388 12:10
> 77084 12:11
> 77248 12:12
> 77432 12:13
> 77312 12:14
> 76908 12:15
> 76976 12:16
> 77268 12:21
> 77248 12:24 hardly any increase of used memory the last 15 minutes
> -
>
> When all reports are disabled, the memory leak on my system is practically
> zero.
>
> Attached the skin settings of mben31.
>
> Any clue how reduce this memory leak?
>
> Luc
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/d91724fe-da46-4b4e-9913-59f55aa91657%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEAqrL6Ok%3DxyYHb5wFRwfps%2BEWtJreA6SaMjNThr%3Diiajg%40mail.gmail.com.

Re: [weewx-development] Re: weewx--4.0.0b16: SyntaxError: invalid syntax

[Thomas Keffer]

Try this version.



On Wed, Mar 18, 2020 at 4:14 AM Thomas Keffer  wrote:

> He's right. The extension has not been completely ported over to Python 3.
>
>
> On Tue, Mar 17, 2020 at 10:45 PM Gert Andersen 
> wrote:
>
>> Hi Vince
>>
>> Thanks for looking.
>>
>> I have downloaded mqtt.py from the link you mentioned and installed it.
>> Still syntax error at line 215
>>
>> If you look at line 215, you have:
>> *except KeyError, e:*
>> and I think it should be
>> *except KeyError as e:*
>> under Python 3
>>
>> Even if I change that line, I just get another error.
>>
>> So, I might do something wrong, but I can't see what. If you got this
>> working, you must have done something differently
>>
>> Gert
>>
>> On Tuesday, March 17, 2020 at 10:50:41 PM UTC+1, Vince Skahan wrote:
>>>
>>>
>>> Mar 17 22:05:25 weewx4Test weewx[7169] CRITICAL __main__:   name
>>>> 'queue' is not defined
>>>>
>>>>
>>>
>>> You're not working off the latest version on github it seems
>>>
>>> The top of the old file has a line saying simply "import queue".
>>> The top of the new version has python3 and python2 supported
>>>
>>> Download the current file
>>> https://raw.githubusercontent.com/matthewwall/weewx-mqtt/master/bin/user/mqtt.py
>>> and install it in place of your messed up one.  It should work.
>>>
>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-development+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-development/a6fa5d8a-dd64-47ed-bf7a-1c7286f52499%40googlegroups.com
>> <https://groups.google.com/d/msgid/weewx-development/a6fa5d8a-dd64-47ed-bf7a-1c7286f52499%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEB_eJF6p89p3TQEF_2GfQPWo-noXRRf_u2BsFM5T6BmNA%40mail.gmail.com.
# Copyright 2013 Matthew Wall
# Distributed under the terms of the GNU Public License (GPLv3)
"""
Upload data to MQTT server

This service requires the python bindings for mqtt:

   pip install paho-mqtt

Minimal configuration:

[StdRestful]
[[MQTT]]
server_url = mqtt://username:password@localhost:1883/
topic = weather
unit_system = METRIC

Use of the inputs map to customer name, format, or units:

[StdRestful]
[[MQTT]]
...
unit_system = METRIC # default to metric
[[[inputs]]]
outTemp
name = inside_temperature  # use a label other than outTemp
format = %.2f  # two decimal places of precision
units = degree_F   # convert outTemp to F, others in C
windSpeed
units = knot  # convert the wind speed to knots

Use of TLS to encrypt connection to broker.  The TLS options will be passed to
Paho client tls_set method.  Refer to Paho client documentation for details:

  https://eclipse.org/paho/clients/python/docs/

[StdRestful]
[[MQTT]]
...
[[[tls]]]
# CA certificates file (mandatory)
ca_certs = /etc/ssl/certs/ca-certificates.crt
# PEM encoded client certificate file (optional)
certfile = /home/user/.ssh/id.crt
# private key file (optional)
keyfile = /home/user/.ssh/id.key
# Certificate requirements imposed on the broker (optional).
#   Options are 'none', 'optional' or 'required'.
#   Default is 'required'.
cert_reqs = required
# SSL/TLS protocol (optional).
#   Options include sslv1, sslv2, sslv23, tls, tlsv1.
#   Default is 'tlsv1'
#   Not all options are supported by all systems.
tls_version = tlsv1
# Allowable encryption ciphers (optional).
#   To specify multiple cyphers, delimit with commas and enclose
#   in quotes.
#ciphers =
"""

try:
import queue as Queue
except ImportError:
import Queue

try:
from urllib.parse import urlparse
except ImportError:
from urlparse import urlparse

import paho.mqtt

Re: [weewx-development] Re: weewx--4.0.0b16: SyntaxError: invalid syntax

[Thomas Keffer]

He's right. The extension has not been completely ported over to Python 3.


On Tue, Mar 17, 2020 at 10:45 PM Gert Andersen 
wrote:

> Hi Vince
>
> Thanks for looking.
>
> I have downloaded mqtt.py from the link you mentioned and installed it.
> Still syntax error at line 215
>
> If you look at line 215, you have:
> *except KeyError, e:*
> and I think it should be
> *except KeyError as e:*
> under Python 3
>
> Even if I change that line, I just get another error.
>
> So, I might do something wrong, but I can't see what. If you got this
> working, you must have done something differently
>
> Gert
>
> On Tuesday, March 17, 2020 at 10:50:41 PM UTC+1, Vince Skahan wrote:
>>
>>
>> Mar 17 22:05:25 weewx4Test weewx[7169] CRITICAL __main__:   name
>>> 'queue' is not defined
>>>
>>>
>>
>> You're not working off the latest version on github it seems
>>
>> The top of the old file has a line saying simply "import queue".
>> The top of the new version has python3 and python2 supported
>>
>> Download the current file
>> https://raw.githubusercontent.com/matthewwall/weewx-mqtt/master/bin/user/mqtt.py
>> and install it in place of your messed up one.  It should work.
>>
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/a6fa5d8a-dd64-47ed-bf7a-1c7286f52499%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] Fresh install of 400b16: No module named 'pymysql'

[Thomas Keffer]

Oh, and I should mention, the instructions do say "If this does not install
cleanly, then see https://pypi.org/project/mysqlclient/;

Did you try following the instructions there?

-tk

On Tue, Mar 17, 2020 at 3:56 PM Thomas Keffer  wrote:

> Which version of Raspbian is your Pi running?
>
> -tk
>
> On Tue, Mar 17, 2020 at 8:33 AM Lucas Heijst  wrote:
>
>> Tom,
>>
>> I followed the install instructions of v4.0.0b16 for python3, see below.
>> After startup I got a ModuleNotFoundError: No module named 'pymysql'
>> So I added to the install:
>> apt-get install python3-mysqldb
>>
>> Luc
>>
>> install instructions
>> =
>> apt-get install python3-pip -y
>>
>> # Required packages:
>> sudo python3 -m pip install configobj
>> sudo python3 -m pip install cheetah3
>> sudo python3 -m pip install pillow
>>
>> # Required if hardware is serial or USB, respectively:
>> sudo python3 -m pip install pyserial
>> sudo python3 -m pip install pyusb
>>
>> # Required if using MySQL. If this does not
>> # install cleanly, then see https://pypi.org/project/mysqlclient/
>> sudo python3 -m pip install mysqlclient
>>
>> # Optional: for extended almanac information:
>> sudo python3 -m pip install pyephem
>> 
>>
>> startup
>> 
>> Mar 17 12:18:42 pi37 weewx[7000] INFO __main__: Initializing weewx
>> version 4.0.0b16
>> ...
>> Mar 17 12:18:42 pi37 weewx[7004] DEBUG weewx.engine: Loading service
>> user.cmon.ComputerMonitor
>> Mar 17 12:18:42 pi37 /weewxd: cmon: service version is 0.17
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: Caught unrecoverable
>> exception:
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   No module
>> named 'pymysql'
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   Traceback
>> (most recent call last):
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
>> "/home/weewx/bin/weedb/mysql.py", line 12, in 
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   import
>> MySQLdb
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
>> "/usr/local/lib/python3.7/dist-packages/MySQLdb/__init__.py", line 18, in
>> 
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   from .
>> import _mysql
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
>> ImportError: libmariadb.so.3: cannot open shared object file: No such file
>> or directory
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   During
>> handling of the above exception, another exception occurred:
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   Traceback
>> (most recent call last):
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
>> "/home/weewx/bin/weewxd", line 148, in main
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   engine
>> = weewx.engine.StdEngine(config_dict)
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
>> "/home/weewx/bin/weewx/engine.py", line 75, in __init__
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
>> self.loadServices(config_dict)
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
>> "/home/weewx/bin/weewx/engine.py", line 136, in loadServices
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   obj =
>> weeutil.weeutil.get_object(svc)(self,config_dict)
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
>> "/home/weewx/bin/user/cmon.py", line 705, in __init__
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
>> initialize=True)
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
>> "/home/weewx/bin/weewx/manager.py", line 523, in get_manager
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
>> self.manager_cache[data_binding] = open_manager(manager_dict, initialize)
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
>> "/home/weewx/bin/weewx/manager.py", line 673, in open_manager
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
>> manager_dict['schema'])
>> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
>> "/home/weewx/bin/weewx/manager.py", line 150, in open_with_create
>> Mar 1

Re: [weewx-development] Fresh install of 400b16: No module named 'pymysql'

[Thomas Keffer]

Which version of Raspbian is your Pi running?

-tk

On Tue, Mar 17, 2020 at 8:33 AM Lucas Heijst  wrote:

> Tom,
>
> I followed the install instructions of v4.0.0b16 for python3, see below.
> After startup I got a ModuleNotFoundError: No module named 'pymysql'
> So I added to the install:
> apt-get install python3-mysqldb
>
> Luc
>
> install instructions
> =
> apt-get install python3-pip -y
>
> # Required packages:
> sudo python3 -m pip install configobj
> sudo python3 -m pip install cheetah3
> sudo python3 -m pip install pillow
>
> # Required if hardware is serial or USB, respectively:
> sudo python3 -m pip install pyserial
> sudo python3 -m pip install pyusb
>
> # Required if using MySQL. If this does not
> # install cleanly, then see https://pypi.org/project/mysqlclient/
> sudo python3 -m pip install mysqlclient
>
> # Optional: for extended almanac information:
> sudo python3 -m pip install pyephem
> 
>
> startup
> 
> Mar 17 12:18:42 pi37 weewx[7000] INFO __main__: Initializing weewx version
> 4.0.0b16
> ...
> Mar 17 12:18:42 pi37 weewx[7004] DEBUG weewx.engine: Loading service
> user.cmon.ComputerMonitor
> Mar 17 12:18:42 pi37 /weewxd: cmon: service version is 0.17
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: Caught unrecoverable
> exception:
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   No module
> named 'pymysql'
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   Traceback
> (most recent call last):
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
> "/home/weewx/bin/weedb/mysql.py", line 12, in 
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   import
> MySQLdb
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
> "/usr/local/lib/python3.7/dist-packages/MySQLdb/__init__.py", line 18, in
> 
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   from .
> import _mysql
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   ImportError:
> libmariadb.so.3: cannot open shared object file: No such file or directory
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   During
> handling of the above exception, another exception occurred:
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   Traceback
> (most recent call last):
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
> "/home/weewx/bin/weewxd", line 148, in main
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   engine =
> weewx.engine.StdEngine(config_dict)
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
> "/home/weewx/bin/weewx/engine.py", line 75, in __init__
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
> self.loadServices(config_dict)
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
> "/home/weewx/bin/weewx/engine.py", line 136, in loadServices
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   obj =
> weeutil.weeutil.get_object(svc)(self,config_dict)
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
> "/home/weewx/bin/user/cmon.py", line 705, in __init__
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
> initialize=True)
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
> "/home/weewx/bin/weewx/manager.py", line 523, in get_manager
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
> self.manager_cache[data_binding] = open_manager(manager_dict, initialize)
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
> "/home/weewx/bin/weewx/manager.py", line 673, in open_manager
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
> manager_dict['schema'])
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
> "/home/weewx/bin/weewx/manager.py", line 150, in open_with_create
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
> connection = weedb.connect(database_dict)
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
> "/home/weewx/bin/weedb/__init__.py", line 86, in connect
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
> __import__(db_dict['driver'])
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: File
> "/home/weewx/bin/weedb/mysql.py", line 15, in 
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   import
> pymysql as MySQLdb
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__: 
> ModuleNotFoundError: No module named 'pymysql'
> Mar 17 12:18:42 pi37 weewx[7004] CRITICAL __main__:   Exiting.
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To 

Re: [weewx-development] weewx--4.0.0b16: SyntaxError: invalid syntax

[Thomas Keffer]

It looks like the mqtt extension has not been ported to Python 3.

You'll have to talk to the extension author about that.

-tk

On Mon, Mar 16, 2020 at 10:20 PM Gert Andersen 
wrote:

> Hi
> Currently I'm running weewx 3.9.2 and mqtt on a Raspberry system  and I'm
> trying to setup a test system for weewx 4 with mqtt.
>
> I have followed the weewx 4 installation instructions and used this link
> https://github.com/weewx/weewx/wiki/mqtt for installing mqtt. I have been
> searching to see if mqtt should be installed differently using weewx
> 4(Python 3), but can't find any advises.
>
> Starting weewx gives this error:
>
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: Caught
> unrecoverable exception:
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: 
> invalid syntax (mqtt.py, line 197)
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: 
> Traceback (most recent call last):
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: File
> "/home/weewx/bin/weewxd", line 148, in main
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: 
> engine = weewx.engine.StdEngine(config_dict)
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: File
> "/home/weewx/bin/weewx/engine.py", line 75, in  __init__
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: 
> self.loadServices(config_dict)
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: File
> "/home/weewx/bin/weewx/engine.py", line 136, i n
> loadServices
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: 
> obj = weeutil.weeutil.get_object(svc)(self,config _dict)
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: File
> "/home/weewx/bin/weeutil/weeutil.py", line 109 3, in
> get_object
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: 
> mod = __import__(module)
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: File
> "/home/weewx/bin/user/mqtt.py", line 197
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: 
> except KeyError, e:
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: 
>  ^
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: 
> SyntaxError: invalid syntax
> Mar 16 21:17:45 weewx4Test weewx[2305] CRITICAL __main__: 
> Exiting.
>
> Gert
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/7435406f-8193-46a6-9f79-af59af70bc02%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEBMLj2X%3DZqGoG-BW2-jMuCAND_KT9XFzNmenukTkQiAwg%40mail.gmail.com.

Re: [weewx-development] AttributeError in weewx 4.0.0b16

[Thomas Keffer]

Sorry, but I have no idea what module bme280 is.

The only differences between b14 and b16 are in how configuration files are
opened, default latitude and longitudes, logging for netbsd and openbsd,
setup.py, apache defaults, and some documentation changes. See for
yourself *here
*.

Hard to see how any of those could make a difference.

-tk

On Mon, Mar 16, 2020 at 11:48 AM Lucas Heijst  wrote:

> Tom,
>
> Version 4.0.0b14 runs without problems. Config: Raspberry PI 2B+, raspbian
> stretch, python3, drivers for bme280 and rtlsdr.
> After the upgrade to 4.0.0b16 I got an attribute error, see logging below.
> I 'downgraded' to 4.0.0b14 and all is back to normal.
>
> Any hints?
>
> Luc
>
> 
> Mar 16 15:37:37 pi35 rtld[9604] INFO __main__: Initializing weewx version
> 4.0.0b16
> Mar 16 15:37:37 pi35 rtld[9604] INFO __main__: Using Python 3.5.3
> (default, Sep 27 2018, 17:25:39) #012[GCC 6.3.0 20170516]
> Mar 16 15:37:37 pi35 rtld[9604] INFO __main__: Platform
> Linux-4.19.66-v7+-armv7l-with-debian-9.11
> Mar 16 15:37:37 pi35 rtld[9604] INFO __main__: Locale is 'en_GB.UTF-8'
> Mar 16 15:37:37 pi35 rtld[9604] INFO __main__: PID file is
> /var/run/weewx_rtld.pid
> Mar 16 15:37:37 pi35 rtld[9608] INFO __main__: Using configuration file
> /home/weewx/weewx_rtld.conf
> Mar 16 15:37:37 pi35 rtld[9608] DEBUG __main__: Initializing engine
> Mar 16 15:37:37 pi35 rtld[9608] INFO weewx.engine: Loading station type
> Rtldavis (user.rtldavis)
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: driver version is 0.14
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: using rain_bucket_type
> 1
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: sensor map is:
> {'outTemp': 'temperature', 'leafWet1': 'leaf_wetness_1', 'extraTemp2':
> 'pct_good_1', 'soilMoist1': 'soil_moisture_1', 'inTempBatteryStatus':
> 'bat_th_2', 'inTemp': 'temp_in', 'soilMoist3': 'soil_moisture_3',
> 'windSpeed': 'wind_speed', 'UV': 'uv', 'extraTemp1': 'pct_good_0',
> 'soilMoist2': 'soil_moisture_2', 'leafWet2': 'leaf_wetness_2',
> 'extraTemp3': 'pct_good_2', 'consBatteryVoltage': 'freqError0',
> 'soilTemp3': 'soil_temp_3', 'heatingVoltage': 'freqError4', 'soilTemp4':
> 'soil_temp_4', 'soilMoist4': 'soil_moisture_4', 'extraHumid2': 'humid_2',
> 'hail': 'freqError1', 'leafTemp1': 'leaf_temp_1', 'extraHumid1': 'humid_1',
> 'leafTemp2': 'pct_good_3', 'inHumidity': 'humidity_in', 'pressure':
> 'pressure', 'rainBatteryStatus': 'bat_leaf_soil', 'soilTemp2':
> 'soil_temp_2', 'hailRate': 'freqError2', 'txBatteryStatus': 'bat_iss',
> 'supplyVoltage': 'supercap_volt', 'rainRate': 'rain_rate', 'outHumidity':
> 'humidity', 'outTempBatteryStatus': 'bat_th_1', 'soilTemp1': 'soil_temp_1',
> 'heatingTemp': 'freqError3', 'radiation': 'solar_radiation', 'windDir':
> 'wind_dir', 'rxCheckPercent': 'pct_good_all', 'windBatteryStatus':
> 'bat_anemometer', 'referenceVoltage': 'solar_power'}
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: sensor map is {}
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: using frequency EU
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: using iss_channel 1
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: using
> anemometer_channel 2
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: using
> leaf_soil_channel 3
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: using
> temp_hum_1_channel 0
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: using
> temp_hum_2_channel 0
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: using transmitters 7
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: log_humidity_raw False
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: startup process
> '/home/weewx/work/bin/rtldavis -ppm +1 -tf EU -tr 7'
> Mar 16 15:37:37 pi35 rtld[9608] DEBUG user.rtldavis: start async reader
> for stderr-thread
> Mar 16 15:37:37 pi35 rtld[9608] DEBUG user.rtldavis: start async reader
> for stdout-thread
> Mar 16 15:37:37 pi35 rtld[9608] DEBUG weewx.engine: Loading service
> weewx.engine.StdTimeSynch
> Mar 16 15:37:37 pi35 rtld[9608] DEBUG weewx.engine: Finished loading
> service weewx.engine.StdTimeSynch
> Mar 16 15:37:37 pi35 rtld[9608] DEBUG weewx.engine: Loading service
> user.bme280wx.Bme280wx
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.bme280wx: bme280wx configuration
> {'i2c_port': '1', 'i2c_address': '0x77', 'usUnits': 'METRIC',
> 'temperatureKeys': 'inTemp', 'temperature_must_have': '', 'pressureKeys':
> 'pressure', 'pressure_must_have': 'outTemp', 'humidityKeys': 'not-present',
> 'humidity_must_have': ''}
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: shutdown process
> /home/weewx/work/bin/rtldavis -ppm +1 -tf EU -tr 7
> Mar 16 15:37:37 pi35 rtld[9608] INFO user.rtldavis: rtldavis with pid 9619
> killed
> Mar 16 15:37:37 pi35 rtld[9608] CRITICAL __main__: Caught unrecoverable
> exception:
> Mar 16 15:37:37 pi35 rtld[9608] CRITICAL __main__:   module
> 'bme280' has no attribute 'load_calibration_params'

Re: [weewx-development] The Netatmo Driver for Weewx

[Thomas Keffer]

The netatmo is not a supported driver, but nothing in the API has changed,
so it should work with V4 (although not, of course, under Python 3, unless
it was ported to Python 3).

On Sun, Mar 15, 2020 at 2:04 PM Gert Andersen 
wrote:

> Hi
>
> Will this driver work with weewx version 4?
>
> Gert
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/6acca3c4-076b-47d8-a4d6-c7d66fcae4ac%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] Re: CRITICAL __main__: Database OperationalError exception: (1054, "Unknown column 'rain' in 'field list'")

[Thomas Keffer]

Fixed in commit b884c96


-tk

On Sun, Mar 8, 2020 at 10:58 AM Lucas Heijst  wrote:

> Tom,
>
> This workaround in wxservices.py works for me.
>
> def _setup(self, stop_ts, db_manager):
> """Initialize the rain event list"""
> if self.rain_events is None:
> self.rain_events = []
> start_ts = stop_ts - self.retain_period
> try:
> # Get all rain events since the window start from the database
> for row in db_manager.genSql("SELECT dateTime, usUnits, rain
> FROM %s "
>  "WHERE dateTime>? AND
> dateTime<=?;"
>  % db_manager.table_name,
> (start_ts, stop_ts)):
> # Unpack the row:
> time_ts, unit_system, rain = row
> self.add_loop_packet({'dateTime': time_ts, 'usUnits':
> unit_system, 'rain': rain},
>  db_manager)
> except weedb.DatabaseError as e:
> log.debug("DatabaseError '%s'" % e)
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/d6d6f37f-911c-40f4-9043-33c6d563db27%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zECOyB4J69%3DehHLx6HVazYHcB-Q9n_Kf9jZcVc1EYpD4uA%40mail.gmail.com.

Re: [weewx-development] Upgrade to weewx 4.0.0b16

[Thomas Keffer]

There's a lot of stuff I don't recognize in there. They are not part of the
regular weewx distribution.

One subtle difference: before, the old 'bin' subdirectory was set aside and
renamed, for example, bin.20200314122522. Now, 'bin' is just overwritten.
So, any files in there that are not part of the distribution will survive
the upgrade.

-tk

On Sun, Mar 15, 2020 at 7:57 AM Lucas Heijst  wrote:

> Tom,
>
> The b16 upgrade created a whole bunch of new directories in the
> /home/weewx/bin directory.
> I have deleted the *.pyc files. Below are listed the found *.py files.
>
> Luc
>
> 
> /home/weewx/examples/alarm.py
> /home/weewx/examples/lowBattery.py
> /home/weewx/examples/mem.py
> /home/weewx/examples/stats.py
> /home/weewx/examples/transfer_db.py
> /home/weewx/examples/xstats/install.py
> /home/weewx/examples/xstats/bin/user/xstats.py
> /home/weewx/examples/pmon/install.py
> /home/weewx/examples/pmon/bin/user/pmon.py
> /home/weewx/examples/fileparse/install.py
> /home/weewx/examples/fileparse/bin/user/fileparse.py
> /home/weewx/examples/basic/install.py
> /home/weewx/bin/daemon.py
> /home/weewx/bin/ez_setup.py
> /home/weewx/bin/miniterm.py
> /home/weewx/bin/six.py
> /home/weewx/bin/weewx/accum.py
> /home/weewx/bin/weewx/almanac.py
> /home/weewx/bin/weewx/cheetahgenerator.py
> /home/weewx/bin/weewx/crc16.py
> /home/weewx/bin/weewx/defaults.py
> /home/weewx/bin/weewx/engine.py
> /home/weewx/bin/weewx/filegenerator.py
> /home/weewx/bin/weewx/imagegenerator.py
> /home/weewx/bin/weewx/manager.py
> /home/weewx/bin/weewx/qc.py
> /home/weewx/bin/weewx/reportengine.py
> /home/weewx/bin/weewx/restx.py
> /home/weewx/bin/weewx/station.py
> /home/weewx/bin/weewx/tags.py
> /home/weewx/bin/weewx/units.py
> /home/weewx/bin/weewx/uwxutils.py
> /home/weewx/bin/weewx/wxengine.py
> /home/weewx/bin/weewx/wxformulas.py
> /home/weewx/bin/weewx/wxmanager.py
> /home/weewx/bin/weewx/wxservices - kopie.py
> /home/weewx/bin/weewx/wxservices.py
> /home/weewx/bin/weewx/xtypes.py
> /home/weewx/bin/weewx/__init__.py
> /home/weewx/bin/weewx/drivers/acurite.py
> /home/weewx/bin/weewx/drivers/cc3000.py
> /home/weewx/bin/weewx/drivers/fousb.py
> /home/weewx/bin/weewx/drivers/simulator.py
> /home/weewx/bin/weewx/drivers/te923.py
> /home/weewx/bin/weewx/drivers/ultimeter.py
> /home/weewx/bin/weewx/drivers/vantage.py
> /home/weewx/bin/weewx/drivers/wmr100.py
> /home/weewx/bin/weewx/drivers/wmr200.py
> /home/weewx/bin/weewx/drivers/wmr300.py
> /home/weewx/bin/weewx/drivers/wmr9x8.py
> /home/weewx/bin/weewx/drivers/ws1.py
> /home/weewx/bin/weewx/drivers/ws23xx.py
> /home/weewx/bin/weewx/drivers/ws28xx.py
> /home/weewx/bin/weewx/drivers/__init__.py
> /home/weewx/bin/weeutil/config.py
> /home/weewx/bin/weeutil/ftpupload.py
> /home/weewx/bin/weeutil/log.py
> /home/weewx/bin/weeutil/logger.py
> /home/weewx/bin/weeutil/Moon.py
> /home/weewx/bin/weeutil/rsyncupload.py
> /home/weewx/bin/weeutil/Sun.py
> /home/weewx/bin/weeutil/timediff.py
> /home/weewx/bin/weeutil/weeutil.py
> /home/weewx/bin/weeutil/__init__.py
> /home/weewx/bin/weeplot/genplot.py
> /home/weewx/bin/weeplot/utilities.py
> /home/weewx/bin/weeplot/__init__.py
> /home/weewx/bin/weeimport/csvimport.py
> /home/weewx/bin/weeimport/cumulusimport.py
> /home/weewx/bin/weeimport/wdimport.py
> /home/weewx/bin/weeimport/weeimport.py
> /home/weewx/bin/weeimport/wuimport.py
> /home/weewx/bin/weeimport/__init__.py
> /home/weewx/bin/weedb/mysql.py
> /home/weewx/bin/weedb/sqlite.py
> /home/weewx/bin/weedb/__init__.py
> /home/weewx/bin/weecfg/config.py
> /home/weewx/bin/weecfg/database.py
> /home/weewx/bin/weecfg/extension.py
> /home/weewx/bin/weecfg/__init__.py
> /home/weewx/bin/wcwidth/table_wide.py
> /home/weewx/bin/wcwidth/table_zero.py
> /home/weewx/bin/wcwidth/wcwidth.py
> /home/weewx/bin/wcwidth/__init__.py
> /home/weewx/bin/wcwidth/tests/test_core.py
> /home/weewx/bin/wcwidth/tests/__init__.py
> /home/weewx/bin/user/cmon-old.py
> /home/weewx/bin/user/cmon.py
> /home/weewx/bin/user/extensions.py
> /home/weewx/bin/user/modbusenergy - kopie.py
> /home/weewx/bin/user/modbusenergy-0.10.py
> /home/weewx/bin/user/modbusenergy-0.11.py
> /home/weewx/bin/user/modbusenergy-0.4.py
> /home/weewx/bin/user/modbusenergy-0.5.py
> /home/weewx/bin/user/modbusenergy-0.6.py
> /home/weewx/bin/user/modbusenergy-0.7.py
> /home/weewx/bin/user/modbusenergy-0.8.py
> /home/weewx/bin/user/modbusenergy-0.9.py
> /home/weewx/bin/user/modbusenergy.py
> /home/weewx/bin/user/tfrc.py
> /home/weewx/bin/user/tfrcschema.py
> /home/weewx/bin/user/tfrc_0.1.py
> /home/weewx/bin/user/__init__.py
> /home/weewx/bin/user/myfiles/cmon-orig.py
> /home/weewx/bin/user/myfiles/cmon.py
> /home/weewx/bin/user/myfiles/cmon_hh.py
> /home/weewx/bin/user/myfiles/units.py
> /home/weewx/bin/user/myfiles/units_orig.py
> /home/weewx/bin/user/installer/rtldavis/install.py
> /home/weewx/bin/serial/aio.py
> /home/weewx/bin/serial/rfc2217.py
> /home/weewx/bin/serial/rs485.py
> /home/weewx/bin/serial/serialcli.py
> /home/weewx/bin/serial/serialjava.py

Re: [weewx-development] Upgrade to weewx 4.0.0b16

[Thomas Keffer]

1. It was actually the intention not to prompt if setup.py is performing an
upgrade. It should just silently accepts what was in weewx.conf (the
previous behavior).  This will change in the next version.

2. My installation has 70 .pyc files when installed under either Python 2
or Python 3. Where are the extra files you are finding?

3. The 'rain' problem is on the TODO list. Soon!

-tk

On Sun, Mar 15, 2020 at 6:38 AM Lucas Heijst  wrote:

> Tom,
>
> Upgrade from 4.0.0b14 to 4.0.0b16 on a Raspberry PI model 3B+ with Rasbian
> stretch and Python 3.
> Note: In Raspbian buster I could not compile the rtlsdr part of tfrec
> without errors.
>
> Before I forget, the critical error for not having a Rain field in the
> database still exists in this version.
> 
> Mar 15 10:14:15 pi31 tfrc[3322] CRITICAL __main__: Database
> OperationalError exception: (1054, "Unknown column 'rain' in 'field list'")
> Mar 15 10:14:15 pi31 tfrc[3322] CRITICAL __main__:   Waiting 2
> minutes then retrying...
> ===
> I added a try/except in wxservices.py to catch this.
>
> I noticed a LOT more *.pyc files: 565 to be precise, where it used to be
> about 70.
>
> I like the changed behaviour of the 400.b16 install. It won't update the
> weewx.conf file silently, but let you check the answers.
> The units parameter had no default (it was metric), so I had to type
> metric here.
> Below the configuration of weewx_mben and weewx_tfrc respectively.
>
> === mben ===
> Enter a brief description of the station, such as its location.  For
> example:
> Santa's Workshop, North Pole
> description [Modbus Energy Monitor]:
> Specify altitude, with units 'foot' or 'meter'.  For example:
> 35, foot
> 12, meter
> altitude [4, meter]:
> Specify latitude in decimal degrees, negative for south.
> latitude [5.8218431]:
> Specify longitude in decimal degrees, negative for west.
> longitude [-55.2190431]:
> Indicate the preferred units for display: 'metric' or 'us'
> units: metric
> Installed drivers include:
>   0) ComputerMonitor (user.cmon)
>   1) ComputerMonitor (user.cmon-old)
>   2) ModbusEnergy(user.modbusenergy)
>   3) ModbusEnergy(user.modbusenergy - kopie)
>   4) ?   (user.modbusenergy-0.10)  No module named
> 'user.modbusenergy-0'
>   5) ?   (user.modbusenergy-0.11)  No module named
> 'user.modbusenergy-0'
>   6) ?   (user.modbusenergy-0.4)   No module named
> 'user.modbusenergy-0'
>   7) ?   (user.modbusenergy-0.5)   No module named
> 'user.modbusenergy-0'
>   8) ?   (user.modbusenergy-0.6)   No module named
> 'user.modbusenergy-0'
>   9) ?   (user.modbusenergy-0.7)   No module named
> 'user.modbusenergy-0'
>  10) ?   (user.modbusenergy-0.8)   No module named
> 'user.modbusenergy-0'
>  11) ?   (user.modbusenergy-0.9)   No module named
> 'user.modbusenergy-0'
>  12) TFRC(user.tfrc)
>  13) ?   (user.tfrc_0.1)   No module named
> 'user.tfrc_0'
>  14) ?   (weewx.drivers.acurite)   No module named 'usb'
>  15) CC3000  (weewx.drivers.cc3000)
>  16) ?   (weewx.drivers.fousb) No module named 'usb'
>  17) Simulator   (weewx.drivers.simulator)
>  18) ?   (weewx.drivers.te923) No module named 'usb'
>  19) Ultimeter   (weewx.drivers.ultimeter)
>  20) Vantage (weewx.drivers.vantage)
>  21) ?   (weewx.drivers.wmr100)No module named 'usb'
>  22) ?   (weewx.drivers.wmr200)No module named 'usb'
>  23) ?   (weewx.drivers.wmr300)No module named 'usb'
>  24) WMR9x8  (weewx.drivers.wmr9x8)
>  25) WS1 (weewx.drivers.ws1)
>  26) WS23xx  (weewx.drivers.ws23xx)
>  27) ?   (weewx.drivers.ws28xx)No module named 'usb'
> choose a driver [2]: 2
> Saved backup to /home/weewx/weewx.conf.20200315095003
> Saved configuration to /home/weewx/weewx.conf
> root@pi31:/home/weewx-4.0.0b16#
> ==
>
> === tfrc ===
> Santa's Workshop, North Pole
> description [Paramaribo – tfrc31]:
> Specify altitude, with units 'foot' or 'meter'.  For example:
> 35, foot
> 12, meter
> altitude [4, meter]:
> Specify latitude in decimal degrees, negative for south.
> latitude [5.8218431]:
> Specify longitude in decimal degrees, negative for west.
> longitude [-55.2190431]:
> Indicate the preferred units for display: 'metric' or 'us'
> units: metric
> Installed drivers include:
>   0) ComputerMonitor (user.cmon)
>   1) ComputerMonitor (user.cmon-old)
>   2) ModbusEnergy(user.modbusenergy)
>   3) ModbusEnergy(user.modbusenergy - kopie)
>   4) ?   (user.modbusenergy-0.10)  No module named
> 'user.modbusenergy-0'
>   5) ?   (user.modbusenergy-0.11)  No module named
> 'user.modbusenergy-0'
>   6) ?   (user.modbusenergy-0.4)   No module named
> 'user.modbusenergy-0'
>   7) ?   (user.modbusenergy-0.5)   No module named
> 'user.modbusenergy-0'
>   8) ?   

Re: [weewx-development] WeeWX 4b15 setup error

[Thomas Keffer]

I didn't phrase that very well. Perhaps it would be better to say that the
weewx version of setup.py was intended for installation in /home/weewx.

But, you're right: generally Python's setup.py does install into
/usr/share, /etc, and so on. However, our assumption, good or bad, was that
users would use apt-get (or equivalent) if that's what they wanted.

-tk

On Sat, Mar 14, 2020 at 7:47 PM Xant  wrote:

>
> Good on b16! Acknowledge to be "a minor", but it was inserted in b15 (b14
> was ok).
>
> I'm puzzled as though "/etc/weewx" and "/usr/share/weewx" to be the
> 'original/formal' locations of WeeWX. If not, where is the "official"
> location? (apologies for this basic inquiry, but there are conflicting
> info).
>
> Xant
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/bf640db7-bf49-4954-b17b-6db5bfff8b6d%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEDrwbMr_Ryn6TY%2BsX4FSLaFRcR4HxQNiS4pM%2Bqi9vnyqw%40mail.gmail.com.

Re: [weewx-development] WeeWX 4b15 setup error

[Thomas Keffer]

OK. Try 4.0.0b16

-tk

On Sat, Mar 14, 2020 at 6:36 PM Thomas Keffer  wrote:

> The setup.py method wasn't really intended to be used to install in the
> system locations.
>
> Still, if this is the only problem, it should be possible to get it to
> work. Let me fiddle with it a bit.
>
> -tk
>
> On Sat, Mar 14, 2020 at 6:23 PM Xant  wrote:
>
>>
>> 'setup.cfg' as the following:
>>
>> [install]
>> home = /etc/weewx
>> prefix =
>> exec-prefix =
>> install_lib = /usr/share/weewx
>> install_scripts = /usr/share/weewx
>>
>> [egg_info]
>> tag_build =
>> tag_date = 0
>>
>> All files were installed correctly at designated folders, but the
>> following:
>>
>> /usr/bin/python: can't open file '/etc/weewx/bin/wee_config': [Errno 2]
>> No such file or directory
>>
>> It seems that the correct path would be:
>>
>> /usr/share/weewx/wee_config
>>
>> Xant
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-development+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-development/84c1e996-aa8d-4b32-9a1b-602911097156%40googlegroups.com
>> <https://groups.google.com/d/msgid/weewx-development/84c1e996-aa8d-4b32-9a1b-602911097156%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEBkON%3DQ0GQj0f7mXNQ9hdeT5bCWwpdO3Xs05TWuSzP%3D5g%40mail.gmail.com.

Re: [weewx-development] WeeWX 4b15 setup error

[Thomas Keffer]

The setup.py method wasn't really intended to be used to install in the
system locations.

Still, if this is the only problem, it should be possible to get it to
work. Let me fiddle with it a bit.

-tk

On Sat, Mar 14, 2020 at 6:23 PM Xant  wrote:

>
> 'setup.cfg' as the following:
>
> [install]
> home = /etc/weewx
> prefix =
> exec-prefix =
> install_lib = /usr/share/weewx
> install_scripts = /usr/share/weewx
>
> [egg_info]
> tag_build =
> tag_date = 0
>
> All files were installed correctly at designated folders, but the
> following:
>
> /usr/bin/python: can't open file '/etc/weewx/bin/wee_config': [Errno 2] No
> such file or directory
>
> It seems that the correct path would be:
>
> /usr/share/weewx/wee_config
>
> Xant
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/84c1e996-aa8d-4b32-9a1b-602911097156%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEDx77WBUXVQFwPznh5rCMzTmp5zLrDDY_05tGg%2B6rhqfA%40mail.gmail.com.

Re: [weewx-development] More debug logging in weewx version 4

[Thomas Keffer]

Yes, that will work (although the exception should be limited to just
catching ImportError).

Or, just use old-style "syslog" logging. It will work fine, but you'll get
a mix of new- and old-style logging formats.

-tk



On Sat, Mar 14, 2020 at 11:17 AM Vince Skahan  wrote:

> Tom - I updated the driver I'm fiddling with per your wiki, and noticed
> that there's no backward compatibility example for the "In main programs"
> example at the top of the wiki page. Does this look right as a potential
> addition to the wiki ?
>
> Tests out ok on python3 / weewx4 FWIW
>
> if __name__ == "__main__":
> usage = """%prog [options] [--help]"""
>
> def main():
> try:
> import logging
> import weeutil.logger
> log = logging.getLogger(__name__)
> weeutil.logger.setup('mydrivername', {} )
> except:
> import syslog
> syslog.openlog('mydrivername', syslog.LOG_PID |
> syslog.LOG_CONS)
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/58ba0277-d263-4e88-aa2f-0292482537a6%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEB4V%2Bh1LR7Ktko%3DoF6b3cz3br5udhy6mgx3sb7EajKePA%40mail.gmail.com.

Re: [weewx-development] More debug logging in weewx version 4

[Thomas Keffer]

Yes. Two methods come to mind:

1. You can suppress the debug messages in the driver. See Throttling
logging events

.

2. Or, you can add a [Logging] section to weewx.conf to do the same.

[Logging]
  [[loggers]]
[[[weewx.drivers.pymodbus]]]
  level = INFO

Once we get the hang of it, I think we'll find the Python logging module
much more flexible. See the white paper Weewx V4 and logging
 for details.

-tk


On Sat, Mar 14, 2020 at 9:34 AM Lucas Heijst  wrote:

> Tom,
>
> I have written a weewx device driver which collects data from a modbus
> energy meter.
>
> ===
> from pymodbus.constants import Endian
> from pymodbus.payload import BinaryPayloadDecoder
> from pymodbus.payload import BinaryPayloadBuilder
> from pymodbus.client.sync import ModbusSerialClient as ModbusClient
> from pymodbus.compat import iteritems
> from collections import OrderedDict
>
> from pymodbus.constants import Endian
> from pymodbus.payload import BinaryPayloadDecoder
> from pymodbus.payload import BinaryPayloadBuilder
> from pymodbus.compat import iteritems
> from collections import OrderedDict
> ===
>
>
> In version 3.9.2 I got only weewx debug messages in the syslog file when
> debug was set to 1.
>
> In version 4.0.0b14 I also get the pymodbus logging, see snippet below.
> This logging is HUGE: 20,500 lines per minute!!
>
> 
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.transaction: Running
> transaction 2184
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.transaction: SEND: 0x1 0x4
> 0x0 0x52 0x0 0x2 0xd0 0x1a
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.framer.rtu_framer: Changing
> state to IDLE - Last Frame End - 1584184619.972779, Current Time stamp -
> 1584184620.01192
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.client.sync: New
> Transaction state 'SENDING'
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.transaction: Changing
> transaction state from 'SENDING' to 'WAITING FOR REPLY'
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.transaction: Changing
> transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.transaction: RECV: 0x1 0x4
> 0x4 0x47 0x12 0xdc 0xa6 0x97 0x8f
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.framer.rtu_framer: Getting
> Frame - 0x4 0x4 0x47 0x12 0xdc 0xa6
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.factory: Factory
> Response[ReadInputRegistersResponse: 4]
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.framer.rtu_framer: Frame
> advanced, resetting header!!
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.transaction: Adding
> transaction 1
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.transaction: Getting
> transaction 1
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.transaction: Changing
> transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.payload: [18194, 56486]
> Mar 14 08:17:00 pi31 mben[1835] DEBUG pymodbus.payload: [b'G\x12',
> b'\xdc\xa6']
> Mar 14 08:17:00 pi31
> 
>
> As a workaround I have set the folowing line in file/etc/rsyslog.conf.
>
> :msg, contains, "DEBUG pymodbus" stop
>
>
> which suppresses the log lines in the syslog file.
>
>
> But I wonder: is there a better way?
>
>
> Luc
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/fcd18609-1408-4d4d-b93c-ae2d410e101e%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] Re: [weewx-user] 4 beta test report

[Thomas Keffer]

OK, so we've isolated the issue to a problem with how NetBSD implements
time.mktime().

I suppose we could trap the exception in intervalgen() and, instead, return
the simple arithmetic result of adding increment. Something like:

delta = datetime.timedelta(seconds=interval)
last_stamp1 = 0
while dt1 < stop_dt:
dt2 = min(dt1 + delta, stop_dt)
stamp1 = int(time.mktime(dt1.timetuple()))
try:
stamp2 = int(time.mktime(dt2.timetuple()))
except OverflowError:
stamp2 = stamp1 + interval
if stamp2 > stamp1 > last_stamp1:
yield TimeSpan(stamp1, stamp2)
last_stamp1 = stamp1
dt1 = dt2




On Mon, Mar 9, 2020 at 5:35 PM Greg Troxel  wrote:

> I get
>
> Starting datetime is 2020-03-08 01:00:00
> Represented as a time tuple, this is time.struct_time(tm_year=2020,
> tm_mon=3, tm_mday=8, tm_hour=1, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=68,
> tm_isdst=-1)
> After adding an hour, the resultant datetime is 2020-03-08 02:00:00
> Represented as a timetuple this is time.struct_time(tm_year=2020,
> tm_mon=3, tm_mday=8, tm_hour=2, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=68,
> tm_isdst=-1)
> Traceback (most recent call last):
>   File "./test.py", line 22, in 
> ts = time.mktime(tt1)
> OverflowError: mktime argument out of range
>
>
> I wrote a test program for mktime.  With the isdst/gmtoff values from
> localtime, it works.  With this,  I can provoke EINVAL, which I think is
> per the spec.
>
> 
> #include 
> #include 
> #include 
>
> int
> main()
> {
>   struct tm *t;
>   time_t start = 1583647200;/* 20200308T0100 EST */
>   time_t plus1;
>
>   t = localtime();
>
>   printf("isdst %d tm_gmtoff %ld\n", t->tm_isdst, t->tm_gmtoff);
>   t->tm_isdst = -1;
>   t->tm_gmtoff = 0;
>   printf("isdst %d tm_gmtoff %ld\n", t->tm_isdst, t->tm_gmtoff);
>
>   t->tm_hour += 1;
>   printf("tm_hour %d\n", t->tm_hour);
>
>   plus1 = mktime(t);
>
>   printf("plus1 %jd errno %d\n", (intmax_t) plus1, errno);
>
>   printf("result: %s\n", plus1 == 1583650800 ? "ok" : "bad");
>
>
>   return 0;
> }
> 
> isdst 0 tm_gmtoff -18000
> isdst -1 tm_gmtoff 0
> tm_hour 2
> plus1 -1 errno 22
> result: bad
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEB8H%2BNw_u99vN3D00pFn4HWkp1t3B3eChauPA5v8ba_-w%40mail.gmail.com.

Re: [weewx-development] How to handle mixed US and metric units in a driver?

[Thomas Keffer]

Well, I did say, "if possible!"

In your case, it does make sense to convert to a common unit system and
keep everything together in one packet.

On Sun, Mar 8, 2020 at 9:26 PM John Kline  wrote:

> I agree that, all things being equal, a driver should just pass it on; but
> this is not that case.
>
> There won’t be any meaningful loss of precision for the double
> conversions. As such, the alternative, splitting into separate packets, is
> an unnecessary complication even without factoring in that StdWXCalculate
> might not be able to perform some calculations.
>
> On Mar 8, 2020, at 9:17 PM, Thomas Keffer  wrote:
>
> 
> Yes. A good driver makes minimal interpretations about the data it is
> seeing. If possible, it should just pass it on.
>
> On Sun, Mar 8, 2020 at 9:03 PM John Kline  wrote:
>
>> This isn’t the general case.  I find it difficult to see the harm in
>> converting to and fro for some cases.  Are you worried about loss of
>> precision?
>>
>> On Mar 8, 2020, at 8:45 PM, Thomas Keffer  wrote:
>>
>> 
>> As you concluded, it's generally best to keep the unit system as close to
>> the "native" unit system of the hardware as possible.
>>
>> -tk
>>
>> On Sun, Mar 8, 2020 at 8:32 PM Bill Burton  wrote:
>>
>>> Hello,
>>>
>>> On Sunday, March 8, 2020 at 4:01:53 PM UTC-4, John Kline wrote:
>>>>
>>>> Since you are writing the driver, have you considered performing the
>>>> necessary conversions so that the driver returns US or metric (i.e., one or
>>>> the other, not a mix)?
>>>>
>>>
>>> Yes, good question. I suppose it could be done that way picking one unit
>>> type for the packet and then converting all fields not in the same unit
>>> type. However, if the weather station is configured to return metric units
>>> but the driver is written to convert all fields to US/imperial but the
>>> archive database is configured to be metric, then there's a double
>>> conversion, metric -> US -> metric. So I was thinking if the fields
>>> returned by the driver are the original units returned by the weather
>>> station, then there's zero or one conversions to store archive records,
>>> never two conversions.
>>>
>>> -Bill
>>>
>>>
>>>> On Mar 8, 2020, at 12:57 PM, Bill Burton  wrote:
>>>>
>>>> 
>>>> Hello,
>>>>
>>>> I'm implementing a driver for the Columbia Weather Systems MicroServer
>>>> that supports a variety of their weather stations including the Pulsar 600.
>>>> So far I have the driver polling the station reliably under WeeWX 3.9.2
>>>> under Python 2.7 and 4.0.0b13 under Python 3.6.
>>>>
>>>> However, the issue I'm trying to resolve is the station can return a
>>>> mix of US and metric units for the different fields yet a loop packet can
>>>> only return one unit type. So, what is the best way to return a record that
>>>> could be a mix of unit types? Note that I'm requesting the extended XML
>>>> format which returns the unit type for each field. The following are
>>>> examples of these records, first US/Imperial followed by an all metric
>>>> record:
>>>>
>>>> 
>>>> 2020/02/18 03:17:09
>>>> 7.7
>>>> 7.7
>>>> 8.0
>>>> 0.4
>>>> 5237.3
>>>> -3759
>>>> 9.0
>>>> 26.4
>>>> 0.06
>>>> 0.05
>>>> 30.05
>>>> 0.0853
>>>> 0.0001
>>>> 1
>>>> -3298
>>>> 0.908
>>>> 0.0854
>>>> 7.7
>>>> 0.0049
>>>> 71
>>>> 0.4
>>>> 0
>>>> 0
>>>> 0.4
>>>> 0
>>>> 0.6
>>>> 346
>>>> 0.8
>>>> 31
>>>> 0.9
>>>> 60
>>>> 244
>>>> 3.0
>>>> 2020/02/18 02:46:45
>>>> 134
>>>> 1.8
>>>> 2020/02/18 03:11:33
>>>> 294
>>>> 1.4
>>>> 2020/02/18 03:16:01
>>>> 0.
>>>> 0.0031
>>>> 0.6756
>>>> 3.0556
>>>> 0.
>>>> 0.
>>>> 0.000
>>>> 30.09
>>>> 30.09
>>>> 0
>>>> 32.8
>>>> 
>>>>
>>>> 
>>>> 2020/02/18 03:19:25
>>>> -17.8
>>>> 2891.8
>>>> -12.8
>>>> 

Re: [weewx-development] How to handle mixed US and metric units in a driver?

[Thomas Keffer]

Yes. A good driver makes minimal interpretations about the data it is
seeing. If possible, it should just pass it on.

On Sun, Mar 8, 2020 at 9:03 PM John Kline  wrote:

> This isn’t the general case.  I find it difficult to see the harm in
> converting to and fro for some cases.  Are you worried about loss of
> precision?
>
> On Mar 8, 2020, at 8:45 PM, Thomas Keffer  wrote:
>
> 
> As you concluded, it's generally best to keep the unit system as close to
> the "native" unit system of the hardware as possible.
>
> -tk
>
> On Sun, Mar 8, 2020 at 8:32 PM Bill Burton  wrote:
>
>> Hello,
>>
>> On Sunday, March 8, 2020 at 4:01:53 PM UTC-4, John Kline wrote:
>>>
>>> Since you are writing the driver, have you considered performing the
>>> necessary conversions so that the driver returns US or metric (i.e., one or
>>> the other, not a mix)?
>>>
>>
>> Yes, good question. I suppose it could be done that way picking one unit
>> type for the packet and then converting all fields not in the same unit
>> type. However, if the weather station is configured to return metric units
>> but the driver is written to convert all fields to US/imperial but the
>> archive database is configured to be metric, then there's a double
>> conversion, metric -> US -> metric. So I was thinking if the fields
>> returned by the driver are the original units returned by the weather
>> station, then there's zero or one conversions to store archive records,
>> never two conversions.
>>
>> -Bill
>>
>>
>>> On Mar 8, 2020, at 12:57 PM, Bill Burton  wrote:
>>>
>>> 
>>> Hello,
>>>
>>> I'm implementing a driver for the Columbia Weather Systems MicroServer
>>> that supports a variety of their weather stations including the Pulsar 600.
>>> So far I have the driver polling the station reliably under WeeWX 3.9.2
>>> under Python 2.7 and 4.0.0b13 under Python 3.6.
>>>
>>> However, the issue I'm trying to resolve is the station can return a mix
>>> of US and metric units for the different fields yet a loop packet can only
>>> return one unit type. So, what is the best way to return a record that
>>> could be a mix of unit types? Note that I'm requesting the extended XML
>>> format which returns the unit type for each field. The following are
>>> examples of these records, first US/Imperial followed by an all metric
>>> record:
>>>
>>> 
>>> 2020/02/18 03:17:09
>>> 7.7
>>> 7.7
>>> 8.0
>>> 0.4
>>> 5237.3
>>> -3759
>>> 9.0
>>> 26.4
>>> 0.06
>>> 0.05
>>> 30.05
>>> 0.0853
>>> 0.0001
>>> 1
>>> -3298
>>> 0.908
>>> 0.0854
>>> 7.7
>>> 0.0049
>>> 71
>>> 0.4
>>> 0
>>> 0
>>> 0.4
>>> 0
>>> 0.6
>>> 346
>>> 0.8
>>> 31
>>> 0.9
>>> 60
>>> 244
>>> 3.0
>>> 2020/02/18 02:46:45
>>> 134
>>> 1.8
>>> 2020/02/18 03:11:33
>>> 294
>>> 1.4
>>> 2020/02/18 03:16:01
>>> 0.
>>> 0.0031
>>> 0.6756
>>> 3.0556
>>> 0.
>>> 0.
>>> 0.000
>>> 30.09
>>> 30.09
>>> 0
>>> 32.8
>>> 
>>>
>>> 
>>> 2020/02/18 03:19:25
>>> -17.8
>>> 2891.8
>>> -12.8
>>> -0.041
>>> 2.8
>>> 101
>>> 101
>>> 2.7
>>> 98
>>> 1.5
>>> 155
>>> 1.4
>>> 80
>>> 1.5
>>> 62
>>> 100
>>> 2.8
>>> 2020/02/18 03:19:25
>>> 100
>>> 2.8
>>> 2020/02/18 03:19:25
>>> 100
>>> 2.8
>>> 2020/02/18 03:19:25
>>> 0.000
>>> 0.000
>>> 17.018
>>> 77.470
>>> 0.000
>>> 0.000
>>> 0
>>> 
>>>
>>> My first inclination is to split up the fields into separate loop
>>> packets - one packet for US/Imperial measurements and a second packet for
>>> metric measurements then yield each one depending on availability. Does
>>> this sound like a reasonable approach or is there a better one?
>>>
>>> However, some conversions will be required for metric as some
>>> measurements such as wind speed can be returned in different units being
>>> one of kph or meters per second. Otherwise, wind speed could be returned as
>>

Re: [weewx-development] How to handle mixed US and metric units in a driver?

[Thomas Keffer]

As you concluded, it's generally best to keep the unit system as close to
the "native" unit system of the hardware as possible.

-tk

On Sun, Mar 8, 2020 at 8:32 PM Bill Burton  wrote:

> Hello,
>
> On Sunday, March 8, 2020 at 4:01:53 PM UTC-4, John Kline wrote:
>>
>> Since you are writing the driver, have you considered performing the
>> necessary conversions so that the driver returns US or metric (i.e., one or
>> the other, not a mix)?
>>
>
> Yes, good question. I suppose it could be done that way picking one unit
> type for the packet and then converting all fields not in the same unit
> type. However, if the weather station is configured to return metric units
> but the driver is written to convert all fields to US/imperial but the
> archive database is configured to be metric, then there's a double
> conversion, metric -> US -> metric. So I was thinking if the fields
> returned by the driver are the original units returned by the weather
> station, then there's zero or one conversions to store archive records,
> never two conversions.
>
> -Bill
>
>
>> On Mar 8, 2020, at 12:57 PM, Bill Burton  wrote:
>>
>> 
>> Hello,
>>
>> I'm implementing a driver for the Columbia Weather Systems MicroServer
>> that supports a variety of their weather stations including the Pulsar 600.
>> So far I have the driver polling the station reliably under WeeWX 3.9.2
>> under Python 2.7 and 4.0.0b13 under Python 3.6.
>>
>> However, the issue I'm trying to resolve is the station can return a mix
>> of US and metric units for the different fields yet a loop packet can only
>> return one unit type. So, what is the best way to return a record that
>> could be a mix of unit types? Note that I'm requesting the extended XML
>> format which returns the unit type for each field. The following are
>> examples of these records, first US/Imperial followed by an all metric
>> record:
>>
>> 
>> 2020/02/18 03:17:09
>> 7.7
>> 7.7
>> 8.0
>> 0.4
>> 5237.3
>> -3759
>> 9.0
>> 26.4
>> 0.06
>> 0.05
>> 30.05
>> 0.0853
>> 0.0001
>> 1
>> -3298
>> 0.908
>> 0.0854
>> 7.7
>> 0.0049
>> 71
>> 0.4
>> 0
>> 0
>> 0.4
>> 0
>> 0.6
>> 346
>> 0.8
>> 31
>> 0.9
>> 60
>> 244
>> 3.0
>> 2020/02/18 02:46:45
>> 134
>> 1.8
>> 2020/02/18 03:11:33
>> 294
>> 1.4
>> 2020/02/18 03:16:01
>> 0.
>> 0.0031
>> 0.6756
>> 3.0556
>> 0.
>> 0.
>> 0.000
>> 30.09
>> 30.09
>> 0
>> 32.8
>> 
>>
>> 
>> 2020/02/18 03:19:25
>> -17.8
>> 2891.8
>> -12.8
>> -0.041
>> 2.8
>> 101
>> 101
>> 2.7
>> 98
>> 1.5
>> 155
>> 1.4
>> 80
>> 1.5
>> 62
>> 100
>> 2.8
>> 2020/02/18 03:19:25
>> 100
>> 2.8
>> 2020/02/18 03:19:25
>> 100
>> 2.8
>> 2020/02/18 03:19:25
>> 0.000
>> 0.000
>> 17.018
>> 77.470
>> 0.000
>> 0.000
>> 0
>> 
>>
>> My first inclination is to split up the fields into separate loop packets
>> - one packet for US/Imperial measurements and a second packet for metric
>> measurements then yield each one depending on availability. Does this sound
>> like a reasonable approach or is there a better one?
>>
>> However, some conversions will be required for metric as some
>> measurements such as wind speed can be returned in different units being
>> one of kph or meters per second. Otherwise, wind speed could be returned as
>> mph or knots.
>>
>> One issue is I haven't been able to find any definitive documentation as
>> to all the fields a driver is supposed to output and what units are
>> expected for US vs. metric packets. So any pointers on fields and their
>> definitions would be helpful.
>>
>> If there are any existing drivers that handle a mixture of units in a
>> similar way that I could reference, that would be very helpful to know.
>>
>> Thanks for any input,
>> -Bill
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-de...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-development/1142ae3a-c6c4-47d6-af01-33de21b2d5fd%40googlegroups.com
>> 
>> .
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/0d252600-cedb-4d9a-8902-b14028684e99%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view 

Re: [weewx-development] How to handle mixed US and metric units in a driver?

[Thomas Keffer]

All units within a packet must use one of the three weewx unit systems, US,
METRIC, or METRICWX. You can change from packet to packet, but not within a
packet.

You could emit a different packet for each observation type, but you could
miss out on some calculations. For example, to calculate dewpoint, you need
outside temperature plus outside humidity. If they are in separate packets,
StdWXCalculate can't perform the calculation.

Make sure you read the section *Porting to new hardware
* in the Customization
Guide.

-tk

On Sun, Mar 8, 2020 at 12:57 PM Bill Burton  wrote:

> Hello,
>
> I'm implementing a driver for the Columbia Weather Systems MicroServer
> that supports a variety of their weather stations including the Pulsar 600.
> So far I have the driver polling the station reliably under WeeWX 3.9.2
> under Python 2.7 and 4.0.0b13 under Python 3.6.
>
> However, the issue I'm trying to resolve is the station can return a mix
> of US and metric units for the different fields yet a loop packet can only
> return one unit type. So, what is the best way to return a record that
> could be a mix of unit types? Note that I'm requesting the extended XML
> format which returns the unit type for each field. The following are
> examples of these records, first US/Imperial followed by an all metric
> record:
>
> 
> 2020/02/18 03:17:09
> 7.7
> 7.7
> 8.0
> 0.4
> 5237.3
> -3759
> 9.0
> 26.4
> 0.06
> 0.05
> 30.05
> 0.0853
> 0.0001
> 1
> -3298
> 0.908
> 0.0854
> 7.7
> 0.0049
> 71
> 0.4
> 0
> 0
> 0.4
> 0
> 0.6
> 346
> 0.8
> 31
> 0.9
> 60
> 244
> 3.0
> 2020/02/18 02:46:45
> 134
> 1.8
> 2020/02/18 03:11:33
> 294
> 1.4
> 2020/02/18 03:16:01
> 0.
> 0.0031
> 0.6756
> 3.0556
> 0.
> 0.
> 0.000
> 30.09
> 30.09
> 0
> 32.8
> 
>
> 
> 2020/02/18 03:19:25
> -17.8
> 2891.8
> -12.8
> -0.041
> 2.8
> 101
> 101
> 2.7
> 98
> 1.5
> 155
> 1.4
> 80
> 1.5
> 62
> 100
> 2.8
> 2020/02/18 03:19:25
> 100
> 2.8
> 2020/02/18 03:19:25
> 100
> 2.8
> 2020/02/18 03:19:25
> 0.000
> 0.000
> 17.018
> 77.470
> 0.000
> 0.000
> 0
> 
>
> My first inclination is to split up the fields into separate loop packets
> - one packet for US/Imperial measurements and a second packet for metric
> measurements then yield each one depending on availability. Does this sound
> like a reasonable approach or is there a better one?
>
> However, some conversions will be required for metric as some measurements
> such as wind speed can be returned in different units being one of kph or
> meters per second. Otherwise, wind speed could be returned as mph or knots.
>
> One issue is I haven't been able to find any definitive documentation as
> to all the fields a driver is supposed to output and what units are
> expected for US vs. metric packets. So any pointers on fields and their
> definitions would be helpful.
>
> If there are any existing drivers that handle a mixture of units in a
> similar way that I could reference, that would be very helpful to know.
>
> Thanks for any input,
> -Bill
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/1142ae3a-c6c4-47d6-af01-33de21b2d5fd%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zECNkcVs9OwODBPx%2BzSu7ZMSqPfFhHA244jkTQbptyQPHA%40mail.gmail.com.

Re: [weewx-development] CRITICAL __main__: Database OperationalError exception: (1054, "Unknown column 'rain' in 'field list'")

[Thomas Keffer]

This is probably being caused by the "rainRate" calculator. The default is
to calculate 'rainRate', despite you not having it listed in
[[Calculations]].

What to do?

   1. We could remove rainRate from the defaults, and require it to be
   listed in [[Calculations]]. In fact, we could remove *all* defaults.
   2. Or, we could catch the exception and swallow it.
   3. Or, both.

I'm inclined to go with option #3.

-tk



On Sat, Mar 7, 2020 at 6:53 AM Lucas Heijst  wrote:

> Tom,
>
> The following three weewx programs got a critical error after startup of
> weewx version 4.0.0b14.
>
> *CRITICAL __main__: Database OperationalError exception: (1054, "Unknown
> column 'rain' in 'field list'")*
>
>
> weewx_klim formerly running version 4.0.0.a4
> weewx_mben formerly running version 3.9.1
> weewx_tfrc formerly running version 3.9.1
>
> Note:
> Program weewx_klim (klimalogg driver) does not have a rain database field
> Program weewx_mben (modbus energy monitor) does not have a rain database
> field
>
> All three programs use the same weewx_conf file with the old and with the
> new weewx version.
>
> What can be done to debug this?
>
> Note: the syslog says (see attachment):
> INFO weewx.wxservices: The following values will be calculated:
> pressure=prefer_hardware, altimeter=prefer_hardware,
> appTemp=prefer_hardware, barometer=prefer_hardware,
> beaufort=prefer_hardware, cloudbase=prefer_hardware,
> dewpoint=prefer_hardware, ET=prefer_hardware, heatindex=prefer_hardware,
> humidex=prefer_hardware, inDewpoint=prefer_hardware,
> maxSolarRad=prefer_hardware, rainRate=prefer_hardware,
> windchill=prefer_hardware, windrun=prefer_hardware
> while none of these values exist in the database.
>
> Snippet of weewx.conf:
> =
>
> ##
>
> #   This section can adjust data using calibration expressions.
>
> [StdCalibrate]
>
> [[Corrections]]
> # For each type, an arbitrary calibration expression can be given.
> # It should be in the units defined in the StdConvert section.
>
>
> ##
>
> #   This section is for quality control checks. If units are not specified,
> #   values must be in the units defined in the StdConvert section.
>
> [StdQC]
>
> [[MinMax]]
>
>
> ##
>
> #   This section controls the origin of derived values.
>
> [StdWXCalculate]
> [[Calculations]]
> # How to calculate derived quantities.  Possible values are:
> #  hardware- use the value provided by hardware
> #  software- use the value calculated by weewx
> #  prefer_hardware - use value provide by hardware if available,
> #  otherwise use value calculated by weewx
>
>
> ##
> =
>
> Luc
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/7a6ad431-8806-48f1-b471-c39411de62f4%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zECxrqJLq4UNhFoPOyZUPYDG-5FH%3DOTu%2BgGVyRk-pWPCTw%40mail.gmail.com.

Re: [weewx-development] DEBUG weewx.wxservices: Unknown extensible type 'dayRain'

[Thomas Keffer]

Hmmm... how about a little more information?

   1. Can you give the context of the error? More of the log would help.
   2. I don't know why wxservices would be trying to calculate dayRain. Do
   you have it listed under [StdWXCalculate]?
   3. Where is dayRain used? Is it used in your skins?

I did change how the accumulators work in 4.0.0b14, but I don't see how it
would affect dayRain.

-tk

On Fri, Mar 6, 2020 at 9:04 AM Lucas Heijst  wrote:

> Tom,
>
> For several months I runned succesful weewx version 4.0.0a4 with raspbian
> stretch on a raspberry Pi 2B.
>
> Today I installed from scratch raspbian buster lite (2020-02-13) and weewx
> version 4.0.0b14.
>
> With each loop message I now get a debug message:
> DEBUG weewx.wxservices: Unknown extensible type 'dayRain'
>
> Any clues what causes this?
>
> Luc
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/7c8f7d9a-b69e-4f77-b814-a18c14ac5388%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zECR%2BJmDV%2BcRzxcmP3nbZ0oavFH1WFOjSFx1uFYOQgq%3Dew%40mail.gmail.com.

Re: [weewx-development] Re: Package mysql-client is not available in raspbian_buster

[Thomas Keffer]

Thanks, Les. That simplified things a bit.

Changed the install instructions in commit 937903e


-tk

On Tue, Mar 3, 2020 at 2:00 PM Les Niles  wrote:

> In Buster and Stretch, and probably earlier, there is a meta-package
> “default-mysql-client” that installs the preferred version of the client,
> mariadb-client.  In Stretch the mysql-client package still existed but it
> was just dependent on default-mysql-client so still got the mariadb
> version.  I don’t have an older system handy to poke around on but I
> imagine this arrangement existed for several previous versions.  Apparently
> by Buster, debian expects people to have cleaned up explicit dependencies
> on the mysql packages.
>
> What about the server side?  It looks like the same thing applies to the
> mysql-server packge.
>
>   -Les
>
>
>
> On 3 Mar 2020, at 12:36, John Kline  wrote:
>
> FWIW, WRT mysql-client, I’m not seeing any difference in buster between
> Raspbian and standard Debian.  mysql-client does not exist in both cases.
>
> It appears to me that Debian has moved on to mariadb as the drop in
> replacement.
>
> As for: “ but is referred to by another package.”; perhaps an “apt
> dist-upgrade” will fix it.
>
> On Mar 3, 2020, at 11:53 AM, Vince Skahan  wrote:
>
> 
> On Tuesday, March 3, 2020 at 9:14:29 AM UTC-8, Lucas Heijst wrote:
>>
>> I did a fresh install of raspbian buster on a rpi 3b+
>>
>> Package mysql-client is not available, but is referred to by another
>> package.
>>
>> This may mean that the package is missing, has been obsoleted, or
>>
>> is only available from another source
>>
>> However the following packages replace it:
>>
>> mariadb-client-10.0
>>
>>
>> E: Package 'mysql-client' has no installation candidate
>>
>>
>> I installed module mariadb-client-10.0 instead without any further
>> errors.
>>
>>
>>
>>
> This sounds like the renaming of mysql that happened a while back.   If
> they did the mariadb packages correctly they would be set up to 'provide'
> mariadb-whatever as a capability of their package (I'm speaking from a
> RedHat background and how RPM does it, I don't know if debian packages can
> do that or not)
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/95142a8e-430e-4c88-bc4b-010972640dc6%40googlegroups.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/A065D115-61F2-4DCC-9D83-0AF1A44E483C%40johnkline.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/E65C7D54-E8F6-4074-B169-A39FD410A644%402pi.org
> 
> .
>

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

Re: [weewx-development] new driver ... next steps

[Thomas Keffer]

Hello, Bob, and thanks for your effort.

Take a look at the many 3rd party drivers listed in the Wiki
 to see how others have done
this. Just to pick one at random, how about the Rainwise IP-100
? The driver is in bin/user/.
It also uses an install program, install.py. A change log is also a good
idea. Include a license. Add a readme with directions.

Then add your new driver to the list on the Wiki, with a link to your
GitHub repository.

A great learning experience on git and github!

-tk



On Tue, Mar 3, 2020 at 12:38 PM Bob Atchley  wrote:

> I have a new weewx beta driver that should support the following weather
> stations:
> Youshiko YC9388
> Bresser PC 6 in 1
> Garni 935PC
> Ventus W835
>
> I have the Youshiko weather station.
>
> The driver is working reliably (I have 48 hours of weewx data and growing)
> but I view it as very much first steps.
> I'm not a python expert by any means, so I'm hoping for feedback and
> improvements.
>
> But the first step is sharing this with the community.  I'm also new to
> git.  I''ve just cloned the repository,
> do I just add the driver into bin/user and commit it (or into
> bin/weewx/drivers)  or is it more complicated than that
>
> Thanks
>
> Bob
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/341ac067-8ba7-4c51-b0bc-c19a9c764a93%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEC94tqUZLy6aca1Te9zkSsQLpNkGMwXZ0eOc3%3DNHLUVnw%40mail.gmail.com.

Re: [weewx-development] Package mysql-client is not available in raspbian_buster

[Thomas Keffer]

Oh, which of the 3 versions of Raspbian Buster did you install?
https://www.raspberrypi.org/downloads/raspbian/

   - Raspbian Buster with desktop and recommended software
   - Raspbian Buster with desktop
   - Raspbian Buster Lite.

-tk

On Tue, Mar 3, 2020 at 9:42 AM Thomas Keffer  wrote:

> Thanks for the heads up, Luc. I've added it to the TODO list.
>
> -tk
>
> On Tue, Mar 3, 2020 at 9:14 AM Lucas Heijst  wrote:
>
>> I did a fresh install of raspbian buster on a rpi 3b+
>> Preparing a fresh install of weewx-4.0.0b13
>> All with python3 modules.
>>
>> I got a warning with this step:
>>
>> # Required if using MySQL:
>>
>> *sudo apt-get install mysql-client*
>>
>>
>> Package mysql-client is not available, but is referred to by another
>> package.
>>
>> This may mean that the package is missing, has been obsoleted, or
>>
>> is only available from another source
>>
>> However the following packages replace it:
>>
>> mariadb-client-10.0
>>
>>
>> E: Package 'mysql-client' has no installation candidate
>>
>>
>> I installed module mariadb-client-10.0 instead without any further
>> errors.
>>
>>
>> Luc
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-development+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-development/f2054656-1b0e-41e3-932a-d0f60fcfb336%40googlegroups.com
>> <https://groups.google.com/d/msgid/weewx-development/f2054656-1b0e-41e3-932a-d0f60fcfb336%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEBZQdovT3CiVoUVOijW2nwmh_Qt0kKZyqgOmhfZk0gM%3DA%40mail.gmail.com.

Re: [weewx-development] state of the git repo, master/development considered very awkward

[Thomas Keffer]

The merge was intended (and usually is) done just before release. It was
our intention to do an immediate release, but we had some delays.

WeeWX may be a bit different from other software you are used to. We
*never* support
old releases. Either you upgrade, or you don't. There's nothing in between.
So, the usual work flow is to do the merge into master, then release.
There's no reason to have branches dedicated to maintaining older releases.

In this case, we did the merge, but then the development team was unable to
finish. So, it has been languishing.

We do our best, but sometimes paying jobs interfere.

-tk

On Sat, Feb 29, 2020 at 12:57 PM Greg Troxel  wrote:

> I have been following the messages about 4.0 alpha/beta stuff with
> interest, expecting to get around to testing some day.
>
> I just did a git remote update, and was surprised to find that master,
> which had previously been the stable branch, now contains 4.0beta
> (loosely speaking).  I must have missed the announcement of the big
> merge from develop, which I consider to be of huge import.  I spent a
> bit of time digging through to find out if there were any changes to 3.8
> since my last update, and concluded no.
>
> I realize opinions differ, but I think the master/develop scheme is
> awkward and difficult to deal with.  Yes, I realize that new unstable
> stuff goes on develop, and at some point develop is merged to master.
>
> But, I'm trying to be on 3.8, and get bug fixes, and not jump to 4 yet,
> until I can do a build/test and try the simulator.  Part of this is that
> I'm running NetBSD rather than Linux, which probably nobody has tested
> on, and probably it is fine, but I am basically doing the
> staging/qualify/upgrade normal IT change management thing, which I see
> as well within normal for anyone who is trying hard to avoid trouble.
>
> With the master/develop scheme, there are multiple serious problems:
>
>   I was trying to follow 3.8 stable, but if I "git pull", I jump
>   branches (even though we haven't had a release as far as I can tell).
>
>   If I want to follow 3.8 stable whether or not 4.0 is released, because
>   I want to choose when to jump branches, that's not just not automatic,
>   it's pretty difficult.
>
>   There is no mechanism to apply a bugfix to 3.8, as of the instant that
>   develop was merged to master.  (Yes, I get it that a branch could be
>   created retrospectively.  But the master/develop scheme militates
>   against that happening.)
>
> In contrast, the stable/master scheme is much easier to deal with:
>
>   master has new code on it (exactly like develop is today)
>
>   each stable branch has a branch, e.g. "stable-3.8", and fix commits
>   are put on it.  They are merged to master usually, just like master
>   commits are merged to develop usually (or cherry-picked from there).
>
>   when it's time to start a new stable for 4.0, a stable-4.0 is branched
>   off master.
>
>   people who want to switch from 3.8 to 4.0 do "git checkout
>   stable-4.0".  People who aren't ready yet don't.  There is no magic
>   and it is really obvious what one is on when typing 'git status'.
>
>   the downside is that people that pay zero attention and just git pull
>   remain on the stable branch they were on.  (I actually think that's a
>   good thing.)
>
>   The stable-3.8 branch remains indefinitely as one that could be
>   updated with a fix, and can easily be accessed by name.
>
>
> So this is a long way of saying that today the master/develop felt
> extremely awkward, for no real overall benefit, and I'd like to suggest
> changing to stable/master.
>
>
> Now, I realize that a lot of people are using git to get code, when
> those people do not necessarily understand git.  I wonder if the
> master/develop scheme's main point is that a naive checkout gets one the
> most recent stable.  So maybe getting that benefit without all the pain
> of master/develop would be:
>
>   develop: new code codes here
>
>   stable-N: branched off develop for new branches, and each one gets bug
>   fixes
>
>   master: the highest stable-N is merged to master, so that master is
>   always the most recent version of the most recent stable.  The only
>   point of master, and the only use, is people that do checkouts and
>   don't understand git or weewx well enough to choose a stable branch
>   explicitly.  (IMHO, these people should be using distribution
>   packages, not git.)
>
>
> Thanks for listening to me rant,
> Greg
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/rmiblphyuuz.fsf%40s1.lexort.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from 

Re: [weewx-development] Re: is there a driver (not extension) for http get of json data ?

[Thomas Keffer]

I suspect they meant the Davis WeatherLink Live logger:
https://github.com/weewx/weewx/issues/412

-tk

On Tue, Feb 25, 2020 at 4:22 PM Bob Weber  wrote:

>
>
> On Tuesday, February 25, 2020 at 3:23:58 PM UTC-5, Vince Skahan wrote:
>>
>> I'm working with a user who is looking to get weewx running vs. his Davis
>> WeatherLink IP device.   There's no driver for that currently, although
>> there's an issue open on it in the weewx repo.
>>
>>
>>
> Am I missing something?  I have been using the Vantage driver for years
> with my WeatherLink IP data logger connected to an Envoy.  You can even
> tell the  WeatherLink IP data logger to stop updating the Davis website (at
> least in the older firmware I have).  Just set they type = ethernet, the
> host = data logger IP address and tcp_port = data logger port to use
> (probably 2)
>
> ... bob
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/4e002188-0c64-4d3a-b3df-35fa122a466f%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] My experience upgrading from Weewx 3.92 to Weewx 4.0.0b12 on a system with both Python-2.7.17 and Python-3.8.1

[Thomas Keffer]

The other option would be to make python3 the default in setup.py.

On Mon, Feb 17, 2020 at 7:23 AM Joel Bion  wrote:

> Thank you both for your swift replies!
>
> Here's where my mistake was rooted: I assumed weewx 4.0 only supported
> Python3, and missed the point that it was written to support both Python2
> and Python3 simultaneously. Therefore, I just followed the instructions in
> 'upgrading.htm' - and assumed that the upgrade steps would upgrade my weewx
> to one supporting Python3.
>
> But, since weewx supports both, just executing "./setup.py ..." as
> mentioned in 'upgrading.htm' chooses the python based on the "env python"
> in the first line of the setup.py script, it meant that a Python2 based
> upgrade happened, creating binaries that referenced "/usr/bin/python" vs
> "/usr/bin/python3".
>
> Since the errors reported upon weewx startup (and later, report
> generation) were so trivial to resolve in a couple of minutes (by just
> pulling in Cheetah3, PyMysql and Pillow with pip3), I never dug more deeply
> into the documentation to see what was wrong. It was so easy to resolve.
>
> Most of my time was spent scanning through the weewx-purpleair extension.
> Since it had been written to support only Python2, I didn't want to make
> just the syntactic changes, but convince myself that the rest of the script
> would actually do what was intended. It's a short script - but the reason I
> am taking a while to send the changes upstream is that I want to see if the
> divisions (/)  in the script should be changed to floor divisions (//) to
> mimic Python2's behavior - and I want to make sure the results look
> reasonable over a period of time before suggesting them upstream.
>
> Yes, if I were installing weewx from scratch, the few minutes spent at the
> start would not have been needed, as the setup.htm documentation does
> indeed mention python3 compatible packages. :)
>
> Overall, it was a very easy experience, with weewx working flawlessly,
> with the only possible suggestion from me being this: that there be some
> sort of text in upgrading.htm about upgrading weewx from python2 to python3.
>
> -Joel
>
> On Monday, February 17, 2020 at 6:12:51 AM UTC-8, John Kline wrote:
>>
>> Assuming you used setup.py to install, a lot of this is covered in the
>> documentation.  For example, you’ll find the python3 packages you need to
>> install.  You’ll also see the steps to install are:
>>
>> python3 ./setup.py build
>> sudo python3 ./setup.py install
>>
>> With the above steps, you won’t need to hand edit the scripts to use
>> python3.
>>
>> To view the WeeWX 4 setup guide in HTML, click the link below:
>>
>>
>> https://htmlpreview.github.io/?https://raw.githubusercontent.com/weewx/weewx/master/docs/setup.htm
>>
>>
>> On Feb 17, 2020, at 6:02 AM, Joel Bion  wrote:
>>
>> 
>> My system still has Python2 installed. I also have Python-3.8.1. Here's
>> what I had to do to get weewx 4.0.0b12 working on my system, which supports
>> both python2 and python3 simultaneously:
>>
>>1. Since "python" on my system resolves to Python2 - I had to change
>>the executable scripts in /home/weewx/bin to have hashbangs that 
>> referenced
>>/usr/bin/python3
>>2. I had to install PyMySQL for Python3. MySQLdb/MySQL-Python just
>>didn't work for me. PyMySQL worked like a charm.
>>3. I had to install Cheetah3.
>>4. I had to install Pillow for images support. The very old "imaging"
>>package (I think v1.1.7?) didn't work for me with Python3.
>>5. As to other Python packages needed for weewx under Python3, I
>>haven't checked. I had a good number installed already. The above
>>(Cheetah3, PyMySQL, Pillow) were the ones I had to install because I did
>>not already have them under Python3.
>>6. I wondered how old the stuff was in the bin/user directory - and
>>there were a couple of extensions I no longer used, which I just removed,
>>and then I upgraded my versions of __init__.py and extensions.py from the
>>4.0.0b12 source tree. To get the 'purpleair' extension working in Python3,
>>I had to make a couple of syntax edits (print is a function, not a
>>statement) and (exception handling uses the 'as' keyword). When I see the
>>'purpleair' extension working for a week or so, I will send these trivial
>>edits up-stream.
>>
>> The above got me running on a system supporting both Python2 and Python3.
>> Total work was probably about 60-90 minutes; not bad! It was nice to see
>> how relatively easy it was upgrading to WeeWx 4.0, and all of the changes I
>> had to make had nothing to do with the Weewx code.
>>
>> I'm scanning through the weewx doc to see if it references the newer
>> Python3 modules, but with the work-week beginning, that may not happen
>> right away.
>>
>> At some point, when GCC 10.0 comes out, it will be time to rebuild my
>> system from the ground up. (I use linuxfromscratch, which is sort of a
>> 'build-it-yourself step-by-step 

Re: [weewx-development] My experience upgrading from Weewx 3.92 to Weewx 4.0.0b12 on a system with both Python-2.7.17 and Python-3.8.1

[Thomas Keffer]

Hi, Joel

Thanks for your feedback!

Question: did you look through the install instructions in docs/setup.htm?
How do they compare with your experience? Are they pretty much on target?



On Mon, Feb 17, 2020 at 6:02 AM Joel Bion  wrote:

> My system still has Python2 installed. I also have Python-3.8.1. Here's
> what I had to do to get weewx 4.0.0b12 working on my system, which supports
> both python2 and python3 simultaneously:
>
>1. Since "python" on my system resolves to Python2 - I had to change
>the executable scripts in /home/weewx/bin to have hashbangs that referenced
>/usr/bin/python3
>2. I had to install PyMySQL for Python3. MySQLdb/MySQL-Python just
>didn't work for me. PyMySQL worked like a charm.
>3. I had to install Cheetah3.
>4. I had to install Pillow for images support. The very old "imaging"
>package (I think v1.1.7?) didn't work for me with Python3.
>5. As to other Python packages needed for weewx under Python3, I
>haven't checked. I had a good number installed already. The above
>(Cheetah3, PyMySQL, Pillow) were the ones I had to install because I did
>not already have them under Python3.
>6. I wondered how old the stuff was in the bin/user directory - and
>there were a couple of extensions I no longer used, which I just removed,
>and then I upgraded my versions of __init__.py and extensions.py from the
>4.0.0b12 source tree. To get the 'purpleair' extension working in Python3,
>I had to make a couple of syntax edits (print is a function, not a
>statement) and (exception handling uses the 'as' keyword). When I see the
>'purpleair' extension working for a week or so, I will send these trivial
>edits up-stream.
>
> The above got me running on a system supporting both Python2 and Python3.
> Total work was probably about 60-90 minutes; not bad! It was nice to see
> how relatively easy it was upgrading to WeeWx 4.0, and all of the changes I
> had to make had nothing to do with the Weewx code.
>
> I'm scanning through the weewx doc to see if it references the newer
> Python3 modules, but with the work-week beginning, that may not happen
> right away.
>
> At some point, when GCC 10.0 comes out, it will be time to rebuild my
> system from the ground up. (I use linuxfromscratch, which is sort of a
> 'build-it-yourself step-by-step distribution.) When I do that, I am going
> to try to have a python3-only system under which to try to run Weewx.
>
> -Joel
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/dd3aefaa-b407-4d35-808d-542acdeb3d80%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEBGA9Hyu-AbbC%3D_FoWgQY_8cP294mC3suKrhhpZSwKCmw%40mail.gmail.com.

Re: [weewx-development] How to exit the service (without crashing the main process of WeeWx)?

[Thomas Keffer]

Things like this should really be run in another thread, which then
communicates with the main thread. It's easy to hang, or even crash, the
main thread if it is dependent on a network connection.

For a fairly simple example of how this is done, look at the weewx-nmea-xdr

service. On startup, it sets up a separate thread, then connects it to the
main thread via a queue. The thread blocks on a serial port. When data
comes in, the thread packages it, then sends it down the queue to the main
thread.

You can do something similar using a socket instead of a serial port.

Now that I think about it, take a look around in the forums. Surely someone
has done something close to what you need!

-tk

On Wed, Feb 12, 2020 at 1:42 PM Tarmo  wrote:

> How to exit the service (to try again later) in an exception without
> crashing the main WeeWx process?
>
> Let's say, I want to connect to a host:
>def connect(self):
> try:
> self.hp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> self.hp.connect(self.host, self.port)
> except socket.error as e:
> logerr("Error: connection failed {}".format(e))
> self.hp.close()
>
>
>
> Now, in case of an exception, I would like to return gracefully to the
> main WeeWx thread without crashing it and try on the next archive interval.
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/1ed99eeb-426e-4c6a-a4e2-90bc2b6566ea%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEBo7kYfZVr7KYE2zVKH5pgrLteaVtDy5znPS%3DcjRHQP0A%40mail.gmail.com.

Re: [weewx-development] WeeWx archiving

[Thomas Keffer]

Yes, modulo DST weirdness, you should see 288 counts per day.

Are the high counts consistent? That is, every day?

-tk

On Tue, Feb 11, 2020 at 1:44 PM  wrote:

> I’ll admit I haven’t dug deep into the code (yet); but, I’m trying to
> understand how weewx processes archive vs loop records and how those
> eventually get aggregated into the “archive_day” tables.
>
>
>
> I have loop_interval = 2.5 and archive_interval = 300, if that makes any
> difference.
>
>
>
> Anyway, what I would have expected is to see at MOST 288 (24*12), maybe
> +/- 1,  counts in the “archive_day” tables:
>
>
>
> Instead, I have below – can anyone offer some insight?
>
>
>
> Thanks!
>
> Clay Jackson
>
>
>
> MariaDB [weewx]> select dateTime, from_unixtime(dateTime), `count` from
> archive_day_wind where `count` > 12*24;
>
> ++-+---+
>
> | dateTime   | from_unixtime(dateTime) | count |
>
> ++-+---+
>
> | 1509865200 | 2017-11-05 00:00:00 |   297 |
>
> | 1541314800 | 2018-11-04 00:00:00 |   298 |
>
> | 1572764400 | 2019-11-03 00:00:00 |   294 |
>
> ++-+---+
>
>
>
> MariaDB [weewx]> select avg(`count`) from archive_day_wind;
>
> +--+
>
> | avg(`count`) |
>
> +--+
>
> | 282.1309 |
>
> +--+
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/231a01d5e124%247116a780%245343f680%24%40n7qnm.net
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEDjH-yu9%3DRHEECFe%3DhaaTrx2yGdAdfGBaiR0nv8HD5F_Q%40mail.gmail.com.

Re: [weewx-development] 4.0.0b11: table archive_day_wind is not created anymore

[Thomas Keffer]

That's no different. You've always needed to specify WXDaySummaryManager to
get a wind daily summary.

OK, now I feel better that we understand what happened.

-tk

On Tue, Feb 11, 2020 at 11:04 AM Bernhard R.  wrote:

> Found the culprit:
>
> [DataBindings]
>
> [[wx_binding]]
>
>  #manager = weewx.manager.DaySummaryManager   # does not 
> recreate
> archive_day_wind
>  manager = weewx.wxmanager.WXDaySummaryManager# *works!*
> (archive_day_wind is created)
>
> just in case someone else does similar things one day...
>
>
>
> Am Dienstag, 11. Februar 2020 19:45:25 UTC+1 schrieb Bernhard R.:
>>
>> Hi Tom,
>>
>> must be some obscure quirks in my weewx.conf.
>>
>> I did a lot of other tests, but finally, I used b12 with the unmodified
>> b6 conf file (just adapting the version string) and archive_day_wind is
>> created and filled again.
>>
>> I'll now adapt the configs line by line and repeat the rebuild process
>> after each change to find my error, but you are right (of course) it's not
>> a regression in b11, it's a stupid user changing things in files he should
>> have understood before doing so...
>>
>> Anyways, thanks a lot for your help and sorry for wasting your time...
>>
>> bernhard :-)
>>
>>
>>
>> Am Dienstag, 11. Februar 2020 18:42:46 UTC+1 schrieb Tom Keffer:
>>>
>>> Hmm, I'm unable to reproduce this.
>>>
>>> I created a schema "schema_with_sunshine_time", derived off the wview
>>> schema (NB: *not* wview_extended), then created the database. It had
>>> archive_day_wind
>>>
>>> Then I dropped and rebuilt the daily summaries. Still has
>>> archive_day_wind.
>>>
>>> This is using v4.0.0b12
>>>
>>> -tk
>>>
>>> On Tue, Feb 11, 2020 at 8:57 AM Bernhard R.  wrote:
>>>
 Hi Tom,

 the --rebuild-daily was done on 4.0.0b11 version and the table
 archive_day_wind is not recreated.

 All others that are usually present are created as they should
 (including the ones for the custom fields), only wind is missing.

 Thanks for your patience,

 Bernhard :-)





 Am Dienstag, 11. Februar 2020 17:46:38 UTC+1 schrieb Tom Keffer:
>
> Sorry. I guess I need to rephrase that. Did you do the --rebuild-daily
> under the buggy version? Sounds like you did.
>
> That would explain the "regression".
>
> -tk
>
> On Tue, Feb 11, 2020 at 8:43 AM Bernhard R. 
> wrote:
>
>> Hi Tom,
>>
>> The answer was ment to be the second last line of my previous message:
>>
>> > The database was initially created on v.3.9.1 and extended by 2
>> columns with wee_database under 4.0.0b6.
>>
>> Was this th information you were asking for?
>>
>> I'll take a look at the new type of extension in the meantime...
>>
>> Thanks a lot,
>>
>> Bernhard :-)
>>
>> PS: sorry for accidentially answering by email previously...
>>
>>
>>
>> Am Dienstag, 11. Februar 2020 17:36:52 UTC+1 schrieb Tom Keffer:
>>>
>>> V4.0 introduces a new way to specify a schema, although the old way
>>> is still supported.
>>>
>>> The "wview" schema uses the old way.
>>>
>>> The "wview_extended" schema uses the new way. How to extend it is
>>> documented in the new version of the customizing guide. See the section
>>> "Adding a new type to the database".
>>>
>>> You used an old-style addition on the new-style schema
>>> wview_extended. That's why it didn't work.
>>>
>>> But, you didn't answer my question. Did you create the new database
>>> using V4.0.0b11, or an earlier version, which, perhaps, contained the 
>>> bug?
>>>
>>> Cheers,
>>>
>>> -tk
>>>
>>>
>>> On Tue, Feb 11, 2020 at 8:28 AM Bernhard R. 
>>> wrote:
>>>
 Hi Tom,

 I redefined the schema in a user extension (user.sunduration) like
 this:
 *schema_with_sunshine_time* = schemas.wview.schema +
 [('sunshine_time', 'REAL')] + [('sunshine_int', 'INTEGER')]

 and use this schema in weewx.conf:
 # The schema defines the structure of the database.
 # It is *only* used when the database is created.
 # schema = schemas.wview_extended.schema
 schema = user.sunduration.*schema_with_sunshine_time*

 When I now naively try to redefine the extended schema (following
 the defaults) in my user extension like that

 import schemas.wview_extended
 schema_with_sunshine_time = schemas.wview_extended.schema +
 [('sunshine_time', 'REAL')] + [('sunshine_int', 'INTEGER')]

 wee_database would fail with error:

 TypeError: unsupported operand type(s) for +: 'dict' and 'list'


 The database was initially created on v.3.9.1 and extended by 2
 columns with wee_database under 4.0.0b6.

Re: [weewx-development] 4.0.0b11: table archive_day_wind is not created anymore

[Thomas Keffer]

Hmm, I'm unable to reproduce this.

I created a schema "schema_with_sunshine_time", derived off the wview
schema (NB: *not* wview_extended), then created the database. It had
archive_day_wind

Then I dropped and rebuilt the daily summaries. Still has archive_day_wind.

This is using v4.0.0b12

-tk

On Tue, Feb 11, 2020 at 8:57 AM Bernhard R.  wrote:

> Hi Tom,
>
> the --rebuild-daily was done on 4.0.0b11 version and the table
> archive_day_wind is not recreated.
>
> All others that are usually present are created as they should (including
> the ones for the custom fields), only wind is missing.
>
> Thanks for your patience,
>
> Bernhard :-)
>
>
>
>
>
> Am Dienstag, 11. Februar 2020 17:46:38 UTC+1 schrieb Tom Keffer:
>>
>> Sorry. I guess I need to rephrase that. Did you do the --rebuild-daily
>> under the buggy version? Sounds like you did.
>>
>> That would explain the "regression".
>>
>> -tk
>>
>> On Tue, Feb 11, 2020 at 8:43 AM Bernhard R.  wrote:
>>
>>> Hi Tom,
>>>
>>> The answer was ment to be the second last line of my previous message:
>>>
>>> > The database was initially created on v.3.9.1 and extended by 2
>>> columns with wee_database under 4.0.0b6.
>>>
>>> Was this th information you were asking for?
>>>
>>> I'll take a look at the new type of extension in the meantime...
>>>
>>> Thanks a lot,
>>>
>>> Bernhard :-)
>>>
>>> PS: sorry for accidentially answering by email previously...
>>>
>>>
>>>
>>> Am Dienstag, 11. Februar 2020 17:36:52 UTC+1 schrieb Tom Keffer:

 V4.0 introduces a new way to specify a schema, although the old way is
 still supported.

 The "wview" schema uses the old way.

 The "wview_extended" schema uses the new way. How to extend it is
 documented in the new version of the customizing guide. See the section
 "Adding a new type to the database".

 You used an old-style addition on the new-style schema wview_extended.
 That's why it didn't work.

 But, you didn't answer my question. Did you create the new database
 using V4.0.0b11, or an earlier version, which, perhaps, contained the bug?

 Cheers,

 -tk


 On Tue, Feb 11, 2020 at 8:28 AM Bernhard R.  wrote:

> Hi Tom,
>
> I redefined the schema in a user extension (user.sunduration) like
> this:
> *schema_with_sunshine_time* = schemas.wview.schema +
> [('sunshine_time', 'REAL')] + [('sunshine_int', 'INTEGER')]
>
> and use this schema in weewx.conf:
> # The schema defines the structure of the database.
> # It is *only* used when the database is created.
> # schema = schemas.wview_extended.schema
> schema = user.sunduration.*schema_with_sunshine_time*
>
> When I now naively try to redefine the extended schema (following the
> defaults) in my user extension like that
>
> import schemas.wview_extended
> schema_with_sunshine_time = schemas.wview_extended.schema +
> [('sunshine_time', 'REAL')] + [('sunshine_int', 'INTEGER')]
>
> wee_database would fail with error:
>
> TypeError: unsupported operand type(s) for +: 'dict' and 'list'
>
>
> The database was initially created on v.3.9.1 and extended by 2
> columns with wee_database under 4.0.0b6.
>
> Does this narrow it down a bit, is there some additional info I can
> supply, to help tracinf this?
>
> Thanks for all your efforts so far,
>
> Bernhard :-)
>
>
> Am Montag, 10. Februar 2020 23:52:09 UTC+1 schrieb Tom Keffer:
>>
>> Hmmm, I thought this was fixed in commit
>> https://github.com/weewx/weewx/commit/ba096b752493134442b222c5c4fa4b49bcef1d84,
>> now four months ago. Have you generated the new database using V4.0.0b11,
>> or an earlier version, which, perhaps, contained the bug?
>>
>> Also, can you take a look in your weewx.conf and see what type of
>> schema you have? This will look something like:
>>
>> [DataBindings]
>>
>> [[wx_binding]]
>> ...
>> # The schema defines the structure of the database.
>> # It is *only* used when the database is created.
>> schema = schemas.wview_extended.schema
>>
>>
>>
>> On Mon, Feb 10, 2020 at 10:33 AM Bernhard R. 
>> wrote:
>>
>>> Hi there,
>>>
>>> I guess, I stumbled over a regression somewhere between 4.0.0b6 and
>>> 4.0.0b11.
>>>
>>> if I do
>>> wee_database /etc/weewx/weewx.conf --drop-daily
>>> and afterwards
>>> wee_database /etc/weewx/weewx.conf --rebuild-daily
>>>
>>> then table *archive_day_wind* is NOT created anymore when using
>>> weewx 4.0.0.b11
>>> also letting weewx create the statistics upon start (after dropping
>>> them once again) will not create this table either.
>>>
>>> However, the table still seems to be referenced by the included
>>> default skins, resulting in 

Re: [weewx-development] 4.0.0b11: table archive_day_wind is not created anymore

[Thomas Keffer]

Sorry. I guess I need to rephrase that. Did you do the --rebuild-daily
under the buggy version? Sounds like you did.

That would explain the "regression".

-tk

On Tue, Feb 11, 2020 at 8:43 AM Bernhard R.  wrote:

> Hi Tom,
>
> The answer was ment to be the second last line of my previous message:
>
> > The database was initially created on v.3.9.1 and extended by 2 columns
> with wee_database under 4.0.0b6.
>
> Was this th information you were asking for?
>
> I'll take a look at the new type of extension in the meantime...
>
> Thanks a lot,
>
> Bernhard :-)
>
> PS: sorry for accidentially answering by email previously...
>
>
>
> Am Dienstag, 11. Februar 2020 17:36:52 UTC+1 schrieb Tom Keffer:
>>
>> V4.0 introduces a new way to specify a schema, although the old way is
>> still supported.
>>
>> The "wview" schema uses the old way.
>>
>> The "wview_extended" schema uses the new way. How to extend it is
>> documented in the new version of the customizing guide. See the section
>> "Adding a new type to the database".
>>
>> You used an old-style addition on the new-style schema wview_extended.
>> That's why it didn't work.
>>
>> But, you didn't answer my question. Did you create the new database
>> using V4.0.0b11, or an earlier version, which, perhaps, contained the bug?
>>
>> Cheers,
>>
>> -tk
>>
>>
>> On Tue, Feb 11, 2020 at 8:28 AM Bernhard R.  wrote:
>>
>>> Hi Tom,
>>>
>>> I redefined the schema in a user extension (user.sunduration) like this:
>>> *schema_with_sunshine_time* = schemas.wview.schema + [('sunshine_time',
>>> 'REAL')] + [('sunshine_int', 'INTEGER')]
>>>
>>> and use this schema in weewx.conf:
>>> # The schema defines the structure of the database.
>>> # It is *only* used when the database is created.
>>> # schema = schemas.wview_extended.schema
>>> schema = user.sunduration.*schema_with_sunshine_time*
>>>
>>> When I now naively try to redefine the extended schema (following the
>>> defaults) in my user extension like that
>>>
>>> import schemas.wview_extended
>>> schema_with_sunshine_time = schemas.wview_extended.schema +
>>> [('sunshine_time', 'REAL')] + [('sunshine_int', 'INTEGER')]
>>>
>>> wee_database would fail with error:
>>>
>>> TypeError: unsupported operand type(s) for +: 'dict' and 'list'
>>>
>>>
>>> The database was initially created on v.3.9.1 and extended by 2 columns
>>> with wee_database under 4.0.0b6.
>>>
>>> Does this narrow it down a bit, is there some additional info I can
>>> supply, to help tracinf this?
>>>
>>> Thanks for all your efforts so far,
>>>
>>> Bernhard :-)
>>>
>>>
>>> Am Montag, 10. Februar 2020 23:52:09 UTC+1 schrieb Tom Keffer:

 Hmmm, I thought this was fixed in commit
 https://github.com/weewx/weewx/commit/ba096b752493134442b222c5c4fa4b49bcef1d84,
 now four months ago. Have you generated the new database using V4.0.0b11,
 or an earlier version, which, perhaps, contained the bug?

 Also, can you take a look in your weewx.conf and see what type of
 schema you have? This will look something like:

 [DataBindings]

 [[wx_binding]]
 ...
 # The schema defines the structure of the database.
 # It is *only* used when the database is created.
 schema = schemas.wview_extended.schema



 On Mon, Feb 10, 2020 at 10:33 AM Bernhard R. 
 wrote:

> Hi there,
>
> I guess, I stumbled over a regression somewhere between 4.0.0b6 and
> 4.0.0b11.
>
> if I do
> wee_database /etc/weewx/weewx.conf --drop-daily
> and afterwards
> wee_database /etc/weewx/weewx.conf --rebuild-daily
>
> then table *archive_day_wind* is NOT created anymore when using weewx
> 4.0.0.b11
> also letting weewx create the statistics upon start (after dropping
> them once again) will not create this table either.
>
> However, the table still seems to be referenced by the included
> default skins, resulting in errors upon cheetahgenerator runs.
>
> When I revert to version 4.0.0b6 and repeat the process, the table
> archive_day_wind is created just fine.
>
> Is this intentional (and the skin templates need to be adjusted
> accodingly) or is this a regression?
>
> anyways, Thanks for the great work done so far,
>
> Bernhard :-)
>
> --
> You received this message because you are subscribed to the Google
> Groups "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to weewx-de...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/b245c089-33f8-45ac-bf5e-80f3ed62c75e%40googlegroups.com
> 
> .
>
 --
>>> You received this message because you are 

Re: [weewx-development] 4.0.0b11: table archive_day_wind is not created anymore

[Thomas Keffer]

V4.0 introduces a new way to specify a schema, although the old way is
still supported.

The "wview" schema uses the old way.

The "wview_extended" schema uses the new way. How to extend it is
documented in the new version of the customizing guide. See the section
"Adding a new type to the database".

You used an old-style addition on the new-style schema wview_extended.
That's why it didn't work.

But, you didn't answer my question. Did you create the new database using
V4.0.0b11, or an earlier version, which, perhaps, contained the bug?

Cheers,

-tk


On Tue, Feb 11, 2020 at 8:28 AM Bernhard R.  wrote:

> Hi Tom,
>
> I redefined the schema in a user extension (user.sunduration) like this:
> *schema_with_sunshine_time* = schemas.wview.schema + [('sunshine_time',
> 'REAL')] + [('sunshine_int', 'INTEGER')]
>
> and use this schema in weewx.conf:
> # The schema defines the structure of the database.
> # It is *only* used when the database is created.
> # schema = schemas.wview_extended.schema
> schema = user.sunduration.*schema_with_sunshine_time*
>
> When I now naively try to redefine the extended schema (following the
> defaults) in my user extension like that
>
> import schemas.wview_extended
> schema_with_sunshine_time = schemas.wview_extended.schema +
> [('sunshine_time', 'REAL')] + [('sunshine_int', 'INTEGER')]
>
> wee_database would fail with error:
>
> TypeError: unsupported operand type(s) for +: 'dict' and 'list'
>
>
> The database was initially created on v.3.9.1 and extended by 2 columns
> with wee_database under 4.0.0b6.
>
> Does this narrow it down a bit, is there some additional info I can
> supply, to help tracinf this?
>
> Thanks for all your efforts so far,
>
> Bernhard :-)
>
>
> Am Montag, 10. Februar 2020 23:52:09 UTC+1 schrieb Tom Keffer:
>>
>> Hmmm, I thought this was fixed in commit
>> https://github.com/weewx/weewx/commit/ba096b752493134442b222c5c4fa4b49bcef1d84,
>> now four months ago. Have you generated the new database using V4.0.0b11,
>> or an earlier version, which, perhaps, contained the bug?
>>
>> Also, can you take a look in your weewx.conf and see what type of schema
>> you have? This will look something like:
>>
>> [DataBindings]
>>
>> [[wx_binding]]
>> ...
>> # The schema defines the structure of the database.
>> # It is *only* used when the database is created.
>> schema = schemas.wview_extended.schema
>>
>>
>>
>> On Mon, Feb 10, 2020 at 10:33 AM Bernhard R.  wrote:
>>
>>> Hi there,
>>>
>>> I guess, I stumbled over a regression somewhere between 4.0.0b6 and
>>> 4.0.0b11.
>>>
>>> if I do
>>> wee_database /etc/weewx/weewx.conf --drop-daily
>>> and afterwards
>>> wee_database /etc/weewx/weewx.conf --rebuild-daily
>>>
>>> then table *archive_day_wind* is NOT created anymore when using weewx
>>> 4.0.0.b11
>>> also letting weewx create the statistics upon start (after dropping them
>>> once again) will not create this table either.
>>>
>>> However, the table still seems to be referenced by the included default
>>> skins, resulting in errors upon cheetahgenerator runs.
>>>
>>> When I revert to version 4.0.0b6 and repeat the process, the table
>>> archive_day_wind is created just fine.
>>>
>>> Is this intentional (and the skin templates need to be adjusted
>>> accodingly) or is this a regression?
>>>
>>> anyways, Thanks for the great work done so far,
>>>
>>> Bernhard :-)
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-de...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-development/b245c089-33f8-45ac-bf5e-80f3ed62c75e%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/e916b4b8-17dc-44e7-986c-d773cedf5183%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] weewx no longer starts weewx-Version 4

[Thomas Keffer]

Most likely the problem is exactly what the traceback suggests: a syntax
error in weeusb.conf, line 240.

On Tue, Feb 11, 2020 at 7:49 AM Hartmut Schweidler 
wrote:

> After an update, weewx no longer starts
> I haven't made any changes to weeusb.conf
> under cmon.conf and weekl.conf weewx really only starts with
> weeusb.conf only appears
>
> Feb 11 16:13:57 hesba weewx-weekl[1687] INFO __main__:   Terminate
> Feb 11 16:13:58 hesba weewx-weekl[13414] INFO __main__: Initializing weewx
> version 4.0.0b11
> Feb 11 16:13:58 hesba weewx-weekl[13414] INFO __main__: Using Python
> 3.7.3rc1 (default, Mar 13 2019, 11:01:15) #012[GCC 8.3.0]
> Feb 11 16:13:58 hesba weewx-weekl[13414] INFO __main__: Platform
> Linux-3.4.104+-armv7l-with-debian-9.11
> Feb 11 16:13:58 hesba weewx-weekl[13414] INFO __main__: Locale is
> 'de_DE.UTF-8'
> Feb 11 16:13:58 hesba weewx-weekl[13414] INFO __main__: PID file is
> /var/run/weewx-weekl.pid
> Feb 11 16:13:58 hesba weewx-weekl[13418] INFO __main__: Using
> configuration file /home/weewx/weekl.conf
> Feb 11 16:13:58 hesba weewx-weekl[13418] INFO weewx.engine: Loading
> station type KlimaLogg (user.kl)
> Feb 11 16:13:58 hesba weewx-weekl[13418] INFO user.kl: driver version is
> 1.4.0
> Feb 11 16:13:58 hesba weewx-weekl[13418] INFO user.kl: channel is 1
> Feb 11 16:13:58 hesba weewx-weekl[13418] INFO user.kl: frequency is EU
> Feb 11 16:13:58 hesba weewx-weekl[13418] INFO user.kl: sensor map is: ...
>
> Feb 11 16:38:40 hesba weewx-weeusb[19347] INFO __main__: Initializing
> weewx version 4.0.0b11
> Feb 11 16:38:40 hesba weewx-weeusb[19347] INFO __main__: Using Python
> 3.7.3rc1 (default, Mar 13 2019, 11:01:15) #012[GCC 8.3.0]
> Feb 11 16:38:40 hesba weewx-weeusb[19347] INFO __main__: Platform
> Linux-3.4.104+-armv7l-with-debian-9.12
> Feb 11 16:38:40 hesba weewx-weeusb[19347] INFO __main__: Locale is
> 'de_DE.UTF-8'
> Feb 11 16:38:40 hesba weewx-weeusb[19347] INFO __main__: PID file is
> /var/run/weewx-weeusb.pid
> Feb 11 16:39:01 hesba CRON[19370]: (root) CMD (/home/bild/bild_eingang.sh
> 1>/dev/null 2>&1)
> Feb 11 16:40:01 hesba CRON[19396]: (root) CMD (/home/bild/bild_eingang.sh
> 1>/dev/null 2>&1)
> Feb 11 16:40:18 hesba weewx-weekl[13418] INFO weewx.manager: Added record
> 2020-02-11 16:40:00 CET (1581435600) to database 'weewxHausTemp'
> Feb 11 16:40:18 hesba weewx-weekl[13418] INFO weewx.manager: Added record
> 2020-02-11 16:40:00 CET (1581435600) to daily summary in 'weewxHausTemp'
> Feb 11 16:40:23 hesba weewx-cmon[1711] INFO weewx.manager: Added record
> 2020-02-11 16:40:00 CET (1581435600) to database 'weewxHausCmon'
> Feb 11 16:40:24 hesba weewx-cmon[1711] INFO weewx.manager: Added record
> 2020-02-11 16:40:00 CET (1581435600) to daily summary in 'weewxHausCmon'
> Feb 11 16:40:24 hesba weewx-cmon[1711] INFO weewx.engine: Garbage
> collected 2889 objects in 0.14 seconds
>
> the message is missing "INFO __main__: Using configuration file
> /home/weewx/weeusb.conf"
>
> debug is 1 in weeusb.conf
>
> if i call
>
> root@hesba:/home/weewx/bin# ./weewxd /home/weewx/weeusb.conf
> Traceback (most recent call last):
>   File "./weewxd", line 261, in 
> main()
>   File "./weewxd", line 125, in main
> config_path, config_dict = weecfg.read_config(options.config_path,
> list(args))
>   File "/home/weewx/bin/weecfg/__init__.py", line 177, in read_config
> default_encoding='utf-8')
>   File "/usr/lib/python3/dist-packages/configobj.py", line 1229, in
> __init__
> self._load(infile, configspec)
>   File "/usr/lib/python3/dist-packages/configobj.py", line 1318, in _load
> raise error
> configobj.ConfigObjError: Parsing failed with several errors.
> First error at line 240.
>
> any idea
>
> Hartmut
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/021f9775-ddec-4d5c-8757-53dc6f42e428%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEA2RdytTS1YprUwiDAX49j3VaP-Q9hnebvY27_9-ieyvw%40mail.gmail.com.

Re: [weewx-development] 4.0.0b11: table archive_day_wind is not created anymore

[Thomas Keffer]

Hmmm, I thought this was fixed in commit
https://github.com/weewx/weewx/commit/ba096b752493134442b222c5c4fa4b49bcef1d84,
now four months ago. Have you generated the new database using V4.0.0b11,
or an earlier version, which, perhaps, contained the bug?

Also, can you take a look in your weewx.conf and see what type of schema
you have? This will look something like:

[DataBindings]

[[wx_binding]]
...
# The schema defines the structure of the database.
# It is *only* used when the database is created.
schema = schemas.wview_extended.schema



On Mon, Feb 10, 2020 at 10:33 AM Bernhard R.  wrote:

> Hi there,
>
> I guess, I stumbled over a regression somewhere between 4.0.0b6 and
> 4.0.0b11.
>
> if I do
> wee_database /etc/weewx/weewx.conf --drop-daily
> and afterwards
> wee_database /etc/weewx/weewx.conf --rebuild-daily
>
> then table *archive_day_wind* is NOT created anymore when using weewx
> 4.0.0.b11
> also letting weewx create the statistics upon start (after dropping them
> once again) will not create this table either.
>
> However, the table still seems to be referenced by the included default
> skins, resulting in errors upon cheetahgenerator runs.
>
> When I revert to version 4.0.0b6 and repeat the process, the table
> archive_day_wind is created just fine.
>
> Is this intentional (and the skin templates need to be adjusted
> accodingly) or is this a regression?
>
> anyways, Thanks for the great work done so far,
>
> Bernhard :-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/b245c089-33f8-45ac-bf5e-80f3ed62c75e%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEDuRiD6w1oX1Un-zrxoe_%2BFvTevCTaksc5FCNrLsQKqiA%40mail.gmail.com.

Re: [weewx-development] Too much info in syslog for weewx

[Thomas Keffer]

The module "w34rt" is producing the packet. It's not part of WeeWX and I'm
not familiar with it. You'll have to look through that module to figure out
how to shut off the log messages.

One thing to try is to just set debug=0 in weewx.conf. Perhaps it will
respond to that.

-tk

-tk

On Sun, Jan 19, 2020 at 4:59 AM Ray Burg  wrote:

> Hi All,
>   My syslog is being filled with the loop packets from weewx and I cannot
> find how to stop it.
>
> It makes it hard to find any errors when I am bombarded by these
> messages...
>
> I am running Beta 4 rel 9
>
> Here is an example:
>
> Jan 19 23:49:33 WeatherPI weewxd: w34rt: Event packet after: {'monthET':
> 0.0, 'outsideAlarm2': 0, 'rainAlarm': 0, 'dayET': 0.0, 'maxSolarRad': 0.0,
> 'consBatteryVoltage': 4.28, 'monthRain': 2.62, 'insideAlarm': 0,
> 'barometer': 29.644, 'dateTime': 1579438173, 'stormRain': 0.0, 'sunrise':
> 1579374480.0, 'windchill': 70.7, 'dewpoint': 68.88429374546376,
> 'outsideAlarm1': 0, 'forecastIcon': 3, 'heatindex': 70.7, 'forecastRule':
> 192, 'outHumidity': 94.0, 'stormStart': 1579093200, 'inDewpoint':
> 63.145822964960885, 'inHumidity': 59.0, 'windSpeed10': 0.0, 'yearRain':
> 2.62, 'inTemp': 78.7, 'extraAlarm1': 0, 'extraAlarm2': 0, 'extraAlarm3': 0,
> 'extraAlarm4': 0, 'extraAlarm5': 0, 'extraAlarm6': 0, 'extraAlarm7': 0,
> 'extraAlarm8': 0, 'rainRate': 0.0, 'rain': 0.0, 'humidex':
> 85.0674769607422, 'pressure': 29.543151717591297, 'soilLeafAlarm4': 0,
> 'soilLeafAlarm2': 0, 'soilLeafAlarm3': 0, 'beaufort': 0, 'soilLeafAlarm1':
> 0, 'leafWet4': 0.0, 'yearET': 0.0, 'txBatteryStatus': 0, 'appTemp':
> 77.78000921543449, 'dayRain': 0.01, 'windDir': 132.0, 'outTemp': 70.7,
> 'windSpeed': 0.0, 'sunset': 1579424784.0, 'windGust': 1.0, 'usUnits': 1,
> 'windGustDir': 99.0, 'cloudbase': 510.6605123945995}
> Jan 19 23:49:35 WeatherPI weewxd: w34rt: Event packet before: {'monthET':
> 0.0, 'heatindex': 70.7, 'outHumidity': 94.0, 'dayET': 0.0, 'humidex':
> 85.0674769607422, 'consBatteryVoltage': 4.28, 'monthRain': 2.62,
> 'insideAlarm': 0, 'barometer': 29.644, 'dayRain': 0.01, 'stormRain': 0.0,
> 'sunrise': 1579374480.0, 'windchill': 70.7, 'dewpoint': 68.88429374546376,
> 'outsideAlarm1': 0, 'rainRate': 0.0, 'outsideAlarm2': 0, 'forecastRule':
> 192, 'rainAlarm': 0, 'inTemp': 78.7, 'inHumidity': 59.0, 'windSpeed10':
> 0.0, 'yearRain': 2.62, 'windGustDir': 99.0, 'extraAlarm1': 0,
> 'extraAlarm2': 0, 'extraAlarm3': 0, 'extraAlarm4': 0, 'extraAlarm5': 0,
> 'extraAlarm6': 0, 'extraAlarm7': 0, 'extraAlarm8': 0, 'soilLeafAlarm2': 0,
> 'maxSolarRad': 0.0, 'pressure': 29.543151717591297, 'beaufort': 0, 'rain':
> 0.0, 'soilLeafAlarm4': 0, 'forecastIcon': 3, 'soilLeafAlarm3': 0,
> 'usUnits': 1, 'soilLeafAlarm1': 0, 'leafWet4': 0.0, 'yearET': 0.0,
> 'txBatteryStatus': 0, 'appTemp': 77.78000921543449, 'inDewpoint':
> 63.145822964960885, 'dateTime': 1579438175, 'windDir': None, 'outTemp':
> 70.7, 'windSpeed': 0.0, 'sunset': 1579424784.0, 'windGust': 1.0,
> 'cloudbase': 510.6605123945995}
> Jan 19 23:49:35 WeatherPI weewxd: w34rt: Event packet after: {'monthET':
> 0.0, 'outsideAlarm2': 0, 'rainAlarm': 0, 'dayET': 0.0, 'maxSolarRad': 0.0,
> 'consBatteryVoltage': 4.28, 'monthRain': 2.62, 'insideAlarm': 0,
> 'barometer': 29.644, 'dateTime': 1579438175, 'stormRain': 0.0, 'sunrise':
> 1579374480.0, 'windchill': 70.7, 'dewpoint': 68.88429374546376,
> 'outsideAlarm1': 0, 'forecastIcon': 3, 'heatindex': 70.7, 'forecastRule':
> 192, 'outHumidity': 94.0, 'stormStart': 1579093200, 'inDewpoint':
> 63.145822964960885, 'inHumidity': 59.0, 'windSpeed10': 0.0, 'yearRain':
> 2.62, 'inTemp': 78.7, 'extraAlarm1': 0, 'extraAlarm2': 0, 'extraAlarm3': 0,
> 'extraAlarm4': 0, 'extraAlarm5': 0, 'extraAlarm6': 0, 'extraAlarm7': 0,
> 'extraAlarm8': 0, 'rainRate': 0.0, 'rain': 0.0, 'humidex':
> 85.0674769607422, 'pressure': 29.543151717591297, 'soilLeafAlarm4': 0,
> 'soilLeafAlarm2': 0, 'soilLeafAlarm3': 0, 'beaufort': 0, 'soilLeafAlarm1':
> 0, 'leafWet4': 0.0, 'yearET': 0.0, 'txBatteryStatus': 0, 'appTemp':
> 77.78000921543449, 'dayRain': 0.01, 'windDir': 132.0, 'outTemp': 70.7,
> 'windSpeed': 0.0, 'sunset': 1579424784.0, 'windGust': 1.0, 'usUnits': 1,
> 'windGustDir': 99.0, 'cloudbase': 510.6605123945995}
> Jan 19 23:49:37 WeatherPI weewxd: w34rt: Event packet before: {'monthET':
> 0.0, 'heatindex': 70.7, 'outHumidity': 94.0, 'dayET': 0.0, 'humidex':
> 85.0674769607422, 'consBatteryVoltage': 4.28, 'monthRain': 2.62,
> 'insideAlarm': 0, 'barometer': 29.644, 'dayRain': 0.01, 'stormRain': 0.0,
> 'sunrise': 1579374480.0, 'windchill': 70.7, 'dewpoint': 68.88429374546376,
> 'outsideAlarm1': 0, 'rainRate': 0.0, 'outsideAlarm2': 0, 'forecastRule':
> 192, 'rainAlarm': 0, 'inTemp': 78.7, 'inHumidity': 59.0, 'windSpeed10':
> 0.0, 'yearRain': 2.62, 'windGustDir': 99.0, 'extraAlarm1': 0,
> 'extraAlarm2': 0, 'extraAlarm3': 0, 'extraAlarm4': 0, 'extraAlarm5': 0,
> 'extraAlarm6': 0, 'extraAlarm7': 0, 'extraAlarm8': 0, 'soilLeafAlarm2': 0,
> 'maxSolarRad': 0.0, 'pressure': 29.543151717591297, 

Re: [weewx-development] Crash with 4.0.0b6

[Thomas Keffer]

One of the strings in the file that filepile is reading cannot be converted
to a number. It probably looks something like

outTemp =

or possibly

outTemp = ""

This is probably a bug in filepile. It should accept either of these,
returning None for the value. Fixed in commit 3863f21

.

Thanks for your detailed report!

-tk


On Tue, Jan 7, 2020 at 9:15 PM Ralph Underwood  wrote:

> My system crashed this afternoon.  This is the log starting with the last
> successful Ftp.  I had been working on my MQTT sensor code, adding some
> delay to cut down on the file writes to the SD card.
>
> My setup is an RPi 4 with an Ultimeter Station and an additional BME280
> sensor connected to a Huzzah ESP8266 that publishes an MQTT payload. I have
> a little Python3 program that subscribes to the MQTT and writes a file for
> the file pile service. This basic set up has been working for several days,
> until I restarted the MQTT based sensor, the MQTT messages are being
> published OK and all looked good. I thought I heard rain and looked to my
> web site and the time was 15:45 on the site, real time was about 19:00.
>
> So my question is - did I uncover a bug or did I screw something up.
>
> Jan  7 15:45:26 JV-Wx weewx[24318] INFO weewx.reportengine: ftpgenerator:
> Ftp'd 24 files in 9.25 seconds
> Jan  7 15:45:26 JV-Wx weewx[24318] DEBUG weewx.reportengine: reportengine:
> Report 'RSYNC' not enabled. Skipping.
> Jan  7 15:50:15 JV-Wx weewx[24318] INFO weewx.engine: Main loop exiting.
> Shutting engine down.
> Jan  7 15:50:15 JV-Wx weewx[24318] INFO weewx.engine: Shutting down
> StdReport thread
> Jan  7 15:50:15 JV-Wx weewx[24318] DEBUG weewx.engine: StdReport thread
> has been terminated
> Jan  7 15:50:15 JV-Wx weewx[24318] DEBUG weewx.drivers.ultimeter: Close
> serial port /dev/ttyUSB0
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: Caught
> unrecoverable exception:
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine:   could
> not convert string to float:
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
>  Traceback (most recent call last):
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: File
> "/home/weewx/bin/weewx/engine.py", line 201, in run
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
>  self.dispatchEvent(weewx.Event(weewx.CHECK_LOOP, packet=packet))
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: File
> "/home/weewx/bin/weewx/engine.py", line 230, in dispatchEvent
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
>  callback(event)
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: File
> "/home/weewx/bin/weewx/engine.py", line 582, in check_loop
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
>  raise BreakLoop
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
>  weewx.engine.BreakLoop
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine:   During
> handling of the above exception, another exception occurred:
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
>  Traceback (most recent call last):
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: File
> "/home/weewx/bin/weewx/engine.py", line 598, in post_loop
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
>  self._catchup(self.engine.console.genArchiveRecords)
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: File
> "/home/weewx/bin/weewx/engine.py", line 639, in _catchup
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
>  for record in generator(lastgood_ts):
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: File
> "/home/weewx/bin/weewx/drivers/__init__.py", line 30, in genArchiveRecords
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
>  raise NotImplementedError("Method 'genArchiveRecords' not implemented")
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
>  NotImplementedError: Method 'genArchiveRecords' not implemented
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine:   During
> handling of the above exception, another exception occurred:
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
>  Traceback (most recent call last):
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: File
> "/home/weewx/bin/weewx/engine.py", line 903, in main
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL weewx.engine: 
>  engine.run()
> Jan  7 15:50:16 JV-Wx weewx[24318] CRITICAL 

Re: [weewx-development] MySql Create tables crash

[Thomas Keffer]

Yup. That's a bug! Fixed in commit 6ad9870

.

Thanks, Jaap.

-tk

On Tue, Jan 7, 2020 at 2:16 PM Jaap de Munck  wrote:

> Hello,
>
> Problem with MySql and create new table.
>
> weewx.manager: Created and initialized table 'archive5' in database 'weewx'
> weewx.engine: Caught unrecoverable exception:
>   (1050, "Table 'archive_day_barometer' already exists")
>   Traceback (most recent call last):
> File "/home/weewx/bin/weedb/mysql.py", line 51, in guarded_fn
>   return fn(*args, **kwargs)
> File "/home/weewx/bin/weedb/mysql.py", line 261, in execute
>   self.cursor.execute(mysql_string, tuple(sql_tuple))
> File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 250, in
> execute
>   self.errorhandler(self, exc, value)
> File "/usr/lib/python3/dist-packages/MySQLdb/connections.py", line 50,
> in defaulterrorhandler
>   raise errorvalue
> File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 247, in
> execute
>   res = self._query(query)
> File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 411, in
> _query
>   rowcount = self._do_query(q)
> File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 374, in
> _do_query
>   db.query(q)
> File "/usr/lib/python3/dist-packages/MySQLdb/connections.py", line
> 292, in query
>   _mysql.connection.query(self, query)
>   _mysql_exceptions.OperationalError: (1050, "Table
> 'archive_day_barometer' already exists")
>
> Its from a new test system. (Installed with install-weewx.sh).
> At first start an Sqlite database is created (can all be seen in attached
> logging). Stopped.
> Configuration was then changed to a MySql database: The current MySql
> database schema/user (for the 'production' system) but with a new tablename
> archive5.
> Tabel archive5 is created ok.
>
> Regards,
> Jaap
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/a9eb77ce-82f9-44e2-9bd1-6d21c4323add%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEBpinmWtLOZx6Po5M1NMMNSbjgUAiaMxLM9Qw-%3DGcxH6Q%40mail.gmail.com.

Re: [weewx-development] Re: Y axis scale on both sides of graphs

[Thomas Keffer]

Unfortunately, no, it is not possible. There can be only one scale on a
plot.

On Tue, Jan 7, 2020 at 7:52 AM Bernhard Walser  wrote:

> Hello,
> im interrestet in two Y-axis with different units(humidy, radiation), in
> one plot. is this possible with your genplot.py?
>
> Am Donnerstag, 14. Februar 2019 01:03:38 UTC+1 schrieb Bob Smith:
>>
>> I have a modified genplot.py file that puts the y axis scale on both
>> sides of the generated graph images. Do I commit it on Github to have it
>> looked at and incorporated or do I need to contact someone to have this
>> modification done?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/41b6512c-7dd5-4950-8f04-1b1ca28832de%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEBXHT4isrrYos_CQs2M%2BYtc-b3suJrzKSSwfgWZdzo31A%40mail.gmail.com.

Re: [weewx-development] WeeWx 4 and 1-wire

[Thomas Keffer]

Glad that's working out. Unfortunately, we can't always depend on six being
around when running under Python 2.

Another option would be

try:
ow.init(self.interface)
except TypeError:
ow.init(self.interface.encode())



On Thu, Jan 2, 2020 at 1:30 PM Jaap de Munck  wrote:

> Hi Tom,
>
> Thanks for your quick reaction (mine took a bit too long).
>
> Good guess, you were right..
> With a special treatment for Python2 like
>
> if six.PY2:
> ow.init(self.interface.encode())
> else:
> ow.init(self.interface)
>
> It runs on all (Weewx4-python3; Weewx4-python2.7 and Weewx3.9-python2.7)
>
> Here is the new version (attached).
>
> Jaap
>
>
> Op dinsdag 24 december 2019 01:50:40 UTC+1 schreef Tom Keffer:
>>
>> I'm just guessing, but you could try to change line 488 in owfs.py from
>> this
>>
>> ow.init(self.interface)
>>
>> to this
>>
>> ow.init(self.interface.encode())
>>
>> -tk
>>
>>
>> On Mon, Dec 23, 2019 at 3:46 PM Jaap de Munck  wrote:
>>
>>> Hello,
>>>
>>> No problems with Vantage (Pro) and Weewx 4!
>>> But I also have a 1-wire sensor. OWFS isn't Python3 ready yet, so I
>>> tried to do that myself.
>>> The result seemed not so bad. It is running on Python3!
>>> It's also running on Python2.7: I copied it back to the 'production'
>>> system running weewx 3.9.2.
>>> Later the Weewx 4 test environment was switched back to Python2
>>> resulting in:
>>>
>>> CRITICAL weewx.engine: Caught unrecoverable exception:
>>> CRITICAL weewx.engine:   in method 'init', argument 1 of type
>>> 'char const *'
>>> CRITICAL weewx.engine:   Traceback (most recent call last):
>>> CRITICAL weewx.engine: File
>>> "/home/weewx/bin/weewx/engine.py", line 886, in main
>>> CRITICAL weewx.engine:   engine = StdEngine(config_dict)
>>> CRITICAL weewx.engine: File
>>> "/home/weewx/bin/weewx/engine.py", line 83, in __init__
>>> CRITICAL weewx.engine:   self.loadServices(config_dict)
>>> CRITICAL weewx.engine: File
>>> "/home/weewx/bin/weewx/engine.py", line 143, in loadServices
>>> CRITICAL weewx.engine:   obj =
>>> weeutil.weeutil.get_object(svc)(self,config_dict)
>>> CRITICAL weewx.engine: File "/home/weewx/bin/user/owfs.py",
>>> line 488, in __init__
>>> CRITICAL weewx.engine:   ow.init(self.interface)
>>> CRITICAL weewx.engine: File
>>> "/usr/lib/python2.7/dist-packages/ow/__init__.py", line 220, in init
>>> CRITICAL weewx.engine:   if not _OW.init( iface ):
>>> CRITICAL weewx.engine:   TypeError: in method 'init', argument 1
>>> of type 'char const *'
>>> CRITICAL weewx.engine:   Exiting.
>>>
>>> The logging (attached) is from a (virtual) Debian10 environment and
>>> Weewx4 + Simulator driver. But it also occurs with Ubuntu 19.04 and Weewx4
>>> + Vantage driver.
>>>
>>> Best wishes,
>>> Jaap
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-de...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-development/a160e60b-57fd-444f-bfb2-7bb9fb139366%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/679a0365-7b70-4915-b7b7-0bc0f0ad8a83%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

Respectively, disagree. At this point, editing the pages on weewx.conf is
not only more work, but would add to the confusion. Python 3? Version 3.x
supports Python 3?

-tk

On Thu, Jan 2, 2020 at 12:45 PM Vince Skahan  wrote:

> On Thursday, January 2, 2020 at 11:32:21 AM UTC-8, Tom Keffer wrote:
>>
>> The instructions that come with V4 invokes setup.py with an explicit call
>> to python.
>>
>>
>>
> Yes, it does indeed.
>
> But the legacy v3 web pages that most folks likely read along with (I know
> that's where I look) have the less preferred syntax.   In the days of only
> python2 that was probably ok, but I was just suggesting that perhaps a
> quick edit on the web pages might help lessen confusion.  It's not always
> self-evident to dig down into the html-formated docs subdirectory when
> trying to install the v4 beta.
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/abf24a39-0e18-4d95-baa2-6e20ad955ecb%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zECEHne%3DaqDaOxNTdjSb-6H4THXeRhZWD45DUC3BfHa6mw%40mail.gmail.com.

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

The instructions that come with V4 invokes setup.py with an explicit call
to python.

-tk

On Thu, Jan 2, 2020 at 12:21 PM Vince Skahan  wrote:

> On Thursday, January 2, 2020 at 10:32:41 AM UTC-8, mwall wrote:
>>
>>
>>
>> On Thursday, January 2, 2020 at 1:16:06 PM UTC-5, Johannes Ebner wrote:
>>>
>>>
>>> Then I tried to install weewx but getting the following error:
>>>
>>> pi@Weewx:~/weewx-4.0.0b6 $ ./setup.py build
>>> Traceback (most recent call last):
>>>   File "./setup.py", line 21, in 
>>> import configobj
>>> ImportError: No module named configobj
>>>
>>>
>>> Any hints?
>>>
>>
>> you might want to be explicit about everything, at least until we get all
>> the dependencies sorted out.  if you 'source' an rc file you may not get
>> what you expect.
>>
>> there can be a huge difference between this:
>>
>> ./setup.py install
>>
>> and this:
>>
>> python ./setup.py install
>>
>> i find it best to do this:
>>
>> python2 ./setup.py install
>>
>> or, if you want to use python3:
>>
>> python3 ./setup.py install
>>
>>
>
> Matthew - the 'installation using setup.py' instructions on the web show
> "./setup.py" as the recommended syntax, not prefaced with "python".
>
> Might be worth a quick edit to specify your preferred syntax on what
> people see on the web, just in case people don't dig into the development
> branch docs for the v4 syntax (which looks ok to me)
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/9f2a87cc-b2c3-4159-be6a-56bb935a780e%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEBXOtfiJGwdFLhq80E4a2E-YLKO9crXBm33k7Tbq-DgtQ%40mail.gmail.com.

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

You're not giving much information, but it looks like you are trying to run
weewx as a daemon. Unless you changed the in init.d file you are using (or
systemd weewx.service), it is still invoking python 2. If you wish to run
as a daemon, you will need to change that file.

-tk

On Thu, Jan 2, 2020 at 12:07 PM Patrick Tranchant 
wrote:

> up
>
> installation done with setup.py = OK
> I try just now with "simulator" in weewx.conf =>
>
> but I had an error in syslog
>
> Jan  2 19:57:02 raspberrypi weewx[5741] INFO weewx.engine: Initializing
> weewx version 4.0.0b6
> Jan  2 19:57:02 raspberrypi weewx[5741] INFO weewx.engine: *Using Python
> 2.7.13 (default, Sep 26 2018, 18:42:22*)
> #012[GCC 6.3.0 20170516]
> Jan  2 19:57:02 raspberrypi weewx[5741] INFO weewx.engine: Platform
> Linux-4.14.71-v7+-armv7l-with-debian-9.4
> Jan  2 19:57:02 raspberrypi weewx[5741] INFO weewx.engine: Locale is
> 'fr_FR.UTF-8'
> Jan  2 19:57:02 raspberrypi weewx[5741] INFO weewx.engine: PID file is
> /var/run/weewx.pid
> Jan  2 19:57:02 raspberrypi weewx[5729]: Starting weewx weather system:
> weewx.
> Jan  2 19:57:02 raspberrypi systemd[1]: Started LSB: weewx weather system.
> Jan  2 19:57:02 raspberrypi weewx[5746] INFO weewx.engine: Using
> configuration file /home/weewx/weewx.conf
> Jan  2 19:57:02 raspberrypi weewx[5746] INFO weewx.engine: Loading station
> type Simulator (weewx.drivers.simulator)
>
> I have python 2.7 and python 3.5 installed on my RPi, I can deactived
> python 2.7 for test ?
>
> patrick
>
> On Monday, December 30, 2019 at 10:28:50 PM UTC+1, Tom Keffer wrote:
>>
>> ... is up. In the usual spot.
>> http://weewx.com/downloads/development_versions/
>>
>> -tk
>>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/05cedf4d-2ca3-4af7-b473-de8b2a4c87a0%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zECSthdh%2B%3Dez-runjwbZs0SsaQrTwnsjkETUrXbdNrfZrQ%40mail.gmail.com.

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

Teaching users to use virtualenv or pyenv sounds like a nightmare.

I wish Python's package management system was up to the task. Things are so
much easier in Javascript land.

-tk

On Thu, Jan 2, 2020 at 11:43 AM mwall  wrote:

> it has always been best practice to not modify the system's python.
> however, to do that strictly would mean that you must do one of these:
>
> * use python's virtualenv
> * install your own version of python, completely separately from the
> system python
> * install extensions to the system python using the --user option to 'pip
> install'
>
> none of those are particularly user-friendly.
>
> since weewx has minimal requirements, the docs use instructions that
> result in modification of the system's python installation.  typically that
> mean 'sudo pip install xxx'.  but on some systems you would have to first
> install pip, or you would have to use easy_install.
>
> i think we can continue this pattern - use the system's python - instead
> of complicating things for weewx users.  but only if we can keep the weewx
> dependencies to a minimum.
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/37665692-184e-4087-b31a-198e618d7336%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEAvQxw7DMDZHZR6zN4cSRb%2BaWuR35YWWjv8cF-3Cdsj%2BA%40mail.gmail.com.

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

Unfortunately, no. WeeWX V4 is only available for installation via the
setup.py.

However, it is easy enough to unpack the tarball someplace, then simply run
the unpacked weewxd using your old weewx.conf file. It should work fine.

-tk

On Thu, Jan 2, 2020 at 8:35 AM Patrick Tranchant  wrote:

>
> hello
>
> I can follow this procedure ?
>
> On Monday, December 30, 2019 at 10:28:50 PM UTC+1, Tom Keffer wrote:
>>
>> ... is up. In the usual spot.
>> http://weewx.com/downloads/development_versions/
>>
>> -tk
>>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/4e9f5ef6-9c26-48c4-8238-26b6bd968b68%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEAqE%2BDygUOa8r1FOwtFKu535S5sJTS3GyZZ_yNrEOw5mw%40mail.gmail.com.

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

The docs are in the "docs" subdirectory.

Installation is largely the same for Python 2, quite different for Python
3. Instructions are in the docs.

-tk

On Wed, Jan 1, 2020 at 12:24 PM Patrick Tranchant 
wrote:

> hello Tom
> happy new for all
>
> I downloaded version B6 to test on my BYOWS, where is the new doc ( if
> there is); the installation is the same of version 3.9.2 ?
> I have already python 3.5
>
> thanks
>
> patrick
>
> On Monday, December 30, 2019 at 10:28:50 PM UTC+1, Tom Keffer wrote:
>>
>> ... is up. In the usual spot.
>> http://weewx.com/downloads/development_versions/
>>
>> -tk
>>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/f55b6216-a9ec-42d2-b9f6-e1230502498b%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

Commit 2943038c
<https://github.com/weewx/weewx/commit/2943038c2bea3f2681a99ed502dc102539297ab7>
.

On Wed, Jan 1, 2020 at 8:27 AM Thomas Keffer  wrote:

> I've noticed that as well. That seems to be the way setup.py works:
> however you invoke it, is how it installs the executables.
>
> I will make a note in the setup docs.
>
> -tk
>
> On Wed, Jan 1, 2020 at 8:00 AM Cameron D  wrote:
>
>> A comment on the documentation.
>> I'm not sure if I missed it somewhere, but the docs say that if the
>> default python is v2 then  "...you would be happiest if you install using
>> Python 2".
>> In fact, I wouldn't. I'd like to ensure programs use python3 where
>> possible, but I don't want to change the system default just yet for fear
>> of killing other python code.
>>
>> What I found by accident was that explicitly using python3 to run
>> setup.py will configure the hash-bang lines to use python 3 but I don't
>> know if that is the appropriate way.  I was expecting a config option
>> somewhere but never saw any
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-development+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-development/775a2da5-5f18-4848-8ff4-0b0af20b1b7c%40googlegroups.com
>> <https://groups.google.com/d/msgid/weewx-development/775a2da5-5f18-4848-8ff4-0b0af20b1b7c%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEA-hZvJ2fOhR-ZmYXmpwB5RsOfwbhef0S09%2BMFY_mRBRQ%40mail.gmail.com.

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

I've noticed that as well. That seems to be the way setup.py works: however
you invoke it, is how it installs the executables.

I will make a note in the setup docs.

-tk

On Wed, Jan 1, 2020 at 8:00 AM Cameron D  wrote:

> A comment on the documentation.
> I'm not sure if I missed it somewhere, but the docs say that if the
> default python is v2 then  "...you would be happiest if you install using
> Python 2".
> In fact, I wouldn't. I'd like to ensure programs use python3 where
> possible, but I don't want to change the system default just yet for fear
> of killing other python code.
>
> What I found by accident was that explicitly using python3 to run setup.py
> will configure the hash-bang lines to use python 3 but I don't know if that
> is the appropriate way.  I was expecting a config option somewhere but
> never saw any
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/775a2da5-5f18-4848-8ff4-0b0af20b1b7c%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEC%2B-S-3vgEF%3DqiKdYh9SwpHRG5sEToXahBPXzgwH%2BmRzA%40mail.gmail.com.

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

Thanks for figuring that one out, Cameron! Nice sleuthing.

Fixed in commit 3f0d80a

.

-tk

On Wed, Jan 1, 2020 at 2:33 AM Cameron D  wrote:

> Hi Tom,
> 1. the failure to read history on DB initialisation was a trivial change,
> so I will submit that at some stage.
>
> 2. KeyError - a bit of background, the WMR300 unit returns date in
> METRICWX the unit set, which is partly why I chose that for my DB.  So wind
> speed is in m/s and as soon as I return the first new set of data from the
> history, it wants to calculate windrun which is group_distance.   If I used
> METRIC then it converts the speed to km/hour, which might be why it is
> happy with that.
>
> I added a convertion from 'meter' to 'km' in conversionDict in units.py
> and it seems to be happy.
>
> I have attached a log from startup to crash, with various debug lines of
> wmr300.py enabled, so you can see the exception happens as soon as it
> returns the first relevant historical record.
>
>
> On Tuesday, 31 December 2019 21:55:24 UTC+10, Tom Keffer wrote:
>>
>> Thanks, Cameron
>>
>> 1. Can you post the log where this happened?
>>
>> 2. Conversion from meter to km was never possible. Meter is a member of
>> group_altitude, and km is a member of group_distance. Can you give me the
>> context where this happened?
>>
>> -tk
>>
>>
>> On Tue, Dec 31, 2019 at 12:53 AM Cameron D 
>> wrote:
>>
>>> I have just started messing around with the beta 4 code.
>>>
>>> 1. the WMR300 driver seems to be basically working, both standalone
>>> under python3 and as part of weewx to a new sqlite db.  There is one small
>>> problem  -  it is not reading the history from the console because there is
>>> no time to which data was previously stored.  It's only a once-off problem
>>> but I'll see if there's an easy fix.  Once the database has a "last time"
>>> then the read history works as expected.  I would expect the bug is also
>>> present in the old version.
>>>
>>> 2. My system was based on METRICWX - If I configure v4 for that then it
>>> raises a KeyError exception:
>>>
>>>
 ...
>>>   File "/home/weewx/_base/bin/weewx/units.py", line 1190, in convert
>>> conversion_func = conversionDict[val_t[1]][target_unit_type]
>>> KeyError: 'km'
>>>
>>> and the log file reports:
>>>
>>>  DEBUG weewx.units: Unable to convert from meter to km
>>>
>>>
>>> Using METRIC seems to work fine.
>>> Happy to provide more logs if necessary.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-de...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-development/df802b4a-2833-4536-8133-797987f5e4cf%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/9bcb976a-af3e-4cb5-8854-08262a0508b7%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEB6OXns_3pWOBJMGtRP2zt60%3DVZNCFcUwz5tJmBLV5ftA%40mail.gmail.com.

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

>
> Mine's python 2.7.3 and configobj 4.7.2
>

Does the problem go away if you upgrade configobj to the current version,
5.0.6?

-tk

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEDJ6drx48O%3DH_HdDYSr-YKcpXm7D0BCfWwCDo8RaYH4Yw%40mail.gmail.com.

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

Ralph, the docs that come with WeeWX v4 should be correct. If you found a
mistake, please post it!

As for the Wiki, it will take some time for all the extension publishers to
switch to Python 3.

-tk

On Tue, Dec 31, 2019 at 4:27 PM Ralph Underwood  wrote:

> It was relatively painless to convert/upgrade my python code to 3.7.  A
> few stumbles as the great internet  has many wrong examples and
> "solutions". For instance trying to install pyehem - what worked is *sudo
> pip3 install ephem*
>
> Same kind of issues with install the mosquitto and paho client - being
> sure that the solutions are valid for python 3
>
> (google sure does like to "fix" spelling)
>
> I think that there will be a lot of work to update the docs and wiki for
> version 4 - probably can't get it done this year :)
>
> happy New Year.
>
>
>
> On Tuesday, December 31, 2019 at 3:13:59 PM UTC-8, Tom Keffer wrote:
>>
>> Come on, Python 2.6 is over 11 years old, and hasn't been supported for
>> well over 6 years! Time to upgrade!
>>
>> If you're running Python 3, WeeWX requires Python v3.5 or greater.
>> Versions before that do not support % formatting of bytes and bytearrays.
>>
>> Not sure what the problem is. Are you two using an old version of
>> configobj? That could do it. Try
>>
>> *python -c "import configobj; print(configobj.__version__)"*
>>
>>
>> -tk
>>
>> On Tue, Dec 31, 2019 at 11:42 AM Vince Skahan  wrote:
>>
>>> On Monday, December 30, 2019 at 1:28:50 PM UTC-8, Tom Keffer wrote:

 ... is up. In the usual spot.
 http://weewx.com/downloads/development_versions/


>>> Does b6 have a minimum python version ?
>>>
>>> Rolled the dice and tried an upgrade of my ancient Seagate Dockstar
>>> 3.9.0 to beta-6.  Fail on startup.
>>>
>>> Python is 2.7.3,  debian version is 7.6
>>> I'd have to compile my own python pieces from source to get a current
>>> version if you wanted me to try that.
>>> Same goes for trying to get to python3.  Nothing newer than 3.2.3
>>> available precompiled for this box.
>>>
>>> root@debian:/home/src/weewx-4.0.0b6# service weewx start
>>> [] Starting weewx weather system: weewxTraceback (most recent call
>>> last):
>>>   File "/home/weewx/bin/weewxd", line 16, in 
>>> import weewx.engine
>>>   File "/home/weewx/bin/weewx/engine.py", line 30, in 
>>> import weewx.accum
>>>   File "/home/weewx/bin/weewx/accum.py", line 95, in 
>>> defaults_dict = configobj.ConfigObj(StringIO(DEFAULTS_INI),
>>> encoding='utf-8')
>>>   File "/usr/lib/python2.7/dist-packages/configobj.py", line 1230, in
>>> __init__
>>> self._load(infile, configspec)
>>>   File "/usr/lib/python2.7/dist-packages/configobj.py", line 1290, in
>>> _load
>>> infile = self._handle_bom(infile)
>>>   File "/usr/lib/python2.7/dist-packages/configobj.py", line 1430, in
>>> _handle_bom
>>> if not line.startswith(BOM):
>>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xef in position 0:
>>> ordinal not in range(128)
>>>  failed!
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "weewx-development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to weewx-de...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-development/c71931fd-e57d-4f7d-94ec-60648a934f98%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/a7445948-6163-47d6-ad1b-5ec25e46e27b%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEA%2B9YEdRxJ5fO7cMpV45R2S2A-Dc_HwFywUUttD-wGZZQ%40mail.gmail.com.

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

Come on, Python 2.6 is over 11 years old, and hasn't been supported for
well over 6 years! Time to upgrade!

If you're running Python 3, WeeWX requires Python v3.5 or greater. Versions
before that do not support % formatting of bytes and bytearrays.

Not sure what the problem is. Are you two using an old version of
configobj? That could do it. Try

*python -c "import configobj; print(configobj.__version__)"*


-tk

On Tue, Dec 31, 2019 at 11:42 AM Vince Skahan  wrote:

> On Monday, December 30, 2019 at 1:28:50 PM UTC-8, Tom Keffer wrote:
>>
>> ... is up. In the usual spot.
>> http://weewx.com/downloads/development_versions/
>>
>>
> Does b6 have a minimum python version ?
>
> Rolled the dice and tried an upgrade of my ancient Seagate Dockstar 3.9.0
> to beta-6.  Fail on startup.
>
> Python is 2.7.3,  debian version is 7.6
> I'd have to compile my own python pieces from source to get a current
> version if you wanted me to try that.
> Same goes for trying to get to python3.  Nothing newer than 3.2.3
> available precompiled for this box.
>
> root@debian:/home/src/weewx-4.0.0b6# service weewx start
> [] Starting weewx weather system: weewxTraceback (most recent call
> last):
>   File "/home/weewx/bin/weewxd", line 16, in 
> import weewx.engine
>   File "/home/weewx/bin/weewx/engine.py", line 30, in 
> import weewx.accum
>   File "/home/weewx/bin/weewx/accum.py", line 95, in 
> defaults_dict = configobj.ConfigObj(StringIO(DEFAULTS_INI),
> encoding='utf-8')
>   File "/usr/lib/python2.7/dist-packages/configobj.py", line 1230, in
> __init__
> self._load(infile, configspec)
>   File "/usr/lib/python2.7/dist-packages/configobj.py", line 1290, in _load
> infile = self._handle_bom(infile)
>   File "/usr/lib/python2.7/dist-packages/configobj.py", line 1430, in
> _handle_bom
> if not line.startswith(BOM):
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xef in position 0:
> ordinal not in range(128)
>  failed!
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/c71931fd-e57d-4f7d-94ec-60648a934f98%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zECiLp_-WS0LUk%2BUNP6Mkde6T-a9uGkiW4P4FGeAUh_A_A%40mail.gmail.com.

Re: [weewx-development] Re: WeeWX Version 4, beta 6

[Thomas Keffer]

Thanks, Cameron

1. Can you post the log where this happened?

2. Conversion from meter to km was never possible. Meter is a member of
group_altitude, and km is a member of group_distance. Can you give me the
context where this happened?

-tk


On Tue, Dec 31, 2019 at 12:53 AM Cameron D  wrote:

> I have just started messing around with the beta 4 code.
>
> 1. the WMR300 driver seems to be basically working, both standalone under
> python3 and as part of weewx to a new sqlite db.  There is one small
> problem  -  it is not reading the history from the console because there is
> no time to which data was previously stored.  It's only a once-off problem
> but I'll see if there's an easy fix.  Once the database has a "last time"
> then the read history works as expected.  I would expect the bug is also
> present in the old version.
>
> 2. My system was based on METRICWX - If I configure v4 for that then it
> raises a KeyError exception:
>
>
>> ...
>   File "/home/weewx/_base/bin/weewx/units.py", line 1190, in convert
> conversion_func = conversionDict[val_t[1]][target_unit_type]
> KeyError: 'km'
>
> and the log file reports:
>
>  DEBUG weewx.units: Unable to convert from meter to km
>
>
> Using METRIC seems to work fine.
> Happy to provide more logs if necessary.
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/df802b4a-2833-4536-8133-797987f5e4cf%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEB6FLnEg0TH3LR3PtSWEOY6e2mg3%2BPg%3D0Rcbhazjy4HXg%40mail.gmail.com.

Re: [weewx-development] Is this a bug? 4.0.0.b5

[Thomas Keffer]

Could you try beta 6, just posted?

http://weewx.com/downloads/development_versions/

-tk

On Mon, Dec 30, 2019 at 8:11 AM KSKENYON  wrote:

> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine: File "/home/weewx/bin/weewx/engine.py", line 892,
> in main*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine:   engine.run()*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine: File "/home/weewx/bin/weewx/engine.py", line 196,
> in run*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine: 
> self.dispatchEvent(weewx.Event(weewx.NEW_LOOP_PACKET, packet=packet))*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine: File "/home/weewx/bin/weewx/engine.py", line 229,
> in dispatchEvent*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine:   callback(event)*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine: File "/home/weewx/bin/weewx/wxservices.py", line
> 88, in new_loop_packet*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine:   self.calc.new_loop_packet(event.packet)*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine: File "/home/weewx/bin/weewx/wxservices.py", line
> 153, in new_loop_packet*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine:   self.rain_rater.add_loop_packet(loop_packet,
> self.db_manager)*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine: File "/home/weewx/bin/weewx/wxservices.py", line
> 608, in add_loop_packet*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine:   rain = weewx.units.convertStd((record['rain'],
> u, g), self.unit_system)[0]*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine: File "/home/weewx/bin/weewx/units.py", line 1222,
> in convertStd*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine:   return
> StdUnitConverters[target_std_unit_system].convert(val_t)*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine:   KeyError: None*
>
> Dec 30 00:00:04 mythtv weewxd[1011003]: *weewx[1011003] CRITICAL
> weewx.engine:   Exiting.*
>
> Dec 30 00:00:04 mythtv python[1011003]: detected unhandled Python
> exception in '/home/weewx/bin/weewxd'
>
> Dec 30 00:00:04 mythtv systemd[1]: *weewx.service: Main process exited,
> code=exited, status=1/FAILURE*
>
>
> *It happens every night at midnight during a report generate.  Running
> standard Simulator engine.*
>
> *Kevin*
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/ab1b3430-6d0a-41a6-af70-02b426873a8e%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEAoKKiep2fXHZu8Sfi-qYxFdgBYXBrARc0%3DctXz%2BKidrw%40mail.gmail.com.

[weewx-development] WeeWX Version 4, beta 6

[Thomas Keffer]

... is up. In the usual spot.
http://weewx.com/downloads/development_versions/

-tk

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

Re: [weewx-development] V4.0.0b4 is up

[Thomas Keffer]

I think it is too. So we don't go chasing old bugs, I've posted beta 6.

On Mon, Dec 30, 2019 at 10:03 AM Vince Skahan  wrote:

> On Monday, December 30, 2019 at 8:37:11 AM UTC-8, Andy wrote:
>>
>> Weewx stops when rain starts. Log attached. I have not spent much time
>> looking into this yet and could be a layer 8 issue.
>>
>>
>>
> Sounds like the problem I reported a while back -
> https://groups.google.com/forum/#!topic/weewx-development/IoTUyFA21pY
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/1459736d-d51d-4c11-a1cf-c6985b4e2470%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] Vantage 3.2.0 driver not converting dayRain correctly for mm bucket sizes (weewx 4.0.0b5)

[Thomas Keffer]

Fixed in commit 554f5b3

.

Thanks, James, for your thorough debugging. Having a US bucket, I would
never have caught that.

-tk

On Tue, Dec 24, 2019 at 6:46 AM James Taylor <
ja...@blisteringbarnacles.co.uk> wrote:

> Tom
>
> Yes I have the 2mm bucket, therefore started to spot the graphs and
> numbers misbehaving when I was getting x.3mm and x.5mm of rain values being
> reported!
>
> I found this under the 3.1.1 so I'm guessing it should the same _loop_map
> entries so yes monthRain and yearRain as well.
>
> if self.rain_bucket_type == 1:
> _archive_map['rain'] = _archive_map['rainRate'] =
> _loop_map['stormRain'] = _loop_map['dayRain'] = \
> _loop_map['monthRain'] = _loop_map['yearRain'] = _bucket_1
> _loop_map['rainRate'] = _bucket_1_None
>
> A quick sql update and rebuild of the archive database restored all the
> reporting.
>
> James
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/66484266-0c5a-4068-aa35-f8a9de427f90%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEAXNaHQxxUt18CirPJkCcFMw9rHfx0Fh7ZsNn45i%3DrVfw%40mail.gmail.com.

Re: [weewx-development] Vantage 3.2.0 driver not converting dayRain correctly for mm bucket sizes (weewx 4.0.0b5)

[Thomas Keffer]

I believe you're right. Can we conclude that monthRain and yearRain need to
be changed as well?

You didn't say what kind of rain bucket you have. From your note, it sounds
like a 0.2mm bucket. Is that right?

-tk



On Tue, Dec 24, 2019 at 2:44 AM James Taylor <
ja...@blisteringbarnacles.co.uk> wrote:

> Hello
>
> Since installing and testing 4.0.0b5 (working really well) I noticed my
> rain reports were reporting incorrectly and going in jumps of 2.54mm rather
> than 2mm.
>
> I looked at the data in the archive database (using METRIC), and it was
> reporting rain as 0.0254 (ie 0.254cm)
>
> Looking at the loop data as well and it was reporting 0.06 inch for
> dayRain (0.15cm), though my weather station is reporting 0.12cm
>
> LOOP:   2019-12-24 08:22:06 GMT (1577175726) appTemp: 40.77673899893075,
> barometer: 29.771, beaufort: 2, cloudbase: 653.4402820747907,
> consBatteryVoltage: 4.68, dateTime: 1577175726, dayET: 0.0, dayRain: 0.06,
> dewpoint: 43.92886275887092, extraAlarm1: 0, extraAlarm2: 0, extraAlarm3:
> 0, extraAlarm4: 0, extraAlarm5: 0, extraAlarm6: 0, extraAlarm7: 0,
> extraAlarm8: 0, forecastIcon: 8, forecastRule: 120, heatindex: 45.0,
> humidex: 45.0, inDewpoint: 50.31047742263314, inHumidity: 50.0,
> insideAlarm: 0, inTemp: 69.8, leafWet4: 0.0, maxSolarRad:
> 0.2677935114636761, monthET: 0.38, monthRain: 5.01, outHumidity: 96.0,
> outsideAlarm1: 0, outsideAlarm2: 0, outTemp: 45.0, pressure:
> 29.32375790783909, radiation: 8.4, rain: None, rainAlarm: 0, rainRate: 0.0,
> soilLeafAlarm1: 0, soilLeafAlarm2: 0, soilLeafAlarm3: 0, soilLeafAlarm4: 0,
> stormRain: 0.0472440942, stormStart: 1577145600, sunrise: 1577174880.0,
> sunset: 1577205168.0, txBatteryStatus: 0, usUnits: 1, UV: 0.0, windchill:
> 42.34519893957256, windDir: 221.0, windGust: 5.0, windGustDir: 221.0,
> windSpeed: 5.0, windSpeed10: 5.0, yearET: 27.93, yearRain: 29.23
>
> In summary I started looking at the vantage.py code and I believe it is
> because dayRain said
>
> 'dayRain' : lambda p, k: float(p[k]) / 100.0,
>
> and I think it should be calling the _decode_rain function
>
> _loop_map = {
> 'altimeter'   : lambda p, k: float(p[k]) / 1000.0 if p[k] else
> None,
> 'barometer'   : lambda p, k: float(p[k]) / 1000.0 if p[k] else
> None,
> 'consBatteryVoltage': lambda p, k: float((p[k] * 300) >> 9) / 100.0,
> 'dayET'   : lambda p, k: float(p[k]) / 1000.0,
> 'dayRain' : _decode_rain,
> 'dewpoint': lambda p, k: float(p[k]) if p[k] & 0xff != 0xff
> else None,
>
> Loop data is now reporting 0.0472440942 inch which equals 0.12cm.
>
> LOOP:   2019-12-24 09:04:03 GMT (1577178243) appTemp: 42.50129603384309,
> barometer: 29.775, beaufort: 1, cloudbase: 717.0811874901804,
> consBatteryVoltage: 4.68, dateTime: 1577178243, dayET: 0.0, dayRain:
> 0.0472440942, dewpoint: 44.64884277504321, extraAlarm1: 0, extraAlarm2: 0,
> extraAlarm3: 0, extraAlarm4: 0, extraAlarm5: 0, extraAlarm6: 0,
> extraAlarm7: 0, extraAlarm8: 0, forecastIcon: 8, forecastRule: 120,
> heatindex: 46.0, humidex: 46.040897257508945, inDewpoint:
> 49.675285300449026, inHumidity: 49.0, insideAlarm: 0, inTemp: 69.7,
> leafWet4: 0.0, maxSolarRad: 20.265282927928308, monthET: 0.38, monthRain:
> 5.01, outHumidity: 95.0, outsideAlarm1: 0, outsideAlarm2: 0, outTemp: 46.0,
> pressure: 29.327744885181772, radiation: 25.2, rain: None, rainAlarm: 0,
> rainRate: 0.0, soilLeafAlarm1: 0, soilLeafAlarm2: 0, soilLeafAlarm3: 0,
> soilLeafAlarm4: 0, stormRain: 0.0472440942, stormStart: 1577145600,
> sunrise: 1577174880.0, sunset: 1577205168.0, txBatteryStatus: 0, usUnits:
> 1, UV: 0.0, windchill: 44.249603120917584, windDir: 212.0, windGust: 4.0,
> windGustDir: 212.0, windSpeed: 4.0, windSpeed10: 5.0, yearET: 27.93,
> yearRain: 29.23
>
> James
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/d60cf791-032a-4c65-88fa-71ed5fae0d64%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] WeeWx 4 and 1-wire

[Thomas Keffer]

I'm just guessing, but you could try to change line 488 in owfs.py from this

ow.init(self.interface)

to this

ow.init(self.interface.encode())

-tk


On Mon, Dec 23, 2019 at 3:46 PM Jaap de Munck  wrote:

> Hello,
>
> No problems with Vantage (Pro) and Weewx 4!
> But I also have a 1-wire sensor. OWFS isn't Python3 ready yet, so I tried
> to do that myself.
> The result seemed not so bad. It is running on Python3!
> It's also running on Python2.7: I copied it back to the 'production'
> system running weewx 3.9.2.
> Later the Weewx 4 test environment was switched back to Python2 resulting
> in:
>
> CRITICAL weewx.engine: Caught unrecoverable exception:
> CRITICAL weewx.engine:   in method 'init', argument 1 of type
> 'char const *'
> CRITICAL weewx.engine:   Traceback (most recent call last):
> CRITICAL weewx.engine: File "/home/weewx/bin/weewx/engine.py",
> line 886, in main
> CRITICAL weewx.engine:   engine = StdEngine(config_dict)
> CRITICAL weewx.engine: File "/home/weewx/bin/weewx/engine.py",
> line 83, in __init__
> CRITICAL weewx.engine:   self.loadServices(config_dict)
> CRITICAL weewx.engine: File "/home/weewx/bin/weewx/engine.py",
> line 143, in loadServices
> CRITICAL weewx.engine:   obj =
> weeutil.weeutil.get_object(svc)(self,config_dict)
> CRITICAL weewx.engine: File "/home/weewx/bin/user/owfs.py",
> line 488, in __init__
> CRITICAL weewx.engine:   ow.init(self.interface)
> CRITICAL weewx.engine: File
> "/usr/lib/python2.7/dist-packages/ow/__init__.py", line 220, in init
> CRITICAL weewx.engine:   if not _OW.init( iface ):
> CRITICAL weewx.engine:   TypeError: in method 'init', argument 1
> of type 'char const *'
> CRITICAL weewx.engine:   Exiting.
>
> The logging (attached) is from a (virtual) Debian10 environment and Weewx4
> + Simulator driver. But it also occurs with Ubuntu 19.04 and Weewx4 +
> Vantage driver.
>
> Best wishes,
> Jaap
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/a160e60b-57fd-444f-bfb2-7bb9fb139366%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEDoGaXUEkmD%2B-Raj4xUMrgezudC1oaNGhYS0ABNgAgXgg%40mail.gmail.com.

Re: [weewx-development] V4.0.0b4 is up

[Thomas Keffer]

That's quite the PR! Thank you.

It will take me a day or two to review it. Get back to you soon.

-tk

On Thu, Dec 19, 2019 at 7:45 PM John Kline  wrote:

> I got the CC3000 driver running on Debian Buster in Python 2.7.16 and
> Python 3.7.3.
>
> It did require changes to run on Python 3.  I’ve sent a pull request that
> also includes a great deal of robustness enhancements to the CC3000 driver
> that I have been running (on two CC3000s) for many months.  I’m hoping you
> can take all of this.
>
> On Dec 18, 2019, at 5:07 PM, Thomas Keffer  wrote:
>
> 
> That's good news!
>
> On Wed, Dec 18, 2019 at 6:00 PM Xant  wrote:
>
>>
>> Update report:
>>
>>- WeeWX: 4.0.0b5
>>- computer: RPi4
>>- OS: Raspbian GNU/Linux 10 (buster)
>>- PWS; WeatherFlow
>>- driver: weatherflow-udp (by Capitan-Coredump)
>>- skin: Seasons
>>- Python: 3.7.3
>>
>> Just restarted in Python 3 mode... no issues so far.
>>
>> X
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "weewx-development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to weewx-development+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-development/1d4979f8-b8f0-4bb4-aefa-e6f39ccdcff4%40googlegroups.com
>> <https://groups.google.com/d/msgid/weewx-development/1d4979f8-b8f0-4bb4-aefa-e6f39ccdcff4%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/CAPq0zEARQj99VhwMKQLydoUoBOQyDa0XswZuq_ytJF3ECQnu0A%40mail.gmail.com
> <https://groups.google.com/d/msgid/weewx-development/CAPq0zEARQj99VhwMKQLydoUoBOQyDa0XswZuq_ytJF3ECQnu0A%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/1CED7051-5F17-4874-93C6-9B1AD4BC62A0%40johnkline.com
> <https://groups.google.com/d/msgid/weewx-development/1CED7051-5F17-4874-93C6-9B1AD4BC62A0%40johnkline.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEAt83_Np0JbX2zDqY9e5m%2BvpohbSFVHbyA8YcWdNH6%2BOQ%40mail.gmail.com.

Re: [weewx-development] V4.0.0b4 is up

[Thomas Keffer]

That's good news!

On Wed, Dec 18, 2019 at 6:00 PM Xant  wrote:

>
> Update report:
>
>- WeeWX: 4.0.0b5
>- computer: RPi4
>- OS: Raspbian GNU/Linux 10 (buster)
>- PWS; WeatherFlow
>- driver: weatherflow-udp (by Capitan-Coredump)
>- skin: Seasons
>- Python: 3.7.3
>
> Just restarted in Python 3 mode... no issues so far.
>
> X
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/1d4979f8-b8f0-4bb4-aefa-e6f39ccdcff4%40googlegroups.com
> 
> .
>

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

Re: [weewx-development] V4.0.0b4 is up

[Thomas Keffer]

Yes, I have run WeeWX on Catalina and have not had any problems. The
how-to-install instructions in the file macos.htm that comes in the tarball
are current.

-tk

On Wed, Dec 18, 2019 at 12:04 PM Chris Alemany  wrote:

> Has anyone tried V4 on macOS yet? I am running weewx on Catalina (macOS
> 10.15) now so was thinking of trying to work on a procedure for installing
> python 3 and weewx4 over the next couple weeks.
>
> On Dec 18, 2019, at 10:43 AM, Xant  wrote:
>
> (update)
>
> Please, disregard my previous posting as Year now showing.
>
>
> After much do and starting over, WeeWX 4.0.0b5 now working with no issues
> on RPi4 2.7 python. Will leave for a while, and later try python 3.
>
> X
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/7b536f81-9e1c-48e9-a1c7-b9ccc434d753%40googlegroups.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/3271DCF2-1E6C-4469-888A-6FF0C99D0A1F%40gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEDXbYjFmizLFnM_i6bq%3DE4k51q9dRaC5E1n8ouph6wQcA%40mail.gmail.com.

Re: [weewx-development] Re: V4.0.0b4 is up

[Thomas Keffer]

Ralph,

Try this version of cmon.py. I did a quick port to Python 3. It should work
with Python 2 or 3, and under either WeeWX V3.9, or 4.0.

-tk

On Mon, Dec 16, 2019 at 6:53 PM Ralph Underwood  wrote:

> I found most of those items, but I was still getting a bunch of errors. My
> system running 3.?? died a few days ago and my backups were not good so I
> was installing the version 4 as a replacement - consequently I had less
> that 24 hours data on the system I mistakenly installed cmon on.
>
> I am interested in cmon because I want to track down why my "old" system
> was periodically crashing - I was suspecting a memory leak. The memory in
> use would just creep up, seemed to crash
>
> I just made a clean installation using a newly imaged card and Vince's
> script. Copied over the latest ultimeter driver and I am up and running.
>
> I still have to get my MQTT stuff working again - I stumbled upon how to
> get the python 3 version of paho.mqtt installed yesterday, but didn't make
> good notes.
>
> Thanks again to Tom, Vince and Gary!
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/c5f6e1cb-4934-4ae3-b62c-aab93668bd07%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zECp_PGoOtZwn_Zi320%3DDFa14b4bYxXvNOrkzOU_kgfc_g%40mail.gmail.com.
# $Id: cmon.py 1651 2017-01-16 18:10:37Z mwall $
# Copyright 2013 Matthew Wall
"""weewx module that records cpu, memory, disk, and network usage.

This file contains both a weewx driver and a weewx service.

Installation

Put this file in the bin/user directory.


Service Configuration

Add the following to weewx.conf:

[ComputerMonitor]
data_binding = cmon_binding
max_age = 2592000 # 30 days; None to store indefinitely

[DataBindings]
[[cmon_binding]]
database = cmon_sqlite
manager = weewx.manager.DaySummaryManager
table_name = archive
schema = user.cmon.schema

[Databases]
[[cmon_sqlite]]
root = %(WEEWX_ROOT)s
database_name = archive/cmon.sdb
driver = weedb.sqlite

[Engine]
[[Services]]
archive_services = ..., user.cmon.ComputerMonitor


Driver Configuration

Add the following to weewx.conf:

[Station]
station_type = ComputerMonitor

[ComputerMonitor]
polling_interval = 30
driver = user.cmon


Schema

The default schema is defined in this file.  If you prefer to maintain a schema
different than the default, specify the desired schema in the configuration.
For example, this would be a schema that stores only memory and network data,
and uses eth1 instead of the default eth0:

[DataBindings]
[[cmon_binding]]
database = cmon_sqlite
manager = weewx.manager.DaySummaryManager
table_name = archive
[[[schema]]]
dateTime = INTEGER NOT NULL PRIMARY KEY
usUnits = INTEGER NOT NULL
interval = INTEGER NOT NULL
mem_total = INTEGER
mem_free = INTEGER
mem_used = INTEGER
swap_total = INTEGER
swap_free = INTEGER
swap_used = INTEGER
net_eth1_rbytes = INTEGER
net_eth1_rpackets = INTEGER
net_eth1_rerrs = INTEGER
net_eth1_rdrop = INTEGER
net_eth1_tbytes = INTEGER
net_eth1_tpackets = INTEGER
net_eth1_terrs = INTEGER
net_eth1_tdrop = INTEGER

Another approach to maintaining a custom schema is to define the schema in the
file user/extensions.py as cmonSchema:

cmonSchema = [
('dateTime', 'INTEGER NOT NULL PRIMARY KEY'),
('usUnits', 'INTEGER NOT NULL'),
('interval', 'INTEGER NOT NULL'),
('mem_total','INTEGER'),
('mem_free','INTEGER'),
('mem_used','INTEGER'),
('net_eth1_rbytes','INTEGER'),
('net_eth1_rpackets','INTEGER'),
('net_eth1_rerrs','INTEGER'),
('net_eth1_rdrop','INTEGER'),
('net_eth1_tbytes','INTEGER'),
('net_eth1_tpackets','INTEGER'),
('net_eth1_terrs','INTEGER'),
('net_eth1_tdrop','INTEGER'),
]

then load it using this configuration:

[DataBindings]
[[cmon_binding]]
database = cmon_sqlite
manager = weewx.manager.DaySummaryManager
table_name = archive
schema = user.extensions.cmonSchema
"""

# FIXME: make these methods 

Re: [weewx-development] Re: V4.0.0b4 is up

[Thomas Keffer]

cmon has not been ported to Python 3.

On Mon, Dec 16, 2019 at 2:17 PM Ralph Underwood  wrote:

> I tried to install the cmon extension with the version 4 and got this
> error.
>
> I had just restarted my tail of the log so I hope this is enough.
>
> Dec 16 13:02:16 JV-Wx weewx[27906] CRITICAL weewx.engine: 
>  obj = weeutil.weeutil.get_object(svc)(self,config_dict)
> Dec 16 13:02:16 JV-Wx weewx[27906] CRITICAL weewx.engine: File
> "/home/weewx/bin/weeutil/weeutil.py", line 1093, in get_object
> Dec 16 13:02:16 JV-Wx weewx[27906] CRITICAL weewx.engine: 
>  mod = __import__(module)
> Dec 16 13:02:16 JV-Wx weewx[27906] CRITICAL weewx.engine: File
> "/home/weewx/bin/user/cmon.py", line 331
> Dec 16 13:02:16 JV-Wx weewx[27906] CRITICAL weewx.engine: 
>  except (ValueError, IOError, KeyError), e:
> Dec 16 13:02:16 JV-Wx weewx[27906] CRITICAL weewx.engine: 
>^
> Dec 16 13:02:16 JV-Wx weewx[27906] CRITICAL weewx.engine: 
>  SyntaxError: invalid syntax
> Dec 16 13:02:16 JV-Wx weewx[27906] CRITICAL weewx.engine: 
>  Exiting.
> Dec 16 13:02:16 JV-Wx systemd[1]: weewx.service: Main process exited,
> code=exited, status=1/FAILURE
> Dec 16 13:02:16 JV-Wx systemd[1]: weewx.service: Failed with result
> 'exit-code'.
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/67b362a4-7cc3-417f-8c98-6894e5149706%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zED7dTDHE_C2hmkDcHooz5EV%3Dpny0J6Br8mryYHpVwkN%2BA%40mail.gmail.com.

Re: [weewx-development] couple crashes running beta4

[Thomas Keffer]

Fixed in commit 28f14e9c
<https://github.com/weewx/weewx/commit/28f14e9c64eeb7d1d355540a5e8d90e9a0dcd877>
.

-tk

On Sun, Dec 15, 2019 at 12:46 PM Vince Skahan  wrote:

> On Sun, Dec 15, 2019 at 11:32 AM Thomas Keffer  wrote:
>
>> 1. Looks like you forgot to "import syslog" in your file dbexample.py
>> (which is not part of WeeWX).
>>
>>
> Indeed - I tried to cook up a minimalist extension to create a secondary
> db and missed including that it appears.  Thanks !!!
>
>
>
>> 2. The rain exception looks like it could be triggered if a rain event
>> happens in the very first record inserted into a database. I'll add a check
>> for that.
>>
>>
> That one surprises me a bit, as the db has existed for months and it's
> rained lots of times.   Maybe the WeatherFlow driver can put out unexpected
> output under some circumstances (???).  I'll poke around a little there.
>
> Thanks for the help.
>
> --
> -  vinceska...@gmail.com 
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEAC2Ct5k%2BF1f4FgCGXX7-_KD_oeT5p5mEkSxoD23nfUFQ%40mail.gmail.com.

Re: [weewx-development] couple crashes running beta4

[Thomas Keffer]

1. Looks like you forgot to "import syslog" in your file dbexample.py
(which is not part of WeeWX).

2. The rain exception looks like it could be triggered if a rain event
happens in the very first record inserted into a database. I'll add a check
for that.

Thanks, Vince!

-tk




On Sun, Dec 15, 2019 at 10:16 AM Vince Skahan  wrote:

> Two crashesboth b4 on a pi4 under python3
>
>
>- First was me messing with the network.  I replaced my network switch
>and the pi4 (wireless) lost connection to the WeatherFlow Hub (also
>wireless).   The error seems to look like I'm missing the python syslog
>module perhaps () although it 'is' there.  I can run python3 and do an
>'import syslog' interactively.
>
>
>- Second was overnight, some kind of units thing () as rain
>started.
>
>
> Just as a comparison, my 'wired' pi3b+ running 3.9.1 looks like it 'did'
> restart automagically but the processes stayed healthy throughout.  The
> network was down 17 minutes while I was fiddling with wires.  I grabbed the
> pertinent time periods from the wired pi just as a comparison of what 3.9.1
> did
>
> FWIW - I updated to beta 5 this morning on the pi4 just in case to see if
> the rain crash thing reoccurs.
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/a34d5712-c1c2-40f2-8f2f-b334ff1a505f%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEC-3AbqfV4XVvOJoiTqkkA_GL1kPS7xW4vKPnW89QYegw%40mail.gmail.com.

Re: [weewx-development] 'weewx.sdb': UNIQUE constraint failed: archive.dateTime

[Thomas Keffer]

> i put the change in engine.py instead of wmr300.py - that way it will fix
> this problem for every driver, not just wmr300.  changed at
> weewx-development commit e9962fe8
>

For stations with an internal clock, it's possible the time will drift a
few seconds, maybe even archive_delay seconds ahead. We don't want to
reject records just because of that.

-tk

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEAHippuXx6GUg2R7sTFn_dA%2B9svMiPRs_LKr4HE9DApwg%40mail.gmail.com.

Re: [weewx-development] 'weewx.sdb': UNIQUE constraint failed: archive.dateTime

[Thomas Keffer]

The log sure would be useful...

On Sat, Dec 14, 2019 at 11:19 AM Leon Shaner  wrote:

> Hey WeeWX'ers...
>
> I've been getting a series of the following error for about an hour each
> time I restart WeeWx since syncing to the latest development branch several
> weeks ago:
>
> Dec 14 13:12:14 nixie weewx[14125] ERROR weewx.manager: Unable to add
> record 2019-12-14 13:12:00 EST (1576347120) to database 'weewx.sdb': UNIQUE
> constraint failed: archive.dateTime
>
> The error messages occur only right after starting WeeWx and continues on
> every archive interval for an hour after the weewx restart, then the error
> is no longer shown.
>
> Sure seems like a timezone ± 1 hour offset issue of some kind, but I can't
> pinpoint it.
> Coincidentally we crossed into Eastern Standard time a few days before I
> made the upgrade.
>
> Anyone else seeing a similar error?
>
> Last night I sync'd to the latest development branch again and the error
> persists.
> I had been running under the system default Python 2.7, so this morning I
> switched weewx to use Python 3.5, and the error still persists.
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad)
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/39928361-6AFF-44EA-BC1A-3B9666C42669%40isylum.org
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEA%2BVHZbVn43zbkz9KyKVvfqR3k0T%3DhyZTsDjWvXOHagBw%40mail.gmail.com.

Re: [weewx-development] Re: V4.0.0b4 is up

[Thomas Keffer]

Silly me. I forgot to save the characters to the buffer! Try the attached.

Those damn 'b's are because you are printing bytes or bytearrays, not
strings. If you want to get rid of them, you need to convert to a string
(which is unicode under Python3). This illustrates:

>>> print(b'abc)
b'abc'
>>> # This fails, because str(b'abc') returns the "informal"
representation, which includes the b's:
>>> print(str(b'abc'))
b'abc
>>> print(b'abc'.decode())
abc


-tk

On Sat, Dec 14, 2019 at 11:18 AM Ralph Underwood  wrote:

> This is the result with latest ultimeter.py and debug_serial = 1
>
>
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.engine: retrying...
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.engine: Using configuration
> file /home/weewx/weewx.conf
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Debug is 1
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Initializing engine
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.engine: Loading station type
> Ultimeter (weewx.drivers.ultimeter)
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.drivers.ultimeter: Driver
> version is 0.40
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.drivers.ultimeter: Using
> serial port /dev/ttyUSB0
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.drivers.ultimeter: Open
> serial port /dev/ttyUSB0
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Loading service
> weewx.engine.StdTimeSynch
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Finished loading
> service weewx.engine.StdTimeSynch
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Loading service
> weewx.engine.StdConvert
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.engine: StdConvert target
> unit is 0x1
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Finished loading
> service weewx.engine.StdConvert
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Loading service
> weewx.engine.StdCalibrate
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Finished loading
> service weewx.engine.StdCalibrate
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Loading service
> weewx.engine.StdQC
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Finished loading
> service weewx.engine.StdQC
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Loading service
> weewx.wxservices.StdWXCalculate
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.manager: Daily summary
> version is 2.0
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.wxservices: The following
> values will be calculated: altimeter=prefer_hardware,
> appTemp=prefer_hardware, barometer=prefer_hardware,
> beaufort=prefer_hardware, cloudbase=prefer_hardware,
> dewpoint=prefer_hardware, ET=prefer_hardware, heatindex=prefer_hardware,
> humidex=prefer_hardware, inDewpoint=prefer_hardware,
> maxSolarRad=prefer_hardware, pressure=prefer_hardware,
> rainRate=prefer_hardware, windchill=prefer_hardware, windrun=prefer_hardware
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.wxservices: The following
> algorithms will be used for calculations: altimeter=aaASOS, maxSolarRad=RS
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Finished loading
> service weewx.wxservices.StdWXCalculate
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Loading service
> weewx.engine.StdArchive
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.engine: Archive will use
> data binding wx_binding
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.engine: Record generation
> will be attempted in 'hardware'
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.engine: Using archive
> interval of 300 seconds (specified in weewx configuration)
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Use LOOP data in
> hi/low calculations: 1
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Finished loading
> service weewx.engine.StdArchive
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Loading service
> weewx.restx.StdStationRegistry
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.restx: StationRegistry:
> Registration not requested.
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Finished loading
> service weewx.restx.StdStationRegistry
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Loading service
> weewx.restx.StdWunderground
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.restx: Wunderground: Posting
> not enabled.
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Finished loading
> service weewx.restx.StdWunderground
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Loading service
> weewx.restx.StdPWSweather
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.restx: PWSweather: Posting
> not enabled.
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Finished loading
> service weewx.restx.StdPWSweather
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG weewx.engine: Loading service
> weewx.restx.StdCWOP
> Dec 14 10:06:36 JV-Wx weewx[12591] INFO weewx.restx: CWOP: Posting not
> enabled.
> Dec 14 10:06:36 JV-Wx weewx[12591] DEBUG 

Re: [weewx-development] Re: V4.0.0b4 is up

[Thomas Keffer]

I think this problem may be related to this thread
,
which was never resolved. Hopefully, we'll get it this time.

Try this version, but before you do, not only set debug=1 at the top of
weewx.conf, but also set debug_serial in the [Ultimeter] section:

debug = 1
...

[Ultimeter]
  port = XXX
  debug_serial = 1


-tk




On Fri, Dec 13, 2019 at 7:31 PM Ralph Underwood  wrote:

> This is the result with the new driver. I let it go several times with
> same result.
>
>
>
> Dec 13 18:23:16 JV-Wx weewx[3658] INFO weewx.engine: retrying...
> Dec 13 18:23:16 JV-Wx weewx[3658] INFO weewx.engine: Using configuration
> file /home/weewx/weewx.conf
> Dec 13 18:23:16 JV-Wx weewx[3658] DEBUG weewx.engine: Debug is 1
> Dec 13 18:23:16 JV-Wx weewx[3658] DEBUG weewx.engine: Initializing engine
> Dec 13 18:23:16 JV-Wx weewx[3658] INFO weewx.engine: Loading station type
> Ultimeter (weewx.drivers.ultimeter)
> Dec 13 18:23:16 JV-Wx weewx[3658] INFO weewx.drivers.ultimeter: driver
> version is 0.30
> Dec 13 18:23:16 JV-Wx weewx[3658] INFO weewx.drivers.ultimeter: using
> serial port /dev/ttyUSB0
> Dec 13 18:23:16 JV-Wx weewx[3658] DEBUG weewx.drivers.ultimeter: open
> serial port /dev/ttyUSB0
> Dec 13 18:23:16 JV-Wx weewx[3658] DEBUG weewx.engine: Loading service
> weewx.engine.StdTimeSynch
> Dec 13 18:23:16 JV-Wx weewx[3658] DEBUG weewx.engine: Finished loading
> service weewx.engine.StdTimeSynch
> Dec 13 18:23:16 JV-Wx weewx[3658] DEBUG weewx.engine: Loading service
> weewx.engine.StdConvert
> Dec 13 18:23:16 JV-Wx weewx[3658] INFO weewx.engine: StdConvert target
> unit is 0x1
> Dec 13 18:23:16 JV-Wx weewx[3658] DEBUG weewx.engine: Finished loading
> service weewx.engine.StdConvert
> Dec 13 18:23:16 JV-Wx weewx[3658] DEBUG weewx.engine: Loading service
> weewx.engine.StdCalibrate
> Dec 13 18:23:16 JV-Wx weewx[3658] DEBUG weewx.engine: Finished loading
> service weewx.engine.StdCalibrate
> Dec 13 18:23:16 JV-Wx weewx[3658] DEBUG weewx.engine: Loading service
> weewx.engine.StdQC
> Dec 13 18:23:16 JV-Wx weewx[3658] DEBUG weewx.engine: Finished loading
> service weewx.engine.StdQC
> Dec 13 18:23:16 JV-Wx weewx[3658] DEBUG weewx.engine: Loading service
> weewx.wxservices.StdWXCalculate
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.manager: Daily summary
> version is 2.0
> Dec 13 18:23:17 JV-Wx weewx[3658] INFO weewx.wxservices: The following
> values will be calculated: altimeter=prefer_hardware,
> appTemp=prefer_hardware, barometer=prefer_hardware,
> beaufort=prefer_hardware, cloudbase=prefer_hardware,
> dewpoint=prefer_hardware, ET=prefer_hardware, heatindex=prefer_hardware,
> humidex=prefer_hardware, inDewpoint=prefer_hardware,
> maxSolarRad=prefer_hardware, pressure=prefer_hardware,
> rainRate=prefer_hardware, windchill=prefer_hardware, windrun=prefer_hardware
> Dec 13 18:23:17 JV-Wx weewx[3658] INFO weewx.wxservices: The following
> algorithms will be used for calculations: altimeter=aaASOS, maxSolarRad=RS
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.engine: Finished loading
> service weewx.wxservices.StdWXCalculate
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.engine: Loading service
> weewx.engine.StdArchive
> Dec 13 18:23:17 JV-Wx weewx[3658] INFO weewx.engine: Archive will use data
> binding wx_binding
> Dec 13 18:23:17 JV-Wx weewx[3658] INFO weewx.engine: Record generation
> will be attempted in 'hardware'
> Dec 13 18:23:17 JV-Wx weewx[3658] INFO weewx.engine: Using archive
> interval of 300 seconds (specified in weewx configuration)
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.engine: Use LOOP data in
> hi/low calculations: 1
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.engine: Finished loading
> service weewx.engine.StdArchive
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.engine: Loading service
> weewx.restx.StdStationRegistry
> Dec 13 18:23:17 JV-Wx weewx[3658] INFO weewx.restx: StationRegistry:
> Registration not requested.
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.engine: Finished loading
> service weewx.restx.StdStationRegistry
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.engine: Loading service
> weewx.restx.StdWunderground
> Dec 13 18:23:17 JV-Wx weewx[3658] INFO weewx.restx: Wunderground: Posting
> not enabled.
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.engine: Finished loading
> service weewx.restx.StdWunderground
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.engine: Loading service
> weewx.restx.StdPWSweather
> Dec 13 18:23:17 JV-Wx weewx[3658] INFO weewx.restx: PWSweather: Posting
> not enabled.
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.engine: Finished loading
> service weewx.restx.StdPWSweather
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.engine: Loading service
> weewx.restx.StdCWOP
> Dec 13 18:23:17 JV-Wx weewx[3658] INFO weewx.restx: CWOP: Posting not
> enabled.
> Dec 13 18:23:17 JV-Wx weewx[3658] DEBUG weewx.engine: Finished loading
> service weewx.restx.StdCWOP
> Dec 13 18:23:17 JV-Wx 

Re: [weewx-development] Re: V4.0.0b4 is up

[Thomas Keffer]

weewx.service is the systemd configuration file. You'll find it under
util/systemd. It's used when starting weewx as a daemon.

One other thing: the weewx.conf file you enclosed is a V3.9.2 file. Are you
sure you're running v4.0.0?

-tk

On Thu, Dec 12, 2019 at 1:44 PM Xant  wrote:

>
> Starting from scratch (again). PWS is WeatherFlow.
>
> 1) RPi3 WeeWX release w Bskin - all is well and running
>
> 2) RPi4 WeeWX - python 2x for now; got the following error msg:
>
> root@RPi4:/etc/weewx# service weewx start
> Failed to start weewx.service: Unit weewx.service not found.
>
> Only place I see reference for "weewx.service" is under 'vantage.rules'
> (I'm not using Vantage).
>
> weewx.conf in attach.
>
>
> Vince
> It seems you using WFlow and running. Any to patch?
>
> X
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/77a4f51a-7953-4186-8b52-2fd2ab40d39e%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zEDshKvqwJ_R7HX-KwdD6u%2BhXc6ZLZkCfWtVoA1pc9VNNw%40mail.gmail.com.

Re: [weewx-development] Re: V4.0.0b4 is up

[Thomas Keffer]

I don't think so. It's definitely a problem. Fixed in commit 55f9cb3

.

Uploaded V4.0.0b5 .

-tk

On Fri, Dec 6, 2019 at 7:17 AM Armando Esteves 
wrote:

> Tom
>
> Hold-on on this issue, as it might not be WeeWX/DB related, but Rpi
> version/OS conflict (
> https://groups.google.com/d/msg/weewx-development/ZXChMjAGUjM/RGlnAUzYBAAJ
> ).
>
> Will inform back upon new developments and when ready for further b-Tests.
>
> X
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/a28e5b86-5376-4f02-a87a-2f53e325f5cd%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zECjj-PZpeJ3uJ0EU%3DgHk_VEUnEJQD_PciGU-7Dm6cjCAQ%40mail.gmail.com.

Re: [weewx-development] Re: V4.0.0b4 is up

[Thomas Keffer]

You're doing things right! It's just that how a schema is specified has
changed in V4.0. However, the intention was to make it backwards
compatible, which I obviously failed at.

Let me think about this case and I'll get back to you.

-tk

On Thu, Dec 5, 2019 at 6:01 PM Armando Esteves 
wrote:

> Xant here, trying to jump into the "Big Boys league" (aka, development) :P
>
> Since jumping to next up, went to duplicate and upgrade everything:
>
>- Rpi3 to Rpi4 - check!
>- Bskin 1.1b7 to Bskin 1.1b8 - check!
>- WeeWX 3.9.2 to WeeWX 4.0.0b4 -error (ufff...)
>
> NOT reportingas a bug, but probably some "silly" hands-on upgrade mistake.
> It seems related to DB, more than other. Some errors as the following:
>
> 1) Tried service start
>
> root@raspberrypi:/usr/share/weewx# service weewx start
> Job for weewx.service failed because the control process exited with error
> code.
> See "systemctl status weewx.service" and "journalctl -xe" for details.
>
> 2) Systemctl
>
> root@raspberrypi:/usr/share/weewx# systemctl status weewx.service
> ● weewx.service - LSB: weewx weather system
>Loaded: loaded (/etc/init.d/weewx; generated)
>Active: failed (Result: exit-code) since Thu 2019-12-05 17:58:21 EST;
> 28s ago
>  Docs: man:systemd-sysv-generator(8)
>   Process: 10858 ExecStart=/etc/init.d/weewx start (code=exited,
> status=1/FAILURE)
>
> Dec 05 17:58:21 raspberrypi weewx[10858]: Starting weewx weather system:
> weewxTraceback (most recent call last):
> Dec 05 17:58:21 raspberrypi weewx[10858]:   File "/usr/bin/weewxd", line
> 14, in 
> Dec 05 17:58:21 raspberrypi weewx[10858]: import user.extensions  #
> @UnusedImport
> Dec 05 17:58:21 raspberrypi weewx[10858]:   File
> "/usr/share/weewx/user/extensions.py", line 22, in 
> Dec 05 17:58:21 raspberrypi weewx[10858]: schema_extended =
> schemas.wview.schema + [('maxSolarRad', 'REAL'), ('illuminance', 'REAL'),
> ('lightcount', 'REA
> Dec 05 17:58:21 raspberrypi weewx[10858]: TypeError: unsupported operand
> type(s) for +: 'dict' and 'list'
> Dec 05 17:58:21 raspberrypi weewx[10858]:  failed!
> Dec 05 17:58:21 raspberrypi systemd[1]: weewx.service: Control process
> exited, code=exited, status=1/FAILURE
> Dec 05 17:58:21 raspberrypi systemd[1]: weewx.service: Failed with result
> 'exit-code'.
> Dec 05 17:58:21 raspberrypi systemd[1]: Failed to start LSB: weewx weather
> system.
>
> 3) DB Reconfigure? (aka, "desperation mode")
>
> root@raspberrypi:/usr/share/weewx# wee_database /etc/weewx/weewx.conf
> --reconfigure
> Traceback (most recent call last):
>   File "/usr/bin/wee_database", line 23, in 
> import user.extensions  # @UnusedImport
>   File "/usr/share/weewx/user/extensions.py", line 22, in 
> schema_extended = schemas.wview.schema + [('maxSolarRad', 'REAL'),
> ('illuminance', 'REAL'), ('lightcount', 'REAL'), ('lightdist', 'REAL'),
> ('lightavgdist', 'REAL'), ('lightenergy', 'REAL')]
> TypeError: unsupported operand type(s) for +: 'dict' and 'list'
>
> Best,
> Xant
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-development+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/2182e000-062d-4fe8-b045-d3b27b62ae46%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-development+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-development/CAPq0zED5sY%3DBhKtNe287ApqCCjOgdd5kd_cUd48atnVjBy%3DNjQ%40mail.gmail.com.