ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[vbs]

Oje, ist etwas länger geworden, sorry schonmal dafür 

Meine Idee wäre, dass jeder Controller seine hsv und / oder raw werte published also etwa:
/hooks/devices/LedController/$instance/Actuals/RAW und
/hooks/devices/LedController/$instance/Actuals/HSV

Ich denke, dass sich damit Fades nicht ohne weiteres abbilden lassen, oder?

und dass Du, auch für jeden Controller, eine Möglichkeit hast, Dich auf einen solchen Endpoint zu subscriben.
Du hast natürlich Recht, auch da tritt eine Latenz auf - 2x die Netzwerklaufzeit. Ich denke aber, das ist sicher weniger als das, was auftritt, wenn Du die fhem Event Queue nutzt.

Also vorweg: ich sehe da eigentlich weder mit der FHEM-Methode noch mit MQTT Probleme bzgl. der Latenz.
Bist du sicher wegen der FHEM-Queue? Ich hab nochmal drüber nachgedacht und ich bin jetzt eigentlich der Meinung, dass Befehle, die ein Modul per fhem() absetzt gar nicht durch die Event-Queue gehen, sondern direkt synchron ausgeführt werden.

Außerdem, wenn man mal vergleicht, was in beiden Szenarien passiert wenn man einen Befehl an einen Master und einen (oder mehr Slaves) schicken möchte:
FHEM:
-> FHEM sendet nacheinander die HTTP-Requests non-blocking an alle Master und Slaves (ich denke sogar ohne Event-Queue dazwischen) -> fertig

MQTT:
-> FHEM sendet an den Master -> Master prozessiert Nachricht -> Master sendet an MQTT-Broker -> MQTT-Broker prozessiert Nachricht -> MQTT-Broker sendet an alle Slaves -> fertig

Ich kann mir nicht vorstellen, dass man mit dem MQTT-Ansatz kleinere Latenzen erreicht. Bitte korrigier mich, wenn ich etwas falsch dargestellt bzw. falsch verstanden habe.
Darüberhinaus finde ich es im FHEM-Umfeld nicht so gut, Logik und/oder Konfiguration vom zentralen FHEM-Server in die Endgeräte zu verschieben, aber das mag Geschmackssache sein. Ich hab da Logik/Config gerne zentral im Zugriff.

