Modulentwicklung für Rhasspy Sprachassistent

[JensS]

Damit's auch mal wieder um was anderes geht:

An "confirm" habe ich auch schon etwas rumgehirnt, ggf. kommt dann als nächstes, dass man für Gruppen-OnOff (optional) Bestätigungen einbauen kann (über "tweaks"). Von der Syntax her wäre es dann so, dass man Intent-"Kürzel" und Gruppenname(n) (künftig dann ggf. noch: FHEM-Device-Name) angeben könnte, und das dann via regex gecheckt wird.
Für Devices dann in "specials" ähnlich, aber da dann nur als Regex für die Intent-Kürzel?

Das dann noch weiter zu verfeinern (z.B. nur "on", aber nicht "off"), ist evtl. etwas schwieriger, aber bis auf den geschliderten Level runter sollte es "eigentlich" mit vertretbarem Aufwand machbar sein (wenn das mit den Filtern mal endlich soweit passt)...

Sieht interessant aus - bin schon auf die Ref gespannt!

[Beta-User]

Ein leeres Array löscht den Filter. Das sieht genau so aus, als wären alle Intents in einer Positivliste. Aber man kann nichts, in einer nicht existierenden Liste durch false ausschließen. Klingt komisch  - is aber so.

...da war doch was ...
Das scheint in der Tat so gelöst zu sein, dass beide Filter eigentlich (immer) als Positivliste zu verstehen sind, und mit dem letzten Element dann die ganze Liste gelöscht wird. Was den "configure"-Filter angeht, gefällt mir das nicht wirklich, aber zumindest im Moment müssen wir wohl damit leben.

Hier mal ein Programmbeispiel zur Abfrage der vorhandenen Intents:
[...]

Danke für den Schnipsel, ich habe das jetzt erst mal in der Form umgesetzt, dass
- beim FHEM-Start bzw. nach Änderung der DEF ein API-Request abgesetzt wird, der dann asynchron abgearbeitet wird;
- die intents in einem Reading landen (Komma-separiert (?));
- der callback dann auch ein "configure" initiiert, durch das alle Intents (bis auf unsere Standard-Negativliste) aktiviert bleiben sollten (das ganze geht auf einmal raus).

