WMR89_Oregon_Scientific

Configuring WMR89 with weeWX

WMR89_Oregon_Scientific

Introduction

My WMR88 Oregon Scientific Station unfortunately died a couple of weeks ago after almost 6 years working. I was very satisfied with this model but Oregon Scientific does not produce it anymore. The updated version, the WMR89, is compatible with the sensors of the old model but, surprisingly, their computer interfaces are completely different. Luckily some clever people from www.wxforum.net found out how to decode the data sent by the station. In this short guide I will expose how to install and configure a WMR89 station with weeWX in a Raspberry Pi.

Configuring CP210x Driver

Most weeWX drivers use pyusb library to communicate with weather stations. That was the case, for instance, of the WMR88. However, the WMR89 uses chip CP210x as a USB to UART (serial) Bridge Virtual COM Port. Using the CP210x drivers the device can be mapped to a serial port of the Raspberry Pi, such as /dev/ttyUSB0. The required drivers are already included in the last Raspbian version (Strech) but, to map the device, you should first load the CP210x kernel module. You can do it manually by typing:

Unfortunately, the vendor and product ID of the WMR89 are not registered in the driver CP210x.c. This means that, even though the device can be found with dmesg when connected, your Raspberry will not be able to communicate with it (/dev/ttyUSB* doesn’t exist). One option could be to edit the driver, include the pair vendor/product, recompile and reinstall.

A much simpler solution is to edit the file /sys/bus/usb-serial/drivers/cp210x/new_id and include the vendor and product ID of the WMR89 station in it. Writing a product ID to this file will make Raspberry to attempt to dynamically add it to a PCI device driver. Upon successfully adding an ID, the driver will probe for the device and attempt to bind to it. Do it with this code, where 0fde is the vendor Id and ca0a the product:

If everything runs correctly, you should see now the device in /dev/ttyUSB0.

If you want to load automatically cp210x kernel module at boot time append it to file /etc/modules:

I have also included in rc.local the  command to add the device to new_id file in order to ensure that the weather station, when connected, is correctly configured.

Installing WMR89 weeWX driver

There are a couple of available weeWX drivers for the WMR90 station. However, none of them are officially included in the last weeWX release (3.8.0 version).  The drivers are not complete and are unable to decode forecast values or low battery signals. However the basic weather information is correctly captured. I have used fcauwe driver, available in his Github. Download the file, place it in /usr/share/weewx/drivers (for a Raspberry Pi running Raspbian) and do the following changes in your weewx.conf file:

 Due to the utilisation of CP210x, the driver uses pyserial instead of the pyusb module to communicate with the weather station unlike it happened with the WMR100 driver. Once configured, you should just restart weeWX to see the first incoming data. Note that some weather data are sent in a low pace. For instance, the barometric pressure is sent every 15 minutes. For this reason, and depending on your archive interval, you will see some missing values in your records.

7 thoughts on “Configuring WMR89 with weeWX”

  1. Hey!
    Not working with me. I don’t see the device /dev/ttyUSB0 and there will be an error message: raspberrypi weewx[1505]: import of driver failed: [Errno 2] could not open port /dev/ttyUSB0: ()
    Jul 9 18:34:57 raspberrypi weewx[1505]: engine: Unable to load driver: [Errno 2] could not open port /dev/ttyUSB0:

  2. Hi,
    Thanks a lot for the instructions! It finally helped me to convert my weewx from WMR100 to WMR89. More or less, the process went smooth. Ran in to a couple of issues though, and I describe them here to help others. I’m really not a programmer, so I’ll just describe this with my own words.
    1. ttyUSB* seems to be deleted during restart of either weewx or my RPi (not sure which). This caused some error messages, seen when running [sudo /etc/init.d/weewx status -l]
    . I solved this by adding it again according to your instructions on this page.
    2. engine.py and crt.py have, for whatever reason, “ghost copies” with extension .pyc, this was discovered after I solved issue #1, and also seen with command [sudo /etc/init.d/weewx status -l]. I found similar problems on various sites, and the solution is to simply delete them (I made backups of course). But, also in this case, both files return after restart, so I just deleted them again and did not restart after that.

    For now I have just left it like this, and will see what happens after next restart.

    Also noticed the issue with barometric values only reported every 15 minutes, causing annoying gaps in the diagram. But I can live with that!

    Again, thanks a lot for publishing this guide!

    BR Hans

    • Hi Hans,

      I am happy to help. Regarding the *.pyc files, they are Python bytecodes. You will find a .pyc file for each .py file. They are created by Python interpreter each time the code in the .py file is run so it is perfectly normal that they “come back” after each weewx restart.

      To avoid this annoying gaps in the barometric pressure diagram, just add aggregate_type = avg and aggregate_interval = 1 in the image definition. Weewx will draw an average of the barometric values received instead of gaps when no value is provided.

      Regards,

      Daniel

  3. Hi Daniel!
    Thanks for the tip! (Sorry for late reply, went travelling for vacation).
    I will try this, as well as to attend to some other issues. Also found additional help in the weewx user group!
    All the best,
    Hans

  4. Hi Daniel,
    Final solution;
    I set the aggregation interval for the database to 15 minutes since the WMR89 interval caused N/A values in the current data table (found this solution in the weewx user group, maybe it was from your comment?!). This however caused gaps in all lines in the 24 hour diagrams. Your proposal above did unfortunately not work as expected for me, tried to put it on different levels in the image generator. But the solution was found in the gap lines function which I (for now) have set to 3600 sec. So, the 15 minute gaps are visually gone, and only mor lasting gaps will show, so it is easy to see where data is truly missing.
    Again, thanks for publishing your method on this page and for the support to me!
    Cheers,
    Hans

Leave a Comment