ESP RGBWW Wifi Led Controller - Firmware vbs

[micky0867]

Könntest du bitte nochmal ein list des Devices anhängen? Danke

Der Controller ist nicht in Fhem eingebunden.
Brauchst du einen bestimmten Wert?

[pjakobs]

Hallo Forum, hallo @vbs,

soweit ich das alles mitgelesen habe, bietet die Firmware (zur Zeit) keine Möglichkeit, einen GPIO "frei" zu beschalten. Die Hardware Push Buttons gehen ja schon in die Richtung, aber die schalten ja "nur" den Controller aus, oder? Ich hätte gerne einen Ausgang, über den ich meinen LED-Stripe (via MOSFET) vom "Dauerplus" trennen kann. Wenn ich es dann noch schaffe, ihn immer dann abzuschalten, wenn die Helligkeit 0 ist, dann wäre alles perfekt.
Warum ich das machen möchte? Ich kämpfe bei meinem LED-Stripe mit nachglimmen, möchte aber keine Lösung à la Widerstand parallel schalten oder so.

Ist so etwas in absehbarer Zukunft geplant? Oder gibt es schon eine Lösung, die ich nur übersehen habe?

Gruß Rainer

Das verstehe ich nicht, wohin soll denn der LED Streifen "nachglimmen"? Wenn der Controller kein PWM macht, dann gibt es von den LED keinen Pfad zur Masse und dementsprechend kein (nach)Leuchten.
Sind da noch irgendwelche anderen Komponenten in Deiner Schaltung? Ich hab bald 20 Controller im Betrieb und fast meine gesamte Beleuchtung hier ist darüber realisiert und ich habe sowas noch nicht beobachtet.

Grundsätzlich bin ich aus zwei Gründen kein Freund davon, dem Controller hier mehr Fähigkeiten einzubauen:

• gab es schon die Frage nach diesem oder jenem Sensor. Wieviel zusätzliche Funktion bauen wir ein und haben wir dann am Ende nicht einfach ein anderes Tasmota? Ich denke, wir tun gut daran, den Controller das sein zu lassen, was er am besten kann.
• 
  in dem Moment, wo wir anfangen an den drei herausgeführten Pins zusätzliche, über einen Taster hinausgehende Hardware zu unterstützen fürchte ich, dass wir von Problemen überhäuft werden. Die drei Pins, die da zur Verfügung stehen sind GPIO2, GPIO0 und GPIO16 - alle haben zum Boot Zeitpunkt spezifische Bedeutung, ganz besonders GPIO16, der den Controller auf "Werkseinstellung" zurücksetzt. Daran irgendeine externe Schaltung, die, gewollt oder ungewollt, einen LOW Pegel herbeiführt und wir bekommen hier Fehler ohne Ende.

pj

[vbs]

Warum ich das machen möchte? Ich kämpfe bei meinem LED-Stripe mit nachglimmen, möchte aber keine Lösung à la Widerstand parallel schalten oder so.

Das ist mit ziemlicher Sicherheit ein Hardwareproblem. Ich hab hier 4 von den neuen Controllern, aber nur einen in Betrieb bisher. Bei dem ging auch erst ein Kanal nicht, den ich dann nachgelötet habe. Bei dem hatte ich danach jedenfalls auch das Problem, dass der noch geglimmt hat, auch wenn alle Kanäle aus waren. Also irgendwo fließt da offenbar ungewollter Weise noch Strom.

[vbs]

Der Controller ist nicht in Fhem eingebunden.
Brauchst du einen bestimmten Wert?

Ahh ok, nee nicht so konkret tatsächlich. Wollte nur grob vergleichen, ob ich mit einer ähnlichen Config teste. Also mehr so als Paranoidmodus ^^

Falls du die Möglichkeit hast, könntest du alternativ die Ausgabe der URL "http://<ip>/config" posten.

Ich hab mal ein paar Sachen ausprobiert bzgl. Reboot-Probleme und ich hab es evtl. etwas verbessert, aber gefühlt wird das nicht 100% helfen. Da passiert recht viel unter der Haube im SDK, worauf man nicht viel Einfluss hat.

[pjakobs]

