ESP8266 - Arduino - HTTP Get, ESP stürzt ab.

[Holger K. (holgerkraehe)]

Hallo zusammen

Ich versuche mit einem ESP8266 eine GET-Anfrage zu senden.
Leider stürzt nach 2-3 Anfragen der ESP ab.

Ich vermute es handelt sich um eine Wechselwirkung zwischen zwei 
Libraries.
Da Debugging praktisch unmöglich ist, kann ich das Problem kaum 
eingrenzen.

Was ich machen möchte:

Im 2-5 Sekunden Takt eine GET Anfrage an eine RestFull URL senden.

z.b. domain.tld/pushData.php?data=123

Nun frage ich mich, wie ich dies am einfachsten machen könnte.
Die vielen HTTPClient beispiele funktionieren leider nicht richtig.
Ich vermute es ist ein problem, da diese Librarys nicht ansync sind.

Kennt jemand eine Möglichkeit, möglichst rudimentär, eine GET Anfrage zu 
senden?

Ist es sinnvoll, die verbingung wieder zu trennen, wenn innerhalb von 
2-3 sekunden wieder eine Anfrage gesendet wird?

Danke

[Michael U. (amiga)]

Hallo,

Holger K. schrieb:
> Ich vermute es handelt sich um eine Wechselwirkung zwischen zwei
> Libraries.

gibt es zwar manchmal durchaus, ich kann aber die Namen der Libs in 
meiner Glaskugel nicht richtig erkennen.

> Da Debugging praktisch unmöglich ist, kann ich das Problem kaum
> eingrenzen.

Set Erfindung der Seriellen Schnittstelle kann man sich auch von einem 
ESP alles mögliche ausgeben lassen. Manchmal nutze ich soagr MQTT dafür 
wennd as Ding nicht am Rechner hängt...

Holger K. schrieb:
> Die vielen HTTPClient beispiele funktionieren leider nicht richtig.

Das wäre mir doch neu...

Holger K. schrieb:
> Ist es sinnvoll, die verbingung wieder zu trennen, wenn innerhalb von
> 2-3 sekunden wieder eine Anfrage gesendet wird?

Zumindest sollte man klären, ob die vorigie Anfrage überhaupt schon 
beantwortet wurde.

Sorry, aber ich Deinem Post irgendwie nicht richtig interpretieren.
Ich benutze sowas in der Art zwar selten, intern im Netz allerdings sehr 
häufig und nicht in so kurzen Zeitabständen. Wüßte auch nicht, wozu das 
gut sein sollte, ein Webserver ist ja keine Real-Time-Engine.

Gruß aus Berlin
Michael

[Holger K. (holgerkraehe)]

Michael U. schrieb:
> gibt es zwar manchmal durchaus, ich kann aber die Namen der Libs in
> meiner Glaskugel nicht richtig erkennen.

Richtig,

Es handelt sich um die nRF24 Library.

https://github.com/nRF24

Ich nutze RF24, Network und Mesh

Anbei mein .ino ohne HTTPClient.
Dieses .ino ist die Grundlage, in welches ich die GET Funktionalität 
noch mit einbauen möchte.


Michael U. schrieb:
> Set Erfindung der Seriellen Schnittstelle kann man sich auch von einem
> ESP alles mögliche ausgeben lassen. Manchmal nutze ich soagr MQTT dafür
> wennd as Ding nicht am Rechner hängt...

Richtig, oft bekomme ich vom HTTPClient ein connection refused. Wenn ich 
jedoch den RF24 Teil komplett auskommentiere, so funktioniert es oft, 
2-3 mal und dann gehts nicht mehr.

[Arduino Fanboy D. (ufuf)]

Holger K. schrieb:
> Die vielen HTTPClient beispiele funktionieren leider nicht richtig.

Dann machst du was anderes falsch.

Holger K. schrieb:
> Ich vermute es handelt sich um eine Wechselwirkung zwischen zwei
> Libraries.
Ja klar....
Wenn das HTTP korrekt abgehandelt wird, dann tuts das auch!

Holger K. schrieb:
> st es sinnvoll, die verbingung wieder zu trennen, wenn innerhalb von
> 2-3 sekunden wieder eine Anfrage gesendet wird?
Seit HTTP1.1 kann man Verbindungen offen halten.

Aber das erfordert erhöhte Aufmerksamkeit, wenn das mit den Zwergen 
gelingen soll.

Offensichtlich solltest du dich über das HTTP kundig machen.

[Michael U. (amiga)]

Hallo,

Holger K. schrieb:
> Es handelt sich um die nRF24 Library.
>
> https://github.com/nRF24

ich habe nur schnell reingeschaut, habe ich noch nie genutzt. Erwähnt 
wird der ESP zumindest nicht, nur Arduino und RasPi.

Müßte man mal schauen, ob jemand das schon auf dem ESP hatte.
> Anbei mein .ino ohne HTTPClient.
> Dieses .ino ist die Grundlage, in welches ich die GET Funktionalität
> noch mit einbauen möchte.

Ich könnte zwar aus Interesse mal einen nRF2401A an einen ESP8266 
hängen, was macht die Geschichte wenn es da kein Mesh etc. gibt, läuft 
das so durch oder wartet der nRF-Kram dann auf irgendwas und bleibt 
hängen?
Dann würde es hier keinen Sinn machen hier so zu testen, wird heute aber 
zeitlich sowieso nichts bei mir.

Gruß aus Berlin
Michael

[Holger K. (holgerkraehe)]

