I've known nimh batteries have less voltage than a disposable alkaline. I can see and hear the difference between the two from my smart shades.
I did not, however, realize until recently that 1.5V lithium rechargeables have an inner cell voltage and an IC converts it to 1.5V. That's how they're all done; that is why 1.5V Lithium is known to have a very flat output voltage as the state of charge decreases under load.
Why does this matter?
I've noticed some community or more open device drivers can expose the raw battery voltage along with preferences to configure a derived battery life percent calculation. I assume drivers that do not expose the low-level voltages either handle that privately, or the device has an IC that handles it in hardware. Parsing a battery life reading, from a hardware implementation with no exposed configuration, will involve a hard-set battery cell voltage.
This creates a challenge for owners of battery-hungry devices that are designed to use 1.5V Alkaline (if the owner prefers rechargeable):
nimh batteries do not provide enough voltage for motors in things like shades. Other devices may base "battery life" on the voltage curve of alkaline disposables and present chronically low battery level readings that can drop steeply at lower charge levels.
Rechargeable Lithium is 1.5V, so high-drain devices like smart shade motors are happy, but the voltage of these stays the same until a sharp drop-off before full discharge. No warning about shades dying, that could become stuck mid way while on holiday, is not good either.
It would be nice if devices with replaceable consumer batteries could expose parameters or stick to designs that expose advanced configuration values so that setting OTS configuration during device inclusion could lend consistency of battery life data.
I'm going to try and use 1.6V Ni-Zn Rechargeables in some of the devices that require regular battery replacement.
I went this route, and all 3 brands had major failures. EBL, Tenergy and don't recal the other. While these worked they were great but had a high failure rate, even with the specialized charger. Now about 12-15 years ago, Ray-O-Vac had near perfected this technology. I surmise when they saw they were killing their own sales, they discontinued this fantastic product. I still have 2 of these Ray-O-Vac NiZnrechargable alkaline batteries that still work!!!
While this video focuses on AA batteries, it does a good job of covering different battery chemistries, their performance over time and some best use cases for the battery chemistry.
I was also fan of rayovac nimh. Their early 00's "hybrid" and 15min rechargeables were peak. They licensed the 15min to radioshack too. I was rocking those in my graphing calculator for years.
The EBL Ni-Zn I got are working well in my smart shades. That extra voltage really helps the shades open and close quicker. I doubt the shades will report a timely low battery level though. I'm open to a pleasant surprise.
The pace of my shades with the Ni-Zn vs even Lithium continues to impress. My concern about battery status reflective of the cells I've installed remains. I believe something, be it hardware of software, applies an assumption that doesn't accurately produce a battery status reflective of the actual remaining life or state of charge.
I'm doing a comparison test on rechargeable performance in my Third Reality Smart Shades. Its not scientific by any means.
I've got two shades in one room gradually opening, triggered based on a dashboard settable "shades open alarm time" variable, and then gradually closing starting from a static offset before sunset. More details here: Strategy for Controlling Multiple Shades / Devices - #7 by user2599
And... Earth's poles flipping worries me less than my blinds inverting
The shades come with alkaline AAs, but each shade takes 4 batteries. It's designed for (guessing series) 6.0V. I've got more than these two too, so I am not interested in tossing pounds of alkalines annually.
I put 4x of EBL USB (the earlier gen with micro-usb) Lithium Rechargeables in the shade, of the two, that travels the most each day. I replaced them today, after maybe a month.
Before, I had used EBL or Eneloop nimh. The slow struggle-bussing sound of only 4.8V was annoying, but it got more sad sounding when the batteries were running lower on charge.
With the integrated voltage converter in the rechargeable lithium, the constant voltage makes the sound consistent- no audible warning. I have battery alert notifications setup... I received a warning this morning that the shade with the EBL USB Rechargeable Li-ion was at 0% battery . With the nimh I'd get progressive warnings starting at 45%, and the lower voltage of a set of 4 freshly charged nimh AAs starts off with a battery level of 65-80ish%. I have days to replace the nimh after the initial wsrning. The Li-ion were pegged at 100% until they were suddenly 0%. I checked the events and logs.
I've now got Ni-Zn 1.6V installed in both the shades. Those things move with a purpose with 6.4V vs the 6.0V of the lithium, and make the 4.8V nimh sound like eeyore.
Does anyone know if the source for the generic zigbee shades driver is available? I'd like to know if a voltage reading is getting parsed.
Im hoping to at least have advance notice of the Ni-Zn batteries running low, via my alerts, with the stock driver. More optimally, I'd like to have accurate battery life readings, maybe just hardset for whichever battery chemistry I end up choosing. If that is possible, Ive got further ideas.
At this point, I know I wont be using lithium in my shades going forward. Im waiting to see if the voltage vs charge level of the Ni-Zn align whatsoever with the stock driver. If so, I can achieve my minimal goal by adjusting the battery alert correspondingly. For example, if the parsed battery level reading dips from 100% a few days before the Ni-Zn are drained, I can set alerts for a range at or below that initial dip. If, however, the parsed battery level drops but too quickly (only a few hours) before the batteries are drained that would indicate, if the driver can be tweaked, that it may be possible to adapt the parsed battery level readings to give more advanced notice. If that were to fail, but I still rly prefer the Ni-Zn to the nimh... I may consider having a low battery alert trigger a rule to make the relevant shade close, and flip a boolean value somewhere to prevent shade opening rules from acting on the shade with (assumed dangerously) low battery.
Is there a process to submit a change request in pursuit of an improved battery level parser and maybe expose configuration preferences to support different battery chemistries?
There’s a forum category for feature requests here.
Many people find that battery reporting in most small sensors tends to be too unreliable to be all that useful, no matter how much effort is put into Hubitat driver code optimization.
One of my shades with Ni-Zn Batteries finally drained enough for a change. I have low battery notifications set for levels below 50-45%. The Ni-Zn first received a notice when the "level" was 17%. I did not leave the batteries in to find out how much more life they had- I may do that for the other shades with the same Ni-Zn Batteries. I'm happy the Ni-Zn lasted much longer, the shades benefit from the higher voltage, and there is at least some limited notice when the batteries are low on charge.
TL;DR- i highly recommend Ni-Zn Rechargeables in devices designed for alkaline.
Feel free to use it as a a base for your own. My driver has an auto-retry feature I added long before Hubitat added theirs, since I had tons of trouble with them responding 100% of the time when commanding a room full at once.
Sweeeeeet. Line 72 is where one would apply changes to account for a different battery chemistry/voltage, ya?
Also, if i wanted to POC a preference for battery cell type... The section around Ln42 looks good.
I've never really read through custom or community drivers, or written in groovy. Should be fun.
I suspect, even with your driver, that the shades direction randomly inverting still happens? IIRC that's assumed a device-level issue.
It’s a mechanical issue. If the shades go all the way down without hitting the end stop button they’ll unspool all of the cord inside them, then once fully unspooled they’ll continue turning the motor in the same direction (down) but now the cord starts wrapping around the spool the other direction and the shades start going up.
The shades MUST be installed such that they hit the end stop button before fully bottoming out. If you have them installed somewhere that they can fully extend without hitting the button then they’ll do this “reversing” issue.
They could fix it in firmware by remembering the motor direction just before it shuts off from being fully open then changing which way is “down” next time you operate them but I don’t think they do that.
I don't think so. So let's say you press "down", and the motor turns one direction, let's say it's clockwise. It turns clockwise and the cord inside the shade starts to unspool. If the shade doesn't hit the endstop it will keep turning clockwise until it's completely unspooled, then it will keep turning, spooling the cord around the drum inside the shade the other direction, and the shade will start to move upwards. Now if you hit stop, "down" will move the shade up and "up" will move the shade down.
EBL has disappointed me a bunch recently. I have 48 of their rechargeable CR2 batteries that I found really worked well, but just 4 years later they no longer sell them anywhere. The last set of non-rechargeable CR2s I got them from didn't last long at all. Recently I got some CR2032s from them that were supposed to have a 5 year shelf life, but the neither the package or the batteries have a date stamp on them.
. With the nimh I'd get progressive warnings starting at 45%, and the lower voltage of a set of 4 freshly charged nimh AAs starts off with a battery level of 65-80ish%. I have days to replace the nimh after the initial wsrning. The Li-ion were pegged at 100% until they were suddenly 0%. I checked the events and logs.
