After 3.6.2-upgrade: ExtraSensors have "moved" one channel/index (WMR200)

[Per Edström]

Were there a new WMR200-driver introduced in Weewx 3.6.2?
Is it 3.1.1?

I have 5 THGR810 sensors.

skin.conf
        extraTemp2     = Temperatur - Kallare (5E)
        extraHumid2    = Luftfuktighet - Kallare (5E)
        extraTemp3     = Temperatur - Vind (5E)
        extraHumid3    = Luftfuktighet - Vind (5E)
        extraTemp4     = Temperatur - Vind (5F)
        extraHumid4    = Luftfuktighet - Vind (5F)
        extraTemp5     = Temperatur - Skyddsrum (L5)
        extraHumid5    = Luftfuktighet - Skyddsrum (L5)
        extraTemp6     = Temperatur - Kanal6 (L5)
        extraHumid6    = Luftfuktighet - Kanal6 (L5)

But they have all steped one channel in the software i.e. the value of the sensor set on ch.3 will show up as extraTemp2 = ch.2, the ch.5-sensor is extraTemp4 in Weewx web page etc. The ch.6-sensor in N/A although it is "online" with WMR200.

Now, when I debug there is no extraTemp6 but extraTemp1 have emerged. It should not exist. I guess this is part of the problem but why did the index change to start on 1 instead of 2 (ch.1 is the "original" outdoor sensor on WMR200).

Jan  5 13:00:37 eBox3350 weewx[3827]: wmr200: MainThread: D  Packet cooked: id:14 Archive Data 2017-01-05 12:59:09 CET (1483617549) len:98 fields:33 {'interval': 1, 'windchill': None, 'outHumidity': 75, 'rainRate': 0.0, 'rain': 0.0, 'forecastIcon': 3, 'pressure': 992.0, 'extraHumid4': 23, 'extraHumid5': 23, 'extraHumid2': 53, 'extraHumid3': 65, 'extraHumid1': 28, 'totalRainLast': None, 'extraTemp4': 18.399999999999999, 'extraTemp5': 21.600000000000001, 'altimeter': 992.0, 'extraTemp3': -9.3000000000000007, 'usUnits': 16, 'extraTemp1': 21.800000000000001, 'totalRain': 75.742800000000003, 'extraTemp2': -5.9000000000000004, 'heatindex': None, 'UV': 0, 'dateTime': 1483617549.0, 'windDir': None, 'outTemp': -20.199999999999999, 'windSpeed': 0.0, 'inHumidity': 22, 'inTemp': 24.0, 'rain24': 0.0, 'windGust': 0.0, 'hourRain': 0.0, 'windGustDir': None}


I see a similar problem on my other WMR200 (see picture), note the change..

[Andrew Milner]

They were remapped

see the release notes

http://weewx.com/docs/changes.txt

[Per Edström]

But why? To use another sensor instead of the original outdoor sensor?
And why move the other ones?
Are you telling me that from now on:
Ch.2 = extraTemp1
Ch.3 = extraTemp2
etc.. ?

[Per Edström]

Well, it was a quick fix to remove that "improvement"..

Just edit this file, seach for "extraTemp", remove the yellow-marked "-1", save and restart Weewx..

/usr/share/weewx/weewx/drivers/wmr200.py

        elif sensor_id >= 2:
            # Extra temperature sensors.
            # If additional temperature sensors exist (channel>=2), then
            # use observation types 'extraTemp1', 'extraTemp2', etc.
            record['extraTemp%d' % (sensor_id)-1] = temp
            record['extraHumid%d' % (sensor_id)-1] = humidity

        if DEBUG_PACKETS_TEMP:

[Thomas Keffer]

Per, it may seem that this fix was made to drive you crazy, but there was a reason. See issue #164. Read that before passing judgment.

I admit that it does cause a change in where values go in the database. If that is causing you problems, let's fix that rather than having your own private version of the driver.

-tk

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mwall]

On Thursday, January 5, 2017 at 6:55:14 PM UTC-5, Tom Keffer wrote:

Per, it may seem that this fix was made to drive you crazy, but there was a reason. See issue #164. Read that before passing judgment.

I admit that it does cause a change in where values go in the database. If that is causing you problems, let's fix that rather than having your own private version of the driver.

