Modulentwicklung für Rhasspy Sprachassistent

[Gisbert]

Hallo Jörg,

@Gisbert: War meine Anleitung soweit nachvollziehbar?

von weitem betrachtet, hast du mir Mut gemacht; dann kam aber deine Konversation mit drhirn - da hab ich auf Durchzug geschaltet, ich bin noch nicht soweit und bis Ostern hab ich eher weniger Zeit mich damit auseinanderzusetzen. Aufgeschoben ist nicht aufgehoben.

Viele​ Grüße​ Gisbert​

[Beta-User]

bis Ostern hab ich eher weniger Zeit mich damit auseinanderzusetzen. Aufgeschoben ist nicht aufgehoben.

...kein Problem...

Die Diskussion hat zumindest mal aufgezeigt, wo die Anleitung lückenhaft war.

Es würde mich natürlich weiter interessieren, ob es jetzt auch bei anderen funktioniert, aber früher oder später wird da schon die eine oder andere Rückmeldung kommen...

Hier jedenfalls mal die aktualisierte Anleitung:
1. siteId von der FHEM Instanz (siehe entsprechendes Internal) im Bereich "Intent Recognition" der Rhasspy-Base eintragen.

2. mit "get <RHASSPY> test_sentence wie spät ist es" testen, ob die Kommunikation in den "Positiv-Fällen" klappt.

3. mit "get <RHASSPY> test_sentence alice kann von bob nicht erhört werden" (oder irgendeinem Unsinn, den Rhasspy nicht versteht) die Negativ-Fälle testen. Es sollte eine Antwort kommen, die in etwa so aussieht: "Test failed, result is: alice kann von bob nicht erhört werden => Intent not recognized."
Kommt ein Timeout, ist der "not recognized"-Topic vermutlich nicht in den "subscriptions" am MQTT2_CLIENT enthalten; wer die subscriptions von RHASSPY verwalten läßt ("attr rhasspy2mqtt subscriptions setByTheProgram") sollte dieses Problem nicht haben.

Wenn beides klappt, kann man die "geballte Ladung" auf Rhasspy loslassen:

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

Ich habe übrigens noch eine weitere Antwort auf die Frage gefunden: Weil man damit Lücken im Programmablauf aufdecken kann...

[drhirn]

von weitem betrachtet, hast du mir Mut gemacht; dann kam aber deine Konversation mit drhirn - da hab ich auf Durchzug geschaltet

Ignorier einfach alle Unterhaltungen zwischen Beta-User, pah, JensS oder mir. Das verwirrt im "Anfängerstadium" nur und hat (noch) keine Relevanz. Auch wenn das jetzt arrogant klingt. Ist nicht so gemeint.

Mach zu deinen Fragen einfach einen neuen Thread auf. Da bekommst du zielgerichtete Antworten und es bleibt übersichtlicher.

[drhirn]

Kommt ein Timeout, ist der "not recognized"-Topic vermutlich nicht in den "subscriptions" am MQTT2_CLIENT enthalten; wer die subscriptions von RHASSPY verwalten läßt ("attr rhasspy2mqtt subscriptions setByTheProgram") sollte dieses Problem nicht haben.

Code Auswählen Erweitern


test(s) passed successfully. Summary: tested 160 sentences, failed total: 123, amongst these in dialogues: 0. Testing time: 4.10 seconds. See ./FEST_result.txt for detailed results., duration: 4.10 s


[Beta-User]

Code Auswählen Erweitern


test(s) passed successfully. Summary: tested 160 sentences, failed total: 123, amongst these in dialogues: 0. Testing time: 4.10 seconds. See ./FEST_result.txt for detailed results., duration: 4.10 s


Danke für die Rückmeldung, sonst wären mir wirklich die Ideen ausgegangen...
Und ja: Performance auf dem Server ist offenkundig nicht das Problem .

Jetzt bin ich nur mal gespannt, ob dir die Analyse der FEST_result.txt auch das eine oder andere "aha"-Erlebnis bringt (oder die Frage aufwirft, wie man die dahinter stehende Aufgabe am effizientesten löst) .

Notizen an mich selbst:
- die "not recognized"-Fälle sollte man bei den "echten" Messenger-Fällen vermutlich auch noch gesondert mit einer Antwort bedenken, damit der Anfragende jedenfalls eine Rückmeldung bekommt;
- die doppelte Zeitausgabe muss nicht sein...
- Die ergänzte "Anleitung" sollte noch in den anderen Thread.

@all und insbesondere Gisbert: da kann man dann auch die Fragen zum Testen an sich und ggf. eben den Ergebnissen loswerden (so sie nichts mit den "internen Abläufen" zu tun haben).
Und: ruhig auch als "Einsteiger" testen; nur wenn eventuelle Fragen auftauchen, kann man was verbessern, sei es an den Programmabläufen, sei es an der Doku .

[drhirn]

Und ja: Performance auf dem Server ist offenkundig nicht das Problem .

Nein, haha. Nur das Beste für meine VMs

