[weewx-user] Re: WMR300 testing LAST Driver

[Paul Lacatus]

Hi everybody , 

I have installed a Weewx on a Raspbian Stretch last version. Raspberry pi 
used is B2.0 with BCM2835 rev. 000e.  The station is WMR300 . It took me a 
long time to find this driver 0.19rc5 . With 0.19rc3 was working for around 
1.5 2 hours and exiting without error in syslog. Now the 0.19rc5 is working 
for more than 8 hours and counting.

Thank you for your work and development

Paul 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

I have 10 days uptime with this driver version.

I think all is stable now :-D

Thank's a lot for your work.

El sábado, 17 de marzo de 2018, 13:53:04 (UTC+1), Ruben Navarro Huedo 
escribió:
>
> I am trying it now.
>
> I will tell result in some hours.
>
> Mar 17 13:51:31 MeteoElche weewx[9026]: wmr300: content: d2 80 00 3f 
> ee ee ee 00 0a 00 e9 00 00 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 20 04 
> 7f 7f 7f 7f 7f 7f 7f 00 08 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f fd 
> 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f fd 7f ff 00 15 00 02 00 02 00 
> 14 00 00 00 00 00 00 02 00 11 03 09 0f 01 00 00 27 e1 01 7f ff 7f ff 7f ff 
> 7f ff 7f 7f 7f 7f 7f 7f 7f 7f ff 7f ff 7f ff 00 00 00 00 00 00 00 0f 01
> Mar 17 13:52:20 MeteoElche weewx[9026]: wmr300: get history complete: 
> count=0 last_index=15584 history_end_index=15585
> Mar 17 13:52:20 MeteoElche weewx[9026]: engine: Starting main packet loop.
> Mar 17 13:52:21 MeteoElche weewx[9026]: wmr300: dump history
> Mar 17 13:52:21 MeteoElche weewx[9026]: wmr300: reading records since 
> 2018-03-17 13:52:21 CET (1521291141) (last_index=15584 
> history_end_index=15585)
> Mar 17 13:52:21 MeteoElche weewx[9026]: wmr300: get history complete: 
> count=0 last_index=15584 history_end_index=15585
>
>
>
> El sábado, 17 de marzo de 2018, 1:18:02 (UTC+1), Cameron D escribió:
>>
>> Following up on my last post, I decided to bump the failure rate and ran 
>> raid-check every day.
>> This revealed gaps up to 2 minutes between heartbeats, which confirmed 
>> the diagnosis, so I have added the code to send a restart and it seems to 
>> be keeping it alive.
>>
>> I have attached what I hope is a working version, with various diagnostic 
>> log outputs.
>>
>> Ruben, it would be good if you could try this out.  I don't think your 
>> problems relate to the actual history reset code, but if you could leave 
>> the history_limit value at 5 or 6% then it helps confirm that that code is 
>> OK.  In fact, I can't think of a good reason to have it much higher than 
>> that.
>>
>> Cameron.
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

I am trying it now.

I will tell result in some hours.

Mar 17 13:51:31 MeteoElche weewx[9026]: wmr300: content: d2 80 00 3f ee 
ee ee 00 0a 00 e9 00 00 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 20 04 7f 
7f 7f 7f 7f 7f 7f 00 08 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f fd 7f 
ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f fd 7f ff 00 15 00 02 00 02 00 14 
00 00 00 00 00 00 02 00 11 03 09 0f 01 00 00 27 e1 01 7f ff 7f ff 7f ff 7f 
ff 7f 7f 7f 7f 7f 7f 7f 7f ff 7f ff 7f ff 00 00 00 00 00 00 00 0f 01
Mar 17 13:52:20 MeteoElche weewx[9026]: wmr300: get history complete: 
count=0 last_index=15584 history_end_index=15585
Mar 17 13:52:20 MeteoElche weewx[9026]: engine: Starting main packet loop.
Mar 17 13:52:21 MeteoElche weewx[9026]: wmr300: dump history
Mar 17 13:52:21 MeteoElche weewx[9026]: wmr300: reading records since 
2018-03-17 13:52:21 CET (1521291141) (last_index=15584 
history_end_index=15585)
Mar 17 13:52:21 MeteoElche weewx[9026]: wmr300: get history complete: 
count=0 last_index=15584 history_end_index=15585



El sábado, 17 de marzo de 2018, 1:18:02 (UTC+1), Cameron D escribió:
>
> Following up on my last post, I decided to bump the failure rate and ran 
> raid-check every day.
> This revealed gaps up to 2 minutes between heartbeats, which confirmed the 
> diagnosis, so I have added the code to send a restart and it seems to be 
> keeping it alive.
>
> I have attached what I hope is a working version, with various diagnostic 
> log outputs.
>
> Ruben, it would be good if you could try this out.  I don't think your 
> problems relate to the actual history reset code, but if you could leave 
> the history_limit value at 5 or 6% then it helps confirm that that code is 
> OK.  In fact, I can't think of a good reason to have it much higher than 
> that.
>
> Cameron.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Cameron D]

Following up on my last post, I decided to bump the failure rate and ran 
raid-check every day.
This revealed gaps up to 2 minutes between heartbeats, which confirmed the 
diagnosis, so I have added the code to send a restart and it seems to be 
keeping it alive.

I have attached what I hope is a working version, with various diagnostic 
log outputs.

Ruben, it would be good if you could try this out.  I don't think your 
problems relate to the actual history reset code, but if you could leave 
the history_limit value at 5 or 6% then it helps confirm that that code is 
OK.  In fact, I can't think of a good reason to have it much higher than 
that.

Cameron.

-- 
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.
For more options, visit https://groups.google.com/d/optout.
#!/usr/bin/env python
# vim: sw=4 ts=4 expandtab
# Copyright 2015 Matthew Wall
# See the file LICENSE.txt for your rights.
#
# Credits:
# Thanks to Cameron for diving deep into USB timing issues
#
# Thanks to Benji for the identification and decoding of 7 packet types
#
# Thanks to Eric G for posting USB captures and providing hardware for testing
#   https://groups.google.com/forum/#!topic/weewx-development/5R1ahy2NFsk
#
# Thanks to Zahlii
#   https://bsweather.myworkbook.de/category/weather-software/
#
# No thanks to oregon scientific - repeated requests for hardware and/or
# specifications resulted in no response at all.

# TODO: figure out battery level for each sensor
# TODO: figure out signal strength for each sensor
# TODO: figure out archive interval

# FIXME: figure out unknown bytes in history packet

# FIXME: decode the 0xdb packets

# FIXME: warn if altitude in pressure packet does not match weewx altitude