i just committed the sensor_map pattern for the wmr100 driver.  i'm working on wmr9x8 and wmr200 now.

with the sensor_map you can associate a database field name with a sensor name by specifying the mapping in weewx.conf

m

[mwall]

as of commit dfdb243, the sensor map pattern has been applied to every built-in driver that supports more than one remote sensor (except for the vantage driver)

if you have a wmr100, wmr200, or wmr9x8 with multiple remote sensors, and you have had issues mapping the sensors to database field names, please consider giving this a try.

the sensor map looks like this (this is for the wmr200 - the sensor names for each type of hardware are slightly different, depending on how/whether the hardware reports sensor data):

[WMR200]
    driver = weewx.drivers.wmr200
    ...
    [[sensor_map]]
        altimeter = altimeter
        pressure = pressure
        windSpeed = wind_speed
        windDir = wind_dir
        windGust = wind_gust
        windBatteryStatus = wind_battery_status
        inTemp = temperature_0
        outTemp = temperature_1
        extraTemp1 = temperature_2
        extraTemp2 = temperature_3
        extraTemp3 = temperature_4
        extraTemp4 = temperature_5
        extraTemp5 = temperature_6
        extraTemp6 = temperature_7
        extraTemp7 = temperature_8
        inHumidity = humidity_0
        outHumidity = humidity_1
        extraHumid1 = humidity_2
        extraHumid2 = humidity_3
        extraHumid3 = humidity_4
        extraHumid4 = humidity_5
        extraHumid5 = humidity_6
        extraHumid6 = humidity_7
        extraHumid7 = humidity_8
        outTempBatteryStatus = battery_status_out
        rain = rain
        rainTotal = rain_total
        rainRate = rain_rate
        hourRain = rain_hour
        rain24 = rain_24
        rainBatteryStatus = rain_battery_status
        UV = uv
        uvBatteryStatus = uv_battery_status
        windchill = windchill
        heatindex = heatindex
        forecastIcon = forecast_icon
        outTempFault = fault_out
        windFault = wind_fault
        uvFault = uv_fault
        rainFault = rain_fault
        clockUnsynchronized = clock_unsynchronized

this is still subject to change!  in particular, i would like to make it possible to specify only the *change* to the default map instead of having to specify an entirely new sensor map if you just want to change one or two sensors.

m

[Thomas Keffer]

this is still subject to change!  in particular, i would like to make it possible to specify only the *change* to the default map instead of having to specify an entirely new sensor map if you just want to change one or two sensors.

​This is becoming an increasingly common pattern in weewx, one that I just used for specifying accumulator behavior in the schema branch. See lines 382 and beyond in accum.py.

-tk​

 

[Per Edström]

The WMR200 is a bit special as it is using channel 1 for the original outdoor sensor. The good thing about this is that if the original outdoor sensor is broken then a "standard" extra sensor set on channel 1 can be used, but this is also why the change was not correctly made.

On e.g. WMR928 the outdoor sensor has its own "internal" channel that can't be used for extra sensors and here you can't replace it with a "standard" sensor e.g. THGR810 but you will need the original replacement sensor.

On WMR200 the display says (channel) [1] for the outdoor sensor but on the WMR928 is says [ ] i.e. an empty channel field.

So, on WMR200 the "extraTemp2" should not be read as "the second extraTemp" but rather "the extraTemp on channel 2" as this is how it is read on the display. This is how the naming should be interpreted on the WMR928 too, as related to the WMR-channel used/shown on the display.

The current change is causing a confusion as "extraTemp1" will be found on channel 2 on WMR200 but on channel 1 on WMR928. Really not logical.
Note that if you don't have the original outdoor sensor it is possible to use channel 1 on WMR200 for another sensor, as described above, but it requires the driver to be modified and also a setting in weewx.conf (under [wmr200]-section):