Das ist mit ziemlicher Sicherheit ein Hardwareproblem. Ich hab hier 4 von den neuen Controllern, aber nur einen in Betrieb bisher. Bei dem ging auch erst ein Kanal nicht, den ich dann nachgelötet habe. Bei dem hatte ich danach jedenfalls auch das Problem, dass der noch geglimmt hat, auch wenn alle Kanäle aus waren. Also irgendwo fließt da offenbar ungewollter Weise noch Strom.

ah, das kann natürlich sein. Wir hatten bei der Charge, die von Elecrow gefertigt wurde (also der letzten Sammelbestellung) ein bisschen Probleme mit zu viel Lot auf den Pads des ESP12 auf der äußeren Seite. Wenn Du ein Multimeter hast, schau doch mal, ob nebeneinander liegende Pads dort zueinander kurzgeschlossen sind. Das sollten sie nicht sein.
Wenn doch, dann kommt es zu merkwürdigen Effekten.

pj

[vbs]

Der Controller ist nicht in Fhem eingebunden.
Brauchst du einen bestimmten Wert?

Ich hab die FW nochmal geupdatet. Wenn du nochmal Gelegenheit hättest zum Testen, wäre es super:
http://rgbww.dronezone.de/sming-3.9.x/version.json

Ich glaube, ich konnte mindestens eines deiner Probleme nachstellen. Bei mir verhält sich ein normaler Disconnect anders als eine MAC-Sperre. Der normale Disconnect funktioniert mit der aktuellen Version zuverlässig (bei mir). Ich teste mit einem mobilen Hotspot auf einem Android-Device, den ich dann ein- und ausschalte.

Da das Testen sicherlich zeitaufwendig ist, können wir uns gerne erstmal auf den "normalen" Disconnect konzentrieren (anstelle des MAC-Filters. Sofern es wirklich unterschiedlich ist).

(sind auch ein paar andere Bugs bzgl Sming 4.x gefixt)

[micky0867]

Der normale disconnect ist mit

Code Auswählen Erweitern


Connect an WIFI-Router, WIFI ausgeschaltet und länger aus gelassen
Nachdem der Controller seinen AP aufgespannt hat WIFI wieder eingeschaltet

abgebildet.

Der MAC-Filter ist nur auf der Fritze. Das habe ich auch nur gemacht, damit ich meine APs nicht umkonfigurieren, bzw das WiFi an der Fritze ganz abschalten muss. An der Fritze hängen etliche Clients, am Wifi-Router normalerweise keiner.

Ich werd's mal testen.

Auf Grund von einigen Anleitungen im Internet glaube ich aber, dass man den Station-Modus immer wieder aktivieren muss, weil er es sonst nach einem Timeout nie wieder von selbst probiert...


Gesendet von meinem ONEPLUS A3003 mit Tapatalk

[vbs]

Meiner Erfahrung nach klappt der Reconnect generell schon, aber ein Problem ist, dass oft (aber nicht immer) die Reconnects aufhören, wenn man deinen Wifi-Scan startet (das passiert im Zuge der AP-Aktivierung). Ich weiß nicht, ob das ein Bug oder so gewollt ist. Ich triggere jetzt jedenfalls händisch ein Connect nach dem Wifi-Scan. Kann aber nicht sagen, ob das in allen Konstellationen hilft.

[micky0867]

Meiner Erfahrung nach klappt der Reconnect generell schon, aber ein Problem ist, dass oft (aber nicht immer) die Reconnects aufhören, wenn man deinen Wifi-Scan startet (das passiert im Zuge der AP-Aktivierung). Ich weiß nicht, ob das ein Bug oder so gewollt ist. Ich triggere jetzt jedenfalls händisch ein Connect nach dem Wifi-Scan. Kann aber nicht sagen, ob das in allen Konstellationen hilft.

Cool, jetzt funktioniert es!
Man kann sehen, dass er auch im AP-Modus immer wieder einen Connect versucht und sobald er eine Verbindung hat, den AP-Modus verlässt.

Die /config (warum wird die OTA-URL immer wieder zurück gesetzt?)

Code Auswählen Erweitern


