Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Ja, "frisches" global (oder gesäubertes ).

Weil im Demo-FHEM auch ein sunRise Device vorkommt, dachte ich mir, das wäre eigentlich ein guter Anschauungspunkt für Shortcuts.

Bekommen wir das hin, dass so ein Shortcut funktioniert?

Code Auswählen Erweitern

i="wann geht die sonne auf" f="" r="um [Astro:sunRise] uhr"

Derzeit wird mir die Response einfach vorgelesen (voiceResponse: um [Astro:sunRise] uhr).

Guter Gedanke, eventuell müssen wir das aber im Detail anders lösen. Mal schauen.

Ich glaube, der timerLimits-Code sollte auch passen, kurze cref (rhasspyTweaks) dazu ist auch drin, siehe Anhang. Was mir noch nicht 100% gefällt sind "Null"-Ansagen, z.B. wenn man den Wecker auf ganze Stunden stellt... Das ist aber nicht neu dazu gekommen.

[drhirn]

Warum antworten wir nicht wirklich einfach mit 12 Uhr 15, wenn Hourabs vorhanden ist? Dem, der den Timer so setzt, ist ja im Normalfall wurscht, wie viel Minuten und Sekunden es bis dahin sind. Also, mir zumindest.

[drhirn]

Aber, die rhasspyTweaks bzgl. Timer funktionieren. Und wenn ich die letzte Zahl auf 0 stelle (oder die erste), hab ich genau das, was ich will

[Beta-User]

Aber, die rhasspyTweaks bzgl. Timer funktionieren. Und wenn ich die letzte Zahl auf 0 stelle (oder die erste), hab ich genau das, was ich will

.

Wie schon mehrfach geschrieben: wir können gerne über die im Modul vercodeten defaults diskutieren, die "Nullwerte" würde ich aber gerne an beiden Stellen vermeiden wollen, sonst hagelt es vermutlich nur Beschwerden über den vermeintlich "dummen" Code...

Guter Gedanke, eventuell müssen wir das aber im Detail anders lösen. Mal schauen.

Lösungsvorschlag für das Detail: Alle response-Werte gehen nochmal durch "RHASSPY_ReplaceReadingsVal()", es muss nur einer der Parameter p, f oder r angegeben werden.
Gültig ist daher auch:

Code Auswählen Erweitern

i="wann geht die sonne auf" r="um [Astro:sunRise] uhr"

Kurz angetestet, scheint zu funktionieren, cref ist dahingehend aktualisiert.

[drhirn]

Wie schon mehrfach geschrieben: wir können gerne über die im Modul vercodeten defaults diskutieren

Das ist schon ok so. Kann sich ja jeder einstellen, wie er will.

Lösungsvorschlag für das Detail: Alle response-Werte gehen nochmal durch "RHASSPY_ReplaceReadingsVal()", es muss nur einer der Parameter p, f oder r angegeben werden.
Gültig ist daher auch:

Code Auswählen Erweitern

i="wann geht die sonne auf" r="um [Astro:sunRise] uhr"

Kurz angetestet, scheint zu funktionieren, cref ist dahingehend aktualisiert.

Hmm, kann ich leider nicht bestätigen. Hab das Modul neu geladen, FHEM neu gestartet, update devicemap gemacht. Aber trotzdem wird mir noch die eckige Klammer vorgelesen. Hab ich was vergessen?

Mah, fies! Das Reading heißt gar nicht sunRise. Sondern SunRise. Damit geht's.

[Beta-User]

Das ist schon ok so. Kann sich ja jeder einstellen, wie er will.

Na ja, meine Vorstellung wäre, dass man was voreinstellt, das erst mal als "mehrheitsfähig" durchgehen könnte. Die 3 Stunden für absolute Zeitangaben sind relativ lang, sehe ich auch so, kommt halt aus dem Ursprungscode. Vorschlag wäre, das (5. Parameter) auf eine Stunde (HOURSECONDS) voreinzustellen.
Unklar ist mir noch, was passiert, wenn man "nichts" bzw. nichtnummerische Werte angibt, wäre gut, wenn du das testen könntest.

Mah, fies! Das Reading heißt gar nicht sunRise. Sondern SunRise. Damit geht's.

Bitte auch in der cref anpassen.

Btw.: Das war ein erfüllter feature-request, und die sollte es doch eigentlich vor dem 29. gar nicht geben ...

Ansonsten habe ich auch "drumrum" die offenen Punkte noch ergänzt etc.. Würde vorschlagen, "meine" Stelle zu nutzen, da kann man den Text freier schreiben.
Einen hatte ich auf der Shortlist vergessen, nämlich das Abspielen von einer WAV bei Wecker-Ende.
Muss mal schauen, wie ich Rhasspy dazu bewegen kann, die "bin bereit"-etc-Sounds abzuspielen, dann geht's ggf. an der Stelle weiter...

[drhirn]

Bitte auch in der cref anpassen.

Erledigt.

