ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[vbs]

die controllpoints sind http. Da entstehen Latenzen durch, DNS, Connect, übertrage verarbeiten, ok melden ...

Das wäre ja aber auch gar kein Broadcast. Was du beschreibst, sind ja genau die Probleme, wegen denen ich nach der Gruppenfunktion gefragt hatte.

[herrmannj]

yepp. Hast Recht.

Hatte Deinen post zu schnell gelesen und den IST Zustand beschrieben. Relevant trotzdem ein wenig - nur insofern weil  derzeit UDP nicht in der fw ist deswegen kein Broadcast geht. Das einzubauen wäre auch entsprechend aufwendig.

vg
joerg

[pjakobs]

@vbs neben dem Ansatz, den ich beschrieben habe (pub/sub) gibt es noch einen weiteren, imho nochmal aufwendigeren, den Du gerade vor Deinem geistigen Auge hast: Multicasting. Ich glaube nicht, dass das sming Framework multicast überhaupt unterstützt.

Im Modul passt schon ganz gut, denke ich, und ich vermute auch, dass das kein echtes Timing Problem sein wird.

pj

[mrpj]

ist das neue google formular schon verfügbar ?

Noch nicht - Google hat seine Formulare umgestellt und ich kämpfe mich noch durch das neue Interface 

Inwiefern würdest du die Netzwerklatenz da als Faktor sehen? Ich hätte gedacht, dass auf den FHEM-Befehl hin ein UDP-Paket vom AP als Broadcast gesendet wird, welcher dann von allen Controller (nahezu) zeitgleich empfangen wird, oder?

Eine synchrone Steuerung von mehreren Controllern ist ein sehr aufwändiges unterfangen und mMn is das Ergebnis dem Zeitaufwand nicht gerechet.

Selbst in dem Fall von UDP hast du ein Problem: Paketverluste bei Wifi. Das UDP Paket wird einmal verpackt und über Wifi verschickt - je nachdem wie es um das Netzwerk bestimmt ist (allgemeine Signalqualität,wieviele weitere Sender sind im selben Frequenzband aktiv, etc.) kann es sein, dass das Paket verspätet oder gar nicht erst ankommt.

Ein weiterer Faktor:
auch wenn alle Controller gleichzeitig starten - je mehr Zeit bei der Animation verstreicht, desto höher ist die Wahrscheinlichkeit, dass die Controller +/- ms auseinander liegen. (Eine Berechnung dauert länger, die Berechnung wird durch ein Netzwerkpaket unterbrochen, ein Controller wird dauerhaft mit http Anfragen ausgelastet etc.) Dadurch wäre es notwendig einen Synchronisationsmechanismus zwischen den Controllern zu implementieren, welcher natürlich auch wieder die Netzwerklatenzen in betracht ziehen müsste.


