I wonder if it’s doing some scaling like the luminosity on the battery. Maybe that’s 1% just means it’s below 1.5v (3.0v) or something? I’ve got one at 10%, I will let it run until it stops reporting and see how long it lasts at 1%.
Yeah the battery reporting troubles me. If the sensor sends 255 that’s is the low battery alert as far as the sensor is concerned. The code translates it into 1% which triggers SmartThings low battery notification and gives you a chance to change the batteries. Also if you have rechargeable batteries in there beware. The sensor will suck the voltage down to the point normal chargers won’t charge them. The sensor requires the battery state to be pulled as it doesn’t send it by itself.
Battery went to 1% on July 4th. It is still reporting today, I’ll keep watching it and see how long it works.
edit: Update, still running on 8th of July.
Update: Still running on the 8th of July.
Robert,
Looking at the v1.2 code there may be a typo causing a problem with checkBattery here:
commands(resuest)
should be:
commands(request)?
I fixed and my battery reporting seems fine.
BTW - thanks for your effort getting these sensors to work. I ordered two and with the fix above everything seems in order and working fine. I get the comments on the illuminance thing being a bit weird will have to write down different levels vs actual perception of room. Heres the table on lux readings from wikipedia, I’m guessing we hit 100% around a 320-500 lux reading (actual).
Examples
Illuminance Surfaces illuminated by:
0.0001 lux Moonless, overcast night sky (starlight)[3]
0.002 lux Moonless clear night sky with airglow[3]
0.27–1.0 lux Full moon on a clear night[3][4]
3.4 lux Dark limit of civil twilight under a clear sky[5]
50 lux Family living room lights (Australia, 1998)[6]
80 lux Office building hallway/toilet lighting[7][8]
100 lux Very dark overcast day[3]
320–500 lux Office lighting[6][9][10][11]
400 lux Sunrise or sunset on a clear day.
1000 lux Overcast day;[3] typical TV studio lighting
10000–25000 lux Full daylight (not direct sun)[3]
32000–100000 lux Direct sunlight
1 Like
Ah jeez! Thanks! I can’t believe it was so simple. I’ll adjust the code.
1 Like
Fixed the typo you pointed out and did more testing. Fresh rechargeables showing 30% which is a bit disturbing. if they are going on voltage, perhaps that is why. I set my wakeup interval to every hour by hand so I can monitor it more closely. I also added event generation for battery events so you will see the reported battery levels in the “recently” tab as well, not just in live logging.
Also found another issue I had handling the version command class. you may have noticed some errors in the live logging where it couldn’t parse a command. I’ve fixed that in the updated code as well. The sensor uses V2 of the version command class but ST is only supporting V1… So I call V1 and now am letting the handling of it be ambiguous which is working.
Now it reads the zwave and firmware version in the live logging.
11:28:04 AM: debug —VERSION REPORT V1— Office Sensor is running firmware version: 5.1, Z-Wave version: 4.5
Version number of the DH is the same for these minor fixes. I know, bad, but whatever. 
I agree something is up on the battery reporting. It’s the 13th and my zooZ has been on 1% since the 2nd. I’ll keep going until it stops.
figured out the battery issue.
The device was designed around alkalines… alkalines have 1.5 or more volts to start while NiMh only has at most 1.4, but that top charge quickly drops off to around 1.2-1.3 and then stays pretty steady until they die pretty hard. That explains the behavior completely. I can put a preference in for rechareable / alkaline and have some math put against the reported value but it wont be perfect, just somewhat more accurate… Need to figure out the curve to get it close… I wrote the vendor and we’ll see what she says. To data, Lorenz HD has been super responsive and open to feedback.
That’s what I expected, it seems like it isn’t really report battery life %, but against some voltage and we need to map that to a curve. (likely wrong, back of napkin as I write this post) Super simple linear would be 100% = 3.0v, 30% = 2.5v (1.25x2) and that gives us (.00714v/%) 2.21v @ 1%, or 1.1v/cell.
edit: found a quick curve with both NiMH and Alkaline @ 200mAH just for reference.
NiMH and Alkaline Discharge Curve
I was thinking about this last night. Most devices have a range of voltages they work with. Three AAA Nimh batteries would be 3.6 volts, just .6 volts higher than two alkalines. I kind of want to hack in another battery and see what happens. Longer battery life and higher battery reading… The only drawback besides killing the sensor (unlikely) is the actual low battery point would be higher making the batteries less likely to be chargeable without manual intervention once you did need to charge them. I just went to charge a couple batteries I had in an Aeon Multi, and they won’t charge and are nearly new. The voltage was down to .02 volts which really destroys Nimh batteries. I would love to see @TheSmartestHouse make a new version with a built in Li-poly battery pack and USB charge port with higher capacity than the Nimh equivalent, and a magnetic mount for easy change out. I just place mine on shelves so the mount isn’t a big deal for me for changing batteries but I imagine for some who mint them up high it would be more an issue for.
1 Like
Thanks for the feedback @Robert_Vandervoort! We’re trying to get more information on the battery level mapping for you guys to be able to program the sensor for more energy-efficient performance. We’ll definitely try to include a USB charge port in the next version and work on the mount. Not sure if a large magnet to hold the sensor would not interfere with radio communication. But we’ll work out a way to simplify mounting and optimize battery life - these are both very important aspects of any smart home product so we have no choice but to figure it out soon!
We collect all requests and suggestions and pass them on to product development so do keep them coming
Battery reporting based by percentage never works with rechargeables–as mentioned upthread, they don’t have the same discharge pattern as nonrechargeable’s. Just physics.
If you plan to use rechargeable batteries in a home automation device, you should just put your replacements on a time-based schedule.
1 Like
I got an email from Zooz where they identified this Advanced handler code for their ZSE40:
(1% Started on the 4th of July)
19th and still going on 1% (Alkaline).
Love the sensor, it’s similar to the Aeon…but much more accurate. It also seems to be more robust, my Aeon’s don’t last long (sensor life, not battery life). It also has the right set of sensors.
As you have noted, the mount is usable…but it’s ugly and HUGE. Give me a Aeon type mount and sane battery life and I’ll buy a dozen of them!
Thanks for sharing your experience @rsnow! Reworking the mount is on our list, we hope to have a new improved version of the sensor ready in the next few months. Will be sure to announce it here once it arrives
Our engineers confirmed that the sensor is designed for use with alkaline batteries only, as already explained by @JDRoberts so unfortuntaely, battery reporting will not work well with rechargeables, sorry @Robert_Vandervoort!
We will continue to look for a way to optimize battery life and make documentation very clear on which types of batteries are to be used with this device. Thanks again guys for helping us make this sensor better!
2 Likes
Great news on all fronts. I’d add in that there are some weird scalings that the engineers are doing that aren’t clear:
- Battery Monitoring: It’s weird even with Alkalines. I’ve got a sensors that has been on 1% since the 4th of July, I’m going to let it run until it stops to get an idea of actual battery life vs. reported.
- Battery Life: related to above since we don’t actually know battery life at this time, but it sure does seem to report very often, which uses battery.
- Lux Readings: I get the goal, but Home Automation folks are pretty savvy and would just assume get the raw data and make their own assumptions and scalings.
Keep up the awesome work and please take my list as positive feedback and not a knock. If it sucked, I’d just throw it away and not bother trying to give constructive feedback.
2 Likes
Thank you for the detailed feedback @rsnow. We are trying to get more details from the engineers about battery monitoring. Did you see any rapid drops in battery reports before it went down to 1%?
We will adjust default polling and wake-up times to conserve energy in the future release.
Well noted about lux - unless the engineering team comes up with a solid argument against it, we will make the change.
Let us know if you think of anything else, this is all super helpful!
Thank you for being receptive, but PLEASE confer with someone with much more experience than me like @JDRoberts or @Robert_Vandervoort on what makes sense, I’m just a part-timer with some personal wishes…they are the pros!