Aeotec Multisensor 6 ZW100 burning through batteries like mad

[vanja (galaxy)]

Hi,
This sensor burns 2 x CR123A duracell batteries in 2 months. Ouch! expensive…
Then I moved to rechargeable batteries which it burns in 2 weeks.
Considering I only need temperature and humidity from it, this sensor is useless in its current state. Comparing to some other xiaomi sensors that run for years on a single CR2032 battery.

Any advice how to optimize this sensor for better/lower energy usage. What is your experience with its battery life?

here is the config:

UID: zwave:device:9d309ab5:node6
label: Z-Wave Temperature Sensor Ventilation
thingTypeUID: zwave:aeon_zw100_01_010
configuration:
  config_52_1: 50
  config_54_2: 100
  config_202_1: 0
  config_204_1: 0
  group_1:
    - controller
  config_112_4: 3600
  config_39_1: 21
  config_9_2_00000100: 0
  config_56_1: 4
  config_58_1: 5
  config_201_2_000000FF: 1
  config_43_2: 100
  config_64_1: 1
  config_252_1: 0
  config_60_1: 2
  config_81_1: 1
  config_41_4_0000FF00: 1
  wakeup_interval: 600
  config_255_4_wo: 0
  config_50_4_7FFF0000_wo: 0
  action_heal: false
  config_102_4: 0
  config_9_2: 2
  config_3_2: 3600
  config_45_1: 2
  config_41_4_wo: 20
  config_5_1: 0
  config_55_1: 8
  config_53_2: 1000
  config_100_1_wo: 0
  config_51_1: 60
  config_201_2: 0
  config_203_2: 0
  config_50_4_wo: 0
  config_201_2_0000FF00: 1
  wakeup_node: 1
  config_113_4: 3600
  config_9_2_00000001: 0
  config_111_4: 300
  config_49_4_wo: 0
  config_59_1: 10
  config_49_4_7FFF0000_wo: 280
  config_57_2: 5121
  config_42_1: 10
  config_41_4_00FF0000: 1
  config_44_1: 10
  config_50_4_0000FF00_wo: 1
  config_61_1: 0
  config_40_1: 0
  config_49_4_0000FF00_wo: 1
  action_failed: false
  config_110_1_wo: 0
  binding_pollperiod: 3600
  config_2_1: 0
  config_101_4: 96
  config_8_1: 15
  config_46_1: 0
  config_4_1: 0
  config_103_4: 0
  config_48_1: 0
  node_id: 6
bridgeUID: zwave:serial_zstick:9d309ab5

[vanja (galaxy)]

seems I have it configured to wake up every 10 minutes, will set it to 1 hour and test.
still, I feel other cr2032 sensor report more often then 1 hour…

[Andrew_Rowe]

I do not own any Aeotec devices but that rate of battery consumption is obviously not practical. Something is wrong, maybe it is defective. I’m guessing this is a new sensor? I would contact the manufacturer or return it

[vanja (galaxy)]

its actually 4 years old, it was always an energy guzzler so I was running it off a usb power bank. But in current scenario that is not an option. Just trying to understand if I can optimize it before I discard it…

[rpwong (Russ)]

@vanja

seems I have it configured to wake up every 10 minutes

This would definitely burn more battery. Wakeup is not related to reporting. It’s a check-in with the controller for configuration.

I have my sensors set to 86400 seconds, which is 24 hours.

[apella12 (Bob Eckhoff)]

I’ll add this reference A Comparison Between Z-Wave, Z-Wave Plus, and Z-Wave Plus V2 - Alarm Grid. For a 500 device (like the Multisensor 6) wake power usage is 35,000x sleep. If I did the calc correctly, waking for one second every ten minutes is like 58 days of sleep battery usage versus waking once a day

[Andrew_Rowe]

@vanja

I was running it off a usb power bank.

wait, that is a clue. The device will configure itself differently if it is initialized plugged in then if it is initialized running on batteries. I believe unincluding the device from the network, factory resetting it and reincluding while running on batteries may change how much power it consumes.
Did somebody already suggest this?

[rpwong (Russ)]

Agreed. I think I posted at exactly the same time as @vanja, so I didn’t see the but about the USB power bank.

[vanja (galaxy)]

it was added as battery device, then later connected to usb…how can I check what he thinks he is? a battery or mains device?

it doesn’t let me use 86400

I dont understand these hex values, what is 2? what is yours reporting?

[apella12 (Bob Eckhoff)]

Not allowing longer wakeups seems odd. What do you have on the Controller UI for systemwide wakeup. May need to set that to 86400 too.

I don’t have the device, but my read is “2” is battery. I think in binary the options are 00, 10 (2) or 11 (3). The most significant bit (MSB) is on the left in this case.

[vanja (galaxy)]

You’re right, wakeup was 3600 on the controller. I set it to 24hours now, and I have to wait for like an hour for zw100 to pick the configuration up I guess…

[vanja (galaxy)]