Wenn Du eine lange Befehlskette hast (und wenn Du mit Effektlicht arbeiten willst können das ja mal 50 set's auf einen Rutsch sein), dann bleibt der Fokus so lange beim Modul, bis all diese Befehle abgearbeitet sind, danach geht er zurück an den Main Loop - so jedenfalls sah es für mich aus, als ich das letztes Jahr untersucht hatte.
Aus dem Grund wollen wir hier die Zeit, die zur Abarbeitung eines Befehls gebraucht wird möglichst kurz halten, und Christian hat da extrem viel getan.

Ahh ok, verstehe. So einen Fall mit mehr als 3 Befehlen hatte ich bei mir noch nicht, aber klar, man kann auch 50 Befehle absetzen. Aber wenn man für den Fall optimieren will, wäre es dann nicht besser im Modul eine Schnittstelle zu schaffen, so dass man direkt mit einem set-Befehl mehrere LED-Befehle einliefern kann? So in der Art "set myLed HSB 100,100,100 4:150,20,100 4:50,100,100 2"? Ist vermutlich auch nicht sooo aufwendig. Da würde man schonmal den ganzen FHEM-Drumrum Overhead sparen. Im Idealfall könnte das Modul dann auch direkt an den Controller per API (HTTP/MQTT) mehrere Befehle absetzen.
Außerdem kann man in FHEM längere Befehlskette aufbrechen, in dem man ein "sleep 0" einstreut. Damit baut ja FHEM ein internes "at" welches dann über die Event-Queue abgearbeitet wird. Damit könnten dann auch andere Events zwischendurch zum Zuge kommen (so als yield-Ersatz). Hatten das Thema hier neulich erst:
https://forum.fhem.de/index.php/topic,68350

----

Ich denke, ich hab jetzt ganz gut verstanden, wie du dir das vorstelltst mit dem Auslagern in ein eigenes Modul, also danke erstmal für die Erklärung!

Im Grunde ist doch das, was Du hier vorstellst nicht LedController spezifisch.

Hm weiß nicht, ich denke schon, dass das zumindest schon recht modul-spezifisch sein wird (s.u.).

Du hast, wenn ich das richtig sehe, ein paar Betriebsmodi:

• alle Slave Devices sollen das gleiche tun und verstehen die gleiche "Sprache" (=Befehlssysntax). In dem Fall musst Du nur durch die Slave Devices iterieren und sie mit $cmd @args aufrufen, das werden sie verstehen
• alle Slave Devices verstehen die gleiche Sprache, aber sie sollen was anderes tun. Wie Du geschrieben hast: vielleicht 10% dunkler oder 20% mehr Sättigung oder um 30% auf dem Farbkreis gedreht, kurz: irgendeine Transformation aber der eigentliche Befehl bleibt gleich Hier müsstest Du imho das Kommando "verstehen" weil die Transformation ja für rgb anders wäre als für hsv und Du müsstest die args aufsplitten und neu zusammensetzen.
• wie 2. allerdings muss auch noch die Befehlssyntax transformiert werden, z.B. von Kleinbuchstaben auf Großbuchstaben (für WifiLight etc.) Das wäre meistens eine einfacher Ersetzung

Ich glaube einfach, dass das cleaner in einem gesonderten Modul unterzubringen wäre und das LedController Modul mit einer Menge Code aufblähen würde, die mit dem Controller selbst nix zu tun hat.
Außerdem wäre es dann m.E. auch für völlig andere Devices nutzbar (z.B. Schaltergruppen oder so).

Also ich denke, dass man damit aber viele Sachen nachbauen würde, die es in FHEM sowieso schon gibt. Und auch recht grundlegende Funktionen dazu. Im Prinzip ist gibt es ja das, was dir vorschwebt schon ziemlich genau so in Form von "structure" (jedoch ohne die Transformationsschicht). Deinen ersten Punkt ("alle Slave Devices sollen das gleiche tun und verstehen die gleiche "Sprache") deckt das bestehende structure jetzt schon ab, denk ich.
Für die anderen Fälle müsste man es aufbohren und hätte dann mMn eine Art "structure 2.0" Wenn man das jedoch so bauen würde und da sehr generisch Befehle an mehrere verschiedenartige Geräte absetzen möchte, dann würde man das doch momentan in FHEM auch schon per notify/DOIF bauen können, oder?
Mir ist noch nicht ganz klar welche konkreten Einsatzszenarien es überhaupt dafür gibt, aber wenn ich, sagen wir, die Raumtemperatur auf 20°C schalten möchte, wenn jemand die LED auf "rot" setzt, dann ginge das doch schon mit einem notify recht einfach:

Code Auswählen Erweitern

define nty notify wl_led:hsv 0,.* set wz_temp 20
(bitte mich nicht drauf festnageln, mag genau so evtl. nicht funktionieren, aber ich hoffe man versteht die Idee:))

Und das halte ich eigentlich für einfacher, also dafür ein Master-Modul zu definieren und dann per Attribut (vermutlich) recht komplexe Transformationsausdrücke zu definieren. Ich fürchte, dass die recht komplex sein müssen, weil das Modul ja sehr generisch sein soll und zwischen beliebigen Devices transformieren können soll. Damit geht mMn eine gewisse Komplexität einher. Dieser Ansatz mit dem notify wiederum klappt bei dem LedController mMn eben nicht so gut, nämlich wieder wegen den Fades. Man kann eben nicht auf hsv-Events lauschen (per notify) und diese dann 1:1 auf ein anderes LED-Gerät übertragen. Man muss das wirklich auf Befehlsebene machen, denk ich. Und darum denke ich, dass es doch irgendwie modulspezifisch ist.

Ein anderer Punkt sind die Readings: um mit dem LedController sinnvolle Logiken zu basteln, braucht man Zugriff auf die Readings. Wenn man nun ein separates Master-Modul baut, dann müsste man sich irgendwie auch überlegen, wie man den Zugriff auf Readings abbilden will. Wenn das dann auch entsprechend generisch sein soll, wird man da auch nochmal einiges an Transformationslogik reinstecken müssen.

Ich glaube der Aufhänger für diesen generischen Ansatz ist, dass LedController per Slave in der Lage ist WifiLight zu steuern, oder? Ich vermute, wenn das WifiLight da nicht vorgekommen wäre, hätte es sich für dich weniger unpassend angefühlt? Da würde ich dir teilweise zustimmen. LedController sollte eigentlich nicht das Interface von anderen Modulen kennen und die steuern können. Wenn man da konsequent wäre, könnte man diese Funktion auch wieder rausnehmen, so dass LedController nur andere LedController steuern könnte. Andererseits ist es auch ganz schick, dass man damit WifiLight mit abdeckt mMn. Bin unschlüssig

Oh mann, vermutlich mein längster Post ever Sorry, dass ich da an den meisten Stellen unterschiedlicher Meinung bin Ich finde die Diskussion jedoch an beiden Ecken sehr interessant!

[pjakobs]

@vbs: ich antworte mal drüben im Thread for das fhem - modul, wir verwirren jeden hier im Controller thread

[pjakobs]

Update: die Boards liegen jetzt seit ner Woche im Zoll, obwohl sie korrekt deklariert sind und ich natürlich Zoll und Einfuhr Umsatzsteuer zahlen will. Ich habe eine ähnliche Situation schonmal erlebt, da hat's zwei Wochen gedauert, keiner wusste was und irgendwann kam ein Brief (!) meines lokalen Zollbüros, ich möge doch mein Päckchen abholen.

Rund um die Welt ist einfach, deutsche Behörden brauchen Zeit.

pj

Update 2: soeben sind die letzten ESP12 und DC/DC Wandler eingetroffen. Sobald die Boards da sind, kann's los gehen!

pj

[pjakobs]

Laut Tracking sind die Boards jetzt per Kurier auf dem Weg zu mir, mal schnell noch Kleingeld holen gehen...

Gesendet von meinem HTC 10 mit Tapatalk

[pjakobs]

soeben sind die Boards eingetroffen, damit ist alles, was wir brauchen komplett.
Ich habe auch schon getestet: sie passen perfekt in die vorgeschlagenen Gehäuse! (ich gebe zu, beim Ausmessen hatten wir ein paar Wirrkungen)

Was jetzt passiert:

• [ X ] ein Board aufbauen, um es zu testen
• [   ] ein Board aufbauen und den Vorgang als howto Video veröffentlichen
• [   ] die Bauteile für die Komplettgeräte separieren und pf@anne bringen
• [   ] Bausätze zusammenstellen
• [   ] Versand

Ich hatte für die Fertigboards angefangen, die DC/DC Wandler auf einem Window-Comparator abzugleichen (simple Schaltung mit zwei Spannungen und einem Opamp, macht es aber sehr schnell, die Teile einzustellen) dabei sind mir drei von 100 aufgefallen, die meinen Ansprüchen nicht genügen (500mV Sägezahn am Ausgang, einer lässt sich garnicht einstellen). Unter den Bedingungen möchte ich Euch die Dinger nicht "einfach so" zuschicken, dass heißt, Ihr bekommt alle DC/DC Wandler ziemlich genau auf 3,3V (-0/+0,08V) eingestellt, bitte messt sie aber dennoch nach, sie könnten sich verstellt haben. Das vermindert alledings das Risiko, dass Ihr alles zusammenbaut und Euren schönen ESP12 beim ersten Einschaltet bratet sehr deutlich.

Ich werde am Wochenende leider, wenn überhaupt, sehr wenig Zeit dafür haben, also seid mir bitte nicht böse, wenn sich die Vorbereitungen noch durch die nächste Woche ziehen und die ersten Päckchen frühestes Anfang übernächster Woche rausgehen.

Grüße

pj

[lewej]

Hallo Pjakobs,

ich denke nicht alle haben zu Hause ein Labormessgerät. Ich hab nur ein normales Messgerät, kann ich auch damit die DCs einstellen. Eine kleine Schaltung kriege ich auch zusammen gelötet, um diese dann einzustellen, nur weiss ich nicht genau wie ich so eine Schaltung aufbauen sollte.

Könntest du von deiner Mal ein Foto machen und evtl. ein Schaltbild und wie was zu verdrahten ist.

Grüsse und Danke für die Mühe.

lewej

[pjakobs]

Hallo Pjakobs,

ich denke nicht alle haben zu Hause ein Labormessgerät. Ich hab nur ein normales Messgerät, kann ich auch damit die DCs einstellen. Eine kleine Schaltung kriege ich auch zusammen gelötet, um diese dann einzustellen, nur weiss ich nicht genau wie ich so eine Schaltung aufbauen sollte.

Könntest du von deiner Mal ein Foto machen und evtl. ein Schaltbild und wie was zu verdrahten ist.

Grüsse und Danke für die Mühe.

lewej

Hmm... ich werde die DC/DC Wandler alle hier korrekt einstellen, aber ich kann nicht garantieren, dass sich das nicht unterwegs ändert. Ein einfaches Digitalmultimeter bekommst Du bei Conrad und Co schon für deutlich unter 10 Euro, und wenn Du Schaltungen wie diese zusammenlöten willst, dann sollte das zu Deinem Werkzeug gehören, genau wie ein kleiner Lötkolben mit ordentlicher Spitze (rund oder flach, ich bevorzuge rund).
Ich gehe aber davon aus, dass es keine Probleme geben wird. Der ganze Bausatz kommt in eine Antistatik-Tasche, da dürfte nix passieren. Nur: es bleibt Deine Verantwortung, das zu überprüfen. Wenn Du das Teil ansteckst und versehentlich 12V an den ESP durchgereicht werden, dann war's das für den.
Also: es muss ja nicht gleich ein Fluke Messgerät sein, ein 10Euro Teil genügt, und wenn das am Ausgang des Wandlers 3,3V anzeigt ist alles in Butter.

Grüße

pj

[pjakobs]

jetzt habe ich gerade einen wunderbaren Controller komplett zusammengelötet, um davon ein Video zu machen und - der größte Teil davon fehlt, weil ich nach einem heruntergefallenen Widerstand suchte und danach vergessen habe, das Video wieder zu starten. Das Alter! Ich sag's Euch!.

pj

[vbs]

 

[AxelSchweiss]

jetzt habe ich gerade einen wunderbaren Controller komplett zusammengelötet, um davon ein Video zu machen und - der größte Teil davon fehlt, weil ich nach einem heruntergefallenen Widerstand suchte und danach vergessen habe, das Video wieder zu starten. Das Alter! Ich sag's Euch!.

Dann löte doch alles wieder ab und lasse das Video dann rückwärts laufen 
(Aua  ... nicht hauen)

[pc1246]

Naja
Ich gehe eher davon aus, dass er einfach einen zweiten Widerstand runterschmeisst. Nee einen zweiten Controller loetet!
Gruss Christoph

[Haecksler]

Hallo zusammen,
habe nun endlich auch einen meiner 3 Controller inbetriebgenommen.

Ich weiß nicht, ob es irgendwo steht und ich es übersehen habe, aber bei meinen ESP ging gar nichts bis ich eine Antenne angelötet haben.
Hat mich gestern abend 3h gekostet  .

Vielleicht sollte hier noch ein Hinweis bei der Flashanleitung
https://forum.fhem.de/index.php/topic,48918.msg443761.html#msg443761
diesbezüglich hinzugefügt werden.

Gruß,
Stefan

[pjakobs]

Hallo zusammen,
habe nun endlich auch einen meiner 3 Controller inbetriebgenommen.

Ich weiß nicht, ob es irgendwo steht und ich es übersehen habe, aber bei meinen ESP ging gar nichts bis ich eine Antenne angelötet haben.
Hat mich gestern abend 3h gekostet  .

Vielleicht sollte hier noch ein Hinweis bei der Flashanleitung
https://forum.fhem.de/index.php/topic,48918.msg443761.html#msg443761
diesbezüglich hinzugefügt werden.

Gruß,
Stefan

äh, eine Antenne?
Magst Du mir bitte mal ein Foto schicken?
Ich hab hier mittlerweile sechs Controller laufen, und alle funktionieren prima mit der on-board Antenne des ESP12 (e oder f, wobei der f ja eine verbesserte Antenne hat).
Hast Du da, wo Du den Controller aufbaust grundsätzlich schlechten WLAN Empfang?
Kannst Du mal z.B. hiermit nachmessen?

Wo hast Du denn eine Antenne angelötet?

Grüße

pj

[RaspiLED]

Hi,
Hauptsache wir bekommen die Directors Cut Version mit der deleted scene: "A grown man searching a not so grown R!"
*lol*
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[pjakobs]

ich hab's eher so mit dem Blues:

R is gone
R is gone away
R is gone baby
R is gone away