Jetzt bin ich nur mal gespannt, ob dir die Analyse der FEST_result.txt auch das eine oder andere "aha"-Erlebnis bringt (oder die Frage aufwirft, wie man die dahinter stehende Aufgabe am effizientesten löst) .

Nicht so wirklich. Liegt aber daran, dass bei mir Sprachassistenten seit jeher ein Schattendasein führen. Rhasspy wird bei mir (und nur mir) verwendet, um den PC und den TV einzuschalten und Lichtszenen im Wohnzimmer zu ändern. Das war's

[Beta-User]

Nicht so wirklich. Liegt aber daran, dass bei mir Sprachassistenten seit jeher ein Schattendasein führen. Rhasspy wird bei mir (und nur mir) verwendet, um den PC und den TV einzuschalten und Lichtszenen im Wohnzimmer zu ändern. Das war's

Spricht ja auch nichts dagegen, das so zu halten, ging mir ja lange genauso...

Allerdings war ich auch "überrascht", wie relativ genau man Anweisungen erteilen muß, um ein Ergebnis zu bekommen, es ist also (zum Teil auch) ein "Henne-Ei"-Problem. Dazu kommt ggf. noch das, was man als fehlende "Dialogfähigkeit" bezeichen könnte: die allgemeinere Akzeptanz einer solchen Lösung hängt u.A. auch davon ab, dass man sich mit ihr "unterhalten" kann (wenn ich insbesondere pahs Ausführungen zu diesem Thema korrekt verstanden/interpretiert habe). Bei RHASSPY war sowas (bisher) eher wenig bis nicht vorhanden...

Mit der Option, per Messenger Infos abzufragen, ist für mich aber ein interessantes Spielfeld dazugekommen, das m.E. auch flexibler ist als das, was z.B. msgDialog kann.

Nun ja, mal sehen, was wir da noch hinfrickeln können.

[Prof. Dr. Peter Henning]

Ich bin in den letzten Wochen durch meinen Beruf mal wieder komplett blockiert und komme wenig zum Testen.

Zum Thema Messenger: Ich habe Telegram an mein System angekoppelt. Über Telegram Keyboards für die wesentlichen Aufgaben - aber faktisch kann ich darüber alles abfragen und (bis auf sicherheitskritische Dinge) auch alles steuern, was ich per Spracheingabe tun kann.

LG

pah

[Beta-User]

Ich bin in den letzten Wochen durch meinen Beruf mal wieder komplett blockiert und komme wenig zum Testen.

...nun ja, die bestellte Pizza wird halt kalt, aber ich vermute, damit kannst du leben...

Zum Thema Messenger: Ich habe Telegram an mein System angekoppelt. Über Telegram Keyboards für die wesentlichen Aufgaben - aber faktisch kann ich darüber alles abfragen und (bis auf sicherheitskritische Dinge) auch alles steuern, was ich per Spracheingabe tun kann.

Ich habe auch Telegram und darüber ein paar Favoriten-Menüs im Einsatz. Alles mögliche Schalten oder abfragen geht sowieso, wenn man die Namen kennt. Als derzeitiger Maintainer von msgDialog habe ich es sogar in der Hand, das ggf. weiter zu verbessern, und mit dem "aktiviere etwas nur, wenn es über den Meta-Dialog kommt"-Mechanismus kann man damit auch nette Sachen basteln, die helfen, wenn man den/die Namen grade nicht parat hat.

Mein "Problem": irgendwie widerstrebt es mir, dafür extra nochmal eine zweite "Meta-Sprach-Ebene" einzuziehen - vermutlich ist das bei mir ähnlich wie bei dir mit Babble (und bei anderen glt ggf. dasselbe für Talk2FHEM oder TEERKO (?)). Deswegen nutze ich eben jetzt FEST.txt um die noch fehlenden Bausteinchen für eine sehr flexible Abfrage- und Ansage-Ebene zusammenzupuzzeln...

Gedanklich hänge ich grade an einer Anweisung wie "mach ein bißchen heller". Gibt es nur ein Gerät, das dafür in Frage kommt, ist es einfach, aber wie könnte man das umsetzen, wenn es sich um eine Gruppe von Leuchtmitteln handelt?
Vor allem, wenn da eventuell ein paar reine ein/aus-Geräte dabei sind, einige derzeit ausgeschaltet, ... (von "mach einfach die Rollläden auf, wenn es Tag ist" gar nicht zu sprechen...).

[drhirn]

Gedanklich hänge ich grade an einer Anweisung wie "mach ein bißchen heller". Gibt es nur ein Gerät, das dafür in Frage kommt, ist es einfach, aber wie könnte man das umsetzen, wenn es sich um eine Gruppe von Leuchtmitteln handelt?
Vor allem, wenn da eventuell ein paar reine ein/aus-Geräte dabei sind, einige derzeit ausgeschaltet, ... (von "mach einfach die Rollläden auf, wenn es Tag ist" gar nicht zu sprechen...).

Das wäre meiner Meinung nach in FHEM abzubilden. Aber da kenn ich mich nicht aus

[Beta-User]

Das wäre meiner Meinung nach in FHEM abzubilden. Aber da kenn ich mich nicht aus

