When you instantiate a service, one of the parameters is the engine
instance:

    def __init__(self, engine, config_dict):

The archive interval used by the engine can be obtained from it as

engine.console.archive_interval

-tk



On Fri, Jun 10, 2022 at 11:07 AM 'Peter Fletcher' via weewx-user <
weewx-user@googlegroups.com> wrote:

> Yes. This is potentially even more of a problem if you only determine
> whether the sun is shining when the radiation value changes, which is what
> I now do (with a timeout to deal with the instances when the 'gap' is a
> multiple of 50+ seconds). I have addressed it slightly differently - I
> accumulate seconds of sunshine and the total seconds elapsed between
> computations in the LOOP code and use the *ratio* of these (for each
> archive interval) to determine sunshine time for that interval.
>
> On Friday, June 10, 2022 at 10:40:09 AM UTC-4 jterr...@gmail.com wrote:
>
>> The Davis VP2 archive are recorded in the datalogger at the exact archive
>> interval.
>> So even if for any reason a service bound to NEW_ARCHIVE_RECORD is
>> running a little bit later that the time the record was captured by the
>> VP2, the data will still be valid, and the "*event.record['interval'] " *will
>> be the interval between the two last recors received from the VP2.
>>
>> Concerning our context of doing sunshine duration measurements based  on
>> LOOP packets, these loop packets may be not always in phase with the
>> archive  at the time an archive record is processed by weewx for our service
>> So for instance, I saw initially  with my archive interval of 5 min and
>> during  a period of full sunshine, that the sunshine duration derived from
>> loop packets during  an "archive" interval"  was a little bit higher that 5
>> min, or sometimes a little bit lower :
>>
>> 2022-06-06 11:30:19  weewx[4501] INFO user.sunduration: Sunshine duration
>> from loop packets = 5.016667 min, last radiation = 828.000000, and last
>> threshold = 639.982068
>>
>> Given the context of "slow" update of solar radiation of the VP2 compared
>> to the LOOP interval, I decided to round up the sunshine duration to full
>> minutes
>>
>> Le 10 juin 2022 à 15:52, 'Peter Fletcher' via weewx-user <
>> weewx...@googlegroups.com> a écrit :
>>
>> Thanks to all! Granted that you are most likely to need to know the
>> archive interval in the context of an archive interrupt service, where it
>> is easily available and the returned value is reliable, it would be nice if
>> the actual working value (rather than just the value from weewx.conf) were
>> readily available in other contexts.
>>
>> On Friday, June 10, 2022 at 9:04:06 AM UTC-4 jterr...@gmail.com wrote:
>>
>>> "Using the interval field from the current archive record should always
>>> give the correct value.".
>>>
>>> I use it in my extension and it works very well:
>>> *event.record['interval'] *
>>>
>>> Le vendredi 10 juin 2022 à 05:04:45 UTC+2, gjr80 a écrit :
>>>
>>>> Whilst in almost all cases the archive interval used by WeeWX will
>>>> match the archive_interval config option in weewx.conf [StdArchive] this
>>>> is not always the case. Installs that use software record generation always
>>>> use an archive interval that matches the archive_interval config
>>>> option; however, when using hardware record generation if the archive
>>>> interval set in the station hardware is different to the
>>>> archive_interval config option the archive_interval config option is
>>>> ignored and the station hardware archive interval is used instead. This is
>>>> most commonly seen with Davis stations used with a default WeeWX install.
>>>> The Davis station uses an out-of-the-box 30 minute archive interval and
>>>> that value overrides the default WeeWX archive interval of five minutes.
>>>>
>>>> Using the interval field from the current archive record should always
>>>> give the correct value.
>>>>
>>>> Gary
>>>>
>>>
>> --
>> 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/W0jG1kElJ1k/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/87e7270c-2cbf-4438-a60b-638be2005049n%40googlegroups.com
>> <https://groups.google.com/d/msgid/weewx-user/87e7270c-2cbf-4438-a60b-638be2005049n%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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/d030a216-4cfd-4df3-ad3c-55ae8df63cf8n%40googlegroups.com
> <https://groups.google.com/d/msgid/weewx-user/d030a216-4cfd-4df3-ad3c-55ae8df63cf8n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zECUV0DPBTxNf_A_mJosbDqoJRmiBGN%3DpdPiXQrf5dt_TQ%40mail.gmail.com.

Reply via email to