ESP8266 Community Forum

- Mon May 02, 2016 10:08 am #46697 Hi Electroguard,
the big problem is that, when the program is running, all the interactions with the web page are not running, except when the command 'wait' is run.
So, if the program is not stopped or in "wait" it will be impossible to stop it using the web interface.
Probably this design can be changed but, for the moment, this is how the program is done.
The web browser, unfortunately, is not a console and all the interactions pass through web requests; if the web server on the ESP is not running, all these requests are lost.
I don't know the reasons that pushed mmiscool into this choice, probably the negative performance required to answer web requests during program execution. For sure I think that there is a good reason.
One possible and simple solution could be to implement a "special" udp channel where we could send and receive debug commands (run, stop, pause, step, breakpoints, ...).
A customised utility could be in charge to send "commands" and, eventually, set and get variables.
But, maybe, this is rocket science ?

- Mon May 02, 2016 12:28 pm #46711 Yeah, thanks cicciocb, and I can see why the parser 'zombie' must always remain active even after errors in order for the browser to always have something 'alive' to connect up to on the ESP.

I suspect that vars and/or branches are still being corrupted somehow, causing errors that the parser isn't expecting or able to cope with.

What makes me suspect var/branch corruption is because I can use the web buttons to eg: blink the IP address of my udp network demonstrator program and everything is ok. I can then click ? button and check out any of the doc pages ok ... but very often (and more likely than not), when I return Home and try to use the web buttons again, instead of the button task being activated, the parser often brings up an unsolicited doc page. That is clearly an error somewhere, but the program still continues doing some things, so there's no way of knowing what went wrong or where or when.

Same thing when sending udp instructions such as ALL BLINKIP from your udp utility by the way, typically after viewing ? doc pages in the browser.

Once that happens, any edits are unlikely to Save ok, so the inevitable result is a reformat and reflash.

I know my program isn't giving the parser an easy time, but it's the best way I know of shaking out any problems, and usually I can offer some definative symptoms for you guys to chase down - but not this time I'm afraid, even though there is definitely a problem in there somewhere.


Something I have noticed, but haven't had the stability to try tracking down, is that since trying to attach to router as adhcp node, returning the reformatted and reflashed esp to AP doesn't now seem to work properly anymore.
The browser is definitely attached to the ESP in AP mode, but instead of ip() showing 192.168.4.1 it is returning the historic router dhcp network address.
I suspect this is just an ip() bug rather than being related to the above problem, but until the zombie is a bit better behaved there's not much I can do to pinpoint anything.

Where to get modules?

https://www.banggood.com/custlink/KvGGhGF4wG

- Mon May 02, 2016 12:57 pm #46716 And yes, an alternative udp connection into the parser could be a very useful idea - it's already got the udp functionality built in, so why not use it when wanted... could give easy access to whatever internal commands/instructions you decide to include. Even spit out some debug info. Great idea!

Where to get modules?

https://www.banggood.com/custlink/KvGGhGF4wG

- Mon May 02, 2016 8:02 pm #46732 Holy moly cow why not trim down some of the code and just host some of that html in separate files last I knew 253 lines of code was the max and that was pushing it ... Errr did not get time to really read much of that monster but from what I can tell while I was scrolling sheesh it didn't stop scrolling.

As far as getting AP mode to work visit my troubleshooter I've been stuck in loops and such and this kind of tells you some of the quirks and how to work around it ...

The default behavior at start up is the same. The device will attempt to connect to the last network. If unsuccessful it will start its own access point.

When running a program the connect command and the AP command will no longer put the module in to an exclusive mode. You can run both commands and the device will be connected to the network and act as an access point.

The WiFioff command can be called in order to disable all networking and the AP or connect command if run after WiFioff will activate that particular WiFi mode. You can turn them both back on at any point with each of there commands.

IMPORTANT !!!!!!!: If you change your wifi settings it is critical to not only reset your ESP but also it helps to reset your router or wifi device depending on if you are connecting station or AP mode the reason being is that your router or your wifi card will keep the setting lingering so it is a must that you do the reset to your router or your wifi depending on how you connect!!!

Never leave blank data in the station mode box you are better off using incorrect data for the SSID and Pass then no data at all keep this in mind.
- See more at: viewtopic.php?f=40&t=6732#sthash.zYlo7Vq4.dpuf

Helpful? Donate To help support Mike http://www.esp8266basic.com click the donate button lets keep this project going and hope we can get the ESP32 in the mix. BEGINNERS GUIDE HERE http://www.esp8266.com/viewtopic.php?f=40&t=6732

Where I buy my ESP8266 boards from... (Banggood)