[ST Edge] Web Requestor: a driver to issue local POST and GET HTTP requests

I’ve always assumed so, but @nayelyz should confirm that for us.

1 Like

Thanks for reaching out, I’m discussing this with the internal team, I’ll come back here once I know more :+1:


@nayelyz Is it 200 per hub, or per ST account? Not sure why virtual devices would count against a hub. Seems like the hub would only be involved with zigbee/zwave/LAN

It’s 200 per SmartThings location (for regions outside USA. It was lifted in the USA)


Interesting disparity :thinking:

I wonder what the rationale was for this? If it can be technically lifted, I’m not sure why it would be left in place for some users and not others. Maybe it is bandwidth related and they can push more traffic on the US servers. Just guessing.

If it is due to bandwidth, maybe they can lift it for all when more local processing takes hold

My understanding is that it’s the other way around: as they start doing more local processing, they run the risk of customers’ hubs becoming overloaded, so they need to put some guardrails in place. Virtual devices will take pretty much the same amount of memory and processing on a hub as a physical device, so that’s why they would fall under the same limits. :thinking:

We already see this in some of the competitor hubs which run everything locally except third-party integrations. The usual solution there is to add another hub to help carry the load, but that’s not easy under the smartthings architecture. But you will find quite a few customers of Homeseer, hubitat, and Vera running more than one hub as their networks expand, just to name some examples.

But we should take this conversation to the guardrails topic:

FAQ: Limits and Guardrails (max # of automations, devices, etc)

1 Like

Do you think this would work for the switchbot stuff we talked about earlier in the thread?

1 Like

A conundrum. I need to update my app to use this, yet I see many here whose devices disappeared etc when they update. Sheesh lol

Is anyone using the Web Requestor to do anything with LIFX?

Hi again, @TAustin, @blueyetisoftware.

Yes, there’s a limit of 200 devices allowed per location, if we had more than that number of devices in the location, the app performance could be affected.
The virtual devices and cloud-connected devices are also counted; the limit restriction is the same for all the regions.


There’s an open goal if ever I saw one. Who wants the first go?


@TAustin Following on from the comments about {state_change = true} on the virtual devices thread, that could have an application in this driver.

When calling a device via a Rule, the httpcode attribute isn’t first cleared as it is when using the UI, however the response is, whereas the response is set to --. This means that the httpcode only propagates when it changes.

So, for example, I ping a TV every five minutes. When it is off I get a ** Timeout and when it is on I get a 200. so if I turn the telly on at 6pm and off at 10pm I get the 200 at 6pm and the ** Timeout at 10pm and nothing in between. However I do see two response every five minutes - the -- and the actual reply.

Arguably the code could benefit from the {state_change = true} so it is always propagated on every web request (so it can be triggered off).

It could also be argued that the response could use it so that the preliminary -- is unnecessary, but you probably still need to clear the response somewhere so it is swings and roundabouts.

Did you try this out with the Bond Bridge and get it to work?

Yes. I am testing out a pre-release version of the driver, but it does work. There is still a good amount of setup since it isn’t a dedicated driver though

I’m on Android using Bond firmware v2.29.7-Beta running local wifi.

If your doing some tests, I’d love for you to keep me in mind.

A Web Requestor driver update has been pushed out that expands the usefulness of the driver by allowing users to provide HTTP ‘body’ data in their configured web requests. This is useful wherever you need to send additional data such as json, xml, or other text along with the HTTP request URI and endpoint.

The way this is implemented is in device settings for the first 5 configurable HTTP requests, there is a companion setting field where you can provide the optional body data. If 5 requests are not sufficient for your needs, you can always create more web requestor devices!

Some other changes made in this driver update:

  • added option to use a PUT method for configured web requests
  • code changes to reduce the number of extra entries in history caused by resetting/blanking out device detail screen fields when executing a web request
  • limited the displayed response data to 1024 characters ; this is to prevent any SmartThings app glitches that have been shown to happen when large http responses are received. Although the response field in the device details screen tends to cut off the data shown, you can usually see the first 1024 characters in device history. Note that the response data attribute will still have the entire returned data for access from Rules or SmartApps.

Note: HTTP bodies and PUT methods are not supported for on-the-fly requests sent as arguments from routines or Rules.

Once this driver has been updated on your hub; confirmed by checking for driver version:


…you should see the new optional body fields available in device settings. If you don’t, try creating a new web requestor device.

Thanks to @blueyetisoftware for the original request and testing!


Thank you! This driver has been awesome for experimentation with the many LAN connected devices that have REST apis.

1 Like

Awesome stuff!!

Curious if anyone is using this driver to control LIFX lights locally? I know there is a LIFX LAN protocol but still trying to wrap my head around it.

I think my hub doesn’t like this update. I’m using this to send a webhook into my local Home Assistant instance whenever the SmartThings more changes. I didn’t get my usual notification this morning, so I went investigating.

Trying to execute a web request just results in the spinning circles and eventually a generic network error. It was last working as of 11:01pm Eastern time last night.

I’m sorry you’re having trouble. Can you try creating another web requestor device? That will tell us if the driver is even (re) installed and functioning.