"""Driver for Oregon Scientific WMR300 weather stations.

Sensor data transmission frequencies:
  wind: 2.5 to 3 seconds
TH: 10 to 12 seconds
  rain: 20 to 24 seconds

The station supports 1 wind, 1 rain, 1 UV, and up to 8 temperature/humidity
sensors.

The station ships with "Weather OS PRO" software for windows.  This was used
for the USB sniffing.

Sniffing USB traffic shows all communication is interrupt.  The endpoint
descriptors for the device show this as well.  Response timing is 1.

It appears that communication must be initiated with an interrupted write.
After that, the station will spew data.  Sending commands to the station is
not reliable - like other Oregon Scientific hardware, there is a certain
amount of "send a command, wait to see what happens, then maybe send it again"
in order to communicate with the hardware.  Once the station does start sending
data, the driver basically just processes it based on the message type.  It
must also send "heartbeat" messages to keep the data flowing from the hardware.

Communication is confounded somewhat by the various libusb implementations.
Some communication "fails" with a "No data available" usb error.  But in other
libusb versions, this error does not appear.  USB timeouts are also tricky.
Since the WMR protocol seems to expect timeouts, it is necessary for the
driver to ignore them at some times, but not at others.  Since not every libusb
version includes a code/class to indicate that a USB error is a timeout, the
driver must do more work to figure it out.

The driver ignores USB timeouts.  It would seem that a timeout just means that
the station is not ready to communicate; it does not indicate a communication
failure.

Internal observation names use the convention name_with_specifier.  These are
mapped to the wview or other schema as needed with a configuration setting.
For example, for the wview schema, wind_speed maps to windSpeed, temperature_0
maps to inTemp, and humidity_1 maps to outHumidity.

Maximum value for rain counter is 400 in (10160 mm) (4 = 0x9c 0x40).  The
counter does not wrap; it must be reset when it hits maximum value otherwise
rain data will not be recorded.


Message types -

packet types from station:
57 - station type/model; history count + other status
41 - ACK
D2 - history; 128 bytes
D3 - temperature/humidity/dewpoint/heatindex; 61 bytes
D4 - wind/windchill; 54 bytes
D5 - rain; 40 bytes
D6 - pressure; 46 bytes
DB - forecast; 32 bytes
DC - temperature/humidity ranges; 62 bytes

packet types from host:
A6 - heartbeat - response is 57 (usually)
41 - ACK
65 - do not delete history when it is reported.  each of these is ack-ed by
   the station
b3 - delete history after you give it to me.
cd - start history request.  last two bytes are one after most recent read
35 - finish history request.  last two bytes are latest record index that
   was read.
73 - some sort of initialisation packet
72 - ? on rare occasions will be used in place of 73, in both observed cases
   the console was already free-r

[weewx-user] Re: WMR300 testing LAST Driver

[Cameron D]

OK, Finally another hang-up.  3 weeks to the day after the previous one.
As I suspected, it is due to the WMR300 console behaving as if it has not 
seen the heartbeat packets and so stops transmitting. The code then is 
stuck forever in genLooopPackets waiting for the next packet, which never 
comes.
I do have code in my experimental driver to resend the initialisation 
commands if it notices that the console has sent no packets in the hearbeat 
interval, so I think it would be a good idea for Matthew to implement that 
in his driver.  I will put it into my debug-laden RC5 but I am about to 
head off for a few days, so it won't be immediate. If anybody wants to try 
to confirm the issue I have attached my RC5 with extra debug log entries 
that list every time no packets are received for a while.

The "3 weeks to the day" turns out to be significant, as I noticed large 
delays in the logged graph generation times in the wee hours of every 
Tuesday morning. This happens to be when I run *raid-check*! Apparently 
"low" priority is not low enough.
This is somehow blocking weewx execution for long enough that the hearbeats 
do not get sent.
So one question is - is this specific to my system? I don't expect rasb pis 
to be running software raid drives, but there might be other activities 
that cause the same problems.

-- 
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.
For more options, visit https://groups.google.com/d/optout.
#!/usr/bin/env python
# vim: sw=4 ts=4 expandtab
# Copyright 2015 Matthew Wall
# See the file LICENSE.txt for your rights.
#
# Credits:
# Thanks to Cameron for diving deep into USB timing issues
#
# Thanks to Benji for the identification and decoding of 7 packet types
#
# Thanks to Eric G for posting USB captures and providing hardware for testing
#   https://groups.google.com/forum/#!topic/weewx-development/5R1ahy2NFsk
#
# Thanks to Zahlii
#   https://bsweather.myworkbook.de/category/weather-software/
#
# No thanks to oregon scientific - repeated requests for hardware and/or
# specifications resulted in no response at all.

# TODO: figure out battery level for each sensor
# TODO: figure out signal strength for each sensor
# TODO: figure out archive interval

# FIXME: figure out unknown bytes in history packet

# FIXME: decode the 0xdb packets

# FIXME: warn if altitude in pressure packet does not match weewx altitude

"""Driver for Oregon Scientific WMR300 weather stations.

Sensor data transmission frequencies:
  wind: 2.5 to 3 seconds
TH: 10 to 12 seconds
  rain: 20 to 24 seconds

The station supports 1 wind, 1 rain, 1 UV, and up to 8 temperature/humidity
sensors.

The station ships with "Weather OS PRO" software for windows.  This was used
for the USB sniffing.

Sniffing USB traffic shows all communication is interrupt.  The endpoint
descriptors for the device show this as well.  Response timing is 1.

It appears that communication must be initiated with an interrupted write.
After that, the station will spew data.  Sending commands to the station is
not reliable - like other Oregon Scientific hardware, there is a certain
amount of "send a command, wait to see what happens, then maybe send it again"
in order to communicate with the hardware.  Once the station does start sending
data, the driver basically just processes it based on the message type.  It
must also send "heartbeat" messages to keep the data flowing from the hardware.

Communication is confounded somewhat by the various libusb implementations.
Some communication "fails" with a "No data available" usb error.  But in other
libusb versions, this error does not appear.  USB timeouts are also tricky.
Since the WMR protocol seems to expect timeouts, it is necessary for the
driver to ignore them at some times, but not at others.  Since not every libusb
version includes a code/class to indicate that a USB error is a timeout, the
driver must do more work to figure it out.

The driver ignores USB timeouts.  It would seem that a timeout just means that
the station is not ready to communicate; it does not indicate a communication
failure.

Internal observation names use the convention name_with_specifier.  These are
mapped to the wview or other schema as needed with a configuration setting.
For example, for the wview schema, wind_speed maps to windSpeed, temperature_0
maps to inTemp, and humidity_1 maps to outHumidity.

Maximum value for rain counter is 400 in (10160 mm) (4 = 0x9c 0x40).  The
counter does not wrap; it must be reset when it hits maximum value otherwise
rain data will not be recorded.


Message types -

packet types from station:
57 - station type/model; history count + other status
41 - ACK
D2 - history; 128 bytes
D3 - temperature/humidity/dewpoint/heatindex; 61 bytes
D4 - wind

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

It is set to 5 minutes both values.
I cleared the console log but stability problem continues with RC5.

