Oregon Scientific WMR89

1,401 views
Skip to first unread message

martin swanepoel

unread,
Jan 3, 2015, 8:24:01 AM1/3/15
to weewx...@googlegroups.com
The specs for the WMR88 and WMR89 look similar. Anybody knows whether the WMR89 will work with weewx?

Thanks.

mwall

unread,
Jan 3, 2015, 11:13:46 AM1/3/15
to weewx...@googlegroups.com
On Saturday, January 3, 2015 8:24:01 AM UTC-5, martin swanepoel wrote:
The specs for the WMR88 and WMR89 look similar. Anybody knows whether the WMR89 will work with weewx?

try the wmr100 driver and let us know if it works

the wmr100 driver looks for product/vendor of 0x0fde/0xca01

the wmr89 might have a product id different from the wmr88.  the vendor id should be the same.

for the wmr100 driver, you can specify a different vendor/product in weewx.conf:

[WMR100]
    product_id = 0xca01

m

martin swanepoel

unread,
Jan 3, 2015, 12:27:01 PM1/3/15
to weewx...@googlegroups.com
Nope. Got the following out of the syslog:

Jan  3 14:13:46 Weather weewx[8994]: engine: Initializing weewx version 3.0.1
Jan  3 14:13:46 Weather weewx[8994]: engine: Using Python 2.7.3 (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
Jan  3 14:13:46 Weather weewx[8994]: engine: Using configuration file /root/weewx301/weewx.conf
Jan  3 14:13:46 Weather weewx[8994]: engine: Loading station type WMR100 (weewx.drivers.wmr100)
Jan  3 14:13:47 Weather weewx[8994]: engine: StdConvert target unit is 0x1
Jan  3 14:13:47 Weather weewx[8994]: engine: Archive will use data binding wx_binding
Jan  3 14:13:47 Weather weewx[8994]: engine: Record generation will be attempted in 'hardware'
Jan  3 14:13:47 Weather weewx[8994]: engine: Using archive interval of 300 seconds
Jan  3 14:13:48 Weather weewx[8994]: manager: Created and initialized table 'archive' in database 'archive/weewx.sdb'
Jan  3 14:13:49 Weather weewx[8994]: manager: Created daily summary tables
Jan  3 14:13:49 Weather weewx[8994]: engine: Using binding 'wx_binding' to database 'archive/weewx.sdb'
Jan  3 14:13:49 Weather weewx[8994]: engine: Starting backfill of daily summaries
Jan  3 14:13:49 Weather weewx[8994]: engine: Daily summaries up to date.
Jan  3 14:13:49 Weather weewx[8994]: engine: Starting up weewx version 3.0.1
Jan  3 14:13:49 Weather weewx[8994]: engine: Starting main packet loop.
Jan  3 14:13:49 Weather weewx[8994]: wmr100: Unable to send USB control message
Jan  3 14:13:49 Weather weewx[8994]: ****  error sending control message: Broken pipe
Jan  3 14:13:49 Weather weewx[8994]: engine: Caught WeeWxIOError: error sending control message: Broken pipe
Jan  3 14:13:49 Weather weewx[8994]:     ****  Waiting 60 seconds then retrying...

dmesg:
[    2.368969] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[    2.475477] usb 1-1.2: New USB device found, idVendor=0fde, idProduct=ca0a
[    2.477207] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.484862] usb 1-1.2: Product: WMR89 Professional Weather Station
[    2.486511] usb 1-1.2: Manufacturer: Silicon Labs
[    2.487998] usb 1-1.2: SerialNumber: xxxxxxxx

lsusb -v:
Bus 001 Device 004: ID 0fde:ca0a
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0fde
  idProduct          0xca0a
  bcdDevice            1.00
  iManufacturer           1 Silicon Labs
  iProduct                2 WMR89 Professional Weather Station
  iSerial                 3 009F3A42
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              2 WMR89 Professional Weather Station
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

Regards,
Martin


On Saturday, January 3, 2015 6:13:46 PM UTC+2, mwall wrote:
On Saturday, January 3, 2015 8:24:01 AM UTC-5, martin swanepoel wrote:
The specs for the WMR88 and WMR89 look similar. Anybody knows esg:whether the WMR89 will work with weewx?

mwall

unread,
Jan 3, 2015, 12:37:44 PM1/3/15
to weewx...@googlegroups.com
On Saturday, January 3, 2015 12:27:01 PM UTC-5, martin swanepoel wrote:
Nope. Got the following out of the syslog:

interesting.  the 'broken pipe' probably means that the wmr89 is using a different protocol than the wmr100 driver is using.

try using the wmr200 driver instead of wmr100 driver.  you will probably have to set the product id:

[Station]
    ...
    station_type = WMR200