even after changing it to 24hours on the controller, zw100 still doesnt want to take any number bigger then 3600 for wakeup.
Another thing, I have configured reporting groups the following way:
Group1 - report only Humidity - update every 3600 seconds (1 hour)
Group2 - report only temperature - update every 3600 seconds (1 hour)
Group3 - report only Battery - update every 7200 seconds (2 hours)

However, it ignores it and reports all 3 values every 10 minutes…this is whats probably burning the battery…

whatever I try to insert here, its just stuck to pending. other values in the config I am able to change…so maybe for some reason it is still secretly using 600 seconds (previous value) as a wake up period, and then reports everything every 10 minutes once woken up. don’t know how to stop this…all in all really shitty sensor

[vanja (galaxy)]

it seems there is a bug with OH, when you apply the config, sometimes he throws an error that 0 is selected for a property where 1 and 2 are the only allowed values. its for setting celsius or fahrenheit.
Where in reality I have it set to 1 (celsius) but somehow it thinks its 0.
This error happens if I click on the code tab and then click save. If I save it on gui config tab, then no error, but stuck on pending.
it may happen if I disable enable the device but not sure…

2024-08-05 09:23:03.640 [WARN ] [.core.thing.binding.BaseThingHandler] - Attempt to apply invalid configuration 'Configuration[{key=config_52_1; type=BigDecimal; value=50}, {key=config_54_2; type=BigDecimal; value=100}, {key=config_202_1; type=BigDecimal; value=0}, {key=config_204_1; type=BigDecimal; value=0}, {key=group_1; type=ArrayList; value=[controller]}, {key=config_112_4; type=BigDecimal; value=3600}, {key=config_39_1; type=BigDecimal; value=21}, {key=config_9_2_00000100; type=BigDecimal; value=1}, {key=config_56_1; type=BigDecimal; value=4}, {key=config_58_1; type=BigDecimal; value=5}, {key=config_201_2_000000FF; type=BigDecimal; value=0}, {key=config_43_2; type=BigDecimal; value=100}, {key=config_64_1; type=BigDecimal; value=1}, {key=config_252_1; type=BigDecimal; value=0}, {key=config_60_1; type=BigDecimal; value=2}, {key=config_81_1; type=BigDecimal; value=2}, {key=config_41_4_0000FF00; type=BigDecimal; value=1}, {key=wakeup_interval; type=BigDecimal; value=600}, {key=config_255_4_wo; type=BigDecimal; value=0}, {key=config_50_4_7FFF0000_wo; type=BigDecimal; value=0}, {key=action_heal; type=Boolean; value=false}, {key=config_102_4; type=BigDecimal; value=32}, {key=config_9_2; type=BigDecimal; value=256}, {key=config_3_2; type=BigDecimal; value=3600}, {key=config_45_1; type=BigDecimal; value=2}, {key=config_41_4_wo; type=BigDecimal; value=20}, {key=config_5_1; type=BigDecimal; value=0}, {key=config_55_1; type=BigDecimal; value=8}, {key=config_53_2; type=BigDecimal; value=1000}, {key=config_100_1_wo; type=BigDecimal; value=0}, {key=config_51_1; type=BigDecimal; value=60}, {key=config_201_2; type=BigDecimal; value=0}, {key=config_203_2; type=BigDecimal; value=0}, {key=config_50_4_wo; type=BigDecimal; value=0}, {key=config_201_2_0000FF00; type=BigDecimal; value=0}, {key=wakeup_node; type=BigDecimal; value=1}, {key=config_113_4; type=BigDecimal; value=7200}, {key=config_9_2_00000001; type=BigDecimal; value=0}, {key=config_111_4; type=BigDecimal; value=3600}, {key=config_49_4_wo; type=BigDecimal; value=0}, {key=config_59_1; type=BigDecimal; value=10}, {key=config_49_4_7FFF0000_wo; type=BigDecimal; value=280}, {key=config_57_2; type=BigDecimal; value=5121}, {key=config_42_1; type=BigDecimal; value=10}, {key=config_41_4_00FF0000; type=BigDecimal; value=1}, {key=config_44_1; type=BigDecimal; value=10}, {key=config_50_4_0000FF00_wo; type=BigDecimal; value=1}, {key=config_61_1; type=BigDecimal; value=0}, {key=config_40_1; type=BigDecimal; value=0}, {key=config_49_4_0000FF00_wo; type=BigDecimal; value=1}, {key=action_failed; type=Boolean; value=false}, {key=config_110_1_wo; type=BigDecimal; value=0}, {key=binding_pollperiod; type=BigDecimal; value=3600}, {key=config_2_1; type=BigDecimal; value=0}, {key=config_101_4; type=BigDecimal; value=64}, {key=config_8_1; type=BigDecimal; value=3600}, {key=config_46_1; type=BigDecimal; value=0}, {key=config_4_1; type=BigDecimal; value=0}, {key=config_103_4; type=BigDecimal; value=1}, {key=config_48_1; type=BigDecimal; value=0}, {key=node_id; type=BigDecimal; value=6}]' on thing 'zwave:device:9d309ab5:node6' blocked. This is most likely a bug: {config_201_2_000000FF=The value 0 does not match allowed parameter options. Allowed options are: [ParameterOption [value="1", label="Celsius"], ParameterOption [value="2", label="Fahrenheit"]]}

