Modulentwicklung für Rhasspy Sprachassistent

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

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: JensS am 15 Juni 2021, 20:47:35
switchDM=1 war/ist gesetzt
Ah, ok, sorry für die Rückfrage, das war mir nicht klar.

Was du schreibst, klingt danach, als hätten die Filter irgendwelche Auswirkungen, was sich leider nicht mit meinen eigenen Beobachtungen deckt. Zum Teil könnte das daran liegen, dass ich bisher die App ohne Hotword zum Testen verwendet hatte, also die Sitzungsverwaltung nicht von der Base her initiiert wurde. Muss da noch weiter testen, aber das wäre eine Erklärung.

Falls die Filter bei dir/euch wirken:
Es würde mich interessieren, ob das immer gilt, nur dann, wenn die Sitzung über die Hotword-Erkennung der base lief, oder auch, wenn die Hotword-Erkennung auf dem Satelliten ablief.

Zitat
Abschließende Betrachtung zum Filter aus meiner Sicht:
Einen globalen Filter zu setzen, welcher alle Intents AUSSER ConfirmAction, etc. erlaubt, ist derzeit nicht in Sicht.
Oder bedeutet das, dass das "DialogueConfigureIntent" (Ausgabe an der Linux-Konsole) doch keine Auswirkungen hat?

Zitat
Intentfilterung via continueSession oder/und configure ist generell möglich.
Letztlich sollte nur eine Variante zum filtern genutzt werden.
Klar scheint mir, dass derzeit "zu viel" gefiltert wird (bzw. versucht wird zu filtern). Ziel sollte daher mAn. sein, jeweils nur "das Erforderliche" auf der richtigen Ebene zu filtern.

ZitatEs sollten passende Antworten zu confirm, cancel, intentNotRecognized und silence ausgegeben sowie der/die Filter zurückgesetzt werden.
Mir ist noch unklar, was mit "intentNotRecognized und silence" gemeint ist. Da bräuchte ich ggf. Material, um das nachzuvollziehen.
Unter "silence" würde ich grade verstehen, dass "nichts sagen" grade als "nein" erkannt und via ConfirmAction-intent weiterverarbeitet wird (weil das globale Filtern nicht funktioniert).

Ansonsten habe ich neben confirm und cancel noch die beiden "choice"-Intents, die auch (standardmäßig) deaktiviert werden sollten (aber eine "passende" Antwort liefern, wenn sie verfrüht angesprochen werden).
ZitatWenn das alles passt, könnte die Dialogroutine abgehakt werden.
Irgendwie sind m.E. dazu aber im Moment noch zu viele Fragezeichen offen....
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

Zitat von: Beta-User am 16 Juni 2021, 11:11:02
Zum Teil könnte das daran liegen, dass ich bisher die App ohne Hotword zum Testen verwendet hatte, also die Sitzungsverwaltung nicht von der Base her initiiert wurde. Muss da noch weiter testen, aber das wäre eine Erklärung.
Wie schräg ist das denn...?!? Es macht einen Riesen-Unterschied, ob eine Sitzung mit oder ohne Hotword (=per app-shortcut) gestartet wird.
Per Hotword sind die intentFilter auch nach Ende der session weiter aktiv!?! Ergo müßte man den nach Ende der Auswahl auch wieder zurücksetzen.
Auf den app-button hat das keinen Einfluss, startet man eine Session darüber, kann man unabhängig von den gesetzten intentFiltern und configures alle intents ansprechen...
Nicht lustig, im Moment habe ich k.A., wie man das in den Griff bekommen sollte. Die intentFilter wieder zurückzusetzen, sollte ja gehen, aber was bringt das, wenn "configure" als Oberfilter nicht durchschlägt?
Mal sehen, ob jemand von den Rhasspy-Leuten eine Idee hat.
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

