Modulentwicklung für Rhasspy Sprachassistent

[JensS]

Ok, mit der aktuellen Version und f= und d= wird das Event ausgelöst. Das hatte in der Vorversion mit den selben Bedingungen nicht geklappt.
Die Perl-Anweisung geht nur mit d=. Wenn ich das d= weglasse, weil die Perlanweisung über ein einzelnes Dummy hinausgehen könnte, wird kein Event erzeugt.

Code Auswählen Erweitern

2021.07.22 16:25:09 4: dummy set Gartensprenger on
2021.07.22 16:25:09 4: [Rhasspy] dispatch result is Rhasspy

Doppelt nein:
- my $foo = "baa" if $baz; ist grundsätzlich eine "unzulässige" Anweisung. (Wenn, dann müßte man $foo vorher einführen);
- wenn der Hash nicht defined ist, bleibt $cmd undefined, und genau das wird später gecheckt.

... natürlich. Klar müsste zuvor deklariert werden. Mir ist bei der Initialisierung von shortCuts aufgefallen, dass {perl} nur erzeugt wird, wenn ein p= existiert.
Ein paar Zeilen zuvor wird {perl} zwangsweise deklariert - daher ist ein exists eh falsch.

[Beta-User]

Danke für die Rückmeldung.

Habe ich das jetzt richtig verstanden, dass ich das von der Liste streichen kann, oder ist doch noch was offen?

Ein paar Anmerkungen:
- Eigentlich ist der "f="-Teil gar nicht geändert, nur beim Perl-Zweig wird jetzt (entsprechend der Doku) "d" berücksichtigt.
- Perl wird btw. auch "gesetzt", wenn die Zeile in der "alten Notation" gefunden wird, also nicht mit "i=..." beginnt.
- Es kann jetzt eine "Lücke" geben, wenn der Code Gerätenamen zurückgibt. Die werden jetzt nicht mehr als "getriggert" erkannt. Glaube allerdings nicht, dass das eine größere Anzahl von Usern bisher genutzt hatte...
=> das könnte man auch noch abfangen bzw. erweitern, wenn man das Ergebnis (wie in CustomIntent) auf den Datentyp prüft.  Dann könnte man bei einem Array (usw....).

(Frage mich grade, ob man an der Stelle devspec zulassen sollte (und devspec2array+join dranhängen, was relativ einfach ginge). Konkrete Device-Namen in der Config sind irgendwie gefühlt sehr statisch (aber hier vermutlich verschmerzbar, zumindest solange die Anweisung selbst nicht devspec nutzt...)).

[JensS]

Igendwie muss es eine Änderung gegeben haben, welche auch den f-Zweig in irgendeiner Weise auf die Beine geholfen hat.
Von der Liste streichen - hab ich noch ein flaues Gefühl. Wenn man eine Perlanweisung mit dem gleichen Erfolg, wie in der Befehlszeile absetzen kann - dann gern. Man kann ja einen Hinweis in der cref machen und sich bei Bedarf drum kümmern.
Vorerst ist es für mich eine Möglichket, SetOnOff-Geräte gesichert zu schalten. Muss halt nur eine zusätzliche Anweisung ($de.fhem.Device einschalten) nutzen.

[Beta-User]

Vorerst ist es für mich eine Möglichket, SetOnOff-Geräte gesichert zu schalten. Muss halt nur eine zusätzliche Anweisung ($de.fhem.Device einschalten) nutzen.

...da war doch was...

Bisher gab es praktisch keine Rückmeldung zur "Temperaturanfrage":

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

[...]
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)?

Mir ist schon klar, dass das Geschreibsel nicht so einfach zu verstehen ist; im Zweifel bitte einfach nachfragen, wie es gemeint ist...

Ansonsten löse ich das ggf. irgendwann dann eben auf die Art und Weise, die mir zu diesem Zeitpunkt grade im Kopf rumspukt...

[JensS]

Mir ist schon klar, dass das Geschreibsel nicht so einfach zu verstehen ist; im Zweifel bitte einfach nachfragen, wie es gemeint ist...

