Re: [weewx-user] NEW_ACHIVE_RECORD event chronology

[jterr...@gmail.com]

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  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  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  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  
> 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 

Re: [weewx-user] NEW_ACHIVE_RECORD event chronology

[jterr...@gmail.com]

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  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  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  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  
 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 GW1. 
>
> 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')
>  

Re: [weewx-user] NEW_ACHIVE_RECORD event chronology

[Karen K]

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  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  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  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  
>>> 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 GW1. 

 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 " % 

Re: [weewx-user] NEW_ACHIVE_RECORD event chronology

[Jacques Terrettaz]

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  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 > 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 > 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 <>  <>> 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 GW1. 
>> 
>> 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:
>> 

Re: [weewx-user] NEW_ACHIVE_RECORD event chronology

[gjr80]

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  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  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  
>> 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 GW1. 
>>>
>>> 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 

Re: [weewx-user] NEW_ACHIVE_RECORD event chronology

[Jacques Terrettaz]

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  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 > 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 <> >> <>> 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 GW1. 
 
 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
  
 .
>>> 
>>> 
>>> -- 
>> 
>>> 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 

Re: [weewx-user] NEW_ACHIVE_RECORD event chronology

[gjr80]

Yes, guess it comes down to what MyService is doing, is it morphing the 
archive record or simply reporting on it.

Gary

On Wednesday, 6 December 2023 at 05:41:37 UTC+10 tke...@gmail.com wrote:

> 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 
>  to track.
>
> -tk
>
>
> On Tue, Dec 5, 2023 at 11:27 AM gjr80  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 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  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  
>>> 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 GW1. 

 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
  
 
 .

>>>
>>> -- 
>>>
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "weewx-user" group.
>>> To unsubscribe from this topic, 

Re: [weewx-user] NEW_ACHIVE_RECORD event chronology

[Tom Keffer]

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
 to track.

-tk


On Tue, Dec 5, 2023 at 11:27 AM gjr80  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 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  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 
>> 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 GW1.
>>>
>>> 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
>>> 
>>> .
>>>
>>
>> --
>>
>> 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
>> 

Re: [weewx-user] NEW_ACHIVE_RECORD event chronology

[gjr80]

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  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  
> 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 GW1. 
>>
>> 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
>>  
>> 
>> .
>>
>
> -- 
>
> 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
>  
> 
> .
>
>
>

-- 
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/abec7d74-1320-4c8a-9d86-e1d5a941bbe4n%40googlegroups.com.

Re: [weewx-user] NEW_ACHIVE_RECORD event chronology

[Jacques Terrettaz]

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  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  
> mailto:jterret...@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 GW1. 
>> 
>> 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+unsubscr...@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
>>  
>> .
> 
> 
> -- 
> 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+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/CAPq0zECMS9hMGQSgNK4_mSfP4MyxpXLqR1WXhACE9-0spssX2g%40mail.gmail.com
>  
> .

-- 
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/A4F009AC-0C6F-416D-B356-D2F587C6AEF2%40gmail.com.

Re: [weewx-user] NEW_ACHIVE_RECORD event chronology

[Tom Keffer]

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 
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 GW1.
>
> 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+unsubscr...@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
> 
> .
>

-- 
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/CAPq0zECMS9hMGQSgNK4_mSfP4MyxpXLqR1WXhACE9-0spssX2g%40mail.gmail.com.