Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Habe heute alle sentences und mappings auf englisch umgestellt und bin erfreut, dass es funktioniert. 

Freut mich sehr, dass das geklappt hat. Würdest du den Aufwand für die Umstellung als groß ansehen, oder eher als klein, wenn man mal weiß, was zu ändern ist?

Z.B. Kaldi Mixed Language Model Weight soll nun tatsächlich funktionieren. Das wäre ein großer Sprung, da ein riesen Wortschatz dran hängt.
Leider läuft das bisher nur mit Docker und die eigenständige Debian-Installation erweist sich als langwierig...

Das Thema würde mich auch (später mal) interessieren. Ich weiß, die Gefahr der Unübersichtlichkeit besteht, wenn man Teilthemen auf mehrere Thread verteilt, aber trotzdem die Bitte, das in einen separaten Thread zu packen. MAn. wäre das auch für die aktuellen sentences-Tests besser gewesen, denn bei dem alten Thread ist es so: Neue User (mich eingeschlossen) interessiert die ganze Historie nicht im Detail, jeder "Einsteiger" in ein neues Thema will eigentlich nur eine aktuelle summary haben (selbst wenn die vorläufig ist und offene Fragen als solche benennt), und sich nicht seitenlang alles mögliche (potentiell schon wieder veraltete) durchlesen und sich dadurch verwirren lassen.

Nein
[...]
Und hier der Sentence-Eintrag:

Code Auswählen Erweitern

[de.fhem:ConfirmAction]
(ja | tu es | ist ok ){Mode:OK}
(lass es | nein | abbrechen | abbruch ){Mode:Cancel}


Das simle "ja" scheint für Rhasspy zu kurz zu sein, wenn "intent not recognized" zurückkommt. Diese Erfahrung hatte drhirn ja auch gemacht. Mit meinem "ja mach" scheint es zu funktionieren, wenn ich die etwas kryptische Rückmeldung von drhirn richtig deute.

Apropos "intent" und Timeout - betr. der "nein"-Confirmation habe ich folgende Theorie: RHASSPY deaktiviert den. Das bedeutet aber nicht, dass es ihn (vorübergehend) nicht mehr gibt (das war meine Vermutung), und auch noch nicht mal, dass er nicht mehr versendet wird. Entweder es ist ein Fehler im Deaktivierungs-Code oder  ich würde als Bug bei Rhasspy ansehen, aber wir könnten dann vermutlich als würgaround dann einfach die "SilentConfirmation" durchführen.
Mal sehen...

Da zwar ausgiebiges Lob zurückkam, aber keine ausdrückliche Rückmeldung zu dem Timer-Thema vom Ober-Skeptiker betr. des "Wecker"-Dingens, hier noch eine Anleitung:

a) es sollte (wie üblich  ...) alles funktionieren, was mit dem "alten timer"-Code auch ging:
"timer auf 5 Sekunden", "timer auf 2 Minuten 7 sekunden", ...
Wenn man dann in die Bereiche von einigen Minuten oder mehreren Stunden kommt, kommt eben dann eine andere Rückmeldung .
b) Man kann "belabeln":
"timer Eier auf 5 Minuten"
Das ist optional, führt aber uU. dazu, dass man in einem Raum mehrere Timer laufen haben kann (und entsprechend viele Readings hat (weiß nicht, ob man das überdenken sollte oder eben einfach von Zeit zu Zeit nicht mehr genutzte Readings löschen sollte).
c) Absolute Zeitangaben sind möglich:
"timer auf 18 Uhr", "Timer auf 18 Uhr 15", "Wecker Kartoffeln auf 18 Uhr 15", "Wecker Eier auf 6 Uhr 22".
Auch hier wieder: Bitte verschiedene Endezeiten (ab jeweils "jetzt") testen, und das ganze dann auch mal über Mitternacht raus versuchen.

