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

@TAustin Precisely what they said! :arrow_up:

@Rodd62 Thank you for explaining more elegantly exactly what I was attempting to say. And I too had in the back of my mind a Web Requestor motion device, but I used a virtual switch example in the hope of being better understood, and still failed! It seems a waste of resources squandering so many Web Requestor Routines that could be put to better use elsewhere, let’s hope something can be done.

@Alwas @Rodd62

I must be dense because I still don’t really understand something: Today, you need two automations: one to trigger an ‘on’ web request configured in web requestor and a second to trigger an ‘off’ request configured in web requestor. If you now have a dedicated switch device that sends http requests when switched on or off - you still need automations to turn the switch device on or off. So I don’t see where you are saving anything in terms of number of routines.

What am I missing?


I don’t think you’re dense on this as you’re totally correct.

I think where my motion sensor example differs is the “on” is handled externally and “off” is on a timer.

For the switch, it could still be helpful for uses in Alexa/Google or other cases where the web requestor wouldn’t be an available device.

*edited for clarity

@TAustin you’re not alone lol. I’ve been racking my brain trying to figure out what’s being asked.

Not really, an example would be a V switch called TV, who’s on and off state is determined by a smart plug, now if that V TV switch, could automatically send http requests with each on and off, 2 Routines saved.

This would be a great idea to fire webhooks from a virtual switch


I think in your example and to Tod’s point, couldn’t the routine syncing the V switch and plug also fire the http requests? It would be an extra action in each routine but for the most part should function the same.

I also don’t mean to diminish your need, just get you a solution :slight_smile:

Appreciate the effort, I have 20 V switches, with only Web Requestor Routines attached.

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.

1 Like

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

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.


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…

1 Like

@TAustin this is what I mean, 2,3,4 weeks, whenever you find time, and thank you for all you’re doing :pray:

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 :slight_smile: .

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 :slight_smile:


@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.


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:


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 :+1:

1 Like

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.

1 Like

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!

1 Like

@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!

1 Like

@TAustin This is great, it eliminates several routines and is a much cleaner approach. Thanks for all your work.

1 Like