Iris V3 Keypad Low Battery Issues when using NiMH

I've been using the Nyckelharpa app for a while and I felt like I had it configured just about correctly. During the last week I had also been updating to the various releases of HE V2.2.5 and started seeing inconsistent behavior when working with the IrisV3 Keypad. I had been using NiMH batteries in it for about a month while it was working fine and they were reading 100% on the device (CentraliteX driver) page. I replaced the batteries with new alkaline cells and it seems like the stability improved but I still find it disconnecting with the blue light flashing when I try to use it for more than one thing during testing (arm/disarm followed by PANIC test). Is there a low voltage cutoff with the IrisV3 Keypad or these keypads a bit flaky (as I think I've read)? Is anyone having issues with them on HE V2.2.5? I bought 3 used but I'm trying to figure out the first one before I deploy any more.

Change the battery preference to Alkaline.

I believe it is normal for the IRIS icon to blink in Panic mode

Probably, but the usual symptom is the keypad stops woking

They are croissant level

1 Like

Another thing to bear in mind with respect to NiMH (as well as NiCd) is that there is a difference in full capacity voltages.

Alkaline = 1.5vdc
NiMH and NiCd = 1.2vdc (fully charged)

Logic from the Centralitex Keypad driver for IrisV3 battery reporting

if (device.data.model.substring(0,3)!='340')	//UEI and Iris V3 use 4AA batteries, 6volts
	{
	switch (BatteryType)
		{
		case "Rechargeable":
			excessVolts = (1.35 * 4)
			minVolts = (1.0 * 4)
			maxVolts = (1.2 * 4)
		break
		case "Lithium":
			excessVolts = (1.8 * 4)
			minVolts = (1.1 * 4)
			maxVolts = (1.7 * 4)
		break
		default:					//assumes alkaline
			excessVolts=6.8
			maxVolts=6.0
			minVolts=4.6
		break
		}
	}
1 Like

Nice!
They've already accounted for it!

I only mentioned it because most folks aren't aware of the fact that a difference even exists.

That's my user module.

The system provided Iris V3 module uses 3Volts max, 2 volts min for reporting. No preference setting for battery type.

1 Like

Very impressive!!

I can see I accidentally stepped off into the deep end. :laughing:
Had no idea. Didn't realize the OP was getting support direct from the source!

Just at the tip of the iceberg in trying to learn names and associations here. :slight_smile:

1 Like

I have a question. Why use a multiplication for the Rechargeable and Lithium but not for the Default? In other words, why not list the parameters as excessVolts = (1.7 * 4), maxVolts = (1.5 * 4), and minVolts = (1.15 * 4)?

Also in the ordering, why not keep the same order for all three?

excessVolts, maxVolts, and minVolts instead of reversing the min and max for the Rechargeable and Lithium?

Respectfully,

Stephen

On the battery volts, I wanted to make clear the single battery voltages for non alkaline batteries. Looking back at it, I could have used a comment eliminating a very small amount of cpu time.

Regarding the parameter coding order: no reason, it just happened that way and has no impact on the results.

Should the code be updated I will adjust this code :grinning:

1 Like

Thanks and back on this topic I'm finding that my keypad just disconnects every day or two even when inactive. It hadn't done this previously but I had made several hub firmware updates over the last few weeks so maybe related. The issue is that if I press any button eventually the blue light starts flashing and seems to continue indefinitely but I've only let it go for maybe 10 minutes. There is nothing in the logs and no response or action in HSM. The fix is to do a zigbee discovery. Sometime the discovery says it found an already added device and sometimes it just silently reassociates (init sequence of lights followed by blue light stops flashing) and then it seems to work again. It could be a flaky keypad like you said but I'm not sure how to troubleshoot it. Right now I'm using the CentraliteX driver and your pin code manager. Thanks, Joe

Sounds like this may be zigbee mesh issue. What happens if it's moved the closer to the hub?

I migrated to 2.2.5 this evening, and my Iris V3 is functioning normally.

Good advice and maybe. All my other zigbee devices are rock solid (I've been adding repeaters etc to improve the mesh performance) and I have two other zigbee buttons on the same table and both are rock solid. My problems don't seem to start until about 48 hours after "re-pairing" so it will be interesting to me if you have longer term reliability. The truth is that I bought these keypads used off of Ebay so ... Anyway, your advice is good. I'll move the keypad very near the hub and see what happens. I have two more Iris V3s so I can fire each one up and check if they exhibit the same behavior too. I appreciate the input.

One other thing to check. Go to the device's events page, then search for battery events. The Centalitex's driver battery description has the reported voltage and the calculated percentage.

I've noticed my V3 keypad exhibits strange behavior, such as falling off the network or not sending, when the voltage drops to around 5.2 volts using alkaline batteries. With fresh alkalines my keypad reports 6.3 volts. YVMV (your voltage may vary).

I checked it out and interestingly there are only two battery events in the log both of them are from almost two weeks ago. The first entry is when I installed the NiMH batteries and then when I switched the selector from alkaline to NiMH and the voltage was 5.1V and the percentage went to 100% so there have been no updates since then. I got it to update by running a refresh on the driver page and it says 5.8V, 86% for the alkaline batteries that I've had installed for the last few days. Is there something that I need to enable in the driver to get regular battery event updates or does it seem like I have a more fundamental issue with my keypad? I'm not sure how to check the firmware version etc.