"delay" command does not work in rules

[nonflammable]

If you self compile, please state this and PLEASE try to ONLY REPORT ISSUES WITH OFFICIAL BUILDS!

Summarize of the problem/feature request

versions <=mega-20180804
rules:
On System#Boot do
neopixelall,0,0,0
neopixelall,128,0,0
delay 400
neopixelall,0,128,0
delay 400
neopixelall,0,0,128
delay 400
neopixelall,0,0,0
endon
is blinking led strip off/red/green/blue/off with 400ms delays

versions >=mega-20180808
above example is only one short flash

Expected behavior

should work like in versions <=mega-20180804

Actual behavior

the "delay" command looks skipped

Steps to reproduce

as in the above example

System configuration

Hardware: Wemos + WS2812 strip

ESP Easy version: >=mega-20180808

ESP Easy settings/screenshots:

Rules or log data

[TD-er]

The delay command should need a complete make-over. See #1600

[giig1967g]

Is the "delay" command still not working in rules?

[TD-er]

I have not changed it, so its status should be the same at this moment.
As soon as this project of mine is ready and merged, I will also have a look at the timers used in rules.
These rules timers are not yet included in the new scheduler, since they seem to support something like "pause", which is not yet part of the scheduler.
I guess the most logical interpretation for "delay" should be some kind of pause of the rules execution.
However, I guess it is a bit more complex, since you only would want the execution of the current scope to pause/wait for a while.

So proper fixing of the 'delay' in rules, may take quite some effort to get it right.

[giig1967g]

ok.
what could be a workaround to send two commands with 200ms of pause between them from rules?

(I have a light that will change it's color if I quickly turn off and on it.)

[TD-er]

My pull request, I linked, is about managing send intervals by controllers.
These controllers could be set to delay the commands to 200 msec as minimum send interval.

Maybe that's an option for your use case?

[giig1967g]

I am not sure it's my case.
The code is:

on R1OffOn do
  PCFGPIO,65,1
  delay,200
  PCFGPIO,65,0
endon

[TD-er]

Nope, that won't be fixed by that pull request.

[giig1967g]

I could think of two possible solutions:

1. more complex but possibly faster execution:
   using the syntax used by OpenHAB. So, something that actually creates a timer:
   Example:

        timer = Timer.create(now.plusSeconds(3) [|
        {sendCommand(EnergiseGD, OFF)}
        {sendCommand(EnergiseGD, OFF)}
        ]

In ESPEasy could be:

on R1OffOn do
  PCFGPIO,65,1
  createTimer,200
    PCFGPIO,65,0
  endtimer
endon

2. less complex but possibly slower execution:
   using events with timers in milliseconds (even if I suspect that maybe 200ms could easily be too short.)

new command:
msTimerSet (set timer in milliseconds),n,ms

on R1OffOn do
  PCFGPIO,65,1
  msTimerSet,1,200
endon

on rules#msTimer=1 do
  PCFGPIO,65,0
endon

What do you think?

[TD-er]

I think adding a single command for 1 pulse also solves it.

[giig1967g]

a new command or an existing command?

[TD-er]

Not sure yet, just a thought of how to fix your issue.

[giig1967g]

do you mean using PCFPULSE?

[TD-er]

I haven't looked at existing commands, but if there is something like that, which does output a logical '1' for something like 200 msec, then yes, that should also work.

[giig1967g]

will test

[giig1967g]

I solved with pcfpulse.

[tonhuisman]

This seems to be solved, so can be closed.