Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Dann hilft die Änderung (siehe Anhang im letzten Post) wohl auch nicht...
Hmm, als RGB-Wert hätte das eigentlich gehen sollen...

Das mit der language-file wäre eine Möglichkeit, aber: Im Prinzip ist es sehr willkürlich, welche Keys es geben kann, und es ist dort etwas "unprominent" platziert. Einen Tweak mit rhasspyColors-Key und dann danach allen word2command-Paaren wäre m.E. besser (?): (grün="rgb 00FF00"). Dann könnte man diese Keys auch einfach noch in den slot packen, und die Commands gehen an die Devices, die den ersten Teil (hier: rgb) kennen...

Mit Umrechnungen beschäftigt sich Color.pm. Da gibt es aus einem guten Grund kein Hue2HEX (bzw. rgb): HUE hat afaik keinen Helligkeitsinhalt, RGB sehr wohl (deswegen gefällt mir auch Color mit HEX-Inhalt nicht so). Aber vermutlich hat sich schon jemand mit der Frage beschäftigt und es gibt fertige Formeln...
Bin mir übrigens auch nicht sicher, ob ein lineares Verständnis immer paßt. (Für meine RGBW-MiLights wohl schon, die "denken" anscheinend in einem Farbkreis).

(Generell: Da via gDT auch der Device-slot eingeehngt werden kann, ist diese ganze Kompabilitäts-Geschichte (bzw. der Aufwand, das ggf. anders als "entweder oder" zuzulassen) eh' eine Frage, die man aufwerfen sollte.)

[Beta-User]

Noch etwas schnell aufgefundene Theorie:

Evtl. sollte man HUE als 360° notieren?
Nö, man macht das jetzt so...

Na jedenfalls habe ich mal auf die Schnelle versucht, die Tabelle aus https://en.wikipedia.org/wiki/Hue#24_hues_of_HSL/HSV zu integrieren, und jetzt kommt auch "irgendwas" raus, wenn man Hue-Befehle auf "pure rgb"-Devices (wie die Stimmungsleuchte) losläßt...

Edit:
Und rhasspyColors habe ich dann auch gleich aus der Liste der globalen Attribute rausgenommen, cref ist entsprechend ergänzt, dass man das bei Bedarf von Hand machen soll.

[drhirn]

Nö, man macht das jetzt so...

Na jedenfalls habe ich mal auf die Schnelle versucht, die Tabelle aus https://en.wikipedia.org/wiki/Hue#24_hues_of_HSL/HSV zu integrieren, und jetzt kommt auch "irgendwas" raus, wenn man Hue-Befehle auf "pure rgb"-Devices (wie die Stimmungsleuchte) losläßt...

Und wie soll jetzt ein Device und ein sentence aussehen?

Edit:
Und rhasspyColors habe ich dann auch gleich aus der Liste der globalen Attribute rausgenommen, cref ist entsprechend ergänzt, dass man das bei Bedarf von Hand machen soll.

Gefällt mir gar nicht die Idee! Momentan.

War nicht der Plan, dass ich wieder anfange zu testen. Ich wollte mich eigentlich auf die Doku konzentrieren. Und jetzt finde ich knapp vor der Präsentation eine Unstimmigkeit nach der anderen. Deswegen wollte ich einen Feature-Freeze. Und die gDTs am Donnerstag nur am Rande als "in Arbeit" erwähnen. Geht jetzt natürlich nicht mehr.

[drhirn]

Hab heute wiedermal meinen physischen Satelliten in Betrieb genommen. siteId ist "Küche".
Der ist schon mal gelaufen, ich habe mit ihm getestet. Heute wird mir ein Reading "listening_k__che" erstellt, statt "listening_küche". Da hat sich aber nichts geändert, oder?

Weiters habe ich ein Device "thermKueche" mit gDT thermostat im Raum "Küche". Frage ich jetzt meinen Satelliten "wie warm ist es", antwortet der: Die Temperatur von Rhasspy beträgt 5°. Warum "Rhasspy"?

Code Auswählen Erweitern


         thermKueche:
           alias      heizung
           groups     temperatur
           names      heizung
           rooms      rhasspy,wetter,küche
           intents:
             GetNumeric:
               desired-temp:
                 currentVal desired-temp
                 type       desired-temp
               temperature:
                 currentVal temperature
                 type       temperature
             SetNumeric:
               desired-temp:
                 cmd        desired-temp
                 currentVal desired-temp
                 maxVal     28
                 minVal     10
                 step       0.5
                 type       temperature


Code Auswählen Erweitern


2021.04.23 14:36:30.542 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_GetNumeric => {"input": "temperature", "intent": {"intentName": "de.fhem:GetNumeric", "confidenceScore": 1.0}, "siteId": "küche", "id": null, "slots": [{"entity": "Type", "value": {"kind": "Unknown", "value": "temperature"}, "slotName": "Type", "rawValue": "wie warm ist es", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "rawEnd": 15}}], "sessionId": "küche-porcupine_raspberry-pi-8b193597-5ba7-43ef-b51e-158cab426e76", "customData": null, "asrTokens": [[{"value": "temperature", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}]], "asrConfidence": null, "rawInput": "wie warm ist es", "wakewordId": "porcupine_raspberry-pi", "lang": null}
2021.04.23 14:36:30.542 5: Parsed value: temperature for key: input
2021.04.23 14:36:30.543 5: Parsed value: wie warm ist es for key: rawInput
2021.04.23 14:36:30.543 5: Parsed value: 1 for key: probability
2021.04.23 14:36:30.543 5: Parsed value: GetNumeric for key: intent
2021.04.23 14:36:30.543 5: Parsed value: küche for key: siteId
2021.04.23 14:36:30.543 5: Parsed value: küche-porcupine_raspberry-pi-8b193597-5ba7-43ef-b51e-158cab426e76 for key: sessionId
2021.04.23 14:36:30.544 5: Parsed value: temperature for key: Type
2021.04.23 14:36:30.544 5: handleIntentGetNumeric called
2021.04.23 14:36:30.545 5: matches in room: thermKueche, matches outside: tempOutside thermWohnzimmer
2021.04.23 14:36:30.545 5: thermKueche
2021.04.23 14:36:30.545 5: Response is: Die Temperatur von rhasspy beträgt 5 Grad
2021.04.23 14:36:34.115 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "nominal"}, "sessionId": "küche-porcupine_raspberry-pi-8b193597-5ba7-43ef-b51e-158cab426e76", "siteId": "küche", "customData": "porcupine_raspberry-pi"}
2021.04.23 14:36:34.115 5: Parsed value: küche for key: siteId
2021.04.23 14:36:34.115 5: Parsed value: küche-porcupine_raspberry-pi-8b193597-5ba7-43ef-b51e-158cab426e76 for key: sessionId


