Re: [weewx-user] Re: Chill Hours Extension

[Seth Ratner]

[[[daychill]]]
plot_type = bar
chillHours
aggregate_type = cumulative
aggregate_interval = hour


That's what I have in the Seasons skin.conf. The way WeeWX is passing that 
to my xType is calling get_aggregate for one hour blocks. I'm not sure if 
there was a simpler way to do it, but I was able to get it to work using 
genBatchRecords and iterating through it as a generator.

For the utah method, each record outTemp has to be compared to a scale that 
gives differing chill hour multipliers. That may be why the complexity is 
needed? I dunno.

I went through and changed everything to chillTime. One thing I don't know 
if how to set the default for chillTime to hours. Like you said, the image 
generator is doing everything in seconds. I think I know how I can rig it, 
but I'm guessing there's a right way to do it.

Here's the code as it stands, if anyone could take a look through it I'd be 
grateful. In particular, anything commented with ###*** needs attention

https://github.com/lordratner/weewx_chillHours/blob/main/chillTime.py


On Friday, January 21, 2022 at 7:56:40 PM UTC-6 tke...@gmail.com wrote:

> On Fri, Jan 21, 2022 at 4:27 PM Seth Ratner  wrote:
>
>> Also, the "one hour apart" thing was because a chart was pulling chill 
>> hour accumulation for a day on an hourly interval. The Utah method can 
>> actually subtract chill hours, so hourly changes wont necessarily be in 
>> hour increments. 
>
>
> I see. Why don't you start by just providing "get_aggregate()". The 
> plotting engine should be smart enough to figure out how to chop a plot for 
> a day into a cumulative plot on one hour increments.
>
> -tk
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/0909723f-28b9-446a-916f-0f646b66fc6cn%40googlegroups.com.

Re: [weewx-user] Re: Storing Text as a record, wee_import and mysql UPDATE

[Glenn McKechnie]

Thanks Gary,

I'll give it a test drive as soon as I get a moment or three.

On a related note (ie:- related to using TEXT fields in the database)
I went and checked out wee_database and found that it baulked at the
TEXT field in the database.

Details are in the attached file, which should keep the formatting sane.

Let me know if you want it raised as a seperate issue and I'll do that instead.

On 22/01/2022, gjr80  wrote:
> Glenn,
>
> I have created a new branch wee_import_text off development for this and
> have modified the wee_import code to import text to a WeeWX TEXT field.
> There are a dew conditions:
>
> 1. text import only works with CSV imports
>
> 2. import source fields that are to be imported as text must use 'text' as
> the WeeWX units specifier in the field map in the import config file, eg:
> [[FieldMap]]
> 
> aComment = import_text_field, text
>
> 3. the destination text field has been added to the WeeWX database and
> WeeWX configured as per the Storing text in the database
>  wiki
> page
>
> I have only done basic testing of the code so there may be some corner
> cases I have not covered, but you should be right to give it a go if you
> want. As I said I have taken a branch off development, since there has been
>
> quite a few changes in development since the last release the most reliable
>
> option is for you to clone and install wee_import_text. However, the
> wee_import code does not change often so you could probably get away with
> running v4.5.1 and just downloading and installing the modified
> weeimport.py
> .
>
> To use the new wee_import:
>
> 1. Either clone and install from the wee_import_text branch or if using
> v4.5.1 (or any other recent version at your own peril) replace
> BIN/weeimport/weeimport.py with weeimport.py from the wee_import_text
> branch. You can download weeimport.py from the wee_import_text branch
> directly using wget as follows:
>
> $ wget
> https://raw.githubusercontent.com/weewx/weewx/wee_import_text/bin/weeimport/weeimport.py
>
> 2. edit your import config file and add your text field import to the field
>
> map as outlined above
>
> 3. stop WeeWX and run your import using --dry-run and then without
> --dry-run
>
> Let me know if you have any issues.
>
> Gary
>


-- 


Cheers
 Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

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

weewx.4.5.1

 If a database with a field type of TEXT is checked using `wee_database 
--check-strings` it fails with the following stack trace.

:graybeard@whitebeard:/home/weewx/bin
06:50 PM $ ./wee_database --check-strings
Using configuration file /home/weewx451/weewx.conf
Using database binding 'wx_binding', which is bound to database 'archive_sqlite'
Preparing Null String Fix, this may take a while...
Traceback (most recent call last):
  File "./wee_database", line 1138, in 
main()
  File "./wee_database", line 227, in main
check_strings(config_dict, db_binding, options, fix=False)
  File "./wee_database", line 934, in check_strings
if record[icol] is not None and not check_type(record[icol], 
obs_type_list[icol]):
  File "./wee_database", line 879, in check_type
raise ValueError("Unknown type %s" % expected)
ValueError: Unknown type TEXT


== FIXED (for me) with the following changes to wee_database


xterm root@whitebeard:/home
04:44 PM $ diff -au weewx451/bin/wee_database weewx451/bin/wee_database-text 
--- weewx451/bin/wee_database   2021-04-03 06:02:14.0 +1100
+++ weewx451/bin/wee_database-text  2022-01-22 16:25:26.293912710 +1100
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/python3
 #
 #Copyright (c) 2009-2021 Tom Keffer 
 #
@@ -875,6 +875,8 @@
 return isinstance(val, float)
 elif expected == 'STR':
 return isinstance(val, six.string_types)
+elif expected == 'TEXT':
+return isinstance(val, six.string_types)
 else:
 raise ValueError("Unknown type %s" % expected)
 
@@ -886,6 +888,8 @@
 return float(val)
 elif target == 'STR':
 return six.ensure_str(val)
+elif target == 'TEXT':
+return six.ensure_str(val)
 else:
 raise ValueError("Unknown type %s" % target)


 Null strings in test record (which also has a TEXT field) are then 
detected as expected.

:graybeard@whitebeard:/home/weewx/bin
07:34 PM $ sudo ./wee_database --fix-strings
Using configuration file /home/weewx451/weewx.conf
Using database binding 'wx_binding', which is bound to 

Re: [weewx-user] Re: Storing Text as a record, wee_import and mysql UPDATE

[gjr80]

Glenn,

I have created a new branch wee_import_text off development for this and 
have modified the wee_import code to import text to a WeeWX TEXT field. 
There are a dew conditions:

1. text import only works with CSV imports

2. import source fields that are to be imported as text must use 'text' as 
the WeeWX units specifier in the field map in the import config file, eg:
[[FieldMap]]

aComment = import_text_field, text

3. the destination text field has been added to the WeeWX database and 
WeeWX configured as per the Storing text in the database 
 wiki page

I have only done basic testing of the code so there may be some corner 
cases I have not covered, but you should be right to give it a go if you 
want. As I said I have taken a branch off development, since there has been 
quite a few changes in development since the last release the most reliable 
option is for you to clone and install wee_import_text. However, the 
wee_import code does not change often so you could probably get away with 
running v4.5.1 and just downloading and installing the modified weeimport.py
.

To use the new wee_import:

1. Either clone and install from the wee_import_text branch or if using 
v4.5.1 (or any other recent version at your own peril) replace 
BIN/weeimport/weeimport.py with weeimport.py from the wee_import_text 
branch. You can download weeimport.py from the wee_import_text branch 
directly using wget as follows:

$ wget 
https://raw.githubusercontent.com/weewx/weewx/wee_import_text/bin/weeimport/weeimport.py

2. edit your import config file and add your text field import to the field 
map as outlined above

3. stop WeeWX and run your import using --dry-run and then without --dry-run

Let me know if you have any issues.

Gary

On Tuesday, 18 January 2022 at 10:17:56 UTC+10 Glenn McKechnie wrote:

> Thanks Gary, I appreciate it.
>
> Hopefully UPDATE won't raise any serious weewx issues.
> I look forward to seeing it raised as an issue :)
>
> On 18/01/2022, gjr80  wrote:
> > Correct, wee_import will not accept text only fields. When we put 
> together
> > wee_import we only included support for numeric fields; text fields were
> > omitted, perhaps not intentionally, but more likely because no real
> > consideration had been given to including them in the schema. That being
> > said, it should be a fairly simple process to modify wee_import to 
> support
> > text fields, at least for CSV imports anyway. Having had a quick 
> wee_import
> >
> > refresher this morning I am thinking we could support something like
> > ANComment
> > = ANComment, text in the field map. Let me look at this further and see
> > what I can come up with.
> >
> > As for supporting UPDATE, that will require further thought as I suspect
> > that will introduce a number of wider issues. I'll probably raise an 
> issue
> > for that one.
> >
> > Gary
> > On Monday, 17 January 2022 at 23:14:00 UTC+10 Glenn McKechnie wrote:
> >
> >> Working with TEXT records.
> >>
> >> I've gone through the wiki entry
> >> https://github.com/weewx/weewx/wiki/Storing-text-in-the-database
> >> and that all works well. I can add TEXT to the database and display it
> >> in the weewx skin. So far so good.
> >>
> >> Using a modified filepile.py, I can add what I want via the new_archive
> >> record hook. What I can't seem to do is add historical data that is in
> >> TEXT form, via weewx. Fair enough, it makes sense.
> >>
> >> I figured wee_import may be a solution so I crafted a csv file and used
> >> wee_import but it baulks on the text field. The csv files,
> >> /var/tmp/weewxaddnotes.csv has the contents...
> >>
> >> timestamp,extraTemp1,extraTemp2,ANComment
> >> 1641729300,23.0,22.0,"Test.\\nThen test again"
> >>
> >> It appears to be wanting a weewx_unit_name and I'm missing a clue stick.
> >> I can't find a name that it will accept without error. If the
> >> weewx_unit_name field is left blank (only the csv_field_name is given)
> >> it gives the following.
> >>
> >> Obtaining raw import data for period 1 ...
> >>  Unable to parse source-to-WeeWX field map.
> >>  No units specified for source field 'ANComment' in
> >> /home/weewx/csv.conf.
> >>  Nothing done, exiting.
> >>
> >> Which makes sense as I had the following...
> >>
> >> [[FieldMap]]
> >> dateTime = timestamp, unix_epoch
> >> interval =
> >> barometer =
> >> pressure =
> >> altimeter =
> >> inTemp =
> >> outTemp =
> >> extraTemp1 = extraTemp1, degree_C
> >> extraTemp2 = extraTemp2, degree_C
> >> ANComment = ANComment
> >>
> >> If I tell wee_imports to ignore the ANComment entry, as follows...
> >> ANComment =
> >> then everything else imports as expected so it's falling over on the
> >> ANComment field
> >>
> >> ignore_invalid_data in the csv.conf file is tantalizing close (a numeric
> >> field containing non-numeric data) but I don't want it skipped or
> >> halted. I want it accepted.
> >>
> >> Can I 

Re: [weewx-user] Re: Chill Hours Extension

[Tom Keffer]

On Fri, Jan 21, 2022 at 4:27 PM Seth Ratner  wrote:

> Also, the "one hour apart" thing was because a chart was pulling chill
> hour accumulation for a day on an hourly interval. The Utah method can
> actually subtract chill hours, so hourly changes wont necessarily be in
> hour increments.


