Airmar 150WX+weewx

[Aleksandar Tsankov]

Hi guys!
Recently I obtained an access to Airmar 150WX WeatherStation. Since I do not like the software which comes with it I started to search for alternative and found weewx. It's completely on my taste - Unix oriented and open source so I decided to give it a try.
However I do not see Airmar 150WX in the list of supported hardware. My question is is it possible to use weewx with Airmar 150WX out of the box? And if it's not possible, how weewx can be tweaked to do so? I have enough skills in Perl programming (not python, sorry) to make a daemon that connects to Airmar via serial port, fetch the data stream and store it in a temporary file or resend it over TCP.
For the record, the output format of Airmar 150WX is NMEA 0183.

Regards
Alex

[Thomas Keffer]

Hello, Aleksandar

I'm not aware of any drivers for the Airmar, but if it's NMEA, then it should not be very hard to write one, even if you have limited experience with Python. NMEA 0183 is a serial, ASCII protocol, with a very simple structure.

Do you have a list of sentences that it emits?

Take a look at the Ultimeter driver (file bin/weewx/drivers/ultimater.py), which also uses a simple serial protocol. NMEA is even simpler than this.

I would strongly recommend doing it in Python, rather than rely on interprocess communications from a Perl program. 

-tk

[Aleksandar Tsankov]

Hi Thomas and thank you for your fast reply!
Of course IPC is a hell, even between forked processes - shared memory, pipes etc. Of course I do not meant such approach for production environment - I'd rather thought about quick and dirty hack in order to see that things work.
Airmar 150WX sends data in NMEA 0183 format which format can be seen at http://www.airmartechnology.com/uploads/installguide/PB100TechnicalManual_rev1.007.pdf
Today I gathered some data from device and you can see it:

