Modulentwicklung für Rhasspy Sprachassistent

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

Vorheriges Thema - Nächstes Thema

Beta-User

#870
So, nachdem ich lange genug erfolglos auf den Code gestarrt habe, poste ich halt mal meinen aktuellen Stand - vielleicht findet ja jemand anderes den Dreh, wann und warum es ggf. Stottereien gibt...? (das mit der Erhöhung der Silence-Zeit könnte helfen?). Bin zwischenzeitlich auch auf 2.5.11-preview@deb-Paket.

Anders gesagt: Für "normale User" ist nichts neues drin, und "dialogorientierte" Mitüberleger müssen aufpassen, was sie sagen, wenn RHASSPY auf weiteren Input wartet bzw. den anfragt. (Aber ansonsten sollte eigentlich alles andere weiter funktionieren).

Vorbereitungen:
- Es gibt neue Keys ("default" auswechseln reicht ;) )
- Habe mal "OK" für ConfirmAction noch mit "Back" und "Next" ergänzt, dementsprechend "braucht" man auch was in der sentences.ini:
[de.fhem:ConfirmAction]
( ja mach | tu es | ist ok | aber gerne doch ){Mode:OK}
( lieber doch nicht ){Mode}
( Geh zurück | bleib da ) zurück{Mode:Back}
( Mach | geh ) weiter{Mode:Next}

("Braucht" meint: es ist eigentlich noch gar nicht vollst. relevant, OK reicht im Moment noch).

Die grundsätzliche Idee: Wenn der rawInput zu intentNotRecognized eine gewisse Länge hat, kann man vermuten, dass es die Absicht des Sprechers ist, RHASSPY was anderes mitzuteilen als eine positive oder negative Antwort bzw. eine Auswahlentscheidung. Habe jetzt mal die Grenze etwas willkührlich bei 12 Zeichen gezogen.

Daher erfolgt dann (hoffentlich) eine Rückfrage (bis dahin scheint es nicht nur theoretisch zu funktionieren), ob RHASSPY den neuen Content korrekt erfaßt hat. "Ja" sollte dann dazu führen, dass der neue Content ausgewertet wird (im Prinzip nach denselben Regeln wie eine komplett neue Ansage).
"Prinzipiell" klappt das auch, nur scheint (manchmal) während des Sprechens der Rückfrage durch Rhasspy bereits wieder was erkannt zu werden, was dann im Ergebnis irgendwie ein ungeordnet wirkt, und (noch) keine Regel zu erkennen ist, in welchen Fällen das passiert.

_Falls_ wir das in den Griff bekommen, sollte es dann möglich sein, auch sowas wie "Schalte ein paar Geräte ein" - "welche?" - "[den] Verstärker" - "was sonst?" - "Licht" - "OK, weiter?" ... umzusetzen, und/oder dann von "licht an" auf "dimmen" weiterzugehen usw. (entsprechende Konfiguration vorausgesetzt...). Ist zwar vermutlich im Detail auch "tricky".

Oder hat jemand andere/bessere Ideen, als das über den zentralen "Verteiler" ConfirmAction/Mode laufen zu lassen?
(Ich komme mir vor, als würde ich grade Holzräder schnitzen und würde übersehen, wo die nächstbeste Luftreifenfabrik ist...)
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

#871
Prima, das teste ich in der nächsten Woche.

Als ich das von der Stotterei las, kam mir folgende Idee, welche auch funktioniert.
Rhasspy -> Audio Playing -> Local Command -> Program: /opt/ausgabe.sh:#!/bin/bash
amixer -q -c 'seeed2micvoicec' sset Capture 0
cat $1 > /tmp/handy.wav && aplay /tmp/handy.wav
amixer -q -c 'seeed2micvoicec' sset Capture 95

Das wäre eventuell ein Ansatz für die Rhasspy-Entwickler, um das lokale Echo zu verhindern. In der Form allerdings extrem langsam.

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

#872
Irgendwie scheinen wir alle noch nicht so richtig zum Testen (&Grübeln) gekommen zu sein...

Aber manchmal ist ja ein bißchen Abstand ganz hilfreich, vorliegend jedenfalls, was die Doku anbelangt  ::) .

