Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Kurze Frage - wie überrede ich das RHASSPY-Device, ein textCommand mit der siteId=wohnzimmer aufzurufen?

Im Moment ist das so nicht vorgesehen, patches welcome...

[Beta-User]

Hallo zusammen,

gestern gab es eine Anfrage im Rhasspy-Forum, die in ähnlicher Form immer mal wieder auftaucht:

Is it possible to say "go vacuum the kitchen and the dining room" and have it recognize "govacuum" as the intent and the slot "room" would be "kitchen, dining room" or something like that? This would also work for split level hvac, turning on/off multiple lights ect.

Eigentlich sollte es nicht allzu schwierig sein, eine "Verundung" reinzubasteln, für's erste wäre SetOnOff mit mehreren Geräten ({Device}, {Device1} ... {Device.}) ein eventueller Prototyp.

Meinungen?

[JensS]

Für's Erste funktioniert das. In der sentences.ini sind leider keine {Device(n)} vorgesehen. Es müssten alle denkbaren Szenarien optional abgebildet werden.

p.s. Hier ein wirres Beispiel:
Slot "de.fhem.Test"

Code Auswählen Erweitern

([ und [(den | dem | der | die | das)] ]) (stuhl){moebel2}
([ und [(den | dem | der | die | das)] ]) (sessel){moebel1}

sentences.ini (hab SetOnOff missbraucht...)

Code Auswählen Erweitern

wische den bereich um dem $de.fhem.Test [$de.fhem.Test]

Text: "wische den bereich um dem sessel und dem stuhl"

JSON:

Code Auswählen Erweitern

{
    "entities": [
        {
            "end": 32,
            "entity": "moebel1",
            "raw_end": 32,
            "raw_start": 26,
            "raw_value": "sessel",
            "start": 26,
            "value": "sessel",
            "value_details": {
                "kind": "Unknown",
                "value": "sessel"
            }
        },
        {
            "end": 46,
            "entity": "moebel2",
            "raw_end": 46,
            "raw_start": 41,
            "raw_value": "stuhl",
            "start": 41,
            "value": "stuhl",
            "value_details": {
                "kind": "Unknown",
                "value": "stuhl"
            }
        }
    ],
    "intent": {
        "confidence": 1,
        "name": "de.fhem:SetOnOff"
    },
    "raw_text": "wische den bereich um dem sessel und dem stuhl",
    "raw_tokens": [
        "wische",
        "den",
        "bereich",
        "um",
        "dem",
        "sessel",
        "und",
        "dem",
        "stuhl"
    ],
    "recognize_seconds": 0.11035313599859364,
    "slots": {
        "moebel1": "sessel",
        "moebel2": "stuhl"
    },
    "speech_confidence": 1,
    "text": "wische den bereich um dem sessel und dem stuhl",
    "tokens": [
        "wische",
        "den",
        "bereich",
        "um",
        "dem",
        "sessel",
        "und",
        "dem",
        "stuhl"
    ],
    "wakeword_id": null
}
Gruß Jens

p.p.s. In pyjsgf gibt es einen Wiederholungsparameter ($de.fhem.Test)+, der in Rhasspy nicht übernommen wurde.
https://pyjsgf.readthedocs.io/en/latest/api/expansions.html?highlight=repeat#jsgf.expansions.Repeat

[JensS]

Nanu, so ruhig hier? Gibt's heute keine Pizza? 

($de.fhem.Test)+ wird wohl nicht implementiert sein, weil man sonst eine unendliche Wiederholung im Wörterbuch der möglichen Frasen einfügen muss.
Vielleicht lässt sich @synesthesiam überreden, 2 Wiederholungen bei ()+ als Standard zu setzen und eine andere maximale Anzahl als Zusatz mit anzufügen.
z.B. ($de.fhem.Test)+5

[Beta-User]

Ja, das irgendwie in einen mehr oder weniger passenden Key zu bekommen, ist vermutlich nicht so sehr das Problem, eher dann die Auswertung, zumal es dann Mischungen zwischen {Device(n)}, {Room(n)} und {Group(n)}geben könnte...
Sicher alles interessant, aber erst muss ich mal das mit der Auswahl nach "getConfirmation" fixen, das ist irgendwie (noch) seltsam ...

Die Pizza scheint einem Shelly-firmware-Problem zum Opfer gefallen zu sein (oder dem Wetter?!?)...

[JensS]

Jist vermutlich nicht so sehr das Problem, eher dann die Auswertung, zumal es dann Mischungen zwischen {Device(n)}, {Room(n)} und {Group(n)}geben könnte...