Michael U. schrieb:
> Ich könnte zwar aus Interesse mal einen nRF2401A an einen ESP8266
> hängen, was macht die Geschichte wenn es da kein Mesh etc. gibt, läuft
> das so durch oder wartet der nRF-Kram dann auf irgendwas und bleibt
> hängen?
> Dann würde es hier keinen Sinn machen hier so zu testen, wird heute aber
> zeitlich sowieso nichts bei mir.

Vielen Dank für dein Angebot!

Ich werde die Software so anpassen, dass es einen Fehler gibt, ohne dass 
du ein zweites NRF24 Modul benötigst.

So dass es genügt, ein Modul am ESP zu haben.

Ich melde mich, sobald ich ein entsprechendes .ino habe.

[Arno (Gast)]

Schuss ins Blaue: In den aktuellen ESP-Arduino-Versionen 2.4.0 und 2.4.1 
gibt es einen Bug in WiFiClient, der benutzten Speicher beim reconnect 
nicht korrekt freigibt: https://github.com/esp8266/Arduino/issues/4497 - 
möglicherweise setzt HTTPClient intern auf WiFiClient?

Äußert sich ähnlich wie dein Problem... lässt sich aber recht gut 
debuggen, indem du regelmäßig Serial.println(ESP.getFreeHeap()) 
aufrufst.

MfG, Arno

[Holger K. (holgerkraehe)]

So, ich habe nun mal etwas zusammengetragen.
Anbei das .ino file.

Zum Vorgehen:

- NRF24 ist wie folgt verbunden:

  pinMode(0,OUTPUT);  //SCK
  pinMode(5,INPUT);   //MISO
  pinMode(4,OUTPUT);  //MOSI
  pinMode(2,OUTPUT);  //CS
  pinMode(15,OUTPUT); //CE

Ein Funkmodul ist nicht in Reichweite.
Somit könnte dies theoretisch jeder mit nur einem NRF nach"bauen"

Ich habe meine RF24 Library entsprechend angepasst, dass diese bei 
eienem ESP8266 automatisch SoftSPI macht. Einige Ports sind noch 
hardcoded. Ist erstmal aber irrelevant.

Was geschieht:

Wenn ich das ino so wie es angehängt ist herunterlade, so ergibt sich 
ERR01.png nach dem Starten.

Wenn ich genau dasselbe .ino nochmals herunterlade, ergibt sich 
ERR02.png.

Wenn ich nun genau dasselbe .ino noch mit HTTP_CLIENT Debug 
herunterlade, ergibt es ERR03.txt

Ab irgend einem Punkt gibt es nur noch connection refused, aber keinen 
wdt mehr.

ERR04.txt -> hier wurde der vorgeschlagene 
Serial.println(ESP.getFreeHeap()); eingefügt. Der freie Speicher bewegt 
sich im Bereich von 41760 Bytes. Sollte also gut sein ;)
Interessanterweise, schafft es diese Version kein einziges mal, einen 
GET zu senden.

ERR05.txt -> hier wurde der Serial.println(ESP.getFreeHeap()); wieder 
entfernt, und auf Gut Glück einfach nochmals versucht. Siehe da, es gab 
eine Exception.

Für mich ist dieses Verhalten äusserst fragwürdig!
Mir ist bewusst, dass die pushData.php URL vorhanden ist.
Es darf jeder soviel pushen wie er möchte!

Auch die SSID ist nur eine Temporäre. Daher keine Bedenken!

Anbei befindet sich noch meine angepasste RF24 Lib.
Die Mesh und Network sind original, untouched!

Arno schrieb:
> Äußert sich ähnlich wie dein Problem... lässt sich aber recht gut
> debuggen, indem du regelmäßig Serial.println(ESP.getFreeHeap())
> aufrufst.

Vielen Dank für deinen Hinweis.
Wie du siehst, habe ich diesen danke deinem Hinweis bereits ausprobiert.

[Holger K. (holgerkraehe)]

Nachtrag:

Wenn ich die RGB-LED auskommentiere:

  //pinMode(12,OUTPUT); //B
  //pinMode(16,OUTPUT); //R
  //pinMode(14,OUTPUT); //G

  pinMode(0,OUTPUT);  //SCK
  pinMode(5,INPUT);   //MISO
  pinMode(4,OUTPUT);  //MOSI
  pinMode(2,OUTPUT);  //CS
  pinMode(15,OUTPUT); //CE

 

  //analogWrite(12,120);
  //analogWrite(14,150);
  //analogWrite(16,200);

Scheinen die Fehler wie von Geisterhand massiv besser zu werden.
Dann ergibt sich ERR06.txt
Leider kommt am ende dennoch ein wdt

Kann sich dies jemand erklären? Liegt dies am PWM?

Bei ERR07.txt wurde nun der Heap wieder überwacht.
Leider scheint dies dem ESP gar nicht zu bekommen. Er stützt ziemlich 
direkt ab (wdt).

Bei ERR08.txt wurde nun genau das selbe wie bei ERR07.txt nochmals 
geladen. Immerhin schaffen wir es nun auf einen GET.


Bei ERR09.txt wurde nun google.ch ge Gettet.
Scheint so, als hätte mein Server auch noch ein Problem.
Denn mit google.ch scheint es zu funktionieren.

Trozdem kann ich mir das unvorhersehbare Verhalten nicht erklären.
Denn wenn ich die URL im Browser eingebe, kann ich so oft wie ich möchte 
refresh drücken, ohne dass es einen Fehler gibt.

EDIT -> Zu früh gefreut.
Nach ca. 1 Minute gibt Google connection refused

[HTTP-Client][end] tcp is closed
 
********Assigned Addresses********
**********************************
39832
Try to begin HTTP GET
[HTTP-Client][begin] url: http://google.ch
[HTTP-Client][begin] host: google.ch port: 80 url: 
[HTTP-Client] failed connect to google.ch:80
[HTTP-Client][returnError] error(-1): connection refused
-1
[HTTP-Client][end] tcp is closed
 
