Closed boguslawb closed 6 years ago
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. mode STA+AP iphone wont connect to soft AP
get errors on iphone such as incorrect password, or could not join network! errors in debug like
err already associed!
station: dc:0c:5c:e2:.. leave, AID = 1
@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. I have three WiFiServer instances running, on port 80 (tcp), 8080 (httpserver) and 9876 (tcp). The solar panels only talk to the one on port 80, but traffic stops (time-out) on ANY TCP port.
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: {while(tcp_tw_pcbs!=NULL){tcp_abort(tcp_tw_pcbs);}}
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. Could you try the latest git version of core (post 2.4 release) ?
@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 ;-) :urn 38 :urd 38, 38, 0 WS:ac
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 notifications@github.com 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. Client connections (websocket:tcp:80) from the ESP8266 are still working.
Currently framework is on gitver
Platform Espressif 8266 (Stage)
--------
Updating espressif8266 @ 76fb9d2 [Up-to-date]
@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 notifications@github.com 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). Btw: memory usage has improved a lot as well, also in relation to lwip v2 in this release
Thank you all for your dedication and much appreciated efforts!
Awesome. Closing due to lack of feedback from OP and can't reproduce with latest release.
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. 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. And for signal strength: it's close to an AP, and if the AP drops, it connects to another one, all without any problems. For last: I'm always running with fixed IP's.
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!!
@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.
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 <notifications@github.com
:
@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 https://github.com/esp8266/Arduino/issues/2194#issuecomment-421320918, or mute the thread https://github.com/notifications/unsubscribe-auth/Ahx4yQ6BsI8oHn_UC0J-ai8aE5iS7jTgks5ua4tMgaJpZM4I-gWp .
but my devices are exchanging data every few seconds, they receive and send
... 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