Excessive Battery Usage Monoprice Z-Wave Plus Door/Window Sensor (24259)

Devices & Integrations
1

Ok So I’ve installed Qty 2 of Monoprice Z-Wave Plus Door/Window Sensor (24259).and they both are excessively draining a new set of batteries in just a few days.

I looked at the live log feed (see bottom of post for example) and what it’s showing is ironically that every 5secs the device is sending a battery status update.

What I’ve tried:
(1) I initially used the default device handler & executed the inclusion routine for the sensor as a secure device (hold inclusion button for three seconds during paring). Result Excessive Drain.

(2) I excluded the sensors/ factory reset / dropped from network.

(3) Added them back in using RoyBoy Monoprice Handler. Executed the inclusion routine for the sensor as a secure device (hold inclusion button for three seconds during paring). Result Excessive Drain.

(4) Did this again: I excluded the sensors/ factory reset / dropped from network.

(5) Added them back in using RoyBoy Monoprice Handler. Executed the inclusion routine for the sensor as a NON SECURE Device press inclusion button three times quickly during paring). Result Excessive Drain.

Don’t know what else to try - the RoyBoy handler & the Monoprice install guide both say that the default wakeup time is supposed to be Zero for the device (only wake up on contact open)

Any ideas?

duke3k

12:32:38 PM: debug Parse returned [[name:battery, unit:%, value:47, isStateChange:true, displayed:true, linkText:Door Front Door, descriptionText:Door Front Door battery is 47%]]
12:32:38 PM: trace BatteryReport: BatteryReport(batteryLevel: 47)
12:32:33 PM: debug Parse returned [[name:battery, unit:%, value:49, isStateChange:true, displayed:true, linkText:Door Front Door, descriptionText:Door Front Door battery is 49%]]
12:32:33 PM: trace BatteryReport: BatteryReport(batteryLevel: 49)
12:32:28 PM: debug Parse returned [[name:battery, unit:%, value:47, isStateChange:true, displayed:true, linkText:Door Front Door, descriptionText:Door Front Door battery is 47%]]
12:32:28 PM: trace BatteryReport: BatteryReport(batteryLevel: 47)
12:32:24 PM: debug Parse returned [[name:battery, unit:%, value:48, isStateChange:false, displayed:false, linkText:Door Front Door, descriptionText:Door Front Door battery is 48%]]
12:32:24 PM: trace BatteryReport: BatteryReport(batteryLevel: 48)
12:32:19 PM: debug Parse returned [[name:battery, unit:%, value:48, isStateChange:true, displayed:true, linkText:Door Front Door, descriptionText:Door Front Door battery is 48%]]
12:32:19 PM: trace BatteryReport: BatteryReport(batteryLevel: 48)
12:32:14 PM: debug Parse returned [[name:battery, unit:%, value:50, isStateChange:true, displayed:true, linkText:Door Front Door, descriptionText:Door Front Door battery is 50%]]

2

That’s correct, it should be sending battery reports every 25 hours. All of our test devices have been on the same battery for a few months all between 99% and a 100% - so something isn’t right.

Couple of things to check:

  1. What battery are you using? (alkaline?)
  2. How far is the device from the nearest z-wave repeater/active device?
  3. Check if the device cover was left open accidentally

Try this:

  1. Exclude your device
  2. Reboot your hub
  3. Include the device

Keep your IDE Live Logging open during this time and you should see some debug logs, the device handler will ask the device to report it’s wake up time and you should try to catch that debug message. I’m wondering is somehow the data is getting corrupted or something which is making it wake up more often.

Feel free to email our support team and we can look into what’s going on.

3

RBoy,

Thank you for the things to try. Short answer is that none of it worked so here’s the run down / answers to your questions & Suggestions.

(1) Answers to your questions

What battery are you using? 
  - I'm using alkalines and 2 brand new sets have been depleted in just 2 days

How far is the device from the nearest z-wave repeater/active device?
  - both sensors are about 40' away

Check if the device cover was left open accidentally
 -nope.

