Modulentwicklung für Rhasspy Sprachassistent

[chicco]

Ich habe die aktuelle Version mit Svn_GetFile() geholt, habe es nochmal probiert und hatte wieder einen crash.
Als fhem nach dem crash neu gestartet war, habe ich es nochmal versucht, dann hat es geklappt, rhasspy device ist erstellt und state ist online.
Ich nehme an, man muss fhem neu starten nachdem man Svn_GetFile() ausgeführt hat? Dann würde sich der crash beim ersten Versuch erklären.

[Beta-User]

Na ja, ohne (wenigstens) einen reload kein aktueller code im Speicher...
Aber klappt ja jetzt...

[JensS]

Code Auswählen Erweitern

next if ref $ref->{$_} ne 'HASH'...hast ein wenig getrickst um die Klippe zu umschiffen. 

[Beta-User]

Hallo zusammen,

auf Anregung von pah gibt es im svn ein kleines update.

Das kann eine Liste von Sätzen oder einen einzelnen Satz (via jeweiligem Get) an Rhasspy senden und  schreibt dann die Ergebnisse in eine Ergebnisdatei. Finde das ganz interessant, weil man damit relativ schnell und im Überblick sehen kann, wo ggf. noch Verbesserungspotential bei der Konfiguration der sentences.ini bzw. der RHASSPY-Attribute in einer Installation besteht.

[...], sollte
- die Ergebnisfile nur noch da Rückmeldungen enthalten, wo ein Ergebnis kam;
- auch die Auswertung für diverse "Abfragen" in den Ergebnissen enthalten sein (für die ganzen "setter" wäre es ggf. sehr viel schwieriger!);
- ein neues Reading etwas mehr Aufschluss geben, was die "ratio" betrifft und wo das ganze zu finden ist.

Muss mal noch schauen, ob es sehr aufwändig wäre, das so aufzubohren, dass man auch die Rückmeldungen auf "Set"-Anweisungen rückgemeldet bekommt, aber Rom und so...

Jetzt warte ich auch mal auf eure Rückmeldungen zum Thema.

Fehlen noch weitere "Testsätze" - pah's Muster ist etwas anders gestrickt als meine Steuerungsanforderungen, von daher war auch die erste Sätze insgesamt / Treffer - "ratio" nicht allzu prickelnd .

[Prof. Dr. Peter Henning]

pah's Muster ist etwas anders gestrickt als meine Steuerungsanforderungen

na fein, dann lass doch mal Deine Anforderungen sehen - ich bau sie gerne auch in meine Tests ein.

LG

pah

[Beta-User]

Gemach, eins nach dem anderen...

Vorab mal: Das mit den Tests ist klasse, damit kann man recht fix rausfinden, was RHASSPY jeweils angeliefert bekommt, und selbst da, wo es keine "unmittelbare" Info gibt, wie das ausgewertet wurde, kann man in etwa erahnen, was an Steuerungsbefehlen dann abgeleitet wird. War eine schöne Gelegenheit, meine sentences.ini weiter zu optimieren .

Weiter auch ein Anlass, das mit den erweiterten GetState-Optionen mal auszutesten - leider nur in Teilen erfolgreich .

Hier mal ein paar weitere Sätze:

Code Auswählen Erweitern

  mach alle jalousien im esszimmer zu
  mach alle jalousien im wohnzimmer halb auf
  fahr die jalousie in der mitte halb zu

  wie warm ist es draussen
 
  färbe die stehlampe links rot
  stelle die stehlampe rechts auf blau
 
  mach überall die rollläden auf fünfzig
  mach alle lichter im wohnzimmer heller
  mach alle leuchten im wohnzimmer dunkler
 
  mach lauter
  mach die musik leiser
 
  halte die wiedergabe an
  halte die musikwiedergabe an
 
  wie wird das wetter heute
  was kostet diesel in Karlsruhe


Würde vorschlagen, dass wir für diesen Teil einen separaten Thread starten? Hier kann es gerne darum gehen, ob/wie man das Tool erweitern kann (die Set-Zweige im Code auch noch für Tests ergänzen?) und ggf. wie die Rückmeldungen verbessert werden könnten (HASH-Fälle => Klartext kommt bei Gelegenheit), aber m.E. ist das eine Super-Sache, um die Interaktion zu analysieren und dann zu diskutieren, an welcher Stelle man ggf. sinnvollerweise Anpassungen vornimmt und was eigentlich in welchen Intent rein sollte (Wetter-Abfrage ist bei mir jetzt ein GetState).

[Prof. Dr. Peter Henning]

Machen wir doch glatt:

https://forum.fhem.de/index.php/topic,126864.0.html

zum Thema testen.

