Re: [weewx-user] Pipe errors etc

[jterr...@gmail.com]

David,

I have 2 suggestions about your network problems with your IP datalogger :

   1. By default, the IP datalogger will periodically send sensor real-time 
   data and datalogger archive data to weatherlink.com servers. Weewx needs 
   exclusive access to the IP datalogger. You may try to disable the upload to 
   weatherlink servers by connecting to the datalogger using a web browser and 
   uncheck the "Upload to weatherlink.com" option.  Concerning the exclusive 
   access needed by weewx, are you using any other software (Weatherlink 
   software or any other) that connects to the IP datalogger and that may 
   break the weewx-datalogger pipe ?
   2. Is the IP logger configured with  a static IP address ? If it is the 
   case, check that you don't have any other network device configured 
   statically with the same IP address. Check also that the address range of 
   the DHCP server of your router does not overlap with the static IP address 
   of the datalogger.


Le mardi 5 décembre 2023 à 18:58:12 UTC+1, hind...@gmail.com a écrit :

> Thanks.  I might end up having to try one of these options.
>
> On Tuesday 5 December 2023 at 15:19:35 UTC gary@gmail.com wrote:
>
>> I went with a WiFiLogger2 which has performed without a hitch for a 
>> couple of years now.
>> The maker also has an Ethernet unit if you don't want the added heat from 
>> a radio in your console.
>>
>> https://wifilogger.net/
>>
>> https://wifilogger.net/ethernet.html
>>
>> On Tuesday, December 5, 2023 at 6:54:14 AM UTC-5 hind...@gmail.com wrote:
>>
>>> I have recently moved a BT Wholehome Wifi disc a little closer to the 
>>> Console  (10cm now; was 100cm)  , so I guess that *might* be 
>>> "interfering" in some way  - I will try moving it further away again to see 
>>> if that solves the problem.  I have already re-seated the WLIP logger a few 
>>> times. Incidentally, if Davis no longer make the WLIP logger, does anyone 
>>> know what the the preferred method now is of getting the data from the 
>>> weather station to weewx etc?
>>>
>>> I may also try the different drive that was suggested in 
>>> https://groups.google.com/g/weewx-user/c/q67cvEsXtjQ/m/7difZtkUAgAJ.
>>>
>>> Regarding the question in 
>>> https://groups.google.com/g/weewx-user/c/q67cvEsXtjQ/m/J9W5KA7rAQAJ, I 
>>> haven't changed anything on my network, other than moving a few ethernet 
>>> cables for other devices around, due to an unstable Sky TV connection.
>>>
>>> Thanks to everyone that has commented on this to help me find a 
>>> solution.  Much appreciated.
>>>
>>> David.
>>>
>>> On Tuesday 5 December 2023 at 00:25:06 UTC Tom Keffer wrote:
>>>
 That's certainly possible. I'd say ask Davis, but this logger has been 
 so long out of production that I doubt David would get any satisfaction 
 out 
 of them.

 I'm also suspicious when electronic devices "just break." That's very 
 rare. But, it does happen.

 One thing you could try: reseating the logger. 

 Oh, and is there any new source of RF nearby? A new router? Satellite 
 dish? 5 kW pirate radio?

 On Mon, Dec 4, 2023 at 4:17 PM Graham Eddy  wrote:

> the vantage IP device seems to accept a connection, work for a while, 
> then stop responding, then connection is reset → sounds like on device 
> side 
> it seizes up and the ip protocol times out; establishing new connection 
> just repeats the cycle. the device apparently has been working for years 
> and is now failing → sounds like device has broken
> *⊣GE⊢*
>
> On 5 Dec 2023, at 9:23 am, vince  wrote:
>
> Just a thought, but when I see "weewx.drivers.vantage: ip-read error: 
> timed out" that makes me think your network is unstable.   From your 
> posts in the thread it 'sounds' like it has been working for years 
> without 
> issues.  Did you change anything on your network ? Did you change any 
> firewall settings on your pi or install something like fail2ban or pihole 
> recently ?
>
>
> -- 
> 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/6B5C1B94-55F5-484D-8E8E-3142F471AE4C%40geddy.au
>  
> 
> .
>


