Rule Engine - Http POST Issue

[Bry]

I am trying to use Rule Engine to make a POST/JSON request to a local device (a WLED server on the local network). The command will turn the attached LEDs on or off. My problem, I THINK, is that the target URL has to be Internet accessible.

I can curl to make this work: curl -X POST -H "Content-Type: application/json" -d {"on":true} 192.168.0.175/json/state from my local network, so it makes sense that I can reach a private address.

I also have it working with a webCore piston:

define const boolean on = true;
Make a POST request to http://192.168.0.175/json/state with JSON encoded data {on};

I’d like to get it working in Rule Engine, if for no other reason than to learn it a bit better. Is there a way around the public IP requirement?

[Bloodtick_Jones]

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?

[Bry]

@Bloodtick_Jones

Are you running SmartThings or Hubitat?

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.

[Bloodtick_Jones]

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.

[James]

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.

[OBSOLETE] Virtual HTTP Switch/Button Creator

[Bloodtick_Jones]

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.

[Bry]

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!

[b_geee]

@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?

[josh]

@b_geee

@josh how come you can’t send Get requests like webCoRE that also runs in the cloud?

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.

[b_geee]

Thanks Josh, I eventually found the workaround of using Web Requestor after some hours of confusion, then panic!

[Malcolm_Graves]

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?

[b_geee]

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.

[Malcolm_Graves]

ok that make sense, would you mind posting an example or screenshot of what you did?

[b_geee]

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.

[Malcolm_Graves]

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.

[b_geee]

I changed to desktop mode on Firefox with my S22 but it didn’t make much difference…

[Chris_C]

@Malcolm_Graves

It would help if they would let you select multiple devices at the same time.

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

[Malcolm_Graves]

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.

[Bry]

@Malcolm_Graves

broadcast to my speakers in the home. I would like to move that over,

If you’re using SmartThings, that might be easier to do with a Routine, presuming that your speakers are supported…

[josh]

@Malcolm_Graves

and then broadcast to my speakers in the home.

I answered a similar question over in the SmartThings community.

[ST Edge] Web Requestor: a driver to issue local POST and GET HTTP requests - #209 by joshua_lyon - Community Created Device Types - 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…