Author Topic: Software Defined Radio with the WS-2902A  (Read 14295 times)

0 Members and 1 Guest are viewing this topic.

Offline GHammer

  • Senior Contributor
  • ****
  • Posts: 210
    • Woodmar Weather
Re: Software Defined Radio with the WS-2902A
« Reply #25 on: February 06, 2019, 11:49:50 PM »
Is this a Raspberry Pi?  It doesn't look like Weewx specifically.  Hmmmmm...

Let's see how this seems to affect things.
No a 'normal' Linux server.
It's the weewx_sdr driver, only get the log when I run it directly or when weewx starts which would load the driver.
Plus, it's referring to USB.
Wireless Vantage Pro2 Plus with 24hr FARS, WLL

Offline StephenR0

  • Senior Member
  • **
  • Posts: 83
Re: Software Defined Radio with the WS-2902A
« Reply #26 on: February 14, 2019, 01:32:12 PM »
I should also mention that under rare circumstances rtl_433 doesn't return a value for light_lux.  This results in Packet.get_float(obj, 'light_lux') not being a float.  This causes the conversion to watts per square meter to fail and weewx dies.  This is in sdr.py in the weewx-sdr driver.  I'm testing a fix for this, but since it occurs so rarely, I won't be confident of it for a couple of weeks at least.

There's been some movement on this problem.  First, the weewx-sdr author made a change to the code that I suggested for the WH65B section.  The WH65B returns a light value in lux.  The WS-2902A console then converts that value to W/M^2 which is a radiation value.  I had chosen to do this conversion in the weewx-sdr driver.  He rightly determined that the driver should return the light value in lux and weewx should do any required conversions.

Technically, there is no way to convert from light in lux to radiation in W/M^2.  But since the console does this, we need to get this to happen in weewx.  Fine Offset has said that the conversion is

radiation(W/m2) = light(lux) / 126

But using that didn't agree with what the console was reading.  Another common formula is

radiation(W/m2) = light(lux) * 0.0079

But that didn't quite agree with the console either.  So, after some calculation I empirically determined that formula to be

radiation(W/m2) = light(lux) * 0.007893

This closely agrees with what my console shows.

So, to get the current weewx-sdr driver to work with weewx, a couple of changes need to made to weewx.conf.  Here is the relevant portions of my weewx.conf.

Code: [Select]
[SDR]
    # This section is for the software-defined radio driver.

    # The driver to use
    driver = user.sdr
    path = /usr/local/bin
    cmd = rtl_433 -q -U -F json -p 39.741 -R 78 -f 914980000
    [[sensor_map]]
        outTemp = temperature.89.FOWH65BPacket
        outHumidity = humidity.89.FOWH65BPacket
        windDir = wind_dir.89.FOWH65BPacket
        windSpeed = wind_speed.89.FOWH65BPacket
        windGust = wind_gust.89.FOWH65BPacket
        rain_total = rain_total.89.FOWH65BPacket
        # uv.89.FOWH65BPacket
        UV = uv_index.89.FOWH65BPacket
        light = light.89.FOWH65BPacket
        outTempBatteryStatus = battery.89.FOWH65BPacket
        inTemp = temperature.21.FOWH25Packet
        inHumidity = humidity.21.FOWH25Packet
        pressure = pressure.21.FOWH25Packet
        inTempBatteryStatus = battery.21.FOWH25Packet
    [[deltas]]
        rain = rain_total

[StdCalibrate]

    [[Corrections]]
        # For each type, an arbitrary calibration expression can be given.
        # It should be in the units defined in the StdConvert section.
        # Example:
        foo = foo + 0.2
        radiation = light * 0.007893 if light is not None else None

There are two changes.  The first one is to assign light.89.FOWH65BPacket to light instead of radiation.  As before, the "89" is my ID.  Yours will be different.  The second change is to calculate radiation from light in the [StdCalibrate] portion of weewx.conf.  There's also a check to make sure that light does actually have a value.  This is necessary because the WH65B occasionally doesn't return a value for light.  Again, these changes require the latest version of sdr.py in the weewx-sdr driver.  I'm running this configuration so I should see any problems with it.  But I don't anticipate any at this point.

Offline galfert

  • Global Moderator
  • Forecaster
  • *****
  • Posts: 6822
