Zigbee Devices Experiencing Battery Drain w/OpenHab

[OpenHabDad]

Logs have been captured.
Seeing a lot of the following in the logs:

2019-12-07 21:46:57.136 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ManagementLqiRequest [0/0 -> 57746/0, cluster=0031, TID=18, startIndex=0]
2019-12-07 21:46:57.140 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=57746/0, profile=0000, cluster=49, addressMode=DEVICE, radius=31, apsSecurity=false, apsCounter=24, payload=00 00]
2019-12-07 21:46:57.145 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - EzspSendUnicastRequest [type=EMBER_OUTGOING_DIRECT, indexOrDestination=57746, apsFrame=EmberApsFrame [profileId=0, clusterId=49, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY, EMBER_APS_OPTION_RETRY], groupId=0, sequence=24], messageTag=24, messageContents=00 00]
2019-12-07 21:46:57.262 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspSendUnicastResponse [status=EMBER_SUCCESS, sequence=38]
2019-12-07 21:46:57.264 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspSendUnicastResponse [status=EMBER_SUCCESS, sequence=38]
2019-12-07 21:46:57.859 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspMessageSentHandler [type=EMBER_OUTGOING_DIRECT, indexOrDestination=61732, apsFrame=EmberApsFrame [profileId=0, clusterId=49, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY, EMBER_APS_OPTION_RETRY], groupId=0, sequence=31], messageTag=17, status=EMBER_DELIVERY_FAILED, messageContents=]
2019-12-07 21:46:57.861 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspMessageSentHandler [type=EMBER_OUTGOING_DIRECT, indexOrDestination=61732, apsFrame=EmberApsFrame [profileId=0, clusterId=49, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY, EMBER_APS_OPTION_RETRY], groupId=0, sequence=31], messageTag=17, status=EMBER_DELIVERY_FAILED, messageContents=]
2019-12-07 21:46:57.900 [DEBUG] [com.sun.xml.bind.v2.ContextFactory  ] - Property com.sun.xml.bind.XmlAccessorFactoryis not active.  Using JAXB's implementation
2019-12-07 21:46:57.989 [DEBUG] [com.sun.xml.bind.v2.util.XmlFactory ] - SAXParserFactory instance: com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl@174f714
2019-12-07 21:46:58.147 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingMessageHandler [type=EMBER_INCOMING_BROADCAST, apsFrame=EmberApsFrame [profileId=0, clusterId=1, sourceEndpoint=0, destinationEndpoint=0, options=[], groupId=0, sequence=213], lastHopLqi=255, lastHopRssi=-51, sender=46274, bindingIndex=255, addressIndex=255, messageContents=F6 FD FF 00 00]
2019-12-07 21:46:58.150 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=46274/0, destinationAddress=0/0, profile=0000, cluster=1, addressMode=null, radius=0, apsSecurity=false, apsCounter=213, payload=F6 FD FF 00 00]
2019-12-07 21:46:58.153 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: IeeeAddressRequest [46274/0 -> 0/0, cluster=0001, TID=NULL, nwkAddrOfInterest=65533, requestType=0, startIndex=0]
2019-12-07 21:46:59.288 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=61732]
2019-12-07 21:46:59.290 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspIncomingRouteErrorHandler [status=EMBER_MAC_INDIRECT_TIMEOUT, target=61732]
2019-12-07 21:46:59.664 [DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction timeout: ManagementLqiRequest [0/0 -> 61732/0, cluster=0031, TID=16, startIndex=0]
2019-12-07 21:46:59.670 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 000D6F000B02B5D8: Node SVC Discovery: ManagementLqiRequest response CommandResult [TIMEOUT]
2019-12-07 21:46:59.675 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 000D6F000B02B5D8: Node SVC Discovery: request NEIGHBORS failed after 13 attempts.
2019-12-07 21:46:59.678 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 000D6F000B02B5D8: Node SVC Discovery: running
2019-12-07 21:46:59.681 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 000D6F000B02B5D8: Node SVC Discovery: complete
2019-12-07 21:46:59.685 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 000D6F000B02B5D8: Node 61732 update
2019-12-07 21:47:00.137 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingMessageHandler [type=EMBER_INCOMING_BROADCAST, apsFrame=EmberApsFrame [profileId=0, clusterId=1, sourceEndpoint=0, destinationEndpoint=0, options=[], groupId=0, sequence=214], lastHopLqi=255, lastHopRssi=-51, sender=46274, bindingIndex=255, addressIndex=255, messageContents=F7 FD FF 00 00]
2019-12-07 21:47:00.141 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=46274/0, destinationAddress=0/0, profile=0000, cluster=1, addressMode=null, radius=0, apsSecurity=false, apsCounter=214, payload=F7 FD FF 00 00]
2019-12-07 21:47:00.144 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: IeeeAddressRequest [46274/0 -> 0/0, cluster=0001, TID=NULL, nwkAddrOfInterest=65533, requestType=0, startIndex=0]
2019-12-07 21:47:00.557 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspMessageSentHandler [type=EMBER_OUTGOING_DIRECT, indexOrDestination=20636, apsFrame=EmberApsFrame [profileId=0, clusterId=49, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY, EMBER_APS_OPTION_RETRY], groupId=0, sequence=37], messageTag=23, status=EMBER_DELIVERY_FAILED, messageContents=]
2019-12-07 21:47:00.561 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Unhandled EZSP Frame: EzspMessageSentHandler [type=EMBER_OUTGOING_DIRECT, indexOrDestination=20636, apsFrame=EmberApsFrame [profileId=0, clusterId=49, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY, EMBER_APS_OPTION_RETRY], groupId=0, sequence=37], messageTag=23, status=EMBER_DELIVERY_FAILED, messageContents=]
2019-12-07 21:47:03.005 [DEBUG] [com.sun.xml.bind.v2.ContextFactory  ] - Property com.sun.xml.bind.XmlAccessorFactoryis not active.  Using JAXB's implementation
2019-12-07 21:47:03.095 [DEBUG] [com.sun.xml.bind.v2.util.XmlFactory ] - SAXParserFactory instance: com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl@9332e0
2019-12-07 21:47:08.110 [DEBUG] [com.sun.xml.bind.v2.ContextFactory  ] - Property com.sun.xml.bind.XmlAccessorFactoryis not active.  Using JAXB's implementation
2019-12-07 21:47:08.184 [DEBUG] [com.sun.xml.bind.v2.util.XmlFactory ] - SAXParserFactory instance: com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl@8a9c83

