ESP RGBWW Wifi Led Controller - Firmware vbs

[RaspiLED]

Hi,
Vielleicht erst eine statische Seite ,,Check WLAN Güte..." dann ein reload der js?
Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...

[pjakobs]

@vbs: ich kann jetzt zwar mit einem Button die LED an und ausschalten, aber verstanden hab ich das noch nicht.
a) kann ich festlegen, was die einzelnen Buttons tun? (sinnvoll wäre an/aus, dim up, dim down)?
b) erzeugen die Buttons Events, die ich im fhem abfangen kann? MQTT?

pj

[pjakobs]

Mal eine Noobie Frage zur Sicherheit:

Nach meinem Verständnis hat der ESP interne Pull-Ups an den GPIO-Pins (die ich in der Firmware auch aktiviert habe). Daher meine ich, dass man an dem GPIO für den Taster-Betrieb keinen einen 10k-Widerstand zusätzlich hängen muss. Ist das so korrekt oder braucht man den externen Pull-Up trotzdem?

EDIT:
Beim Entwickeln hatte ich keinen externen Widerstand dran und immer nur den Pin per Jumper-Kabel auf GND gezogen und es hatte funktioniert.

In den Controllern aus meinem / Patricks Design liegen GPIO0 und GPIO16 ja jeweils auf den Tastern für PRG und CLR und sind über 10k HIGH gezogen. Der GPIO2 ist auch über 10k auf HIGH, allerdings gibt es hier halt keinen Taster.
Laut Espressif Forum liegt der Wert der internen Pullups zwischen 30 und 100kOhm, was also zusammen mit den externen 10k Widerständen mindestens 7,5kOhm oder einen Strom von 440µA pro Pin ergibt.

Damit der Controller funktioniert darf keiner der GPIOs beim Start auf GND gezogen sein! (es sei denn, der ESP soll neu geflasht werden, dann gilt natürich PRG->GND)

die RGBWWCW Ausgänge haben übrigens 10k Pulldowns, da wäre es kontraproduktiv, die internen Pullups einzuschalten.
Ich kann auf die Schnelle nicht herausfinden, welche Treiber-Topologie Espressif gewählt hat, aber da sie sowohl für sink als auch für source einen maximalen Strom von 12mA angeben und der Ausgang auf High Impedance gesetzt werden kann, gehe ich von einem push/pull (Totem Pole) Output aus, so dass man sich im Betrieb die pullup/pulldown Widerstände sogar komplett sparen könnte.

pj

[vbs]

Wir haben ja in der Sammelbestellung einige Fälle, in der statt der Webapp nur eine leere Seite gezeigt wird. Wenn ich mir das mit dem Chrome Debugger ansehe, dann sind es immer app.min.css und app.min.js, die, meist mit einem "content length mismatch" nicht geladen werden können.

Wo siehst du den Fehler bzw. wer meldet den? Geht es um einen bestimmten Browser? Bin noch nicht so sicher, ob dass wirklich an der WLAN-Verbindung liegt. Da würde ich eigentlich ein anderes Fehlerbild erwarten. Kannst du einen tcpdump bereit stellen?

[pjakobs]

gerade arbeite ich dran!

[ohhh, Wireshark 3!]

so wie ich das sehe, geht da mindestens ein Paket verloren (59516) aber das wird dennoch ACK'd, der Server wiederholt das Paket und schickt danach ein [FIN]

Vielleicht hat der sming webserver / die http Implementation ein Problem mit Retransmits?

pj

[edit] noch ein zweites pcap File angehängt

[vbs]

Danke, das ist gut. Muss ich mir mal in Ruhe ansehen wenn Zeit ist.

Vielleicht hat der sming webserver / die http Implementation ein Problem mit Retransmits?

Hm, HTTP arbeitet eigentlich da drüber. Betrifft wenn dann den TCP/IP Stack im Sming. Soweit ich weiß, wird LWIP eingesetzt (https://savannah.nongnu.org/projects/lwip/). Ist eigentlich recht verbreitet, darum würde es mich eher wundern, wenn es da einen so gravierenden Bug gäbe im Retransmission-Handling. Aber natürlich trotzdem möglich.
Um welche Software-Version geht es eigentlich?

[vbs]

@vbs: ich kann jetzt zwar mit einem Button die LED an und ausschalten, aber verstanden hab ich das noch nicht.
a) kann ich festlegen, was die einzelnen Buttons tun? (sinnvoll wäre an/aus, dim up, dim down)?
b) erzeugen die Buttons Events, die ich im fhem abfangen kann? MQTT?

Genau, leider geht nur toggle.

[pjakobs]