edit: i can workaround this by toggling this value all the time. If I want to change something like wake up period, i have to switch it to fahrenheit. then later on back to celsius. otherwise if I dont touch the temperature unit, my config changes get stuck in pending and might throw an error that I’m trying to use value 0 for temperature unit.

edit2: OK it seem that with this workaround I managed to apply the settings of wake up every 3600 (maximum it allows me) and it is reporting all 3 reporting groups (humidity, temperature and battery) only every 1 hour, not every 10 minutes like before.
Also, I asked it to report on battery every 2 hours, but since it gets wake up call every hour, it reports the battery on the hour as well.
I can live with it because this should improve the battery life 6 times. (wake up and reporting happening once per hour rather then 6 times). Meaning my batteries should run for a year. Good enough since I cannot force it to wake up every 24 hours as you suggest.

THanks for all your inputs! Drastic improvements!

edit3: this guy has the same issue with same device

Did max zwave wakeup interval change?

Why won’t it let me change the wakeup interval to be more than 3600 seconds? Did something change recently? I’m on build 2793. [wakeup] @chris Any idea what’s going on. Edit: Ok, so this only seems to be happening on the Aeon ZW100. So there must be something specific to this device that limits the wakeup interval to 3600 seconds. Edit 2: But I can’t find where this limit is defined.

maximum wake up 3600.
Someone suggested messing around with xml of the device, but i think i will just leave it alone

[apella12 (Bob Eckhoff)]

I do see an issue with the ZW DB for some of these devices. Unfortunately there are 4 ZW100 that look pretty similar. I’m guessing you have version 1.10 or 1.11, but please confirm. The issue is there are three 201 parameters that overlap. Assuming no temp calibration is needed, set the parameter “Temperature calibration in 0.1 deg steps” to 1 from zero. Also the Calibration unit parameter needs to be 1.

On the 3600, check the Controller UI tab. Maybe the UI thing tab change didn’t stick. The controller needs to reset after the change and I’ve seen where the UI thing change didn’t do that, but the UI code tab did. Even if the code shows 86400, change it to 43200, then back to 86400 and see if that allows a higher value on Node6

[vanja (galaxy)]

• versionMin 1.10
  I guess this is the version.

there is no calibration, its already set to zero.
for calibration unit i have a selection of celsius or fahrenheit to click. which one is 1 ?
controller UI shows 86400, I even disabled and enabled the controller and all the devices went offline for 2 minutes. all of them picked up the new value of wake up 86400 - except ZW100. It still persists 3600. nevermind, case closed, I had this set on 600 and this was the reason for the battery burn.

[apella12 (Bob Eckhoff)]

Ok dropping the wakeup.

The background for my suggestion to clear the Warn gets into byte masking. It might help to look at the code tab and have the manual explanation on parameter 201 open while reading this to confirm what I think is going on. Parameter 201 is a two byte parameter and has three entries config_201_2, config_201_2_000000FF, config_201_2_0000FF00. The config_201_2 parameter is like config_201_2_0000FFFF as all 2 byte values are allowed. I’m not an expert on all the nuances, but basically the “F” allows any hexadecimal value (0 to F) and the “0” blocks it.

I have opened a ticket to the developer to delete the config_201_2 because it is redundant and is causing the WARN message. Changing it to “1” is a workaround until that happens. It will not cause any calibration to occur because calibration is set in the second byte. What it will do is cause config_201_2 to match config_201_2_000000FF Both will be 0x0001, so the Warn will go away. This would be a lot more complicated if you were using the calibration

[Magnus (Magnus Franzén)]

Hi!
I have been using the Aeotec Multisensor 6 for several years and it has worked perfectly without any problems.
I have used 2 batteries at the same time and these last about 1 year.
I have configured it as below.

In the first 201 (Temperature Calibration Unit) I chose C°.
In the second 201 (Temperature Calibration Value) I entered the decimal value I wanted to correct the temperature with.
eg. 10 = +1.0° and -10 = -1.0°.

I found more information here.

ES%20-%20Multisensor%206%20V1.13.pdf

Maybe this can be helpful.

[apella12 (Bob Eckhoff)]

@Magnus

In the first 201 (Temperature Calibration Unit) I chose C°.

The problem I described is related to the third 201 parameter that is only visible on the UI page if you click advanced. The default is 0 and could override (or try to override) the parameters in the other two. I don’t have the device, so am not sure how it sorts any conflicts. I’m pretty sure that the temp unit sticks because the device should reject “0” as not allowed (but as noted above OH springs a WARN if the device is version 1.10). As to your calibration value I don’t know. You could check the code tab. If my math is correct you want F601 or 62977 for the unmasked 2 byte value.