I am currently experiencing a extreme battery draining on these sensors. I have to replace the batteries every 3-4 days. I use to following device handler: “https://github.com/krlaframboise/SmartThings/blob/master/devicetypes/krlaframboise/zooz-4-in-1-sensor.src/zooz-4-in-1-sensor.groovy” The settings are as follows:
• Primary Status: MOTION
• Round The primary Status to a whole number?: OFF
• Secondary Status: NONE
• Temp Scale: 0
• Temp Change Trigger: 50
• Temp Off set: 0
• Humidity Change Trigger: 50
• Humidity offset: 0
• Light change trigger:10
• Light %Offset: 0
• Light Lux Offset: 0
• Report Illuminance as Lux? NO
• LUX Value to report at 100%: 50
• Motion Retrigger time: 60
• Motion Sensitivity: 2
• LED Indicator mode: 1
• Round Values to how many decimal places: 2
• Minimum Check interval: 4
• Battery reporting interval: 12
• Automatic clear Tamper? YES
• Enable debug Logging? NO
Can you please provide me with a solution to this issue?
what is the time scale, milliseconds,seconds,minuites?
It does not give an option for scale, it says 1=1hour so that would be hours.
if you are using rechargeables then these Zooz battery curves are not very useful since they report 1% for many months (3-5 months so far, for 2 devices in testing) while operating normally.
Other than that I would replace them with units from a different batch.
Has the sensor received its configuration? The DTH I use shows whether it was sent to the device or not. I’ve seen it take many hours as the configuration can only be sent when the sensor wakes up. One way to force it to happen right away is to press the tiny button behind the pin hole and pressing (in my case) the configure and refresh buttons. If not, then the settings may not actually be what the sensor is doing.
One reason for battery drainage is too many reports being sent back to the hub or communication issues requiring additional transmissions. Do you have a strong zwave mesh network in the location where you installed the sensor? Sometimes I wonder whether pairing the sensor close to the hub and then moving it to the final location might actually be part of the issue as the routing it selects is likely no longer appropriate and since it is a sleepy device a network repair is unlikely to update the routing to something appropriate… which may result in the sensor trying to communicate directly with the hub (if it was paired right next to it as often suggested). I built out my Zwave Plus network (which has NWI) so I always try to pair this sensor in its final location. An alternative, if this were not to work, is to wake up the sensor a few times (it only stays awake for 10 (?) minutes and the repair can take much longer) while the network repair is running. Hopefully this would adjust the routing as needed minimizing its need to “work harder” to get its messages to the hub.
When this happened to me a few times int he past I took the shotgun approach and excluded/re-included it. Problem went away but it was likely just due to a botched include or bad routing.
One last thing to consider is also the source of your batteries… I suspect there are tons of counterfeits on amazon or just old stock so I now buy batteries from Digikey as they are much more reliable for that type of item.
Very useful response.
The network is fairly large. There is about 45 repeaters around the sensors(all Z-wave plus). It seems plausible that it can be a botched include. I never had so much include issues with any other sensors. It took about one hour for one sensor to be included (there is 19 of them). It would include it as a window sensor, then I remove it and include it again, then it would include it as a z-wave sensor, then I would go through the same process until it picks it up as zooz. The batteries is high grade, so it can only be one of two things, Somehow there is a congestion on the network and it has to resubmit the info/if a botched include.
In my recent migration I had the same inclusion difficulties with the 4 in 1 Zooz sensors. I believe one sign of a botched inclusion was that the raw description in the IDE had several parts set to all zeros.
I currently have one in that state right now:
zw:S type:0701 mfr:0000 prod:0000 model:0000 ver:0.00 zwv:0.00 lib:00 cc:5E,86,72,5A,85,59,73,80,71,31,70,84,7A,98
All of my Aeon Recessed Door sensors are also failing to include properly.
I read somewhere that in the past this issue was due to the hub forcing a secure communication while the device (or DTH?) was not able to for whatever reason. I have yet to clear all my post v3 migration issues and this is one of the issues on my list.
I too have a strong Zwave mesh network but I am quite sure the routing has been my issue many times…
This is a partial (did not fit on screen) screenshot of my network:
Each device has the number of nodes it can reach. Device 127 happens to be the sensor with the botched inclusion and it says 0 Nodes even though there are at least a couple dozen zwave plus devices in its immediate vicinity. When I get a chance I will exclude and re-include to fix the issue…
WOW I thought that mine was big… It seems like the more devices you have on the network the harder it gets to include new devices. I Had a look, none of the devices had "zw:S type:0701 mfr:0000 prod:0000 model:0000 ver:0.00 zwv:0.00 lib:00 ".
I think it could be related, but every couple of hours the system gets unresponsive for a few minutes, after which it responds great again. but I can not see any error, I have redone this installation 5 times but get the same results, I even changed the hub, location of the hub, and moved all the rules from web-core to Core. but still the same…
Alex: whit the size of your network, have you ever experience to be chronically unresponsive?
There are multiple versions of this device so does yours take (2) AAA or (1) CR123A?
The device requires close to 3V to run properly so the manufacturer doesn’t recommend using rechargeable batteries.
Does the device show that there are pending changes?
Every time I’ve had a device join like this, removing it and bouncing the hub solved the problem.
Users on a different platform were having similar inclusion issues with this device and after watching the inclusion process with a z-wave sniffer I discovered that the device sometimes sends a wake up notification which causes the handler to put the device to sleep before inclusion finishes.
I wasn’t aware users were having the same problem with my ST handler, but now that I know I’ll make some changes to the handler tonight.
All that being said, that shouldn’t have anything to do with the battery draining. If you’re not using rechargeable batteries then you should be getting at least a couple of months out of the AAA or even longer with the CR123A and the 17.9 firmware.
If you’re only seeing this with one sensor you might want to contact The Smartest House’s support.
Man you guys are helpful!
I have the CR123A model, it seems to be a few but not all with this issue. However I was wondering if a botched inclusion could cause the device to malfunction in the network, and in so doing drain the battery, almost like a faulty network card that sends garbage over the network.
I have noticed that if the voltage drops below 2.5v the sensor stops responding. I think that is also a flaw, it actual only uses 0.5v of the battery and the rest is wasted?
I will remove all the sensors and include them with a reboot in between each.
Rebooting once before you start adding the devices should be all you need.
You may want to hold off until I release the updated version of the handler or temporarily add // in front of the line:
cmds << wakeUpNoMoreInfoCmd()
Make sure you remove the // after you’ve added the devices because that will cause the battery to drain very quickly.
Would it not be a idea to keep the // there and then run a repair, and after the repair you remove the //. This way the routing gets updated.
Alex I see you have over 223 z-wave devices on your network. Do you not have issues with running a repair. ST suport told me that they do not recommend running a repair, as this is causing more harm than good. Apparently anything bigger than 30 z-wave device network it is not recommended. This seems silly, I can not see how you would get the routing table updated if you can not run a repair.
The device automatically goes to sleep after about 10 seconds so that probably wouldn’t make a difference.
As long as the zwave repair is successful with my powered devices I’ve never had issues with moving sleeping devices after joining them…
When rebuilding my network when migrating from v2 to v3 I noticed that after adding 40 or so devices the inclusion process was getting very unreliable (failures, no inclusion message, super long waits, "botched inclusions, etc.). I wasted an incredible amount of time to do something that should be fairly quick.
If you have an issue with your network “every couple hours” then you likely have something happening every couple hours:
- You mentioned webCore I believe… do you have any seemingly harmless pistons scheduled to run every X amount of time? You might be surprised that an incorrectly written piston can cause major trouble to your network… I know cause I did it
- Do you have energy reporting devices? Could they be scheduled to report metrics every so often? I doubt a single device might cause this but it might be part of a multiple factor issue
- Interference caused by something that automatically activated every 2 hours?
Overall I would analyze anything in your house or close to your house that might have a “cycle time” that coincides with your issues. I would not exclude anything to begin with.
It is my understanding that batteries of different technologies have different voltage drop profiles while discharging. In other words a battery of one type will hold its voltage steady until it is nearly dead, and another type will have a more gradual voltage drop. The chart below just shows the difference between two different anode materials that can be used in Lithium batteries so not exactly what I was discussing above but the idea is the same. Also, due to the number of different batteries that are available, I believe it is hard for the device manufacturer to accurately “measure” the level of charge as the measurement would need to take into account the exact battery voltage drop curve. In the chart below, 20% charge is 3.5V for one and 3.2V for the other. Also, for devices that require 3V (and not less) the solid line battery would likely work until fully discharged while the dotted line battery would be useless 8% charge or so. It is my understanding that this concept applies when comparing Alkaline Vs Lithium Vs Li-Po Vs etc.
My Zwave Toolbox shows 107 Zwave devices. I used the migration to eliminate a number of older non Zwave Plus devices so it shrunk a little ;-). The ID you saw in the snapshot was a result of having to include/exclude devices so many times… ST uses the next available ID and reverts back to the unused ones once it has cycled through the entire range. The IDE shows over 200 devices but that includes everything ST shows as a device int he app (Zigbee devices, Harmony activities, Ecobee thermostats plus sensors, LiFX, Hue, Nest Protect, etc).
I thought it was 10 minutes… but the user manual confirms 10 seconds indeed. So my pressing the button to wake it up during a repair is unlikely to do anything.
Given the Zwave Plus routing is somewhat static unless you do a repair, how would the sensor reroute its messages to the hub via different nodes if you paired it right next to the hub? Pairing it next to the hub would create a direct hop between the hub and the device but once you move the sensor to its final location it might be best served by using intermediate nodes - even if it can reach the hub directly - to communicate with the hub. Do Zwave Plus devices vary their power output based on the size of the hop? If they do, then a poor routing might reduce battery life. If they don’t, but the poor routing causes them to have to retry the transmission, then that too might reduce battery life. I just do not know how “intelligent” the communication is between nodes… Our resident expert @JDRoberts might have some insight here Either way, one reason I replaced all my dimmers/switches with Zwave Plus models was to benefit from NWI (Network wide inclusion) so that I can pair devices in their final location and know/hope their routing should be closer to ideal (of course less hassle too).
@krlaframboise - I believe I am using your “Advanced” version of the 4in1 DTH. I will update it tonight and let you know if the sensors pair easier. Rebooting the hub has become my standard modus operandi when adding/removing devices given all the issues I have been dealing with. It has helped quite a bit. On a side note, I added an Aeon Recessed Door sensor to my HomeSeer ZFlash (to update its firmware) and it added perfectly within seconds. I definitely CANNOT say the same for my ST system given I tried for hours with tons of failures. The issue is the same… failure to exchange keys or something along those lines and the raw description is largely all zeros.
EDIT: I am actually using a different DTH:
Every device is different, but this one happens to be 10 seconds.
That DTH might have the same problem, but it’s using a longer delay so I can’t be sure.
I just released a new version that should help with inclusion reliability.
Last night I tried excluding and including the sensor with the botched raw description. While including it I pressed the “zwave button” every few seconds to keep it awake to see whether it would work better. In some cases I was getting 4 blinks or 5 blinks… not sure what those meant. Either way, all attempts resulted in it including much faster than the other day, but it was never recognized as the 4 in 1 sensor, rather it was being pulled up as a Zwave Window/Door sensor. After changing to @erocm1231 's DTH I was using, I was unable to sync the settings to the sensor even waking it up. On the plus side the raw description was perfect.
All attempts failed so I tried doing a regular include without pressing the zwave button several times during the process and it included relatively fast and using the correct DTH. The raw description was good too and I was able to sync the configuration right away.
I suspect that the inclusion issue I had the other day was caused by something else on the cloud side or maybe something on my mesh network was causing trouble (too much traffic). More relevant to this thread, the first few includes resulted in my sensor blinking very often (likely for motion and temp reporting but it was very frequent) which I am guessing would result in poor battery life.
@erocm1231 any idea if you need to implement @krlaframboise same fix to help with the inclusion process? I had a very hard time including my 6 4-in-1 sensors just a few days ago.
Last night, when pressing the zwave button only once (as per user manual) it was correctly recognizing the sensor as a 4-in-1 using @erocm1231’s DTH. The other day nothing I tried was working. Out of 6 sensors only one or two worked right away, the others required numerous attempts and some just did not include properly. That is why I suspect there was something else causing issues.