Danke, das ist gut. Muss ich mir mal in Ruhe ansehen wenn Zeit ist.
Hm, HTTP arbeitet eigentlich da drüber. Betrifft wenn dann den TCP/IP Stack im Sming. Soweit ich weiß, wird LWIP eingesetzt (https://savannah.nongnu.org/projects/lwip/). Ist eigentlich recht verbreitet, darum würde es mich eher wundern, wenn es da einen so gravierenden Bug gäbe im Retransmission-Handling. Aber natürlich trotzdem möglich.
Um welche Software-Version geht es eigentlich?

könnte ich mir aber gut vorstellen.
Vor vielen Jahren hatten wir unter NetWare (ich hab lang für Novell gearbeitet) mal einen Bug im tcp retransmit code, dessen Ursache darin lag, dass die Entwickler Speicher sparen wollten. Will sagen: gut möglich, dass der tcp Code nur eine kleine Anzahl Segmente puffert und dann verwirft und beim zweiten Retransmit einfach die Daten nicht mehr hat und deshalb einen RST schickt?
Die Ebene weiß ja nichts mehr von der Datei, aus der die Daten neu gelesen werden könnten.

pj

[update] das hier sieht sehr ähnlich aus (retransmit und double ACK) http://lwip.100.n7.nabble.com/TCP-spurious-Retransmission-and-Dup-Ack-issue-td28322.html

[vbs]

Vor vielen Jahren hatten wir unter NetWare (ich hab lang für Novell gearbeitet) mal einen Bug im tcp retransmit code, dessen Ursache darin lag, dass die Entwickler Speicher sparen wollten. Will sagen: gut möglich, dass der tcp Code nur eine kleine Anzahl Segmente puffert und dann verwirft und beim zweiten Retransmit einfach die Daten nicht mehr hat und deshalb einen RST schickt?
Die Ebene weiß ja nichts mehr von der Datei, aus der die Daten neu gelesen werden könnten.

Also naiv hätte ich gedacht, dass man einfach die gesendeten Pakete aus dem TCP out Buffer so lange vorhalten MUSS bis sie entsprechend mit ACK bestätigt worden sind. Wenn man sie schon vorher verwirft, hat man natürlich keine Chance auf ein Retransmit. Würde ich dann aber kaum noch Bug nennen wollen, sondern eher einen TCP-Stack ohne Retransmit Support? Aber was weiß ich schon, hab ich noch nie implementiert sowas.

Kannst du noch sagen, um welche Version es gerade geht?

[pjakobs]

Also naiv hätte ich gedacht, dass man einfach die gesendeten Pakete aus dem TCP out Buffer so lange vorhalten MUSS bis sie entsprechend mit ACK bestätigt worden sind. Wenn man sie schon vorher verwirft, hat man natürlich keine Chance auf ein Retransmit. Würde ich dann aber kaum noch Bug nennen wollen, sondern eher einen TCP-Stack ohne Retransmit Support? Aber was weiß ich schon, hab ich noch nie implementiert sowas.

Kannst du noch sagen, um welche Version es gerade geht?

Das tritt bei allen Versionen auf, von Anbeginn der Zeit bis (hier) 4.2

pj

Gesendet von meinem HTC U11 mit Tapatalk

[vbs]

Ist es richtig, dass das immer nur genau bei der initialen Inbetriebnahme auftritt jedoch nie danach noch im regulären Betrieb?

[pjakobs]

Ist es richtig, dass das immer nur genau bei der initialen Inbetriebnahme auftritt jedoch nie danach noch im regulären Betrieb?

Nein, das habe ich bei verschiedenen Controllern immer wieder erlebt. Es hängt wohl eher damit zusammen, dass die beiden Dateien (Script und CSS) so groß sind, dass eine relativ hohe statistische Wahrscheinlichkeit besteht, dass etwas verloren geht.

pj

[vbs]

Was mich am meisten wundert, ist das FIN-Flag seitens des Controllers direkt nach der Retransmission.

[pjakobs]

Was mich am meisten wundert, ist das FIN-Flag seitens des Controllers direkt nach der Retransmission.

ich schätze mal, auf der Applikationsebene sehen wir die Fehler der LwIP Schicht nicht?
LwIP scheint, was Memory Handling angeht, ziemlich mächtig zu sein, vielleicht lässt sich da was tunen? Ich weiß nicht, wie viele Buffer da angelegt sind.

pj

[vbs]

Stimme dir schon zu, dass ich das Problem auch irgendwo in der Ecke vermuten würde. Allerdings k.A. was genau.
Entweder muss man sich da in das lwip soweit selbst einarbeiten, dass man das analysieren kann oder eben das Problem so als Testfall reproduzierbar machen, dass man das entweder an Sming oder anlwip adressieren kann.