Release v2.0-20180221 Basic local Button lagging

[zulfiqaradil]

Hi Everyone

First of all I like to thankful to all team of www.letscontrolit.com who really did very fascinating job on this development to make life of IOT more easy and hassles free.

I just upload new Release v2.0-20180221 and its seems to be very nice and stable.

I want to share here some of my experience here I have setup following hardware:

• Respberry PI W with MQTT on it

• Using Domoticz MQTT Controller

• WEMOS D1 MINI total 10 in quantity

• 4 Channel Relay Board total 10 in quantity

• TTP223 Touch Sensor total 40 in quantity (4 Each of Wemos D1 Mini)

• 4 NEO Pixel RGB LED total 40 in Quantity (4 Each of Wemos D1 Mini)

with this hardware setup I do one thing first to connect one relay and one touch button with simple toggle rule for each Relay with its associated Touch Button input at local configuration and its seems to be work with about 1230ms of complete process means it Turn on Suddenly as I touch but after 1230ms I need to wait for good touch to toggle relay which is not seems to be look like good because at this stage no MQTT controller is Enable nor Global Sync.

In 2nd test I enable MQTT Controller and Global Sync and now time goes to 1730ms
In 3rd test I add all four relays along with all 4 touch sensors now this time its more interesting thing appear if I touch 1st Touch sensor 1st Relay turn ON and very quickly If I touch 2nd Touch sensor with in less the 3 Seconds it not allow me to do until that 3 Second is done and if that time is not ended and I keep touch any other sensor that time is doubled and tripled and more(with multiple touch) no Relay is triggered at this stage I check the serial log with level 4 it seems to be look like lot of process is going on the background which need to be done first until new interrupt is appear (Means touch) now what is this ? it cause my brain fried. Just think currently I am only run One WeMos D1 Mini and if I run more modules in same network it will cause more UDP and MQTT commands in network then how much lagging will be appear... Oh my GOD. I hope main team will be focus on this issue or any expert level suggestion or solution can be warm welcome here

My Suggestion ::

In the web base portal there should be another settings for the priority set to make inputs or out to react on priority based also I think its better to do like this :: All triggered process need to be done very quickly as it appear > reflect and all local sync or server sync based back and forth commands need to buffer in background and can be flushed on when that command is reach on its destination::

[TD-er]

There is some issue with MQTT which I will look into ASAP.
And there are already plans on changing the scheduling to improve response times.
Still the handling of rules seems to be causing some delays also.

A similar issue was already raised just last week, with similar delays. So it is good to know this is really an issue and not just some single measured instance. (well there were already 2 reports in that other topic)

[leel1967l]

Hi Everyone

First of all I like to thankful to all team of www.letscontrolit.com who really did very fascinating job on this development to make life of IOT more easy and hassles free.

I just upload new Release v2.0-20180221 and its seems to be very nice and stable.

I want to share here some of my experience here I have setup following hardware:

• Respberry PI W with MQTT on it

• Using Domoticz MQTT Controller

• WEMOS D1 MINI total 10 in quantity

• 4 Channel Relay Board total 10 in quantity

• TTP223 Touch Sensor total 40 in quantity (4 Each of Wemos D1 Mini)

• 4 NEO Pixel RGB LED total 40 in Quantity (4 Each of Wemos D1 Mini)

with this hardware setup I do one thing first to connect one relay and one touch button with simple toggle rule for each Relay with its associated Touch Button input at local configuration and its seems to be work with about 1230ms of complete process means it Turn on Suddenly as I touch but after 1230ms I need to wait for good touch to toggle relay which is not seems to be look like good because at this stage no MQTT controller is Enable nor Global Sync.