Zu Deinen Sätzen ein paar Fragen - sorry fürs nachbohren, aber die Semantik von Daten ist eines meiner Hauptarbeitsgebiete

- Was ist der Unterschied zwischen Jalousien und Rollläden bei Dir?
- Warum würde man "alle Jalousien" von "die Jalousien" unterscheiden?
- Gibt es vorgefertigte Szenen für die Jalousien/Rollläden?
- Gibt es einen Unterschied zwischen "halb zu" und "halb auf"?
- Fragst Du auch nach dem Dieselpreis in anderen Orten?
- Wie viele Farben erkennt das System?

LG

pah

[Beta-User]

Machen wir doch glatt:

https://forum.fhem.de/index.php/topic,126864.0.html

Danke.

Habe eben noch eine Version ins svn geschubst, die etwas länger mit dem asyncOutput wartet und die vereinzelten HASH-responses auch noch "verklartextet".

Zu Deinen Sätzen ein paar Fragen - sorry fürs nachbohren, aber die Semantik von Daten ist eines meiner Hauptarbeitsgebiete

Kein Problem mit den Fragen .

- Was ist der Unterschied zwischen Jalousien und Rollläden bei Dir?

Jalousien haben drehbare Lamellen, und es gibt ein "special" dazu. Rollladen ist das, was  einen "Panzer" hat. Effektiv gibt es in der Steuerungslogik sonst keine weiteren Unterschiede, sind beides gDT "blind".

- Warum würde man "alle Jalousien" von "die Jalousien" unterscheiden?

"alle" und "sämtliche" sind bei mir die "Kenner" für Gruppenintents (wir hatten die Diskussion über structure schon, aus dem Folgenden wird vielleicht klarer, warum ich das anders passender finde).

Prinzipiell ist noch fraglich, ob wir einen "Durchbruch" von Einzel- zu Gruppenintent brauchen könnten, und was ggf. die Kriterien wären, das zu machen ("mach das licht aus" => mehre Möglichkeiten (im Raum)).

- Gibt es vorgefertigte Szenen für die Jalousien/Rollläden?

Bisher nicht.
Wäre dann aber eine vom gDT abgekoppelte Sache, die über "SetScene" laufen würde

- Gibt es einen Unterschied zwischen "halb zu" und "halb auf"?

Nein.
Steuert beides einen "speziellen" Zwischenstand, so dass ich die "Panzer-Wicklung" bei den Rollläden (CUL_HM) berücksichtigen könnte (49.5=> ca. 30, "spezielles Feature", ursprünglich entwickelt für/mit Gisbert)

- Fragst Du auch nach dem Dieselpreis in anderen Orten?

Bisher nicht, das hatte ich jetzt erst mal auf die Schnelle hingepinselt wegen der Tests. Aber prinzipiell sollte das auch ohne weiteres funktionieren, wobei hier das spezielle Thema noch nicht gelöst ist, dass eigentlich ein Reading abgefragt werden soll. STATE ginge schon, Rest ist "Todo".

- Wie viele Farben erkennt das System?

Das ist (fast) der slot aus der de-cfg, der nach meiner Erinnerung das Farbrad mit 360 Grad Farben in ca. 15 Grad-Schritten auflöst.
(Die Erläuterung zu Farben steht im Wiki, meine ich; das Prinzip ist Rhasspy-Farbe => Nummer => RHASSPY => HUE-Nummer auf der individuellen Skala des Devices, wenn das nicht geht Mapping zu rgb-Wert).

[Beta-User]

wobei hier das spezielle Thema noch nicht gelöst ist, dass eigentlich ein Reading abgefragt werden soll. STATE ginge schon, Rest ist "Todo".

...stimmt gar nicht, jedenfalls nicht, was den Type "price" angeht. Man muss nur "richtig fragen":

Code Auswählen Erweitern