[Beta-User]

Zwei Unterstriche deuten darauf hin, dass es irgendein Konvertierungsproblem ist. Gefühlt wurde an dem Teil des Codes nichts geändert.

Rhasspy ist der defaultRoom, da hat also was mit der Zuordung nicht gepaßt. Dachte erst, das hinge mit einer fehlenden lc-Anweisung zusammen, aber die stand am erwarteten Ort. eventuell war aber auch der Versuch des splits in RHASSPY_roomName() keine gute Idee (für die Satelitten-Gruppenfunktion), habe das jetzt geändert in substitution.

[drhirn]

Zwei Unterstriche deuten darauf hin, dass es irgendein Konvertierungsproblem ist. Gefühlt wurde an dem Teil des Codes nichts geändert.

Ich glaub eh auch, dass das an mir liegt. Aber ich verstehe nicht, wo das Problem sein könnte.

Wenn ich mir in onmessage $siteId und $room vor und nach der Umwandlung der Umlaute ausgeben lasse, sieht das so aus:

Code Auswählen Erweitern


2021.04.23 15:54:04.915 5: Parsed value: büro for key: siteId
$VAR1 = "b\x{c3}\x{bc}ro";
$VAR1 = "b\x{e3}\x{bc}ro";
$VAR1 = "b\x{e3}\x{bc}ro";


Und $hash liefert auch so komische Umlaute:

Code Auswählen Erweitern


'timerCancellation' => "\$label im \$room gel\x{c3}\x{b6}scht"


