Modulentwicklung für Rhasspy Sprachassistent

[drhirn]

aber der Link auf die "Initialize"-Funktion muss bei anderem Namen angepaßt werden.

Ich find das nicht. Wo genau?

Anders gefragt: Was stört dich am Namen?

Hehe, überhaupt nichts. Ich wollte es nur wissen.

[Beta-User]

Ich find das nicht. Wo genau?

Code Auswählen Erweitern

sub ::RHASSPY_Demo_Utils_Initialize { goto &Initialize }
Um das myUtils-"Modul" zu registrieren, muss fhem.pl eine Initialize-Funktion haben, die eben genau dem Dateinamens-Schema entspricht (ohne den Zahlenpräfix); das ist genau gleich wie bei allen anderen Modulen und auch so im Wiki zu 99_myUtils.pm zu finden. Hier ist nur die Besonderheit, dass wir wegen des packages erst noch nach $main verweisen müssen => daher die beiden Doppelpunkte .

[drhirn]

Ahhh, verstehe. Danke für die Aufklärung!

Und was müssten wir tun, wenn wir das in einen Unterordner legen möchten? Nach opt/fhem/FHEM/rhasspy-intents z.B.?

[drhirn]

Und kannst du mir bitte noch timerTrigger erklären? V.a., wie ich den Trigger dann nutzen könnte?

[Beta-User]

Und was müssten wir tun, wenn wir das in einen Unterordner legen möchten? Nach opt/fhem/FHEM/rhasspy-intents z.B.?

Hmm, also:
- afaik kann man nicht so einfach eine Sonderbehandlung für irgendwas in einem Unterverzeichnis haben, fhem.pl ist dafür nicht ausgelegt.
- man könnte sowas vielleicht via RHASSPY nachladen, aber:

Warum sollte man?

Im praktischen Leben ist es so:
- User will "normale" Funktionen haben. Dann macht er "normale" myUtils (wie gehabt).
- User will mehr. Dann lädt er sich die "Muster-package-myUtils" (für RHASSPY) aus "contrib" runter (dort aus dem angedachten RHASSPY-Verzeichnis?) und platziert die mittels svn_Get... an der richtigen Stelle (gleich mit "laden"-Kommando). Danach kann er eine Kopie ziehen (save as), muss dann eben den Initialize-Verweis anpassen und rauswerfen oder umbenennen, was er nicht braucht (oder die Demo wieder löschen).

Für eine Unterstruktur unterhalb ./FHEM sehe ich jedenfalls im Moment keinen Bedarf.
Oder übersehe ich mal wieder was?

Und kannst du mir bitte noch timerTrigger erklären? V.a., wie ich den Trigger dann nutzen könnte?

Die Kurzfassung ist in der commandref drin. Hintergrund ist folgender:
- bisher war es beim "einfachen speak" nach Ablauf des Timer so, dass man ein oder zwei Events (am RHASSPY-Device) hatte, nämlich den vom "speak" und das "Reading löschen" (?).
- jetzt ist es uU. ein eher allgemeines "playWav", und das Reading wird erst am Ende gelöscht.
- mit timerTrigger kann man jetzt bei Ablauf des (bei Wiederholung: ersten) Timers ein genau umrissenes Event auslösen. Einzige Einschränkung: es muss ein "label" für den Timer geben.

Darauf kann dann ein beliebiger Eventhandler (z.B. notify) hören, und dann wieder beliebige FHEM- oder Perl-Befehle auslösen. Beispiel: Weckautomation mit Aufdimmen des Lichts, Einschalten der Stereoanlage, Einstellen eines bestimmten Senders, ...

(Es wäre ggf. gut, wenn du in solchen Fällen einfach mal "nachbaust", was jeweils in der cref kurz angerissen ist. Dann sehen wir auch gleich, ob es a) sachlich korrekt ist (und nicht nur auf dem System paßt, auf dem ich es getestet hatte), und b) halbwegs verständlich...)

[drhirn]

Für eine Unterstruktur unterhalb ./FHEM sehe ich jedenfalls im Moment keinen Bedarf.
Oder übersehe ich mal wieder was?

Nun, es wäre schon irgendwie cool, wenn User A ein File mit einem Intent zur Verfügung stellt. Und User B die Datei dann einfach nur in den Ordner kopieren muss und schon den Intent zur Verfügung hat.

(Es wäre ggf. gut, wenn du in solchen Fällen einfach mal "nachbaust", was jeweils in der cref kurz angerissen ist. Dann sehen wir auch gleich, ob es a) sachlich korrekt ist (und nicht nur auf dem System paßt, auf dem ich es getestet hatte), und b) halbwegs verständlich...)

