[Feature request] Receiving value from web-server in response to SendToHTTP

[sparkescreative]

Hi ESP Masters

Just wanna say I absolutely love your work.

I have a feature request - I think?

I would like a way to get an ESP Easy to send an external server a value and receive a value as a response?

For example an ESP with a button

1. Button gets pressed
2. ESP Sends unique value to web server via SendToHTTP
3. Server processes value in php and responds with either value 0 or 1 for example
4. ESP runs rule depending on received return value of 0 or 1

I really hope somebody understand what I'm getting at!

It's the receiving of the value and being able to process it that I'm looking for.

Is this something that could be added?

[uzi18]

@TD-er maybe it is something for string events? #2787

[TD-er]

@uzi18 I think it can indeed be done like that.

So just to sketch the rough idea for this feature request:

• Send an async http request with an extra parameter to mark the return event
• Receive an event with the extra marker and the returned string value ("0" is also a string)

This can then also be the fix (finally) for the long requested async version of SendToHttp and actually waiting for the reply, which is needed for more services like ThingSpeak.

[sparkescreative]

The speed in which you guy's reply on this forum is insane.... Thank you.

This would be an extremely useful feature for so many reasons.

Something like this as the rule outgoing rule...

and then a rule something like this using the response...

I just wish I was more skilled at coding for ESP's and ESP Easy so that I could help. I'm a long time supporter and have been using it for over 2 years. I've made loads of little things from my underfloor heating to my garden lights and they all run on ESP Easy. Everything gets logged to a web server but I keep coming across situations where a return value would be incredibly useful.

Just to keep everybody motivated I've attached a few of screenshot of my platform at the moment.

[TD-er]

Just curious about that logo. Was that burnt in there with a laser engraver, or do you have it cut out of metal and just burned it in there while it was hot?

And about the idea I have for the new/improved version of SendToHttp is just adding an extra parameter to it.

For example:

SendToHttp domain.org,80,/getvalue.php?foo=[task#name],replyEventName

...
on replyEventName=1 do
  ...
endon

Or even with working %eventValue% or %eventvaluestr% as suggested in the issue linked by @uzi18

[sparkescreative]

Yes that would work great. Sorry I didn't fully get it the first time I read it.

The (,replyEventName) on the end and the (On replyEventName=1) rule are a great solution.

No pressure - hehe - but when were you thinking of implementing it if this is the way we're going to go.

Regarding my logo in the wood the first one I did I recessed slightly with a chisel and painted it. The second one I made like you suggested was burnt in with a little bit of metal. Now however I'm using a stencil and a spray can... lol

I have know idea about the ones in the pictures above as I have 25+ little pods. A few of my friends have them in there home's and business'. They can all log into the web platform I have built and only see there own pods.

[giig1967g]

@TD-er in this case the command's 4th argument must be optional.

[giig1967g]

SendToHttp domain.org,80,/getvalue.php?foo=[task#name],replyEventName

... on replyEventName=1 do ... endon

What if you use variables? SendToHttp domain.org,80,/getvalue.php?foo=[task#name],%v1%

[TD-er]

in this case the command's 4th argument must be optional.

Yep, or maybe even use a different command name to make it clear it is the async one.

What if you use variables? SendToHttp domain.org,80,/getvalue.php?foo=[task#name],%v1%

I think it should just work.

[giig1967g]

If I may suggest a naming convention, we could use: SendToHttp, SendTo, SendToUDP, etc. to send a command GetFromHttp, GetFrom, GetFromUDP, etc. to receive a value back from a controller in this case the arguments will all be mandatory.

[sparkescreative]

If I may suggest a naming convention, we could use: SendToHttp, SendTo, SendToUDP, etc. to send a command GetFromHttp, GetFrom, GetFromUDP, etc. to receive a value back from a controller in this case the arguments will all be mandatory.

I totally agree with this if it's going to be a separate command. It makes it self explanatory.

[sparkescreative]

SendToHttp domain.org,80,/getvalue.php?foo=[task#name],replyEventName ... on replyEventName=1 do ... endon

What if you use variables? SendToHttp domain.org,80,/getvalue.php?foo=[task#name],%v1%

Maybe this solution is the cleanest though?

[TD-er]

If I may suggest a naming convention, we could use: SendToHttp, SendTo, SendToUDP, etc. to send a command GetFromHttp, GetFrom, GetFromUDP, etc. to receive a value back from a controller in this case the arguments will all be mandatory.

Looks nice and clean to me.

[sparkescreative]

If I may suggest a naming convention, we could use: SendToHttp, SendTo, SendToUDP, etc. to send a command GetFromHttp, GetFrom, GetFromUDP, etc. to receive a value back from a controller in this case the arguments will all be mandatory.

Looks nice and clean to me.

Sorry it is also a clean solution. I didn't mean to offend you. I should of said easier because I assume adding a new command was harder than adding to an existing command.

[TD-er]

@sparkescreative Don't worry, I'm not that easy to offend :)

[sanyafifa]

It would be great! I like the free service for sending data from sensors https://narodmon.com. It supports feedback for devices. Here is an example from the help:

For TCP, GET, POST protocols, instead of the typical "OK" and in the absence of errors, the project server in response to the testimony transmits commands starting with the "#" character and separating the commands through ";" without spaces in chronological order to avoid overflow of the receive buffer on weak devices up to 5 in 1 session. Examples of TCP, GET, POST: gpio12 = 1 or interval = 300 or ip = 10.0.0.10

[TD-er]

Hmm that's a nice site. Will bookmark it to later check it out to see what possibilities we may have with this geo-based sensor logging.

[uzi18]

my vote is for first idea/example https://github.com/letscontrolit/ESPEasy/issues/2796#issuecomment-561146538

so you can prepare extra action for your specyfic request

[TD-er]

@uzi18 Using the extra parameter as I suggested, but maybe change the command name into GetFromHttp ? The thing is, we had a lot of users having issues with the new rules parsing, so I added a "patch" setting, to be less strict in parsing the last parameter. But this also makes it hard to add an extra parameter to the existing command. Also when creating a new command, you also imply the ESP will wait for an answer, even though the resulting event will maybe not be processed in the rules. This gives the explicit option for users to have a version of SendToHttp which does not close the connection until a reply is received.

I've looked into this and it looks like I may have to use the same code as I added for the Settings Archive option, but this does add quite a big part to the binary size. (10 - 15 k if I am not mistaken). So this command must have its own define to be included in the code, or else it will be next to impossible to make minimal_OTA builds.

Any ideas on that?

[uzi18]

@TD-er maybe there should be also option how many optional parameters are supported by command?

other idea is to add command to check received buffer

1. SendToHTTP will send request and store received buffer 2a. command like "CheckHTTPResponse,string,event" found string -> generate event 2b. [HTTP#string] if found returns 1.0 2c. [HTTP#string#value] if found header with value returns 1.0
2. if next SendToHTTP command fill buffer with new response
3. if end of rules procesing drop buffer

[TD-er]

Well for async handling you should add a label to it, or else you will evaluate the wrong reply. And I really would like to get rid of commands that keep the rules execution blocked.

For new commands we can enforce how the arguments should look like, but for existing ones we may need to be a bit more tolerant or else existing rules will no longer work.

[uzi18]

it can be used for new implementation of rules, so special file will be executed. for old one we can block on response check

[agroszer]

Looks like this thread/idea died?

My usecase would be to read a (simple) value from a request. Precipitation from a nearby weather station as a number.

[TD-er]

Currently the HTTP return code (e.g. 200 or 404, etc) is sent as an event after a SendToHttp command.

[sparkescreative]

I originally wanted to process something on a server and return a value to esp easy. Just having it return 200 would work for me.

[TD-er]

This event with the return code is relatively new, so you need a build from the last few months.

I am not 100% sure, but you might need to check "SendToHTTP wait for ack" on the Tools->Advanced page.

[agroszer]

Any plans to implement something in the near future? The simplest thing to receive a number would do it (for me)

[TD-er]

Yep, there are plans to implement something similar to what MQTT import does. However the exact form isn't clear yet.

It could be something for an HTTP controller, or a plugin like MQTT import. Sending the full page as part of the event value in the event isn't a good idea, so not sure yet what would be a good approach to this.

[tonhuisman]

The simplest thing to receive a number would do it (for me)

As suggested, with the Tools/Advanced option SendToHTTP wait for ack enabled, on completion of the request you will see an event being generated like http#<ip-address-or-domain-name>=<http-result-code>, so that can be handled by having a rule like this:

on http#<ip-address-or-domain-name> do
  if %eventvalue1%>=200 and %eventvalue1%<400
    // All is fine
  else
    // Some error occurred
  endif
endon

(air code...)

[TD-er]

A recent related request: https://github.com/letscontrolit/ESPEasy/issues/4539