Es gibt eine Lösungsmöglichkeit, die aber viel Zeit und Aufwand zur Implementierung benötigt (der Algorithmus zur Berechnung von Farbübergängen müsste komplett umgeschrieben werden.
Kurzer Umriss:
- die RGBWW Controller synchronisieren in regelmäßigen kurzen intervallen eine interne Systemzeit
- jeder Animationsbefehl enthält einen Startzeitpunkt und eine Laufzeit. Ausgehend von dieser Startzeit kann der Controller dann seinen aktuellen Zustand extrapolieren

@vbs neben dem Ansatz, den ich beschrieben habe (pub/sub) gibt es noch einen weiteren, imho nochmal aufwendigeren, den Du gerade vor Deinem geistigen Auge hast: Multicasting. Ich glaube nicht, dass das sming Framework multicast überhaupt unterstützt.

pub/sub hat auch das Problem der Netzwerklatenz. Befehle würde unterschiedlich bei den Controllern ankommen - zusätzlich gilt das gleiche was ich oben drüber schon geschrieben hatte

[Tom71]

Hallo,
ich bin nun endlich dazu gekommen, die LED Stripes einzubauen. Anfänglich funktioniert der Controller auch sehr gut. Leider reagiert der Controller über Fhem nach einer Weile (ca. halbe Stunde) nicht mehr.

Fhem sendet:

Code Auswählen Erweitern

2016.07.20 15:49:58 5: LedController1 called with off
2016.07.20 15:49:58 5: LedController1 setting VAL to 0, keeping HUE 26 and SAT 36
2016.07.20 15:49:58 5: LedController1 extended args raw: ,
2016.07.20 15:49:58 5: LedController1 extended args: t = 0, q = false, d = 1
2016.07.20 15:49:58 5: LedController1: called SetHSVColor 26, 36, 0, 2700, 0, solid, false, 1)
*** {"hsv":{"s":"36","ct":"2700","v":"0","h":"26"},"q":"false","cmd":"solid","t":"0","d":"1"}
2016.07.20 15:49:58 4: LedController1: set HSV color request
HASH(0x2a1a028)
2016.07.20 15:49:58 5: LedController1: calculated RGB as 000000
2016.07.20 15:49:58 4: LedController1: begin Readings Update
   hue: 26
   sat: 36
   val:0
   ct : 2700
   HSV: 26,36,0
   RGB: 000000

Code Auswählen Erweitern

2016.07.20 15:50:28 4: LedController1: got HSV color response
2016.07.20 15:50:28 2: LedController1: error connect to http://192.168.0.44:80 timed out setting HSV color

Über das Webinterface antwortet der Controller noch, allerdings zuerst verzögert:

Code Auswählen Erweitern

{
"deviceid": "8482868",
"current_rom": "0",
"firmware": "0.3.1",
"git_version": "v0.3.1",
"git_date": "2016-06-29",
"config_version": "1",
"sming": "2.1.0",
"rgbww": {
"version": "0.8.1",
"queuesize": 100
},
"connection": {
"connected": true,
"ssid": "XXX",
"dhcp": true,
"ip": "192.168.0.44",
"netmask": "255.255.255.0",
"gateway": "192.168.0.1",
"mac": "XXX"
}
}

Danach antwortet der Controller auch wieder sofort über fhem:

Code Auswählen Erweitern

2016.07.20 15:54:06 5: LedController1 called with on
2016.07.20 15:54:06 5: LedController1 setting VAL to 100, SAT to 0 and keeping HUE 26
2016.07.20 15:54:06 5: LedController1 extended args raw: ,
2016.07.20 15:54:06 5: LedController1 extended args: t = 0, q = false, d = 1
2016.07.20 15:54:06 5: LedController1: called SetHSVColor 26, 0, 100, 2700, 0, solid, false, 1)
*** {"cmd":"solid","t":"0","q":"false","hsv":{"ct":"2700","h":"26","v":"100","s":"0"},"d":"1"}
2016.07.20 15:54:06 4: LedController1: set HSV color request
HASH(0x2944f18)
2016.07.20 15:54:06 5: LedController1: calculated RGB as ffffff
2016.07.20 15:54:06 4: LedController1: begin Readings Update
   hue: 26
   sat: 0
   val:100
   ct : 2700
   HSV: 26,0,100
   RGB: ffffff
2016.07.20 15:54:06 4: LedController1: got HSV color response
2016.07.20 15:54:06 5: LedController1: HSV color response data {"success":true}

Ich habe dieses Verhalten bei 2 Controllern hier. Sieht aus wie ein Deep-Sleep o.ä. aus dem der Controller erst wieder aufwachen muss. Nun schicke ich in einem Screen einen ping an den Controller und schaue mal, wie er sich da verhält.

An der fhem Version des Moduls kann es eigentlich nicht liegen, ich habe den master und dev-pj ausprobiert.

Habt ihr ähnliches beobachtet?

Das Faden (ramp) hat allerdings ein Lächeln in das Gesicht der Betrachter gezaubert. Nice.

