WLAN-Probleme ESP8266

[Dieter_P]

@martinp

Ich vermute der Begriff "Anlaufstrom" hat nichts mit unserem E-Technik-Verständnis eines Einschaltstroms für induktive Lasten zu tun.

Es geht dort eher um maximale Ströme um das Drehmoment zum verstellen des Ventils aufzubringen.

Demnach das 8-10fache was man so kennt und die Absicherung darüber mit 3A ok.

[MartinP]

@dieter_p Es gibt zwei vier Varianten Normal Open/Normal Close und 230V/24V.

Soweit ich weiß, sind die ohne Stell-Motor und ziemlich einfach aufgebaut. Eine TemperaturdoseEin Dehnstoffelement, wie in einem normalen Drehthermostat sorgt für die Stellkraft auf das Ventil. Die Reaktion wird durch Aufheizen des Dehnstoffelements mit einem Heizwiderstand erreicht.
https://de.wikipedia.org/wiki/Dehnstoffelement

Bei der NC-Dose führt das Aufheizen zum Öffnen des Ventils, bei der NO-Dose führt das Aufheizen zum Schließen.
Ich habe eine NC-Variante gewählt, da wird die Heizleistung des Widerstandes nicht unnötig aufgebracht, weil ja die Wärme gebraucht wird solange das Ventil geöffnet ist...

Ich vermute, man nutzt angepasste PTC Widerstände, um das Öffnen der Ventile zu beschleunigen. Die Heizen dann mit einem Anfangsstrom von 250 mA auf (60 Watt Heizleistung), und sinken dann nach der Aufheizung auf 2 W = 9 mA@230V ab, um das Ventil aufzuhalten ... Dauert trotzdem noch 3 Minuten laut Datenblatt...

Meine Erwägungen mit den Vorteilen der NC-Variante scheinen nicht mehr zu stimmen: In einem modernen Heizsystem - gerade mit Wärmepumpe - und korrektem hydraulischem Abgleich sind die Ventile eigentlich immer auf. Will man sie über Fensterkontakte getriggert gelegentlich temporär schließen, ist ein NO-Stellglied wahrscheinlich besser ...

Jedenfalls sind die Dinger mit die günstigste Möglichkeit, ein Ventil zentral anzusteuern. Kostenpunkt ca 10 € pro Stück... Ist natürlich einiges an Drumherum, bis man die aus ioBroker heraus ansteuern kann - einfachste Möglichkeit wäre eine Tasmota- oder Zigbee-Schaltsteckdose, die gleich eine Temperaturmessung erlaubt ...

[MartinP]

So, jetzt noch ein weiterer Effekt.
Angemeldet war der ESP im "Garten" WLAN.
Dies ist ein 2. Netz (mit WPA2 Verschlüsselung) auf meinem Freifunk Netz auf einem Netgear R6120 Router.
Wenn der ESP mal wieder für mindestens 15 Minuten versucht hat, sich nach einem Spannungsregler bedingten Neustart im WLAN anzumelden, war ein wenig mehr Speicher im Freifunk Router belegt.
Nach 3...14 Tagen hat sich der Router neu gestartet....

Ist wohl jetzt wirklich Zeit, die ESP Firmware und Hardware auf neue Beine zu stellen.
Wollte mir Zeit lassen, und ein paar Gimmicks einbauen, da ist ja jetzt Zeit, bis zum Herbst

Seitdem der ESP aus ist, ist der Grafana Plot des Specherverbrauchs des Freifunk Routers linealgerade.....

[MartinP]

Da die Sommerzeit das Heizen eigentlich derzeit entbehrlich machen sollte, hatte ich mir Zeit gelassen, den Thermostaten auf einen LOLIN S32 Mini umzustellen.

Jetzt ist das aber mehr oder weniger vollbracht...

Leider hat es immer noch ein paar Holperer gegeben, die ich aber hoffe, mit heutigen Codeänderungen behoben zu haben...

WLAN stand stabil in der ersten Code-Version, aber MQTT wurde nicht wieder aktiviert, wenn etwas schief gegangen ist ...

Symptom: Das Modul ließ sich anpingen, war aber über MQTT nicht zu erreichen.

void onMqttDisconnect(AsyncMqttClientDisconnectReason reason) {
  Serial.println("Disconnected from MQTT.");
  if (WiFi.isConnected()) {
    mqttReconnectTimer.once(2, connectToMqtt);
  }
  return;
  }

der mqttReconnectTimer - Aufruf fehlte aus irgendwelchen Gründen. Dadurch wurde eine klemmende Verbindung zu MQTT nicht repariert...

[MartinP]

Ich bin dem Problem auf der Fährte ...

Im Haus habe ich drei SSIDs (vier, wenn man Freifunk mitzählt), Einmal ein Mesh aus Fritzbox und 1200AX Repeater (Kabelgebunden), und dann noch ein privates WLAN mit anderer SSID auf dem Freifunk-Router Netgear R6120. Sohnemann hat in seinen Zimmer einen Huawei WLAN-Accesspoint. Der hat auch eine eigene SSID...

Nur in dem Fritzbox Mesh WLAN läuft der ESP32 stabil ... an dem zweiten WLAN des Freifunk-Routers gibt es andauernd Connect/Reconnect Sequenzen ... Möglicherweise war die Spannungsversorgung des ESP8266 doch nicht unterdimensioniert ...

Da der Freifunk-Router sich alle paar Tage neu startet, werde ich da ggfs. überlegen, eine andere Lösung für privates WLAN im Garten zu bauen ...

[MartinP]

@martinp said in WLAN-Probleme ESP8266:

Nur in dem Fritzbox Mesh WLAN läuft der ESP32 stabil ... an dem zweiten WLAN des Freifunk-Routers gibt es andauernd Connect/Reconnect Sequenzen ...

Noch eine Ergänzung: Falls es mehrere Access-Points mit gleicher SSID gibt, scannt die ESP32 Wifi - Klasse die Kanale in aufsteigender Reihenfolge, und nutzt den ersten gefundenen AP, egal wie mies die Qualität ist.
Will man das verbessern, muss man durch "SetScanMethod() und SetSortMethod()" das Standard-Verhalten überschreiben ... Ohne diese Ergänzung klemmte sich das ESP32 Modul immer an die deutlich schlechter positionierte Fritzbox (RSSI -80), statt an den im gleichen Zimmer hängenden 1200AX Repeater (RSSI -38)

void connectToWifi() {
  Serial.print("Client ");
  Serial.print(MQTT_PUB_DEV_PREFIX);
  Serial.print(" Connecting to Wi-Fi...");
  Serial.println(WIFI_SSID);
  WiFi.setScanMethod(WIFI_ALL_CHANNEL_SCAN);
  WiFi.setSortMethod(WIFI_CONNECT_AP_BY_SIGNAL);
  WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
}

[MartinP]

Deprimierenderweise scheint auch das Wifi des Lolin S32 Mini nicht viel stabiler zu sein, als das des D1 Mini von AZ Delivery...

Vor einigen Tagen verlor auch das ESP32-Modul die Wifi - Verbindung, und konnte sie nicht wieder aufbauen. Serielles Logging immer im Wechsel "Connecting to Wi-Fi..." und "Disconnected from Wi-Fi"...

Einmal die Reset-Taste auf dem Modul betätigt, und alles funktionierte wieder ...

Mir scheint, die Bibliotheken sind nicht besonders "schussfest" ...

Ich bin da etwas ratlos. Vielleicht gehe ich einfach pragmatisch an die Sache heran: Nach 10 "Disconnected From Wi-Fi" in z. B. 100 Sekunden wird ein Reboot ausgelöst ...

[haselchen]

@martinp

Einfach nur ne kurze Info zu meiner Erfahrung .
Wollte nen Repeater aufsetzen ( günstig natürlich)
Hatte nen ESP32 und nen ESP8266 zur Auswahl .
Die Leistung und das Ergebnis , da liegen Universen zwischen .
Der 8266 ist komplett abgekackt.
Da war nix möglich . Die App hat nichtmal die Geschwindigkeit messen können.
Der ESP32 läuft stabil und kann mehrere Clienten verlustfrei bedienen.

[wendy2702]

Habe ein Unifi Wifi Netz und auch so meine Probleme mit ESP8266 und WLAN. Egal ob Tasmota, ESPhome, ESPeasy

Habe aber auch einige andere Tasmota devices und dann mal verglichen.

Die einzelnen 8266 laufen bei mir im WLAN mit der aktuellen Tasmota Version immer nur für einige Minuten. Dann ist die Verbindung weg und ich muss neustarten. Verhalten ist mit einem ESP32 besser und stabiler aber auch die verlieren nach einiger Zeit die Verbindung.

Dann mal geschaut welche Tasmota Version auf den fertig gekauften und bereits geflashten Produkten läuft und da bin ich bei 13.1.0 Diese sind alle dauerhaft und Stabil mit dem WLAN verbunden.

Also mal einen 8266 und einen ESP32 mit der älteren Tasmota bespielt und siehe da. Der 8266 ist stabil im Netz bringt nur häufig CRC fehler für den angeschlossenen Sensor. Der ESP32 läuft seit Tagen stabil und bringt mit dem gleichen Sensor keinen einzigen Fehler.

[MartinP]

@haselchen Es ist die Frage, welche Rolle die CPU, und welche das "Drumherum" auf der kleinen Leiterplatte spielt ...

Auf den meisten WLAN-Steckdosen, die mit Tasmota geflasht werden können arbeitet ein ESB8266 - und da hört man wenig von instabilem WLAN ...

Ich habe ja die Schaltung ursprünglich auf einem D1Mini aufgebaut, und nutzte vom D1Mini die Ports

D1 (Pin 14)-> Stellantrieb Heizkörper
D2 (Pin 13)<-Fensterkontakt (noch nicht implementiert)
D4 (Pin 11)-> PWM Heizkörperlüfter
D5 (Pin 4)<-> OneWire Bus

Um auf meiner Leiterplatte keine Änderungen vornehmen zu müssen werden beim Lolin S2 Mini folgende GPIOs verwendet (Pinnummern der äußeren Reihe wie beim D1 Mini gezählt)

GPIO35 (Pin 14)-> Stellantrieb Heizkörper
GPIO33 (Pin 13)<-Fensterkontakt (noch nicht implementiert)
GPIO16 (Pin 11)-> PWM Heizkörperlüfter
GPIO7 (Pin 4)<-> OneWire Bus

In EINEM der Blogs zu dem S2 Mini habe ich gelesen, dass GPIO 35 und -33 nicht als Ausgang genutzt werden dürften - https://draeger-it.blog/vergleich-wemos-d1-mini-mit-lolin-s2-mini/

Die Pins 34, 35, 36 & 39 am Lolin S2 mini können nur als Input Pin dienen!

Er meint wohl die GPIO...

Aber diesen Hinweis habe ich nirgendwo sonst gefunden, und ihn deshalb nicht ernst genommen. Vielleicht ist das aber ein Problem ...

EDIT: Hier im ESP32 WROOM 32 Datasheet findet man einen Hinweis ... der wird aber im Lolin S2 mini nicht eingesetzt:

https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32_datasheet_en.pdf

Diese Einschränkung gibt es beim ESP32-S2 nicht

https://www.espressif.com/sites/default/files/documentation/esp32-s2_datasheet_en.pdf

[MartinP]

@martinp said in WLAN-Probleme ESP8266:

Ich bin da etwas ratlos. Vielleicht gehe ich einfach pragmatisch an die Sache heran: Nach 10 "Disconnected From Wi-Fi" in z. B. 100 Sekunden wird ein Reboot ausgelöst ...

So, auch diese Änderung habe ich eingebaut... Die Hauptschleife läuft in einem 10 Sekunden-Takt (Temperatur auslesen, Berechnungen ausführen, Ventil+Lüfter ansteuern). Wenn 24 Mal in Folge MQTT und WLAN (eins oder beide) nicht "up" sind, wird ein Reboot gemacht ...