I see. Why don't you start by just providing "get_aggregate()". The
plotting engine should be smart enough to figure out how to chop a plot for
a day into a cumulative plot on one hour increments.

-tk

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

Re: [weewx-user] Re: Chill Hours Extension

[Tom Keffer]

I don't think you'll need genSql(). If you were trying to calculate an
aggregate that required seeing every record and doing some complex
calculation in Python, then, yes.

But, your aggregate is simple enough that you can actually do the whole
thing in an SQL query, so getSql() should suffice.

Later, if you decide you want an optimized version of get_series(), then it
might be useful.

While I have you: consider another name besides "chillHours." That strongly
suggests that it will always be in hours, which is not necessarily true.
How about "chillTime"?

If you want to donate something, donate to my "real" project: Western Flyer
.

On Fri, Jan 21, 2022 at 4:24 PM Seth Ratner  wrote:

> Ok thanks. So I just learned what a python generator is. Cleared up a lot.
>
> Dude, I am seriously floored by how much you put into programming this.
> I'm back-tracking my way through the code for answers, and the detail is
> mind-blowing. Do you have a donations link?
>
> I'll reply once I have a functioning draft. Now that I understand how to
> use the genBatchRecords generator, I should have a working xType soon
>
> Then someone will have to explain the difference between scalar, series,
> and aggregate to me...
>
> Thanks!
>
> On Friday, January 21, 2022 at 6:07:28 PM UTC-6 tke...@gmail.com wrote:
>
>> Not sure why you would want to do this for times only one hour apart.
>>
>> Try something like this (NOT TESTED, and highly schematic):
>>
>> def get_aggregate(obs_type, timespan, aggregate_type, db_manager,
>> **option_dict):
>> if obs_type != 'chillHours':
>> raise weewx.UnknownType(obs_type)
>> if aggregate_type != 'sum':
>> return weewx.UnknownAggregation(aggregate_type)
>>
>> # Convert 45 to the same unit as the database:
>> baseline = weewx.units.convertStd(ValueTuple(45, 'degree_F',
>> 'group_temperature'),
>>   db_manager.std_unit_system)
>> result = db_manager.getSql("SELECT SUM(`interval`) * 60 WHERE
>> outTemp<=? AND dateTime BETWEEN ? AND ?",
>>   baseline.value, *timespan)
>>
>> # Check if result are None.
>> # Get the proper unit and group, return as a ValueTuple.
>>
>> Note that the type "interval" is escaped with backquotes. This is because
>> in MySQL, "interval" is a keyword unless you escape it.
>>
>> Assigning the results to either group_elapsed seems reasonable.
>>
>> Another option would be "group_deltatime", which is normally used for
>> things like system uptime. If you print it out, the results should come
>> back as "20 days, 7 hours, 15 minutes", which is what you want.
>>
>> -tk
>>
>> On Fri, Jan 21, 2022 at 2:56 PM Seth Ratner  wrote:
>>
>>> Closer and Closer, lol
>>>
>>> row = db_manager.getSql(sql_stmt)
>>>
>>> Using: SELECT outTemp FROM archive WHERE dateTime BETWEEN 1642744800 AND
>>> 1642748400
>>>
>>> Is returning a single outTemp. I am not sure how to return multiple rows
>>> then iterate through them to check for == chilhour and add them together. I
>>> know how to do it in PHP, but not WeeWX...
>>>
>>> I think once I get that, I'll be there. It would be simpler to put
>>> chillHours in the archive then I could just use sum(chillHours) in the sql
>>> query, but I'd rather not at this point, to make the xtype more flexible.
>>>
>>>
>>> On Friday, January 21, 2022 at 4:48:30 PM UTC-6 tke...@gmail.com wrote:
>>>
 Oooh. That's a perfect example! Thanks, John.

 On Fri, Jan 21, 2022 at 2:29 PM 'John Kline' via weewx-user <
 weewx...@googlegroups.com> wrote:

> Another example:
>
>
> https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L538
>
> On Jan 21, 2022, at 2:01 PM, Seth Ratner  wrote:
>
> It looks like there is an example in the  weewx-xaggs
>  repository. I'm about to
> dive in, but from a cursory look, unlike with the scalar, I'm going to 
> have
> to figure out how to use dbmanager to pull the outtemps from the database
> then iterate through each one, determine which ones are chill hours, and
> then add those together, correct?
>
> On Friday, January 21, 2022 at 3:49:33 PM UTC-6 tke...@gmail.com
> wrote:
>
>> Let me see if I can come up with something. Give me some time.
>>
>> On Fri, Jan 21, 2022 at 1:37 PM Seth Ratner 
>> wrote:
>>
>>> Oh boy...
>>>
>>> I cant find any examples for that. If one exists, it will greatly
>>> reduce the number of questions I have...
>>>
>>> On Friday, January 21, 2022 at 3:24:07 PM UTC-6 tke...@gmail.com
>>> wrote:
>>>
 You're getting close!

 You're going to have to implement get_aggregate(), as well as
 get_scalar().

 The xtypes framework has no way of taking the calculation 

Re: [weewx-user] Re: Chill Hours Extension

[Seth Ratner]

Also, the "one hour apart" thing was because a chart was pulling chill hour 
accumulation for a day on an hourly interval. The Utah method can actually 
subtract chill hours, so hourly changes wont necessarily be in hour 
increments. 

More to follow

On Friday, January 21, 2022 at 6:07:28 PM UTC-6 tke...@gmail.com wrote:

> Not sure why you would want to do this for times only one hour apart.
>
> Try something like this (NOT TESTED, and highly schematic):
>
> def get_aggregate(obs_type, timespan, aggregate_type, db_manager, 
> **option_dict):
> if obs_type != 'chillHours':
> raise weewx.UnknownType(obs_type)
> if aggregate_type != 'sum':
> return weewx.UnknownAggregation(aggregate_type)
>
> # Convert 45 to the same unit as the database:
> baseline = weewx.units.convertStd(ValueTuple(45, 'degree_F', 
> 'group_temperature'),
>   db_manager.std_unit_system)
> result = db_manager.getSql("SELECT SUM(`interval`) * 60 WHERE 
> outTemp<=? AND dateTime BETWEEN ? AND ?",
>   baseline.value, *timespan)
>
> # Check if result are None.
> # Get the proper unit and group, return as a ValueTuple.
> 
> Note that the type "interval" is escaped with backquotes. This is because 
> in MySQL, "interval" is a keyword unless you escape it.
>
> Assigning the results to either group_elapsed seems reasonable.
>
> Another option would be "group_deltatime", which is normally used for 
> things like system uptime. If you print it out, the results should come 
> back as "20 days, 7 hours, 15 minutes", which is what you want.
>
> -tk
>
> On Fri, Jan 21, 2022 at 2:56 PM Seth Ratner  wrote:
>
>> Closer and Closer, lol
>>
>> row = db_manager.getSql(sql_stmt)
>>
>> Using: SELECT outTemp FROM archive WHERE dateTime BETWEEN 1642744800 AND 
>> 1642748400
>>
>> Is returning a single outTemp. I am not sure how to return multiple rows 
>> then iterate through them to check for == chilhour and add them together. I 
>> know how to do it in PHP, but not WeeWX...
>>
>> I think once I get that, I'll be there. It would be simpler to put 
>> chillHours in the archive then I could just use sum(chillHours) in the sql 
>> query, but I'd rather not at this point, to make the xtype more flexible. 
>>
>>
>> On Friday, January 21, 2022 at 4:48:30 PM UTC-6 tke...@gmail.com wrote:
>>
>>> Oooh. That's a perfect example! Thanks, John.
>>>
>>> On Fri, Jan 21, 2022 at 2:29 PM 'John Kline' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
 Another example:


 https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L538

 On Jan 21, 2022, at 2:01 PM, Seth Ratner  wrote:

 It looks like there is an example in the  weewx-xaggs 
  repository. I'm about to dive 
 in, but from a cursory look, unlike with the scalar, I'm going to have to 
 figure out how to use dbmanager to pull the outtemps from the database 
 then 
 iterate through each one, determine which ones are chill hours, and then 
 add those together, correct?

 On Friday, January 21, 2022 at 3:49:33 PM UTC-6 tke...@gmail.com wrote:

> Let me see if I can come up with something. Give me some time.
>
> On Fri, Jan 21, 2022 at 1:37 PM Seth Ratner  
> wrote:
>
>> Oh boy...
>>
>> I cant find any examples for that. If one exists, it will greatly 
>> reduce the number of questions I have...
>>
>> On Friday, January 21, 2022 at 3:24:07 PM UTC-6 tke...@gmail.com 
>> wrote:
>>
>>> You're getting close!
>>>
>>> You're going to have to implement get_aggregate(), as well as 
>>> get_scalar().
>>>
>>> The xtypes framework has no way of taking the calculation for 
>>> get_scalar() and using it to calculate an aggregate. You're going to 
>>> have 
>>> to do it.  The good news is that once you've done it, then the 
>>> framework 
>>> can use that to calculate a series on its own. This is where we will 
>>> find 
>>> out how fast the calculation is.
>>>
>>> -tk
>>>
>>> On Fri, Jan 21, 2022 at 12:51 PM Seth Ratner  
>>> wrote:
>>>
 Getting Closer, but still getting errors. 

 I can now see the result in the archive loop (gets sent over MQTT). 
 But with the seasons skin attempts to make a chart with it, I get:

 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR 
 weewx.reportengine: Caught unrecoverable exception in generator 
 'weewx.imagegenerator.ImageGenerator'
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR 
 weewx.reportengine:   chillHours
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR 
 weewx.reportengine:   Traceback (most recent call last):

Re: [weewx-user] Re: Chill Hours Extension

[Seth Ratner]

Ok thanks. So I just learned what a python generator is. Cleared up a lot.

Dude, I am seriously floored by how much you put into programming this. I'm 
back-tracking my way through the code for answers, and the detail is 
mind-blowing. Do you have a donations link? 

I'll reply once I have a functioning draft. Now that I understand how to 
use the genBatchRecords generator, I should have a working xType soon

Then someone will have to explain the difference between scalar, series, 
and aggregate to me...

Thanks!

On Friday, January 21, 2022 at 6:07:28 PM UTC-6 tke...@gmail.com wrote:

