No data from station

[Roland Ehle]

Hi all,

I have now attached my WMR300 to an Intel NUC running Ubuntu 16.04 LTS. Unfortunately weewx 3.6.1 is unable to read data from the station. Apparantly the reason is, that the USB device is reset by the Kernel, according to the log:

Oct 24 20:57:01 lin01 weewx[932]: engine: Loading station type WMR300 (weewx.drivers.wmr300)
Oct 24 20:57:01 lin01 weewx[932]: wmr300: driver version is 0.13
Oct 24 20:57:01 lin01 weewx[932]: wmr300: Found station at bus= device=
Oct 24 20:57:02 lin01 kernel: [ 2514.640999] usb 1-4: reset full-speed USB device number 5 using xhci_hcd

and Later:

Oct 24 20:55:46 lin01 weewx[932]: engine: Starting up weewx version 3.6.1
Oct 24 20:55:46 lin01 weewx[932]: engine: Station does not support reading the time
Oct 24 20:55:46 lin01 weewx[932]: wmr300: reading records since ******* N/A *******     (    N/A   )
Oct 24 20:55:46 lin01 weewx[932]: wmr300: read: failed attempt 1 of 5: [Errno 110] Operation timed out
Oct 24 20:55:49 lin01 weewx[932]: wmr300: read: failed attempt 2 of 5: [Errno 110] Operation timed out
Oct 24 20:55:52 lin01 weewx[932]: wmr300: read: failed attempt 3 of 5: [Errno 110] Operation timed out
Oct 24 20:55:55 lin01 weewx[932]: wmr300: read: failed attempt 4 of 5: [Errno 110] Operation timed out
Oct 24 20:55:58 lin01 weewx[932]: wmr300: read: failed attempt 5 of 5: [Errno 110] Operation timed out

I am about to give up and use a Raspberry Pi, but am hoping, that someone has a hint.

Thank you!

Regards,

Roland

[Roland Ehle]

I found this Thread: https://groups.google.com/forum/#!msg/weewx-user/FdapyM5Ku0U/c03far_WAQAJ but the thread is old and I am hoping, the bug mentioned there was fixed.

[mwall]

roland,

i think the timeouts are due to a usb initialization problem, which is in turn due to differences between how 'reset' works in different versions of libusb.

from the "Found station at bus= device=" i would guess that you are running libusb 1.0, but could you post the exact versions of pyusb and libusb on your ubuntu system?

i have been testing the wmr300 driver on ubuntu 14.04.1 with kernel 3.19.0-32-generic on x86_64 with these usb versions:

python-usb 0.4.3-1
libusb-1.0-0 1.0.17-1
libusb-0.1-4 0.1.12-23.3

m

[Roland Ehle]

Thanks for your response. If necessary I am willing to downgrade to ubuntu 14.04

I am on Ubuntu 16.04 with Kernel 4.4.0-45-generic

I have

python-usb 1.0.0~b2

libusb-1.0-0 1.0.20-1

libusb-0.1-4 0.1.23-28

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/YSz_IWnzOjE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roland Ehle]

Here is the output of lsusb -v -d

root@lin01:~# lsusb -v -d 0fde:ca08

Bus 001 Device 006: ID 0fde:ca08 Oregon Scientific
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x0fde Oregon Scientific
  idProduct          0xca08
  bcdDevice            0.20
  iManufacturer           1 Microchip Technology Inc.
  iProduct                2 USB HID Bootloader
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      29
          Report Descriptor: (length is 29)
            Item(Global): Usage Page, data= [ 0x00 0xff ] 65280
                            (null)
            Item(Local ): Usage, data= [ 0x01 ] 1
                            (null)
            Item(Main  ): Collection, data= [ 0x01 ] 1
                            Application
            Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                            (null)
            Item(Local ): Usage Maximum, data= [ 0x40 ] 64
                            (null)
            Item(Global): Logical Minimum, data= [ 0x00 ] 0
            Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255
            Item(Global): Report Size, data= [ 0x08 ] 8
            Item(Global): Report Count, data= [ 0x40 ] 64
            Item(Main  ): Input, data= [ 0x00 ] 0
                            Data Array Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                            (null)
            Item(Local ): Usage Maximum, data= [ 0x40 ] 64
                            (null)
            Item(Main  ): Output, data= [ 0x00 ] 0
                            Data Array Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Main  ): End Collection, data=none
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Status:     0x0001
  Self Powered
root@lin01:~#

[mwall]

On Tuesday, October 25, 2016 at 12:23:45 PM UTC-4, Roland Ehle wrote:

Thanks for your response. If necessary I am willing to downgrade to ubuntu 14.04

I am on Ubuntu 16.04 with Kernel 4.4.0-45-generic

I have

python-usb 1.0.0~b2

libusb-1.0-0 1.0.20-1

libusb-0.1-4 0.1.23-28

roland,

before you try a different version of ubuntu, please try downgrading python-usb (to 0.4.3)

m

[Roland Ehle]

Downgrade to python-usb 0.4.3 did not change the behavior. Clean install of Ubuntu 14.04.5 followed by a clean install of weewx 3.6.1 did not change the behavior. No I took a brand new Raspberry, put weewx on it, but I have exactly the same issue. In the past I was running my station on a Raspberry with weewx 3.5.0 successfully.

Station was reset using the reset button........

[vince]

On Thursday, October 27, 2016 at 1:12:29 PM UTC-7, Roland Ehle wrote:

Downgrade to python-usb 0.4.3 did not change the behavior. Clean install of Ubuntu 14.04.5 followed by a clean install of weewx 3.6.1 did not change the behavior. No I took a brand new Raspberry, put weewx on it, but I have exactly the same issue. In the past I was running my station on a Raspberry with weewx 3.5.0 successfully.

At this point it's unclear to me if it's software or hardware, so I'd suggest a clean Raspbian with weewx 3.5.0 on it to try to recreate the same config you had when it last worked.

[Roland Ehle]

Thank you Matthew. After some more digging and testing I came to the conclusion: It is not weewx itself that causes the issue, but the WMR300 driver for some reason. I downgraded to weewx 3.5.0 and everything worked fine. After copying the WMR300 driver files I upgraded again to the latest version and the issue was present again until I copied the driver version 0.10 to the location /usr/share/weewx/weewx/drivers.

So, after all, I have a working configuration :-) Thanks for your support

Regards,

Roland

[Alberto Sánchez]

I have had the same problem and I have solve it with the same solution. Using 3.5.0 wmr 300 driver.

Thank you

[Alberto Sánchez]

Sorry in my case I use a raspberry pi 3 with raspbyan Jessy.

[mwall]

On Tuesday, November 1, 2016 at 4:49:24 PM UTC-4, Alberto Sánchez wrote:

I have had the same problem and I have solve it with the same solution. Using 3.5.0 wmr 300 driver.

alberto, roland, and others,

please try the latest wmr300 driver (0.15rc1).  it uses the usb initialization logic from 0.10, but it has the pressure/barometer and wind direction fixex that came later.

https://github.com/weewx/weewx/blob/master/bin/weewx/drivers/wmr300.py

it turns out that the wmr300 stations do not default to spewing data to the usb - the driver must invoke an interruptWrite periodically to keep the data flowing.

m

[Roland Ehle]

I gave it a try, but I had the following errors in the log with debug = 0

Nov  3 18:01:42 lin01 weewx[19698]: wmr300: usb failure: could not detach kernel driver from interface 0: Keine Daten verfügbar
Nov  3 18:01:42 lin01 weewx[19698]: engine: Caught WeeWxIOError: could not detach kernel driver from interface 0: Keine Daten verfügbar
Nov  3 18:01:42 lin01 weewx[19698]:     ****  Waiting 60 seconds then retrying..

[mwall]

On Thursday, November 3, 2016 at 4:17:43 PM UTC-4, Alberto Sánchez wrote:

Thank you very much for your answer.

I have tested the new driver and report me this error:

alberto, the DOCTYPE indicates that the wmr300.py file was not downloaded properly.  you must download the raw .py file.  use this link instead:

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

 

[mwall]

On Thursday, November 3, 2016 at 1:07:53 PM UTC-4, Roland Ehle wrote:

I gave it a try, but I had the following errors in the log with debug = 0

Nov  3 18:01:42 lin01 weewx[19698]: wmr300: usb failure: could not detach kernel driver from interface 0: Keine Daten verfügbar
Nov  3 18:01:42 lin01 weewx[19698]: engine: Caught WeeWxIOError: could not detach kernel driver from interface 0: Keine Daten verfügbar
Nov  3 18:01:42 lin01 weewx[19698]:     ****  Waiting 60 seconds then retrying..

roland,

thank you for trying this.  please post the usb info for your system, specifically which libusb and pyusb.  for example, on a debian system do this:

dpkg -l | grep usb

m

[Alberto Sánchez]

Hi,

I just test the new driver and I have the same Roland error. Thank you very much.

[Roland Ehle]

