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