Ok. I’ve had someone else ask about accepting host names so that would require the same change. I’ll look at what I can do and get back to you.
For moment I’ve disabled the username/password as it is lan only, but will be a nice security addon if you can make it work.
1 Like
I ended up implementing support for passing a security token as a request parameter, to work around the lack of basic authentication in Web Requestor…
It wasn’t too difficult in the apache config, and I’d be happy to share that, but it sure sounds like we might just be getting a more capable web requestor soon. 
This is probably very dumb, but I can’t figure it out for more than two hours:
Say I get this responce from HUE Bridge:
{"name":"Living Room","lights":["46","40","39","38","4","5","45","7"],"sensors":[],"type":"Room","state":{"all_on":false,"any_on":false},"recycle":false,"class":"Living room","action":{"on":false,"bri":165,"ct":275,"alert":"select","colormode":"hs"}}
What should the “response key to extract” format be to get the value for “all_on”?
state:all_on doesn’t do it, nor state:{"all_on"} or any other weird combos of ", , and so on.
I’m can’t confirm it right now, but have you tried “state.all_on” ? Or even just “all_on”? I’ll check this when I can a bit later.
Both don’t seem to work.
name and type return the expected results, though.
Edit: When the value is true, it’s returned by all_on.
When it’s false, it doesn’t report correctly.
I think I know what could be happening, and it will require a fix to the driver code. Will try to get it done quickly.
Heads up that I’ll be pushing a driver update out soon that will have these changes:
- fix to response data key value parsing for boolean values as reported by @Peter_B
- addition of device settings option to set timeout value (current driver is fixed at 3 seconds, but there’s been a suggestion that that may be too short for some cases)
However before I push this update, I’ve found a slight change in the way the platform is handling selecting items from the ‘Select web request to execute’ button. It seems not to let you pick the same item twice in a row. For example if you select request #1 to execute and then want to execute it again, the app is not letting you; you have to select a different request (you can pick an unused one) before you can select request #1 again. It’s an irritating usability issue that I’d like to find a fix for. I don’t think it’s affecting automations. Is anyone else seeing this?
Driver Update:
Version 2022-08-15T02:52:07.653617524
See previous post for changes.
The issue with not being able to select the same web request to execute twice in a row is not resolved but has been reported to SmartThings. In the meantime, simply choose another unused http request slot before executing the same one again, or back out of the device controls screen and return.
hi could this be used to tell a google home mini to say something via tts.
thanks
martin
I don’t have Google Home myself so can’t answer with authority. It would need to have an http-based API available to send it commands.
Perhaps setting up an automation within Google home that could key off of a SmartThings device state would be an alternative way to go.
I have had great success with this driver with everything but IFTTT. Every time I try to execute a request I get “NOT CONFIGURED.” I carefully copied and pasted the URLs into the setting after confirming they were all working via the browser.
Any ideas?
Edit: NVM, forgot that I needed a bridge for non-local http requests. 
I’d have to see the string you configured. You can direct message me if it has private info.
Right! For anyone else new to this, be aware that Edge drivers are restricted to communicating with IP addresses on your local LAN. In order to use webrequestor (or any Edge driver) to access anything beyond that (e.g. IFTTT, SmartThings API, or any internet RESTful API) you’ll need to use my edgebridge server. You may also get a standard proxy server to work, but due to another Edge limitation, proxy servers will only work with http requests, not https. With my edgebridge server, you can use https URLs.
3 Likes
Can I use this with the Netatmo weatherstation API? Currently I’m using a smartapp for the netatmo integration which works perfect… but yea thats going away…
Great driver, I’m working with a Somfy Tahoma bridge, which has a local API, but it requires Basic Authentication, and quite a long JSON body (I keep hitting the character limit). Perhaps a few updates on those fronts?
I was forced to crack that nut in another driver of mine, so it’s possible I could integrate that code into this driver. I will look at it.
Are you hitting a character limit in the device settings field? I define no maximum for that, so I’m not sure there’s much I can do. It must be a SmartThings app limit.
Looking for some help , installed the driver successfully but struggling to basically copy my current webcore config
I would like to setup the first broadcast body so I can then setup the routines
I can steer you in the right direction, but since you seem to be using variables in webcore, you may have to adjust this a bit:
web request string would be something like this:
and your web request body would have to contain the actual values of those 4 variables (command, user, broadcast, converse):
{“command_value”, “user_value”, “broadcast_value”, “converse_value”}