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 <[email protected]> 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 [email protected] 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 <[email protected] <>> 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 [email protected] <> 
>>> 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 <[email protected] <>> 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 [email protected] <> <[email protected] 
>>>>> <>> 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 [email protected] <>.
>>>>>> 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 
>>>>> [email protected] <>.
>>>>> 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 
>>> [email protected] <>.
>> 
>>> 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 
> [email protected] 
> <mailto:[email protected]>.
> 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CD24DA95-5B1E-4E8B-9C65-7185EDDD6579%40gmail.com.

Reply via email to