Battery reporting, still a problem in 2018

Yea I could prob find another thread and bump it… but really this should be in that ‘core competencies’ that any executive or even c-level people in ST/Samsung should be looking at with commitment. Why is it in 2018 we cant get accurate battery reporting? Heck how about telling me when a battery is low… Or at the VERY minimum, why not tell us when a device is dead for over 7 days.

The ‘story’ the long gone Alex loved to say started this company was a leak at his mountain cabin. First, must be nice, but still… if detecting water and reporting ‘started ST’… wouldn’t that be a core value? Well why did I just notice my sensor has been offline for >7 days, last reported 22% battery.

I may be the ‘odd one’ that has my home so well automated that I RARELY open the app… But isn’t that part of the goal for ST, make your home ‘just work’ or such. But adding a new sensor and bulb today I decided to check all the devices and boom, water leak sensor dead. In the MAIN location and like #1 location for flooding, laundry room. Thanks.

I wont even go into the fact that you still have to do the song and dance of removing stuff you didnt wanted added because “Super LAN Connect” … I dont want my Sonos speakers in ST… and every time you open to add a device boom…back. But thats another thread in itself.


There are no issues here. Move along. See, here is proof! #AlexWho?


Indeed, no issues here. Alex is no longer with SmartThings as of a few months ago.

The SmartThings division has, essentially, entirely new management. While we don’t know the exact details and organizational structure, there has been a substantial upheaval. Might as well give the new folks some time to figure out their priorities. Fair warning, though: they still may not align with any of ours, however.

Consumers don’t drive business strategy.

1 Like

This could be a good thing.

I’m fine with saying it is going to get worse before it gets better. The problem here is there are not any competitors to ST that have webCoRE!

as a workaround, since this is an open and inexpensive system, you can add and use SimpleDeviceViewer about once a week and check the battery list, and the last-reported list. It also has an automatic notification feature that I am not familiar with.

Maybe Control4 has perfect battery reporting in their closed system.


I do this. I also have a webCoRE piston I use.

Battery devices have a couple of issues. One is that different devices have different thresholds (see the first post of the link for details). Example some locks die at 50% while others die at 10%
Some low power devices go on till 0% and still keep functioning while others die around 25%. There are lots of reasons behind this starting from device incorrectly measuring and reporting battery levels (firmware issues) to different types of batteries with different voltage curves. I had published a couple of posts around on this issue and how to tackle it as well as how to select batteries. Mismatching batteries to devices can be problematic also, e.g if the firmware has been designed to measure alkaline battery discharge curves then using a lithium ion or a nickel metal hydride battery in those devices will create havoc with the battery reporting.

The second issue is battery defects. Sometimes this drop voltages more precipitously than normal batteries would which lead to a sudden shut down of the device leaving with you the last known battery in your case 22%.

A good way to handle this is to create individual monitoring of battery levels for your device and creating custom notifications based on what % you battery is likely to die.

If you have access to RBoy apps check out this app and the first post


I am still trying to decide if I would rather have it go dead with 67% battery or have false open/close and false motion to trigger SHM ARMED (AWAY) and SHM ARMED (STAY) modes.

I think going dead is better since it doesn’t make the wife say we have to go home when we are out and about because of stupid false triggers.

I have decided to start my own battery change log to see which batteries have better lifetime and maybe less problems with false triggers.

Ok hear me out. I’m a little curmudgeon on on this but I think I have some valid logic.

Few different issues with the ‘solutions’ suggested. I am a person that works, lives, dabbles, and enjoys technology. I have messed with electronics off and on a bit, from wired to battery powered. And I’d say I’m above average in terms of ‘suaveness’ around tech really. So there’s that.

I fully understand that battery reporting is hard. Just what RBoy said, every battery reports different, has different falloff slopes, and is overall hard. But hear me out, on that point, every device knows what it needs in terms of volts and amps. It can see that, its doing some sort of reporting on that already. Ok maybe its ‘bad form’ to tell people to replace batteries before they are on the last 1%. But they know minimums they need, once you reach a threshold you can say ‘replace me’. You are within 10% of what you need…its going to fail ‘sooner than later’. Maybe that means you still have a month or maybe a day, I’d rather replace before a sensor is dead.

Other side of that is when the battery is dead, and a sensor is ‘gone’ TELL ME. Much like alarm systems that use wireless sensors (most of which are still just zwave anyway), if the sensor is gone, it complains or wont even let you arm it. My leak sensor is gone for a threshold period… once again that word threshold… say its gone for 12 hours, a day, whatever. Tell me, don’t just let it go sitting gone.

On the side of ‘install X app and it does this’. These sorta things should be dang near bare metal. I’ll even go so far as saying the leak sensors I’m complaining about are even ST/Samsung sensors. I try to keep the app experience as stock st/samsung as possible. I’ll admit that Im using Iris sensors for a lot of other things but I do have some ST sensors. But for DTH’s and apps, nope keep it as stock as possible. Ive found my system to be much more reliable that way.