$GPGGA,102108.50,4207.5457,N,02446.4413,E,1,9,1.0,148.0,M,43.5,M,,*50 $GPVTG,122.0,T,117.3,M,0.1,N,0.1,K,A*26 $WIMWV,91.5,R,0.3,N,A*1D $WIMDA,29.9139,I,1.0130,B,19.1,C,,,23.5,,-2.2,C,263.2,T,258.5,M,0.3,N,0.2,M*7D $GPZDA,102109.00,03,04,2015,00,00*6C $YXXDR,A,-2.9,D,PTCH,A,-18.7,D,ROLL*68 $YXXDR,C,,C,WCHR,C,,C,WCHT,C,,C,HINX,P,0.9954,B,STNP*4A $WIMWV,91.5,R,0.3,N,A*1D $GPGGA,102109.50,4207.5457,N,02446.4413,E,1,9,1.0,148.1,M,43.5,M,,*50 $GPVTG,125.3,T,120.6,M,0.1,N,0.1,K,A*23 $WIMWV,91.5,R,0.2,N,A*1C $WIMDA,29.9109,I,1.0129,B,19.1,C,,,23.5,,-2.2,C,268.0,T,263.3,M,0.2,N,0.1,M*73 $GPZDA,102110.00,03,04,2015,00,00*64 $YXXDR,A,-2.9,D,PTCH,A,-18.7,D,ROLL*68 $YXXDR,C,,C,WCHR,C,,C,WCHT,C,,C,HINX,P,0.9953,B,STNP*4D $WIMWV,91.5,R,0.2,N,A*1C $GPGGA,102110.50,4207.5458,N,02446.4413,E,1,9,1.0,148.2,M,43.5,M,,*54 $GPVTG,126.0,T,121.3,M,0.1,N,0.1,K,A*27 $WIMWV,91.5,R,0.3,N,A*1D $WIMDA,29.9139,I,1.0130,B,19.1,C,,,23.5,,-2.2,C,262.8,T,258.1,M,0.3,N,0.2,M*72 $GPZDA,102111.00,03,04,2015,00,00*65 $YXXDR,A,-2.9,D,PTCH,A,-18.7,D,ROLL*68 $YXXDR,C,,C,WCHR,C,,C,WCHT,C,,C,HINX,P,0.9954,B,STNP*4A $WIMWV,91.5,R,0.3,N,A*1D $GPGGA,102111.50,4207.5458,N,02446.4412,E,1,9,1.0,148.4,M,43.5,M,,*52 $GPVTG,139.9,T,135.2,M,0.0,N,0.0,K,A*24 $WIMWV,91.5,R,0.1,N,A*1F $WIMDA,29.9139,I,1.0130,B,19.1,C,,,23.5,,-2.2,C,280.8,T,276.1,M,0.1,N,0.1,M*73 $GPZDA,102112.00,03,04,2015,00,00*66 $YXXDR,A,-3.0,D,PTCH,A,-18.8,D,ROLL*6F $YXXDR,C,,C,WCHR,C,,C,WCHT,C,,C,HINX,P,0.9953,B,STNP*4D $WIMWV,91.5,R,0.2,N,A*1C $GPGGA,102112.50,4207.5458,N,02446.4412,E,1,9,1.0,148.7,M,43.5,M,,*52 $GPVTG,125.6,T,120.9,M,0.0,N,0.0,K,A*29 $WIMWV,91.5,R,0.2,N,A*1C $WIMDA,29.9139,I,1.0130,B,19.1,C,,,23.5,,-2.2,C,251.6,T,246.9,M,0.2,N,0.1,M*79 $GPZDA,102113.00,03,04,2015,00,00*67 $YXXDR,A,-2.9,D,PTCH,A,-18.7,D,ROLL*68 $YXXDR,C,,C,WCHR,C,,C,WCHT,C,,C,HINX,P,0.9953,B,STNP*4D $WIMWV,91.5,R,0.3,N,A*1D $GPGGA,102113.50,4207.5458,N,02446.4412,E,1,9,1.0,148.8,M,43.5,M,,*5C $GPVTG,142.1,T,137.4,M,0.0,N,0.0,K,A*24 $WIMWV,91.5,R,0.2,N,A*1C $WIMDA,29.9168,I,1.0131,B,19.1,C,,,23.5,,-2.2,C,251.6,T,246.9,M,0.2,N,0.1,M*7C $GPZDA,102114.00,03,04,2015,00,00*60 $YXXDR,A,-3.0,D,PTCH,A,-18.8,D,ROLL*6F $YXXDR,C,,C,WCHR,C,,C,WCHT,C,,C,HINX,P,0.9954,B,STNP*4A $WIMWV,91.5,R,0.2,N,A*1C $GPGGA,102114.50,4207.5458,N,02446.4412,E,1,9,1.0,148.9,M,43.5,M,,*5A $GPVTG,128.0,T,123.3,M,0.0,N,0.0,K,A*2B $WIMWV,91.5,R,0.2,N,A*1C $WIMDA,29.9139,I,1.0130,B,19.1,C,,,23.4,,-2.2,C,251.7,T,247.0,M,0.2,N,0.1,M*71 $GPZDA,102115.00,03,04,2015,00,00*61 $YXXDR,A,-2.9,D,PTCH,A,-18.7,D,ROLL*68 $YXXDR,C,,C,WCHR,C,,C,WCHT,C,,C,HINX,P,0.9953,B,STNP*4D $WIMWV,91.5,R,0.3,N,A*1D $GPGGA,102115.50,4207.5458,N,02446.4412,E,1,9,1.0,149.0,M,43.5,M,,*53 $GPVTG,120.5,T,115.8,M,0.2,N,0.3,K,A*29 $WIMWV,91.5,R,0.2,N,A*1C $WIMDA,29.9139,I,1.0130,B,19.1,C,,,23.4,,-2.2,C,274.6,T,269.9,M,0.3,N,0.2,M*70 $HCHDT,160.1,T*2F $GPZDA,102116.00,03,04,2015,00,00*62 $YXXDR,A,-2.9,D,PTCH,A,-18.7,D,ROLL*68 $YXXDR,C,,C,WCHR,C,,C,WCHT,C,,C,HINX,P,0.9953,B,STNP*4D $WIMWV,91.5,R,0.3,N,A*1D $GPGGA,102116.50,4207.5457,N,02446.4412,E,1,9,1.0,149.2,M,43.5,M,,*5D $GPVTG,122.4,T,117.7,M,0.2,N,0.3,K,A*27 $WIMWV,91.5,R,0.3,N,A*1D $WIMDA,29.9198,I,1.0132,B,19.1,C,,,23.4,,-2.2,C,270.4,T,265.7,M,0.4,N,0.2,M*7A $GPZDA,102117.00,03,04,2015,00,00*63 $YXXDR,A,-2.9,D,PTCH,A,-18.7,D,ROLL*68 $YXXDR,C,,C,WCHR,C,,C,WCHT,C,,C,HINX,P,0.9954,B,STNP*4A $WIMWV,91.5,R,0.3,N,A*1D $GPGGA,102117.50,4207.5457,N,02446.4413,E,1,9,1.0,149.3,M,43.5,M,,*5C $GPVTG,115.4,T,110.7,M,0.2,N,0.3,K,A*24 $WIMWV,91.5,R,0.2,N,A*1C $WIMDA,29.9168,I,1.0131,B,19.1,C,,,23.4,,-2.2,C,273.4,T,268.7,M,0.3,N,0.2,M*7F $GPZDA,102118.00,03,04,2015,00,00*6C $YXXDR,A,-2.9,D,PTCH,A,-18.7,D,ROLL*68 $YXXDR,C,,C,WCHR,C,,C,WCHT,C,,C,HINX,P,0.9953,B,STNP*4D $WIMWV,91.5,R,0.3,N,A*1D $GPGGA,102118.50,4207.5457,N,02446.4413,E,1,9,1.0,149.4,M,43.5,M,,*54 $GPVTG,123.1,T,118.4,M,0.1,N,0.1,K,A*2E $WIMWV,91.5,R,0.2,N,A*1C $WIMDA,29.9168,I,1.0131,B,19.1,C,,,23.4,,-2.2,C,266.7,T,262.0,M,0.2,N,0.1,M*77 $GPZDA,102119.00,03,04,2015,00,00*6D $YXXDR,A,-2.9,D,PTCH,A,-18.7,D,ROLL*68 $YXXDR,C,,C,WCHR,C,,C,WCHT,C,,C,HINX,P,0.9953,B,STNP*4D $WIMWV,91.5,R,0.3,N,A*1D

