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.
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:
1
pinMode(0,OUTPUT); //SCK
2
pinMode(5,INPUT); //MISO
3
pinMode(4,OUTPUT); //MOSI
4
pinMode(2,OUTPUT); //CS
5
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.
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
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.
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.
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!
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:
>> 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
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:
1
flash vendor:
2
E0h : N/A
3
flash devID:
4
4016h
5
QUAD;32Mbit
6
crystal:
7
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
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.
1
analogWrite(12,120);
2
analogWrite(14,150);
3
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.
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
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