While I groan everytime JD brings up the argument of MTBF of 6 months… I get that already. I honestly couldnt tell you the last time I had a problem with the app or automations. I’ve had 2 ‘failures’ that I can remember… this year. A sengled bulb went uncontrollable, power cycled it and it came back. Then my osram light strip went uncontrollable, this was more difficult, it didnt come back until i went into the thing and ‘edit’ and hit ‘save’ then it came back. By keeping my system as ‘basic’ as possible I’ve honestly had minimal issues. Like so few I cant remember anything but those 2 things since I switched to my v2 hub.

Keeping things ‘basic’ keeps things more intune with what ST seems to have in mind. Like EVERYTHING I have is locally processed as well. I’ve honestly not seen much of an issue with my whole setup in like forever. So much so my monthly or 6 weekly scroll through and look at every ‘thing’ to see if its still connected and updating has dropped off…obv that was a mistake at this point.

But every ST motion sensor has issues with false motion alerts if the battery starts going dead. So much so like obx said, I change those batteries after i get fed up with too many false alerts in SHM… just got one on the way home today. This I fully understand is a hard problem. But the sensor straight up dead for 6 days and I have not been alerted at all…thats a problem

Yes we can try all sorts of apps/hacks/methods… but if we cant even get basic dead sensor reporting to us then whats the point. “Device Health” is on, i actually have little trouble with the bugs many have with it. So why didnt I get a push alert…an email… smoke signal something. Just a little red dot that who knows how long has been that way. I’m 99% sure I had looked at the device sometime this past week but guess not.

CoRE is not the answer to every question. Honestly until it runs locally I will never consider it. And after that, its still kinda meh since i dont ‘need’ that much complication. I’ve lived now like 3ish years with nothing but SmartLighting, SHM, and NotifyMe (lot of the notify stuff used to actually work better in the old dashboard). Same with SimpleDeviceViewer. I set it up once, and man once again typical open source its a sledge hammer to a brass tack. And I’m an open source guy. It just was like too much for being a ‘simple’ device viewer.

Sensors should not just go offline and 0 notification about it without opening the app. let me opt in and set a threshold or something. Device dispears for 2 days tell me via push. This should be core. But im guessing the goal is to have more eyes in the app. Instead of my ideal of my house ‘just working’. Why i dont have tablets in every room with a dashboard, why i dont have echo dots in every room so i can tell my house my every whim. So far ST has somewhat worked…I just get tired of these battery issues that have been around for years and years

1 Like
  1. SmartThings already has built a feature called “Device Health Check”. It’s implementation is likely flawed, as many people have reported false “ill health” indications, but at least this indicates SmartThings has thought about the problem and attempted to implement a fix.

  2. Sensors are not required to ever report to SmartThings when there has been no activity. While many sensors will send periodic Battery reports or Temperature changes; in order to conserve battery, many sensors will not report unless there has been a significant change. For example, a Contact Sensor on a door that is “never” opened will never change its state from “closed” to “open”, and therefore it is considered perfectly normal for there to be no messages from the sensor for weeks or even months. Of course, that’s why Battery level reporting, at a reasonable frequency, is built into most sensors. That way there can be at least a “last gasp” message from the device… even if that last gasp is 44% Battery level, which may seem more than sufficient and thus not immediately trigger a health warning.


  • The Community solutions are indeed based upon checking the Event Activity Log of selected devices to indicate which have not sent any messages within a particular time range. SmartThings keeps a maximum of 7 days Activity; therefore, we can only trust devices which report something at least once every 7 days… and, of course, somewhat more frequently is better… 24 hours? 12 hours?

  • SmartThings has implemented Health Check; but without specifying the details to anyone in the Community nor in the official developer documentation!!!. This is infuriating. The ability of a Device to participate in Health Check is defined as a Capability, but not listed anywhere in the Capabilities Reference ( Therefore, Device developers do not know how to implement this for their Devices, and SmartApp developers (including ActionTiles) do not know how to implement a user interface for this (we have lots of customers which would like us to indicate “unhealthy” Things on their Tiles).

But this situation is entirely expected, typical, characteristic, and normal of SmartThings as a company. We don’t know why. We just know that complaining here has extremely seldomly helped; even when top level management has acknowledge and agreed upon the legitimacy of the concern.

1 Like

…which works. Recently told me I had a battery needing replacement.

Edit: to @tgauchat’s point, the devices it can tell you about must periodically report something—battery level, in my example case—for this to be effective.

1 Like

So my wall of text burried it. I have Device Heath Check on. Unless I’m missing something, which seems you also miss too :), I’ve never been notified of an issue. I do get the red dot for things that went missing.