#752
Zitat von: Beta-User am 16 Juni 2021, 11:11:02
Irgendwie sind m.E. dazu aber im Moment noch zu viele Fragezeichen offen....
Einige Fragen lassen sich eventuell mit verbose 5 am rhasspyMQTT2 klären. Das ist fast so gut, wie ein mosquitto_sub.
Bei (ja bitte|nein danke) funktioniert alles wie gewünscht - inkl. passenderAntwort.
Wenn man gar nichts sagt, läuft die Session durch und wird ordentlich beendet . Auch dann erhält man eine Antwort.
Der configure-Filter bleibt dauerhaft aktiviert, wenn nicht mit (ja bitte|nein danke) geantworten wird, sonder bspw. mit "wie spät ist es". Dort gibt es wohl noch ein "altes" Sprungziel.
In dem Fall muss man Rhasspy neu starten, um das configure zurückzusetzen.
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.

JensS

Zitat von: Beta-User am 16 Juni 2021, 20:17:40
Die intentFilter wieder zurückzusetzen, sollte ja gehen, aber was bringt das, wenn "configure" als Oberfilter nicht durchschlägt?
Der intentFilter sollte nicht das Problem sein. Der wird nach der Session von der Base zurückgesetzt. Wenn configure mit "default intent filter" nicht von fhem zurückgesetzt wird, klemmt's halt.
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 16 Juni 2021, 20:33:11
Der intentFilter sollte nicht das Problem sein. Der wird nach der Session von der Base zurückgesetzt. Wenn configure mit "default intent filter" nicht von fhem zurückgesetzt wird, klemmt's halt.
Sorry, verstehe ich nicht bzw. anders, oder das Verhalten ist auf einer Debian-Installation anders als auf docker:

Im Moment teste ich vorrangig ohne die zusätzlichen "configure"-Anweisungen, die globalen Deaktivierungs-Versuche gehen daher nur bei FHEM-Restart (oder Änderung der DEF) raus, das Verhalten war aber auch mit switchDM=1 schon "komisch" gewesen - daher der (mglicherweise falsche) Schluss, dass das "configure" im Endeffekt schlicht und ergreifend gar keine Auswirkungen zu haben scheint.
intentFilter ist auch bei ordnungsgemäßer Beendigung weiter aktiv, das habe ich grade mit und ohne switchDM nochmal durchgespielt.
Es scheint zwar partiell zu helfen, wenn man das configure "feuert", aber eine richtige Struktur kann ich im Moment nicht erkennen; das scheint bestenfalls eine Art globaler reset zu sein, was ja auch eine Option wäre, würde es immer funktionieren. Das tut es aber scheinbar auch nicht...
Und Rhasspy immer wieder neu zu starten ist ja auch keine Lösung, zumal dann ja auch die beabsichtigten partiellen Deaktivierungen (derzeit: via configure) wieder nicht Bestand hätten...

Bin irgendwie noch nicht auf den Trichter gekommen, wie das ganze gedacht ist, irgendwas übersehe ich bestimmt...
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

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 16 Juni 2021, 21:15:01
https://forum.fhem.de/index.php/topic,119447.msg1161151.html#msg1161151 hilft. Dann ist nur noch der intentFilter in Benutzung und (fast) alles ist gut.
Das Weglassen von switchDM in der DEF und ein einmaliger Neustart von Rhasspy haben mAn. genau dieselben Effekte: Es gehen keine Messages mehr an "configure". Soweit ich das bisher getestet habe, ist dann aber leider nichts wirklich besser.
intentFilter ist jedenfalls nicht auf die aktuelle Sitzung beschränkt und damit in der jetzigen Form unkalkulierbar. Ich bin auch unschlüssig, ob bzw. wie es sinnvoll ist, da noch weitere Anpassungen vorzunehmen, insbesondere, um auch den intentFilter wieder zurückzusetzen. Es wäre zwar möglich, das (De-) Aktivieren von intents in intentFilter "umzuziehen", aber nach meinem Eindruck ist  da eigentlich vorrangig zuerst auf der Rhasspy-Seite Nacharbeit erforderlich; das ganze wirkt auch mich schlicht unausgegoren oder einfach buggy. (Übergangsweise mag es aber sinnvoll sein, einen workaround zu bauen oder auch intentFilter komplett zu deaktivieren).