Wenn "use" gesetzt ist aber kein gDT-Attribut gesetzt, hat das ja eigentlich keine Auswirkungen, oder? Überraschend wird's nur, wenn man schon gesetzte gDT-Attribute von anderen Sprachsteuerungen hat und nicht damit rechnet, dass diese Geräte dann in Rhasspy auftauchen.
Ich überleg nämlich gerade, was passiert, wenn wir "use" automatisch setzen bzw. der "default" 1 ist.

"use" wirkt sich in der Tat nur aus, wenn a) überhaupt irgendwo ein gDT gesetzt ist und b) (zusätzlich!) das Device von der devspec erfasst ist. Von daher sollte sich die Überraschung in Grenzen halten.
Das mit dem default halte ich für eine gute Idee. Wer es von den jetzigen Usern nicht will, liest hier vermutlich sowieso mit und kann es abschalten, und Einsteigern (=>29.) erleichtert es die Sache, wenn "sowieso" schon gDT gesetzt sind.
Soll ich oder machst du?

Für den 29. sehe ich gute Chancen zur weiteren Verbreitung und Unterstützung. Die Intents im Forum sind ein guter Anfang. Diese Infos gebündelt als ein README für die deutsche Version im Github bzw. zukünftig im Wiki würde ich als Schlüssel zur Verbreitung ansehen.

Die sentences sind definitiv wichtig. Genauso wichtig ist eine offene Kommunikation zu Möglichkeiten und Grenzen, von daher bin ich auch mal gespannt, was ihr dazu so zu berichten habt, ich selbst bin nämlich noch in der Experimentierphase: Einerseits begeistert, dass das alles verblüffend gut klappt, andererseits schaue ich immer mal wieder auf top (derzeit unauffällig) und die "Treffer". Letztere sind in meiner Wahrnehmung  hin und wieder weiter manchmal irgendwie zufällig. Weiß noch nicht so recht, ob es daran liegt, dass ich zum Testen das ganze relativ schnell etwas breiter ausgerollt habe und daher die Namensvergabe teilweise noch nicht so durchdacht (oder verinnerlicht) ist, dass es "super" ist, sei es, dass es (auch bei anderen Lösungen!) eben Grenzen des Verfahrens im allgemeinen gibt. Aber da fehlt mir z.B. auch der Vergleich mit anderen Sprachsteuerungssystemen. Ich vermute, alle kämpfen an der Stelle mit ähnlichen Problemen. (Ich habe aber mal wieder nicht die Neigung, sämtliche 1000 Seiten zu alexa und homebridge zu lesen...).
Auch dazu bin ich mal auf den 29. gespannt .

[drhirn]

MAn. wäre das auch für die aktuellen sentences-Tests besser gewesen, denn bei dem alten Thread ist es so: Neue User (mich eingeschlossen) interessiert die ganze Historie nicht im Detail, jeder "Einsteiger" in ein neues Thema will eigentlich nur eine aktuelle summary haben (selbst wenn die vorläufig ist und offene Fragen als solche benennt), und sich nicht seitenlang alles mögliche (potentiell schon wieder veraltete) durchlesen und sich dadurch verwirren lassen.

Mein Plan war, die Sentences/Devices dann in eine Doku zu packen, sobald die Tests abgeschlossen sind.
Aber du hast recht, ich mag auch keine ewig langen Threads. Andererseits ist bei einem neuen die Gefahr, dass das ein paar Mitleser nicht mitbekommen.
Und ich verlinke alle Intent-Test-Beiträge ja im ersten Beitrag. (Außer die von gestern, die hab ich vergessen )

Das simle "ja" scheint für Rhasspy zu kurz zu sein, wenn "intent not recognized" zurückkommt. Diese Erfahrung hatte drhirn ja auch gemacht. Mit meinem "ja mach" scheint es zu funktionieren, wenn ich die etwas kryptische Rückmeldung von drhirn richtig deute.

