NEWS
WLAN-Probleme ESP8266
-
@martinp said in WLAN-Probleme ESP8266:
@blockmove Naja, dann kann man ja gleich kabelgebundene Geräte nehmen, wenn man neben jedes Gerät einen Spezial-WLAN-Access-Point installieren soll
Ich habe zwar drei WLAN-Router im Haus, aber die Probleme treten bei allen auf...
- Fritzbox
- Huawei AX3 dual core
- Netgear 6120 (Freifunk Firmware)
(3) wäre eigentlich der Access Point der Wahl, da er nur 2 Meter vom Gerät entfernt hinter der Haus-Außenwand hängt ... Der macht aber die meisten Probleme
Also 8266 langfristig stabil an's WLAN zu bekommen ist schwierig.
Ich kann da ein Lied davon singen. Ich hab diverse WLED-Controller.
Anfangs gab's permant Probleme. Also Spannungsversorgung geändert.
Dann war's schon besser. Dann die Gehäuse umkonstruiert und die Einbaulage geändert.
Anschließend war 1,5 Jahre Ruhe. Jetzt geht's wieder los.
Ähnlich bei der Abfrage meines Gaszählers. Immer wieder Impulse verloren.
Austausch gegen nen ESP32 und Ruhe ist.
Ich werd jetzt Step by Step meine ESP8266 gegen ESP32 ausgetauscht. -
@blockmove Es wäre ja durchaus für die meisten Anwendungen auch ausreichend, wenn sich die 8266 bei WLAN-Problemen selber resetten, und danach ist alles wieder gut, aber ein Neustart ohne Stromlos machen, scheint weniger durchgreifend zu sein, als "Stecker ziehen".
Jedenfalls kriege ich dann häufig das aufgesattelte MQTT nicht wieder richtig ans Laufen ...
Werde mal schauen, was sich da anbietet, D1 Mini zu ersetzen ...
Wollte ja eigentlich sowieso eine Leiterplatte machen. Vielleicht kann ich da dann auch ein günstigeres ESP32 Modul ohne die Möglichkeit, Pfostenleisten zu montieren nutzen, und direkt auf der Leiterplatte auflöten ... -
Also ich habe bei mir mehrere VLAN laufen. Das für die Laptops, Tablets und Handys hat WPA3 (inkl. PMF weil notwendig) aktiviert. Für IoT verwende ich ein VLAN mit WPA2 und deaktiviertem PMF. Damit laufen meine ESP8266 alle stabil (tw. Tasmota und tw. EasyESP). Allerdings habe ich keine Fritz!-Box. Auf meinem Provider-Modem ist der Bridge-Mode aktiv und dahinter hängt eine USG4-Pro von UniFi samt Switches und APs.
-
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.
-
@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.
-
@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
-
@martinp
Die Verbesserung mit der neuen Firmware kann ich nicht bestätigen. -
@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.
-
@wal Bisher keine Ausfälle des WLAN zum Zoo der ESP8266 Devices - weder Tasmota noch andere Firmwares ..
Klopfe auf Holz...
-
@martinp ,
im Log der Fritzbox ist ausser den Handys die sich aus/einloggen nichts zu sehen. -
@wal Aktuell bei mir auch nicht ....
Aber eine "Verstümmelung" hat es wohl gegeben ...
Ist eine Tasmota Schaltsteckdosesonoff.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*
-
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 - [31merror[39m: javascript.0 (190703) script.js.ThermostatLogging: Freifunk-Router Ping timeout 2023-09-20 21:38:49.872 - [32minfo[39m: sonoff.0 (190752) Client [Bewaesserung] reconnected. Old secret 1694879442811_5422. New secret 1695238729865_2965 2023-09-20 21:38:56.309 - [32minfo[39m: javascript.0 (190703) script.js.ThermostatLogging: Freifunk-Router alive 2023-09-20 21:39:21.874 - [32minfo[39m: sonoff.0 (190752) Client [Bewaesserung] reconnected. Old secret 1695238729865_2965. New secret 1695238761873_1776 2023-09-20 21:41:11.923 - [32minfo[39m: sonoff.0 (190752) Client [Bewaesserung] reconnected. Old secret 1695238761873_1776. New secret 1695238871922_9382 2023-09-20 22:32:07.832 - [32minfo[39m: mqtt.0 (190737) Client [esp8266-cf6d7a] connection closed: timeout 2023-09-20 22:32:15.341 - [31merror[39m: javascript.0 (190703) script.js.Solltemperatur_Arbeitszimmer: Thermostat communication timeout fired 2023-09-20 22:32:17.098 - [32minfo[39m: mqtt.0 (190737) Client [esp8266-cf6d7a] connected with secret 1695241937097_5260 2023-09-20 22:32:18.646 - [32minfo[39m: javascript.0 (190703) script.js.Solltemperatur_Arbeitszimmer: Thermostat communication recovery 2023-09-20 22:32:18.656 - [32minfo[39m: javascript.0 (190703) script.js.Solltemperatur_Arbeitszimmer: Setze Solltemperatur "Nacht" 2023-09-20 22:32:43.801 - [33mwarn[39m: mqtt.0 (190737) Client [esp8266-cf6d7a] Message 1 deleted after 11 retries 2023-09-20 22:32:47.792 - [33mwarn[39m: 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 ...
-
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 ... -
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
-
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...
-
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... -
@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. -
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 ...
-
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 ...
-
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