"DoEvents" for mqtt publish

[buzzger0815]

Hi there!

Is there a "doevents" (stolen from vb6 ) like command? Because in the code below, i publish a status "going-down" as information, that work is in progress and a status "down" when work is finished. BUT the mqtt publish "going-down" is only send after the pcfpulse is finished. Or what am i doing wrong?

Code: Select all

    Publish,"leinwand/status","going-down"
    PCFPulse,2,0,10000
    Publish,"leinwand/status","down"

Thank you!

[Ath]

There are (at least) 2 ways you can try to resolve this:

1) Allow for some background processing during rules (unsure if this will actually work though)

Code: Select all

    Publish,"leinwand/status","going-down"
    Delay,0  // The delay command is advised not to be used, thought the exception seems to be delay,0, to allow events to be processed
    PCFPulse,2,0,10000
    Publish,"leinwand/status","down"

2) Split the action in 2 parts:

Code: Select all

on whatever#event do
// original event action
    Publish,"leinwand/status","going-down"
    ASyncEvent,GoDown  // ASyncEvent will be queued instead of processed immediately as Event does, to allow the steps above to be processed
endon

on GoDown do
    PCFPulse,2,0,10000  // This action is (most likely) blocking, so nothing else is happening during the 'wait'
    Publish,"leinwand/status","down"
endon

[buzzger0815]

Thank you for your help!

But, none of these 2 ways does work. Either the "delay,0" after the first publish does work, nor the async thing. The async does start the async task and does execute all the things to do BUT the first publish, published before starting the async task, is send AFTER the async task has finished

By the way, im on "20109 - Mega" on a esp8266-01. Maybe the esp is the problem, because its the first ever produce one? But i like it, because its that tiny.

Thank you Ath!

[TD-er]

A publish will be queued to the (first enabled) MQTT controller.
So if that's a problem, you may want to look at the controller settings.
See also: https://espeasy.readthedocs.io/en/lates ... parameters

[Ath]

Well, it shouldn't matter what type of ESP8266 board you are running for this type of action, as they are all based on the ESP8266EX chip, that (usually) runs at 80 MHz. (ESP32 is a different beast, with dual cores at 240 MHz)

A bit weird though that the first rule execution isn't completed before the second scheduled rule is started. Maybe that's worth looking into, as it would IMHO be the expected behavior. But changing something there could be breaking backward compatibility.

I'll do some investigation first before we create an issue on github for this.

Or maybe @TD-er has a better clue on how to get the desired behavior?

[Ath]

By the way, im on "20109 - Mega" on a esp8266-01.

Most clear version to report is the name of the .bin file installed on your board, as '20109' is the version of the internal settings structure, and that doesn't change for every released version.

[TD-er]

If you need to wait for the pulse to be finished, which has a known duration, you can also set a timer.

For example the longpulse command (using the internal GPIO pins) is starting when called and does schedule the inverse action after the set duration.
So the execution of longpulse is starting when called, but not finishing.
I can imagine the other pulse commands are using the same, but I'm not sure.
If it is blocking for 10 seconds, then you could also loose WiFi connection and other bad things may happen.

So if timing and execution order is important, you can split the pulse command into 2 steps:

- publish
- set timer
- set pin high (or low, whatever comes first )

After the timer has finished, you have this:

- set pin low
- publish.

[buzzger0815]

Ok, i did it with the timer soultion, thank you!

Works great, thank you!