The flaw I see with the point number 2 that the sensors dont have to report ever if no activity… Yea this is true. But every sensor I own reports more than 1 thing. Temp changes being the big one. For example on this water sensor, it also reports temp. Temp does change in almost every situation at some point in a day. So yea, it may have never seen water (I do test it every now and then with a drop of water on the floor), but it will see the temp change through the day and report that.

Like I also said, I’m complaining mostly about ST/Samsung sensors here. My Iris sensors have given me like 0 problems like this. Also I’ve standardized on batteries to panasonic alkaline batteries. Not even rechargables, which does pain me sometimes. But ultimatly Ive had better luck out of these than my friends that used duracell/energizer/or other brands… I’ve had no issues with batter life in general, just that low levels in motion sensors give TONS of false alerts. And when they die, we get NO alert from it.

Yes again, plenty of ‘community solutions’. Again, MTBF has been proven to be better if you dont use any of those solutions. You can tinker all day with them. Staying very stock ST blessed (ie things in the market place only) has meant I’ve had like minimal issues in the last 2 years. Easily one hand could count the ‘problems’ outside battery related things in 2 years.

I doubt this is true.

While folks certainly can load up their environment with far too many ad hoc custom DTH and SmartApps, there are plenty of SmartApps that absolutely contribute to the value and stability.

I can say with great certainty, for example, that ActionTiles for example, does not worsen MTBF to any measurable degree.

More relevantly, the popular Device Check SmartApp is a value add, with no significantly added risk.

More realistically: Samsung SmartThings will never offer the optimal set of features. The SmartThings Cloud (and ecosystem) is a PLATFORM. It can be argued endlessly as to what components and features should be fundamental / foundational to a Platform, and which can be left to add-on developers, but the more productive thing is to simply be grateful for the available add-ons.

Nobody would use Android, iOS, Windows or Linux with only the “built-in” or official Apps developed by Google, Apple, Microsoft, and the particular Linux distro. The platform concept has been around since the invention of the “operating system”. Embrace it.

And this is why I’m absolutely confounded that SmartThings has never, ever, ever, ever (?!?) explained the functionality and purpose of the “Device Health” feature. :confounded:

If I’ve missed an announcement, blog, or even a Community Topic somewhere, please let me know.

If “Device Health” doesn’t handle the supposedly simple case of a “device gone silent”, then what is the purpose of it?


Not saying you write bad code or sell a bad product. On more than one occasion I’ve debated getting ActionTiles. But in the end I dont think I need it, and dont have a way to ‘test’ it to see if Id even like it.

But in the end, when I was using RuleMachine my automations were ‘buggier’ than with SmartLighting. I do keep a very basic setup but I’d get more failures with RM than SL. Then I used CoRE for a little while. Same situation, and I dont think its a problem with the code but more from the platform esp at the time.

I dont need the extra functionality of those to do the mostly basic lighting that I do. I say basic compared to some other peoples need to have 3 nested else if’s. But everyone that’s been to my house is always amazed on how well it works. I have small ‘gotchas’ like if Im watching tv and sit still the lights go off and i move they come on. I could setup a ‘watching tv’ routine but I live alone and I am not bothered by this too much.

But I stand behind the fact that my mostly stock setup with only ST/Samsung provided apps/dth/routines/automations all have been pretty rock solid. Seriously, power outages, internet outages, cloud issues, everything…I’ve had a pretty darn functional home. Since Hue went local processing I’ve not even noticed anything from the cloud ever causing me an issue. I still read here to see whats going on, but the common complaints people have, I just dont have. Ive bought a few iris outlets to ‘beef up the zigbee mesh’, Ive got most my lights on Hue, and SL running my entire automations. Solid. Like I want to complain about ST more, but my lights come on and off as expected and wanted like…all the time.

So I continue to try to keep it this way. The battery situation is ST’s problem to solve. What if your bluetooth headphones for your phone didnt report battery life and just died without telling you? Would that be accepted by everyone? No. So your ‘operating system’ analogy still stands. Same with the idea of ‘apps’. I only install stuff in the app store. Same goes for ST. If its not there in the marketplace, I dont use it, and I’ll say that methodology has lead to my robustness. Its how ST/Samsung sees us, ‘use the marketplace’ like the unwashed masses do. Sure sideload all the android apps you want on your phone…your experience may vary.

Not knocking you, your product, or any of the other great developments here. Just saying ST doesn’t embrace them since we are the minority. If the “CORE” product doesnt have these features, it should. They started down the road for a while of ‘blessing’ apps, then stopped, then hired andy…so who knows how it will be in the future. I see it more closed than open. If so thats fine…if they actually fix the closed env.

