From my total ignorance on web requestor.
I don’t know if this is what @Alwas means
If in the requestor web virtual device 2 preferences are added to write the On web request and another one to write the Off web request.
When On or Off is pressed on virtual web requestor device, the On or Off web request is also sent.
Let me try and map this out:
*** TODAY ***
SMARTPLUG ---------> TV VIRTUAL SWITCH ---------> WEB REQUESTOR -------------->
on/off on/off http request
*** PROPOSED ***
SMARTPLUG ---------> HTTP SWITCH -------------->
on/off http request
** ALTERNATIVE **
SMARTPLUG ---------> WEB REQUESTOR -------------->
on/off http request
I think I see now why you are asking what you are asking! To @Rodd62’s point, you could simplify things by getting rid of the virtual switches altogether and just triggering the web requests off of the smartplug. But I’m assuming you WANT to have the virtual devices for other purposes.
Agreed
I’ve got a lot on my plate right now, so it may be a week or two before I can get to this, but I’ll try…
@TAustin this is what I mean, 2,3,4 weeks, whenever you find time, and thank you for all you’re doing 
Ditto what @Alwas stated.
For me, nothing near term, just looking to trim the complexity. My assumption is that once you build it, the limit will get increased 
.
Side note, if its possible to build your web requestor into your Virtual Device driver, couldn’t any devices created from it talk to each other (to some degree)? If so, you might expand more easily? Just a thought but I don’t really know what I’m, talking about so feel free to ignore the above rambling.
I always appreciate the discussion and your willingness to listen and receive feedback.
In an ideal world, my vEdge driver would support both http and MQTT for every virtual device
@Alwas @Rodd62 - I’ve got a new driver for you to try to address your challenge of automation routine proliferation using webrequestor. I’ve tried to meet your need for a specific ‘virtual’ device type (e.g. switch) with built-in ability to issue http requests for any supported command.
I’ve put the driver out on my tests channel here and it’s called HTTP Devices V1.
You’ll do an Add device / Scan for nearby devices to get the initial creator device added to your No room assigned room. You can then use that device to create whatever types of devices you are interested in.
The driver initially supports: switch, switchLevel (dimmer), momentary button, and alarm. Pick the one you want and it will be created. Then go into the device Settings for that new device and configure your HTTP requests for each command supported by that device type (switch: on/off, switchLevel: setLevel, button: push, alarm: off, siren, strobe, both.
There is a part a and part b field for both the request URL and the body in order to accommodate unusually long strings that may exceed what the mobile app allows you to type in one field.
The URL needs to be in the same format as webrequestor expects, i.e.
"POST:http(s)://<ipaddress>/path?parm1=xxxx"
GET and PUT are also accepted.
I’ve implemented the dimmer device a bit uniquely because you need to be able to send the actual dimmer value. How you do this is to insert a special replacement string - “${level}” - either in the URL or in the BODY. It will be replaced with the switch level value when the http request is sent. If you put it in the body, be sure to also add the appropriate Content-Type header. If you want to send proper json, then you’d code this in the body:
{"level"=${level}}
On the device Controls screen there is just the stock capability control plus a field that shows the HTTP code resulting from the last request that was sent. If the particular command invoked doesn’t have a valid request URL configured it will show ‘(not configured)’ when you press a button. Otherwise you should see a ‘200’ if the HTTP request is successfully sent.
Right now I don’t do anything with any response data, as this is really a ‘fire-and-forget’ kind of operation.
I’ll expand this to support additional device types based on community needs.
Let me know what you think!
Hey @TAustin , thanks for putting this together! It’s 99% of what I need (motion and get request). I’ll see if I can bend it into something I can use.
I could probably use a switch with some Blue Iris functions that I haven’t yet thought of.
This is really innovative work 
Thanks again for your great work, it is working well for me, will remove automation, and just use the switch that sends directly a state=on or off.
Do you need a motion device? If so I assume it would also need a switch that you could use to control the active/inactive states?
GET is already supported.
This is great. Currently I have several routines that send a command using Web Requestor to my home theater system. This will eliminate that and I can just create a device for the various inputs. Thank you!
@TAustin This is fantastic, better than I could of hoped for, really appreciate the long address fields, this has eliminated an Android server, not only are you a code machine, you’re also helping the environment!
@TAustin This is great, it eliminates several routines and is a much cleaner approach. Thanks for all your work.
I’m a very basic user, could someone explain or show me examples how to set this up, I’m unsure if it’s the IP address of the device I want to operate or my router/SmartThings hub
Also what additional steps do I need to take to send webhooks to say Tasker ( I am ok with the process of receiving webhooks at the Tasker end)
Many Thanks
If you have a device on your LAN that accepts HTTP requests for control, then you configure that device’s IP address into the device settings along with the rest of the URL that the device expects.
I’m not familiar with Tasker myself so hopefully others can comment on that.
You can’t really send webhooks to Tasker, as there is no endpoint. But there are ways to accomplish the same thing. I use Pushover, but for other options, see Getting Data to Tasker in Android.
It’s a shame that you cannot access Public URLs. It would be nice to be able to send requests to Public APIs for devices such as an Ecobee Thermostat. Today, the stock integration doesn’t support changing the thermostat’s program mode. The Ecobee Suite SmartApp alleviates that issue, but it will die when the Groovy platform is shutdown. If we could send to the Ecobee public API via HTTPS, it would allow for greater control via Routines when a stock driver doesn’t support certain functions.
If you have an always-on computer available on your LAN, you can get to external APIs with my edgebridge app.
I do, but that’s just another failure point. Seems like we should have the option to allow access to public endpoints.
Well I suppose technically that’s true, but the reality is that SmartThings fails often enough by itself, and hubs require occasional reboots, whereas I have scripts like edgebridge running on Raspberry Pis that virtually never fail. I’ve got one that hasn’t even been rebooted in nearly a year I truly believe that anything you are running locally is going to be way more reliable than SmartThings or its hubs.
A motion device would be amazing. The current ST Blue Iris smart app has a callback piece. Basically it allows you to use other ST motion sensors to trigger Blue Iris motion and trigger a recording. While that function is a nice to have and your web requestor nails it, it would be awesome to have a switch/motion sensor with the web request capability so I could manually trigger the motion event.
It’s so much easier to manage than the web requestor. Some reason my brain quits working unless I process map it and that is too much like work.
Again, no rush and feel free to prioritize whatever else ahead of it. Thanks again!