Re: [weewx-user] Davis Weather Monitor II

468 views
Skip to first unread message

Thomas Keffer

unread,
Dec 10, 2013, 9:35:35 AM12/10/13
to weewx...@googlegroups.com
Hello, 

As I understand it, the WM II uses a protocol "similar," but, unfortunately, not identical to the Vantage series. If you are a Python programmer, you're welcome to give it a try. I think there is probably some documents on the Davis website that describes the protocol it uses.

-tk

On Monday, December 9, 2013, wrote:
Hello,

Is it possible to modify weewx to support the Davis Weather Monitor II?  If so, how much work would be involved?

I have a Weather Monitor II and the weatherlink serial interface and need software to be able to upload data to weatherunderground.

Thanks!

--
You received this message because you are subscribed to the Google Groups "Weewx user's group" 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/groups/opt_out.

ma...@slabax.com

unread,
Dec 12, 2013, 9:27:57 PM12/12/13
to weewx...@googlegroups.com
Hi Tom,

Thanks for the response.  Do you know of anyone who has already done any work on a driver for the WM II?

Marty
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.

Thomas Keffer

unread,
Dec 13, 2013, 7:40:46 AM12/13/13
to weewx-user
Unfortunately, no. It looks like not even wview (which has the most extensive list of supported hardware I know of) supports it.

-tk


To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

Matthew Wall

unread,
Dec 13, 2013, 8:19:13 AM12/13/13
to weewx...@googlegroups.com

On 13 Dec 2013, at 07:40, Thomas Keffer wrote:

> Unfortunately, no. It looks like not even wview (which has the most extensive list of supported hardware I know of) supports it.

tom,

weather display supports the most types of hardware:

weewx wview wd cumulus wfrog
vantage pro/vue y y y y y
wmr100 y y y y y
wmr200 y y y y y
wmr9x8 y y y y y
fo10xx/fo20xx y y y y y
fo30xx y y y y
ws23xx y y y y -
ws28xx y y y
te923 y y y
vaisala y y
twi y y
instromet y y
peet bros y
kestral y
1-wire y
davis wmIII y
rain wise y
weather hawk y

for many stations (e.g. ws28xx), wd and cumulus require that the vendor software is running, then they parse local cache file emitted by vendor software.

cumulus is windows only.

weather display runs on windows, macosx, or linux.

m

cub...@gmail.com

unread,
Jan 9, 2014, 11:03:00 PM1/9/14
to weewx...@googlegroups.com
I am kind of in the same boat.  I have been using meteo (meteo.othello.ch) but it requires considerable expertise to set up (which I do have), and is no longer maintained.  Here is some info that may prove helpful (I have not yet decided whether I want to give weewx a try or not).

The WM II serial protocol document is revision 3.3, 1998 / 1999.    The link to download this document is on page

http://www.davisnet.com/support/weather/downloads/software_direct.asp?SoftCat=4&SoftwareID=38

This is a self extracting exe.  The document itself is named Techref.doc / Techref.txt

The corresponding information for the VP devices is a PDF located at http://www.davisnet.com/support/weather/download/VantageSerialProtocolDocs_v261.pdf

There are definitely some differences:

WM II has only 256 bytes of processor memory instead of 4KB
WM II has only 32KB of archive memory instead of 132KB
WM II has no accessible EEPPROM memory
The Loop Packet is completely different

Over the next week or so, I'll have a look at the respective protocols to see how different they might be - and so how much work might be involved for someone wanting to try.  At first blush, they seem conceptually similar, but different significantly in details, so I'd have to learn how weewx works enough to find the module that supports the Vantage series to get an idea of how much work might be involved.

It would obviously save me a lot of time if someone like TK here could point me at the code that supports the Vantage series.  ;)
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.

mwall

unread,
Jan 9, 2014, 11:10:15 PM1/9/14
to weewx...@googlegroups.com
On Thursday, January 9, 2014 11:03:00 PM UTC-5, cub...@gmail.com wrote:

It would obviously save me a lot of time if someone like TK here could point me at the code that supports the Vantage series.  ;)


i think tom is busy sampling tequilas right now, or perhaps analyzing turbulent flow in a hot tub :)

the vantage-specific code is in bin/weewx/drivers/vantage.py

the schema is located in bin/user/schemas.py

the tail end of the weewx customization guide might also help.

http://weewx.com/docs/customizing.htm

m

cub...@gmail.com