Ich habe das zwar nicht behauptet, weil ich das nicht wusste. Aber ich werde das gleich ausprobieren.

Da zwar ausgiebiges Lob zurückkam, aber keine ausdrückliche Rückmeldung zu dem Timer-Thema vom Ober-Skeptiker betr. des "Wecker"-Dingens, hier noch eine Anleitung:

Suuuper, danke!

Auch hier wieder: Bitte verschiedene Endezeiten (ab jeweils "jetzt") testen, und das ganze dann auch mal über Mitternacht raus versuchen.

Ahm. Letzte Woche hat sich bei mir mal Rhasspy während dem Fernsehen bei mir gemeldet (wie so oft). Ich hab nur leider nicht verstanden, was sie mir gesagt hat. Dafür hat sich mich dann mitten in der Nacht mit "Timer abgelaufen" angebrüllt. Das mit "über Mitternacht" scheint also zu funktionieren

Das mit dem default halte ich für eine gute Idee. Wer es von den jetzigen Usern nicht will, liest hier vermutlich sowieso mit und kann es abschalten, und Einsteigern (=>29.) erleichtert es die Sache, wenn "sowieso" schon gDT gesetzt sind.
Soll ich oder machst du?

Darf ich dich bitten?

Die sentences sind definitiv wichtig. Genauso wichtig ist eine offene Kommunikation zu Möglichkeiten und Grenzen, von daher bin ich auch mal gespannt, was ihr dazu so zu berichten habt, ich selbst bin nämlich noch in der Experimentierphase: Einerseits begeistert, dass das alles verblüffend gut klappt, andererseits schaue ich immer mal wieder auf top (derzeit unauffällig) und die "Treffer". Letztere sind in meiner Wahrnehmung  hin und wieder weiter manchmal irgendwie zufällig. Weiß noch nicht so recht, ob es daran liegt, dass ich zum Testen das ganze relativ schnell etwas breiter ausgerollt habe und daher die Namensvergabe teilweise noch nicht so durchdacht (oder verinnerlicht) ist, dass es "super" ist, sei es, dass es (auch bei anderen Lösungen!) eben Grenzen des Verfahrens im allgemeinen gibt. Aber da fehlt mir z.B. auch der Vergleich mit anderen Sprachsteuerungssystemen. Ich vermute, alle kämpfen an der Stelle mit ähnlichen Problemen. (Ich habe aber mal wieder nicht die Neigung, sämtliche 1000 Seiten zu alexa und homebridge zu lesen...).
Auch dazu bin ich mal auf den 29. gespannt .

Ganz ehrlich? Überhaupt kein Vergleich zu Alexa, Google, Siri. Wäre auch vermessen, das überhaupt zu erwarten. Oder zu erwarten, dass das irgendwann so wird. Hinter Rhasspy stecken weder Milliarden an Dollar, noch riesige Serverfarmen, noch eine schier unendliche Zahl an Trainingsdaten. Das darf man nie vergessen. Trotzdem funktioniert Rhasspy erfreulich gut finde ich. Man ist halt in den Möglicheiten beschränkt und hat viel Handarbeit. Aber das Projekt ist eigentlich noch sehr jung. Mal sehen, was da noch kommt.

[Cordula]

Zum Thema shortcuts:

Bei mir funktioniert das mit "Ja mach" oder auch mit "Ja mach das bitte" auch nicht. Gleiche Fehlermeldung: hermes/nlu/intentNotRecognized. Version 2.5.10

[drhirn]

Mixed Language Model Weight soll (so habe ich es verstanden) alle deutschen Wörter mit in die Erkennung einfließen lassen. Sobald mein separates Kaldi läuft, werde ich hoffentlich mehr dazu schreiben können.
Du hast ja Docker am Start und bist bestimmt schneller.