Beim eingehenden Intent könnte man die [moebel(1-2)] zählen, die einzelnen Devices in ein Hilfsarray packen und die folgende SetOnOff-Funktion x-mal abarbeiten. Allerdings dürfte die Session zwischenzeitlich nicht geschlossen werden.
Eine von viele Möglichkeiten.

[Beta-User]

Hmm, da war noch eine "device-lose" Abfrage nach "braucht das eine Bestätigung" - ist im svn gefixt.
Gibt jetzt zwar ein Folgeproblem, weil ich jetzt plötzlich für "mach wärmer" trotz priority nach einer Auswahl (nach Bestätigung) gefragt werde, aber eins nach dem anderen...

Fyi:
- Das Problem mit der (fehlerhaften) device-losen Abfrage wg. der Bestätigung existiert(e) nicht nur in SetOnOff, sondern noch in ein paar anderen Intents (das ganze war eine Folge der Erweiterung der Funktion auch für Gruppen);
- den Grund für die Auswahlabfrage (nach Bestätigung in SetNumeric) konnte ich auch dingfest machen;
- autoTraining ist auch einen halben Schritt vorangekommen;
- ein paar Perlcritics sind gefixt, für ein paar andere (die m.E. nicht allzu berechtigt sind) Pflaster geklebt.

Soweit so gut, werde jetzt erst mal selbst etwas testen, weil dabei auch regexe etwas verändert worden sind, danach kann es wieder für die Allgemeinheit weiter gehen .

Beim eingehenden Intent könnte man die [moebel(1-2)] zählen, die einzelnen Devices in ein Hilfsarray packen und die folgende SetOnOff-Funktion x-mal abarbeiten. Allerdings dürfte die Session zwischenzeitlich nicht geschlossen werden.
Eine von viele Möglichkeiten.

Das Problem scheint mir weniger zu sein, auf die Schnelle was zusammenzuschreiben, sondern für den Fall der Fälle würde ich mir das schon so vorstellen, dass man im Prinzip beliebige "Gruppierungsmerkmale" kombinieren kann, also:
Device 1 + Device 2
Device 1 + Gruppe a
Gruppe a + Device 1
Gruppe a+ Gruppe b
"Gruppe a  mit Name xy" in Raum 1 + Raum 2
...

Anders gesagt: Ich glaube, es spricht sich nur dann "organisch", wenn man nicht groß überlegen muss, was sich hinter den einzelnen Elementen verbirgt. Das bedeutet aber, dass man checken muss, ob in einem Intent "falsche" Keys drin sind, und das dann zum Anlass nehmen müßte, erst mal zu sammeln... Möglicherweise ist es trivial, möglicherweise näherungsweise unmöglich, im Moment noch keine Ahnung .

Damit ergibt sich aber nicht nur "zwanglos" eine Liste mit betroffenen Devices, sondern es stellen sich ein paar Folgefragen:
- Ist das dann insgesamt als "Gruppenanweisung" zu verstehen, oder sollen "Genehmigungsvorbehalte" aus Einzeldevices noch relevant sein?
- Wenn ja: Soll der "nicht betroffene Rest" vorab durchgeführt werden...? Oder alles erst nach Genehmigung? Wie soll die aussehen...?
(Tendiere zu: Wenn irgendwo eine Genehmigung für einen Teil erforderlich ist: Warten mit allem, "raw-Rückfrage". Mehrere Devices können identifiziert werden: Genehmigungs-tweak für Gruppen-Intent greift.)

Schwierig wird es uU., wenn man zwar eine Gruppe hat, aber kein Device kann, was die Anweisung will (muß man das erst checken, bevor man ein Device in die Liste aufnimmt...?).

Hat man dann die Liste, muss man sie uU. erst mal (wegen der Genehmigung) "auf die Seite packen", und dann (ggf. später)nochmal durchflözen wegen der Frage, in welcher Reihenfolge man das ganze schaltet... Prinzipiell ist vermutlich auch dieser Teil irgendwie schon gelöst, aber das ganze dann wieder fehlerfrei zusammenzustückeln ist vermutlich nicht ganz trivial (siehe das mit dem "confirm"-Special und der seltsamen Auswahl-Folge)...

[JensS]

Eigentlich sollte es nicht allzu schwierig sein, eine "Verundung" reinzubasteln, für's erste wäre SetOnOff mit mehreren Geräten ({Device}, {Device1} ... {Device.}) ein eventueller Prototyp.

Meinungen?

