Modulentwicklung für Rhasspy Sprachassistent

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

Vorheriges Thema - Nächstes Thema

Beta-User

Der mqtt-Verkehr bei so einer Schleife wäre ggf. interessant.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JensS

#856
hermes/intent/de.fhem:SetOnOff {"input": "stehlampe on", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "stehlampe"}, "slotName": "Device", "rawValue": "stehlampe", "confidence": 1.0, "range": {"start": 0, "end": 9, "rawStart": 0, "rawEnd": 9}}, {"entity": "Value", "value": {"kind": "Unknown", "value": "on"}, "slotName": "Value", "rawValue": "an", "confidence": 1.0, "range": {"start": 10, "end": 12, "rawStart": 10, "rawEnd": 12}}], "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "customData": "alexa", "asrTokens": [[{"value": "stehlampe", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 9, "time": null}, {"value": "on", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 12, "time": null}]], "asrConfidence": 0.9718234, "rawInput": "stehlampe an", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"customData": "alexa","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "stehlampe wirklich on schalten?"}
hermes/nlu/intentNotRecognized {"input": "", "siteId": "wohnzimmer", "id": null, "customData": null, "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "siteId": "wohnzimmer", "input": "", "customData": "alexa"}
hermes/dialogueManager/continueSession {"customData": "intentNotRecognized","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "please confirm: "}
hermes/nlu/intentNotRecognized {"input": "", "siteId": "wohnzimmer", "id": null, "customData": null, "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "siteId": "wohnzimmer", "input": "", "customData": "intentNotRecognized"}
hermes/dialogueManager/continueSession {"customData": "intentNotRecognized","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "please confirm: "}
hermes/nlu/intentNotRecognized {"input": "ida", "siteId": "wohnzimmer", "id": null, "customData": null, "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "siteId": "wohnzimmer", "input": "ida", "customData": "intentNotRecognized"}
hermes/dialogueManager/continueSession {"customData": "intentNotRecognized","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "please confirm: ida"}
hermes/nlu/intentNotRecognized {"input": "", "siteId": "wohnzimmer", "id": null, "customData": null, "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "siteId": "wohnzimmer", "input": "", "customData": "intentNotRecognized"}
hermes/dialogueManager/continueSession {"customData": "intentNotRecognized","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "please confirm: "}
hermes/nlu/intentNotRecognized {"input": "", "siteId": "wohnzimmer", "id": null, "customData": null, "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "siteId": "wohnzimmer", "input": "", "customData": "intentNotRecognized"}
hermes/dialogueManager/continueSession {"customData": "intentNotRecognized","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "please confirm: "}
hermes/nlu/query {"input": "nein danke", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ConfirmAction", "de.fhem:CancelAction"], "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "wakewordId": "alexa", "lang": null, "customData": "intentNotRecognized", "asrConfidence": 1.0, "customEntities": null}
hermes/nlu/intentParsed {"input": "Abbruch", "intent": {"intentName": "de.fhem:CancelAction", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Mode", "value": {"kind": "Unknown", "value": "Abbruch"}, "slotName": "Mode", "rawValue": "nein danke", "confidence": 1.0, "range": {"start": 0, "end": 7, "rawStart": 0, "rawEnd": 10}}], "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28"}
hermes/intent/de.fhem:CancelAction {"input": "Abbruch", "intent": {"intentName": "de.fhem:CancelAction", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Mode", "value": {"kind": "Unknown", "value": "Abbruch"}, "slotName": "Mode", "rawValue": "nein danke", "confidence": 1.0, "range": {"start": 0, "end": 7, "rawStart": 0, "rawEnd": 10}}], "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "customData": "intentNotRecognized", "asrTokens": [[{"value": "Abbruch", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}]], "asrConfidence": 1.0, "rawInput": "nein danke", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/endSession {"customData": "intentNotRecognized","intentFilter": null,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "Habe abgebrochen"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "siteId": "wohnzimmer", "customData": "intentNotRecognized"}


Ich denke, beim intentNotRecognized handelt es sich um ein lokales Echo Bestätigungsanfrage. Dazu habe ich noch keine Lösung.

p.s. Ludwig kommt tatsächlich vom ABC-Intent/Slot.
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Beta-User

Jetzt mal noch eine etwas längere Antwort zum ganzen...:

Zitat von: JensS am 31 Juli 2021, 09:44:29
Hey - cool!  8)
8)
Zitat
Funktioniert mit SetOnOff. Habe es alsrhasspySpecials confirm: SetOnOff="$target wirklich $Value schalten?" SetScenedefiniert.
Es kommt die Rückfrage "Stehlampe wirklich ON schalten?" und man kann bestätigen oder abbrechen.

Zitat von: Beta-User am 31 Juli 2021, 09:57:07
ON kann man in words übersetzen.
Das bezieht sich auf einen Abschnitt in der language-file, siehe https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/rhasspy-de.cfg#L22 ff

Es gäbe noch einen zweiten "key", den man in der language-file (unter "responses") einsortieren kann, z.B.:
"DefaultConfirmationRequestRawInput": "bitte bestätige $rawInput", (s.u.)

Zitat von: JensS am 31 Juli 2021, 14:44:01
Ich denke, beim intentNotRecognized handelt es sich um ein lokales Echo Bestätigungsanfrage. Dazu habe ich noch keine Lösung.

p.s. Ludwig kommt tatsächlich vom ABC-Intent/Slot.
Aus dem MQTT-Auszug läßt sich die Ursache auch noch nicht abschließend ermitteln, aber "ida" geht auch in diese Richtung. Ich vermute (!), es handelt sich (auch) um ein spezielles Problem, das durch die App (iVm. mit "silence detection") entsteht, wenn man nicht die hotword-Erkennung nutzt, sondern das Mikro manuell einschalten. Dann wird anscheinend das Mikro nicht sauber aus- und anschaltet (wenn Rhasspy das macht, gibt es trigger unter "hermes/hotword/"). Klingt danach, als würde einfach irgendeiner der "kürzesten möglichen" erkannten "Sätze" ausgewählt...
Da wurde in .11 auch was verbessert, wenn ich das richtig verstanden habe. Falls du docker nutzt, wäre ggf. mal ein Wechsel auf die pre-release sinnvoll.

Kann aber auch sein, dass einfach die Länge der Ausgabe falsch berechnet wird? (kommt ggf. auf die TTS-Engine an?).



Vielleicht auch noch ein paar Takte zur Bestätigungs-Anfrage:

Obiger key "DefaultConfirmationRequestRawInput" wird verwendet, wenn nirgendwo was passendes zu finden ist. Da wird einfach der erkannte Text zurückgegeben ($rawInput). Das hat den Vorteil, dass zumindest immer irgendwas (halbwegs) "verständliches" zurückgegeben wird.

Das kann man (in der üblichen Vorgehensweise, dass die speziellere Vorgabe die allgemeine verdrängt) überlagern, indem man entweder in "Specials" was angibt (wie oben zitiert), oder in "Tweaks". Das obige Beispiel aus "confirmIntentResponses" würde dann für alle SetOnOff-Bestätigungsanfragen gelten, bei denen es kein entsprechendes "Special" gibt... Verfügbar sind immer die Variablen $rawInput, $Value (modifiziert durch "words") und $target (Device- bzw- Gruppenname).
(Ob das wirklich in allen Fällen sauber funktioniert, habe ich bisher nicht getestet).

Das Grundproblem bei allen Rückfragen ist, dass man den gefundenen Wert irgendwie "rückübersetzen" muss, was bei on/off noch relativ leicht ist, dann aber schnell ausfasert. An sich wird das "Ausgangswort" sogar mit im JSON übermittelt. Allerdings kann sich der betreffende Inhalt - soweit ich die JSON dazu mal etwas intensiver angesehen hatte - aber leider unter ziemlich vielen "Flaggen" verstecken, so dass mir jedenfalls bisher keine wirklich elegante Option eingefallen ist, das irgendwie soweit rauszuarbeiten, dass man damit weiterarbeiten könnte.
Vermutlich wäre es einfacher, den "words"-Hash (auf Geräte-Ebene => Specials) erweitern/ersetzen zu können, dann könnte man z.B. "on" auch in "ausfahren" übersetzen. Aber damit wäre man so ziemlich am Ende dessen angelangt, was ich glaube (selbst) umsetzen zu können...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JensS

Derzeit kämpfe ich mit meinem Viomi S9, der (bisher) nur über die Cloud zu steuern ist. Aber das ist ein anderes Thema...

Der Rhasspy-Dialog läuft nun aktuell zuverlässig.  :)
Die Sprachdatei habe ich angepasst und auch gleich "please confirm" in "bitte bestätige" übersetzt.
Auch das lokal Echo konnte ich durch eine Verlängerung von "silence after" unterdrücken. Bisher fehlerfrei.
Übrigens nutze ich in meinen Systemen (noch) kein Docker.

Vielen Dank @Beta-User!
Sollten wir für Rhasspy ein Feature anregen, das mittels Flag (z.B. [Intent]#deactive) bestimmte Intents per default in der sentences.ini deaktiv setzen kann?
Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Beta-User

#859
Zitat von: JensS am 03 August 2021, 16:52:21
Vielen Dank @Beta-User!
Gerne!

Zitat
Der Rhasspy-Dialog läuft nun aktuell zuverlässig.  :)
Die Sprachdatei habe ich angepasst und auch gleich "please confirm" in "bitte bestätige" übersetzt.
...da das mit dem "please confirm" dann scheinbar doch "halbwegs" ok ist und das ganze dann halbwegs direkt durch die zentrale Routine "abzufrühstücken" ist, hätte ich anbei die nächste Iteration:
Praktisch alle Device- und Gruppen-set-Kommandos sollten sich jetzt eine Bestätigung holen können, Groups und Devicenamen kann man per regex in "Tweaks" angeben (hoffe ich zumindest).

Zitat
Auch das lokal Echo konnte ich durch eine Verlängerung von "silence after" unterdrücken. Bisher fehlerfrei.

Zitat
Sollten wir für Rhasspy ein Feature anregen, das mittels Flag (z.B. [Intent]#deactive) bestimmte Intents per default in der sentences.ini deaktiv setzen kann?
a) ist mir das noch zu früh, über den Punkt "wie soll es nach einem 'falschen Intent' weitergehen" müssen wir m.E. auch erst nochmal nachdenken, und
b) würde ich davon Abstand nehmen, einen konkreten Vorschlag zur Umsetzung zu unterbreiten.
An sich fände ich es aber nach wie vor richtig, bestimmte Intents komplett wegschalten zu können.

Jetzt wünsche ich erst mal viel Spaß beim weiteren Testen. Kleine (englische) Syntax-Beispiele sind in der cref enthalten.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JensS

Zitat von: Beta-User am 03 August 2021, 19:34:02
...da das mit dem "please confirm" dann scheinbar doch "halbwegs" ok ist und das ganze dann halbwegs direkt durch die zentrale Routine "abzufrühstücken" ist, hätte ich anbei die nächste Iteration:
Praktisch alle Device- und Gruppen-set-Kommandos sollten sich jetzt eine Bestätigung holen können, Groups und Devicenamen kann man per regex in "Tweaks" angeben (hoffe ich zumindest).
confirmValueMap ist cool.  8)

Zitata) ist mir das noch zu früh, über den Punkt "wie soll es nach einem 'falschen Intent' weitergehen" müssen wir m.E. auch erst nochmal nachdenken
Was meinst du genau? Gibt's unbehandelte Zustände?

Zitatb) würde ich davon Abstand nehmen, einen konkreten Vorschlag zur Umsetzung zu unterbreiten.
An sich fände ich es aber nach wie vor richtig, bestimmte Intents komplett wegschalten zu können.
Ich kann ja mal was vorbereiten und dir vorstellen.?

ZitatJetzt wünsche ich erst mal viel Spaß beim weiteren Testen. Kleine (englische) Syntax-Beispiele sind in der cref enthalten.
Danke, den hab ich - ist gut erklärt und läuft echt gut.
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Beta-User

Zitat von: JensS am 03 August 2021, 20:23:41
confirmValueMap ist cool.  8)
Fand ich nach dem ersten Testen auch, der nächste Impuls war dann: Wie bekommt man sowas für Gruppen-Intents hin... ::)
Im Endeffekt würde dann aber vermutlich die Syntax sehr kompliziert ausfallen müssen, mit der man sowas "ver-attributiert" und dann auch wieder auswertet => kommt erst mal auf die Seite (und dann vermutlich nie).

Zitat
Was meinst du genau? Gibt's unbehandelte Zustände?
Jein. Der Dialog bleibt - auch wenn man irgendwas anderes an Rhasspy "reinlabert" - ja solange offen, bis entweder bestätigt oder abgebrochen wird, oder eben dann der timeout zuschlägt, alles andere geht (im Sinne eines (fast*) folgenlosen Funktionsaufrufs) über "intent not recognized". Theoretisch wäre es aber auch möglich, als Reaktion auf "not recognized" rückzufragen, was denn nun passieren soll. "Unbehandelt" ist dann die (neben Confirm/Cancel) die "dritte Option", nämlich den "weiteren Intent" tatsächlich zu erkennen und dann damit weiterzumachen.

Dann müßte man aber
- rückfragen, ob ein Wechsel gewollt ist;
- eine Logik haben, die eine entsprechende "Bestätigung**" erkennt;
- den erkannten raw-Text (*: der wird intern über die Funktion heute schon zwischengespeichert) dann (insbesondere) _nach Änderung des intentFilters_ wieder an die Intent-Erkennung zurückgeben.

** Die Bestätigung für den Wechsel könnte auch ein spezieller Text in der "Cancel"-Behadlung sein, sonst müßte man nochmal einen Intent generieren. So oder so dürfte das ganze im Endergebnis irgendwie "gekünstelt" wirken...

Zitat
Ich kann ja mal was vorbereiten und dir vorstellen.?
Du musst mir nichts vorstellen ;) . Mein Eindruck war/ist lediglich, dass
- das "Grundproblem" mit den nicht komplett ausgeschalteten Intents heute schon "bekannt" und adressiert ist, und es eher an Anschauungsmaterial fehlt, wie sich das konkret auswirkt (so wie dein "Ludwig-Ida-Gestottere"***);
- bisher (außer dem Demo-Script) keine "App" da war, die überhaupt in etwas größerem Umfang dialogische Optionen genutzt hat****. Von daher wäre mein Angang eben eher darzustellen, welche Optionen unsere "App" heute schon bietet, und welche Probleme sich auftun:

-- "Themenwechsel" (bewußt/unbewußt) wie oben beschrieben (für eine Antwort wäre es da ggf. hilfreich zu wissen, als welcher intent es den erkannt worden wäre). Da stellt sich die Frage, ob (und in welchen Fällen) das "Ausschalten" ggf. helfen könnte? (***wäre ein sehr gutes Beispiel).
-- Zu weite/ nicht beschränkbare slots/slot-Werte: Wenn man eine Wahl (z.B zwischen mehreren Devices) anbietet, sollte (vorrangig?) erkannt werden, was zur Wahl steht, und nicht weiter "alles mögliche", was in dem Ausgangsslot stand, oder?

Betr. **** wäre es noch die "Krönung", wenn man sowas wie msgDialog abbilden könnte, aber da habe ich auch noch deutlich zu wenig Erfahrung: Außer einem kleinen "Gespräch" zum Thema Spritpreise ist mir da auch noch nicht viel eingefallen (und das könnte man über einen CustomIntent oder eine Status-Abfrage vermutlich direkter abbilden).

ZitatDanke, den hab ich - ist gut erklärt und läuft echt gut.
Thx. für die Rückmeldung.
Bzgl. "Erklärungen": Wäre nett, wenn sich jemand mal der commandref annehmen würde. Zum einen sehen 4 (oder mehr) Augen immer mehr als 2, und zum anderen habe ich manches (denke grade v.a. auch an die Fein-Strukturierung, wie die Reihenfolge der Attribute/Keys in den Attributen) auch einfach aus der Hüfte geschossen, eventuell fehlen Querverweise, weitere (kleine!) Beispiele, usw., usf... (Das ist mAn. auch keine reine Frage nach Englisch-Kenntnissen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JensS

#862
Das sind gute Ideen und diese sollten auch relativ gut umsetzbar sein.
Bei zwei intentNotRecognized-Durchläufen könnte man die möglichen Antwortmöglichkeiten vorlesen lassen sowie fragen, ob abgebrochen oder einen Schritt zurückgegangen werden soll.
Eine Auswertung vom raw-Text wäre hier nicht nötig.

Einen msgDialog könnte man relativ einfach aufbauen. Natürlich wird es komplexer, je mehr Möglichkeiten man anbietet. Eine Idee/Spielerei:

Ich: "Alexa, beginne einen Dialog"
Rhasspy: "Ok, was kann ich für dich tun? Schalten oder informieren?
Ich: "informieren"
Rhasspy: Was möchtest du wissen? Status - Temperatur - Leerungstermin ...
Ich: "Temperatur"
Rhasspy: "Ok, die Temperatur von welchem Gerät oder Raum?
Ich: "Garten"
Rhasspy startet de.fhem:GetNumeric mit {Type:temperature} und $de.fhem.Room{Room} und dem vorhandenen hash.
Rhasspy: "Die Temperatur vom Garten beträgt 26 Grad Celsius"

Denkbar?

Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Beta-User

Zitat von: JensS am 04 August 2021, 21:20:35
diese sollten auch relativ gut umsetzbar sein.
Da bin ich eher skeptisch, der Teufel steckt - wie so oft - im Detail...

Zitat
Bei zwei intentNotRecognized-Durchläufen könnte man die möglichen Antwortmöglichkeiten vorlesen lassen sowie fragen, ob abgebrochen oder einen Schritt zurückgegangen werden soll.
Eine Auswertung vom raw-Text wäre hier nicht nötig.
Gedanklicher Ausgangspunkt ist: Wer weiß, wie er mit Rhasspy sprechen muss, kann den direkten Weg nehmen, eigentlich geht es bei den Dialogen immer darum, entweder eine Sicherung einzubauen (Confirm), oder eben eine Benutzerführung zu haben - tendenziell auch für die, die sich nicht mit den Details rumschlagen wollen (Mitbewohner). Für letztere muss das ganze "organisch" sein, sonst wird es (vermutlich) nicht angenommen.

Ergo stellt sich gleich die Frage, wieso erst beim 2. Mal?
Falls es wegen "schwacher" Erkennung des eigentlich gewollten ist, müßte man vorrangig da nacharbeiten, für andere Fälle sehe ich die Notwenigkeit einer Wiederholung nicht, das führt sonst zu einer Wahrnehmung im Sinne von "das Sch..-System reagiert mal wieder nicht!".

Und wenn "zurück", muss man wissen, wohin. Wenn/solange der "Anschlussintent" beliebig ist, kann dann bei einem (bestätigt) absichtlichen Wechsel auch direkt die Auswertung des gespeicherten letzten rawInput erfolgen, sonst müsste man ja nochmal sagen, was bereits (zutreffend!) erkannt wurde => unorganisch.

ZitatDenkbar?
Denkbar ist immer vieles, aber im Detail stelle ich es mir ziemlich schwierig vor, das mit den jetzigen Methoden umzusetzen: Es würde erfordern, dass man die intents wirksam (!) beschränken _und_ die slots @runtime ändern kann. Ginge vielleicht (!) mit voice2json, aber selbst wenn das das kann, ist noch keine Zeile Code geschrieben mit der FHEM die jeweils passenden nächsten Schritte ermitteln könnte.
Kurz: Bevor nicht "ChoiceDevice" 100% funktioniert (mit Beschränkung auf zum vorherigen Schritt passenden Filterungen (!)), braucht man über sowas erst gar nicht nachdenken.
Davon abgesehen dürfte der Programmier- und (!) Konfigurationsaufwand viel zu hoch werden und den großen Mehrwert gegenüber den bereits bestehenden Auswahl-Intents sehe ich auch noch nicht.

Aber vielleicht übersehe ich mal wieder was wesentliches... ::) ?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Was anderes - hier ist mir ein interessanter Ansatz über den Weg gelaufen:
ZitatAlternatively, I might put Zigbee based buttons around the house and trigger the hotword through pressing the button
...ist erst mal eher ein Merkposten, aber ggf. hat ja jemand damit Erfahrung, wie man sowas im FHEM-Kontext umsetzt bzw. ob es sinnvoll wäre, eine "start session"-Logik in/zu RHASSPY zu basteln...?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JensS

#865
In Bezug auf msgDialog muss ich etwas falsch verstanden haben. Zumindestens sollte es möglich sein, eine Session in msgDialog offen zu halten. Einen msgDialog würde dann auch im msgDialog-Device abgebildet. Wenn man einen frei manipulierbaren [Dialog]-Intent in continueSession hätte, wäre manches einfacher umzusetzen.
Jetzt werden meine Anfragen im Rhasspy-Forum anschaulicher.
Snips hatte einige Erweiterungen mehr. So verstehe ich die Hermes-Referenz bei Snips. Bisher wird es noch kein Erfordernis für variable Slots in continueSession/intentFilter gegeben zu haben. Auch die Möglichkeit, Intents per Standard zu deaktivieren wurde wohl noch nicht gebraucht. Wenn man die Beiträge sieht, ist 10_RHASSPY.pm in dieser Hinsicht wesentlich weiter, als die Entwickler (bisher) geplant haben.
Ich habe mir mal die Rhasspy-Quellen angesehen und es ist in der Tat eine große Aufgabe, die Standard-Deaktivierung zu implementieren. Derzeit wird die Intent-Zeile nur bis ] ausgewertet. Dahinter ist aber noch viel Platz :) .

Bei der intentNotRecognized weiß ich nicht, was du genau vorhast. Klar reicht ein Durchlauf...

Die Zigbee-Geschichte müsste ja nur einen Dialog anschubsen. Letztlich kommuniziert Rhasspy intern auch bloß über MQTT. Also einen Satelliten in der Nähe als siteId angeben und was sonst noch in der ref steht, sollte reichen.

Mit dem ESP habe ich auch schon geliebäugelt. Da meine Zero's aber ihren Dienst tun, bin ich dem nicht nachgegangen.

Ich würde bei Bedarf/Gelegenheit mal einen kleinen msgDialog zusammenbasteln.?

Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

drhirn

Können wir das Attribute languageFile so umbauen, dass man auch mehrere Files angeben kann? Ich hab nämlich das - in einem früheren Post befürchtete - Problem, dass mir ein Update des Files natürlich immer meine "User"-Einträge überschreibt. Um nicht jedes Mal ein diff machen zu müssen, wär's daher praktisch, wenn wir da zwei Files angeben könnten. Ein File, in dem unsere Default-Einträge drinnen stehen. Und eines mit dem "User"-Abschnitt.

Beta-User

Zitat von: drhirn am 20 August 2021, 12:41:01
Können wir das Attribute languageFile so umbauen, dass man auch mehrere Files angeben kann?
Können schon, aber nach etwas Nachdenken bin ich weiter nicht überzeugt, dass das eine gute Lösung wäre.
Argumente dagegen:
- sowas ist nicht configDB-kompatibel
- (Aufwand)
- ist auch nicht unbedingt selbsterklärend, wie dann was ineinandergreifen würde.

Dagegen sind eigentlich nur noch bei größeren Umbauten Änderungen an den keys in der File zu erwarten. Die Nächste, wenn/falls ich die Probleme mit "notRecognized" (und ggf. sowas wie einem "continuous mode") in den Griff bekomme.... Wird aber noch dauern ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JensS

Zitat von: Beta-User am 21 August 2021, 08:14:36
... wenn/falls ich die Probleme mit "notRecognized" (und ggf. sowas wie einem "continuous mode") in den Griff bekomme...
Was meinst du speziell?
Mir ist aufgefallen (#4114 ff) , dass das Modul bei notRecognized den intentFilter auf zurücksetzt und cusomData auf intentNotRecognized gesetzt wird.
Man erhält dann eine "please confirm"-Aufforderung, welche im Hintergrund lediglich die Intents confirmAction und cancelAction zur Verfügung stellt.
Da wäre mir persönlich lieber, den vorigen intentFilter sowie die customData für einen zweiten Versuch zu behalten.
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Beta-User

Du hast des Pudels Kern gut getroffen.

"Speziell" teste ich grade an einer Variante rum, die die Frage, ob der nächste Schritt eingeleitet werden soll daran festmacht, wie lang der rawInput des nicht erkannten Intents ist und dann für "Confirm" noch ein paar weitere Varianten kennt. Leider laufe ich damit auch in "Stottereien" rein, die ich mir erst ansehen muss, bevor ich hier einen weiteren Zwischenstand poste...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files