ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[pjakobs]

ok, mqtt ist wäre eine alternative Implementierung.

Stand heute ist das fhem modul ja auf der json api, und die sendet nix zurück, also zumindest keine device-events auser "ok" oder "falsch"

Angenommen wir gehen hier von einer mqtt unabhängigen Lösung aus bleint die Fragestellung bestehen. Das "mitrechnen" würde die device-events ersetzen sollen.. Du schreibst . Wo siehst Du Herausforderung ? Evtl übersehe ich da was.

vg
joerg

vielleicht stell ich's mir auch nur zu schwierig vor, aber: Du müsstest die Queue lokal vorhalten (und deshalb das Verhalten auch lokal nachbilden), Du müsstest das Timing wenigstens halbwegs synchron hinbekommen - was ja durchaus mal über ein paar Sekunden hinweg schwierig sein kann etc.
Ich denke, wenn wir von einer Transition reden, dann ist das kein Problem, aber sobald wir mehr wollen find ich den Aufwand zu hoch.

Wie gesagt: über MQTT würden wir die tatsächlichen Werte vom Controller quasi geschenkt bekommen.

pj

[herrmannj]

ich habe evtl eine Idee:

@mprj:

wäre es möglich den Endppoint (oder einen neuen) wo man jetzt die Farbe abfragt (getColor) um Informationen zu ergänzen:

* Ob in einer Transition.
* Ideal: Daten der Transition, von wo nach wo, wie lange.
* sind weitere Trabsitions ge-queued.

Dann könnte man tatsächlich gut pollen und die polls mit den Angaben sinnvoll optimieren.

Sprich: wenn ich weiß das eine Transition von 0,100,80 nach 0,100,100 über 600Sekunden läuft kann ich anschätzen das ich erst in 10 Sekunden wieder polle. Bei schnelleren fades schauen wir öfter, aber eben max 250msec oder so.

Ginge das ?

vg
joerg

edith: sorry überschnitten ...

[pjakobs]

@herrmannj:

das wäre zumindest förderlich, weil Du auf diesem WEg Fixpunkte sammeln könntest. Damit könnte ich leben, denk ich.

pj

[herrmannj]

Schön. Dann wollen wir mal hoffen das wir die Rechnung nicht ohne den Wirt gemacht haben #mprj 😏

[mrpj]

Pf@nne hat an einer MQTT Anbindung gearbeitet - doch gerade steht das ganze etwas.

Hintergrund:
Im Moment wird die API direkt bei den HTTP Endpunkten verarbeitet - um mqtt (und evtl websockets) sinvoll zu nutzen würde ich eine gemeinsame API (nur über unterschiedliche Transportwege) vorschlagen. Ich habe zu wenig mit MQTT bisher getan, als das ich abschätzen kann ob es Sinn macht eine JSON API via MQTT zu veröffentlichen.

Wenn wir diese Richtung einschlagen wollen, würde es ein größeres refactoring des codes nach sich ziehen - so dass die API ausgegliedert wird.

Habt ihr mehr Erfahrungen mit MQTT? Macht es Sinn oder wiederspricht es dem Prinzip hinter MQTT?

@mprj:

wäre es möglich den Endppoint (oder einen neuen) wo man jetzt die Farbe abfragt (getColor) um Informationen zu ergänzen:

* Ob in einer Transition.
* Ideal: Daten der Transition, von wo nach wo, wie lange.
* sind weitere Trabsitions ge-queued.

Der Endpunkt ist mit den Informationen erweiterbar - hier sollten wir "Transition" mit Animation generalisieren.
Im Moment gibt es 2 Animationen:
- Transition/Fade (von Farbe X) nach Farbe Y in Zeit t
- Zeige Farbe A für (mindestens) Zeit t

Geplant ist noch ein weiteres Element: "Animationset" - eine Liste bestehend aus Animationselementen die dem Controller übergeben wird. Diese List ist ein einzelnes Element in der internen Queue des Controllers und hat die Besonderheit sich wiederholen (loop) zu können.

Ich überlege gerade wie man den Endpunkt für das abfragen gestalten kann. Den Endpunkt /color würde ich gerne als reine Abfrage des aktuellen Farbwertes beibehalten. Für mich macht es mehr (semantischen) Sinn den Endpunkt /queue oder /animation zu nehmen - der speziell die Informationen die ihr braucht bereit stellt. (Inklusive der Abfrage der kompletten Q?)

