The optimal solution would be to use hostnames instead of IP addresses, but unfortunately that is not supported in the Edge environment.
Are you using Rules to build your requests on the fly? I’m trying to better understand how you have things set up.
In case you weren’t aware, I have an Edge driver specifically for Shelly devices. There is a driver specifically for Gen1 devices, and a separate one for Gen2 devices. The Gen1 driver requires you to configure the device IP address, so it may not necessarily make things much easier when IP address change due to device swap-out. The Gen2 driver, however, auto-discovers devices, so that issue is addressed.
The ST Edge Web Requestor is a driver that enables local devices running on the ST Edge platform to issue POST and GET HTTP requests. This driver allows these devices to interact with remote web services and retrieve or send data over HTTP.
With the Web Requestor driver, developers can implement various use cases such as:
Data retrieval: Devices can issue GET requests to fetch data from remote servers or APIs. This allows devices to retrieve information such as weather data, stock prices, or any other data available through web services.
Data submission: Devices can send data to remote servers or APIs by issuing POST requests. This enables devices to push sensor readings, device status updates, or any other relevant data to a remote server for processing or storage.
Integration with web services: The Web Requestor driver allows devices to integrate with various web services and leverage their capabilities. For example, a device can interact with a cloud-based service to perform complex computations or access additional functionality.
By providing the ability to issue local POST and GET requests, the Web Requestor driver enhances the capabilities of devices running on the ST Edge platform and enables seamless integration with external systems and services.
Apologies for the delayed response here - and thanks for your feedback.
While I am using Shelly devices, I have them flashed with Tasmota firmware as I need some specific functionality (Tasmota can send a “blink” command for the device to process/perform via http GET request).
Context:
I’m using the Shelly device to control the color of a pool light. The pool light operates in such a way that to change to a specific color you need to power cycle the light a certain number of times. So, for example, blue will be 10 on-off cycles, green would be 11, white 12 etc.
So, to control the Shelly I create a new device via the web requester master in Smartthings. Within this newly created device settings I manually enter into Web Request 1 the GET request to the Shelly IP address with the relevant tasmota parameters to switch the pool light on. In Web Request 2 I enter in the string to switch of, and then in request 3 - 14 I enter all the various requests for the individual colors.
So, in a nutshell I have 16 pre-configured web requests in this device, each of which require the IP address of the Shelly. If this Shelly needs to be replaced, to avoid having to manually edit each of those requests with the new IP number of the new Shelly, I basically force the new device to use the same IP address as the previous Shelly.
Hope this all makes sense.
So - my question was along the lines if in the web requester device setting, there wouldn’t be a way to define the IP address up front, so that all the subsequent web requests already pull from this field rather than having to enter it for all the request fields manually.
I love this driver, thank you so much for sharing it.
Has anyone figuted a way to trigger an http command on a scheduled basis? Effectively I would like to poll an http service and do something with the response…
Tnx!
Hi. Are you not able to do this with the options available in automation routines? If not, you might find useful my timer/counter utility driver which could give you some additional ways to trigger an automation - either every n seconds/hours/days/weeks, or based on a simple counter.
Can you elaborate on what you need to do with the response?
The webserver on your ESP8266 would need to be able to accept an additional parameter to invoke the command you want. Or it would need to provide alternate endpoints - one for open, and one for close. Right now it’s just displaying a simple web page with buttons, expecting the user to press one of them from a browser. The web page is in fact being returned to webrequestor, thus the text you see in the response data field. So you know it’s working, but it’s returning a web page which you really can’t do anything with in webrequestor.
Is it possible your webserver accepts something like this?
In another thread, Graham suggested this thread to possibly solve my problem with Photon Particle and smartthings (ST). I made a device that uses a Particle to drive a servo that opens a remote HVAC vent in my garage. It used to show up as either on or off in ST. Now it only shows “connected” in ST and will not control the device. The driver is now shown as “LAN Thing” and I used ti have it set up with a handler in the old ST. It worked for 2 years flawlessly. unfortunately I am not very knowledgeable about how the various software components work together so cannot determine if your driver is a good solution path for my issues. Searched Particle Photon and edge drivers and came up empty handed. Any help is greatly appreciated as the HVAC device I designed was an awesome help in my garage and is now basically useless.
For Alexa integration, you’ll need to do it through the creation of some automations, since you won’t be able to control webrequestor directly from Alexa. One way to do it is to create a virtual switch that you can control via Alexa. Then create a couple automation routines: one to execute the specific webrequest for open when the switch is ‘on’, and one to execute the specific webrequest for close when the switch is ‘off’. You’ll find that when you define actions in automation routines for a webrequestor device, you’ll be able to choose which ‘slot’ number to execute. The downside of this setup is having to use the terms ‘on’ and ‘off’ with Alexa instead of ‘open’ or ‘close’. There might an alternative to this with using a virtual blind device to address that, which I think can be controlled from Alexa.
A more stream-lined way to do the automations would to use Rules, where you can actually specify the webrequest itself within the rule. See the readme file for more info and an example.
That’s usually because something is wrong with the format of the request string. Double check it for correct syntax or post screenshot here so I can take a look.
I think Andriod app is showing things slightly different from what I see in my iOS-based app. Can you check the extra fields you aren’t using like Body, More Body, and Headers for both request #1 and #2, and make sure they contain ‘–’ (double dashes)? I’m seeing “Custom trigger=” in your body field - is that something you typed?