Re: Software Defined Radio with the WS-2902A
« Reply #27 on: February 14, 2019, 08:49:09 PM »
Ambient's formula to convert from Lux to W/m^2 is to divide by 126.7.

Or you can also multiply by 0.007892659826361483820047355959 but it would be more accurate and simpler to just divide by 126.7.

Reference:
https://ambientweather.net/help/why-is-the-lux-to-w-m-2-conversion-factor-126-7/

PS - just showing off but I could have given you that long decimal number to even more significant digits than the 30 I gave you. But you gotta stop somewhere.

You can also see this in the Ambient ObserverIP Calibration screen.  And also on the WS-2000.

 [ You are not allowed to view attachments ]
 [ You are not allowed to view attachments ]
« Last Edit: February 14, 2019, 09:17:04 PM by galfert »
Ecowitt GW1000 | Meteobridge on Raspberry Pi
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Windy: pws-f075acbe
Weather Underground Issue Tracking
Tele-Pole

Offline GHammer

  • Senior Contributor
  • ****
  • Posts: 210
    • Woodmar Weather
Re: Software Defined Radio with the WS-2902A
« Reply #28 on: February 15, 2019, 06:16:13 PM »
I should also mention that under rare circumstances rtl_433 doesn't return a value for light_lux.  This results in Packet.get_float(obj, 'light_lux') not being a float.  This causes the conversion to watts per square meter to fail and weewx dies.  This is in sdr.py in the weewx-sdr driver.  I'm testing a fix for this, but since it occurs so rarely, I won't be confident of it for a couple of weeks at least.

There's been some movement on this problem.  First, the weewx-sdr author made a change to the code that I suggested for the WH65B section.  The WH65B returns a light value in lux.  The WS-2902A console then converts that value to W/M^2 which is a radiation value.  I had chosen to do this conversion in the weewx-sdr driver.  He rightly determined that the driver should return the light value in lux and weewx should do any required conversions.

Technically, there is no way to convert from light in lux to radiation in W/M^2.  But since the console does this, we need to get this to happen in weewx.  Fine Offset has said that the conversion is

radiation(W/m2) = light(lux) / 126

But using that didn't agree with what the console was reading.  Another common formula is

radiation(W/m2) = light(lux) * 0.0079

But that didn't quite agree with the console either.  So, after some calculation I empirically determined that formula to be

radiation(W/m2) = light(lux) * 0.007893

This closely agrees with what my console shows.

So, to get the current weewx-sdr driver to work with weewx, a couple of changes need to made to weewx.conf.  Here is the relevant portions of my weewx.conf.

Code: [Select]
[SDR]
    # This section is for the software-defined radio driver.

    # The driver to use
    driver = user.sdr
    path = /usr/local/bin
    cmd = rtl_433 -q -U -F json -p 39.741 -R 78 -f 914980000
    [[sensor_map]]
        outTemp = temperature.89.FOWH65BPacket
        outHumidity = humidity.89.FOWH65BPacket
        windDir = wind_dir.89.FOWH65BPacket
        windSpeed = wind_speed.89.FOWH65BPacket
        windGust = wind_gust.89.FOWH65BPacket
        rain_total = rain_total.89.FOWH65BPacket
        # uv.89.FOWH65BPacket
        UV = uv_index.89.FOWH65BPacket
        light = light.89.FOWH65BPacket
        outTempBatteryStatus = battery.89.FOWH65BPacket
        inTemp = temperature.21.FOWH25Packet
        inHumidity = humidity.21.FOWH25Packet
        pressure = pressure.21.FOWH25Packet
        inTempBatteryStatus = battery.21.FOWH25Packet
    [[deltas]]
        rain = rain_total

[StdCalibrate]

    [[Corrections]]
        # For each type, an arbitrary calibration expression can be given.
        # It should be in the units defined in the StdConvert section.
        # Example:
        foo = foo + 0.2
        radiation = light * 0.007893 if light is not None else None

There are two changes.  The first one is to assign light.89.FOWH65BPacket to light instead of radiation.  As before, the "89" is my ID.  Yours will be different.  The second change is to calculate radiation from light in the [StdCalibrate] portion of weewx.conf.  There's also a check to make sure that light does actually have a value.  This is necessary because the WH65B occasionally doesn't return a value for light.  Again, these changes require the latest version of sdr.py in the weewx-sdr driver.  I'm running this configuration so I should see any problems with it.  But I don't anticipate any at this point.