[chris (Chris Jackson)]

If I remember correctly there’s a setting in the binding to configure the mesh update rate - try increasing this.

After 2.5 is released I plan to do an update which will not send these messages to battery devices. That said, I don’t think it will matter as you can see here that the device doesn’t respond so this probably means that it is sleeping and therefore it doesn’t matter what the binding sends it as it won’t respond.

[TheNON (Marcell)]

Hi @chris,

sorry for bothering with my question, but as the last entry in this thread is more than 6 months old and I am experiencing battery drain too, may you provide some update if there was any improvement implemented?

For info I tried the following devices:

• IKEA Tradfri remote (reporting battery related channels) / purchased a long time ago
• IKEA Tradfri motion sensor (reporting battery related channels) / purchased a week ago
• IKEA Symfonisk sound controller (NOT reporting battery related channels) / purchased a week ago

Summary:

• however all of these devices were struggling due to some issues with openhab, they were paired succesfully with the binding
• the remote I returned several months ago, so i have no recent information about it (in the meanwhile i bought a new one, but not paired yet)
• at least the motion sensor and the sound controller were reporting “mains” as power source (again, I cannot remember what the remote was reporting)
• all of the devices’ batteries were drained within few days
• I am already running on replacement battery for the sound controller (I will waste some in the other devices later on)

thanks for the info in advance

[chris (Chris Jackson)]

@TheNON

sorry for bothering with my question, but as the last entry in this thread is more than 6 months old and I am experiencing battery drain too

Please can we keep the discussion on one thread - you asked also this question about battery here -:

Howto: Symfonisk Controller with zigbee binding

Hi Bruce, Many thanks for the quick reply. Right now I am facing to a different issue, as all my battery devices were drained. In this case this one and an ikea motion sensor, but some months ago it happened to me the same w an Ikea remote, the battery became empty just in few (4-5) days. So I replaced the battery in the symfonisk, but it did not react to anything any longer. Removed from OH, then added/paired again, but except for the discovery, I see no kind of activity at all. I let the…

As suggested there, I need a log to see what is happening. There should not be any reason that the binding is impacting the battery life, but if there is, then I’d need to see a log to know what is happening.

@TheNON

may you provide some update if there was any improvement implemented?

As stated above, I don’t expect any change in the binding. Battery devices normally manage their own battery - they sleep most of the time, so the binding is normally unable to send data to them even if it wanted to.

[TheNON (Marcell)]

Hi Chris,

Thanks for the quick response
The other thread is about capturing a toggle switch and tuning the dimmer of a specific zigbee device, true, I was mentioning there that I had recently a battery issue.
The reason of asking about the battery here is, that in one hand I did not want to mix up the threads in the other hand I’ve experienced this in case of more devices.

If you prefer, we can abandon my comment made here and continue over there.
Thank you

[chris (Chris Jackson)]

@TheNON

The reason of asking about the battery here is, that in one hand I did not want to mix up the threads

But you already asked in the other thread (yesterday) about battery -:

@TheNON

Right now I am facing to a different issue, as all my battery devices were drained.

Ok, let’s discuss here then - I don’t mind, but it gets confusing when there are multiple conversations going on about the same thing in different threads.