I gave a look to utilmeter.py and yes, it is not complicated even for a newbie like me :). I think it can be easily rewritten but I'm still not aware about the whole mechanism of weewx and particularly with the fields which are not present in Airmar's data or with fields that are present but not handled in weewx, getting/setting date of device - it is not present in 150WX etc.
I'm still reading the driver's code and who knows - may be I'll try to write on python :).

Regards
Alex

[Thomas Keffer]

there's only a handful of functions that have to be implemented to make a useful driver. Of those, only one, genLoopPackets(), is particularly hard.

Be sure to see the section Porting to new hardware in the Customizing Guide.

-tk

[Aleksandar Tsankov]

After long reading I created some sort of Airmar driver :). Well, I didn't tried it yet. I'm attaching it here in order to be verified because it obviously will have a lot of mistakes.
Parsing the NMEA 0183 sentences is only partially - without GPS-related ones. I hope someone will check the content of the data() dictionary (hash in the Perl world) - probably there are items which are already in use with another devices and I gave them new names.
Airmar devices allow two-way communication (accept commands) but I didn't implement that yet - only unidirectional stream of data from WS to PC.

[Thomas Keffer]

Hello

Unfortunately, my main development computer died last night, so I can't take a good look at this.

But, just looking through it, it seems like a great start. You sure you didn't know any Python? :-)

Couple of suggestions.

In general, statements like

        buf = buf.split(",")

are not a good idea. They are tougher to debug and, in a language that makes heavy use of dynamic memory, they don't save any space. Better to introduce a new variable.

The other thing to watch out for is missing values. I  don't know how the Airmar would signal this --- perhaps just a blank field --- but you need to be prepared for it. Set any missing values to None.

Finally, do you know if it emits Sea-level Pressure (that is, corrected for altitude and temperature), altimeter (corrected only for altitude) or gauge (uncorrected) pressure?

-tk

[Aleksandar Tsankov]

Hi Thomas,
No, I've never did a Python programming since yesterday :). Well, now and then I tried to read Python code but only from academical interest :).

About suggestions - of course it was stupid idea to reuse variables in such a way. I'll clean the code accordingly. The other thing - about missing values: yes, I red this in the instructions but was in a hurry and did not want to think about it at that stage.

About the pressure, I think Airmar device emits two of them:
- in sentence $YXXDR-A it emits barometric station pressure which is the raw, uncorrected barometric pressure reading. It is distinct from the altimeter setting, which is the barometric pressure corrected for altitude, provided in the MDA sentence.
- in sentence $WIMDA: The barometric pressure provided in this sentence is the altimeter setting, which is the barometric pressure corrected for altitude above sea level.

Regards
Alex

[Thomas Keffer]

In that case, the results from sentence $YXXDR-A would go to weewx data type "pressure".

Sentence $WIMDA would go to "altimeter".

Service StdWXCalculate will calculate  the last of the trinity, "barometer". 

-tk

[Aleksandar Tsankov]

Added corrections as Thomas suggested.
Thomas, can you also check wind and rain sections? Or tell me what are the common accepted names and their meanings?

Regards
Alex

[Thomas Keffer]

Few other suggestions:

Some of the lines are very long --- 229 characters in one case. Generally, we try to keep them under 100 characters. 

You have a few hard coded tabs in the file. We use spaces. Standard indent is four spaces.

Generally, we've been using totalRain for total accumulated rain (rather than long_term_rain)

While the formula is dirt simple, we use the function weewx.wxformulas.calculate_rain() to calculate rain from the change in total rain.

In the calculations for rollRate and rollRate_raw, you are missing an opening bracket ('[')

So far, we have not encountered measurements relative to a moving platform, or relative to a heading, or relative to magnetic north. I think you're on the right track by introducing suffixes such as _m, _t, _r, _rv, etc. Could you produce a table with each of these suffixes and a precise definition? I think this could be a very useful addition, so getting these right, early, is important.

Having said that, so far all wind directions in weewx are considered to be against true north so the variable windDir_t should just be windDir. We will have to live with the old definition.

But, using the suffix _m to indicate magnetic seems like a good idea.

What do you see as the difference between windDir_t and windAngle_t. In your comments, you say the latter is "theoretical," meaning that it has been corrected for the platform's movement, but where would the former have come from? Think about this, and include the difference in your table.

Thanks. This looks interesting.

-tk

[Aleksandar Tsankov]

Hi,
The long lines are probably due to the comments. I suppose the comments will be cleared in some time, but for now I think they will be in help because even I am not so familiar with the code :).
Hardcoded tabs are from Geany - I thought tabs are inherited from the code used as a basis but may be I'm wrong. Will have to check how Geany introduces them.

