Is there a way to prevent(or distinguish) "automatic polling" from SmartThings?

Hello,

I’m currently using a SmartThings Schema connector with AWS Lambda.
It seems that the SmartThings platform periodically sends Discovery and State Refresh requests to my Lambda for all(?) integrated user account and devices.

Though I do note that the reference manual ( https://smartthings.developer.samsung.com/docs/devices/smartthings-schema/smartthings-schema-reference.html#Interaction-Types ) mentioned this(currently observed time interval in my Lambda seems 24 hours which is somewhat different from the value mentioned in the manual though),

NOTE : Automatic polling occurs approximately every 6 hours. The Discovery request is followed by the State Refresh request.

I could not distinguish whether the request is by automatic polling or by actual user interaction(I would like to distinguish this for figuring out request statistics).

So my question is,

  1. Is there a way I can modify or disable settings for automatic polling?
    Of course, my Lambda support device state callback logic caused by the device.

  2. Or at least, is there a way I can distinguish request origin?
    I cannot find any difference between the request payload on automatic polling and actual user interaction.

Thanks!

Hi, @blue9519

Indeed, this lapse between polling requests was updated to reduce network traffic and cloud usage costs on both sides.

Also, to identify these poll requests, I personally recommend you to nest a timestamp at your JWT Access Tokens to have a reference on when that user logged in from the SmartThings App, this way you’ll be able to control if the discovery is a scheduled poll request or the user has integrated his/her account for the first time.

Now, to have a better experience controlling this data I recommend you to consider the following:

  • Make sure the token responses from your OAuth provider supports expires_in and refresh_token params in addition to access_token.
  • And verify that your OAuth provider refreshes access tokens properly. This way, the Connector will remain as an active Connected Service, and users won’t be prompted to log in again, breaking your JWT-nested timestamps.
1 Like

I think your answer provide enough solution for my problem.

Thank you very much for your advice :slight_smile:

1 Like