[weewx-user] Re: WMR300 - intermittent and partial loss of loop data

[Juan Antonio Mosquera]

OK thanks. I will test this driver in weewx 3.9.1 tomorrow.

El domingo, 17 de febrero de 2019, 7:57:54 (UTC+1), Cameron D escribió:
>
> The 3.9.1 driver does not have my changes, but does have some 
> modifications for python 3.  I expect that means the default driver will 
> have the same problems.
>
> I have attached
>wmr300-v19rc6+f5.py   and 
>wmr300x-v19rc6+f5.py
>
> Which are each basically the same as I previously posted, except that 
> these have the python-3 changes to the "except" statements.
>
> Cameron.
>
> On Saturday, 16 February 2019 02:56:07 UTC+10, Juan Antonio Mosquera wrote:
>>
>> Hi,
>>
>> I use this version now:
>>
>> weewx.drivers.wmr300x-v19rc6+f3
>>
>> All ok... but.. in weewx 3.9.1 driver change¿, can i use wmr300 driver 
>> default?
>>
>> thanks.
>>
>>
>>

-- 
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 - intermittent and partial loss of loop data

[Juan Antonio Mosquera]

Hi,

I use this version now:

weewx.drivers.wmr300x-v19rc6+f3

All ok... but.. in weewx 3.9.1 driver change¿, can i use wmr300 driver 
default?

thanks.

El jueves, 4 de octubre de 2018, 16:22:22 (UTC+2), Cameron D escribió:
>
> The rc5 and rc6 drivers shjipped with the weewx releases had issues where, 
> after some time (days to weeks) the system would stop reporting any data.
> That was addressed in this update of 24th September 
> .
>
> At least two users have reported a different problem, where there is only 
> partial loss, for example wind or temperature and humidity.
>
>1. Juan Antonio Mosquera reports wind data missing 
>.
>2. Markus Biewer reports temperature/humidity, and sometimes other data 
>going missing after about a week 
>.
>
> Initially it looked like it might have been related to Belchertown skin, 
> but it is reported to also be an issue with the standard skin.
>
> The attached zip file has 3 files:
>
>1. *wmr300-v19rc6+f3.py*  - and updated version of the main wmr300 
>driver - this has a couple of minor bug fixes as well as extra diagnostic 
>code for this problem.
>2. *summ-pkt-data.awk*  -   an awk script to  convert the new 
>diagnostic logfile data into a csv file.
>3. *wmr300x-v19rc6+f3.py* - note the 'x'. This is the experimental 
>driver that uses pyusb 1 and libusb1 if available.  It also contains the 
>extra diagnostics, but is included for the other issue where the pi locks 
>up completely.
>
> *New Diagnostics*:
>
> In your weewx.conf file, enable
>   debug=1
>
> and in the WMR300 section I would suggest the following:
> debug_counts = 1
> debug_decode = 0
> debug_comm = 0
> debug_history = 0
> debug_timing = 1
> debug_rain = 0
>
> The debug_counts setting will output a summary of each packet type read 
> from the USB  in a specified time interval (default 20 seconds) as well as 
> the number of loop packets sent to weewx.
>
> Here is my WMR300 section
>
> ##
>
> [WMR300]
> # This section is for WMR300 weather stations
>
> # The station model, e.g., WMR300A
> model = WMR300
>
> # The driver to use:
> driver = user.wmr300-v19rc6+f3
>
> history_limit = 6
>
> debug_counts = 1
> debug_decode = 0
> debug_comm = 0
> debug_history = 1
> debug_timing = 1
> debug_rain = 0
>
>
> ##
>
> Note that I recommend placing these drivers in the "user" directory of the 
> weewx installation.
> You can also create a similar section named *[WMR300x]* to use the 
> experimental driver, and select between them by editing this line in the 
> *[Station]* section:
>  station_type = WMR300
>
> *Experimental driver:*
> This driver uses the PyUSB version 1 API, which allows it to use libusb1 
> or other usb libraries.
> It will default to libusb1 if possible, but otherwise will fall back to 
> libusb0.
>
> Note that some versions of Ubuntu seemed to ship with a beta version of 
> PyUSB-1 that did not seem to support the full api.  If it reports a version 
> beginning "1.0.0b..." then the driver will use libusb0.
>
> If you enable the experimental version then check the log file when it 
> starts up:
> It will always show pyusb_version, and the experimental driver will print 
> which usb backend library is selected.
>
> grep -i pyusb (your-logfile)
>
> will display both.
>

-- 
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 - intermittent and partial loss of loop data

[vince]

On Thursday, October 11, 2018 at 7:54:49 AM UTC-7, Ruben Navarro Huedo 
wrote:
>
> Using last 4.14.70 kernel raspberry+wmr200 hang up full kernel after 72 
> hours.
> I have to return to 4.4.50
>


New Raspbian version just came out dated Oct-9th, kernel is 4.14.71-v7+  
(download 
link) 

-- 
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 - intermittent and partial loss of loop data

[Ruben Navarro Huedo]

Using last 4.14.70 kernel raspberry+wmr200 hang up full kernel after 72 
hours.
I have to return to 4.4.50

El jueves, 11 de octubre de 2018, 8:01:27 (UTC+2), Juan Antonio Mosquera 
escribió:
>
> This dawn, without doing anything has begun to receive wind data, I do not 
> know how long it will last. I am using the experimental driver with libusb1. 
> Today in the afternoon I'm going to restart the console and change the USB 
> port.
>
> Thank you.
>
>
> El martes, 9 de octubre de 2018, 14:33:06 (UTC+2), Cameron D escribió:
>>
>> OK, this is not the symptom that this thread applies to - it might be 
>> more relevant to the hanging thread - I'll explain why at the end.
>>
>> The logs are demonstrating total loss of data - this is similar to the 
>> previous problem, where the data stops, and my driver update detects this 
>> and resends the initialisation command.
>> Where this is different is the restart command seems to have no effect. 
>> The wmr300 console resolutely stops sending data.
>> Even restarting weewx is not enough to make it wake up.
>>
>> There are 3 possibilities I can think of.
>>
>>1. hardware fault in USB
>>2. kernel driver fault in USB code
>>3. WMR300 USB code is very touchy and liable to deadlock - which I 
>>discovered when trying to modify the code. It gets upset if both sides 
>> try 
>>to read or write at the same time.
>>
>> for point 3, I have tried to put lots of workarounds to try to ensure it 
>> does not happen, but there might be hardware timing differences between 
>> systems causing problems on one setup and not another.
>> for point 2, this gets back to the kernel version differences.  Maybe 
>> this is how my experimental driver responds to the same problem that locks 
>> up under libusb0. Which kernel is this happening on?
>> for point 1 - not a lot I can do there, wait to see if other people 
>> replicate it.
>>
>> The next steps would be:
>>
>>- try the other kernel
>>- try another USB port, if available
>>- when it happens next time, see what happens if you simply unplug 
>>the USB for a few seconds. This will reset the WMR300 console comms, it 
>>should also reset the kernel.driver code.
>>
>> Cameron.
>>
>>
>> On Tuesday, 9 October 2018 05:58:39 UTC+10, Ruben Navarro Huedo wrote:
>>>
>>> raspberry did not hung... only stopped receibing data from wmr300.
>>>
>>>
>>>