[WMR200]
    product_id = 0xca0a
    driver = weewx.drivers.wmr200

if that does not work you'll have to do some sniffing of the usb traffic.

m

martin swanepoel

unread,
Jan 3, 2015, 12:43:58 PM1/3/15
to weewx...@googlegroups.com
No success. Syslog messages:

Jan  3 19:41:06 Weather weewx[2580]: engine: Initializing weewx version 3.0.1
Jan  3 19:41:06 Weather weewx[2580]: engine: Using Python 2.7.3 (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
Jan  3 19:41:06 Weather weewx[2580]: engine: Using configuration file /root/weewx301/weewx.conf
Jan  3 19:41:06 Weather weewx[2580]: engine: Loading station type WMR200 (weewx.drivers.wmr200)
Jan  3 19:41:06 Weather weewx[2580]: wmr200: MainThread: I Created watchdog thread to poke for live data every 30 seconds
Jan  3 19:41:06 Weather weewx[2580]: wmr200: MainThread: I Created USB polling thread to read block on device
Jan  3 19:41:06 Weather weewx[2580]: wmr200: MainThread: E write_device() Unable to send USB control message error sending control message: Broken pipe
Jan  3 19:41:06 Weather weewx[2580]: engine: Unable to load driver: error sending control message: Broken pipe
Jan  3 19:41:06 Weather weewx[2580]: engine: Caught WeeWxIOError: error sending control message: Broken pipe
Jan  3 19:41:06 Weather weewx[2580]:     ****  Exiting...
Jan  3 19:41:06 Weather weewx[2580]: wmr200: Thread-2: I USB polling device thread for live data launched

Any pointers on how to sniff the usb traffic? Never done it before.

Thanks.

mwall

unread,
Jan 3, 2015, 1:08:56 PM1/3/15
to weewx...@googlegroups.com
On Saturday, January 3, 2015 12:43:58 PM UTC-5, martin swanepoel wrote:
Any pointers on how to sniff the usb traffic? Never done it before.


sniffing is pretty easy, but making sense out of what you sniff can be quite complicated.

the basic idea is to run the vendor's software while you monitor traffic on the usb.  in this case you would run the wmr89 windows software, using pcap to monitor and capture the traffic.

1) install pcap in windows

2) start pcap and start capturing traffic

3) start the windows software that communicates with the device

4) do something in the software

5) stop the software

6) stop the pcap capture

you should do this repeatedly, and for small actions.  for example, do one capture where you collect current readings from the station.  do another capture where you set some value on the station.  by isolating the actions you make it easier to decode the traffic.

to analyze a capture, load it into an analysis tool such as wireshark.

then the difficult part begins: decoding.  the capture contains the bytes sent to/from the device.  but you still have to decode them.  the wmr100 and wmr200 drivers might help here.

(i guess we should make a wiki page about this)

i would be surprised if the wmr89 has a protocol completely different from the wmr88.  it is possible that the wmr100 driver just needs a little adjustment to make the communication work.

m

martin swanepoel

unread,
May 1, 2015, 5:21:20 AM5/1/15
to weewx...@googlegroups.com
Got a couple of usb captures for this weather station. Anybody willing to decipher this?

Thanks,
Martin

Thomas Keffer

unread,
May 1, 2015, 9:57:01 AM5/1/15
to weewx-user
Martin,

Did you try the WMR200 driver?

-tk

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

martin swanepoel

unread,
May 3, 2015, 4:46:21 AM5/3/15
to weewx...@googlegroups.com
Yes we tried it, but no success.

Thanks

mwall

unread,
May 3, 2015, 1:41:26 PM5/3/15
to weewx...@googlegroups.com
On Friday, May 1, 2015 at 5:21:20 AM UTC-4, martin swanepoel wrote:
Got a couple of usb captures for this weather station. Anybody willing to decipher this?

martin,

do you have pcap files of the usb traffic?  do you also have a description of what you and/or the software was doing to generate the traffic?  also the actual values displayed in the software and/or hardware display?

for example, one test is to request current sensor values from the station, capture the usb traffic for the request and the reply, and note the (decoded) values that are reported.  another test would be to set the station time.  another would be to request historical records from the station (if the wmr89 has a logger, of course).  start with simply decoding the sensor readings.

a dump of usb traffic without any accompanying context is much more difficult to decipher.  it is easy to tell which parts of the traffic are data, and fairly easy to infer the communication protocol if there are a lot of packets.  if there are many packets then some educated guesses can be made about the data.  but decoding the actual data is difficult unless there are some converted/decoded values to go with the raw traffic.

m

Erik

unread,
Nov 25, 2015, 5:46:33 AM11/25/15
to weewx-user
Hi,

I see this post has gone quiet, hopefully I can revive it and add another supported device to the weewx community.