El domingo, 11 de febrero de 2018, 7:01:59 (UTC+1), Cameron D escribió:
>
> Hello Ruben,
> I cannot see where you have already said this, but can you report the 
> logging frequency of the WMR300 console and the archive interval you have 
> set in weewx.
> From the logs it look like WMR300 is set to 5 minutes.
>
> There is an odd section at the start of the console's history log, where 
> it has saved data from before the clock was set up.  Can you please clear 
> the log from the console touch panel.
> And I'll try mine as well, because I have just noticed that my system  
> also has some junk in the first 30 history packets.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Cameron D]

Two problems with RC5 so far...

1. There is still something wrong in the history code, with more bogus 
history records being reported.. I have not yet worked out if it was a 
fault in my original code or in the recent adaptation.  Even though I am 
saving every minute, I still have to wait about 1 day before I can do each 
buffer clear, so testing is going to take a while.

2. Weewx stopped reporting at 05:42 this morning - nothing to do with the 
history buffer code. The logs reported that the console's history storage 
was being incremented, but no data was going into the database, no graphs 
were being updated, and nothing was logged from the main code.  My first 
thought is that the code was running in the genLoopPackets code but no data 
was being reported from the console. This might relate to the dropoff in 
packet numbers that I had noted earlier.  More diagnostic code going in.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Cameron D]

>
>
> Hi Matthew,
> 1. I might load RC5 onto my system and see how it behaves, ...
>

Traps for young players (and not so young) - I spent yesterday mulling over 
weird debug logs only to finally discover it was due to syslog 
rate-limiting always discarding the critical part.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Cameron D]

On Sunday, 11 February 2018 16:01:59 UTC+10, Cameron D wrote:
>
>
> There is an odd section at the start of the console's history log, where 
> it has saved data from before the clock was set up. 
> And I'll try mine as well, because I have just noticed that my system  
> also has some junk in the first 30 history packets.
>

 Hmm, the junk seems to have accumulated as a result of my code.  I don't 
know if it was from the early tests or latest code, so I will need to do 
some more testing.
OTOH, it probably does not relate to your problems.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Cameron D]

Hello Ruben,
I cannot see where you have already said this, but can you report the 
logging frequency of the WMR300 console and the archive interval you have 
set in weewx.
>From the logs it look like WMR300 is set to 5 minutes.

There is an odd section at the start of the console's history log, where it 
has saved data from before the clock was set up.  Can you please clear the 
log from the console touch panel.
And I'll try mine as well, because I have just noticed that my system  also 
has some junk in the first 30 history packets.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

1.- NO...all information is here.
I can do all necessary tests for you.

El sábado, 10 de febrero de 2018, 15:36:05 (UTC+1), Cameron D escribió:
>
>
>
> On Saturday, 10 February 2018 22:58:32 UTC+10, mwall wrote:
>>
>> On Saturday, February 10, 2018 at 3:26:22 AM UTC-5, Cameron D wrote:
>>>
>>> Hi all,
>>> I am back after a long period of doing other things and have started 
>>> merging Matthew's latest code into my version of the driver, which 
>>> uses only PyUSB v1
>>> I am looking to create a unified version that works with both V0 and V1 
>>> APIs.
>>>
>>
>> camera,
>>
>> i think we have the libusb/pyusb issues under control.  it was basically 
>> and issue of detecting timeouts and 'no data' "errors", since the wmr300 
>> driver needs to ignore those.  since v1 is backward compatible with v0 api, 
>> we should be ok.
>>
>> at some point it might be useful to make weewx aware of different pyusb 
>> and libusb versions, but imho that should be done in a weewx.usb module, 
>> not in each driver. (see the 'usb' branch for one way of doing it - that 
>> generalization also makes it possible to support platforms like macos and 
>> other hid implementations)
>>
>> i think the remaining issues for wmr300 driver are:
>>
>> 1) figure out how to clear the history properly.  the rc5 driver does 
>> this (based on the code you wrote!), but ruben's station seems to respond 
>> differently than others, so we're still not quite there.
>>
>> 2) figure out how to reset the rain counter from software.  this might 
>> not be possible.
>>
>> 3) address any of the long-term issues you have discovered.  did any of 
>> those cause weewx to stop?
>>
>> thank you for continuing to collect data and for the detailed analyses. 
>>  i suspect we might have to make some of that instrumentation easy for any 
>> wmr300 user so that we can figure out what is happening with hardware like 
>> ruben's
>>
>> m
>>
>
> Hi Matthew,
> 1. I might load RC5 onto my system and see how it behaves,  Do you have 
> more information on Ruben's problem than posted here?
> 2. Resetting the rain counter - I decided that it is so unlikely they have 
> allowed for that possibility that I am not looking to test it.
> 3. It stopped once, but restarted, so not an issue. I put it down to 
> possibly a hardware glitch.
>
> Other issues I might look at
> 4. Battery levels. - I have pored over captures when the console and 
> Windows software changed the display indicating battery issues, but I just 
> cannot work out which bits did it.
> 5. clock drift - they did not even consider the possibility of customers 
> outside North America or Europe, so their windows software does not even 
> worry when the clock is miles off the actual time. I am sure there is no 
> way to remotely fix it so I am hoping for some way to issue an alert. Mine 
> drifted by over a minute in about 10 months.
>
> Cameron.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Cameron D]

On Saturday, 10 February 2018 22:58:32 UTC+10, mwall wrote:
>
> On Saturday, February 10, 2018 at 3:26:22 AM UTC-5, Cameron D wrote:
>>
>> Hi all,
>> I am back after a long period of doing other things and have started 
>> merging Matthew's latest code into my version of the driver, which 
>> uses only PyUSB v1
>> I am looking to create a unified version that works with both V0 and V1 
>> APIs.
>>
>
> camera,
>
> i think we have the libusb/pyusb issues under control.  it was basically 
> and issue of detecting timeouts and 'no data' "errors", since the wmr300 
> driver needs to ignore those.  since v1 is backward compatible with v0 api, 
> we should be ok.
>
> at some point it might be useful to make weewx aware of different pyusb 
> and libusb versions, but imho that should be done in a weewx.usb module, 
> not in each driver. (see the 'usb' branch for one way of doing it - that 
> generalization also makes it possible to support platforms like macos and 
> other hid implementations)
>
> i think the remaining issues for wmr300 driver are:
>
> 1) figure out how to clear the history properly.  the rc5 driver does this 
> (based on the code you wrote!), but ruben's station seems to respond 
> differently than others, so we're still not quite there.
>
> 2) figure out how to reset the rain counter from software.  this might not 
> be possible.
>
> 3) address any of the long-term issues you have discovered.  did any of 
> those cause weewx to stop?
>
> thank you for continuing to collect data and for the detailed analyses.  i 
> suspect we might have to make some of that instrumentation easy for any 
> wmr300 user so that we can figure out what is happening with hardware like 
> ruben's
>
> m
>