Leider ist die Doku jetzt auf dem Stand der Testversion mit den "Stottereien", wenn man beim Warten auf eine Bestätigungsanfrage was unpassendes sagt, aber zum einen nutzen das Bestätigungsfeature vermutlich die wenigstens, oder sie sind dann besser motiviert, Abhilfemöglichkeiten zu erruieren... "stable" ist das also nicht, ich hatte aber auch keine Lust, die Doku rückwärts zu portieren).

(Das mit dem script habe ich bisher nicht getestet, ich vermute (begründet mal wieder nur durch Bauchgefühl) weiter irgendeinen Logikfehler in dem, was wir von RHASSPY aus generieren und auswerten).
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

drhirn

Zitat von: Beta-User am 22 September 2021, 14:22:28
Irgendwie scheinen wir alle noch nicht so richtig zum Testen (&Grübeln) gekommen zu sein...

Naja. Es läuft und läuft und läuft. Die drei Befehle, die ich so durchschnittlich am Tag gebe, werden immer korrekt ausgeführt. Mehr Verwendungszweck habe ich offenbar derzeit nicht.

Aufgefallen ist mir nur, dass mir bei einer Frage nach der Temperatur immer zwei Geräte vorgeschlagen werden. Ok soweit. Aber egal, was ich danach sage, es gibt zuerst einen IntentNotRecognized und dann irgendwann "tut mir leid, da hat etwas zu lange gedauert". Es war mir aber bisher nicht wichtig genug, um dem nachzugehen.

Ich stell die neue Version dann am Abend ins SVN. Auf GitHub ist sie schon.

Beta-User

#874
Zitat von: drhirn am 22 September 2021, 14:31:29
Naja. Es läuft und läuft und läuft. Die drei Befehle, die ich so durchschnittlich am Tag gebe, werden immer korrekt ausgeführt. Mehr Verwendungszweck habe ich offenbar derzeit nicht.
So ähnlich ist es bei mir auch...

Zitat
Aufgefallen ist mir nur, dass mir bei einer Frage nach der Temperatur immer zwei Geräte vorgeschlagen werden. Ok soweit. Aber egal, was ich danach sage, es gibt zuerst einen IntentNotRecognized und dann irgendwann "tut mir leid, da hat etwas zu lange gedauert". Es war mir aber bisher nicht wichtig genug, um dem nachzugehen.
Das könntest du mit einer "priority" abstellen, aber solche "Nickeligkeiten" meine ich; interessant ist dann, was in "IntentNotRecognized" denn so alles als rawInput erkannt wurde. Das Verhalten scheint aber auch teils damit zusammenzuhängen, wie der Dialog initialisiert wurde (bei mir macht es gefühlt einen Unterschied, ob die App auf "wakeword" steht (also "base" den Dialog steuert), oder ob man das mit dem "Mikro-Knopf" initiiert.)

ZitatIch stell die neue Version dann am Abend ins SVN. Auf GitHub ist sie schon.
...drum... hatte mich schon gewundert, wo die .39 herkam...
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

drhirn

Zitat von: Beta-User am 22 September 2021, 14:38:49
interessant ist dann, was in "IntentNotRecognized" denn so alles als rawInput erkannt wurde.

Kann ich bei Gelegenheit mal liefern.

ZitatDas Verhalten scheint aber auch teils damit zusammenzuhängen, wie der Dialog initialisiert wurde (bei mir macht es gefühlt einen Unterschied, ob die App auf "wakeword" steht (also "base" den Dialog steuert), oder ob man das mit dem "Mikro-Knopf" initiiert.)

Ausschließlich via Wakeword.

Wenn wir schon plaudern: Ich muss gestehen, ich hab mir im Sommer einen Nest Audio organisiert. Weil mich meine Rhasspy-Hardware in der Küche um's Verrecken nicht verstehen will (stark befahrene Straße vor'm Fenster) und die Angebetete beim Abwaschen gerne Musik hat. Und ich muss sagen, es ist schon großartig, was mit dem Rhasspy-Modul alles auf die Beine gestellt wurde! In Verbindung mit FHEM um Ecken besser und einfacher als Google Home. Letzteres hat halt andere Vorteile. Aber das könnten wir alles auch, wenn hinter Rhasspy und RHASSPY Milliarden an Dollar stecken würden ;).

Beta-User

