Zigbee Devices Experiencing Battery Drain w/OpenHab

Tags: #<Tag:0x00007fc20ff46860> #<Tag:0x00007fc20ff466d0>

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.

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.

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

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:

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:

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:

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.

Duh I should RTFM lol.

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

1 Like

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

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.