Keine Sorge, das mach ich eh immer. Aber manchmal weiß ich halt nicht, wie ich was nachbauen muss .

[Beta-User]

Nun, es wäre schon irgendwie cool, wenn User A ein File mit einem Intent zur Verfügung stellt. Und User B die Datei dann einfach nur in den Ordner kopieren muss und schon den Intent zur Verfügung hat.

Genauso könnte das doch laufen; nur dass eben direkt in ./FHEM mehrere 99_RHASSPY_.*Utils.pm vorhanden sein können, eine jede ganz hübsch und ordentlich mit einer Beschreibung des Intents, des korrekten Funktionsaufrufs, eines passenden sentence-Schnippsels und der Funktion in der zugehörigen cref...
(Das machen wir @attrTemplate in "speziellen Fällen" ähnlich: Wenn der User was passendes hat/haben will, wird (nur) der zugehörige Code runtergeladen).

Keine Sorge, das mach ich eh immer. Aber manchmal weiß ich halt nicht, wie ich was nachbauen muss .

Schon klar, dass das nicht immer einfach zu verstehen ist, was ich da so hinpinsle... Bei timerTrigger sollte es aber einfach sein: Den key in "tweaks" packen mit dem Wert "default", und dann einfach einen (kurzen) belabelten Timer anlegen. Fertig, bzw. bereit, das Ergebnis im Event-Monitor zu sehen .

[drhirn]

Genauso könnte das doch laufen; nur dass eben direkt in ./FHEM mehrere 99_RHASSPY_.*Utils.pm vorhanden sein können

Ich bin ein Fan von Unterordnern zwecks Aufgeräumtheit

Schon klar, dass das nicht immer einfach zu verstehen ist, was ich da so hinpinsle...

timerTrigger jetzt trotzdem kapiert. Und frage mich dabei, ob wir nicht einfach standardmäßig ein Event triggern sollen. Spricht was dagegen?

[Beta-User]

Ich bin ein Fan von Unterordnern zwecks Aufgeräumtheit

Kann ich nachvollziehen, aber das framework gibt halt nur die "Ordnung via Benennung" her. Von daher könnte man auch "Utils" und "Demo" umdrehen?
Ansonsten sollte v.a. der Code ordentlich sein, also (mAn.) z.B. auch gepackaged; da wird es vermutlich noch etwas "guidance" für den einen oder anderen brauchen; v.a., was den Import von ggf. genutzten Funktionen angeht (auch sowas häufiges wie ReadingsVal, z.B.).

Und frage mich dabei, ob wir nicht einfach standardmäßig ein Event triggern sollen. Spricht was dagegen?

M.E. nicht, wenn man von der "Gefahr" absieht, dass bei "unbelabelten" Timern vermutlich die Events teils (seitens einiger User) nicht sauber abgegriffen werden (mit .* am Ende).
Ehrlich gesagt war es so, dass mich im Nachhinein etwas wundert, dass vorher scheinbar keiner auf die Idee gekommen ist, Events zu generieren oder abzugreifen, um z.B. Sound-loops anzuschubsen...
Na ja, Rom und so.

Gibts du ein Signal, oder haben wir das jetzt schon beschlossen mit dem immer triggern?

[drhirn]

Kann ich nachvollziehen, aber das framework gibt halt nur die "Ordnung via Benennung" her. Von daher könnte man auch "Utils" und "Demo" umdrehen?

Verstehe. Die Umbenennung wäre praktisch. Dann sind sie wenigstens sortiert.

Gibts du ein Signal, oder haben wir das jetzt schon beschlossen mit dem immer triggern?

Naja, wenn nichts dagegen spricht, können wir das gerne so machen. Ist aber nicht dringend.

[Beta-User]

Deaktivieren ist einfacher wie einbauen...

here you are .

[drhirn]

Sodala, die CRef ist jetzt tippitoppi. Hab sie auch extra noch durch einen HTML-Syntaxchecker laufen lassen. Manoman, waren da Fehler drin

https://github.com/drhirn/fhem-rhasspy/blob/0.4.9/opt/fhem/FHEM/10_RHASSPY.pm

[Beta-User]

Sodala, die CRef ist jetzt tippitoppi. Hab sie auch extra noch durch einen HTML-Syntaxchecker laufen lassen. Manoman, waren da Fehler drin

...einen Logikfehler habe ich in der cref mAn. noch gefunden, yellow sollte wohl F0F000 sein, oder täuschen mich meine Trockenübungsaugen?

(Ansonsten ist es schade, dass die Unterschiede in github hier nicht im Detail angezeigt werden. Ist nicht eben mein Spezialgebiet, und vermutlich könnte ich da noch das eine oder andere lernen für meine anderen "Kunstwerke"... Also falls du mal Muße hast ).