********Assigned Addresses********
**********************************
40376
Try to begin HTTP GET
[HTTP-Client][begin] url: http://google.ch
[HTTP-Client][begin] host: google.ch port: 80 url: 

********Assigned Addresses********
**********************************
41784
Try to begin HTTP GET
[HTTP-Client][begin] url: http://google.ch
[HTTP-Client][begin] host: google.ch port: 80 url: 
[HTTP-Client] failed connect to google.ch:80
[HTTP-Client][returnError] error(-1): connection refused
-1
[HTTP-Client][end] tcp is closed
Fatal exception 0(IllegalInstructionCause):
epc1=0x4000dd3b, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000

Exception (0):
epc1=0x4000dd3b epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

ctx: cont 
sp: 3fff0780 end: 3fff0aa0 offset: 01a0

>>>stack>>>
3fff0920:  3ffef9b0 00000008 3fff0930 402065ac <
3fff0930:  40106a98 00000002 00000002 40106b91  
3fff0940:  74205d64 00000002 00000002 402031ce  
3fff0950:  3ffe000a 3fff09e0 3ffef75c 3ffefa70  
3fff0960:  00000000 00000017 3ffef75c 4020322b  
3fff0970:  3ffef5a8 3ffef75c 3fff0990 402039ac  
3fff0980:  3ffef5d4 3ffef5de 00000000 40202e54  
3fff0990:  3ffef98c 00000151 3fff1b5c 40205113  
3fff09a0:  3ffef5a8 ffffffff 3fff1a4c 3ffefa70  
3fff09b0:  3fffdad0 3ffef5ac 3ffef5ac 40204012  
3fff09c0:  3ffef5a8 3ffef9b0 3fff09e0 402061c8  
3fff09d0:  3fffdad0 3ffef5ac 3ffefa68 402023a5  
3fff09e0:  00000000 00000000 00000000 00000000  
3fff09f0:  00000000 3f000050 3f001388 00000000  
3fff0a00:  00000000 00000000 00000000 00000000  
3fff0a10:  00000000 00000000 00000000 00000000  
3fff0a20:  00000000 00000000 00000000 00000000  
3fff0a30:  00000000 00000000 00000000 00000000  
3fff0a40:  00000000 ffffffff 3ffef900 00000000  
3fff0a50:  00000000 00000000 00000000 402065f0  
3fff0a60:  3fffdad0 3ffef5ac 3ffef9b0 40206664  
3fff0a70:  00000000 00000000 00000001 3ffefa70  
3fff0a80:  3fffdad0 00000000 3ffefa68 40207790  
3fff0a90:  feefeffe feefeffe 3ffefa80 40100a2c  
<<<stack<<<

 ets Jan  8 2013,rst cause:2, boot mode:(1,6)


 ets Jan  8 2013,rst cause:4, boot mode:(1,6)

wdt reset

[Stefan ⛄ F. (stefanus)]

Ich sehe da zwei Resets direkt nacheinander. Der erste cause:2 deutet 
an, dass der Chip vom Deep-Sleep aufgewacht ist. Der zweite cause:4 
deutet an, dass der Watchdog-Timer ausgelöst hat.

Deep Sleep benutzt du aber gar nicht in deinem Quelltext.
Wenn ein Programm amok läuft, dann ist der Grund fast immer ein Stack 
Überlauf. Auf die Schnelle sehe ich in deinem ino keinen entsprechenden 
Schwachpunkt. Vielleicht ist in dieser mesh Library was falsch.

Zum Watchdog:
Der löst aus, wenn deine loop zu lange beschäftigt ist. Aber auch da 
sehe ich keine mögliche Ursache in der ino.

Du kannst zur Kontrolle mal Start und Ende der loop mit einem I/O Pin 
anzeigen und die Zeit messen. Es soll weniger als 20ms sein.

Falls das Ok ist, würde ich die verwendeten Libraries untersuchen, 
insbesondere bezüglich Stack-Verbrauch. Bei meinem letzten Test fand ich 
heraus, dass man nicht viel mehr als 4kB Stack belegen darf.

[Holger K. (holgerkraehe)]

Stefanus F. schrieb:
> Falls das Ok ist, würde ich die verwendeten Libraries untersuchen,
> insbesondere bezüglich Stack-Verbrauch. Bei meinem letzten Test fand ich
> heraus, dass man nicht viel mehr als 4kB Stack belegen darf.

Vielen Dank.
Wie untersuche ich dies beim ESP8266?

Ich habe noch gelesen, dass es teilweise Korrupte Daten im Flash gibt, 
je nach USB-Serial adapter oder auch je nach Baudrate.

Einige haben berichtet, dass erst das vollständige Löschen des Flashs, 
die Probleme behoben hat.

Ich habe das Flash nun gelöscht und beschreibe es nun mit 57600 Baud.
Danach versuche ich es mittels OTA zu beschreiben.

[Holger K. (holgerkraehe)]

Ich habe das Flash nun mit dem ESP Tool vollständig gelöscht und dannach 
mit 57600 Baud das Programm geladen.

Nun läuft es seit einigen Minuten mit der ursprünglichen pushAdresse 
erfolgreich.

Ich bin mal vage zuversichtlich

[Stefan ⛄ F. (stefanus)]

Der Flash wird doch nach dem Beschreiben nochmal kontrolliert, oder etwa 
nicht?

Wie man die Größe des Stack prüft, musst du selbst herausfinden. Ich 
weiß nur anhand reproduzierbarer Abstürze, das er weniger als 5kB für 
eigene Anwendungen übrig hat (Stand Mai 2017).