Btw.: Das war ein erfüllter feature-request, und die sollte es doch eigentlich vor dem 29. gar nicht geben ...

Ja, haha, verdammt, erwischt
Aber immerhin einer mit direktem Bezug auf den 29.

Würde vorschlagen, "meine" Stelle zu nutzen, da kann man den Text freier schreiben.

Stimmt. Am Anfang sieht man's allerdings besser. V.a. weil die CRef bei mir hellgrau auf weißem Hintergrund ist. Aber ich kann damit leben. Meine Punkte sind eh abgearbeitet.

Einen hatte ich auf der Shortlist vergessen, nämlich das Abspielen von einer WAV bei Wecker-Ende.
Muss mal schauen, wie ich Rhasspy dazu bewegen kann, die "bin bereit"-etc-Sounds abzuspielen, dann geht's ggf. an der Stelle weiter...

Die WAV byte für byte an "hermes/audioServer/<siteId>/playBytes/<beliebige SessionID>" schicken. Hätte mir gedacht, wir nehmen playWAV dafür.

[drhirn]

Na ja, meine Vorstellung wäre, dass man was voreinstellt, das erst mal als "mehrheitsfähig" durchgehen könnte. Die 3 Stunden für absolute Zeitangaben sind relativ lang, sehe ich auch so, kommt halt aus dem Ursprungscode. Vorschlag wäre, das (5. Parameter) auf eine Stunde (HOURSECONDS) voreinzustellen.
Unklar ist mir noch, was passiert, wenn man "nichts" bzw. nichtnummerische Werte angibt, wäre gut, wenn du das testen könntest.

Code Auswählen Erweitern

timerLimits=90,300,3000,2*HOURSECONDS,x

PERL WARNING: Use of uninitialized value in numeric lt (<) at ./FHEM/10_RHASSPY.pm line 3160.
PERL WARNING: Use of uninitialized value in numeric lt (<) at ./FHEM/10_RHASSPY.pm line 3162.
PERL WARNING: Use of uninitialized value in numeric lt (<) at ./FHEM/10_RHASSPY.pm line 3169.

Fehlt eine Zahl, bekomme ich ein FHEM-Popup mit

in timerLimits=300,3000,2*HOURSECONDS,0, 5 comma separated values have to be provided

[Beta-User]

Ok, die Warnings sind unschön, geben aber dem "kundigen Leser" einen Hinweis auf die Ursache. Paßt m.E. soweit. Dass der Code wenigstens vorab die Zahl der Argumente checkt, ist "klar" . Die Frage war eher, ob man das noch verbessern muss, um Abstürze zu vermeiden.

Der "nichts"-Test, um das abschließend zu klären, sähe dann noch z.B. so aus:

Code Auswählen Erweitern

timerLimits=90,,,,xEs sollten dann eigentlich auch nur wieder "nur" Warnings kommen.

Stimmt. Am Anfang sieht man's allerdings besser. V.a. weil die CRef bei mir hellgrau auf weißem Hintergrund ist. Aber ich kann damit leben. Meine Punkte sind eh abgearbeitet.

Ja, hängt vom Editor ab (bzw. dessen "Spracheinstellung"). "Abgearbeitet" ist auch das mit dem fehlenden Trigger? Wenn nein, wäre das m.E. noch wichtig.

Die WAV byte für byte an "hermes/audioServer/<siteId>/playBytes/<beliebige SessionID>" schicken. Hätte mir gedacht, wir nehmen playWAV dafür.

playWAV wäre schon das Mittel der Wahl, ich habe es nur bisher nicht geschafft, mein Handy per Ton bimmeln zu lassen, Sprache klappt 1a...
(Und einen superhypermodernen Pi (im Vergleich zu meinem Altbestand) wollte ich erst mal noch ins Netz hängen ).

[drhirn]

Der "nichts"-Test, um das abschließend zu klären, sähe dann noch z.B. so aus:

Code Auswählen Erweitern

timerLimits=90,,,,xEs sollten dann eigentlich auch nur wieder "nur" Warnings kommen.

Jup, wäre wohl sinnvoller gewesen.
Da bekomme ich keine Warning/Errors, etc. Funktioniert einfach.

"Abgearbeitet" ist auch das mit dem fehlenden Trigger? Wenn nein, wäre das m.E. noch wichtig.

Du meinst den bei Shortcuts + Perl-Code? Das geht nämlich.

[Beta-User]

OK, dann gilt also numerisch "undef==0". Mal sehen, wann da wer drüberstolpert...

Anbei eine "cleanup" Version, bei der dann "deine" offenen Punkte raus sind. "Eigentlich" ist am Code nichts geändert, aber wie immer: Fehler sind nicht komplett ausgeschlossen...

Die Limits habe ich mal auf "(91, 9*MINUTESECONDS, HOURSECONDS, 1.5*HOURSECONDS, HOURSECONDS )" gesetzt. Falls das Gefallen findet, würde ich vorschlagen, das als default-Werte dann auch in der cref zu nennen, dann findet man es auch wieder und es ist besser klar, dass die FHEM-Zeitkonstanten verfügbar sind.