(2) exclude / reboot / include. ( capture of live log during inclusion at bottom of this post)
Did not make a difference when I excluded these specific devices and re-added them.
Same behavior every 5 secs bat status was being sent.

(3) I did the device handler modification you sent me in the PM , published it , excluded the device / re-added it . No difference.

(4) What did make a difference temporarily was this:
- I was adding in another Zwave Device (a Kwikset lock) and was having problems to get it to include
- I did a general exclusion of all zwave devices
- rebooted the hub
- I was then able to succesfully add the Kwickset lock
- and then later in the evening I noticed that the Door sensors (both of them) had stopped sending the battery status commands. I thought great - all it took was a reboot of the hub.
- So with that problem seemingly solved - I decided to put a brand new set of Alkalines in the front door sensor and as soon as I did the sensor started sending batt updates every 5 seconds.

- as a test I left the backdoor sensor alone ( it was still behaving after the reboot w/ it's old batteries) and let it run all night - and it worked fine .. no bat status every 5 seconds - battery level remained constant thru the night.   This afternoon - I changed the batteries with a fresh set and it immediately started sending 5 sec bat update commands.

***************** Here’s live log during re-association of one of sensors - this was before your recommended device handler changes ******

784f6a10-74e8-4361-869c-6b74cb645d94 1:43:21 PM: debug Parse returned [[descriptionText:Monoprice Z-Wave Plus Door/Window Sensor (24259) MSR: 0208-0201-0008, isStateChange:false, displayed:false, linkText:Monoprice Z-Wave Plus Door/Window Sensor (24259)], 8002]
784f6a10-74e8-4361-869c-6b74cb645d94 1:43:21 PM: debug msr: 0208-0201-0008
784f6a10-74e8-4361-869c-6b74cb645d94 1:43:20 PM: debug Parse returned [[descriptionText:Monoprice Z-Wave Plus Door/Window Sensor (24259) MSR: 0208-0201-0008, isStateChange:false, displayed:false, linkText:Monoprice Z-Wave Plus Door/Window Sensor (24259)], 8002]
784f6a10-74e8-4361-869c-6b74cb645d94 1:43:20 PM: debug msr: 0208-0201-0008

cb81ac5f-44ab-4aaf-8fce-20d92a41ca87 1:43:20 PM: trace in ssdpDiscover
cb81ac5f-44ab-4aaf-8fce-20d92a41ca87 1:43:20 PM: debug scheduled run, numberOfRuns: 3
cb81ac5f-44ab-4aaf-8fce-20d92a41ca87 1:43:20 PM: trace in discovery
784f6a10-74e8-4361-869c-6b74cb645d94 1:43:20 PM: trace Configure called
33eb324f-961b-46ff-9f8a-c183a58ca673 1:43:20 PM: debug Update detected: DeviceCreated 784f6a10-74e8-4361-869c-6b74cb645d94
784f6a10-74e8-4361-869c-6b74cb645d94 1:43:19 PM: trace Configure called
784f6a10-74e8-4361-869c-6b74cb645d94 1:43:19 PM: trace Installed called settings: [:]

cb81ac5f-44ab-4aaf-8fce-20d92a41ca87 1:43:06 PM: trace in ssdpDiscover
cb81ac5f-44ab-4aaf-8fce-20d92a41ca87 1:43:06 PM: debug scheduled run, numberOfRuns: 1
cb81ac5f-44ab-4aaf-8fce-20d92a41ca87 1:43:06 PM: trace in discovery

4

It all looks okay, if the reboot/repair of the hub solved the issue the first time I would suggest try that again. Unfortunately we’ve never seen anything like this before.

It may be a quirk with your hub and I think this is what may be happening. After device wakes up and send the reports, the hub sends back a command to put the device to sleep. So I’m guessing either that command is getting lost somewhere or something else is going on between the hub and your device(s).

Try the reboot thing again. Worst case you can try to contact Monoprice support and see if they’ll send you replacement sensors and if still continues to happen it may be related to your hub.

(I know the some Yale locks have been acting up and they suspect it’s the hub firmware but I don’t know if these are two correlated). I dare say it could be a bad hub, the best way would be if you have access to another hub and paired the devices with that hub to see if that still happens.

One last thing you could try is being the devices closer to hub, open and close the cover and see if the distance is causing the issue.

I’ll see if I can whip up some mode debug stuff to help isolate what maybe going on.

5

Rboy,

Sorry it took so long to respond. I installed the custom Debug Handler that you whipped up for the Zwave Monoprice Door sensors and unfortunately no luck. The sensors are still sending updates every 5 seconds.

I have since even added some Zwave repeaters, repaired the network , dropped and re-added the sensors so many times I can’t count.

At this point I’m convinced that it is a bad batch of sensors and not my hub .- there are now quite a few recent reviews on Amazon of many people complaining about execessive battery drain as well.

I’m sending these back and getting something else. Really frustrating.

I sincerely appreciate you responding to my posts and the effort you put into the custom handler.

all the best.
duke3k

6

I just purchased 4 of these, getting the exact same problem with one of them, the other 3 seem fine so far (only been installed 2 hours so far)

7

Got couple of these. More than 1/2 are showing huge battery drain problem. I also saw a similar log (as OP mentioned) on ST live logging.

I started with the batteries in the package. Installed in the late afternoon, by noon next day battery state went down to low 10% and by afternoon they became unavailable.

Rest are doing OK till now.

8

Don’t rely on the packaged batteries, we’ve seen duds sometimes. If they’re down in a day, it’s a bad batch. Try putitng new ones in.

9

50% RMA rate 5 out of 10 have failed and two of these have the exact same problem showing 1% battery life after a couple of weeks, with zero activity on each of the sensors. These are garbage in my opinion and I regret purchasing them.

10

Before retuning, I tired new batteries on 2. Same result.

11

Just ran across this same issue with the last of three sensors I purchased back in late March via Amazon. I have attempted all of the above listed recommendations from Rboy and others without success. Was anyone else able to correct the issue with a defective device, or is the best course of action to return / replace?

12

I’m having a strange version of this. I have a battery notification piston (webcore) that let’s me know the battery state of all devices. In my sunroom I have two of these. One SIPS battery very slowly. The other starts at 100% and by the next day or so is at 1%.

Now here’s the strange part. It can stay at 1% for weeks. I’m wondering if this is different from the above or the same issue and people just didn’t realize it might be the sensor just being horrid at reporting battery life. I only replaced my batteries as I was tired of seeing the 1% alert all the time and assumed it was a bad set. Nope.

1 Like
13

It’s more like this, the sensor sends a low battery warning. ST in turns translates a low battery warning as 1% (unfortunately ST specs don’t define what a low battery level is, some devices it’s 25%, others is 10%, it’s very device dependent). So the low battery warning ends up as 1% even though the actual % may be higher. Basically indicating it may be time to change the battery as the next update may not come if the voltage drops too low. Most cases it’ll continue to work. Some cases it may stop working with no warning. Batteries are also notorious, some die quickly without warning (manufacturing detects).

14

Thanks. Just completed a product swap with Monoprice before getting this. Hoping the next one is as reliable as the first one.

15

I am having this issue of battery drain. Every 5 seconds sending status of the battery burns through it. Dead in 2 days. I will contact Monoprice about this. Hopefully I will get a new and non bugged one.
I am glad to read that it’s not just me.

16

I just installed one yesterday. The manual said something about it by default only sending status when open/closed is triggered, but also being able to set a custom interval to send regular updates. Maybe that “default” is sometimes set differently. I haven’t looked into how to change that value, but it might be worth taking a look.

17

I had the same problem, thought it was a DH problem but different ones it still reports battery constantly. I also read that the original batteries were garbage but the ones I provided still had the same issue. Going to RMA.

18

Was the problem fixed after you RMA’d the devices. I am having low battery issues with the following sensors.

If anyone has found a fix… please let me know.

19

I would start by resetting the device and then try adding a z-wave repeater close by which can help extend battery life

20

so what you are saying if there is no repeater They will drain the batteries and report 1% every 5 to 10 secs? That seems weird.

Also so fresh batteries should last longer than 2 days.