-- 
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 - intermittent and partial loss of loop data

[Juan Antonio Mosquera]

This dawn, without doing anything has begun to receive wind data, I do not know 
how long it will last. I am using the experimental driver with libusb1. Today 
in the afternoon I'm going to restart the console and change the USB port.

Thank you.


El martes, 9 de octubre de 2018, 14:33:06 (UTC+2), Cameron D escribió:
>
> OK, this is not the symptom that this thread applies to - it might be more 
> relevant to the hanging thread - I'll explain why at the end.
>
> The logs are demonstrating total loss of data - this is similar to the 
> previous problem, where the data stops, and my driver update detects this 
> and resends the initialisation command.
> Where this is different is the restart command seems to have no effect. 
> The wmr300 console resolutely stops sending data.
> Even restarting weewx is not enough to make it wake up.
>
> There are 3 possibilities I can think of.
>
>1. hardware fault in USB
>2. kernel driver fault in USB code
>3. WMR300 USB code is very touchy and liable to deadlock - which I 
>discovered when trying to modify the code. It gets upset if both sides try 
>to read or write at the same time.
>
> for point 3, I have tried to put lots of workarounds to try to ensure it 
> does not happen, but there might be hardware timing differences between 
> systems causing problems on one setup and not another.
> for point 2, this gets back to the kernel version differences.  Maybe this 
> is how my experimental driver responds to the same problem that locks up 
> under libusb0. Which kernel is this happening on?
> for point 1 - not a lot I can do there, wait to see if other people 
> replicate it.
>
> The next steps would be:
>
>- try the other kernel
>- try another USB port, if available
>- when it happens next time, see what happens if you simply unplug the 
>USB for a few seconds. This will reset the WMR300 console comms, it should 
>also reset the kernel.driver code.
>
> Cameron.
>
>
> On Tuesday, 9 October 2018 05:58:39 UTC+10, Ruben Navarro Huedo wrote:
>>
>> raspberry did not hung... only stopped receibing data from wmr300.
>>
>>
>>

-- 
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 - intermittent and partial loss of loop data

[Ruben Navarro Huedo]

Hello Cameron:

I tried disconnecting and connecting again with no effect... the only 
solution was reboot the raspberry.
Now i am using a rasp zero w and i have only one usb port.
I am using last stable raspbian kernel: Linux meteo 4.14.70+ #1144 Tue Sep 
18 17:20:50 BST 2018 armv6l GNU/Linux

If it stops receiving again i will try with 4.4... kernel.

Thank's 

El martes, 9 de octubre de 2018, 14:33:06 (UTC+2), Cameron D escribió:
>
> OK, this is not the symptom that this thread applies to - it might be more 
> relevant to the hanging thread - I'll explain why at the end.
>
> The logs are demonstrating total loss of data - this is similar to the 
> previous problem, where the data stops, and my driver update detects this 
> and resends the initialisation command.
> Where this is different is the restart command seems to have no effect. 
> The wmr300 console resolutely stops sending data.
> Even restarting weewx is not enough to make it wake up.
>
> There are 3 possibilities I can think of.
>
>1. hardware fault in USB
>2. kernel driver fault in USB code
>3. WMR300 USB code is very touchy and liable to deadlock - which I 
>discovered when trying to modify the code. It gets upset if both sides try 
>to read or write at the same time.
>
> for point 3, I have tried to put lots of workarounds to try to ensure it 
> does not happen, but there might be hardware timing differences between 
> systems causing problems on one setup and not another.
> for point 2, this gets back to the kernel version differences.  Maybe this 
> is how my experimental driver responds to the same problem that locks up 
> under libusb0. Which kernel is this happening on?
> for point 1 - not a lot I can do there, wait to see if other people 
> replicate it.
>
> The next steps would be:
>
>- try the other kernel
>- try another USB port, if available
>- when it happens next time, see what happens if you simply unplug the 
>USB for a few seconds. This will reset the WMR300 console comms, it should 
>also reset the kernel.driver code.
>
> Cameron.
>
>
> On Tuesday, 9 October 2018 05:58:39 UTC+10, Ruben Navarro Huedo wrote:
>>
>> raspberry did not hung... only stopped receibing data from wmr300.
>>
>>
>>

-- 
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 - intermittent and partial loss of loop data

[Cameron D]

OK, this is not the symptom that this thread applies to - it might be more 
relevant to the hanging thread - I'll explain why at the end.

The logs are demonstrating total loss of data - this is similar to the 
previous problem, where the data stops, and my driver update detects this 
and resends the initialisation command.
Where this is different is the restart command seems to have no effect. The 
wmr300 console resolutely stops sending data.
Even restarting weewx is not enough to make it wake up.

There are 3 possibilities I can think of.

   1. hardware fault in USB
   2. kernel driver fault in USB code
   3. WMR300 USB code is very touchy and liable to deadlock - which I 
   discovered when trying to modify the code. It gets upset if both sides try 
   to read or write at the same time.

for point 3, I have tried to put lots of workarounds to try to ensure it 
does not happen, but there might be hardware timing differences between 
systems causing problems on one setup and not another.
for point 2, this gets back to the kernel version differences.  Maybe this 
is how my experimental driver responds to the same problem that locks up 
under libusb0. Which kernel is this happening on?
for point 1 - not a lot I can do there, wait to see if other people 
replicate it.

The next steps would be:

   - try the other kernel
   - try another USB port, if available
   - when it happens next time, see what happens if you simply unplug the 
   USB for a few seconds. This will reset the WMR300 console comms, it should 
   also reset the kernel.driver code.

Cameron.


On Tuesday, 9 October 2018 05:58:39 UTC+10, Ruben Navarro Huedo wrote:
>
> raspberry did not hung... only stopped receibing data from wmr300.
>
>
>

-- 
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 - intermittent and partial loss of loop data

[Ruben Navarro Huedo]

After 48 hours weewx lost connection with wmr300:

