Could I use this driver and Tasker to activate automations when scanning nfc tags?
Since I have an iPhone, I really donât know much about Tasker, so not sure I can answer. If you tell me a little bit more what you want to do I could advise on if Web Requestor might be part of the solution.
Think of Web Requestor as a tool that you can trigger to send predefined HTTP(s) requests (GET or POST) to any IP address on your local LAN. You can load it up with up to 50 different HTTP requests and initiate any one of them from an automation or Rule, or manually via the mobile app. If you have a device that supports a RESTful API, it can be used to send commands to that device. Itâs best used for creating static HTTP requests, not for requests that require additional payload data (json, etc.).
1 Like
Tasker on an Android device can read NFC cards, then you can create Tasks. Tasks could include Http requests, gets, posts plus many other things.
With the right plugins it could also trigger SharpTools and/or Alexa routines.
Thanks @Paul_Oliver; thatâs helpful.
@Sakari -
So in this case Tasker would be the initiator of the HTTP requests, which you would want to use to trigger something in SmartThings. This would be fairly easy to set up using my bridge server in conjunction with one of my companion Edge LAN drivers (LAN trigger, LAN motion, or LAN presence).
Thereâs a video in Youtube how to do it with Tasker app and Sharptools. That of course is not local execution, but with Web Requestor it would be. I read all the documentation you have written and Iâm quite confident I could make this work on my own. Iâll ask further help later. Now that I know nfc tags could be used I need to buy few of them for testing.
1 Like
Sounds good; always here if you need any help!
For testing purposes you donât need to buy any NFC tags, you can use a regular bank card, that triggers Taskerâs NFC protocol. Try it.
Funny thing, I just thought of this while cycling home from work. If it could work. 
Hello all,
This may have been done before or even potentially a few times on the thread. I wanted to write up essentially a case study of how to use the Web Requestor driver to control a device that can accept REST API request.
In my instance, I am using the Web Requestor driver to control a raspberry pi that has a software called Falcon Pi Player on it. This software (FPP) is used to control christmas light shows (addressable RGB lights in mass).
Web Requestor, in my instance, is sending âGETâ request to FPP in order to do things such as âStart a Playlistâ, âStop a Playlistâ, âRepeat a Playlistâ. Essentially if an open API exist for your project and it accepts static âGETâ request. It can definitely be done with this driver. Someone here on the thread or the developerâ> @TAustin was very helpful in helping me to get it running and everything that will be spoken of in the following post went well with no issues. Also, thank you to @JDRoberts for helping me connect with @TAustin as my original approach to this project was going to be to use MQTT for connection to FPP. As of this writing, there is not an Edge Driver available for MQTT. I have a feeling this is going to change in due time thanks to the expertise of @TAustin. For Now the Web Requestor with itâs Rest API was the quickest way to get smartthings communicating with FPP.
The following is how I got everything connected. These may help you get everything connected for your project as long as your requirements are similar. (Sending static GET request by Rest API to a project of your choosing that has a documented API)
The link to the GITHUB is in the first post of this thread. It has also been reposted here:
https://github.com/toddaustin07/webrequestor/blob/main/README.md
Here are my âlaymanâ instructions:
Go to the following link and âEnrollâ and click into "Available Drivers"
Shared Projects Channel- @TAustin
Next, install the âWeb Requestor Multi v1.0â and if you are wanting to controller whatever you are doing by a voice assistant, i.e.) Google Assistant, Amazon Echo, go ahead and Install âVirtual Devices V2ââ> this will allow you to create virtual switches. You will then use the virtual switch in a routine to send your GET Request to the project you are wanting to communicate with that has documented API.
Now that you have these 2 drivers installed.
Go to your smartthings app (you must own a hub for this whole process to work). Use the search for devices feature. The smartthings app will find a device related to both the Virtual Device Driver and the Web Requestor Multi v1.0 driver. Each of these will be used to create the devices necessary to run your externally driven API project. The devices (really they are device creators-- more on that in the next step) will be in the âNo Room Assignedâ area.
Now, letâs create a device for the GET Request.
Click into the âWeb Req Multi Masterâ (You can change the name of the device if you would like)
Click Triple Dot
Settings
Add the GET request (to the âWeb Request #â input fields, leave all other at default)-- one to each of the 50 positions available.â> READ AND UNDERSTAND THE BELOW BEFORE DOING THIS
ANOTHER OPTION (which I chose): An issue I had in this step is that when you go to create your routine later in one of the following steps, there is no way to rename the âWeb Request#â input field so it can be difficult to keep track of which command you are selecting as your action within the routines area of smartthings. So, what I ended up doing to make this easier on myself is I used the âCreate New Deviceâ button on the main screen of the âWeb Req Multi Masterâ to create a new Web Request Device for each GET command I wanted to use. So instead of putting all of my request within 1 Web Request Device (you could put 50 total into 1 device). I created a bunch of Web Request devices using the âCreate New Deviceâ button on the Web Req Multi Master device page and only added 1 GET request to each Device. Then when I get to the routines page (here in the following steps), it is easier to know which Web request device to select as the action portion of the routine. The trigger will be the virtual switch and the action will be the web request device that you put your GET command inâ> If you did it like me, it would be the web request device with the same name and Request postion #1.
The 2 request (1 contains additional arguements) I used for FPP were:
Start and Repeat Playlist: GET:http://192.168.1.250/api/command/Start%20Playlist/1MINTIMER/true/false
Stop Playlist: GET:http://192.168.1.250/api/playlists/stop
You will need to review the API you are trying to integrate in order to get the above arguements etc. properly setup for your Web Request.
Now, letâs create our virtual switch that we will use to trigger the Web Requestor Device that was just created.
Go to the device in your âNo Room Assignedâ area that is named âvEdge Creatorâ.
Choose Quantity you want created, then select the type of device you want to create. In my instance I chose a momentary button (this actually creates 3 things within 1 device-- a contact sensor, a switch, and a momentary button.âI used the switch within Google Assistant for Voice Commands)
Click Triple Dot, Review Settings. I left mine a default. I wanted the switch to trigger then go back off after a few seconds. Default was good.
Then create a routine with the virtual switch as the trigger and the action as the web request device of more than likely the same name if went the route of my âOPTIONâ explanation a few paragraphs above.
I hope anyone that finds this in the future finds this helpful. I think between the GitHub readme and the post here. You will be able to understand and use the Web Requestor Driver with ease.
Thank everyone here for your help. @TAustin thank you so much for using your expertise to help us all out and make our smart homes better!!
@JDRoberts Thank you again for helping me get this going also!! A little different route than we originally were going to go but this works just as well!
9 Likes
Awesome write-up. Thanks for taking the time!
1 Like
I am unable to get this syntax working - any ideas?
First can you confirm the driver version you have installed? It should be 2022-05-13T17:50:11.90298
Second, do you have any way to find out if the request is actually being sent to that address? Do you have any console or log on your device that would let you know? Iâm trying to narrow the issue down to whether thereâs a problem with it being sent at all, or if the device doesnât like something about the syntax.
Also have you tried typing this same http request into a browser to see if it works from there?
Yes, it was working in a browser which is what was troubling me.
I ultimately got it to work with a GET by copying the webhook from an email rather than typing it in. Despite checking it 100 times, I must have not had it right.
Thanks very much and thanks for a great driver! Iâm using this to switch my Synology Surveillance Station (cameras) between Home and Away modes.
1 Like
WebRequestor is giving me a cloud for HTTP Request Response.
If you execute a configured web request, does it go away?
Nope. It just stays. I need to re-install driver and see if that helps.
All users of the Web Requestor driver:
Iâve pushed out an update to the driver to address âbroken cloudâ icons seen on the device fields as a result of a recent Android app update. These icons appear for any field that has not been explicitly set with a value, which can happen with new devices or devices with fields that have not been used.
The latest driver version is now 2022-06-20T15:43:45.84981114 and it will automatically be updated on your hub.
I believe that in most cases if you have a Master device that has been used at least once to issue a web request, that there should not be any broken cloud icons for fields that have had data displayed in them. If you still have a broken cloud in say, an extracted key value field because itâs never been used, then this should not affect the function of the device. And if the extracted key value field IS ever used, then the broken cloud should go away.
If you have created a secondary device and it has one or more broken cloud icons, then create another device once you have this driver update, and they hopefully will go away (all fields are now all initialized with blanks in this driver update).
I do not have an Android phone so have not confirmed the above is 100% accurate, so please post any further issues here and I will do my best to address them.
1 Like
@Sakari is WR working for you now? Not for me, I tried rebooting the hub but still nothing. V1 still works though, strange.
Nope, Still all clouds after update.