Aeotec multisensor temperature reporting threshold incorrect

Configuration
11

So I purchased another Aeotec Multisensor 6 and it is doing exactly the same thing.

Out of the box the default temperature threshold value (parameter 41) displays as 20, but if something is written to the value (e.g. 10, or 5) after a short delay it displays 1310976 as the set value. I have tried this with both secure and insecure connections. All other parameter values display correctly.

I’m pretty sure this is just a display bug as the device behaves as expected for the value entered.

It would be nice to have this confirmed on another system before I log an issue though.

Anyone?

12

I’ve opened an issue.

https://github.com/home-assistant/home-assistant/issues/16941

13

For anyone wondering it’s a problem with OZW.

https://github.com/OpenZWave/open-zwave/issues/1332

1 Like
14

And does anyone know if this will be fixed in home-assistant?
Assuming it has been fixed upstream like the closure of the issue implies.

15

This still appears to be a problem. I see the issue opened with HA was closed in reference to it being an OZW issue. That issue was also closed, however I’m still seeing this problem.

Anyone have any clues on how to get this to work?

16

The issue is still open… if you read the thread it links to the issue that ultimately solve the problem.

https://github.com/OpenZWave/open-zwave/issues/644

17

Thank you replying @petro, but I must have missed something. I read issue #1332 that @tom_l opened. I see it was closed as this is an OZW issue (#644) but that’s closed as well. I looked at the OZW config file that my 85.0 install has and it references 4 bytes for field #41, yet I still get this error.

What am I missing?

18

That’s what I’m saying, issue 644 is what I linked and it’s still open, meaning the issue has not been resolved. There is nothing you can do.

image
image915×161 13.5 KB

19

@petro I see. I was looking at #664 when I typed #644. I see #644 is old issue that includes several issues like the one we’re seeing. Thanks!

20

This is what i got from Aeotec support team which i find helpful in understanding what is going on with Parameter 41:

Using Parameter 41 with 4 byte size value

1310976 is the decimal value for 0x00140100 which uses the threshold for 2.0C. As a quick explaination to the hex values:

0x00YYZZ00

YY is the threshold setting for temperature multipied by 0.1 scale for the decimal value. So if this 0x14, this is converted to 20 for hex. This means that is a change in (20*0.1) temperature happens, it will report.

ZZ is the scale where 01 is the scale for C (while 02 is the scale for F), this shouldn’t change for you.

​Unfortunately the minimum setting is 1.0 (while 0.5 cannot be done) which is likely the setting reports back to default. For this example, i will set it to the minimum of 10 degree of change.

So converting 10 to hex, this is 0x0A, this is what will be plugged into YY

Converting 01 scale for C to hex is still 0x01, this will be plugged into ZZ.

0x000A0100 is the final value you want to use. converting this to decimal yields 655616.

So you want to input:

Parameter 41 [4 byte] = 655616

Using 1 byte size for Parameter 41

Alternatively, if you use Parameter 41 [1 byte] = 10, the reported value will report as 655616 (which converts 1 byte into its 4 byte value setting)

ie. So if Parameter 41 [1 byte] = 0x0A or 10, the Multisensor 6 will automatically convert this to 4 byte using the 0x00YYZZ00 value where 0x0A is the YY value.

If the scale is set to 01 (Celcius) or 02 (Fahrenheit) [Lets just say C degree for this example] via Parameter 64. This automatically sets ZZ value as 0x01.

So the output of Parameter 41 will report 0x000A0100 as 655616

6 Likes
21

Can you please help.I cant change the thershold for the multisensor 6 fot the temperaure and humidity . i have 4 multisensors with the same isue. application version is 1.11

22

I think the problem here is the interpretation of the parameter.

The value 1310976 corresponds to 0x140100 = 20 and °C = 2.0°C

To set the value to 0.5°C the hex value must look like 0x50100, but this is not possible because parameter 41 is at least 10 (1.0°C).
If the value is 0xA0100 this would correspond to a Dziamal value of 655616.

23

Anyone seen that this sensor is not reporthing at all when threshold is reached.

Also have issues with wake time. Cant set it to other values then default 3600

24

Dude. That was a 2 year old post. I don’t even have zwave devices anymore and it was also fixed 2 years ago:

25

This issue is still presented in ha, and the post is old does not matter

26

Then it’s likely a new issue, because that issue was fixed in this PR add ZMHAD1 Qubino support by wackoracoon · Pull Request #664 · OpenZWave/open-zwave · GitHub

Yeah it does. See point 3 here.

27

I see the exact same issue with parameter 41, showing 1310976. Latest HA, Zwave integration.

28

I see the same thing with 1.12 firmware on the Aeotec and the latest HA with zwave (fresh wipe and reinstall).
Weirdly, using 655616 as the value in Parameter 41 leaves that value present, hoping that will reporting 1.0 degree changes in F.

Looking for anyone that can help

29

I raised it on git here, I found other parameters doing this too. No one responded yet and I see a few pending zwave issues going unfixed. I also switched to beta open zwave, behaviour is exactly the same interestingly. Feels like it’s not going to get addressed any time soon so I swallowed the cost and have now switched to a combee ii and aqara / sonoff sensors and have no issues.

Makes you wonder though, I got recommended this sensor quite a bit, don’t understand why people would recommend a sensor they aren’t able to fully configure so I assume for some people its working OK.

If anyone can confirm if this is likely to be more an open zwave issue rather than HA I’ll log it on their git too.

30

Any news about this problem ?
I still got the same problem running on jeedom smartbox and ZW-100 AEOTEC.
I found that setting 655616 in the 41 parameters sets the value to 1° report …