Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Hmm, also:
- Die Sätze (einschl. der letzten Ergänzungen wegen "multi-Commands") und die komplettierte Datei sind jetzt auch wie gewünscht in deinem allgemeinen Thread zu finden.
- die geraffte Zusammenfassung der "news" zu RHASSPY ist im 0.5-er "offene Themen" zu finden. Da habe ich bisher nur das "multi-command-feature" nicht separat herausgehoben, das braucht noch Tests. Funktionieren sollte jetzt aber (mit der gestern hier angehängten Version) insbesondere auch AMAD.* (!).
- Werde mal überlegen, ob die Developer-Version ggf. im ersten Post der "offenen Themen" besser aufgehoben wäre, andererseits bin ich geneigt, die recht direkt wieder ins svn zu übernehmen - vorausgesetzt, es gibt wegen der "multi-command-feature"-Sache keinen Einspruch seitens @drhirn. Das ganze ist etwas sehr spontan entstanden und enthält doch jetzt einige tiefergreifende Eingriffe in den Code...

Insgesamt ist dieser Thread in der Tat zwischenzeitlich sehr lang und wenig geeignet, "normale User" auf dem Laufenden zu halten. Das war der Grund für den "offene Punkte"-Thread. Vielleicht sollten wir irgendwann hier auch einfach wieder zumachen, das meiste findet sich ja dann doch jetzt im Wiki etc.. M.E. wäre der richtige Zeitpunkt dann, wenn ein paar mehr Rückmeldungen zum "multi-command-feature" da sind und die Entwicklung der aktuellen Evolutionsstufe soweit als abgeschlossen betrachtet werden kann?

[drhirn]

vorausgesetzt, es gibt wegen der "multi-command-feature"-Sache keinen Einspruch seitens @drhirn. Das ganze ist etwas sehr spontan entstanden und enthält doch jetzt einige tiefergreifende Eingriffe in den Code...

Kein Einspruch. Funktioniert eh schon erstaunlich gut.

Insgesamt ist dieser Thread in der Tat zwischenzeitlich sehr lang und wenig geeignet, "normale User" auf dem Laufenden zu halten. Das war der Grund für den "offene Punkte"-Thread. Vielleicht sollten wir irgendwann hier auch einfach wieder zumachen, das meiste findet sich ja dann doch jetzt im Wiki

"Normale" User sollten bei Fragen eigene Threads aufmachen. Der kann ruhig für uns offen bleiben.
Aber ich könnte im ersten Beitrag anmerken, dass es bessere Informationsquellen als diesen Thread gibt?

[Beta-User]

Kein Einspruch. Funktioniert eh schon erstaunlich gut.

Habe noch ein paar kleinere offene Punkte damit, die sich aber auch recht einfach fixen lassen sollten (bzw. wo ich die Fixes noch testen muss):
- Beim Testen per File hatte ich eine "Echt-Schaltung" (Ursache vermutlich lokalisiert/gefixt)
- Bin nicht sicher, ob die Erkennung immer klappt, dass eine Bestätigung erforderlich/erwünscht ist (falls jemand was ähnliches feststellt, wären die Rahmenbedingungen interessant, um das ggf. nachvollziehen zu können; ist vermutlich wenn, dann auch nur eine Kleinigkeit).
- Doku... (commandref, ggf. auch Wiki)

"Normale" User sollten bei Fragen eigene Threads aufmachen. Der kann ruhig für uns offen bleiben.

Keine Einwände.

Aber ich könnte im ersten Beitrag anmerken, dass es bessere Informationsquellen als diesen Thread gibt?

