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

I have a new Edge driver to share that provides the ability to issue POST and GET web requests to a specified URL. This functionality can help users that may today depend on webCoRE or other cloud-based means to do a similar task. Of course being an Edge driver it enables you to have fast & local automations.

There are two ways this driver can be used:

  1. Pre-configure up to 50 different POST/GET URL strings, which can then be individually triggered through Automations/Rules or via a button in the mobile app.
  2. Issue custom URL POST/GET commands from within a Rule

>>>>>UPDATE: Please go to this readme file for the latest instructions


Limitations

  • Although GET method is supported, it currently does not actually do anything with the returned data from the server. I’m open to ideas here on how to expand this.
    UPDATE: Enhancements made in new driver to better use response data; see post
  • The Edge platform limits communication to IP addresses on your local LAN only. So if you need to POST or GET to an internet URL, you’d have to run a bridging/forwarding server on a Raspberry Pi or similar. Message me if you need this; I have the bridging program available.

Instructions

  • Use the link below to access my shared channel, enroll your hub, and select the ‘Web Requestor’ driver. (This is the same shared channel I used for my vEdge driver)
    SmartThings. Add a little smartness to your things.
  • When the driver gets installed onto your hub (up to 12 hours), you can do an Add device / Scan nearby and a new device called ‘Web Requestor’ will be created in your ‘No room assigned’ room.

If you want to set up pre-configured web requests, do the following:

  • Go to the device details screen of Web Requestor and go into device Settings by tapping the 3 vertical dots in the upper right corner of the screen. Here you can configure up to 50 web requests. The format must be:
POST:http://<ip:port/path> or GET:http://<ip:port/path> or
POST:https://<ip:port/path> or GET:https://<ip:port/path>

Notes regarding URL string:

  • you must include a valid IP and port number; if you normally don’t include port number in other apps or a browser, use ‘:80’
  • if your URL contains any spaces, use ‘%20’

Each request ‘slot’ has a default example string you can modify; note that any slot can be either POST or GET

  • After you have saved some web requests, return to the device details screen and tap the button labeled ‘Select web request to execute’. Then select the corresponding request number and your web request will be sent.
  • The send status will be displayed for about 3 seconds and then reset. Possible values are:
    OK: your request was sent and accepted by the server (HTTP 200 OK)
    Failed: the request could not be executed for any number of reasons, e.g. IP or port not found, timeout, socket error, etc.
    No HTTP response: no acknowledgement from server; it didn’t recognize the request
    HTTP error nnn - HTTP error number nnn was returned by the server
    Refused: connection was refused
    Not configured: the string in Settings hasn’t been properly configured or it is invalid or has a bad format
  • You can now create Automations or Rules to trigger your configured web requests.

If you want to specify a custom web request URL in a Rule, here is an example of how that would be done:

{
  "name": "Test Web Requestor",
  "actions": [
    {
      "if": {
        "equals": {
          "left": {
            "device": {
              "devices": [
                "4c4f0e69-2542-4a05-83bf-1dfa0f0ccaad"
              ],
              "component": "main",
              "capability": "presenceSensor",
              "attribute": "presence"
            }
          },
          "right": {
            "string": "present"
          }
        },
        "then": [
          {
            "command": {
              "devices": [
                "3b70d48d-d458-472e-befd-e18afd173382"
              ],
              "commands": [
                {
                  "component": "main",
                  "capability": "partyvoice23922.webrequest",
                  "command": "GET",
                  "arguments": [
                    {
                      "string": "http://192.168.1.104:1755/tts_SCPD.xml"
                    }
                  ]
                }
              ]
            }
          }
        ]
      }
    }
  ]
}

Sadly there is a bug currently in Automations where command arguments can’t be provided (reported to SmartThings), so Rules are the only option until that gets fixed. UPDATE: I’m getting help from ST to find an alternative, so hopefully Automations will be also available for custom web requests soon

Timeouts
There is currently a 3 second timeout set for all HTTP requests.

Acknowledgement
It’s important that I acknowledge @Alwas who provided the inspiration for this driver. His input and testing was essential for its creation. THANK YOU @Alwas!

14 Likes

Can this be used to access local camera?

If the camera accepts POST or GET requests, sure. Although as I mentioned in the post, a GET request does not do anything with any returned data at the moment.

