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.
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
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)
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.
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.
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.
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.
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.
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.
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?
Most of the logs you have uploaded a few minutes ago do not have debug enabled.
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.