Auf jeden Fall kannst du da nicht die AVR spezifische Testmethode 
anwenden. Beim ESP funktioniert die Speicherverwaltung ganz anders.

[Holger K. (holgerkraehe)]

Stefanus F. schrieb:
> Der Flash wird doch nach dem Beschreiben nochmal kontrolliert, oder etwa
> nicht?

Nein, wird er nicht.
Das Problem scheint definitiv gelöst zu sein!
Es läuft nun tadellos seit mehreren Minuten.

Vielen Dank!

[Stefan ⛄ F. (stefanus)]

Dann hast du das sicher verstellt. Kontrolliere mal deine 
Voreinstellungen (Code nach dem Hochladen prüfen).

[Holger K. (holgerkraehe)]

Stefanus F. schrieb:
> Dann hast du das sicher verstellt. Kontrolliere mal deine
> Voreinstellungen (Code nach dem Hochladen prüfen).

Werde ich gleich machen.
Wo wäre dies zu finden?

Es scheint wohl doch noch nicht ganz alles einwandfrei zu funktionieren:

Voltage: 3.50 V
Temperature: 28.75 C
Humidity: 29.64 %rH
41896
Try to begin HTTP GET
200

 
********Assigned Addresses********
NodeID: 1 RF24Network Address: 05
**********************************
Voltage: 3.50 V
Temperature: 28.68 C
Humidity: 29.15 %rH
41896
Try to begin HTTP GET

Exception (0):
epc1=0x401f9bb5 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

ctx: cont 
sp: 3fff0090 end: 3fff03e0 offset: 01a0

>>>stack>>>
3fff0230:  000000a4 00000001 3fff0294 00000000  
3fff0240:  00000000 00000001 3fff0294 4020a280  
3fff0250:  3ffe8ce4 3fff0288 3fff0320 00000000  
3fff0260:  00000000 3ffe8ce4 3fff0320 402062db  
3fff0270:  00000000 00000000 00000000 00000000  
3fff0280:  00000000 00000000 00000000 00000000  
3fff0290:  00000000 3fff1f54 000000af 000000a6  
3fff02a0:  3ffe8d38 00000000 00000000 40209e7f  
3fff02b0:  00000000 00000000 3fff0320 40206962  
3fff02c0:  3ffef2d0 00000258 00000258 3ffef3b8  
3fff02d0:  3ffeee0c 00000001 3fff0320 401004d8  
3fff02e0:  3ffe8d38 00000161 00000161 4010020c  
3fff02f0:  3ffeee0c 3ffe8a80 3fff039c 3ffef3b8  
3fff0300:  3ffeee0c 3ffe8a80 3ffef2f8 402069be  
3fff0310:  3ffeee0c 3ffe8a80 3ffef2f8 40202bf4  
3fff0320:  3fff10ec 3fff172c 3fff1c64 0000001f  
3fff0330:  00000017 3f000050 00001388 3fff1efc  
3fff0340:  0000004f 00000046 3fff18e4 0000000f  
3fff0350:  00000004 3fff18fc 0000000f 00000000  
3fff0360:  3fff1914 0000001f 00000011 3fff193c  
3fff0370:  0000000f 00000000 00000000 00000000  
3fff0380:  00000000 ffffffff 3ffef000 00000000  
3fff0390:  00000000 00000000 00000000 00000000  
3fff03a0:  00000000 00000000 0b630db0 40200b34  
3fff03b0:  00000000 00000000 00000001 3ffef3b8  
3fff03c0:  3fffdad0 00000000 3ffef3b0 4020aa88  
3fff03d0:  feefeffe feefeffe 3ffef3c0 40100710  
<<<stack<<<

 ets Jan  8 2013,rst cause:2, boot mode:(1,7)


 ets Jan  8 2013,rst cause:4, boot mode:(1,7)

wdt reset

[Arduino Fanboy D. (ufuf)]

> Exception (0):
Nutze den "ESP Exception Decoder".
Dieser lässt sich in der IDE integrieren.

[Stefan ⛄ F. (stefanus)]

>> Dann hast du das sicher verstellt. Kontrolliere mal deine
>> Voreinstellungen (Code nach dem Hochladen prüfen).

> Werde ich gleich machen.
> Wo wäre dies zu finden?

In den Voreinstellungen (im Datei Menü).

[Holger K. (holgerkraehe)]

Stefanus F. schrieb:
>>> Dann hast du das sicher verstellt. Kontrolliere mal deine
>>> Voreinstellungen (Code nach dem Hochladen prüfen).
>
>> Werde ich gleich machen.
>> Wo wäre dies zu finden?
>
> In den Voreinstellungen (im Datei Menü).

Achsoo, ja, das ist gesetzt.
Ich glaube aber nicht, dass der Flash tatsächlich überprüft wird.

[Michael U. (amiga)]

Hallo,

ich komme heute nicht mehr zu Experimenten.
Es gibt ein Problem mit einem Flashtype eines Herstellers, ich finde den 
Thread by Espressif gerade nicht. Ursprünglich sollte es nur ESp-01 
Module mit 1MB Flash dieses Types und Upload von SPIFFS-Daten betreffen.
Es sind inzwischen wohl auch NodeMCU-Module mit Problemen beim 
Sketch-Upload aufgetaucht. In den Sonoff-Relaismodulen ist bei mir solch 
ein Flashtype verbaut.
Diese lassen sich nur im Mode DQOUT zuverlässig flashen.
baudrate usw. sind nur Zufallseffekte, ich flashe generell mit 921600, 
nur bei meinem "Drahtverhau"-Adapter, der per Lötleitungen an 
irgendwelche -03/-07/-12 gelötet wird, bricht ein flashen manchmal ab, 
beim 2. versuch läuft es dann durch. Fehlerhafte Daten hat es aber noch 
nie erzeugt, wenne s durchlief war auch alles ok.

