How can I check polling of a device?

How can I check polling of a device, ie the device polling schedule? The reason I ask is I have a deadbolt with batteries that last less then a month before needing replaced. I am wondering if maybe the device is being polled too often.

Model : 910TRL

I may be jumping to a conclusion, but I think SmartThings “never” polls a low-power (ZigBee or Z-Wave) Device (unless a SmartApp schedule or Refresh command is explicitly issued). But I might be wrong.

If my assumption is correct, then it is up to the ZigBee or Z-Wave configuration parameters sent to the Device (or its own defaults) that tells it how often to “wake up” and send a Status, if it feels it has a meaningful update (e.g., a battery level or temperature); and, of course, it wakes up to send a critical Attribute change (e.g., locked, unlocked, tamper).

There isn’t any value to Polling except if: (a) the device’s status updates could be lost from time to time, which is certainly possible, and/or (b) the device’s own wakeup interval is too slow or unreliable (e.g., a device’s battery dies before it can wake and send a final low-battery update… ?

The other variable: What exactly does SmartThing’s optional “Device Health” feature do? Does that add timed Polling? Maybe… Therefore, I’d suggest turning off the Device Health feature and see if that, perhaps, lowers battery drain.

thanks @tgauchat , that is good information. Thinking about tamper any idea if the 910 has that feature built in? If so I wonder if that is causing the problem since when the door is just dead bolted and gets hit with significant amount of wind there is a bit of play. As for device health I disabled that awhile ago due to performance problems I was having overall.

As far as the short life for the lock battery, this can be caused by several factors other than SmartThings. The main thing, of course, is usage frequency. If that is normal, the second most common problem is an installation where the bolt has resistance in the locking/unlocking path. Even if installed perfectly, house shifting/breathing can cause this to change seasonally.

Finally, look on the website for your device. See if others are complaining on the battery life on the non-connected version of the device. That will give hints on other possible problems not related to the smart capability.

1 Like

Battery operated devices like sirens and locks can’t sleep because they need to be able to respond to commands at any moment so SmartThings polling is a valid concern.

If the DTH has a poll command SmartThings will execute it every 10 minutes. If that poll command sends commands to the device every time it executes then that will hurt the battery life.

If you don’t see “poll()” in the DTH then SmartThings polling doesn’t apply to your situation.

If it’s a Zigbee device then the DTH could have set the device to automatically send reports too often, but you can test for that by adding a line like the one below to the parse method.

log.trace "parse()"

If you leave live logging open for a while and you’re not seeing “parse()” at a regular and frequent interval than that’s not the problem either.

If both of those situations don’t apply then it’s probably caused by one of the things @Gutheinz mentioned and I doubt there’s anything you can do to improve it.


Sorry kinda new to this, what is DTH? How do I check it?


I’m pretty sure that Device Health checks to verify that the device has registered certain types of events (usually action events coming FROM the device) at least every XX hours (configurable by the device, but the default is 60 minutes, I think). If ST doesn’t see events within that timeframe, I think it call “ping()”, or “refreshI()” or "poll()) (in that order).

So yes, if Device Health is enabled, you may see more activity going to the lock.

The DTH (Device Type Handler) that you use contributes/controls the frequency of checks. I personally use @RBoy’s DTH for my locks, and I’ve noted that it works hard to skip the majority of refresh/poll calls it makes…


I guess I am using whatever the default one is, since I have only installed the lock using the “add a thing” from the app?

A couple of things to note here

  1. If you’re using the stock device handler or any device handler which implements the capability polling, then ST will poll the device. You have no control over the polling period nor it is consistent. We’ve seen devices being polled every 3-5 minutes, others polled every 30-60 minutes and some devices that are never polled at all. ST is not clear about how polling works or even guarantee that devices will be polled at all. However they do say that it is supposed to poll every 15 minutes.

  2. Polling cannot explain the battery drains you’re experiencing. I’ve personally setup a lock and manually polled it every minute continuously just to see how much battery drain happens and the battery (duracell alkaline) lasted a few months. ST will definitely not poll that much.

What you’re experiencing could be caused by a couple of things:

  1. Battery - what type are you using? Alkaline or Lithium (not Lithium Ion) or Rechargeables - it is advisable to use only alkaline or 1.5v lithium (not lithium ion) batteries for best battery life. Rechargeables had lower voltages and can appear to die faster because locks have a cut off voltage that determines when they stop operating, higher the voltage, the longer they will operate which is why rechargeables are at a disadvantage. Here is a little post comparing the battery life:
  1. Some app is continuously communicating with your lock, this you can track down easily through the events page in the IDE.

  2. You had a bad Z-Wave chip/lock. It’s known to happen. We have 3 identical Schlage locks in our lab and the battery life between them vary a lot from 2 months to 9 months. Identical setups and batteries.

  3. Your Z-Wave setup if you lock is too far or you don’t have z-wave repeaters it can speed up battery drain.


This post is old but it does a great job of explaining how device handlers and smartapps work (and it’s still applicable).


The “Device Health” feature only applies to devices that support the “Health Check” capability and it uses the “checkInterval” attribute to determine the maximum number of seconds the device can go without generating new events.

If the device hasn’t created any events within that amount of time then SmartThings executes the “ping()” command and if that didn’t generate any events SmartThings marks the device as offline.

The “poll()” method is unrelated to Device Health and SmartThings is supposed to execute it every 10 minutes based on the documentation, but like @rboy said, the actual frequency is completely random.

SmartThings does not execute the “refresh()” command automatically.