I made a simple table with dictionary names and relation to the Airmar NMEA sentences. In fact, all descriptions can be found in the file 300WXUserTechnicalManual_0183.pdf which I'm also uploading.
I fixed the missing bracket and also a missing dollar sign and uploading the new version of driver. I didn't change the name of windDir_t to windDir yet because after inspecting the table and PDF Thomas may have another ideas :).

Regards
Alex

[Aleksandar Tsankov]

It finally works!
Today I tested the driver (after some bugfixing) and yes - it works.
Here is an excerpt from console output:

LOOP:   2015-04-15 20:04:33 EEST (1429117473) {'rain': None, 'rainRate': 0, 'long_term_rain': None, 'usUnits': 1, 'dateTime': 1429117473}
LOOP:   2015-04-15 20:04:33 EEST (1429117473) {'windchill': 77.0, 'dewpoint': 36.859999999999999, 'outHumidity': 23.5, 'rainRate': 0, 'windDir_m': 105.7, 'heatindex': 77.0, 'rain': None, 'dateTime': 1429117473, 'windDir': 110.40000000000001, 'outTemp': 77.0, 'windSpeed': 0.086897624040818605, 'long_term_rain': None, 'altimeter': 30.105799999999999, 'usUnits': 1}
LOOP:   2015-04-15 20:04:33 EEST (1429117473) {'rain': None, 'dateTime': 1429117473, 'windSpeed': 0.17379524808163721, 'long_term_rain': None, 'windAngle_r': 91.5, 'rainRate': 0, 'usUnits': 1}
LOOP:   2015-04-15 20:04:33 EEST (1429117473) {'heading_true': 18.699999999999999, 'rain': None, 'dateTime': 1429117473, 'long_term_rain': None, 'rainRate': 0, 'usUnits': 1}
LOOP:   2015-04-15 20:04:33 EEST (1429117473) {'rain': None, 'rainRate': 0, 'long_term_rain': None, 'usUnits': 1, 'dateTime': 1429117473}
LOOP:   2015-04-15 20:04:34 EEST (1429117474) {'rain': None, 'rainRate': 0, 'long_term_rain': None, 'usUnits': 1, 'dateTime': 1429117474}
LOOP:   2015-04-15 20:04:34 EEST (1429117474) {'rain': None, 'rainRate': 0, 'long_term_rain': None, 'usUnits': 1, 'dateTime': 1429117474}
LOOP:   2015-04-15 20:04:34 EEST (1429117474) {'rain': None, 'rainRate': 0, 'long_term_rain': None, 'usUnits': 1, 'dateTime': 1429117474}
LOOP:   2015-04-15 20:04:34 EEST (1429117474) {'rain': None, 'dateTime': 1429117474, 'windSpeed': 0.26069287212245579, 'long_term_rain': None, 'windAngle_r': 91.5, 'rainRate': 0, 'usUnits': 1}
LOOP:   2015-04-15 20:04:34 EEST (1429117474) {'heading_true': 18.800000000000001, 'rain': None, 'dateTime': 1429117474, 'long_term_rain': None, 'rainRate': 0, 'usUnits': 1}
LOOP:   2015-04-15 20:04:34 EEST (1429117474) {'rain': None, 'rainRate': 0, 'long_term_rain': None, 'usUnits': 1, 'dateTime': 1429117474}
LOOP:   2015-04-15 20:04:34 EEST (1429117474) {'windchill': 77.0, 'dewpoint': 36.68, 'outHumidity': 23.399999999999999, 'rainRate': 0, 'windDir_m': 105.59999999999999, 'heatindex': 77.0, 'rain': None, 'dateTime': 1429117474, 'windDir': 110.3, 'outTemp': 77.0, 'windSpeed': 0.17379524808163721, 'long_term_rain': None, 'altimeter': 30.102900000000002, 'usUnits': 1}

Web interface also works although it's not so meaningful at the moment since device is indoor.
I think some remapping of dictionary keys is needed - I hope Thomas will help me.

I'm attaching the working driver - all older versions are not functional.

Regards
Alex

[mwall]

On Wednesday, April 15, 2015 at 3:28:44 PM UTC-4, Aleksandar Tsankov wrote:

It finally works!
Today I tested the driver (after some bugfixing) and yes - it works.

alex,

very nice!

could you create a github repository for the driver and put the code there?  just sign up for a github account, create a new repository called 'airmar' or 'airmar-driver', then put the code into the repository.

with the driver in github we can make specific suggestions, review the code, see what changes you make, etc.

m

[mwall]

On Wednesday, April 15, 2015 at 3:28:44 PM UTC-4, Aleksandar Tsankov wrote:

It finally works!
Today I tested the driver (after some bugfixing) and yes - it works.

alex,

here are a few things to consider:

- syntax error at line 239 (missing colon)
- use spaces instead of tabs for all indentation
- the _decode method is not used and can be eliminated
- what happens when message type is $WIMDA but buf[17] is 0?  is that zero windspeed (0) or no windspeed (None)? similarly for other observations
- you probably want either _m or _magn but not both
- 'rainTotal' is probably better than 'long_term_rain' ('long_term_rain' is the label used internally by ultimeter hardware, so it makes sense there)