ii  libusb-0.1-4:amd64                          2:0.1.12-28                                   amd64        userspace USB programming library
ii  libusb-1.0-0:amd64                          2:1.0.20-1                                    amd64        userspace USB programming library
hi  python-usb                                  0.4.3-1                                       amd64        USB interface for Python

I have downgraded to python-usb version 0.4.3 due to your recommendation.

System is running on Ubuntu 16.04 LTS with kernel 4.4.0-45-generic #66-Ubuntu

[Roland Ehle]

Full output of dpkg -l | grep usb is attached for better reading.

Regards,
Roland

Am Donnerstag, 3. November 2016 21:37:56 UTC+1 schrieb mwall:

[mwall]

On Thursday, November 3, 2016 at 4:45:22 PM UTC-4, Alberto Sánchez wrote:

Hi,

I just test the new driver and I have the same Roland error. Thank you very much.

alberto, could you post the errors you get with the 0.15rc1 driver?  thank you!
 

[Alberto Sánchez]

Hi Mwall,

Here my error, with Rasbian Jessy:


$ sudo /etc/init.d/weewx status -l
● weewx.service - LSB: weewx weather system
Loaded: loaded (/etc/init.d/weewx)
Active: active (running) since vie 2016-11-04 07:32:31 CET; 37s ago
Process: 19854 ExecStop=/etc/init.d/weewx stop (code=exited, status=0/SUCCESS)
Process: 19975 ExecStart=/etc/init.d/weewx start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/weewx.service
└─19990 python /usr/bin/weewxd --daemon --pidfile=/var/run/weewx.pid /etc/weewx/weewx.conf

nov 04 07:32:31 raspberrypi weewx[19990]: restx: Wunderground-PWS: Data for station IULTZAMA2 will be posted
nov 04 07:32:31 raspberrypi weewx[19990]: restx: PWSweather: Posting not enabled.
nov 04 07:32:31 raspberrypi weewx[19990]: restx: CWOP: Posting not enabled.
nov 04 07:32:31 raspberrypi weewx[19990]: restx: WOW: Posting not enabled.
nov 04 07:32:31 raspberrypi weewx[19990]: restx: AWEKAS: Posting not enabled.
nov 04 07:32:31 raspberrypi weewx[19990]: engine: Starting up weewx version 3.6.1
nov 04 07:32:31 raspberrypi weewx[19990]: wmr300: reading records since 2016-11-04 07:30:00 CET (1478241000)
nov 04 07:32:32 raspberrypi weewx[19990]: wmr300: usb failure: could not detach kernel driver from interface 0: No hay datos disponibles
nov 04 07:32:32 raspberrypi weewx[19990]: engine: Caught WeeWxIOError: could not detach kernel driver from interface 0: No hay datos disponibles
nov 04 07:32:32 raspberrypi weewx[19990]: **** Waiting 60 seconds then retrying...

[Alberto Sánchez]

pi@raspberrypi:~ $ dpkg -l | grep usb
ii libusb-0.1-4:armhf 2:0.1.12-25 armhf userspace USB programming library
ii libusb-1.0-0:armhf 2:1.0.19-1 armhf userspace USB programming library
ii libusbmuxd2:armhf 1.0.9-1 armhf USB multiplexor daemon for iPhone and iPod Touch devices - library
ii python-usb 0.4.3-1 armhf USB interface for Python
ii usb-modeswitch 2.2.0+repack0-2 armhf mode 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 armhf Linux USB utilities

[Alberto Sánchez]

I am noob with Raspberry and weewx, so I have done a clean installation of raspbian (Jessie) and Weewx 3.6.1 with the same result:

pi@raspberrypi:~ $ sudo /etc/init.d/weewx status -l

● weewx.service - LSB: weewx weather system

   Loaded: loaded (/etc/init.d/weewx)

   Active: active (running) since sáb 2016-11-05 13:52:08 CET; 5min ago

  Process: 426 ExecStart=/etc/init.d/weewx start (code=exited, status=0/SUCCESS)

   CGroup: /system.slice/weewx.service

           └─958 python /usr/bin/weewxd --daemon --pidfile=/var/run/weewx.pid /etc/weewx/weewx.conf

nov 05 13:57:13 raspberrypi weewx[958]: restx: PWSweather: Posting not enabled.

nov 05 13:57:13 raspberrypi weewx[958]: restx: CWOP: Posting not enabled.

nov 05 13:57:13 raspberrypi weewx[958]: restx: WOW: Posting not enabled.

nov 05 13:57:13 raspberrypi weewx[958]: restx: AWEKAS: Posting not enabled.

nov 05 13:57:13 raspberrypi weewx[958]: engine: Starting up weewx version 3.6.1

nov 05 13:57:13 raspberrypi weewx[958]: wmr300: reading records since ******* N/A *******     (    N/A   )

nov 05 13:57:13 raspberrypi weewx[958]: wmr300: read: failed attempt 1 of 5: could not detach kernel driver from interface 0: No hay datos disponibles

nov 05 13:57:16 raspberrypi weewx[958]: wmr300: read: failed attempt 2 of 5: could not detach kernel driver from interface 0: No hay datos disponibles

nov 05 13:57:19 raspberrypi weewx[958]: wmr300: read: failed attempt 3 of 5: could not detach kernel driver from interface 0: No hay datos disponibles

nov 05 13:57:22 raspberrypi weewx[958]: wmr300: read: failed attempt 4 of 5: could not detach kernel driver from interface 0: No hay datos disponibles

pi@raspberrypi:~ $ sudo /etc/init.d/weewx status

● weewx.service - LSB: weewx weather system

   Loaded: loaded (/etc/init.d/weewx)

   Active: active (exited) since sáb 2016-11-05 13:52:08 CET; 19h ago

  Process: 426 ExecStart=/etc/init.d/weewx start (code=exited, status=0/SUCCESS)

nov 05 19:27:17 raspberrypi weewx[958]: wmr300: read failed: max retries (5) exceeded

nov 05 19:27:17 raspberrypi weewx[958]: engine: Caught WeeWxIOError: read failed: max retries (5) exceeded

nov 05 19:27:17 raspberrypi weewx[958]: ****  Waiting 60 seconds then retrying...

nov 05 19:28:17 raspberrypi weewx[958]: engine: retrying...

nov 05 19:28:17 raspberrypi weewx[958]: engine: Using configuration file /etc/weewx/weewx.conf

nov 05 19:28:17 raspberrypi weewx[958]: engine: Loading station type WMR300 (weewx.drivers.wmr300)

nov 05 19:28:17 raspberrypi weewx[958]: wmr300: driver version is 0.13

nov 05 19:28:17 raspberrypi weewx[958]: import of driver failed: could not reset: No existe el dispositivo (<class 'usb.USBError'>)

nov 05 19:28:17 raspberrypi weewx[958]: engine: Unable to load driver: could not reset: No existe el dispositivo

nov 05 19:28:17 raspberrypi weewx[958]: ****  Exiting...

[Alberto Sánchez]

I have tried with 0.10 driver but I have error too. The only driver that I can use is 0.9.

0.10 driver error:

sudo /etc/init.d/weewx status -l

● weewx.service - LSB: weewx weather system

   Loaded: loaded (/etc/init.d/weewx)

   Active: active (running) since dom 2016-11-06 10:09:21 CET; 36s ago

  Process: 4943 ExecStop=/etc/init.d/weewx stop (code=exited, status=0/SUCCESS)

  Process: 5074 ExecStart=/etc/init.d/weewx start (code=exited, status=0/SUCCESS)

   CGroup: /system.slice/weewx.service

           └─5089 python /usr/bin/weewxd --daemon --pidfile=/var/run/weewx.pid /etc/weewx/weewx.conf

nov 06 10:09:22 raspberrypi weewx[5089]: restx: StationRegistry: Registration not requested.

nov 06 10:09:22 raspberrypi weewx[5089]: restx: Wunderground: Posting not enabled.

nov 06 10:09:22 raspberrypi weewx[5089]: restx: PWSweather: Posting not enabled.

nov 06 10:09:22 raspberrypi weewx[5089]: restx: CWOP: Posting not enabled.

nov 06 10:09:22 raspberrypi weewx[5089]: restx: WOW: Posting not enabled.

nov 06 10:09:22 raspberrypi weewx[5089]: restx: AWEKAS: Posting not enabled.

nov 06 10:09:22 raspberrypi weewx[5089]: engine: Starting up weewx version 3.6.1

nov 06 10:09:22 raspberrypi weewx[5089]: wmr300: reading records since ******* N/A *******     (    N/A   )

nov 06 10:09:22 raspberrypi weewx[5089]: engine: Caught WeeWxIOError: Expiró el tiempo de conexión

nov 06 10:09:22 raspberrypi weewx[5089]: ****  Waiting 60 seconds then retrying...

[Thomas O]

I see the same issue with 0.15rc1 from master and WMR300.

Any data you need to further debug ; I am trying to diff 0.9 and 0.15rc1 but I didn't find anything obvious yet.

