Battery reporting and SmartThings


#1

What’s the deal with SmartThings and their inability to accurately report battery percentages?

I have several battery-powered sensors and locks that are never reported correctly. When I asked support they said it’s a known issue and they’re reporting has had problems not exactly the answer I was hoping for.


(www.rboyapps.com - Make your home your butler!) #2

Devices reports their own battery levels in %, ST just displays them.
Each device is responsible for reporting changes in battery levels, due to defects in firmware or communication issues with the mesh, either wrong levels are reports or sometimes not reported at all.

Each device is difference, some require custom polling, some update by themselves so it’s more do with the device than the platform.


#3

RBoy: Is that how your automation for Low Battery works?
That is, do you use the % returned from SmartThings, or do you use a custom call on each device?


(www.rboyapps.com - Make your home your butler!) #4

SmartApps can only use what’s reported (i.e. %). Device handlers have different strategies to get the reported % as I mentioned, it depends on the device (sleepy vs FliRS and the device specifications itself).


(Mark) #5

Are there other hubs that do it better?


#6

Vera did report this when I used it on 2010


#7

Yeah…if your devices aren’t reporting the correct %, that’s not ST’s fault.


(www.rboyapps.com - Make your home your butler!) #8

One of the reasons this happens is to the mesh data loss. You can see this happen with locks which are FLiRS devices, if you look long enough sometimes you’ll find that the data being sent by the locks “invalid”, they’re missing a few bytes caused by corruption. However with FliRS devices you can always send the command again.
With sleepy devices, they wake up send the event and go back to sleep. So if there was data corruption and a byte went missing, it’ll show up as null. Since it’s sleep it won’t send it again until the next update which could be hours or days.
Technically device handlers can be modified to handle this situation (which would need a massive rewrite of a lot of ST handlers) but it happens to infrequently that I’m guessing ST may not do it - and the solution is that it’ll resolve itself on the next battery update.