Modulentwicklung für Rhasspy Sprachassistent

Begonnen von drhirn, 11 März 2021, 15:59:50

Vorheriges Thema - Nächstes Thema

Beta-User

Mit dem missing slot muss ich mal schauen (geht aber nicht vor heute abend), ich nutze den gar nicht mehr, sondern die Hue-Variante. Das hat m.E. den Vorteil, dass das nur den Farbwert wiederspiegelt und man sich am Ende darauf beschränken könnte, den erforderlichenfalls in RGB umzuwandeln (was aber dann die Ermittlung eines "guten" Helligkeitswerts voraussetzt, wenn das Zielgerät nur rgb kann.

Betr. RGB ist es so, dass RHASSPY das (zumindest im Moment noch) gerne ohne den "#"-Vorsatz hätte. Ggf. kannst du den Filter auch aufbohren, kommt aber darauf an, was das jeweilige Gerät versteht (also ggf: das # löschen).

Ansonsten sehe ich jetzt auf die Schnelle nichts, was gegen die Steuerbarkeit des Testdevices spräche (ggf. mal das RHASSPY-list kontrollieren).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

drhirn

Bei siteId2room hat's was mit dem Encoding:

setstate Rhasspy 2021-04-23 09:50:05 siteId2room_wohnzimmer b�ro

Beta-User

Hm, evtl. muss man der decode-Anweisung in der myUtils ausdrücklich UTF-8 (oder was auch immer unter "encoding" angegeben war) unterschieben (und dem encoding in RHASSPY genauso)?

Kannst du das mal ergänzen?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

drhirn

Ich versuch's.

Zitat von: Beta-User am 23 April 2021, 09:57:47
Ansonsten sehe ich jetzt auf die Schnelle nichts, was gegen die Steuerbarkeit des Testdevices spräche (ggf. mal das RHASSPY-list kontrollieren).

Der Schmäh ist: Es braucht den Setter hue damit das Device überhaupt im List auftaucht. Ändert aber nichts daran, dass es bei SetColorGroup nicht gefunden wird.

drhirn

#484
siteId2room war schuld. Also eigentlich ich ;)



Ich hab zwei Geräte mit einem temperature-Mapping. Eines im Raum "draußen", eines im Raum "Wohnzimmer".

"Wie warm ist es" im Wohnzimmer gesprochen, bringt mir jetzt die Temperatur von draußen. Weil im Wohnzimmer kein Gerät gefunden wurde (matches in room). Warum? Das ging doch mal.



defmod thermWohnzimmer dummy
attr thermWohnzimmer group Temperatur
attr thermWohnzimmer icon temp_inside
attr thermWohnzimmer readingList measured-temp desired-temp
attr thermWohnzimmer rhasspyMapping SetOnOff:cmdOn=desired-temp 22.5,cmdOff=desired-temp 0\
GetOnOff:currentVal=desired-temp,valueOff=0\
GetNumeric:currentVal=measured-temp,type=temperature\
GetNumeric:currentVal=desired-temp,part=0,type=desired-temp\
SetNumeric:currentVal=desired-temp,cmd=desired-temp,part=0,minVal=0,maxVal=23,step=0.5,type=temperature
attr thermWohnzimmer rhasspyName Heizung
attr thermWohnzimmer rhasspyRoom Wohnzimmer
attr thermWohnzimmer room Rhasspy,Wetter
attr thermWohnzimmer setList desired-temp
attr thermWohnzimmer stateFormat measured-temp °C / desired-temp °C




2021.04.23 11:13:32.703 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_GetNumeric => {"input": "temperature", "intent": {"intentName": "de.fhem:GetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "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": "wohnzimmer-snowboy-3d5890d1-292d-48d5-9cb8-e0331c96ba35", "customData": null, "asrTokens": [[{"value": "temperature", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}]], "asrConfidence": null, "rawInput": "wie warm ist es", "wakewordId": "snowboy", "lang": null}
2021.04.23 11:13:32.703 5: Parsed value: wohnzimmer-snowboy-3d5890d1-292d-48d5-9cb8-e0331c96ba35 for key: sessionId
2021.04.23 11:13:32.703 5: Parsed value: temperature for key: Type
2021.04.23 11:13:32.704 5: Parsed value: wie warm ist es for key: rawInput
2021.04.23 11:13:32.704 5: Parsed value: 1 for key: probability
2021.04.23 11:13:32.704 5: Parsed value: wohnzimmer for key: siteId
2021.04.23 11:13:32.704 5: Parsed value: GetNumeric for key: intent
2021.04.23 11:13:32.704 5: Parsed value: temperature for key: input
2021.04.23 11:13:32.705 5: handleIntentGetNumeric called
2021.04.23 11:13:32.705 5: matches in room: , matches outside: tempOutside thermWohnzimmer
2021.04.23 11:13:32.705 5: tempOutside
2021.04.23 11:13:32.706 5: Response is: Die Temperatur von draußen beträgt 19,5 Grad



         thermWohnzimmer:
           alias      heizung
           groups     temperatur
           names      heizung
           rooms      wohnzimmer
           intents:
             GetNumeric:
               desired-temp:
                 currentVal desired-temp
                 part       0
                 type       desired-temp
               temperature:
                 currentVal measured-temp
                 type       temperature

Beta-User

#485
Lustiges feature, schiebt man rgb nach vorne, taucht es auch im Mapping auf...

Habe jetzt die Regex (auch an noch ein paar anderen Stellen) aufgebohrt, damit die das auch akzeptiert, wenn "end of string" erreicht ist.

Ansonsten hatte ich bisher nur "hue" und "Colortemp" als Gruppenbefehle in der Praxis (also mit realen Geräten) ausgetestet, und das war insoweit ok, als alle bei hue die Farbe gewechselt haben, und nur die Truppe, die dann auch ct kann auf den Colortemp reagiert hat.

RGB (via Color und Rgb) hatte ich gestern in der Troppenübung durch, da aber nur single und mit dem gezeigten dummy; Wert der beiden Felder war sechsstelliges HEX (FF0000).
Da die Gruppen-Logik nur eine übergreifende Schleife ist, die eben die Devices überspringt, die den jeweiligen Befehl nicht kennen, "müsste" das eigentlich auch passen. Beim Testen mit Gruppe daher erst starten, wenn der "single"-Payload-JSON paßt.



Zum "outisde room":
Ist das 2room-reading noch gesetzt? Dann ist der Satellit im B?ro ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

drhirn

Zitat von: Beta-User am 23 April 2021, 11:26:45
Zum "outisde room":
Ist das 2room-reading noch gesetzt? Dann ist der Satellit im B?ro ;) .

Ja, hehe. Hatte das eh oben geschrieben. Aber zu spät. Peinlich ;D

drhirn

Ich kann jetzt rhasspyColors und gDT nicht mehr mischen, oder? Ich mein, alle bunten Lichter müssen jetzt entweder ein rhasspyColors oder ein gDT haben. Ein Licht mit rhasspyColors, ein anderes mit gDT geht nicht mehr. Zumindest weiß ich nicht, wie ich die Rhasspy-sentences bauen sollte.
Ich müsste das so machen:


[de.fhem:SetColor]
\[setze|färbe|stelle] $de.fhem.Device{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] $de.fhem.Color{Color}
\[setze|färbe|stelle] $de.fhem.Device{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] (grün{Rgb:008000}|rot{Hue:1})


Da wird aber bei "grün" natürlich immer der erste Satz genommen.

Oder so

[de.fhem:SetColor]
\[setze|färbe|stelle] $de.fhem.Device{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] ($de.fhem.Color{Color}|grün{Rgb:008000}|rot{Hue:1})

Dann wird immer 008000 genommen.

Oder übersehe ich da etwas?

Beta-User

Mischen sollte schon (bedingt) gehen, allerdings macht es m.E. in der "neuen Welt" nicht mehr den großen Sinn, Farben erst auf der FHEM-Seite zu benennen.
Das hier sollte gehen (vorausgesetzt, das mapping auf der FHEM-Seite wird auf HEX umgestellt):
\[setze|färbe|stelle] $de.fhem.Device{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] (grün{Color:008000}|rot{Hue:1})


Insgesamt fand ich den "separaten Kanal" für das Farb-Thema schon immer komisch und _glaube_, dass man das mittelfristig als "deprecated" kennzeichnen sollte, nämlich dann, wenn wir "Hue2hex" können...
(Nachtrag: Das mapping auf der FHEM-Seite via Attribut macht uU. allerdings dann Sinn, wenn man Farbkorrekturen vornehmen will/muss, mal schauen)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

drhirn

Somit brechen wir aber jetzt schon mit der Rückwertskompatibiliät. Das rhasspyColors ist somit sinnlos. Bzw. dessen Inhalt. Und der Slot de.fhem.Colors.

Beta-User

Nicht unbedingt.

Der slot an sich funktioniert und wird das auch weiterhin. Wer es wie gehabt nutzen will: Gerne, kein Problem.

Ursprünglich hatte ich überlegt, ob man ein "word2rgb"-Mapping machen sollte, dann wäre "Color" mit (englischen) Wortwerten gegangen. So ist das im Moment auch auskommentiert begonnen.

Mit meinen jetzigen Erfahrungen mit dem Thema würde ich sagen, dass man dann mehrfach mappt, was vermutlich Quatsch ist, weil man in jedem Fall ein mapping auf der Rhasspy-Seite braucht, und das dann auch gleich "richtig" machen kann und (nach derzeitigem Verständnis) "Hue" nummerisch übergeben.

Zwischenfazit also:
Wer in die "neue Welt" will sollte das nach der Devise tun: Ganz oder gar nicht.
Zum Testen kann man ja ein Schlüsselwort voranstellen, und dann entweder Hue (zu empfehlen) oder Rgb zusätzlich nutzen. Ähnliches gilt für  Gruppenfunktionen; die gehen dann eben nur "entweder" oder...
Schwierig, das letztlich auf Basis einiger weniger Erfahrungen jetzt schon zu entscheiden, auch von daher bin ich mal auf nachher bzw. den Do. gespannt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

drhirn

Versteh ich nicht. Wie soll das gehen? Der Slot nützt mir ja nichts mehr sobald ich irgendein Gerät habe, dessen Farben mit gDT gesteuert werden. Weil ich eben keine auf beide passenden sentences mehr zusammen bringe.

drhirn

Als Beispiel dieses Device


defmod Stimmungsleuchte dummy
attr Stimmungsleuchte readingList pct rgb
attr Stimmungsleuchte rhasspyColors grün=rgb 008000\
blau=rgb 0000FF\
gelb=rgb FFFF00
attr Stimmungsleuchte rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off
...
attr Stimmungsleuchte setList on off pct rgb


Und der sentence:

[de.fhem:SetColor]
\[setze|färbe|stelle] $de.fhem.Device{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] ($de.fhem.Color{Color}|grün{Color:008000})


Das ergibt bei "Stelle die Stimmungslampe auf grün":

2021.04.23 12:28:22.749 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetColor => {"input": "stelle stimmungslampe auf 008000", "intent": {"intentName": "de.fhem:SetColor", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "stimmungslampe"}, "slotName": "Device", "rawValue": "stimmungslampe", "confidence": 1.0, "range": {"start": 7, "end": 21, "rawStart": 7, "rawEnd": 21}}, {"entity": "Color", "value": {"kind": "Unknown", "value": "008000"}, "slotName": "Color", "rawValue": "grün", "confidence": 1.0, "range": {"start": 26, "end": 32, "rawStart": 26, "rawEnd": 30}}], "sessionId": "wohnzimmer-snowboy-d0a043dc-738d-4fd1-852a-437de2504e3a", "customData": null, "asrTokens": [[{"value": "stelle", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 6, "time": null}, {"value": "stimmungslampe", "confidence": 1.0, "rangeStart": 7, "rangeEnd": 21, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 22, "rangeEnd": 25, "time": null}, {"value": "008000", "confidence": 1.0, "rangeStart": 26, "rangeEnd": 32, "time": null}]], "asrConfidence": null, "rawInput": "stelle stimmungslampe auf grün", "wakewordId": "snowboy", "lang": null}
2021.04.23 12:28:22.750 5: Parsed value: 1 for key: probability
2021.04.23 12:28:22.750 5: Parsed value: SetColor for key: intent
2021.04.23 12:28:22.750 5: Parsed value: stelle stimmungslampe auf 008000 for key: input
2021.04.23 12:28:22.750 5: Parsed value: wohnzimmer for key: siteId
2021.04.23 12:28:22.750 5: Parsed value: stimmungslampe for key: Device
2021.04.23 12:28:22.751 5: Parsed value: stelle stimmungslampe auf grün for key: rawInput
2021.04.23 12:28:22.751 5: Parsed value: 008000 for key: Color
2021.04.23 12:28:22.751 5: Parsed value: wohnzimmer-snowboy-d0a043dc-738d-4fd1-852a-437de2504e3a for key: sessionId
2021.04.23 12:28:22.751 5: handleIntentSetColor called
2021.04.23 12:28:22.752 5: Device selected (by hash, with room and name): Stimmungsleuchte
2021.04.23 12:28:22.752 5: Response is: Tut mir leid, aber ich konnte kein passendes Mäpping finden
2021.04.23 12:28:22.752 5: Response is: Da ist leider etwas schief gegangen
2021.04.23 12:28:25.400 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-snowboy-d0a043dc-738d-4fd1-852a-437de2504e3a", "siteId": "wohnzimmer", "customData": "snowboy"}
2021.04.23 12:28:25.400 5: Parsed value: wohnzimmer-snowboy-d0a043dc-738d-4fd1-852a-437de2504e3a for key: sessionId
2021.04.23 12:28:25.400 5: Parsed value: wohnzimmer for key: siteId