{"network":{"connection":{"dhcp":true,"ip":"0.0.0.0","netmask":"0.0.0.0","gateway":"0.0.0.0"},"ap":{"secured":false,"password":"rgbwwctrl","ssid":"RGBWW10965773"},"mqtt":{"enabled":false,"server":"mqtt.local","port":1883,"username":"","password":"","topic_base":"home/"}},"color":{"outputmode":0,"startup_color":"last","hsv":{"model":0,"red":0,"yellow":0,"green":0,"cyan":0,"blue":0,"magenta":0},"brightness":{"red":100,"green":100,"blue":100,"ww":100,"cw":100},"colortemp":{"ww":2700,"cw":6000}},"security":{"api_secured":false},"ota":{"url":"http://rgbww.dronezone.de/release/version.json"},"sync":{"clock_master_enabled":false,"clock_master_interval":30,"clock_slave_enabled":false,"clock_slave_topic":"home/led1/clock","cmd_master_enabled":false,"cmd_slave_enabled":false,"cmd_slave_topic":"home/led1/command","color_master_enabled":false,"color_master_interval_ms":0,"color_slave_enabled":false,"color_slave_topic":"home/led1/color"},"events":{"color_interval_ms":500,"color_mininterval_ms":500,"server_enabled":true,"transfin_interval_ms":1000},"general":{"device_name":"","pin_config":"13,12,14,5,4","buttons_config":"","buttons_debounce_ms":50}}


Die Version

Code Auswählen Erweitern


Firmware 4.1.1-rc1-58-gc695-dirty
Web Interface 0.3.3-shojo7
RGBWW Version 0.9.0
SMING Version 4.0.0-rc2


Das Log.
Connect an den Wifi-Router, dann dort Wifi abgeschaltet und nach einigen Minuten wieder eingeschaltet.

Code Auswählen Erweitern


connected with FRITZ!Box 7330, channel 1
dhcp client start...
ip:192.168.178.31,mask:255.255.255.0,gw:192.168.178.1
pm open,type:0 0
bcn_timout,ap_probe_send_start
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
no FRITZ!Box 7330 found, reconnect after 1s
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
mode : sta(84:0d:8e:a7:53:0d) + softAP(86:0d:8e:a7:53:0d)
add if1
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
bcn 100
scandone
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (0)
reconnect
scandone
.
.
usw.usw.usw......
.
.
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 0 (29)
reconnect
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt

connected with FRITZ!Box 7330, channel 1
dhcp client start...
ip:192.168.178.31,mask:255.255.255.0,gw:192.168.178.1
bcn 0
del if1
pm open,type:0 0
mode : sta(84:0d:8e:a7:53:0d)


Ein weiterer Test.
Der Wifi-Router ist aus, der Controller wird aus/eingeschaltet, danach wird der Wifi-Router auch eingeschaltet.
Vermutlich ist das ähnlich wie bei einem Stromausfall, der Controller ist schneller oben, als ein Wifi-Router.
Hiervon habe ich kein Log, kann aber sagen, dass es sehr lange dauert, bis ein Reconnect funktioniert.