Nun, meinen Vorschlag hast du ja. Ob du was draus machst, ist natürlich dir überlassen. Memo an mich: Nicht alles wörtlich nehmen...

[Beta-User]

Soweit so gut, werde jetzt erst mal selbst etwas testen, weil dabei auch regexe etwas verändert worden sind, danach kann es wieder für die Allgemeinheit weiter gehen .

Das scheint soweit zu passen, umfassend testen ist aber schwierig. Jedenfalls ist seit eben ein update im svn .

Neben dem hoffentlich gefixten Thema mit der "Einzelbestätigung" scheint jetzt auch "autoTraining" voll funktional zu sein, ich neige dazu, das mittelfristig zur Standardeinstellung mit einem timeout von ca. 60 Sekunden zu machen.

Meinungen dazu?


Was auch etwas besser geworden ist, ist das Ding mit den "kontinuierlichen Dialogen". Funktional ist es trotzdem noch nicht, aber im Zuge der letzten paar Code-Reviews sind mir schon einige Stellen ins Auge gesprungen, die so nicht optimal waren. Mal sehen, vielleicht klappt es auch noch, diesen Knoten vollends durchzuhauen.

Da wir im svn sind, kann man für support-Zwecke sowieso die svn-Nummer als eindeutigen Kenner (ggf. mit Anmerkungen zu Test- und Zwischenversionen) heranziehen. Das entsprechende Internal bräuchten wir daher m.E. eigentlich nicht mehr.

Nun, meinen Vorschlag hast du ja.

Ich habe die Rückmeldung als "finde ich gut" gewertet. Das ganze Thema bedarf auch für mich noch der "Reifung", und sorry, wenn ich in dem Zusammenhang einfach versuche, meine Gedanken auch mal irgendwo niederzuschreiben.
Vermutlich vergeht noch einige Zeit, bis daraus vielleicht der Versuch entsteht, funktionalen Code zu basteln.

Vor allem will ich jetzt erst mal die übrigen Punkte von der ToDo-Liste haben, der Weg scheint mir nicht mehr allzu weit zu sein .


Bzgl. der AMAD.*-Geschichte fehlt mir noch eine Idee, wie das "eine" Attribut künftig heißen sollte; ansonsten wäre noch offen, wie man den Voice-Input wieder öffnet für Rückfragen etc.. Manuell klappt das jedenfalls nicht, muss auch dazu nochmal in den Code schauen.

[drhirn]

Neben dem hoffentlich gefixten Thema mit der "Einzelbestätigung" scheint jetzt auch "autoTraining" voll funktional zu sein, ich neige dazu, das mittelfristig zur Standardeinstellung mit einem timeout von ca. 60 Sekunden zu machen.

Was ist dieses "autoTraining"?

Da wir im svn sind, kann man für support-Zwecke sowieso die svn-Nummer als eindeutigen Kenner (ggf. mit Anmerkungen zu Test- und Zwischenversionen) heranziehen. Das entsprechende Internal bräuchten wir daher m.E. eigentlich nicht mehr.

Das Internal "Version"? Das brauch ich nämlich um zu wissen, welche Version ich gerade installiert habe.

[Beta-User]

Was ist dieses "autoTraining"?

Muss wohl nochmal ausholen...

Hatte vor einiger Zeit eine längere pm-Diskussion mit martinp876 zu diversen Themen, u.a. allgemein um das, was man wohl eine stringente Nutzerführung nennen könnte. Dabei war seine These, dass ein Modul wie RHASSPY eigentlich in der Lage sein sollte, die Konfiguration auch des externen Systems konsistent zu halten, also konkret: Auf Änderungen in/an Attributen, die Auswirkungen auf die von Rhasspy erkannten Sätze haben können zui prüfen, ob ein Training erforderlich wäre und das dann ggf. auch automatisch anzuschubsen.

Genau das macht dieses feature, was im Moment als key in DEF umgesetzt ist: Es reagiert per NotifyFn() (ggf. u.a. auch) auf diverse globale Events, und setzt bzw. erneuert dann einen Timer. Ist der abgelaufen, wird geprüft, ob sich der an Rhasspy zu sendende Content geändert hat, wenn ja => update der Daten. Wenn angekommen, dann Training veranlassen . ("attr global showInternalValues 1" sollte zeigen, gegen was im Detail geprüft wird).

Falls das zum default würde, wäre es dann eher per Tweak deaktivierbar?

Das Internal "Version"? Das brauch ich nämlich um zu wissen, welche Version ich gerade installiert habe.