Hi Matthew,
1. I might load RC5 onto my system and see how it behaves,  Do you have 
more information on Ruben's problem than posted here?
2. Resetting the rain counter - I decided that it is so unlikely they have 
allowed for that possibility that I am not looking to test it.
3. It stopped once, but restarted, so not an issue. I put it down to 
possibly a hardware glitch.

Other issues I might look at
4. Battery levels. - I have pored over captures when the console and 
Windows software changed the display indicating battery issues, but I just 
cannot work out which bits did it.
5. clock drift - they did not even consider the possibility of customers 
outside North America or Europe, so their windows software does not even 
worry when the clock is miles off the actual time. I am sure there is no 
way to remotely fix it so I am hoping for some way to issue an alert. Mine 
drifted by over a minute in about 10 months.

Cameron.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[mwall]

On Saturday, February 10, 2018 at 3:26:22 AM UTC-5, Cameron D wrote:
>
> Hi all,
> I am back after a long period of doing other things and have started 
> merging Matthew's latest code into my version of the driver, which 
> uses only PyUSB v1
> I am looking to create a unified version that works with both V0 and V1 
> APIs.
>

camera,

i think we have the libusb/pyusb issues under control.  it was basically 
and issue of detecting timeouts and 'no data' "errors", since the wmr300 
driver needs to ignore those.  since v1 is backward compatible with v0 api, 
we should be ok.

at some point it might be useful to make weewx aware of different pyusb and 
libusb versions, but imho that should be done in a weewx.usb module, not in 
each driver. (see the 'usb' branch for one way of doing it - that 
generalization also makes it possible to support platforms like macos and 
other hid implementations)

i think the remaining issues for wmr300 driver are:

1) figure out how to clear the history properly.  the rc5 driver does this 
(based on the code you wrote!), but ruben's station seems to respond 
differently than others, so we're still not quite there.

2) figure out how to reset the rain counter from software.  this might not 
be possible.

3) address any of the long-term issues you have discovered.  did any of 
those cause weewx to stop?

thank you for continuing to collect data and for the detailed analyses.  i 
suspect we might have to make some of that instrumentation easy for any 
wmr300 user so that we can figure out what is happening with hardware like 
ruben's

m

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Cameron D]

Hi all,
I am back after a long period of doing other things and have started 
merging Matthew's latest code into my version of the driver, which 
uses only PyUSB v1
I am looking to create a unified version that works with both V0 and V1 
APIs.

My system has been running without crashing for about 11 months, however 
there have been *unexpected events *that might be related to crashes here. 

Normally the system sends over 100 packets in every heartbeat interval of 
20 seconds. But every now and again it slows right down - I have logged 
over 24000 occurrences where the system sent fewer than 10 packets in the 
20 seconds.
I don't know why - I intend to look in more detail at the timing for any 
trends that might help explain this.
In the same 11 months, there were 1760 times when it sent zero data, and my 
code assumes the weather station console has gone to sleep and tries to 
kick it to life again.
I don't know if this is necessary, but the system is usually happy with the 
process.

On about half of these 1760 occasions when I read nothing, I "immediately" 
flush the read buffer and there is a burst of 22 packets (occasionally up 
to 26) within the 1 second. Whether this is the Linux side getting clogged 
up, or the WMR console, I can't tell.
I don't even check what sort of packets they are, but I might start doing 
that (when I get the code working again)

On 11 out of the 1760 occasions, the console refused to read the next A6 
heartbeat packet and caused a timeout, but the system recovered and carried 
on.

So, there are certainly still irregularities in the way the console and 
Linux drivers talk to each other. If these are timing issues leading to 
deadlock then it could easily explain why we see problems on one system and 
not another.

There was one "unknown error" (code 99) from the USB lib while  trying to 
read a loop packet. This triggered an exception and weewx restarted 
automatically, so that behaved as we would hope.

Cameron.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

After 54 hours RC5 Crashed again :-(
With NO message on syslog.

El jueves, 8 de febrero de 2018, 12:34:57 (UTC+1), Ruben Navarro Huedo 
escribió:
>
> I don't know what changed, but it is running now 48 hours with RC5 and all 
> is fine.
>
> El martes, 6 de febrero de 2018, 13:52:29 (UTC+1), mwall escribió:
>>
>> On Tuesday, February 6, 2018 at 7:29:04 AM UTC-5, Ruben Navarro Huedo 
>> wrote:
>>>
>>> Mismas versiones que yo pero en mi caso no es estable.
>>>
 
>>
>
>> ruben, thank you for checking the versions.  i think we have the usb 
>> instabilities under control now, but what remains is the clearing of 
>> historical data.  that feature was not in older versions of the driver, and 
>> you will only see the odd behavior if the number of records in the logger 
>> exceeds a certain level.
>>
>> as a workaround you could set the history_limit to 95, then manually 
>> clear the station memory before it reaches 95% capacity.
>>
>> if martin would be so kind to permit me to use his station again, i might 
>> be able to fix it.
>>
>> m 
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

I don't know what changed, but it is running now 48 hours with RC5 and all 
is fine.

El martes, 6 de febrero de 2018, 13:52:29 (UTC+1), mwall escribió:
>
> On Tuesday, February 6, 2018 at 7:29:04 AM UTC-5, Ruben Navarro Huedo 
> wrote:
>>
>> Mismas versiones que yo pero en mi caso no es estable.
>>
>>> 
>

> ruben, thank you for checking the versions.  i think we have the usb 
> instabilities under control now, but what remains is the clearing of 
> historical data.  that feature was not in older versions of the driver, and 
> you will only see the odd behavior if the number of records in the logger 
> exceeds a certain level.
>
> as a workaround you could set the history_limit to 95, then manually clear 
> the station memory before it reaches 95% capacity.
>
> if martin would be so kind to permit me to use his station again, i might 
> be able to fix it.
>
> m 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

You have my station at your disposal.

If interested you can access my rasp using SSH.

Send me personal mail and i will send you details.

runahue at gmail.com

El martes, 6 de febrero de 2018, 13:52:29 (UTC+1), mwall escribió:
>
> On Tuesday, February 6, 2018 at 7:29:04 AM UTC-5, Ruben Navarro Huedo 
> wrote:
>>
>> Mismas versiones que yo pero en mi caso no es estable.
>>
>>> 
>

> ruben, thank you for checking the versions.  i think we have the usb 
> instabilities under control now, but what remains is the clearing of 
> historical data.  that feature was not in older versions of the driver, and 
> you will only see the odd behavior if the number of records in the logger 
> exceeds a certain level.
>
> as a workaround you could set the history_limit to 95, then manually clear 
> the station memory before it reaches 95% capacity.
>
> if martin would be so kind to permit me to use his station again, i might 
> be able to fix it.
>
> m 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[mwall]

On Tuesday, February 6, 2018 at 7:29:04 AM UTC-5, Ruben Navarro Huedo wrote:
>
> Mismas versiones que yo pero en mi caso no es estable.
>
>> 

>>>
ruben, thank you for checking the versions.  i think we have the usb 
instabilities under control now, but what remains is the clearing of 
historical data.  that feature was not in older versions of the driver, and 
you will only see the odd behavior if the number of records in the logger 
exceeds a certain level.

as a workaround you could set the history_limit to 95, then manually clear 
the station memory before it reaches 95% capacity.

if martin would be so kind to permit me to use his station again, i might 
be able to fix it.

m 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

Gracias.

Mismas versiones que yo pero en mi caso no es estable.

El martes, 6 de febrero de 2018, 9:02:44 (UTC+1), Alberto Sánchez escribió:
>
> Linux 4.4.50-v7+
>
>  
>
> pi@raspberrypi:~ $ dpkg -l | grep usb
>
> ii  libusb-0.1-4:armhf2:0.1.12-25 
>   armhfuserspace USB programming library
>
> ii  libusb-1.0-0:armhf2:1.0.19-1 
>armhfuserspace USB programming library
>
> ii  libusbmuxd2:armhf 1.0.9-1 
>   armhfUSB multiplexor daemon for iPhone and iPod Touch 
> devices - library
>
> ii  python-usb0.4.3-1 
>   armhfUSB interface for Python
>
> ii  usb-modeswitch2.2.0+repack0-2 
>   armhfmode switching tool for controlling "flip flop" 
> USB devices
>
> ii  usb-modeswitch-data   20150115-1 
>all  mode switching data for usb-modeswitch
>
> ii  usbutils  1:007-2 
>   armhfLinux USB utilities
>
>
>
> Buenas Ruben,
>
> Esa es mi configuración. Es una Raspberry pi 3, y la tengo con disco duro. 
>
> Un saludo
>
> El lunes, 5 de febrero de 2018, 21:28:53 (UTC+1), Ruben Navarro Huedo 
> escribió:
>>
>> ¿Que version de kernel Alberto y de librerias usb?
>>
>> uname -a para el kernel
>> y dpkg -l | grep usb para las librerias
>>
>>
>>
>> El lunes, 5 de febrero de 2018, 19:17:37 (UTC+1), Alberto Sánchez 
>> escribió:
>>>
>>> Hi mwall,
>>>
>>> 12 days testing RC5 without errors.
>>>
>>> Thanks
>>>
>>> http://www.elurerauntsi.com/weather/index.html
>>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Alberto Sánchez]