Oct  8 20:40:14 meteo weewx[20330]: manager: Added record 2018-10-08 
20:40:00 CEST (1539024000) to daily summary in 'weewx.sdb'
Oct  8 20:40:15 meteo weewx[20330]: restx: CWOP: Published record 
2018-10-08 20:40:00 CEST (1539024000)
Oct  8 20:40:15 meteo weewx[20330]: restx: AWEKAS: Published record 
2018-10-08 20:40:00 CEST (1539024000)
Oct  8 20:40:15 meteo weewx[20330]: restx: PWSWeather: Published record 
2018-10-08 20:40:00 CEST (1539024000)
Oct  8 20:40:15 meteo weewx[20330]: restx: Wunderground-PWS: Published 
record 2018-10-08 20:40:00 CEST (1539024000)
Oct  8 20:40:15 meteo weewx[20330]: restx: WeatherCloud: Published record 
2018-10-08 20:40:00 CEST (1539024000)
Oct  8 20:40:19 meteo weewx[20330]: wmr300x: read counts; Loop: 135; TH_0: 
11; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 10; 
TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16
Oct  8 20:40:19 meteo weewx[20330]: wmr300x: write counts;
Oct  8 20:40:36 meteo weewx[20330]: cheetahgenerator: Generated 10 files 
for report StandardReport in 20.88 seconds
Oct  8 20:40:39 meteo weewx[20330]: wmr300x: read counts; Loop: 135; TH_0: 
10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 10; 
TH_8: 10; barom: 11; forecast: 10; rain: 12; wind: 16; x57: 1
Oct  8 20:40:39 meteo weewx[20330]: wmr300x: write counts; xa6: 1
Oct  8 20:40:49 meteo weewx[20330]: imagegenerator: Generated 9 images for 
StandardReport in 13.02 seconds
Oct  8 20:40:49 meteo weewx[20330]: copygenerator: copied 0 files to 
/var/www/html/weewx
Oct  8 20:40:50 meteo weewx[20330]: cheetahgenerator: Generated 1 files for 
report TiempoElche in 0.53 seconds
Oct  8 20:40:56 meteo weewx[20330]: imagegenerator: Generated 8 images for 
TiempoElche in 6.80 seconds
Oct  8 20:40:56 meteo weewx[20330]: copygenerator: copied 0 files to 
/var/www/html/weewx/TiempoElche
Oct  8 20:41:00 meteo weewx[20330]: wmr300x: read counts; Loop: 49; TH_0: 
3; TH_1: 6; TH_2: 4; TH_3: 3; TH_4: 4; TH_5: 4; TH_6: 4; TH_7: 4; TH_8: 3; 
barom: 3; forecast: 4; rain: 5; wind: 6; x57: 1
Oct  8 20:41:00 meteo weewx[20330]: wmr300x: write counts; xa6: 1
Oct  8 20:41:10 meteo weewx[20330]: ftpgenerator: ftp'd 28 files in 13.77 
seconds
Oct  8 20:41:20 meteo weewx[20330]: wmr300x: read counts;
Oct  8 20:41:20 meteo weewx[20330]: wmr300x: write counts;
Oct  8 20:41:29 meteo weewx[20330]: wmr300x: Loop data packets in heartbeat 
interval = 0
Oct  8 20:41:30 meteo weewx[20330]: wmr300x: No loop data in heartbeat 
interval,  restarting
Oct  8 20:41:40 meteo weewx[20330]: wmr300x: read counts;
Oct  8 20:41:40 meteo weewx[20330]: wmr300x: write counts;
Oct  8 20:41:54 meteo weewx[20330]: wmr300x: Loop data packets in heartbeat 
interval = 0
Oct  8 20:41:54 meteo weewx[20330]: wmr300x: No loop data in heartbeat 
interval,  restarting
Oct  8 20:42:00 meteo weewx[20330]: wmr300x: read counts;
Oct  8 20:42:00 meteo weewx[20330]: wmr300x: write counts;
Oct  8 20:42:18 meteo weewx[20330]: wmr300x: Loop data packets in heartbeat 
interval = 0
Oct  8 20:42:18 meteo weewx[20330]: wmr300x: No loop data in heartbeat 
interval,  restarting
Oct  8 20:42:20 meteo weewx[20330]: wmr300x: read counts;
Oct  8 20:42:20 meteo weewx[20330]: wmr300x: write counts;

And a lot of log lines like these.

pi@meteo:~ $ lsusb
Bus 001 Device 002: ID 0fde:ca08 Oregon Scientific
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@meteo:~ $

Then trying to restart weewx:

Oct  8 21:51:57 meteo weewx[8577]: wmr300x: history limit is 6% at index 
1994
Oct  8 21:51:57 meteo weewx[8577]: wmr300x: using PyUSB backend: libusb1
Oct  8 21:51:57 meteo kernel: [337451.298735] Indeed it is in host mode 
hprt0 = 00021501
Oct  8 21:51:58 meteo kernel: [337451.505449] usb 1-1: reset full-speed USB 
device number 2 using dwc_otg
Oct  8 21:51:58 meteo kernel: [337451.505671] Indeed it is in host mode 
hprt0 = 00021501
Oct  8 21:52:15 meteo weewx[8577]: import of driver failed: Init comm 
failed after 3 tries ()
Oct  8 21:52:15 meteo weewx[8577]: engine: Unable to load driver: Init comm 
failed after 3 tries
Oct  8 21:52:15 meteo weewx[8577]:   Exiting...

I have had to reboot the raspberry and after that weewx went up again.

Thank's

-- 
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 - intermittent and partial loss of loop data

[Cameron D]

It seems that firmware was issued in 2013.
The current Firmware version is printed in log file every time weewx is 
started - look for "Communication established" and then is shows
'Station_model' : 'A004'
Where A is Europe model and 4 is firmware version.

If you are able to connect a Windows PC and run that software, that is the 
first thing you should be testing.

>From what the logs are reporting, I cannot see how it has anything to do 
with 3.8.2 or Belchertown extension.  If you really want to prove that, is 
it possible to run the driver alone, with suitable debug settings defined 
in the driver.

Cameron.

