You are right, none of those examples meets the condition (starting and ending on day boundaries), but the first example starts at the start of today, ending with the latest timestamp in the database. Which is still today, but not a day's boundary. So my best guess is, that the shortcuts using the daily summaries, is also taken in that particular case.
And yes, your explanation helps. Tom Keffer schrieb am Samstag, 14. September 2024 um 21:27:01 UTC+2: > I'm not following your question --- too many numbers flying around --- but > let me try to explain the calculation in the hopes that it helps. > > When calculating an aggregate, there's always a well-defined answer. In > this case, it's the minimum temperature over the aggregate interval, so you > scan all the relevant records and look for the minimum and the timestamp of > the record that contains it. > > However, if the interval starts and ends on day boundaries (that is, at > midnight), then a shortcut can be taken. The algorithm can use the daily > summaries to speed the calculation. Otherwise, the main archive table is > used. > > I didn't look too closely, but I don't think either of your examples > satisfies this condition. The aggregation interval is something like 20 > hours or 27 hours. So, the main archive table should have been used. > > Either way, you should get the same answer, although the daily summaries > can be slightly more precise for the timestamp. The reason is that while > the archive table has the minimum value seen in the interval, it doesn't > have the precise time, only the timestamp of the record with the lowest > value. By contrast, the daily summaries have the timestamp of the LOOP > packet that provided the minimum value, so the precision can be down to a > few seconds. > > Otherwise, there should be no difference. > > Does that help? > > -tk > > > > On Sat, Sep 14, 2024 at 10:56 AM '[email protected]' via > weewx-development <[email protected]> wrote: > >> Is it possible, that this function returns different values, if the >> timespan is across more than a single calendar day? >> >> results = weewx.xtypes.get_aggregate("outTemp", TimeSpan(1726264800, >> 1726335600), "min", dbmanager) >> print(results) >> results = weewx.xtypes.get_aggregate("outTemp", TimeSpan(1726264800, >> 1726335600), "mintime", dbmanager) >> print(results) >> yields >> (4.5, 'degree_C', 'group_temperature') >> (1726303300, 'unix_epoch', 'group_time') >> Where 1726264800 is the start of today in my timezone. 1726303300 is the >> min outtemp of toady as in archive_day_outtemp. >> >> results = weewx.xtypes.get_aggregate("outTemp", TimeSpan(1726238400, >> 1726335600), "min", dbmanager) >> print(results) >> results = weewx.xtypes.get_aggregate("outTemp", TimeSpan(1726238400, >> 1726335600), "mintime", dbmanager) >> print(results) >> yields >> (4.555172413793103, 'degree_C', 'group_temperature') >> (1726303500, 'unix_epoch', 'group_time') >> Where 1726238400 is some random time yesterday in my timezone. >> 1726303500 is the first timestamp of the record in archive, where outtemp >> has the minimum value. >> >> Obviously, when doing the second "query", I don't get the exact minimum >> and it's timestamp. Can I only achieve my desired result, if I limit the >> timespan to not overlap a calendar day change? >> >> >> >> >> [email protected] schrieb am Samstag, 14. September 2024 um 16:15:43 >> UTC+2: >> >>> Thanks! Although obviously there, I didn't get it :) >>> >>> Tom Keffer schrieb am Samstag, 14. September 2024 um 15:35:04 UTC+2: >>> >>>> Just substitute "mintime" / "maxtime" for "min" / "max". >>>> >>>> See the table of Aggregation Types >>>> <https://www.weewx.com/docs/5.1/reference/aggtypes/>. >>>> >>>> On Sat, Sep 14, 2024 at 2:02 AM '[email protected]' via >>>> weewx-development <[email protected]> wrote: >>>> >>>>> Thank you Tom, this works for the max/min value as I need it. But the >>>>> dateTime for that value isn't in the result and I don't have a clue, how >>>>> to >>>>> get it for that particular value. >>>>> >>>>> Tom Keffer schrieb am Freitag, 13. September 2024 um 22:27:31 UTC+2: >>>>> >>>>>> The xtypes system can do this. See the section, *XTypes API >>>>>> <https://github.com/weewx/weewx/wiki/xtypes#xtypes-api>*. >>>>>> >>>>>> Your example would be: >>>>>> >>>>>> results = weewx.xtypes.get_aggregate("outTemp", TimeSpan(1726092000, >>>>>> 1726178400), "max", dbmanager) >>>>>> >>>>>> >>>>>> where "dbmanager" is an open database manager. The results will be >>>>>> a ValueTuple <https://www.weewx.com/docs/5.1/reference/valuetuple/>. >>>>>> >>>>>> Here's a more complete example: >>>>>> >>>>>> import weecfg >>>>>> import weewx.manager >>>>>> import weewx.xtypes >>>>>> from weeutil.weeutil import TimeSpan >>>>>> >>>>>> >>>>>> config_path, config_dict = >>>>>> weecfg.read_config('/home/weewx/weewx.conf') >>>>>> >>>>>> with weewx.manager.open_manager_with_config(config_dict, >>>>>> 'wx_binding') as dbmanager: >>>>>> >>>>>> results = weewx.xtypes.get_aggregate("outTemp", >>>>>> TimeSpan(1726092000, 1726178400), "max", dbmanager) >>>>>> >>>>>> >>>>>> print(results) >>>>>> >>>>>> >>>>>> (68.4, 'degree_F', 'group_temperature') >>>>>> >>>>>> >>>>>> On Fri, Sep 13, 2024 at 10:27 AM '[email protected]' via >>>>>> weewx-development <[email protected]> wrote: >>>>>> >>>>>>> When I write an extension in python, can I get the minimum/maximum >>>>>>> value for an obs_type and a given timespan and their related timestamp? >>>>>>> >>>>>>> Something like: >>>>>>> >>>>>>> maxValue, datetime = getMax("outTemp", 1726092000, 1726178400) >>>>>>> >>>>>>> The min/max has to be obtained from the archive_day table, the >>>>>>> archive table might not contain the exact max/min value, and also not >>>>>>> the >>>>>>> exact timestamp the value arrived. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "weewx-development" 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-development/6d13cde1-43c4-4ca3-a4a4-d220fc5e2040n%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/weewx-development/6d13cde1-43c4-4ca3-a4a4-d220fc5e2040n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "weewx-development" 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-development/2aaf12b7-25ad-4013-8185-b379168b4bc5n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/weewx-development/2aaf12b7-25ad-4013-8185-b379168b4bc5n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "weewx-development" 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-development/c183248b-1a04-47bd-8359-51ec5f215741n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-development/c183248b-1a04-47bd-8359-51ec5f215741n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "weewx-development" 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-development/8138a283-82d2-418b-8a06-d919daee47b0n%40googlegroups.com.