Schadet sicher nicht, ein paar (kurze) Hinweise aufzunehmen, wo ggf. was zu finden ist. Ich werde dann auch dazu übergehen, das nächste "pre-release" vielleicht dann über den ersten Beitrag in "Offene Themen" anzupinnen (falls es nicht direkt per svn kommt, die aktuellste scheint ja (bei 3 Testern?) im wesentlichen keine Probleme zu machen.

[drhirn]

Schadet sicher nicht, ein paar (kurze) Hinweise aufzunehmen, wo ggf. was zu finden ist.

Ist schon erledigt.

Ich werde dann auch dazu übergehen, das nächste "pre-release" vielleicht dann über den ersten Beitrag in "Offene Themen" anzupinnen (falls es nicht direkt per svn kommt, die aktuellste scheint ja (bei 3 Testern?) im wesentlichen keine Probleme zu machen.

Nein, bitte nicht. Mir ist lieber, die hängen da in den Beiträgen. Dann kann ich auf GitHub als Commit-Message einfach nur die ID der Nachricht (bzw. den Link drauf) anhängen. Sonst weiß ich unter Umständen nicht mehr genau, in welchem Beitrag zugehörige Änderungen erklärt werden.

[Beta-User]

Ist schon erledigt.

Thx!

Nein, bitte nicht. Mir ist lieber, die hängen da in den Beiträgen. Dann kann ich auf GitHub als Commit-Message einfach nur die ID der Nachricht (bzw. den Link drauf) anhängen. Sonst weiß ich unter Umständen nicht mehr genau, in welchem Beitrag zugehörige Änderungen erklärt werden.

Na ja, dieses Prinzip brauchst du deswegen ja eigentlich nicht aufzugeben. Ob das jeweils dann direkt im "Kommentar-Beitrag" angepinnt war oder irgendwo anders, oder aus dem svn per download kommt, ist ja sekundär.

Und jetzt sollte es auch wieder "ruhiger" zugehen, so dass dann ggf. die Infos, was wie zu verwenden ist, dann auch wieder aus der Doku entnommen werden kann (bzw. diese Hinweise dann da auch nachgepfelgt werden, wenn sie fehlen).

Was Doku betrifft: Im Wiki fehlen - soweit ich das im Kopf habe - v.a. die noch Intent-Beschreibungen sowie passende "sentences", oder?
UU. ist auch nicht ganz aktuell, was mindestens geliefert werden muss. Z.B. "mach wärmer" sollte vermtlich lt. Doku nicht gehen, klappt aber faktisch (jedenfalls prinzipiell).

Generell noch: Was die Einrichtung angeht, stellt sich ja jetzt mit der Option der "Testsuite" (und des "AMAD.+"-Wegs) die Frage, wie man User am besten durch die Doku lotst, damit die schnell finden, wie sie bestimmte Anforderungen umgesetzt bekommen.

[drhirn]

Was Doku betrifft: Im Wiki fehlen - soweit ich das im Kopf habe - v.a. die noch Intent-Beschreibungen sowie passende "sentences", oder?
UU. ist auch nicht ganz aktuell, was mindestens geliefert werden muss. Z.B. "mach wärmer" sollte vermtlich lt. Doku nicht gehen, klappt aber faktisch (jedenfalls prinzipiell).

Ich hab da leider den Überblick verloren. Nach der Grund-Erstellung der Artikel habe ich mich (wie angekündigt) nicht mehr darum gekümmert. Und bekomme auch leider keine Benachrichtigungen, wenn sich an den Artikel was ändert.

[Beta-User]

Ich hab da leider den Überblick verloren. Nach der Grund-Erstellung der Artikel habe ich mich (wie angekündigt) nicht mehr darum gekümmert. Und bekomme auch leider keine Benachrichtigungen, wenn sich an den Artikel was ändert.

War auch eher als Feststellung gemeint...
(Ich habe nur leider zwischenzeitlich so komplexe Sätze, dass man das kaum einem Einsteiger erklären kann, was das soll. Zudem braucht man dazu eigentlich den Gesamtkontext => muss mir was überlegen, wie man das ggf. aufbereiten kann...

PS:
Um schnell zu sehen, wer was in welchem Umfang geändert hat, kann man auch das Wiki befragen, z.B. mit
https://wiki.fhem.de/wiki/Spezial:Letzte_%C3%84nderungen?hidebots=1&limit=50&days=7&enhanced=1&urlversion=2 oder dem Aufruf der Änderungsgeschichte zu einem Artikel.

[Prof. Dr. Peter Henning]

Ich hab da leider den Überblick verloren.

Das spricht mir aus der Seele. Fachlich habt ihr das sehr gut vorangetrieben, keine Frage - aber der Einsteiger sieht hier den Wald vor Bäumen nicht.

LG

pah

[Beta-User]

Nun ja, man muss (v.a. als Einsteiger) auch nicht vom Stand weg alle möglichen Optionen kennen - geschweige denn verstehen.

Was man immer braucht, sind
- eine funktionierende Rhasspy-"base", also einen Dienst, der entweder
-- "Sprache" (also Sound, via Mikro oder "abgesetztem Mikro" (=ESP32 oder Rhasspy-App)) entgegennimmt und das in Text umwandelt, oder
-- direkt Text entgegennimmt (z.B. von einer externen STT-Engine (z.B. via AMADDevice) oder einem Rhasspy-Satelliten),

und eine RHASSPY-Instanz, die
- FHEM-Devices in "Text-Bausteine" für diese Rhasspy-"base" liefert und
- den (vereinfacht) in key/Value-Paare umgewandelten Text entgegennimmt und dann in FHEM-Aktionen umsetzt.

An diesem Grundpinzip hat sich eigentlich seit Anbeginn nichts geändert ...

Das ganze ist halt dann besonders schwierig zu überblicken, wenn man "alles auf einmal" einrichten und umsetzen will.

Da wir hier in "development" zu RHASSPY sind, hier noch die direkte Rückfrage zu dem hier:

1. Input: Was ist der Text, den das NLP-System bekommen hat?

Die Zeile bleibt entweder "pur" stehen oder es erfolgen weitere Infos. Wird ein explizites "not recognized" oder ähnliches gewünscht?

2. Ergebnis: Was hat es daraus gemacht, i.e., was sind die Eckpunkte des Intents (Ort? Gerät? Zeit? Aufgabe?)

Hier kommen bei RHASSPY alle intern verfügbaren "keys" samt Werten. Ist das "to much"? Abspecken wäre relativ viel Aufwand, daher: eher ungern...

3. Wenn "nur" eine Antwort erfolgte, wie lautete diese?

Kommt, wenn es eindeutig ist (s.u.).

4. Wenn eine echte Aktion durchgeführt wurde, welches FHEM-Kommando wurde abgesetzt?

Bei Einzelanweisungen kommt die Info, wie der FHEM-Befehl aussehen würde bzw. ggf. auch Perl-Code. Eine Ausführung erfolgt nicht, daher ist uU. auch der Perl-Code halt "as is"... Sollte bis dahin ok sein (abgesehen davon, dass wir den einen offenen Punkt dazu noch hatten).

Wenn Gruppen adressiert werden, kann man das in RHASSPY nicht (bzw: vermutlich nicht ohne größeren Aufwand) so detailiert erfassen, m.E. sind aber die Angabe der Device-Namen iVm. Intent etc. soweit eindeutig, dass auch fortgeschrittene Einsteiger was damit anfangen können sollten.

Die eigentliche Frage dahinter, die für mich noch nicht eindeutig geklärt ist: Paßt das soweit, oder ist das eine "betriebsblinde" Sichtweise? (Rückmeldungen dazu fehlen bisher, von daher kann ich nur spekulieren...)

[Prof. Dr. Peter Henning]

1. Input: Was ist der Text, den das NLP-System bekommen hat?

Die Zeile bleibt entweder "pur" stehen oder es erfolgen weitere Infos. Wird ein explizites "not recognized" oder ähnliches gewünscht?

ich lasse die Zeile "pur" stehen.

2. Ergebnis: Was hat es daraus gemacht, i.e., was sind die Eckpunkte des Intents (Ort? Gerät? Zeit? Aufgabe?)

Hier kommen bei RHASSPY alle intern verfügbaren "keys" samt Werten. Ist das "to much"? Abspecken wäre relativ viel Aufwand, daher: eher ungern...

Kommt bei mir auch relativ viel Zeug. Müsste halt eingerückt sein, damit man es einfacher igrnorieren kann.

    3. Wenn "nur" eine Antwort erfolgte, wie lautete diese?

Kommt, wenn es eindeutig ist (s.u.).

Stimmt. Sonst s.u.

    4. Wenn eine echte Aktion durchgeführt wurde, welches FHEM-Kommando wurde abgesetzt?

Bei Einzelanweisungen kommt die Info, wie der FHEM-Befehl aussehen würde bzw. ggf. auch Perl-Code. Eine Ausführung erfolgt nicht, daher ist uU. auch der Perl-Code halt "as is"... Sollte bis dahin ok sein (abgesehen davon, dass wir den einen offenen Punkt dazu noch hatten).

Ebenso. Beispiele:

Code Auswählen Erweitern

[Babble_DoIt] Input:    sag mir die feuchte im wohnzimmer
              Ergebnis: Category=2.1.7: Gerät=feuchte Ort=wohnzimmer Verb=sagen Ziel=status /
              Ausführung: {speak('Tab1.EG','Die Feuchte im Wohnzimmer beträgt '.ReadingsVal('humProfileC','WZ.rH','').' Prozent')}


Code Auswählen Erweitern

[Babble_DoIt] Input:    mache etwas dunkler
              Ergebnis: Category=1.3.0: Gerät=etwas Ort=none Verb=schalten Ziel=dunkler /
              Antwort:  {speak('Tab1.EG','Es tut mir leid, das habe ich nicht verstanden')}


Wenn Gruppen adressiert werden, kann man das in RHASSPY nicht (bzw: vermutlich nicht ohne größeren Aufwand) so detailiert erfassen, m.E. sind aber die Angabe der Device-Namen iVm. Intent etc. soweit eindeutig, dass auch fortgeschrittene Einsteiger was damit anfangen können sollten.

Aber gruppen sollten doch auch eindeutige Gerätenamen haben. Auf die Frage "Welche Geräte kennst Du" sollten alle Geräte und Gruppennamen zurückkommen.

LG

pah

[Beta-User]

Also: Aktualisierte Fassung ist im svn, damit ist
- das "multicommand"-feature allgemein verfügbar...
- (hoffentlich) das Schalten aus dem Test per File heraus Geschichte;
- die Rückmeldung nach Test per File auch wieder lesbar.

Über die Formatierung der Rückgabe für's Testen muss ich mir dann mal gesondert einen Kopf machen, das erfordert vermutlich wieder eine etwas andere Strukturierung der Daten.

Über

Aber gruppen sollten doch auch eindeutige Gerätenamen haben. Auf die Frage "Welche Geräte kennst Du" sollten alle Geräte und Gruppennamen zurückkommen.

muss ich noch etwas nachdenken.

Prinzipiell ist es so, dass eine "Gruppe" aus RHASSPY-Perspektive "nur" ein "Abgrenzungslabel" ist, das - genausowenig wie der "Name" - eindeutig sein müßte. Gruppen sind jedenfalls keine "Geräte" (bzw.: Device-Instanzen) im FHEM-Sinn. Sie werden intern eher (!) gehandhabt wie dynamisch erstellte "structure"-Instanzen - deswegen war es auch relativ einfach, die bestehenden Gruppen-Intents "aufzubohren" für diese multi-Strukturierungselement-Geschichte.
Weiter kann ein "Gerät" viele Namen haben und auch zu vielen Gruppen gehören.

Alles anzusagen, ist daher m.E. in der Regel nicht sinnvoll. Was Namen angeht, begrenzt RHASSPY das daher auf die "Haupt-Namen" (bzw. "Haupt-Räume"). Von denen gibt es pro Device nur einen.
Bei Gruppen-Etiketten gibt es (jedenfalls vermutlich und im Moment) keine "Hauptgruppe" im eigentlichen Sinn. Muss mir mal näher ansehen, ob es überhaupt im Moment irgendeine halbwegs schnelle Methode gibt, sowas wie Gruppennamen pro Raum zu ermitteln. Aber selbst wenn, bliebe vermutlich das Problem, dass das uU. "endlos" ist (wobei: Das ggf. passend zu konfigurieren, sollte möglich sein, wenn man auch für dieses Strukturierungsmerkmal sowas wie "Hauptgruppen" einführt).
Hmm, mal sehen...

[Beta-User]

Anbei mal mein Schema für die Anbindung von Babble an Rhasspy.

Hättest du ggf. dazu noch den "Quellcode"? Dann könnte ich ggf. versuchen, mal den aktuellen Stand in Sachen AMAD.* (und msgDialog) einzupflegen...

Update der Dev-Version des Moduls ist in https://forum.fhem.de/index.php/topic,124952.0.html zu finden, da ist v.a. auch die Ausgabe der Testergebnisse in der "result"-File modifiziert (ich will nicht behaupten, dass das bereits besonders schön und/oder optimal wäre ).

[Prof. Dr. Peter Henning]

Anbei der "Quellcode" für das Diagramm.

Ich grübele gerade über einer Möglichkeit, der precise Wakeword-Engine zusätzliche Parameter mitzugeben, wenn sie von Rhasspy gestartet wird. Hintergrund: ich hab ein meinem Wakeword-Modell immer noch zu viele "false positives". Ich möchte also abends, wenn der Fernseher mal läuft, auf derselben Hardware die Wakeword-Erkennung mit dem Parameter -d falsepos laufen lassen. Wenn ich dann sicherstelle, dass niemand von uns tatsächlich "Hallo Jeannie" sagt, verfüge ich danach über eine ganze Sammlung von Audioschnipseln, die man zum Training eines neuen Modells verwenden kann.

LG

pah

[JensS]

Gestern habe ich die SVN eingespielt und die multicommand-Anweisungen funktionieren gut.
Gibt es die Möglichkeit, vorhandene confirm-Abfragen in den rhasspySpecials der einzelnen Devices zwingend aufzurufen?

Gruß Jens

[Beta-User]

Gestern habe ich die SVN eingespielt und die multicommand-Anweisungen funktionieren gut.
Gibt es die Möglichkeit, vorhandene confirm-Abfragen in den rhasspySpecials der einzelnen Devices zwingend aufzurufen?

Muss ich mir nochmal in Ruhe ansehen, wie das im Detail gelöst ist, hätte eigentlich gedacht, dass ein"single-needs-confirmation" bei einem beteiligten Device auch einen confirmation-request für diesen "speziellen Gruppen-Intent" verursacht.

Dass man allgemein eine confirmation für alle diese "ad-hoc"-Gruppen-Anweisungen anfordern kann, dürfte angekommen sein (ich habe aber bisher nicht gegengecheckt, ob das so funktioniert wie gedacht).

Wäre super, wenn  du auch mit der aktuellsten dev-Version testen könntest (aus https://forum.fhem.de/index.php/topic,124952.msg1195323.html#msg1195323). Da ist allerdings nichts passiert bzgl. des confirmation-Themas.