Also, ich weiß bis jetzt nur, dass ein Mixed Language Model Weight Wert von 0.05 die Trainingszeit auf einer Proxmox VM mit 4CPUs um 180s verlängert 
So viel, wie ich derzeit durch die Tests trainieren lasse, kann ich das nicht brauchen

[drhirn]

Zum Thema shortcuts:

Bei mir funktioniert das mit "Ja mach" oder auch mit "Ja mach das bitte" auch nicht. Gleiche Fehlermeldung: hermes/nlu/intentNotRecognized. Version 2.5.10

Kann ich bestätigen.

[Beta-User]

Zum Thema shortcuts:

Bei mir funktioniert das mit "Ja mach" oder auch mit "Ja mach das bitte" auch nicht. Gleiche Fehlermeldung: hermes/nlu/intentNotRecognized. Version 2.5.10

Hmm, bin da im Moment ratlos. RHASSPY braucht halt eine eingehende Bestätigung (oder eben einen Abbruch). Wenn es auf der Rhasspy-Seite hakt - warum auch immer - kann das nicht klappen....
Tiefergreifende Analysen dazu habe ich nicht gemacht, aber wenn es da schon Schwierigkeiten mit so (vermeintlich) einfachen Sachen gibt, ist das unschön.

"ja mach" gibt mir jedenfalls "Warte grade nicht auf eine Bestätigung" zur Antwort.
(habe aber nach dem update bisher nur den Dienst neu gestartet, nicht den ganzen Server; auch nach einem  Training@2.5.10 passt das noch).

Also, ich weiß bis jetzt nur, dass ein Mixed Language Model Weight Wert  [...]

...klingt spannend...

Suuuper, danke!

Ahm. Letzte Woche hat sich bei mir mal Rhasspy während dem Fernsehen bei mir gemeldet (wie so oft). Ich hab nur leider nicht verstanden, was sie mir gesagt hat. Dafür hat sich mich dann mitten in der Nacht mit "Timer abgelaufen" angebrüllt. Das mit "über Mitternacht" scheint also zu funktionieren

Na ja, es ging eher a) um die Rückmeldung, die man direkt nach dem Setzen eines Timers bekommt bzw. b) darum, dass er zum richtigen Zeitpunkt abläuft .

Darf ich dich bitten?

Kommt bei Gelegenheit.

Ganz ehrlich? Überhaupt kein Vergleich zu Alexa, Google, Siri. Wäre auch vermessen, das überhaupt zu erwarten. Oder zu erwarten, dass das irgendwann so wird. Hinter Rhasspy stecken weder Milliarden an Dollar, noch riesige Serverfarmen, noch eine schier unendliche Zahl an Trainingsdaten. Das darf man nie vergessen. Trotzdem funktioniert Rhasspy erfreulich gut finde ich. Man ist halt in den Möglicheiten beschränkt und hat viel Handarbeit. Aber das Projekt ist eigentlich noch sehr jung. Mal sehen, was da noch kommt.

Dieses "die haben viel Geld"-Argument ist m.E. nur bedingt tragfähig. Natürlich braucht man bei mehr Variationsmöglichkeiten genauere Unterscheidungsmethoden, und in dem Zusammenhang dann auch entsprechend Rechenpower. Das schließt aber nicht aus, dass man mit relativ bescheidenen Mitteln schon mehr als akzeptable Ergebnisse erzielen kann - dass das eine entsprechend "intelligente" Konfiguration voraussetzt, ist schon klar, aber auch da sollten sich die Aufwände in einem überschaubaren Rahmen halten lassen.
Im Ergebnis kochen eben alle nur mit Wasser, und ein gutes Rezeptebuch hilft manchmal über das Fehlen von Kaviar ganz gut hinweg ... Also: wardmrsab.

[drhirn]

Hmm, bin da im Moment ratlos. RHASSPY braucht halt eine eingehende Bestätigung (oder eben einen Abbruch). Wenn es auf der Rhasspy-Seite hakt - warum auch immer - kann das nicht klappen....
Tiefergreifende Analysen dazu habe ich nicht gemacht, aber wenn es da schon Schwierigkeiten mit so (vermeintlich) einfachen Sachen gibt, ist das unschön.