unread,
Jan 10, 2014, 10:03:26 AM1/10/14
to weewx...@googlegroups.com
Thanks.  I also did some code browsing over nite.  It looks like a "wee" bit of work - probably something like 80 hours to get the WM II going.  Not something that one would do in a day or two, but something I *** might *** (as in, NO PROMISES) do over the next month or so.  I really wish it were something other then Python, but hey, that's just me, and I can deal with it.  I am thinking that the technique I would use would be:

1.  Use the existing drivers to come up with a design.
2.  Manually capture and/or build some packets and use them as simulated input to test a driver
3.  Write and test the new driver, and get that going using simulated input
4.  Finally actually hook up to the instrument and test the driver with that.

At first it would probably have some hard-coded configuration stuff - while I learned what was reasonable to configure.

Yuck.  Real work.  ;)

mwall

unread,
Jan 10, 2014, 10:34:29 AM1/10/14
to weewx...@googlegroups.com
On Friday, January 10, 2014 10:03:26 AM UTC-5, cub...@gmail.com wrote:
Thanks.  I also did some code browsing over nite.  It looks like a "wee" bit of work - probably something like 80 hours to get the WM II going.  Not something that one would do in a day or two, but something I *** might *** (as in, NO PROMISES) do over the next month or so.  I really wish it were something other then Python, but hey, that's just me, and I can deal with it.  I am thinking that the technique I would use would be:

1.  Use the existing drivers to come up with a design.
2.  Manually capture and/or build some packets and use them as simulated input to test a driver
3.  Write and test the new driver, and get that going using simulated input
4.  Finally actually hook up to the instrument and test the driver with that.

At first it would probably have some hard-coded configuration stuff - while I learned what was reasonable to configure.


it is probably easier than you think.

beware that there is a wide range of features and styles in the driver code in weewx.  it is mostly due to the hardware capabilities, but it is also tied to driver history.  for example, fousb could be *much* simpler.  it is complicated because we were/are trying to maintain some correlation with the pywws codebase upon which it is based.  the ws23xx driver encapsulates code from the ws2300 codebase.    the wmr200 is more complicated because of the way the hardware works.  the ws28xx driver is insanely large because it started from machine-generated c++ code, and the hardware has many quirks.

on the other hand, the simulator is a great example of minimal driver implementation.  the wmr100 driver is also pretty basic.

one thing you might want to try is to build a basic manual testing mechanism into the driver itself.  take a look at the te923 driver.  there is an entry point in the driver itself so you can test the driver-hardware communication independently of any weewx engine/service layers.  get that working, then worry about the mapping to weewx constructs of LOOP, REC, error handling, etc.  its no automated unit test suite, but it does make driver development go much faster.

please post to the weewx-development list if you run into any snags.

m

cub...@gmail.com

unread,
Jan 10, 2014, 5:50:16 PM1/10/14
to weewx...@googlegroups.com
My estimate was based mostly on a quick read of the documentation for the Weather Monitor II protocol, and comparisons to the doc for the Vantage series, rather than the code in the driver.  I have done a lot of coding over the years, but I really don't like to work in Python.  ;)  I'll have to roll it into Eclipse so I have a development environment (and probably update Eclipse in the process - mine is in need of a refresh).  It might help if I don't bother with archive feature, initially (the WM II only has a complete DMP command, no DMPFRM), and let weewx deal with that, and of course there is whole bunches of stuff for the Vantage series that doesn't apply - like most / all of the configuration stuff.

But, for now (say, next 7 days) I think I will see if the existing meteo code I had been using will just compile and run on my new hardware / updated OS (which prompted this in the first place).  That doesn't mean I would give up on weewx, necessarily, but putting a lot of time into this isn't high on my list right now.

Thomas Keffer

unread,
Jan 10, 2014, 6:29:28 PM1/10/14
to weewx-user
The Vantage driver includes far more than you need to get started --- it even has entry points for turning the console lights on and off!

All you really need to do is implement genLoopPackets(). If the WMII protocol is similar to the Vantage protocol, that should not be too tough. Everything else is optional.

I've been doing a lot of Javascript programming recently. and it has reinforced how much I enjoy Python. :-)

-tk



--
You received this message because you are subscribed to the Google Groups "Weewx user's group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

cub...@gmail.com

unread,
Jan 12, 2014, 9:55:48 PM1/12/14
to weewx...@googlegroups.com
Having read thru the doc, I understand that.  My previous message even made that same point.

javaScript isn't a real language.  Either.  8P
Reply all
Reply to author
Forward
0 new messages