Program lag when looking at RUN page
Posted:
Thu Jul 28, 2016 7:03 pm
by electronrancher
I have a timer that blinks an LED every 5 seconds for 100ms. I have also set the device to excecute on startup.
I find that if I am looking at the edit page, the timer appears to work correctly. But on the RUN page (so I can see the trivial, two-print statement output) the LED timing is all out of whack. Delay is much longer than 5s and on time is also several seconds.
Is this typical operation?
Re: Program lag when looking at RUN page
Posted:
Thu Jul 28, 2016 7:50 pm
by Mmiscool
It will be slower if it is doing things with the web sockets. I don't think that it would be too much slower though.
Re: Program lag when looking at RUN page
Posted:
Thu Jul 28, 2016 9:01 pm
by electronrancher
Ok, thanks for the reply!
My application is a simple temp sensor, so the webpage only needs to display a single number that is also transmitted to thingspeak in the background.
Would you give your suggestion on the best (and lightest overhead) way to implement this? A print seems to keep the old text and print a new line - perhaps keeping several lines is what takes the heavy lifting. Is there a way to give a blank page with one number that occasionally changes?
Re: Program lag when looking at RUN page
Posted:
Sat Jul 30, 2016 2:22 am
by Oldbod
I'm interested in this as I will be doing something similar. Using a browser as a front end display looks like it should simplify things, and it is the ubiquitous solution without doubt, but between a simple print statement and what pops up on the screen there are a huge number of variables to potentially confuse things.
As I understand it, web sockets were developed to support exactly the sort of thing you are doing here, with a reduced protocol overhead. So hopefully a good fit here. I havent read the documentation for a bit, but last timeI looked I dont think it said exactly how stuff was delivered.
I don't quite understand by what you mean by ok running from the edit page and delays running when looking at the run page, probably being very dense. Bad night....
Often a good way to spot whats introducing a delay is to skip round a section of code and see if things improve. For example, you might replace your print statement with a counter, then see how that affects things. Likewise your thingspeak write, and your temp sensor read. You might have done this already....
Is your esp connected to a pc on usb or a dumb power supply. Print writes to serial port and browser buffer, i wonder if serial port has any flow control and if this affects anything? If it does point to your print statement, perhaps replace it with wprint, maybe use htmlvar?
If your problem only occurs when the program starts itself on power on, but works fine if you kick it off by manually running it, i'd be wondering if the delays are caused by the program trying to write to a non-existant connection - either esp not linked to network or cant find path to thingspeak/destination browser. No idea how a browser write without a browser connection affects performance, but very easy to test.
How do you know the timing is off - is it by what the led is doing? Wonder what the code is doing between say led on and led off.
Could you be updating thingspeak in a way that slows things down - too often or thingspeak slow to respond?
Very easy to sit here and waffle, hope you get to the bottom of it! If you wanted to post your code up, sure someone here would know...