Can i provide some more traces ?

[mwall]

thomas,

please post your usb configuration 'dpkg -l | grep usb'

also, please post the exception stack when you run 0.15rc1

this is rather perplexing. i thought the localization that alberto (es) and roland (de) are using might be causing the problem, but i'm not sure.  the driver checks for 'No data available' and 'No error' messages from libusb.  (i have not yet figured out a way to check for an error code that works across different libusb versions)

m

[Alberto Sánchez]

Thank you very much for the work you do with weewx mwall. If you need something else that I could do, please tell me. I am very noob with weewx but I am avaliable to test what you need.

[Thomas O]

On Sunday, November 6, 2016 at 6:41:44 PM UTC+1, mwall wrote:

On Sunday, November 6, 2016 at 8:58:36 AM UTC-5, Thomas O wrote:

I see the same issue with 0.15rc1 from master and WMR300.

Any data you need to further debug ; I am trying to diff 0.9 and 0.15rc1 but I didn't find anything obvious yet.

Can i provide some more traces ?

thomas,

please post your usb configuration 'dpkg -l | grep usb'

I will unfortunately I have access to the hardware only on weekends.

 

also, please post the exception stack when you run 0.15rc1

this is rather perplexing. i thought the localization that alberto (es) and roland (de) are using might be causing the problem, but i'm not sure.  the driver checks for 'No data available' and 'No error' messages from libusb.  (i have not yet figured out a way to check for an error code that works across different libusb versions)

You may be on something as my localization is "fr"

Thomas.

[Cameron D]

Hello,
I have just purchased a wrm300 and have been lead to this thread by similar problems.
I am in Australia, where they supply the European model.
I have connected the station to my windows 7 PC and verified communication seems to work with the supplied software.

My server is CentOS 6.8, and so I used the redhat instructions and installed the weewx-3.6.2-1.rhel.noarch
I configured it to use mysql storage and assigned the station at the same time. The mysql tables are created OK, but nothing is written.

I had the same error messages as Roland reported in the first post, except that I do not see the "station does not report reading the time" message.

Installed packages:
kernel-3.18.41-20.el6.x86_64  (from Xen repo), although I am not currently booting Xen.
libusb1-1.0.9-0.7.rc1.el6.x86_64
libusb-0.1.12-23.el6.x86_64

Pyusb from easy_install, looks like it is v1.0.0

I copied in wrm300.py v0.15rc2, as described above, and, running

PYTHONPATH=. python weewx/drivers/wmr300.py

I now get:

Nov 12 13:55:19 x wmr300[13744]: wmr300: driver version is 0.15rc2
Nov 12 13:55:19 x wmr300[13744]: wmr300: Found station at bus= device=
Nov 12 13:55:19 x wmr300[13744]: wmr300: usb failure: [Errno 110] Operation timed out

The null entries for bus and filename look to be from usb.legacy, where they are simply populated with empty strings.
Note, the timeout (and exit) is almost immediate - always the same second.

[mwall]

On Friday, November 11, 2016 at 11:47:26 PM UTC-5, Cameron D wrote:

I copied in wrm300.py v0.15rc2, as described above, and, running

PYTHONPATH=. python weewx/drivers/wmr300.py

I now get:

Nov 12 13:55:19 x wmr300[13744]: wmr300: driver version is 0.15rc2
Nov 12 13:55:19 x wmr300[13744]: wmr300: Found station at bus= device=
Nov 12 13:55:19 x wmr300[13744]: wmr300: usb failure: [Errno 110] Operation timed out

The null entries for bus and filename look to be from usb.legacy, where they are simply populated with empty strings.
Note, the timeout (and exit) is almost immediate - always the same second.

cameron,

if you try starting a second time, does everything work?

on a test system i sometimes see the timeout when starting weewx for the very first time, i.e., when there has been no communication with the station for some time (an hour? a day? a week?).  but a subsequent start works.  i suspect it is a case of getting the station to start spitting out data on the usb - the driver must not be using the right protocol to get communication started.  but once the station is spitting out data, the driver works fine - there is a heartbeat command that keeps communication going.

could you sniff the usb when running the windows software to communicate with the hardware?  we need a capture that covers this:

1) station is already plugged in to usb
2) start the windows software
3) record one or two intervals of current data

i also suspect that we are dealing with two issues here - one is the driver's check for 'No error' and 'No data available' (that would be affected by localization) and the other is the timeout failures (due to startup/initialization protocol).

of course, this is all reverse engineering a system for which we get zero help from the manufacturer or vendor, so i could be completely wrong.

m

[Cameron D]

On Saturday, 12 November 2016 22:33:12 UTC+10, mwall wrote:

if you try starting a second time, does everything work?

on a test system i sometimes see the timeout when starting weewx for the very first time, i.e., when there has been no communication with the station for some time (an hour? a day? a week?).  but a subsequent start works.  i suspect it is a case of getting the station to start spitting out data on the usb - the driver must not be using the right protocol to get communication started.  but once the station is spitting out data, the driver works fine - there is a heartbeat command that keeps communication going.

could you sniff the usb when running the windows software to communicate with the hardware?  we need a capture that covers this:

1) station is already plugged in to usb
2) start the windows software
3) record one or two intervals of current data

i also suspect that we are dealing with two issues here - one is the driver's check for 'No error' and 'No data available' (that would be affected by localization) and the other is the timeout failures (due to startup/initialization protocol).

of course, this is all reverse engineering a system for which we get zero help from the manufacturer or vendor, so i could be completely wrong.

m

 Hi,
I had initially tried several times, and then started using the debug method of running the driver directly.
I have now got it to work - by adding a test for "timed out" in the error string. This seems to come from libusb1 being mapped from LIBUSB_ERROR_TIMEOUT.

I cannot understand how an error message of "No data available" could be created instead of a timeout message.

I also recoded the driver in the non-legacy pyusb api, but that was a waste of time (except that I could then understand a bit better what was happening).
I will do a bit of packet sniffing of the windows version while I still have the sensors on the ground.  I will even put the hose into it and see what the software does when I "overflow" the raingauge counter.

But first to plug it back into weewx and see if it still works.

[mwall]

On Saturday, November 12, 2016 at 9:33:42 AM UTC-5, Cameron D wrote:

 Hi,

I had initially tried several times, and then started using the debug method of running the driver directly.
I have now got it to work - by adding a test for "timed out" in the error string. This seems to come from libusb1 being mapped from LIBUSB_ERROR_TIMEOUT.

I cannot understand how an error message of "No data available" could be created instead of a timeout message.

i suspect that different versions of libusb assemble the errors differently.  afaict, some of the strerror messages are coming from the operating system, not libusb.  i do not yet know a reliable way to extract the error intent using pyusb.

the timeouts have been particularly difficult for me to test.  i might see a timeout once after not running the driver for some time, but then no subsequent timeouts.  not so good for reproducibility.
 

I also recoded the driver in the non-legacy pyusb api, but that was a waste of time (except that I could then understand a bit better what was happening).
I will do a bit of packet sniffing of the windows version while I still have the sensors on the ground. 

i though about rewriting all the usb weewx drivers to use pyusb 1, but there are too many other windmills to tilt.

i'd like to put all the packet captures into a repo somewhere, but i've have avoided this out of fear of the dmca and that way of thinking.
 

I will even put the hose into it and see what the software does when I "overflow" the raingauge counter.

that would be *very* helpful.  on eric's system the rain counter hits 10160 inches (40000 mm) then stops.  any more rain shows up in hour and day counts, plus rain rate, but not in the total.  only a physical reset using the console will clear the counter.  obviously that is not desirable behavior!

when you test, please set debug in weewx.conf:

debug=1
...

[WMR300]
    ...
    debug_rain = 1
    debug_decode = 1