m

[Aleksandar Tsankov]

hi,
- syntax error at line 239 fixed
- about indentation: I lost about an hour today in fighting with tabs and checking the code with python -tt airmar.py and thought that finally cleared the problem. Obviously it's not :(. Can anyone explain me how to set properly Geany? Don't forget that I'm coming from Perl world and all that indentation is a hell for me :).
- _decode will be removed, probably I forgot to do that
- about checks with "if (buf[17]):" - I thought that it just checks for an empty string and even if it contains "0" it will give a positive decision. Please correct me if I'm wrong.
- for naming convention I'm fully opened for suggestions
- same apply for rainTotal - I just do not have enough time to walk through all drivers and look for dictionary keys.

I've just registered a github account but have to had some reading about how to work with it.
Nevertheless, I'm open for all kind of suggestions (and most of all - for help).

Regards
Alex

[mwall]

On Wednesday, April 15, 2015 at 5:42:48 PM UTC-4, Aleksandar Tsankov wrote:

- about indentation: I lost about an hour today in fighting with tabs and checking the code with python -tt airmar.py and thought that finally cleared the problem. Obviously it's not :(. Can anyone explain me how to set properly Geany? Don't forget that I'm coming from Perl world and all that indentation is a hell for me :).
- _decode will be removed, probably I forgot to do that

with the geany editor, use 'spaces' instead of 'tabs' for the indentation type:

http://www.geany.org/manual/dev/index.html#editor-indentation-preferences

 

- about checks with "if (buf[17]):" - I thought that it just checks for an empty string and even if it contains "0" it will give a positive decision. Please correct me if I'm wrong.

you can test in a python interpreter.  type 'python' at a prompt, then enter python code:

>>> x='0123'
>>> x[0]
'0'
>>> if x[0]:
...     print True
...
True
>>>

so the code you wrote will work, but it is not a very effective test.  for example, if the WIMDA string is only 13 characters long, the test for buf[15] will fail with an exception.  if the strings are expected to be a certain length, then test for that something like this:

if buf[0] == '$WIMDA':
    try:
        data['outHumidity'] = float(buf[9])
    except (ValueError, IndexError):
        data['outHumidity'] = None
    try:
        data['foobar'] = float(buf[10:12])
    except (ValueError, IndexError):
        data['foobar'] = None

btw, the parens in a simple conditional are not necessary in python:

if (buf[17]):
    pass

if buf[17]:
    pass
 

- for naming convention I'm fully opened for suggestions
- same apply for rainTotal - I just do not have enough time to walk through all drivers and look for dictionary keys.

can you use _r instead of _rv to indicate relative?
can you use _t instead of _tv to indicate true?
can you use _magn instead of _m?

for example:
heading_magn
windDir_magn  # instead of windDir_m - the _m might mean meter or minute
windDir       # instead of windDir_t - the _t is implied

the table you posted has some ambiguities.  for example 'windSpeed' is listed multiple times, once as WIMDA, once as WIMWD, and once as WIMDV.
 

I've just registered a github account but have to had some reading about how to work with it.
Nevertheless, I'm open for all kind of suggestions (and most of all - for help).

try using pycharm instead of geany.  it will give you instant feedback about the python syntax.

m

[Aleksandar Tsankov]

Hi again!

I'm attaching another driver's version (not functional).
There are no hardcoded tabs in it :). I also took mwall's advise and implemented the structure try-except (not in all places for the moment but finally will be).
I decided to use a little bit different approach in decoding YXXDR sentences - rows 394 to 400 along with subroutines in rows 163 to 299. Obviously I have a mistake because weewx exits with an error:

alex@t60:~/weewx$ ./bin/weewxd weewx.conf
Traceback (most recent call last):
  File "./bin/weewxd", line 63, in <module>
    weewx.engine.main(options, args)
  File "/home/alex/weewx/bin/weewx/engine.py", line 836, in main
    engine.run()
  File "/home/alex/weewx/bin/weewx/engine.py", line 187, in run
    for packet in self.console.genLoopPackets():
  File "/home/alex/weewx/bin/weewx/drivers/airmar.py", line 84, in genLoopPackets
    data = Station.parse_readings(readings)
  File "/home/alex/weewx/bin/weewx/drivers/airmar.py", line 398, in parse_readings
    getattr(self, 'calc_'+typestr)(buf)
NameError: global name 'self' is not defined
alex@t60:~/weewx$

I also changed the names of some variables in dictionary and updated the table accordingly.

Can someone give me an advise about how to solve the error?

Regards
Alex

[mwall]

On Friday, April 24, 2015 at 1:54:54 PM UTC-4, Aleksandar Tsankov wrote:

Can someone give me an advise about how to solve the error?

you have defined parse_readings as a static method, but the call to getattrs at line 398 requires an object. 

a quick fix is to remove the @staticmethod from parse_readings, and change line 84 from Station.parse_readings to self.station.parse_readings

m

[Aleksandar Tsankov]

