ESP RGBWW Wifi Led Controller - Firmware vbs

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

Vorheriges Thema - Nächstes Thema

vbs

Zitat von: ext23 am 12 Januar 2018, 00:01:29
Wenn ich jetzt auf der UART schaue (9600) und ein Reset mache sehe ich dort nur ein paar Zeichen Matsch, soll das so? Wenn ich jetzt auf OTA Update drücke geht das Fenster auf und OTA - updating steht da, auch nach 10 Minuten noch. Die Stromstärke steigt ab und an mal an zwischen 20 und 30 mA. Auf der UART kommt keinerlei Ausgabe. Rufe ich den URL neu auf steht nur "OTA in progress" da.
Also erstmal: ich versteh es auch nicht :(

Ein paar Punkte:
- Baudrate 9600 ist falsch, du brauchst 115200,8,N,1
- du sagtest ja mal, dass du zwei Controller hast. Ist das bei beiden identisch so? Wäre interessant zu wissen, ob "nur" einer der Controller in einen "exotischen" Zustand gekommen ist oder ob das irgendwie System hat
- du flasht jetzt auch mit der Kommandozeile, die ich neulich mal gepostet hatte, oder? Falls nicht, dann das bitte mal probieren. Ich sage nciht, dass das der einzig richtige Weg ist, aber bei dem Befehl weiß ich einfach, dass er prinzipiell funktioniert
- flashe bitte mal die FW von hier https://forum.fhem.de/index.php/topic,70738.msg746407.html#msg746407. Die hat Debug-Ausgaben. Wenn du die drauf hast, dann bitte mal OTA starten und den seriellen Output posten.
- Interessant wären auch die HTTP-Antworten von der Webseite während da "OTA in progress" steht. Das machen wir dann mal im Anschluss...

Dann sehen wir weiter...

ext23

OK, dann eben 115200, hatte weiter vorne was von 9600 gelesen. Aber egal, irgendwie scheint TeraTerm ein Problem zu haben, ich sehe nur Matsch und wenn ich verbunden bin hängt der ESP fest. Das erklärt warum ich so ein Verhalten hatte das nichts ging. Aber ok, ich hab jetzt den Serial Monitor der Arduino IDE genommen, das klappt auch und ich sehe jetzt was. Ich weiß nicht warum sich TeraTerm nicht mit dem ESP verträgt, alle andere Verbindung liefen damit bis jetzt immer und besser als mit Putty, komisch.

Geflashed habe ich jetzt wieder mit dem Windows GUI Tool.

Im Anhang die Debug Ausgabe beim OTA, der dreht irgendwie im Loop... musst mal schauen.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

vbs

Erste Vermutung: der Controller kann die Firmware-Files nicht runterladen und hängt. Denk bitte nochmal scharf nach, ob du irgendwas im Router o.ä. laufen hast, was da Probleme machen könnte (Firewall, MAC-Filter, DNS-Filter, Routen usw.). Sollte natürlich trotzdem nicht zu so einem Zustand kommen.
Was du da als Loop siehst, ist sehr wahrscheinlich der Webclient der zyklisch nachfragt, ob das Update fertig ist.

Ich baue nachher nochmal ein paar mehr Logausgaben ein, um das noch stärker einzugrenzen.

ext23

Naja an der Firewall sollte es nicht liegen. Das json file kann er ja auch ziehen. Protokoll ist doch immer gleich, Port auch. Ich sehe auch nicht das irgend etwas geblockt wird. mhhh

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

vbs

Zitat von: ext23 am 12 Januar 2018, 17:34:45
Naja an der Firewall sollte es nicht liegen. Das json file kann er ja auch ziehen. Protokoll ist doch immer gleich, Port auch. Ich sehe auch nicht das irgend etwas geblockt wird. mhhh
Also wie ich es drehe und wende, für mich sieht es so aus, als könne der Controller zwar eine HTTP-Verbindung aufbauen, aber dann kommen keine Daten durch. Und nein, der Controller hat das version.json nicht runtergeladen. Das macht der Webclient, also dein Browser, und schickt dann den Inhalt an den Controller.

Im Anhang nochmal ein FW mit mehr Logausgaben, aber ich bin mir einigermaßen sicher, dass dort auch nur zu sehen sein wird, dass eine Verbindung zu Stande kommt, aber dann keine Daten eintreffen.

Ist deine Infrastruktur irgendwie besonders? Proxy? Oder einfach ein Wald&Wiesen-Consumer-Router?

Du kannst mal probieren, bei dir im Netzwerk lokal einen HTTP-Server laufen zu lassen und von dort zu updaten. Mal sehen, was da passiert.

Oder mal den Controller über einen Hotspot auf deinem Handy ein Update versuchen lassen. Also über eine völlig andere Verbindung ins Inet.

Hab sonst leider keine gute Idee, sorry :( Ich tippe auf Netzwerk...

ext23

Zitat von: vbs am 12 Januar 2018, 21:26:43
Also wie ich es drehe und wende, für mich sieht es so aus, als könne der Controller zwar eine HTTP-Verbindung aufbauen, aber dann kommen keine Daten durch. Und nein, der Controller hat das version.json nicht runtergeladen. Das macht der Webclient, also dein Browser, und schickt dann den Inhalt an den Controller.

Achso, naja dann sieht die Sache schon ganz anders aus. Da ich keine IP sehe, hier ist nur alles 0.0.0.0 kann es natürlich sein, das ihm dann der DNS fehlt. Ich dachte das json zieht sich der Controller. Mhh das sollte man aber mal ändern dann, bzw. ein Fehler ausspucken.

Und nein ich habe kein Standard Netzwerk ;-)

Ich schau mal im DHCP was ich da für ein misst eingestellt habe.
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

vbs

Man sieht in deinem Log, dass er DNS hat, kann daran eigentl. niht liegen:
DNS record found: rgbww.dronezone.de = 151.101.13.147

Bin voll bei dir, dass es eine Fehlermeldung geben sollte. Leider nicht so einfach, da er offenbar erfolgreich eine Verbindung aufbaut, aber dann keine Daten kommen. Also die Datenübertragung ist unendlich langsam ^^
Evlt. könnte man einen Mechanismus bauen, der das Update abbricht, wenn es nicht nach 5 Minuten oder so zu einem Ergebnis gekommen ist... finde ich aber auch nicht unbedingt super schön.

ext23

#472
Boa danke jetzt geht es, voll drauf verlassen, dass es nicht am DHCP liegen kann. Das ging über den Transparenten Proxy, da habe ich mich bei der GW IP vertan. Jetzt geht es auch.

Aber mit der seriellen gibt es ein paar Probleme, der bootet öfters nicht richtig wenn die serielle vorm Reset verbunden ist. Aber das liegt vermutlich am DTR der auf dem Board ja mit dem gpio0 verbunden ist. Sollte man natürlich nicht machen ;-)