this will help you understand what is happening with the rain counter.  and it would help me to see any packets of type 57 (i'm trying to figure out if the firmware version is reported there).

m

[Cameron D]

On Sunday, 13 November 2016 00:52:40 UTC+10, mwall wrote:

i suspect that different versions of libusb assemble the errors differently.  afaict, some of the strerror messages are coming from the operating system, not libusb.  i do not yet know a reliable way to extract the error intent using pyusb.

Yes, from what I could understand of the pyusb source, the exceptions are purely those provided by the underlying backend, and, of those, some seem to be mapped to specific English strings and some to system error messages - I guess out of the underlying libc.

 

when you test, please set debug in weewx.conf:

debug=1
...

[WMR300]
    ...
    debug_rain = 1
    debug_decode = 1

Ah, that is useful - I was wondering where those values came from, other than hard-coding them into the driver. 

On that topic, which parameter take priority? the debug flag in the weewx.conf, or DEBUG_RAIN in the driver?

[mwall]

debug_rain and debug_decode are driver-specific.  see the top part of wmr300 for other driver-specific debug flags.

debug is the weewx-global enabler - if debug=0 you will not see anything from debug_rain or debug_decode

the DEBUG_* globals in wmr300 should respect what is specified in weewx.conf

setting debug=2 gives you even more debug, mostly about what will be uploaded by restful services

m

[Cameron D]

Hmm, more debugging needed.

Now, each time I start weewx, it loads the updated saved records, Then gets a bit of data and then the console stops reporting, although it is still responding to request status 6466. 

It also goes through a period where the same rain result is being reported every 2 seconds, but temperature is not.  Maybe it's time for a reset, and switch to windows to capture a few packets.

[Cameron D]

On Monday, 14 November 2016 11:46:25 UTC+10, Cameron D wrote:

Hmm, more debugging needed.

I think I have made a bit of progress - but not on the missing data problem.

I have adjusted the code to be able to choose between libusb0 and libusb1 - and to save what version is being used.

When using libusb0, the reported exceptions are unreliable. I have two cases:

1.USB cable has been removed and replugged - detaching kernel HID is required. USB read timeouts return USBError with 

      strerror set to "Connection timed out"

      errno set to None

      backend_error_code set to -110

2. restarting without replugging cable (HID not attached). USB read timeouts return USBError with:

      strerror set to "could not detach kernel driver from interface 0: No data available"

      errno set to None

      backend_error_code set to -110

when I use libusb1, the following happens, in both cases:

      strerror set to "Connection timed out"

      errno set to 110

      backend_error_code set to -7

However, there are still problems, possibly with my code, so wait for more details.

[Alberto Sánchez]

Hi mwall

You said that our error is related to the location of the operating system. If we change the location (I don`t know how yet), will the new drivers work?

Thank you very much.

[mwall]

On Monday, November 14, 2016 at 2:41:34 PM UTC-5, Alberto Sánchez wrote:

Hi mwall

You said that our error is related to the location of the operating system. If we change the location (I don`t know how yet), will the new drivers work?

hi alberto,

it is the locale, not the location.  you could try the newer driver with the locale set to english to see if that makes any difference.

cameron has identified some issues that i suspected but was never able to isolate.  eventually this will lead us to a solution that will not be affected by the locale.

m

[Cameron D]

 Alberto,

if you want to help you could try my modified version, which might work without needing to change locale.

I have attached a zipped version.

It has a different name, so it should not overwrite the official version.  I put my copy in the user directory.

In weewx.conf  I change to

station_type = WMR300c

and I add a section

[WMR300c]
    # This section is for WMR300 weather stations. modified by cameron

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

    # The driver to use:
    driver = user.wmr300c

    debug_decode=1
    debug_rain=1

I don't have much time to work on this today, but I'd be interested if my changes only work on my system, or are more general.

It uses the more recent API version of  pyusb, so if you only have the original one then it will not work.

There is quite a bit of debugging output, so your log files might grow fairly quickly.

In my case I am getting numerous timeouts on the write calls, and data collection rapidly stalls - that might be a fault in my driver modifications, or it might be the console is in an odd state.

[Alberto Sánchez]

Hi Cameron,

I have tried your solution and report me this error:

sudo /etc/init.d/weewx status -l

● weewx.service - LSB: weewx weather system

   Loaded: loaded (/etc/init.d/weewx)

   Active: active (exited) since mar 2016-11-15 19:47:20 CET; 2s ago

  Process: 19541 ExecStop=/etc/init.d/weewx stop (code=exited, status=0/SUCCESS)

  Process: 19588 ExecStart=/etc/init.d/weewx start (code=exited, status=0/SUCCESS)

nov 15 19:47:20 raspberrypi weewx[19603]: ****    File "/usr/share/weewx/weewx/engine.py", line 70, in __init__

nov 15 19:47:20 raspberrypi weewx[19603]: ****      self.setupStation(config_dict)

nov 15 19:47:20 raspberrypi weewx[19603]: ****    File "/usr/share/weewx/weewx/engine.py", line 88, in setupStation

nov 15 19:47:20 raspberrypi weewx[19603]: ****      driver = config_dict[stationType]['driver']

nov 15 19:47:20 raspberrypi weewx[19603]: ****    File "/usr/lib/python2.7/dist-packages/configobj.py", line 554, in __getitem__

nov 15 19:47:20 raspberrypi weewx[19603]: ****      val = dict.__getitem__(self, key)

nov 15 19:47:20 raspberrypi weewx[19603]: ****  KeyError: 'WMR300c'

nov 15 19:47:20 raspberrypi weewx[19603]: ****  Exiting.

Thank you

[Alberto Sánchez]

Sorry, I had a error in my code, now I have this:

Introducir código aquí...sudo /etc/init.d/weewx status

● weewx.service - LSB: weewx weather system

   Loaded: loaded (/etc/init.d/weewx)

   Active: active (exited) since mar 2016-11-15 19:51:25 CET; 6min ago

  Process: 19794 ExecStop=/etc/init.d/weewx stop (code=exited, status=0/SUCCESS)

  Process: 20014 ExecReload=/etc/init.d/weewx reload (code=exited, status=0/SUCCESS)

  Process: 19841 ExecStart=/etc/init.d/weewx start (code=exited, status=0/SUCCESS)

nov 15 19:51:25 raspberrypi systemd[1]: Started LSB: weewx weather system.

nov 15 19:51:41 raspberrypi systemd[1]: Reloading LSB: weewx weather system.

nov 15 19:51:41 raspberrypi weewx[19906]: Reloading weewx weather system: weewxstart-stop-daemon: warning: failed to kill 19856: No such process

nov 15 19:51:41 raspberrypi weewx[19906]: .

nov 15 19:51:41 raspberrypi systemd[1]: Reloaded LSB: weewx weather system.

nov 15 19:55:23 raspberrypi systemd[1]: Reloading LSB: weewx weather system.

nov 15 19:55:23 raspberrypi weewx[20014]: Reloading weewx weather system: weewxstart-stop-daemon: warning: failed to kill 19856: No such process

nov 15 19:55:23 raspberrypi weewx[20014]: .

nov 15 19:55:23 raspberrypi systemd[1]: Reloaded LSB: weewx weather system.

nov 15 19:55:28 raspberrypi systemd[1]: Started LSB: weewx weather system.

[Alberto Sánchez]

 

sudo /etc/init.d/weewx status -l

● weewx.service - LSB: weewx weather system

  Loaded: loaded (/etc/init.d/weewx)

  Active: active (exited) since mar 2016-11-15 20:11:54 CET; 8min ago

 Process: 1752 ExecReload=/etc/init.d/weewx reload (code=exited, status=0/SUCCESS)

 Process: 424 ExecStart=/etc/init.d/weewx start (code=exited, status=0/SUCCESS)

nov 15 20:11:54 raspberrypi weewx[1007]: ****    File "/usr/share/weewx/weewx/engine.py", line 88, in setupStation

nov 15 20:11:54 raspberrypi weewx[1007]: ****      driver = config_dict[stationType]['driver']

nov 15 20:11:54 raspberrypi weewx[1007]: ****    File "/usr/lib/python2.7/dist-packages/configobj.py", line 554, in __getitem__

nov 15 20:11:54 raspberrypi weewx[1007]: ****      val = dict.__getitem__(self, key)

nov 15 20:11:54 raspberrypi weewx[1007]: ****  KeyError: 'wmr300'

nov 15 20:11:54 raspberrypi weewx[1007]: ****  Exiting.

nov 15 20:19:16 raspberrypi systemd[1]: Reloading LSB: weewx weather system.

nov 15 20:19:16 raspberrypi weewx[1752]: Reloading weewx weather system: weewxstart-stop-daemon: warning: failed to kill 1007: No such process

nov 15 20:19:16 raspberrypi weewx[1752]: .

nov 15 20:19:16 raspberrypi systemd[1]: Reloaded LSB: weewx weather system.

pi@raspberrypi:~ $ ^C

After reversing the changes I have this error. 

[Cameron D]

Hi Alberto,

I'm not sure, but it looks like your weewx.conf is slightly wrong - Or I have forgotten to tell you something.

Would you like to email me your conf file and I will check.

[Cameron D]

This is sending me crazy.

I have narrowed down the behaviour on the windows system (will post that to the dev forum later) but no matter what I try to do, every write after the first 2 or 3 causes a timeout. Or nearly every one - occasionally one is accepted.

This happens whether they are commands or ACK packets.

I have Linux packet dumps which make no sense in relation to the timeouts.

These seem to show the interrupt-mode transfer handshake, which the windows packet captures do not.

Initially I see frames like:

1. write a data packet

2. see a success status packet return

3. send a request for a packet

4. see the read data packet arrive.

6. write a packet

7. after precisely the timeout period, see a failure packet come in, with a URB status: -2  (ENOENT)

But what is generating this packet? 

The wmr300 does not know the timeout period

If it was an ENOENT error then why does it not get created immediately?  Why is this code not returned as the error code? or why is the error code not the timeout error?  Does wireshark have the error codes wrong?

The code is set to ignore lots of timeout exceptions on write, but eventually the console gets sick of not seeing any ACK packets and gives up. So even ignoring the timeouts does not work.

The pyusb debug settings do not help much. They do not log any errors at all.

[Dafydd P]

Hi Guys

Have been following this thread with interest as I am having the same issues. Current setup is a WMR300 connected to a RPi 3 running Rasbian Jessie. Installed 3.6.2 and had the same usb issue. Tried installing the 0.15RC2 driver but had a different error. As it was a new setup I downgraded to 3.5.0 to ensure that all was working ok. This was successful so I'm happy the hardware is ok.

I will try and put 3.6.2 back on and retry the updated driver. If anybody has any further info about this it would be much appreciated,

Cheers

Daff

Perth, Western Australia

[Cameron D]

Hi Daff,

I would suggest don't bother with new drivers yet.- the changes in the driver I posted are only to avoid the language issue. I have tried to address a few other issues but I am just making it worse.

I think I should go back to look at the driver in 3.5.0

Cameron.

[mwall]

On Tuesday, November 22, 2016 at 7:33:31 AM UTC-5, Dafydd P wrote:

Have been following this thread with interest as I am having the same issues. Current setup is a WMR300 connected to a RPi 3 running Rasbian Jessie. Installed 3.6.2 and had the same usb issue. Tried installing the 0.15RC2 driver but had a different error. As it was a new setup I downgraded to 3.5.0 to ensure that all was working ok. This was successful so I'm happy the hardware is ok.

I will try and put 3.6.2 back on and retry the updated driver. If anybody has any further info about this it would be much appreciated,

daff,

could you post both of the errors you saw (weewx 3.6.2 and weewx 3.6.2 with 0.15rc2 driver)

then try weewx 3.6.2, but with the attached 0.15rc3.  i would like to be sure that the problem is just in the driver, not in the weewx version.

if that fails, post the exception stack then try weewx 3.6.2 with the 0.9 driver from weewx 3.5.0

there are bugs in rain calculation and barometer in 0.9, these are fixed by 0.15

whereas 0.15rc2 used the 'repr' approach, 0.15rc3 reverts to the 'args' approach for inspecting a USBError type.  the args approach is known to fail on some versions of libusb/pyusb.

cameron, i know your pain...

m 

[Cameron D]

More pain...

When I start usb capture and directly run either v0.9 or the v0.15rc3 I get the same immediate crash 

The last lines of the stack trace are 

 File "weewx/drivers/wmr300-v09.py", line 1045, in read

    if not e.args[0].find('No data available'):

AttributeError: 'int' object has no attribute 'find'

This happens on the very first read.

Running weewx itself produces basically the same error, within station.read from genStartupRecords.

If I precede that line by "print e" I get: "[Errno 110] Operation timed out"

The only other thing I noticed in the capture was a control packet :

     USBHID SET_IDLE request

and an acknowledgement that it was successful.

This only happens the first time - when the kernel detach succeeds.  However, I have sometimes seen it on a windows capture as well, so I don't think it is significant.

[mwall]

On Wednesday, November 23, 2016 at 8:58:03 AM UTC-5, Cameron D wrote:

More pain...

When I start usb capture and directly run either v0.9 or the v0.15rc3 I get the same immediate crash 

The last lines of the stack trace are 

 File "weewx/drivers/wmr300-v09.py", line 1045, in read

    if not e.args[0].find('No data available'):

AttributeError: 'int' object has no attribute 'find'

This happens on the very first read.

when pyusb creates a USBError, it puts the libusb errno and strerror into an args member of the USBError exception.  so our initial implementations used the args member to figure out what kind of USBError was being raised.

apparently the use of args changed at some point - i'm not sure whether the change was due to pyusb or libusb.

so i modified the weewx usb drivers to use repr instead - that stringifies the USBError in a way that seems to have worked across pyusb and libusb versions.

you can see the difference in 3 places in 0.15rc3 where the USBError is handled.

i am confused by the reports that say "weewx 3.6.2 with driver 0.9 works, but weewx 3.6.2 with driver 0.15rc2 does not work".  afaict, that should not be possible.

 

If I precede that line by "print e" I get: "[Errno 110] Operation timed out"

The only other thing I noticed in the capture was a control packet :

     USBHID SET_IDLE request

and an acknowledgement that it was successful.

This only happens the first time - when the kernel detach succeeds.  However, I have sometimes seen it on a windows capture as well, so I don't think it is significant.

the timeouts seem to happen when the station has stopped spewing on the usb.  if that is the root cause of timeouts, then the question is "how do we get it to start spewing again?"  i have only seen the timeout when starting weewx.  starting weewx a second time resulted in normal behavior.  so using loop_on_init is a workaround for that, but it does not tell us what part of the driver initialization causes the station to start usb spewage.  more significantly, there might be cases where someone is getting timeouts, and multiple attempts at starting weewx does not make the timeouts go away.

localization comes into play in the detection of the USBError type.  when we get a 'no data available' or 'no error' USBError, we ignore them.  these are not really errors (especially not the 'no error' "error"), so we do not want to raise exceptions.  when localization changes the string from 'No data available' to the equivalent in de, es, or fr, an exception is raised instead of being ignored.

so there are two things to sort out:

1) how to determine the USBError type without:
a) using the member args, which is dependent on libusb/pyusb version
b) parsing for a 'no data available' string that depends on locale

