The SharpTools rule engine is running outside of your local network and you will not be able to access a 192.168.x.x address (or any other private address) since it not on your local LAN. There are solutions to tunnel and then DNS, but a ‘better’ solution would to run a local device handler on your hub. Are you running SmartThings or Hubitat?
1 Like
I’m running SmartThings.
Makes sense that the Rule Engine isn’t running locally hence needs an external address. But webCore isn’t running locally either and I can use a private address.
webCoRE does issue the command within the local LAN when using a non DNS address. It uses the hubAction class to have the SmartThings query devices local. Outside of the externally hosted web GUI, webCoRE itself is just a [very] well designed SmartThings application and has the same ability to issue commands from the hub just like any other purpose built SmartThings application.
2 Likes
Update: With the deprecation of Groovy, you may want to use the Web Requestor Edge Driver as the HTTP Button will no longer be available.
@Bry you may want to check out the HTTP Button device below as @Bloodtick_Jones allured to, which also uses hubaction to send local HTTP request, and you will just use the rule to trigger the button push to send the HTTP request locally.
1 Like
IMHO - Probably better to use webCoRE similar to your test and hit the pistons external address with SharpTools. Since webCoRE is a ST application and not Device Handler it should be in viable longer as they depreciate groovy. The SmartThings team has indicated that applications will move later.
Thanks. It’s working in webCore, predicated on a switch turning on and off. I’ll revisit down the road as things deprecate. I was asking more for education sake. Thanks for the help!
1 Like
@josh how come you can’t send Get requests like webCoRE that also runs in the cloud?
Have you thought about using HubAction to do it? Could you add it at some point in the future? Does this feature need voting on?
Hi @b_geee-
Welcome to the community and thanks for posting!
The next-generation SmartThings REST APIs don’t offer the ability to send HTTP Requests locally.
The Web Requestor Edge driver seems to be a popular choice for this. You can use it in your SharpTools rules to make HTTP calls within your LAN.
Thanks Josh, I eventually found the workaround of using Web Requestor after some hours of confusion, then panic!
1 Like
I’m looking into moving everything over from webcore and it looks like I’ll run into the same issue you did. What was your work around using web requestor?
Basically on a whim, I tried using Web Requester as a “device” to access and send web requests on the local network, and unlike ST’s Routines, you can send more than one.
1 Like
ok that make sense, would you mind posting an example or screenshot of what you did?
Sure, here’s the screenshot.
You can see the Web Requestor part. The rule is still incomplete, as it’s too cumbersome and time consuming to finish. I have 10 radio switches that 9 need to turn off when 1 turns on, that then sends Radio URL to a speaker, and a local web request to a Raspberry Pi to change a media image on a dashboard. On webCoRE it took minutes, here I’ve only done 2, I would need a day to complete it. Very underwhelmed with Sharptools at the moment, it’s like trying to drive a car whilst being in a straitjacket.
Something odd is going on with the screenshot, everything is on top of each other. I agree using sharptools is a bit cumbersome compared to webCore. It would help if they would let you select multiple devices at the same time.
1 Like
There’s a request open that you can vote for Select multiple devices in rule triggers and actions
The Web Requestor is just be a GET or POST command to the address
Thanks for the info, I voted on the request. I currently have some automation that checks if the garage door was left open and then broadcast to my speakers in the home. I would like to move that over, would that work in sharptools.
If you’re using SmartThings, that might be easier to do with a Routine, presuming that your speakers are supported…
I answered a similar question over in the SmartThings community.
Web Requestor has 5 slots that can be preconfigured with ‘body’ data to be sent over with the request. But these don’t include a JSON ‘content-type’ header, which means it won’t work with a lot of servers.
I submitted a request to either default to JSON or provide a configuration option… and also to expose the ability to dynamically send body content via the Web Requestor driver. It sounds like the device author has their hands full at the moment, but lets see what happens…
Thanks for the info I’ll take a look