To be discussed...

Also: Gedanklicher Ausgangspunkt war bei mir "mach wärmer" - das ging bis gestern ohne Device oder Gruppe gar nicht, obwohl doch eigentlich klar ist, was der Sprechende (in etwa) haben will, nämlich eine Anhebung der Solltemperatur in dem Raum, in dem er sich befindet...
Bei "mach lauter" ging diese Device-lose Logik "schon immer" (wobei ich mich im Moment frage, ob es immer an das richtige Device geht, wenn es zwei aktive gibt), jetzt geht es bei "desired-temp", wenn es genau ein passendes Gerät gibt (das habe ich jetzt durch "priority/inRoom"-Specials erzwungen, wo es nicht eindeutig war).

Das Problem, dass FHEM ohne RHASSPY nach meinem Gefühl im Moment hat: Ohne konkreten Anknüpfungspunkt kann es nicht abgrenzen, wo und was eigentlich im Detail passieren soll. Selbst wenn man z.B. eine structure gäbe, müßte man die zunächst identifizieren. Entweder der Sprechende tut es, (indem er den Namen nennt...) oder es müßte eine Art "Fallback" geben, den RHASSPY dann heranzieht.
Letzteres hat aber m.E. kaum Vorteile gg. einer dynamisch erstellten "RHASSPY-Struktur", wie sie im Kern ja bereits angesprochen wird, wenn man "dimme gruppe xy runter" sagt. (Bei einer structure hagelt es übrigens Log-Einträge, wenn man eine Mischung von dim- und on/off-Geräten hat).

An sich müßte es möglich sein, eine Art "virtuelle Durchschnittshelligkeit" zu bestimmten, die eine solche spontan abgegrenzte Gruppe grade hat, und die zu verändern, indem man eben entweder Dimm-Befehle ausführt, oder einzelne Geräte ab (ggf. individuellen) Grenzwerten ein- oder ausschaltet. Aber ja: Es ist und bleibt relativ komplex rauszufinden, was in welchem Fall konkret passieren soll, und die Geschmäcker sind verschieden, und viele Anwendungsfälle kann man vermutlich über Szenen besser abbilden...

[drhirn]

Hmm. Naja, wenn einer "mach wärmer" sagt, dann wissen wir ja schon mal, was er will (sofern er nicht das Licht wärmer stellen will). Und wir wissen, wo er wahrscheinlich ist (siteId). Müsste man ja nur noch ein Gerät finden, dass man wärmer stellen kann (GDT). Und wenn's mehrere gibt, nachfragen.

[Beta-User]

Hmm. Naja, wenn einer "mach wärmer" sagt, dann wissen wir ja schon mal, was er will (sofern er nicht das Licht wärmer stellen will). Und wir wissen, wo er wahrscheinlich ist (siteId). Müsste man ja nur noch ein Gerät finden, dass man wärmer stellen kann (GDT). Und wenn's mehrere gibt, nachfragen.

Na ja, bei meinen CUL_HM-Klimageräten ist es so, dass die entweder "geteamt" sind (es reicht, einen zu stellen, der andere folgt dann nach), oder man sinnigerweise den Wandthermostaten anspricht (mit identischer Folgewirkung). Beides ist eine Ausgangssituation, bei der man mit "priority" für eindeutige Verhältnisse in "SetNumeric" sorgen kann, und das z.B. dann zweimal im Jahr zu ändern, falls man noch eine Klimaanlage hat, ist dann die Lösung für die, die keinen dummy+eigene Logik dazwischenklemmen wollen...

Aber nochmal: Wo ist der Unterschied zur Beleuchtung...? Außer der vermuteten größeren Anzahl (=>SetNumericGroup) der betroffenen Devices (und den daraus so oder so resultierenden Detailfragen)?

[Beta-User]

...da ich ja grade eh' dabei war, wieder etwas tiefer im Code zu graben, habe ich eben noch ein update ins svn geschubst, das im Intent "SetTimer" einen "key" "GetTimer" (ähnlich wie "CancelTimer") versteht und dann zurückmeldet, wann der ggf. abläuft. Geht nur mit Timern, die RHASSPY erstellt hat bzw. die dessen Namenskonvention folgen...

Die "üblichen" Zusätze für Räume und Label sind auch für die Abfrage erlaubt, und beim Testen bekommt man jetzt auch dafür eine Rückmeldung (wenn gesetzt, was über Tests nicht erfolgt).

Code Auswählen Erweitern


[de.fhem:SetTimer]
[...]
wann klingelt{GetTimer} [<labels>{Label}] [<rooms>]
\[auf] wann{GetTimer} ist [<labels>{Label}] [<rooms>] ( gestellt | fällig | zu erwarten )

Da es eine neuen Antwort für "es gibt keinen passenden Timer" gibt, braucht dieses update einen Neustart (und eine passende de-cfg, wenn man es in DE haben will).

[drhirn]

Cool!

Ein "stopp" wäre super, wenn der Timer klingelt. Aber ich weiß nicht, wie man das lösen könnte. Irgendwie hört Rhasspy nicht zu, während es Audio ausgibt.