ActionTiles is automatically 100% free for 14-Days per SmartThings Location. And we will generally reset this Free Trial upon request to (and it is also reset periodically after major Releases so everyone can test new functionality). So… plenty of ways to “test it”.

It is indeed a shame that SmartThings abandoned the Marketplace concept prior to providing a replacement, and as a result, some quantity of stuff in the Marketplace only exists because of luck - i.e., no better SmartApp had an opportunity to be certified and added after the cutoff. ActionTiles is actually a certified "Works with SmartThings"™ SmartApp; it just wasn’t added to Marketplace because it is installable only from our website, rather than in-App. We were lucky, perhaps, to be on that cusp of certification and publication.

With due respect, you can say “should” till the cows come home, but it won’t make the world different than it is. Even if all consumers or customers agreed (or democratically voted?) upon how SmartThings “should” work, we know that products are seldom implemented to optimize customer satisfaction.

There have been dozens or hundreds of no-brainer “should have” Features discussed here for SmartThings and just a few of them have been implemented … and even then, unsatisfactorily or with negative side-effects. Can’t even start to list them… How about the classic and nearly irrefutable value of having entry and exit grace delays for Smart Home Monitor (yes - implemented in the new App; but the new App removes other SHM functions). And yes - Delays can be achieved via the tremendous effort of a Community developed SmartApp.

They don’t. They are very old, and that wasn’t a common feature at the time I purchased them. I’m also not sure how valuable that feature would be, depending on the amount of notice given.

This is a good point. Indeed, officially compatible battery operated devices should be “smart” enough to report their battery status in a standard way that the SmartThings platform can act upon to alert the customer. As far as I know, SmartThings as a company actually thinks they do this. OK - they’re not ignorant, and plenty of folks there know that low-battery reporting is not comprehensive and sub-optimal. But your guess is as good as mine as to why they haven’t come up with a more reliable solution yet. I can only say that the reason is likely similar to the reason that SHM doesn’t have entry/exit grace delays.

When ST Staff chime in here from time to time (I’m not pointing out any names), we’re told the best way to get management’s attention for a bug or feature request is to (a) Report it to, and (b) Politely mention it in the Play Store, Apple Store and Amazon “reviews” section. While this seems sub-optimal, it also seems reasonable.

I emphasize that feedback and requests in this Community Forum are not given any significant weight, comparatively. Unfortunate, because we come up with great ideas and even hash them out to some degree of consensus. But no big deal… just write the reviews instead.

In the past, I’ve actually received email from ST Marketing promising accessibility features would be fixed to make it easier for folks with various handicaps to use their phone/tablet apps immediately after posting a less than favorable review in the Apple Store. So, apparently they read the reviews.

But, of course it didn’t happen. Whoever sets product priorities apparently didn’t think it mattered that much…


Have you written them back?

1 Like

Hubitat has webCoRE.


Good write up. Let me try to add a few points from how ST and the DTH’s work with some devices. If you have a Z-Wave device as per the specs it defines two alerts before the battery dies. First one is low battery and other one is critical battery (depends on type of device). Now comes the tricky part:

  1. The specs don’t define what is low battery and what is critical battery. Some devices report low battery as 30% others as 10%. Same for critical battery. So what ST does is by default in most handlers when it receives a low or critical battery it sets the level to 1%. So if you see a device showing 1% it’s not because the battery is at 1% it’s because it sent a low or critical battery alert and the DTH set it to 1%. If you have custom DTH then those may do a better job of defining how it handle those alert level and appropriately report the battery levels. So while it may report low battery which for the device may indicate 30% battery remaining but the DTH reports it as 1% it continue working for another few weeks or even months! On the flip side Schlage connect locks doesn’t report a low battery alert until it gets down but the lock itself shuts down when the battery gets lower than 50% due to a sudden drop in voltage when the deadbolt motor is used and the batteries can’t provide the juice needed. This has caught many people unaware because the battery level is 50% and the lock is dead ie no more updates.
  2. Not all devices report these two alerts. Some only report critical. Other report both. Some don’t report any either by bad design or like I mentioned Schlage above it doesn’t get a chance to reach the operating voltage level (again poor design).
  3. As for why ST doesn’t report when a device does go offline using its Health Reporting System, it’s complex because some sleepy devices don’t send updates for as much as 72 hours. Since ST doesn’t make customized DTH’s it has to take the worst case scenario in mind and then determine when to report a device offline. Plus to make it worse with sleepy devices there no way to poll and see if the device is active so it’s a waiting game and the waiting period is determined by the longest wait time of the device in that class as ST DTH’s aren’t customized. So here some the case for why not have custom DTHs do a better job for reporting device is offline, that’s because ST doesn’t encourage the use of device health in custom DTH due to an internal bug in their system for years now. But this is the best case scenario is to have custom DTH’s handle device offline reports.

I hope this helps shed some light on the complexity of the issue.