Topic: Using add-on WH31 as "sensor of record" for outdoor temp/humidity

[gbru316]

I'd like to use a WH31 for outdoor temp/humidity/pressure.

Problem is, the add-on sensor is listed as "extra sensors" in both CumulusMX and WeeWx and isn't used for plots.


Has anyone had success doing something like this? I imagine it's just a matter of changing a variable from "outdoor temp sensor" (or something similar) to "extratemp1" (or similar), but where does this change need to take place? (in either Cumulus or Weewx, haven't settled on a program  yet).

[mcrossley]

Currently you cannot remap the GW1000 sensors in Cumulus MX - you can for other stations like the Davis WLL, so it is something to consider adding.

[Mandrake]

Are we talking here about one of the 8 additional Internal sensors or the single dedicated external sensor that can be purchased to replace the measuring of the outside temperature/humidity instead of the all in one.

This External sensor is automatically detected by the GW1000 or consoles and trumps the data from the all-in ones.

[galfert]

gbru316,
Last we spoke a few days ago I suggested the GW1002 station to you that comes with the WH32. Seems like you were receptive to this recommendation. Cumulus MX and WeeWX (and any other software/site) will see the WH32 as the GW1000 main outdoor sensor. You won't have to do any remapping. The GW1000 automatically uses the WH32 to report outdoor temperature/humidity. Any software or service you upload data to via GW1000 does not care about the particulars of where the GW1000 got the data, as it could be a WH32 or a WS80 or a WH65 for outdoor temperature/humidity sensor.

Also the WH32 does not have barometric sensor. The barometric pressure comes from the GW1000 itself. Set up the GW1000 with any compatible sensors and Cumulus MX or WeeWX or Meteobridge or Weather-Display will use them without you needing to go through much effort other than to select the GW1000 as your console.

The GW1000 can accommodate additional sensors as extra sensors. But that is not accomplished via WH32. As you can only have one WH32. Additional temperature/humidity sensors are accomplished by getting WH31 sensors (up to 8 of them). You can put these WH31 sensors anywhere you'd like, but a WH31 can never be the main outdoor sensor. I find no need for any software to allow you to do this. If you want to report main outdoor temperature/humidity then just do it with a WH32, or WS80 or WH65. If you have a WH65 and add a WH32 (or WS80) then it will take precedence over the WH65. WH32 trumps WS80 also.

The WH31 has dip switches to select a channel 1 - 8.
The WH32 does not have dip switches. It transmits as its own separate ID to the console.

[gbru316]

gbru316,
Last we spoke a few days ago I suggested the GW1002 station to you that comes with the WH32. Seems like you were receptive to this recommendation. Cumulus MX and WeeWX (and any other software/site) will see the WH32 as the GW1000 main outdoor sensor. You won't have to do any remapping. The GW1000 automatically uses the WH32 to report outdoor temperature/humidity. Any software or service you upload data to via GW1000 does not care about the particulars of where the GW1000 got the data, as it could be a WH32 or a WS80 or a WH65 for outdoor temperature/humidity sensor.

Also the WH32 does not have barometric sensor. The barometric pressure comes from the GW1000 itself. Set up the GW1000 with any compatible sensors and Cumulus MX or WeeWX or Meteobridge or Weather-Display will use them without you needing to go through much effort other than to select the GW1000 as your console.

The GW1000 can accommodate additional sensors as extra sensors. But that is not accomplished via WH32. As you can only have one WH32. Additional temperature/humidity sensors are accomplished by getting WH31 sensors (up to 8 of them). You can put these WH31 sensors anywhere you'd like, but a WH31 can never be the main outdoor sensor. I find no need for any software to allow you to do this. If you want to report main outdoor temperature/humidity then just do it with a WH32, or WS80 or WH65. If you have a WH65 and add a WH32 (or WS80) then it will take precedence over the WH65. WH32 trumps WS80 also.

The WH31 has dip switches to select a channel 1 - 8.
The WH32 does not have dip switches. It transmits as its own separate ID to the console.