As I’ve said here and in the other thread, the binding doesn’t really control a devices battery. Battery devices generally sleep most of the time to conserve battery. Remote controls do not ever receive commands except during inclusion in general, so I would not expect them to wake at all. Therefore even if the binding sends stuff to the device, the device should be sleeping to manage its battery.

This is the same answer as I made last year -:

@chris

I don’t think it will matter as you can see here that the device doesn’t respond so this probably means that it is sleeping and therefore it doesn’t matter what the binding sends it as it won’t respond.

From the log that you provided to allow me to look at battery life in the other thread, there is no activity - I think there were around 120 messages sent by the binding in a 7 hour period - this is pretty low. I’m not sure what the devices are, but most of those messages were in response to either OTA transfers (so probably to a bulb) that the device made, or as part of a new device joining the network.

I really don’t see any issue with the binding - it is not sending data, so should not impact the device battery as far as I can tell.

[TheNON (Marcell)]

Thanks.
The 7 hour period of “silence” is due to the fact the device was unresponsive after pairing and discovery. I added it in the morning again and then it was ok. (14B457FFFE799778).

I have uploaded some more daily logs, a recent one from today and a short readme file.
The device is reported on paperui as online.

I appreciate your efforts and understand the information you’ve provided in here and also accept if you’d prefer to close the battery issue I’ve raised according to the above definitions in your reply.

[chris (Chris Jackson)]

@TheNON

The 7 hour period of “silence” is due to the fact the device was unresponsive after pairing and discovery.

That maybe, but the point I was making is that the binding isn’t trying to send anything during this time. If the device was silent, and the binding is silent (as I would expect for a battery device) then the binding is not going to have an impact on the device.

@TheNON

I have uploaded some more daily logs

Where are these uploaded to? I can’t see a link…

[OpenHabDad]

I’ll be honest here. Never fixed the issue. It got a little better with the release of openhabian whatever version around that time where I could set the zigbees to not talk as much, but ultimately I’m now on hubitat.

I also moved from zigbee largely to zwave as it just worked better.

In the end I think it boiled down to a few things:

• openhabian getting gunked up and never clearing cache

• zigbee interference from wifi even after channel adjustment

• was in a previous home (moved since then) with metal doors and windows and such which I think added to the issues

• zwave/zigbee stick…I went through two and neither really worked well

That was the pro and cons of OpenHab for me. Open, easy to do once you got behind the learning curve, but open enough that mileage really varied.

I’m at the point and age in life (40 ish) where I love tinker but I just want stuff to also work, so I ended up on hubitat and it’s worked for me for what I need at my new place.

[TheNON (Marcell)]

From past readings (mostly your posts ) I understood that how it should work with battery devices.
I confirm that I got your point

Here are the logs (MMDD.log naming format).
Dropbox

[chris (Chris Jackson)]

@TheNON

Here are the logs

Thanks. Please can you provide a debug log of the binding startup.

[TheNON (Marcell)]

Ok, I am trying to manage these remotely on my phone as I am in the office.
A restart of openhab is fine or you prefer a different action to be performed?

Edit: is there any additional setting is needed? You mentioned explicitly “debug”. According to my understanding the debug levels are set according to the binding page. Is there anything else needed?

[Bruce_Osborne]

Debug log instructions are in the binding documentation. When things don’t appear to be working.

ZigBee - Bindings

[chris (Chris Jackson)]

@TheNON

A restart of openhab is fine or you prefer a different action to be performed?

Restarting OH is fine - it might just make the logs a lot bigger than just restarting the binding so that would be my preference. If you are already going into the console, then why not just restart the binding with the restart command?

@TheNON

According to my understanding the debug levels are set according to the binding page.

Most of the logs you have uploaded a few minutes ago do not have debug enabled.

[TheNON (Marcell)]

@chris

do not have debug enabled.

Strange… thank god, to be on the safe side, yesterday evening I’ve set them again.

the restart.log is provided in the same location Dropbox
on the phone i could not filter out the exact time, therefore the last 5000 rows are provided (roughly 20 minutes).

ps.: I promise I will improve my skills on linux…too

[chris (Chris Jackson)]

Thanks - I will try and take a look later. The binding is polling this device a lot, and it seems this device does not sleep, so there is likely some improvement that the binding can make here and it could well be impacting the battery so I think we can improve this.

[TheNON (Marcell)]

@chris

there is likely some improvement that the binding can make here and it could well be impacting the battery so I think we can improve this.

Sounds good, many thanks for the investigation and future efforts.
Until that I will remove the device as it makes not much sense to replace the battery in every 4-5 days.

[chris (Chris Jackson)]

I’ve made a small change that should help with what I saw in your log earlier. This extends the polling for any battery device.

Hopefully this works ok for most devices.

Use extended polling for RFD

[TheNON (Marcell)]

Thank you, looking forward to 2.5.8

[Bruce_Osborne]

Once the build is updated, you can use the manual install script to install a snapshot binding with the fix.

Zigbee and Z-Wave manual install script - Tutorials & Examples - openHAB Community