Na ja, nachdem es eine svn-Nummer hat, kann man die "version" ja auch ganz regulär abfragen. Es gibt dann nur noch diese eine Stelle, die "jemand" pflegen muss . Zwischenversionen kann man nämlich durch Änderung in der ID-Zeile kenntlich machen.

Eigentlich wäre es auch an der Zeit, das Modul für "Meta" vorzubereiten, dann gäbe es wohl auch automatisch ein passendes Internal. Aber das ist immer etwas mühsam aufzubereiten (ich müßte das eigentlich auch in ein paar anderen "geerbten" Modulen noch nachpflegen ).

[drhirn]

Genau das macht dieses feature, was im Moment als key in DEF umgesetzt ist: Es reagiert per NotifyFn() (ggf. u.a. auch) auf diverse globale Events, und setzt bzw. erneuert dann einen Timer. Ist der abgelaufen, wird geprüft, ob sich der an Rhasspy zu sendende Content geändert hat, wenn ja => update der Daten. Wenn angekommen, dann Training veranlassen . ("attr global showInternalValues 1" sollte zeigen, gegen was im Detail geprüft wird).

Ah. Sehr cool!

Falls das zum default würde, wäre es dann eher per Tweak deaktivierbar?

Nach meiner FHEM-Logik eher als Attribut, oder?

Na ja, nachdem es eine svn-Nummer hat, kann man die "version" ja auch ganz regulär abfragen. Es gibt dann nur noch diese eine Stelle, die "jemand" pflegen muss . Zwischenversionen kann man nämlich durch Änderung in der ID-Zeile kenntlich machen.

Verwendet aber nicht jeder SVN 

[Beta-User]

Ah. Sehr cool!

Hatte eher eine skeptische Reaktion erwartet, aber wenn wir beide das cool finden, sollten wir nach deinen ersten Tests mal über die Frage eines "guten" Timeout-Werts nachdenken .

Nach meiner FHEM-Logik eher als Attribut, oder?

"tweak" meint: Ein Schlüssel innerhalb "rhasspyTweaks". Ein eigenes Attribut dafür finde ich übertrieben...
Entweder es ist "gut", dann sollte es allgemein aktiv sein, oder es "hakt", dann bleibt es experimentell . Wer ein "gutes" feature deaktivieren will, sollte das tun können, aber ein "Silbertablett" braucht es dafür nach meiner Ansicht/Logik nicht.

Verwendet aber nicht jeder SVN 

Ist egal. Solange $Id "gepflegt ist, kommt auch was raus, wenn man z.B. auf GitHub oder hier veröffentlichten Versionen "irgendwelche" Informationen dort reinschreibt. Ich lasse z.B. in der Regel die svn-Version als Basis stehen und ergänze mit Datum + ggf. einer weiteren Unternummer. Das "nicht jeder" ist also m.E. kein "schlagendes" Argument. Was damit "verloren" geht, wäre der "Masterplan" in Richtung auf "1.0" ... Im Moment sind wir gefühlt jedenfalls mind. auf 0.6 .

[drhirn]

Entweder es ist "gut", dann sollte es allgemein aktiv sein, oder es "hakt", dann bleibt es experimentell . Wer ein "gutes" feature deaktivieren will, sollte das tun können, aber ein "Silbertablett" braucht es dafür nach meiner Ansicht/Logik nicht.

Naja, das Feature nimmt direkt Einfluss auf die Verhaltensweise des Moduls. Unabhängig von irgendwelchen Rhasspy-Devices, Sätzen oder sonstiges. Somit hätte ich es schon als "wichtiger" angesehen, als rhasspyTweaks z.B.

[Beta-User]

Na ja, mAn. hängt das von der Sichtweise ab: Für dich als langjährigem RHASSPY-Nutzer ist es "normal", den update-devicemap+training-Prozess manuell "anschubsen" zu müssen. Ich hatte auch gewisse Schwierigkeiten, mich von dem Gedanken
"aber das dauert doch etwas, bis das training durch ist, und ich will das in der Hand haben, wann es stattfindet! Schließlich weiß ich ja, was zu tun ist...!"
lösen zu können und martinp876's Sichtweise als "normal" zu akzeptieren, dass der User auf der einen Seite was ändert, und dann eben erwartet, dass Rhasspy das schon mitbekommen wird, ohne dass er was explizit in diese Richtung veranlasst.

Von daher: Es war nach Meinung gefragt, und das klingt jetzt doch etwas skeptischer, als ich es zunächst wahrgenommen hatte...