Let's Control It

Posted: **19 Feb 2018, 16:36**

Hi,
I have written several rules in espeasy.
But some times the rules can take several seconds to be executed and this could be dangerous for some applications.
(i.e. a garage door sensor to block the door if someone press an emergency stop button or if a photocell is engaged)

I was wondering if it is possible to write a rule and recompile the whole firmware with that rule embedded.

Any idea on how to do it?

thanks

Posted: **19 Feb 2018, 20:34**

Can you give an example of a rule that sometimes takes longer to process? (including screenshot of the settings page of the related devices)
What version of ESPeasy are you using?
And are you using any MQTT controller? If so, could you please test it with one of the newer versions?

Posted: **19 Feb 2018, 22:33**

From my Sonoff 4CH Pro's syslog output:

FG EspEasy: EVENT: Processing time:2973 milliSeconds
FG EspEasy: EVENT: Processing time:2982 milliSeconds

Almost all my event logs have an event processing time in excess of 1400 milliseconds. Lowest I have seen is 1200 ms

I wish the log showed the name of the event processed.

I do wish, as the OP indicated, there would be a way to reduce the event times (although admittedly I cannot say what event(s) take a long time, following in the syslog doesn't seem to make coherent sense)... 1 second or so isn't bad, but the ones that take upwards of 2.5+ seconds seem to lag the system .

Posted: **19 Feb 2018, 22:47**

Hi TD-er,
thanks for replying.

My configuration:
Using Wemos D1 mini - 4MB - V3.0.0
Firmware: Mega, v2.0-20180217
MQTT: OpenHab 2.1

All push buttons and relays defined in DEVICES as "Switch input - PCF8574".

The situation is the following:
I want to use two push button to activate two relays for raising and lowering a window blind.

So the logic will be:
- push button 1 (UP)
- if blind is moving up stop it
- if blind is moving down, stop down and move up for 10 seconds
- if blind is still, move blind up for 10 seconds

- push button 2 (DOWN)
- if blind is moving stop it
- if blind is moving up, stop up and move down for 10 seconds
- if blind is still, move blind up for 10 seconds

In order to control 3 blinds from a single ESP8266, I am using 2x 8574A port expander (12 PINS in total).
One for push buttons and one for controlling relays.

The problem is the following:
I press PUSH BUTTON 1 and blinds move up.
I immediately press again PUSH BUTTON 1 (within 1 second) and nothing happens (it should stop the blind)
I press again PUSH BUTTON 1 (after 2 or 3 seconds) and the the blind stops.

In other words, after pressing the PUSH BUTTON for the first time (changing the state from 1 to 0), the push button does not respond for 2 or 3 seconds and then it responds again.
Looking in the DEBUG LOG it seems that the rule itself is executed in 891 ms, then 643 ms are due to MQTT and finally the state of the GPIO is changed after another 662 ms.
Total of 2.2 seconds.
So the GPIO changes back from 0 to 1 only AFTER 2.2 seconds, even if I have released the push button immediately.
And after another 682ms the blind stops. Total of almost 3 seconds. Too much in case of an emergency.

Code:

Code: Select all

On System#Boot do  
  PCFGPIO,65,1 //push up
  PCFGPIO,66,1 //push down
  PCFGPIO,73,1 //relay up
  PCFGPIO,74,1 //relay down

  taskvalueset 2,1,1 //InputPush0
  taskvalueset 3,1,1 //InputPush1
  taskvalueset 4,1,1 //Relay0
  taskvalueset 5,1,1 //Relay1
endon

on InputPush0#state=0 do
  if [Relay0#state]=1  // if relay UP=OFF
    PCFGPIO,74,1  //stop down
    delay 200  //to avoid risk of sending double command
    PCFLongPulse,73,0,10  //start up for 10 seconds
    PCFGPIO,65,1  // reset push button
  else 
    PCFGPIO,73,1 //stop up
    PCFGPIO,74,1 //stop down
	PCFGPIO,65,1  // reset push button
  endif
endon

on InputPush1#state=0 do
  if [Relay1#state]=1  // if relay DOWN=OFF
    PCFGPIO,73,1  //stop up
    delay 200  //to avoid risk of sending double command
    PCFLongPulse,74,0,10  //start down for 10 seconds
    PCFGPIO,66,1  // reset push button
  else 
    PCFGPIO,73,1 //stop up
    PCFGPIO,74,1 //stop down
    PCFGPIO,66,1  // reset push button
  endif
endon

Code: Select all

LOG:
02-19-2018	22:22:53	Kernel.Debug	192.168.1.219	ESP9 EspEasy: WD   : Uptime 127 ConnectFailures 0 FreeMem 17112
02-19-2018	22:22:53	Kernel.Debug	192.168.1.219	ESP9 EspEasy: UDP  : Send Sysinfo message
02-19-2018	22:22:54	Kernel.Debug	192.168.1.219	ESP9 EspEasy: PCF  : State 0
02-19-2018	22:22:54	Kernel.Debug	192.168.1.219	ESP9 EspEasy: EVENT: InputPush0#state=0.00
02-19-2018	22:22:54	Kernel.Debug	192.168.1.219	ESP9 EspEasy: ACT  : PCFGPIO,74,1
02-19-2018	22:22:54	Kernel.Debug	192.168.1.219	ESP9 EspEasy: PCF  : GPIO 74 Set to 1
02-19-2018	22:22:54	Kernel.Debug	192.168.1.219	ESP9 EspEasy: ACT  : delay 200
02-19-2018	22:22:54	Kernel.Debug	192.168.1.219	ESP9 EspEasy: ACT  : PCFLongPulse,73,0,10
02-19-2018	22:22:54	Kernel.Debug	192.168.1.219	ESP9 EspEasy: PCF  : GPIO 73 Pulse set for 10 S
02-19-2018	22:22:54	Kernel.Debug	192.168.1.219	ESP9 EspEasy: ACT  : PCFGPIO,65,1
02-19-2018	22:22:54	Kernel.Debug	192.168.1.219	ESP9 EspEasy: PCF  : GPIO 65 Set to 1
02-19-2018	22:22:55	Kernel.Debug	192.168.1.219	ESP9 EspEasy: EVENT: Processing time:891 milliSeconds
02-19-2018	22:22:55	Kernel.Debug	192.168.1.219	ESP9 EspEasy: MQTT : /ESP9/InputPush0/state 0
02-19-2018	22:22:55	Kernel.Debug	192.168.1.219	ESP9 EspEasy: PCF  : State 0
02-19-2018	22:22:55	Kernel.Debug	192.168.1.219	ESP9 EspEasy: EVENT: Relay0#state=0.00
02-19-2018	22:22:55	Kernel.Debug	192.168.1.219	ESP9 EspEasy: EVENT: Processing time:643 milliSeconds
02-19-2018	22:22:55	Kernel.Debug	192.168.1.219	ESP9 EspEasy: MQTT : /ESP9/Relay0/state 0
02-19-2018	22:22:55	Kernel.Debug	192.168.1.219	ESP9 EspEasy: MQTT : Topic: /ESP9/InputPush0/state
02-19-2018	22:22:55	Kernel.Debug	192.168.1.219	ESP9 EspEasy: MQTT : Payload: 0
02-19-2018	22:22:55	Kernel.Debug	192.168.1.219	ESP9 EspEasy: PCF  : State 1
02-19-2018	22:22:55	Kernel.Debug	192.168.1.219	ESP9 EspEasy: EVENT: InputPush0#state=1.00
02-19-2018	22:22:56	Kernel.Debug	192.168.1.219	ESP9 EspEasy: EVENT: Processing time:662 milliSeconds
02-19-2018	22:22:56	Kernel.Debug	192.168.1.219	ESP9 EspEasy: MQTT : /ESP9/InputPush0/state 1
02-19-2018	22:22:56	Kernel.Debug	192.168.1.219	ESP9 EspEasy: MQTT : Topic: /ESP9/Relay0/state
02-19-2018	22:22:56	Kernel.Debug	192.168.1.219	ESP9 EspEasy: MQTT : Payload: 0
02-19-2018	22:22:56	Kernel.Debug	192.168.1.219	ESP9 EspEasy: PCF  : State 0
02-19-2018	22:22:56	Kernel.Debug	192.168.1.219	ESP9 EspEasy: EVENT: InputPush0#state=0.00
02-19-2018	22:22:57	Kernel.Debug	192.168.1.219	ESP9 EspEasy: ACT  : PCFGPIO,73,1
02-19-2018	22:22:57	Kernel.Debug	192.168.1.219	ESP9 EspEasy: PCF  : GPIO 73 Set to 1
02-19-2018	22:22:57	Kernel.Debug	192.168.1.219	ESP9 EspEasy: ACT  : PCFGPIO,74,1
02-19-2018	22:22:57	Kernel.Debug	192.168.1.219	ESP9 EspEasy: PCF  : GPIO 74 Set to 1
02-19-2018	22:22:57	Kernel.Debug	192.168.1.219	ESP9 EspEasy: ACT  : PCFGPIO,65,1
02-19-2018	22:22:57	Kernel.Debug	192.168.1.219	ESP9 EspEasy: PCF  : GPIO 65 Set to 1
02-19-2018	22:22:57	Kernel.Debug	192.168.1.219	ESP9 EspEasy: EVENT: Processing time:682 milliSeconds

Posted: **19 Feb 2018, 23:45**

Methuselah wrote: ↑19 Feb 2018, 22:33 [...]
I wish the log showed the name of the event processed.
[...]

Your wish is my PullRequest: https://github.com/letscontrolit/ESPEasy/pull/904

leel1967l wrote: ↑19 Feb 2018, 22:47[...]

I have to take a little more time to look into it.
Maybe @Grovkillen can also have a look at it?

Those delays are a bit long and at least one second of them can be explained by the fact the rules are parsed from within the runOncePerSecond() function.

I have been looking into the MQTT code a lot the last few days and perhaps some parts can still be improved upon.
There is still a lot done in one run of the loop and I guess splitting those in smaller parts may improve the overall speed of ESP easy.
Maybe we should make the timer for executing rules not so periodical, but more dynamic.
For instance when some activity is detected, shorten the timer for executing rules to now() + 10 msec or something like that.

There is also the PCF chip. In another issue (keypad with that chip), I already mentioned the extra "interrupt" pin on that chip should also be connected to a GPIO on the ESP.
That's the only way you could reliably react to key strokes.
Also detecting a key stroke does take some time, since you do not want to detect it twice due to 'dender' (not sure if that's the correct English term) of the keys.
They never make contact at once but always bounce a little.

Posted: **20 Feb 2018, 10:02**

Thanks I appreciate you looking at my case.
But is there anyway I can write my own rules in the code and then compile them?

Posted: **20 Feb 2018, 10:41**

What value do you have for message delay? Found under the advanced page.

Posted: **20 Feb 2018, 10:46**

grovkillen wrote: ↑20 Feb 2018, 10:41 What value do you have for message delay? Found under the advanced page.

Hi,
I have set = 100ms

Posted: **20 Feb 2018, 11:30**

I don't understand why you have multiple PCFGPIOs that does not change anything. Shouldn't the rules below be enough?

Code: Select all

on InputPush0#state=0 do
  if [Relay0#state]=1  // if relay UP=OFF
    PCFLongPulse,73,0,10  //start up for 10 seconds
  endif
endon

on InputPush1#state=0 do
  if [Relay1#state]=1  // if relay DOWN=OFF
    PCFLongPulse,74,0,10  //start down for 10 seconds
endon

Posted: **20 Feb 2018, 11:52**

grovkillen wrote: ↑20 Feb 2018, 11:30 I don't understand why you have multiple PCFGPIOs that does not change anything. Shouldn't the rules below be enough?
Code: Select all
on InputPush0#state=0 do
  if [Relay0#state]=1  // if relay UP=OFF
    PCFLongPulse,73,0,10  //start up for 10 seconds
  endif
endon

on InputPush1#state=0 do
  if [Relay1#state]=1  // if relay DOWN=OFF
    PCFLongPulse,74,0,10  //start down for 10 seconds
endon

Hi,
It's for safety.
Imagine the following scenario:
The blind is moving up and someone presses the down button. The UP relay should be stopped and the DOWN relay should be engaged.

Command: PCFGPIO,74,1 //stop down
because before activating the UP RELAY I need to stop the DOWN RELAY if this is engaged.

Command: delay 200 //to avoid risk of sending double command
The delay is to make sure that the blind motor does not receive both commands at the same time even if for few ms. It could be possibly reduced.

Command: PCFGPIO,65,1 // reset push button
I use this because I call this function from an API, so I set the GPIO=0 and automatically is set back to 1 in the function.
(I know I could use events, but events introduce 1 second more of processing time)

Posted: **20 Feb 2018, 12:47**

Can't you have only one button and make it alternate between up/stop/down? That way you will make sure that you don't accidently trigger up when you're going down, etc..

Posted: **20 Feb 2018, 13:08**

grovkillen wrote: ↑20 Feb 2018, 12:47 Can't you have only one button and make it alternate between up/stop/down? That way you will make sure that you don't accidently trigger up when you're going down, etc..

I could do that logic too.
But I am not sure if it will speed up things...
Also WAF could be problematic. And I would need a dummy variable to store the last direction used.
So probably not a benefit in terms of execution time.

Back to the original issue:
It seems that what is taking time is the acknowledge of the push button release.
So when I shortly push and release the button, the state should change back almost immediately, but it's taking 3 seconds...
That is the problem I am focusing now.
Because whatever solution I take (yours or mine), if I want to stop, it takes 3 seconds to stop the blind...

Posted: **20 Feb 2018, 13:32**

Okay, I understand the problem. And keeping the button pushed for movement is not an option I think.

Posted: **20 Feb 2018, 14:26**

grovkillen wrote: ↑20 Feb 2018, 13:32 Okay, I understand the problem. And keeping the button pushed for movement is not an option I think.

It is an option that I already tested actually, but it can be even worse.
Infact if you release the button within 1 second from the first push then the blind will never stop, because it will not receive the status change.

At the end the problem is the same.

Posted: **20 Feb 2018, 16:31**

Instead of long pulse, have you tried timer?

Posted: **20 Feb 2018, 17:06**

grovkillen wrote: ↑20 Feb 2018, 16:31 Instead of long pulse, have you tried timer?

Yes, I tried timer, but the execution time was longer.
I found that using LongPulse had the fastest execution time.

edit: I will explain better.
With timers at the first push of the button the activation of the relay had a delay of 500ms.
While with longpulse the execution was almost instantaneous.
Is it expected behaviuor?

I noticed also that using events (in order to reuse the code), the execution was longer.
Is this an expected behaviour too?

Posted: **21 Feb 2018, 00:07**

I've created an issue to look into making the timing interval to process rules more dynamic.
See https://github.com/letscontrolit/ESPEasy/issues/912

Do you have any suggestions on use cases, or other ideas on what should be added?

Posted: **21 Feb 2018, 09:30**

TD-er wrote: ↑21 Feb 2018, 00:07 I've created an issue to look into making the timing interval to process rules more dynamic.
See https://github.com/letscontrolit/ESPEasy/issues/912

Do you have any suggestions on use cases, or other ideas on what should be added?

Hi TD-er,
Definitely the dynamic rules timing is a way to go, but as a work around that can be implemented quicker, I would add the possibility to change the static timing interval to process rules. In other words if you activate the rules, then you can decide what the timing is (between 1 seconds to 100ms).
Let's see what the performances are. And then according to the result, we can decide if it's worth to implement the dynamic method.

Because I think that we need to be sure that the lag is due to the rules timing only...

What do you think?

EDIT:
the reason why I say that is because in the example at the beginning of this thread I pressed and immediately released the PUSH button, so the actual interval between the two events (STATE=0 and STATE=1) was 100ms. But if you look in the log file, the time that pass between "EVENT: InputPush0#state=0.00" and the subsequent "EVENT: InputPush0#state=1.00" is 2.2 seconds. So maybe the lag is somewhere else.

Posted: **25 Feb 2018, 15:04**

I solved the issue:

In the original project I had added my output relays to the 8574 device.
And that generated the delay.

I tested now removing the relays from the 8574 device and adding them to a dummy device, and now the speed is very fast.

So must be something to do with the 8574 plug-in.

Consider solved the problem.

But my original question remains: Is it possible to write rules in the original code and compile them?

Posted: **25 Feb 2018, 15:07**

leel1967l wrote: ↑25 Feb 2018, 15:04
But my original question remains: Is it possible to write rules in the original code and compile them?

No, not really but its fairly easy to upload them... Please explain more what you really want to do. My flash wrapper tool can do it for you.

Posted: **28 Feb 2018, 21:01**

grovkillen wrote: ↑25 Feb 2018, 15:07
leel1967l wrote: ↑25 Feb 2018, 15:04
But my original question remains: Is it possible to write rules in the original code and compile them?
No, not really but its fairly easy to upload them... Please explain more what you really want to do. My flash wrapper tool can do it for you.

Hi,
no I haven't been clear.
I want to write rules more complex than the ones allowed in the embedded rules. For example adding OR, AND, nested if, etc.
So it's not a matter to upload the rules with your tool (that it's really useful) but to write rules in the firmware, compile it and upload.

thanks

Posted: **01 Mar 2018, 11:32**

leel1967l wrote: ↑28 Feb 2018, 21:01
grovkillen wrote: ↑25 Feb 2018, 15:07
leel1967l wrote: ↑25 Feb 2018, 15:04
But my original question remains: Is it possible to write rules in the original code and compile them?
No, not really but its fairly easy to upload them... Please explain more what you really want to do. My flash wrapper tool can do it for you.
Hi,
no I haven't been clear.
I want to write rules more complex than the ones allowed in the embedded rules. For example adding OR, AND, nested if, etc.
So it's not a matter to upload the rules with your tool (that it's really useful) but to write rules in the firmware, compile it and upload.

thanks

I think you gonna have to hang on for µpyeasy with script ability ...

Let's Control It

Writing custom rules and compile them

Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them

Re: Writing custom rules and compile them