ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[vbs]

Ich hätte da evtl. noch eine Idee für ein Feature: mit Wifilight und dem LD382 habe ich trotz Farbkalibration das Problem, dass sich der Farbton stark verändert wenn ich nur die Helligkeit verstelle (https://forum.fhem.de/index.php/topic,18958.msg423941.html#msg423941).

Wäre es sinnvoll und möglich, eine 2-Punkt-Kalibration einzuführen? Sprich: Man würde die Grundfarben bei (mindestens) zwei verschiedenen Helligkeiten kalibrieren (zB bei 20% und 80% Helligkeit) und dann wird je nach aktueller Helligkeit dazwischen geeignet interpoliert?

[mrpj]

Grundsätzlich stimme ich Dir da zu, allerdings bietet sich MQTT halt für Dinge an, die REST so nicht kann - nämlich genau das Thema push statt pull.
Ich denke, wir sprechen am Ende über zwei unterschiedliche Dinge:
Über REST kann ich, für den Controller asynchron, die aktuellen Werte abfragen.
der Controller seinerseits kann über REST keine asynchronen Updates an das fhem Modul senden.
Über MQTT hingegen können beide Seiten asynchron Updates verschicken, wir haben also zusätzliche Möglichkeiten.

Ich glaube da mischt du mehrere Sachen - MQTT, HTTP, WEBSOCKET sind Transportprotokolle. REST ist eine Schnitstellen Dokumentation (Verben/Syntax). Diese Verben/Syntax kann in jedem Transportprotokoll abgebildet werden. In HTTP via die HTTP Headers (GET/POST/PUT) + body - bei mqtt/websockets z.b. via json/xml.

Auch wenn die Communication bei mqtt erstmal asynchron läuft - ist dies kein Hindernis eine REST Schnitsteller / API damit zu implementieren. Ganz einfach: mit jedem Request was man abschickt hängt man eine ID an - die Antwort auf dem Rückkanal enthält die ID der Anfrage auf die sich die Antwort bezieht. (JSON-RPC handhabt das so)

Mein Gedankengang hinter diesem Austausch ist:
Warum muss ein Client 2 Protokolle implementieren um mit dem Controller zu kommunizieren? Die Befehle die du über HTTP schicken möchtest können genausogut via MQTT gesendet werden (siehe Rückkanal mit ID).

Anderes Beispiel: Beim auslesen von Sensoren über MQTT: nicht jeder Sensor gibt die Daten kontinuierlich von sich aus - teilweise wird das auslesen auch durch ein "read" angestoßen und landet dadurch auf dem Rückkanal

Ich hoffe ich kann dir Näher bringen, warum ich nicht einfach einen MQTT Client "reinklatsche" und das implementiere.

Eine weitere Sache muss auch noch geklärt werden: Wie wird dem controller mitgeteilt welche Werte er publizieren soll (RAW/HSV+K etc.) - ein "config switch" oder gibt es da genauerere Vorstellungen?

Du also wirklich MQTT updates verschicken, würde ich davon ausgehen, dass Du das mit jedem zweiten Schritt machst, das halte ich für a) ausreichend und b) für den Broker erträglich.

Da muss man mal testen inwiefern eine update Frequenz Sinn macht - mqtt ist auf TCP aufgesockelt - d.h. zu häufige updates bei schlechtem Empfang könnten negative folgen haben.

Die Alternativmöglichkeiten hier wären ganz simple: UDP Packet (SPAM) an eine broadcast Adresse (mit werten und mac)

nebenbei: ich habe eben ein etwas aufgeräumtes Modul gepusht

Ich habs gesehen - hab mal im Git ein "Contributing" guideline von mir reingestellt - damit sieht jeder beim forken wie die branches gehandhabt werden.
Generell persönlicher fork -> develop -> master. Somit bleibt master unangetastet bis man einen "neuen release" hat

[mrpj]

