SendToHTTP not working

Message

sentinel · #1 Post by **sentinel** » 26 Dec 2017, 15:28

Hi guys,
I wanted your help with SendToHTTP:
I have 2 wemos d1 mini, both flashed with EspEasy. The 1st wemos has a temperature sensor (DS18b20) and a TM1637 display. The 2nd wemos has an LCD display. I want to send the temperature from the 1st wemos to the second and display it on the LCD. I cannot get the SendToHTTP command to work. I tried a simple test rule on the 2nd wemos:

Code: Select all

On System#Boot do
    timerSet,1,10
endon
On Rules#Timer=1 do
  SendToHTTP <IP>,80,/control?cmd=lcd,1,1,test123
  lcd,2,1,- %systime% -
  timerSet,1,10
endon

The log shows:

Code: Select all

194787 : EVENT: Rules#Timer=1
194791 : ACT : SendToHTTP 192.168.1.72,80,/control?cmd=lcd,1,1,test123
201086 : ACT : lcd,2,1,- 16:19 -
201102 : ACT : timerSet,1,10
201105 : WD : Uptime 3 ConnectFailures 0 FreeMem 27992

The time shows correctly on the second line of the display, but not the text "test123"

When I enter the following from a browser, it works: http://<IP>/control?cmd=lcd,1,1,test123

Any ideas what I'm doing wrong?
(apologies if this is not the correct part of the forum to post this)

toffel969 · #2 Post by **toffel969** » 27 Dec 2017, 14:52

try

Code: Select all

On System#Boot do
    timerSet,1,10
endon
On Rules#=1 do
  SendToHTTP <IP>,80/control?cmd=lcd,1,1,test123
  lcd,2,1,- %systime% -
  timerSet,1,10
endon

You had a "," to many after the port number

vader · #3 Post by **vader** » 27 Dec 2017, 15:23

I have no LCD to test it, but the WIKI says:
SendToHTTP <IP address>, <Portnumber>, <command>

grovkillen · #4 Post by **grovkillen** » 27 Dec 2017, 15:47

I don't get it. Are you using SendToHTTP on the same unit as the LCD?

vader · #5 Post by **vader** » 27 Dec 2017, 15:52

That was confusing me too....

But he wrote, that it is just a "simple test rule"

toffel969 · #6 Post by **toffel969** » 27 Dec 2017, 23:48

vader wrote: ↑27 Dec 2017, 15:23 I have no LCD to test it, but the WIKI says:
SendToHTTP <IP address>, <Portnumber>, <command>

You are right, please ignore my previous post.

sentinel · #7 Post by **sentinel** » 29 Dec 2017, 13:07

Yes, I am using SendToHTTP on the same unit as the LCD. I tried using it on the other unit too, but it also doesn't work (unit-1 with the SendToHTTP Rule, sending the request to unit-2 which has the LCD).
Do you know if there's a way to analyse the http request message?
Do I need any particular settings in Devices --> LCD?

sentinel · #8 Post by **sentinel** » 03 Jan 2018, 21:19

I have tried a few things:
if the command is "lcd,2,1,hello world" --> the display shows "hello world"
if the command is "lcd,2,1,hello,world" --> the display shows "world"
if the command is "lcd,2,1,hello,wo,r,l,d" --> the display shows "d"
It seems that the software looks for the last comma and displays the text after that. So I thought there may be a similar problem with the HTTP request since the path contains many commas ("/control?cmd=lcd,1,1,test123").
I found that the HTTP request is generated in file "Command.ino", line #201. The path is built a few lines above (#196-197), using the function getParamStartPos (in file "Misc.ino"). I then made a simple c program and recoded the same function. The function works properly. So I guess that the HTTP request must be correct.

I also tried this:
SendToHTTP 192.168.1.72,80,control?cmd=lcd,1,1,%systime%
the log shows:
2858584 : ACT : SendToHTTP 192.168.1.72,80,control?cmd=lcd,1,1,16:44
which is an indication that it correctly inserts the time. But again, nothing displayed

Does anyone have any ideas? Can I test SendToHTTP in another way?
Is the comma handling (I described above) an error?

grovkillen · #9 Post by **grovkillen** » 03 Jan 2018, 22:03

But are these sent from the same unit as the LCD?

sentinel · #10 Post by **sentinel** » 04 Jan 2018, 07:38

yes, the SendToHTTP is sent from the same unit. I have tried the SendToHTTP from another unit. It also doesn't work

When it comes to the command "lcd,2,1,hello world", I can only send it from the same unit.

grovkillen · #11 Post by **grovkillen** » 04 Jan 2018, 09:31