Bei einem list Rhasspy passt das aber. Und fetchSiteIds schreibt mir die siteIds auch mit Umlauten hin.

Das ist alles nicht ganz logisch. Kannst du das irgendwann bei dir mal testen bitte?

[drhirn]

Rhasspy ist der defaultRoom, da hat also was mit der Zuordung nicht gepaßt. Dachte erst, das hinge mit einer fehlenden lc-Anweisung zusammen, aber die stand am erwarteten Ort. eventuell war aber auch der Versuch des splits in RHASSPY_roomName() keine gute Idee (für die Satelitten-Gruppenfunktion), habe das jetzt geändert in substitution.

Ich denke, das hängt auch mit meinem Umlaut-Problem zusammen. Hat ja mal funktioniert. Und deine Änderung ändert nichts am Fehlverhalten.

[Beta-User]

Zum Konvertierungs-Thema kann ich im Moment nichts beitragen, es erinnert mich allerdings an die von JensS geschilderten Probleme. Mal sehen...

Zu dem Farb-Ding:
Es wäre vermutlich sinnvoll, eine "Variable" in den sentences zu definieren, die dann ausgewählte "Sprechfarben" in Hue-Werte übersetzt. Ansonsten kann man den bisherigen Satz auch entsprechend ändern:

Code Auswählen Erweitern

\[setze|färbe|stelle] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] (grün{Hue:120}|rot{Hue:0}|blau{Hue:240}|(warm weiss){Colortemp:100}|(kalt weiss){Colortemp:0}|(mittleres weiss){Colortemp:50})
Damit sollte sich jedes Device farblich direkt steuern lassen, das hue oder rgb als Kommando kennt und gDT "light" ist (das sollte eigentlich die ganz überwiegende Mehrzahl sein). Ob die Eingrenzung auf diesen Device-Teilslot es ermöglicht, daneben noch die anderen Devices über denselben sentence (aber Color-Content) abzufackeln, wäre die Frage.

Ein "Loch" war noch bei Colortemp2HEX (bzw. allgemein weiß oder grau). Dazu habe ich in Color.pm was gefunden, bin aber am Import gescheitert und hab's daher einfach als eine Art Klon eigebaut. Da ist mir aber auch erst mal unklar, wie der Wertebereich denn sinnvollerweise sein soll, eine 100-Skala wohl definitiv nicht. Hab jetzt mal die 0-100 auf den Bereich von 2000 bis 7000 gemappt (Anlehnung an FHEM-Wiki zu Color), mal schauen, ob das praxistauglich ist.

Das mit den globalen Attributen ist lediglich auskommentiert, also keine große Sache. Ich würde es trotz mancher (mAn. kleinerer!) Wackeligkeiten deaktiviert lassen, das war es übrigens bis 0.2.0 btw. auch.

Und wenn du Einsteiger interessieren willst, solltest du das gDT-Thema nicht außen vor lassen. Es ist mAn. soweit fertig, dass man sich eher in Ausnahmefällen noch mit eigenen Mappings beschäftigen wird...
(Bzgl. Testen: Das betrifft nur den Color-Teil; für den Rest ist es gleichgültig, wo das mapping herkommt).

[drhirn]

Zum Konvertierungs-Thema kann ich im Moment nichts beitragen, es erinnert mich allerdings an die von JensS geschilderten Probleme. Mal sehen...

Ja. Nur bei mir ändert auch das Setzen des "encoding" auf cp-irgendwas nichts. Wird nur noch schlimmer.

Es wäre vermutlich sinnvoll, eine "Variable" in den sentences zu definieren, die dann ausgewählte "Sprechfarben" in Hue-Werte übersetzt.

Ich hätte mir gedacht, wir schreiben für den Anfang in das language-file die z.B. HUE-Farben mit "hue angle".
Keinen genauen Plan, wie. Aber so z.B.:

Code Auswählen Erweitern


'colors' => {
  'red' => 0,
  'green' => 120,
...
}

Und im Code rechnen wir dann halt um. Je nach Setter.
Ist das realistisch?

Ob die Eingrenzung auf diesen Device-Teilslot es ermöglicht, daneben noch die anderen Devices über denselben sentence (aber Color-Content) abzufackeln, wäre die Frage.