Ich würde dem Thema momentan keine zu hohe Priorität gönnen. Es ist auch im Rhasspy-Forum noch ziemlich ruhig diesbezüglich. Bringen wir unsere Standard-Intents mal vollständig zum Laufen.

Na ja, es ging eher a) um die Rückmeldung, die man direkt nach dem Setzen eines Timers bekommt bzw. b) darum, dass er zum richtigen Zeitpunkt abläuft .

Ist der Plan für heute. Warte schon darauf, dass mich Rhasspy erinnert, dass ich bald zum Zahnarzt muss 

[Beta-User]

Also: "use" müßte anliegend default sein, und die gemessene Temperatur kommt jetzt auch beim Thermostaten.
Bin noch nicht sicher, ob das nicht Nebenwirkungen auf die Solltemperatur hat, aber wenn, war das sowieso bisher ein Zufallstreffer, da war jedenfalls ein kleiner aber wirkungsvoller Typo im Code...
Na jedenfalls wäre jetzt die Herausforderung, die Solltemperatur ansagen zu lassen .

Generell ist da noch etwas Vorbereitung drin, um ggf. auch "subType" auswerten zu können (insbesondere für "desired-temp"). Allerdings bin ich mir noch nicht sicher, ob das auf diese Art sinnvoll gelöst ist, wird sich zeigen.

Dann mal viel Spaß beim Dentisten und später wieder beim Testen...

[JensS]

Freut mich sehr, dass das geklappt hat. Würdest du den Aufwand für die Umstellung als groß ansehen, oder eher als klein, wenn man mal weiß, was zu ändern ist?

Der Aufwand pro Device ist gering. Da sich alle Devices im Raum Rhasspy befinden, hat man auch eine gute Übersicht, was man anfassen muss.

Gruß Jens

[Beta-User]

Danke für die Rückmeldung.

Anbei wieder eine Iteration weiter:
- desired-temp ist als neue abfragbare Kategorie drin. Noch nicht optimaler sentence (GetNummeric):

Code Auswählen Erweitern

((Solltemperatur | Wunschtemperatur | Zieltemperatur){Type:desired-temp} | ( warm | kalt | heiß | Temperatur ){Type:temperature}) [ist es | von | vom | ist ] ([(im|auf dem)]($de.fhem.Room){Room}|[das]($de.fhem.Device){Device})
- In dem confirmation-Code waren noch einige Ungereimtheiten drin. Bei mir funktioniert das weiter, vielleicht hilft es auch bei euch...? Was jedenfalls besser ist: Es fühlt sich jemand für das "lautlose nein" zuständig, es gibt keinen Timeout mehr.

[drhirn]

Ich arbeite gerade am Timer. Da laufen die letzten Tests. Schau mir deine Änderungen gleich danach an.

[drhirn]

Unser Gesundheitsminister tritt wohl zurück, ich allerdings noch nicht. Habe am Timer gebastelt. Ihr werdet mich prügeln dafür, aber ihr müsst eure Rhasspy-Sentences anpassen. Es gab da Inkonsistenzen was die Groß-/Kleinschreibung der Labels betrifft (hourabs, hour, min, sec). Außerdem hab ich als Vorsichtsmaßname Cancel in CancelTimer umbenannt. Nur Cancel könnte unter Umständen zweideutig werden.
Das Wort "timer" hab ich aus den Sentences gestrichen und ein "Label" draus gemacht. Gemeinsam mit Änderungen an den Sprachdateien gibt das schönere Sprachausgaben.
Außerdem werden die Readings nicht mehr auf 0 od. 1 gesetzt, sondern auf die Uhrzeit, wann der Timer abläuft. Nach Ablauf od. Abbruch werden die Readings wieder gelöscht.