Zitat von: drhirn am 22 September 2021, 14:48:31
Kann ich bei Gelegenheit mal liefern.
Vermutlich ist das eher was, was sich der jeweilige User (=du) näher ansehen muss, weil das einfach nur "Rohdaten" sind und man "raten" muss, wie und warum es in dieser Form dann zustande gekommen ist...

Zitat
Ausschließlich via Wakeword.
Na ja, es geht bei der Initialisierung mehr um die Frage, _wie_ herum das Karussel fährt, weniger, ob überhaupt ::) ...

Zitat
Wenn wir schon plaudern: Ich muss gestehen, ich hab mir im Sommer einen Nest Audio organisiert. Weil mich meine Rhasspy-Hardware in der Küche um's Verrecken nicht verstehen will (stark befahrene Straße vor'm Fenster) und die Angebetete beim Abwaschen gerne Musik hat. Und ich muss sagen, es ist schon großartig, was mit dem Rhasspy-Modul alles auf die Beine gestellt wurde! In Verbindung mit FHEM um Ecken besser und einfacher als Google Home. Letzteres hat halt andere Vorteile. Aber das könnten wir alles auch, wenn hinter Rhasspy und RHASSPY Milliarden an Dollar stecken würden ;) .
Na ja, für mich ist Rhasspy sehr gut tauglich, wie es ist, und ich teste auch gerne mit (mehr oder weniger melodischem) "Hintergrundgeräusch" ;D . Bin mal gespannt, ob irgendwann mal auch sowas wie ein "App-Store" (für externe Applikationen) kommt, aber eher aus allgemeinem Interesse, "brauchen" wäre anders...

Wie "umständlich" man manche Dinge mit anderen Lösungen basteln muss, "freut" mich auch immer mal wieder :P . Es ist aber auch klar ein Unterschied, ob man "alles mögliche" erkennen will/muss, oder ob es nur darum geht, einen relativ begrenzten Wortschatz (ordentlich!) zu beherrschen. Ich bin jedenfalls sehr zufrieden mit dieser Offline-Variante, die wir hier gebastelt haben 8) .
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

Ziton

Ich bin zumeist auch Happy mit dieser wirklich schönen Offline Variante.

Das größte Ärgernis für mich im Alltag ist immer noch das Wakeword.
Wenn es zuhören soll, tut es das nicht. Wenn es nicht zuhören soll, wird es vom Fernseher aktiviert oder der grade laufenden Unterhaltung.
Ich muss deutlich BumbleBEE sagen damit es klappt und im Fernsehen kann es ein Ton sein der nicht im geringsten etwas damit zu tun hat. Gefolgt von der Spannung welchen
Befehl er aus der laufenden Aufnahme glaubt zu erkennen. Meistens versucht er einen Timer zu stellen was wenig schmerzlich ist. Aber er hat auch schon meinen kompletten TV-Schrank ausgeschaltet
im laufenden Betrieb, was ziemlich ärgerlich war.

Welches Wakeword Modul benutzt ihr bzw. womit habt ihr die besten Erfahrungen gemacht?