Eben nicht. Device-light ist ja nur eine Untermenge von Device.

Das mit den globalen Attributen ist lediglich auskommentiert, also keine große Sache. Ich würde es trotz mancher (mAn. kleinerer!) Wackeligkeiten deaktiviert lassen, das war es übrigens bis 0.2.0 btw. auch.

Ja, war so. Und ich fand's lästig .

Und wenn du Einsteiger interessieren willst, solltest du das gDT-Thema nicht außen vor lassen. Es ist mAn. soweit fertig, dass man sich eher in Ausnahmefällen noch mit eigenen Mappings beschäftigen wird...

Keine Sorge. Ich werde gDT auf jeden Fall prominent erwähnen. Ich find's immer noch cool. Mich stört nur das Entweder-Oder bei den Lichtfarben. Aber andererseits, die drei bisherigen User werden's überleben wenn wir den Zopf abschneiden. Jens wird schimpfen, aber damit müssen wir leben

[drhirn]

Ich hätte mir gedacht, wir schreiben für den Anfang in das language-file die z.B. HUE-Farben mit "hue angle".
Keinen genauen Plan, wie. Aber so z.B.:

Code Auswählen Erweitern


'colors' => {
  'red' => 0,
  'green' => 120,
...
}

Und im Code rechnen wir dann halt um. Je nach Setter.

Achso, ich vergaß. Und aus den Farben im Language-File machen wir einen Slot "colors". Der kann dann in die Sentences eingebaut werden.

[Beta-User]

Ja. Nur bei mir ändert auch das Setzen des "encoding" auf cp-irgendwas nichts. Wird nur noch schlimmer.

Schade, aber wenig überraschend. Evtl. auch nur ein Darstellungsproblem, oder wir müssen irgendwie die Verwendung von UTF8 erzwingen (da gibt es ein "use", wenn ich das richtig im Kopf habe).


Ich hätte mir gedacht, wir schreiben für den Anfang in das language-file die z.B. HUE-Farben mit "hue angle".
Keinen genauen Plan, wie. Aber so z.B.:

Code Auswählen Erweitern


'colors' => {
  'red' => 0,
  'green' => 120,
...
}

Und im Code rechnen wir dann halt um. Je nach Setter.
Ist das realistisch?

Realistisch ja, aber "gefühlt" im Kreis rum. Eher anders herum für "backwards"-Kompabilität, also "mach aus einer Ziffer ein (deutsches) Wort - und vergleiche das dann mit dem, was in rhasspyColors drin steht.
Dann ist es m.E. einfacher und deutlich weniger fehleranfällig, der User mappt das in seinem Attribut. (wobei er dann HEX-Werte nach Color packen müßte; auch nicht lustig).

Achso, ich vergaß. Und aus den Farben im Language-File machen wir einen Slot "colors". Der kann dann in die Sentences eingebaut werden.

Hmm, (irgendwie) denkbar. Sehe aber im Moment nicht den großen Vorteil zu einer für die sentences.ini vorbereiteten Variable. Das ist ja (im Prinzip) in jeder deutschen Konfiguration gleich.

Andere Option noch für "backwards compability" (aber auch ohne slots): Kann man ein "Doppel-tag" vergeben? also:

Code Auswählen Erweitern

\[setze|färbe|stelle] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] (grün{Hue:120}{Color}|rot{Hue:0}{Color}|blau{Hue:240}{Color}|(warm weiss){Colortemp:100}|(kalt weiss){Colortemp:0}|(mittleres weiss){Colortemp:50})

Eben nicht. Device-light ist ja nur eine Untermenge von Device.

OK, klar, Überschneidungen sind immer schwierig...

Ja, war so. Und ich fand's lästig .

Meine Idee war jetzt, das wieder lästig zu machen, damit es nur noch die nutzen, die das haben oder unbedingt wollen ...

Keine Sorge. Ich werde gDT auf jeden Fall prominent erwähnen. Ich find's immer noch cool. Mich stört nur das Entweder-Oder bei den Lichtfarben. Aber andererseits, die drei bisherigen User werden's überleben wenn wir den Zopf abschneiden. Jens wird schimpfen, aber damit müssen wir leben