[drhirn]

Gut, gut, gut!
Die Version ist jetzt die Version 0.4.8 und auch die Default-Branch. Ich ernenne die Version hiermit zu stable.

[drhirn]

Mein Plan ist wie folgt:

Wir testen noch SetNumeric durch. Das ist der letzte Intent, der noch offen ist. Klappt da alles (wovon ich derzeit ausgehe), geb ich eine Runde Bier aus und mach eine Version 1.0.0. Mit der wird dann die Präsentation gemacht. Was uns aber nicht daran hindern soll, an einer 1.0.1 weiter zu arbeiten.

[Beta-User]

...das mit dem Bier klingt gut!

1.0.0 ist aber ein "gewaltiger Schritt", lirc ist ja auch erst bei 0.10.0rc1 , und ASC ist auch noch bei 0.10.0....

Wie auch immer: diese Version ist m.E. jedenfalls die, mit der wir für den 29. ganz gut "unterwegs" sein sollten.

Ob ihr's glaubt oder nicht, ich habe (erst) jetzt dann auch mal die Zeit gefunden, den "RHASSPY & FHEM"-Thread nochmal zu durchstöbern. Hier mal meine (um eigene Schlagworte ergänzte) Stichwortliste - ist eine wilde Mischung aus Ideen bzw. potentiellen ToDo's, offenen Enden und Fragen, teils vermutlich auch für den 29. nicht uninteressant:

- SetOnOff: Bestätigung welches Gerät wie geschaltet wurde (derzeit: User-Code bei rhasspyMapping)
- Talk2FHEM, Jabber, Telegram: Schnittstellen, Zusammenspiel (+msg-Kommando?)
- Wikipedia, google und andere "offene" Anfragen an die Weiten des Inet (Vorfrage: wie "trainierte" Stichworte generieren?)
- Bring! und andere Einkaufslisten
- Ansagen für ausstehende Timer
- zufällige Ansagen oder Rückmeldungen (oder: mal was anderes statt "OK")
- CustomIntents: Code in eigene .pm verlagern?

Gerade der letzte Punkt wäre auch im Rahmen der Idee interessant, das ganze "Beiwerk" auch längerfristig via contrib anzubieten. Würde aber vorschlagen, entsprechenden Code dann auch zu packagen. (@Mitleser: keine Sorge, das ist nicht allzu schwierig! Ordentlich formatierter Code, der mal perlcritic.com gesehen hat, wäre aber als Voraussetzung wünschenswert...)

[drhirn]

...das mit dem Bier klingt gut!

Haben wir uns auch verdient

1.0.0 ist aber ein "gewaltiger Schritt", lirc ist ja auch erst bei 0.10.0rc1 , und ASC ist auch noch bei 0.10.0....

Das sind ja auch alles Feiglinge

Meine Logik ist eigentlich die:
x.0.0 - Große Stable-Versionen (Änderung der Stelle bringt sehr wahrscheinlich Inkompatibilitäten mir vorigen Versionen)
x.x.0 - Kleine Stable-Versionen (Kleine bis keine Inkompatibilitäten)
x.x.x - Bug-Fix-Versionen (Keine Inkompatibilitäten)
x.x.x.x - Entwicklungs-Versionen

Hab ich zwar noch nie so durchgezogen, würde aber Sinn machen

- SetOnOff: Bestätigung welches Gerät wie geschaltet wurde (derzeit: User-Code bei rhasspyMapping)

Würde ich fast so lassen. Dann hat der User die Wahl. Oder ein zusätzliches Attribut/Mapping beim Device.

- Talk2FHEM, Jabber, Telegram: Schnittstellen, Zusammenspiel (+msg-Kommando?)

Hatte ich bei Snips in Kombination mit Talk2FHEM. Aber leider die Devices gelöscht. Hab aber einfach alles, was an hermes/asr/textCaptured ankam, zu T2F geschickt.
Sehe ich aber nicht als Rhasspy-Thema.

- Wikipedia, google und andere "offene" Anfragen an die Weiten des Inet (Vorfrage: wie "trainierte" Stichworte generieren?)
- Bring! und andere Einkaufslisten

Nein! Hat níchts mit FHEM zu tun. Wie schon mal erwähnt, ist da ein Rhasspy-"Modul" der bessere Weg. Weil dann auch Nicht-FHEM-User davon profitieren könnten.

- Ansagen für ausstehende Timer

Hohe Prio! "Wie lange noch" geht mir mächtig ab.

- zufällige Ansagen oder Rückmeldungen (oder: mal was anderes statt "OK")

Täte mir auch gefallen. Geht aber theoretisch eh schon mittels "response" und "rand()"

- CustomIntents: Code in eigene .pm verlagern?

Gerade der letzte Punkt wäre auch im Rahmen der Idee interessant, das ganze "Beiwerk" auch längerfristig via contrib anzubieten.

Dafür