Announcement: there is an English version of this forum on 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
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
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.
:
Bearbeitet durch User
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.
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
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.
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
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.
:
Bearbeitet durch User
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 |
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
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.
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!
Dann hast du das sicher verstellt. Kontrolliere mal deine Voreinstellungen (Code nach dem Hochladen prüfen).
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 |
> Exception (0):
Nutze den "ESP Exception Decoder".
Dieser lässt sich in der IDE integrieren.
>> 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ü).
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.
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
Angehängte Dateien:
-
settings.png
9,94 KB, 131 Downloads
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)
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.
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
:
Bearbeitet durch User
Löte mal einen 100µF oder 220µF Elko direkt auf das Modul an VCC und GND.
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.
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
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.
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
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.
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.
:
Bearbeitet durch User
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
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
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.
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.
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!
Thread beobachten
Seitenaufteilung abschalten