-- 
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/d7ac813d-fc19-4ab7-8f73-f7f7a47ee46an%40googlegroups.com.

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:
>> loginf("reco

Re: [weewx-user] can not get weewx to process this formula

[Tom Keffer]

Final note on this: Commit a978796 

 
allows one to apply corrections to only archive records, even if they came 
from software. So, you could do

 [[Corrections]]
pf = 0.88
consumption = ((ampere * linevoltage) /1000) * pf, archive

This is not precisely what you want, because it is applying the expression 
to the product of the *average* amperage times the *average* linevoltage, 
but it would get you close.

-tk

On Tuesday, October 17, 2023 at 9:17:44 PM UTC-7 mksm...@gmail.com wrote:

> Thank you Tom
> the service file is doing exactly what we needed.
>
> GOD bless you
>
> On Wednesday, October 18, 2023 at 7:01:27 AM UTC+3 Mks Mk wrote:
>
>>
>> added import weewx to the top of file
>> it worked
>>
>> On Wednesday, October 18, 2023 at 6:50:58 AM UTC+3 Mks Mk wrote:
>>
>>> there is nothing in the log file related to the correction
>>>
>>> we tried the service but it failed twice
>>>
>>> 1st run failed with error:
>>>
>>> Oct 18 06:37:20 debian weewx[3413] CRITICAL __main__: File 
>>> "/usr/share/weewx/user/myservice.py", line 10
>>> Oct 18 06:37:20 debian weewx[3413] CRITICAL __main__:   def 
>>> new_archive_record(self, event)
>>> Oct 18 06:37:20 debian weewx[3413] CRITICAL __main__:    
>>>   ^
>>> Oct 18 06:37:20 debian weewx[3413] CRITICAL __main__:  
>>>  SyntaxError: invalid syntax
>>> Oct 18 06:37:20 debian weewx[3413] CRITICAL __main__:   Exiting.
>>>
>>> changed to
>>>
>>> def new_archive_record(self, event):
>>>
>>> run weewx again but failed with error
>>>
>>>
>>> Oct 18 06:42:20 debian weewx[3603] CRITICAL __main__: File 
>>> "/usr/share/weewx/weewxd", line 148, in main
>>> Oct 18 06:42:20 debian weewx[3603] CRITICAL __main__:  
>>>  engine = weewx.engine.StdEngine(config_dict)
>>> Oct 18 06:42:20 debian weewx[3603] CRITICAL __main__: File 
>>> "/usr/share/weewx/weewx/engine.py", line 93, in __init__
>>> Oct 18 06:42:20 debian weewx[3603] CRITICAL __main__:  
>>>  self.loadServices(config_dict)
>>> Oct 18 06:42:20 debian weewx[3603] CRITICAL __main__: File 
>>> "/usr/share/weewx/weewx/engine.py", line 161, in loadServices
>>> Oct 18 06:42:20 debian weewx[3603] CRITICAL __main__:   obj 
>>> = weeutil.weeutil.get_object(svc)(self, config_dict)
>>> Oct 18 06:42:20 debian weewx[3603] CRITICAL __main__: File 
>>> "/usr/share/weewx/user/myservice.py", line 8, in __init__
>>> Oct 18 06:42:20 debian weewx[3603] CRITICAL __main__:  
>>>  self.bind(weewx.NEW_ARCHIVE_RECORD, self.new_archive_record)
>>> Oct 18 06:42:20 debian weewx[3603] CRITICAL __main__:  
>>>  NameError: name 'weewx' is not defined
>>> Oct 18 06:42:20 debian weewx[3603] CRITICAL __main__:   Exiting.
>>>
>>> On Wednesday, October 18, 2023 at 4:42:59 AM UTC+3 Tom Keffer wrote:
>>>
 Just had a thought. 

 I assume that weewxd is using software record generation. Check in the 
 log. If so, [[Corrections]] does not apply the corrections to archive 
 records because, in theory, the correction should have already been 
 applied 
 in the LOOP packets. Obviously that's not happening here.

 I've created issue #895  to 
 track.

 In the meantime, what you can do is create a simple service 
  to do 
 the calculation. It would look something like this (NOT TESTED):

 from weewx.engine import StdService

 class Power(StdService):

   def __init__(self, engine, config_dict):
 super(Power, self).__init__(engine, config_dict)

 self.bind(weewx.NEW_ARCHIVE_RECORD, self.new_archive_record)

   def new_archive_record(self, event)
 ampere = event.record.get('ampere')
 linevoltage = event.record.get('linevoltage')
 if ampere is not None and linevoltage is not None:
   event.record['consumption'] = ampere * linevoltage
 else:
   event.record['consumption'] = None

 This will work provided that linevoltage and ampere do not vary too 
 much over the archive interval. Because you are using short intervals (60 
 seconds), this is probably not much of a problem.
 






 On Tue, Oct 17, 2023 at 6:12 PM Mks Mk  wrote:

> from database
>
> dateTime usUnits interval consumption  ampe

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 it

Re: [weewx-user] Wind direction graph weirdness

[vince]

Rob - I'm in Federal Way a mile or so south of Redondo and my graphs 'do' 
line up with our prevailing winds here that tend to be from the SW in this 
location.  We rarely get wind from the NNE-SE directions.  It either comes 
off the Sound in the Port of Tacoma or from the SW from Browns Point. 
 Occasionally from the NW through a slot in the trees from the water next 
to Redondo but not too often.

Your graphs just look a bit bouncy to me which might be your siting.   See 
if your Vue vane is pointing into the direction weewx reports.   Mine down 
here is from the SW currently FWIW.

(if you watch local tv news, take a drink every time they say 'atmospheric 
river' this week)

On Tuesday, December 5, 2023 at 1:01:14 PM UTC-8 Rob Cranfill wrote:

> I’ll figure out how to do that and let ya know. Thanks! :-)
>
> On Tue, Dec 5, 2023 at 12:28 Tom Keffer  wrote:
>
>> Good point, Jeff
>>
>> Looking at April 2023, the plot suggests wind direction is mostly SSE. 
>> The monthly summary 
>>  
>> the same.
>>
>> Still, I'd like to see the database, if possible.
>>
>> -tk
>>
>> On Tue, Dec 5, 2023 at 11:12 AM Jeff A. D.  wrote:
>>
>>> Looks like those are daily plots?  Should each plot correspond with the 
>>> dominant direction (DOM DIR), the last column of the monthly NOAA report? 
>>>
>>> On Tuesday, December 5, 2023 at 8:27:30 AM UTC-7 Tom Keffer wrote:
>>>
 That is an odd graph of wind direction. I looked over a one-year plot 
 of wind direction at my location, and it has a similar look. But then, I 
 live in a gorge where the wind almost always blows east or west, 
 occasionally from the south, almost never from the north.

 [image: image.png]

 Is there some way you could make your database available to me? Perhaps 
 put it on a Google Drive, or FTP server? I'd like to take a closer look.

 -tk

 On Mon, Dec 4, 2023 at 5:36 PM Rob Cranfill  wrote:

> Hi, all! Longtime user, and hoping this isn't too dumb a question.
>
> I have seen the ongoing discussions about the inherent difficulty of 
> calculating "average wind direction" and am wondering if maybe that issue 
> is what is causing the weirdness in this long-term graph, like this 
> (taken 
> from http://robcranfill.net/weather, which you are free to peruse!)
>
> [image: yearwinddir]
>
> This is my yearly data, and I'm sure the wind does *not* actually blow 
> like that. I had a friend/user ask me about why the graph looks like 
> this, 
> and I had no answer, except to say "No, there is nothing preventing my 
> weather vane from pointing any way the wind blows!" :-)
>
> Thanks for any info,
>   rob in seattle
>
> -- 
> 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/e1a39ce9-ad57-4750-a181-211e87d6aa21n%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+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/9c4c47fa-5c2b-4e92-95b2-def016a0b50an%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/AiRP8V9t90w/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/CAPq0zEBrsbJkSGYBAWbAVB0P6hVC%3Du%2BX3-70tWbHGBKPRRcG9Q%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/8d895fd6-bca6-44a7-b5d0-c2ad78bd8643n%40googlegroups.com.

Re: [weewx-user] Wind direction graph weirdness

[Rob Cranfill]

I’ll figure out how to do that and let ya know. Thanks! :-)

On Tue, Dec 5, 2023 at 12:28 Tom Keffer  wrote:

> Good point, Jeff
>
> Looking at April 2023, the plot suggests wind direction is mostly SSE. The 
> monthly
> summary
> 
> the same.
>
> Still, I'd like to see the database, if possible.
>
> -tk
>
> On Tue, Dec 5, 2023 at 11:12 AM Jeff A. D.  wrote:
>
>> Looks like those are daily plots?  Should each plot correspond with the
>> dominant direction (DOM DIR), the last column of the monthly NOAA report?
>>
>> On Tuesday, December 5, 2023 at 8:27:30 AM UTC-7 Tom Keffer wrote:
>>
>>> That is an odd graph of wind direction. I looked over a one-year plot of
>>> wind direction at my location, and it has a similar look. But then, I live
>>> in a gorge where the wind almost always blows east or west, occasionally
>>> from the south, almost never from the north.
>>>
>>> [image: image.png]
>>>
>>> Is there some way you could make your database available to me? Perhaps
>>> put it on a Google Drive, or FTP server? I'd like to take a closer look.
>>>
>>> -tk
>>>
>>> On Mon, Dec 4, 2023 at 5:36 PM Rob Cranfill  wrote:
>>>
 Hi, all! Longtime user, and hoping this isn't too dumb a question.

 I have seen the ongoing discussions about the inherent difficulty of
 calculating "average wind direction" and am wondering if maybe that issue
 is what is causing the weirdness in this long-term graph, like this (taken
 from http://robcranfill.net/weather, which you are free to peruse!)

 [image: yearwinddir]

 This is my yearly data, and I'm sure the wind does *not* actually blow
 like that. I had a friend/user ask me about why the graph looks like this,
 and I had no answer, except to say "No, there is nothing preventing my
 weather vane from pointing any way the wind blows!" :-)

 Thanks for any info,
   rob in seattle

 --
 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/e1a39ce9-ad57-4750-a181-211e87d6aa21n%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/9c4c47fa-5c2b-4e92-95b2-def016a0b50an%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/AiRP8V9t90w/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/CAPq0zEBrsbJkSGYBAWbAVB0P6hVC%3Du%2BX3-70tWbHGBKPRRcG9Q%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/CAOVFAvrFB42%2BZDeWJZViaCgM-B5D3KsKNm8gqLh7n2ff8oX3kA%40mail.gmail.com.

Re: [weewx-user] Wind direction graph weirdness

[Tom Keffer]

Good point, Jeff

Looking at April 2023, the plot suggests wind direction is mostly SSE.
The monthly
summary

the same.

Still, I'd like to see the database, if possible.

-tk

On Tue, Dec 5, 2023 at 11:12 AM Jeff A. D.  wrote:

> Looks like those are daily plots?  Should each plot correspond with the
> dominant direction (DOM DIR), the last column of the monthly NOAA report?
>
> On Tuesday, December 5, 2023 at 8:27:30 AM UTC-7 Tom Keffer wrote:
>
>> That is an odd graph of wind direction. I looked over a one-year plot of
>> wind direction at my location, and it has a similar look. But then, I live
>> in a gorge where the wind almost always blows east or west, occasionally
>> from the south, almost never from the north.
>>
>> [image: image.png]
>>
>> Is there some way you could make your database available to me? Perhaps
>> put it on a Google Drive, or FTP server? I'd like to take a closer look.
>>
>> -tk
>>
>> On Mon, Dec 4, 2023 at 5:36 PM Rob Cranfill  wrote:
>>
>>> Hi, all! Longtime user, and hoping this isn't too dumb a question.
>>>
>>> I have seen the ongoing discussions about the inherent difficulty of
>>> calculating "average wind direction" and am wondering if maybe that issue
>>> is what is causing the weirdness in this long-term graph, like this (taken
>>> from http://robcranfill.net/weather, which you are free to peruse!)
>>>
>>> [image: yearwinddir]
>>>
>>> This is my yearly data, and I'm sure the wind does *not* actually blow
>>> like that. I had a friend/user ask me about why the graph looks like this,
>>> and I had no answer, except to say "No, there is nothing preventing my
>>> weather vane from pointing any way the wind blows!" :-)
>>>
>>> Thanks for any info,
>>>   rob in seattle
>>>
>>> --
>>> 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/e1a39ce9-ad57-4750-a181-211e87d6aa21n%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/9c4c47fa-5c2b-4e92-95b2-def016a0b50an%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/CAPq0zEBrsbJkSGYBAWbAVB0P6hVC%3Du%2BX3-70tWbHGBKPRRcG9Q%40mail.gmail.com.

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 top

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.

Re: [weewx-user] Wind direction graph weirdness

[Jeff A. D.]

Looks like those are daily plots?  Should each plot correspond with the 
dominant direction (DOM DIR), the last column of the monthly NOAA report? 

On Tuesday, December 5, 2023 at 8:27:30 AM UTC-7 Tom Keffer wrote:

> That is an odd graph of wind direction. I looked over a one-year plot of 
> wind direction at my location, and it has a similar look. But then, I live 
> in a gorge where the wind almost always blows east or west, occasionally 
> from the south, almost never from the north.
>
> [image: image.png]
>
> Is there some way you could make your database available to me? Perhaps 
> put it on a Google Drive, or FTP server? I'd like to take a closer look.
>
> -tk
>
> On Mon, Dec 4, 2023 at 5:36 PM Rob Cranfill  wrote:
>
>> Hi, all! Longtime user, and hoping this isn't too dumb a question.
>>
>> I have seen the ongoing discussions about the inherent difficulty of 
>> calculating "average wind direction" and am wondering if maybe that issue 
>> is what is causing the weirdness in this long-term graph, like this (taken 
>> from http://robcranfill.net/weather, which you are free to peruse!)
>>
>> [image: yearwinddir]
>>
>> This is my yearly data, and I'm sure the wind does *not* actually blow 
>> like that. I had a friend/user ask me about why the graph looks like this, 
>> and I had no answer, except to say "No, there is nothing preventing my 
>> weather vane from pointing any way the wind blows!" :-)
>>
>> Thanks for any info,
>>   rob in seattle
>>
>> -- 
>> 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/e1a39ce9-ad57-4750-a181-211e87d6aa21n%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/9c4c47fa-5c2b-4e92-95b2-def016a0b50an%40googlegroups.com.

Re: [weewx-user] Pipe errors etc

[hind...@gmail.com]

Thanks.  I might end up having to try one of these options.

On Tuesday 5 December 2023 at 15:19:35 UTC gary@gmail.com wrote:

> I went with a WiFiLogger2 which has performed without a hitch for a couple 
> of years now.
> The maker also has an Ethernet unit if you don't want the added heat from 
> a radio in your console.
>
> https://wifilogger.net/
>
> https://wifilogger.net/ethernet.html
>
> On Tuesday, December 5, 2023 at 6:54:14 AM UTC-5 hind...@gmail.com wrote:
>
>> I have recently moved a BT Wholehome Wifi disc a little closer to the 
>> Console  (10cm now; was 100cm)  , so I guess that *might* be 
>> "interfering" in some way  - I will try moving it further away again to see 
>> if that solves the problem.  I have already re-seated the WLIP logger a few 
>> times. Incidentally, if Davis no longer make the WLIP logger, does anyone 
>> know what the the preferred method now is of getting the data from the 
>> weather station to weewx etc?
>>
>> I may also try the different drive that was suggested in 
>> https://groups.google.com/g/weewx-user/c/q67cvEsXtjQ/m/7difZtkUAgAJ.
>>
>> Regarding the question in 
>> https://groups.google.com/g/weewx-user/c/q67cvEsXtjQ/m/J9W5KA7rAQAJ, I 
>> haven't changed anything on my network, other than moving a few ethernet 
>> cables for other devices around, due to an unstable Sky TV connection.
>>
>> Thanks to everyone that has commented on this to help me find a 
>> solution.  Much appreciated.
>>
>> David.
>>
>> On Tuesday 5 December 2023 at 00:25:06 UTC Tom Keffer wrote:
>>
>>> That's certainly possible. I'd say ask Davis, but this logger has been 
>>> so long out of production that I doubt David would get any satisfaction out 
>>> of them.
>>>
>>> I'm also suspicious when electronic devices "just break." That's very 
>>> rare. But, it does happen.
>>>
>>> One thing you could try: reseating the logger. 
>>>
>>> Oh, and is there any new source of RF nearby? A new router? Satellite 
>>> dish? 5 kW pirate radio?
>>>
>>> On Mon, Dec 4, 2023 at 4:17 PM Graham Eddy  wrote:
>>>
 the vantage IP device seems to accept a connection, work for a while, 
 then stop responding, then connection is reset → sounds like on device 
 side 
 it seizes up and the ip protocol times out; establishing new connection 
 just repeats the cycle. the device apparently has been working for years 
 and is now failing → sounds like device has broken
 *⊣GE⊢*

 On 5 Dec 2023, at 9:23 am, vince  wrote:

 Just a thought, but when I see "weewx.drivers.vantage: ip-read error: 
 timed out" that makes me think your network is unstable.   From your 
 posts in the thread it 'sounds' like it has been working for years without 
 issues.  Did you change anything on your network ? Did you change any 
 firewall settings on your pi or install something like fail2ban or pihole 
 recently ?


 -- 
 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/6B5C1B94-55F5-484D-8E8E-3142F471AE4C%40geddy.au
  
 
 .

>>>

-- 
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/e65e8a9c-47ec-45a2-8711-13ac39cd814fn%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.

[weewx-user] Bass.dll V2.4 Download

[Chiquita Palafox]

Errors related to bass.dll can arise for a few different different reasons. 
For instance, a faulty application, bass.dll has been deleted or misplaced, 
corrupted by malicious software present on your PC or a damaged Windows 
registry.
bass.dll v2.4 download

*Download Zip* https://urluss.com/2wIrzw


In the vast majority of cases, the solution is to properly reinstall 
bass.dll on your PC, to the Windows system folder. Alternatively, some 
programs, notably PC games, require that the DLL file is placed in the 
game/application installation folder.

The size of this dynamic link library is *0.11 MB* and its download links 
are healthy. It has been downloaded *27001* times already and it has 
received *3.5* out of *5 stars*.

If you don't know how to install the *Bass.dll* library you will download 
from our site, you can browse the methods above. Above we explained all the 
processes you can do to fix the dll error you are receiving. If the error 
is continuing after you have completed all these methods, please use the 
comment form at the bottom of the page to contact us. Our editor will 
respond to your comment shortly.

When an application requires bass.dll, Windows will check the application 
and system folders for this .dll file. If the file is missing you may 
receive an error and the application may not function properly.Learn how to 
re-install bass.dll.

To fix the error, you need to copy the missing Bass.dll file to your system 
or replace the corrupted dll file with a working one by following the 
instructions below. There are 6 different versions of the dll file 
available for download with sizes between 90.05KB - 125.18KB.

You can download Bass.dll for free from the download section on this page. 
After downloading the zip file, unzip it to a convenient location on your 
computer. In order to fix dll related errors, you need to copy the .dll 
file to the installation folder of the application/game, or install .dll 
file directly to Windows (Windows XP, Vista, Windows 7, Windows 10).

CLEO requires an 'ASI Loader' installed to run which is provided with the 
release. The ASI Loader requires overwriting one original game file: 
vorbisFile.dll - be sure to make a backup of this file. No additional files 
are replaced, however the following files and folders are added:
- cleo\ (CLEO script directory)
- cleo\FileSystemOperations.cleo (file system plugin)
- cleo\IniFiles.cleo (INI config plugin)
- cleo\IntOperations.cleo (INT operations plugin)
- cleo\cleo_saves\ (CLEO save directory)
- cleo\cleo_text\ (CLEO text directory)
- cleo.asi (core library)
- bass.dll (audio engine library)
- vorbisHooked.dll (Silent's ASI Loader)All plugins are optional, however 
they may be required by various CLEO scripts.CLEO 4 for San Andreas needs 
the BASS.dll v2.4 to be installed. This dll file can be downloaded from the 
official site of Un4seen Developments Ltd. Compatibility Mode CLEO is 
continually being improved and extended over time. In very rare 
circumstances, some scripts written for CLEO 3 may not work while using 
CLEO 4. However, since CLEO 4.3 you are able to enable a 'legacy mode' to 
increase compatibility with CLEO 3 scripts by naming them with the 
extension .cs3. CLEO 4.3 will load .cs and

After Alien's retirement, the development slowed down until Silent issued a 
patch to the latest available version. Soon after that DK22Pac announced 
the next version of CLEO for GTA 3 and Vice City, written from scratch. It 
was never released, but ThirteenAG helped to finish his work and CLEO 2.0 
for GTA 3 and VC is now available for download.

Descarga el siguiente bass.dll para resolver tu problema dll. En este 
momento tenemos disponibles 7 versiones diferentes de este archivo.
Elige sabiamente. La mayoría de las veces basta con elegir la versión más 
alta.

Los errores relacionados con bass.dll pueden producirse por distintas 
razones. Por ejemplo, una aplicación defectuosa, bass.dll, se ha eliminado 
o ubicado de forma incorrecta, ha sido corrompida por un software malicioso 
en tu PC o un registro de Windows dañado.

En la mayoría de los casos, la solución consiste en volver a instalar 
adecuadamente bass.dll en tu PC, en la carpeta de sistema de Windows. Por 
otra parte, algunos programas, sobre todo los juegos para PC, requieren que 
el archivo de DLL se encuentre ubicado en la carpeta de instalación del 
juego/aplicación.

BASS files such as bass.dll utilize the DLL file extension. This file is 
considered a Win32 DLL (Dynamic link library) file, and was first created 
by NextUp.com for the TextAloud 3.0.83 software package.

Bass.dll is considered a type of Dynamic Link Library (DLL) file. Dynamic 
Link Library files, like bass.dll, are essentially a "guide book" that 
stores information and instructions for executable (EXE) files - like 
MpSigStub.exe - to follow. These files were created so that multiple 
programs (eg. TextAloud) could share the same bass.dll file, saving 
valuable memory a

[weewx-user] Override: Mech City Brawl Torrent Download [pack]

[Chiquita Palafox]

No gears, no glory! Control gigantic fighting robots and duke it out across 
fantastic cityscapes in this 3D mech-based brawler! Epic and explosive 
battles await with anime-inspired mechs in local and online versus game 
modes, party co-op with two to four players, and a single-player campaign.
Pilot a diverse roster of epic, skyscraper-sized mechs, each with their own 
play style, special moves, and finishers in the ultimate mech fighting 
game! Tower over your opponents and lay waste to entire cities underfoot. 
Destroy 3D arenas modeled after actual cities and countries, including 
Tokyo, Egypt, San Francisco, and Mexico. Challenge other players, gathering 
two to four friends to engage in dynamic co-op gameplay where each player 
is responsible for one part of a towering mech! Customize your mechs in the 
Garage, changing their accessories and skins to create your own unique 
style!
Override: Mech City Brawl Torrent Download [pack]

*Download File* https://urluss.com/2wIrzs


eebf2c3492

-- 
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/ab8fe576-cc67-4e1f-8902-6cdcbf3c6eb2n%40googlegroups.com.

[weewx-user] Agent

[Chiquita Palafox]

A Dialogflow agent is a virtual agent that handles concurrent conversations 
with your end-users. It is a natural language understanding module that 
understands the nuances of human language. Dialogflow translates end-user 
text or audio during a conversation to structured data that your apps and 
services can understand. You design and build a Dialogflow agent to handle 
the types of conversations required for your system.

An enrolled agent is a person who has earned the privilege of representing 
taxpayers before the Internal Revenue Service by either passing a 
three-part comprehensive IRS test covering individual and business tax 
returns, or through experience as a former IRS employee. Enrolled agent 
status is the highest credential the IRS awards. Individuals who obtain 
this elite status must adhere to ethical standards and complete 72 hours of 
continuing education courses every three years.

Enrolled agents, like attorneys and certified public accountants (CPAs), 
have unlimited practice rights. This means they are unrestricted as to 
which taxpayers they can represent, what types of tax matters they can 
handle, and which IRS offices they can represent clients before. Learn more 
about enrolled agents in Treasury Department Circular 230PDF.
agent

*DOWNLOAD* https://urluss.com/2wIrzl


The agent section specifies where the entire Pipeline, or a specific 
stage,will execute in the Jenkins environment depending on where the 
agentsection is placed. The section must be defined at the top-level inside 
thepipeline block, but stage-level usage is optional.

In agents declared at the top level of a Pipeline, an agent is allocated 
and then the timeout option is applied.The time to allocate the agent *is 
not included* in the limit set by the timeout option.

In agents declared within a stage, the options are invoked *before* 
allocating the agent and *before* checking any when conditions.In this 
case, when using timeout, it is applied *before* the agent is allocated.The 
time to allocate the agent *is included* in the limit set by the timeout 
option.

In order to support the wide variety of use-cases Pipeline authors may 
have,the agent section supports a few different types of parameters. 
Theseparameters can be applied at the top-level of the pipeline block, or 
withineach stage directive.

When applied at the top-level of the pipeline block no global agentwill be 
allocated for the entire Pipeline run and each stage section willneed to 
contain its own agent section. For example: agent none

Execute the Pipeline, or stage, with the given container which will 
bedynamically provisioned on a node pre-configured toaccept Docker-based 
Pipelines, or on a node matching the optionally definedlabel parameter. 
docker also optionally accepts an args parameterwhich may contain arguments 
to pass directly to a docker run invocation, andan alwaysPull option, which 
will force a docker pull even if the imagename is already present.For 
example: agent docker 'maven:3.8.7-eclipse-temurin-11' or

A string. Run the Pipeline or individual stage this agentis applied to 
within this custom workspace, rather than the default. It can beeither a 
relative path, in which case the custom workspace will be under 
theworkspace root on the node, or an absolute path. For example:

The stage directive goes in the stages section and should contain asteps 
section, an optional agent section, or other stage-specific 
directives.Practically speaking, all of the real work done by a Pipeline 
will be wrappedin one or more stage directives.

The input directive on a stage allows you to prompt for input, using 
theinput step.The stage will pause after any options have been applied, and 
beforeentering the agent block for that stage or evaluating the when 
condition of the stage. If the inputis approved, the stage will then 
continue. Any parameters provided as part ofthe input submission will be 
available in the environment for the rest of thestage.

By default, the when condition for a stage will be evaluated afterentering 
the agent for that stage, if one is defined. However, this canbe changed by 
specifying the beforeAgent option within the whenblock. If beforeAgent is 
set to true, the when condition will beevaluated first, and the agent will 
only be entered if the whencondition evaluates to true.

Stages in Declarative Pipeline may have a stages section containing a list 
of nested stages to be run in sequential order.Note that a stage must have 
one and only one of steps, stages, parallel, or matrix.It is not possible 
to nest a parallel or matrix block within a stage directive if that 
stagedirective is nested within a parallel or matrix block itself. However, 
a stagedirective within a parallel or matrix block can use all other 
functionality of a stage,including agent, tools, when, etc.

Stages in Declarative Pipeline may have a parallel section containing a 
list of nested stages to be run in parallel.Note that a st

[weewx-user] Prem Kahani Movie Video Song 13

[Chiquita Palafox]

Kishore also worked with other composers including Rajesh Roshan, Sapan 
Chakraborty and Bappi Lahiri. Kumar sang "Bhool Gaya Sab Kuchh" (duet with 
Lata Mangeshkar) and "Dil Kya Kare Jab Kisise" for Rajesh Roshan's film 
*Julie*.[59] Their other songs include "Yaadon Mein Woh" from *Swami*, 
"Chhookar Mere Man Ko Kiya Toone Kya Ishaara" from *Yaarana*, "Kaha Tak Ye 
Manko Andher Chalenge" from *Baton Baton Mein*, "O Yara Tu Yaro Se Hai 
Pyar", and "Laharon Ki Tatah Yaadien" (1983) and *Kahiye, Suniye* (duet 
with Asha Bhosle) from *Baton Baton Mein*. Bappi Lahiri also recorded many 
songs with Kumar, including *Pag Ghunghroo Bandh* from *Namak Halaal* 
(1982), *Manzilen Apni Jagah Hai* from *Sharaabi* (1984), "Chalate Chalte 
Mere Ye Geet Yad Rakhana" from *Chalte Chalte* (1975) and "Saason Se Nahi 
Kadmose Nahi" from *Mohabbat* (1987) and duets with Lata Mangeshkar such as 
"Albela Mausam" and "Pyar Ka Tohfa" from *Tohfa* (1984). The Kishore and 
Bappi pair also recorded hits in Bengali, including "Chirodini Tumi Je 
Amar" from *Amar Sangi* (1987) and "E Amar Gurudakshina" from *Gurudakshina* 
(1987). Another Bengali musician was Ajay Das, who composed many hit songs 
in Kumar's voice. He also recorded a duet song *Hello Hello Kya Haal Hai* 
with Asha Bhosle for Naushad in 1975 for the movie *Sunehra Sansar*, the 
only song of Kishore. He also worked with music directors Basu and Manohari 
Singh for duets such as "Wada Karo Jaanam" and "Dariya Kinare" for the film 
*Sabse 
Bada Rupaiya* and "Aa Humsafar" for the film *Chatpatee*.[*citation needed*]
prem kahani movie video song 13

*DOWNLOAD* https://urluss.com/2wIrzk


eebf2c3492

-- 
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/e2a96491-cef3-4dc0-a2f4-58bb763a8ea0n%40googlegroups.com.

Re: [weewx-user] Wind direction graph weirdness

[Tom Keffer]

That is an odd graph of wind direction. I looked over a one-year plot of
wind direction at my location, and it has a similar look. But then, I live
in a gorge where the wind almost always blows east or west, occasionally
from the south, almost never from the north.

[image: image.png]

Is there some way you could make your database available to me? Perhaps put
it on a Google Drive, or FTP server? I'd like to take a closer look.

-tk

On Mon, Dec 4, 2023 at 5:36 PM Rob Cranfill  wrote:

> Hi, all! Longtime user, and hoping this isn't too dumb a question.
>
> I have seen the ongoing discussions about the inherent difficulty of
> calculating "average wind direction" and am wondering if maybe that issue
> is what is causing the weirdness in this long-term graph, like this (taken
> from http://robcranfill.net/weather, which you are free to peruse!)
>
> [image: yearwinddir]
>
> This is my yearly data, and I'm sure the wind does *not* actually blow
> like that. I had a friend/user ask me about why the graph looks like this,
> and I had no answer, except to say "No, there is nothing preventing my
> weather vane from pointing any way the wind blows!" :-)
>
> Thanks for any info,
>   rob in seattle
>
> --
> 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/e1a39ce9-ad57-4750-a181-211e87d6aa21n%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/CAPq0zEBcQtX%3DgHw0iqjuz9956-m__zC8_AttM6SODWKxDcsECw%40mail.gmail.com.

Re: [weewx-user] Pipe errors etc

[gary....@gmail.com]

I went with a WiFiLogger2 which has performed without a hitch for a couple 
of years now.
The maker also has an Ethernet unit if you don't want the added heat from a 
radio in your console.

https://wifilogger.net/

https://wifilogger.net/ethernet.html

On Tuesday, December 5, 2023 at 6:54:14 AM UTC-5 hind...@gmail.com wrote:

> I have recently moved a BT Wholehome Wifi disc a little closer to the 
> Console  (10cm now; was 100cm)  , so I guess that *might* be 
> "interfering" in some way  - I will try moving it further away again to see 
> if that solves the problem.  I have already re-seated the WLIP logger a few 
> times. Incidentally, if Davis no longer make the WLIP logger, does anyone 
> know what the the preferred method now is of getting the data from the 
> weather station to weewx etc?
>
> I may also try the different drive that was suggested in 
> https://groups.google.com/g/weewx-user/c/q67cvEsXtjQ/m/7difZtkUAgAJ.
>
> Regarding the question in 
> https://groups.google.com/g/weewx-user/c/q67cvEsXtjQ/m/J9W5KA7rAQAJ, I 
> haven't changed anything on my network, other than moving a few ethernet 
> cables for other devices around, due to an unstable Sky TV connection.
>
> Thanks to everyone that has commented on this to help me find a solution.  
> Much appreciated.
>
> David.
>
> On Tuesday 5 December 2023 at 00:25:06 UTC Tom Keffer wrote:
>
>> That's certainly possible. I'd say ask Davis, but this logger has been so 
>> long out of production that I doubt David would get any satisfaction out of 
>> them.
>>
>> I'm also suspicious when electronic devices "just break." That's very 
>> rare. But, it does happen.
>>
>> One thing you could try: reseating the logger. 
>>
>> Oh, and is there any new source of RF nearby? A new router? Satellite 
>> dish? 5 kW pirate radio?
>>
>> On Mon, Dec 4, 2023 at 4:17 PM Graham Eddy  wrote:
>>
>>> the vantage IP device seems to accept a connection, work for a while, 
>>> then stop responding, then connection is reset → sounds like on device side 
>>> it seizes up and the ip protocol times out; establishing new connection 
>>> just repeats the cycle. the device apparently has been working for years 
>>> and is now failing → sounds like device has broken
>>> *⊣GE⊢*
>>>
>>> On 5 Dec 2023, at 9:23 am, vince  wrote:
>>>
>>> Just a thought, but when I see "weewx.drivers.vantage: ip-read error: 
>>> timed out" that makes me think your network is unstable.   From your 
>>> posts in the thread it 'sounds' like it has been working for years without 
>>> issues.  Did you change anything on your network ? Did you change any 
>>> firewall settings on your pi or install something like fail2ban or pihole 
>>> recently ?
>>>
>>>
>>> -- 
>>> 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/6B5C1B94-55F5-484D-8E8E-3142F471AE4C%40geddy.au
>>>  
>>> 
>>> .
>>>
>>

-- 
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/021e0ca9-fd6a-4178-b932-fc30c9cfadfen%40googlegroups.com.

Re: [weewx-user] Pipe errors etc

[hind...@gmail.com]

I have recently moved a BT Wholehome Wifi disc a little closer to the 
Console  (10cm now; was 100cm)  , so I guess that *might* be "interfering" 
in some way  - I will try moving it further away again to see if that 
solves the problem.  I have already re-seated the WLIP logger a few times. 
Incidentally, if Davis no longer make the WLIP logger, does anyone know 
what the the preferred method now is of getting the data from the weather 
station to weewx etc?

I may also try the different drive that was suggested 
in https://groups.google.com/g/weewx-user/c/q67cvEsXtjQ/m/7difZtkUAgAJ.

Regarding the question 
in https://groups.google.com/g/weewx-user/c/q67cvEsXtjQ/m/J9W5KA7rAQAJ, I 
haven't changed anything on my network, other than moving a few ethernet 
cables for other devices around, due to an unstable Sky TV connection.

Thanks to everyone that has commented on this to help me find a solution.  
Much appreciated.

David.

On Tuesday 5 December 2023 at 00:25:06 UTC Tom Keffer wrote:

> That's certainly possible. I'd say ask Davis, but this logger has been so 
> long out of production that I doubt David would get any satisfaction out of 
> them.
>
> I'm also suspicious when electronic devices "just break." That's very 
> rare. But, it does happen.
>
> One thing you could try: reseating the logger. 
>
> Oh, and is there any new source of RF nearby? A new router? Satellite 
> dish? 5 kW pirate radio?
>
> On Mon, Dec 4, 2023 at 4:17 PM Graham Eddy  wrote:
>
>> the vantage IP device seems to accept a connection, work for a while, 
>> then stop responding, then connection is reset → sounds like on device side 
>> it seizes up and the ip protocol times out; establishing new connection 
>> just repeats the cycle. the device apparently has been working for years 
>> and is now failing → sounds like device has broken
>> *⊣GE⊢*
>>
>> On 5 Dec 2023, at 9:23 am, vince  wrote:
>>
>> Just a thought, but when I see "weewx.drivers.vantage: ip-read error: 
>> timed out" that makes me think your network is unstable.   From your 
>> posts in the thread it 'sounds' like it has been working for years without 
>> issues.  Did you change anything on your network ? Did you change any 
>> firewall settings on your pi or install something like fail2ban or pihole 
>> recently ?
>>
>>
>> -- 
>> 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/6B5C1B94-55F5-484D-8E8E-3142F471AE4C%40geddy.au
>>  
>> 
>> .
>>
>

-- 
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/f554b857-491d-46e2-8a6e-98d61a4415d7n%40googlegroups.com.

Re: [weewx-user] Pipe errors etc

[Tomás]

Hello, I think I had the same wakeup problem with the weatherlink, found a 
way out using this driver: 
https://github.com/chaunceygardiner/weewx-vantagenext

In my case weewx restarted repeatedly after getting loop packets failed, 
unfortunately I did not document the error.

Hope it helps,

Tomás.-


On Monday, 4 December 2023 at 21:25:06 UTC-3 Tom Keffer wrote:

> That's certainly possible. I'd say ask Davis, but this logger has been so 
> long out of production that I doubt David would get any satisfaction out of 
> them.
>
> I'm also suspicious when electronic devices "just break." That's very 
> rare. But, it does happen.
>
> One thing you could try: reseating the logger. 
>
> Oh, and is there any new source of RF nearby? A new router? Satellite 
> dish? 5 kW pirate radio?
>
> On Mon, Dec 4, 2023 at 4:17 PM Graham Eddy  wrote:
>
>> the vantage IP device seems to accept a connection, work for a while, 
>> then stop responding, then connection is reset → sounds like on device side 
>> it seizes up and the ip protocol times out; establishing new connection 
>> just repeats the cycle. the device apparently has been working for years 
>> and is now failing → sounds like device has broken
>> *⊣GE⊢*
>>
>> On 5 Dec 2023, at 9:23 am, vince  wrote:
>>
>> Just a thought, but when I see "weewx.drivers.vantage: ip-read error: 
>> timed out" that makes me think your network is unstable.   From your 
>> posts in the thread it 'sounds' like it has been working for years without 
>> issues.  Did you change anything on your network ? Did you change any 
>> firewall settings on your pi or install something like fail2ban or pihole 
>> recently ?
>>
>>
>> -- 
>> 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/6B5C1B94-55F5-484D-8E8E-3142F471AE4C%40geddy.au
>>  
>> 
>> .
>>
>

-- 
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/b58a2be7-a1e0-4bf9-abc9-812c11024362n%40googlegroups.com.

[weewx-user] NEW_ACHIVE_RECORD event chronology

[jterr...@gmail.com]

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.