On Monday, 8 October 2018 04:02:56 UTC+10, Juan Antonio Mosquera wrote:
>
> When I checked the console it seemed all right. These problems only happen 
> to me since version 3.8.2 and since I tried Belchertown extension.
> Cameron, could you send me the WMR300 driver used in weewx 3.8.2?
>
> Ruben: I do not know if there are several firmware, is it possible to 
> update the firmware with the windows application of the Oregon?
>
> Greetings and thanks.
>
> El domingo, 7 de octubre de 2018, 14:32:23 (UTC+2), Cameron D escribió:
>>
>> Every wind reading seems to be zero. Interestingly, the gust direction is 
>> changing, as you would expect.
>>
>> All I can think of is maybe the console is confused about units. I am 
>> lost... Some random suggestions...
>>
>>1. Try cycling through the units on the console display (this should 
>>not change the units used for transmission to the computer.
>>2. Try a console reset.
>>3. Try connecting with the Windows software and see if it records 
>>wind properly - check both the history records from when it starts up and 
>>the live update
>>
>> Also, when you post long logs, it is easier for me to handle a 
>> zipped/gzipped  attachment, rather than embedding it in-line.
>>
>> Cameron.
>>
>>
>> On Sunday, 7 October 2018 19:30:22 UTC+10, Juan Antonio Mosquera wrote:
>>>
>>> Thanks, results:
>>>
>>>
>>> ...
>>> Oct 07 11:29:22 meteomontaos weewx[22943]: wmr300x: raw packet: 
>>> {'wind_gust': 0.0, 'ts': 1538904540.0, 'wind_avg': 0.0, 'packet_type': 212, 
>>> 'wind_dir': 30.0, 'wind_gust_dir': 26.0, 'channel': 1, 'windchill': None}
>>> Oct 07 11:29:22 meteomontaos weewx[22943]: wmr300x: converted packet: 
>>> {'windchill': None, 'dateTime': 1538904562, 'windDir': 30.0, 'windSpeed': 
>>> 0.0, 'windGust': 0.0, 'usUnits': 17, 'windGustDir': 26.0}...
>>>
>>

-- 
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 - intermittent and partial loss of loop data

[Ruben Navarro Huedo]

Have a look at the website:

Improvement on main unit firmware (v4) 


   - Bug fix on wind speed function 



El domingo, 7 de octubre de 2018, 20:27:38 (UTC+2), Juan Antonio Mosquera 
escribió:
>
> more info:
>
> http://weather.oregonscientific.com/update.html
>
> El domingo, 7 de octubre de 2018, 19:35:25 (UTC+2), Ruben Navarro Huedo 
> escribió:
>>
>> I think:
>>
>> All the consoles have the same firmware? 
>> Is possible his console is using another firmware / protocol?
>>
>> El domingo, 7 de octubre de 2018, 14:32:23 (UTC+2), Cameron D escribió:
>>>
>>> Every wind reading seems to be zero. Interestingly, the gust direction 
>>> is changing, as you would expect.
>>>
>>> All I can think of is maybe the console is confused about units. I am 
>>> lost... Some random suggestions...
>>>
>>>1. Try cycling through the units on the console display (this should 
>>>not change the units used for transmission to the computer.
>>>2. Try a console reset.
>>>3. Try connecting with the Windows software and see if it records 
>>>wind properly - check both the history records from when it starts up 
>>> and 
>>>the live update
>>>
>>> Also, when you post long logs, it is easier for me to handle a 
>>> zipped/gzipped  attachment, rather than embedding it in-line.
>>>
>>> Cameron.
>>>
>>>
>>> On Sunday, 7 October 2018 19:30:22 UTC+10, Juan Antonio Mosquera wrote:

 Thanks, results:


 ...
 Oct 07 11:29:22 meteomontaos weewx[22943]: wmr300x: raw packet: 
 {'wind_gust': 0.0, 'ts': 1538904540.0, 'wind_avg': 0.0, 'packet_type': 
 212, 
 'wind_dir': 30.0, 'wind_gust_dir': 26.0, 'channel': 1, 'windchill': None}
 Oct 07 11:29:22 meteomontaos weewx[22943]: wmr300x: converted packet: 
 {'windchill': None, 'dateTime': 1538904562, 'windDir': 30.0, 'windSpeed': 
 0.0, 'windGust': 0.0, 'usUnits': 17, 'windGustDir': 26.0}...

>>>

-- 
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 - intermittent and partial loss of loop data

[Juan Antonio Mosquera]

more info:

http://weather.oregonscientific.com/update.html

El domingo, 7 de octubre de 2018, 19:35:25 (UTC+2), Ruben Navarro Huedo 
escribió:
>
> I think:
>
> All the consoles have the same firmware? 
> Is possible his console is using another firmware / protocol?
>
> El domingo, 7 de octubre de 2018, 14:32:23 (UTC+2), Cameron D escribió:
>>
>> Every wind reading seems to be zero. Interestingly, the gust direction is 
>> changing, as you would expect.
>>
>> All I can think of is maybe the console is confused about units. I am 
>> lost... Some random suggestions...
>>
>>1. Try cycling through the units on the console display (this should 
>>not change the units used for transmission to the computer.
>>2. Try a console reset.
>>3. Try connecting with the Windows software and see if it records 
>>wind properly - check both the history records from when it starts up and 
>>the live update
>>
>> Also, when you post long logs, it is easier for me to handle a 
>> zipped/gzipped  attachment, rather than embedding it in-line.
>>
>> Cameron.
>>
>>
>> On Sunday, 7 October 2018 19:30:22 UTC+10, Juan Antonio Mosquera wrote:
>>>
>>> Thanks, results:
>>>
>>>
>>> ...
>>> Oct 07 11:29:22 meteomontaos weewx[22943]: wmr300x: raw packet: 
>>> {'wind_gust': 0.0, 'ts': 1538904540.0, 'wind_avg': 0.0, 'packet_type': 212, 
>>> 'wind_dir': 30.0, 'wind_gust_dir': 26.0, 'channel': 1, 'windchill': None}
>>> Oct 07 11:29:22 meteomontaos weewx[22943]: wmr300x: converted packet: 
>>> {'windchill': None, 'dateTime': 1538904562, 'windDir': 30.0, 'windSpeed': 
>>> 0.0, 'windGust': 0.0, 'usUnits': 17, 'windGustDir': 26.0}...
>>>
>>

-- 
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 - intermittent and partial loss of loop data

[Juan Antonio Mosquera]

When I checked the console it seemed all right. These problems only happen 
to me since version 3.8.2 and since I tried Belchertown extension.
Cameron, could you send me the WMR300 driver used in weewx 3.8.2?

Ruben: I do not know if there are several firmware, is it possible to 
update the firmware with the windows application of the Oregon?

Greetings and thanks.

El domingo, 7 de octubre de 2018, 14:32:23 (UTC+2), Cameron D escribió:
>
> Every wind reading seems to be zero. Interestingly, the gust direction is 
> changing, as you would expect.
>
> All I can think of is maybe the console is confused about units. I am 
> lost... Some random suggestions...
>
>1. Try cycling through the units on the console display (this should 
>not change the units used for transmission to the computer.
>2. Try a console reset.
>3. Try connecting with the Windows software and see if it records wind 
>properly - check both the history records from when it starts up and the 
>live update
>
> Also, when you post long logs, it is easier for me to handle a 
> zipped/gzipped  attachment, rather than embedding it in-line.
>
> Cameron.
>
>
> On Sunday, 7 October 2018 19:30:22 UTC+10, Juan Antonio Mosquera wrote:
>>
>> Thanks, results:
>>
>>
>> ...
>> Oct 07 11:29:22 meteomontaos weewx[22943]: wmr300x: raw packet: 
>> {'wind_gust': 0.0, 'ts': 1538904540.0, 'wind_avg': 0.0, 'packet_type': 212, 
>> 'wind_dir': 30.0, 'wind_gust_dir': 26.0, 'channel': 1, 'windchill': None}
>> Oct 07 11:29:22 meteomontaos weewx[22943]: wmr300x: converted packet: 
>> {'windchill': None, 'dateTime': 1538904562, 'windDir': 30.0, 'windSpeed': 
>> 0.0, 'windGust': 0.0, 'usUnits': 17, 'windGustDir': 26.0}...
>>
>

-- 
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 - intermittent and partial loss of loop data

[Ruben Navarro Huedo]

I think:

All the consoles have the same firmware? 
Is possible his console is using another firmware / protocol?

El domingo, 7 de octubre de 2018, 14:32:23 (UTC+2), Cameron D escribió:
>
> Every wind reading seems to be zero. Interestingly, the gust direction is 
> changing, as you would expect.
>
> All I can think of is maybe the console is confused about units. I am 
> lost... Some random suggestions...
>
>1. Try cycling through the units on the console display (this should 
>not change the units used for transmission to the computer.
>2. Try a console reset.
>3. Try connecting with the Windows software and see if it records wind 
>properly - check both the history records from when it starts up and the 
>live update
>
> Also, when you post long logs, it is easier for me to handle a 
> zipped/gzipped  attachment, rather than embedding it in-line.
>
> Cameron.
>
>
> On Sunday, 7 October 2018 19:30:22 UTC+10, Juan Antonio Mosquera wrote:
>>
>> Thanks, results:
>>
>>
>> ...
>> Oct 07 11:29:22 meteomontaos weewx[22943]: wmr300x: raw packet: 
>> {'wind_gust': 0.0, 'ts': 1538904540.0, 'wind_avg': 0.0, 'packet_type': 212, 
>> 'wind_dir': 30.0, 'wind_gust_dir': 26.0, 'channel': 1, 'windchill': None}
>> Oct 07 11:29:22 meteomontaos weewx[22943]: wmr300x: converted packet: 
>> {'windchill': None, 'dateTime': 1538904562, 'windDir': 30.0, 'windSpeed': 
>> 0.0, 'windGust': 0.0, 'usUnits': 17, 'windGustDir': 26.0}...
>>
>

-- 
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 - intermittent and partial loss of loop data

[Cameron D]

Every wind reading seems to be zero. Interestingly, the gust direction is 
changing, as you would expect.

All I can think of is maybe the console is confused about units. I am 
lost... Some random suggestions...

   1. Try cycling through the units on the console display (this should not 
   change the units used for transmission to the computer.
   2. Try a console reset.
   3. Try connecting with the Windows software and see if it records wind 
   properly - check both the history records from when it starts up and the 
   live update

Also, when you post long logs, it is easier for me to handle a 
zipped/gzipped  attachment, rather than embedding it in-line.

Cameron.


On Sunday, 7 October 2018 19:30:22 UTC+10, Juan Antonio Mosquera wrote:
>
> Thanks, results:
>
>
> ...
> Oct 07 11:29:22 meteomontaos weewx[22943]: wmr300x: raw packet: 
> {'wind_gust': 0.0, 'ts': 1538904540.0, 'wind_avg': 0.0, 'packet_type': 212, 
> 'wind_dir': 30.0, 'wind_gust_dir': 26.0, 'channel': 1, 'windchill': None}
> Oct 07 11:29:22 meteomontaos weewx[22943]: wmr300x: converted packet: 
> {'windchill': None, 'dateTime': 1538904562, 'windDir': 30.0, 'windSpeed': 
> 0.0, 'windGust': 0.0, 'usUnits': 17, 'windGustDir': 26.0}...
>

-- 
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 - intermittent and partial loss of loop data

[Cameron D]

That means "wind" data packets are being reported, but it does not tell you 
the contents.
For that, enable "debug_packet=1"
and run for a short time while you know it is windy. A few minutes will be 
enough then disable debug-packet again.

A separate test is stop weewx for maybe 20 to 30 minutes and restart - see 
if the wmr300 reports sensible wind results in the history.

Cameron.

On Saturday, 6 October 2018 19:20:27 UTC+10, Juan Antonio Mosquera wrote:
>
> It's weird, it seems that wind data does read no?
>
>
> Oct 06 11:17:13 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 
> 135; TH_0: 11; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; 
> TH_7: 10; TH_8: 10; barom: 10; forecast: 12; rain: 12; wind: 16; x57: 1
> Oct 06 11:17:13 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
> Oct 06 11:17:33 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 
> 135; TH_0: 10; TH_1: 16; TH_2: 11; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; 
> TH_7: 10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
>
>

-- 
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 - intermittent and partial loss of loop data

[Ruben Navarro Huedo]

i think Wind is ok here with x version.

Oct  6 14:06:41 meteo weewx[16870]: wmr300x: read counts; Loop: 134; TH_0: 
10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 10; 
TH_8: 10; barom: 10; forecast: 11; rain: 12; wind: 16; x57: 1
Oct  6 14:06:41 meteo weewx[16870]: wmr300x: write counts; xa6: 1
Oct  6 14:07:01 meteo weewx[16870]: wmr300x: read counts; Loop: 134; TH_0: 
10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 10; 
TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16
Oct  6 14:07:01 meteo weewx[16870]: wmr300x: write counts;
Oct  6 14:07:21 meteo weewx[16870]: wmr300x: read counts; Loop: 135; TH_0: 
10; TH_1: 17; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 10; 
TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
Oct  6 14:07:21 meteo weewx[16870]: wmr300x: write counts; xa6: 1
Oct  6 14:07:41 meteo weewx[16870]: wmr300x: read counts; Loop: 135; TH_0: 
11; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 10; 
TH_8: 10; barom: 10; forecast: 11; rain: 12; wind: 16; x57: 1
Oct  6 14:07:41 meteo weewx[16870]: wmr300x: write counts; xa6: 1
Oct  6 14:08:01 meteo weewx[16870]: wmr300x: read counts; Loop: 135; TH_0: 
10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 11; 
TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
Oct  6 14:08:01 meteo weewx[16870]: wmr300x: write counts; xa6: 1
Oct  6 14:08:21 meteo weewx[16870]: wmr300x: read counts; Loop: 134; TH_0: 
10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 10; 
TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
Oct  6 14:08:21 meteo weewx[16870]: wmr300x: write counts; xa6: 1
Oct  6 14:08:41 meteo weewx[16870]: wmr300x: read counts; Loop: 134; TH_0: 
10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 10; 
TH_8: 10; barom: 10; forecast: 11; rain: 12; wind: 16; x57: 1
Oct  6 14:08:41 meteo weewx[16870]: wmr300x: write counts; xa6: 1
Oct  6 14:09:01 meteo weewx[16870]: wmr300x: read counts; Loop: 134; TH_0: 
10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 10; 
TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
Oct  6 14:09:01 meteo weewx[16870]: wmr300x: write counts; xa6: 1


El sábado, 6 de octubre de 2018, 11:20:27 (UTC+2), Juan Antonio Mosquera 
escribió:
>
> It's weird, it seems that wind data does read no?
>
>
> Oct 06 11:17:13 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 
> 135; TH_0: 11; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; 
> TH_7: 10; TH_8: 10; barom: 10; forecast: 12; rain: 12; wind: 16; x57: 1
> Oct 06 11:17:13 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
> Oct 06 11:17:33 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 
> 135; TH_0: 10; TH_1: 16; TH_2: 11; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; 
> TH_7: 10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
> Oct 06 11:17:33 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
> Oct 06 11:17:53 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 
> 134; TH_0: 10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; 
> TH_7: 10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
> Oct 06 11:17:53 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
> Oct 06 11:18:14 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 
> 135; TH_0: 10; TH_1: 16; TH_2: 10; TH_3: 11; TH_4: 10; TH_5: 10; TH_6: 10; 
> TH_7: 10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16
> Oct 06 11:18:14 meteomontaos weewx[10621]: wmr300x: write counts;
> Oct 06 11:18:34 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 
> 136; TH_0: 11; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 11; TH_5: 10; TH_6: 10; 
> TH_7: 10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
> Oct 06 11:18:34 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
> Oct 06 11:18:54 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 
> 135; TH_0: 10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 11; TH_6: 10; 
> TH_7: 10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
> Oct 06 11:18:54 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
> Oct 06 11:19:14 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 
> 135; TH_0: 10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 11; 
> TH_7: 10; TH_8: 10; barom: 10; forecast: 11; rain: 12; wind: 16; x57: 1
> Oct 06 11:19:14 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
> Oct 06 11:19:34 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 
> 134; TH_0: 10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; 
> TH_7: 10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
> Oct 06 11:19:34 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
> Oct 06 11:19:54 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 
> 135; TH_0: 10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; 
> TH_7: 11; TH_8: 10; barom: 10; forecast: 10; 

[weewx-user] Re: WMR300 - intermittent and partial loss of loop data

[Ruben Navarro Huedo]

A lot of thank's.

Running now x version:

Oct  6 13:59:53 meteo weewx[16870]: wmr300x: driver version is 0.19rc6+f3
Oct  6 13:59:53 meteo weewx[16870]: wmr300x: usb info: pyusb_version=1.0.0
Oct  6 13:59:53 meteo weewx[16870]: wmr300x: sensor map is {'outHumidity': 
'humidity_1', 'extraDewpoint6': 'dewpoint_7', 'windchill': 'windchill', 
'extraDewpoint4': 'dewpoint_5', 'rainRate': 'rain_rate', 'heatindex': 
'heatindex_1', 'inTemp': 'temperature_0', 'windGustDir': 'wind_gust_dir', 
'extraDewpoint2': 'dewpoint_3', 'extraDewpoint3': 'dewpoint_4', 
'extraDewpoint1': 'dewpoint_2', 'barometer': 'barometer', 'extraDewpoint7': 
'dewpoint_8', 'dewpoint': 'dewpoint_1', 'extraDewpoint5': 'dewpoint_6', 
'extraHumid6': 'humidity_7', 'pressure': 'pressure', 'extraHumid4': 
'humidity_5', 'extraHumid5': 'humidity_6', 'extraHumid2': 'humidity_3', 
'extraHumid3': 'humidity_4', 'extraHumid1': 'humidity_2', 'extraTemp6': 
'temperature_7', 'extraTemp7': 'temperature_8', 'extraTemp4': 
'temperature_5', 'extraTemp5': 'temperature_6', 'extraTemp2': 
'temperature_3', 'extraTemp3': 'temperature_4', 'extraTemp1': 
'temperature_2', 'extraHeatindex3': 'heatindex_4', 'extraHeatindex2': 
'heatindex_3', 'extraHeatindex1': 'heatindex_2', 'extraHeatindex7': 
'heatindex_8', 'extraHeatindex6': 'heatindex_7', 'extraHeatindex5': 
'heatindex_6', 'extraHumid7': 'humidity_8', 'extraHeatindex4': 
'heatindex_5', 'windDir': 'wind_dir', 'outTemp': 'temperature_1', 
'windSpeed': 'wind_avg', 'inHumidity': 'humidity_0', 'windGust': 
'wind_gust'}
Oct  6 13:59:53 meteo weewx[16870]: wmr300x: history limit is 6% at index 
1994
Oct  6 13:59:53 meteo weewx[16870]: wmr300x: using PyUSB backend: libusb1


El sábado, 6 de octubre de 2018, 1:09:44 (UTC+2), Cameron D escribió:
>
> There is something not right in your configuration file.
> In /etc/weewx/weewx.conf:
>
> 1. You should duplicate the block under [WMR300] and assign a new label 
> WMR300x, similar to this:
>
> ##
>
> [WMR300]
> # This section is for WMR300 weather stations
>
> # The station model, e.g., WMR300A
> model = WMR300
>
> # The driver to use:
> #driver = weewx.drivers.wmr300
> driver = user.wmr300-v19rc6+f3
>
> history_limit = 6
>
> debug_counts = 1
> debug_decode = 0
> debug_comm = 0
> debug_history = 0
> debug_timing = 1
> debug_rain = 0
>
>
> ##
> [WMR300x]
> # This section is for WMR300 weather stations. experimental driver
>
> # The station model, e.g., WMR300A
> model = WMR300x
>
> # The driver to use:
> driver = user.wmr300x-v19rc6+f3
>
> history_limit = 6
>
> debug_counts = 1
> debug_decode = 0
> debug_comm = 0
> debug_history = 0
> debug_timing = 1
> debug_rain = 0
> # Set debug_backend to 0 for default lib
> # 1 for libusb0
> # 2 for libusb1
> # 3 for openusb
> # 4 for ... depends on local pyusb
> debug_backend = 0
>
>
> ##
>
>
> the "driver" line needs to point to the correct driver file location.
> This makes it much clearer in the logs which driver is being used.
>
> Then, to switch drivers, simply edit the "station_type" in the "[Station]" 
> block.
>
>
> Cameron.
>
>
> On Saturday, 6 October 2018 05:35:23 UTC+10, Ruben Navarro Huedo wrote:
>>
>> Testing x version under last raspbian version:
>>
>> ...
>> Oct  5 21:33:51 meteo weewx[10082]: engine: Using configuration file 
>> /etc/weewx/weewx.conf
>> Oct  5 21:33:51 meteo weewx[10082]: engine: Loading station type WMR300 
>> (weewx.drivers.wmr300)
>> Oct  5 21:33:51 meteo weewx[10082]: import of driver failed: 'WMR300x' 
>> ()
>> Oct  5 21:33:51 meteo weewx[10082]: engine: Unable to load driver: 
>> 'WMR300x'
>> Oct  5 21:33:51 meteo weewx[10082]:   Exiting...
>>
>> Testing now NON-X version.
>>
>>
>> El jueves, 4 de octubre de 2018, 16:22:22 (UTC+2), Cameron D escribió:
>>>
>>> The rc5 and rc6 drivers shjipped with the weewx releases had issues 
>>> where, after some time (days to weeks) the system would stop reporting any 
>>> data.
>>> That was addressed in this update of 24th September 
>>> .
>>>
>>> At least two users have reported a different problem, where there is 
>>> only partial loss, for example wind or temperature and humidity.
>>>
>>>1. Juan Antonio Mosquera reports wind data missing 
>>>
>>>.
>>>2. Markus Biewer reports temperature/humidity, and sometimes other 
>>>data going missing after about a week 
>>>
>>>.
>>>
>>> Initially it looked like it might have been related to Belchertown skin, 
>>> but it is reported to also be 

[weewx-user] Re: WMR300 - intermittent and partial loss of loop data

[Juan Antonio Mosquera]

It's weird, it seems that wind data does read no?


Oct 06 11:17:13 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 135; 
TH_0: 11; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 
10; TH_8: 10; barom: 10; forecast: 12; rain: 12; wind: 16; x57: 1
Oct 06 11:17:13 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
Oct 06 11:17:33 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 135; 
TH_0: 10; TH_1: 16; TH_2: 11; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 
10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
Oct 06 11:17:33 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
Oct 06 11:17:53 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 134; 
TH_0: 10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 
10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
Oct 06 11:17:53 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
Oct 06 11:18:14 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 135; 
TH_0: 10; TH_1: 16; TH_2: 10; TH_3: 11; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 
10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16
Oct 06 11:18:14 meteomontaos weewx[10621]: wmr300x: write counts;
Oct 06 11:18:34 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 136; 
TH_0: 11; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 11; TH_5: 10; TH_6: 10; TH_7: 
10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
Oct 06 11:18:34 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
Oct 06 11:18:54 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 135; 
TH_0: 10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 11; TH_6: 10; TH_7: 
10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
Oct 06 11:18:54 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
Oct 06 11:19:14 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 135; 
TH_0: 10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 11; TH_7: 
10; TH_8: 10; barom: 10; forecast: 11; rain: 12; wind: 16; x57: 1
Oct 06 11:19:14 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
Oct 06 11:19:34 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 134; 
TH_0: 10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 
10; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
Oct 06 11:19:34 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1
Oct 06 11:19:54 meteomontaos weewx[10621]: wmr300x: read counts; Loop: 135; 
TH_0: 10; TH_1: 16; TH_2: 10; TH_3: 10; TH_4: 10; TH_5: 10; TH_6: 10; TH_7: 
11; TH_8: 10; barom: 10; forecast: 10; rain: 12; wind: 16; x57: 1
Oct 06 11:19:54 meteomontaos weewx[10621]: wmr300x: write counts; xa6: 1


Thanks.


El jueves, 4 de octubre de 2018, 16:22:22 (UTC+2), Cameron D escribió:
>
> The rc5 and rc6 drivers shjipped with the weewx releases had issues where, 
> after some time (days to weeks) the system would stop reporting any data.
> That was addressed in this update of 24th September 
> .
>
> At least two users have reported a different problem, where there is only 
> partial loss, for example wind or temperature and humidity.
>
>1. Juan Antonio Mosquera reports wind data missing 
>.
>2. Markus Biewer reports temperature/humidity, and sometimes other data 
>going missing after about a week 
>.
>
> Initially it looked like it might have been related to Belchertown skin, 
> but it is reported to also be an issue with the standard skin.
>
> The attached zip file has 3 files:
>
>1. *wmr300-v19rc6+f3.py*  - and updated version of the main wmr300 
>driver - this has a couple of minor bug fixes as well as extra diagnostic 
>code for this problem.
>2. *summ-pkt-data.awk*  -   an awk script to  convert the new 
>diagnostic logfile data into a csv file.
>3. *wmr300x-v19rc6+f3.py* - note the 'x'. This is the experimental 
>driver that uses pyusb 1 and libusb1 if available.  It also contains the 
>extra diagnostics, but is included for the other issue where the pi locks 
>up completely.
>
> *New Diagnostics*:
>
> In your weewx.conf file, enable
>   debug=1
>
> and in the WMR300 section I would suggest the following:
> debug_counts = 1
> debug_decode = 0
> debug_comm = 0
> debug_history = 0
> debug_timing = 1
> debug_rain = 0
>
> The debug_counts setting will output a summary of each packet type read 
> from the USB  in a specified time interval (default 20 seconds) as well as 
> the number of loop packets sent to weewx.
>
> Here is my WMR300 section
>
> ##
>
> [WMR300]
> # This section is for WMR300 weather stations
>
> # The station model, e.g., WMR300A
> model = WMR300
>
> # The driver to use:
> driver = 

[weewx-user] Re: WMR300 - intermittent and partial loss of loop data

[Juan Antonio Mosquera]

In the first tests with the WMR300 and WMR300x driver neither of them 
obtains the wind data.

Greetings and thanks.

El jueves, 4 de octubre de 2018, 16:22:22 (UTC+2), Cameron D escribió:
>
> The rc5 and rc6 drivers shjipped with the weewx releases had issues where, 
> after some time (days to weeks) the system would stop reporting any data.
> That was addressed in this update of 24th September 
> .
>
> At least two users have reported a different problem, where there is only 
> partial loss, for example wind or temperature and humidity.
>
>1. Juan Antonio Mosquera reports wind data missing 
>.
>2. Markus Biewer reports temperature/humidity, and sometimes other data 
>going missing after about a week 
>.
>
> Initially it looked like it might have been related to Belchertown skin, 
> but it is reported to also be an issue with the standard skin.
>
> The attached zip file has 3 files:
>
>1. *wmr300-v19rc6+f3.py*  - and updated version of the main wmr300 
>driver - this has a couple of minor bug fixes as well as extra diagnostic 
>code for this problem.
>2. *summ-pkt-data.awk*  -   an awk script to  convert the new 
>diagnostic logfile data into a csv file.
>3. *wmr300x-v19rc6+f3.py* - note the 'x'. This is the experimental 
>driver that uses pyusb 1 and libusb1 if available.  It also contains the 
>extra diagnostics, but is included for the other issue where the pi locks 
>up completely.
>
> *New Diagnostics*:
>
> In your weewx.conf file, enable
>   debug=1
>
> and in the WMR300 section I would suggest the following:
> debug_counts = 1
> debug_decode = 0
> debug_comm = 0
> debug_history = 0
> debug_timing = 1
> debug_rain = 0
>
> The debug_counts setting will output a summary of each packet type read 
> from the USB  in a specified time interval (default 20 seconds) as well as 
> the number of loop packets sent to weewx.
>
> Here is my WMR300 section
>
> ##
>
> [WMR300]
> # This section is for WMR300 weather stations
>
> # The station model, e.g., WMR300A
> model = WMR300
>
> # The driver to use:
> driver = user.wmr300-v19rc6+f3
>
> history_limit = 6
>
> debug_counts = 1
> debug_decode = 0
> debug_comm = 0
> debug_history = 1
> debug_timing = 1
> debug_rain = 0
>
>
> ##
>
> Note that I recommend placing these drivers in the "user" directory of the 
> weewx installation.
> You can also create a similar section named *[WMR300x]* to use the 
> experimental driver, and select between them by editing this line in the 
> *[Station]* section:
>  station_type = WMR300
>
> *Experimental driver:*
> This driver uses the PyUSB version 1 API, which allows it to use libusb1 
> or other usb libraries.
> It will default to libusb1 if possible, but otherwise will fall back to 
> libusb0.
>
> Note that some versions of Ubuntu seemed to ship with a beta version of 
> PyUSB-1 that did not seem to support the full api.  If it reports a version 
> beginning "1.0.0b..." then the driver will use libusb0.
>
> If you enable the experimental version then check the log file when it 
> starts up:
> It will always show pyusb_version, and the experimental driver will print 
> which usb backend library is selected.
>
> grep -i pyusb (your-logfile)
>
> will display both.
>

-- 
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 - intermittent and partial loss of loop data

[Cameron D]

There is something not right in your configuration file.
In /etc/weewx/weewx.conf:

1. You should duplicate the block under [WMR300] and assign a new label 
WMR300x, similar to this:
##

[WMR300]
# This section is for WMR300 weather stations

# The station model, e.g., WMR300A
model = WMR300

# The driver to use:
#driver = weewx.drivers.wmr300
driver = user.wmr300-v19rc6+f3

history_limit = 6

debug_counts = 1
debug_decode = 0
debug_comm = 0
debug_history = 0
debug_timing = 1
debug_rain = 0

##
[WMR300x]
# This section is for WMR300 weather stations. experimental driver

# The station model, e.g., WMR300A
model = WMR300x

# The driver to use:
driver = user.wmr300x-v19rc6+f3

history_limit = 6

debug_counts = 1
debug_decode = 0
debug_comm = 0
debug_history = 0
debug_timing = 1
debug_rain = 0
# Set debug_backend to 0 for default lib
# 1 for libusb0
# 2 for libusb1
# 3 for openusb
# 4 for ... depends on local pyusb
debug_backend = 0

##


the "driver" line needs to point to the correct driver file location.
This makes it much clearer in the logs which driver is being used.

Then, to switch drivers, simply edit the "station_type" in the "[Station]" 
block.


Cameron.


On Saturday, 6 October 2018 05:35:23 UTC+10, Ruben Navarro Huedo wrote:
>
> Testing x version under last raspbian version:
>
> ...
> Oct  5 21:33:51 meteo weewx[10082]: engine: Using configuration file 
> /etc/weewx/weewx.conf
> Oct  5 21:33:51 meteo weewx[10082]: engine: Loading station type WMR300 
> (weewx.drivers.wmr300)
> Oct  5 21:33:51 meteo weewx[10082]: import of driver failed: 'WMR300x' 
> ()
> Oct  5 21:33:51 meteo weewx[10082]: engine: Unable to load driver: 
> 'WMR300x'
> Oct  5 21:33:51 meteo weewx[10082]:   Exiting...
>
> Testing now NON-X version.
>
>
> El jueves, 4 de octubre de 2018, 16:22:22 (UTC+2), Cameron D escribió:
>>
>> The rc5 and rc6 drivers shjipped with the weewx releases had issues 
>> where, after some time (days to weeks) the system would stop reporting any 
>> data.
>> That was addressed in this update of 24th September 
>> .
>>
>> At least two users have reported a different problem, where there is only 
>> partial loss, for example wind or temperature and humidity.
>>
>>1. Juan Antonio Mosquera reports wind data missing 
>>.
>>2. Markus Biewer reports temperature/humidity, and sometimes other 
>>data going missing after about a week 
>>.
>>
>> Initially it looked like it might have been related to Belchertown skin, 
>> but it is reported to also be an issue with the standard skin.
>>
>> The attached zip file has 3 files:
>>
>>1. *wmr300-v19rc6+f3.py*  - and updated version of the main wmr300 
>>driver - this has a couple of minor bug fixes as well as extra diagnostic 
>>code for this problem.
>>2. *summ-pkt-data.awk*  -   an awk script to  convert the new 
>>diagnostic logfile data into a csv file.
>>3. *wmr300x-v19rc6+f3.py* - note the 'x'. This is the experimental 
>>driver that uses pyusb 1 and libusb1 if available.  It also contains the 
>>extra diagnostics, but is included for the other issue where the pi locks 
>>up completely.
>>
>> *New Diagnostics*:
>>
>> In your weewx.conf file, enable
>>   debug=1
>>
>> and in the WMR300 section I would suggest the following:
>> debug_counts = 1
>> debug_decode = 0
>> debug_comm = 0
>> debug_history = 0
>> debug_timing = 1
>> debug_rain = 0
>>
>> The debug_counts setting will output a summary of each packet type read 
>> from the USB  in a specified time interval (default 20 seconds) as well as 
>> the number of loop packets sent to weewx.
>>
>> Here is my WMR300 section
>>
>> ##
>>
>> [WMR300]
>> # This section is for WMR300 weather stations
>>
>> # The station model, e.g., WMR300A
>> model = WMR300
>>
>> # The driver to use:
>> driver = user.wmr300-v19rc6+f3
>>
>> history_limit = 6
>>
>> debug_counts = 1
>> debug_decode = 0
>> debug_comm = 0
>> debug_history = 1
>> debug_timing = 1
>> debug_rain = 0
>>
>>
>> ##
>>
>> Note that I recommend placing these drivers in the "user" directory of 
>> the weewx installation.
>> You can also create a similar section named *[WMR300x]* to use the 
>> experimental driver, and select between 

[weewx-user] Re: WMR300 - intermittent and partial loss of loop data

[Ruben Navarro Huedo]

Testing x version under last raspbian version:

Oct  5 21:33:50 meteo weewx[10078]: engine: Platform 
Linux-4.14.70+-armv6l-with-debian-9.4
Oct  5 21:33:50 meteo weewx[10078]: engine: Locale is 'es_ES.UTF-8'
Oct  5 21:33:50 meteo weewx[10078]: engine: pid file is /var/run/weewx.pid
Oct  5 21:33:50 meteo weewx[10067]: Starting weewx weather system: weewx.
Oct  5 21:33:50 meteo systemd[1]: Started LSB: weewx weather system.
Oct  5 21:33:51 meteo weewx[10082]: engine: Using configuration file 
/etc/weewx/weewx.conf
Oct  5 21:33:51 meteo weewx[10082]: engine: Loading station type WMR300 
(weewx.drivers.wmr300)
Oct  5 21:33:51 meteo weewx[10082]: import of driver failed: 'WMR300x' 
()
Oct  5 21:33:51 meteo weewx[10082]: engine: Unable to load driver: 'WMR300x'
Oct  5 21:33:51 meteo weewx[10082]:   Exiting...

Testing now NON-X version.


El jueves, 4 de octubre de 2018, 16:22:22 (UTC+2), Cameron D escribió:
>
> The rc5 and rc6 drivers shjipped with the weewx releases had issues where, 
> after some time (days to weeks) the system would stop reporting any data.
> That was addressed in this update of 24th September 
> .
>
> At least two users have reported a different problem, where there is only 
> partial loss, for example wind or temperature and humidity.
>
>1. Juan Antonio Mosquera reports wind data missing 
>.
>2. Markus Biewer reports temperature/humidity, and sometimes other data 
>going missing after about a week 
>.
>
> Initially it looked like it might have been related to Belchertown skin, 
> but it is reported to also be an issue with the standard skin.
>
> The attached zip file has 3 files:
>
>1. *wmr300-v19rc6+f3.py*  - and updated version of the main wmr300 
>driver - this has a couple of minor bug fixes as well as extra diagnostic 
>code for this problem.
>2. *summ-pkt-data.awk*  -   an awk script to  convert the new 
>diagnostic logfile data into a csv file.
>3. *wmr300x-v19rc6+f3.py* - note the 'x'. This is the experimental 
>driver that uses pyusb 1 and libusb1 if available.  It also contains the 
>extra diagnostics, but is included for the other issue where the pi locks 
>up completely.
>
> *New Diagnostics*:
>
> In your weewx.conf file, enable
>   debug=1
>
> and in the WMR300 section I would suggest the following:
> debug_counts = 1
> debug_decode = 0
> debug_comm = 0
> debug_history = 0
> debug_timing = 1
> debug_rain = 0
>
> The debug_counts setting will output a summary of each packet type read 
> from the USB  in a specified time interval (default 20 seconds) as well as 
> the number of loop packets sent to weewx.
>
> Here is my WMR300 section
>
> ##
>
> [WMR300]
> # This section is for WMR300 weather stations
>
> # The station model, e.g., WMR300A
> model = WMR300
>
> # The driver to use:
> driver = user.wmr300-v19rc6+f3
>
> history_limit = 6
>
> debug_counts = 1
> debug_decode = 0
> debug_comm = 0
> debug_history = 1
> debug_timing = 1
> debug_rain = 0
>
>
> ##
>
> Note that I recommend placing these drivers in the "user" directory of the 
> weewx installation.
> You can also create a similar section named *[WMR300x]* to use the 
> experimental driver, and select between them by editing this line in the 
> *[Station]* section:
>  station_type = WMR300
>
> *Experimental driver:*
> This driver uses the PyUSB version 1 API, which allows it to use libusb1 
> or other usb libraries.
> It will default to libusb1 if possible, but otherwise will fall back to 
> libusb0.
>
> Note that some versions of Ubuntu seemed to ship with a beta version of 
> PyUSB-1 that did not seem to support the full api.  If it reports a version 
> beginning "1.0.0b..." then the driver will use libusb0.
>
> If you enable the experimental version then check the log file when it 
> starts up:
> It will always show pyusb_version, and the experimental driver will print 
> which usb backend library is selected.
>
> grep -i pyusb (your-logfile)
>
> will display both.
>

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