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

[Tom Keffer]

Early in this thread, we discussed how to change units in a plot.
Unfortunately, it wasn't possible --- you were pretty much stuck with
whatever unit the appropriate unit group uses. Issue #729
 was created to track a proposed
enhancement.

That has now been implemented by commit 77b00e5
,
due to appear in V4.8.

-tk

On Sat, Jan 22, 2022 at 6:58 AM Seth Ratner  wrote:

> Thankyouthankyouthankyou.
>
> I added a couple comments questions I wasn't sure on, but I'm going to
> throw it on my Pi and see how it works in the meantime.
>
> Disclaimer: I don't know the right way to use GitHub
>
> On Saturday, January 22, 2022 at 7:41:58 AM UTC-6 tke...@gmail.com wrote:
>
>> Take a look at the Pull Request I posted to your repository.
>>
>> On Fri, Jan 21, 2022 at 10:31 PM Seth Ratner  wrote:
>>
>>> [[[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+...@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
>>> 
>>> .
>>>
>> --
> 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/3d88704a-2c3b-4145-9f54-b3ed1c159edcn%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/CAPq0zEAw%2BLco9WkuG%2BJufGjGmmXRY20eQaEmTvQdBrNr2O7v2g%40mail.gmail.com.

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

[Seth Ratner]

Thankyouthankyouthankyou. 

I added a couple comments questions I wasn't sure on, but I'm going to 
throw it on my Pi and see how it works in the meantime.

Disclaimer: I don't know the right way to use GitHub

On Saturday, January 22, 2022 at 7:41:58 AM UTC-6 tke...@gmail.com wrote:

> Take a look at the Pull Request I posted to your repository.
>
> On Fri, Jan 21, 2022 at 10:31 PM Seth Ratner  wrote:
>
>> [[[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+...@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
>>  
>> 
>> .
>>
>

-- 
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/3d88704a-2c3b-4145-9f54-b3ed1c159edcn%40googlegroups.com.

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

[Tom Keffer]

Take a look at the Pull Request I posted to your repository.

On Fri, Jan 21, 2022 at 10:31 PM Seth Ratner  wrote:

> [[[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
> 
> .
>

-- 
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/CAPq0zEDu5BFF3EdcJA7%3DFRsT%2B-CSLn%3DmqZcEDLTJpjo2sdtP2w%40mail.gmail.com.

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: 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] 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] Re: Chill Hours Extension

[Tom Keffer]

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+unsubscr...@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+unsubscr...@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 
https://groups.google.com/d/msgid/weewx-user/CAPq0zEAF%3DmU%3D7EMaq9Tm7m3cFaUA%2Bvd1ZN6KG9%2BA11mDbwwnZA%40mail.gmail.com.

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

[Seth Ratner]

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+unsubscr...@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+unsubscr...@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.

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

[Tom Keffer]

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 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/CAPq0zEAdDBGTow7i55XfnGPzncQjdmiH%2BSk%3DL9_ZoE85QXKO%3Dw%40mail.gmail.com.

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

[Seth Ratner]

Ok, that's good to hear. I'll do it as an xType, it'll be good practice. 

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.

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?

On Thursday, January 20, 2022 at 5:41:31 PM UTC-6 tke...@gmail.com wrote:

> You can do it either way, but you mentioned putting a new type in the 
> database, and so I figured the method outlined above would be easier to 
> understand.
>
> The big advantage of xtypes is that they don't duplicate what's already in 
> the database, which is good database practice. Think of them as a 
> "synthetic type." 
>
> You don't always need a service to initialize an xtype. You just, somehow, 
> have to make sure the type gets registered. A service is a convenient way 
> to do that.
>
> Personally, I would do this via an xtype. When I see a new type that's a 
> synthesis of old types, I think "xtype". That's the way all the derived 
> types are done in WeeWX. 
>
> -tk
>
> On Thu, Jan 20, 2022 at 3:19 PM Seth Ratner  wrote:
>
>> Thanks, I'll put something together and see if it works. This is very 
>> similar to the service I had to create for wired rain buckets, at least in 
>> it's simplicity. 
>>
>> But I'm still not sure why one would use a service over an xType or vice 
>> versa. Especially since the xtype uses a service to initialize it... Why 
>> not use a service for all of it? The xtype for wind direction seems to be 
>> doing something similar. Look at the loop packet, if the wind is zero then 
>> "None" the direction, put it back in the loop, and done. I just want to 
>> make sure I'm doing things in line with how you set most of this up. 
>>
>> Or is the xType for when you don't want something in the archive? 
>> (confused)
>> On Thursday, January 20, 2022 at 4:25:41 PM UTC-6 tke...@gmail.com wrote:
>>
>>> I would bind to NEW_ARCHIVE_RECORD. I doubt the added resolution of 
>>> resolving chill hours to the minute adds any value. But, the bigger problem 
>>> is that there is no predictable "loop interval". By contrast, archive 
>>> records include a field 'interval', so you know exactly how many seconds 
>>> (or hours, see below) to add.
>>>
>>> Each archive record should include the amount of time the temperature 
>>> was below 45º. So, for a 5 minute archive interval, it would typically be 
>>> either zero or 300. Nothing in between.
>>>
>>> To get the number of chill seconds since the start of the year, you 
>>> would use $year.chillTime.sum. The ".sum" suffix will cause all of the 
>>> values to be summed, which is what you want. This is what we do for rain.
>>>
>>> To show a cumulative plot of chill time, you would use
>>>
>>> [[yearimages]]
>>> ...
>>> [[[yearchill]]]
>>> plot_type = bar
>>> chillTime
>>> aggregate_type = cumulative
>>> aggregate_interval = week
>>>
>>> One problem with this approach is that you will be plotting "chill 
>>> seconds," which is likely to be a very big number. While there is a way to 
>>> convert between units for tags like $year.chillTime, unfortunately there is 
>>> no way for plots (there should be!), so it is probably better to save 
>>> "chill time" in hours, or even days, thus avoiding the unit conversion.
>>>
>>> Created issue #729  for the 
>>> future.
>>>
>>> On Thu, Jan 20, 2022 at 8:06 AM Seth Ratner  
>>> wrote:
>>>
 Just so I know I'm on the right track, that service would bind to 
 New_loop_packet, pull the temp, and if below xx degrees (or whatever 
 formula) add the number of seconds equal to the loop interval to the 
 chillHours type, which I would have previously added to the archive with 
 weedb. Yeah? Where would I set the chillHours type to be cumulative (like 
 rain) for the archive entries instead of Max or Average?


 Also, is there an interface for other programs to request data from 
 WeeWx? Let's say I wanted my irrigation software to get the total rain or 
 ET for a certain time period, could I do that by querying WeeWX or should 
 I 
 just access the WeeWX database?

 On Wed, Jan 19, 2022, 15:09 Tom Keffer  wrote:

> If you want to add the type to the main archive table, then go for it. 
> That is way less risky. In fact, as I 

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

[Tom Keffer]

You can do it either way, but you mentioned putting a new type in the
database, and so I figured the method outlined above would be easier to
understand.

The big advantage of xtypes is that they don't duplicate what's already in
the database, which is good database practice. Think of them as a
"synthetic type."

You don't always need a service to initialize an xtype. You just, somehow,
have to make sure the type gets registered. A service is a convenient way
to do that.

Personally, I would do this via an xtype. When I see a new type that's a
synthesis of old types, I think "xtype". That's the way all the derived
types are done in WeeWX.

-tk

On Thu, Jan 20, 2022 at 3:19 PM Seth Ratner  wrote:

> Thanks, I'll put something together and see if it works. This is very
> similar to the service I had to create for wired rain buckets, at least in
> it's simplicity.
>
> But I'm still not sure why one would use a service over an xType or vice
> versa. Especially since the xtype uses a service to initialize it... Why
> not use a service for all of it? The xtype for wind direction seems to be
> doing something similar. Look at the loop packet, if the wind is zero then
> "None" the direction, put it back in the loop, and done. I just want to
> make sure I'm doing things in line with how you set most of this up.
>
> Or is the xType for when you don't want something in the archive?
> (confused)
> On Thursday, January 20, 2022 at 4:25:41 PM UTC-6 tke...@gmail.com wrote:
>
>> I would bind to NEW_ARCHIVE_RECORD. I doubt the added resolution of
>> resolving chill hours to the minute adds any value. But, the bigger problem
>> is that there is no predictable "loop interval". By contrast, archive
>> records include a field 'interval', so you know exactly how many seconds
>> (or hours, see below) to add.
>>
>> Each archive record should include the amount of time the temperature was
>> below 45º. So, for a 5 minute archive interval, it would typically be
>> either zero or 300. Nothing in between.
>>
>> To get the number of chill seconds since the start of the year, you would
>> use $year.chillTime.sum. The ".sum" suffix will cause all of the values to
>> be summed, which is what you want. This is what we do for rain.
>>
>> To show a cumulative plot of chill time, you would use
>>
>> [[yearimages]]
>> ...
>> [[[yearchill]]]
>> plot_type = bar
>> chillTime
>> aggregate_type = cumulative
>> aggregate_interval = week
>>
>> One problem with this approach is that you will be plotting "chill
>> seconds," which is likely to be a very big number. While there is a way to
>> convert between units for tags like $year.chillTime, unfortunately there is
>> no way for plots (there should be!), so it is probably better to save
>> "chill time" in hours, or even days, thus avoiding the unit conversion.
>>
>> Created issue #729  for the
>> future.
>>
>> On Thu, Jan 20, 2022 at 8:06 AM Seth Ratner  wrote:
>>
>>> Just so I know I'm on the right track, that service would bind to
>>> New_loop_packet, pull the temp, and if below xx degrees (or whatever
>>> formula) add the number of seconds equal to the loop interval to the
>>> chillHours type, which I would have previously added to the archive with
>>> weedb. Yeah? Where would I set the chillHours type to be cumulative (like
>>> rain) for the archive entries instead of Max or Average?
>>>
>>>
>>> Also, is there an interface for other programs to request data from
>>> WeeWx? Let's say I wanted my irrigation software to get the total rain or
>>> ET for a certain time period, could I do that by querying WeeWX or should I
>>> just access the WeeWX database?
>>>
>>> On Wed, Jan 19, 2022, 15:09 Tom Keffer  wrote:
>>>
 If you want to add the type to the main archive table, then go for it.
 That is way less risky. In fact, as I recall, Gary R used a similar
 strategy for calculating temperature extremes at night and during the day.
 He created a new field outTempDay that held the temperature during the day,
 and None for night. Similar, but opposite, for outTempNight. That way, he
 could easily calculate the hottest night temperature.

 You could do something similar by creating a field chillHours that
 would hold the number of seconds the temperature was below 45ºF during that
 archive interval. Then, once the daily summaries have done their magic, the
 field 'sum' in the daily summaries would hold the total number of seconds
 since midnight that the temperature was below 45.

 No need to modify the summaries, and no xtype necessary. Just a new
 service that calculates chillHours for the current record. Simple.

 -tk


 On Wed, Jan 19, 2022 at 1:57 PM Seth Ratner  wrote:

> Yeah, That's what it looks like
>
> For something simple it will work perfectly. If a make an xtype for
> 

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

[Seth Ratner]

Thanks, I'll put something together and see if it works. This is very 
similar to the service I had to create for wired rain buckets, at least in 
it's simplicity. 

But I'm still not sure why one would use a service over an xType or vice 
versa. Especially since the xtype uses a service to initialize it... Why 
not use a service for all of it? The xtype for wind direction seems to be 
doing something similar. Look at the loop packet, if the wind is zero then 
"None" the direction, put it back in the loop, and done. I just want to 
make sure I'm doing things in line with how you set most of this up. 

Or is the xType for when you don't want something in the archive? (confused)
On Thursday, January 20, 2022 at 4:25:41 PM UTC-6 tke...@gmail.com wrote:

> I would bind to NEW_ARCHIVE_RECORD. I doubt the added resolution of 
> resolving chill hours to the minute adds any value. But, the bigger problem 
> is that there is no predictable "loop interval". By contrast, archive 
> records include a field 'interval', so you know exactly how many seconds 
> (or hours, see below) to add.
>
> Each archive record should include the amount of time the temperature was 
> below 45º. So, for a 5 minute archive interval, it would typically be 
> either zero or 300. Nothing in between.
>
> To get the number of chill seconds since the start of the year, you would 
> use $year.chillTime.sum. The ".sum" suffix will cause all of the values to 
> be summed, which is what you want. This is what we do for rain.
>
> To show a cumulative plot of chill time, you would use
>
> [[yearimages]]
> ...
> [[[yearchill]]]
> plot_type = bar
> chillTime
> aggregate_type = cumulative
> aggregate_interval = week
>
> One problem with this approach is that you will be plotting "chill 
> seconds," which is likely to be a very big number. While there is a way to 
> convert between units for tags like $year.chillTime, unfortunately there is 
> no way for plots (there should be!), so it is probably better to save 
> "chill time" in hours, or even days, thus avoiding the unit conversion.
>
> Created issue #729  for the 
> future.
>
> On Thu, Jan 20, 2022 at 8:06 AM Seth Ratner  wrote:
>
>> Just so I know I'm on the right track, that service would bind to 
>> New_loop_packet, pull the temp, and if below xx degrees (or whatever 
>> formula) add the number of seconds equal to the loop interval to the 
>> chillHours type, which I would have previously added to the archive with 
>> weedb. Yeah? Where would I set the chillHours type to be cumulative (like 
>> rain) for the archive entries instead of Max or Average?
>>
>>
>> Also, is there an interface for other programs to request data from 
>> WeeWx? Let's say I wanted my irrigation software to get the total rain or 
>> ET for a certain time period, could I do that by querying WeeWX or should I 
>> just access the WeeWX database?
>>
>> On Wed, Jan 19, 2022, 15:09 Tom Keffer  wrote:
>>
>>> If you want to add the type to the main archive table, then go for it. 
>>> That is way less risky. In fact, as I recall, Gary R used a similar 
>>> strategy for calculating temperature extremes at night and during the day. 
>>> He created a new field outTempDay that held the temperature during the day, 
>>> and None for night. Similar, but opposite, for outTempNight. That way, he 
>>> could easily calculate the hottest night temperature.
>>>
>>> You could do something similar by creating a field chillHours that would 
>>> hold the number of seconds the temperature was below 45ºF during that 
>>> archive interval. Then, once the daily summaries have done their magic, the 
>>> field 'sum' in the daily summaries would hold the total number of seconds 
>>> since midnight that the temperature was below 45. 
>>>
>>> No need to modify the summaries, and no xtype necessary. Just a new 
>>> service that calculates chillHours for the current record. Simple.
>>>
>>> -tk
>>>
>>>
>>> On Wed, Jan 19, 2022 at 1:57 PM Seth Ratner  wrote:
>>>
 Yeah, That's what it looks like

 For something simple it will work perfectly. If a make an xtype for 
 chillHours that works like the ET type, except use either the Utah model (
 https://practicalprimate.com/chill-hours/) or just < 45F to calculate 
 the number of chill_seconds and put it into the archive, and the daily 
 summary will populate the sum/wsum which will allow for easy calculation 
 of 
 cumulative chill hours, average chill hours, etc. 

 Part of the problem I'm having is conceptualizing how types work 
 *without* being in the archive. I'm writing a program that will 
 automatically monitor and manage a small orchard, to include modifying 
 watering routines based on things like ET, ripening windows, and rain 
 received. This is the entire reason I set up a WeeWX station in the 
 orchard, for the 

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

[Tom Keffer]

I would bind to NEW_ARCHIVE_RECORD. I doubt the added resolution of
resolving chill hours to the minute adds any value. But, the bigger problem
is that there is no predictable "loop interval". By contrast, archive
records include a field 'interval', so you know exactly how many seconds
(or hours, see below) to add.

Each archive record should include the amount of time the temperature was
below 45º. So, for a 5 minute archive interval, it would typically be
either zero or 300. Nothing in between.

To get the number of chill seconds since the start of the year, you would
use $year.chillTime.sum. The ".sum" suffix will cause all of the values to
be summed, which is what you want. This is what we do for rain.

To show a cumulative plot of chill time, you would use

[[yearimages]]
...
[[[yearchill]]]
plot_type = bar
chillTime
aggregate_type = cumulative
aggregate_interval = week

One problem with this approach is that you will be plotting "chill
seconds," which is likely to be a very big number. While there is a way to
convert between units for tags like $year.chillTime, unfortunately there is
no way for plots (there should be!), so it is probably better to save
"chill time" in hours, or even days, thus avoiding the unit conversion.

Created issue #729  for the
future.

On Thu, Jan 20, 2022 at 8:06 AM Seth Ratner  wrote:

> Just so I know I'm on the right track, that service would bind to
> New_loop_packet, pull the temp, and if below xx degrees (or whatever
> formula) add the number of seconds equal to the loop interval to the
> chillHours type, which I would have previously added to the archive with
> weedb. Yeah? Where would I set the chillHours type to be cumulative (like
> rain) for the archive entries instead of Max or Average?
>
>
> Also, is there an interface for other programs to request data from WeeWx?
> Let's say I wanted my irrigation software to get the total rain or ET for a
> certain time period, could I do that by querying WeeWX or should I just
> access the WeeWX database?
>
> On Wed, Jan 19, 2022, 15:09 Tom Keffer  wrote:
>
>> If you want to add the type to the main archive table, then go for it.
>> That is way less risky. In fact, as I recall, Gary R used a similar
>> strategy for calculating temperature extremes at night and during the day.
>> He created a new field outTempDay that held the temperature during the day,
>> and None for night. Similar, but opposite, for outTempNight. That way, he
>> could easily calculate the hottest night temperature.
>>
>> You could do something similar by creating a field chillHours that would
>> hold the number of seconds the temperature was below 45ºF during that
>> archive interval. Then, once the daily summaries have done their magic, the
>> field 'sum' in the daily summaries would hold the total number of seconds
>> since midnight that the temperature was below 45.
>>
>> No need to modify the summaries, and no xtype necessary. Just a new
>> service that calculates chillHours for the current record. Simple.
>>
>> -tk
>>
>>
>> On Wed, Jan 19, 2022 at 1:57 PM Seth Ratner  wrote:
>>
>>> Yeah, That's what it looks like
>>>
>>> For something simple it will work perfectly. If a make an xtype for
>>> chillHours that works like the ET type, except use either the Utah model (
>>> https://practicalprimate.com/chill-hours/) or just < 45F to calculate
>>> the number of chill_seconds and put it into the archive, and the daily
>>> summary will populate the sum/wsum which will allow for easy calculation of
>>> cumulative chill hours, average chill hours, etc.
>>>
>>> Part of the problem I'm having is conceptualizing how types work
>>> *without* being in the archive. I'm writing a program that will
>>> automatically monitor and manage a small orchard, to include modifying
>>> watering routines based on things like ET, ripening windows, and rain
>>> received. This is the entire reason I set up a WeeWX station in the
>>> orchard, for the incredible database.
>>>
>>> If my chill hours xtype is in the archive (or daily_summary) then
>>> accessing the db data from my irrigation program seems trivial.   I unsure
>>> if there's a way for an outside program to query WeeWX (as opposed to going
>>> directly to the database). If there is, that could be a way to use an xtype
>>> that isn't in the archive. It would also allow for more dynamic creation of
>>> similar types. For example, if you decided you wanted to change the
>>> definition of chill hours to <40F then you would only have to adjust the
>>> formula used in the xType, since nothing is stored in the db. Future
>>> queries to WeeWX from the irrigation program would immediately apply the
>>> new formula periods before the change.
>>>
>>> I was also trying to think of a way to allow for multiple
>>> chillHours-style calculations without adding a new xtype for each
>>> calculation, but I don't 

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

[Seth Ratner]

On second thought, it looks like ET does not attach to the loop, only to
the archive. That seems more appropriate for chillHours.

I guess what I'm wondering now is why would ET be an xtype and chillHours
only be a service? What's the distinction that I'm missing?

Thanks for the help, as always!

On Wed, Jan 19, 2022, 15:09 Tom Keffer  wrote:

> If you want to add the type to the main archive table, then go for it.
> That is way less risky. In fact, as I recall, Gary R used a similar
> strategy for calculating temperature extremes at night and during the day.
> He created a new field outTempDay that held the temperature during the day,
> and None for night. Similar, but opposite, for outTempNight. That way, he
> could easily calculate the hottest night temperature.
>
> You could do something similar by creating a field chillHours that would
> hold the number of seconds the temperature was below 45ºF during that
> archive interval. Then, once the daily summaries have done their magic, the
> field 'sum' in the daily summaries would hold the total number of seconds
> since midnight that the temperature was below 45.
>
> No need to modify the summaries, and no xtype necessary. Just a new
> service that calculates chillHours for the current record. Simple.
>
> -tk
>
>
> On Wed, Jan 19, 2022 at 1:57 PM Seth Ratner  wrote:
>
>> Yeah, That's what it looks like
>>
>> For something simple it will work perfectly. If a make an xtype for
>> chillHours that works like the ET type, except use either the Utah model (
>> https://practicalprimate.com/chill-hours/) or just < 45F to calculate
>> the number of chill_seconds and put it into the archive, and the daily
>> summary will populate the sum/wsum which will allow for easy calculation of
>> cumulative chill hours, average chill hours, etc.
>>
>> Part of the problem I'm having is conceptualizing how types work
>> *without* being in the archive. I'm writing a program that will
>> automatically monitor and manage a small orchard, to include modifying
>> watering routines based on things like ET, ripening windows, and rain
>> received. This is the entire reason I set up a WeeWX station in the
>> orchard, for the incredible database.
>>
>> If my chill hours xtype is in the archive (or daily_summary) then
>> accessing the db data from my irrigation program seems trivial.   I unsure
>> if there's a way for an outside program to query WeeWX (as opposed to going
>> directly to the database). If there is, that could be a way to use an xtype
>> that isn't in the archive. It would also allow for more dynamic creation of
>> similar types. For example, if you decided you wanted to change the
>> definition of chill hours to <40F then you would only have to adjust the
>> formula used in the xType, since nothing is stored in the db. Future
>> queries to WeeWX from the irrigation program would immediately apply the
>> new formula periods before the change.
>>
>> I was also trying to think of a way to allow for multiple
>> chillHours-style calculations without adding a new xtype for each
>> calculation, but I don't think there's a way to do that smartly. And
>> besides, I suppose what's a few more columns in a table with 100+ different
>> observation types?
>>
>> Also, do I understand the code correctly that DaySummaryManager takes
>> care of both adding archive entries as well as updating the Daily Summary
>> tables?
>>
>> Thank you for helping a plodding hobbyist!
>> Seth
>> On Wednesday, January 19, 2022 at 2:21:03 PM UTC-6 tke...@gmail.com
>> wrote:
>>
>>> "Premature optimization is the root of all evil."
>>>
>>> Your proposal sounds complicated and incompatible with the existing
>>> daily summaries. You would have to replicate a lot of what it already does.
>>>
>>> Make it work first, then worry about making it fast. You don't know yet
>>> whether the calculation will take a long time.
>>>
>>>
>>>
>>> On Wed, Jan 19, 2022 at 9:38 AM Seth Ratner  wrote:
>>>
 Your Phenology extension is actually what got me thinking about how to
 implement the chilling hours in a more generic way, such that more than one
 metric (or one set of temperature thresholds) can be used.

 The "simplest" way that came to mind was using some sort of modified
 Daily Summary table in the database. I haven't yet figured out how WeeWX
 populates those tables, but if the columns and calculation methods are
 customizable, then the daily (or nightly) data could be compiled at the end
 of the day and loaded into the table. That way every time you want to
 display the information, it's just a straight query from that summary
 table, rather than running the calculations every time for every archive
 entry. This also allows for multiple calculation methods, all stored in the
 summary table.

 So as an example, at the end of the day, whenever WeeWX normally
 populates the summary tables, this new extension could run multiple
 algorithms (one for basic 

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

[Seth Ratner]

Just so I know I'm on the right track, that service would bind to
New_loop_packet, pull the temp, and if below xx degrees (or whatever
formula) add the number of seconds equal to the loop interval to the
chillHours type, which I would have previously added to the archive with
weedb. Yeah? Where would I set the chillHours type to be cumulative (like
rain) for the archive entries instead of Max or Average?


Also, is there an interface for other programs to request data from WeeWx?
Let's say I wanted my irrigation software to get the total rain or ET for a
certain time period, could I do that by querying WeeWX or should I just
access the WeeWX database?

On Wed, Jan 19, 2022, 15:09 Tom Keffer  wrote:

> If you want to add the type to the main archive table, then go for it.
> That is way less risky. In fact, as I recall, Gary R used a similar
> strategy for calculating temperature extremes at night and during the day.
> He created a new field outTempDay that held the temperature during the day,
> and None for night. Similar, but opposite, for outTempNight. That way, he
> could easily calculate the hottest night temperature.
>
> You could do something similar by creating a field chillHours that would
> hold the number of seconds the temperature was below 45ºF during that
> archive interval. Then, once the daily summaries have done their magic, the
> field 'sum' in the daily summaries would hold the total number of seconds
> since midnight that the temperature was below 45.
>
> No need to modify the summaries, and no xtype necessary. Just a new
> service that calculates chillHours for the current record. Simple.
>
> -tk
>
>
> On Wed, Jan 19, 2022 at 1:57 PM Seth Ratner  wrote:
>
>> Yeah, That's what it looks like
>>
>> For something simple it will work perfectly. If a make an xtype for
>> chillHours that works like the ET type, except use either the Utah model (
>> https://practicalprimate.com/chill-hours/) or just < 45F to calculate
>> the number of chill_seconds and put it into the archive, and the daily
>> summary will populate the sum/wsum which will allow for easy calculation of
>> cumulative chill hours, average chill hours, etc.
>>
>> Part of the problem I'm having is conceptualizing how types work
>> *without* being in the archive. I'm writing a program that will
>> automatically monitor and manage a small orchard, to include modifying
>> watering routines based on things like ET, ripening windows, and rain
>> received. This is the entire reason I set up a WeeWX station in the
>> orchard, for the incredible database.
>>
>> If my chill hours xtype is in the archive (or daily_summary) then
>> accessing the db data from my irrigation program seems trivial.   I unsure
>> if there's a way for an outside program to query WeeWX (as opposed to going
>> directly to the database). If there is, that could be a way to use an xtype
>> that isn't in the archive. It would also allow for more dynamic creation of
>> similar types. For example, if you decided you wanted to change the
>> definition of chill hours to <40F then you would only have to adjust the
>> formula used in the xType, since nothing is stored in the db. Future
>> queries to WeeWX from the irrigation program would immediately apply the
>> new formula periods before the change.
>>
>> I was also trying to think of a way to allow for multiple
>> chillHours-style calculations without adding a new xtype for each
>> calculation, but I don't think there's a way to do that smartly. And
>> besides, I suppose what's a few more columns in a table with 100+ different
>> observation types?
>>
>> Also, do I understand the code correctly that DaySummaryManager takes
>> care of both adding archive entries as well as updating the Daily Summary
>> tables?
>>
>> Thank you for helping a plodding hobbyist!
>> Seth
>> On Wednesday, January 19, 2022 at 2:21:03 PM UTC-6 tke...@gmail.com
>> wrote:
>>
>>> "Premature optimization is the root of all evil."
>>>
>>> Your proposal sounds complicated and incompatible with the existing
>>> daily summaries. You would have to replicate a lot of what it already does.
>>>
>>> Make it work first, then worry about making it fast. You don't know yet
>>> whether the calculation will take a long time.
>>>
>>>
>>>
>>> On Wed, Jan 19, 2022 at 9:38 AM Seth Ratner  wrote:
>>>
 Your Phenology extension is actually what got me thinking about how to
 implement the chilling hours in a more generic way, such that more than one
 metric (or one set of temperature thresholds) can be used.

 The "simplest" way that came to mind was using some sort of modified
 Daily Summary table in the database. I haven't yet figured out how WeeWX
 populates those tables, but if the columns and calculation methods are
 customizable, then the daily (or nightly) data could be compiled at the end
 of the day and loaded into the table. That way every time you want to
 display the information, it's just a straight query from that summary

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

[Tom Keffer]

If you want to add the type to the main archive table, then go for it. That
is way less risky. In fact, as I recall, Gary R used a similar strategy for
calculating temperature extremes at night and during the day. He created a
new field outTempDay that held the temperature during the day, and None for
night. Similar, but opposite, for outTempNight. That way, he could easily
calculate the hottest night temperature.

You could do something similar by creating a field chillHours that would
hold the number of seconds the temperature was below 45ºF during that
archive interval. Then, once the daily summaries have done their magic, the
field 'sum' in the daily summaries would hold the total number of seconds
since midnight that the temperature was below 45.

No need to modify the summaries, and no xtype necessary. Just a new service
that calculates chillHours for the current record. Simple.

-tk


On Wed, Jan 19, 2022 at 1:57 PM Seth Ratner  wrote:

> Yeah, That's what it looks like
>
> For something simple it will work perfectly. If a make an xtype for
> chillHours that works like the ET type, except use either the Utah model (
> https://practicalprimate.com/chill-hours/) or just < 45F to calculate the
> number of chill_seconds and put it into the archive, and the daily summary
> will populate the sum/wsum which will allow for easy calculation of
> cumulative chill hours, average chill hours, etc.
>
> Part of the problem I'm having is conceptualizing how types work *without* 
> being
> in the archive. I'm writing a program that will automatically monitor and
> manage a small orchard, to include modifying watering routines based on
> things like ET, ripening windows, and rain received. This is the entire
> reason I set up a WeeWX station in the orchard, for the incredible database.
>
> If my chill hours xtype is in the archive (or daily_summary) then
> accessing the db data from my irrigation program seems trivial.   I unsure
> if there's a way for an outside program to query WeeWX (as opposed to going
> directly to the database). If there is, that could be a way to use an xtype
> that isn't in the archive. It would also allow for more dynamic creation of
> similar types. For example, if you decided you wanted to change the
> definition of chill hours to <40F then you would only have to adjust the
> formula used in the xType, since nothing is stored in the db. Future
> queries to WeeWX from the irrigation program would immediately apply the
> new formula periods before the change.
>
> I was also trying to think of a way to allow for multiple chillHours-style
> calculations without adding a new xtype for each calculation, but I don't
> think there's a way to do that smartly. And besides, I suppose what's a few
> more columns in a table with 100+ different observation types?
>
> Also, do I understand the code correctly that DaySummaryManager takes
> care of both adding archive entries as well as updating the Daily Summary
> tables?
>
> Thank you for helping a plodding hobbyist!
> Seth
> On Wednesday, January 19, 2022 at 2:21:03 PM UTC-6 tke...@gmail.com wrote:
>
>> "Premature optimization is the root of all evil."
>>
>> Your proposal sounds complicated and incompatible with the existing daily
>> summaries. You would have to replicate a lot of what it already does.
>>
>> Make it work first, then worry about making it fast. You don't know yet
>> whether the calculation will take a long time.
>>
>>
>>
>> On Wed, Jan 19, 2022 at 9:38 AM Seth Ratner  wrote:
>>
>>> Your Phenology extension is actually what got me thinking about how to
>>> implement the chilling hours in a more generic way, such that more than one
>>> metric (or one set of temperature thresholds) can be used.
>>>
>>> The "simplest" way that came to mind was using some sort of modified
>>> Daily Summary table in the database. I haven't yet figured out how WeeWX
>>> populates those tables, but if the columns and calculation methods are
>>> customizable, then the daily (or nightly) data could be compiled at the end
>>> of the day and loaded into the table. That way every time you want to
>>> display the information, it's just a straight query from that summary
>>> table, rather than running the calculations every time for every archive
>>> entry. This also allows for multiple calculation methods, all stored in the
>>> summary table.
>>>
>>> So as an example, at the end of the day, whenever WeeWX normally
>>> populates the summary tables, this new extension could run multiple
>>> algorithms (one for basic chill hours, one for the Utah Model, one for the
>>> phenology table on your website, etc) and store the resultant value in the
>>> respective column (one for Utah, one for basic, one for phenology, etc) in
>>> the new daily summary row for this extension. No new specific types are
>>> required in the loop or archive packets, so the processing power is only
>>> required once per day. When the data is viewed, it is only pulling values
>>> from a table 

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

[Seth Ratner]

Yeah, That's what it looks like

For something simple it will work perfectly. If a make an xtype for 
chillHours that works like the ET type, except use either the Utah model 
(https://practicalprimate.com/chill-hours/) or just < 45F to calculate the 
number of chill_seconds and put it into the archive, and the daily summary 
will populate the sum/wsum which will allow for easy calculation of 
cumulative chill hours, average chill hours, etc. 

Part of the problem I'm having is conceptualizing how types work *without* 
being 
in the archive. I'm writing a program that will automatically monitor and 
manage a small orchard, to include modifying watering routines based on 
things like ET, ripening windows, and rain received. This is the entire 
reason I set up a WeeWX station in the orchard, for the incredible database.

If my chill hours xtype is in the archive (or daily_summary) then accessing 
the db data from my irrigation program seems trivial.   I unsure if there's 
a way for an outside program to query WeeWX (as opposed to going directly 
to the database). If there is, that could be a way to use an xtype that 
isn't in the archive. It would also allow for more dynamic creation of 
similar types. For example, if you decided you wanted to change the 
definition of chill hours to <40F then you would only have to adjust the 
formula used in the xType, since nothing is stored in the db. Future 
queries to WeeWX from the irrigation program would immediately apply the 
new formula periods before the change.

I was also trying to think of a way to allow for multiple chillHours-style 
calculations without adding a new xtype for each calculation, but I don't 
think there's a way to do that smartly. And besides, I suppose what's a few 
more columns in a table with 100+ different observation types?

Also, do I understand the code correctly that DaySummaryManager takes care 
of both adding archive entries as well as updating the Daily Summary tables?

Thank you for helping a plodding hobbyist!
Seth
On Wednesday, January 19, 2022 at 2:21:03 PM UTC-6 tke...@gmail.com wrote:

> "Premature optimization is the root of all evil."
>
> Your proposal sounds complicated and incompatible with the existing daily 
> summaries. You would have to replicate a lot of what it already does.
>
> Make it work first, then worry about making it fast. You don't know yet 
> whether the calculation will take a long time. 
>
>
>
> On Wed, Jan 19, 2022 at 9:38 AM Seth Ratner  wrote:
>
>> Your Phenology extension is actually what got me thinking about how to 
>> implement the chilling hours in a more generic way, such that more than one 
>> metric (or one set of temperature thresholds) can be used. 
>>
>> The "simplest" way that came to mind was using some sort of modified 
>> Daily Summary table in the database. I haven't yet figured out how WeeWX 
>> populates those tables, but if the columns and calculation methods are 
>> customizable, then the daily (or nightly) data could be compiled at the end 
>> of the day and loaded into the table. That way every time you want to 
>> display the information, it's just a straight query from that summary 
>> table, rather than running the calculations every time for every archive 
>> entry. This also allows for multiple calculation methods, all stored in the 
>> summary table. 
>>
>> So as an example, at the end of the day, whenever WeeWX normally 
>> populates the summary tables, this new extension could run multiple 
>> algorithms (one for basic chill hours, one for the Utah Model, one for the 
>> phenology table on your website, etc) and store the resultant value in the 
>> respective column (one for Utah, one for basic, one for phenology, etc) in 
>> the new daily summary row for this extension. No new specific types are 
>> required in the loop or archive packets, so the processing power is only 
>> required once per day. When the data is viewed, it is only pulling values 
>> from a table rather than doing the calculations each time.
>>
>> But I'm not sure such customizations to the daily-table-creation-process 
>> is possible. 
>>
>> Thoughts?
>>
>>
>>
>>
>>
>>
>> On Wednesday, January 19, 2022 at 9:20:30 AM UTC-6 charlescu...@gmail.com 
>> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE- 
>>> Hash: SHA1 
>>>
>>> On Tue, 18 Jan 2022 17:05:33 -0800 
>>> Tom Deffer  wrote: 
>>>
>>> > Upon reflection, the biggest difference seems to be that 
>>> > cooling-degree days are weighted by the temperature difference from 
>>> > the baseline. You just want the total number of hours. 
>>>
>>> > This is best done as an XTypes extension 
>>> > . 
>>>
>>> I've fooled around with XTypes for my Phenology extension. 
>>>
>>> * [weewx-phenology](HTTP://LacusVeris.com/Phenology) — Growing 
>>> Degree-Days development models for various insect pests, showing 
>>> when to apply control strategies to minimize crop damage. 
>>>
>>> The Growing Degree-Days calculation(s) are compute-intensive relative 
>>> to the 

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

[Tom Keffer]

"Premature optimization is the root of all evil."

Your proposal sounds complicated and incompatible with the existing daily
summaries. You would have to replicate a lot of what it already does.

Make it work first, then worry about making it fast. You don't know yet
whether the calculation will take a long time.



On Wed, Jan 19, 2022 at 9:38 AM Seth Ratner  wrote:

> Your Phenology extension is actually what got me thinking about how to
> implement the chilling hours in a more generic way, such that more than one
> metric (or one set of temperature thresholds) can be used.
>
> The "simplest" way that came to mind was using some sort of modified Daily
> Summary table in the database. I haven't yet figured out how WeeWX
> populates those tables, but if the columns and calculation methods are
> customizable, then the daily (or nightly) data could be compiled at the end
> of the day and loaded into the table. That way every time you want to
> display the information, it's just a straight query from that summary
> table, rather than running the calculations every time for every archive
> entry. This also allows for multiple calculation methods, all stored in the
> summary table.
>
> So as an example, at the end of the day, whenever WeeWX normally populates
> the summary tables, this new extension could run multiple algorithms (one
> for basic chill hours, one for the Utah Model, one for the phenology table
> on your website, etc) and store the resultant value in the respective
> column (one for Utah, one for basic, one for phenology, etc) in the new
> daily summary row for this extension. No new specific types are required in
> the loop or archive packets, so the processing power is only required once
> per day. When the data is viewed, it is only pulling values from a table
> rather than doing the calculations each time.
>
> But I'm not sure such customizations to the daily-table-creation-process
> is possible.
>
> Thoughts?
>
>
>
>
>
>
> On Wednesday, January 19, 2022 at 9:20:30 AM UTC-6 charlescu...@gmail.com
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On Tue, 18 Jan 2022 17:05:33 -0800
>> Tom Deffer  wrote:
>>
>> > Upon reflection, the biggest difference seems to be that
>> > cooling-degree days are weighted by the temperature difference from
>> > the baseline. You just want the total number of hours.
>>
>> > This is best done as an XTypes extension
>> > .
>>
>> I've fooled around with XTypes for my Phenology extension.
>>
>> * [weewx-phenology](HTTP://LacusVeris.com/Phenology) — Growing
>> Degree-Days development models for various insect pests, showing
>> when to apply control strategies to minimize crop damage.
>>
>> The Growing Degree-Days calculation(s) are compute-intensive relative
>> to the Cooling Degree-Days calculation. XTypes exposes three entry
>> points that return values: scalar, series, and aggregate. I implement
>> only the "series" entry point, and I keep a running tally of
>> cumulative Degree-Days. It seems that, if I had implemented
>> "aggregate," each cumulative step would have meant recalculating
>> previous steps at factorial cost, but that's just me.
>>
>> I agree the Chilling Hours calculations seem relatively simple, but
>> never let it be said that researchers in the Life Sciences can leave
>> any particularly elegant concept uncluttered. Here is a more or less
>> grammatical overview of various kinds of Chilling Hours calculations.
>> You may overlook the Climate Change hysteria at the end. The Utah
>> method obviously requires quite a few machine cycles, but matching the
>> Queensland method's curve might require quite a few more.
>>
>> * [Chill Hours and Fruit
>> Trees](https://practicalprimate.com/chill-hours/) — Many deciduous
>> fruit trees will not give you the fruit yields you want unless your
>> property receives adequate chill hours. But what are chill hours and
>> why are they so important?
>>
>> ... so both Chill Hours and Growing Degree-Days potentially challenge
>> WeeWX's data collection, calculation, reporting, and image generation
>> capabilities. I developed a kludge to handle Growing Degree-Days
>> because treating orchard insects and disease is a season-to-season
>> battle and many treatments depend on such calculations. I am not so
>> interested in Chill Hours because that has more to do with orchard
>> siting and choice of cultivars, which tend to be one-off decisions.
>> However, Chill Hours (in whatever manifestation) does keep coming up
>> here and on the other discussion group I frequent. Perhaps this is
>> due to ongoing Climate-Change concerns.
>>
>> * [Growing Fruit](https://growingfruit.org/search?q=chill%20hours)
>>
>> I wonder whether I have gone down the right chute with the Phenology
>> Extension's Growing Degree-Days calculation and imaging capacity.
>> Does adding Chill Hours call for a more general approach?
>>
>> I sadly fear the appetite for reporting Chill Hours does not
>> necessarily imply the desire or 

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

[Seth Ratner]

Your Phenology extension is actually what got me thinking about how to 
implement the chilling hours in a more generic way, such that more than one 
metric (or one set of temperature thresholds) can be used. 

The "simplest" way that came to mind was using some sort of modified Daily 
Summary table in the database. I haven't yet figured out how WeeWX 
populates those tables, but if the columns and calculation methods are 
customizable, then the daily (or nightly) data could be compiled at the end 
of the day and loaded into the table. That way every time you want to 
display the information, it's just a straight query from that summary 
table, rather than running the calculations every time for every archive 
entry. This also allows for multiple calculation methods, all stored in the 
summary table. 

So as an example, at the end of the day, whenever WeeWX normally populates 
the summary tables, this new extension could run multiple algorithms (one 
for basic chill hours, one for the Utah Model, one for the phenology table 
on your website, etc) and store the resultant value in the respective 
column (one for Utah, one for basic, one for phenology, etc) in the new 
daily summary row for this extension. No new specific types are required in 
the loop or archive packets, so the processing power is only required once 
per day. When the data is viewed, it is only pulling values from a table 
rather than doing the calculations each time.

But I'm not sure such customizations to the daily-table-creation-process is 
possible. 

Thoughts?






On Wednesday, January 19, 2022 at 9:20:30 AM UTC-6 charlescu...@gmail.com 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tue, 18 Jan 2022 17:05:33 -0800
> Tom Deffer  wrote:
>
> > Upon reflection, the biggest difference seems to be that
> > cooling-degree days are weighted by the temperature difference from
> > the baseline. You just want the total number of hours.
>
> > This is best done as an XTypes extension
> > .
>
> I've fooled around with XTypes for my Phenology extension.
>
> * [weewx-phenology](HTTP://LacusVeris.com/Phenology) — Growing
> Degree-Days development models for various insect pests, showing
> when to apply control strategies to minimize crop damage.
>
> The Growing Degree-Days calculation(s) are compute-intensive relative
> to the Cooling Degree-Days calculation. XTypes exposes three entry
> points that return values: scalar, series, and aggregate. I implement
> only the "series" entry point, and I keep a running tally of
> cumulative Degree-Days. It seems that, if I had implemented
> "aggregate," each cumulative step would have meant recalculating
> previous steps at factorial cost, but that's just me.
>
> I agree the Chilling Hours calculations seem relatively simple, but
> never let it be said that researchers in the Life Sciences can leave
> any particularly elegant concept uncluttered. Here is a more or less
> grammatical overview of various kinds of Chilling Hours calculations.
> You may overlook the Climate Change hysteria at the end. The Utah
> method obviously requires quite a few machine cycles, but matching the
> Queensland method's curve might require quite a few more.
>
> * [Chill Hours and Fruit
> Trees](https://practicalprimate.com/chill-hours/) — Many deciduous
> fruit trees will not give you the fruit yields you want unless your
> property receives adequate chill hours. But what are chill hours and
> why are they so important?
>
> ... so both Chill Hours and Growing Degree-Days potentially challenge
> WeeWX's data collection, calculation, reporting, and image generation
> capabilities. I developed a kludge to handle Growing Degree-Days
> because treating orchard insects and disease is a season-to-season
> battle and many treatments depend on such calculations. I am not so
> interested in Chill Hours because that has more to do with orchard
> siting and choice of cultivars, which tend to be one-off decisions.
> However, Chill Hours (in whatever manifestation) does keep coming up
> here and on the other discussion group I frequent. Perhaps this is
> due to ongoing Climate-Change concerns.
>
> * [Growing Fruit](https://growingfruit.org/search?q=chill%20hours)
>
> I wonder whether I have gone down the right chute with the Phenology
> Extension's Growing Degree-Days calculation and imaging capacity.
> Does adding Chill Hours call for a more general approach?
>
> I sadly fear the appetite for reporting Chill Hours does not
> necessarily imply the desire or ability to configure WeeWX to do the
> appropriate calculations or interpret the results. These are not
> straightforward things.
>
> - -- 
> .. Be Seeing You,
> .. Chuck Rhode, Sheboygan, WI, USA
> .. Weather: http://LacusVeris.com/WX
> .. 15° — Wind WNW 22 mph — Sky mostly clear.
>
> -BEGIN PGP SIGNATURE-
>
> iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCYegsMQAKCRBg2/xipKOW
> UuoSAJ4kvvWrCWqDkEZ8tl2yDzAPXU3LnQCeO5z01CamBSnFAr677iJNzwgf15U=
> =aptL
> -END PGP 

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

[Chuck Rhode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 18 Jan 2022 17:05:33 -0800
Tom Deffer  wrote:

> Upon reflection, the biggest difference seems to be that
> cooling-degree days are weighted by the temperature difference from
> the baseline. You just want the total number of hours.

> This is best done as an XTypes extension
> .

I've fooled around with XTypes for my Phenology extension.

* [weewx-phenology](HTTP://LacusVeris.com/Phenology) — Growing
  Degree-Days development models for various insect pests, showing
  when to apply control strategies to minimize crop damage.

The Growing Degree-Days calculation(s) are compute-intensive relative
to the Cooling Degree-Days calculation.  XTypes exposes three entry
points that return values: scalar, series, and aggregate.  I implement
only the "series" entry point, and I keep a running tally of
cumulative Degree-Days.  It seems that, if I had implemented
"aggregate," each cumulative step would have meant recalculating
previous steps at factorial cost, but that's just me.

I agree the Chilling Hours calculations seem relatively simple, but
never let it be said that researchers in the Life Sciences can leave
any particularly elegant concept uncluttered.  Here is a more or less
grammatical overview of various kinds of Chilling Hours calculations.
You may overlook the Climate Change hysteria at the end.  The Utah
method obviously requires quite a few machine cycles, but matching the
Queensland method's curve might require quite a few more.

* [Chill Hours and Fruit
  Trees](https://practicalprimate.com/chill-hours/) — Many deciduous
  fruit trees will not give you the fruit yields you want unless your
  property receives adequate chill hours. But what are chill hours and
  why are they so important?

... so both Chill Hours and Growing Degree-Days potentially challenge
WeeWX's data collection, calculation, reporting, and image generation
capabilities.  I developed a kludge to handle Growing Degree-Days
because treating orchard insects and disease is a season-to-season
battle and many treatments depend on such calculations.  I am not so
interested in Chill Hours because that has more to do with orchard
siting and choice of cultivars, which tend to be one-off decisions.
However, Chill Hours (in whatever manifestation) does keep coming up
here and on the other discussion group I frequent.  Perhaps this is
due to ongoing Climate-Change concerns.

* [Growing Fruit](https://growingfruit.org/search?q=chill%20hours)

I wonder whether I have gone down the right chute with the Phenology
Extension's Growing Degree-Days calculation and imaging capacity.
Does adding Chill Hours call for a more general approach?

I sadly fear the appetite for reporting Chill Hours does not
necessarily imply the desire or ability to configure WeeWX to do the
appropriate calculations or interpret the results.  These are not
straightforward things.

- -- 
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather:  http://LacusVeris.com/WX
.. 15° — Wind WNW 22 mph — Sky mostly clear.

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCYegsMQAKCRBg2/xipKOW
UuoSAJ4kvvWrCWqDkEZ8tl2yDzAPXU3LnQCeO5z01CamBSnFAr677iJNzwgf15U=
=aptL
-END PGP SIGNATURE-

-- 
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/20220119091910.5661af6a%40wealthy.

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

[Tom Keffer]

Upon reflection, the biggest difference seems to be that cooling-degree
days are weighted by the temperature difference from the baseline. You just
want the total number of hours.

This is best done as an XTypes extension
. Yes,
it's Python, and it's in the bowels of WeeWX, but it's actually a pretty
simple calculation. Several other users have successfully written xtypes
extensions.

On Tue, Jan 18, 2022 at 4:36 PM jszit...@gmail.com 
wrote:

> I would be very interested in this calculation as well!  Unfortunately I
> am of a limited proficiency when it comes to Python.
>
> As I understand cooling degree days, they reference a temperature mean for
> the day.  Chill hours would be a different subset, and is specifically the
> amount of time below 45 degrees Fahrenheit.  Cooling hours are cumulatively
> counted between October 1 through February 28 (at least in Texas). A more
> specific model only counts time with temperatures greater than 32 and less
> than 45 degrees. Newer models (still being reviewed I believe) have begun
> subtracting the time below 32 degrees from the cumulative number for a more
> exact count.
>
> Seth, I think you are on the right track.  If you could calculate on a
> daily basis and include that in the summary database, you would then only
> need to add the summaries together for a selected period.  This is the same
> process used for rain (I think).
>
> -Jonathan Z
> On Tuesday, January 18, 2022 at 6:11:03 PM UTC-6 tke...@gmail.com wrote:
>
>> What's the difference between chill hours and the existing cooling-days,
>> except for the value of the base?
>>
>> On Tue, Jan 18, 2022 at 3:47 PM Seth Ratner  wrote:
>>
>>> Ok, I'm looking at this from a different angle, and was wondering if
>>> someone knew the "right" way to do this before I go inventing a more
>>> complicated solution.
>>>
>>> For Chill Hours, I just need to add up the time that the temp is below
>>> XX degrees between two dates. As I understand WeeWX, every database entry
>>> has the interval length and the average temp for that interval. So in
>>> theory I can query the DB for the number of entries between two timestamps
>>> where the temp is below XX, and multiply the number of entries by the
>>> interval duration (5 minutes default).
>>>
>>> However, that would have me doing that query every time I wanted to
>>> display the value, which might be unnecessary processing power. It would
>>> also limit my display options. For example, if I wanted a chart to show
>>> chill hours the same way rain can be shown (with a cumulative line, an
>>> absolute line, etc), I'd have to come up with a more complicated query.
>>>
>>> Which got me thinking, chill hours are somewhat similar to rain, in that
>>> they are additive. So do I just create a service that gets triggered on an
>>> archive entry, looks at the temp for that archive entry, and if the temp is
>>> below the threshold it adds a value to column 'chill_hours' equal to the
>>> interval duration is? Then instead of inches, I'm using "minutes" as the
>>> unit of measurement.
>>>
>>> And is there any way to influence the daily summary table that would be
>>> created for this new "chill hours" field? Or do they all have to follow the
>>> same logic?
>>>
>>> Am I going about this the entirely wrong way? Ultimately I'd like to
>>> create the ability to track the accumulated hours of various custom temp
>>> ranges, and use that data for charting similar to other existing fields.
>>>
>>> Thanks,
>>> Seth
>>>
>>>
>>>
>>>
>>>
>>> On Saturday, December 25, 2021 at 11:48:43 AM UTC-6 Seth Ratner wrote:
>>>
 Hi everyone,

 I was wondering if anyone had already come up with a way to monitor
 chill hours (cumulative hours below 45℉) in WeeWx. I'm using Belchertown,
 and it would be nice to have a readout with Oct-May chill hours, and maybe
 a chart that shows the per-week and cumulative hours together.

 Thanks!
 Seth

>>> --
>>> 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/dcff6386-f236-43ab-92e2-c2e0c76acd37n%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/f7932dc4-02de-4d37-bf8a-3d5b000c7a7en%40googlegroups.com
> 

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

[jszit...@gmail.com]

I would be very interested in this calculation as well!  Unfortunately I am 
of a limited proficiency when it comes to Python. 

As I understand cooling degree days, they reference a temperature mean for 
the day.  Chill hours would be a different subset, and is specifically the 
amount of time below 45 degrees Fahrenheit.  Cooling hours are cumulatively 
counted between October 1 through February 28 (at least in Texas). A more 
specific model only counts time with temperatures greater than 32 and less 
than 45 degrees. Newer models (still being reviewed I believe) have begun 
subtracting the time below 32 degrees from the cumulative number for a more 
exact count.

Seth, I think you are on the right track.  If you could calculate on a 
daily basis and include that in the summary database, you would then only 
need to add the summaries together for a selected period.  This is the same 
process used for rain (I think).

-Jonathan Z
On Tuesday, January 18, 2022 at 6:11:03 PM UTC-6 tke...@gmail.com wrote:

> What's the difference between chill hours and the existing cooling-days, 
> except for the value of the base?
>
> On Tue, Jan 18, 2022 at 3:47 PM Seth Ratner  wrote:
>
>> Ok, I'm looking at this from a different angle, and was wondering if 
>> someone knew the "right" way to do this before I go inventing a more 
>> complicated solution.
>>
>> For Chill Hours, I just need to add up the time that the temp is below XX 
>> degrees between two dates. As I understand WeeWX, every database entry has 
>> the interval length and the average temp for that interval. So in theory I 
>> can query the DB for the number of entries between two timestamps where the 
>> temp is below XX, and multiply the number of entries by the interval 
>> duration (5 minutes default). 
>>
>> However, that would have me doing that query every time I wanted to 
>> display the value, which might be unnecessary processing power. It would 
>> also limit my display options. For example, if I wanted a chart to show 
>> chill hours the same way rain can be shown (with a cumulative line, an 
>> absolute line, etc), I'd have to come up with a more complicated query. 
>>
>> Which got me thinking, chill hours are somewhat similar to rain, in that 
>> they are additive. So do I just create a service that gets triggered on an 
>> archive entry, looks at the temp for that archive entry, and if the temp is 
>> below the threshold it adds a value to column 'chill_hours' equal to the 
>> interval duration is? Then instead of inches, I'm using "minutes" as the 
>> unit of measurement.
>>
>> And is there any way to influence the daily summary table that would be 
>> created for this new "chill hours" field? Or do they all have to follow the 
>> same logic?
>>
>> Am I going about this the entirely wrong way? Ultimately I'd like to 
>> create the ability to track the accumulated hours of various custom temp 
>> ranges, and use that data for charting similar to other existing fields. 
>>
>> Thanks,
>> Seth
>>
>>
>>
>>
>>
>> On Saturday, December 25, 2021 at 11:48:43 AM UTC-6 Seth Ratner wrote:
>>
>>> Hi everyone,
>>>
>>> I was wondering if anyone had already come up with a way to monitor 
>>> chill hours (cumulative hours below 45℉) in WeeWx. I'm using Belchertown, 
>>> and it would be nice to have a readout with Oct-May chill hours, and maybe 
>>> a chart that shows the per-week and cumulative hours together. 
>>>
>>> Thanks!
>>> Seth
>>>
>> -- 
>> 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/dcff6386-f236-43ab-92e2-c2e0c76acd37n%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/f7932dc4-02de-4d37-bf8a-3d5b000c7a7en%40googlegroups.com.

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

[Tom Keffer]

What's the difference between chill hours and the existing cooling-days,
except for the value of the base?

On Tue, Jan 18, 2022 at 3:47 PM Seth Ratner  wrote:

> Ok, I'm looking at this from a different angle, and was wondering if
> someone knew the "right" way to do this before I go inventing a more
> complicated solution.
>
> For Chill Hours, I just need to add up the time that the temp is below XX
> degrees between two dates. As I understand WeeWX, every database entry has
> the interval length and the average temp for that interval. So in theory I
> can query the DB for the number of entries between two timestamps where the
> temp is below XX, and multiply the number of entries by the interval
> duration (5 minutes default).
>
> However, that would have me doing that query every time I wanted to
> display the value, which might be unnecessary processing power. It would
> also limit my display options. For example, if I wanted a chart to show
> chill hours the same way rain can be shown (with a cumulative line, an
> absolute line, etc), I'd have to come up with a more complicated query.
>
> Which got me thinking, chill hours are somewhat similar to rain, in that
> they are additive. So do I just create a service that gets triggered on an
> archive entry, looks at the temp for that archive entry, and if the temp is
> below the threshold it adds a value to column 'chill_hours' equal to the
> interval duration is? Then instead of inches, I'm using "minutes" as the
> unit of measurement.
>
> And is there any way to influence the daily summary table that would be
> created for this new "chill hours" field? Or do they all have to follow the
> same logic?
>
> Am I going about this the entirely wrong way? Ultimately I'd like to
> create the ability to track the accumulated hours of various custom temp
> ranges, and use that data for charting similar to other existing fields.
>
> Thanks,
> Seth
>
>
>
>
>
> On Saturday, December 25, 2021 at 11:48:43 AM UTC-6 Seth Ratner wrote:
>
>> Hi everyone,
>>
>> I was wondering if anyone had already come up with a way to monitor chill
>> hours (cumulative hours below 45℉) in WeeWx. I'm using Belchertown, and it
>> would be nice to have a readout with Oct-May chill hours, and maybe a chart
>> that shows the per-week and cumulative hours together.
>>
>> Thanks!
>> Seth
>>
> --
> 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/dcff6386-f236-43ab-92e2-c2e0c76acd37n%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/CAPq0zEDVkLD4MSnWOiFJ1bMJ52XsgfOVAmetDkLYbJiiAEN5dQ%40mail.gmail.com.

[weewx-user] Re: Chill Hours Extension

[Seth Ratner]

Ok, I'm looking at this from a different angle, and was wondering if 
someone knew the "right" way to do this before I go inventing a more 
complicated solution.

For Chill Hours, I just need to add up the time that the temp is below XX 
degrees between two dates. As I understand WeeWX, every database entry has 
the interval length and the average temp for that interval. So in theory I 
can query the DB for the number of entries between two timestamps where the 
temp is below XX, and multiply the number of entries by the interval 
duration (5 minutes default). 

However, that would have me doing that query every time I wanted to display 
the value, which might be unnecessary processing power. It would also limit 
my display options. For example, if I wanted a chart to show chill hours 
the same way rain can be shown (with a cumulative line, an absolute line, 
etc), I'd have to come up with a more complicated query. 

Which got me thinking, chill hours are somewhat similar to rain, in that 
they are additive. So do I just create a service that gets triggered on an 
archive entry, looks at the temp for that archive entry, and if the temp is 
below the threshold it adds a value to column 'chill_hours' equal to the 
interval duration is? Then instead of inches, I'm using "minutes" as the 
unit of measurement.

And is there any way to influence the daily summary table that would be 
created for this new "chill hours" field? Or do they all have to follow the 
same logic?

Am I going about this the entirely wrong way? Ultimately I'd like to create 
the ability to track the accumulated hours of various custom temp ranges, 
and use that data for charting similar to other existing fields. 

Thanks,
Seth





On Saturday, December 25, 2021 at 11:48:43 AM UTC-6 Seth Ratner wrote:

> Hi everyone,
>
> I was wondering if anyone had already come up with a way to monitor chill 
> hours (cumulative hours below 45℉) in WeeWx. I'm using Belchertown, and it 
> would be nice to have a readout with Oct-May chill hours, and maybe a chart 
> that shows the per-week and cumulative hours together. 
>
> Thanks!
> Seth
>

-- 
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/dcff6386-f236-43ab-92e2-c2e0c76acd37n%40googlegroups.com.