Nur besagter Flashtyp erzeugt auch nach fehlerfreiem flashen umotivierte 
Exception auch direkt nach dem Start.

Ist im Moment nur ein Hinweis wegen der verschiedenen Reset-Gründe.

Gruß aus Berlin
Michael

[Holger K. (holgerkraehe)]

Michael U. schrieb:
> Ist im Moment nur ein Hinweis wegen der verschiedenen Reset-Gründe.
>
> Gruß aus Berlin
> Michael

Vielen Dank für deine Beteiligung.
Das ESP-Download Tool von Espressif sagt folgendes zum Flash:

flash vendor:
E0h : N/A
flash devID:
4016h
QUAD;32Mbit
crystal:
26 Mhz

Ich flashe immer mit den angehängten Einstellungen (mit ausnahme der 
Baudrate natürlich)

[Stefan ⛄ F. (stefanus)]

Versuche es mal mit der anderen (älteren) lwIP Variante. Die neue v2 
habe ich noch gar nicht verwendet, weil ich mit der alten zufrieden bin 
(kein Bock auf neue Probleme, der ESP hat mich schon genug Nerven 
gekostet).

Nochwas, ich kann es gar nicht oft genug herunter beten: Instabilitäten 
werden sehr häufig durch schlechte Stromversorgung verursacht. Das 
Netzteil muss alleine für den ESP mindestens 400mA liefern können.

Steckbretter eignen sich schlecht. Die Kontakte haben häufig zu viel 
Übergangswiderstand und die typischen Dupont-Kabel sind zu dünn. Dazu 
kommt, dass die Kapazitäten zwischen den Kontakten die Funktion des 
Flash Speichers stören können, wenn dessen Daten-Leitungen auf die 
Stiftleiste herausgeführt sind.

[Michael U. (amiga)]

Hallo,

vergiß meine Anmerkung zum Flash. Ist ein BG25Q32 von BergMicro (4MB).
Da ist mir keine Auffälligkeit bekannt, der ist auf diversen ESP8266-12 
Modulen verbaut.

Da es Stefanus F. (stefanus) gerade ansprach: ich benutze auch noch lwIP 
v1.4, die 2.0 hat noch ein paar Probleme, aber mehr mit älteren Libs mit 
WLAN-Funktionen.

Gruß aus Berlin
Michael

[Stefan ⛄ F. (stefanus)]

Löte mal einen 100µF oder 220µF Elko direkt auf das Modul an VCC und 
GND.

[Holger K. (holgerkraehe)]

Michael U. schrieb:
> Da es Stefanus F. (stefanus) gerade ansprach: ich benutze auch noch lwIP
> v1.4, die 2.0 hat noch ein paar Probleme, aber mehr mit älteren Libs mit
> WLAN-Funktionen.

Danke für den Hinweis.
Habe ich nun versucht. Leider ohne signifikante Änderungen.
Teilweise hat das Modul auch mühe sich zu verbinden.

Stefanus F. schrieb:
> Löte mal einen 100µF oder 220µF Elko direkt auf das Modul an VCC
> und
> GND.

Danke für den Tipp.
Bevor ich dies tun werde, werde ich mit den Oszilloskop nachschauen wie 
es aussieht.

[Andreas B. (andreasb)]

Holger K. schrieb:
> Nachtrag:
>
> Wenn ich die RGB-LED auskommentiere:
>
...
>
> Scheinen die Fehler wie von Geisterhand massiv besser zu werden.
> Dann ergibt sich ERR06.txt
> Leider kommt am ende dennoch ein wdt

Der ESP hat kein Hardware PWM, sondern verwendet Software PWM.

  analogWrite(12,120);
  analogWrite(14,150);
  analogWrite(16,200);

Du verwendest PWM.
Durch deaktivieren veränderst du dein Timing verhalten.

Dein Fehlerverhalten könnte ein Timing Problem sein. Leider ist dies 
sehr schwer zu testen.

Grundsätzlich ist da immer der Tipp: Den Code reduzieren, so viel 
Funktionalität raus nehmen bis der Fehler nicht mehr auftritt.

Konkret: Ein mal nur Funk Module, ein mal nur WLAN.
DHCP raus etc.

Wenn du die "Ursache" gefunden hast, den Rest wieder aktivieren, tritt 
der Fehler dann nicht mehr auf, liegt es spezifisch an der Funktion, 
wenn der Fehler wieder auftritt, kann es gut ein Timing Problem sein.

Genannt wurde es ja bereits: Durch ausschalten von Funktionalität wird 
möglicherweise ein Problem mit der Spannungsversorgung mit gelöst. Aber 
das wolltest du ja sowieso messen....

Im loop etwas raus zu schreiben (über UART) ist auch immer eine gute 
Möglichkeit, dann siehst du, ob sich da was aufhängt.

Viel Erfolg beim probieren.

mfg Andreas

[Holger K. (holgerkraehe)]

Andreas B. schrieb:
> Du verwendest PWM.
> Durch deaktivieren veränderst du dein Timing verhalten.

Daran habe ich auch schon gedacht.

Andreas B. schrieb:
> Viel Erfolg beim probieren.
>
> mfg Andreas
Danke

Ich habe inzwischen neue Erfolge zum verkünden.
Habe gestern Abend noch vor irgendwelchen Messungen, 470uF direkt über 
das Modul gelötet. Habe ebenfalls auf lwIP 1.4 gewechselt. Habe dann das 
Programm wieder heruntergeladen. Die ersten paar Sekunden / Messwerte 
hat es funktioniert, dann wieder nicht.

