ESP8266 server only serves page once, sometimes twice #766
Replies: 24 comments
-
Posted at 2015-04-15 by DrAzzy
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-15 by DrAzzy You can see there that the first request goes fine, but the second one just seems to go nowhere after being received.... Order doesn't matter either - same requests in opposite order, but failing same way for unknown reasons.
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-15 by @gfwilliams Thanks - I'll take a look. It's odd because I did actually get this when doing the server code :) not sure what's gone on. Iirc Espruino should respond to the Unlink that comes from the esp8266, so it should know that a new socket has opened. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-15 by JumJum I have a similiar problem using ESP8266 with nodemcu firmware. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-15 by @gfwilliams Well that was embarrassing. Typo :) Should be fixed now. On the plus side, I've had a Pico doing the Weather Station thing running for a few days non-stop now and it's still working great (HTTP GET). |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-15 by DrAzzy Thanks "Should be fixed now" Is that a change in the module, or a change in the firmware that fixes it? (Ie, to fix it, do I have to build and flash latest firmware, or just resend and count on website having updated modules?) Can you point me to the github commit? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-15 by @gfwilliams It's just a module, so the next time you flash it should work - thankfully now it's all JS life is a lot easier. commit here - told you it was embarrassing :) It seems to work ok now, I think you might be able to confuse it be refreshing very quickly though? After a while the server does seem to just stop accepting connections. Not actually sure what's up with that as I reckon that one is on the ESP8266 side - it might even be a bad WiFi connection here. Worst case you can just do a software reset though. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-16 by DrAzzy This is better, but it's still so unreliable as to be useless. If the ESP8266 is going to be used with the Pico's that are going out, major improvements are necessary. A few calls went well... then a call that had worked before failed, and now the server is not answering http requests. Additionally I can't seem to revive the ESP without a hard power cycle. Sometimes I need to do it twice, because it doesn't respond to AT+RST,
code now is:
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-16 by DrAzzy In this state, requests for status.json look like this:
What is going on? Does anyone know how to fix this? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-16 by @gfwilliams Strange - so I can get it to stop responding, but it does seem to pull itself back together after a while and respond. Looks like it starts off with it responding I quickly googled Client seems rock solid though - the weather thing is still running fine. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-16 by DrAzzy Yeah - getting working server is critical for me- this problem is gating several projects that I'd really like to work on, and I'm sure as people get their pico's and ESP's, there will be many more people with the same problem. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-17 by @gfwilliams Yes, sorry about that. It sucks because the firmware version I was told I was getting on the ESP8266 modules isn't what actually came, and then I had to try and get it to work as-is in a short timeframe - it could well be that this wouldn't have been a problem on newer firmware. Hopefully once the rest of the Picos are shipped (first half of next week) I'll be able to fix this properly. At least we've got working Picos, on time - and working a WiFi client. The server will be fixable in software, even if I have to write a firmware updater :) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-18 by DrAzzy Trying this on a Pico through the shim this seems much more reliable. 0018000902-AI03 firmware Was something changed in the module in the past day or two? Only thing changed in code is that the file serving stuff is commented out since there's no E.openFile(), though none of the files requested were ever on the SD card. Could that have been causing a problem through spooky means? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-20 by @gfwilliams Strange - it shouldn't have caused a problem - IRQs are always enabled during SPI send, and I only changed the code that I'd mentioned above. Thanks for letting me know about filesystem though - that should have been compiled in :( Is it possible it could still have been some power fluctuation issue? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-20 by DrAzzy Yeah, I'm suspicious of power fluctuation as well. I did use a larger cap on the pico shim - an excuse to use one of those 47 uf caps I bought because "wtf 47uf caps that tiny? must have!". I'll throw on a larger cap next time I try. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-20 by @allObjects Regarding ESP8266 (firmware): may be cloning @gordon and throw up some kickstarter money for a Gordon-quality ESCOMINO would get everyone in a better state of wifi! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-07-04 by Pho3nix Hi!
I also have insalled a temperature and air pressure sensor, which I wanted to serve as json data.
This is the code I used (Almost identical to the ESP8266's sample code)
What is the advised firmware to use on ESP8266? (Excuse my English, I'm not a native speaker.) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-07-05 by DrAzzy What does the Espruino show when it fails to serve the page? Does it work better if you wait a minute or two between requests? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-07-05 by Pho3nix Nothing. Request handler executes w/o errors, but the browser just hangs and nothing happens. Before the first request:
First request:
Second request:
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-07-06 by @gfwilliams I think this is because you're using a newer firmware on the ESP8266 - there's a post about someone else having issues with it somewhere else on the forum too :( The one the module is designed for is However it should be possible to tweak the existing driver to work with the new ESP8266 firmware - I'll see what can be done with that when I get some time, but if you want to get stuck in then the source is here and you can probably get a much clearer idea of what's going on by calling |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-07-06 by Pho3nix Thank you Gordon, I guess I will dig into this, I'll try to find out, whats going on with the new driver :) If anybody else looking for the |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-07-07 by the1laz @Pho3nix Thanks, I was struggling to find the right one! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-07-07 by @gfwilliams Hi - just to let you know I've now created a new driver that should work with the newer 0.25 firmware. Details on the ESP8266 page |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-07-11 by Pho3nix @gordon That was my plan for the weekend. I guess I need to find something else then ;) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2015-04-15 by DrAzzy
I've been trying to make a Espruino webserver that would work with an ESP8266, and be able to serve static files and dynamically generated data.
I've run into a problem though....
It serves the first request just fine.
Subsequent requests make the ESP's activity LED blink, but nothing is printed to the espruino console, and the browser hangs at "waiting for 192.168.2.102..."
It's as if the callback stops getting called after the first request. Are things getting fouled up, leaving the ESP waiting for a response that the Espruino doesn't know it needs to give?
In any event, after getting into this state, the ESP8266 needs to be reset. If we can't keep it from doing this, we need to take the CC3k approach and wire in reset, and use it liberally.
at.debug() output below.
Beta Was this translation helpful? Give feedback.
All reactions