A quick update about the test of using an XTYPE extension in my context.
I see the same problem as the one I had with a service : the record
received by the *get_scalar* function of the XTYPE extension does not
contain GW1000 records values.
So XTYPE extensions are also processed before StdArchive is called and
before the GW1000 record values are generated from the accumulated LOOP
packets.
Le vendredi 8 décembre 2023 à 09:18:26 UTC+1, jterr...@gmail.com a écrit :
> Thanks . I will also have a try with an XTYPE extension
>
> Le mercredi 6 décembre 2023 à 16:21:57 UTC+1, Karen K a écrit :
>
>> Maybe, writing an XTYPE extension instead of a service would be a
>> solution. There you have access to the archive record and you can create
>> new observation types, that can be saved to the database.
>>
>> Jacques Terrettaz schrieb am Mittwoch, 6. Dezember 2023 um 07:16:19 UTC+1:
>>
>>> Thanks.
>>>
>>> Right now I think will follow option 2 and I am looking forward to use
>>> the separate extraction of records from accumulators in version 5.1 !
>>>
>>>
>>> Le 5 déc. 2023 à 23:36, gjr80 <gjrod...@gmail.com> a écrit :
>>>
>>> Like I said, depends whether you wanted to morph the archive record or
>>> not.
>>>
>>> Since you are clearly happy to get your hands dirty a couple of
>>> workarounds come to mind:
>>>
>>> 1. Bind your service to both NEW_LOOP_PACKET and NEW_ARCHIVE_RECORD.
>>> When a new loop packet comes in check it for the Ecowitt obs you want and
>>> save the value as a property of your service. When NEW_ARCHIVE_RECORD
>>> occurs use the saved property to do what you want to the archive record. As
>>> long as your service appears after the gw1000 service and before
>>> StdArchive it should be fine. A couple of variations, keep a timestamp
>>> of the Ecowitt value and you can decide whether to alter the archive record
>>> or not depending on whether the Ecowitt data is stale or not.
>>>
>>> 2. If you particularly want to do something based on the archive period
>>> value of the Ecowitt obs then bind your service to NEW_LOOP_PACKET,
>>> NEW_ARCHIVE_RECORD and END_ARCHIVE_PERIOD. You can get the Ecowitt
>>> value from the loop packet and accumulate it, on the END_ARCHIVE_PERIOD
>>> event you can calculate the archive period value for the Ecowitt obs (eg
>>> simple average) snd reset the accumulated value and then on
>>> NEW_ARCHIVE_PERIOD you can modify the archive record. Again as long
>>> your service appears after the gw1000 service and before StdArchive it
>>> should be fine.
>>>
>>> There are probably other possibilities. Will be much easier when v5.1
>>> comes out with a split StdArchive :) :)
>>>
>>> Gary
>>> On Wednesday 6 December 2023 at 05:58:37 UTC+10 jterr...@gmail.com
>>> wrote:
>>>
>>>> Thanks for the suggestion Gary. But in that case, with a service in
>>>> archive_
>>>> services (after StdArchive) or in report_services , it is a read-only
>>>> access to the full archive record.
>>>>
>>>> The idea of my service was to read some GW1000 sensor archive record
>>>> values, and depending on these value modify another non-GW1000 archive
>>>> record value. If I understand well, this has to be done before
>>>> StdArchive, i.e before the archive record is finalized and written to
>>>> the database.
>>>>
>>>>
>>>>
>>>> Le 5 déc. 2023 à 20:27, gjr80 <gjrod...@gmail.com> a écrit :
>>>>
>>>> Not quite true. If you include your service in archive_services (after
>>>> StdArchive) or anywhere in report_services it will have access to the
>>>> augmented archive record (even restful_services will work but that
>>>> just doesn't sound right to me).
>>>>
>>>> Gary
>>>>
>>>> On Wednesday, 6 December 2023 at 03:50:02 UTC+10 jterr...@gmail.com
>>>> wrote:
>>>>
>>>>> Yes, this is the case. The GW1000 gateway service only adds sensor
>>>>> values to the LOOP packets. So in that case, there is no way to capture
>>>>> the
>>>>> archive record of GW1000 sensors using a custom service.
>>>>>
>>>>> Thanks for your reply
>>>>>
>>>>>
>>>>> Le 5 déc. 2023 à 16:38, Tom Keffer <tke...@gmail.com> a écrit :
>>>>>
>>>>> As you're hinting, it depends on details of how GatewayService adds
>>>>> outTemp5.
>>>>>
>>>>> Service StdArchive is responsible for taking the accumulated LOOP
>>>>> packets and turning them into an archive record. So, if GatewayService
>>>>> only
>>>>> adds outTemp5 to the LOOP packets and depends on StdArchive to turn them
>>>>> into archive records, outTemp5 won't appear until *after* StdArchive
>>>>> has run.
>>>>>
>>>>> On the other hand, if GatewayService puts outTemp5 in the archive
>>>>> record, it should be in there by the time MyService sees the record.
>>>>>
>>>>>
>>>>> On Tue, Dec 5, 2023 at 2:32 AM jterr...@gmail.com <jterr...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I have weewx (4.10.2) configured with the Davis Vantage 2 driver, and
>>>>>> additionally the GW1000 gateway service provides values for some more
>>>>>> temperature sensors.
>>>>>> Everything is working properly , and GW1000 temperature values
>>>>>> (mapped as extraTempX) are recorded in the archive database and appear
>>>>>> in
>>>>>> LOOP packets.
>>>>>>
>>>>>> I am working on a new service, triggered by the NEW_ARCHIVE_RECORD
>>>>>> event, that needs to read the record values of the some of the
>>>>>> extraTemp
>>>>>> captured by the GW10000.
>>>>>>
>>>>>> In this exemple :
>>>>>>
>>>>>> class MyService(StdService):
>>>>>> def __init__(self, engine, config_dict):
>>>>>> super(MyService self).__init__(engine, config_dict)
>>>>>> manager_dict =
>>>>>> weewx.manager.get_manager_dict_from_config(config_dict, 'wx_binding')
>>>>>> self.db_manager = weewx.manager.open_manager(manager_dict)
>>>>>> self.bind(weewx.NEW_ARCHIVE_RECORD, self.newArchiveRecord)
>>>>>>
>>>>>> def newArchiveRecord(self, event):
>>>>>> if event.record.get('extraTemp5') is not None:
>>>>>> loginf("record extraTemp5 is : %f " % (event.record['extraTemp5']))
>>>>>> else:
>>>>>> loginf("no extraTemp5 in record" )
>>>>>> if event.record.get('OutTemp') is not None:
>>>>>> loginf("record OutTemp is : %f " % (event.record['outTemp']))
>>>>>> else:
>>>>>> loginf("no outTemp in record" )
>>>>>>
>>>>>> When this new service is running, I have always in the log "no
>>>>>> extraTemp5 in record" ( the outTemp value is correctly logged) ,
>>>>>> but ultimately the value of extraTemp5 is written in the archive table
>>>>>> of
>>>>>> the database. So at the time weewx triggers a NEW_ARCHIVE_RECORD event,
>>>>>> there is no data coming from the GW1000 in the archive record.
>>>>>>
>>>>>> Does it means that the archive values of the parameters coming from
>>>>>> GW1000 service, and presumably generated by weewx since the GW1000
>>>>>> service
>>>>>> is generating LOOP packets only, are inserted in the archive record
>>>>>> after
>>>>>> the NEW_ARCHIVE_RECORD event is triggered?
>>>>>>
>>>>>> in weewx.conf, the services are as follows :
>>>>>> data_services = user.gw1000.GatewayService
>>>>>> process_services = weewx.engine.StdConvert,
>>>>>> weewx.engine.StdCalibrate, weewx.engine.StdQC,
>>>>>> weewx.wxservices.StdWXCalculate, user.sunduration.SunshineDuration,
>>>>>> user.myservice.MyService
>>>>>>
>>>>>> --
>>>>>> 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/99eadb93-8622-4663-b511-cb2477d5c4fen%40googlegroups.com
>>>>>>
>>>>>> <https://groups.google.com/d/msgid/weewx-user/99eadb93-8622-4663-b511-cb2477d5c4fen%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/sStF634U7Rw/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/CAPq0zECMS9hMGQSgNK4_mSfP4MyxpXLqR1WXhACE9-0spssX2g%40mail.gmail.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/weewx-user/CAPq0zECMS9hMGQSgNK4_mSfP4MyxpXLqR1WXhACE9-0spssX2g%40mail.gmail.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/sStF634U7Rw/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/abec7d74-1320-4c8a-9d86-e1d5a941bbe4n%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/weewx-user/abec7d74-1320-4c8a-9d86-e1d5a941bbe4n%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/sStF634U7Rw/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/65d02f78-6f61-40ba-b118-43006131a3cdn%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/weewx-user/65d02f78-6f61-40ba-b118-43006131a3cdn%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/c9cb57ed-f0e5-416a-b1e1-e562b41b7f32n%40googlegroups.com.
