ESP RGBWW Wifi Led Controller - Firmware vbs

Begonnen von vbs, 18 April 2017, 09:26:13

Vorheriges Thema - Nächstes Thema

pjakobs

Zitat von: vbs am 18 Oktober 2019, 14:09:23
Ich muss mich korrigieren: Wenn die 10 Versuche erreicht sind, dann macht er zwar den AP auf, aber im Hintergrund versucht er weiterhin sich zum normalen Wifi zu verbinden. Also eigentlich genau so, wie es Peter sich gewünscht hat.
Hmmm... Strange, irgendwas funktioniert dann bei mir nicht, denn wie schon gesagt: ich hatte eine Menge Controller, die nach einem Komplettausfall nicht wieder in's Netz laben bis ich sie wieder resettet hab.

pj

Gesendet von meinem HTC U11 mit Tapatalk


micky0867

Zitat von: vbs am 18 Oktober 2019, 14:09:23
Ich muss mich korrigieren: Wenn die 10 Versuche erreicht sind, dann macht er zwar den AP auf, aber im Hintergrund versucht er weiterhin sich zum normalen Wifi zu verbinden. Also eigentlich genau so, wie es Peter sich gewünscht hat.
Bei mir war gestern auch kurz der Strom weg und der Controller hat sich (selbst nach Stunden) nicht von alleine neu verbunden.
Da half nur aus-/einschalten.  :(

micky0867

#1112
Möglicherweise ist aber auch folgendes passiert:
Der FI war raus, alles war dunkel. FI wieder rein, alles startet....
Der Controller kommt relativ schnell hoch, ebenso der Devolo mit Wifi, aber die Fritze, die die IP-Adressen verwaltet, braucht ein wenig länger.
Der Controller hat zwar eine Wifi-Verbindung zum Devolo, aber der DHCP-Request geht ins Leere....
...wieviele Requests werden denn wie lange gesendet?

vbs

Kann ich nicht sagen. Das passiert irgendwo innerhalb des espressif SDKs. Müsste man wohl selbst untersuchen für belastbaren Aussage.

Ich bin mir recht sicher, dass der DNS Server eine Macke und hat den Controller zum Absturz bringt. Hab auch das Gefühl, dass er nicht richtig funktioniert. So wie ich den Code verstehe, sollte er jede beliebige Domain in die IP des Controllers umwandeln. Sprich: man muss nicht 192.168.4.1 eingeben, sondern kann auch irgendeinen Domain-Namen eingeben. Klappt bei mir aber irgendwie nicht.

vbs

@pjakobs @micky0867
Ich hätte da eine Idee, die evtl. bei euren Wifi-Problemen helfen könnte. Könntet ihr das bei euch testen, wenn ich damit mal eine entsprechende FW zusammen basteln würde?

micky0867


Cybers

Zitat von: Pythonf am 13 Juli 2017, 18:42:52
Ich hab bereits unter dem Original FHEM-Modul meinen Vorschlag gepostet, will den aber auch hier noch unterbringen.
Ich hab eine Möglichkeit gefunden einen 4in1 RGB + WW LED Stripe ähnlich wie bei Philips Hue in der Farbtemperatur zu variieren. Meine aktuelle Umsetung ist Farbtechnisch sicherlich nicht korrekt aber sie funktioniert. Mit ein wenig Feintuning der Kurven würde man sicherlich ein noch besseres Ergebniss erzielen. Meine LEDs haben bei 100% WW laut Hersteller 3000 K. Ich habe nun eine Kurve für die Roten LEDs die bis 2000 K auf maximale Helligkeit eingestellt werden und eine zweite Funktion, welche bis 7000K alle RGB LEDs auf maximale Helligkeit einstellen. Zusätzlich wird die Helligkeit der WW LEDs von 3000 K - 7000 K um die Hälfe reduziert. Die Werte sind allerdings rein empirisch aufgenommen und entspricht somit nicht den exakten Werten. Ich verwende das ganze unter Anderem in Kombination mit den neuen Alexa Funktionen für die Farbtemperatur. Das ganze ist als cmdalias definiert.
set RGBW_.* ct .* AS {

my $R = (-1.023 * $EVTPART2) + (3*1023);
my $WW = (-0.12775 * $EVTPART2) + (1406.25);
my $RGB = ( 0.25575* $EVTPART2 ) - 767.25 ;

if ($R > 1023) {$R = 1023};
if ($WW > 1023) {$WW = 1023};
if ($RGB > 1023) {$RGB = 1023};

if ($R < 0) {$R = $RGB};
if ($WW < 0) {$WW = 0};
if ($RGB < 0) {$RGB = 0};
$R = int($R);
$WW = int($WW);
$RGB = int($RGB);

fhem("set $EVTPART0 raw $R,$RGB,$RGB,$WW,$WW");
}

Vielleicht kann damit ja jemand etwas anfangen oder es findet sich sogar ein Entwickler, welcher das in das FHEM Modul einbaut. Der Übergang zu Kaltweiß sieht m. M. nach sehr gut aus, in den wärmeren Bereich wird es bei direkter Betrachtung irgendwann etwas rotstichig.

das wäre schon eine sinnvolle Erweiterung...  :-X

Gruß, Sascha
FHEM 6.2 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

vbs

Fänd ich auch toll. Problem ist, dass niemand weiß wie (bzw. ob!) man das machen kann.

vbs

Zitat von: vbs am 21 Oktober 2019, 18:33:23
@pjakobs @micky0867
Ich hätte da eine Idee, die evtl. bei euren Wifi-Problemen helfen könnte. Könntet ihr das bei euch testen, wenn ich damit mal eine entsprechende FW zusammen basteln würde?
pjakobs hat sich bisher nicht gemeldet, aber ich hoffe mal stark, dass er das noch tut und bei sich auch noch testen kann:

Ich hab mal eine Firmware gemacht auf dem RC von der neuen Sming 4 Version. Ich hab da drin auch einen Bug gefixt, der mMn zu einem Crash führen kann, wenn die Wifi-Verbindung abbricht (z.B. der AP rebootet). Ich denke, dass könnte ein Grund sein, warum sich der Controller dann in diesen Fällen nicht korrekt wieder beim AP anmeldet.

Wäre super, wenn die Betroffenen (also pjakobs und micky0867 und evtl. weitere) das mal testen könnten, ob es in ihren Fällen das Problem behebt:
http://rgbww.dronezone.de/sming-3.9.x/version.json

Da das Ganze auf einer neuen Sming-Version basiert, ist es auch möglich, dass andere/neue Bugs reingekommen sind. Bei mir verhält sich die FW jedoch bisher unauffällig.

micky0867

Hallo,

ich habe die neue FW ausprobiert.
Es scheint, als würde kein reconnect probiert, sobald der Controller erstmal in den AP-Mode gegangen ist.
Ich sehe zumindest kein zyklisches retry.

Gruß
Micky

vbs

Hm das blöd...

Zitat von: micky0867 am 27 Oktober 2019, 21:07:32
Es scheint, als würde kein reconnect probiert, sobald der Controller erstmal in den AP-Mode gegangen ist.
Kann ich dann daraus umgekehrt schließen, dass der Reconnect bei dir zuverlässig funktioniert, wenn der Verbindungsabbruch so kurz ist, dass er noch nicht in den AP-Mode gegangen ist?

Zitat von: micky0867 am 27 Oktober 2019, 21:07:32
Ich sehe zumindest kein zyklisches retry.
Guckst du in deinem AP oder im Log des Controllers? Hast du die Möglichkeit an das Log des Controllers zu kommen und hier zu posten (115200,8,N,1)? Wobei ich mir nicht ganz sicher bin, ob die Release-FW überhaupt etwas loggt :/ Da müsste ich im Zweifel mal forschen...

War irgendwas Spezielles an deinem testen oder einfach den Controller mit einem AP verbunden und den dann für eine gewisse Zeit abgeschaltet?


pjakobs

sorry Jungs, ich kann mich an der Fehlersuche hier gerade nicht beteiligen, weil ich a) ein anderes Projekt am Wickel hab und b) meine fhem Installation gerade auf einen anderen Host umgezogen habe, und da noch ein paar Dinge nicht ganz koscher sind.