Das kann ich unterstreichen. 
Anstatt mit vielen Tweaks zu arbeiten, würde ich manche Funktionen in bestehende Intents integrieren. Manchmal ist weniger mehr.

Allgemein fände ich  es gut, wenn es u.a. im SetOnOff-Mapping möglich wäre, eine optionale Rückfrage zu stellen. Bei dem einen Device muss ich aktuell "schalte die Stehlampe an" sagen und beim anderen "Gartensprenger einschalten". Eine Option confirm="Soll ich $DEVICE wirklich einschalten?" (im Zusammenhang mit Confirm- CancelAction) würde das lösen.

Gruß Jens

[drhirn]

Stimme Jens zu. Das mit den Tweaks ist nicht so intuitiv. Wie wär's mit einem eigenen Attribut?

[Beta-User]

Das kann ich unterstreichen. 
Anstatt mit vielen Tweaks zu arbeiten, würde ich manche Funktionen in bestehende Intents integrieren. Manchmal ist weniger mehr.

Na ja, ich finde "Tweaks" und "Specials" eigentlich ein gutes Konzept, aber das muss ich wohl auch ...

Stimme Jens zu. Das mit den Tweaks ist nicht so intuitiv. Wie wär's mit einem eigenen Attribut?

du bist der Maintainer...

Meine Meinung/Begründung für "Tweaks"/"Specials":
Irgendwo muss der Content hin, damit das Modul ihn findet. Dazu kann man viele Attribute nutzen, oder eben ein Attribut mit vielen "Schlüsselwörtern".

Attribute zu verwalten, ist von der Modul-Code-Seite her deutlich aufwändiger, und der User muss mehr aufräumen, wenn er das betreffende Modul nicht mehr nutzen will. Außerdem braucht er in der Regel nur ein oder zwei Einträge aus dem ganzen "Strauß".
Mit "Specials" ist jetzt halt ein Attribut vorhanden, in dem er alles gebündelt findet, dazu auch eine cref-Anzeige, in der sämtliche Optionen dann (beim Gerät!) auch direkt gelistet werden.
Ohne Not würde ich das nicht mehr in Richtung Einzelattribut umdrehen, jm2ct...

Oder bezog sich das wirklich nur auf "Tweaks" als (für Einzelanweisungen ungewohntes) Attribut, das sich auf Einzeldevices auswirken kann?

Allgemein fände ich  es gut, wenn es u.a. im SetOnOff-Mapping möglich wäre, eine optionale Rückfrage zu stellen. Bei dem einen Device muss ich aktuell "schalte die Stehlampe an" sagen und beim anderen "Gartensprenger einschalten". Eine Option confirm="Soll ich $DEVICE wirklich einschalten?" (im Zusammenhang mit Confirm- CancelAction) würde das lösen.