Linux 4.4.50-v7+

 

pi@raspberrypi:~ $ dpkg -l | grep usb

ii  libusb-0.1-4:armhf2:0.1.12-25   
armhfuserspace USB programming library

ii  libusb-1.0-0:armhf2:1.0.19-1   
 armhfuserspace USB programming library

ii  libusbmuxd2:armhf 1.0.9-1   
armhfUSB multiplexor daemon for iPhone and iPod Touch 
devices - library

ii  python-usb0.4.3-1   
armhfUSB interface for Python

ii  usb-modeswitch2.2.0+repack0-2   
armhfmode switching tool for controlling "flip flop" USB 
devices

ii  usb-modeswitch-data   20150115-1   
 all  mode switching data for usb-modeswitch

ii  usbutils  1:007-2   
armhfLinux USB utilities



Buenas Ruben,

Esa es mi configuración. Es una Raspberry pi 3, y la tengo con disco duro. 

Un saludo

El lunes, 5 de febrero de 2018, 21:28:53 (UTC+1), Ruben Navarro Huedo 
escribió:
>
> ¿Que version de kernel Alberto y de librerias usb?
>
> uname -a para el kernel
> y dpkg -l | grep usb para las librerias
>
>
>
> El lunes, 5 de febrero de 2018, 19:17:37 (UTC+1), Alberto Sánchez escribió:
>>
>> Hi mwall,
>>
>> 12 days testing RC5 without errors.
>>
>> Thanks
>>
>> http://www.elurerauntsi.com/weather/index.html
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

¿Que version de kernel Alberto y de librerias usb?

uname -a para el kernel
y dpkg -l | grep usb para las librerias



El lunes, 5 de febrero de 2018, 19:17:37 (UTC+1), Alberto Sánchez escribió:
>
> Hi mwall,
>
> 12 days testing RC5 without errors.
>
> Thanks
>
> http://www.elurerauntsi.com/weather/index.html
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Alberto Sánchez]

Hi mwall,

12 days testing RC5 without errors.

Thanks

http://www.elurerauntsi.com/weather/index.html

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

i can't see anything on the log.

Last i can see is:

Jan 25 01:19:14 MeteoElche wpa_supplicant[382]: wlan0: WPA: Group rekeying 
completed with 00:0c:42:bc:80:94 [GTK=CCMP]
Jan 25 01:20:14 MeteoElche weewx[6486]: manager: Added record 2018-01-25 
01:20:00 CET (1516839600) to database 'weewx.sdb'
Jan 25 01:20:14 MeteoElche weewx[6486]: manager: Added record 2018-01-25 
01:20:00 CET (1516839600) to daily summary in 'weewx.sdb'
Jan 25 01:20:15 MeteoElche weewx[6486]: restx: AWEKAS: Published record 
2018-01-25 01:20:00 CET (1516839600)
Jan 25 01:20:15 MeteoElche weewx[6486]: restx: PWSWeather: Published record 
2018-01-25 01:20:00 CET (1516839600)
Jan 25 01:20:15 MeteoElche weewx[6486]: restx: CWOP: Published record 
2018-01-25 01:20:00 CET (1516839600)
Jan 25 01:20:15 MeteoElche weewx[6486]: restx: Wunderground-PWS: Published 
record 2018-01-25 01:20:00 CET (1516839600)
Jan 25 01:20:18 MeteoElche weewx[6486]: cheetahgenerator: Generated 11 
files for report StandardReport in 3.81 seconds
Jan 25 01:20:27 MeteoElche weewx[6486]: imagegenerator: Generated 9 images 
for StandardReport in 8.82 seconds
Jan 25 01:20:27 MeteoElche weewx[6486]: copygenerator: copied 0 files to 
/var/www/html/weewx
Jan 25 01:20:27 MeteoElche weewx[6486]: cheetahgenerator: Generated 1 files 
for report TiempoElche in 0.13 seconds
Jan 25 01:20:32 MeteoElche weewx[6486]: imagegenerator: Generated 8 images 
for TiempoElche in 5.39 seconds
Jan 25 01:20:33 MeteoElche weewx[6486]: copygenerator: copied 0 files to 
/var/www/html/weewx/TiempoElche
Jan 25 01:20:50 MeteoElche weewx[6486]: ftpgenerator: ftp'd 29 files in 
17.42 seconds