> Not sure why you would want to do this for times only one hour apart.
>
> Try something like this (NOT TESTED, and highly schematic):
>
> def get_aggregate(obs_type, timespan, aggregate_type, db_manager, 
> **option_dict):
> if obs_type != 'chillHours':
> raise weewx.UnknownType(obs_type)
> if aggregate_type != 'sum':
> return weewx.UnknownAggregation(aggregate_type)
>
> # Convert 45 to the same unit as the database:
> baseline = weewx.units.convertStd(ValueTuple(45, 'degree_F', 
> 'group_temperature'),
>   db_manager.std_unit_system)
> result = db_manager.getSql("SELECT SUM(`interval`) * 60 WHERE 
> outTemp<=? AND dateTime BETWEEN ? AND ?",
>   baseline.value, *timespan)
>
> # Check if result are None.
> # Get the proper unit and group, return as a ValueTuple.
> 
> Note that the type "interval" is escaped with backquotes. This is because 
> in MySQL, "interval" is a keyword unless you escape it.
>
> Assigning the results to either group_elapsed seems reasonable.
>
> Another option would be "group_deltatime", which is normally used for 
> things like system uptime. If you print it out, the results should come 
> back as "20 days, 7 hours, 15 minutes", which is what you want.
>
> -tk
>
> On Fri, Jan 21, 2022 at 2:56 PM Seth Ratner  wrote:
>
>> Closer and Closer, lol
>>
>> row = db_manager.getSql(sql_stmt)
>>
>> Using: SELECT outTemp FROM archive WHERE dateTime BETWEEN 1642744800 AND 
>> 1642748400
>>
>> Is returning a single outTemp. I am not sure how to return multiple rows 
>> then iterate through them to check for == chilhour and add them together. I 
>> know how to do it in PHP, but not WeeWX...
>>
>> I think once I get that, I'll be there. It would be simpler to put 
>> chillHours in the archive then I could just use sum(chillHours) in the sql 
>> query, but I'd rather not at this point, to make the xtype more flexible. 
>>
>>
>> On Friday, January 21, 2022 at 4:48:30 PM UTC-6 tke...@gmail.com wrote:
>>
>>> Oooh. That's a perfect example! Thanks, John.
>>>
>>> On Fri, Jan 21, 2022 at 2:29 PM 'John Kline' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
 Another example:


 https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L538

 On Jan 21, 2022, at 2:01 PM, Seth Ratner  wrote:

 It looks like there is an example in the  weewx-xaggs 
  repository. I'm about to dive 
 in, but from a cursory look, unlike with the scalar, I'm going to have to 
 figure out how to use dbmanager to pull the outtemps from the database 
 then 
 iterate through each one, determine which ones are chill hours, and then 
 add those together, correct?

 On Friday, January 21, 2022 at 3:49:33 PM UTC-6 tke...@gmail.com wrote:

> Let me see if I can come up with something. Give me some time.
>
> On Fri, Jan 21, 2022 at 1:37 PM Seth Ratner  
> wrote:
>
>> Oh boy...
>>
>> I cant find any examples for that. If one exists, it will greatly 
>> reduce the number of questions I have...
>>
>> On Friday, January 21, 2022 at 3:24:07 PM UTC-6 tke...@gmail.com 
>> wrote:
>>
>>> You're getting close!
>>>
>>> You're going to have to implement get_aggregate(), as well as 
>>> get_scalar().
>>>
>>> The xtypes framework has no way of taking the calculation for 
>>> get_scalar() and using it to calculate an aggregate. You're going to 
>>> have 
>>> to do it.  The good news is that once you've done it, then the 
>>> framework 
>>> can use that to calculate a series on its own. This is where we will 
>>> find 
>>> out how fast the calculation is.
>>>
>>> -tk
>>>
>>> On Fri, Jan 21, 2022 at 12:51 PM Seth Ratner  
>>> wrote:
>>>
 Getting Closer, but still getting errors. 

 I can now see the result in the archive loop (gets sent over MQTT). 
 But with the seasons skin attempts to make a chart with it, I get:

 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR 
 weewx.reportengine: Caught unrecoverable exception in generator 
 

Re: [weewx-user] Re: Chill Hours Extension

[gjr80]

Try using genSql() instead of getSql(). genSql() is a generator that will 
allow you to iterate over all rows. getSql() returns a single row. So you 
would have something like:

for row in db_manager.genSql(sql_stmt):


I would also be wary of using BETWEEN. As I understand it BETWEEN is 
inclusive on the low side and the high side, so in your example above both 
records timestamped 1642744800 and 1642748400 will be returned. WeeWX 
usually uses exclusive on the low side and inclusive on the high side - the 
record timestamped 1642744800 includes data for the archive period that 
*ends* at 1642744800 - eg, for a five minute archive interval that would 
include data from 1642744500 to 1642744800. Of course you could do a bit of 
maths on your timestamps, but why bother when you can use:

SELECT outTemp FROM archive WHERE dateTime > 1642744800 AND dateTime <= 
1642748400

Gary

On Saturday, 22 January 2022 at 09:54:37 UTC+10 Seth Ratner wrote:

> Step by step by step...
>
> I think what I want is genBatchRecords from the manager. But I have no 
> idea what the dictionary it yields looks like, so I don't know how to work 
> with it. I've been unsuccessful getting the dictionary to print in the logs 
> so I can look at it. I managed to get get genBatchRows to work, but the 
> list-of-lists it creates are not linked to the column names. 
>
> On Friday, January 21, 2022 at 4:56:02 PM UTC-6 Seth Ratner wrote:
>
>> Closer and Closer, lol
>>
>> row = db_manager.getSql(sql_stmt)
>>
>> Using: SELECT outTemp FROM archive WHERE dateTime BETWEEN 1642744800 AND 
>> 1642748400
>>
>> Is returning a single outTemp. I am not sure how to return multiple rows 
>> then iterate through them to check for == chilhour and add them together. I 
>> know how to do it in PHP, but not WeeWX...
>>
>> I think once I get that, I'll be there. It would be simpler to put 
>> chillHours in the archive then I could just use sum(chillHours) in the sql 
>> query, but I'd rather not at this point, to make the xtype more flexible. 
>>
>>
>> On Friday, January 21, 2022 at 4:48:30 PM UTC-6 tke...@gmail.com wrote:
>>
>>> Oooh. That's a perfect example! Thanks, John.
>>>
>>> On Fri, Jan 21, 2022 at 2:29 PM 'John Kline' via weewx-user <
>>> weewx...@googlegroups.com> wrote:
>>>
 Another example:


 https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L538

 On Jan 21, 2022, at 2:01 PM, Seth Ratner  wrote:

 It looks like there is an example in the  weewx-xaggs 
  repository. I'm about to dive 
 in, but from a cursory look, unlike with the scalar, I'm going to have to 
 figure out how to use dbmanager to pull the outtemps from the database 
 then 
 iterate through each one, determine which ones are chill hours, and then 
 add those together, correct?

 On Friday, January 21, 2022 at 3:49:33 PM UTC-6 tke...@gmail.com wrote:

> Let me see if I can come up with something. Give me some time.
>
> On Fri, Jan 21, 2022 at 1:37 PM Seth Ratner  
> wrote:
>
>> Oh boy...
>>
>> I cant find any examples for that. If one exists, it will greatly 
>> reduce the number of questions I have...
>>
>> On Friday, January 21, 2022 at 3:24:07 PM UTC-6 tke...@gmail.com 
>> wrote:
>>
>>> You're getting close!
>>>
>>> You're going to have to implement get_aggregate(), as well as 
>>> get_scalar().
>>>
>>> The xtypes framework has no way of taking the calculation for 
>>> get_scalar() and using it to calculate an aggregate. You're going to 
>>> have 
>>> to do it.  The good news is that once you've done it, then the 
>>> framework 
>>> can use that to calculate a series on its own. This is where we will 
>>> find 
>>> out how fast the calculation is.
>>>
>>> -tk
>>>
>>> On Fri, Jan 21, 2022 at 12:51 PM Seth Ratner  
>>> wrote:
>>>
 Getting Closer, but still getting errors. 

 I can now see the result in the archive loop (gets sent over MQTT). 
 But with the seasons skin attempts to make a chart with it, I get:

 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR 
 weewx.reportengine: Caught unrecoverable exception in generator 
 'weewx.imagegenerator.ImageGenerator'
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR 
 weewx.reportengine:   chillHours
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR 
 weewx.reportengine:   Traceback (most recent call last):
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR 
 weewx.reportengine: File 
 "/usr/share/weewx/weewx/reportengine.py", line 196, in run
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR 
 weewx.reportengine:   obj.start()
 Jan 21 

Re: [weewx-user] Re: Chill Hours Extension

[Tom Keffer]

Not sure why you would want to do this for times only one hour apart.

Try something like this (NOT TESTED, and highly schematic):

def get_aggregate(obs_type, timespan, aggregate_type, db_manager,
**option_dict):
if obs_type != 'chillHours':
raise weewx.UnknownType(obs_type)
if aggregate_type != 'sum':
return weewx.UnknownAggregation(aggregate_type)

# Convert 45 to the same unit as the database:
baseline = weewx.units.convertStd(ValueTuple(45, 'degree_F',
'group_temperature'),
  db_manager.std_unit_system)
result = db_manager.getSql("SELECT SUM(`interval`) * 60 WHERE
outTemp<=? AND dateTime BETWEEN ? AND ?",
  baseline.value, *timespan)

# Check if result are None.
# Get the proper unit and group, return as a ValueTuple.

Note that the type "interval" is escaped with backquotes. This is because
in MySQL, "interval" is a keyword unless you escape it.

Assigning the results to either group_elapsed seems reasonable.

Another option would be "group_deltatime", which is normally used for
things like system uptime. If you print it out, the results should come
back as "20 days, 7 hours, 15 minutes", which is what you want.

-tk

On Fri, Jan 21, 2022 at 2:56 PM Seth Ratner  wrote:

> Closer and Closer, lol
>
> row = db_manager.getSql(sql_stmt)
>
> Using: SELECT outTemp FROM archive WHERE dateTime BETWEEN 1642744800 AND
> 1642748400
>
> Is returning a single outTemp. I am not sure how to return multiple rows
> then iterate through them to check for == chilhour and add them together. I
> know how to do it in PHP, but not WeeWX...
>
> I think once I get that, I'll be there. It would be simpler to put
> chillHours in the archive then I could just use sum(chillHours) in the sql
> query, but I'd rather not at this point, to make the xtype more flexible.
>
>
> On Friday, January 21, 2022 at 4:48:30 PM UTC-6 tke...@gmail.com wrote:
>
>> Oooh. That's a perfect example! Thanks, John.
>>
>> On Fri, Jan 21, 2022 at 2:29 PM 'John Kline' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> Another example:
>>>
>>>
>>> https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L538
>>>
>>> On Jan 21, 2022, at 2:01 PM, Seth Ratner  wrote:
>>>
>>> It looks like there is an example in the  weewx-xaggs
>>>  repository. I'm about to dive
>>> in, but from a cursory look, unlike with the scalar, I'm going to have to
>>> figure out how to use dbmanager to pull the outtemps from the database then
>>> iterate through each one, determine which ones are chill hours, and then
>>> add those together, correct?
>>>
>>> On Friday, January 21, 2022 at 3:49:33 PM UTC-6 tke...@gmail.com wrote:
>>>
 Let me see if I can come up with something. Give me some time.

 On Fri, Jan 21, 2022 at 1:37 PM Seth Ratner  wrote:

> Oh boy...
>
> I cant find any examples for that. If one exists, it will greatly
> reduce the number of questions I have...
>
> On Friday, January 21, 2022 at 3:24:07 PM UTC-6 tke...@gmail.com
> wrote:
>
>> You're getting close!
>>
>> You're going to have to implement get_aggregate(), as well as
>> get_scalar().
>>
>> The xtypes framework has no way of taking the calculation for
>> get_scalar() and using it to calculate an aggregate. You're going to have
>> to do it.  The good news is that once you've done it, then the framework
>> can use that to calculate a series on its own. This is where we will find
>> out how fast the calculation is.
>>
>> -tk
>>
>> On Fri, Jan 21, 2022 at 12:51 PM Seth Ratner 
>> wrote:
>>
>>> Getting Closer, but still getting errors.
>>>
>>> I can now see the result in the archive loop (gets sent over MQTT).
>>> But with the seasons skin attempts to make a chart with it, I get:
>>>
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>> Caught unrecoverable exception in generator
>>> 'weewx.imagegenerator.ImageGenerator'
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>>   chillHours
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>>   Traceback (most recent call last):
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>> File "/usr/share/weewx/weewx/reportengine.py", line 
>>> 196, in
>>> run
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>>   obj.start()
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>> File "/usr/share/weewx/weewx/reportengine.py", line 
>>> 281, in
>>> start
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR 

Re: [weewx-user] Re: Chill Hours Extension

[Seth Ratner]

Step by step by step...

I think what I want is genBatchRecords from the manager. But I have no idea 
what the dictionary it yields looks like, so I don't know how to work with 
it. I've been unsuccessful getting the dictionary to print in the logs so I 
can look at it. I managed to get get genBatchRows to work, but the 
list-of-lists it creates are not linked to the column names. 

On Friday, January 21, 2022 at 4:56:02 PM UTC-6 Seth Ratner wrote:

> Closer and Closer, lol
>
> row = db_manager.getSql(sql_stmt)
>
> Using: SELECT outTemp FROM archive WHERE dateTime BETWEEN 1642744800 AND 
> 1642748400
>
> Is returning a single outTemp. I am not sure how to return multiple rows 
> then iterate through them to check for == chilhour and add them together. I 
> know how to do it in PHP, but not WeeWX...
>
> I think once I get that, I'll be there. It would be simpler to put 
> chillHours in the archive then I could just use sum(chillHours) in the sql 
> query, but I'd rather not at this point, to make the xtype more flexible. 
>
>
> On Friday, January 21, 2022 at 4:48:30 PM UTC-6 tke...@gmail.com wrote:
>
>> Oooh. That's a perfect example! Thanks, John.
>>
>> On Fri, Jan 21, 2022 at 2:29 PM 'John Kline' via weewx-user <
>> weewx...@googlegroups.com> wrote:
>>
>>> Another example:
>>>
>>>
>>> https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L538
>>>
>>> On Jan 21, 2022, at 2:01 PM, Seth Ratner  wrote:
>>>
>>> It looks like there is an example in the  weewx-xaggs 
>>>  repository. I'm about to dive 
>>> in, but from a cursory look, unlike with the scalar, I'm going to have to 
>>> figure out how to use dbmanager to pull the outtemps from the database then 
>>> iterate through each one, determine which ones are chill hours, and then 
>>> add those together, correct?
>>>
>>> On Friday, January 21, 2022 at 3:49:33 PM UTC-6 tke...@gmail.com wrote:
>>>
 Let me see if I can come up with something. Give me some time.

 On Fri, Jan 21, 2022 at 1:37 PM Seth Ratner  wrote:

