WLAN-Probleme ESP8266

[Samson71]

@dr-bakterius sagte in WLAN-Probleme ESP8266:

Für IoT verwende ich ein VLAN mit WPA2 und deaktiviertem PMF. Damit laufen meine ESP8266 alle stabil (tw. Tasmota und tw. EasyESP).

Genau das war der Grundgedanke bei meinem Post mit dem Hinweis auf PMF auch.

@dr-bakterius sagte in WLAN-Probleme ESP8266:

Allerdings habe ich keine Fritz!-Box.

Genau das ist in diesem Fall ja das "Problem".

@dr-bakterius sagte in WLAN-Probleme ESP8266:

Auf meinem Provider-Modem ist der Bridge-Mode aktiv und dahinter hängt eine USG4-Pro von UniFi samt Switches und APs.

Bei mir ist es ne Kabelfritte, aber die reicht alles an das USG mit deaktiviertem NAT durch, incl. der Telefonie.

[MartinP]

@homoran

@homoran said in WLAN-Probleme ESP8266:

Sinnvoll kann auch sein, ein reines 2.4GHz WLAN für solche Geräte zu haben.

Wobei ESPs allgemein nicht gerade die beste Reichweite haben.

Was das Problem dann ggfs. etwas weniger leicht lösbar machen wird... Ein eigenes 2,4 GHz WLAN für die ESPs ist vielleicht doch etwas teuer, in Betrieb und Anschaffung, da man ggfs. ein zweites dichtes Netz aus APs spannen muss....

Einen zusätzlichen Access Point mit eigenem 2,4 GHz WLAN, der mit befriedigenden Signalwerten das ganze Haus abdeckt würde ich mir ja ggfs. gefallen lassen...

Aktuell hat sich aber etwas anderes geändert - die Kabel-Fritzbox ist vom Provider auf Firmware 7,57 upgedatet worden. Seitdem verlieren die ESPs die Verbindung nicht mehr (will den Tag aber nicht vor dem Abend loben, sind erst 24 Stunden) ...

Werde das mal beobachten.

Ansonsten muss ich wiederum im Notebook meines Sohnes schauen, warum der sich nur mit aktiviertem WPA3 / PMF ins Wlan einbucht ...

Erst, wenn ich WPA3 auf WPA2 zurückgeschaltet habe, besteht die Möglichkeit PMF abzuschalten ... und da protestiert derzeit der Sohn wg. Laptop

[Blockmove]

@martinp
Die Verbesserung mit der neuen Firmware kann ich nicht bestätigen.

[Wal]

@martinp ,
ich denke das du ein anderes Problem hast. Bin auch bei Vodafon und hänge mit einer 6591 mit eingeschaltetem PMF am Kabel. Habe über 10 ESP8266 und 5 ESP32 am Wifi hängen und das läuft wie geschmiert ohne Aussetzer, allerdings habe ich im Haus 3 1200AX als Mesh sitzen.
Heut Nacht wurde die 7.57 aufgespielt und habe mal im Systemlog das an/abmelden aktiviert und schaue heute Abend danach.

Wenn ich mir deinen Log vom ioBroker anschaue, sieht das fast so aus als ob der ESP beim anmelden am Adapter ins stottern kommt, weil er sehr viele Meldungen absetzen muss. Spiele einfach zum testen Tasmota auf den ESP ob er da auch die Anmeldeprobleme hat.

[MartinP]

@wal Bisher keine Ausfälle des WLAN zum Zoo der ESP8266 Devices - weder Tasmota noch andere Firmwares ..

Klopfe auf Holz...

[Wal]

@martinp ,
im Log der Fritzbox ist ausser den Handys die sich aus/einloggen nichts zu sehen.

[MartinP]

@wal Aktuell bei mir auch nicht ....

Aber eine "Verstümmelung" hat es wohl gegeben ...
Ist eine Tasmota Schaltsteckdose