2) how to get the station to start jabbering (assuming that the timeouts are because the station is not jabbering).  of course, this might be more complicated if the root cause is a more subtle usb comm issue rather than just getting the station to start talking.

so what do we do?

- for each test, we need to know:
  - what version of libusb
  - what version of pyusb
  - what version of weewx
  - what version of wmr300

- test the following:
  - start up weewx

- test permutations
  - weewx versions: 3.5.0, 3.6.2
  - wmr300 versions: 0.9, 0.15rc2, 0.15rc3
  - libusb versions: 1.0.x, 0.1.x
  - pyusb versions: 0.4, 1.0

the number of different libusb and pyusb versions is bigger.  for example, i have seen a significant differences between libusb 1.0.11, libusb 1.0.19, and libusb 1.0.20.

we should be able to prune the number of permutations if we could get a report of exactly what is working and what is not working to this point.

m

[Cameron D]

the timeouts seem to happen when the station has stopped spewing on the usb.  if that is the root cause of timeouts, then the question is "how do we get it to start spewing again?"  i have only seen the timeout when starting weewx.  starting weewx a second time resulted in normal behavior.  so using loop_on_init is a workaround for that, but it does not tell us what part of the driver initialization causes the station to start usb spewage.  more significantly, there might be cases where someone is getting timeouts, and multiple attempts at starting weewx does not make the timeouts go away.

I have posted in the other thread in the weewx-development area what triggers the wmr300 to start spitting out data.

But when I put in the code to do this, it then starts timing out when I try to write the ACKs

So as soon as I make it talk, it stops listening!

 

localization comes into play in the detection of the USBError type.  when we get a 'no data available' or 'no error' USBError, we ignore them.  these are not really errors (especially not the 'no error' "error"), so we do not want to raise exceptions.  when localization changes the string from 'No data available' to the equivalent in de, es, or fr, an exception is raised instead of being ignored.

so there are two things to sort out:

1) how to determine the USBError type without:
a) using the member args, which is dependent on libusb/pyusb version
b) parsing for a 'no data available' string that depends on locale

My modified code traps all the possible timeouts, however, from how you describe what used to work in v0.9 I think my changes are probably not backward compatible with those older versions of pyusb.

However, chasing the error number seems to me a better option.

 

2) how to get the station to start jabbering (assuming that the timeouts are because the station is not jabbering).  of course, this might be more complicated if the root cause is a more subtle usb comm issue rather than just getting the station to start talking.

so what do we do?

- for each test, we need to know:
  - what version of libusb
  - what version of pyusb
  - what version of weewx
  - what version of wmr300

- test the following:
  - start up weewx

- test permutations
  - weewx versions: 3.5.0, 3.6.2
  - wmr300 versions: 0.9, 0.15rc2, 0.15rc3
  - libusb versions: 1.0.x, 0.1.x
  - pyusb versions: 0.4, 1.0

As well as all that, there is the issue of error state being different whether or not the kernel release fails.

It would be simple enough to write a bit of code that starts the spewing and run it directly before starting weewx. That would at least standardise the starting point.

It is also worthwhile finding out what versions people are using from teh point of view that if there are old versions nobody is using any more then we can ignore those for the wmr300.

Cameron.

[Cameron D]

I now have a version that is working reliably across a few restarts.

I need to do a lot of tidying up of debug code, test it using usblib0 and clean up a few mysteries such as why it is suddenly in US units.

This will not happen for a few days due to other commitments.  If anybody wants to try this interim code they are welcome to try the attached...

Essentially I think the problem, as I guessed in the devel list posting, is that the console is non-deterministic in its i/o stream and eventually gets tied up if single-thread blocking i/o calls are used.

