Chill Hours Extension

[Seth Ratner]

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

[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

[Tom Keffer]

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

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

[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

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

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/f7932dc4-02de-4d37-bf8a-3d5b000c7a7en%40googlegroups.com.

[Chuck Rhode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 18 Jan 2022 17:05:33 -0800
Tom Deffer <effe...@mail.com> 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

> <HTTP://git hub.com/weewx/weewx/wiki/WeeWX-V4-user-defined-types>.

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

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

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

--

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/07e91ec6-4eca-4023-8bc0-691b5e8679ffn%40googlegroups.com.

[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

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/59f83ce0-32d1-470c-97bd-0471af8fa524n%40googlegroups.com.

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

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/CAPq0zEA4yV-y4GM-ZmuqZgP21DqLCLF%3Df8SqgPu4ZqQn4Ou8yg%40mail.gmail.com.

[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 <tke...@gmail.com> wrote:

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/CAPq0zEA4yV-y4GM-ZmuqZgP21DqLCLF%3Df8SqgPu4ZqQn4Ou8yg%40mail.gmail.com.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAHTssjPAkRW_aCqzPi4%3DLEO7oVKHy4-Yhfw_Yc7_6ArEEf%3DDxw%40mail.gmail.com.

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

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d8f0bdb7-ebef-499a-aeb8-2fcb837bd49bn%40googlegroups.com.

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

[Tom Keffer]

On Thu, Jan 20, 2022 at 4:01 PM Seth Ratner <lordr...@gmail.com> 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

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

--

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.

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

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.

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

[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

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/cb666588-aced-461c-9171-9d48b89e85f5n%40googlegroups.com.

[Seth Ratner]

Oh boy...

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

[Tom Keffer]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/8bb5d647-2f69-42b5-b5db-5b4c901e32f5n%40googlegroups.com.

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

[John Kline]

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 <lordr...@gmail.com> 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?

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/5c169c50-b9aa-4986-b2cc-0d58494b6665n%40googlegroups.com.

[Tom Keffer]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/A8392819-685E-4BA1-93BD-BEAAF6D888C5%40johnkline.com.

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

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

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d6e37e32-94a3-4220-8bf7-8503a3f23d3cn%40googlegroups.com.

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

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

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

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/53c49b11-447f-45e4-952d-72a2c36e3eden%40googlegroups.com.

[Tom Keffer]

On Fri, Jan 21, 2022 at 4:27 PM Seth Ratner <lordr...@gmail.com> 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

[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

[Tom Keffer]

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

--

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.

[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

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/3d88704a-2c3b-4145-9f54-b3ed1c159edcn%40googlegroups.com.