Gruss Thomas

[pjakobs]

Hi Tom,

ich habe hier manchmal das Problem, dass der Controller nicht auf arp Requests zu antworten scheint, @mrpj hat dazu auch mal einen möglichen Bug im Espressiv Code gefunden.
Ich nehme an, in Deinem Fall laufen fhem und der Browser, mit dem Du auf den Controller zugreifest auf unterschiedlichen Geräten?
Bei Linuxoiden könntest Du mit einem

Code Auswählen Erweitern


arp -v

ggf. mehr Info zum Zustand bekommen.

Grüße

pj

[Tom71]

Fhem läuft auf einem Raspi 3
Hier mal die Ausgabe:

Code Auswählen Erweitern

pi@fhem ~ $ arp -v -a rgbww1.fritz.box
rgbww1.fritz.box (192.168.0.44) auf 5c:cf:7f:81:70:34 [ether] auf eth0
Einträge: 34   Ignoriert: 33   Gefunden: 1
pi@fhem ~ $ ping 192.168.0.44
PING 192.168.0.44 (192.168.0.44) 56(84) bytes of data.
64 bytes from 192.168.0.44: icmp_seq=27 ttl=255 time=1.33 ms
64 bytes from 192.168.0.44: icmp_seq=28 ttl=255 time=1.37 ms
^C
--- 192.168.0.44 ping statistics ---
28 packets transmitted, 2 received, 92% packet loss, time 27020ms
rtt min/avg/max/mdev = 1.331/1.352/1.373/0.021 ms

In der Arp-Tabelle ist der Controller vorhanden. Das ping startet aber erst nach ca. 25 sec. Ich hab jetzt das gleiche Verhalten von 3 Controllern, die in unterschiedlichen WLAN-Netzen hängen.

