AeoTec MultiSensor 6 (ZW100) temperature calibration on OH 2.5.1 with device firmware 1.12

I’m hoping @chris or someone else can chime in on this since there was a similar issue in 2016 (Aeotec Multi-Sensor 6 ZW100-C -Temperature Calibration). I’ve been working with AeoTec for several weeks to confirm that the current MultiSensor 6 (1.12 firmware) is indeed calibrated the same way as the previous 1.07 firmware units.

Quoting on of their engineers…

As per parameter 201, the value is in a scale of x0.1, so a value of 10 = 1.0 degree change. For value -5.0, you will input:


Where value CE = temperature change (0xCE = 206 (calculated from 256-50))
Where value 02 = scale of temperature in F (while 01 would be C)

0xCE02 for -5.0 degree change is 52738

There is also a spreadsheet at:

So, for a -5 offset, you should be able to enter 52738 for parameter 201.

There issues are as follows:

  1. In PaperUI there are two 201 parameter for this value (the second is at the bottom once you click “more”). In HABmin there is only 1.
  2. For both PaperUI and HABmin, you cannot input a number larger than +/-127. You can an error during entry in PaperUI while with HABmin, you never see the parameter go to pending.
  3. For both PaperUI and HABmin it will take -5 (or +5) but I do not see a change in temperature and I’m also not sure if the unit is accepting the change. For example, I was attempted to offset by -7 and after my 900 second wakeup cycle these is what my was in my events.log file

2020-02-17 14:30:14.169 [vent.ItemStateChangedEvent] - office_temp changed from 73.4 to 23
2020-02-17 14:32:44.792 [me.event.ThingUpdatedEvent] - Thing ‘zwave:device:c46e91bd:node5’ has been updated.
2020-02-17 14:32:44.812 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[ConfigStatusMessage [parameterName=config_201_2_0000FF00, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null]]]
2020-02-17 14:45:07.153 [vent.ItemStateChangedEvent] - office_temp changed from 23 to 73.7
2020-02-17 14:45:13.335 [vent.ItemStateChangedEvent] - office_lum changed from 7 to 10
2020-02-17 14:45:13.784 [me.event.ThingUpdatedEvent] - Thing ‘zwave:device:c46e91bd:node5’ has been updated.
2020-02-17 15:00:07.078 [vent.ItemStateChangedEvent] - office_temp changed from 73.7 to 74.2
2020-02-17 15:00:07.555 [vent.ItemStateChangedEvent] - office_rh changed from 24 to 23
2020-02-17 15:00:13.225 [vent.ItemStateChangedEvent] - office_lum changed from 10 to 12
2020-02-17 15:00:13.729 [me.event.ThingUpdatedEvent] - Thing ‘zwave:device:c46e91bd:node5’ has been updated.

At 14:45 the node certainly work up and sends a report (because group 1 reporting is also set to 900) but I don’t know if saying the thing has update means what I think it means. You can also see that at 15:00 (just in case a cycle was missed) the temp is still about same. Also, doing it this way only whole numbers and be entered. So attempting to do something like -6.5 would throw an error that says “Input should satisfy expression -?\d+”.

  1. One last quirk… for both PaperUI and HABmin I have randomly noticed that after I set 201 to an offset. When I go back it might change to a number up to what I am guessing is 255. For instance, I think with either a -5 or -7 offset, I saw 249 in HABmin for parameter 201. I just noticed that happening in the last couple of days and only major environment changes was that I added another sensor and a Kasa bulb. These devices do not interact.

The overarching question is what is the correct way to do the temperature calibration in OpenHAB 2.5.1 now?

If that is the case we need a new device in the database.
Please provide a pdf manual showing the new values and your xml file for that node.
If you are able to add it yourself please read:

Please note that firmware 1.07 also has

Did you switch to advanced mode?

1 Like

Sorry for the delay but you provided some good information that helped shed some light on this.

First, I’m running 1.12 firmware, but according to Chris’ database 1.12 would be part of “All after 1.10” which is here:

Next, I had not gone into advanced mode in HABmin but that appears to be the same as the items under “more” in PaperUI. HABmin still seems a bit quirky at times so I tend to use PaperUI but in this regard both are consistent.

Now, here is the interesting part… the “advanced” 201 parameter as I read it should use a 2 byte hex code but when I try to enter, for example, what is in the example, 0x1402 in HABmin or PaperUI, it can not be done because you can not type the “x”.

That’s what made be give the other two 201 parameter a second look which ultimately was the solution. On OpenHAB the parameters are split into their two bytes So when you choose the temperature unit that is actually the low byte of 1 or 2 and then for the temperature offset to 1/10 of a degree, you can follow the instructions from the advanced 201 parameter (its more detailed). Therefore for -5 degrees you enter -50 or for say +1.3 degrees, you would enter 13.

This method of entry works and now that I understand it, this is much easier than having to calculate the offsets manually.

I waited a couple of days to make sure this was stable and so far it has been. :+1:t4: I hope this helps someone else because I don’t think its clear how to do the calibration on OpenHAB. Its actually a better user experience. I’m going to circle back with Aeotec to let them know this as well so that they don’t go down the wrong rabbit hole with someone else.

1 Like