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 <https://github.com/weewx/weewx/issues/729> for the > future. > > On Thu, Jan 20, 2022 at 8:06 AM Seth Ratner <se...@lordratner.com> 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 <tke...@gmail.com> 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 <lordr...@gmail.com> 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 <lordr...@gmail.com> >>>>> 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 <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----- >>>>>>> >>>>>> -- >>>>>> >>>>> 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 >>>>>> >>>>>> <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 weewx-user+...@googlegroups.com. >>>> 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 >>> 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 >>> >>> <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 weewx-user+...@googlegroups.com. >> > 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 >> >> <https://groups.google.com/d/msgid/weewx-user/CAHTssjPAkRW_aCqzPi4%3DLEO7oVKHy4-Yhfw_Yc7_6ArEEf%3DDxw%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 weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d8f0bdb7-ebef-499a-aeb8-2fcb837bd49bn%40googlegroups.com.