Gleich zwei Fehlermeldungen nämlich

Beta-User

#493
Na ja, ein sentence, beide Gruppen bedienen wird vermutlich nicht gehen bzw. nur dann, wenn jemand das mapping für "nicht-HEX-Color" fertig stellen würde (das wir übrigens auch als Option in "tweaks" unterbringen könnten, dann kann es der user auf Deutsch einstellen; die jetzige Form ist vermutlich nicht gut, de-Text nach HEX wäre vermutlich besser, und wer dann was anderes braucht, muss dann halt rhasspyColors am Gerät anders einstellen, das hat bei einem match (in Color) immer Vorrang).

Daher ist im Moment dem Einsteiger zu empfehlen, direkt gDT zu nehmen, und es sollte auch möglich sein, SetColor als mapping in rhasspyMapping unterzubringen, falls z.B. jemand RGB als setter hat.

Falls der Eindruck entstanden sein sollte, dass das alles schon irgendwie fertig ausgekocht oder vercodet ist: bewahre... Ich habe bisher nur festgestellt, dass es überraschend easy mit den zwei (farbigen) Typen klappt, die ich habe, und _glaube_, dass die verbliebenen Lücken relativ leicht zu füllen sein müßten, ohne jemandem Funktionalität abzuklemmen, der die neuen features nicht nutzen will (bzw. mit in der Entwickelung supporten).

(Das mit den zwei Rückmeldungen muss ich mir in Ruhe ansehen; werden denn auch beide gesprochen oder nur die letzte?)
EDIT: Bitte mal testen, ob jetzt die eigentlich richtige Antwort kommt. Wenn, waren da ein paar mehr Stellen; die Änderung sollte unschädlich sein...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

drhirn

Es werden beide gesprochen.

Also nicht rückwärtskompatibel ;)

Ich hätte mir gedacht, wir bringen die Farben irgendwie im language-file unter. Aber dazu müssten wir wirklich umrechnen können (HEX <-> HUE). Da hat doch sicher schon mal jemand gemacht, nicht?