Zumindest auf den ersten Blick sieht das auf der MQTT-Seite ok aus, und "nein" wurde mit "intent not recognized" bzw. "nichts" quittiert, viel mehr habe ich bisher nicht getestet.
Das ist jetzt irgendwie "gefühlt unfertig". Meine "Bauchschmerzen":
- Zunächst müssten wir checken, dass der globale Filter auf diese Weise korrekt gesetzt wird und aktiv ist (s.u.).
- Dann muss geklärt werden,
-- wann jeweils das "globale configure" aufgerufen werden sollte (ich vermute: das muss nicht ständig sein, aber eben nach jedem Rhasspy-Restart, von dem wir aber nichts mitbekommen (? - evtl. gibt's die Möglichkeit, irgendwie an die uptime von Rhasspy (-hermes) zu kommen?), und
-- wie das Verhältnis von intentFilter und globalem Filter wirklich ist, wenn die Sitzung "zu" ist (und ob ggf. ein "nachgeschobenes" "null" für intentFilter@siteId ausreicht, um den globalen Filter wieder aktiv zu bekommen).

hermes/nlu/query gibt den aktiven Filter aus. Allerdings nur im laufenden Dialog. Der configure-Filter könnte neu gesetzt werden, wenn ein Diff zum api/intents-Ergebnis minus ConfirmAction etc. existiert.

Danke für den Hinweis, muss ich mir dann mal im laufenden Betrieb ansehen, was darüber dann kommt - und wie man das ggf. verwerten kann. Meine Befürchtung wäre, dass man dann relativ viel Daten intern vorhalten muss und bedingte (asynchrone) Auswertungen vornehmen - puh...

Zum testen empfehle ich einen Raspi oder die Base.

Mein eigentliches Zielgerät ist und bleibt halt der Android, und auch zum Testen ist der schneller bei der Hand ...

Sieht interessant aus - bin schon auf die Ref gespannt!

...erst mal ohne cref und ungetestet, aber für SetOnOffGroup eventuell schon funktional...
Das ganze ist relativ generisch angelegt und sollte daher auch relativ einfach auf andere Gruppen- und auch Einzelintents erweitert werden können. (Falls das mit den Dialogen dann mal voll funktioniert...)

[JensS]

Zeile 771 musste noch ein ; ran.
Ich teste gleich mal...

Prima, sieht gut aus! Alle Möglichkeiten werden richtig abgefangen und zu Ende gebracht.
Machst du das configure nach endSession oder kommt das von der Base? Hab mich gerade im Code verirrt. 

[Beta-User]

Zeile 771 musste noch ein ; ran.

Ups, sorry, hatte ich nur auf dem Hauptsystem ergänzt...

Ich teste gleich mal...

Prima, sieht gut aus! Alle Möglichkeiten werden richtig abgefangen und zu Ende gebracht.
Machst du das configure nach endSession oder kommt das von der Base? Hab mich gerade im Code verirrt. 

Wann das "configure" aufgerufen wird, hängt von der DEF ab. Mit "switchDM=1" wird das bei jedem von FHEM aus initiierten Dialogende rausgepustet, ohne nur zum Start...

Klingt danach, als wäre

- Zunächst müssten wir checken, dass der globale Filter auf diese Weise korrekt gesetzt wird und aktiv ist (s.u.).

soweit geklärt; der "zusammengefasste Filter auf siteId=>null" scheint ok zu sein .

Damit wären wir bei

- Dann muss geklärt werden,
-- wann jeweils das "globale configure" aufgerufen werden sollte (ich vermute: das muss nicht ständig sein, aber eben nach jedem Rhasspy-Restart, von dem wir aber nichts mitbekommen (? - evtl. gibt's die Möglichkeit, irgendwie an die uptime von Rhasspy (-hermes) zu kommen?), und
-- wie das Verhältnis von intentFilter und globalem Filter wirklich ist, wenn die Sitzung "zu" ist (und ob ggf. ein "nachgeschobenes" "null" für intentFilter@siteId ausreicht, um den globalen Filter wieder aktiv zu bekommen).

Mehr Infos zu letzterem Punkt sollte man dadurch bekommen können, dass man den Schalter in der DEF rausnimmt (und Rhasspy während des Tests nicht neu startet!). Passen dann die Filter (bzw. werden dann nur die jeweils gerade relevanten Intents erkannt), funktioniert auch das "Überlagern" des globalen Filters durch den "continue"-Mechanismus und das Zurücksetzen nach Dialogende (mit "null").
(Falls Rhasspy zwischendurch doch neu gestartet werden muss: danach die DEF anfassen, z.B. ein Leerzeichen reinmachen oder so, dann geht der request auch raus).

(Erst) dann können wir überlegen, wann es Sinn macht, das globale "configure" aufzurufen - bzw. vermutlich besser: den api-Request abzusetzen? Dessen Antwort triggert dann das configure zum richtigen Zeitpunkt, nämlich nach Erhalt der ggf. aktualisierten Intent-Liste.

[JensS]

Ich hab mal die Zeilen 2285 und 2286 auskommentiert. Läuft weiterhin 1a!
So kann ConfirmAction etc. in den produktiven Betrieb gehen.
Wie und wann die Positivliste gesetzt werden muss, ist schwer ermittelbar. Die Routine bei der Definition ist jedefalls schnell und zuverlässig durchgelaufen.
Schau die mal die hermes/nlu/#-Messages an, ob das mit einem Filtervergleich praktikabel wäre.
Was besseres fällt mir (noch) nicht ein. Notfalls erst mal ein set...

Gruß Jens

[Beta-User]

Hmm, #2286 leuchtet mir ein, das läuft auf dasselbe raus, wie den Wert aus der DEF zu nehmen (was mittelfristig das Ziel sein sollte; das ist ja nur zum Testen und einfachen Umschalten drin).

#2285 ist ein "Hosenträger". Wenn es ohne geht, auch gut, aber als Merkposten sollte die Zeile erst mal drin bleiben, falls es doch komische Effekte gibt (kann aber auch sein, dass ich wegen der "false=>true-Geschichte jetzt in dem Punkt übervorsichtig bin...).

Den Verkehr aaO schaue ich mir bei Gelegenheit dann mal in Ruhe an, eventuell können wir auch in der Rhasspy-Communitiy mal nachhaken, ob es möglich ist, irgendwie eine Signalisierung von einem Rhasspy-Start zu bekommen. Oder wir feuern halt von Zeit zu Zeit während eines laufenden Dialogs eine Abfrage raus, ob noch ein Filter gesetzt ist und reagieren dann, wenn da nicht rechtzeitig eine (aus FHEM-sicht korrekte) Antwort kommt?
Insgesamt gefällt es mir aber nicht, dass der globale Filter nicht per default aktiv (und persistent) ist. Das würde ich eigentlich vorrangig zu allem anderen in die Rhasspy-Community als Änderungswunsch rückmelden (wenn der Rest soweit läuft)...

[JensS]

#2285 ist ein "Hosenträger". Wenn es ohne geht, auch gut, aber als Merkposten sollte die Zeile erst mal drin bleiben, falls es doch komische Effekte gibt (kann aber auch sein, dass ich wegen der "false=>true-Geschichte jetzt in dem Punkt übervorsichtig bin...).

Sicher ist sicher - Gürtel und Hosenträger. 
Finde ich auch gut so, lasse es aber trotzdem (bei mir) auskommentiert und stelle es auf Wiedervorlage.

Den Verkehr aaO schaue ich mir bei Gelegenheit dann mal in Ruhe an, eventuell können wir auch in der Rhasspy-Communitiy mal nachhaken, ob es möglich ist, irgendwie eine Signalisierung von einem Rhasspy-Start zu bekommen. Oder wir feuern halt von Zeit zu Zeit während eines laufenden Dialogs eine Abfrage raus, ob noch ein Filter gesetzt ist und reagieren dann, wenn da nicht rechtzeitig eine (aus FHEM-sicht korrekte) Antwort kommt?
Insgesamt gefällt es mir aber nicht, dass der globale Filter nicht per default aktiv (und persistent) ist. Das würde ich eigentlich vorrangig zu allem anderen in die Rhasspy-Community als Änderungswunsch rückmelden (wenn der Rest soweit läuft)...

Das wäre gut, genau wie die Möglichkeit einer Negativliste. Die Jungs sind leider nicht so gesprächig...

[JensS]

@Beta-User
Könntest/würdest du ein Mäpping für die Bestätigungsanfrage bei SetOnOff schreiben?

Gruß Jens

p.s.
Hab mal eben die Rhasspy-Quellen nach einer gangbaren Lösung für eine Startmessage durchsucht und eine Zeile in /var/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/_init_.py zugefügt:

Code Auswählen Erweitern

    # -------------------------------------------------------------------------
    # MQTT Event Handlers
    # -------------------------------------------------------------------------

    def on_connect(self, client, userdata, flags, rc):
        """Connected to MQTT broker."""
        try:
            self.is_connected = True
            _LOGGER.debug("Connected to MQTT broker")

            # Default subscriptions
            self.subscribe(
                HotwordDetected,
                AsrTextCaptured,
                NluIntent,
                NluIntentNotRecognized,
                AsrAudioCaptured,
                AudioSummary,
            )
            self.client.publish("hermes/start", '{"event":"start"}')
            # Re-subscribe to everything
            for topic in self.all_mqtt_topics:
                self.client.subscribe(topic)
                _LOGGER.debug("Subscribed to %s", topic)

            self.connected_event.set()
        except Exception:
            _LOGGER.exception("on_connect")

Beim (re)start wird dann eine Message hermes/start {"event":"start"} ausgegeben. Vielleicht implementieren die Rhasspy-Leute das, wenn du das dort postest. Mein Englisch ist super schlecht...

p.p.s. Hab die Nachricht auf ein JSON geändert. Auswerten kann man das, wenn die subscriptions der rhasspy-MQTT-Bridge um hermes/start erweitert wird.
Dann ein MQTT2_DEVICE anlegen:

Code Auswählen Erweitern

defmod MQTT2_rhasspyMQTT2 MQTT2_DEVICE rhasspyMQTT2
attr MQTT2_rhasspyMQTT2 event-on-update-reading event
attr MQTT2_rhasspyMQTT2 readingList rhasspyMQTT2:hermes/start:.* { json2nameValue($EVENT) }
und ein Notify drauf ansetzen:

Code Auswählen Erweitern

defmod updateIntentFilter notify MQTT2_rhasspyMQTT2 set  Rhasspy update intent_filter

[Beta-User]

...da waren noch ein paar Wackler in der vorigen Version drin, das mit dem SetOnOffGroup klappt (erst) mit der beigefügten Version. Die braucht einen restart, damit der neue language-key eingefügt wird.

Code Auswählen Erweitern

attr rhasspy rhasspyTweaks confirmIntents=SetOnOffGroup=rollläden,deckenlichter

Zum Rest ein ander Mal.

[Beta-User]

Erst mal ein paar ergänzende Infos, was die letzte Version eigentlich so alles mitbringt.... Hier erst mal eine shortlist:

1.
- der "lang"-key wird mit durchgeschleust;
- sendSpeakCommand() adressiert jetzt "startSession" statt direkt die "tts/say"

2.
- fetchIntents() als neue interne Funktion eingefügt, die setzt dann in der Folge auch den globalen Filter zurück;
- es gibt einen setter dafür (unterhalb update), das ganze wird derzeit ansonsten nur beim FHEM-Start bzw. bei Änderung der DEF ausgeführt;
- switchDM gibt's nicht mehr (war nur ein Hilfsmittel zum testen)

3.
- es gibt den neuen Tweak "confirmIntents" (mehr dazu unten);
- und das "Special" "confirm" (s.u.)
- getNeedsConfirmation() als neue zentrale Funktion eingefügt.

4.
- sendIntentNotRecognized ist "repariert" und steht im Moment auf "true". Das scheint (vorläufig gesprochen) die "richtige" Einstellung zu sein, wenn man einen Dialog mit dem App-shortcut startet, für per hotword eröffnete sessions scheint es egal zu sein, ob man das überhaupt mitsendet;

5.
- die respond()-Funktion ist umgebaut und extrahiert jetzt die relevanten Daten direkt aus $data (ist eher intern und aus User-Sicht uninteressant)
- Ausgabemöglichkeit für "speakerless"-Satelliten (Reading-Auswertung "siteId2doubleSpeak_<siteId>")

Etwas mehr Details zu einigen der Stichworte:
1. "lang"-key durchschleusen
Aus https://community.rhasspy.org/t/passing-language-setting-to-intent/2903/2 (und dem dort weiter verlinkten Material) habe ich den Schluss gezogen, dass es sinnvoll ist, diesen Key weiterzugeben, wenn er vorhanden ist. Inwieweit das ggf. dann dazu genutzt werden _könnte_, auch eine automatische Übersetzung unserer "englischen" default-Antworten in die gewünschte Zielsprache zu ermöglichen, weiß ich im Moment auch nicht, ebensowenig wie geklärt ist, ob es ggf. sinnvoll wäre, den "notification"-Messages (aus speakCommand) gleich die lang-Info (aus dem Internal LANGUAGE) mitzugeben...
Also falls da einer unserer Mehrsprachler tiefer einsteigen will...

2. (und evtl. 4.)
In dem Filter-Thema ist jedenfalls jetzt Bewegung drin .

Beim (re)start wird dann eine Message "hermes/start on" ausgegeben. Vielleicht implementieren die Rhasspy-Leute das, wenn du das dort postest.

Hab's mal da eingekippt , in diese Richtung ging auch die Überlegung von @synesthesiam.
Mal sehen, was wir in dem Zusammenhang wann wie umbauen können/müssen.

3.
Das mit der Bestätigungsanforderung ist jetzt im eigentlichen Intent-spezifischen Code relativ unaufwändig gelöst. Im aktuellen Beispiel "handleIntentSetOnOffGroup" ist es nur die eine Zeile:

Code Auswählen Erweitern

return $hash->{NAME} if !$data->{Confirmation} && getNeedsConfirmation( $hash, $data, 'SetOnOffGroup' );Bevor wir das aber auf diese Art weiter ausrollen, noch ein paar Gedanken dazu:
- Zum Aktivieren (für Gruppen) kann man den beschriebenen Tweak setzen, Syntax ist "intent=<Gruppennamen>". Für diesen Fall halte ich auch die Syntax für ok und verständlich, Gruppen mit Leerzeichen kann man (wie parseParams-üblich) mit dem Setzen passender Quotes ebenfalls verwenden.
Unsicher bin ich allerdings, ob das Komma als Trennzeichen glücklich gewählt ist, denn das Ganze könnte man auch als Regex formulieren und umdrehen, was ggf. die flexiblere Variante wäre. => Meinungen dazu?!? (Meine eigene Tendenz wäre, das in diese Richtung umzubauen)
- Theoretisch geht das genauso (per Tweak) mit den FHEM-Device-Namen und Einzelintents (man muss die Zeile dann nur mit "nicht im Bulk-Modus" ergänzen), ABER:
- Eigentlich finde ich die Logik eingängiger, alles, was mit einzelnen Devices zu tun hat, auch (nur) über "Specials" zu regeln und würde das tendenziell daher als Tweak deaktivieren. Andererseits: eine Regex-Lösung funktioniert mAn. nur zentral, von daher ist meine aktuelle Tendenz, das an der Stelle beizubehalten (eigentlich nur wegen der regex-Option);
- Was "Specials" angeht, ist das derzeit (ungetestet) eine einfache "per-intent"-Lösung. Vermutlich ließe sich das auch noch filigraner lösen (also nur z.B. für das "off"), aber das würde "gefühlt" wieder deutlich mehr Coding erfordern. Insgesamt bin ich gedanklich noch nicht so richtig bei Einzelgeräten angekommen gewesen, und im Moment habe ich erst mal nur die richtige Stelle für die Abfrage bei dem (relativ einfachen (!)) SetOnOff-Intent lokalisiert: Es muss der FHEM-Device-Name bekannt sein, also kurz vor analyzeAndRunCmd() (#2869). Dachte erst, bei anderen Intents gäbe es deutlich mehr Stellen, aber die Zahl der Aufrufe ist zum Glück relativ begrenzt... (Erfahrungsgemäß steckt der Teufel dann aber im Detail, sobald man was umsetzen will ).

Wie ist denn die allgemeine Temperatur dazu? Braucht es filigranere Unterscheidungen (bzw. würde es ggf. reichen, on und off gesondert zu betrachten)?

[JensS]

https://community.rhasspy.org/t/lost-in-dialogues-customdata-intentfilter-and-dialoguemanager-configure/2890/9?u=jens-schiffke
Aus meiner Sicht wäre es besser, wenn @synesthesiam continueSession um die Option "slot" erweitern würde.
Die configure-Lösung springt quasi in die Bresche, um bestimmte Worte, wie "ja" per Filter im laufenden Betrieb auszuklammern.
Wenn "ja" erst gar nicht erkannt würde, weil der entsprechende Slot keinem Intent zugeordnet ist, würde der intentFilter genügen.
Das macht Dialoge einfacher, sicherer und flexibler.
Natürlich kann ich mit meiner Auslegung der Hermes-Referenz daneben liegen...
Wie du schon bemerkt hast, sollte es nicht um Reiseziele, sondern um Devices gehen. Ich fand die Reise anschaulicher.

[Beta-User]

Die configure-Lösung springt quasi in die Bresche, um bestimmte Worte, wie "ja" per Filter im laufenden Betrieb auszuklammern.

So ist das derzeit gelöst, und wenn dann ein Filter angewendet wird, geht's nach "intentNotRecognized", was - je nach Anweisung an den DialogueManager - eben dann Ende des Dialogs (false) bzw. "lass das externe Programm entscheiden" bedeutet (s.u.).

Das "Grundproblem" scheint zu sein: Rhasspy muss vorher wissen, welche "Datenmodelle" es auswerten darf. Die werden beim "training" erstellt - auf Basis der zu diesem Zeitpunkt vorhandenen "Effektivsätze", die daraus gebildet werden, dass alle Varianten der "sentences.ini" (bzw. alle relevanten "Rohsätze") aus den vorhandenen Bausteinen (feste und optionale Elemente aus den Sätzen unter Berücksichtigung aller Varianten, die sich durch die Auflösung der Variablen (also auch: slots)) ergeben.

Ändert man nachträglich was (aktiviert slots?), muss man neu trainieren, was (derzeit) aus Zeitgründen effektiv nicht geht.

Ein "slot" entsprechend deinem Vorschlag könnte daher (diesem Verständnis folgend) allenfalls ein kompletter "Satz" sein, der eben (nach dem Training) entweder aktiviert wird oder nicht, aber mAn. ist es etwas anderes wie andere "slots", die im Prinzip als variable _Bestandteile_ von Sätzen fungieren und daher vor dem Training "eingeordnet" (oder vielleicht ist "ausgepackt" plakativer?) werden müssen.

Vielleicht wäre es besser, von einem "optionalSentence" zu sprechen, der dann flexibel beliebigen Intents zugeordnet werden kann?

Das könnte in der Tat eine gewisse weitere Flexibilität ermöglichen, interne Basis wäre aber weiter die Option, einzelne Sätze (egal ob per (globalem) Filter oder per "optionalSentence") für die Erkennung komplett ein- und auszuschalten (ohne Training).

Ich fand die Reise anschaulicher.

Das mit der Reise ist anschaulicher. Um im Bild zu bleiben: Wenn man in Rom startet, braucht man in der zweiten Anfrage "Rom" nicht mehr verstehen; dieses Schlüsselwort sollte also aus dem slot raus bzw. die damit gebildeten Sätze sollten dann auch nicht mehr erkannt werden...
Alles nicht so einfach.

Wenn "ja" erst gar nicht erkannt würde, weil der entsprechende Slot keinem Intent zugeordnet ist, würde der intentFilter genügen.
Das macht Dialoge einfacher, sicherer und flexibler.

Zwischenzeitlich bin ich nicht mehr unbedingt sicher, ob diese These zutrifft.
Unsere Ausgangsmotivation ist doch in etwa so (oder ?): Es ist keine gute User-Erfahrung, wenn Rhasspy in einem Dialog zwischendurch plötzlich "irgendwas" erkennt und von sich aus scheinbar das Thema wechselt. Das kann man mit den heutigen (Filter-) Mechanismen (teilweise) abfangen (vorausgesetzt, das Dialogue-Management wird durch Rhasspy-hermes gesteuert), oder auch nicht, was dann eben das vorzeitige Dialog-Ende bedeutet (was derzeit fast noch die "beste" Lösung erscheint).
Das Thema zu wechseln kann aber auch gewollt sein, und dann ist es (auch für die User-Experience) kontraproduktiv, wenn man nicht flexibel reagiert...

Letzteres würde bedeuten, den intentNotRecognized-Topic auszuwerten, und dann Daten zu konsolidieren, die History berücksichtigen, entweder einfach erst mal still sein (wie mit "true" heute) oder nochmal nachhaken, ...
Muss mal sehen, ob sich da was machen läßt, aber das sieht mir tricky aus.

[JensS]

Ok, dann wollen wir mal sehen, was die Rhasspy-Leute daraus machen.
Wenn "slot" nach dem Ansatz umgesetzt wird, wie ich ihn verstanden habe, wäre es ein weiterer Schritt nach vorn.
Man könnte dynamisch Rückfragen erstellen und sich dabei aller denkbaren Slots (Device, Room, Zahl, Uhrzeit, Dauer, etc...) bedienen.
Dazu genügt ein Intent "Dialogue" eine sub "rhasspyDialogue" als Dialog-Bridge. Man bräuchte nicht für jede Situation einen extra Intent.

p.s.

Das Thema zu wechseln kann aber auch gewollt sein, und dann ist es (auch für die User-Experience) kontraproduktiv, wenn man nicht flexibel reagiert...
Letzteres würde bedeuten, den intentNotRecognized-Topic auszuwerten, und dann Daten zu konsolidieren

Das sollte unbedingt mit rein. Das hat Potenzial. Beim intentFilter werden alle gelernten Worte zur STT mit einbezogen aber nur die gefilterten Worte als Treffer ausgegeben. Die verworfenen Worte werden trotzdem über MQTT ausgegeben. Das hat schon was...

[Beta-User]

Man könnte dynamisch Rückfragen erstellen und sich dabei aller denkbaren Slots (Device, Room, Zahl, Uhrzeit, Dauer, etc...) bedienen.
Dazu genügt ein Intent "Dialogue" eine sub "rhasspyDialogue" als Dialog-Bridge. Man bräuchte nicht für jede Situation einen extra Intent.

Na ja, weiß nicht recht...

Das Problem ist mAn. weniger, dass man ggf. viele Intents braucht, sondern eher, dass man zu jedem Zeitpunkt weiß, was (mit der notwendigen Sicherheit) jeweils gewollt ist. Es kann daher zwar hilfreich sein, wenn man z.B. einen (sehr kurzen) Bestätigungs-Satz (bzw. Abbruch/zurück,...) "überall" einbauen kann, aber ansonsten fand ich die "Vorstrukturierung" über die Erkennung der diversen Intent-Sektionen in der sentences.ini eigentlich ganz ok.

p.s.Das sollte unbedingt mit rein. Das hat Potenzial. Beim intentFilter werden alle gelernten Worte zur STT mit einbezogen aber nur die gefilterten Worte als Treffer ausgegeben. Die verworfenen Worte werden trotzdem über MQTT ausgegeben. Das hat schon was...

Auch da: schon, aber soweit meine Tests bisher reichen, bekommt man eben dann nur den "raw"-Text ohne die erkannten Bestandteile. Im Ergebnis wird man dann vermutlich nochmal eine Schleife brauchen, in der dann entweder der User nochmal "seinen" (bereits erkannten) Satz sagt, oder wir müssen den rawInput dann wieder über die Intent-Erkennung laufen lassen, nachdem der Filter geändert/den neuen Gegebenheiten angepaßt wurde => gefühlt müssen sehr viele Dialogstufen zwischengespeichert werden und zu jedem Zeitpunkt dann wieder der passende Aspekt hervorgeholt werden (und passend beantwortet!).
Bin ehrlich gesagt grade nicht sicher, ob
a) sich das lohnt und
b) ich überhaupt in der Lage wäre, sowas als programmtechnischen Ablauf sauber zu designen .

Werde mal versuchen, zumindest die erste Stufe, also Erkennen und Auswerten von intentNotRecognized, mal abzubilden. Erst danach läßt sich vermutlich erkennen, wie es dann weitergehen kann...

[JensS]

Es geht ja nur um die Rückfrage-Dialoge.
Die normale sentences.ini und der bisherige Programmcode bliebe unangetastet und würde wie gewohnt abgearbeitet.

Wenn der intentFilter gesetzt ist und keine Antwort, wie "ja bitte" sondern "wie spät ist es" gegeben wurde, erhält man vor der intentNotRecognized-Nachricht eine NLU-Message (sofern aboniert).

Code Auswählen Erweitern

hermes/nlu/query {"input": "wie spät ist es"