Insane battery drain for ikea on-off remote using zha - SOLVED

Thanks to the new migrate radio feature I decided to try to upgrade the radio from the first gen conbee usb stick to the Sonoff “ZBDongle-P” (based on CC2652P). Everything seemed to work at first, but I quickly noticed that my ikea on-off remote now only last one day with a new battery. I don’t have that many c2032 batteries left so I’d like some advice what I could try next. Each try is costing me one battery so as few tries as possible would be nice.

I upgraded the firmware of the sonoff stick to the latest from Koenkk (CC1352P2_CC2652P_launchpad_coordinator_20220219) before using the stick. The firmware on the IKEA remote is 2.3.079, which I believe is the latest.

I tried using the CONFIG_MAX_END_DEVICE_CHILDREN: 0 setting in the HA config but it didn’t make any difference.

I changed back to the conbee stick for now in order to see where the problem could be.

Is this something that specific to the the zigbee stick or is it something with ZHA… a combination? Could I change any settings in the remote itself to solve this?

You might have seen the huge thread for the IKEA 5-button remote which regularly behaves similarly:

The 5-button remote latest firmware is 0x23080631 using the ZHA upgrader, however I gave up with the one button version as it just wouldn’t pair with ZHA / Sonoff 3 USB / Yellow.

One suggestion is the IKEA remotes keep broadcasting if the mesh changes, discharging the battery quickly. Removing the dead CR2032, adding a new one, mashing the reset button, and re-adding it in the final location (to see the final mesh peers) might work.

For me, it tended to directly pair the button with a nearby non-IKEA Zigbee bulb meaning I now had two devices that needed a factory reset!

Z2MQTT is suggested to be better than ZHA for handling IKEA “protocol additions” but I’ve not tried it. Replacing the non-standard IKEA remotes was easier for me (although the mains switches work well).

You are not alone, as I’m sure you’ve seen from the thread referenced above. As a simple thing to try, pair the remote to a repeater in your mesh rather than the coordinator itself. I’ve had some luck in zha with this and the ikea remotes, but it is hit and miss…

Yes - always pair the device in the FINAL LOCATION where it will be used.

Unlike Z-Wave (which recalculates with mesh every night), Zigbee seems to not like mesh changes, and some devices ignore new router devices right next to them.

This is not typically a problem for IKEA remotes, as the battery will die after a day, ZHA will refuse to re-interview the device, forcing a factory reset and new interview regularly! :sob:

I’ve run the old conbee usb stick for 5 days now and the battery is still going strong… still using ZHA. I’ve also used this zigbee device for many years before and never had this problem. So my question is: Is it the sonoff (CC2652P) firmware that is causing this? What HW suffers from this problem? Which zigbee devices have you tested?

I have about 10 IKEA 2- and 5-button switches and never had battery problems with them for years. However, I use them via deconz and not ZHA. :frowning:

I don’t necessarily think it’s ZHA that is at fault. If you use deconz that means you use a conbee Zigbee device. For me conbee doesn’t cause any excess battery drain even if used with ZHA.


I’ve now tried using the same problematic zigbee router (ZBDongle-P”) with Zigbee2MQTT instead of ZHA. Only the the IKEA on-off button was paired with the zigbee stick this time to rule out the other routers being the problem. With this setup I have no problems with battery drain, so I think we can conclude that it is ZHA which is doing something that drains the battery in combination with certain zigbee sticks. I’m not sure how to troubleshoot further, but if I can be of assistance solving this problem I’m willing to help.

At last it seems to be fixed. After updating the firmware Koenkk to the 20221226 version I see no excess battery drain in ZHA anymore. The switch is now registred as unk_model by unk_manufacturer, but works just fine withouth quirks, so it was either the firmware or the quirk that was previously used that was the cause. In any case I’m marking this as solved now.