In diesem Momment ist mir aufgefallen, dass die Position teilweise einen 
Einfluss auf den Erfolg der GET-Anfrage hat.

Ich habe begonnen die Positionen zu verändern, teilweise mit Erfolg 
teilweise ohne. Als ich jedoch mit dem Finger die Leiterbahnantenne des 
ESP berührt habe, wurden alle GET-Requests direkt ausgeführt. Die 
Distanz zum WLAN-Router betrug jedoch immer nur ca. 10 Meter und dies 
auf Sicht!
Ich habe dann ein ca. 1 Euro grosses Stück Aluminiumfolie mit einer 
Wäscheklammer direkt an die Leiterbahn geklammert. Und siehe da, es lief 
nun die ganze Nacht hindurch ohne irgendeinen Aussetzer. Habe nun heute 
morgen die Alufolie entfernt, die Position allerdings nicht verändert.
Seither nur noch Probleme bei den Requests.

Es scheint also, nebst allem anderem, noch ein Funktechnisches Problem 
zu bestehen. Zum Glück habe ich dieses noch gefunden. Ich denke sowas zu 
Finden ist wirklich reiner Zufall!

Diesem Phänomen auf den Grund zu gehen, wird wohl etwas aufwändiger 
werden.

[Michael U. (amiga)]

Hallo,

laß Dir mal bei WLAN connct bzw. reconnects die RSSI-Werte ausgeben.
Was für ein Modul nutzt Du?
Eine relativ kleine Lageänderung kann die Verhältnisse manchmal exterm 
beeinflussen. Die geschirmten Module sind recht robust gegen 
Einstreuungen, die ungeschirmten (-01, -03 z.B.) reagieren da sauer. Die 
Zuleitung eines elektronischen "Trafos" zu einer 25W halogen verhinerte 
auch bei 15cm Abstand den WLAN-connect bei mir, ein -12 kam auch in 3cm 
Abstand noch klar.
10m bei Sichtverbindung klingt nicht soviel, ich habe aber bei meinem 
Router durchaus schon ein weniger Abstand regelrechte "löcher" in den 
Feldstärkewerten gehabt.

Du hast WiFi.setAutoConnect ( false ) im Sketch, hat das einen Grund?
Der ESP macht das eigentlich sehr ordentlich wenn er sich ohnehin immer 
im selben WLAN anmelden soll.

Du kannst Dei "GET" natürlich in eine Abfrage auf vorhandenen Connect 
kapseln, da gibt es aber auch einen Fallstrick: der ESP meldet WiFi 
connected sobald er wieder im WLAN ist. Wenn er die IP per DHCP bekommt, 
kann es aber passieren, daß er zu diesem noch keine IP hat. Wenn dann 
ein Zugriff startet fällt er auf die Nase. Connetion refused vom Client 
mußt Du ohnehin auswerten, wenn er nicht durchkam eben etwas warten und 
es nochmal probieren.

Ich versuche nachher mal einen Sketch von auf das Minimum 
zusammenzukürzen.
Der ESP ist in einer Steckdosenschaltleiste und schaltet mit 5 SSR die 
Steckdosen. Außerdem ist die WeMo-Emu drin (Amazon/Alexa) und MQTT und 
mein von mir genutztes Webserver-Konstrukt mit SPIFFS-Nutzung sowie 
natürlich OTA.
Dieser ESP ist an einer Stelle wo ich am Tage diverse Reconnects habe 
obwohl die Feldstärke eigentlich ok ist und mir mit 2 andeen ESP ca. 1m 
entfernt keine Probleme aufgefallen sind.

Problem war, daß der ESP sauber reconnectete, im WLAN war, Alexa lief, 
der Webserver erreichbar war und mir der MQTT-Broker das Verschwinden 
des Client meldete. Der war erst nach einem Rest des ESP wieder da bis 
er irgendwann wieder verschwand.

Ursache war das Zusammenspiel genau an dieser Stelle. WLAn-reconnect, 
MQTT reconnect. Der AsyncMQTT hat das auch sehr schnell gemacht, leider 
manchmal eben zu schnell und hat es dann leider nie wieder versucht...
Mit dem PubSubClient für MQTT war das so kein Problem, der war 
blockieren und hat den ganzen Laden zum Stehen gebracht wenn es mal 
schiefging, das fiel mir dann ja auch auf...

Die Lösung habe ich letztlich im Internet irgendwo im Espressif-Forum 
gefunden und nutze die inzwischen hier überall. Besagter ESP ist seitdem 
nie wieder hängen geblieben.
Genutzt werden die WiFi-Eventhandler und die Ticker-lib für den 
reconnect zum Wifi und zum MQTT usw.

Ich muß das nachher nur mal auf das Nötige zusammenkürzen und testen.

Gruß aus Berlin
Michael

[Holger K. (holgerkraehe)]

Michael U. schrieb:
> laß Dir mal bei WLAN connct bzw. reconnects die RSSI-Werte ausgeben.
> Was für ein Modul nutzt Du?

Vielen Dank für deine Antwort.
Ich werde dies gleich mal versuchen.
Ich nutze ESP-12F Boards.

Michael U. schrieb:
> Du hast WiFi.setAutoConnect ( false ) im Sketch, hat das einen Grund?
> Der ESP macht das eigentlich sehr ordentlich wenn er sich ohnehin immer
> im selben WLAN anmelden soll.

Das war noch ein überbleibsel aus früheren Versuchen.