I cannot understand that SendToHTTP would ever work on the same unit as the receiver. Why? Because the ESP8266 is a single threaded unit and during the time the unit is sending the HTTP request it is occupied doing that and are not able to respond to any HTTP requests. The internal rules are different since it will write to memory and in later loops the unit will read this from memory, thus you can make commands trigger internally.

So first of, stop experimenting with the command on the same unit that you want to test. Second I'd try to only use a computer to send these requests. If this is working as intended I'd start testing sending from another ESP unit. If this is not working we might have a bug on our hands.

sentinel · #12 Post by **sentinel** » 04 Jan 2018, 12:02

Thanks for the explanation and suggestions. I'll be away on a trip for 2 weeks. I'll try them out when I get back.
Do you know how could I somehow trace the http request message?

grovkillen · #13 Post by **grovkillen** » 04 Jan 2018, 12:40

I personally use Fiddler but Wireshark is also possible. Maybe even try Postman which I use for testing HTTP based API.

sentinel · #14 Post by **sentinel** » 11 Feb 2018, 10:22

Hi guys,

took me a while to reply. I think I found the problem. Let me give you some more information about my configuration:
module-1: wemos d1 mini pro, running build 120
module-2: wemos d1 mini pro, running a custom build: ESPEasy-v2.0.0-dev12+P073.rar, which I found here: Connecting a TM1637 4-Digit Display

The idea is: module-1 has an LCD display. Module-2 has a 7-segment display (supported by the custom build) and a ds18b20 sensor. Module-2 displays the temperature on the 7-segment display and also sends it using http to module-1.
Module-1 displays the temperature received.

Now, it seems there is a problem with sendToHTTP with the custom build. SendToHTTP works from module-1 to module-2, but not the other way around.
Do you have any ideas? Or how to further troubleshoot?

Thanks!

grovkillen · #15 Post by **grovkillen** » 11 Feb 2018, 10:29

Try the official (mega) build. The plugin is part of it now.

https://www.letscontrolit.com/wiki/inde ... nt_display

sentinel · #16 Post by **sentinel** » 11 Feb 2018, 16:11

thanks for the reply. I tried with this: ESPEasy_mega-20180209
but it still doesn't work.

And one more thing: When my Rules contain "on Clock#Time do" (to trigger sendToHTTP), I can see "ACT : SendToHTTP..." in the log. But when my Rules contain a timer, I don't see the timer expiring in the log (and the log entry about SendToHTTP). As if the timer never expires.

grovkillen · #17 Post by **grovkillen** » 11 Feb 2018, 16:25

sentinel wrote: ↑11 Feb 2018, 16:11 thanks for the reply. I tried with this: ESPEasy_mega-20180209
but it still doesn't work.

And one more thing: When my Rules contain "on Clock#Time do" (to trigger sendToHTTP), I can see "ACT : SendToHTTP..." in the log. But when my Rules contain a timer, I don't see the timer expiring in the log (and the log entry about SendToHTTP). As if the timer never expires.

Just so I understand. The time with timer is executed but the log is not populated?

sentinel · #18 Post by **sentinel** » 11 Feb 2018, 16:32

There's nothing in the log. I don't know if the time is executed, because all I had was the SendToHTTP. Or did I not understand your question?

grovkillen · #19 Post by **grovkillen** » 11 Feb 2018, 16:38

Yes, I wanted to know if the problem was that the rule never triggered or if it "only", was the missing information in log. I guess you don't know?

sentinel · #20 Post by **sentinel** » 11 Feb 2018, 17:22

no, I don't know, since what the rule contains is SendToHTTP, which also doesn't work.

sentinel · #21 Post by **sentinel** » 11 Feb 2018, 17:48

I think the rule is never triggered. I started 2 timers: When timer-1 expires, I switch the on-board LED on. When timer-2 expires, I switch it off. Nothing happens.

grovkillen · #22 Post by **grovkillen** » 11 Feb 2018, 17:54

You mind sharing screen shots?

sentinel · #23 Post by **sentinel** » 11 Feb 2018, 18:06

here is a screenshot of my rules. Do you need another tab?

grovkillen · #24 Post by **grovkillen** » 11 Feb 2018, 20:16

Okay, that explains it. You cannot use timers like that. They will start tugging for that poor gpio 2. You need to do it like this.

Code: Select all

On System#Boot Do
 TimerSet,1, 5
EndOn

On Rules#Timer=1 Do
 Gpio,2,1
 TimerSet,2,10
EndOn

On Rules#Timer=2 Do
 Gpio,2,0
 TimerSet,1,5
EndOn

You need to do this in order to know that they will trigger in sequence.

sentinel · #25 Post by **sentinel** » 11 Feb 2018, 20:58

This also doesn't work. My Rules are:

Code: Select all

On System#Boot Do
 TimerSet,1, 2
EndOn

On Rules#Timer=1 Do
 Gpio,2,1
 TimerSet,2,4