I have made the edits, installed weewx-sdr 0.58.
Once the Sun comes up, I'll have a better idea how things match up.
Thanks for the update and for staying with the infrequent crash. Which, BTW, I never experienced.
Wireless Vantage Pro2 Plus with 24hr FARS, WLL

Offline Stenella

  • Member
  • *
  • Posts: 2
Re: Software Defined Radio with the WS-2902A
« Reply #29 on: February 16, 2019, 04:49:46 PM »
I want to thank everyone who put in the time to get this decoded. It's insane how much effort is needed to read the data a sensor I paid money for, sitting on my roof is transmitting.

We're working on decoding the WH32B and getting that added to rtl_433. I pushed an update to weewx-sdr last week to parse the output from theWH31E sensor, will do the same once WH32 is done :D

I'm working on a Docker package containing everything needed to read these sensors using an OrangePi and SDR dongle,then dump that data to mysql.

 

Offline Mountbaldy

  • Member
  • *
  • Posts: 2
Re: Software Defined Radio with the WS-2902A
« Reply #30 on: February 26, 2019, 04:35:25 PM »
This is awesome!  I'm so happy I joined the wxforum.  I work at a school in the IT department.  I had the district purchase an Observer IP and a WH65B station to go with it.  We set the thing up and had intermittent signal.  The folks at Ambient sent us a new WH65B.  We had the Observer IP drop connection periodically to the Outdoor array.  It was a giant PITA.  Long story short, after we moved the location of the station and the observer ip the new one works great.  Now I'm left with a spare WH65B....

I just bid on a wireless receiver dongle and I have multiple RPI's laying around.  I think I just found my next home project!

Are their any good WIki's out there on setting up these things?  Do you have any advice for a NOOB like me? 

Thanks!

Offline StephenR0

  • Senior Member
  • **
  • Posts: 83
Re: Software Defined Radio with the WS-2902A
« Reply #31 on: February 26, 2019, 05:13:03 PM »
I know of no wiki that describes every step setting this up.  This thread is about the only thing there is, I think.  You sound like you're already familiar with the Raspberry Pi.  The second link in the first post is good for specific hardware configuration.  Other than that, take it one step at a time and I'm sure you'll be fine.  :-)

Offline CW2274

  • Forecaster
  • *****
  • Posts: 6731
    • Conditions @ CW2274 West Tucson-Painted Hills Ranch
Re: Software Defined Radio with the WS-2902A
« Reply #32 on: February 26, 2019, 05:37:05 PM »
Are their any good WIki's out there on setting up these things?  Do you have any advice for a NOOB like me? 
https://www.weather.gov/media/epz/mesonet/CWOP-Siting.pdf

Offline Mountbaldy

  • Member
  • *
  • Posts: 2
Re: Software Defined Radio with the WS-2902A
« Reply #33 on: February 26, 2019, 08:25:04 PM »
Thanks for the advice!  I'll check things out. This site is great!

Offline steepleian

  • Senior Member
  • **
  • Posts: 53
    • The Claydons Community Weather
Re: Software Defined Radio with the WS-2902A
« Reply #34 on: March 17, 2019, 04:15:11 AM »
I want to thank everyone who put in the time to get this decoded. It's insane how much effort is needed to read the data a sensor I paid money for, sitting on my roof is transmitting.

We're working on decoding the WH32B and getting that added to rtl_433. I pushed an update to weewx-sdr last week to parse the output from theWH31E sensor, will do the same once WH32 is done :D

I'm working on a Docker package containing everything needed to read these sensors using an OrangePi and SDR dongle,then dump that data to mysql.

Any news on how the WH32B is progressing?

Thanks,
Ian

Offline RdRocket16

  • Member
  • *
  • Posts: 16
Re: Software Defined Radio with the WS-2902A
« Reply #35 on: March 24, 2019, 06:22:05 PM »
Hey,
Im trying to get my WS2902 to parse into the Weewx, and i think i have almost everything working, except w/m^2. Shows I have 16k during the day, which should be 130.
I have in my weewx.conf

radiation = light.10.FOW65HPacket

and in StdConvert

radiation = lights/127.6

but its not doing anything.
am I missing something?

Offline StephenR0

  • Senior Member
  • **
  • Posts: 83