Puh so haben wa das auch geklärt. Naja also ein paar mehr Informationen wären schon ganz gut auf der Seite, so für Deppen wie mich.

Also hier das meine ich mit 0.0.0.0, FHEM zeigt da leider nichts:
config-network-connection-gateway
0.0.0.0
2018-01-12 22:05:42
config-network-connection-ip
0.0.0.0
2018-01-12 22:05:42
config-network-connection-netmask
0.0.0.0
2018-01-12 22:05:42

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

vbs

Ja, das ist die statische Netzwerk-Konfiguration des Controllers, also wenn man kein DHCP benutzt (config-network-connection-dhcp). Ist aber kein Rückkanal für die aktuelle vergebene DHCP-Config. Wäre evtl. aber auch nett zu haben...

AlexSchei

Moin

@Shojo
Zitat von: Shojo am 11 Januar 2018, 21:28:58
MQTT lässt sich aktuell nur über das FHEM Modul EspLedController konfigurieren.

Ich hab es geschafft. DANKE!  War etwas knifflig, da ich keine Anleitung gefunden hatte.
Set devicename config config-network-mqtt-enabled 1

Jetzt ergibt sich daraus für mich eine weitere Frage:

Als color master sendet der Controller kontinuierlich einen String. Wenn ich den Controller auf color slave setze, und ich den selben String per MQTT Client dann an den Controller sende, passiert nichts. Kann ich den Controller irgendwie über MQTT steuern? Ohne FHEM. Quasi als Slave. Und den command String direkt senden. Geht sowas? Oder über einen anderen Weg?