sonoff.0
	2023-09-14 19:13:20.047	warn	Cannot parse data "SENSOR": _{"Time":"2023-09-14T18:13:07","ENERGY":{"TotalStartTime":"2023-07-03T14:48:02","Total":0.192,"Yesterday":0.00*

[MartinP]

Ich habe fast das Gefühl, dass hier merkwürdige Dinge passieren ...

Mit dem Abschmieren meines ESP8266 heute nacht haben auch diverse Tasmota-Steckdosen usw einen Schluckauf bekommen (sich aber wieder erholt) - selbst der Freifunk-Router, der per LAN Kabel an die Fritzbox angeschlossen war, ist kurz aus dem Tritt gekommen ...

Hier logging vom ersten Problemzeitpunkt

2023-09-20 21:38:27.205  - error: javascript.0 (190703) script.js.ThermostatLogging: Freifunk-Router Ping timeout
2023-09-20 21:38:49.872  - info: sonoff.0 (190752) Client [Bewaesserung] reconnected. Old secret 1694879442811_5422. New secret 1695238729865_2965
2023-09-20 21:38:56.309  - info: javascript.0 (190703) script.js.ThermostatLogging: Freifunk-Router alive
2023-09-20 21:39:21.874  - info: sonoff.0 (190752) Client [Bewaesserung] reconnected. Old secret 1695238729865_2965. New secret 1695238761873_1776
2023-09-20 21:41:11.923  - info: sonoff.0 (190752) Client [Bewaesserung] reconnected. Old secret 1695238761873_1776. New secret 1695238871922_9382
2023-09-20 22:32:07.832  - info: mqtt.0 (190737) Client [esp8266-cf6d7a] connection closed: timeout
2023-09-20 22:32:15.341  - error: javascript.0 (190703) script.js.Solltemperatur_Arbeitszimmer: Thermostat communication timeout fired
2023-09-20 22:32:17.098  - info: mqtt.0 (190737) Client [esp8266-cf6d7a] connected with secret 1695241937097_5260
2023-09-20 22:32:18.646  - info: javascript.0 (190703) script.js.Solltemperatur_Arbeitszimmer: Thermostat communication recovery
2023-09-20 22:32:18.656  - info: javascript.0 (190703) script.js.Solltemperatur_Arbeitszimmer: Setze Solltemperatur "Nacht"
2023-09-20 22:32:43.801  - warn: mqtt.0 (190737) Client [esp8266-cf6d7a] Message 1 deleted after 11 retries
2023-09-20 22:32:47.792  - warn: mqtt.0 (190737) Client [esp8266-cf6d7a] Message 1 deleted after 11 retries

In der Fritzbox gab es etwa 2 Minuten vorher ein Band steering für ein Android Smartphone, und einen Kanalwechsel im 5 GHz Band ... vielleicht gibt es bei Band steering oder Kanalwechsel im 5 GHz Band auch einen Stolperer im 2,4 GHz Band ...

[MartinP]

So, ich habe dem ESP eine neue Firmware verpasst, die ihn in das private WLAN meines Freifunk-Routers (NETGEAR R6100, siehe unten) leitet.

Die Einstellungen des privaten WLAN - ich vermute, dass ich damit Probleme mit WPA3/PMF ausschließen kann, um das Problem weiter einzugrenzen:

wireless.wan_radio0=wifi-iface
wireless.wan_radio0.macaddr='....................'
wireless.wan_radio0.network='wan'
wireless.wan_radio0.encryption='psk2'
wireless.wan_radio0.device='radio0'
wireless.wan_radio0.mode='ap'
wireless.wan_radio0.key='...................'
wireless.wan_radio0.disabled='0'
wireless.wan_radio0.ssid='..................'

Bisher läuft es darüber ohne Störungen - mal schauen, wie es sich entwickelt. Da hatte ich den ESP auch schon vorher angemeldet - da hat die Fritzbox aber noch Autokanal bei 2,4 GHz gehabt, und ggfs dem Freifunkrouter den Saft abgedreht ...

Hier mein Bastelprojekt, eine Outdoor-Halterung für einen Indoor-Router mit Freifunk Firmware zu bauen:

https://wiki.ffdo.de/Technik/Router/Halterungen-fuer-outdoor-router

Das Fenster links unten auf dem Bild ist im Erdgeschoss.
Der ESP 8266 ist im 1 Stock ca 2 Meter hinter der Außenwand, an der der Router hängt.
Der Router muss aber schräg nach oben noch durch die Beton-Geschossdecke funken ...

[MartinP]

So, jetzt habe ich meinen esp8266 Code etwas hemdsärmelig verlangsamt...

alle 10 Sekunden wird überhaupt nur in der Loop() etwas getan, aber dann kamen die mqttClient.publish() Aufrufe alle hintereinander.
Habe hinter jedes publish() nun ein delay(10) gesetzt, damit der MQTT-Traffic sich etwas verteilt ...

Das scheint erstmal die Situation entschärft zu haben ...

Diese Fehlermeldungen sind seitdem ausgeblieben:

mqtt.0
	2023-09-22 18:49:34.670	info	Client [esp8266-cf6d7a] connection closed: timeout
mqtt.0
	2023-09-22 18:49:14.169	warn	Client [esp8266-cf6d7a] Message 20 deleted after 11 retries
mqtt.0
	2023-09-22 18:49:12.168	warn	Client [esp8266-cf6d7a] Message 20 deleted after 11 retries
mqtt.0
	2023-09-22 18:49:10.168	warn	Client [esp8266-cf6d7a] Message 20 deleted after 11 retries
mqtt.0
	2023-09-22 18:48:42.346	info	Client [esp8266-cf6d7a] Received pubrec on esp8266-cf6d7a for unknown messageId 20
mqtt.0
	2023-09-22 18:48:42.345	info	Client [esp8266-cf6d7a] connected with secret 1695401322344_5606
mqtt.0
	2023-09-22 18:48:40.326	info	Client [esp8266-cf6d7a] connection closed: closed

Nun gibt es aber ein Problem mit der Influxdb...

influxdb.0
	2023-09-22 18:58:11.314	warn	Error in query "from(bucket: "iobroker") |> range(start: 2022-09-21T16:00:00.000Z, stop: 2023-09-21T15:59:59.999Z) |> filter(fn: (r) => r["_measurement"] == "Raumtemperatur-ArbeitszimmerMartin") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group() |> sort(columns: ["_time"], desc: true) |> limit(n: 1)": RequestTimedOutError: Request timed out

[MartinP]

Hatte noch einen "Logischen Kurzschluss" in meinem Code

Die abonnierten Sollwerte für Raumtemperatur usw werden vom ESP8266 nach dem Programmstart mit einem Default-Wert geschrieben, damit im Standalone-Betrieb bei gestörtem MQTT Broker ein gültiger Sollwert vorliegt. Das geschah nicht nur intern, sondern auch durch Publishing in Richtung MQTT...

Bei manchem Reset gewann der im ioBroker abgelegte über den MQTT-Broker gesendete Wert, manchmal der voreingestellte Wert im ESP.

Eine Handsteuerung der Temperatur am Thermostat ist eh bisher nicht vorgesehen, erst wenn das anders wird, würde eine Rückmeldung des eingestellten Sollwertes über Publishing sinnvoll werden...

[MartinP]

Hat jetzt zwei Tage ohne Reset durchgehalten. Jetzt ist es erstmalig (soweit ich es bemerkt habe) zu einem Neustart des ESP gekommen.
Der hat sich aber nicht so ausgewirkt, dass der ESP nicht mehr "hochgekommen" ist.
Wahrscheinlich war das Publishing der Soll-Werte in Richtung Broker doch schädlich...

[klassisch]

@martinp sagte in WLAN-Probleme ESP8266:

Dieses Problem habe ich vor ein paar Tagen wohl in den Griff bekommen: Direkt an der Steckerleiste des D1 Mini einen Elektrolytkondensator 1000 µF zwischen 5 V und Gnd - seitdem war Ruhe. Jedenfalls bis heute Nacht.... (Das ist mein Tipp)

Ich betreibe seit Jahren (2016 oder so?) eine Herde von ESP8266. Sowohl mit eigenen Programmen als auch mit ESPEasy und ESPHome.

Der 1000µF Elko an den 5V ist nicht schlecht und den habe ich auch bei allen ohne nachzudenken. Wichtiger sind aber die 3.3V und deshalb haben alle meine Schäfchen auch dort einen 1000µF Elko standardmäßig ohne nachzudenken.
Die laufen in der Regel sehr stabil. Manche etliche Jahre bis ein Bagger die Stromleitung zerstört hat.
Sie mögen aber kein schlechtes WLAN und auch beim Update der Fritte vermissen sie den Router und manche reagieren dann mit Neustart.
Mit den (frühen) ESP32 hatte ich eher schlechtere Erfahrungen WLAN war schwächer.
Als Netzteile verwende ich Qualitätsnetzteil mit allen erforderlichen Zertifikaten aus dem Abverkauf. Vorletzte Stromsparstufe und damit billiger Abverkauf.

[MartinP]

Schwierige Kaffeesatzleserei ...

Habe den Code des ESP-Thermostaten noch einmal angepasst, und schreibe die RSSI-Werte per MQTT in einen Datenpunkt, den ich dann über Influx nach Grafana plotten lasse ...

Inzwischen habe ich auch in der Fritzbox wieder auf WPA2 ohne PMF umgestellt. Die ist aber wohl doch zu weit weg, und mit zu vielen Hindernissen im Weg RSSI schwankt zwischen 80....85

Der Freifunk Router auf Kanal 1 mit einem zweiten privaten WLAN-Netz ließ sich auch nicht besonders gut ansprechen solange er auf Kanal 1 festgepinnt war. Zuviel Verkehr auf Kanal 1 in der direkten Nachbarschaft....

Habe jetzt entgegen der Regeln den Freifunk Router auf Kanal 6 umgestellt und den ESP in das WLAN eingebucht - jetzt ist es erstmal wieder Stabil RSSI 70 ...75 ...

Wenn das auch nicht stabil läuft, werde ich ggfs. auch noch einen weiteren Kondensator ins Auge fassen ...

Auch eine Verbesserung der Leiterplatten-Antenne wäre ggfs. noch eine Idee ... um 7 Stufen verbesserten RSSI mit einem alten Stück Koax-Kabel sind ja schon einmal etwas ...

https://www.stall.biz/project/verbesserte-wlan-konnektivitaet-mit-externen-antennen-fuer-wiffi-weatherman-und-andere-module-mit-esp8266/

[MartinP]

Auch mit der aktuellen Änderung hat der ESP8266 gestern abend wieder gezickt. Stecker ziehen hat aber auf Anhieb geholfen.
Bevor ich da noch einen Angst-Kondensator einbaue, habe ich die in günstiger Nähe zum Entwichlungsrechner platzierte Schaltung nun etwas optimaler Richtung Access-Point platziert RSSI ist dadurch von -72 auf -66 angestiegen ...

Muss dann eben etwas umplatzieren, wenn ich mal wieder eine geänderte Firmware hochladen möchte ... meine USB-Kabel sind nicht lang genug ...

[MartinP]

So, ich habe jetzt den Garten-Router etwas auf der Außenwand versetzt. Ein Stück nach oben, und etwas zur Seite, damit die Dachsparren nicht so im Weg sind...

Das hat den RSSI von -75... -65 auf -50 angehoben...
Mit einem so deutlichen Effekt habe ich nicht gerechnet!

Vorher/Nachher

[MartinP]

Hat alles nichts gebracht - wieder zwei Aussetzer für ca 14 Minuten - direkt aufeinanderfolgend ...

[Blockmove]

@dieter_p said in WLAN-Probleme ESP8266:

@martinp

Irgendwie kommt mir das ähnlich einem D1 Mini vor, der mich auch durch seltsames Verhalten wie Wifi Reconnects nicht zufrieden stimmte. Da es auch erhebliche Qualitätsunterschiede wie zB bei dem Festspannungsregler auf dem D1 Mini gibt, frag ich mich ob die Analyse erfolg haben kann.

Bin mitlerweile auf die ESP32-S2 Mini gewechselt und hier noch keine solche Effekte bisher festgestellt. Da die Pinkompatibel sind würde ein einfacher Tausch zum Test zeigen ob es an "minderwertiger" HW liegt.

Das kann ich zu 100% bestätigen.
Ich hatte 8266 Module in meinen WLED-Controllern und bei der Erfassung meines Gasverbrauchs im Einsatz. Immer wieder Probleme. Egal ob WLED, Tasmota oder selbstgeschriebene Applikation. Nachdem Austausch gegen ESP32 ist jetzt Ruhe. Seit 14 Tagen null Aussetzer bei 6 Stück.
Interessant ist, dass ich einige WLAN-Steckdosen und LED-Treiber mit 8266 habe, die problemlos seit Jahren laufen. Aber das sind ältere ESP8266-Version. Probleme machen bei mir die 12E oder F (müsste ich mal nachschauen).

Ich denke auch, dass ein Austausch gegen einen pinkompatiblen ESP32 mal nen Versuch wert ist.

[MartinP]

Drei ESP32 Module habe ich schon besorgt - mal schauen.

[Jan1]

@blockmove
Ich habe sehr viele 8266 D1 mini mit Tasmota und WLED laufen und keine WLAN Probleme. Die ESP32 S2 mini habe ich auch, wobei ich da WLED nicht zum Laufen bekomme. Also ich kann das überhaupt nicht bestätigen, dass die 32 besser als die 8266 im WLAN laufen würden.

Edit:
bevor denn wieder die Gerüchte über Mesh, AVM und SSIDs mit selbem Namen als mögliche Ursache aufkommen. Bei mit laufen beide Netze mit einer SSID auf ner Fritz im Mesh, ohne Probleme
Ja es gibt bessere HW als ne Fritz, aber für die meisten Leute reicht ne Fritz eben locker aus , wenn sie nur ein Stockwerk versorgen müssen und keine exotischen Konfigurationen benötigen.

Edit 2:
Die ESP32 S2 mini laufen doch wunderbar mit WLED, wenn man das bin selber kompiliert. Mit fertigen bins hatte ich es nicht geschafft, egal welches bin mit oder ohne Bootloader.