Espeasy: Missing initial status event on Pulse

[mr2c12]

Checklist

• [X] The title of this issue is "to the point" and descriptive.
• [X] This issue describes what is happening.
• [X] This issue describes what components are affected (e.g. name of plugin/controller)
• [X] This issue describes how to reproduce it.
• [ ] This issue describes when it was introduced (when known) and what version is now showing the problem.

I have...

• [X] searched the issue tracker or the forum for a similar issue. (include links when applicable)
• [X] entered a system description using "Copy info to clipboard" on the sysinfo page. (when possible)
• [ ] entered the full filename of the used version (e.g. ESP_Easy_mega-20181001_test_ESP8266_4096_VCC.bin )
• [ ] given a list of active plugins or controllers when applicable.
• [X] filled out all applicable fields below.

Steps already tried...

• [ ] Tried a clean install (empty .bin files are included in the ZIP)
• [ ] Tested previous/other build (mention which one already tested)
• [ ] Tested on other node to make sure hardware isn't defective.
• [ ] Verified if the problem is limited to a single plugin/controller

Summarize of the problem/feature request

If you monitor a GPIO pin, when sending a Pulse command, you get an event only for the final state of the pin.
Suppose you monitor GPIO 13.
Given via MQTT the command
Pulse,13,1,500
The pin behave as expected, but you get only an event (the last one):

425103 : Info : SW : GPIO 13 Pulsed for 500 mS
425160 : Info : EVENT: GPIO#13=0

Expected behavior

There should be an event for GPIO13=1 too.

Actual behavior

The event reflecting the first state of the pulse is missing.

Steps to reproduce

1. Monitor the proper pin
2. Send a Pulse command via MQTT
3. Check the log (or any rule that should run when the GPIO is set to High/Low when the pulse start: the rule is never run)

System configuration

Hardware:

ESP Easy version:
Build:⋄
20104 - Mega
System Libraries:⋄
ESP82xx Core bc204a9b, NONOS SDK 2.2.2-dev(38a443e), LWIP: 2.1.2 PUYA support
Git Build:⋄
mega-20191208
Plugins:⋄
46 [Normal]
Build Time:⋄
Dec 8 2019 18:04:38
Binary Filename:⋄
ESP_Easy_mega-20191208_normal_ESP8266_4M1M.bin

[giig1967g]

I think I fixed it in November, and the PR is waiting to be merged.

[TD-er]

That will be merged soon, but maybe the test build I made for it can be tested to verify whether it has been fixed?
See: https://github.com/letscontrolit/ESPEasy/pull/2778#issuecomment-567685164

[mr2c12]

@TD-er I can test your build. Can you please tell me how to get the proper version?

[giig1967g]

https://github.com/letscontrolit/ESPEasy/pull/2778#issuecomment-567685164

[TD-er]

I linked the comment in which I linked the test build.
It is a zip file, just like the nightly builds.

[DittelHome]

Ok, i have done a test, with catastrophic result: (loop)

`load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
vbc204a9b
~ld
ªU69 : Info  : 


INIT : Booting version:  (ESP82xx Core bc204a9b, NONOS SDK 2.2.2-dev(38a443e), LWIP: 2.1.2 PUYA support)
70 : Info  : INIT : Free RAM:32696
71 : Info  : INIT : Warm boot #23 Last Task: Background Task - Restart Reason: Exception
73 : Info  : FS   : Mounting...
98 : Info  : FS   : Mount successful, used 78814 bytes of 957314
486 : Info  : CRC  : program checksum       ...OK

Exception (9):
epc1=0x4027517c epc2=0x00000000 epc3=0x00000000 excvaddr=0x3fff117e depc=0x00000000

>stack>
ctx: cont
sp: 3fff2570 end: 3fff27f0 offset: 01a0
3fff2710:  00000000 3fff5cdc 3fff0634 3fff0e2c  
3fff2720:  3fff0e0c 3fff0dec 00000020 40101757  
3fff2730:  3fff0e0c 3fff5cdc 00000002 4022b119  
3fff2740:  40275ae0 00000000 40275ae0 00000000  
3fff2750:  40275ae0 00000000 40275ae0 00000000  
3fff2760:  3fff0e0c 3fff0dec 3fff03d8 4023fa0c  
3fff2770:  3fff5c00 0024002f 80ff27a0 40268475  
3fff2780:  402c52e0 3ffe86a4 3fff1174 3fff16b4  
3fff2790:  3fff0631 3ffe86a4 3fff1174 402540dc  
3fff27a0:  3fff5800 000b000f 8027005d 4027447c  
3fff27b0:  3fff3ff4 006b006f 00efeffe feefeffe  
3fff27c0:  feefeffe feefeffe feefeffe 3fff283c  
3fff27d0:  3fffdad0 00000000 3fff27f8 40269ec0  
3fff27e0:  feefeffe feefeffe 3ffe86d8 401006bd  
<stack<

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)`

This file was used:
ESP_Easy_mega-20191208-25-PR_2778_normal_ESP8266_4M1M.bin

I just reflashed to ESP_Easy_mega-20191122_normal_ESP8266_4M1M.bin and all is fine again.
Unfortunately I had to remove the ESP8266 and flash it over the cable. (not good)

[ironataerial]