Michael U. schrieb:
> Fallstrick: der ESP meldet WiFi
> connected sobald er wieder im WLAN ist. Wenn er die IP per DHCP bekommt,
> kann es aber passieren, daß er zu diesem noch keine IP hat. Wenn dann
> ein Zugriff startet fällt er auf die Nase. Connetion refused vom Client
> mußt Du ohnehin auswerten, wenn er nicht durchkam eben etwas warten und
> es nochmal probieren.

Das ist ein guter Hinweis. Vielen Dank.
Momentan verliere ich in solch einem Fall einfach einen Messwert. Dies 
ist für mich derzeit kein Problem.

Michael U. schrieb:
> Die Lösung habe ich letztlich im Internet irgendwo im Espressif-Forum
> gefunden und nutze die inzwischen hier überall. Besagter ESP ist seitdem
> nie wieder hängen geblieben.
> Genutzt werden die WiFi-Eventhandler und die Ticker-lib für den
> reconnect zum Wifi und zum MQTT usw.
>
> Ich muß das nachher nur mal auf das Nötige zusammenkürzen und testen.

Klingt interessant.
Ich wäre auf jeden Fall an dem zusammengekürzten Sketch interessiert.

[Stefan ⛄ F. (stefanus)]

Hallo Holger,

mit dem WLAN Empfang hatte ich auch schon mehrmals Probleme, ebenso mit 
Reflexionen, die angrenzende Bauteile zum Ausfall brachten.

Deswegen löte ich diese ESP Modul nicht mehr direkt auf die Platine. Die 
ESP-01 Module eignen sich sehr gut dazu, mit einem Stück Flachkabel 
abgesetzt zu werden. Man kann sie dann so ausrichten/montieren, dass sie 
gut funktionieren.

> Ich denke sowas zu Finden ist wirklich reiner Zufall!

Ein flexibler Aufbau hilft allerdings beim Experimentieren. Wer Funk 
kennt nimmt Kabel

und, falls ich Ergänzen darf: er baut Antennen niemals fest ein.

Es gibt glücklicherweise auch ESP-Module mit ordentlichem Steckanschluss 
für externe Antennen. Nur widerspricht das natürlich dem 
Miniaturisierungswahn ganz gewaltig.

[Michael U. (amiga)]

Hallo,

Stefanus F. schrieb:
> Es gibt glücklicherweise auch ESP-Module mit ordentlichem Steckanschluss
> für externe Antennen. Nur widerspricht das natürlich dem
> Miniaturisierungswahn ganz gewaltig.

eigentlich bin ich bei den ESP8266 mit Leiterplatten- oder 
Keramikantenne mehr positiv überrascht. Problem ist einfach, daß man die 
Unwägbarkeiten des eigenen WLAN auch innerhalb der Wohnung meist 
garnicht mitbekommt. Wenn ein YT-video auf dem Laptop mal kurz hakt ist 
das eben so, ob die Webseite mal 2s länger zum Aufbauen braucht oder ein 
Kopiervorhang über WLAN eine Denkpause einlegt, man nimmt es nicht 
weiter zur Kenntnis daß da ein Reconnect oder eine elend lange 
Latenzzeit war.

Beim ESP muß man sich notgedrungen in der eigenen Software selbst damit 
auseinandersetzen, was passiert, wenn an unpassender Stelle eben mal 
solch eine Denkpause eintritt und ein anderer Programmteil dadurch aus 
dem Tritt kommt.

Gruß aus Berlin
Michael

[Michael U. (amiga)]

Hallo,

so, ich habe das mal minimiert:

/*--------------------------------------------------
Test für WiFi Connect
--------------------------------------------------*/

#include <ESP8266WiFi.h>
#include <Ticker.h>

#define WIFI_SSID "xxxxxxxxxx"
#define WIFI_PASSWORD "xxxxxxxxxx"

// WiFi
WiFiEventHandler wifiConnectHandler;
WiFiEventHandler wifiDisconnectHandler;
Ticker wifiReconnectTimer;

void connectToWifi(void);
void onWifiConnect(const WiFiEventStationModeGotIP& event);
void onWifiDisconnect(const WiFiEventStationModeDisconnected& event);


bool ich_bin_im_wlan_flag = false;              // Flag als Kennezichen daß WLAN ok ist.

void setup()
{
  Serial.begin(115200);
  Serial.println("\r\nReset");

// Start WiFi
  wifiConnectHandler = WiFi.onStationModeGotIP(onWifiConnect);
  wifiDisconnectHandler = WiFi.onStationModeDisconnected(onWifiDisconnect);
  connectToWifi();
}

void loop()
{
  if (ich_bin_im_wlan_flag)
  {
    Serial.println("Ich bin im WLAN");   // Hier solltest Du sicher sein, daß Dein GET durchkommen sollte...
  }
  else
  {
    Serial.println("Ich bin NICHT im WLAN");
  }
  delay(1000);                           // nur damit mich die serielle Ausgabe nicht nervt...     
}

// ###############################################################
// ---------------------- WiFi-Tools ------------------------------
// ###############################################################

void connectToWifi()
{
  Serial.println("Connecting to Wi-Fi...");

  WiFi.mode(WIFI_STA);
  WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
}

//-----------------------------------------------------------

void onWifiConnect(const WiFiEventStationModeGotIP& event)
{
  ich_bin_im_wlan_flag = true;

  Serial.println("Connected to Wi-Fi.");
  Serial.println(WiFi.localIP());
}

//-----------------------------------------------------------

void onWifiDisconnect(const WiFiEventStationModeDisconnected& event)
{
  ich_bin_im_wlan_flag = false;
  
  Serial.println("Disconnected from Wi-Fi.");
  wifiReconnectTimer.once(2, connectToWifi);
}

