Zigbee Devices Experiencing Battery Drain w/OpenHab

Setup, Configuration and Use Runtime
,
1

Hello all!

I am running Openhabian 2.4.0 (release build) for some time now on a Raspi 3. I have the husbzb-1 stick powering my z-wave and zigbee needs. Z-wave has always worked flawlessly with this sitck and build of Openhab, but my zigbee devics are finicky all of a sudden and I’m trying to understand why exactly.

I was originally on Winkhub v1, and had slowly moved a few zigbee sensors (basically all of them are for monitoring my first floor windows and doors) off to Openhab, and for the most part they worked. I did notice though that the battery drained in them rather fast and I was having to replace the button cell batteries every 1-2 months vs the 6+ months the others were running without issue.

I figured at that point, it was one of two things: interference from a bad zigbee devices on the zigbee network or more than likely interference from the winkhub trying to poll things. Well, I made the switch off about ~3 months ago from Winkhub to Openhab completely and the Winkhub has been disconnected and offline for quite a while now. The only other thing around creating possible interference is the 3 x Ubiquiti APs I have (one downstairs, one upstairs, one above my garage in a playroom). I am contemplating moving the Openhab setup closer to the middle of my first floor to give equal coverage, but before I do, need to pick some brains.

Basically what’s happening right now is my zigbee sensors seem to need to be refreshed with new batteries every month or so. Before I ran them nearly a year before having to change those batteries on the same devices. Trying to figure out what exactly the issue is. Is it wifi interfering? The winkhub is in the same spot as Openhab is now, and nothing else changed.

Looking @ the APs right now here are the bands being used for their transmission:

Playroom - Channel 11 (set to auto) for 2.4ghz, and channel 38 for 5ghz (auto)
Downstairs - Channel 6 (auto) for 2.4ghz, and channel 46 for 5ghz (auto)
Upstairs: Channel 1 (auto) for 2.4ghz and 151 (auto) for 5ghz

The openhab setup is close to the garage wall and nearer to the playroom AP, and I can see that the zigbee (via the ember controller) is set to channel 11. Trying to set it to auto, it just goes back to 11 anyways. Wondering if it’s worth trying to bump it up? I also set the zigbee to boost and high power mode to see if that will help.

Any thoughts?

I’d switch to z-wave sensors but I need at least 12 and that’s going to be, bare min, about $150 bucks US, and I already paid that out with Zigbee about a year ago :-/

The other thing I have is a sonoff bridge that I may or may not have flashed with the custom firmware (I have to check) and dozens of the 433mhz sensors that came with the original Digoo security system I bought a while back. I could always take a stab at integrating that bridge via MQTT to Openhab, but how annoying! I already have things setup nicely with the zigbees, and I’d like to solve the battery drain issue!!!

Thoughts would be helpful!

Quick update: I was able to set the channel up to 25 (furthest away from the 2.4ghz wifi network as I can get with it). Everything zigbee says it’s now online including the one sensor in my living room that was not wanting to connect up. I think I’ll still see about moving it, but would like additional thoughts, especially around the battery drain issue.

2

There have been major changes to the zigbee binding and it’s supporting libraries since OH 2.4. This includes Power Mode, Transmit Power, Child Aging Timeout, Min/Max Reporting Period, and Polling Period… LOTS of things that could help you. Upgrade to OH 2.5M6, or wait until 2.5 is released in a little over a week.

Everyone should have their Zigbee network on Channel 25 to avoid interference with WiFi.

I gave up on Zigbee due to battery usage and moved everything to Z-Wave, except for some mains powered devices. Well… that and I was tired of disconnects.

3

Only thing I can think of is if you look in HabMin at the devices, there maybe a property to adjust the polling frequency. Poll less often and maybe battery will last longer.

Scott mentioned battery usage as a problem with zigbee devices and my experience is similar. I only have a few Hue devices that still use zigbee. I have a Hue motion sensor and it uses 2 AAA batteries every 2 or 3 months. I may have turned the polling frequency up because I use it for real-time lighting.

Only other zigbee devices I’ve ever had were smart things. They did truly pound the batteries to death in weeks, all of them. Eventually, like Scott, I went the zwave route. Chris likes the zigbee protocol a lot but I don’t know if it is the devices themselves have poor firmware that uses to much battery or what

4

Thanks!

I tried moving to 2.5M6 and Z-Wave broke horrendously for me (zwave portion of the usb stick kept flapping).

I’ll also wait until the official release to see how it goes. I do remember seeing some options in that version for zigbee device polling and such.

I did set my channel to 25 (had to do it in habmin as paperui wouldn’t stick), and the one sensor on the other side of the first floor came back so that’s good I guess.

Will see how things go between the changes there and when 2.5 is officially released.

I think I probably will end up on z-wave sensors, but will have to replace a couple at a time due to cost :frowning:

5

My experience is that ZigBee devices generally perform better on batteries than ZWave, but I guess it comes down to the devices themselves. Unfortunately it’s pretty hard to really comment in detail on what could be happening as there’s no logs to go on.

Generally, the binding should not poll devices - it should be using reporting, but again, I can’t say if that’s the case here. You could try reducing the reporting rate, but really, I think that’s unlikely to make a significant difference unless the reporting rate is set really low. (this is not available in 2.4 so actually you can’t do this).

I think the channel issue is really dependant on what else you have in the area - eg other phones, wifi etc. It may or may not help of course.

Really I’d recommend looking at the logs to try and see what’s happening - it’s probably more helpful than speculating :wink:

6

I can provide logs. Just let me know what I need to do to generate and pull them and I’ll pop them in here :slight_smile:

7

There’s a section in the binding doc called something like “what to do when things don’t go as planned” - that describes enabling logging in the binding.

8

Duh I should RTFM lol.

Ok, debugging enabled for zigbee.
How long should I let the debug logging run for?

1 Like
9

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
10

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.

11

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

12

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

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.

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.

13

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

14

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

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 -:

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.

15

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.

16

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.

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

17

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.

18

From past readings (mostly your posts :heart:) 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

19

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

20

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?