@mwall:
I also have a WMR89 and would like to get it to work on weewx. 

How can I debug the device so that whatever the minor differences between my device and the WMR 88 / WMR 180 can be defined, so that the WMR89 is supported?

I'll happily capture and supply some pcap files, if that's what is required. Please advise what exactly you'd like me to capture and interpret.

Thanks,
Erik.

mwall

unread,
Nov 25, 2015, 8:06:22 PM11/25/15
to weewx-user
On Wednesday, November 25, 2015 at 5:46:33 AM UTC-5, Erik wrote:
How can I debug the device so that whatever the minor differences between my device and the WMR 88 / WMR 180 can be defined, so that the WMR89 is supported?

apparently the WMR89 is significantly different from the WMR88:

http://www.wxforum.net/index.php?topic=27581.0
 
I'll happily capture and supply some pcap files, if that's what is required. Please advise what exactly you'd like me to capture and interpret.

start with something simple:

1) plug in the device to a windows computer
2) start capturing usb traffic for that device
3) start up the windows software that came with the computer
4) make note of what the windows software displays, e.g., values from the sensors
5) stop the windows software
6) stop the capture

inspect the capture to get an idea of how the software communicates with the hardware.  do it a few times to see if it is repeatable.

then start to target specific types of communication.  for example, figure out how the software gets current readings:

1) plug in the device
2) start up the windows software
3) start capturing usb traffic
4) wait for 10 minutes
5) stop capturing traffic

or figure out how to set/get specific parameters (this will depend on the hardware - does the WMR89 let you set its clock? altitude? time zone?)

1) plug in the device
2) start up the windows software
3) start capturing usb traffic
4) use the software to set/get a single parameter
5) stop capturing traffic

or figure out how the data logger works (does the WMR89 have a logger?  does the windows software use it?)

1) plug in the device
2) start up the windows software
3) start capturing usb traffic
4) use the software to download the historical data
5) stop capturing traffic
6) save both the capture and the historical data

from multiple captures you'll be able to figure out the communication protocols.  or post a few of the captures in the weewx development group so that others can have a go at dissecting them.

to decode the actual communication, you must post not only the capture, but also what was done during the capture, and the corresponding real values.  for example, if you captured the process of setting the time zone, we also need to know what the time zone was before and after setting it.

m

Erik

unread,
Feb 6, 2016, 8:32:01 AM2/6/16
to weewx-user
Hi m,

Sorry, I hadn't had much time to spend on this, but I gave I a tinker again today.

To answer your questions:

 
How can I debug the device so that whatever the minor differences between my device and the WMR 88 / WMR 180 can be defined, so that the WMR89 is supported?

apparently the WMR89 is significantly different from the WMR88:

http://www.wxforum.net/index.php?topic=27581.0
Noted.

  
I'll happily capture and supply some pcap files, if that's what is required. Please advise what exactly you'd like me to capture and interpret.

start with something simple:

1) plug in the device to a windows computer
2) start capturing usb traffic for that device
3) start up the windows software that came with the computer
4) make note of what the windows software displays, e.g., values from the sensors
5) stop the windows software
6) stop the capture

inspect the capture to get an idea of how the software communicates with the hardware.  do it a few times to see if it is repeatable.
Done I have attached a zipped pcap file.


then start to target specific types of communication.  for example, figure out how the software gets current readings:

1) plug in the device
2) start up the windows software
3) start capturing usb traffic
4) wait for 10 minutes
5) stop capturing traffic

or figure out how to set/get specific parameters (this will depend on the hardware - does the WMR89 let you set its clock? altitude? time zone?)
The software does not allow you to set the settings. The only way to set them is via the device itself.
The Oregon "Weather Pro" software (image attached) seems to be a view-only interface, which can alert you on the current status and to certain conditions, but provides little in the way of configuration.

 
1) plug in the device
2) start up the windows software
3) start capturing usb traffic
4) use the software to set/get a single parameter
5) stop capturing traffic

or figure out how the data logger works (does the WMR89 have a logger?  does the windows software use it?)
As I mentioned, the software has limited functionality. It appears to do some primitive logging and monitoring of the device's stats.

 
1) plug in the device
2) start up the windows software
3) start capturing usb traffic
4) use the software to download the historical data
5) stop capturing traffic
6) save both the capture and the historical data

from multiple captures you'll be able to figure out the communication protocols.  or post a few of the captures in the weewx development group so that others can have a go at dissecting them.

to decode the actual communication, you must post not only the capture, but also what was done during the capture, and the corresponding real values.  for example, if you captured the process of setting the time zone, we also need to know what the time zone was before and after setting it.
As I have captured some information, can you provide some guidance on how this can be analysed and deconstructed?

Thanks.





20160206-wmr89.zip
Reply all
Reply to author
Forward
0 new messages