Wenn Dein "GET" zyklisch erfolgen soll, würde ich das komplett in einen 
Ticker-callback packen. Dann kannst Du im onWifiDisconnect() einfach den 
Ticker aushängen und im onWifiConnect() wieder einhängen. Spart evtl. 
diverse Flag-Abfragen.

Gruß aus Berlin
Michael

[Holger K. (holgerkraehe)]

Michael U. schrieb:
> Hallo,
>
> so, ich habe das mal minimiert:
>
> Gruß aus Berlin
> Michael

Vielen herzlichen Dank für den Code.
Ich werde diesen einbauen.

Bisher läuft das Modul einwandfrei.

[Serg P. (svd71)]

Hallo,
Fehler ist bekannt und liegt in der Code, wo nur chinessen korrigieren 
können.
Folgendes Sketch zeingt an wie gross Heap ist

/*
  ESP8266 mDNS responder sample

  This is an example of an HTTP server that is accessible
  via http://esp8266.local URL thanks to mDNS responder.

  Instructions:
  - Update WiFi SSID and password as necessary.
  - Flash the sketch to the ESP8266 board
  - Install host software:
    - For Linux, install Avahi (http://avahi.org/).
    - For Windows, install Bonjour 
(http://www.apple.com/support/bonjour/).
    - For Mac OSX and iOS support is built in through Bonjour already.
  - Point your browser to http://esp8266.local, you should see a 
response.

*/


#include <ESP8266WiFi.h>
#include <ESP8266mDNS.h>
#include <WiFiClient.h>

const char* ssid = "CODEROPI";
const char* password = "SDFys!ccX7";

// TCP server at port 80 will respond to HTTP requests
WiFiServer server(80);

void setup(void)
{
  Serial.begin(115200);

    uint32_t realSize = ESP.getFlashChipRealSize();
    uint32_t ideSize = ESP.getFlashChipSize();
    FlashMode_t ideMode = ESP.getFlashChipMode();

    Serial.printf("Flash real id:   %08X\n", ESP.getFlashChipId());
    Serial.printf("Flash real size: %u\n\n", realSize);

    Serial.printf("Flash ide  size: %u\n", ideSize);
    Serial.printf("Flash ide speed: %u\n", ESP.getFlashChipSpeed());
    Serial.printf("Flash ide mode:  %s\n", (ideMode == FM_QIO ? "QIO" : 
ideMode == FM_QOUT ? "QOUT" : ideMode == FM_DIO ? "DIO" : ideMode == 
FM_DOUT ? "DOUT" : "UNKNOWN"));

    if(ideSize != realSize) {
        Serial.println("Flash Chip configuration wrong!\n");
    } else {
        Serial.println("Flash Chip configuration ok.\n");
    }


  //****************************

  // Connect to WiFi network
  WiFi.begin(ssid, password);
  Serial.println("");

  // Wait for connection
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  Serial.println("");
  Serial.print("Connected to ");
  Serial.println(ssid);
  Serial.print("IP address: ");
  Serial.println(WiFi.localIP());

  // Set up mDNS responder:
  // - first argument is the domain name, in this example
  //   the fully-qualified domain name is "esp8266.local"
  // - second argument is the IP address to advertise
  //   we send our IP address on the WiFi network
  if (!MDNS.begin("esp8266")) {
    Serial.println("Error setting up MDNS responder!");
    while(1) {
      delay(1000);
    }
  }
  Serial.println("mDNS responder started");

  // Start TCP (HTTP) server
  server.begin();
  Serial.println("TCP server started");

  // Add service to MDNS-SD
  MDNS.addService("http", "tcp", 80);
}

void loop(void)
{
  // Check if a client has connected
  WiFiClient client = server.available();
  if (!client) {
    return;
  }
  Serial.println("");
  Serial.println("New client");

  // Wait for data from client to become available
  while(client.connected() && !client.available()){
    delay(1);
  }

  // Read the first line of HTTP request
  String req = client.readStringUntil('\r');

  // First line of HTTP request looks like "GET /path HTTP/1.1"
  // Retrieve the "/path" part by finding the spaces
  int addr_start = req.indexOf(' ');
  int addr_end = req.indexOf(' ', addr_start + 1);
  if (addr_start == -1 || addr_end == -1) {
    Serial.print("Invalid request: ");
    Serial.println(req);
    return;
  }
  req = req.substring(addr_start + 1, addr_end);
  Serial.print("Request: ");
  Serial.println(req);
  client.flush();

  String s;
  if (req == "/")
  {
    IPAddress ip = WiFi.localIP();
    String ipStr = String(ip[0]) + '.' + String(ip[1]) + '.' + 
String(ip[2]) + '.' + String(ip[3]);
    s = "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n<!DOCTYPE 
HTML>\r\n<html>Hello from ESP8266 at ";
    s += ipStr;
    s += "<br>";
    s += String(ESP.getFreeHeap());
    s += "</html>\r\n\r\n";
    Serial.println("Sending 200");
  }
  else
  {
    s = "HTTP/1.1 404 Not Found\r\n\r\n";
    Serial.println("Sending 404");
  }
  client.print(s);

  Serial.println("Done with client");
}


Wenn Client sehr oft ruft zur Module an, Heap vergrössert bis zu crash. 
Aber mit der Pause ca. 5-10 Sek wird es gut laufen.

[Bernhard S. (b_spitzer)]

Ich musste die Erfahrung machen, dass der Board-Support in Version 2.4.1 
bei meinen ESP-12E extem häufig crashs verursacht hat. Nachdem ich auf 
die 2.4.0 RC2 zurück gewechselt habe waren die Abstürze bei 
unverändertem Code weg!