HttpUtils_NonblockingGet mit ESP8266

[tgv_boost]

Servus Gemeinde,
ich habe in Verbindung mit FHEM etliche ESP8266 im Einsatz, alle mit eigenen Sketches für unterschiedliche Anwendungen. Beim Beispiel ->

Code Auswählen Erweitern

define ROT_01 notify JalousieROT:.*on {\
{ HttpUtils_NonblockingGet( { url=>"http://192.168.0.172:80/?=/Fab", incrementalTimout=>"1", callback=>sub($$$) { my ($hash, $err, $data) = @_;; {if ("$err" eq "") {Log 1, "Fab: ".("$data")}};; {if ("$err" ne "") {Log 1, "Err Fab: ".("$err") ;; {fhem("sleep 60 ;; set JalousieROT on")}} }}} )};;\
}

geht es um die Steuerung einer Gurtwickler Aussenjalousie, davon gibt es derer 7, eine andere Version steuert 4 Rohrmotoren. Das obige ,,define" hat viele ,,{}()", wobei der Rattenschwanz nach dem callback nur ins Log schreibt und im Fehlerfall alle 60 Sekunden einen neuen Versuch macht. Klappt soweit seit langer Zeit, Ausnahme, sporadisch auftretende Störungen ->

Code Auswählen Erweitern

Err Fauf: connect to http://192.168.0.172:80 timed out

Wenn ich in einem Web Browser http://192.168.0.172:80/?=/Fab absetze, tut das Ganze. Auch wenn ich FHEM neu starte, läuft wieder alles.
Das Problem wandert durch alle verbunden Devices, manchmal sind auch mehrere zur gleichen Zeit betroffen. Auch manchmal löst sich das Problem von selbst und aufgrund der eingebauten Fehlerroutine werden die Kommandos dann zwar zeitlich versetzt, aber wenigstens ausgeführt.

Seit 4 Wochen starte ich nun FHEM und meinen Router (FritzBox 7590)  jede Nacht neu, seitdem gibt's weniger Fehler, aber immer wenn ich glaub, jetzt iss gut, kommt wieder einer. FHEM läuft auf einem Raspberry Pi 3 Model B Rev 1.2 unter Buster. Update und Upgrade regelmässig gemacht. FHEM ist auf der jeweils aktuellsten Version.

Etwas kryptisch, aber dennoch, welche weiteren Infos wären hilfreich um mich in die richtige Richtung zu lotsen oder hat gar schon jemand eine Idee?
Mit bestem Gruß

[Beta-User]

oder hat gar schon jemand eine Idee?

Ja.
Immer die gleiche, wenn ich die Kombination von

etliche ESP8266

und