Jetzt aktuell ist bei mir aber ein Problem aufgetreten. Ich hab seit längerer Zeit mal wieder versucht ein Licht mit dem SetNumeric Intent zu schalten. Dieser wird von Rhasspy korrekt erkannt und verarbeitet
aber auf FHEM Seite leider nicht. Es kommt zu folgender Ausgabe im Log:
2021.09.22 13:09:24 5: RHASSPY: [RhasspyTK] Parse (IO: Mqtt.Rhasspy): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-bumblebee_raspberry-pi-6ed673af-e988-4056-9525-75132ac2449f", "siteId": "wohnzimmer", "customData": "bumblebee_raspberry-pi", "lang": null}
2021.09.22 13:09:24 5: Parsed value: wohnzimmer for key: siteId
2021.09.22 13:09:24 5: Parsed value: wohnzimmer-bumblebee_raspberry-pi-6ed673af-e988-4056-9525-75132ac2449f for key: sessionId
2021.09.22 13:09:24 5: Parsed value: bumblebee_raspberry-pi for key: customData
2021.09.22 13:09:24 5: room is identified using siteId as wohnzimmer
2021.09.22 13:09:28 5: RHASSPY: [RhasspyTK] Parse (IO: Mqtt.Rhasspy): Msg: hermes/intent/de.fhem_SetNumeric => {"input": "die Licht schreibtisch auf 50 percent", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "schreibtisch"}, "slotName": "Device", "rawValue": "schreibtisch", "confidence": 1.0, "range": {"start": 10, "end": 22, "rawStart": 10, "rawEnd": 22}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 50}, "slotName": "Value", "rawValue": "fünfzig", "confidence": 1.0, "range": {"start": 27, "end": 29, "rawStart": 27, "rawEnd": 34}}, {"entity": "Unit", "value": {"kind": "Unknown", "value": "percent"}, "slotName": "Unit", "rawValue": "prozent", "confidence": 1.0, "range": {"start": 30, "end": 37, "rawStart": 35, "rawEnd": 42}}], "sessionId": "wohnzimmer-bumblebee_raspberry-pi-6ed673af-e988-4056-9525-75132ac2449f", "customData": "bumblebee_raspberry-pi", "asrTokens": [[{"value": "die", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "Licht", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 9, "time": null}, {"value": "schreibtisch", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 22, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 23, "rangeEnd": 26, "time": null}, {"value": "50", "confidence": 1.0, "rangeStart": 27, "rangeEnd": 29, "time": null}, {"value": "percent", "confidence": 1.0, "rangeStart": 30, "rangeEnd": 37, "time": null}]], "asrConfidence": 0.35006499999999996, "rawInput": "die licht schreibtisch auf fünfzig prozent", "wakewordId": "bumblebee_raspberry-pi", "lang": null}
2021.09.22 13:09:28 5: Parsed value: 50 for key: Value
2021.09.22 13:09:28 5: Parsed value: die licht schreibtisch auf fünfzig prozent for key: rawInput
2021.09.22 13:09:28 5: Parsed value: percent for key: Unit
2021.09.22 13:09:28 5: Parsed value: bumblebee_raspberry-pi for key: customData
2021.09.22 13:09:28 5: Parsed value: wohnzimmer for key: siteId
2021.09.22 13:09:28 5: Parsed value: SetNumeric for key: intent
2021.09.22 13:09:28 5: Parsed value: wohnzimmer-bumblebee_raspberry-pi-6ed673af-e988-4056-9525-75132ac2449f for key: sessionId
2021.09.22 13:09:28 5: Parsed value: schreibtisch for key: Device
2021.09.22 13:09:28 5: Parsed value: die Licht schreibtisch auf 50 percent for key: input
2021.09.22 13:09:28 5: Parsed value: 1 for key: probability
2021.09.22 13:09:28 5: handleIntentSetNumeric called
2021.09.22 13:09:28 5: room is identified using siteId as wohnzimmer
2021.09.22 13:09:28 5: Device selected (by hash, with room and name): Wz.Di.00_Dim
2021.09.22 13:09:28 1: PERL WARNING: Use of uninitialized value $change in hash element at ./FHEM/10_RHASSPY.pm line 3337.
2021.09.22 13:09:28 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/10_RHASSPY.pm line 3337.
Undefined subroutine &RHASSPY::round called at ./FHEM/10_RHASSPY.pm line 3369


FHEM schmiert ab und startet neu...

Habe ich bei den letzten Änderungen etwas wichtiges verpasst? Ich weiß leider nicht mehr welches die letzte für mich
funktionierende Modul Version war.

Gruß Ziton

drhirn

Ich hab Porcupine im Einsatz. Mit Porcupine als Wakeword. Auf diversen Raspberrys mit ReSpeaker 2MIC. Die Lösung für dein Problem war bei mir - so blöd das jetzt klingt - mit alsamixer den "Gain" zurück zu drehen. Das hat die Erkennung meiner Befehle wesentlich verbessert. Auf TV hört das Ding aber natürlich immer noch.

Bei mir wurde auch immer irgendwas ausgeführt. Meistens wurde ein Timer-Befehl verstanden. Ich hab dann meine Sentences so stark konkretisiert, dass es nicht mehr passiert. Speziell am Anfang des Satzes sollte etwas wirklich eindeutiges stehen. Hab ich zumindest das Gefühl.

Beta-User

#879
Hmm, alsamixer und Mobile App (bei mir), das klingt lustig...