Mal sehen, vielleicht meldet sich ja jemand in der Rhasspy-community, der erklären kann, wie es "richtig" geht...
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

#757
Zu unserem "Lieblingsthema"
Zitat von: JensS am 16 Juni 2021, 21:15:01
https://forum.fhem.de/index.php/topic,119447.msg1161151.html#msg1161151 hilft. Dann ist nur noch der intentFilter in Benutzung und (fast) alles ist gut.
habe ich noch was von synesthesiam gefunden:
https://community.rhasspy.org/t/only-allow-some-intents-to-start-a-dialogue/973/5, zu intentFilter dann das hier: https://community.rhasspy.org/t/how-to-enable-continuous-mode/2277/4

Nach meinem Verständnis sollte es daher jedenfalls nicht falsch sein, hin und wieder "configure" aufzurufen, und das Beibehalten von intentFilter nach Session-Ende halte ich für einen Bug.

Habe gestern noch ein paar Tests gemacht. Nach denen scheint jedenfalls der Filter auch wieder zurückgesetzt zu werden, wenn "configure" (mit den für den Dauerbetrieb richtigen Werten) aufgerufen wird. Daraus habe ich den Schluss gezogen, dass es zum einen sinnvoll ist, "configure" relativ (mAn. eigentlich: zu) häufig aufzurufen, und zum anderen vermutlich kein Fehler, _vorher_ intentFilter wieder auf "null" (ohne Quotes) zu stellen.

Anbei eine (gg. dem gestrigen noch unvollständigen Stand ergänzte) Fassung, die jetzt immer bei _jedem_ Dialogende (ausgenommen also nur Rückmeldungen bei continueSession) beides machen sollte (vorläufig noch nur, wenn switchDM=1 gesetzt ist, das sollte dann aber wieder nicht mehr konfigurierbar sein).

Tests wären willkommen, da da ein (zusätzlicher) InternalTimer-Mechanismus zur Anwendung kommt, um das "configure" erst nach Dialogbeendigung anzuschubsen, ist es allerdings "leicht gefahrgeneigt".



Zur Abwechslung dann aber auch noch was ganz anderes: Gibt es eigentlich einen Grund, warum es a) zwei "TTS-Optionen" im Code gibt (EDIT: da hatte ich wohl was missverstanden) und b) (EDIT: für den einen TTS-Fall) nicht "einfach" der (mAn) default-Weg verwendet wird, den Sitzungsmanager anzuweisen, eine neue "notification"-Sitzung zu starten?
(Details siehe pod ab Zeile 2300).
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

#758
@Beta-User
Soeben habe ich eine Idee erfolgreich testen können. Es ist zwar keine elegante Lösung aber machbar.
Intent-Namen einsammeln und extrahieren:
http://rhasspy:12101/api/intents
Für alle sideId's (null) den "default intent filter" global setzen:
mosquitto_pub -t hermes/dialogueManager/configure -m '{"intents": [{"intentId": "alle Intents AUSSER de.fhem.ConfirmAction", "enable": true}], "siteId": null}'
In der Session den intentFilter setzen:
mosquitto_pub -t hermes/dialogueManager/continueSession-m '{"intentFilter":["de.fhem:ConfirmAction"],"sendIntentNotRecognized":true,"sessionId":"wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652","siteId":"wohnzimmer","text":"Soll ich die Stehlampe wirklich einschalten?"}'

Hintergrund:
Der "default intent filter" von configure wirkt global für alle siteId's und erlaubt alle Intents außer de.fhem.ConfirmAction. Ein "ja bitte" wird im laufenden Betrieb nicht erkannt.
Der intentFilter von continueSession wirkt lediglich in der gestarteten Session und wird abschließend gelöscht.
Der intentFilter hat eine höhere Prio als der "default intent filter" und überlagert diesen, allerdings nur in der Session. Anschließend gilt wieder der "default intent filter".