Gruß Alex

Intel Nuc mit Proxmox — KNX

vbs

Hast du die Beschreibung schon gesehen?
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#direct-color-sychronization

Ansonsten geht das theoretisch. Du musst Slave aktivieren, und vor allem auch color_slave_topic konfigurieren. Und an das Topic dann die Farb-Befehle schicken. Hab es aber ehrlich gesagt länger nicht getestet, da ich es nur begrenzt sinnvoll finde. Was genau hast du vor? Ich denke es ist meist sinnvoller, den cmd-Sync zu verwenden:
https://github.com/verybadsoldier/esp_rgbww_firmware/wiki#command-synchronization

AlexSchei

Moin!
ich schreibe grad eine kleine Anwendung die ich auf einem alten (also so richtig alt) laufen lassen will, wo einfach nur ein paar buttons drauf sind. diese sollen per MQTT Sachen steuern. Das ist die Idee dahinter.

Ich hab es jetzt zum Laufen bekommen. Soweit ich das nachvollziehen kann ist wichtig den Topic bei den MQTT Einstellungen anders als den Standard einzustellen. Seit ich den geändert habe, geht es.

Richtig genial! Danke für die Mühe @vbs

Gruß
Alex
Intel Nuc mit Proxmox — KNX

vbs

Gibt jetzt in FHEM Readings zum aktuellen Netzwerkstatus:
info-connection-dhcp        1
info-connection-gateway     192.168.2.1
info-connection-ip_address  192.168.2.22
info-connection-mac         5ccf7f8c0c03
info-connection-netmask     255.255.255.0
info-connection-ssid        myWifi


@Alex:
Sehr gut! Aber das Standard-Topic muss/sollte genauso funktionieren wie jedes andere. Da ist nix besonderes dran... komisch...

vbs

Shojo war so gut, sich mal die WebApp vorzunehmen und dort ein paar Sachen auf den neuesten Stand zu bringen (besten Dank)!

Ich hab daraus eine vbs26b gemacht:

20.01.2018 - vbs26b
- webapp updated to shojo3 (thanks
- improved stability
- uptime only updated every 60 seconds


Hauptaugenmerk liegt auf dem geänderten Webinterface und auf Stabilität. Ich hatte mit den letzten Versionen beobachtet, dass sich die Controller mal alle paar Stunden/Tage rebootet haben. Wäre klasse, wenn ihr verstärkt drauf achten könntet, ob das weiterhin passiert (zu sehen am uptime-Reading, oder am Zeitstempel des state-Readings).

Achso wenn sich der Controller jetzt von HTTP-Requests überlastet fühlt, dann beantwortet er Requests direkt mit 429 (too many requests) und "Retry-After"-Header, der den Client auffordert, den Request in x Sekunden zu wiederholen. Die neuste Version vom FHEM-Modul beachtet diesen Header und verhält sich entsprechend. Das ganze ist eine Maßnahme, um Crashes zu verhindern.

Shojo

#479
So, habe gestern mal bissel mit dem Controllern gespielt:

https://youtu.be/_axMsUs4uPE

set WZ.Licht.RGB.Fensterfront hue +90 0.1 r;
set WZ.Licht.RGB.Fensterfront sat 50 0.1 qr;
set WZ.Licht.RGB.Fensterfront sat 100 0.1 qr;


Da hast sich glatt FHEM verabschiedet...
Kann es sein das der Controller das FHEM Modul "geddost" hat?

FHEM auf: Shuttle PC (x64) (Docker)
Bridge: SignalESP 433mHz, ConBee (deCONZ in Docker)
Rest: ESP8266, SONOFF, Sonos, Echo Dot, Xiaomi Vacuum (root), ESP RGBWW Wifi Led Controller, Node-RED, LEDMatrix, Pixel It