was kostet{Type:price} (Diesel){Reading} [( in | an | bei )] $de.fhem.Device-info{Device}
(und die Doku anpassen/ergänzen... . Und das Ganze erweitern um eventuelle weitere Type's?)

Dafür kommt noch was anderes auf meine Liste:
Die Antwort auf die Abfrage, was RHASSPY "kann", erhöht vermutlich deutlich die Transparenz und auch die Akzeptanz beim Umfeld, von daher werde ich mal sehen, ob ich den GetState-Intent noch etwas aufbohre um eigene Abfragen zu RHASSPY (mit raumbezogenen Rückmeldungen).

@pah: Prinzipiell würde mich noch interessieren, ob die Rückmeldungen im  Test-Modus in etwa so sind, wie du dir das gedacht hattest?

[Beta-User]

Na nu?!? So still hier...?

Hat denn zwischenzeitlich jemand mal das Test-File-feature ausprobiert? Gibt es weitere Meinungen dazu...?

Wie bereits geschrieben: Die Ergebnisse sind recht aufschlussreich, und ich habe das auch zum Anlass genommen, nochmal kräftig an allen Ecken und Enden nachzujustieren, angefangen damit, dass man (vielleicht) auch "mach wärmer" oder "etwas heller bitte" sagen können sollte, "GetState" zu "allem möglichen" "missbrauchen" kann und voraussichtlich dann auch ein gewisser "probability-score" erreicht sein sollte...

Werde das ganze jetzt erst mal selbst still vor mich hin testen, wenn niemand "will haben" ruft... (Es gibt dann voraussichtlich noch ein paar kleinere Änderungen zum vorherigen Stand bzgl. der "keys" zu GetState usw.).

[Beta-User]

...immer noch still...?!?

Na ja, es gibt jetzt jedenfalls eine neue Version im svn, die de-Sprachdatei ist auch aktualisiert, weil es ein paar neue Antwort-Möglichkeiten gibt => braucht einen Neustart.

changelog:

- confidenceMin (tweak)
Ein (einstellbarer) Mindestwert (global oder pro Intent) muss erreicht sein, sonst wird keine Aktion ausgeführt

- blacklistIntents (special)
einzelne Intents können ignoriert werden, um z.B. "stop"-Kommandos aus HTTPMOD nicht als Kommando verfügbar zu machen

- intent SetNumeric
erlaubt mehr "devicelose" Kommandos (wärmer/kälter usw.)

- GetState überarbeitet:
-- erlaubt es, beliebige Inhalte auszuwerten, indem in rhasspyMapping GetState mit einem type und einer stateFormat-artigen "response" angeben wird;
-- Status-Infos zu RHASSPY selbst können abgefragt werden (insbesondere auf den aktuellen Raum der Anfrage bezogen)

=> neue keys für languageFile => Neustart notwendig!

- Test-Modus
Neue getter, getestet werden kann mit File und einzelnen Sätzen (es werden keine Schaltbefehle ausgeführt).

- Export von rhasspyMapping
Neuer getter, hilfreich vielleicht, wenn man was individualisieren will oder auf ein anderes Device kopieren.

Im Anhang dann auch die etwas erweiterte "Testsuite" von pah mit einem "Schnellschuss" zur Erkennung von Dialogen etc..

Viel Spaß beim Testen.

[Gisbert]

Hallo Jörg,

ich lese eifrig mit und lade in regelmäßigen Abständen die neueste Version runter.
Rhasspy empfängt meine Sprachbefehle über die Handy-App und sagt "Ok, zu Diensten" oder dergleichen.

Eine weiterführende Kommunikation mit Rhasspy habe ich noch nicht versucht, da ich es für mich zu schwierig ansehe, es umzusetzen. Interesse ist im Grunde schon gegeben, aber bis da der Groschen wieder fällt, das könnte dich und mich an unsere Grenzen bringen

Viele​ Grüße​ Gisbert​

[Beta-User]

Also, dann mal der Versuch einer "Kurzanleitung" für einen "Test" mit der im letzten Beitrag angehängten FEST.txt (oder der Ausgangsversion von pah):

Diese Datei so irgendwohin speichern, dass der User "fhem" sie lesen darf (z.B. nach /opt/fhem/FEST.txt mit passenden Rechten).
Dann das Testen mit "get <RHASSPY> test_file ./FEST.txt" starten, und etwas warten. Wird der Test halbwegs zeitnah fertig (bis 30 Sekunden), gibt es eine qualifizierte Rückmeldung, wenn nicht, eben eine timeout-Meldung. Für Sicherheitsfanatiker: bei mir läuft der Test ohne Stress durch, aber sicherheitshalber die statefile vorher wegzuschreiben kann nicht schaden, falls wider Erwarten doch was schief geht...

Während der Test läuft, ist ein Internal "testline" vorhanden, das hochgezählt wird und dann auch wieder gelöscht wird. Geht irgendwas schief, ändert sich die Zahl nicht mehr, und man kann dann den Prozess mit einem "get <RHASSPY> test_sentence bla blub" oä. stoppen. Da das ganze als "Ping-Pong"-Spiel zwischen RHASSPY und Rhasspy abläuft, wird FHEM auch in der Zeit nicht blockiert, Schaltanweisungen werden (hoffentlich) keine ausgeführt.

Die "FEST.txt" enthält einfach "nur" eine Sammlung von möglichen Ergebnissen aus einem speech2text-Prozess, die zeilenweise nacheinander getestet werden. Man kann die Zeilen (oder andere Sätze) genausogut jeweils einzeln testen: "get <RHASSPY> test_sentence <hier steht der gesprochene Text>".

Also eigentlich: Super-easy, und wer RHASSPY bis dahin ans Laufen gebracht hat, sollte damit keine ernsthaften Probleme haben.

Die spannende Frage ist: Warum sollte man das tun?!?

Nun ja, vermutlich wird/muss dazu jeder seine eigene Antwort finden...

Um zu erklären, was es für mich (bisher) gebracht hat, ein paar ergänzende Ausführungen.

Meine Nutzungsweise ist ähnlich wie bei Gisbert:

Rhasspy empfängt meine Sprachbefehle über die Handy-App und sagt "Ok, zu Diensten" oder dergleichen.

Da die App sehr bewußt gestart bzw. das "Mikro" aktiviert wird, wenn man was tun will, und dann recht klar umrissene Sätze gesagt werden, die sowohl der Sprecher und Rhasspy jeweils schon gut "kennen", sind die Ergebnisse meist auch zur vollen Zufriedenheit.
Die "Problemchen" der "normalen User", die per hotword aktivieren, und dann "eigenwillige" Schaltaktionen (oder Ansagen, Timer-Erstellungen, ....) beobachten, kenne ich daher nicht so richtig aus eigener Anschauung. Dazu kommt, dass es ist im normalen Betriebsmodus auch recht mühsam zu rekonstruieren ist, warum was (nicht) passiert ist, wenn mal was schiefgeht.

Läßt man die "geballte Ladung" (aus FEST.txt) auf RHASSPY los, erhält man dagegen recht schnell einen Überblick darüber,
- ob Rhasspy daraus überhaupt was ableitet oder "intent not recognized" ist (=> in der "result" bleibt einfach nur der Ausgangssatz stehen);
- welchen Intent Rhasspy abgeleitet hat und welche "keys" an RHASSPY übergeben wurden;
- wie RHASSPY das verarbeitet hat (jetzt: jedenfalls meistens).

Unmittelbare Folgen aus meinen bisherigen Tests:
1. Bei den ersten Tests war dann recht schnell klar, dass RHASSPY (nach meinem Geschmack) in zu vielen Fällen noch "irgendwas" gemacht hat, obwohl Rhasspy schon "weiß nicht so recht" gemeldet hat - was einem niedrigeren "confidence"-Level entspricht. Diesen (auch) auszuwerten, war eigentlich schon lange auf meiner "muss ich mir mal ansehen"-Liste, aber wegen der oben beschriebenen bewußten Aktivierung stand ja mehr oder weniger immer eine "1" da - das sah also "sinnfrei" aus.

Anders gesagt: Die "Radio/Fernsehen macht den Rollladen zu"-Fraktion sollte also (ganz ohne Tests) deutlich von der aktuellen Version profitieren, schlicht, weil (vermutlich) zufälliger "Kauderwelsch" eher aussortiert wird. Allerdings kann es sein, dass die (allgemeine) Grenze für "confidence" jetzt zu hoch oder niedrig angesetzt ist . Das rauszufinden, könnte einer der denkbaren Anstösse sein, um mal das "get" auszuprobieren .

2. Da die FEST.txt Beispielsätze dazu enthält, was andere User (und deren Mitbewohner) mit ihrer Sprachsteuerung so "tun", ist das ganze auch eine Fundgrube für eventuelle Verbesserungen und/oder Ergänzungen, von der man ggf. Gebrauch machen kann... Teilweise waren dazu Änderungen im RHASSPY-Code erforderlich, und für manches werden wird das ggf. auch noch zu besprechen haben, ob bzw. was noch fehlt.
Da manche von pah's Ausgangssätzen mit leichten Modifikationen zu "besseren" Ergebnissen führen, sind diese (teilweise) als Beispiel am Ende angefügt. Mittelfristig wäre es vermutlich sinnvoller, Varianten direkt untereinander zu listen und ggf. z.B. die Abschnitte zu kennzeichnen, so dass man auch eine gesonderte mengenmäßige Erfassung einzelner Themengebiete vornehmen könnte.

Hoffe, damit wird das Bild etwas klarer .

[drhirn]

Ich bekomm hier bei

Code Auswählen Erweitern

get Rhasspy test_sentence wer bist du
nur "Timeout for test sentence - most likely this is no problem, check testResult reading later, but your system seems to be rather slow..."
Was ich aber echt nicht glaube

testResult ist immer "Test mode stopped (might have been running already)"

[Beta-User]

Hmmm, kennt Rhasspy die siteId von deinem FHEM (typischerweise für "de": "defhem")?

Die muss zumindest im NLU-Modul auf der Rhasspy-Seite mit aufgeführt sein. Sorry, dass ich das in der Anleitung wohl ausgelassen habe (es steht hoffentlich in der commandref).