Ich hätte da evtl. noch eine Idee für ein Feature: mit Wifilight und dem LD382 habe ich trotz Farbkalibration das Problem, dass sich der Farbton stark verändert wenn ich nur die Helligkeit verstelle (https://forum.fhem.de/index.php/topic,18958.msg423941.html#msg423941).

Wäre es sinnvoll und möglich, eine 2-Punkt-Kalibration einzuführen? Sprich: Man würde die Grundfarben bei (mindestens) zwei verschiedenen Helligkeiten kalibrieren (zB bei 20% und 80% Helligkeit) und dann wird je nach aktueller Helligkeit dazwischen geeignet interpoliert?

Die Farbkalibration findet im Controller statt - nicht in Wifiligt.
Bitte berichte doch ob es bei dir auch bei dem Controller aus dem Projekt vorkommt (du schreibst vom LD382 und nicht von dem Projekt) -
Ich kann keine Farbänderung bei unterschiedlichen Helligkeiten erkennen ....

[pjakobs]

Ich glaube da mischt du mehrere Sachen - MQTT, HTTP, WEBSOCKET sind Transportprotokolle. REST ist eine Schnitstellen Dokumentation (Verben/Syntax). Diese Verben/Syntax kann in jedem Transportprotokoll abgebildet werden. In HTTP via die HTTP Headers (GET/POST/PUT) + body - bei mqtt/websockets z.b. via json/xml.

Auch wenn die Communication bei mqtt erstmal asynchron läuft - ist dies kein Hindernis eine REST Schnitsteller / API damit zu implementieren. Ganz einfach: mit jedem Request was man abschickt hängt man eine ID an - die Antwort auf dem Rückkanal enthält die ID der Anfrage auf die sich die Antwort bezieht. (JSON-RPC handhabt das so)

Mein Gedankengang hinter diesem Austausch ist:
Warum muss ein Client 2 Protokolle implementieren um mit dem Controller zu kommunizieren? Die Befehle die du über HTTP schicken möchtest können genausogut via MQTT gesendet werden (siehe Rückkanal mit ID).

das habe ich auch nicht anders gedacht, mir ging es darum, dass das API, mit dem wir den Controller steuern unabhängig ist von dem zweiten Kanal, der die Readings liefert. Der wäre ein "einfacher" Publisher, der regelmäßig die aktuellen rgbcwww/hsv Werte published und sich um nichts sonst kümmert. Ich würde sogar sagen: das ist ein MQTT Topic, das mit dem API nichts zu tun hat.

Anderes Beispiel: Beim auslesen von Sensoren über MQTT: nicht jeder Sensor gibt die Daten kontinuierlich von sich aus - teilweise wird das auslesen auch durch ein "read" angestoßen und landet dadurch auf dem Rückkanal

natürlich, aber genau das ist ja der Punkt an dieser Stelle: wenn wir kontinuierliche Updates haben wollen, dann sollten die von der Stelle kommen, die die Updates durchführt.

Ich hoffe ich kann dir Näher bringen, warum ich nicht einfach einen MQTT Client "reinklatsche" und das implementiere.

Das ist völlig in Ordnung: wie gesagt, die Funktion ist mir auch nicht vordringlich wichtig, aber der Gedanke, dass wir jede Transition jedes ledControllers irgendwo im System in fhem mitkoppeln scheint mir wenig elegant, das würde ich eigentlich gerne vermeiden.

Eine weitere Sache muss auch noch geklärt werden: Wie wird dem controller mitgeteilt welche Werte er publizieren soll (RAW/HSV+K etc.) - ein "config switch" oder gibt es da genauerere Vorstellungen?

klar, idealerweise wäre das konfigurierbar. Da das Modul aber zumindest momentan ausschließlich über HSV mit dem Controller spricht, wäre das imho der sinnvolle erste Schritt - auch weil die interne rgb Darstellung von fhem ja für fast alle Widgets nur 8 Bit abbildet.

Da muss man mal testen inwiefern eine update Frequenz Sinn macht - mqtt ist auf TCP aufgesockelt - d.h. zu häufige updates bei schlechtem Empfang könnten negative folgen haben.

klar, und selbst eine Update Frequenz von 25Hz ist schon extrem hoch und vermutlich nur dann sinnvoll, wenn ich mehrere controller synchronisieren will - was im Übrigen vielleicht eine der besten Anwendungen dafür wäre.

Die Alternativmöglichkeiten hier wären ganz simple: UDP Packet (SPAM) an eine broadcast Adresse (mit werten und mac)

Ich habs gesehen - hab mal im Git ein "Contributing" guideline von mir reingestellt - damit sieht jeder beim forken wie die branches gehandhabt werden.
Generell persönlicher fork -> develop -> master. Somit bleibt master unangetastet bis man einen "neuen release" hat

joa, ich hab mir jetzt im main repo einen eigenen branch eingerichtet, das spart mir ein bisschen hin und her klicken, für die von uns ohne commit rights geht der Weg über den eigenen Fork.

danke & Grüße

pj

[mrpj]

das habe ich auch nicht anders gedacht, mir ging es darum, dass das API, mit dem wir den Controller steuern unabhängig ist von dem zweiten Kanal, der die Readings liefert. Der wäre ein "einfacher" Publisher, der regelmäßig die aktuellen rgbcwww/hsv Werte published und sich um nichts sonst kümmert. Ich würde sogar sagen: das ist ein MQTT Topic, das mit dem API nichts zu tun hat.natürlich, aber genau das ist ja der Punkt an dieser Stelle: wenn wir kontinuierliche Updates haben wollen, dann sollten die von der Stelle kommen, die die Updates durchführt.Das ist völlig in Ordnung: wie gesagt, die Funktion ist mir auch nicht vordringlich wichtig, aber der Gedanke, dass wir jede Transition jedes ledControllers irgendwo im System in fhem mitkoppeln scheint mir wenig elegant, das würde ich eigentlich gerne vermeiden.

Wenn wir für dieses Feature eh schon einen MQTT Broker vorraussetzen, dann kann das Modul doch von Haus aus schon auch die API Befehle über MQTT kommunizieren? Warum also doppelte Wege ?

Andersherum: Warum soll nun jemand umbedingt einen MQTT Broker installieren "nur um den Controller anzusteuern" - ich würde diesen Punkt gerne fest setzen um eine Richtung für das Modul zu haben. (Bisher hat wifilight kein mqtt erfordert - sofern ich weiss)

klar, idealerweise wäre das konfigurierbar. Da das Modul aber zumindest momentan ausschließlich über HSV mit dem Controller spricht, wäre das imho der sinnvolle erste Schritt - auch weil die interne rgb Darstellung von fhem ja für fast alle Widgets nur 8 Bit abbildet.

Ich krätsche hier mal von der Seite rein: FHEM ist eine Möglichkeit den Controller anzusteuern - aber der Controller soll letztendlich nicht ein FHEM controller werden - sondern eine allgemein gültige API bieten, ohne "Sonderfunktionen" zu erfordern. Mit diesem Gedankengang habe ich versucht auch die API zu entwerfen - und mir wäre es wichtig dies beizubehalten.

klar, und selbst eine Update Frequenz von 25Hz ist schon extrem hoch und vermutlich nur dann sinnvoll, wenn ich mehrere controller synchronisieren will - was im Übrigen vielleicht eine der besten Anwendungen dafür wäre..

Uff - damit kommen wir in schwierige gebiete - auch wenn im Idealfall alle Controller immer alle 20ms ihren Wert ändern, so kann genau bei einem controller in dem Moment der Interrupt ankommen um ein Wifipaket abzuschicken usw..
Eine Synchrone Ansteuerung geht meiner meinung nach nur, wenn eine Zentrale Quelle die Befehle mit Zeitstempeln zum abarbeiten verschickt


Ich bin für den Rest (  ) des Tages mal raus

[pjakobs]

Ich hab ja gestern schonmal versucht, die Diskussion abzubiegen, weil ich der Meinung bin, wir treiben viel Aufwand für wenig Gegenwert.

Ich glaube aber auch, dass wir noch ein kleines bisschen aneinander vorbei reden. Macht aber nix. Für mich kann der Controller stand heute alles, was ich für wesentlich halte.

Wenn wir für dieses Feature eh schon einen MQTT Broker vorraussetzen, dann kann das Modul doch von Haus aus schon auch die API Befehle über MQTT kommunizieren? Warum also doppelte Wege ?

Andersherum: Warum soll nun jemand umbedingt einen MQTT Broker installieren "nur um den Controller anzusteuern" - ich würde diesen Punkt gerne fest setzen um eine Richtung für das Modul zu haben. (Bisher hat wifilight kein mqtt erfordert - sofern ich weiss)

Zustimmung.
Wir haben einen kleinen Disconnect:
Du denkst darüber nach, wie Du die API so aufbaust, dass sie, egal welcher Kommunikationsweg eingeschlagen wird, die gleiche Syntax und Mächtigkeit bietet. Haken dran, unterschreib ich.
Ich sage: aufgrund der Natur eines Message Busses (eben mehrere Master, die asynchron Nachrichten verschicken können) kann hier weitere Funktionalität implementiert werden, die bei einem reinen Request/Response bzw. Client/Server Modell schwierig ist.

Ich krätsche hier mal von der Seite rein: FHEM ist eine Möglichkeit den Controller anzusteuern - aber der Controller soll letztendlich nicht ein FHEM controller werden - sondern eine allgemein gültige API bieten, ohne "Sonderfunktionen" zu erfordern. Mit diesem Gedankengang habe ich versucht auch die API zu entwerfen - und mir wäre es wichtig dies beizubehalten.

Unterschreib ich, und da hast Du mich auch missverstanden. Das Modul ist, so wie ich es geschrieben habe, auch möglichst schlank und überlässt vieles dem Controller. Genau aus dem Grund verwende ich ja nur die API für HSV. Klar ist es möglicherweise mächtiger, RAW zu setzen, aber das untergräbt imho ein bisschen die Idee des Controllers, der ja eben viele Möglichkeiten der Farbanpassung bietet.

Uff - damit kommen wir in schwierige gebiete - auch wenn im Idealfall alle Controller immer alle 20ms ihren Wert ändern, so kann genau bei einem controller in dem Moment der Interrupt ankommen um ein Wifipaket abzuschicken usw..
Eine Synchrone Ansteuerung geht meiner meinung nach nur, wenn eine Zentrale Quelle die Befehle mit Zeitstempeln zum abarbeiten verschickt

war auch nicht als Feature Request gedacht sondern lediglich eine Idee, was man mit einem hoch aufgelösten Feedback vom Controller machen könnte. Mir fallen sonst - jenseits der Widgets - keine Anwendungen dafür ein.

Ich bin für den Rest (  ) des Tages mal raus

schönen Nachmittag!

pj

[funclass]

Mal ein kurzes Feedback von mir.

1. Zum Controller:
Top Leistung. Hab 2 fertige Module bekommen. Funktionieren tadellos, ota-Update hat auch geklappt. So im Nachhinein hätte ich gern noch ein/zwei Hardwareeingänge zum Ansteuern über den Standardlichttaster im Raum. Dann könnte ich das Teil auch ohne FHEM oder Web-Device für Raumbeleuchtung verwenden und Frauchen hätte keinerlei Gegenargumente (ist aber auch so akzeptiert obwohl vorher als Spielerei deklariert). Hab schon ein paar Ideen für's Kinderzimmer meiner Tochter.

2. Zum FHEM-Modul:
Funktioniert bei mir problemlos im Einsatz seit einer knappen Woche. Nach etwas Recherche im Programmcode ist mir die Verwendung der Animationsdauer klar.
Was mir noch unklar ist:

• Wie sende ich mehrere Befehle um diese in einer Que abarbeiten zu lassen? Wäre z.B. für optische Notifications interessant (rotes Aufblinken etc.). Auch Sunset- und Sunrisesimulationen stell ich mir cool vor.
• Ist geplant für on, off, rotate etc. auch eine Animationsdauer nutzen zu können? Ein attr hierfür wäre m.E. sinnvoll.
• Ich habe bisher noch keine Erfahrungen mit RGB in FHEM. Wie kann ich Colorwidgets mit dem Modul nutzen?

Ich bin absolut kein Perl-Experte, aber habe etwas Erfahrung mit diversen anderen Programmiersprachen und bin gelernter E-Techniker. Gern würde ich irgendwie im Rahmen meiner Möglichkeiten unterstützen falls Bedarf besteht.

Also nochmal, Hut ab vor eurem Engagement und der Expertise!!!

[pjakobs]

Mal ein kurzes Feedback von mir.

1. Zum Controller:
Top Leistung. Hab 2 fertige Module bekommen. Funktionieren tadellos, ota-Update hat auch geklappt. So im Nachhinein hätte ich gern noch ein/zwei Hardwareeingänge zum Ansteuern über den Standardlichttaster im Raum. Dann könnte ich das Teil auch ohne FHEM oder Web-Device für Raumbeleuchtung verwenden und Frauchen hätte keinerlei Gegenargumente (ist aber auch so akzeptiert obwohl vorher als Spielerei deklariert). Hab schon ein paar Ideen für's Kinderzimmer meiner Tochter.

dafür nehm ich keine Blumen an aber: ja, Hardware und Firmware sind klasse!

2. Zum FHEM-Modul:
Funktioniert bei mir problemlos im Einsatz seit einer knappen Woche. Nach etwas Recherche im Programmcode ist mir die Verwendung der Animationsdauer klar.
Was mir noch unklar ist:

• Wie sende ich mehrere Befehle um diese in einer Que abarbeiten zu lassen? Wäre z.B. für optische Notifications interessant (rotes Aufblinken etc.). Auch Sunset- und Sunrisesimulationen stell ich mir cool vor.
• Ist geplant für on, off, rotate etc. auch eine Animationsdauer nutzen zu können? Ein attr hierfür wäre m.E. sinnvoll.
• Ich habe bisher noch keine Erfahrungen mit RGB in FHEM. Wie kann ich Colorwidgets mit dem Modul nutzen?

Ich bin absolut kein Perl-Experte, aber habe etwas Erfahrung mit diversen anderen Programmiersprachen und bin gelernter E-Techniker. Gern würde ich irgendwie im Rahmen meiner Möglichkeiten unterstützen falls Bedarf besteht.

Also nochmal, Hut ab vor eurem Engagement und der Expertise!!!

Ich vermute, wenn Du Dir die aktuelle dev-pj Version greifst wirst Du sehen, dass Deine Wünsche schon erfüllt sind.

Animation sollte jetzt für alle settings funktionieren. Du kannst einfach

Code Auswählen Erweitern


set myLED on 5

senden und die LED werden innerhalb von 5 Sekunden von 0 auf die definierte Farbe faden. Definierte Farbe? Ja, es gibt jetzt ein attribut

Code Auswählen Erweitern


attr myLED defaultColor h,s,v

mit dem Du die Farbe einstellen kannst, die Du mit einem einfachen "on" haben willst - wenn Du nichts definierst ist es weiß mit 100% Helligkeit.

Wenn Du jetzt mehrere Befehle hintereinander ablaufen lassen willst, dann setzt Du einfach ein "q" (oder "Q") dazu: (da hast Du mich übrigens gerade noch dazu gebracht, schnell noch einen Bug zu fixen, jetzt funktioniert's )

Code Auswählen Erweitern


set myLED on 5 q; set myLED hsv 150,100,50 10 q;set myLED rotate 45 10 q


Und ja, jetzt funktionieren die Transitionen auch für alle Settings, also auch für Rotate. Du kannst mit L zudem noch angeben, ob Du vielleicht lieber "den langen Weg herum" gehen willst, sprich: wenn Du normalerweise von h=60 auf h=120 rotierst, dann läufst Du 60, 61, 62, ... 119, 120. Wenn Du das Flag "L" angibst, dann geht's 60, 59, 58, 57, ..., 1,360,359,...121, 120.
Du kannst auch q und l (oder L) gleichzeitig angeben, dann aber bitte nicht mit Leerzeichen trennen, als ql oder QL oder qL oder Ql.

Achtung: ich habe alle Settings in kleinschrift geändert, also nichts mehr mit

Code Auswählen Erweitern


set myLED RGB FF00FF

sondern jetzt

Code Auswählen Erweitern


set myLED rgb FF00FF

Zu den Widgets:
Wenn Du das normale webui verwendest, dann kannst Du in der Konfigurationsdatei z.B. folgendes angeben:

Code Auswählen Erweitern


define LED_Wo LedController 192.168.29.55
attr LED_Wo colorTemp 2700
attr LED_Wo defaultColor 120,20,80
attr LED_Wo defaultRamp 1000
attr LED_Wo webCmd rgb
attr LED_Wo widgetOverride rgb:colorpicker,rgb

(das sind meine Einstellungen)
Damit bekommst Du die "default" Farbtemperatur von 2700 (das muss @mrpj bei Gelegenheit mal erläutern)
eine default "on Color" von 120,20,80 (in hsv Notation)
Die "defaultRamp" gibt die länge einer Transition an, wenn Du keine explizit mitgibst.
Ein einfaches

Code Auswählen Erweitern


set myLED on

macht dann eben einen Fade von, in diesem Fall, 1000ms.

Durch die letzten zwei Zeilen den rgb Colorpicker im Frontend.

Wenn Du FTUI (also das Tablet UI) verwendest, dann kannst Du z.B. folgendes machen:

Code Auswählen Erweitern


     <div class="row container round bg-gray">
         <div data-type="switch" data-device='LED_Wo' data-on-background-color="LED_Wo:rgb" data-get-   on="dim.*|on" data-set-on="on" data-icon="fa-lightbulb-o" class="small col-1-4"> </div>
         <div class="col-1-2">Wohnzimmer Couch</div>
         <div data-type="symbol" id="ST_Wo" data-device='LED_Wo' data-get="" data-off-color="LED_Wo:    rgb" data-off-background-color="LED_Wo:rgb" data-icon="fa-ellipsis-h" data-background-icon="fa-circle- thin" class="small">
         </div>

         <div data-type="popup" data-height="320px" data-width="320px" data-mode="animate" data-        starter="#ST_Wo" class="col-1-6">
             <div class="dialog">
             <header>RBG COLOR</header>
             <div data-type="colorwheel" data-device='LED_Wo' data-get="rgb" data-set="rgb" class="big  roundIndicator">
             </div>
         </div>
       </div>
   </div>

(bin mir nicht 100% sicher, ich glaube aber, dass die </div> alle da sind...)

Bitte lass mich wissen, ob diese Version für Dich funktioniert, wenn ja, dann werde ich sie nach devel mergen und wir können hoffentlich bald eine neue stabile Version anbieten.

Grüße

pj

[pjakobs]

ach, und weil ich's vergessen habe:

was echt hilfreich wäre ist ganz viel testen und bugs reporten. Da sind sicher noch welche drin.
Ideen sind auch willkommen!
Und wenn Du was schreiben willst: Dokumentation wäre toll!

herzliche Grüße

pj

[uniqueck]

hab mal einen fork gemacht und einen struktur hergestellt, welche mit dem update all <url zum control file> arbeiten kann.
PR habe ich auch schon gestellt, werden dann mal noch schauen, was mir noch so einfällt.
klasse arbeit jungs wollte ich noch sagen.

[mrpj]

Ich freu mich gerade dass das Projekt wieder etwas Schwung aufgenommen hat  .

Mal ein kurzes Feedback von mir.

1. Zum Controller:
Top Leistung. Hab 2 fertige Module bekommen. Funktionieren tadellos, ota-Update hat auch geklappt.

Danke dir 

So im Nachhinein hätte ich gern noch ein/zwei Hardwareeingänge zum Ansteuern über den Standardlichttaster im Raum. Dann könnte ich das Teil auch ohne FHEM oder Web-Device für Raumbeleuchtung verwenden und Frauchen hätte keinerlei Gegenargumente (ist aber auch so akzeptiert obwohl vorher als Spielerei deklariert). Hab schon ein paar Ideen für's Kinderzimmer meiner Tochter.

Für Version 2.0 (in ferner Zukunft) stand ja die Idee an, SPI/IC2 und damit IO/s für eigene Abwandlungsideen zur Verfügung zu stellen. Die große Herausforderung bei Tastern ist, welche werden verwendet und welche Steuerung des Controllers wird wie übernommen. Für konkrete Umsetzungswünsche bin ich offen - ohne Feedback/Diskussion/Ergebnisse ist es schwer eine Funktion zu integrieren, von der ich nicht weiss wie es denn gedacht ist  .

Ein zweites Argument von mir: einen getrennten ESP nehmen der für die Ansteuerung (quasi als Fernbedienung) genutzt wird? Man kann den ESP auf einige uA runterbekommen, wenn man Wifi etc. abschaltet und deep sleep nutzt. Bei einem Input wird der ESP aufgeweckt, verbindet sich mit dem Wlan und sendet den Input raus und bleibt für X Sekunden/Minuten verbunden um weitere Inputs zu senden

Ich hab ja gestern schonmal versucht, die Diskussion abzubiegen, weil ich der Meinung bin, wir treiben viel Aufwand für wenig Gegenwert.
Ich glaube aber auch, dass wir noch ein kleines bisschen aneinander vorbei reden. Macht aber nix. Für mich kann der Controller stand heute alles, was ich für wesentlich halte.

Ich stimme dir da zu - aber solangsam kommen wir der Sache ja auf den Grund 

Wir haben einen kleinen Disconnect:
Du denkst darüber nach, wie Du die API so aufbaust, dass sie, egal welcher Kommunikationsweg eingeschlagen wird, die gleiche Syntax und Mächtigkeit bietet. Haken dran, unterschreib ich.

Ich sage: aufgrund der Natur eines Message Busses (eben mehrere Master, die asynchron Nachrichten verschicken können) kann hier weitere Funktionalität implementiert werden, die bei einem reinen Request/Response bzw. Client/Server Modell schwierig ist.

Ich verstehe dein Argument mit dem Rückkanal - ich möchte den Schritt mit der API weiter gehen, denn es ermöglicht später relativ einfach andere Protokolle aufzusatteln. (z.B. statt MQTT könnte man auch websockets nutzen - damit würde die Abhängigkeit eines MQTT Brokers wegfallen).

Ich überlege gerade welchen Weg wir gehen können um die Funktionalität zu erreichen. Hilfreich für mich wäre es wirklich, eine Absprache zu treffen, wie die Endpunkte/Topics für MQTT aussehen. Und bei der Betrachtung gleich die API mit einbeziehen bevor wir in die Position kommen, alles umzustrukturieren

Unterschreib ich, und da hast Du mich auch missverstanden. Das Modul ist, so wie ich es geschrieben habe, auch möglichst schlank und überlässt vieles dem Controller. Genau aus dem Grund verwende ich ja nur die API für HSV. Klar ist es möglicherweise mächtiger, RAW zu setzen, aber das untergräbt imho ein bisschen die Idee des Controllers, der ja eben viele Möglichkeiten der Farbanpassung bietet.

Ich stimme dir da vollkommen zu - der Vorteil des Controllers ist ja eben auf die internen Farbanpassungen zurück greifen zu können. Die RAW Elemente sind aus dem Wunsch in der Community entstanden - die Kanäle getrennt steuern zu können. (Um z.b. 5 verschiedene Weißkanäle zu haben die getrennt gesteuert werden können).
Ob nun RAW mächtiger ist, bezweifle ich etwas

war auch nicht als Feature Request gedacht sondern lediglich eine Idee, was man mit einem hoch aufgelösten Feedback vom Controller machen könnte. Mir fallen sonst - jenseits der Widgets - keine Anwendungen dafür ein.schönen Nachmittag!

Alles klar 





Da das Projekt wieder etwas mehr Schwung hat, werde ich gegen Ende der Woche meine Gedanken und Vorschläge für die Sammelbestellung 2 hier reinstellen.

[pjakobs]

Ich freu mich gerade dass das Projekt wieder etwas Schwung aufgenommen hat  .

absolut! Es wäre schön, wenn das dann auch zu mehr Momentum insgesamt führen würde, denn ich werde noch fünf Controller brauchen, die nächste Sammelbestellung naht also

Im übrigen sollten wir, was das fhem-Modul angeht, mal drüber nachdenken, wie wir das in fhem hinein bringen.

• gibt es einen Mindeststandard / Mindestumfang, damit wir das angehen?
• ist es sinnvoller, in WifiLight zu mergen und dieses Projekt hier separat zu halten?

Ich hab ja schon Kommentare à la "nichts wäre schlimmer als ein zusätzliches Modul" gelesen - und beim aktuellen Funktionsumfang bin ich der Meinung, wir verlieren nichts, wenn wir die gleiche Unterstützung in WifiLight einbauen.
Mich schreckt die Komplexität von WifiLight ein bisschen ab, das ganze color mapping brauchen wir hier imho nicht. Ich werd trotzdem nochmal drüber sehen.

pj

edit: gerade gesehen, @herrmanj ist der Maintainer von WifiLight - over to you Jörg! :-D

[pjakobs]

@funclass ich habe gerade einen bug in dev-pj behoben - die defaultRamp wurde nicht genutzt, funktioniert jetzt. Wenn Du also testen willst, vorher kurz die neue Version abholen

pj

[funclass]

hab die Version mal geladen. DefaultRamp funktioniert mit Angabe in Millisekunden. Dafür hast du die Angabe der Animationsdauer für die Set-Befehle jetzt auf Sekunden geändert. Das finde ich grundsätzlich nicht schlimm, aber ich kann scheinbar keine Kommawerte wie z.B. 0.1 übergeben. Wäre gut, wenn das möglich ist um Blinken etc. zu realisieren.

Außerdem habe ich ein Problem, wenn defaultColor nicht gesetzt ist. Dann ist on nicht möglich, da der hsv-Wert auf 0,, gesetzt wird.

Der Rest funktioniert nach ersten Tests fehlerfrei. 

An die Doku werd ich mich in den nächsten Tagen mal ran machen.

[pjakobs]

sollte jetzt beides funktionieren.
Die Ramp Time war eigentlich nicht als float vorgesehen, jetzt geht aber 0.5 etc (achtung: punkt, nicht komma!)
Die fehlende defaultColor war ein echter Bug, jetzt passt es - hoffe ich.

erstmal nur im dev-pj Zweig!

pj