Thank you mwall!
I'll fix the code and will check it in Monday since Weather Station is in my work.
As a matter of fact, I've also changed a little wxservices.py and units.py - added some fields to the main dictionary, some to the dispatch_list and two subroutines in wxservices.py for windDir and windSpeed.

Well, I suppose it will not be accepted (at least changes in wxservices), but I'm just experimenting :).

BTW, I'm just thinking - is it possible to use GPS data for lat/lon/alt and dynamically update the static values from config file?

Regards
Alex

[mwall]

On Friday, April 24, 2015 at 3:27:49 PM UTC-4, Aleksandar Tsankov wrote:

Thank you mwall!
I'll fix the code and will check it in Monday since Weather Station is in my work.
As a matter of fact, I've also changed a little wxservices.py and units.py - added some fields to the main dictionary, some to the dispatch_list and two subroutines in wxservices.py for windDir and windSpeed.

Well, I suppose it will not be accepted (at least changes in wxservices), but I'm just experimenting :).

extending the units should be done in the driver module.

as for wxservices, it would be better to derive a new class from StdWXCalculate, override behavior, then use that derived class instead of StdWXCalculate.  you could put the new class in the driver module, then refer to that in the services list in weewx.conf.
 

BTW, I'm just thinking - is it possible to use GPS data for lat/lon/alt and dynamically update the static values from config file?

that is a problem with the existing structure of weewx - all of the weewx internals assume that the lat/lon/alt will never change.

however, i too need these to be dynamic (for some mobile weather stations and other mobile data collectors), so i'm keen to see them become mutable.

one approach would be to add a 'location' service.  this service would watch every packet for lat/lon/altitude observations, then update the stationinfo with new data if they exist.  the tedious part is to test the other parts of weewx to be sure lat/lon/alt are not cached.

m

[Thomas Keffer]

This is a reasonable request. I've opened up a ticket to discuss it. 

-tk

[Aleksandar Tsankov]

Hi,
I followed the mwall's advice and went back to original wxservices.py. The logic for deciding which windSpeed and windDir to be used is putted in the driver.
Now everything works as supposed.
Since I want to have some real-time application running on tablet, is it possible weewx to generate Weather Display's clientraw.txt file in order WDL (or something similar) to be used?
I'm attaching the new version of driver.

[Rob Fuller]

Thanks Aleksandar,

I needed to make a couple of small changes for it to work with our device (Airmar 200WX). Mostly:

1. use pyserial socket:// url, since we are exposing the weatherstation using ftdi driver and kplex

2. added some detail in the log messages

3. added some leniency on the checksum verification (" F" == "0F")

For the 200WX I'm still getting a couple of warnings, but haven't looked into it yet, and generally things seem ok. The warnings are:

weewx[11]: airmar: Wrong data format for windchill_rel ''

weewx[11]: airmar: Wrong data format for windchill ''

weewx[11]: airmar: Wrong data format for heatindex ''

I put the source on github for the moment here if someone is running with it:

https://github.com/fullergalway/weewx-airmar-150wx-driver

Thanks again,

Rob.

[Aleksandar Tsankov]

Hi Rob,
I'm glad that someone else has an interest about Airmar driver.
As a matter of fact I use a slightly updated driver version from a month (at least) without any hassle.
About warnings: they are generated in situations where there are no valid data in the Airmar sentences.
Initially I thought that the sentence won't be generated at all if there are no valid data in it but obviously it's not the case. Since these messages greatly rose log-file's size I decided to not throwing it in the last driver's version.
I saw your modification of validate_string() subroutine - obviously I missed condition with space in the beginning of the string instead of "0" - thank you.
However I cannot get the point of other changes you've made. May be I'm wrong but I think your version just throws error messages without returning an empty string in case of missmatched checksum or garbled message.

Nevermind, I'm very glad that someone (you, Rob) opened a github repository for the Airmar driver. Since I do not have enough time, I'll be thankful if you keep maintaining it.

And yes, one more thing to mention - since the idea for getting lat/lon/alt from devices which are capable to send them is already discussed (https://github.com/weewx/weewx/issues/32), it's probably time to add processing of GPS-related sentences in the driver.

I'm attaching the driver version with suppressed messages for "Wrong data format......."

[Calum Macintosh]

On Friday, 4 August 2017 14:59:55 UTC+1, Calum Macintosh wrote:

Hi Aleksandar,

Thank you for putting this driver together. I can confirm it works with Airmar120wx devices. To get it to work I had to change windSpeed_unfilt in the code to windSpeed  and windAngle_unflilt to windDir on lines 482 and 483. 

Many thanks,

Calum 

[Thomas Boström]

Hi all,

I am running the driver airmar version 028 connected  to an Airmar PB100 weather station with big success, thank you for a great driver.

But I can't see any Barometer values in the report. 

I am very thankful for all help to solve it.

Regards

Thomas

[Thomas Boström]

[Thomas Boström]

Hi all,

I am running the driver airmar version 028 connected  to an Airmar PB100 weather station with big success, thank you for a great driver.

But I can't see any Barometer values in the report. 

I am very thankful for all help to solve it.

Regards

Thomas

Den lördag 4 juli 2015 kl. 13:03:25 UTC+2 skrev Aleksandar Tsankov:

[Kurt Rosenberger]

Thomas et al

I'm very keen to get a data logger working for my AirmarPB200, and am curious how you folks are bringing the data in - via a USB adapter or via the RS-422? I'd really like to try this on a Raspberry Pi, but am thinking I'll need an RS-422 adapter. Also, since GPS provides time, maybe this would negate the need to add a RTC to the Pi? What do you think?

Thanks

Kurt

[Dennis Füß]

Hi Aleksandar,

I know it is a long time since you posted your driver, but I have to try.

First of all thank you for the driver.

I also try to integrate the airmar 150wx into weewx but have my difficulties, therefore I wanted to ask if I only have to integrate the driver ("airmar_0.28.py") in weewx or do I have to modifiy other files to get all data out of the 150wx?

For the moment I have the WX running and it gives me temperature, barometer, winddirection and rel. wind speed. But all the other data are missing.

Of course anyone else is invited to answer ;-)