Wenn man also den "default intent filter" nach dem (re)start von Rhasspy aktiviert, ist alles wie gewollt. Nun fehlt nur noch ein Trigger dazu.

Gruß Jens

p.s. Bei der Überarbeitung meines Beitrags ist mir aufgefallen, dass "sendIntentNotRecognized":"false" den gewünschten boolschen Wert true ergibt und true statt "false" eingetragen.
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

#759
Anbei eine aktualisierte und bisher als ungefährlich eingestufte Aktualisierung.

Die bringt zum einen eine umgebaute speak-Routine, die den mAn. "korrekten" generischen Weg über den (Rhasspy-) Dialog-Manager geht.

Zum anderen konsolidiert das jedenfalls mal meine bisherigen Erkenntnisse, und v.a. auch ein paar der findings von @JensS:

Diese Tests und Feststellungen sind interessant, und das deckt sich eigentlich auch weitgehend mit meinen Erwartungen und dem Versuch, den Code dazu passend zu machen.
Für die RHASSPY-Entwicklung finde ich zwar das "alles aktivieren und dann ausgewählte deaktivieren" nicht "schick", weil das sehr "RHASSPY-zentriert" ist, aber nach meinen bisherigen früheren Tests müßte es eigentlich reichen, einfach (via configure) das zu deaktivieren, was man nicht braucht.

Besonders interessant fand ich, dass man mit "null" alle siteId's ansprechen kann, von daher geht jetzt an diese "Id" nur noch eine MQTT-Message raus, um (vermeintlich) alle unnötigen Intents zu "deaktivieren".

Leider funktioniert das dann grade in der Praxis alles  grade nicht, obwohl das "false" mAn. jeweils "korrekt" (ohne Quotes) übertragen werden sollte (in allen payloads/Fällen).
sentIntentNotRecognized verhält sich auch "komisch" bzw. anders als bisher?!?
Die "configure"-Messages gehen jetzt jedenfalls  (mit switchDM=1) zum "richtigen Zeitpunkt raus, also eigentlich müßte alles "fein" sein?
Leider bekomme ich meinen Rhasspy grade nicht motiviert, vernünftige Debug-Ausgaben zu machen, damit ich selber sehen kann, wann "false" als "true" interpretiert wird. Müsste erst mal Doku lesen, habe dazu jetzt aber grade keine Lust mehr; ein andermal...
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

#760
Zitat von: Beta-User am 20 Juni 2021, 10:20:02
nach meinen bisherigen früheren Tests müßte es eigentlich reichen, einfach (via configure) das zu deaktivieren, was man nicht braucht.

Die Negation eines Filters nach der Art !de.fhem.ConfirmAction ist in Rhasspy nicht vorgesehen. Zur Sicherheit habe ich mir die Quelltexte zu Dialogue und NLU angesehen und dort nur die einfachen intent_filter und intentFilter gefunden. Das deckt sich mit meinem Test vom 11.06.21 https://forum.fhem.de/index.php/topic,119447.msg1162076.html#msg1162076 .
Du wirst dich wohl oder übel vom Gedanken verabschieden müssen, dass es einen negierten globalen Filter "erlaube alles außer ..." gibt bzw. geben wird.

p.s. In den letzten Test-Versionen von 10_Rhasspy.pm scheint es eine Loop zu geben, so dass FHEM mit sich beschäftigt ist und keine Interaktion mehr möglich ist.
Der Prozess muss dann gekillt und neu gestartet werden. Bitte schau dir die letzten Änderungen einmal im Detail an. Eventuell ist es die Behandlung von sendIntentNotRecognized. Mir ist es zu aufwändig, die vielen Sprungziele zu prüfen und vom Debug halte ich wenig...