El jueves, 25 de enero de 2018, 20:32:55 (UTC+1), Ruben Navarro Huedo 
escribió:
>
> 0.18 is "stable" version for me.
> I have had very long uptime with this version and kernel  4.4.50-v7+ 
> Using last kernel (4.9.*) raspberry freezes completly after some hours.
> i will try search for the crash on the log.
>
> pi@MeteoElche:/usr/share/weewx/weewx/drivers $ dpkg -l | grep usb
> ii  libusb-0.1-4:armhf2:0.1.12-25   
> armhfuserspace USB programming library
> ii  libusb-1.0-0:armhf2:1.0.19-1
> armhfuserspace USB programming library
> ii  libusb-1.0-0-dbg:armhf2:1.0.19-1
> armhfuserspace USB programming library development files
> ii  libusb-1.0-0-dev:armhf2:1.0.19-1
> armhfuserspace USB programming library development files
> ii  libusb-1.0-doc2:1.0.19-1
> all  documentation for userspace USB programming
> ii  python-usb0.4.3-1   
> armhfUSB interface for Python
> ii  usb-modeswitch2.2.0+repack0-2   
> armhfmode switching tool for controlling "flip flop" USB devices
> ii  usb-modeswitch-data   20150115-1
> all  mode switching data for usb-modeswitch
> ii  usbutils  1:007-2   
> armhfLinux USB utilities
> pi@MeteoElche:/usr/share/weewx/weewx/drivers $
>
>
> El jueves, 25 de enero de 2018, 20:21:40 (UTC+1), mwall escribió:
>>
>> On Thursday, January 25, 2018 at 2:01:50 PM UTC-5, Ruben Navarro Huedo 
>> wrote:
>>>
>>> Testing last RC and after some hours it crashes :-(
>>> Returning to Stable driver version and all fine.
>>>
>>
>> thank you for the feedback, but could you add a little bit more 
>> information so i can actually do something about it?
>>
>> what is the log output from the 'crashes'?
>>
>> which version is the 'Stable' version for you?
>>  
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

0.18 is "stable" version for me.
I have had very long uptime with this version and kernel  4.4.50-v7+ 
Using last kernel (4.9.*) raspberry freezes completly after some hours.
i will try search for the crash on the log.

pi@MeteoElche:/usr/share/weewx/weewx/drivers $ dpkg -l | grep usb
ii  libusb-0.1-4:armhf2:0.1.12-25   
armhfuserspace USB programming library
ii  libusb-1.0-0:armhf2:1.0.19-1
armhfuserspace USB programming library
ii  libusb-1.0-0-dbg:armhf2:1.0.19-1
armhfuserspace USB programming library development files
ii  libusb-1.0-0-dev:armhf2:1.0.19-1
armhfuserspace USB programming library development files
ii  libusb-1.0-doc2:1.0.19-1
all  documentation for userspace USB programming
ii  python-usb0.4.3-1   
armhfUSB interface for Python
ii  usb-modeswitch2.2.0+repack0-2   
armhfmode switching tool for controlling "flip flop" USB devices
ii  usb-modeswitch-data   20150115-1
all  mode switching data for usb-modeswitch
ii  usbutils  1:007-2   
armhfLinux USB utilities
pi@MeteoElche:/usr/share/weewx/weewx/drivers $


El jueves, 25 de enero de 2018, 20:21:40 (UTC+1), mwall escribió:
>
> On Thursday, January 25, 2018 at 2:01:50 PM UTC-5, Ruben Navarro Huedo 
> wrote:
>>
>> Testing last RC and after some hours it crashes :-(
>> Returning to Stable driver version and all fine.
>>
>
> thank you for the feedback, but could you add a little bit more 
> information so i can actually do something about it?
>
> what is the log output from the 'crashes'?
>
> which version is the 'Stable' version for you?
>  
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[mwall]

On Thursday, January 25, 2018 at 2:01:50 PM UTC-5, Ruben Navarro Huedo 
wrote:
>
> Testing last RC and after some hours it crashes :-(
> Returning to Stable driver version and all fine.
>

thank you for the feedback, but could you add a little bit more information 
so i can actually do something about it?

what is the log output from the 'crashes'?

which version is the 'Stable' version for you?
 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

Testing last RC and after some hours it crashes :-(
Returning to Stable driver version and all fine.


-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

No i am not doing it.

I will try and will tell you the result.

El miércoles, 24 de enero de 2018, 15:25:24 (UTC+1), sina...@gmail.com 
escribió:
>
> Asking you twice, could you upload your data to wunderground with 
> rapidfire feature. If you are already doing give me id please

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Alberto Sánchez]

Jan 24 10:43:00 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:01 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:01 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:01 CET (1516786981) (last_index=6576 latest_index=6577)
Jan 24 10:43:01 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:01 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:01 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:01 CET (1516786981) (last_index=6576 latest_index=6577)
Jan 24 10:43:01 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:02 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:02 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:02 CET (1516786982) (last_index=6576 latest_index=6577)
Jan 24 10:43:02 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:02 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:02 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:02 CET (1516786982) (last_index=6576 latest_index=6577)
Jan 24 10:43:02 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:03 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:03 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:03 CET (1516786983) (last_index=6576 latest_index=6577)
Jan 24 10:43:03 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:04 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:04 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:04 CET (1516786984) (last_index=6576 latest_index=6577)
Jan 24 10:43:04 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:04 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:04 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:04 CET (1516786984) (last_index=6576 latest_index=6577)
Jan 24 10:43:04 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:05 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:05 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:05 CET (1516786985) (last_index=6576 latest_index=6577)
Jan 24 10:43:05 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:06 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:06 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:06 CET (1516786986) (last_index=6576 latest_index=6577)
Jan 24 10:43:06 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:06 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:06 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:06 CET (1516786986) (last_index=6576 latest_index=6577)
Jan 24 10:43:06 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:07 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:07 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:07 CET (1516786987) (last_index=6576 latest_index=6577)
Jan 24 10:43:07 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:08 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:08 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:08 CET (1516786988) (last_index=6576 latest_index=6577)
Jan 24 10:43:08 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:08 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:08 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:08 CET (1516786988) (last_index=6576 latest_index=6577)
Jan 24 10:43:08 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:09 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:09 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:09 CET (1516786989) (last_index=6576 latest_index=6577)
Jan 24 10:43:09 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:09 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:09 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:09 CET (1516786989) (last_index=6576 latest_index=6577)
Jan 24 10:43:09 raspberrypi weewx[875]: wmr300: catchup complete: count=0 
last_index=6576 latest_index=6577
Jan 24 10:43:10 raspberrypi weewx[875]: wmr300: dump history
Jan 24 10:43:10 raspberrypi weewx[875]: wmr300: reading records since 
2018-01-24 10:43:10 CET (1516786990) (last_index

[weewx-user] Re: WMR300 testing LAST Driver

[sinantc34]

Asking you twice, could you upload your data to wunderground with rapidfire 
feature. If you are already doing give me id please

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

Testing

Running 1:30 hours fine.

El miércoles, 24 de enero de 2018, 6:12:18 (UTC+1), mwall escribió:
>
> On Tuesday, January 23, 2018 at 2:13:07 PM UTC-5, Ruben Navarro Huedo 
> wrote:
>>
>>
>> Again "LOOP" and shutdown :-(
>>
>
> ruben,
>
> please try v0.19rc5
>
>
> https://raw.githubusercontent.com/weewx/weewx/master/bin/weewx/drivers/wmr300.py
>
> m 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[mwall]

On Tuesday, January 23, 2018 at 2:13:07 PM UTC-5, Ruben Navarro Huedo wrote:
>
>
> Again "LOOP" and shutdown :-(
>

ruben,

please try v0.19rc5

https://raw.githubusercontent.com/weewx/weewx/master/bin/weewx/drivers/wmr300.py

m 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

Again "LOOP" and shutdown :-(

Jan 22 16:31:18 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:18 CET (1516635078) (last_index=21390 latest_index=21391)
Jan 22 16:31:18 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:18 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:31:18 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:18 CET (1516635078) (last_index=21390 latest_index=21391)
Jan 22 16:31:18 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:19 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:31:19 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:19 CET (1516635079) (last_index=21390 latest_index=21391)
Jan 22 16:31:19 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:19 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:31:19 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:19 CET (1516635079) (last_index=21390 latest_index=21391)
Jan 22 16:31:20 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:20 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:31:20 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:20 CET (1516635080) (last_index=21390 latest_index=21391)
Jan 22 16:31:20 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:21 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:31:21 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:21 CET (1516635081) (last_index=21390 latest_index=21391)
Jan 22 16:31:21 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:21 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:31:21 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:31:21 CET (1516635081) (last_index=21390 latest_index=21391)
Jan 22 16:31:21 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:31:21 MeteoElche systemd[1]: Stopping LSB: weewx weather system...
Jan 22 16:31:21 MeteoElche weewx[15491]: engine: Shutting down StdReport 
thread
Jan 22 16:31:28 MeteoElche weewx[15491]: ftpgenerator: ftp'd 126 files in 
52.22 seconds
Jan 22 16:31:28 MeteoElche weewx[15491]: engine: Terminating weewx version 
3.8.0
Jan 22 16:31:32 MeteoElche weewx[15718]: Stopping weewx weather system: 
weewx...

El martes, 23 de enero de 2018, 16:01:50 (UTC+1), sina...@gmail.com 
escribió:
>
> hey, can you upload to wunderground with rapidfire? Im too far from my 
> wmr300 I cant remote control and give me wu ıd please, thanks a lot
>
> 22 Ocak 2018 Pazartesi 14:48:27 UTC+3 tarihinde Ruben Navarro Huedo yazdı:
>>
>> Hello:
>>
>> Testing last WMR300 driver:
>>
>> Jan 22 12:45:42 MeteoElche weewx[1500]: wmr300: dump history
>> Jan 22 12:45:42 MeteoElche weewx[1500]: wmr300: reading records since 
>> 2018-01-22 12:45:42 CET (1516621542) (last_index=21345 latest_index=21346)
>> Jan 22 12:45:47 MeteoElche weewx[1500]: engine: Caught unrecoverable 
>> exception in engine:
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   list index out of range
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   Traceback (most recent 
>> call last):
>> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
>> "/usr/share/weewx/weewx/engine.py", line 871, in main
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   engine.run()
>> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
>> "/usr/share/weewx/weewx/engine.py", line 187, in run
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   for packet in 
>> self.console.genLoopPackets():
>> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
>> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1263, in genLoopPackets
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   self.dump_history()
>> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
>> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1147, in dump_history
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   for rec in 
>> self.get_history(time.time(), clear_logger=True):
>> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
>> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1160, in get_history
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   
>> self.init_history(clear_logger)
>> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
>> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1089, in init_history
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   if buf is None or 
>> buf[0] != 0x41:
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   IndexError: list index 
>> out of range
>> Jan 22 12:45:47 MeteoElche weewx[1500]:   Exiting.
>>
>>
>>
>>

-- 
You received this messa

[weewx-user] Re: WMR300 testing LAST Driver

[sinantc34]

hey, can you upload to wunderground with rapidfire? Im too far from my 
wmr300 I cant remote control and give me wu ıd please, thanks a lot

22 Ocak 2018 Pazartesi 14:48:27 UTC+3 tarihinde Ruben Navarro Huedo yazdı:
>
> Hello:
>
> Testing last WMR300 driver:
>
> Jan 22 12:45:42 MeteoElche weewx[1500]: wmr300: dump history
> Jan 22 12:45:42 MeteoElche weewx[1500]: wmr300: reading records since 
> 2018-01-22 12:45:42 CET (1516621542) (last_index=21345 latest_index=21346)
> Jan 22 12:45:47 MeteoElche weewx[1500]: engine: Caught unrecoverable 
> exception in engine:
> Jan 22 12:45:47 MeteoElche weewx[1500]:   list index out of range
> Jan 22 12:45:47 MeteoElche weewx[1500]:   Traceback (most recent 
> call last):
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/engine.py", line 871, in main
> Jan 22 12:45:47 MeteoElche weewx[1500]:   engine.run()
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/engine.py", line 187, in run
> Jan 22 12:45:47 MeteoElche weewx[1500]:   for packet in 
> self.console.genLoopPackets():
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1263, in genLoopPackets
> Jan 22 12:45:47 MeteoElche weewx[1500]:   self.dump_history()
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1147, in dump_history
> Jan 22 12:45:47 MeteoElche weewx[1500]:   for rec in 
> self.get_history(time.time(), clear_logger=True):
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1160, in get_history
> Jan 22 12:45:47 MeteoElche weewx[1500]:   
> self.init_history(clear_logger)
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1089, in init_history
> Jan 22 12:45:47 MeteoElche weewx[1500]:   if buf is None or 
> buf[0] != 0x41:
> Jan 22 12:45:47 MeteoElche weewx[1500]:   IndexError: list index 
> out of range
> Jan 22 12:45:47 MeteoElche weewx[1500]:   Exiting.
>
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

Now is running fine with no modification:

Jan 23 13:20:52 MeteoElche weewx[16384]: restx: WeatherCloud: service 
version is 0.10
Jan 23 13:20:52 MeteoElche weewx[16384]: restx: WeatherCloud: Data will be 
uploaded for id=82ffe1c4671ee036
Jan 23 13:20:52 MeteoElche weewx[16384]: engine: Starting up weewx version 
3.8.0
Jan 23 13:20:52 MeteoElche weewx[16384]: wmr300: reading records since 
2018-01-23 13:20:00 CET (151671) (last_index=31 latest_index=314)
Jan 23 13:20:53 MeteoElche weewx[16384]: wmr300: catchup complete: count=0 
last_index=313 latest_index=314
Jan 23 13:20:53 MeteoElche weewx[16384]: engine: Starting main packet loop.
Jan 23 13:20:55 MeteoElche weewx[16384]: wmr300: possible missed rain 
event: new=195.58 old=None
Jan 23 13:20:55 MeteoElche weewx[16384]: wmr300: rain=None 
rain_total=195.58 last_rain=None
Jan 23 13:21:12 MeteoElche weewx[16384]: wmr300: history buffer at 0.9%


El lunes, 22 de enero de 2018, 21:33:23 (UTC+1), Ruben Navarro Huedo 
escribió:
>
> Attached text file.
>
> El lunes, 22 de enero de 2018, 17:52:21 (UTC+1), mwall escribió:
>>
>> On Monday, January 22, 2018 at 10:31:05 AM UTC-5, Ruben Navarro Huedo 
>> wrote:
>>>
>>> A lot of thank's to you.
>>> It has started but i think we have a loop:
>>>
>>
>> not an infinite loop.  but your hardware is not responding the way other 
>> hardware has responded.
>>
>> please post the entire log from the time that weewx starts up.
>>
>> it would also help if you set debug like this:
>>
>> debug=1
>> [WMR300]
>> debug_comm = 1
>> debug_packet = 0
>> debug_counts = 0
>> debug_decode = 0
>> debug_history = 1
>> debug_rain = 1
>>
>> m
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[mwall]

On Monday, January 22, 2018 at 10:31:05 AM UTC-5, Ruben Navarro Huedo wrote:
>
> A lot of thank's to you.
> It has started but i think we have a loop:
>

not an infinite loop.  but your hardware is not responding the way other 
hardware has responded.

please post the entire log from the time that weewx starts up.

it would also help if you set debug like this:

debug=1
[WMR300]
debug_comm = 1
debug_packet = 0
debug_counts = 0
debug_decode = 0
debug_history = 1
debug_rain = 1

m

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: WMR300 testing LAST Driver

[Ruben Navarro Huedo]

A lot of thank's to you.
It has started but i think we have a loop:

Jan 22 16:30:03 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:03 CET (1516635003) (last_index=21390 latest_index=21391)
Jan 22 16:30:03 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:03 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:03 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:03 CET (1516635003) (last_index=21390 latest_index=21391)
Jan 22 16:30:04 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:04 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:04 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:04 CET (1516635004) (last_index=21390 latest_index=21391)
Jan 22 16:30:05 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:05 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:05 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:05 CET (1516635005) (last_index=21390 latest_index=21391)
Jan 22 16:30:05 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:06 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:06 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:06 CET (1516635006) (last_index=21390 latest_index=21391)
Jan 22 16:30:06 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:07 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:07 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:07 CET (1516635007) (last_index=21390 latest_index=21391)
Jan 22 16:30:07 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:08 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:08 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:08 CET (1516635008) (last_index=21390 latest_index=21391)
Jan 22 16:30:08 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:08 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:08 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:08 CET (1516635008) (last_index=21390 latest_index=21391)
Jan 22 16:30:09 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:09 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:09 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:09 CET (1516635009) (last_index=21390 latest_index=21391)
Jan 22 16:30:09 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:10 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:10 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:10 CET (1516635010) (last_index=21390 latest_index=21391)
Jan 22 16:30:10 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:11 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:11 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:11 CET (1516635011) (last_index=21390 latest_index=21391)
Jan 22 16:30:11 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:12 MeteoElche weewx[15491]: wmr300: possible missed rain 
event: new=195.58 old=None
Jan 22 16:30:12 MeteoElche weewx[15491]: wmr300: rain=None 
rain_total=195.58 last_rain=None
Jan 22 16:30:12 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:12 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:12 CET (1516635012) (last_index=21390 latest_index=21391)
Jan 22 16:30:12 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:12 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:12 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:12 CET (1516635012) (last_index=21390 latest_index=21391)
Jan 22 16:30:13 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:13 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:13 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:13 CET (1516635013) (last_index=21390 latest_index=21391)
Jan 22 16:30:13 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 latest_index=21391
Jan 22 16:30:14 MeteoElche weewx[15491]: wmr300: dump history
Jan 22 16:30:14 MeteoElche weewx[15491]: wmr300: reading records since 
2018-01-22 16:30:14 CET (1516635014) (last_index=21390 latest_index=21391)
Jan 22 16:30:14 MeteoElche weewx[15491]: wmr300: catchup complete: count=0 
last_index=21390 lates

[weewx-user] Re: WMR300 testing LAST Driver

[mwall]

On Monday, January 22, 2018 at 6:48:27 AM UTC-5, Ruben Navarro Huedo wrote:
>
> Hello:
>
> Testing last WMR300 driver:
>
> Jan 22 12:45:42 MeteoElche weewx[1500]: wmr300: dump history
> Jan 22 12:45:42 MeteoElche weewx[1500]: wmr300: reading records since 
> 2018-01-22 12:45:42 CET (1516621542) (last_index=21345 latest_index=21346)
> Jan 22 12:45:47 MeteoElche weewx[1500]: engine: Caught unrecoverable 
> exception in engine:
> Jan 22 12:45:47 MeteoElche weewx[1500]:   list index out of range
> Jan 22 12:45:47 MeteoElche weewx[1500]:   Traceback (most recent 
> call last):
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/engine.py", line 871, in main
> Jan 22 12:45:47 MeteoElche weewx[1500]:   engine.run()
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/engine.py", line 187, in run
> Jan 22 12:45:47 MeteoElche weewx[1500]:   for packet in 
> self.console.genLoopPackets():
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1263, in genLoopPackets
> Jan 22 12:45:47 MeteoElche weewx[1500]:   self.dump_history()
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1147, in dump_history
> Jan 22 12:45:47 MeteoElche weewx[1500]:   for rec in 
> self.get_history(time.time(), clear_logger=True):
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1160, in get_history
> Jan 22 12:45:47 MeteoElche weewx[1500]:   
> self.init_history(clear_logger)
> Jan 22 12:45:47 MeteoElche weewx[1500]: File 
> "/usr/share/weewx/weewx/drivers/wmr300.py", line 1089, in init_history
> Jan 22 12:45:47 MeteoElche weewx[1500]:   if buf is None or 
> buf[0] != 0x41:
> Jan 22 12:45:47 MeteoElche weewx[1500]:   IndexError: list index 
> out of range
> Jan 22 12:45:47 MeteoElche weewx[1500]:   Exiting.
>

ruben,

thank you for continuing to help with the wmr300 driver!  please install 
version 0.19rc4:

https://raw.githubusercontent.com/weewx/weewx/master/bin/weewx/drivers/wmr300.py

this version fixes the corner case you discovered, as well as two similar 
conditions when waiting for ACK from the hardware.

m
 

-- 
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.
For more options, visit https://groups.google.com/d/optout.