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 [email protected] 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 <[email protected]> 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 [email protected] 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 <[email protected]> 
>>> 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 <[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/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 [email protected].
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/d8f0bdb7-ebef-499a-aeb8-2fcb837bd49bn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/d8f0bdb7-ebef-499a-aeb8-2fcb837bd49bn%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/691a61b2-34a1-4eb1-ad94-e522cc450a5cn%40googlegroups.com.

Reply via email to