EndOn

//on Clock#Time do
//  SendToHTTP 192.168.1.9,80,/control?cmd=lcd,1,1,--%systime%--
//endon

On Rules#Timer=2 Do
 Gpio,2,0
 TimerSet,1,2
EndOn

Take a look at the log:

Code: Select all

5390 : EVENT: System#Boot
5395 : ACT : TimerSet,1, 2
5426 : EVENT: Processing time:36 milliSeconds
5427 : WD : Uptime 0 ConnectFailures 0 FreeMem 18832
5442 : EVENT: Clock#Time=Sun,21:50
5474 : EVENT: Processing time:32 milliSeconds
32470 : EVENT: Clock#Time=Sun,21:51
32498 : EVENT: Processing time:28 milliSeconds
35426 : WD : Uptime 1 ConnectFailures 0 FreeMem 18688
65426 : WD : Uptime 1 ConnectFailures 0 FreeMem 18688
92724 : EVENT: Clock#Time=Sun,21:52
92751 : EVENT: Processing time:27 milliSeconds
95426 : WD : Uptime 2 ConnectFailures 0 FreeMem 18688
125426 : WD : Uptime 2 ConnectFailures 0 FreeMem 18688
152837 : EVENT: Clock#Time=Sun,21:53
152864 : EVENT: Processing time:27 milliSeconds
155426 : WD : Uptime 3 ConnectFailures 0 FreeMem 18688
185426 : WD : Uptime 3 ConnectFailures 0 FreeMem 18688
213269 : EVENT: Clock#Time=Sun,21:54
213296 : EVENT: Processing time:27 milliSeconds

I think the timer starts but never expires?
I have also tried my code (the one in my screenshot) in a module running build 120 and it works ok.

TD-er · #26 Post by **TD-er** » 11 Feb 2018, 21:27

Don't use spaces here:

Code: Select all

TimerSet,1, 2

Instead use:

Code: Select all

TimerSet,1,2

grovkillen · #27 Post by **grovkillen** » 11 Feb 2018, 21:41

TD-er wrote: ↑11 Feb 2018, 21:27 Don't use spaces here:
Code: Select all
TimerSet,1, 2
Instead use:
Code: Select all
TimerSet,1,2

Yes, my phone added those spaces. Sorry!

sentinel · #28 Post by **sentinel** » 12 Feb 2018, 18:14

thanks guys. I tried it without space but it also doesn't work

After the module boots, I can see the following in the log:
5449 : ACT : timerSet,1,2
but there is no other similar log entry. And of course no led blinking

grovkillen · #29 Post by **grovkillen** » 12 Feb 2018, 18:21

sentinel wrote: ↑12 Feb 2018, 18:14 thanks guys. I tried it without space but it also doesn't work
After the module boots, I can see the following in the log:
5449 : ACT : timerSet,1,2
but there is no other similar log entry. And of course no led blinking

Please try another esp board if possible.

sentinel · #30 Post by **sentinel** » 13 Feb 2018, 19:24

Hi,
ok, I flashed my other module with this binary: ESP_Easy_mega-20180209_test_ESP8266_1024.
The timers start and expire correctly, led flashes. I also added a SendToHTTP command when a timer expires. It also works! I am sending the http request to my laptop. I have apache and run wireshark so I see that the request from wemos is fine. I'll test sending it to the other module with the display (I need to do some re-wiring). But it should also work.
I'll erase the flash and re-flash the other module. What can be the problem?

grovkillen · #31 Post by **grovkillen** » 13 Feb 2018, 19:27

Corrupted flash maybe. Hard to tell.

sentinel · #32 Post by **sentinel** » 18 Feb 2018, 18:10

I think the problem is with the TM1637 plugin:
When I disable the plugin and reboot the device, both the timers and SendToHTTP work. When I enable it, both stop working. This happens with both my modules.

grovkillen · #33 Post by **grovkillen** » 18 Feb 2018, 19:06

What version are you running?

sentinel · #34 Post by **sentinel** » 19 Feb 2018, 09:07

I am running: mega-20180209 (ESP_Easy_mega-20180209_test_ESP8266_1024.bin)

sentinel · #35 Post by **sentinel** » 19 Feb 2018, 15:21

I have also tried the following rules:

Code: Select all

On System#Boot Do
 SendToHTTP 192.168.1.2,80,/control?cmd=lcd,1,1,booting
EndOn

On Clock#Time Do
  SendToHTTP 192.168.1.2,80,/control?cmd=lcd,2,2,--%systime%--
EndOn

and the behaviour is the same: when the plugin is not enabled, both SendToHTTPs work. When it is enabled they don't work.

Just to clarify: when I say "plugin enabled" I mean that I have configured the display and then I enable/disable it using the tick-box.