Ebend. Und es funktioniert ja auf die alte Weise immer noch. Ist nur eben "entweder-oder" (es sei denn, das mit den Doppeltags geht!).

[drhirn]

Schade, aber wenig überraschend. Evtl. auch nur ein Darstellungsproblem, oder wir müssen irgendwie die Verwendung von UTF8 erzwingen (da gibt es ein "use", wenn ich das richtig im Kopf habe).

Keine Ahnung. Ich weiß nur, dass ich keine Ahnung habe, was ich geändert haben könnte. Bin der Meinung nichts. Und ich gerade keine siteIds mit Umlauten verwenden kann. Ich hab schon mal meine ganze Test-Umgebung neu gemacht. Das hat nichts geändert.

Realistisch ja, aber "gefühlt" im Kreis rum. Eher anders herum für "backwards"-Kompabilität, also "mach aus einer Ziffer ein (deutsches) Wort - und vergleiche das dann mit dem, was in rhasspyColors drin steht.

Ich dachte, wir haben uns darauf geeinigt, den Zopf abzuschneiden

Sehe aber im Moment nicht den großen Vorteil zu einer für die sentences.ini vorbereiteten Variable. Das ist ja (im Prinzip) in jeder deutschen Konfiguration gleich.

Ist richtig, ist immer gleich. Aber der User kann's ändern, wenn er das möchte. Oder neue Farben hinzufügen.

Andere Option noch für "backwards compability" (aber auch ohne slots): Kann man ein "Doppel-tag" vergeben?

Leider nein. Wird dann nur der jeweils letzte genommen.

[drhirn]

Jetzt bin ich verwirrt! Mein Farblicht wird immer auf HUE 0 geschalten, RGB bleibt gleich.

Code Auswählen Erweitern


defmod Farblicht dummy
attr Farblicht genericDeviceType light
attr Farblicht group Lampen
attr Farblicht icon light_fairy_lights
attr Farblicht readingList rgb hue
attr Farblicht room Rhasspy,Wohnzimmer
attr Farblicht setList on off rgb hue


Code Auswählen Erweitern


2021.04.23 17:11:07.002 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetColor => {"input": "setze farblicht auf 240", "intent": {"intentName": "de.fhem:SetColor", "confidenceScore": 1.0}, "siteId": "default", "id": "5a4eeff9-d231-4b9b-ab38-beb56eb938d9", "slots": [{"entity": "de.fhem.Device-light", "value": {"kind": "Unknown", "value": "farblicht"}, "slotName": "Device", "rawValue": "farblicht", "confidence": 1.0, "range": {"start": 6, "end": 15, "rawStart": 6, "rawEnd": 15}}, {"entity": "Hue", "value": {"kind": "Unknown", "value": "240"}, "slotName": "Hue", "rawValue": "blau", "confidence": 1.0, "range": {"start": 20, "end": 23, "rawStart": 20, "rawEnd": 24}}], "sessionId": "5a4eeff9-d231-4b9b-ab38-beb56eb938d9", "customData": null, "asrTokens": [[{"value": "setze", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "farblicht", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 15, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 16, "rangeEnd": 19, "time": null}, {"value": "240", "confidence": 1.0, "rangeStart": 20, "rangeEnd": 23, "time": null}]], "asrConfidence": null, "rawInput": "setze farblicht auf blau", "wakewordId": null, "lang": null}
2021.04.23 17:11:07.002 5: Parsed value: 240 for key: Hue
2021.04.23 17:11:07.003 5: Parsed value: setze farblicht auf blau for key: rawInput
2021.04.23 17:11:07.003 5: Parsed value: farblicht for key: Device
2021.04.23 17:11:07.003 5: Parsed value: 1 for key: probability
2021.04.23 17:11:07.003 5: Parsed value: setze farblicht auf 240 for key: input
2021.04.23 17:11:07.003 5: Parsed value: 5a4eeff9-d231-4b9b-ab38-beb56eb938d9 for key: sessionId
2021.04.23 17:11:07.004 5: Parsed value: default for key: siteId
2021.04.23 17:11:07.004 5: Parsed value: SetColor for key: intent
2021.04.23 17:11:07.004 5: handleIntentSetColor called
2021.04.23 17:11:07.004 5: Device selected (by hash, with room and name): Farblicht
2021.04.23 17:11:07.005 5: Response is: OK


