True, but if you want to save the results in the database, that won't work.
Really, the extraction of records from the accumulators should be separated from StdArchive. I looked into that once and concluded it would require some non-trivial changes in the event structure, so I did... nothing. But, I will look into it more. Issue #901 <https://github.com/weewx/weewx/issues/901> to track. -tk On Tue, Dec 5, 2023 at 11:27 AM gjr80 <[email protected]> wrote: > 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 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/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 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/CAPq0zEC9ExJg7O1MgLsr%3Dj1qo-LDd9w9xYkoyK7VNWAOBKoeyQ%40mail.gmail.com.