sentinel · #36 Post by **sentinel** » 03 Mar 2018, 22:39

did you reproduce it?
I'm trying to find out what goes wrong when the 7-segment is enabled. I'm slow

I can see that after I enable the device, when the code reaches the point to check if there are any timers active, it finds no timer active.

TD-er · #37 Post by **TD-er** » 03 Mar 2018, 23:43

There has been a proposed fix for these displays.
It was just merged, so perhaps check tomorrow's build?

sentinel · #38 Post by **sentinel** » 05 Mar 2018, 17:38

no, unfortunately the problem still exists. I tried with ESPEasy_mega-20180305.zip

walmtech · #39 Post by **walmtech** » 17 Mar 2018, 00:49

Still broken for me on ESPEasy_mega-20180315.zip

TD-er · #40 Post by **TD-er** » 17 Mar 2018, 12:00

Could you add an issue on Github about this, describing as much as you can.
I'm loosing track of where to gather information on issues/bugs here on the forum and although the issue list on Github isn't perfect either, it is at least a bit more contained than the forum here.

sentinel · #41 Post by **sentinel** » 18 Mar 2018, 13:28

I have done it: #1111: Timers, Commands not working with P073 plugin

sentinel · #42 Post by **sentinel** » 25 Mar 2018, 17:49

Should we add a note in wiki in the plugin development page to indicate that plugins should not by default return success = true (if the plugin didn't do anything), since Rules, Timers and other plugins will be affected?

TD-er · #43 Post by **TD-er** » 25 Mar 2018, 20:22

sentinel wrote: ↑25 Mar 2018, 17:49 Should we add a note in wiki in the plugin development page to indicate that plugins should not by default return success = true (if the plugin didn't do anything), since Rules, Timers and other plugins will be affected?

I totally agree such important things should be documented.
And maybe we should just add some kind of template file for plugin/controller in the sourcecode, describing what should be where.
This may be comment code, but it should turn up when searching for some keywords in the source.

sentinel · #44 Post by **sentinel** » 27 Mar 2018, 17:14

And maybe we should just add some kind of template file for plugin/controller in the sourcecode, describing what should be where.
This may be comment code, but it should turn up when searching for some keywords in the source.

This is a very good idea.
I made an attempt to create a plugin template file (which needs a lot of description added). I have gone through the bugs and wiki and created a list of hints I thought are good to know when developing a plugin. I have also added a few bugs which I think provide good information, but I can't summarise it

Does that help?

_Pxxx_PluginTemplate_hints.zip: (3.75 KiB) Downloaded 672 times

updated 28/3/18: added one more hint

TD-er · #45 Post by **TD-er** » 30 Mar 2018, 19:03

sentinel wrote: ↑27 Mar 2018, 17:14
And maybe we should just add some kind of template file for plugin/controller in the sourcecode, describing what should be where.
This may be comment code, but it should turn up when searching for some keywords in the source.
This is a very good idea.
I made an attempt to create a plugin template file (which needs a lot of description added). I have gone through the bugs and wiki and created a list of hints I thought are good to know when developing a plugin. I have also added a few bugs which I think provide good information, but I can't summarise it
Does that help?
_Pxxx_PluginTemplate_hints.zip

updated 28/3/18: added one more hint

Can you add a Github issue for this?
On the forum, good ideas tend to get lost.

sentinel · #46 Post by **sentinel** » 30 Mar 2018, 21:33

Can you add a Github issue for this?

here is is: #1211 Plugin template file and hints on writing new plugins

TD-er · #47 Post by **TD-er** » 31 Mar 2018, 01:54

Thanks

esp8266 · #48 Post by **esp8266** » 27 Sep 2018, 18:18

Hello, all
first I want to thank the developers and everyone involved for this wonderful product - ESP Easy
with all due respect, the ESP Easy wiki lacks real, living examples, only syntax.

well, my hard:
1. esp8266 nodemcu, bme280 mega-20180822 (192.168.0.6)
2. esp8266 nodemcu, tm1637 mega-20180822 (192.168.0.7)

my task: to simplify (without mosquito and the like) transfer the temperature value from unit1 to the display of tm1637 unit2
my settings look at the attached screenshots
please correct the settings of the rules

Thank you
(I apologize for me the bad english)

The attachment ESPEASY_1.jpg is no longer available

: ESPEASY_1.jpg (203.28 KiB) Viewed 77521 times

esp8266 · #49 Post by **esp8266** » 27 Sep 2018, 18:22

2 attachment

: ESPEASY_2.jpg (187.32 KiB) Viewed 77517 times

grovkillen · #50 Post by **grovkillen** » 27 Sep 2018, 18:32

We are very much aware that the wiki is lacking in every aspect. We're working on a new GUI and integrated wiki which will be easier to maintain.

Who is online