The solution mainly involved looking again at Zahlii's code and, because the wmr300 would not listed to me, I would not talk to it.

It is quite happy to send data without a single ACK response, so long as the heartbeat occurs every so often.

The history reread might still have some gaps in it.

[Cameron D]

On Saturday, 26 November 2016 00:37:37 UTC+10, Cameron D wrote:

The solution mainly involved looking again at Zahlii's code and, because the wmr300 would not listed to me, I would not talk to it.

It is quite happy to send data without a single ACK response, so long as the heartbeat occurs every so often.

I must have been a bit tired when I wrote that. - I meant to say that I was mainly following the techniques in Zahlii's code, although it had to be modified to accommodate things like history logging.  So: Because the WMR300 would not listen to my ACKs I decided it wasn't going to get any.

 

The history reread might still have some gaps in it.

That was some invalid interpretation on my part - maybe looking at old or cached charts. 

code (attached) is still a bit messy, but it works (for me) with pyusb backends of libusb0 and libusb1. Which means it requires pyusb version 1.something.

It has survived various combinations of starting and restarting, even unplugging and reinserting the USB while weewx is running.

[Alberto Sánchez]

Hi mwall,

I have tested RC2 driver and it starts correctly, thamk you very much for your job. But I have other problem now, I lose a lot of pressure data, temperature ... (example https://www.wunderground.com/personal-weather-station/dashboard?ID=IULTZAMA2#history/tdata/s20161211/e20161211/mdaily)

Weewx 3.6.1
Driver 0.15RC3
Locale English

[mwall]

 
alberto,

the wmr300 emits pressure data once every 15 minutes.  since your archive interval is 5 minutes, it is expected to see some archive records with no pressure data.

weewx does not cache.  this is by design.  if weewx uploaded a pressure value in an archive interval where no pressure was received, it would be lying to you.  there is a lengthy discussion about caching here:

https://github.com/weewx/weewx/issues/31

https://github.com/weewx/weewx/issues/131

there are two other types of records in your wu data that are suspicious.  there is at least one record that contains only pressure, and a couple of records that contain only rain=0 and rainRate=0.  since the other sensors on a wmr300 report much more frequently than once every 5 minutes, these records probably indicate loss of comms between the console and the sensors.  (there might be a loss-of-contact indicator in the raw data, but we have not yet figured out where it is or how to decode it)

m

[Alberto Sánchez]

Hi mwall,

Thanks for the information, I've changed the location of my console and I no longer date. I agree with you on reading barometer data.

I only have to wait until it rains, to see that the readings are correct as well.

Thank you very much

[Alberto Sánchez]

I wanted to say that "I no longer lose data" with the new location of the console.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/YSz_IWnzOjE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alberto Sánchez]

Hi mwall,

It has rained tonight. The console has registered the rain and weewx has recorded the rain rate well but has not calculated the total rain. Example: Today's Rain 0.0 mm
High Rain Rate 1.3 mm / hr at 05:19:22 AM

Weewx 3.6.1
Driver 0,15RC3

[Andrew Milner]

Alberto - I do not fully understand your weather underground station.  If I watch your station for a while it looks as though there are two stations reporting - the last reported time keeps jumping between two sequences eg it can report last reported 10 secs ago, 15 secs ago, 8 minutes ago, 20 secs ago, 8 minutes ago, 25 secs ago, 8 minutes ago, 30 secs ago, 9 minutes ago, 35 secs ago ....... etc etc etc.

Is there anything in the log at/around the time of the rain?

What data is stored in the database between say 04:30:00 and 06:30:00 ??  You can find this by

SELECT dateTime, rain, rainRate from archive where dateTime > 1482204600 and dateTime < 1482211800;

[mwall]

alberto,

when was the last time you reset the rain counter? you can get this information from the wmr300 console.

m

[Alberto Sánchez]

Thanks you very much both,

Andrew,

This is the data in the database

	RainRate	Rain
1482207600	0.0048387097	0
1482207900	0.0499999999	0
1482208200	0.0499999999	0
1482208500	0.0478787878	0
1482208800	0.0091428571	0

I have also seen what you comment on wunderground. I do not know what may be due, I'll check weewx.conf

mwall,

In the rain counter of the console appeared "HHH mm". I just reset and has been zeroed.

[Andrew Milner]

|Alberto

It is POSSIBLE that WU reports the time since the last reading change - but I still do not see what is happening because you do NOT have rapid fire enabled in the weewx.conf you posted.

Do you have multiple instances of weewx running by any chance - can you do ps -A and check that weewxd appears only ONCE in the list of processes

double check

Matthew needs to comment on how we have rainrate but not rain!!

[mwall]

On Tuesday, December 20, 2016 at 1:31:30 PM UTC-5, Alberto Sánchez wrote:

In the rain counter of the console appeared "HHH mm". I just reset and has been zeroed.

this is typical behavior when the rain counter of the wmr300 has reached its maximum value.

once it reaches maximum value, it will no longer record any rain.

it will continue to record rain rate. (since the hardware emits rainRate, weewx does not calculate rainRate)

afaik, the only way to reset the rain counter is to punch the buttons on the console.

if you can find somewhere in the oregon scientific software that will reset the rain counter, please let us know!  even better, do a usb capture of the reset-from-software so we can do it in the wmr300 driver.

m

[Cameron D]

Hi Alberto,
I have just checked my system after some rain and the database contents
look sensible. I can see rain increments of 0.01 and 0.02 (inches) in
my 1-minute sample interval.

The web page shows total rain as 6.6mm since midnight, which agrees with
the console.

I am using Weewx 3.6.2, but with my test drivers. However I do not think
I changed anything in the drivers related to interpreting the data.

I noticed also on your weather underground page that you recorded 191mm
in 5 minutes on 12-Dec. That does not look right - you should see if the
weewx database shows the same set of values.

I thought the rain accumulator capacity was 40 metres of rain - that
should last 4 years even for the wettest place on earth. Unless you have
been supplying an extra source of water it should not need clearing just
yet. It will be interesting if that does fix it.

Cameron.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/YSz_IWnzOjE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> weewx-user+...@googlegroups.com
> <mailto:weewx-user+...@googlegroups.com>.

[Alberto Sánchez]

Hi Cameron,

 

I have had erroneous rain readings (9000mm or even more), I think due to communication failures and in some cases I found cobwebs in the rain gauge. Because of this I think I have reached the limit. At the moment I am in tests, as soon as the weather station works correctly I will erase all the data of wunderground and I will start again. The anticyclone we have in Europe does not help me to speed up the tests xD

 

Many thanks to all for the help.

 

Mwall,

 

At the moment I do not have enough knowledge to help you capture packages for the driver, but if you need me to do some test you can ask me.

> weewx-user+unsubscribe@googlegroups.com
> <mailto:weewx-user+unsub...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/YSz_IWnzOjE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

[Cameron D]

Hi Alberto,

OK - the comms errors would make sense to explain that.

If you are planning to erase and start again then a bottle of water
helps speed up the rainfall.
Or lift the raingauge top off and tip the rain buckets to and fro. That
way you can even count how much "rain" you have had.

Don't worry about packet capture - I intend to do that myself when I
have a bit of spare time.

Given Oregon's approach to control of the setup via PC (i.e. there is
none), I doubt there will be any software reset. They do not even
correct the clock.

Cameron

On 21-Dec-2016 18:59, Alberto Sánchez wrote:
> Hi Cameron,____
>
> __ __

>
> I have had erroneous rain readings (9000mm or even more), I think due to
> communication failures and in some cases I found cobwebs in the rain
> gauge. Because of this I think I have reached the limit. At the moment I
> am in tests, as soon as the weather station works correctly I will erase
> all the data of wunderground and I will start again. The anticyclone we

> have in Europe does not help me to speed up the tests xD____
>
> __ __
>
> Many thanks to all for the help.____
>
> __ __
>
> Mwall,____
>
> __ __

>
> At the moment I do not have enough knowledge to help you capture
> packages for the driver, but if you need me to do some test you can ask me.
>
>
> El 21 dic. 2016 9:19, "Cameron D" <CGo...@davidsoncj.id.au

> <mailto:CGo...@davidsoncj.id.au>> escribió:

> <https://groups.google.com/d/topic/weewx-user/YSz_IWnzOjE/unsubscribe>.

> > To unsubscribe from this group and all its topics, send an email to

> > weewx-user+...@googlegroups.com
> <mailto:weewx-user%2Bunsu...@googlegroups.com>
> > <mailto:weewx-user+...@googlegroups.com
> <mailto:weewx-user%2Bunsu...@googlegroups.com>>.

> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/YSz_IWnzOjE/unsubscribe

> <https://groups.google.com/d/topic/weewx-user/YSz_IWnzOjE/unsubscribe>.

> To unsubscribe from this group and all its topics, send an email to

> weewx-user+...@googlegroups.com
> <mailto:weewx-user%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/YSz_IWnzOjE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> weewx-user+...@googlegroups.com
> <mailto:weewx-user+...@googlegroups.com>.