I ended up purchasing a GW1004 (GW-1000 + WH31), as the GW-1002 was out of stock on Amazon (I'll add the WS68 later).

Both Cumulus and WeeWx detect the WH31, but it's listed as an extra sensor (although I have no additional sensors). I suppose I could purchase a WH32, but  I think I can modify the Weewx interceptor driver to remap this sensor instead. To be clear, I'm not looking for added functionality on either software suite. I'm comfortable enough with the back end of things to modify a script or two as needed to do what I want. Just wasn't sure if anyone's ever done it before.

[galfert]

Well that would be a hack. And you are still left without proper outdoor temperature/humidity for any of the services that the GW1000 can upload to itself like Ecowitt.net and others. Also although you may be able to manipulate open source software, you won't be able to take advantage or other software such as Meteobridge or Weather-Display.

Just get the WH32 so that you won't have to fiddle as software updates come out, allow the GW1000 to upload to Ecowitt.net properly, and you can then also have more software choices.

[gbru316]

Well that would be a hack. And you are still left without proper outdoor temperature/humidity for any of the services that the GW1000 can upload to itself like Ecowitt.net and others.

Yep. I'll be using Cumulus (well, probably WeeWx now) to handle all 3rd party integrations (wunderground, CWOP/APRS, etc). If I can change this at the driver level (for WeeWx, not nearly so easy to do on Windows software), there should be no impact to those services as the data will be read into WeeWx already modified.

Of course purchasing a WH32 would be the easy route, but where's the fun in that? 

[galfert]

Well the title of this thread and OP is to use the WH32 as a main outdoor sensor and that the GW1000 sees WH32 as an extra sensor (which is incorrect). My response was to correct the OP, and to properly point out that the GW1000 and any software getting data from the GW1000 already handles the WH32 properly.

You have a GW1004 kit and that is not a complete weather station. What you are looking to do in remapping the WH31 has nothing to do with the original post.

EDIT: oh okay, now you moved the goal post and renamed the thread    I get it now you just got confused by thinking your WH31 was a WH32 or something.

[gbru316]

Well the title of this thread and OP is to use the WH32 as a main outdoor sensor and that the GW1000 sees WH32 as an extra sensor (which is incorrect). My response was to correct the OP, and to properly point out that the GW1000 and any software getting data from the GW1000 already handles the WH32 perperly.

You have a GW1004 kit and that is not a complete weather station. What you are looking to do in remapping the WH31 has nothing to do with the original post.

I am the OP, corrected the title to reflect my error.

[wardie]

I use the Weewx GW1000 API driver mode and have re-purposed one of my internal multi-channel WH31 sensors for main outdoor temp/humidity use temporarily (whilst I await return of WS80). Very simple once I'd figured out I needed to use the [[field_map_extensions]] and get the correct field names from the driver output. My HP2551 console I just heave hard-wired into internal temp/humidity channel 3 for the time being at least to see it on the display. Best quick solution. weewx.conf:

Code: [Select]

[GW1000]
    driver = user.gw1000
    # temporary mappings for internal sensor channel 3 to outside
    [[field_map_extensions]]
        outTemp = temp3
        outHumidity = humid3


[Gyvate]

I use the Weewx GW1000 API driver mode and have re-purposed one of my internal multi-channel WH31 sensors for main outdoor temp/humidity use temporarily (whilst I await return of WS80). Very simple once I'd figured out I needed to use the [[field_map_extensions]] and get the correct field names from the driver output. My HP2551 console I just heave hard-wired into internal temp/humidity channel 3 for the time being at least to see it on the display. Best quick solution. weewx.conf:

Code: [Select]

[GW1000]
    driver = user.gw1000
    # temporary mappings for internal sensor channel 3 to outside
    [[field_map_extensions]]
        outTemp = temp3
        outHumidity = humid3


In fact there are three (+/- fast and easy) ways how to re-map a WH31 to be the feeder of the outdoor temperature/humidity in weewx.
One of them wardie described above by using a field map.

If you don't want to send these data out to other weather networks and want to have it just for yourself, you only need to change the label of the database field holding your WH31 value.
Then this would show in the pictures of the skin (day,week,month,year), the current conditions and the hi/low portions of the display. There are many ways ....
Also how to arrange the sequence of the pictures or the sequence of the sensors in the current condition and/or hi/lo panes.

(weewx.conf: [StdReport] ... [[Defaults]] ... [[[Labels]]] ....[[[[Generic]]]] .... extraTemp1 = Outdoor Temperature (WH31),
assuming you are using channel 1 of your WS31 and "Outdoor Temperature (WH31)" is the text you want to see. You can change this of course.)

When you later on get your outdoor sensor (array), you only need to adapt the label (or not, depending on the text you use).

e.g.  showing the outdoor temperature sensor plus two more outdoor measuring points/sensors
.....
[[[[Generic]]]]
.....
outTemp = Outside Temp (WS80)
.....
extraTemp1 = WH31/WH32-DIY
extraTemp3 = WH31-EP MeteoshieldPro
......
would (with some regrouping in skin.conf) create the following depiction,
by which you can see different relevant outdoor temperature measurements at one glance:
 [ You are not allowed to view attachments ]

That was for the temperature part only. The humidity part goes analogously.

[wardie]

I use the Weewx GW1000 API driver mode and have re-purposed one of my internal multi-channel WH31 sensors for main outdoor temp/humidity use temporarily (whilst I await return of WS80). Very simple once I'd figured out I needed to use the [[field_map_extensions]] and get the correct field names from the driver output. My HP2551 console I just heave hard-wired into internal temp/humidity channel 3 for the time being at least to see it on the display. Best quick solution. weewx.conf:

Code: [Select]

[GW1000]
    driver = user.gw1000
    # temporary mappings for internal sensor channel 3 to outside
    [[field_map_extensions]]
        outTemp = temp3
        outHumidity = humid3


In fact there are three (+/- fast and easy) ways how to re-map a WH31 to be the feeder of the outdoor temperature/humidity in weewx.
One of them wardie described above by using a field map.

If you don't want to send these data out to other weather networks and want to have it just for yourself, you only need to change the label of the database field holding your WH31 value.

Good ideas thanks! However I want to ensure my weewx database history for the outside temp & humidity is updated using the re-purposed sensor, so the re-map of the input seemed best.I’m not however sending this info out to community weather services WOW etc, just in case. I do this direct from consoles normally not via weewx, although I know you can.

[Gyvate]

I use the Weewx GW1000 API driver mode and have re-purposed one of my internal multi-channel WH31 sensors for main outdoor temp/humidity use temporarily (whilst I await return of WS80). Very simple once I'd figured out I needed to use the [[field_map_extensions]] and get the correct field names from the driver output. My HP2551 console I just heave hard-wired into internal temp/humidity channel 3 for the time being at least to see it on the display. Best quick solution. weewx.conf:

Code: [Select]

[GW1000]
    driver = user.gw1000
    # temporary mappings for internal sensor channel 3 to outside
    [[field_map_extensions]]
        outTemp = temp3
        outHumidity = humid3


In fact there are three (+/- fast and easy) ways how to re-map a WH31 to be the feeder of the outdoor temperature/humidity in weewx.
One of them wardie described above by using a field map.

If you don't want to send these data out to other weather networks and want to have it just for yourself, you only need to change the label of the database field holding your WH31 value.

Good ideas thanks! However I want to ensure my weewx database history for the outside temp & humidity is updated using the re-purposed sensor, so the re-map of the input seemed best.I’m not however sending this info out to community weather services WOW etc, just in case. I do this direct from consoles normally not via weewx, although I know you can.

If you want to have the data in the database, and, understandably, in the proper field, the fastest way is to do the assignment in the [StdCalibrate] [[Corrections]] stanza 
That's method #2
outTemp = temp3
outHumidity = humid3

that's where you might also have to put the "radiation line" as the Fine Offset clones don't provide native radiation data but it needs to be derived from the luminosity
radiation = luminosity/126.7 if luminosity is not None else None

of course, the field map approach also works (and it the better approach if you have a lot of field repurposing to do due to the lack of respective fields in the extended database schema).

[wardie]

that's where you might also have to put the "radiation line" as the Fine Offset clones don't provide native radiation data but it needs to be derived from the luminosity
radiation = luminosity/126.7 if luminosity is not None else None

Thanks - is that the literal text for the [[Corrections]] stanza? Pretty nifty syntax.
Really appreciate the help here.

[Gyvate]

that's where you might also have to put the "radiation line" as the Fine Offset clones don't provide native radiation data but it needs to be derived from the luminosity
radiation = luminosity/126.7 if luminosity is not None else None

Thanks - is that the literal text for the [[Corrections]] stanza? Pretty nifty syntax.
Really appreciate the help here.

yes - that's the respective Python code
just "if not  ... else" - normal extended if clause.
"None" is a defined value, in C that would be "" - an empty string.
 [ You are not allowed to view attachments ]