pj

micky0867

Ich habe nochmal alles mögliche getestet.
Ich habe eine Fritze mit Wifi, an der sich der Controller normalerweise per Wifi anmeldet und von der er seine IP bekommt.
Ausserdem habe ich einen Wifi-Router (mit LEDE drauf) mit der gleichen SSID und dem gleichen Passwort wie die Fritze, nur ein anderer Kanal. Dieser Router leitet DHCP-requests an die Fritze weiter.

Normaler Boot an der Fritze (Wifi-Router ist aus)

mode : sta(84:0d:8e:a7:53:0d)
add if0
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 13
cnt

connected with FRITZ!Box 7330, channel 11
dhcp client start...
ip:192.168.178.31,mask:255.255.255.0,gw:192.168.178.1
pm open,type:0 0


Im Normalbetrieb die MAC des Controllers auf der Fritze gesperrt (Wifi-Router ist aus)

state: 5 -> 2 (6c0)
rm 0
pm close 7
reconnect
state: 2 -> 0 (0)
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)
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

Danach passiert nichts mehr

Wifi-Router aktiviert, aber Ethernet abgezogen --> DHCP-Request wird nicht weitergeleitet

mode : sta(84:0d:8e:a7:53:0d)
add if0
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...
pm open,type:0 0
---> nach 5 Minuten Ethernet angestoepselt <---
ip:192.168.178.31,mask:255.255.255.0,gw:192.168.178.1

Interessant!
Ich war ja davon ausgegangen (siehe Post #1112), dass mein hängender Controller vllt im DHCP-Request festhing, weil die Fritze relativ lange braucht, um zu booten.


Controller auf Fritze gesperrt, WIFI-Router aktiviert
nach dem Boot WIFI für einige Sekunden auf WIFI-Router deaktiviert und wieder aktiviert

mode : sta(84:0d:8e:a7:53:0d)
add if0
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
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 -> 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
pm open,type:0 0

---> Reconnect nach kurzer Unterbrechung funzt


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

mode : sta(84:0d:8e:a7:53:0d)
add if0
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
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



Beide WIFIs abgeschaltet und Controller gebootet

mode : sta(84:0d:8e:a7:53:0d)
add if0
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)
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



Ich habe dem Controller immer mehrere Minuten Zeit gelassen, um sich vllt doch noch mit einem AP zu verbinden.




vbs

Ui, super! Vielen Dank für die Mühen! Werde ich mir mal in Ruhe zu Gemüte führen und versuchen rauszufinden, warum sich das bei dir anders verhält. Zu dem MAC-Filter kann ich nciht viel sagen, da mir nicht klar ist, was da technisch genau passiert, aber die Reconnects würde ich gerne verstehen.

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

dora71

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