Das mit dem Rhasspy-Mapping zu machen, ist halt relativ aufwändig in der Analyse der Attributzeile (aber vermutlich lösbar). Das Problem dabei ist nur, dass man dann das komplette Mapping aufschreiben muss und nicht einfach gDT machen lassen kann.
Das mit dem "individuellen Bestätigungssatz" gefällt mir an sich, allerdings braucht man eigentlich zwei (ein/aus), und es ist dann sehr auf diese Funktion zugeschnitten, was es  schwierig macht, das auf andere Aktionen auszuweiten (was aber eh' in den Sternen steht).
Die Idee, einfach den verstandenen raw-Text zurückzugeben, scheint  demnach nicht zu gefallen...? (OK, das könnte man bei einer generischen Umsetzung immer noch als fallback machen, wenn man nichts besseres findet.) Bleibt aber das Problem, dass man bei der Rückfrage dann wissen muss, welche Rückfrage ggf. die spezifische wäre. Ohne in den Code geschaut zu haben: vermutlich nicht ganz unaufwändig, aber lösbar.

Muss mal nachdenken... (aber nicht gleich), und evtl. hat ja noch jemand anderes Gedanken dazu.

[drhirn]

Oder bezog sich das wirklich nur auf "Tweaks" als (für Einzelanweisungen ungewohntes) Attribut, das sich auf Einzeldevices auswirken kann?

Wenn ich dich richtig verstanden habe: Ja
Brauche ich bei einem bestimmten Device eine Bestätigung, aktiviere ich ein Attribut (confirmation=1 oder confirmation="bist du sicher").

[Beta-User]

Wenn ich dich richtig verstanden habe: Ja

Ah, Danke für die Klarstellung.

Brauche ich bei einem bestimmten Device eine Bestätigung, aktiviere ich ein Attribut (confirmation=1 oder confirmation="bist du sicher").

Wir sind uns einig, dass man die Aktivierung einer Bestätigung für ein einzelnes Device in jedem Fall _bei diesem Device einstellen_ können sollte. MAn. wäre das in "Specials" zu verorten. (Gegen "rasspyMapping" spricht noch, dass das der alte Parser zerlegt, und ich den eigentlich lieber nicht anfassen möchte... Specials kann man immer ergänzen, egal, wo das Mapping herkam ).

Bei "Tweaks" besteht nun das "Problem", dass generischer Code die Angaben dort wohl gegenchecken "muss" (wg. der Gruppen), so dass man als "Nebenwirkung" dann ggf. darüber ein generelles Aktivieren per regex verwirklichen könnte, ohne dass das aufwändig wäre. Im Ergebnis gäbe es dann eben zwei Stellen, von denen man eine tendenziell zwar ausbauen könnte, was aber mit (u.a. Rechen-) Aufwand verbunden wäre...

Zur Syntax:
In Tweaks für Gruppen ist das grade wohl so gelöst:

Code Auswählen Erweitern

confirmIntents=SetOnOffGroup=rollläden,deckenlichter
(Nicht so einfach, da einen Satz dazu zu basteln*.)

Für "Specials"  wäre das eher:

Code Auswählen Erweitern

confirmIntents=SetOnOff="bist du sicher"
oder (Pipe kann nicht gesprochen werden und wäre daher ggf. ein geeigneter Trenner für ein/aus):

Code Auswählen Erweitern

confirmIntents=SetOnOff="$NAME wirklich ausschalten|$NAME wirklich einschalten"

*Was den Satz bei Tweaks angeht:
Könnte man über eine weitere Zeile lösen (confirmIntentsResponses= SetOnOffGroup="$NAME wirklich ausschalten|$NAME wirklich einschalten") oder dann eben (als Rückfallposition) über einen default in languagefile.

(Das wird ggf. "lustig", das zu vercoden...)

[drhirn]

Ich hab mir keine Gedanken darüber gemacht, wie das am besten zu programmieren wäre. Aus User-Sicht wär's natürlich optimal, wenn ich einfach ein "Kästchen beim Device anhacken" würde und ich werde nach einer Bestätigung gefragt. Aber schon das mit dem Kästchen ist mit FHEM nicht lösbar .

Aber es sollte auf jeden Fall beim zu schaltenden Device zu aktivieren sein. Finde ich.

[Beta-User]

[...] Aber schon das mit dem Kästchen ist mit FHEM nicht lösbar .

Nanana!!! Klar ginge das auch mit FHEM, warum denn nicht...?

Es müßte  jemand etwas .js-Code beisteuern...
Der müßte das dann "nur" in passende Konfigurationsanweisungen übersetzen . Falls jemand die "Attributsprache" zu kompliziert ist: Ich hätte kein Problem damit, den RHASSPY-helper-Hash am Ende der normalen Konfiguration dann z.B. einfach noch mit dem zu ergänzen bzw. zu ersetzen, was aus einem weiteren (JSON-encoded?) Attributinhalt kommt...

(Aber auch so ist es doch eigentlich kein Hexenwerk ).

[JensS]

Aber es sollte auf jeden Fall beim zu schaltenden Device zu aktivieren sein. Finde ich.

... ich auch. 

Die Tweaks und Spezials sind eine gute Sache, für Situationen, welche sich nicht im Device abbilden lassen. Generell sollte eine große Flexibiltät in Bezug auf die Fragen/Antworten erhalten bleiben.

[Beta-User]

...also...:

Zuerst die gute Nachricht:
Ein erster Pfad für "Bestätigung auf Device-Ebene" (auch via "Specials") ist gelegt .

Die schlechten:
- das ganze ist von meiner Seite sehr wenig getestet und ausdrücklich experimentell!
- die Syntax in den Attributen (bzw. der betr. Zeilen) gefällt mir noch nicht so ganz => "may" be subject to changes (Ziel: regex, s.u., daher auch noch keine commandref);
- "erster Pfad" meint: vermutlich muss sich im Code noch einiges ändern, und bisher funktioniert es nur für "SetOnOff";
- andere Intents habe ich noch nicht intensiver angesehen, aber insbesondere "SetNumeric" bereitet mir schon jetzt Kopfschmerzen. Will sagen: Ob das jemals (von meiner Seite) kommt, steht in den Sternen...
- das Rückwärtsmapping von "on/off" klappt bisher nur zu "an/aus", und auch nur dann, wenn die "words" in der language-file stehen. Will sagen: das ist ungewohnt unflexibel, und wer am Device dann "auf/zu" haben will, hat derzeit noch keine Chance;
- es wird ein paar Wochen dauern, bis ich mich wieder etwas intensiver damit befassen kann...

Zur Klarstellung zu dem hier:

Die Tweaks und Spezials sind eine gute Sache, für Situationen, welche sich nicht im Device abbilden lassen. Generell sollte eine große Flexibiltät in Bezug auf die Fragen/Antworten erhalten bleiben.

"Specials" ist eigentlich dafür gedacht, Konfigurationen "im Device" (abweichend vom Default, also eben "speziell") abzubilden...

Aktuelle Syntax - global:

Code Auswählen Erweitern

attr RHASSPY rhasspyTweaks confirmIntents=SetOnOffGroup=licht,rollläden\
confirmIntentResponses=SetOnOffGroup="$target $Value schalten" SetOnOff="Gerät $target $Value schalten"


bzw. "lokal":

Code Auswählen Erweitern

attr Sonos rhasspySpecials confirm: SetOnOffoder

Code Auswählen Erweitern

attr Sonos rhasspySpecials confirm: SetOnOff="wirklich $target $Value schalten?" SetScene
Gruppen-Intent-Vorgaben gehen nur via Tweaks, falls (!) globale Vorgaben für alle Devices gewünscht sind, geht das (hoffentlich) über Tweaks (dort müßte aber für die Device- bzw. Gruppen-Liste eigentlich eine regex statt Komma-separierter Vorgaben hin), was in "Specials" vorgegeben wird, sollte "Tweaks" vorgehen (dafür das wenig sinnvolle "SetScene"-Beispiel => der Intent "kann" das (noch) nicht, s.o.).

(als Merkposten für mich:
Das mit der "on/off" => "auf/zu" - Geschichte könnte man eventuell über ein confirmValueMapping in "specials" lösen).

Viel Spaß beim Testen!

PS: Es gab hinsichtlich der einen oder andere "großen" Sprachsteuerung jüngst einige Fragen, bei denen ich so ganz klammheimlich bei mir dachte: "Mit RHASSPY hätte man diese Probleme vermutlich nicht und wäre dazu noch deutlich flexibler...!" 

[JensS]

Hey - cool! 
Funktioniert mit SetOnOff. Habe es als

Code Auswählen Erweitern

rhasspySpecials confirm: SetOnOff="$target wirklich $Value schalten?" SetScenedefiniert.
Es kommt die Rückfrage "Stehlampe wirklich ON schalten?" und man kann bestätigen oder abbrechen.
Damit komme ich schon ein ganzes Stück weiter und kann z.B. Gartenakteure sicher in RHASSPY einbinden.

Hin und wieder gerät der Dialog nach der Antwort in eine Endlosschleife "please confirm: ludwig".
Es werden diverse Slots zufällig abgeklappert. ludwig, licht, hell, ...

[Beta-User]

ON kann man in words übersetzen.
Für die Schleife habe ich keine Idee, wird dauern...
Ludwig klingt nach buchstabieren...?