Re: Software Defined Radio with the WS-2902A
« Reply #36 on: March 24, 2019, 06:38:57 PM »
Yes.  It should be

light = light.10.FOW65HPacket

and in StdConvert

radiation = light/127.6

Notice I took out the 's' in 'lights'.

Read this post carefully.

https://www.wxforum.net/index.php?topic=35494.msg370885#msg370885

I don't really care what conversion you use.  But you really should put in the check for no value.

radiation = light * 0.007893 if light is not None else None
« Last Edit: March 24, 2019, 06:41:27 PM by StephenR0 »

Offline galfert

  • Global Moderator
  • Forecaster
  • *****
  • Posts: 6822
Re: Software Defined Radio with the WS-2902A
« Reply #37 on: March 24, 2019, 06:55:58 PM »
um...both of you have made a typo.  The conversion factor is 126.7 not 127.6.
Ecowitt GW1000 | Meteobridge on Raspberry Pi
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Windy: pws-f075acbe
Weather Underground Issue Tracking
Tele-Pole

Offline StephenR0

  • Senior Member
  • **
  • Posts: 83
Re: Software Defined Radio with the WS-2902A
« Reply #38 on: March 24, 2019, 07:54:04 PM »
I was just replying to his post.  My position is that he can use whatever conversion factor that he wants.

Offline RdRocket16

  • Member
  • *
  • Posts: 16
Re: Software Defined Radio with the WS-2902A
« Reply #39 on: March 24, 2019, 10:56:35 PM »
Got it! Thanks. I had radiation = light.10...
But I needed light = Light.10 then radiation = light / 126.7
I'll add the if else too.

Offline bthoven

  • Senior Member
  • **
  • Posts: 91
    • Europa Cafe' Private Observatory
Re: Software Defined Radio with the WS-2902A
« Reply #40 on: April 04, 2019, 02:36:55 AM »
Hi,

Just come across this post with excitement. Now I'm running weewx server on my Androidtv-turned-to-ubuntu box.

I have outdoor sensor WH24 and indoor WH25 transmitting at 433Mhz. The weather station brand is Misol which are physically same as Ambient Weather Observer IP model WS-1401-IP .


I'm not sure this implementation will potentially work with my hardware? I intend to create another weewx server (ubuntu based) to read live data from the same sensors, without interrupting my other live weewx server.

Thank you.
« Last Edit: April 04, 2019, 03:31:25 AM by bthoven »

Offline StephenR0

  • Senior Member
  • **
  • Posts: 83
Re: Software Defined Radio with the WS-2902A
« Reply #41 on: April 04, 2019, 10:43:46 AM »
Welcome to the world of software defined radio.  :-)  Everything starts with rtl_433.  If your hardware is supported in rtl_433, you can take the other steps and get weewx_sdr to feed that data to weewx.  From there you can customize things to your heart's content.

The good news is that your hardware should be supported.  I only have experience with the WH25 and at a different frequency.  But I expect that should work.  I think the WH24 should work too, but there are a couple of things that you should be aware of about that.  The first is described in this issue.

https://github.com/merbanan/rtl_433/issues/844

I would call your attention to the part where we had conflicting information about the wind speed factor for the WH24.  I have a WH65B, so I was able to verify the wind speed factor for my hardware.  But the gentleman that had the WH24 couldn't do that because he didn't have a console to compare it with.  He just had the WH24.  So, from the two emails that we managed to get from Fine Offset, the first had a windspeed factor of 1.12 and the one that I got said the wind speed factor was 1.19.  I think that rtl_433 still uses 1.12 because we couldn't verify it further.  On the other hand, you will be in a position to derive the correct value if you go forward with your project.  At that point, you can determine if rtl_433 needs to be changed.

The second is described in this interesting post.

http://www.wxforum.net/index.php?PHPSESSID=4b85ccb2b5db5d854f6c78beee1f62d7&topic=28713.msg278935#msg278935

This is mostly for your information.  When you're reading data from the WH24 with an sdr, it's good to be aware of what the WH24 is actually sending.  I think this is related to the wind speed factor issue as well.

