Hi guys, just curious about how SmartThings cloud and SmartThings hub communicate when I send a request to the cloud to collect device information. And what will happen to the hub if I send 8 requests at the same time(8 threads) for an hour to collect device information? I mean in the long term will it do any harm to the hub?
1 Like
Interesting question. I wouldnât expect there to be any communication between cloud and hub due to your requests as the information should already be in the cloud. I could be wrong though.
2 Likes
Yeah. Iâm wonder if thereâs sort of a interval that the cloud collect data from the hub or maybe the hub only send data if thereâs a changes in the device within it.
Yeah, in the end, youâre not getting data directly from the Hub as the data is already saved in the Cloud.
About the requests, you can see in this doc the rate limits on request per x amount of time and others:
Thereâs a better explanation in the post below on the other topics (thanks BTW 
):
2 Likes
Most people wonât care, but from an engineering standpoint, we need to correct both these statements.
POLLING
Polling is done when the hub wants to get the status of a device before the device reports it. For battery powered devices, we want to do as little polling as possible, because it uses up battery life. For mesh systems, including both zwave and Zigbee, we want to do as little polling as possible, because it adds traffic to the network that can cause other messages to be delayed or even lost.
Both Zigbee and zwave battery powered devices are usually designed as âsleepyâ devices: thereâs no difference between the two protocols in this regard. A sleepy device goes inactive most of the time but wakes up on a fixed interval (which might be every few seconds) to check and see if there is anything to report. Polling forces it to wake up early.
Still, even though both protocols have sleepy devices, there is a major difference in how the two protocols, zwave and Zigbee, handle polling.
Zigbee has two kinds of polling:
Short polling, in which an end device responds with a very short message. (The shorter the message, the less battery power it uses, and the less traffic on the network).
Long polling, in which the end device sends a lot of data, which is allowed to last up to 7.68 seconds.
Zigbee also has checkins, which occur on a regular timed interval, usually every hour.
Using long polling when you should be using short polling can kill battery life on Zigbee devices. So can forcing too frequent check ins.
NETWORK TRAFFIC
The SmartThings architecture does impose âguardrails and rate limitsâ as @nayelyz mentioned which are intended to prevent too much traffic on the network. So the good news is that too many queries canât âdamageâ the hub: but they might cause some of the queries to be refused.
THIS CASE
I believe the one that would apply in this case is 12 request per minute for device state, but it would depend on the details.
@Thanh_D When you say you are sending â8 requests for an hourâ do you mean a total of 8 requests in 60 minutes? Or that you are opening 8 communications streams and want to continuously poll 8 devices for an hour, meaning potentially tens of thousands of polling transmissions? The first should work fine. The second will hit a rate limit in the first minute. 
4 Likes
I am going to open 8 communications streams and continuously poll 8 devices for an hour. But the monitoring period will be 1 min/ device, It means I Poll the device data in every 1 minute.
1 Like
1 data request per minute for 8 devices should be fine from a rate limit standpoint.
That said, the data you get will also depend on the specific devices.
For example, some battery operated temperature sensors only check the environment every 15 minutes. You can poll for the temperature every minute, but the data you get might be 14 minutes old. So device selection will also matter.
1 Like
lots of useful info for me. Thank you so much for your explanation.
So the data of the devices will be sent to hub evenly by Polling or whenever the device report to the hub, and then the hub will send these data to smartthings cloud and store it. When we send a request to get the device data we do not get it directly from the hub but the smartthings cloud. is it right?
1 Like
That is true, but I personally donât know what causes the SmartThings cloud to ask the hub for updated information.
I myself am just another customer. I was a network engineer before I ever bought my own first SmartThings hub, and I had worked with both Zigbee and Zwave, so I know quite a bit about the protocols themselves. But as far as what SmartThings has done inside their own implementation, I just have the same knowledge as any other customer might have.
I became disabled a few years ago and no longer do any programming myself since I am now dependent on voice reader technology. So there are other people in the community here who have gone much deeper than I have into the details of the ST implementation. Hopefully some of them will have more details to add. 
Thank you so much 
3 Likes
I wonder if youâve checked it all out. I think it definitely wonât hurt the hub.