Ok, i have done a test, with catastrophic result: (loop)

`load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
vbc204a9b
~ld
ªU69 : Info  : 


INIT : Booting version:  (ESP82xx Core bc204a9b, NONOS SDK 2.2.2-dev(38a443e), LWIP: 2.1.2 PUYA support)
70 : Info  : INIT : Free RAM:32696
71 : Info  : INIT : Warm boot #23 Last Task: Background Task - Restart Reason: Exception
73 : Info  : FS   : Mounting...
98 : Info  : FS   : Mount successful, used 78814 bytes of 957314
486 : Info  : CRC  : program checksum       ...OK

Exception (9):
epc1=0x4027517c epc2=0x00000000 epc3=0x00000000 excvaddr=0x3fff117e depc=0x00000000

>stack>
ctx: cont
sp: 3fff2570 end: 3fff27f0 offset: 01a0
3fff2710:  00000000 3fff5cdc 3fff0634 3fff0e2c  
3fff2720:  3fff0e0c 3fff0dec 00000020 40101757  
3fff2730:  3fff0e0c 3fff5cdc 00000002 4022b119  
3fff2740:  40275ae0 00000000 40275ae0 00000000  
3fff2750:  40275ae0 00000000 40275ae0 00000000  
3fff2760:  3fff0e0c 3fff0dec 3fff03d8 4023fa0c  
3fff2770:  3fff5c00 0024002f 80ff27a0 40268475  
3fff2780:  402c52e0 3ffe86a4 3fff1174 3fff16b4  
3fff2790:  3fff0631 3ffe86a4 3fff1174 402540dc  
3fff27a0:  3fff5800 000b000f 8027005d 4027447c  
3fff27b0:  3fff3ff4 006b006f 00efeffe feefeffe  
3fff27c0:  feefeffe feefeffe feefeffe 3fff283c  
3fff27d0:  3fffdad0 00000000 3fff27f8 40269ec0  
3fff27e0:  feefeffe feefeffe 3ffe86d8 401006bd  
<stack<

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)`

This file was used:
ESP_Easy_mega-20191208-25-PR_2778_normal_ESP8266_4M1M.bin

I just reflashed to ESP_Easy_mega-20191122_normal_ESP8266_4M1M.bin and all is fine again.
Unfortunately I had to remove the ESP8266 and flash it over the cable. (not good)

Was this node on a Static IP ? TD-er introduced this when trying to work out some other issue.

-D

[TD-er]

I really should make my dev environment up and running again soon :(

[DittelHome]

Was this node on a Static IP ?

Yes

[giig1967g]

hi,
try this build:
https://github.com/letscontrolit/ESPEasy/pull/2778#issuecomment-557924921

[DittelHome]

hi,
try this build:
#2778 (comment)

Flashed this file:
2778_moved_gpio_cmd_normal_ESP8266_4M1M.bin
No problem with booting.
Tried this command: LongPulse,5,0,120
get failed
Tried this command: longpulse,5,0,120
get:{
"log": "ort 5. Pulse set for 1200",
"plugin": 1,
"pin": 5,
"mode": "output",
"state": 0
}

Ok

It seem to work, in my rules i use the syntax LongPulse...
Event's are generated.. ;)

[mr2c12]

hi,
try this build:
#2778 (comment)

I am having a lot of problems with the latest build:

• commands are now lowercase (not a problem, just to note)
• commands send on "tools" page works, while sending them via mqtt does not work (i.e. are ignored)
• command "pulse,12,1,500" return "Too many arguments, try using quotes" in the command output ("tools" page)

Is this build so much different from the one I used to use before (mega-20191208) ?

[giig1967g]

@mr2c12.
Thanks for testing the build.
I will look at it.

[giig1967g]

* commands send on "tools" page works, while sending them via mqtt does not work (i.e. are ignored)

@TD-er
Here there is a problem that was not addressed: currently the controllers will receive and process MQTT commands only if they are in the plugins (_C005.ino line 86: PluginCall(PLUGIN_WRITE, &TempEvent, cmd)).
So the core commands are not processed at all.

Should I allow to execute all the core commands by MQTT?

commands are now lowercase (not a problem, just to note)

I still have to test

command "pulse,12,1,500" return "Too many arguments, try using quotes" in the command output ("tools" page)

My fault. Found the bug.

[TD-er]

Should I allow to execute all the core commands by MQTT?

Not entirely sure.
I know several controllers do handle commands differently and that's also bothering me.
But if sending a command via http for example is allowed, then I don't see why it cannot be handled by MQTT.
Both are remote commands and those should obey the same "security level".

Or am I missing something here?

@mr2c12 Do all commands fail, or only specific ones?
If only specific ones fail, which ones do fail?

[giig1967g]

But if sending a command via http for example is allowed, then I don't see why it cannot be handled by MQTT.

You are right.

@mr2c12 Do all commands fail, or only specific ones?
If only specific ones fail, which ones do fail?

All of the internal command are not processed

[giig1967g]

discussion moved to #2778

[giig1967g]

@mr2c12
please test this latest version.
It should fix all errors, including upper and lowercase problem.
PR_2778_4M_8266.zip

[mr2c12]

I'm sorry @giig1967g , at the moment I am unable to test the build, since I don't have a board available!