> Oh boy...
>
> I cant find any examples for that. If one exists, it will greatly 
> reduce the number of questions I have...
>
> On Friday, January 21, 2022 at 3:24:07 PM UTC-6 tke...@gmail.com 
> wrote:
>
>> You're getting close!
>>
>> You're going to have to implement get_aggregate(), as well as 
>> get_scalar().
>>
>> The xtypes framework has no way of taking the calculation for 
>> get_scalar() and using it to calculate an aggregate. You're going to 
>> have 
>> to do it.  The good news is that once you've done it, then the framework 
>> can use that to calculate a series on its own. This is where we will 
>> find 
>> out how fast the calculation is.
>>
>> -tk
>>
>> On Fri, Jan 21, 2022 at 12:51 PM Seth Ratner  
>> wrote:
>>
>>> Getting Closer, but still getting errors. 
>>>
>>> I can now see the result in the archive loop (gets sent over MQTT). 
>>> But with the seasons skin attempts to make a chart with it, I get:
>>>
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>> Caught unrecoverable exception in generator 
>>> 'weewx.imagegenerator.ImageGenerator'
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>>   chillHours
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>>   Traceback (most recent call last):
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>> File "/usr/share/weewx/weewx/reportengine.py", line 
>>> 196, in 
>>> run
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>>   obj.start()
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>> File "/usr/share/weewx/weewx/reportengine.py", line 
>>> 281, in 
>>> start
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>>   self.run()
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>> File "/usr/share/weewx/weewx/imagegenerator.py", line 
>>> 41, 
>>> in run
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>>   self.genImages(self.gen_ts)
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>> File "/usr/share/weewx/weewx/imagegenerator.py", line 
>>> 177, 
>>> in genImages
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>>   start_vec_t, stop_vec_t ,data_vec_t = 
>>> weewx.xtypes.get_series(var_type,
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>> 

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

[Ted Frohling]

Thanks very much for the new python script.  It works.

The other three files looked great as well.

They were all for Tucson, AZ, USA

ted


On 1/20/22 6:12 PM, 'Cameron D' via weewx-user wrote:

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


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


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

Hello,
Not being a programmer, I probably shouldn't have messed with
this, but being curious...

I tried the code posted on github as well as the one by Cameron D.
In both cases I got the following error:
```
root@n4mrv:/home/bg/weewx_tonga_browse-main# python3 ./tonga.py
[file from Cameron D]

distance to eruption 12056.6 km arrival at 1642258360 (2022-01-15
09:52:39)
      opposite pulse arrival at 1642308921 (2022-01-15 23:55:21)
      second time around pulse arrival at 1642385471 (2022-01-16
21:11:10)
Traceback (most recent call last):
  File "./tonga.py", line 178, in 
    plot_burst( cursor, arrival_time, hour_span, "primary" )
  File "./tonga.py", line 54, in plot_burst
    coeff = np.polyfit(xdata, ydata, background_order )
  File "<__array_function__ internals>", line 180, in polyfit
  File
"/usr/local/lib/python3.8/dist-packages/numpy/lib/polynomial.py",
line 638, in polyfit
raise TypeError("expected non-empty vector for x")
TypeError: expected non-empty vector for x
```
I added my lat/lon information but may have missed something else
I need to change. Python modules were installed as directed. Copy
of weewx.sdb is in the same directory as the program.
Thanks.
Bob
On Wednesday, January 19, 2022 at 10:32:49 AM UTC-5
morr...@gmail.com wrote:

On Wednesday, January 19, 2022 at 12:42:04 a.m. UTC-4 Cameron
D wrote:

  * as you get closer to the equator, tidal changes
dominate the baseline in that timescale - I tried
higher order polynomials, but they are next to useless.

I also had little luck with higher order polynomials to remove
the general trend.

I've put the script here:
https://github.com/morrowwm/weewx_tonga_browse

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


--
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/f667e702-0e2d-61a7-1e18-74bc6916ecb3%40gmail.com.

Re: [weewx-user] Re: Chill Hours Extension

[Seth Ratner]

Closer and Closer, lol

row = db_manager.getSql(sql_stmt)

Using: SELECT outTemp FROM archive WHERE dateTime BETWEEN 1642744800 AND 
1642748400

Is returning a single outTemp. I am not sure how to return multiple rows 
then iterate through them to check for == chilhour and add them together. I 
know how to do it in PHP, but not WeeWX...

I think once I get that, I'll be there. It would be simpler to put 
chillHours in the archive then I could just use sum(chillHours) in the sql 
query, but I'd rather not at this point, to make the xtype more flexible. 


On Friday, January 21, 2022 at 4:48:30 PM UTC-6 tke...@gmail.com wrote:

> Oooh. That's a perfect example! Thanks, John.
>
> On Fri, Jan 21, 2022 at 2:29 PM 'John Kline' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
>> Another example:
>>
>>
>> https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L538
>>
>> On Jan 21, 2022, at 2:01 PM, Seth Ratner  wrote:
>>
>> It looks like there is an example in the  weewx-xaggs 
>>  repository. I'm about to dive 
>> in, but from a cursory look, unlike with the scalar, I'm going to have to 
>> figure out how to use dbmanager to pull the outtemps from the database then 
>> iterate through each one, determine which ones are chill hours, and then 
>> add those together, correct?
>>
>> On Friday, January 21, 2022 at 3:49:33 PM UTC-6 tke...@gmail.com wrote:
>>
>>> Let me see if I can come up with something. Give me some time.
>>>
>>> On Fri, Jan 21, 2022 at 1:37 PM Seth Ratner  wrote:
>>>
 Oh boy...

 I cant find any examples for that. If one exists, it will greatly 
 reduce the number of questions I have...

 On Friday, January 21, 2022 at 3:24:07 PM UTC-6 tke...@gmail.com wrote:

> You're getting close!
>
> You're going to have to implement get_aggregate(), as well as 
> get_scalar().
>
> The xtypes framework has no way of taking the calculation for 
> get_scalar() and using it to calculate an aggregate. You're going to have 
> to do it.  The good news is that once you've done it, then the framework 
> can use that to calculate a series on its own. This is where we will find 
> out how fast the calculation is.
>
> -tk
>
> On Fri, Jan 21, 2022 at 12:51 PM Seth Ratner  
> wrote:
>
>> Getting Closer, but still getting errors. 
>>
>> I can now see the result in the archive loop (gets sent over MQTT). 
>> But with the seasons skin attempts to make a chart with it, I get:
>>
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>> Caught unrecoverable exception in generator 
>> 'weewx.imagegenerator.ImageGenerator'
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   chillHours
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   Traceback (most recent call last):
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/reportengine.py", line 196, 
>> in 
>> run
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   obj.start()
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/reportengine.py", line 281, 
>> in 
>> start
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   self.run()
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/imagegenerator.py", line 
>> 41, 
>> in run
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   self.genImages(self.gen_ts)
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/imagegenerator.py", line 
>> 177, 
>> in genImages
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   start_vec_t, stop_vec_t ,data_vec_t = 
>> weewx.xtypes.get_series(var_type,
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/xtypes.py", line 94, in 
>> get_series
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   raise weewx.UnknownType(obs_type)
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   weewx.UnknownType: chillHours
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   Generator terminated
>>
>> Here's the block I added in skin.conf
>>
>> [[[yearchill]]]
>> plot_type = bar
>> 

Re: [weewx-user] Re: Chill Hours Extension

[Tom Keffer]

Oooh. That's a perfect example! Thanks, John.

On Fri, Jan 21, 2022 at 2:29 PM 'John Kline' via weewx-user <
weewx-user@googlegroups.com> wrote:

> Another example:
>
>
> https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L538
>
> On Jan 21, 2022, at 2:01 PM, Seth Ratner  wrote:
>
> It looks like there is an example in the  weewx-xaggs
>  repository. I'm about to dive
> in, but from a cursory look, unlike with the scalar, I'm going to have to
> figure out how to use dbmanager to pull the outtemps from the database then
> iterate through each one, determine which ones are chill hours, and then
> add those together, correct?
>
> On Friday, January 21, 2022 at 3:49:33 PM UTC-6 tke...@gmail.com wrote:
>
>> Let me see if I can come up with something. Give me some time.
>>
>> On Fri, Jan 21, 2022 at 1:37 PM Seth Ratner  wrote:
>>
>>> Oh boy...
>>>
>>> I cant find any examples for that. If one exists, it will greatly reduce
>>> the number of questions I have...
>>>
>>> On Friday, January 21, 2022 at 3:24:07 PM UTC-6 tke...@gmail.com wrote:
>>>
 You're getting close!

 You're going to have to implement get_aggregate(), as well as
 get_scalar().

 The xtypes framework has no way of taking the calculation for
 get_scalar() and using it to calculate an aggregate. You're going to have
 to do it.  The good news is that once you've done it, then the framework
 can use that to calculate a series on its own. This is where we will find
 out how fast the calculation is.

 -tk

 On Fri, Jan 21, 2022 at 12:51 PM Seth Ratner 
 wrote:

> Getting Closer, but still getting errors.
>
> I can now see the result in the archive loop (gets sent over MQTT).
> But with the seasons skin attempts to make a chart with it, I get:
>
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
> Caught unrecoverable exception in generator
> 'weewx.imagegenerator.ImageGenerator'
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     chillHours
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     Traceback (most recent call last):
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>   File "/usr/share/weewx/weewx/reportengine.py", line 196, in
> run
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     obj.start()
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>   File "/usr/share/weewx/weewx/reportengine.py", line 281, in
> start
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     self.run()
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>   File "/usr/share/weewx/weewx/imagegenerator.py", line 41, in
> run
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     self.genImages(self.gen_ts)
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>   File "/usr/share/weewx/weewx/imagegenerator.py", line 177, 
> in
> genImages
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     start_vec_t, stop_vec_t ,data_vec_t =
> weewx.xtypes.get_series(var_type,
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>   File "/usr/share/weewx/weewx/xtypes.py", line 94, in
> get_series
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     raise weewx.UnknownType(obs_type)
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     weewx.UnknownType: chillHours
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     Generator terminated
>
> Here's the block I added in skin.conf
>
> [[[yearchill]]]
> plot_type = bar
> chillHours
> aggregate_type = cumulative
> aggregate_interval = day
>
>
> On Friday, January 21, 2022 at 2:14:11 PM UTC-6 Seth Ratner wrote:
>
>> I'm close, I think, except now I'm getting this every loop or report
>> generation.
>>
>> DEBUG weewx.wxservices: Unknown extensible type 'chillHours'
>>
>> There are a couple things I'm unsure of that might be causing this
>>
>> - I used the group type group_elapsed because it seemed like the best
>> fit
>> - The last line of the python file, modeled after the
>> VaporPressure.py example, is not part of either class, so I'm not sure 
>> what
>> runs it.
>>
>> Here's the code:
>> 

Re: [weewx-user] Re: Chill Hours Extension

['John Kline' via weewx-user]

Another example:

https://github.com/chaunceygardiner/weewx-purple/blob/e7f214539b63281d74af9e90810045dd8d1b7b80/bin/user/purple.py#L538

> On Jan 21, 2022, at 2:01 PM, Seth Ratner  wrote:
> 
> It looks like there is an example in the  weewx-xaggs repository. I'm about 
> to dive in, but from a cursory look, unlike with the scalar, I'm going to 
> have to figure out how to use dbmanager to pull the outtemps from the 
> database then iterate through each one, determine which ones are chill hours, 
> and then add those together, correct?
> 
>> On Friday, January 21, 2022 at 3:49:33 PM UTC-6 tke...@gmail.com wrote:
>> Let me see if I can come up with something. Give me some time.
>> 
>>> On Fri, Jan 21, 2022 at 1:37 PM Seth Ratner  wrote:
>>> Oh boy...
>>> 
>>> I cant find any examples for that. If one exists, it will greatly reduce 
>>> the number of questions I have...
>>> 
 On Friday, January 21, 2022 at 3:24:07 PM UTC-6 tke...@gmail.com wrote:
 You're getting close!
 
 You're going to have to implement get_aggregate(), as well as get_scalar().
 
 The xtypes framework has no way of taking the calculation for get_scalar() 
 and using it to calculate an aggregate. You're going to have to do it.  
 The good news is that once you've done it, then the framework can use that 
 to calculate a series on its own. This is where we will find out how fast 
 the calculation is.
 
 -tk
 
> On Fri, Jan 21, 2022 at 12:51 PM Seth Ratner  wrote:
> Getting Closer, but still getting errors. 
> 
> I can now see the result in the archive loop (gets sent over MQTT). But 
> with the seasons skin attempts to make a chart with it, I get:
> 
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
> Caught unrecoverable exception in generator 
> 'weewx.imagegenerator.ImageGenerator'
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>  chillHours
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>  Traceback (most recent call last):
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>File "/usr/share/weewx/weewx/reportengine.py", line 196, in run
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>  obj.start()
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>File "/usr/share/weewx/weewx/reportengine.py", line 281, in 
> start
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>  self.run()
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>File "/usr/share/weewx/weewx/imagegenerator.py", line 41, in 
> run
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>  self.genImages(self.gen_ts)
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>File "/usr/share/weewx/weewx/imagegenerator.py", line 177, in 
> genImages
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>  start_vec_t, stop_vec_t ,data_vec_t = 
> weewx.xtypes.get_series(var_type,
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>File "/usr/share/weewx/weewx/xtypes.py", line 94, in get_series
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>  raise weewx.UnknownType(obs_type)
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>  weewx.UnknownType: chillHours
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:  
>  Generator terminated
> 
> Here's the block I added in skin.conf
> 
> [[[yearchill]]]
> plot_type = bar
> chillHours
> aggregate_type = cumulative
> aggregate_interval = day
> 
> 
>> On Friday, January 21, 2022 at 2:14:11 PM UTC-6 Seth Ratner wrote:
>> I'm close, I think, except now I'm getting this every loop or report 
>> generation.
>> 
>> DEBUG weewx.wxservices: Unknown extensible type 'chillHours'
>> 
>> There are a couple things I'm unsure of that might be causing this
>> 
>> - I used the group type group_elapsed because it seemed like the best fit
>> - The last line of the python file, modeled after the VaporPressure.py 
>> example, is not part of either class, so I'm not sure what runs it. 
>> 
>> Here's the code: 
>> https://github.com/lordratner/weewx_chillHours/blob/main/chill_hours.py
>> 
>> It's been added to weewx.conf engine section in xtypes, and I've 
>> confirmed the service is loading. 
>> 
>> Thoughts?
>> 
>> 
>>> On 

Re: [weewx-user] Re: Chill Hours Extension

[Seth Ratner]

It looks like there is an example in the  weewx-xaggs 
 repository. I'm about to dive in, 
but from a cursory look, unlike with the scalar, I'm going to have to 
figure out how to use dbmanager to pull the outtemps from the database then 
iterate through each one, determine which ones are chill hours, and then 
add those together, correct?

On Friday, January 21, 2022 at 3:49:33 PM UTC-6 tke...@gmail.com wrote:

> Let me see if I can come up with something. Give me some time.
>
> On Fri, Jan 21, 2022 at 1:37 PM Seth Ratner  wrote:
>
>> Oh boy...
>>
>> I cant find any examples for that. If one exists, it will greatly reduce 
>> the number of questions I have...
>>
>> On Friday, January 21, 2022 at 3:24:07 PM UTC-6 tke...@gmail.com wrote:
>>
>>> You're getting close!
>>>
>>> You're going to have to implement get_aggregate(), as well as 
>>> get_scalar().
>>>
>>> The xtypes framework has no way of taking the calculation for 
>>> get_scalar() and using it to calculate an aggregate. You're going to have 
>>> to do it.  The good news is that once you've done it, then the framework 
>>> can use that to calculate a series on its own. This is where we will find 
>>> out how fast the calculation is.
>>>
>>> -tk
>>>
>>> On Fri, Jan 21, 2022 at 12:51 PM Seth Ratner  wrote:
>>>
 Getting Closer, but still getting errors. 

 I can now see the result in the archive loop (gets sent over MQTT). But 
 with the seasons skin attempts to make a chart with it, I get:

 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
 Caught unrecoverable exception in generator 
 'weewx.imagegenerator.ImageGenerator'
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
     chillHours
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
     Traceback (most recent call last):
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
   File "/usr/share/weewx/weewx/reportengine.py", line 196, in 
 run
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
     obj.start()
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
   File "/usr/share/weewx/weewx/reportengine.py", line 281, in 
 start
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
     self.run()
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
   File "/usr/share/weewx/weewx/imagegenerator.py", line 41, in 
 run
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
     self.genImages(self.gen_ts)
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
   File "/usr/share/weewx/weewx/imagegenerator.py", line 177, 
 in 
 genImages
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
     start_vec_t, stop_vec_t ,data_vec_t = 
 weewx.xtypes.get_series(var_type,
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
   File "/usr/share/weewx/weewx/xtypes.py", line 94, in 
 get_series
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
     raise weewx.UnknownType(obs_type)
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
     weewx.UnknownType: chillHours
 Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
     Generator terminated

 Here's the block I added in skin.conf

 [[[yearchill]]]
 plot_type = bar
 chillHours
 aggregate_type = cumulative
 aggregate_interval = day


 On Friday, January 21, 2022 at 2:14:11 PM UTC-6 Seth Ratner wrote:

> I'm close, I think, except now I'm getting this every loop or report 
> generation.
>
> DEBUG weewx.wxservices: Unknown extensible type 'chillHours'
>
> There are a couple things I'm unsure of that might be causing this
>
> - I used the group type group_elapsed because it seemed like the best 
> fit
> - The last line of the python file, modeled after the VaporPressure.py 
> example, is not part of either class, so I'm not sure what runs it. 
>
> Here's the code: 
> https://github.com/lordratner/weewx_chillHours/blob/main/chill_hours.py
>
> It's been added to weewx.conf engine section in xtypes, and I've 
> confirmed the service is loading. 
>
> Thoughts?
>
>
> On Thursday, January 20, 2022 at 8:26:59 PM UTC-6 tke...@gmail.com 
> wrote:
>
>> I'd try it as a pure xtype first, and see what kind of performance I 
>> got. If it's slow, put it in the database.
>>
>> You can query 

Re: [weewx-user] Re: Chill Hours Extension

[Tom Keffer]

Let me see if I can come up with something. Give me some time.

On Fri, Jan 21, 2022 at 1:37 PM Seth Ratner  wrote:

> Oh boy...
>
> I cant find any examples for that. If one exists, it will greatly reduce
> the number of questions I have...
>
> On Friday, January 21, 2022 at 3:24:07 PM UTC-6 tke...@gmail.com wrote:
>
>> You're getting close!
>>
>> You're going to have to implement get_aggregate(), as well as
>> get_scalar().
>>
>> The xtypes framework has no way of taking the calculation for
>> get_scalar() and using it to calculate an aggregate. You're going to have
>> to do it.  The good news is that once you've done it, then the framework
>> can use that to calculate a series on its own. This is where we will find
>> out how fast the calculation is.
>>
>> -tk
>>
>> On Fri, Jan 21, 2022 at 12:51 PM Seth Ratner  wrote:
>>
>>> Getting Closer, but still getting errors.
>>>
>>> I can now see the result in the archive loop (gets sent over MQTT). But
>>> with the seasons skin attempts to make a chart with it, I get:
>>>
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>> Caught unrecoverable exception in generator
>>> 'weewx.imagegenerator.ImageGenerator'
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>>   chillHours
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>>   Traceback (most recent call last):
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>> File "/usr/share/weewx/weewx/reportengine.py", line 196, in run
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>>   obj.start()
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>> File "/usr/share/weewx/weewx/reportengine.py", line 281, in
>>> start
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>>   self.run()
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>> File "/usr/share/weewx/weewx/imagegenerator.py", line 41, in run
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>>   self.genImages(self.gen_ts)
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>> File "/usr/share/weewx/weewx/imagegenerator.py", line 177, in
>>> genImages
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>>   start_vec_t, stop_vec_t ,data_vec_t =
>>> weewx.xtypes.get_series(var_type,
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>> File "/usr/share/weewx/weewx/xtypes.py", line 94, in get_series
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>>   raise weewx.UnknownType(obs_type)
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>>   weewx.UnknownType: chillHours
>>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>>>   Generator terminated
>>>
>>> Here's the block I added in skin.conf
>>>
>>> [[[yearchill]]]
>>> plot_type = bar
>>> chillHours
>>> aggregate_type = cumulative
>>> aggregate_interval = day
>>>
>>>
>>> On Friday, January 21, 2022 at 2:14:11 PM UTC-6 Seth Ratner wrote:
>>>
 I'm close, I think, except now I'm getting this every loop or report
 generation.

 DEBUG weewx.wxservices: Unknown extensible type 'chillHours'

 There are a couple things I'm unsure of that might be causing this

 - I used the group type group_elapsed because it seemed like the best
 fit
 - The last line of the python file, modeled after the VaporPressure.py
 example, is not part of either class, so I'm not sure what runs it.

 Here's the code:
 https://github.com/lordratner/weewx_chillHours/blob/main/chill_hours.py

 It's been added to weewx.conf engine section in xtypes, and I've
 confirmed the service is loading.

 Thoughts?


 On Thursday, January 20, 2022 at 8:26:59 PM UTC-6 tke...@gmail.com
 wrote:

> I'd try it as a pure xtype first, and see what kind of performance I
> got. If it's slow, put it in the database.
>
> You can query the database directly, but the advantage of using xtypes
> system to do your queries is that it can automatically optimize whether or
> not to use the daily summaries.
>
> There's a brief section
> 
> in the wiki about the API. It's pretty self-explanatory, except about 
> where
> db_manager comes from. That's an instance of
> weewx.manager.DaySummaryManager. Look in weewx/manager.py for how to 
> create
> one. There are some convenient static methods for doing so.
>
> On Thu, Jan 20, 2022 at 6:15 PM Seth Ratner 
> wrote:
>
>> Thanks 

Re: [weewx-user] Re: Chill Hours Extension

[Seth Ratner]

Oh boy...

I cant find any examples for that. If one exists, it will greatly reduce 
the number of questions I have...

On Friday, January 21, 2022 at 3:24:07 PM UTC-6 tke...@gmail.com wrote:

> You're getting close!
>
> You're going to have to implement get_aggregate(), as well as get_scalar().
>
> The xtypes framework has no way of taking the calculation for get_scalar() 
> and using it to calculate an aggregate. You're going to have to do it.  The 
> good news is that once you've done it, then the framework can use that to 
> calculate a series on its own. This is where we will find out how fast the 
> calculation is.
>
> -tk
>
> On Fri, Jan 21, 2022 at 12:51 PM Seth Ratner  wrote:
>
>> Getting Closer, but still getting errors. 
>>
>> I can now see the result in the archive loop (gets sent over MQTT). But 
>> with the seasons skin attempts to make a chart with it, I get:
>>
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>> Caught unrecoverable exception in generator 
>> 'weewx.imagegenerator.ImageGenerator'
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   chillHours
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   Traceback (most recent call last):
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/reportengine.py", line 196, in run
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   obj.start()
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/reportengine.py", line 281, in 
>> start
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   self.run()
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/imagegenerator.py", line 41, in run
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   self.genImages(self.gen_ts)
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/imagegenerator.py", line 177, in 
>> genImages
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   start_vec_t, stop_vec_t ,data_vec_t = 
>> weewx.xtypes.get_series(var_type,
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/xtypes.py", line 94, in get_series
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   raise weewx.UnknownType(obs_type)
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   weewx.UnknownType: chillHours
>> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: 
>>   Generator terminated
>>
>> Here's the block I added in skin.conf
>>
>> [[[yearchill]]]
>> plot_type = bar
>> chillHours
>> aggregate_type = cumulative
>> aggregate_interval = day
>>
>>
>> On Friday, January 21, 2022 at 2:14:11 PM UTC-6 Seth Ratner wrote:
>>
>>> I'm close, I think, except now I'm getting this every loop or report 
>>> generation.
>>>
>>> DEBUG weewx.wxservices: Unknown extensible type 'chillHours'
>>>
>>> There are a couple things I'm unsure of that might be causing this
>>>
>>> - I used the group type group_elapsed because it seemed like the best fit
>>> - The last line of the python file, modeled after the VaporPressure.py 
>>> example, is not part of either class, so I'm not sure what runs it. 
>>>
>>> Here's the code: 
>>> https://github.com/lordratner/weewx_chillHours/blob/main/chill_hours.py
>>>
>>> It's been added to weewx.conf engine section in xtypes, and I've 
>>> confirmed the service is loading. 
>>>
>>> Thoughts?
>>>
>>>
>>> On Thursday, January 20, 2022 at 8:26:59 PM UTC-6 tke...@gmail.com 
>>> wrote:
>>>
 I'd try it as a pure xtype first, and see what kind of performance I 
 got. If it's slow, put it in the database.

 You can query the database directly, but the advantage of using xtypes 
 system to do your queries is that it can automatically optimize whether or 
 not to use the daily summaries. 

 There's a brief section 
 
  
 in the wiki about the API. It's pretty self-explanatory, except about 
 where 
 db_manager comes from. That's an instance of 
 weewx.manager.DaySummaryManager. Look in weewx/manager.py for how to 
 create 
 one. There are some convenient static methods for doing so.

 On Thu, Jan 20, 2022 at 6:15 PM Seth Ratner  
 wrote:

> Thanks Tom
>
> Final questions for the night, I promise 藍
>
> Would you put this one the database, or just let WeeWx calculate it 

Re: [weewx-user] Re: Chill Hours Extension

[Tom Keffer]

You're getting close!

You're going to have to implement get_aggregate(), as well as get_scalar().

The xtypes framework has no way of taking the calculation for get_scalar()
and using it to calculate an aggregate. You're going to have to do it.  The
good news is that once you've done it, then the framework can use that to
calculate a series on its own. This is where we will find out how fast the
calculation is.

-tk

On Fri, Jan 21, 2022 at 12:51 PM Seth Ratner  wrote:

> Getting Closer, but still getting errors.
>
> I can now see the result in the archive loop (gets sent over MQTT). But
> with the seasons skin attempts to make a chart with it, I get:
>
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
> Caught unrecoverable exception in generator
> 'weewx.imagegenerator.ImageGenerator'
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     chillHours
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     Traceback (most recent call last):
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>   File "/usr/share/weewx/weewx/reportengine.py", line 196, in run
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     obj.start()
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>   File "/usr/share/weewx/weewx/reportengine.py", line 281, in start
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     self.run()
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>   File "/usr/share/weewx/weewx/imagegenerator.py", line 41, in run
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     self.genImages(self.gen_ts)
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>   File "/usr/share/weewx/weewx/imagegenerator.py", line 177, in
> genImages
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     start_vec_t, stop_vec_t ,data_vec_t =
> weewx.xtypes.get_series(var_type,
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>   File "/usr/share/weewx/weewx/xtypes.py", line 94, in get_series
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     raise weewx.UnknownType(obs_type)
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     weewx.UnknownType: chillHours
> Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:
>     Generator terminated
>
> Here's the block I added in skin.conf
>
> [[[yearchill]]]
> plot_type = bar
> chillHours
> aggregate_type = cumulative
> aggregate_interval = day
>
>
> On Friday, January 21, 2022 at 2:14:11 PM UTC-6 Seth Ratner wrote:
>
>> I'm close, I think, except now I'm getting this every loop or report
>> generation.
>>
>> DEBUG weewx.wxservices: Unknown extensible type 'chillHours'
>>
>> There are a couple things I'm unsure of that might be causing this
>>
>> - I used the group type group_elapsed because it seemed like the best fit
>> - The last line of the python file, modeled after the VaporPressure.py
>> example, is not part of either class, so I'm not sure what runs it.
>>
>> Here's the code:
>> https://github.com/lordratner/weewx_chillHours/blob/main/chill_hours.py
>>
>> It's been added to weewx.conf engine section in xtypes, and I've
>> confirmed the service is loading.
>>
>> Thoughts?
>>
>>
>> On Thursday, January 20, 2022 at 8:26:59 PM UTC-6 tke...@gmail.com wrote:
>>
>>> I'd try it as a pure xtype first, and see what kind of performance I
>>> got. If it's slow, put it in the database.
>>>
>>> You can query the database directly, but the advantage of using xtypes
>>> system to do your queries is that it can automatically optimize whether or
>>> not to use the daily summaries.
>>>
>>> There's a brief section
>>> 
>>> in the wiki about the API. It's pretty self-explanatory, except about where
>>> db_manager comes from. That's an instance of
>>> weewx.manager.DaySummaryManager. Look in weewx/manager.py for how to create
>>> one. There are some convenient static methods for doing so.
>>>
>>> On Thu, Jan 20, 2022 at 6:15 PM Seth Ratner 
>>> wrote:
>>>
 Thanks Tom

 Final questions for the night, I promise 藍

 Would you put this one the database, or just let WeeWx calculate it
 using the xtype each time?

 Second, is there an API or interface or whatever where another
 application can query WeeWX for some sort of weather data? In this case,
 I'd like my irrigation software to query WeeWX for the ET, total rain, and
 chill hours of a given time frame.

 Or do I just have to read the database directly?



 On Thu, Jan 20, 2022, 19:15 Tom Keffer  wrote:

> On Thu, Jan 20, 2022 

Re: [weewx-user] Re: Chill Hours Extension

[Seth Ratner]

Getting Closer, but still getting errors. 

I can now see the result in the archive loop (gets sent over MQTT). But 
with the seasons skin attempts to make a chart with it, I get:

Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine: Caught 
unrecoverable exception in generator 'weewx.imagegenerator.ImageGenerator'
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
    chillHours
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
    Traceback (most recent call last):
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/reportengine.py", line 196, in run
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
    obj.start()
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/reportengine.py", line 281, in start
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
    self.run()
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/imagegenerator.py", line 41, in run
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
    self.genImages(self.gen_ts)
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/imagegenerator.py", line 177, in 
genImages
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
    start_vec_t, stop_vec_t ,data_vec_t = 
weewx.xtypes.get_series(var_type,
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
  File "/usr/share/weewx/weewx/xtypes.py", line 94, in get_series
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
    raise weewx.UnknownType(obs_type)
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
    weewx.UnknownType: chillHours
Jan 21 14:40:39 Ratner-Orchard weewx[3122] ERROR weewx.reportengine:   
    Generator terminated

Here's the block I added in skin.conf

[[[yearchill]]]
plot_type = bar
chillHours
aggregate_type = cumulative
aggregate_interval = day


On Friday, January 21, 2022 at 2:14:11 PM UTC-6 Seth Ratner wrote:

> I'm close, I think, except now I'm getting this every loop or report 
> generation.
>
> DEBUG weewx.wxservices: Unknown extensible type 'chillHours'
>
> There are a couple things I'm unsure of that might be causing this
>
> - I used the group type group_elapsed because it seemed like the best fit
> - The last line of the python file, modeled after the VaporPressure.py 
> example, is not part of either class, so I'm not sure what runs it. 
>
> Here's the code: 
> https://github.com/lordratner/weewx_chillHours/blob/main/chill_hours.py
>
> It's been added to weewx.conf engine section in xtypes, and I've confirmed 
> the service is loading. 
>
> Thoughts?
>
>
> On Thursday, January 20, 2022 at 8:26:59 PM UTC-6 tke...@gmail.com wrote:
>
>> I'd try it as a pure xtype first, and see what kind of performance I got. 
>> If it's slow, put it in the database.
>>
>> You can query the database directly, but the advantage of using xtypes 
>> system to do your queries is that it can automatically optimize whether or 
>> not to use the daily summaries. 
>>
>> There's a brief section 
>>  
>> in the wiki about the API. It's pretty self-explanatory, except about where 
>> db_manager comes from. That's an instance of 
>> weewx.manager.DaySummaryManager. Look in weewx/manager.py for how to create 
>> one. There are some convenient static methods for doing so.
>>
>> On Thu, Jan 20, 2022 at 6:15 PM Seth Ratner  wrote:
>>
>>> Thanks Tom
>>>
>>> Final questions for the night, I promise 藍
>>>
>>> Would you put this one the database, or just let WeeWx calculate it 
>>> using the xtype each time?
>>>
>>> Second, is there an API or interface or whatever where another 
>>> application can query WeeWX for some sort of weather data? In this case, 
>>> I'd like my irrigation software to query WeeWX for the ET, total rain, and 
>>> chill hours of a given time frame. 
>>>
>>> Or do I just have to read the database directly?
>>>
>>>
>>>
>>> On Thu, Jan 20, 2022, 19:15 Tom Keffer  wrote:
>>>
 On Thu, Jan 20, 2022 at 4:01 PM Seth Ratner  wrote:

> Would you add the step from the xType guide of adding chillHours to 
> [StdWXCalculate] [[Calculations]]? Or would the "synthetic type" concept 
> mean it only exists when it is called on.
>
> As I understand it, adding it to [StdWXCalculate] [[Calculations]] 
> would add chillHours to the loop, but it would not be in the archive 
> unless 
> I also added a column for it with the same type name.
>

 It doesn't hurt to 

Re: [weewx-user] Re: Chill Hours Extension

[Seth Ratner]

Nevermind. Apparently all I needed to do was move the last line from the 
vapor pressure example "weewx.units.obs_group_dict['chillHours'] = 
"group_elapsed"" 
from the end of the file to the beginning, just under the import 
statements. 

The customization guide has it correctly, the vapor pressure example does 
not. 

On Friday, January 21, 2022 at 2:14:11 PM UTC-6 Seth Ratner wrote:

> I'm close, I think, except now I'm getting this every loop or report 
> generation.
>
> DEBUG weewx.wxservices: Unknown extensible type 'chillHours'
>
> There are a couple things I'm unsure of that might be causing this
>
> - I used the group type group_elapsed because it seemed like the best fit
> - The last line of the python file, modeled after the VaporPressure.py 
> example, is not part of either class, so I'm not sure what runs it. 
>
> Here's the code: 
> https://github.com/lordratner/weewx_chillHours/blob/main/chill_hours.py
>
> It's been added to weewx.conf engine section in xtypes, and I've confirmed 
> the service is loading. 
>
> Thoughts?
>
>
> On Thursday, January 20, 2022 at 8:26:59 PM UTC-6 tke...@gmail.com wrote:
>
>> I'd try it as a pure xtype first, and see what kind of performance I got. 
>> If it's slow, put it in the database.
>>
>> You can query the database directly, but the advantage of using xtypes 
>> system to do your queries is that it can automatically optimize whether or 
>> not to use the daily summaries. 
>>
>> There's a brief section 
>>  
>> in the wiki about the API. It's pretty self-explanatory, except about where 
>> db_manager comes from. That's an instance of 
>> weewx.manager.DaySummaryManager. Look in weewx/manager.py for how to create 
>> one. There are some convenient static methods for doing so.
>>
>> On Thu, Jan 20, 2022 at 6:15 PM Seth Ratner  wrote:
>>
>>> Thanks Tom
>>>
>>> Final questions for the night, I promise 藍
>>>
>>> Would you put this one the database, or just let WeeWx calculate it 
>>> using the xtype each time?
>>>
>>> Second, is there an API or interface or whatever where another 
>>> application can query WeeWX for some sort of weather data? In this case, 
>>> I'd like my irrigation software to query WeeWX for the ET, total rain, and 
>>> chill hours of a given time frame. 
>>>
>>> Or do I just have to read the database directly?
>>>
>>>
>>>
>>> On Thu, Jan 20, 2022, 19:15 Tom Keffer  wrote:
>>>
 On Thu, Jan 20, 2022 at 4:01 PM Seth Ratner  wrote:

> Would you add the step from the xType guide of adding chillHours to 
> [StdWXCalculate] [[Calculations]]? Or would the "synthetic type" concept 
> mean it only exists when it is called on.
>
> As I understand it, adding it to [StdWXCalculate] [[Calculations]] 
> would add chillHours to the loop, but it would not be in the archive 
> unless 
> I also added a column for it with the same type name.
>

 It doesn't hurt to add to StdWXCalculate, but it's really only 
 necessary if you want to add the results to the database.  And, yes, 
 it will only get added to the database if there's a matching column in the 
 schema.

>
> So on my Belchertown skin, where I want total Chill Hours from Oct - 
> May displayed, if I add it to the archive WeeWX will use the database to 
> calculate the total (just adding them together), whereas if I don't add 
> it 
> to the archive, WeeWX will have to run the (if outTemp < 45 then 
> chillHours 
> = archive_interval) for every archive row in that timespan, then sum that?
>

 Maybe. For the ImageGenerator that comes with WeeWX, if a type is not 
 available in the database, it will try to calculate it "on the fly" using 
 xtypes. However, I have no idea what the Belchertown skin does. I kind of 
 doubt it leverages xtypes.
 -tk

 -- 
 You received this message because you are subscribed to a topic in the 
 Google Groups "weewx-user" group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/weewx-user/7ysYvSUMOOo/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 weewx-user+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/CAPq0zEAdDBGTow7i55XfnGPzncQjdmiH%2BSk%3DL9_ZoE85QXKO%3Dw%40mail.gmail.com
  
 
 .

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

Re: [weewx-user] Re: Chill Hours Extension

[Seth Ratner]

I'm close, I think, except now I'm getting this every loop or report 
generation.

DEBUG weewx.wxservices: Unknown extensible type 'chillHours'

There are a couple things I'm unsure of that might be causing this

- I used the group type group_elapsed because it seemed like the best fit
- The last line of the python file, modeled after the VaporPressure.py 
example, is not part of either class, so I'm not sure what runs it. 

Here's the 
code: https://github.com/lordratner/weewx_chillHours/blob/main/chill_hours.py

It's been added to weewx.conf engine section in xtypes, and I've confirmed 
the service is loading. 

Thoughts?


On Thursday, January 20, 2022 at 8:26:59 PM UTC-6 tke...@gmail.com wrote:

> I'd try it as a pure xtype first, and see what kind of performance I got. 
> If it's slow, put it in the database.
>
> You can query the database directly, but the advantage of using xtypes 
> system to do your queries is that it can automatically optimize whether or 
> not to use the daily summaries. 
>
> There's a brief section 
>  
> in the wiki about the API. It's pretty self-explanatory, except about where 
> db_manager comes from. That's an instance of 
> weewx.manager.DaySummaryManager. Look in weewx/manager.py for how to create 
> one. There are some convenient static methods for doing so.
>
> On Thu, Jan 20, 2022 at 6:15 PM Seth Ratner  wrote:
>
>> Thanks Tom
>>
>> Final questions for the night, I promise 藍
>>
>> Would you put this one the database, or just let WeeWx calculate it using 
>> the xtype each time?
>>
>> Second, is there an API or interface or whatever where another 
>> application can query WeeWX for some sort of weather data? In this case, 
>> I'd like my irrigation software to query WeeWX for the ET, total rain, and 
>> chill hours of a given time frame. 
>>
>> Or do I just have to read the database directly?
>>
>>
>>
>> On Thu, Jan 20, 2022, 19:15 Tom Keffer  wrote:
>>
>>> On Thu, Jan 20, 2022 at 4:01 PM Seth Ratner  wrote:
>>>
 Would you add the step from the xType guide of adding chillHours to 
 [StdWXCalculate] [[Calculations]]? Or would the "synthetic type" concept 
 mean it only exists when it is called on.

 As I understand it, adding it to [StdWXCalculate] [[Calculations]] 
 would add chillHours to the loop, but it would not be in the archive 
 unless 
 I also added a column for it with the same type name.

>>>
>>> It doesn't hurt to add to StdWXCalculate, but it's really only 
>>> necessary if you want to add the results to the database.  And, yes, it 
>>> will only get added to the database if there's a matching column in the 
>>> schema.
>>>

 So on my Belchertown skin, where I want total Chill Hours from Oct - 
 May displayed, if I add it to the archive WeeWX will use the database to 
 calculate the total (just adding them together), whereas if I don't add it 
 to the archive, WeeWX will have to run the (if outTemp < 45 then 
 chillHours 
 = archive_interval) for every archive row in that timespan, then sum that?

>>>
>>> Maybe. For the ImageGenerator that comes with WeeWX, if a type is not 
>>> available in the database, it will try to calculate it "on the fly" using 
>>> xtypes. However, I have no idea what the Belchertown skin does. I kind of 
>>> doubt it leverages xtypes.
>>> -tk
>>>
>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "weewx-user" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/weewx-user/7ysYvSUMOOo/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/CAPq0zEAdDBGTow7i55XfnGPzncQjdmiH%2BSk%3DL9_ZoE85QXKO%3Dw%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>>
> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>>
> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/CAHTssjOF_Q65XveoboAwRV%2Br5-oNb8curD7LZTTmuD7Y0-EAjQ%40mail.gmail.com
>>  
>> 
>> .
>>
>

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

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

[paul.ba...@gmail.com]

Hello,
I did a little experience using LOWESS (also called  LOESS in some places) 
with success I think. In my experience it is the best method I tried over 
the years.
This non parametric local smoothing exists for many lingages including 
Fortran (which I used...), C, Python, R etc.
It use three parameters: a smoothing factor, adjusted between 0 and 1. You 
have to experiment to find the best according to your problem. In my case 
.03 was good.. the second is the number of iterations, 1 to...; I adopted 
2, the doc says any larger number will not change antthing; the last one is 
a speed-up factor; I choose 0 (= No Speed-Up). With 3639 data points, the 
processing time is barely seen (10 years old Intel i3770 processor). 

The upper pannel represent the original data in blue and the smoothed one 
on red.
The lower pannel represent the difference between the original data and the 
smoothed one.
The time (T) is given in days, starting at 0:00:00 UTC on January 15th. The 
last point is at 24:00:00 on January 18th.
The vertical axis is in mbar. My altitude is 410 meters.

The first and second pulses are very clearely visible. There are a few 
other signals needing interpretation...  Also noticable is the smoother 
signal before the first spike compared to the rest of the data.
Have a nice week-end, Paul
Le Friday, January 21, 2022 à 4:38:59 PM UTC+1, bgra...@umw.edu a écrit :

> Thanks all, bad copy of weewx.sdb. All is well.
>
> On Thursday, January 20, 2022 at 5:25:50 PM UTC-5 morr...@gmail.com wrote:
>
>> It looks like you retrieved no data. It calculated decent looking arrival 
>> times, so no problem with the change you made?
>>
>> Try just a query for data spanning the first arrival. From a shell prompt:
>>
>> sqlite3 weewx.sdb "select datetime, barometer from archive where datetime 
>> > 1642258360-10 and datetime < 1642258360+10 order by dateTime;"
>>
>>
>> On Thursday, January 20, 2022 at 1:29:36 p.m. UTC-4 bgra...@umw.edu 
>> wrote:
>>
>>> I tried the code posted on github as well as the one by Cameron D. In 
>>> both cases I got the following error:
>>> ```
>>> root@n4mrv:/home/bg/weewx_tonga_browse-main# python3 ./tonga.py   [file 
>>> from Cameron D]
>>>
>>> distance to eruption 12056.6 km arrival at 1642258360 (2022-01-15 
>>> 09:52:39)
>>>   opposite pulse arrival at 1642308921 (2022-01-15 23:55:21)
>>>   second time around pulse arrival at 1642385471 (2022-01-16 
>>> 21:11:10)
>>> Traceback (most recent call last):
>>>   File "./tonga.py", line 178, in 
>>> plot_burst( cursor, arrival_time, hour_span, "primary" )
>>>   File "./tonga.py", line 54, in plot_burst
>>> coeff = np.polyfit(xdata, ydata, background_order )
>>>   File "<__array_function__ internals>", line 180, in polyfit
>>>   File "/usr/local/lib/python3.8/dist-packages/numpy/lib/polynomial.py", 
>>> line 638, in polyfit
>>> raise TypeError("expected non-empty vector for x")
>>> TypeError: expected non-empty vector for x
>>> ```
>>> I added my lat/lon information but may have missed something else I need 
>>> to change. Python modules were installed as directed. Copy of weewx.sdb is 
>>> in the same directory as the program.
>>> Thanks.
>>> Bob
>>> On Wednesday, January 19, 2022 at 10:32:49 AM UTC-5 morr...@gmail.com 
>>> wrote:
>>>
 On Wednesday, January 19, 2022 at 12:42:04 a.m. UTC-4 Cameron D wrote:

>
>- as you get closer to the equator, tidal changes dominate the 
>baseline in that timescale - I tried higher order polynomials, but 
> they are 
>next to useless.
>
> I also had little luck with higher order polynomials to remove the 
 general trend.

 I've put the script here: 
 https://github.com/morrowwm/weewx_tonga_browse

>>>

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


Tonga-1.pdf
Description: Adobe PDF document

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

[bgra...@umw.edu]

Thanks all, bad copy of weewx.sdb. All is well.

On Thursday, January 20, 2022 at 5:25:50 PM UTC-5 morr...@gmail.com wrote:

> It looks like you retrieved no data. It calculated decent looking arrival 
> times, so no problem with the change you made?
>
> Try just a query for data spanning the first arrival. From a shell prompt:
>
> sqlite3 weewx.sdb "select datetime, barometer from archive where datetime 
> > 1642258360-10 and datetime < 1642258360+10 order by dateTime;"
>
>
> On Thursday, January 20, 2022 at 1:29:36 p.m. UTC-4 bgra...@umw.edu wrote:
>
>> I tried the code posted on github as well as the one by Cameron D. In 
>> both cases I got the following error:
>> ```
>> root@n4mrv:/home/bg/weewx_tonga_browse-main# python3 ./tonga.py   [file 
>> from Cameron D]
>>
>> distance to eruption 12056.6 km arrival at 1642258360 (2022-01-15 
>> 09:52:39)
>>   opposite pulse arrival at 1642308921 (2022-01-15 23:55:21)
>>   second time around pulse arrival at 1642385471 (2022-01-16 21:11:10)
>> Traceback (most recent call last):
>>   File "./tonga.py", line 178, in 
>> plot_burst( cursor, arrival_time, hour_span, "primary" )
>>   File "./tonga.py", line 54, in plot_burst
>> coeff = np.polyfit(xdata, ydata, background_order )
>>   File "<__array_function__ internals>", line 180, in polyfit
>>   File "/usr/local/lib/python3.8/dist-packages/numpy/lib/polynomial.py", 
>> line 638, in polyfit
>> raise TypeError("expected non-empty vector for x")
>> TypeError: expected non-empty vector for x
>> ```
>> I added my lat/lon information but may have missed something else I need 
>> to change. Python modules were installed as directed. Copy of weewx.sdb is 
>> in the same directory as the program.
>> Thanks.
>> Bob
>> On Wednesday, January 19, 2022 at 10:32:49 AM UTC-5 morr...@gmail.com 
>> wrote:
>>
>>> On Wednesday, January 19, 2022 at 12:42:04 a.m. UTC-4 Cameron D wrote:
>>>

- as you get closer to the equator, tidal changes dominate the 
baseline in that timescale - I tried higher order polynomials, but they 
 are 
next to useless.

 I also had little luck with higher order polynomials to remove the 
>>> general trend.
>>>
>>> I've put the script here: https://github.com/morrowwm/weewx_tonga_browse
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/27166f36-0ac5-43aa-a41d-abd2afe267f3n%40googlegroups.com.

Re: [weewx-user] Skin with webcam?

[DaveStLou]

Turns out it was these two lines:
 mqtt_websockets_username = ""
 mqtt_websockets_password = ""

I do not need either of these and thought leaving them blank caused them to 
be ignored but found out I had to comment them out. All is well.

On Thursday, January 20, 2022 at 9:18:54 AM UTC-6 DaveStLou wrote:

> On Wednesday, January 19, 2022 at 8:21:31 PM UTC-6 vince wrote:
>  
>
>> Not without seeing your logs.
>>  
>>
> When you say 'roll back' did you uninstall/reinstall, or restore a backup 
>> of the skins/Belchertown directory, or something else ?
>>
>  
> My weewx logs were normal. I turned on MQTT write success messages to 
> confirm the loop messages were being recorded. I rolled back by copying 
> weewx.conf and Belchertown folder files from backup.
>
> I'm going to try again and see if I can find anything else. My current 
> theory is that there may have been an issue with my webhost and CloudFlare. 
> I'm going to do further testing before I post logs.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/86d59ba5-1a38-4831-9c96-0795fabbc196n%40googlegroups.com.

Re: [weewx-user] Re: Weatherflow UDP driver, Tempest battery reports 'LOW'

[andy gavras]

i just wanted to say Thank You 'jhn.p...@gmail.com' for starting this 
thread and vince for getting it rolling.  I'm an aged 50+ closet nerd with 
great google skills and who learned  B.A.S.I.C  on an Atari...  

Here's what they said in the above messages in a way that worked for me.
Maybe next  i'll use TxBattery... instead of OutTempBattery, and maybe a 
pretty graph.
not sure how to implement that test for null... might look into that more 
as well.  

To show tempest voltage and current low battery mode in seasons skin...
in 'etc/weewx/skins/Seasons/sensors.inc' change the #def get_battery 
_status($x) definition to read as follows:

#def get_battery_status($x)
#set $y = "{:.2f}".format($x)
#if $x >= 2.455
OK - $y
#else
#if $x >= 2.41
LOW - Mode1 - $y
#else
#if $x >= 2.39
LOW - Mode2 - $y
#else
LOW - Mode3 - $y
#end if
#end if
#end if
#end def




On Friday, December 3, 2021 at 12:19:40 PM UTC-6 peterq...@gmail.com wrote:

> You might want do a test for null before doing a greater/less than 
> comparison to avoid the "TypeError: '>=' not supported between instances of 
> 'NoneType' and 'float'" errors. I suspect you'll get those errors if there 
> is no value for $x in your example. 
>
> This is off the top of my head and likely the wrong syntax:
> #if $x is not None and $x>= 2.41
>
>
> On Fri, Dec 3, 2021, 10:09 AM vince  wrote:
>
>> Well you WANTED accuracy, you're getting accuracy :-)
>>
>> I know you figured it out, but be forewarned that the Cheetah engine 
>> under the hood here is very finicky and debugging things when you have even 
>> the slightest typo can get very frustrating.   Definitely make small 
>> changes one at a time and keep your modifications in a version control 
>> system such as git.  You'll thank yourself later.
>>
>> Incidentally - Cheetah is a third-party thing weewx relies on, so it's 
>> not anything anybody here can fix.  It is what it is.  Sometimes you have 
>> to go with it.  It's powerful but yes it can make you a little crazy when 
>> it throws a fit.
>>
>> Hint for the future - go through the formatting examples 
>>  in the 
>> Customization guide.   It'll make how to tweak things more obvious.  In 
>> fact, you should at least scan the whole Customization guide 
>>  and the other large sets of 
>> info in the wiki  and the FAQ 
>> .
>>  
>> On Friday, December 3, 2021 at 12:43:40 AM UTC-8 jhn.p...@gmail.com 
>> wrote:
>>
>>> k.
>>>
>>>
>>> Battery OK - 2.62260003
>>>
>>> k, how do I format a float in this cheetah template language?  I mean, I 
>>> assume thats what sensor.inc is ?
>>>
>>> #if $x >= 2.455
>>> OK - *$x*
>>> #else
>>> #if $x >= 2.41
>>> LOW - mode 1 - *$x*
>>> #else
>>> #if $x >= 2.39
>>> LOW - mode 2 - *$x*
>>> #else
>>> LOW - mode 3 - *$x*
>>> #end if
>>> #end if
>>> #end if
>>>
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/fa850573-3052-4f98-bfa9-f3847dfd7c0cn%40googlegroups.com
>>  
>> 
>> .
>>
>

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