@hermannj
Ich bin immernoch offen die API auch via websocket zur Verfügung zu stellen

[mrpj]

Noch ein Nachtrag zu MQTT - im Grunde wollte ich das wie ein vereinfachtes JSON-RPC Protokoll nutzen.

Der MQTT Endpunkt könnte z.B. esprgbww1 sein. Die Befehle die Ankommen könnten in dieser Struktur sein:

Code Auswählen Erweitern


{
"cmd": "post",
"resource": "color",
"body": {
             "h": 100,
              ....
}
}


Alternative

Code Auswählen Erweitern


{
"cmd": "postColor",
"body": {
             "h": 100,
              ....
}
}


[pjakobs]

offen gestanden habe ich bisher nur mit einem MQTT subscriber, nie einem publisher gearbeitet.
Ich denke aber dass es im Grunde relativ simpel ist: Du hast ja nicht wirklich Endpoints sondern "Topics", ein Topic könnte sein
/LedController/{instance}/current/rgb,
wie oben beschrieben könnte ich lokal ein Reading darauf subscriben, so dass das Reading jedes Mal dass eine Nachricht über den Broker kommt upgedatet wird.
Du würdest auf deiner Seite "einfach" regelmäßig den aktuellen rgb Wert publishen, etwa so

Code Auswählen Erweitern


public static final String TOPIC_RGB = "current/rgb;

     //...
     while (true)
     {
          publishRGB(rgb);
          Thread.sleep(500);
     }
     //...

     private void publishRGB(rgb) throws MqttException {
         final MqttTopic RGBTopic = client.getTopic(TOPIC_RGB);

        RGBTopic.publish(new MqttMessage(RGB.getBytes()));
     }

(nur symbolisch, so nie selbst geschrieben)

Aber: auf diesem Weg könnte man schnell, einfach und ohne Polling den aktuellen Wert übermitteln.

Ich würde MQTT auch nicht unbedingt als Ersatz für das REST Interface sehen, REST ist prima für Kommandos, MQTT prima für Readings.

pj

[mrpj]

offen gestanden habe ich bisher nur mit einem MQTT subscriber, nie einem publisher gearbeitet.
Ich denke aber dass es im Grunde relativ simpel ist: Du hast ja nicht wirklich Endpoints sondern "Topics", ein Topic könnte sein
/LedController/{instance}/current/rgb,

Ich bin im Moment erstmal von Seiten des Controllers ausgegangen.
Es gibt hier viele Möglichkeiten - z.B. das der Controller nur auf seiner ID lauscht und der Broker verschiedene Topics multiplext - z.B. der channel mit der ID rgbww1234 gehört der Gruppe /rgbwwcontroller an. Bedeutet eine direkte Nachricht erreicht den Controller, eine nach an /rgbwwcontroller erreicht alle controller.

Den Rückkanal hatte ich noch gar nicht betrachtet

wie oben beschrieben könnte ich lokal ein Reading darauf subscriben, so dass das Reading jedes Mal dass eine Nachricht über den Broker kommt upgedatet wird.
Du würdest auf deiner Seite "einfach" regelmäßig den aktuellen rgb Wert publishen, etwa so

Aber: auf diesem Weg könnte man schnell, einfach und ohne Polling den aktuellen Wert übermitteln.

Hier sollten wir genauer das Verhalten des Controllers definieren - denn z.B. mMn braucht der Controller nicht alle 500ms im Netzwerk ein Packet mit dem aktuellen Wert schicken, wenn sich nichts verändert hat. Auch ist mir wichtig, dass eine mögliche MQTT Anbindung keine "Insellösung" wird, sondern eine Kompatbilität zu den Funktionen des Endpunkts get /color aufweist.

Ich würde MQTT auch nicht unbedingt als Ersatz für das REST Interface sehen, REST ist prima für Kommandos, MQTT prima für Readings.

Die REST Schnittstelle wird auch nicht entfernt - aber es macht sicherlich Sinn auf verschiedenen Transportwegen/protokollen die selbe Funktionalität bereit zu stellen.

[pjakobs]