Richtig sollte es heißen: "sendIntentNotRecognized":true
https://rhasspy-hermes.readthedocs.io/en/latest/api.html#rhasspyhermes.dialogue.DialogueContinueSession
Wenn Quotes verwendet werden, wird "false" als String erkannt und ist somit größer als NULL. Die Base erkennt in den Fall ein boolsches true - was auch richtig wäre.
Wenn man die korrekte Syntax ohne Quotes verwendet, wird false als bool übertragen und die Base erkennt false (Defaultwert). Korrekt ist in dem Fall aber true.
https://rhasspy.readthedocs.io/en/latest/reference/#dialoguemanager_intentnotrecognized
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

Hmmm, doof, das...

Es ist mAn. dann nicht gut auf der Rhasspy-Seite gelöst, wenn man z.B. von FHEM aus dann eine Positivliste senden müßte, was man alles haben will. Das bringt die Gefahr mit sich, dass man unbeabsichtigt andere "Clients" beeinflusst, und sei es nur, weil man deren deaktivierte Intents auf diesem Weg anschaltet.

Da das ganze aber sowieso nur die Filterei zu beeinflussen scheint, aber nicht Intents komplett deaktiviert, ist das eh' nur bedingt tauglich.
Muss wohl nochmal das ganze durchdenken und ggf. dann auch nochmal auf der Rhasspy-Seite Rückmeldung geben.


Mit der Fassung von heute morgen und auch mit der Testversion habe ich keine wirklichen Probleme, FHEM läuft ohne Probleme. Allerdings hatte ich manchmal (mit picoTTS?) das Problem, dass sich Rhasspy beim sprechen selbst ausgewertet hat, und dann irgendwas im Kreis ging...
Hast du ggf. etwas MQTT-Verkehr dazu?

intentNotRecognized auf "false" zu setzen, ist eigentlich beabsichtigt, damit die session offen bleibt, wenn was anderes erkannt wird. Aber das muss man dann eh' überdenken, wenn es "nur" als Filter wirkt...
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

Danke für die schnelle Antwort.
Bei "sendIntentNotRecognized":false (default) übernimmt die Base die Verarbeitung und schließt die Session.
Bei "sendIntentNotRecognized":true wird die Verarbeitung an FHEM übergeben und die Session bleibt offen.
Das hattest du damals mit "sendIntentNotRecognized":"false" gelöst.
Nachdem das JSON neuerdings bereinigt wird, passiert genau das Gegenteil von dem, was anfangs geplant war.

Die Positivliste muss nur einmal global mit configure aktiviert werden. Die dabei deaktivierten Intents können ja temporär in der Session aktiviert werden. Da nur eine Session pro siteId möglich ist, und die Positivliste weiterhin für alle siteId's gültig ist, sollte das Ganze funktionieren.

Leider gehen die Quellen zu Rhasspy nicht ins Detail und so muss man sich mühevoll die Infos u.a. durch Analyse vieler Tests erarbeiten.
Vielen Dank, dass du dir die Arbeit machst, konsequent das Modul nach vorn zu bringen und zu optimieren.
Ich verstehe meinen Beitrag dabei als Unterstützung - keinesfalls als Kritik.
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 20 Juni 2021, 13:35:42
Nachdem das JSON neuerdings bereinigt wird, passiert genau das Gegenteil von dem, was anfangs geplant war.
Na supi, eigentlich einleuchtend (allerdings mAn. nicht das wording durch Rhasspy), aber diese ganze "um's-Eck-Denkerei" (in Verbindung mit der etwas dünnen Doku) macht mich fix und alle...

Wie dem auch sei:
http://rhasspy:12101/api/intentsist zwar "nett", aber auch nicht aufschlussreich, was die Frage von evtl. von anderer Seite (de-)aktivierten Intents angeht, jedenfalls, wenn ich beim Testen nicht wieder was grob falsch gemacht habe ::) .
Wenn ich das richtig verstanden hatte, kann man auch mit einem leeren Array alle Intents in die Positiv-Liste aufnehmen? Dann scheint mir das die einfachere Variante zu sein (iVm. mit nachgelagertem Ausschalten von allem, was wir per default nicht haben wollen). Ist zwar weiter mAn. "nicht gut", aber eben dann wohl die beste der heute möglichen Lösungen.