[Beta-User]

Keine Ahnung. Ich weiß nur, dass ich keine Ahnung habe, was ich geändert haben könnte. Bin der Meinung nichts. Und ich gerade keine siteIds mit Umlauten verwenden kann. Ich hab schon mal meine ganze Test-Umgebung neu gemacht. Das hat nichts geändert.

Schreib mal bei den "use"-Anweisungen vorne noch "use utf8;" dazu. Schadet vermutlich nicht.

Ich dachte, wir haben uns darauf geeinigt, den Zopf abzuschneiden

Ebend.
Wie vorhin mal geschrieben: der einzige Grund, künftig das Colors-Attribut zu nutzen könnte höchstens darin bestehen, dass eine individuelle Korrektur der Farbe her muss, weil z.B. eines von zwei Leuchtmitteln in einer Gruppe "rot" anders interpretiert. Das wäre dann aber eh' ein Problem, wenn man "nur" Hue sendet, weil bisher das Mapping via Attribut "Color" voraussetzt.
(Dürfte aber nicht schwierig sein, da bei Bedarf was zu basteln.)

Ist richtig, ist immer gleich. Aber der User kann's ändern, wenn er das möchte. Oder neue Farben hinzufügen.

Na ja, im Prinzip kann er 360 Farben haben; für den Anfang würde ich dazu neigen, die 24 Segmente aus der en-Wikipedia zu übernehmen und dafür (de-) Namen zu zeigen?

Leider nein. Wird dann nur der jeweils letzte genommen.

(schade, dann also s.o.)

Jetzt bin ich verwirrt! Mein Farblicht wird immer auf HUE 0 geschalten, RGB bleibt gleich.

Code Auswählen Erweitern


attr Farblicht setList on off rgb hue


hue braucht ZWINGEND einen Wertebereich (aus getAllSets(), kann also vermutlich auch aus widgetOverride kommen). Wenn es das Kommando in der Wirklichkeit gibt, dann ist der vorhanden. Sonst ist es 0 bis 0...

[Beta-User]

Habe im Nachgang zu gestern dann noch die Funktionen umbenannt, hoffe, das passt so.

Hier dann noch der Versuch, den "Hue-Farbkreis" zu übersetzen:

Code Auswählen Erweitern


[de.fhem:SetColor]
colors=( rot{Hue:0} | orangerot{Hue:15} | orange{Hue:30} | goldgelb{Hue:45} | ([(zitrus|zitronen)] gelb){Hue:60} | (gelb grün){Hue:75} | (grün gelb){Hue:90} | ((grass|hell) grün){Hue:105} | grün{Hue:120} | (dunkel grün){Hue:135} | (smaragd grün | wasser blau){Hue:150} | (türkis [grün] | grün blau ){Hue:165} | (türkis [blau] | blau grün ){Hue:180} | (azur [blau]){Hue:210}  | ([blau] violet){Hue:225} | ([marine] blau){Hue:240} | ([blau] violet){Hue:255} | (rosa){Hue:270} | (purpur [blau]){Hue:285} | (magenta [blau]){Hue:300} | (alt rosa){Hue:315} | (rubin rot){Hue:330} | (karmin rot){Hue:345} )
\[setze|färbe] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf die Farbe] (<colors> | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )

[de.fhem:SetColorGroup]
\[setze|färbe] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}]  [auf die Farbe] (<de.fhem:SetColor.colors> | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )

Leider ist es mir bisher auch nicht gelungen, "doppelte keys" für eine Farbe zu erzeugen, wenn es wirklich (noch) wichtig ist, könnten wir auch mal im Rhasspy-Forum nachfragen, ob bzw. wie das ggf. geht.
Eigentlich wollte ich jetzt schreiben, dass das für meine Bedürfnisse jetzt ist ziemlich cool ist... ABER: es hängt sehr bei den HUEDevices stark (zu stark?) davon ab, wo man startet, vermutlich, was die Sättigung angeht. (Doch lieber Rgb-Werte übergeben) Hmmm, unschön...

Aber jetzt ist erst mal anderes dran.