Thank you in advance and best regards,

Dennis

P.S. I hope, that I didn't miss any information, if so, just let me know

[James Manning - NOAA Federal]

Hi Rob-

First, thanks MUCH for posting your "airmar.py" on github.

I am a very novice weewx user.  I just got the "simulator" working on my RaspberryPi and now I want to hook up my Arimar 200WX.

From what I understand,  I need to take two basic steps:

1) modify the weewx.conf to point to new station_type and set driver=weewx.drivers.airmar

2) put the "airmar.py" in my "user" directory which I think is /home/pi

Is that right?

-JiM.

[Rob Fuller]

Hi James,

I haven't looked at this for a while, but anyhow it was working okay. At Marine Institute we did something like this:

wget -O bin/weewx/drivers/airmar.py https://raw.githubusercontent.com/fullergalway/weewx-airmar-150wx-driver/master/airmar.py && chmod 755 bin/weewx/drivers/airmar.py

In the weewx conf we included these lines

[Station]

...

station_type = Airmar

[Airmar]
    model = Airmar 200WX
    port = socket://10.11.104.5:10000

    driver = weewx.drivers.airmar

I hope this helps!

Rob.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-development/q6IHzkmyhBo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/b9035cdf-fd4d-41b4-ab20-95c9535968ddo%40googlegroups.com.

[Dennis Füß]

Hi Rob,

maybe you can help me out since Aleksandar seems to be gone for a while.

I have an Airmar 150WX up and running but i doesn't seem to give me any values for windSpeed_true_vess. Or in other words I don't get the windspeed subtracted from the vessel's speed.

Do you have any idea, how to accomplish this?

Thank you and best regards in advance,

Dennis

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

[James Manning - NOAA Federal]

Hi Dennis-

I had a similar problem setting up a AirMAr 200Wx and I think I am a few days away from solving the issue.

I discovered today, for example, that I had to specify data['dewpoint']=None and data['outHumidity']=None since my unit was not reporting these.

You can see in Rob's code where he had specified data['longrain']=None.  There are a couple other little things that I will

document better if and when I get it all to work.

-JiM.

You received this message because you are subscribed to the Google Groups "weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/a35bd773-b6b8-4c2d-979d-22337bbcd127o%40googlegroups.com.

[Rob Fuller]

Hi Dennis,

The device we use is at a fixed position so it's not something I've looked at before.

Looking quickly at the code I see it does try to parse windAngle_true_vess and windSpeed_true_vess from the $WIVWT message. Does your device send that?

Otherwise I'm waiting to see what James Manning comes up with ;-)

Kind regards,

Rob.

To unsubscribe from this group and all its topics, send an email to weewx-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/a35bd773-b6b8-4c2d-979d-22337bbcd127o%40googlegroups.com.

[Dennis Füß]

Hi Jim and Rob,

first of all: thank you for your fast reply.

For the moment I have used windSpeed_rel_mwv but it turned out, that the data I'm getting is the windspeed without the subtracted vessel speed.

The main problem is, that I'm the "engineer" for the system but have no possibility to test it in person on the lake, where the vessel is located :-/

Maybe I explain my setup:

Airmar 150WX goes via NMEA 0183 cable to an RS422 to USB converter to a raspberry pi 3 running weewx. Weewx stores the data in an influxdb and grafana is showing them.

@Jim: thank you. But where have you specified the mentioned data? I mean in which configuration file?

@Rob: you asked if I would receive the values for windSpeed_true_vess etc. -> I tried to call it in grafana but it didn't show me data, so I guess I don't receive them. Or is there a way to see all received data/variables in terminal (probably a stupid question, but for the moment I don't know). When I open grafana it shows me the available data from its database, so I don't see any reason why available data shouldn't be stored in there, right?

So I hope, that I didn't forget anything and stay thrilled for Jim's findings ;-)

Thank you in advance and best regards,

Dennis

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/a35bd773-b6b8-4c2d-979d-22337bbcd127o%40googlegroups.com.

[Rob Fuller]

Hi Dennis,