Ich bin im Moment erstmal von Seiten des Controllers ausgegangen.
Es gibt hier viele Möglichkeiten - z.B. das der Controller nur auf seiner ID lauscht und der Broker verschiedene Topics multiplext - z.B. der channel mit der ID rgbww1234 gehört der Gruppe /rgbwwcontroller an. Bedeutet eine direkte Nachricht erreicht den Controller, eine nach an /rgbwwcontroller erreicht alle controller.

klar, ist ne Möglichkeit um eben auch mehrere gleichzeitig anzusprechen.

Den Rückkanal hatte ich noch gar nicht betrachtet

den find ich in dem Fall viel interessanter, weil er eben ohne polling auskommt

Hier sollten wir genauer das Verhalten des Controllers definieren - denn z.B. mMn braucht der Controller nicht alle 500ms im Netzwerk ein Packet mit dem aktuellen Wert schicken, wenn sich nichts verändert hat. Auch ist mir wichtig, dass eine mögliche MQTT Anbindung keine "Insellösung" wird, sondern eine Kompatbilität zu den Funktionen des Endpunkts get /color aufweist.

nein, natürlich nicht alle 500ms sondern nach Bedaf, das kann heißen, immer wenn das RGB Setting verändert wurde und nicht häufiger als alle 50ms, als Beispiel, denn Du willst die anderen Endpoints ja auch nicht flooden.
Was die Kompatibilität mit den REST Endpoints angeht, da sehe ich kein Problem. Du würdest doch vermutlich den MQTT service nur an die internen Werte anflanschen, also;

Du hast heute eine interne Repräsentation der Luminanz aller 5 Kanäle

r, g, b, ww, cw

Wenn ich get /color/raw  schicke, dann gibst Du mir diese fünf Werte zurück.

Wenn Du nun den MQTT publisher anflanschst, dann würdest Du den aufrufen, wenn die Werte geändert werden, also wäre der Wert, der über MQTT gepublished wird und der Wert, den ich per get /color/raw bekomme immer gleich (es sei denn, Du limitierst, wie oben gesagt, die Rate der Updates bei schnellen Transitions).

Die REST Schnittstelle wird auch nicht entfernt - aber es macht sicherlich Sinn auf verschiedenen Transportwegen/protokollen die selbe Funktionalität bereit zu stellen.

Nö, das wäre auch garnicht nötig, wie gesagt: das sind unterschiedliche Zugriffsmethoden auf die gleichen internen Daten.

pj

[herrmannj]

mqtt war doch sowieso parallel geplant.

Ich sehe jetzt von der REST / JSON Seite keine Notwendigkeit, weder mqtt noch websocket.

Warum wieder Schritte zurückgehen, so passt doch alles. MQTT kann man ja parallel weiter entwickeln und komplett in mqtt integrieren.

Wenn Du den "get /color" endpoint lassen möchtest dann würde ich diese Erweiterung so vorschlagen:

Code Auswählen Erweitern

GET /extended

