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

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 be

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

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

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

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

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

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

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

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

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

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

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

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

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

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 funct

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

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 inclu

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

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

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

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 genBatc

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

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 kno

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

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 Ja

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

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 cu

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

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

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

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

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

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

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

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

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

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

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

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 pressur

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

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 l

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

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

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

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 m

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

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] [[C

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

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

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

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

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

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 initial

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

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

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

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!

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

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 wou

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

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

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

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 arc

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

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

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

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

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

-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

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

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

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

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 bel

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

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 m

[weewx-user] Re: Chill Hours Extension

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 datab