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

I’ve updated all my virtual switches so that they are using the correct driver 2022-06-20T15 but the routines that activate the pre-configured web requests no longer work on any of the virtual switches. However, if I go into the “no room assigned” screen and click the web requestor icon and select any of my pre-configured web requests they all seem to work fine.

I even tried deleting a virtual switch and re-configured the proper routine with the correct pre-configured web requests and that doesn’t work either. Anybody experiencing anything similar?

What exactly do you mean by this? You should not have had to manually update the individual vEdge switch devices to the new driver. The updated driver should have automatically been installed onto your hub and the creator device plus any virtual devices you had previously created should have all gotten updated. The only exception to this was the door device, which needs to be recreated under the latest driver.

Regardless of the above, if you created a new virtual switch and it still isn’t triggering your web request, then we need to figure out why. I tried to reproduce what you’re seeing, but couldn’t.

What mobile app OS are you using?

If you continue to have this problem, could you run some logs with the CLI tool?

Can you elaborate on exactly what is happening? Are you having broken cloud issues on the device fields, or something else?

Can you post a screen shot of what you are seeing in your app?

Actually, I created switches for “virtual window shades” switches. In order to get these switches to work I create a routine using the if/then prompts available in the individual switch. I can send you screen shots if that will help. I’ll also run some logs with the CLI tool.

I’m using IOS on an Apple iPhone 12 Pro.

Thanks

No not getting broken cloud icons, and I don’t have the CLI available at this time so I can’t be too useful. Just that the same url works on V1, but not on V1.2 for me at the moment, and I’m also not getting a response on V1.2, last response was a few days ago it said “timeout”.

Have you tried to uninstall and reinstall the driver? It sometimes happens that drivers don’t get properly installed and initialized on the hub. Alos, please make sure you have version 2022-06-20T15:43:45.84981114

I thought I should post here a very strange experience I just had: I went to do some testing with this driver and kept getting network errors in the mobile app when selecting a web request to execute. I fired up logging and saw there were NO events being posted to the driver from SmartThings. In other words, nothing was being executed for this driver. I tried different web requests and different devices for about 5 minutes, but still NOTHING. I tried a couple OTHER drivers and they seemed to be working fine. Then I thought I’d try changing a device setting back in Web Requestor to see if that would result in logging activity - still nothing. Then all of a sudden I started getting a BUNCH of log messages - seemingly queued up activity from all those prior attempts I’d being making for several minutes. From that point on, the driver worked as expected…

I’ve no idea why this happened and it’s the first time I’ve seen something like this. It was as if that particular driver was ‘stuck’ and not getting any execution time for some reason. Seemed to be a random occurrence, but thought I’d share the experience because it says that Edge devices could go unresponsive, and then start working again for no apparent reason.

Just a feedback on my use of “Web Requestor Multi v1.0” and “Virtual Devices V2” - can control now lights on a ESP8266 managed by ESP Home (vEdge Momentary button + routine when pressed to post to device directly a toggle action via Web Requestor). Background - using Home Assistant without cloud access for multiple ESP8266, ESP32 with multiple sensors … in parallel with Smartthings (all devices moved successfully to Edge drivers). Thank you very much for great work @TAustin!! … next will need to get my ESPxx sensors on Smartthings … no time for this yet, any suggestions welcome.

Awesome feedback, thanks!

Do they support MQTT?

Yes, however, I do not use/like MQTT, will try to use http (similar to what works already with HA).

@TAustin - will try to use your other excellent work ( forwarding bridge server, lan based motion …) … need some time to play with ESPxx setup. No intent to use MQTT.
… update:
can see now a motion sensor from a ESP8266 on Smartthings. Used your edgebridge.py, LAN Device Trigger V2, and managed to set the ESP8266 to send http posts to the bridge with motion on or off … Again - amazing work on your edge drivers and tools, as well on documenting them, thank you!!!

Terrific! Glad you are having success!

On the v44 firmware this isn’t working anymore, immediate timeouts.

But I made a pull request on github, because I decided to track it down. :slight_smile:

Any thoughts on supporting DNS?

Any luck? Is your hub one of the ones that got reverted back from the 44.000006 beta?
You might try just rebooting your hub.

Tell me your thoughts on this. How would you use it? I have a stand-alone mDNS explorer driver but I haven’t thought about adding that function the web requestor driver…

Yes, the pull request has been working perfectly well on my hub.

I don’t know if I got reverted back from the 44.000006 beta, but I don’t remember enrolling in that beta, so probably not.

On DNS, well… I’m not really thinking about mDNS, the DNS server that the hub gets pointed at by DHCP will quite happily resolve my internal host names, and I even have perfectly valid LetsEncrypt certificates for those hosts. :slight_smile:

And I even have a web server with such a cert and host name in the same VLAN as the hub.

It’s remotely possible that at some point I went slightly further in my home network setup than most people would.

1 Like

Ah ok, so you are asking to be able to use hostnames in lieu of IP addresses. I think all I would really have to do is remove the IP address validation that’s done on the configured URLs, but I’ll take a look at it.

Hello, how do I use it with basic authentication?
Example
username:password@192.168.1.x/exec?cmd=test

1 Like

Unfortunately the current driver probably won’t accept that as a valid URL. Does the endpoint allow for providing those as parameters? i.e.

GET http://192.168.1.x/exec?cmd=test&username=\<username>&password=<password>

Unfortunately no…