Sampling Rates (polling)

Hi all,

I am currently looking into how fast I can sample devices using smart things. The end goal would be to have multiple devices configured in a given household with the capability of sampling these devices within the seconds range through a smart app. These devices would preferably be controlled directly by the hub and not a webhook up endpoint but I know local control is limited at the moment.

I looked into the default schedules however there only seems to be a minute resolution with the CRON triggers ST use. The current workaround I have is using the setinterval callback in NodeJS. The snippet of code below is from a currently operational smartapp.

// Define the Configuration page of the app'mainPage', (context,page,configData) => {
  // Sensor Section 
  page.section('sensors',section => {

// Callback to be called on a set interval 
async function device_callback(context){
  let sensor=context.config.sensor[0].deviceConfig.deviceId;
  let devStatus= await context.api.devices.getStatus(sensor);
  let data = JSON.stringify(devStatus);
  var objectValue = JSON.parse(data);

app.updated(async (context, updateData) => {
  console.log('In the updated function')

  // Schedule a job 
  setInterval(device_callback, 1000, context); //This is in milliseconds

The above returns a power reading every 1 second from a powerMeter capability. The current Rate Limits are a concern when scaling this sort of app up to multiple devices as I am not sure the API was built for this purpose. The smart app has been continuously running for about an hour now and so far no problems.

Just wondering if anyone has any past experience with testing this kind of thing and the results they obtained/problems encountered?
Any input is welcome!

Sampling is polling. Polling requires power, so it tends to kill the battery life on small devices like sensors.

Zigbee and zwave were both intentionally designed for networks which would have a minimum number of messages each of a very small size. That allows the mesh to operate efficiently and greatly reduces the power required for the overall system. So frequent polling is discouraged. As you noted, many times this means a minimum of once a minute, but really these networks don’t even like that.

The type of communications you are describing are a much better match for a Wi-Fi mains powered system. You don’t have to balance the mesh, all of the devices are always connected, and the fact that they use 10 to 15 times as much power as your typical zigbee or Z wave system is the cost for having real time reporting.

Basically every message sent requires power. If that power is coming from a battery and that message is traveling over a mesh network, you want to limit polling as much as possible.

So the answer in part is going to depend on the specific configuration you are imagining. (First rule of home automation: “the model number matters.“) If This is going to be a houseful of Mains powered Wi-Fi devices, maybe some smart appliances and cameras and a few other supporting devices, then the kind of polling you’re imagining shouldn’t matter.

But if you’re talking about a typical smartthings HA implementation with mostly inexpensive battery operated zigbee or zwave sensors you’re going to kill the battery life and probably crater the network.

So that’s why there are limits. :sunglasses:


Hi @JDRoberts,

Thanks for the feedback, the devices I am using/intending to use are z-wave devices however they are all mains power supplied and do not use batteries.

  1. Aeotec Home Energy Meter
  2. Qubino ZMNHTD1 Smart Meter Z-Wave
  3. Aeotec Smart Switch 6

For the moment I am testing using the power meter on the Aeotec Smart Switch 6. The battery life should not be an issue as they are always connected to a mains supply, its just more of a concern if ST can handle this regular polling? Which from what I understand to your knowledge it should be able too, I was just concerned with the Rate Limits in the docs.

When I begin to scale up and there is a lot of polling occurring across the mesh it may be a case that I would have to switch to a Wi-Fi based solution.

Not sure why this already isn’t hitting the rate limit. The better option would be to configure the event period on the z-wave device and then just subscribe to the events. That would be less taxing on the platform. For devices like the HEM they will update with every change (which will be a metric ton of events) so you don’t really need to poll them in the first place.


Hi @jody.albritton,

Thanks for the reply. I haven’t had a chance to test the HEM yet but what you are saying is altering the timer within the device itself to update the value of Voltage say every 1 second and then subscribe to the voltage update event?

What I am really trying to figure out with this is how often I can take readings from these devices at set intervals of time. I know I can subscribe to the voltage change and assume for the interval of time in between messages everything is the exact same but I want to see how it handles continuous polling.

This is concerning if you think I should already be hitting the rate limit and I am not. Do you have any idea on how I am already not hitting the Rate Limit?