Meine Beobachtung dazu:
Meine APs laufen auf Kanal 11 bzw. Kanal 1.
Wenn der Controller einen Connect zu einem der APs hatte und ihn wieder verliert, spannt er seinen eigenen AP unter dem zuletzt verwendeten Kanal auf.
Das ist sehr gut, weil er damit auch in der Lage ist, den ursprünglichen AP beim Scannen schnell wieder zu finden, weil sich dieser auf dem gleichen Kanal befindet.
Kann der Controller sich allerdings direkt nach einem Boot nicht mit einem AP verbinden, benutzt er standardmäßig den Kanal 7.
(https://github.com/SmingHub/Sming/blob/develop/Sming/Platform/AccessPoint.h, Zeile 60)

Daher von mir noch eine Bitte:
Es wäre super, wenn der Controller seinen AP mit dem Kanal der gespeicherten Verbindung aufspannen könnte (sofern diese Info irgendwo abgespeichert ist).


Danke Dir!
Micky

[vbs]

Ok, danke nochmal, klingt schon ganz gut.

Die /config (warum wird die OTA-URL immer wieder zurück gesetzt?)

Es gibt in der Config die Default-URL für OTA (ota->url). Kann man bei Bedarf (wie andere Parameter auch) auf eine andere URL ändern.

Meine Beobachtung dazu:
Meine APs laufen auf Kanal 11 bzw. Kanal 1.
Wenn der Controller einen Connect zu einem der APs hatte und ihn wieder verliert, spannt er seinen eigenen AP unter dem zuletzt verwendeten Kanal auf.
Das ist sehr gut, weil er damit auch in der Lage ist, den ursprünglichen AP beim Scannen schnell wieder zu finden, weil sich dieser auf dem gleichen Kanal befindet.

Hm, das ist komisch. Das ist eigentlich nicht der Fall. Du hast ja schon gesehen, dass Kanal 7 default ist laut Code und es wird auch nie ein anderer Kanal gesetzt. Ich hab es hier ausprobiert und bei mir ist mein Standard-Wifi ebenfalls Kanal 11/1. Nach dem Disconnect hat der Controller trotzdem seinen AP auf Kanal 7 aufgespannt. Bist du sicher, dass das bei dir anders war/ist?

Kann der Controller sich allerdings direkt nach einem Boot nicht mit einem AP verbinden, benutzt er standardmäßig den Kanal 7.
(https://github.com/SmingHub/Sming/blob/develop/Sming/Platform/AccessPoint.h, Zeile 60)

Daher von mir noch eine Bitte:
Es wäre super, wenn der Controller seinen AP mit dem Kanal der gespeicherten Verbindung aufspannen könnte (sofern diese Info irgendwo abgespeichert ist).

Ja, wäre schon machbar. Ich bin aber noch nicht so recht überzeugt, dass das nötig ist, muss ich gestehen. Wie lange hat denn der Reconnect gedauert und bist du sicher, dass das mit dem Kanal zusammen hängt? Ich hab es hier getestet und da ging der Reconnect sofort. Also entweder mache ich hier irgendwas anders oder es liegt evtl. doch an etwas anderem.
Also ich hab den Controller gebootet (ohne externen AP) und dann macht er irgendwann seinen AP auf (auf Kanal 7). Dann hab ich den externen AP (Kanal 1) aktiviert und der Controller verbindet sich sofort (3-4 Sek.).

[micky0867]

Es gibt in der Config die Default-URL für OTA (ota->url). Kann man bei Bedarf (wie andere Parameter auch) auf eine andere URL ändern.

Ich war mir ziemlich sicher, beim Ersatzcontroller erst die URL gespeichert und dann das Update gemacht zu haben.
Danach war die URL wieder auf dem default 
Habe gerade den anderen Controller genauso umkonfiguriert und da bleibt die URL so, wie ich sie eingestellt habe.
Keine Ahnung, wie ich das geschafft habe.

Hm, das ist komisch. Das ist eigentlich nicht der Fall. Du hast ja schon gesehen, dass Kanal 7 default ist laut Code und es wird auch nie ein anderer Kanal gesetzt. Ich hab es hier ausprobiert und bei mir ist mein Standard-Wifi ebenfalls Kanal 11/1. Nach dem Disconnect hat der Controller trotzdem seinen AP auf Kanal 7 aufgespannt. Bist du sicher, dass das bei dir anders war/ist?

Mit dem Kanal bin ich mir absolut sicher. Ich habe das mit dem Wifirouter (Lede) abgefragt.
Habe das auch mal mit der Fritze probiert, aber da war mir aufgefallen, dass die Fritze die Daten nur on demand aktualisiert und dabei immer die angemeldeten Stationen rausschmeisst.

Ich lese das auch hier so:
https://bbs.espressif.com/viewtopic.php?t=324

Und gefühlt hat es eine halbe Ewigkeit gedauert.
Mein Workaround: Ich habe den zugehörigen AP auf Kanal 7 konfiguriert 

[vbs]

Ich war mir ziemlich sicher, beim Ersatzcontroller erst die URL gespeichert und dann das Update gemacht zu haben.
Danach war die URL wieder auf dem default 
Habe gerade den anderen Controller genauso umkonfiguriert und da bleibt die URL so, wie ich sie eingestellt habe.

In einer der Versionen von letzter Woche hatte ich noch einen Bug, wodurch die Config nicht korrekt gespeichert wurde. Vielleicht hattest du so eine Variante erwischt.

Keine Ahnung, wie ich das geschafft habe.
Mit dem Kanal bin ich mir absolut sicher. Ich habe das mit dem Wifirouter (Lede) abgefragt.
Habe das auch mal mit der Fritze probiert, aber da war mir aufgefallen, dass die Fritze die Daten nur on demand aktualisiert und dabei immer die angemeldeten Stationen rausschmeisst.

Ich lese das auch hier so:
https://bbs.espressif.com/viewtopic.php?t=324

Ich habe das so verstanden, dass der Controller für den AP den gleichen Kanal wie für Station verwendet, wenn beide *gleichzeitig* verbunden sind (weil der Controller hardwaremäßig nur einen Kanal bedienen kann). Den Fall gibt es bei uns aber nie, da der AP abgeschaltet wird, sobald der Controller sich erfolgreich zum regulären AP verbunden hat. Er *versucht* zu verbinden während der AP aktiv ist, aber es ist nie beides wirklich aktiv.
Und ich hab es gerade mal getestet, indem ich das Abschalten des AP raus genommen habe:
1. Controller bootet (kein externer AP vorhanden) und schaltet dann irgendwann seinen AP ein (auf Kanal 7)
2. ich aktiviere externen AP
3. Controller verbindet sich mit externem AP auf Kanal 1
4. Durch die Modifikation schaltet er seinen AP nicht aus, aber switcht seinen AP ebenfalls zu Kanal 1 (!) <- ich denke, dass ist in der Doku gemeint

Also dass sich der Controller den Kanal der letzten erfolgreichen Verbindung speichert und dann für den AP-Modus nachnutzt, hab ich da so nicht raus gelesen und kann das auch in meinen Tests nicht bestätigen.

[micky0867]

Also dass sich der Controller den Kanal der letzten erfolgreichen Verbindung speichert und dann für den AP-Modus nachnutzt, hab ich da so nicht raus gelesen und kann das auch in meinen Tests nicht bestätigen.

Sorry, war vllt missverständlich.
Ich meine, wir haben bei Verlust einer vorhandenen Verbindung den Fall

Case 1.
(1) If user connect ESP8266 station to a router(e.g. router is in channel 6).
(2) Then set ESP8266 softAP by wifi_softap_set_config.
(3) The API may return true, but channel will always be channel 6. Because we have only one hardware channel.

wifi_softap_set_config ist letztlich die Funktion, die den Soft-AP ermöglicht.
Diese bekommt einen Kanal (7) vorgegeben, ignoriert ihn aber, weil auf der Physik bereits ein Kanal gewählt/eingestellt ist bzw. war.
Der Controller probiert ja im Falle eines Verbindungsverlustes weiter, bleibt also eigentlich im Station-Mode, damit haben wir beides gleichzeitig.
Und die API meldet true zurück, obwohl der Kanal 7 bei der Konfiguration gar nicht berücksichtigt wurde...


Im Gegensatz dazu ist ein Boot des Controllers ohne Verbindung zu einem AP zu sehen.
Da wird dann für den SoftAP erstmal 7 benutzt....bis eine Verbindung zu einem bereits konfigurierten AP hergestellt wird.
Aber dazu muss der Controller u.U. den Kanal wechseln und schmeisst damit ggf bereits angemeldetete Stationen wieder raus.

Case 2.
(1) If user set ESP8266 softAP a channel number(e.g. channel 5) by wifi_softap_set_config.
(2) Some stations connected to ESP8266 softAP.
(3) Then connect ESP8266 station to a router of which channel number is different (e.g. channel 6).
(4) ESP8266 softAP has to adjust its channel to be as same as ESP8266 station, in this case, is channel 6.
(5) So the stations that connected to ESP8266 softAP in step 2 will be disconnected because of the channel change.

Und wo ich jetzt nochmal darüber nachdenke:
Wenn der Kontroller im Fall 2 für einem Reconnect-Versuch sowieso selbstständig verschiedene Kanäle probiert, hat es auch wenig Zweck, diesen beim SoftAP vorzugeben.
Schlimmstenfalls dauert ein Reconnect einen kompletten Kanal-Zyklus oder wie auch immer das heissen mag, bzw. der Algorithmus dafür aussehen mag.

[vbs]

Sorry, war vllt missverständlich.
Ich meine, wir haben bei Verlust einer vorhandenen Verbindung den Fall
wifi_softap_set_config ist letztlich die Funktion, die den Soft-AP ermöglicht.
Diese bekommt einen Kanal (7) vorgegeben, ignoriert ihn aber, weil auf der Physik bereits ein Kanal gewählt/eingestellt ist bzw. war.

Mmn ist das hier nicht so: da der AP erst aufgemacht wird, *nachdem* die normale Verbindung verloren wurde, kann dann für den AP durchaus der im Code übergebene Kanal 7 genutzt werden. Das passt auch zu dem, was ich beim Testen sehe.

Der Controller probiert ja im Falle eines Verbindungsverlustes weiter, bleibt also eigentlich im Station-Mode, damit haben wir beides gleichzeitig.
Und die API meldet true zurück, obwohl der Kanal 7 bei der Konfiguration gar nicht berücksichtigt wurde...

Nochmal in anderen Worten:
Da der AP erst aufgespannt wird, nachdem die "normale" Verbindung verloren wurde, ist dann der AP-Modus auch nicht mehr an Kanal der vorherigen, "normalen" Verbindung gebunden. Du kannst das ja mit Wifi Analyzer Apps für Android/Windows/iOS/whatever auch recht leicht sehen, welchen Kanal der Controller-AP gerade verwendet.

Ich hoffe, wir reden nicht irgendwie aneinander vorbei.

Im Gegensatz dazu ist ein Boot des Controllers ohne Verbindung zu einem AP zu sehen.
Da wird dann für den SoftAP erstmal 7 benutzt....bis eine Verbindung zu einem bereits konfigurierten AP hergestellt wird.
Aber dazu muss der Controller u.U. den Kanal wechseln und schmeisst damit ggf bereits angemeldetete Stationen wieder raus.

Seh ich auch so (bis auf den Gegensatz).

Und wo ich jetzt nochmal darüber nachdenke:
Wenn der Kontroller im Fall 2 für einem Reconnect-Versuch sowieso selbstständig verschiedene Kanäle probiert, hat es auch wenig Zweck, diesen beim SoftAP vorzugeben.
Schlimmstenfalls dauert ein Reconnect einen kompletten Kanal-Zyklus oder wie auch immer das heissen mag, bzw. der Algorithmus dafür aussehen mag.

Ich kenne mich technisch nicht genug mit dem Wifi-Connect-Mechanismus aus, aber meinen Beobachtungen zufolge muss der Controller bei den Connect-Versuchen nicht die Kanäle "durchschalten". Da er das ständig macht, müssten doch ebenso ständig alle Clients vom AP fliegen?

EDIT:

Case 1.
(1) If user connect ESP8266 station to a router(e.g. router is in channel 6).
(2) Then set ESP8266 softAP by wifi_softap_set_config.
(3) The API may return true, but channel will always be channel 6. Because we have only one hardware channel.

Mein Punkt ist: Zwischen Schritt 1) und 2) ist ja nicht die Rede davon, dass die Verbindung aus 1) wieder verloren wird. Die haben hier wirklich beide Verbindungen gleichzeitig.

[micky0867]

Da stimmt wohl beides....obwohl es seltsam ist.
Ich habe den Wifi-Analyzer bemüht.

Den Wifi-Router habe ich jetzt doch umkonfiguriert, damit ich eine andere Umgebung habe.
Die SSID lautet esptest.

Im ersten Screenshot sieht man den Controller und den Wifi-Router zusammen auf Kanal 13.
Im zweiten sieht man den Controller auf Kanal 7.
Zwischen den beiden Screenshots liegt ca. 1 Minute.
Vermutlich wird erst der AP aktiviert und dann der Kanal gesetzt.