Meine Sentences:

Code Auswählen Erweitern


[de.fhem:SetTimer]
labels=( Wecker | Eieruhr | Kartoffeltaimer | Teetaimer | Taimer)

# Timer auf eine Stunde, 20 Minuten und 3 Sekunden
# Timer auf eine Stunde
# Timer auf drei Minuten
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (in|auf) [((1..60){Hour!int} (stunde|stunden))] [und] [((1..60){Min!int} (minute|minuten))] [und] [((1..60){Sec!int} (sekunde|sekunden))]

# Timer auf ein einviertel Stunden
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (in|auf) (1..60){Hour!int} (einviertel{Min:15}|einhalb{Min:30}|dreiviertel{Min:45}) (stunde|stunden)

# Timer auf ein einhalb Minuten
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (in|auf) (1..60){Min!int} (einviertel{Sec:15}|einhalb{Sec:30}|dreiviertel{Sec:45}) (minute|minuten)

# Timer auf 12 Uhr 15
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (in|auf|um) (1..24){Hourabs!int} uhr [(1..60){Min!int}]

# Timer löschen
(lösche|entferne|stoppe){CancelTimer} [den|die] [<labels>{Label}]  [in|im|in der|auf der] [$de.fhem.Room{Room}]
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (abbrechen|stoppen|löschen){CancelTimer}


[drhirn]

- In dem confirmation-Code waren noch einige Ungereimtheiten drin. Bei mir funktioniert das weiter, vielleicht hilft es auch bei euch...? Was jedenfalls besser ist: Es fühlt sich jemand für das "lautlose nein" zuständig, es gibt keinen Timeout mehr.

Funktioniert!

Aber:
- Bei einer positiven Bestätigung bleibt im Reading "voiceResponse" ein HASH stehen, solange man die Seite nicht manuell aktualisiert. Bei negativ wechselt das Reading auf "habe abgebrochen"
- Sagt man nichts, gibt's trotzdem eine Aktion. Und zwar positiv, wenn man "ja" in den sentences hat, ansonsten negativ weil "nein" verstanden wird. Das dürfte aber eine Rhasspy-Geschichte sein. Kann man lösen, in dem man in den betreffenden Sentences alles auf optional stellt:

Code Auswählen Erweitern


[de.fhem:ConfirmAction]
\[(ja mach|ja|ja bitte|tu es|ist ok|bitte darum){Mode:OK}]
\[(lass es|nein|abbrechen|abbruch){Mode}]


[Beta-User]

Funktioniert!

Danke für die Rückmeldung und auch für's Verbessern der sentences.
Wegen dem HASH muss ich mal schauen, aber wenn man einen refresh braucht, heißt das eigentlich immer, dass keine ausreichende Info über das getriggerte Gerät (via ParseFn an fhem.pl) zurückgegeben wurde.

Habe am Timer gebastelt. [...]

MAn. kein Grund, irgendwen zu verprügeln!
Klingt alles sinnvoll, und ich bin auch ausgesprochen dankbar, wenn jemand meine "feasibility studies" dann aufgreift und vollends "zur Marktreife" fertig baut .
Auch das mit den erläuternden Kommentaren direkt in sentences.ini ist eine gute Idee, btw.!

[Beta-User]

...auf Verdacht (=ungetestet!) noch ein paar kleinere Änderungen. Hoffentlich (!) sind folgende Punkte damit erledigt:
- ConfirmAction sollte jetzt auf alle Fälle was zurückliefern, und über die kleine Ergänzung in onmessage() sollte jetzt eigentlich immer abgesichert sein, dass zumindest die aufgerufene RHASSPY-Instanz zurückegliefert wird;
- auch die desired-temp-Rückmeldung verwendet jetzt $location; der technische Name war unschön;
Da der Teil bisher in der de-cfg noch nicht drin war, auch dazu ein update.