Zitat
Leider gehen die Quellen zu Rhasspy nicht ins Detail und so muss man sich mühevoll die Infos u.a. durch Analyse vieler Tests erarbeiten.
Na ja, und dann sind die Sourcen auch noch in python - und da habe ich "gewisse Orientierungsschwierigkeiten", und die Tests sind immer auch eher eine Momentaufnahme von dem, was grade auf FHEM-Seite raus- und reingeht, weniger, was auch in Rhasspy verstanden wird. "Blöd" ist insbesondere, dass die Reihenfolge passen (und evtl. die Sitzung auch noch offen sein) muss, sonst scheint es Probleme oder unbeabsichtigte Seiteneffekte zu geben.

ZitatVielen Dank, dass du dir die Arbeit machst, konsequent das Modul nach vorn zu bringen und zu optimieren.
Ich verstehe meinen Beitrag dabei als Unterstützung - keinesfalls als Kritik.
Paßt schon! Ich brauche halt manchmal etwas länger, um die Rückmeldungen einzuordnen und in den Code passend einzuarbeiten  ::) ...
Von daher geht der Dank auch zurück, denn diese Tests sind ja auch nicht eben unaufwendig, und da immer wieder (zum richtigen Zeitpunkt wieder) Rückverweise reinzubauen, wenn ich mal wieder länger auf dem Holzweg war, fällt ja auch nicht vom Himmel ::) .

Muss dann erst mal wieder testen, glaube aber, mit folgenden Zwischenschritten dann wieder weitergekommen zu sein (falls das alles auch klappt...):
-  "sendIntentNotRecognized" künftig auf (bereinigtes) "true"
- "configure" künftig dann zweistufig: Erst Array für "alles" aktivieren, dann ausgewählte deaktivieren; (wäre klasse, wenn man das in eine Message packen könnte, aber das ist mir im Moment "too much", ggf. sollte da auch auf Rhasspy-Seite noch was nachgearbeitet werden);
(Ergänzend, aber schon in der Vorversion eingebaut:)
- "intentFilter" wird bei allen abschließenden Meldungen wieder auf "null" gestellt.

Wenn das soweit klappt, wird sich die Frage stellen, ob wir "configure" dann sicherheitshalber häufiger aufrufen sollten oder eher nicht.


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)...
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

#764
Zitat von: Beta-User am 21 Juni 2021, 17:29:22
kann man auch mit einem leeren Array alle Intents in die Positiv-Liste aufnehmen?
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.
Hier mal ein Programmbeispiel zur Abfrage der vorhandenen Intents:sub intentList(){
my $intentString;
my $ua = LWP::UserAgent->new();
my $response = $ua->get("http://192.168.x.x:12101/api/intents");
my $content = $response->content;
my $ref = JSON->new->decode($content);
my @intents = keys %$ref;
while (@intents) {
    $intentString = $intentString."\"".pop(@intents)."\"\n";
};
$ref = encode('utf-8',$intentString);
return $ref;
}

Dort die nicht allzeit gewünschten Intents rauswerfen und den configure-Filter dauerhaft setzen.
Den intentFilter würde ich jeweils nur einmal bei continueSession definieren und dann durchlaufen lassen.

Gruß Jens

p.s. Ich hatte das mit einer händisch erstellten Positivliste gestestet und es hat alles zuverlässig funktioniert, wie gewollt.
Die Handy-App scheint (unabhängig von der Filterei) etwas sensibel auf nicht rechtzeitige Antworten im Netzwerk zu sein und hat auch schon mal einen Fehler ausgeworfen.
Ich habe zur Sicherheit bei allen Geräten/Servern IPv6 rausgenommen.
Zum testen empfehle ich einen Raspi oder die Base.

ZitatWenn das soweit klappt, wird sich die Frage stellen, ob wir "configure" dann sicherheitshalber häufiger aufrufen sollten oder eher nicht.
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.
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.