Hi,
i use for the first time the short pulses command:
http://192.168.1.71/control?cmd=Pulse,12,1,60000
It works well and for 60 seconds the GPIO is activated.
Problem is that I can send any other commands in these 60 seconds. The webservice is waiting 60 seconds
The normal ESP Webconfig is also dead in this time.
I need to control multiple GPIOs different at this time.
thx
Short pulses freezes the webservice
Moderators: grovkillen, Stuntteam, TD-er
Re: Short pulses freezes the webservice
The pulse command is meant for short pulses, not more than a second. It was specifically created for those short pulses that a remote controller could not handle well using two commands over http. The current pulse command uses blocking mode as it's an easy way to have reliable pulse duration in terms of milliseconds.
The next ESP stable edition will provide add a "longpulse" command that does not block operation during the pulse duration. It is set in seconds and could run for long periods.
The next ESP stable edition will provide add a "longpulse" command that does not block operation during the pulse duration. It is set in seconds and could run for long periods.
Re: Short pulses freezes the webservice
That sounds good!
When will the next ESP stable appear about?
The "longpulse" should continue controlled in milliseconds.
This expands the scope for filigree controls.
When will the next ESP stable appear about?
The "longpulse" should continue controlled in milliseconds.
This expands the scope for filigree controls.
Re: Short pulses freezes the webservice
I highly recommend a hard time limitation to the "pulse" command so that the system does not freeze/crash when a too large value (<=1s ?) is entered.
The other thing is, that i would appreciate to have the "LongPuls" units in 100ms steps and not in seconds.
Having the "checkSystemTimers" in the "run10TimesPerSecond()" section would be a good compromise between cpu load and granularity/universality of the timer.
The other thing is, that i would appreciate to have the "LongPuls" units in 100ms steps and not in seconds.
Having the "checkSystemTimers" in the "run10TimesPerSecond()" section would be a good compromise between cpu load and granularity/universality of the timer.
Who is online
Users browsing this forum: No registered users and 41 guests