Dead again after about 6 hours of movie / tv streaming. I love how in all the Kickstarter updates they never mention what a failure the battery on this remote is or what they intend to do to fix it. But hey, we’re gonna get a Selection UI widget, Media browsing & Auto-mapping for keys. That should be fun for a couple hours of use until the remote battery dies again. This piece of shit remote may be worse my previous R2.
Kevin T
That’s why I ordered the Sofabaton X2.
Let’s see how this remote works.
I’ll wait for the Remote 4 — the Remote 3 is garbage.
Let us know how the X2 works for you. I’m about ready to dump this shiny turd and wash my hands of anything UC related ever again.
Kevin T
What causes the drain in non-sleep? Is it the wifi? Would ditching integrations, turning wifi off, and using BT/IR commands only give longer wake time?
I got mine (bought from a guy here on forums). While I was just checking the web config - had to have the remote nearby (not in home cinema). Almost the whole time the remote was actually in “standby” (or whatever you call it, i.e. the screen was off), because I was programming some scripts and stuff in another program. In less than 2 (yes, TWO) hours the battery completely drained - so that I had to run to the cinema to put on the dock, lol. I have no idea what is going on here 
Perhaps @marton can chime in to acknowledge the battery issue and update us on plans to improve it?
Marton already answered on Discord that there are no issues with battery (Discord).
Battery life depends on usage and can be impacted by a lot of (background) things. The remote could e.g. regularly be woken up by other devices while it’s sleep mode, custom integrations could be running (unnecessary regular) polling processes and permanent reconnecting tasks to integrations and docks may also affect the battery life in the long run.
There were also users that noticed the battery indicator may no show the correct percentage and the remote continues to run for hours even with 0%. This should be solved by letting the remote fully discharge and charge it again.
Perhaps he could comment for those of us who have remotes randomly discharging while docked.
When I had this, it was an integration that was constantly disconnecting and reconnecting again. Not saying it’s definitely that, but it was that for me.
Please elaborate
I could see an integration that was showing in the Web Configurator as disconnected and then it reconnected and that was draining my battery faster than the dock could charge it as it kept repeating that.
This was the Android TV integration and in a previous version, one of the beta features caused constant disconnected.
So it’s worth checking to see if one of your integrations is causing the drain.
I’m going through the logs now. I see nothing that talks about connecting or disconnecting. The appletv integration sure does a lot of polling though, updating attributes.
Hey, Lutz from UC here. Things got a bit heated in here, so just a quick update to cool it down and clear things up: yes, we’re on the battery topics and continue to improve.
Two things are getting mixed up: battery percentage reporting vs. real standby drain.
The “0% / sudden drops” behavior is a known battery gauge issue with coulomb counting. It’s not a real battery level drop, but the level is reported incorrectly. We’re testing fixes internally.
Some good news: we’ve already got standby consumption improvements internally. The bigger gains involve an MCU firmware update for a microcontroller, so we’re being extra careful and testing a lot before rolling it out. With the current internal work we reached a significant improvement in sleep current while keeping Wi-Fi connected in standby.
Current best settings (today):
Wi-Fi on in standby / Bluetooth off, the Bluetooth part of our radio module can be a bit erratic right now and can push standby up to roughly ~20 mA.
About Prevent Sleep option in activies: if that’s enabled, the remote is basically fully on, so ~6 hours of battery life can be totally normal. Awake power is on average around ~1.5 W, but it depends a lot on the use case, especially how many integrations are running and what they are doing. For example, integrations trying to constantly connecting to unavailable devices or producing lots of log information.
One more important point: we can’t fully control what third-party integrations do. We’ve already seen cases where some keep the CPU busy or trying to constantly connect even when it looks like “nothing is happening”, and that will hit battery life hard. So if you’re seeing heavy drain, please try disabling extra/third-party integrations temporarily to see if the behavior changes, it’s a very quick way to narrow things down.
Please be nice - We’ll share more as soon as the next improvements are ready to ship broadly.
Appreciate the update. This is helpful. Look forward to the improvements making their way through.
Thank you @lutz ! I appreciate the update. Moving forward, if the UC folks could be a little more transparent on issues like this, and provide more regular updates, it would help keep things cooler and make us all feel better about our purchase!
I was suspecting this because it showed 0 % but was still staying on (at least for several minutes until I ran to the cinema and put in in dock)
Thanks for the update! Regarding the battery level calculations: I’ve done enough battery management systems myself. I’ve found a mix of coulomb counting and frequent calibration when certain conditions are met the best way to do it. Not just when it’s above Vmax or below Vmin. I could see using the battery voltage directly after longer wakeups a good way to do it. Because then the voltage drop because of consumption should be more or less identical on every occasion. Then map voltage to SOC, depending on battery chemistry.
Also: please add the battery voltage to the API. Then I could do this myself and show it via an integration.
I’ve switched to the settings recommended by @lutz (keep wifi connected during sleep & BT Off) and I can confirm battery life is so much better for normal use than what I was doing before. Responsiveness is very good as well with the retry, even when for example, reaching over to mute or adjust volume when the remote is sleeping. Feeling very good about the R3!
I have an activity called Watch TV, which includes my Sony X95L using Android TV integration and Denon x3800h receiver with Denon integration. Everything works great IF i keep it on prevent sleep. If I turn prevent sleep off, wifi on in standby and bluetooth off then, yes, battery life improves. BUT often times after coming out of standby when using the remote I get the message that either the TV or receiver is not responding, which then results in having to reboot the remote. Anybody else have this problem?
R3 with firmware 2.8.1? If yes direct in the settings on the remote, I think in power savings, is a option resend command and a time. Increase time to 10 seconds. With this option the remote tries to resend the command up to 10 seconds.
Ralf