Danach gab es aber weiterhin Probleme. Habe dann den Verdacht gehabt, dass ein mqttClient.publish(...) bei nicht etablierter Verbindung irgendwie durchdringt, also nicht abgefragt wird, ob überhaupt eine Verbindung aufgebaut ist...
Nun alle publish-Aufrufe in eine connected Abfrage gepackt:

  if (mqttClient.connected()) {
    uint16_t packetIdPub1 = mqttClient.publish((MQTT_PUB_ACTOR_PREFIX + MQTT_PUB_FANACT_SUFFIX).c_str(), 1, true, String(help).c_str());                            
    delay(10);
    packetIdPub1 = mqttClient.publish((MQTT_PUB_ACTOR_PREFIX + MQTT_PUB_VALVE_SUFFIX).c_str(), 1, true, ventState ? "1" : "0");                            
    delay(10);
  }

[MartinP]

Neue Nachrichten ...

heute an der iobroker Installation gebastelt, und mehrere Neustarts gemacht ...

Dabei kamen wieder altbekannte Nachrichten in Endlosschleife:

2024-09-16 14:00:15.781  - warn: mqtt.0 (498) Client [esp32-e0624b304ec0] Message 5 deleted after 11 retries

2024-09-16 14:00:17.792  - warn: mqtt.0 (498) Client [esp32-e0624b304ec0] Message 5 deleted after 11 retries

2024-09-16 14:00:19.783  - warn: mqtt.0 (498) Client [esp32-e0624b304ec0] Message 5 deleted after 11 retries

2024-09-16 14:00:21.782  - warn: mqtt.0 (498) Client [esp32-e0624b304ec0] Message 5 deleted after 11 retries

2024-09-16 14:00:22.567  - info: mqtt.0 (498) Client [esp32-e0624b304ec0] connection closed: closed

2024-09-16 14:00:31.955  - info: mqtt.0 (498) Client [esp32-e0624b304ec0] connected with secret 1726488031944_3480

2024-09-16 14:00:31.974  - info: mqtt.0 (498) Client [esp32-e0624b304ec0] Received pubrec on esp32-e0624b304ec0 for unknown messageId 1

2024-09-16 14:00:59.831  - warn: mqtt.0 (498) Client [esp32-e0624b304ec0] Message 5 deleted after 11 retries

2024-09-16 14:01:05.833  - warn: mqtt.0 (498) Client [esp32-e0624b304ec0] Message 5 deleted after 11 retries

2024-09-16 14:01:09.833  - warn: mqtt.0 (498) Client [esp32-e0624b304ec0] Message 5 deleted after 11 retries

2024-09-16 14:01:11.835  - warn: mqtt.0 (498) Client [esp32-e0624b304ec0] Message 5 deleted after 11 retries

2024-09-16 14:01:11.836  - warn: mqtt.0 (498) Client [esp32-e0624b304ec0] Message 5 deleted after 11 retries

2024-09-16 14:01:12.577  - info: mqtt.0 (498) Client [esp32-e0624b304ec0] connection closed: closed

2024-09-16 14:01:21.946  - info: mqtt.0 (498) Client [esp32-e0624b304ec0] connected with secret 1726488081946_210

2024-09-16 14:01:21.953  - info: mqtt.0 (498) Client [esp32-e0624b304ec0] Received pubrec on esp32-e0624b304ec0 for unknown messageId 1

Bisher habe ich in diesen Situation immer den ESP32 MQTT-Client so lange neu gestartet (Reset-Taster, Stromlos machen), bis die Messages ausblieben ...

Diesmal habe ich etwas anderes probiert, und den MQTT Server/Client Adapter neu gestartet => erster Versuch hat das Problem behoben!

Ist der MQTTClient/Server-Adapter ggfs. etwas zickig, und das der Grund dafür, dass viele User zwischen iobroker und ihre MQTT Geräte einen Mosquitto Server klemmen, und dann mit dem MQTT-Client-Adapter arbeiten?