[Michael Nigbor]

Cameron,

I installed 3.6.2 today on Ubuntu (old HP laptop) attached to a WMR300a. I am having the same problem described in this thread: no data from the console. I installed using apt-get which gave me version 0.13 of the driver.  After reading this thread, I went to github and got 0.16rc2.  Should I use version in this zip file?  It says something about WMR300C. Does that matter? 

[mwall]

On Monday, December 26, 2016 at 3:08:20 PM UTC-5, Michael Nigbor wrote:

I installed 3.6.2 today on Ubuntu (old HP laptop) attached to a WMR300a. I am having the same problem described in this thread: no data from the console. I installed using apt-get which gave me version 0.13 of the driver.  After reading this thread, I went to github and got 0.16rc2.  Should I use version in this zip file?  It says something about WMR300C. Does that matter? 

michael,

what happens when you run weewx 3.6.2 with the version 0.16rc2 driver from the repository?

m

[Michael Nigbor]

I get a timeout error. 

--

You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/YSz_IWnzOjE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

[Cameron D]

Michael,
The code labelled wmr300c is my test driver to try to understand the
timeout issues. It should work with the "A" model as well as the euro
model hardware wmr300.

You can copy it in alongside the normal wmr300 driver and switch between
them by manually editing the config file. I have not given any thought
to whether the reconfigure program would work.

Cameron.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/YSz_IWnzOjE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> weewx-user+...@googlegroups.com
> <mailto:weewx-user+...@googlegroups.com>.

[Alberto Sánchez]

Hi mwall,

I am testing your new WMR300 drivers. 0,18rc2. It collects me data correctly but reports me this error:

Feb 05 13:29:16 raspberrypi weewx[1369]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from...ata available',)

Feb 05 13:29:17 raspberrypi weewx[1369]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from...ata available',)

Feb 05 13:29:17 raspberrypi weewx[1369]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from...ata available',)

Feb 05 13:29:17 raspberrypi weewx[1369]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from...ata available',)

Feb 05 13:29:17 raspberrypi weewx[1369]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from...ata available',)

Thank you very  much.

[mwall]

hi alberto!

does weewx restart itself after any of these messages?

do these messages happen all the time, or just for short periods?

what is your hardware, operating system, libusb, and pyusb versions?

those are debug messages and in this case, they are not failures.  for some reason, some versions of libusb/pyusb report 'could not detach kernel driver' when there is simply no data on the usb.

to eliminate the messages, you could just set debug=0 in weewx conf then restart weewx.

or try wmr300 version 0.18rc3 - i made the driver less chatty:

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

m

[mwall]

the 0.18rc3 driver *should* handle the 'no data available' and 'no error' conditions properly for english, italian, german, french, and spanish locales.

it does not yet handle timeouts properly.  ideally it would recognize and ignore timeouts on the initial communication, then recognize and fail on timeouts after communication has been established.

so if you experience timeout failures using the 0.18 driver, please post the exceptions!

m

[Alberto Sánchez]

ii  libusb-0.1-4:armhf                      2:0.1.12-25                               armhf        userspace USB programming library

ii  libusb-1.0-0:armhf                      2:1.0.19-1                                armhf        userspace USB programming library

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

ii  python-usb                              0.4.3-1                                   armhf        USB interface for Python

ii  usb-modeswitch                          2.2.0+repack0-2                           armhf        mode 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                                   armhf        Linux USB utilities

RPi3B

Raspbian jessie with Pixel 

Weewx doesn't restart after these messages and these messages happen all the time. I am going to test rc3 driver and I will set debug to 0.

thank you.

[Alberto Sánchez]

0.18rc3 seems to work correctly.

Thank you very much mwall!! 

[Miguel Iniesta]

Hello,

I am testing the new versions and unfortunately they do not work for me.
No data from the station but also no error message it seems.

Any help please?
Thanks


Linux raspberrypi 4.4.38-v7+ #938

libusb-0.1-4:armhf             2:0.1.12-25
libusb-1.0-0:armhf             2:1.0.19-1
python-usb                     0.4.3-1

weewx version 3.6.2
DRIVER_NAME = 'WMR300'
DRIVER_VERSION = '0.18rc3'

weewx.service - LSB: weewx weather system
   Loaded: loaded (/etc/init.d/weewx)
   Active: active (running) since sáb 2017-02-11 19:12:08 CET; 17min ago
  Process: 12145 ExecStart=/etc/init.d/weewx start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/weewx.service
           └─12160 /usr/bin/python /home/weewx/bin/weewxd --daemon --pidfile=/var/run/weewx.pid /home/weewx/weewx....

feb 11 19:12:09 raspberrypi weewx[12160]: engine: Loading service weewx.restx.StdAWEKAS
feb 11 19:12:09 raspberrypi weewx[12160]: restx: AWEKAS: Posting not enabled.
feb 11 19:12:09 raspberrypi weewx[12160]: engine: Finished loading service weewx.restx.StdAWEKAS
feb 11 19:12:09 raspberrypi weewx[12160]: engine: Loading service weewx.engine.StdPrint
feb 11 19:12:09 raspberrypi weewx[12160]: engine: Finished loading service weewx.engine.StdPrint
feb 11 19:12:09 raspberrypi weewx[12160]: engine: Loading service weewx.engine.StdReport
feb 11 19:12:09 raspberrypi weewx[12160]: engine: Finished loading service weewx.engine.StdReport
feb 11 19:12:09 raspberrypi weewx[12160]: engine: Starting up weewx version 3.6.2
feb 11 19:12:09 raspberrypi weewx[12160]: engine: Station does not support reading the time
feb 11 19:12:09 raspberrypi weewx[12160]: wmr300: reading records since 2017-02-11 14:20:00 CET (1486819200)

[Alberto Sánchez]

I believe that I had the same problem the first time I tested that driver. I solved it simply restarting raspbian.

--

You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/YSz_IWnzOjE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

[mwall]

On Saturday, February 11, 2017 at 1:46:27 PM UTC-5, Miguel Iniesta wrote:

Hello,

I am testing the new versions and unfortunately they do not work for me.
No data from the station but also no error message it seems.

Any help please?

miguel,

the portion of the log that you posted looks fine - the last line shows that weewx is reading records from the logger.

if the 'running since' time can be trusted, then the driver only has to read about 5 hours of data.  even if the archive interval is 1 minute, that should not take too long, even on an old rpi.

what happens when you wait?

m

[Miguel Iniesta]

Hi m,

After that line, there is nothing else in the log related to weewx: No errors or any activity recorded.
At that moment, there was just 5 hours of data to read because, as I could not find any error message, I thought it was a station problem so I deleted the station's data log records.
A restart has not solved the problem.
Please, find attached full log since restart. It may help.

Thanks.

[mwall]

On Sunday, February 12, 2017 at 5:23:54 AM UTC-5, Miguel Iniesta wrote:

Hi m,

After that line, there is nothing else in the log related to weewx: No errors or any activity recorded.
At that moment, there was just 5 hours of data to read because, as I could not find any error message, I thought it was a station problem so I deleted the station's data log records.
A restart has not solved the problem.

miguel,

please turn on debug.  in weewx.conf:

debug=1
...
[WMR300]
    debug_comm = 1
    debug_history = 1
    ...

then start weewx

m

[Miguel Iniesta]

Hi m,

This is the new error message (twice per second):

weewx.service - LSB: weewx weather system
   Loaded: loaded (/etc/init.d/weewx)

   Active: active (running) since dom 2017-02-12 18:17:30 CET; 3min 10s ago
  Process: 4043 ExecStart=/etc/init.d/weewx start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/weewx.service
           └─4058 /usr/bin/python /home/weewx/bin/weewxd --daemon --pidfile=/var/run/weewx.pid /home/weewx/weewx.conf

feb 12 18:20:39 raspberrypi weewx[4058]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from interface 0: No data available',)
feb 12 18:20:39 raspberrypi weewx[4058]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from interface 0: No data available',)
...

Thanks

[mwall]

On Sunday, February 12, 2017 at 12:26:27 PM UTC-5, Miguel Iniesta wrote:

This is the new error message (twice per second):

weewx.service - LSB: weewx weather system
   Loaded: loaded (/etc/init.d/weewx)
   Active: active (running) since dom 2017-02-12 18:17:30 CET; 3min 10s ago
  Process: 4043 ExecStart=/etc/init.d/weewx start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/weewx.service
           └─4058 /usr/bin/python /home/weewx/bin/weewxd --daemon --pidfile=/var/run/weewx.pid /home/weewx/weewx.conf

feb 12 18:20:39 raspberrypi weewx[4058]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from interface 0: No data available',)
feb 12 18:20:39 raspberrypi weewx[4058]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from interface 0: No data available',)

miguel,

please try the attached wmr300-0.18rc4.py

m
 

[Miguel Iniesta]

Hi m,