Im selben Netzwerk ist auch ein sonoff mit ESP8266 (https://github.com/arendst/Sonoff-MQTT-OTA) Dieser reagiert immer prompt.

Was könnte ich noch probieren? Wenn ein ping die ganze Zeit läuft, tritt das Verhalten nicht auf.

Gruss Thomas

[pjakobs]

Moin Thomas,

wenn der arp Eintrag bei allen vorhanden ist, dann ist es zumindest was anderes als das, was ich hier sehe.
Es kommt bei allen LED Controllern vor? Gefühlt könnte es natürlich ein WLAN Problem sein (vielleicht sind die Teile etwas empfindlicher bei geringer Feldstärke, weil die Antenne durch die Platine abgeschirmt ist - auch wenn die Cu Lage darunter freigelassen ist, könnte eine gewisse Richtwirkung haben).

@mrpj - get /networks liefert bei mir ne leere Liste wenn der Controller im Netz ist und kein Scan ausgeführt wurde - gibt es einen anderen Weg, die Signalstärke des aktuellen Netzes zu lesen?

pj

[Tom71]

Ich hab 3 Controller und bei allen das gleiche Problem. Z.T. sind sie mit unterschiedlichen WLAN-Access-Points verbunden. Die Controller stehen fast neben dem AP, geringe Feldstärke scheidet also aus, eher zuviel.
Bei allen dreien ist das Netzwerk auf manuell gestellt. Gab es damit Probleme?

Thomas

[mrpj]

Hallo Thomas & Peter,

die Antwort kommt gerade leicht verzögert ("Sommer"loch und so )
bei mir ist das Problem bisher (noch) nicht aufgetreten - und ich bin gerade etwas ratlos, wie ich das Nachstellen kann, um mehr Daten für eine eventuelle Lösung zu sammeln....
Das übliche "Labor" vs "Kunde" Szenario 

Ich habe dieses Verhalten bei 2 Controllern hier. Sieht aus wie ein Deep-Sleep o.ä. aus dem der Controller erst wieder aufwachen muss. Nun schicke ich in einem Screen einen ping an den Controller und schaue mal, wie er sich da verhält.

Eigentlich^TM sollte der Controller zu keinem Zeitpunkt in einen sleep modus verfallen - in der Firmware von mir ist alles soweit deaktiviert. Auch das Wlan Modem wird mit "NO_SLEEP" initialisiert. Ich kann aber mal schauen, ob es noch weitere Parameter gibt und diese für eine Testfirmware explizit angeben

Peter hatte mir ja von einem ARP Problem berichtet - welches scheinbar mit dem ESP auftreten kann - Lösungsvorschlag von mir (falls es bald kein update von espressif dazu gibt), wäre ein regelmäßiger blast mit dem ARP Informationen vom ESP (alle X Sekunden). Ist zwar nicht schön und elegant, wirkt aber dem ARP Problem zumindest für den Moment entgegen. (ARP wird vom Espressif SDK gehandhabt, somit liegt das eine ebene drunter und ich kann wenig an deren SourceCode ändern)

@mrpj - get /networks liefert bei mir ne leere Liste wenn der Controller im Netz ist und kein Scan ausgeführt wurde - gibt es einen anderen Weg, die Signalstärke des aktuellen Netzes zu lesen?

Der Controller scannt beim booten einmal das Wlan und speichert die Liste. Um die Liste zu erneuern ein scan_networks vorher ausführen. Kurz warten (ca. 5s) und dann kannst du mit dem GET die aktuelle Liste auslösen

[DannyP]

Hi,

nun bin ich endlich auch mal dazu gekommen, die LED Stripes zu verbauen und in Betrieb zu nehmen RGB klappt auch super.

An einem zweiten Controller habe ich nur einen weißen Stripe dran (http://www.ebay.de/itm/231712106382?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT). Leider bekomme ich den aber nicht zum leuchten Hab ich evtl. den falschen gekauft?

Wenn ich im Webinterface auf der Seite "Color Setting" auf den Haken zum Speichern drücke bekomme ich die Meldung "something went wrong while saving the configuration"
Ist das noch nicht ganz fertig und es fehlt noch etwas? Das Problem habe ich mit beiden Controllern.
Das ist die eingesetzte Firmware:
Firmware 0.3.1   (v0.3.1)
Web Interface 0.3.3
RGBWW Version 0.8.1
SMING Version 2.1.0

Vielen Dank & schöne Grüße
Daniel

[vbs]

Geht denn die weiße Stripe an dem anderen Controller und umgekehrt?

[DannyP]

die bunten gehen an beiden Controllern. Die weißen leider an gar keinem.
Wenn ich sie direkt an einem Netzteil anschließe leuchten sie aber.

[vbs]

Hm, nicht dass ich da viel Ahnung hätte, aber meines Wissens weiß der Controller eigentlich nur bedingt etwas von RGB oder weiß oder wie auch immer. Aus seiner Sicht gibt es einfach 5 Kanäle, die er mit Spannung versorgt. Hätte jetzt daher auch erwartet, dass die Stripe leuchten müsste, wenn du den Controller als RGBWW konfigurierst und einfach alle Kanäle auf volle Intensität drehst. Naja, ich weiß, das hilft dir jetzt nicht wirklich weiter  Doofe Frage: verpolt oder so ist das nix, oder?

[DannyP]

Das habe ich versucht. Unter "Color Settings" habe ich auf RGBWW gestellt und volle Leistung auf allen Kanälen eingestellt. Das ändert aber leider nichts. Beim Speichern bekomme ich auch immer die Meldung "something went wrong while saving the configuration"

Wenn ich unter "Start" mir eine Farbe aussuche, dann wechselt der Bunte Stripe direkt zur gewünschten Farbe.

Verpolt war auch mein erster Gedanke Wenn die Beschriftung auf dem Stripe stimmt, dann ist aber auch alles richtig angeschlossen. Gedreht habe ich zum Test aber auch schon mal.

An den 3 Anschlussklemmen für WW/CW messe ich auch immer nur 0 Volt.