In 2nd test I enable MQTT Controller and Global Sync and now time goes to 1730ms
In 3rd test I add all four relays along with all 4 touch sensors now this time its more interesting thing appear if I touch 1st Touch sensor 1st Relay turn ON and very quickly If I touch 2nd Touch sensor with in less the 3 Seconds it not allow me to do until that 3 Second is done and if that time is not ended and I keep touch any other sensor that time is doubled and tripled and more(with multiple touch) no Relay is triggered at this stage I check the serial log with level 4 it seems to be look like lot of process is going on the background which need to be done first until new interrupt is appear (Means touch) now what is this ? it cause my brain fried. Just think currently I am only run One WeMos D1 Mini and if I run more modules in same network it will cause more UDP and MQTT commands in network then how much lagging will be appear... Oh my GOD. I hope main team will be focus on this issue or any expert level suggestion or solution can be warm welcome here

My Suggestion ::

In the web base portal there should be another settings for the priority set to make inputs or out to react on priority based also I think its better to do like this :: All triggered process need to be done very quickly as it appear > reflect and all local sync or server sync based back and forth commands need to buffer in background and can be flushed on when that command is reach on its destination::

Hi,
I had a similar problem.
In my case, what was causing the delay was setting the relay as an input switch.
I removed the relay from the INPUT SWITCH and added a dummy device to keep track of the state of the relay.

The speed is very fast.

[zulfiqaradil]

There is some issue with MQTT which I will look into ASAP.
And there are already plans on changing the scheduling to improve response times.
Still the handling of rules seems to be causing some delays also.

A similar issue was already raised just last week, with similar delays. So it is good to know this is really an issue and not just some single measured instance. (well there were already 2 reports in that other topic)

Thanks for reply @TD-er and I found some of your tag todo in the code and with deep look i saw it cause of MQTT + UDP and event cause delay. I did some different approach which is totally different scenario which is

for all relay output I didn't use any kind of Rule,Global Sync or not do any send MQTT command to MQTT broker so there is not any MQTT send out string there for all relays and for Touch switches I use MQTT subscription to get switch status with "PUSH BUTTON ACTIVE LOW" and get its status on my Node red with toggle function inside of node red and then I send http command to turn on and off relay and I did so much fast to respond but just think if my PI is off or its CPU at 100% some time then all network will be down which is not recomended

I was wondering with this setup although this process is bit long to execute but its very fast process in real and in other hand why the local commands and rules cause so much delay ? although it can be done locally and should be fast.
One more observation as UDP and MQTT there there it cause slow down the system due to use of "DELAY" and "for loop" inside of the code and at where the "DELAY" and "for loop" inside of the code and on when its execute it will not allow to do any of other process by CPU the code should need to deep look and need to be more optimized and at here I test with first my custom build code and soon I here post here some of my modifications inside of the code.

[TD-er]

[...]
I was wondering with this setup although this process is bit long to execute but its very fast process in real and in other hand why the local commands and rules cause so much delay ? although it can be done locally and should be fast.
One more observation as UDP and MQTT there there it cause slow down the system due to use of "DELAY" and "for loop" inside of the code and at where the "DELAY" and "for loop" inside of the code and on when its execute it will not allow to do any of other process by CPU the code should need to deep look and need to be more optimized and at here I test with first my custom build code and soon I here post here some of my modifications inside of the code.

Please note that the delay() calls on ESP8266 platform are really needed.
They are not only a delay in the code, but also allow to run some background tasks like keeping the WiFi connected and prevent the watchdog timer to reset the ESP.
Those delays have to happen quite often. So adding a delay(1) is really useful sometimes

Last few days I changed some parts of the code related to the controllers access to the outside world.
That should lower the resources used.
Currently the MQTT "loop time" is still at 250 msec, but may be lowered to about 50-ish msec I guess without affecting other performance.
My ideal solution will be to make this timing dynamic, meaning to service almost immediately on events and perform (MQTT) keep-alive tasks at a lower pace.
Also the processing of rules should be as dynamic.
But that's just an idea yet and has to crystallize a bit in my head before I start fixing it.