So, the first step is to acquire an sdr dongle and experiment with rtl_433 to see your hardware's data.  Rtl_433 has several parameters to control it that you will need to customize for your situation.  You will need -R 78 to select the protocol for your hardware.  In addition, you will need to account for frequency offset that your dongle might have.  This is mostly an issue for the cheap dongles.  The more expensive ones have a crystal that accounts for temperature.  Also, you should read about the current parameters of rtl_433.  Rtl_433 is under active development and does change some.  In particular, my previously posted examples aren't necessarily current anymore.  I'm planning on updating my installation, but I haven't done that yet.

So, have fun.  It's not terribly expensive to do this.  And as you've pointed out, it won't interfere with your other hardware.

Offline bthoven

  • Senior Member
  • **
  • Posts: 91
    • Europa Cafe' Private Observatory
Re: Software Defined Radio with the WS-2902A
« Reply #42 on: April 04, 2019, 11:56:07 AM »
Thanks. I’ve just placed an order for the rtl-sdr at ebay. As I already have ObserverIP working with my live weewx server, I will have reference reading values to compare with. I’ll report back here as soon as I get the dongle and install both software.

Thank you.

Offline steepleian

  • Senior Member
  • **
  • Posts: 53
    • The Claydons Community Weather
Re: Software Defined Radio with the WS-2902A
« Reply #43 on: April 07, 2019, 06:09:16 PM »
I want to thank everyone who put in the time to get this decoded. It's insane how much effort is needed to read the data a sensor I paid money for, sitting on my roof is transmitting.

We're working on decoding the WH32B and getting that added to rtl_433. I pushed an update to weewx-sdr last week to parse the output from theWH31E sensor, will do the same once WH32 is done :D

I'm working on a Docker package containing everything needed to read these sensors using an OrangePi and SDR dongle,then dump that data to mysql.

WH32B has been added to the The -R 78 switch and released today. Have upgraded RTL_433 and can now see the WH32B data streams from the command line. However have been unable to map the sensors to the WeeWX SDR driver correctly. Has anybody else been successful as yet?

Offline StephenR0

  • Senior Member
  • **
  • Posts: 83
Re: Software Defined Radio with the WS-2902A
« Reply #44 on: April 07, 2019, 07:25:04 PM »
Of course, I don't have a WH32 so I might not be very much help.  :-)  But I would have expected it to return pretty much the same data that WH25 does.  What do you get when you run the weewx-sdr driver directly?

From   https://github.com/matthewwall/weewx-sdr

===============================================================================
How to run the driver directly

Run the driver directly for testing and diagnostics.  For example, if weewx
was installed using setup.py:

cd /home/weewx
sudo PYTHONPATH=bin python bin/user/sdr.py --help

If weewx was installed from deb or rpm:

sudo PYTHONPATH=/usr/share/weewx python /usr/share/weewx/user/sdr.py --help

===============================================================================

You might have to add your rtl_433 command with the --cmd switch.
« Last Edit: April 07, 2019, 07:28:12 PM by StephenR0 »

Offline steepleian

  • Senior Member
  • **
  • Posts: 53
    • The Claydons Community Weather
Re: Software Defined Radio with the WS-2902A
« Reply #45 on: April 07, 2019, 07:39:30 PM »
Of course, I don't have a WH32 so I might not be very much help.  :-)  But I would have expected it to return pretty much the same data that WH25 does.  What do you get when you run the weewx-sdr driver directly?

From   https://github.com/matthewwall/weewx-sdr

===============================================================================
How to run the driver directly

Run the driver directly for testing and diagnostics.  For example, if weewx
was installed using setup.py:

cd /home/weewx
sudo PYTHONPATH=bin python bin/user/sdr.py --help

If weewx was installed from deb or rpm:

sudo PYTHONPATH=/usr/share/weewx python /usr/share/weewx/user/sdr.py --help

===============================================================================

You might have to add your rtl_433 command with the --cmd switch.

time      : 2019-04-08 00:38:02
model     : Fineoffset-WH32B                       ID        : 146
Temperature: 17.5 C      Humidity  : 60 %          Pressure  : 1001.1 hPa    Battery   : OK            Integrity : CHECKSUM

Offline steepleian

  • Senior Member
  • **
  • Posts: 53
    • The Claydons Community Weather
Re: Software Defined Radio with the WS-2902A
« Reply #46 on: April 07, 2019, 08:08:05 PM »
This is the parser that I created 9Based on WH65B)