1 Like

That seems a useful little tool. Can the presets be accessed via the Rule argument?

To cut a long story short, I’d find it really useful if the result could be emitted in an event that could trigger an automation/rule. The complication would be that any attribute would need to somehow reference the request as well as the result.

I think I understand what you are intending, but yea, might be tricky to accomplish. I’ll have to think about that one a bit…

I’ll uncut the long story. I currently have a DTH that implements a number of virtual devices but uses the success or failure/timeout of a GET request as the active/inactive. The GET request is sent every 15 minutes by the DTH refresh() method. I actually use it to detect a TV is on and create virtual motion to keep a motion controlled light on in the room.

I’ve been using it for quite a while now and if I were starting again I’d be trying to create a less bespoke solution by using Rules, virtual sensor devices and a something to make the web request.

This is awesome. Do you know if it supports random phrases?

Not sure if this will help anyone but I couldn’t get this to work due to spaces in my Get requests.

I use MS Azure TTS services with my raspberry pi and Sonos speakers. So my command is something like the below. Due to the space in the word Living Room, I had to add %20 between those words. I have to do the same for any phrases that contain spaces.

GET:http://192.168.1.x:8888/living%room/say/this%20is%20a%20test

I can look at adding some logic to do this automatically. Same goes for port number; if it’s missing, I could insert a default port 80 like a browser would also do.

1 Like

You’d have to have something else generating them, but I don’t think Rules could support that right now. webCoRE may be the only option for now, but I’d have to make this discoverable by webCoRE first.

This is awesome @TAustin, being able to control IR devices like my TV, AC and robot vacuum locally is nothing short of epic! @rontalley this was made for you!

3 Likes

Interesting indeed. Thanks for the heads up!

1 Like

A couple updates regarding this driver:

  1. In my original post I said that Automations for custom URL POST/GET commands was not working yet, but Rules worked fine. With some help from Nayley, I was able to make a change that would get this working for Automations but due to a SmartThings bug, it seems to only work for Android! iOS unfortunately has a problem with the device not getting listed as available for Automations. Honestly, I don’t know when this will ever get fixed, so if you need this capability, it might be time to take the plunge into Rules. My sample Rule json above can help get you started.

  2. Keep in mind that Edge is still in beta. One of the more painful problems with the platform at the moment is that the Settings function is VERY buggy. This can be manifested in this driver when you configure a web request that you know is correct format-wise, but when you go to test it, it says ‘Not configured’. I won’t go into why this happens here (any developers out there who are interested, I can elaborate), but at this point I think that a temporary code change could be implemented, but it will require you to wait 10 seconds between each settings change. I can’t guarantee that it will solve all problems, but hopefully it would reduce them. I’ll experiment with this and post when/if I have pushed a driver update with this change.
    In the meantime, if you are having problems where your web request didn’t seem to ‘take’, then go back into Settings, edit & tweak the web request string to something else (all it takes is one character change), press OK, wait a second or 2, then edit it again and change it to what you want. Then test it to be sure it’s working. Until I get the possible fix mentioned above pushed out, it’s possible it could take more than one cycle of edit-edit-test.

I’m using IOS and automations are working fine. Maybe I got lucky but the device was picked up by the automation right away and allowed me to choose the web request.

I ran into the 2nd issue but what you suggested worked. i.e. editing, saving and editing again fixed it.

Automations are fine with the current driver when you need to select a pre-configured URL. But have you tried to send a POST/GET command with custom URL string?

Nevermind. I read too quickly. :slight_smile:
I haven’t tried custom yet. Sorry.

1 Like

Great work again @TAustin, you are leading the way here with edge drivers.

Out of interest what APIs have people tried/used?

Would be good to get a library of tried and tested apis/use cases

1 Like

Does this work with HTTPS? I assume no since none of the examples have it.

1 Like

Right now, that string would get ignored. Is there a need for it? As long as the Edge platform’s socket http support can accept it, I could add support for it.

1 Like

For my use case I need it. One of my last remaining webcore pistons is sending a webhook to my local Home Assistant instance, which is only accessible over HTTPS.

OK, let me check it out; I may need you to test for me, as I don’t know if I have something here that requires it.

1 Like