Abgesehen davon, dass dieses Problem ärgerlich ist, ist es durchaus positiv, dass es eine Lösung gibt, die das Problem im ersten Anlauf heilt, und "aus der Ferne" ausgelöst werden kann (kein Reset-Taster in einem schwer erreichbaren ESP32 betätigen...)

[Blockmove]

@martinp said in WLAN-Probleme ESP8266:

Ist der MQTTClient/Server-Adapter ggfs. etwas zickig, und das der Grund dafür, dass viele User zwischen iobroker und ihre MQTT Geräte einen Mosquitto Server klemmen, und dann mit dem MQTT-Client-Adapter arbeiten?

Wenn du viele MQTT-Teilnehmer hast, dann legt dir halt auch der ioBroker MQTT-Broker sehr viele Datenpunkte an. Wenn man in ioBroker nur den Client hat, dann kannst du halt nur gezielt die Topics anfordern, die du brauchst. Das war für mich der Hauptgrund für den Einsatz von Mosquitto.
Zickig würd ich jetzt den ioBroker-Adapter nicht nennen
Installier halt einfach nen Mosquitto und probier es aus. Dann kannst du zumindest das Problem weiter eingrenzen.

[MartinP]

@blockmove Derzeit ist das noch SEHR überschaubar ...

Ein paar Zigbee-Devices über Zigbee2MQTT, Frigate und eine Handvoll Tasmota - Devices ...

[BananaJoe]

@martinp wie @Blockmove schon schreibt - ich habe mit meinen inzwischen über 150 MQTT-Clients (ich finde das Protokoll einfach genial) auch auf den Mosquitto gewechselt und den MQTT-Adapter auf Client umgestellt.
Der MQTT-Adapter läuft in JavaScript und "emuliert" (vereiht mir den Begriff) einen MQTT-Broker. Ja, natürlich, er ist ein richtiger MQTT Broker. Wann ist man ein richtiger MQTT-Broker? Wenn man die Anfragen und Meldungen der Clients so beantwortet wie ein MQTT-Broker das eben so machen muss.
Der MQTT-Adapter läuft aber nun mal in JavaScript oder TypeScript - und da kann das Timing irgendwann mal ein Problem sein, zumindest wenn es viele Geräte und/oder Anfragen werden. Antwortet der z.B. nicht innerhalb der Zeitlimits, brechen die Clients die Verbindung ab und machen sofort wieder einen reconnet. Ganz schlimm wird das nach einem Neustart des Adapters bei mir, dann sind ja alle 150 Clients getrennt und wollen quasi gleichzeitig wieder eine Verbindung.
Wie Leistungsfähig der MQTT-Adapter ist hängt dann auch von deinem System ab, also CPU & Netzwerkkarte. So ein Raspberry Pi 3 über WLAN kann da nur ganz wenige Geräte, ein Intel I9 15900 für fast 1.000 Euro mit Gigabit LAN schafft da ein paar tausend mehr.

Der Mosquitto ist dagegen ein kompiliertes Programm das in C/C++ geschrieben wurde. Ist damit näher an der Hardware/Betriebssystem und schon dadurch vermutlich leistungsfähiger. Und schafft so auch auf schwachbrüstigen Systemen ein paar hundert oder tausend Clients. Und wenn der MQTT-Adapter dann als Clients mal eine halbe Sekunde länger braucht um einen Wertwechsel zu erfassen ist das dann ohne folgen.

Ich hab im MQTT-Client alle Topics abonniert, du kannst natürlich wie @Blockmove schreibt auch gezielt nur bestimmt holen.

Und auch wenn es überschaubar ist - es hängt vom Quellsystem ab und wie viele Topics deine Handvoll Geräte erzeugen bzw. wie oft diese aktualisiert werden

[MartinP]

@bananajoe Danke, das klingt schlüssig ... Frigate ist schon sehr schwatzhaft, was Topics angeht ...
(13 Ordner unter einem Kamera-Knoten... da habe ich auf das Zählen der Datenpunkte in den Unterordnern verzichtet ...)