Bzgl. "round": Das ist ein Bug, den ich wohl irgendwann unbemerkt eingebaut habe, als ich die ganzen "uses" einer Revision unterzogen habe, Danke für den Hinweis.

Die Funktion kommt eigentlich aus 99_Utils, und ist ... na ja...

Habe in der angehängten Version versucht, das zu fixen, kann eigentlich kaum schlechter laufen als die Versin von heute mittag (also wenn svn, dann bitte diese hier).

Sorry for inconvenience!

Nachtrag: Bei Prozent-Anweisungen crasht FHEM nicht mehr, ungetestet ist noch eine Stelle bei Abfragen. Dafür habe ich jetzt beim Rumtesten noch ein paar "uninitialized"-Warnings gesehen ::) ; als Merkposten für später:
2021.09.22 20:06:35 1: PERL WARNING: Use of uninitialized value $change in hash element at ./FHEM/10_RHASSPY.pm line 3342.
2021.09.22 20:06:35 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/10_RHASSPY.pm line 3342.
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

drhirn


JensS

#881
Die Dialog-Geschichte inkl. Confirm und Cancel ist eine gute Sache. Derzeit sehe ich aber Grenzen bei Rhasspy selbst.

  • keine Möglichkeit, Intents per Standard zu deaktivieren
  • bei Sprachausgabe wird das Mikro nicht gemutet (lokales Echo)
  • Nebengeräusche werden teilweise als Sprache erkannt
  • Slots sind in continueSession nicht dynamisch auswählbar
Das führt u.a. zur erwähnten "Stotterei", welche durch die IntentNotRecognized-Behandlung noch verstärkt wird.
Die negativen Aspekte können zwar teilweise kompensiert werden aber das sind dann nur (aufwendige) Notlösungen.
Ich hoffe, dass die Rhasspy-Entwicklung der Rhasspy-Community wieder mehr nach vorn, anstatt in die Breite geht.

Insgesamt ist die Implemetierung der aktuellen Rhasspy-Version in FHEM gut gelungen und funktioniert auch gut.
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

#882
Aus gegebenem Anlass ein kleines Zwischenupdate:
- verhindert den Absturz aus https://forum.fhem.de/index.php/topic,123439.0.html, wenn man vorher keinen CLIENT fertig konfiguriert hat;
- etwas aufgeräumt, v.a. bei den "unsicher" und "für später"-Kommentaren
- kleine commandref-Änderungen.

Für bisherige Nutzer eher kein Anlass zum updaten, aber testen wäre natürlich trotzdem nett...

EDIT: Modulupdate ist im svn (contrib)
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

...da sich bisher keiner beschwert hat...:
@drhirn: würdest du die letzte Fassung wieder einchecken?
(Dann würde die dann voraussichtlich im 6.1-Package landen).
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

Raemsna

Zitat von: Beta-User am 29 Juli 2021, 10:41:44

bzw. "lokal":
attr Sonos rhasspySpecials confirm: SetOnOff="wirklich $target $Value schalten?" SetScene

Hallo zusammen,

Verständnisfrage zur Bestätigung der Befehlsausführung...
Ich habe folgendes Setup:
- aktuellste 10_Rhasspy.pm aus Github
- aktuellstes language File rhasspy-de.cfg aus Github

bei meiner Wasserpumpe im Garten habe ich folgende Rhasspy spezifischen Attribute eingestellt. :


attr Garten_Wasserpumpe rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off
attr Garten_Wasserpumpe rhasspyName Wasser
attr Garten_Wasserpumpe rhasspyRoom Garten
attr Garten_Wasserpumpe rhasspySpecials confirm: SetOnOff="wirklich $target $Value schalten?" SetScene


wenn ich über Rhasspy die Wasserpumpe anschalte, kommt auch die Abfrage, "wirklich Wasser anschalten"? Das ist gemäß Einstellung.

Allerdings weiß ich nicht, was die korrekte Antwort auf die Frage im Falle eines gewünschten Anschaltens ist.
Ich habe schon "on", "an", "ja" usw. versucht, es wird aber immer etwas "komplett anderes" erkannt, z.B. zuletzt "lösche im" wo ich beispielsweise Nein gesagt hat.

Ich stehe leider auf dem Schlauch und freue mich (mal wieder) sehr über eure Hilfe!

Vielen Dank für das tolle Modul!!
Liebe Grüße
Raemsna