Don't have access to the station at weekdays. Hope I can do it next weekend.
Also on another computer to discard a raspi problem.

Thanks.

[Cameron D]

On Monday, 13 February 2017 03:26:27 UTC+10, Miguel Iniesta wrote:

Hi m,

This is the new error message (twice per second):

weewx.service - LSB: weewx weather system
   Loaded: loaded (/etc/init.d/weewx)
   Active: active (running) since dom 2017-02-12 18:17:30 CET; 3min 10s ago
  Process: 4043 ExecStart=/etc/init.d/weewx start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/weewx.service
           └─4058 /usr/bin/python /home/weewx/bin/weewxd --daemon --pidfile=/var/run/weewx.pid /home/weewx/weewx.conf

feb 12 18:20:39 raspberrypi weewx[4058]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from interface 0: No data available',)
feb 12 18:20:39 raspberrypi weewx[4058]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from interface 0: No data available',)
...

This is  actually an error in libusb0.  From my testing, the error message  about "could not detach..." is never cleared from the error  string buffer because the condition "no data available" is not regarded as an error condition at some level.

The first time you run weewx after plugging the USB device in, the kernel automatically attaches it (at least it does on my system) and the weewx driver has to detach it to access it in a different mode.

The next time (and subsequent times) weewx is run, the detach operation fails because it is no longer attached. This is OK, except for the spurious error message. 

You should still be getting data occasionally - if not then the wmr300 console has gotten itself tied up in knots and you need to disconnect the USB and start again.

Try: 

1. stop weewx
   
2. unplug USB, wait 5 sec, reconnect USB.
   
3. restart weewx.
   

this should fix both the error message and the no data condition.

[mwall]

On Tuesday, February 14, 2017 at 8:08:15 PM UTC-5, Cameron D wrote:

On Monday, 13 February 2017 03:26:27 UTC+10, Miguel Iniesta wrote:

feb 12 18:20:39 raspberrypi weewx[4058]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from interface 0: No data available',)
feb 12 18:20:39 raspberrypi weewx[4058]: wmr300: e.errno=None e.strerror=None e.message=could not detach kernel driver from interface 0: No data available repr=USBError('could not detach kernel driver from interface 0: No data available',)
...

This is  actually an error in libusb0.  From my testing, the error message  about "could not detach..." is never cleared from the error  string buffer because the condition "no data available" is not regarded as an error condition at some level.

agreed - i have seen this behavior with many different usb devices, not just the wmr300.  instead of returning an empty buffer, libusb0 raises an 'error' that simply says 'no data available'.  btw, 'no data available' is a localized string in libusb, and the pyusb bindings do not provide a code to distinguish the type.

i am pretty sure that not every version of libusb behaves this way.  even more problematic is that there is no way to know the libusb version from python (at least for older versions of pyusb), even if someone figured out exactly which versions of libusb have this behavior and which do not.

as i understand it, the algorithm for wmr300:

- must not fail on 'no data available' "errors",
- must not fail on the first usb timeout,
- must fail on any usb timeouts after communication has been established,
- must fail on other usb errors

it must do this with every libusb version, or we need to figure out which libusb version(s) are immune to this and only support those.

 

The first time you run weewx after plugging the USB device in, the kernel automatically attaches it (at least it does on my system) and the weewx driver has to detach it to access it in a different mode.

The next time (and subsequent times) weewx is run, the detach operation fails because it is no longer attached. This is OK, except for the spurious error message. 

You should still be getting data occasionally - if not then the wmr300 console has gotten itself tied up in knots and you need to disconnect the USB and start again.

when the firmware is wedged, there is not much we can do.

it would be nice if there were a way to re-establish the communication with the wmr300 *without* having to unplug/replug the usb.  usb reset does not do it.  hubs with power control could be an option, but then the weather station must have no batteries, must be bus-powered, and must retain logger data through a power cycle.

m

[Cameron D]

Hi MWall,

The legacy pyusb interface used in the current wmr300 driver only talks to libusb0, as far as I can tell.

Using the pyusb 1.0 interface I can specify which version of libusb to use or tell which one is called by default.  I have put that code in my "wmr300c" driver. I mainly use libusb1 and it seems reasonably robust.

The only problem I have found since November was when I used the windows software to clear the history and restarted weewx with very few, if any, records in the history. I seem to have an off-by-one or two issue.

The firmware of the wmr300 leaves a lot to be desired. There seems to be only one way to do anything and if you deviate from the path you are in trouble.

I previously promised to check the rain counter filling, but, having seen how little control is available from the PC in other aspects, I an sure there will be no way to remotely clear it.

The fact that I broke my wind vane shaft while having the system temporarily mounted on the ground encouraged me to get it out of my reach and fixed up on the roof.

[Alberto Sánchez]

Hi mwall,

I have tested your last driver and It seems to work well.

Thanks.

--

You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/YSz_IWnzOjE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

[Ruben Navarro Huedo]

Hello friends.

This week i will install a new WMR-300.
I will use a raspberry pi 3 with last raspbian.

What is last wmr300 driver?

Which one must i use?

A lot of thank's

[mwall]

ruben,

as of 18feb2017, the latest wmr300 driver is 0.18rc4.  you can get it here:

https://github.com/weewx/weewx/blob/development/bin/weewx/drivers/wmr300.py

m

[Miguel Iniesta]

Hi m,

This last version works fine. Previous version as well.
I've found out the error is caused by a usb cable.
It is a usb 2.0 cable which works fine with other devices.
Quite strange.

Thank you for your support.

[Ruben Navarro Huedo]

A lot of thank's

My stations has been running 40 days and data has nos been transfered to PC.
It is connected to a raspberry pi3

Weewx has detected ok wmr300 but it is reading records.
I can only read on log: "reading records since *NA**

Is this ok?
how many time could it take?

Thank's a lot.

[mwall]

On Wednesday, February 22, 2017 at 1:53:00 PM UTC-5, Ruben Navarro Huedo wrote:

A lot of thank's

My stations has been running 40 days and data has nos been transfered to PC.

40 days?

which version of the wmr300 driver are you running?
 

Weewx has detected ok wmr300 but it is reading records.
I can only read on log: "reading records since *NA**

Is this ok?
how many time could it take?

if the logger is full it could take a few hours.  the driver will update the log periodically as it reads from the logger.
 
set debug=1 in weewx.conf then post the log from just before you start weewx until after the first archive record.

m

[Cameron D]

On Thursday, 23 February 2017 04:53:00 UTC+10, Ruben Navarro Huedo wrote:

My stations has been running 40 days and data has nos been transfered to PC.
It is connected to a raspberry pi

"nos"? did you mean "now" or "not"?

What is the logging interval set on the WRM300 console?  at 1 minute you get fewer than 30 days storage then it stops recording.

If it is full, it does not discard old log data but stops recording new results.

view the monthly or yearly summary and see what is recorded. 

[Ruben Navarro Huedo]

Excuse me.... it was an human error.
We didn't update driver.
After updating to last driver all is 100% fine.

Thank's a lot.

[Ruben Navarro Huedo]

Running now fine with last driver.
I has readed data from the datalogger from the wmr-300 installation.
This is OK, but if i disconnect it some time (for example 30 minutes) after starting weewx it begins to log real time data but looses these 30 minutes.
Is this Ok?

A lot of thank's

[mwall]

On Thursday, February 23, 2017 at 10:47:22 AM UTC-5, Ruben Navarro Huedo wrote:

Running now fine with last driver.
I has readed data from the datalogger from the wmr-300 installation.
This is OK, but if i disconnect it some time (for example 30 minutes) after starting weewx it begins to log real time data but looses these 30 minutes.
Is this Ok?

if the logger is full, then you will 'lose' data.  apparently the wmr300 logger must be cleared by punching buttons on the console.  if someone knows of software that can clear the logger, please let us know so we can implement this in weewx.

if the logger is not full, then it should continue to capture data during the 30 minutes that weewx is not running.  when you start weewx, it should read data from the logger.

of course, if the logger's archive interval is set to 30 minutes, then you might be 'losing' data because you sampled just less than 30 minutes.

in any case, the weewx log will tell you how many records it retrieved from the logger.
m

[Ruben Navarro Huedo]

I understand.
Problem was logger is FULL.

[Cameron D]

I have the captures of the windows software clearing the log, but have not yet had time to analyse them.

[Ruben Navarro Huedo]

This could be a GREAT new addon !

[Ruben Navarro Huedo]

Hello wmr300 friends.
I want add a second wireless transmiter to my wmr300.
I will use :
One transmitter (Oregon STC300) using channel 1 for: Temp, Humid and Rain
Another transmitter (Also STC300) using channel 2 for: Wind
I need to read all this sensors like one only weather station.
WMR-300 console is reading it correctly (after adding channel 2), but wee_wx doesn't "read" wind information.
Can i do this with weewx?
How?

In another vein: Have we some more information about clearing console datalogger from weewx?

Thank's a lot.