One option to see the raw data in the terminal would be to put kplex between the usb and the weewx. Configure kplex to receive the messages from usb, and publish on a tcp server socket. Configure weewx to connect to that socket for messages.

Kplex will log to a file if you configure it so, or you can simply telnet to the kplex tcp port and see the raw messages. You're looking for $WIVWT messages.

http://www.stripydog.com/kplex/configuration.html

I hope this helps,

Rob.

To unsubscribe from this group and all its topics, send an email to weewx-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/ff51ce20-4659-405e-90b6-b981e671f096o%40googlegroups.com.

[denni...@web.de]

Hi Rob,

if I didn't get the technical manual for the wx unit wrong not all messages are enabled by default. So some messages have to be activated manually. Did anyone managed to do so? When I start minicom the sensor ist talking but never listening.

@James: how are you coming on with this topic?

Thank you and best regards,

Dennis

[denni...@web.de]

First of all thank you Jim and Rob for your patience ;-)

Second I'd like to ask, if someone (more python versed) can tell me how to divide two values in the airmar driver. In my specific case it would be the windSpeed_rel_mwv - SOG_kn. SOG_kn is an value I extracted from the message $GPVTD.

If I use data['windSpeed_true'] = data['windSpeed_rel_mwv']-data['SOG_kn'] I get an error. So can anyone tell me, where my mistake is?

What I have learned, it is not the exact or 100% right way to calculate "true wind" but I think I would be close enough ;-)

Thank you in advance and best regards,

Dennis

[denni...@web.de]

Edit: I ment subtract not divide...sorry about that

[james....@noaa.gov]

I wonder if your values are strings rather than floating point numbers?

If so, then you would need:

data['windSpeed_true'] = str(float(data['windSpeed_rel_mwv'])-float(data['SOG_kn']) ) 

I had to run my version of "airmar.py" independent of WeeWx in order to more easily debug.

When I was satisfied with my tests, then I went back to WeeWx.

I had my driver working for awhile but then had some trouble related, I think, to the RaspberryPi not having a good clock.

After I get a real clock and get things going again, I will document my driver development for Airmar 200Wx modified from Rob's.

-JiM.

[james....@noaa.gov]

by the way,  are you the same Dennis that works with Cooper in Denmark?

[denni...@web.de]

Hi Jim,

thank you for your answer. I'll try it with the "string methode". Before I tried to adapt the lines at the bottom of the aleksander's (the original) driver version:

            if 'windSpeed_mwd' in data and data['windSpeed_mwd'] is not None:
                data['windSpeed'] = data['windSpeed_mwd']
            elif 'windSpeed_mda' in data and data['windSpeed_mda'] is not None:
                data['windSpeed'] = data['windSpeed_mda']

With my above added dictonary entry "SOG_kn":

                try:
                    data['COG_degTrue'] = float(buf[1])
                    data['COG_degMag'] = float(buf[3])
                    data['SOG_kn'] = float(buf[5])
                    data['SOG_kmh'] = float(buf[7])
                except (ValueError):
                    pass
                    loginf("Wrong data format '%s, %s, %s, %s'" % (buf[1], buf[3], buf[5], buf[7]))

But weewx always complains about KeyError: 'SOG_kn'. After some google-sessions I found out, that this is python typical, if there is no dictonary entry for SOG_kn...which is fine, as long as I am testing on the desk with no GPS signal, but outside with values for SOG_kn (even displayable in grafana) I'm still receiving this error.

And, I'm afraid, that I am not the Dennis who works with Cooper in Denmark ;-)

I'm here in Munich, Germany ;-)

[WeewxUser]

Hi!

I'm using weewx with a airmar 150LB, which I found in a bin (about to be thrown out) at my previous employer. It has a broken humidity sensor, so in effect it operates like a 200 WX.

I updated the driver script to handle the case where the humidity and temperature is missing, but also I have a separate python script pulling in humidity and temperature from a cheap DHT22. So I updated the WIMDA message handling to parse messages where not all of the message is complete, so it only pulls out values which are available. I've attached the updated driver.

I'm using kplex to allow multiple inputs NMEA2000 inputs into weewx. Here's my kplex configuration;

[serial]
filename=/dev/ttyAMA0
direction=both
baud=4800
checksum=no
strict=no

[tcp]
mode=server
port=10111
direction=in
checksum=no
strict=no

[tcp]
mode=server
port=10110
direction=out

Here's the relevant section of the weewx config;

[Airmar]
    # This section is for the Airmar series of weather stations.
    #
    # Serial port such as /dev/ttyS0, /dev/ttyUSB0, or /dev/cuaU0
    port = socket://localhost:10110
    
    # The station model, e.g., Airmar 150WX
    model = Airmar
    
    # The driver to use:
    driver = weewx.drivers.airmar

I might see if I can update my version of weewx, and if the driver's still working, make a pull request to include the driver in the weewx package.

[WeewxUser]

FYI; I've cleaned the code up (with some of the issues that pycharm indicated) and created a pull request for it to be merged into the development branch.

https://github.com/weewx/weewx/pull/670