meinen Router (FritzBox ...

sehe: Ungeeignete Kombination...
Kannst du in vielerlei Spielarten (auch mit anderen Consumer-Routern) finden, manchmal hilft ein update des ESP-Frameworks ein wenig weiter, aber prinzipiell ist das Fazit einfach: das geht so nicht...

[betateilchen]

Das obige ,,define" hat viele ,,{}()", wobei der Rattenschwanz nach dem callback nur ins Log schreibt

Da würde ich empfehlen, den gesamten Code-Teil in eine 99_myUtils.pm auszulagern und diese Funktion im notify aufzurufen.

wenn ich die Kombination von und  sehe: Ungeeignete Kombination...

Stimmt.

Besorge Dir irgendwo eine alte Apple Airport Express (siehe Anhang) und konfiguriere dort ein eigenes WLAN für Deine ESP8266. Diese kleine Steckdosenkiste kann das sehr viel besser als die Fritzkotz. Bei mir laufen fast 30 ESP8266-basierte WLAN Steckdosen völlig problemlos in einem von dieser Airport bereitgestellten separaten WLAN. Die Steckdosen sind natürlich trotzdem im "Haupt-Netzwerk" erreichbar, keine Sorge

[tgv_boost]

vielen Dank schon mal für die Antworten ...

zum Thema FritzBox:

Wenn ich in einem Web Browser http://192.168.0.172:80/?=/Fab absetze, tut das Ganze.

. FixChannel für das 2.4GHz WLAN ist auch eingerichtet. Wenn es an der Kombination FritzBox ESP8266 liegt, warum tut dann alles wieder für geraume Zeit sobald ich FHEM neu starte?

[Wernieman]

Nur FHEM oder den FHEM-Rechner reboot?

Bei Konsumer-Produkten ist das Problem einfach die Menge der zu verwaltenden Geräte. Genau das bring häufig die Fritte aus dem tritt. Alternativ EIN RasPi (mit internem WLAN) ... das mag die Fritte auch nicht gerne ...

Habe hier deshalb für das ESP-Netzwerk ein hostapd auf dem FHEM-Server aufgesetzt .. der tut es auch. Allerdings sind dadurch die ESP nicht aus dem Heimnetz erreichbar, war aber auch Absicht (Der Admin weiß natürlich trotzdem Möglichkeiten .. aber lassen wir das). Hatte es gemacht, da ich dessen WLAN-karte nicht genutzt hatte und ich es einfach "probieren" wollte .....

[schwatter]

Ich habe auch Fritzdoof.
Bilde mir ein, nachdem ich "Unterschiedliche Benennung der Funknetze auf 2,4 und 5 GHz" aktiviert hatte, sind komische Symptome weniger geworden.
Name des WLAN-Funknetzes außerdem auf sichtbar.
IPv6 ist auch komplett deaktiviert.

edit:
Vergessen, Kanäle habe ich auch fest vergeben.
Gruß schwatter

[tgv_boost]

Nur FHEM oder den FHEM-Rechner reboot?

nur FHEM auf dem Rasp neu starten, dann tuts wieder für eine Weile

Separates 2.4GHz WLAN ist halt doof, weil ich mit der Abdeckung über die ganze Hütte wieder einige Access Points brauchen würde.
SSID ist sichtbar, obgleich ich das nicht mag. IPV6 aus

Ich sehe das Problem eigentlich nicht auf der Netzwerkseite, wie gesagt, FHEM Dienst neu starten schafft Abhilfe für eine Weile

[tobi01001]

Also ich habe meine ESP8266s (mind. 6 für LED Beleuchtung) dauerhaft im WLAN der FritzBox (im Mesh mit einer zweiten und einem 1750 Repeater).
Dazu noch (aktuell) zwei selbstgebastelte batteriebetriebene ESP32 Temperatur und Feuchtigkeitssensoren die sich nur nach dem Aufwachen kurz verbinden und innerhalb weniger ms wieder schlafen gehen.

All das läuft problemlos. 2.4 und 5 GHz Netze sind getrennt, damit sich die 5 GHz fähigen Geräte nicht in den langsamen 2.4 Kanälen tummeln...

Verstehe deine Herausforderung mit Access Points auch nicht? Die FB mit Mesh teilt die Netzwerke doch selber auf der gleichen Hardware?


Gruß,
Tobias

[tgv_boost]

Danke Tobi01001,
in dem Teil der Diskussion mit den unterschiedlichen Netzen ging es ja auch um Consumer Router am Beispiel FB. Neben einen FB basierenden WLAN noch ein anderes 2.4 GHz  Netz mit der selben Abdeckung aufzubauen, ist aber nicht verhältnismäßig.
Ich freue mich natürlich auch, das bei Dir alles funktioniert, was mir aber nur minimal weiterhilft.
Update: ohne täglichen FHEM Neustart treten die Fehlermeldungen vermehrt auf je länger FHEM läuft, mit täglichem Neustart gibt es derzeit keine Fehler.
mit bestem Gruß

[Wernieman]

Mich wundert, das ein reiner fhem-neustat das problem für einige zeit löst .. wie sieht der Speicher aus? Vor allem wenn FHEM einige Zeit gelaufen ist?

[tgv_boost]

Speicher schaut für mich momentan völlig unspektakulär aus und ist auch nach längerer FHEM Laufzeit nicht wirklich viel anders. System ist nicht ausgelastet und zu jeder Zeit reaktiv

Code Auswählen Erweitern

top - 09:22:30 up 7 days, 12:54,  1 user,  load average: 0,47, 0,29, 0,24
Tasks: 136 total,   1 running, 135 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2,9 us,  0,3 sy,  0,0 ni, 96,6 id,  0,0 wa,  0,0 hi,  0,1 si,  0,0 st
MiB Mem :    926,1 total,     57,9 free,    160,8 used,    707,4 buff/cache
MiB Swap:    100,0 total,     49,1 free,     50,9 used.    682,5 avail Mem

Code Auswählen Erweitern

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
14072 fhem      20   0   77724  68924   7316 S   9,9   7,3  44:09.97 perl
  563 root      20   0   37904   7380   5644 S   1,3   0,8 205:25.38 python
21143 root      20   0       0      0      0 I   0,7   0,0   0:06.74 kworker/u8:1-brcmf_wq/mmc1:0001:1
  414 avahi     20   0    6716   3140   2548 S   0,3   0,3   4:10.32 avahi-daemon
14131 fhem      20   0  164236  55284  33360 S   0,3   5,8   0:28.68 node /usr/local
24492 pi        20   0   12628   5012   4212 S   0,3   0,5   0:00.02 sshd
24517 pi        20   0   10564   3252   2724 R   0,3   0,3   0:00.23 top
    1 root      20   0   33764   5824   4516 S   0,0   0,6  54:56.30 systemd
    2 root      20   0       0      0      0 S   0,0   0,0   0:01.12 kthreadd


[Wernieman]

Was mir mal so spontan einfällt: Hast Du die IPs für die ESP hart vergeben oder dhcp?

[tobi01001]

Danke Tobi01001,
in dem Teil der Diskussion mit den unterschiedlichen Netzen ging es ja auch um Consumer Router am Beispiel FB. Neben einen FB basierenden WLAN noch ein anderes 2.4 GHz  Netz mit der selben Abdeckung aufzubauen, ist aber nicht verhältnismäßig.
Ich freue mich natürlich auch, das bei Dir alles funktioniert, was mir aber nur minimal weiterhilft.
Update: ohne täglichen FHEM Neustart treten die Fehlermeldungen vermehrt auf je länger FHEM läuft, mit täglichem Neustart gibt es derzeit keine Fehler.
mit bestem Gruß

So war das nicht gemeint. Ich habe kein WLAN was neben dem FB basierten existiert. Fände ich dann auch etwas übertrieben. Innerhalb der FB (und derem Mesh) sind zwei Netzte aufgebaut. Eines für 2.4 und eines für 5... Und das nur mit Consumer Produkten. Alles andere finde ich ebenso unverhältnismäßig

Aber das es nach einem Fhem Restart wieder tut und über z.B. Browser nicht, scheint mir weniger am Netzt selbst zu liegen?

Hast du mal - wenn die Fehler auftreten - mit z.B. curl direkt von der RPI shell geschaut was zurückkommt? eventuell auch mal zyklisch laufen lassen und die Ergebnisse in ein File schreiben?
Könnte man parallel auch noch von einem anderen Gerät im Netz machen um zu sehen, ob es ein Netzwerk Problem ist oder irgendwo im Raspi / Fhem.

Ab und an gibt es solche Probleme bei mir, wenn das Internet nicht mag - was für eine Trennung von I-Net und local only Netzwerk-Geräten spräche...

Gruß,
Toby

[Beta-User]

Fände ich dann auch etwas übertrieben. Innerhalb der FB (und derem Mesh) sind zwei Netzte aufgebaut. Eines für 2.4 und eines für 5... Und das nur mit Consumer Produkten. Alles andere finde ich ebenso unverhältnismäßig

Bei deinen wenigen Geräten ist das alles ja noch moderat. Es gibt halt hier mit einer gewissen Regelmäßkeit immer wieder andere Leute, die mit "mein WLAN-Gedöns will nicht mehr ohne Zicken"-Meldungen auftauchen, und die Story ist immer dieselbe: Es hat funktioniert und war billig => größer ausgerollt => tut nicht mehr...

Dass insbesondere die FritzBoxen (und auch andere Router diverser Provider) anscheinend immer wieder "kleine Pakete" vergessen, verbaseln oder einfach in den Orkus werfen, ist m.E. empirisch nachgewiesen. Der Hinweis "aber wenn ich mit dem Browser das Web-Interface aufrufe, klappt das doch" wird zwar gerne als Beleg genutzt, dass das ins Reich der RTL-Gemeinde gehören würde, aber: wer suchet, der findet, und definitiv ist eine FB eben keine gute WLAN-Basis... (Das war sie schon vor dem Aufkommen dieser Massen-WLAN-IoT-Gerätschaften nicht).