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:
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)?