class FOWH32BPacket(Packet):
    # time      : 2019-04-08 00:48:02
   # model     : Fineoffset-WH32B                       
    # ID        : 146
    # Temperature: 17.5 C     
    # Humidity  : 60 %         
    # Pressure  : 1001.2 hPa   
    # Battery   : OK           
    # Integrity : CHECKSUM
_

    # This is for a WH32B which is the indoors sensor array for an Ambient Weather
    # WS-2902A. The same sensor array is used for several models.

   
    IDENTIFIER = "Fineoffset-WH32B"

    @staticmethod
    def parse_json(obj):
        pkt = dict()
        pkt['dateTime'] = Packet.parse_time(obj.get('time'))
        pkt['usUnits'] = weewx.METRIC
        pkt['station_id'] = obj.get('id')
        pkt['temperature'] = Packet.get_float(obj, 'temperature_C')
        pkt['humidity'] = Packet.get_float(obj, 'humidity')
        pkt['pressure'] = Packet.get_float(obj, 'pressure_hPa')
        pkt['battery'] = 0 if obj.get('battery') == 'OK' else 1
        return FOWH32BPacket.insert_ids(pkt)
     
     

    @staticmethod
    def insert_ids(pkt):
        station_id = pkt.pop('station_id', '0000')
        pkt = Packet.add_identifiers(pkt, station_id, FOWH32BPacket.__name__)
        return pkt
     
   

Offline StephenR0

  • Senior Member
  • **
  • Posts: 83
Re: Software Defined Radio with the WS-2902A
« Reply #47 on: April 07, 2019, 08:09:31 PM »
I'm not sure what you're running to get that output.  Here's what I get:

root@pi1:/home/weewx# PYTHONPATH=bin python bin/user/sdr.py --action=show-packets --cmd="rtl_433 -q -U -F json -p 39.741 -R 78 -f 914980000"
out: ['{"time" : "2019-04-08 00:03:23", "model" : "Fine Offset Electronics, WH25", "id" : 21, "temperature_C" : 21.400, "humidity" : 42, "pressure_hPa" : 979.900, "battery" : "OK", "mic" : "CHECKSUM"}\n']
parsed: {'battery.21.FOWH25Packet': 0, 'humidity.21.FOWH25Packet': 42.0, 'temperature.21.FOWH25Packet': 21.4, 'dateTime': 1554681803, 'pressure.21.FOWH25Packet': 979.9, 'usUnits': 16}

From that you can see in the parsed output what needs to be included in the [SDR] portion of weewx.conf.  These are the values that need to be assigned to database values in weewx.  That's the purpose of the [SDR] portion of weewx.conf.  Can you run the weewx-sdr driver directly in a similar manner to my command above and show the output?

Offline StephenR0

  • Senior Member
  • **
  • Posts: 83
Re: Software Defined Radio with the WS-2902A
« Reply #48 on: April 07, 2019, 08:12:19 PM »
Ahh.  The light finally dawned.  You're writing the sdr driver.  :-)  Sorry, I was obviously confused.  Let me look at your code.

Edit: Did you basically clone the code for the WH25?  If so, that should work, I would think.  In addition, there's a big list toward the end of file that needs to have your added entry listed.  When you find it it should be obvious.

Further edit: I see you're getting help from the author of the weewx-sdr driver.  You're in good hands.  :-)
« Last Edit: April 07, 2019, 08:18:43 PM by StephenR0 »

Offline steepleian

  • Senior Member
  • **
  • Posts: 53
    • The Claydons Community Weather
Re: Software Defined Radio with the WS-2902A
« Reply #49 on: April 07, 2019, 09:05:18 PM »
Ahh.  The light finally dawned.  You're writing the sdr driver.  :-)  Sorry, I was obviously confused.  Let me look at your code.

Edit: Did you basically clone the code for the WH25?  If so, that should work, I would think.  In addition, there's a big list toward the end of file that needs to have your added entry listed.  When you find it it should be obvious.

Further edit: I see you're getting help from the author of the weewx-sdr driver.  You're in good hands.  :-)

I had actually managed to work it out before the author got back to me. I used the WH65B parser as a starting point as that is the basis of the outdoor sensors for my model. And yes I had discovered the long 'factory' list at the end.

In fact I am feeling rather pleased with myself - its not often that I get to a solution so quickly. It was worth staying up until 2am!

 

anything