{
  "hsv": {
    "h": 75.0,
    "s": 75.0,
    "v": 75.0,
    "ct": 3500
  },
  "transition": {
    "mode": fade
    }, {
    "from": {
      "h": 50.0,
      "s": 50.0,
      "v": 50.0,
      "ct": 3000
    }, {
      "to": {
       "h": 100.0
       "s": 100.0
       "v": 100.0
       "ct": 4000
    }, {
      "span": 60.0,
      "left": 30.0,
    }, {
     "queue": 5
    }
}


Muss man evtl noch etwas tunen um "Animationset" mit unterzubringen.

Mehr brauchts nicht damit es rund ist.

vg
joerg

[pjakobs]

@herrmannj, @mrpj

vielleicht gehen wir noch einen Schritt zurück und fragen uns: ist die Frage, ob die Readings während einer Transition immer gültig sind wirklich unser vordringlichstes ToDo?
Vom Standpunkt der Softwarearchitektur würde ich die MQTT Lösung weiterhin für die eleganteste halten, aber: mir ist's ehrlich gesagt wuscht, ob das in den nächsten zwei, drei Monaten kommt oder nicht. Für mich wäre das nur die Frage, ob der Button im FT-UI während der Animation den richtigen Farbton zeigt oder nicht.

Was sind denn die wirklich relevanten ToDos?
Wie gesagt: bei mir läuft das Teil mittlerweile problemlos als Wohnzimmerbeleuchtung, gesteuert durch ein FHEM colorwheel Widget, in der Version, die ich im github habe ist momentan für jede set HSV Änderung eine Transition über vier Sekunden eingetragen - das sollte ein attr werden, denke ich. Direkte funktionale Requirements hab ich jetzt eigentlich keine mehr, wiewohl sich sicher noch viel machen lässt. Ich mochte die Idee der set extensions ganz gerne, vor allem ein "on-for-timer", denn das lässt sich natürlich prima mit einer Abwesenheitserkennung zur Anwesenheitssimulation verbinden.

Also meine Bitte: lasst uns Requirements sammeln und sie dann geordnet angehen. Am Thema valide Werte während Transitionen sind wir doch gerade nur deshalb dran, weil wir unterschiedliche Vorstellungen haben, oder?

Und weil ich ja auch selbst keine Ruhe geben kann: das SMING MQTT Beispiel zeigt eigentlich, dass es ziemlich simpel ist, aktuelle Werte zu publishen. Ich fürchte, das Komplexeste daran dürfte sein, den Bus nicht zu überlasten - die maximale Änderungsrate des Controllers wäre wohl ca. 360Hz (ein Fade von hue=0 nach 359 über den 'langen Weg' in einer Sekunde. Darüber, ob das sinnvoll ist kann man streiten, da der Mensch vermutlich schon bei 50 Abstufungen einen flüssigen Ablauf sehen würde) und ich würde man ganz grob sagen, dass  ich die Update-Rate unter 20Hz halten wollen würde - das ist mehr ein Gefühl als ein irgendwie belegter Wert.

Aber wie gesagt: technisch interessant, praktisch aus meiner Sicht nicht wirklich vordringlich.

pj

[mrpj]

Ich muss kurz nochmal was aufklären:

Blöde Frage zum Ausschalten der LED-Kette gibt es bisher keine Möglichkeit?

Einfach die Farbe setzen, in diesem Fall halt dann "Schwarz", also HSB=0,0,0

Wenn die LED ausgeschaltet werden sollen muss nur der B(bzw. V Wert) auf 0 gesetzt werden. Angenommen wir haben den Farbwert H(60,100,100) - die Farbe H(0,0,0) würde einen Übergang zwischen Hue 60 -> 0, Saturation 100 -> 0 und Value 100 -> 0 erfordern.
Bei der selben Farbe/Weißanteil reicht es aus von Value 100 -> 0 zu faden um die Leds auszuschalten.
Analog dazu: es ist sinnvoll beim "Einschalten" Hue/Saturation zu setzen, bevor der Fade für Value angefangen wird.

@herrmannj
Deinen Vorschlag muss ich mir erstmal durch den Kopf gehen lassen - im Moment schottet die RGBWW Library von mir die Interna nach außen hin ab. (Mit der Annahme, wenn ich einen Befehl aufgebe, sind mir die Start/Endwerte bekannt).
Hingegen Elemente in der Queue und der aktuelle Farbwert sind kein Problem.

Vom Standpunkt der Softwarearchitektur würde ich die MQTT Lösung weiterhin für die eleganteste halten, aber: mir ist's ehrlich gesagt wuscht, ob das in den nächsten zwei, drei Monaten kommt oder nicht. Für mich wäre das nur die Frage, ob der Button im FT-UI während der Animation den richtigen Farbton zeigt oder nicht.

MQTT ist sicherlich spannend, wie zuvor geschrieben wäre es mir wichtig ein Definition für die Kommunikation festzulegen (sozusagen die API für MQTT). Meine Präferenz wäre es, eine generalisierte API zu haben, deren Kommunikationsweg nur austauschbar ist. (Hinsichtlich der Codepflege in Zukunft)

Generell stellt sich für mich die Frage: Warum muss der Knopf im FHEM frontend animiert sein? Reicht es nicht wenn der Endwert gesetzt wird. (Wie es derzeit in der Webapp auch ist) ?

Was sind denn die wirklich relevanten ToDos?

Ich denke du gehst hier von dem FHEM Modul aus - denn für den Controller sehe ich gerade (noch) wenig ToDos in dem Aspekt (bis auf meine eigene Liste an Ideen und Wünschen)

Und weil ich ja auch selbst keine Ruhe geben kann: das SMING MQTT Beispiel zeigt eigentlich, dass es ziemlich simpel ist, aktuelle Werte zu publishen. Ich fürchte, das Komplexeste daran dürfte sein, den Bus nicht zu überlasten - die maximale Änderungsrate des Controllers wäre wohl ca. 360Hz (ein Fade von hue=0 nach 359 über den 'langen Weg' in einer Sekunde. Darüber, ob das sinnvoll ist kann man streiten, da der Mensch vermutlich schon bei 50 Abstufungen einen flüssigen Ablauf sehen würde) und ich würde man ganz grob sagen, dass  ich die Update-Rate unter 20Hz halten wollen würde - das ist mehr ein Gefühl als ein irgendwie belegter Wert.

Der Controller hat eine feste Updaterate von 50hz bzw. alle 20ms kann ein neuer Wert gesetzt werden. Die Farbübergänge werden derzeit nach diesem Schema berechnet:
- teile die Zeit t in 20ms Schritte x
- für jedes dx berechne dy des jeweiligen Farbwertes mit Hilfe einer modifizierten Version des Bresenham Algorithmus

Um die 50hz konstant zu erreichen, wird jeder neue Farbwert für den Schritt n im vorherigen Schritt (n-1) berechnet und erst in Schritt n ausgegeben.

[pjakobs]

MQTT ist sicherlich spannend, wie zuvor geschrieben wäre es mir wichtig ein Definition für die Kommunikation festzulegen (sozusagen die API für MQTT). Meine Präferenz wäre es, eine generalisierte API zu haben, deren Kommunikationsweg nur austauschbar ist. (Hinsichtlich der Codepflege in Zukunft)

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 stelle mir das so vor:

Richtung	REST	MQTT
fhem->controller	json coded API commands	json coded API commands
controller->fhem		updates of selected readings

Generell stellt sich für mich die Frage: Warum muss der Knopf im FHEM frontend animiert sein? Reicht es nicht wenn der Endwert gesetzt wird. (Wie es derzeit in der Webapp auch ist) ?

das war nur mein Gedanke, ich weiss nicht, was @herrmannj mit den kontinuierlichen Updates vorhat, vielleicht hat er ja noch andere Ideen.

Ich denke du gehst hier von dem FHEM Modul aus - denn für den Controller sehe ich gerade (noch) wenig ToDos in dem Aspekt (bis auf meine eigene Liste an Ideen und Wünschen)

ja, klar, sorry

Der Controller hat eine feste Updaterate von 50hz bzw. alle 20ms kann ein neuer Wert gesetzt werden. Die Farbübergänge werden derzeit nach diesem Schema berechnet:
- teile die Zeit t in 20ms Schritte x
- für jedes dx berechne dy des jeweiligen Farbwertes mit Hilfe einer modifizierten Version des Bresenham Algorithmus

Um die 50hz konstant zu erreichen, wird jeder neue Farbwert für den Schritt n im vorherigen Schritt (n-1) berechnet und erst in Schritt n ausgegeben.

passt, solltest 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.

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

pj

[herrmannj]

Korrekt.

Stand heute ist die Funkitionialität des Controller mMn ausgewachsen und sehr gut.

Wo gehts also weiter ?

das war nur mein Gedanke, ich weiss nicht, was @herrmannj mit den kontinuierlichen Updates vorhat, vielleicht hat er ja noch andere Ideen.

Zum Beispiel da. Ich bin ja auhc fronthem / smartVisu verheiratet, die fhemweb und sicher auch FTUI Interfaces brauchen das auch.

vg
joerg

[pjakobs]

Korrekt.

Stand heute ist die Funkitionialität des Controller mMn ausgewachsen und sehr gut.

sehe ich auch so.

Wo gehts also weiter ?

Ich denke, im fhem-Modul gibt's schon noch ein paar Dinge aufzuräumen, schau mal auf die README

Zum Beispiel da. Ich bin ja auhc fronthem / smartVisu verheiratet, die fhemweb und sicher auch FTUI Interfaces brauchen das auch.

na ja, ich nutze FTUI und kann damit leben, dass die rgb Anzeige den Endwert darstellt. Ich weiß ehrlich gesagt garnicht, ob FTUI mit sehr schnellen push updates umgehen könnte, müsste man testen.

Grüße,

pj