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 <[email protected]> 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 <[email protected]> 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 [email protected] >> 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 <[email protected]> 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 >>>> [email protected] wrote: >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> On Tue, 18 Jan 2022 17:05:33 -0800 >>>>> Tom Deffer <[email protected]> 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----- >>>>> >>>> -- >>>> >>> 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 [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/weewx-user/07e91ec6-4eca-4023-8bc0-691b5e8679ffn%40googlegroups.com >>>> <https://groups.google.com/d/msgid/weewx-user/07e91ec6-4eca-4023-8bc0-691b5e8679ffn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/weewx-user/59f83ce0-32d1-470c-97bd-0471af8fa524n%40googlegroups.com >> <https://groups.google.com/d/msgid/weewx-user/59f83ce0-32d1-470c-97bd-0471af8fa524n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/weewx-user/CAPq0zEA4yV-y4GM-ZmuqZgP21DqLCLF%3Df8SqgPu4ZqQn4Ou8yg%40mail.gmail.com > <https://groups.google.com/d/msgid/weewx-user/CAPq0zEA4yV-y4GM-ZmuqZgP21DqLCLF%3Df8SqgPu4ZqQn4Ou8yg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAHTssjMDe8_1UO%2BV0agKCCMZVxw__CsKFN-GgNWrVVLjY4y%2BOA%40mail.gmail.com.
