I added the latest Ikea firmware to the shortcut button last Thursday and it was working great.
went away for a few days.
Came back yesterday to a dead battery 
My biggest issue now is I bought two more shortcut buttons, but lost the receipt, so can't take them back (unless they are registered with my Ikea Family profile).
Are you using that with Home Assistant and ZHA or zigbee2mqtt?
I have the Ikea motion sensor setup in zigbee2mqtt on one of my Pi4 devices and the battery drain is at a decent rate.
Using with Home Assistant and the Zigbee integration. But I’ve heard similar results with DeCONZ to HA too.
Just reporting in that my test E1812 button is still working fine and still reporting 2.9 V. The battery was replaced on 19th November, so we're 17 days in now.
Any idea why Hubitat (or maybe the driver) does a presence check every 10 minutes?
Firmware update 2.3.080 has really messed up one of my buttons. The other one I'm not updating.
Not sure; the hub and driver can't affect the button once it's gone back to sleep after a press. The only opportunity they have for communication is within a 3 second window following a button press, or during the initial pairing. Other than that the button is on its own and we have to rely on its internal sleep timer.
What I have no idea about is what the button does to drain its battery so quickly under poor network conditions. Perhaps it goes crazy trying to communicate with any nearby device it has previously seen.
Hmm, I'm on 2.2.9.146 at the moment. What happened?
I recently picked up a zigbee 3.0 coordinator to use with my pi4 and zigbee2mqtt so I could use the Ikea Tradfri devices I have that Hubitat doesn't support.
Did the firmware update using zigbee2mqtt and the latest firmware seems to have messed up the device binding, resulted in the action being null.
Used the annoying Ikea hub to update the firmware, thinking the update using zigbee2mqtt broke it; nope, wonky firmware.
Tried a few things I found online to try and fix the bind issue, but no luck.
That one is back in the box.
Battery voltage down to 2.8 V as of 1am last night.
We're coming up on the 1 month mark! 
Hey thanks for your work.
Subscribed to this post to see the development. I currently use the mast76 driver code on my shortcut button. I just updated the firmware of the button to see if it increases battery life.
I might try your driver to see if there is any improvements.
I'd add that this driver seems more developed than what mast76 did. I'm not sure it's because I updated the shortcut button with Ikea hub, but when I repaired the button with hubitat, I had errors on presenceMethod not found on mast76 driver. I changed the drivers to yours and so far so good. I'll monitor the battery and keep you posted. The battery state is at 100% since yesterday.
What information does your recently-updated button show in the Data section from the Device page?
That's mine, I'm just wondering if there's been a firmware bump and how it's reported.
If there has been I could try an update after this battery test. Currently still 2.8 V.
BTW, if you didn't reconfigure the device when you changed driver, the button itself will still be behaving precisely as it did under the other driver. The reconfiguration is only performed on re-pairing, or when the Configure ‘button’ is pressed within 3 seconds of a physical button press (because the button only stays “awake” and able to receive a message for that long).
The firmwareMT attribute did change!!
I did hit configure button a few times and even had to repair the button a few time because button pressed wasn't reported at all in the logs (even with all debug logs activated).
Here is the before firmware update:
And after:
Here is a picture of an updated button (2.3.080 firmware) without having paired it to hubitat prior to updating the firmware. As you can see, it reports software build, inClusters and outClusters but on my older button, it does not. I could test some stuff for you if you want. I could try deleting the older button and repair it as I feel like mast76's driver is still partially used even though I'm using your driver and I've hit configure/repair/refresh multiple times.
On the battery side, I've measured the battery voltage to make sure all battery was 100% and so far so good. It reports 100% battery on all my button shortcuts (I have 6). Some of them even report higher than 3V (3.1v, 3.2v)
Here are the logs of a freshly bought button, updated to firmware 2.3.080 and paired to HE with your driver after having it paired to Ikea Hub. I'm wondering if you could find some interesting stuff:
dev:4122021-12-15 16:02:19.367 infoButton E : Battery : 100% (3.10 V)
dev:4122021-12-15 16:02:19.364 debugButton E : batteryVoltage : 3.10
dev:4122021-12-15 16:02:19.361 debugButton E : batteryVoltage sensor value : 31
dev:4122021-12-15 16:02:19.359 traceButton E : batteryVoltageHex : 1F
dev:4122021-12-15 16:02:19.357 traceButton E : processMap() : [raw:901B0100010A2000201F, dni:901B, endpoint:01, cluster:0001, size:0A, attrId:0020, encoding:20, command:01, value:1F, clusterInt:1, attrInt:32]
dev:4122021-12-15 16:02:19.354 debugButton E : Parse : read attr - raw: 901B0100010A2000201F, dni: 901B, endpoint: 01, cluster: 0001, size: 0A, attrId: 0020, encoding: 20, command: 01, value: 1F
dev:4122021-12-15 16:02:18.320 infoButton E : Trigger : Button 1 Pressed
dev:4122021-12-15 16:02:18.318 traceButton E : processMap() : [raw:catchall: 0104 0006 01 01 0040 00 901B 01 00 0000 01 00 , profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:901B, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:00, data:[]]
dev:4122021-12-15 16:02:18.314 debugButton E : Parse : catchall: 0104 0006 01 01 0040 00 901B 01 00 0000 01 00
dev:4122021-12-15 16:02:13.595 traceButton E : sendZigbeeCommands received : [he raw 0x901B 1 0x01 0x0001 {10 00 00 20 00}, delay 2000]
dev:4122021-12-15 16:02:13.592 infoButton E : Refreshing
dev:4122021-12-15 16:02:13.556 traceButton E : Trace Logging : true
dev:4122021-12-15 16:02:13.554 debugButton E : Debug Logging : true
dev:4122021-12-15 16:02:13.552 infoButton E : Logging : true
dev:4122021-12-15 16:02:10.753 traceButton E : sendZigbeeCommands received : [he raw 0x901B 1 0x01 0x0001 {10 00 00 20 00}, delay 2000]Thanks for that, looks like it's all behaving itself. Interesting about the reported data and more sensible softwareBuild information on the newer unit. I've also not seen one of my buttons report greater than 3 V before.
I think I figured something out. On the old picture with the old firmware (2.3.015) you can see next to firmwareMT: 117C-11C6-23015631. I believe the 23015 stands for 2.3.015. In the newer screenshot, you can see next to firmwareMT: 117C-11C6-23080631 which is the newer firmware 2.3.080. It looks like the attribute softwareBuild is not being updated because it was from the old driver from mast76. I wonder if I completly delete the device and repair it, if it will use the newer attributes.
Just to be kept posted. If it is a simple software update, that does the trick, I will get my old Gateway up and running again.
Can you explain the purpose of this function? I understand it checks each 10 mins if the button checked in in the last 120 minutes or 280 if we missed one. But what is the purpose?
Is it possible to log it as info instead of warn?
def checkPresence() {
// Check how long ago the presence state was updated.
int uptimeAllowanceMinutes = 20 // The hub takes a while to settle after a reboot.
if (state.presenceUpdated > 0) {
long millisNow = new Date().time
long millisElapsed = millisNow - state.presenceUpdated
long presenceTimeoutMillis = presenceTimeoutMinutes * 60000
BigInteger secondsElapsed = BigDecimal.valueOf(millisElapsed / 1000)
BigInteger hubUptime = location.hub.uptime
if (millisElapsed > presenceTimeoutMillis) {
if (hubUptime > uptimeAllowanceMinutes * 60) {
sendEvent(name: "presence", value: "not present")
logging("${device} : Presence : Not Present! Last report received ${secondsElapsed} seconds ago.", "warn")
} else {
logging("${device} : Presence : Ignoring overdue presence reports for ${uptimeAllowanceMinutes} minutes. The hub was rebooted ${hubUptime} seconds ago.", "debug")
}
} else {
sendEvent(name: "presence", value: "present")
logging("${device} : Presence : Last presence report ${secondsElapsed} seconds ago.", "debug")
}
logging("${device} : checkPresence() : ${millisNow} - ${state.presenceUpdated} = ${millisElapsed} (Threshold: ${presenceTimeoutMillis} ms)", "trace")
} else {
logging("${device} : Presence : Waiting for first presence report.", "warn")
}}
It, erm, checks how long ago the presence state was updated. 
This is how a device's presence state would go from being present to not present without requiring the driver to be triggered by the device itself.
Every 10 minutes checkPresence() runs and if the threshold is reached, the presence state is changed. That way you know if you have devices dropping off your mesh, either due to a low battery or something more nefarious. I use this as a means of generating a push notification with Pushover so I know as soon as possible whether there are issues.
Not much point in that, just check the device's presence status.
Question regarding FW-update, do one need an IKEA gateway or is there a possibility to use the built-in Device Firmware Updater i HE? Would like to avoid buying more hardware just to update stuff.
I don't think you can. Honestly, Ikea GW is 30$...
Download the Hubitat app