Anbei nochmal ein Zwischenstand, der ggf. auch das Setzen von CT, Saturation, HUE und RGB erlaubt, wenn a) das gDT-mapping sowas hergibt und b) ein passender Wert unter dem entsprechenden Keyword übergeben wird, also "Colortemp" für einen CT-Wert, "Rgb" (oder Color) für einen RGB-Wert im HEX-Format (F0F000) oder Saturation.

Wird ein RGB-Wert übergeben, wird im Moment nicht gerechnet, sondern das (auch) als Helligkeitsangabe verstanden, alles andere ist nummerisch 0-100 zu übermitteln und wird als Prozentangabe zwischen dem verfügbaren Minimal- und Maximalwert verstanden.
Muss erst mal testen, inwieweit das klappt, dann kann es ggf. irgendwann auch mit der Übergabe von "keywords" weitergehen, und im Moment habe ich mir auch keinen Kopf zur Kompabilität mit einer späteren Gruppenfunktion gemacht...

(Diese Version ist in diesem Punkt (Color Intent) vermutlich wieder ziemlich gefährlich, da intensiv "rumgehasht" wird und nichts getestet ist!).

[drhirn]

...einen Logikfehler habe ich in der cref mAn. noch gefunden, yellow sollte wohl F0F000 sein, oder täuschen mich meine Trockenübungsaugen?

Eigentlich ist's #FFFF00. Ich hab da irgend eine Zahl genommen. Aber hast recht, ist natürlich nicht korrekt. Grün war's auch nicht.

(Ansonsten ist es schade, dass die Unterschiede in github hier nicht im Detail angezeigt werden. Ist nicht eben mein Spezialgebiet, und vermutlich könnte ich da noch das eine oder andere lernen für meine anderen "Kunstwerke"... Also falls du mal Muße hast ).

Du meinst so: https://github.com/drhirn/fhem-rhasspy/commit/8746b9ab9bd7fa6bf86386c81d912d8953cd0b24

Über deine Kunstwerke können wir dann gerne mal Reden. Welche wären das? Erinnere mich dann einfach mal daran.

(Diese Version ist in diesem Punkt (Color Intent) vermutlich wieder ziemlich gefährlich, da intensiv "rumgehasht" wird und nichts getestet ist!).

Ich könnte da eine 1.4.10 draus machen. Oder eine 0.5.1? In der 0.4.9 möchte ich jetzt keine großen Veränderungen mehr.

[Beta-User]

bzgl. dieser beiden Punkte:

# Attribute:
- "shortcuts" in "rhasspyShortcuts" umbenennen

Sollte kein Hexenwerk sein, ist aber ein "breaking change" (ich will für die Kleinikgeit nicht unbedingt noch Transfercode schreiben...).

Umsetzen? (0.4.10, s.u.)

# Custom Intents
- Bei Verwendung des Dialouges wenn man keine Antwort spricht, bricht Rhasspy ab. Die voice response "Tut mir leid, da hat etwas zu lange gedauert" wird
   also gar nicht ausgegeben.

Muss ich mir ansehen, bin aber unsicher, ob das nicht ggf. damit zusammenhängt, dass Stille gerne als "nein" interpretiert wird und dafür ein "stiller Abbruch" vorgesehen ist, wenn RHASSPY nicht mehr wartet. (Aber eigentlich nur dann, evtl. ist mir da ein Fehler unterlaufen).
Wenn es eine "silent cancellation" war, sollte das response-Reading leer ('') sein.
=> etwas mehr Info dazu wäre evtl. hilfreich.

Ich könnte da eine 1.4.10 draus machen. Oder eine 0.5.1? In der 0.4.9 möchte ich jetzt keine großen Veränderungen mehr.

1.4.10 ist "steil", 0.4.10 fände ich ok.

Ich _glaube_, dass es nur für die gefählich sein kann, die das aktiv austesten, für alle anderen sollte es keine Probleme bringen, und wenn ich dann die Tage mal an's Testen komme, ist auch besser abschätzbar, wie groß das Gefahrenpotential effektiv ist (ich hoffe: 0  ).
Von daher wäre es mir am liebsten, wir könnten die experiementellen Teile einfach in den "rolling" Code integriert lassen (und/oder notfalls den erweiterten Code auf möglichst einfache Weise deaktivieren). Dann ist es für mich einfacher, ggf. erforderliche Bugfixes in den regulären Code-Teilen einzupflegen.
Ich wollte es halt nicht ohne den üblichen Warnhinweis hier posten.

Meine Kunstwerke wären die MySensors-Module, Weekday- und RandomTimer sowie Twilight...

Nachtrag: das via github sichtbare diff ist im Detail leider nicht so aussagekräftig wie im Code-Bereich.