(I'm not a programmer so the code is not correct in syntax but I hope you understand my thinking here)

wmr200.py

        if sensor_id == 0:
            # Indoor temperature sensor.
            record['inTemp'] = temp
            record['inHumidity'] = humidity
        elif sensor_id == 1:
            # Outdoor temperature sensor.
            if (parameter-in-weewx.conf) # This will be extraTemp1 / extraHumid1 if not using the original outdoor sensor
              record['extraTemp%d' % (sensor_id)] = temp
              record['extraHumid%d' % (sensor_id)] = humidity
            else # Using the original outdoor sensor (The Mushroom)
              record['outTemp'] = temp
              record['outHumidity'] = humidity
              record['heatindex'] = heat_index

        elif sensor_id >= 2:
            # Extra temperature sensors.
            # If additional temperature sensors exist (channel>=2), then
            # use observation types 'extraTemp1', 'extraTemp2', etc.

            record['extraTemp%d' % (sensor_id)] = temp # the "-1" is removed/restored to as it was before
            record['extraHumid%d' % (sensor_id)] = humidity # the "-1" is removed/restored to as it was before

        if DEBUG_PACKETS_TEMP:

With the implementation now in place a new sensor on channel 1 on WMR200 will be "extraTemp0" or channel 1 is left unsuable. Was that the intention?
On the WMR928 it is a different story as channel 1 is the first usable channel for extra sensors. Here is makes sense to name it "extraTemp1" as it is on channel 1.

The change made for WMR200 was not thought through as there is a significant hardware difference between the WMR-models.
I recommend it is reverted and a change as described above is made. This change will not affect the weewx currently running with WMR200 i.e. the ones that have been running weewx prior to 3.6.1.

[Andrew Milner]

Doesn't the WMR928 use a different driver - wmr9x8?  There are different four different drivers for different WMR models according to the hardware guide.

[Per Edström]

Because I have the following Oregon-stations running:
1x WMR100
2x WMR200
1x WMR928

I need to have some consistency between them i.e. that the numbering of the extraSensors are related to the channel used or else fault finding, changing of the web templates etc will be more difficult. The extraSensor THGR810 displays the channel number on its display so with the current change I have to think "OK, this is a WMR200-system so this sensor on channel 3 is extraTemp2..or was it extraTemp4..? But if I'm on the WMR100-system then if would be extraTemp3..".

So, if the "-1"-change in the WMR200-driver will remain then I have to keep changing it back on every driver-update. I don't need the problem described above!

[Per Edström]

Yes, different drivers for the WMR200 and WMR9x8 as there is a HW-difference but they need to handle the extraSensors in the same way i.e. having the channel number as numbering of the extraTemp.

As I described it earlier: it should be read as "extraTemp[channel]" and not as the sequence of extra sensors in the system. If you consider the outdoor sensor on WMR200 as an extra sensor, as it is using one of the channels, it might be more clear what I mean.
This is how it is implemented in the wmr9x8.py and how it was implemented in wmr200.py until the "-1" was introduced in 3.6.1.

Out of curiosity, and I tried to understand the issue 164: Why was the previous implementation seen as a problem? Lack of understanding on how WMR200 are using channel 1 compared to other WMR-models?

I note that the same "-1"-change, but in another way, is made in the WMR300 but guess it too uses channel 1 as outdoor sensor.

[Andrew Milner]

Did you see Matthew's comment earlier in the thread regarding the sensor mapping changes he has implemented??  The sensor mapping allows you to map the station's fields to whatever database fields you desire - so you can therefore have consistency within your databases and templates whilst having specific mapping in the .conf file appropriate to the station being controlled.

[Per Edström]

I still don't see the reason for changing the code in wmr200.py

Note that "outTemp" on WMR200 is actually "extraTemp1" as it is on channel 1. The standard mapping should be that the first extra sensor is extraTemp2 as it is on channel 2.

[Per Edström]

The code in wmr200.py should be changed so the original outdoor sensor could be swapped out for another sensor, as stated in my code-example earlier.

Although I don't think many WMR200-users have a need to swap the outdoor sensor or use 10 extra sensors, there might be someone that need that feature and the change seems minimal.

[Andrew Milner]

The weewx coluimn 'extraTemp1' signifies by its name that it is an output from a 'extra' temperature sensor - it may be on channel 1, channel 99, or channel A B or C depending on the specific hardware which has created the record.  Weewx only builds in 5 'extra' columns which people may use as they wish.  They may correspond to channels, they may correspond to rooms or ponds or anything - they are not specifically channel related columns as far as I am aware.

[Andrew Milner]

Per - this is being written 'tongue-in-cheek' - but you could always change the database schema and call the columns extraTempA, extraTempB, extraTempC ..... change your templates to match ..... and map the driver output fields accordingly into the now renamed database columns .........  Not a channel in sight .....

[mwall]

On Saturday, January 7, 2017 at 7:50:00 AM UTC-5, Per Edström wrote:

With the implementation now in place a new sensor on channel 1 on WMR200 will be "extraTemp0" or channel 1 is left unsuable. Was that the intention?

the change was made based on this report:

https://github.com/weewx/weewx/issues/164

clearly we should have provided instructions in the upgrading guide for those who already have many additional sensors, as illustrated by these threads:

https://groups.google.com/forum/#!topic/weewx-user/NH0d3G5lS90

https://groups.google.com/forum/#!topic/weewx-user/KAJbv3qmeK8

https://groups.google.com/forum/#!topic/weewx-user/ag_u-517WzI

and even more clearly, there is significant difference between wmr100, wmr200, and wmr9x8, despite the fact that each type of base station can see many of the same sensors.

the sensor_map pattern has been applied to every driver, so that weewx will work seamlessly no matter how many additional sensors you have.  it also lets you easily remap sensors when you have a sensor failure.  the additional indirection also makes it easy to move sensors physically without disrupting the database or your reports.

since you have wmr100, wmr200, and wmr9x8 hardware, your advice on this is very helpful!

i would suggest that you retain your patch of wmr200; remove the decrement, thus reverting this patch:

https://github.com/weewx/weewx/commit/fc97406fad0dc0d2fd8ff1110bd1430643f8f3b7

but please help us get the default mappings right for the next weewx release.

m
 

[mwall]

per,

here are the (proposed) default maps for the wmr100, wmr200, and wmr9x8 drivers:

wmr100:

        'inTemp': 'temperature_0',
        'outTemp': 'temperature_1',
        'extraTemp1': 'temperature_2',
        'extraTemp2': 'temperature_3',
        'extraTemp3': 'temperature_4',
        'extraTemp4': 'temperature_5',
        'extraTemp5': 'temperature_6',
        'extraTemp6': 'temperature_7',
        'extraTemp7': 'temperature_8',
        'inHumidity': 'humidity_0',
        'outHumidity': 'humidity_1',
        'extraHumid1': 'humidity_2',
        'extraHumid2': 'humidity_3',
        'extraHumid3': 'humidity_4',
        'extraHumid4': 'humidity_5',
        'extraHumid5': 'humidity_6',
        'extraHumid6': 'humidity_7',
        'extraHumid7': 'humidity_8',
        'inTempBatteryStatus': 'battery_status_0',
        'outTempBatteryStatus': 'battery_status_1',
        'extraBatteryStatus1': 'battery_status_2',
        'extraBatteryStatus2': 'battery_status_3',
        'extraBatteryStatus3': 'battery_status_4',
        'extraBatteryStatus4': 'battery_status_5',
        'extraBatteryStatus5': 'battery_status_6',
        'extraBatteryStatus6': 'battery_status_7',
        'extraBatteryStatus7': 'battery_status_8',

wmr200:

        'inTemp': 'temperature_0',
        'outTemp': 'temperature_1',
        'extraTemp1': 'temperature_2',
        'extraTemp2': 'temperature_3',
        'extraTemp3': 'temperature_4',
        'extraTemp4': 'temperature_5',
        'extraTemp5': 'temperature_6',
        'extraTemp6': 'temperature_7',
        'extraTemp7': 'temperature_8',
        'inHumidity': 'humidity_0',
        'outHumidity': 'humidity_1',
        'extraHumid1': 'humidity_2',
        'extraHumid2': 'humidity_3',
        'extraHumid3': 'humidity_4',
        'extraHumid4': 'humidity_5',
        'extraHumid5': 'humidity_6',
        'extraHumid6': 'humidity_7',
        'extraHumid7': 'humidity_8',

wmr9x8:

        'inTemp': 'temperature_in',
        'outTemp': 'temperature_out',
        'extraTemp1': 'temperature_1',
        'extraTemp2': 'temperature_2',
        'extraTemp3': 'temperature_3',
        'extraTemp4': 'temperature_4',
        'extraTemp5': 'temperature_5',
        'extraTemp6': 'temperature_6',
        'extraTemp7': 'temperature_7',
        'extraTemp8': 'temperature_8',
        'inHumidity': 'humidity_in',
        'outHumidity': 'humidity_out',
        'extraHumid1': 'humidity_1',
        'extraHumid2': 'humidity_2',
        'extraHumid3': 'humidity_3',
        'extraHumid4': 'humidity_4',
        'extraHumid5': 'humidity_5',
        'extraHumid6': 'humidity_6',
        'extraHumid7': 'humidity_7',
        'extraHumid8': 'humidity_8',
        'inTempBatteryStatus': 'battery_status_in',
        'outTempBatteryStatus': 'battery_status_out',
        'extraBatteryStatus1': 'battery_status_1', # was batteryStatusTHx      
        'extraBatteryStatus2': 'battery_status_2', # or batteryStatusTx        
        'extraBatteryStatus3': 'battery_status_3',
        'extraBatteryStatus4': 'battery_status_4',
        'extraBatteryStatus5': 'battery_status_5',
        'extraBatteryStatus6': 'battery_status_6',
        'extraBatteryStatus7': 'battery_status_7',
        'extraBatteryStatus8': 'battery_status_8',
        'inDewpoint': 'dewpoint_in',
        'dewpoint': 'dewpoint_out',
        'dewpoint0': 'dewpoint_0',
        'dewpoint1': 'dewpoint_1',
        'dewpoint2': 'dewpoint_2',
        'dewpoint3': 'dewpoint_3',
        'dewpoint4': 'dewpoint_4',
        'dewpoint5': 'dewpoint_5',
        'dewpoint6': 'dewpoint_6',
        'dewpoint7': 'dewpoint_7',
        'dewpoint8': 'dewpoint_8',

as you can see, many more sensors are supported, so everything should work out-of-the-box (we are also working on an extended schema so you won't have to add columns to the database to record data from extra sensors).

questions for you:

- do these mappings make sense for a default, out-of-the-box installation?
- does the wmr200 have a battery status indicator for remote sensors?
- exactly how many remote T/H sensors are supported by wmr100 hardware?
- exactly how many remote T/H sensors are supported by wmr200 hardware?
- exactly how many remote T/H sensors are supported by wmr9x8 hardware?
- what happens when your wmr9x8 receives data from two different wind sensors?

m

[Per Edström]

1. I don't see how extraTemp4-7 can be used in WMR88 or WMR928 as they only support 3 extra sensors. The WMR200 need extraTemp8-9 as it supports 9 extra sensors. However, as the original outdoor sensor is on channel 1 and can be replaced by an external sensor (maybe the user only wants to use THGR810 and noone outside) and in that case be using extraTemp1-10 instead, also as it corresponds to the channel number. Now, as I said earlier, the WMR200 starts the extra sensor-range on channel 2 and in e.g. skin.conf you will map that name to a graph etc:

#Egna sensorer..
        [[[day_kallare5e_temp]]]
            yscale = 13.0, 23.0, 1.0
            [[[[extraTemp2]]]]
                label = Kallartemp. 5E

        [[[day_kallare5e_fukt]]]
            yscale = 0, 100, 10
            [[[[extraHumid2]]]]
                label = Kallarfukt. 5E

I find it very useful to have the channel-number included in the sensor-name. I it also useful for fault finding if the same name is found in all code e.g. in the driver but I guess not all users will play around on the code. I guess it is useful to have the "real" name/usage too but then I will need a translation list to channel number as the sensors can be moved around (or include channel number in the other name too). But I think the "previous" solution was nice and logical.
Don't all weather stations use channels for their sensors?

2. I'm not sure for all possible extra sensors to WMR200 (protocol version 3.0) but my THGR810 send battery information. How ever, the battery symbol is visual on the sensor and on the display but not visual on the generated web pages of in syslog. But as it is sent to the main unit it should be available for collection?

From what I understand from reading about the protocol 3.0 the #7 nibble where 0x4-bit should contain the battery status for all sensors. Now, I can't read the python-code good enough to figure out where to collect this information in the wmr200.py driver but maybe it is stored in the D9-field. There are enough space in byte 4 and 5 to store 9 extra sensors temp/humidity.

It would be nice to have a matrix-overview with current sensors (wind, rain, temp etc) and their battery status on the web page. I think I wrote a "wish" for that here on the forum some years ago..

3. I need to correct myself here. I have WMR88 but it is running the WMR100-driver. WMR88 have space for 3 (ch 1-3) extra sensors and the outdoor temp sensor is on channel [ ] (internal one) but in the same "loop" as the other channels i.e. in the same display field. Protocol 3.0 so the same sensors as WMR200 can be used. WMR88 have the same wind sensor as WMR200 but not the solar panel and another outdoor sensor.

4. WMR200 have space for 9 extra sensors (ch. 2-10) but as I said earlier, if the original outdoor sensor is not used then channel 1 is also available for e.g. THGR810, or the poolsensor etc. The  outdoor sensor is displayed as [1].

5. WMR928 (not sure about WMR918) have, just like WMR88, space for 3 extra sensors. Note: Using protocol 2.1 (?) so the THGR810 will not be used.

6. Not sure if that is even possible as the wind sensor is synchronized with the main unit (the 8-bit "Rolling code). I guess it locks on to a generated sensor ID (0-255). Also, the range of the wind sensor is poor so the other wind sensor have to be within 30m from the main unit so I'd say the risk of picking up another wind sensor with the same ID is low..

[Per Edström]

Why don't WMR200 have:

        'extraBatteryStatus1': 'battery_status_2', #Channel 2

        'extraBatteryStatus2': 'battery_status_3',
        'extraBatteryStatus3': 'battery_status_4',
        'extraBatteryStatus4': 'battery_status_5',
        'extraBatteryStatus5': 'battery_status_6',
        'extraBatteryStatus6': 'battery_status_7',
        'extraBatteryStatus7': 'battery_status_8',

+
        'extraBatteryStatus8': 'battery_status_9',
        'extraBatteryStatus9': 'battery_status_10', # Channel 10
       

[Per Edström]

I have looked through the code and I can't find the collection of battery status from extra sensors anywhere. Looking on the WMR200-protocol I guess there is no clear place where the information is available:
http://www.bashewa.com/wmr200-protocol.php

Now, enabling the debug reveals that my WMR200 (with 5 extra sensors THGR810) sends status package:
Sensor packet:d9 08 00 10 d4 00 c5 01
where
B02: 00
B03: 10 = 0001 0000
B04: d4 = 1101 0100
B05: 00
 
B06: c5 # checksum
B07: 01 # checksum

If I match my data with the procotol reverse engineering I get (high-lighted = 1):

   Byte 02:  (H) [1... ....] = [#80]
                 [.1.. ....] = [#40]
                 [..1. ....] = [#20]
                 [...1 ....] = [#10]
             (L) [.... 1...] = [#08]
                 [.... .1..] = [#04]
                 [.... ..1.] = [#02] Sensor fault: Sensor 1 (temp/hum outdoor) # Correct
                 [.... ...1] = [#01] Sensor fault: Wind (---) # Correct

 Byte 03:  (H) [1... ....] = [#80]
                 [.1.. ....] = [#40]
                 [..1. ....] = [#20] Sensor fault: UV   (--) # Correct
                 [...1 ....] = [#10] Sensor fault: Rain (---) #Correct
             (L) [.... 1...] = [#08]
                 [.... .1..] = [#04]
                 [.... ..1.] = [#02]
                 [.... ...1] = [#01]

   Byte 04:  (H) [1... ....] = [#80] RF Signal Weak: Console Clock (time not synchronized) #This is true. The signal from Frankfurt is too week for my station..
                 [.1.. ....] = [#40] # This should mean something as it is = 1
                 [..1. ....] = [#20]
                 [...1 ....] = [#10] # This should mean something as it is = 1
             (L) [.... 1...] = [#08]
                 [.... .1..] = [#04] # This should mean something as it is = 1
                 [.... ..1.] = [#02] Battery Low: Sensor 1 (temp/hum outdoor)
                 [.... ...1] = [#01] Battery Low: Wind ... to be confirmed)

   Byte 05:  (H) [1... ....] = [#80]
                 [.1.. ....] = [#40]
                 [..1. ....] = [#20] Battery Low: UV ..... (below 2.4v out of 3.0v)
                 [...1 ....] = [#10] Battery Low: Rain ... to be confirmed)
             (L) [.... 1...] = [#08]
                 [.... .1..] = [#04]
                 [.... ..1.] = [#02]
                 [.... ...1] = [#01]

Now, I just replaced batteries on most of the extra sensors but the one on channel 4,as it is places in a remote/inaccessible place, but it should too be low on battery. It seems though as three sensors could be low on battery (if there is one bit per sensor). Maybe I should insert "bad" batteries in one extra sensor, change the channel and see if any bit changes and moves in byte 4 and 5..

[Andrew Milner]

Per - one thing I think you are missing is that the weewx database schema and available column names is device independent and, for most consoles, provides far more available columns than the console provides.  The schema does not change with the station type - but the way the columns are used may vary.  People are using weewx and the database schema for more than just data captured from weather stations - so no, not all the data in extraTemp columns comes from channels connected to a console.  So whilst you would like extraTemp1 to represent say channel 1 and extraTemp2 to represent channel 2 another user may want extraTemp1 to represent a non-weather station, non-channel related CPU temperature.  Each to their own ...

[Per Edström]

Well, there are a lot of things around Weewx that I don't know and others that I don't understand. I thought that the default mapping should mirror what the console could actually provide and if the user wants other data to be stored in the same DB then the user have to make own configurations. The other "standard"-fields should be #-out so if the WMR100-user wants to use extraTemp4 as CPU-temp then he/she can comment it out. (Is this really common?).

The difference with WMR200 compared to all other WMR-stations is that the outdoor-channel can be used for another model of T/H-sensor and hence this is a very possible configuration (my "Mushroom-sensor broke when the roof-guys damaged the mounting and the sensor got hanging in the solarpanel-wire so that the rain flooded the sensor. Instead of buying a new "Mushroom" I could have bought another sensor and set it to channel 1).
So the mapping, in my view, should show (yellow) that as "outTemp" doesn't have to be a sensor for outdoor usage but can be an indoor sensor on channel 1:

wmr200:

        'inTemp': 'temperature_0',
        'outTemp': 'temperature_1', # 'extraTemp1': 'temperature_1',
        'extraTemp2': 'temperature_2', #Ch.2

        'extraTemp3': 'temperature_3',
        'extraTemp4': 'temperature_4',
        'extraTemp5': 'temperature_5',
        'extraTemp6': 'temperature_6',
        'extraTemp7': 'temperature_7',
        'extraTemp8': 'temperature_8',

        'extraTemp9': 'temperature_9',
        'extraTemp10': 'temperature_10', # Ch.10
        'inHumidity': 'humidity_0',
        'outHumidity': 'humidity_1', # 'extraHumid1': 'humidity_1',
        'extraHumid2': 'humidity_2', # Ch.2

        'extraHumid3': 'humidity_3',
        'extraHumid4': 'humidity_4',
        'extraHumid5': 'humidity_5',
        'extraHumid6': 'humidity_6',
        'extraHumid7': 'humidity_7',
        'extraHumid8': 'humidity_8',

        'extraHumid9': 'humidity_9',
        'extraHumid10': 'humidity_10',

In any case, WMR200 need two more extraTemp/extraHumid (green) in the standard configuration/DB.

[Per Edström]

Sorry, I need to correct myself again! My WMR88 is in a place I rarely visit = I don't look at it or handle it physically. Now that I'm actually there I note the following:

1. There is a "shared" temperature-field on the display. The [ ] channel (actually, there is a "-" inside a house-symbol) is the inside (in the console) temperature.

2. The [1] channel is, just like WMR200, the outside sensor.

3. The [2] and [3] channel are for extra sensors hence only two extra sensors are available on the WMR88.

[Per Edström]

Old thread..

I still think that the extraSensor-numbering should correspond to channel used, specially on those models where the sensor is displaying the channel number (e.g. THGR-810):

The changes made earlier means that there will be a mismatch beween the nameing in Weewx and the channel displayed on the sensor. extraTemp3 will not be channel 3 as picture above. That will complicate location of correct sensor. On a stock WMR200 is will not be possible to have an extra sensor och channel 1 as that one is used by the outdoor sensor (which is hard coded to channel 1). However, if the standard outdoor sensor is broken/not used then channel 1 can be used by an extra sensor.

Where these sensors are placed in available in skin.conf:

     [[Generic]]
        # Generic labels, keyed by an observation type.

        #barometer      = Lufttryck
        pressure       = Lufttryck
        dewpoint       = Daggpunkt
        heatindex      = Varmeindex
        inHumidity     = Luftfuktighet inomhus
        inTemp         = Inomhustemperatur
        outHumidity    = Luftfuktighet utomhus
        outTemp        = Utomhustemperatur
        radiation      = Radiation
        rain           = Regn
        rainRate       = Regnintensitet
        rxCheckPercent = ISS Signal Quality
        UV             = UV-index
        windSpeed      = Vindhastighet
        windDir        = Vindriktning
        windGust       = Vindbyar
        windGustDir    = Vindbyar
        windchill      = Koldeffekt
        windvec        = Vindvektor
        windgustvec    = Vindbyar

       # Egna sensorer
          #extraTemp1     =
          #extraHumid1    =

        extraTemp2     = Temperatur - Kallare (5E)
        extraHumid2    = Luftfuktighet - Kallare (5E)
        extraTemp3     = Temperatur - Vind (5E)
        extraHumid3    = Luftfuktighet - Vind (5E)
        extraTemp4     = Temperatur - Vind (5F)
        extraHumid4    = Luftfuktighet - Vind (5F)
        extraTemp5     = Temperatur - Skyddsrum (L5)
        extraHumid5    = Luftfuktighet - Skyddsrum (L5)
        extraTemp6     = Temperatur - Kanal6 (L5)
        extraHumid6    = Luftfuktighet - Kanal6 (L5)

Therefor I have made a different DEFAULT_MAP in driver wmr200.py and I think that this should be the new standard for WMR200. Other weather stations can have another default mapping suitable for that station.

    DEFAULT_MAP = {
        'altimeter': 'altimeter',
        'pressure': 'pressure',
        'windSpeed': 'wind_speed',
        'windDir': 'wind_dir',
        'windGust': 'wind_gust',
        'windBatteryStatus': 'battery_status_wind',
        'inTemp': 'temperature_0',
        # PEED =>

        'outTemp': 'temperature_1', # 'extraTemp1': 'temperature_1',
        'extraTemp2': 'temperature_2', # Ch.2
        'extraTemp3': 'temperature_3',
        'extraTemp4': 'temperature_4',
        'extraTemp5': 'temperature_5',
        'extraTemp6': 'temperature_6',
        'extraTemp7': 'temperature_7',
        'extraTemp8': 'temperature_8',
        'extraTemp9': 'temperature_9',
        'extraTemp10': 'temperature_10', # Ch.10
        'inHumidity': 'humidity_0',
        'outHumidity': 'humidity_1', # 'extraHumid1': 'humidity_1',
        'extraHumid2': 'humidity_2', # Ch.2
        'extraHumid3': 'humidity_3',
        'extraHumid4': 'humidity_4',
        'extraHumid5': 'humidity_5',
        'extraHumid6': 'humidity_6',
        'extraHumid7': 'humidity_7',
        'extraHumid8': 'humidity_8',
        'extraHumid9': 'humidity_9',

        'extraHumid10': 'humidity_10', # CH.10
        'inHeatindex': 'heatindex_0',
        'heatindex': 'heatindex_1',
        'heatindex2': 'heatindex_2',
        'heatindex3': 'heatindex_3',
        'heatindex4': 'heatindex_4',
        'heatindex5': 'heatindex_5',
        'heatindex6': 'heatindex_6',
        'heatindex7': 'heatindex_7',
        'heatindex8': 'heatindex_8',
        'heatindex9': 'heatindex_9',
        'heatindex10': 'heatindex_10',
        # => PEED
        'outTempBatteryStatus': 'battery_status_out',
        'rain': 'rain',
        'rainTotal': 'rain_total',
        'rainRate': 'rain_rate',
        'hourRain': 'rain_hour',
        'rain24': 'rain_24',
        'rainBatteryStatus': 'battery_status_rain',
        'UV': 'uv',
        'uvBatteryStatus': 'battery_status_uv',
        'windchill': 'windchill',
        'forecastIcon': 'forecast_icon',
        'outTempFault': 'out_fault',
        'windFault': 'wind_fault',
        'uvFault': 'uv_fault',
        'rainFault': 'rain_fault',
        'clockUnsynchronized': 'clock_unsynchronized'}