-
Notifications
You must be signed in to change notification settings - Fork 13.3k
WifiServer stop responding after abrupt disconnecting of WifiClient #2194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
client code #include <ESP8266WiFi.h>
#include <ESP8266mDNS.h>
#include <OneWire.h>
#include <DallasTemperature.h>
#include "jsondata.h"
const char *ssid = "****";
const char *password = "**";
int errorcount = 0;
bool isHeating = false;
float histereza = 1.0;
#define ONE_WIRE_BUS D2
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
DeviceAddress thermometer;
void CheckHeater();
void SetError(int error);
void SetErrors(int error);
void StopHeater();
void StartHeater();
void connectWiFi();
WiFiClient client;
char hostString[16] = {0};
int hostcount;
bool isConnected = false;//Czy podłączono do sieci WiFi
void setup() {
Serial.begin(115200);
sensors.begin();
if (!sensors.getAddress(thermometer, 0)) Serial.println("Unable to find address for thermometer ds18b20 ");
sensors.setHighAlarmTemp(thermometer, 90);//alarm przy 90 stopniach
sensors.setLowAlarmTemp(thermometer, 0);
connectWiFi();
}
void loop() {
yield();
sensors.setResolution(9);
sensors.requestTemperatures(); // Send the command to get temperatures
Serial.print("Sensor temperature : ");
htdata.temperature = sensors.getTempC(thermometer);
Serial.println(htdata.temperature);
if (sensors.hasAlarm(thermometer))
{
Serial.println("ALARM: temperature not in range (0,90) ");
SetError(1);
return;
}
if (!isConnected) {
connectWiFi();
return;
}
if (hostcount==0){
hostcount = MDNS.queryService("htcontrol", "tcp");
}
if (hostcount==0) {
Serial.println("No control service found!");
SetError(202);
return;
}
htdata.name = "HT0";
serializeHTSensor();
Serial.print("Connecting to host ");
Serial.print(MDNS.hostname(0));
Serial.print(" (");
Serial.print(MDNS.IP(0));
Serial.print(":");
Serial.print(MDNS.port(0));
Serial.println(")");
unsigned long timeconn = millis();
if (!client.connect(MDNS.IP(0), MDNS.port(0))) {
Serial.println("connection failed");
SetErrors(205);
}
else
{
client.print(htsensor_json);
Serial.println(htsensor_json);
unsigned long timeout = millis();
while (client.available() == 0) {
if (millis() - timeout > 5000) {
Serial.println("Connection timeout");
client.stop();
SetErrors(204);
return;
}
}
// Read all the lines of the reply from server and print them to Serial
while(client.available()){
String line = client.readStringUntil('\r');
Serial.println(line);
if (line.length()>1){
line.toCharArray(house_json,200);
if (deserializeHouse()){
htdata.error = 0;//wyczyść status błędu
errorcount =0;
CheckHeater();
}
else
{
Serial.println("Error in house JSON received!");
SetError(203);
}
}
}
if (client.connected()) {
Serial.println("disconnecting from host.");
client.stop();
}
}
Serial.print("Time : ");
Serial.println(millis() - timeconn);
}
void connectWiFi(){
int count=0;
sprintf(hostString, "ESP_%06X", ESP.getChipId());
Serial.println();
Serial.print("Connecting to ");
Serial.println(ssid);
WiFi.persistent(false);
WiFi.mode(WIFI_STA);
WiFi.begin(ssid, password);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
count++;
if (count>30) {
Serial.println();
Serial.print("Cannot connect to ");
Serial.println(ssid);
SetError(200);
return;
}
}
isConnected = true;
WiFi.hostname(hostString);
Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());
Serial.print("Hostname: ");
Serial.println(hostString);
if (!MDNS.begin(hostString)) {
Serial.println("Error setting up MDNS responder!");
SetError(201);
}
//Serial.println("Sending mDNS query");
hostcount = MDNS.queryService("htcontrol", "tcp");
//Serial.println("mDNS query done");
if (hostcount == 0) {
Serial.println("No control service found");
SetError(202);
}
else {
Serial.printf("Found: %d TCP/IP services\n\r",hostcount);
}
}
void SetError(int error)
{
htdata.error = error;
StopHeater();
}
void SetErrors(int error)
{
if (errorcount <= 5)
{
errorcount++;
}
else
{
SetError(error);
}
}
void StopHeater()
{
if (isHeating)
{
Serial.println("Heater stopping...");
/* tutaj kod zatrzymujący grzanie */
htdata.status = 0; //zatrzymany
isHeating = false;
}
}
void StartHeater()
{
if (!isHeating || htdata.error==0)
{
Serial.println("Heater starting...");
/* tutaj kod uruchamiający grzanie */
htdata.status = 1;// uruchomiony
isHeating = true;
}
}
void CheckHeater()
{
/* Tryb pracy pieca
(0 - automatycznie,1 - grzanie wody, 2 - piec wyłączony)
*/
switch (house.rmode) {
case 0:
htdata.mode = 0;
if (house.temperature < house.requested + histereza) StartHeater();
else
StopHeater();
break;
case 1:
htdata.mode = 1;
if (htdata.temperature >= house.tmax || htdata.temperature <= house.tmin) StopHeater();
else
StartHeater();
break;
case 2:
StopHeater;
break;
default:
Serial.println("Nieznane żądanie trybu pracy!");
break;
}
}
|
jsondata.h #include <ArduinoJson.h>
struct HTSensorData {
const char* name; // HT0
int status; // Status pieca 0 - zatrzymany, 1 - pracuje
int error; // Kod błędu
float temperature; //Aktualna temperatura na piecu
int mode; //Tryb pracy pieca (0 - automatycznie, 1 -grzanie wody, 2- piec wyłączony)
/* Tryby nocny i dzienny są ustalane na serwerze heat_server który ma zegar RTC i dostosowuje
żądanie do aktualnego trybu pracy */
};
struct HouseData {
float temperature; //Temperatura w domu
float requested; //Wymagana temperatura docelowa w domu
float tmax; // Maksymalna temperatura na piecu
float tmin; // Minimalna temperatura na piecu
int rmode; //Żądany tryb pracy pieca
};
HTSensorData htdata;
HouseData house;
char house_json[200];
char htsensor_json[200];
#define HTSENSORDATA_JSON_SIZE (JSON_OBJECT_SIZE(5))
#define HOUSEDATA_JSON_SIZE (JSON_OBJECT_SIZE(5))
bool deserializeHTSensor();
void serializeHTSensor();
bool deserializeHouse();
void serializeHouse();
bool deserializeHTSensor()
{
StaticJsonBuffer<HTSENSORDATA_JSON_SIZE> jsonBuffer;
JsonObject& root = jsonBuffer.parseObject(htsensor_json);
if (root.success())
{
htdata.name = root["name"];
htdata.status = root["status"];
htdata.error = root["error"];
htdata.temperature = root["temperature"];
htdata.mode = root["mode"];
}
return root.success();
}
void serializeHTSensor()
{
StaticJsonBuffer<HTSENSORDATA_JSON_SIZE> jsonBuffer;
JsonObject& root = jsonBuffer.createObject();
root["name"] = htdata.name;
root["status"] = htdata.status;
root["error"] = htdata.error;
root["temperature"] = double_with_n_digits(htdata.temperature,1);
root["mode"] = htdata.mode;
root.printTo(htsensor_json, sizeof(htsensor_json));
}
bool deserializeHouse()
{
StaticJsonBuffer<HOUSEDATA_JSON_SIZE> jsonBuffer;
JsonObject& root = jsonBuffer.parseObject(house_json);
if (root.success())
{
house.temperature = root["temperature"];
house.requested = root["requested"];
house.tmax = root["tmax"];
house.tmin = root["tmin"];
house.rmode = root["rmode"];
}
return root.success();
}
void serializeHouse()
{
StaticJsonBuffer<HOUSEDATA_JSON_SIZE> jsonBuffer;
JsonObject& root = jsonBuffer.createObject();
root["temperature"] = house.temperature;
root["requested"] = house.requested;
root["tmin"] = house.tmin;
root["tmax"] = house.tmax;
root["rmode"] = house.rmode;
root.printTo(house_json, sizeof(house_json));
}
|
I have this problem reproduce for me is, no ap for persistent sta to connect to , so it just trys over and over. get errors on iphone such as incorrect password, or could not join network!
|
@boguslawb is this issue still valid with latest git? with PR #3215 ? |
@boguslawb if still valid, please reduce the sketch (MCVE) to allow investigation. |
I've got the same issue. My solar panels are posting via WiFi to the ESP8266. Every sunrise and sunset, there may be power interruptions to the sending device. As a result the (receiving) ESP8266 stop responding to any TCP. ESP8266 keeps functioning on everything, except TCP: it replies to a ping, it continues to send out UDP comms, serial is working etc. ESP is running in STA mode. There is more than enough free heap (around 30000), the ESP is also not flooded with TCP requests. The fact that it stops to respond to all TCP ports, makes me think WiFiServer gets into an unresponsive state. I already had the cleanup in my loop, but this didn't change anything: Btw: this ESP only runs in STA. Both the panels and the ESP are connected via a separate access point. |
@KlaasjanN This was a behaviour with lwip v1.4 that has been improved with lwip v2. |
@d-a-v Thank for your reply. I just checked with 2.4 lwip v2 MSS=536. In this case the other TCP services keep running (so that has improved!). But the WiFiServer on port 80 still stops responding, until I reset the device. The only thing I can get from logging is this: both at sunrise & sunset ;-) I do not have access to the code of the solar device sending it. When sending via a Raspberry it's all fine. It worries me that this request can actually make the esp unresponsive, this already happens with just a WiFiServer server(80) -and a simple- server.begin(). The device normally sends a http post, but since there is binary data in it, I cannot use the http webserver to access that data (it makes it a string). |
@KlaasjanN several things have been fixed since January. Could you please retest with latest git? |
Will check in the next days!
… Op 29 mei 2018 om 18:25 heeft Develo ***@***.***> het volgende geschreven:
@KlaasjanN several things have been fixed since January. Could you please retest with latest git?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I ran into the same problems running WiFiServer and ESPAsyncWebServer and after some hours the services are not responsive anymore. Currently framework is on gitver
|
@mafe Please try latest git master version, then open a new issue with your details. |
@KlaasjanN did you get a chance to retest? |
Checked with 2.4.1 - can still make TCP fully unresponsive, while UDP (and the ESP) continues to work.
… Op 12 jul. 2018 om 07:35 heeft Develo ***@***.***> het volgende geschreven:
@KlaasjanN did you get a chance to retest?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@KlaasjanN the request is to test with latest git, not with 2.4.1. Several critical fixes have been merged after 2.4.1 was released. |
@devyte I can confirm that I cannot reproduce the same issue anymore on release 2.4.2 (lwip v2 HB). So the issue seems fixed! (Sorry for the late reply... had too much going on) I did experience a loss of IP connectivity on one of the devices, but that was not related to this issue. Still need to figure out what actually happened there (perhaps I did not give it a power cycle after an upgrade, else I'll open up an issue once I've done my analysis). Thank you all for your dedication and much appreciated efforts! |
Awesome. |
I started having issues like this today, Err already associated, I noticed this seems to happen when the network enviroment is crowded. Might be a hint if anyone comes across this. |
@tablatronix this will be off-topic for issue 2194, where TCP actually came to a halt, due to the connection being terminated externally (and UDP kept functioning, ESP did reply to a ping etc). I'm closing in a bit on this apparent new issue, and it seems it's similar to what others reported. What I noticed so far:
I've got 3 ESP's running, all exactly the same software and version. Every 10 minutes they write something in a logfile. There is only one difference: my tablet connects to the webserver on the 3rd device every 5 seconds to fetch a 600 byte 'journal', so load is higher. As mentioned the software and configuration is exactly the same. Guess what.... 2 of those are working fine, no issues. The third has experienced issues nearly every night since I deployed the new release. I even exchanged ESP itself! In the past I could experience an occasional 'hang', but nights in a row is a different story (and this happens randomly, but each time it's a multiply of 10 minutes (xx:x0 hours). I'll try to reproduce it with a nice and clean MCVE. The symptoms: ESP continues to process sensordata and continues to write the logfile. It also logs that is has a connection and an IP address. But all Wifi communications are blocked in all directions. No ping, no TCP, no UDP (in issue 2194, only TCP stopped working). |
Murphy didn't allow a failure last night.... So no more data. Did do some tests and found out that the symptoms described are similar to what happens if you do a wifi.disconnect (wifi.status stays at connected at that time!). I implemented a workaround by checking if external data is still received. When data is not received for a few minutes, a wifi.reconnect() is triggered. (Guess autoreconnect isn't working as wifi.status remains connected?). The 'manual' wifi.reconnect seems to work fine. Will monitor it for the next few days. |
@KlaasjanN @tablatronix You don't mention those tweaks, did you try them ? |
I'll evaluate WiFi.setSleepMode(WIFI_NONE_SLEEP) as it doesn't hurt to put that in the wifi init. |
hmm, I tried sleep none at one point, I will try again if I can |
Tried WiFi.setSleepMode(WIFI_NONE_SLEEP) and solved my udp client connection problems!! |
About Ping-Alive, the goal is to reactivate/trigger the wifi layer from the inside. PingAlive does ping the gateway from inside the esp, which is not the same as some host pinging the ESP (the esp does not necessarily wake up before a ping request comes up, but it needs to do so before sending a packet). I don't know yet for sure whether it is efficient nor anything about current consumption with a good power meter since I have absolutely no report. |
I understand, but my devices are exchanging data every few seconds, they
receive and send. I was a bit skeptical, expecting that a WiFi would never
enter any sleep mode under those circumstances. But after 7 days of
WiFi.setSleepMode(WIFI_NONE_SLEEP)
I did not get any device disconnect anymore!!! Read elsewhere that power
consumption without wifi is 16-20 mA, when it never sleeps it is about 70
mA.
Op vr 14 sep. 2018 om 12:56 schreef david gauchard <[email protected]
…:
@KlaasjanN <https://github.com/KlaasjanN>
I think the ping-alive won't do much in my situation, because the device
already receives data every few seconds. So I expect it to be alive enough.
About Ping-Alive, the goal is to reactivate/trigger the wifi layer *from
the inside*. PingAlive does ping the gateway from inside the esp, which
is not the same as some host pinging the ESP (the esp does not necessarily
wake up before a ping request comes up, but it needs to do so before
sending a packet).
I don't know yet for sure whether it is efficient nor anything about
current consumption with a good power meter since I have absolutely no
report.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2194 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Ahx4yQ6BsI8oHn_UC0J-ai8aE5iS7jTgks5ua4tMgaJpZM4I-gWp>
.
|
... until the esp stops responding, hence the ping from the inside to wake wifi up. Again, and without report, I don't know if that works, but if it does, it will probably consume less current. Anyway I'm glad the none_sleep sleep mode fixes these disconnections ! |
Basic Infos
Hardware
Hardware: Wemos D2 Mini ESP12F
Core Version: ?2.1.0-rc2?
Description
It happens when Wificlient is abruptly disconnected (for example when power failure occurs). When power is restored connection to Wifi softAP seems established but TCP server do not work again :
My question is how to detect such problem in server code and close client releasing TCP stack ? At least wdt reset would be nice
Settings in IDE
Module: Wemos D2 Mini
Flash Size: ?4MB/1MB?
CPU Frequency: ?80Mhz?
Flash Mode: ?qio?
Flash Frequency: ?40Mhz?
Upload Using: ?OTA / SERIAL?
Reset Method: ?ck / nodemcu?
Sketch
Debug Messages
The text was updated successfully, but these errors were encountered: