Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

"Eigentlich" sieht das ganz gut aus...

Es wird ein Hash übergeben, ganz so, wie es sein sollte. Vermutlich solltest du Dumper dazwischenklemmen, oder eben eine for-loop über die keys laufen lassen, um was sinnvolles angezeigt zu bekommen. Aber das eigentliche Ziel war ja, $data genauso verwenden zu können wie innerhalb des Moduls und dann auf beliebige Keys zugreifen zu können (die wir ja kennen), ohne die einzeln als Parameter vorab abzurufen.
In myUtils muss man dann nur den Umweg von NAME auf $defs{NAME} nehmen, also eher so:

Code Auswählen Erweitern

Calculation=rhasspyCalc(NAME,DATA)

Code Auswählen Erweitern


sub rhasspyCalc{
    my $name = shift // return;
    my $data = shift // return;
    my $hash = $defs{$name} // return;

    return "Calc data keys ares: ". join q{, }, keys %{$data};
}
Das wäre noch zu checken.

[drhirn]

Also deine Version bringt ähnliches:

Code Auswählen Erweitern


2021.04.15 18:13:14.255 5: handleCustomIntent called with Calculation key
2021.04.15 18:13:14.255 5: Calling sub:  rhasspyCalc( "Rhasspy",HASH(0x55e6d5487298) )
2021.04.15 18:13:14.255 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at (eval 580) line 1.
2021.04.15 18:13:14.255 3: eval:  rhasspyCalc( "Rhasspy",HASH(0x55e6d5487298) )
2021.04.15 18:13:14.255 1: ERROR evaluating  rhasspyCalc( "Rhasspy",HASH(0x55e6d5487298) ) : Undefined subroutine &main::HASH called at (eval 580) line 1.

2021.04.15 18:13:14.256 5: Response is: Undefined subroutine &main::HASH called at (eval 580) line 1.


[drhirn]

Was aber z.B. funktioniert ist:

Code Auswählen Erweitern


[de.fhem:Calculation]
Was (macht|ergibt) (0..10){Number1} ([plus|und]{Operator:plus}|[minus|weniger]{Operator:minus}|[mal|multipliziert mit]{Operator:mul}|[durch|geteilt durch|dividiert durch]{Operator:div}) (0..10){Number2}


Code Auswählen Erweitern

Calculation=rhasspyCalc(Number1,Number2,Operator)

Code Auswählen Erweitern


sub rhasspyCalc{
  my $val1 = shift // return;
  my $val2 = shift // return;
  my $op = shift // return;

  my $response = "Dafür muss ich nochmal in die Nachhilfe";

  if ($op eq "plus") {
    $response = "Das Ergebnis ist " . ($val1 + $val2);
  }

  return $response;
}


[Beta-User]

Was ein Sch...

Also: Das Problem ist, dass wir mit der absichernden Variante der Code-Ausführung eigentlich nur Text übergeben können. Alles andere führt zu diesen seltsamen Effekten, und im Moment habe ich auch keine Idee, wie man aus dem HASH-String wieder an die Daten kommen könnte.
Von daher schlage ich vor, DATA einfach JSON-encoded zu übergeben, dann muss man halt wieder auspacken... (Eventuell sollte man dazu noch ein Code-Schnipsel in die cref packen, reicht aber später irgendwann noch).

Zumindest auf den ersten Blick sieht das ganz ok aus, was die Fassung in der Anlage macht. Da ist mir auch noch ein "undefined"-Warning vor die Flinte gelaufen.

Nachdem ich jetzt auch das erste Mal mit CustomIntents rumgespielt habe: Eigentlich sollte man zwei Werte zurückliefern können: Device und $response. Oder täuscht mich das?

[drhirn]

Hmm, laß gut sein. Ich find das eigentlich nicht schlecht, wenn man einfach nur die Tags aus dem Sentence weiterreichen kann. Das ist perfekt für schnelle Workarounds und Anfänger. Leute, die einen ausgiebigeren Intent brauchen, sollen ein "Modul für's Modul" schreiben. Da haben dann alle was davon.

Bisher war's so, dass einfach nur eine Response zurückgeliefert wurde. Das Device brauchen wir ja nicht, oder? Höchstens eventuell für einen Trigger, hab ich aber nicht ausprobiert.

[Beta-User]

Hmm, laß gut sein.

Bald...

Ich find das eigentlich nicht schlecht, wenn man einfach nur die Tags aus dem Sentence weiterreichen kann. Das ist perfekt für schnelle Workarounds und Anfänger.

Ja, und diese Option MUSS m.E. auch bleiben, genauso wie die "einfache" Interpretation eines zurückgelieferten SCALARS als $response (und trigger auf die RHASSPY-Instanz).

Leute, die einen ausgiebigeren Intent brauchen, sollen ein "Modul für's Modul" schreiben. Da haben dann alle was davon.

Bisher war's so, dass einfach nur eine Response zurückgeliefert wurde. Das Device brauchen wir ja nicht, oder? Höchstens eventuell für einen Trigger, hab ich aber nicht ausprobiert.

Bei DATA geht es genau um das Thema "Modul für's Modul": Wir brauchen eine Art "API", die vollen Zugriff gibt auf alle Funktionen, die alle anderen internen Funktionen auch haben. Neben $hash (Umweg: NAME) und $data (der Umweg über toJSON ist implementiert und funktioniert!) (und evtl. Room?) sind das eben auch in der Rückgabe:
- $response mit Möglichkeit, den Dialog offenzuhalten (!)
- Liste der Devices, die zu triggern sind.
Das richtet sich in der Tat eher an erfahrenere Leute, aber wenn man spannende weitere features anflanschen will, braucht man m.E. genau das.

Das über einen separaten anderen Intent anzuflanschen, finde ich nicht notwendig, wir müssen jetzt eigentlich nur noch den Rückgabewert darauf prüfen, ob er ein ARRAY-REF ist (wenn ja, ist (z.B.) ${$response}[0] die kommaseparierte Liste der Geräte und ${$response}[1] die $response, die ihrerseits dann weitergereicht wird, was ggf. (wenn das ein HASH-REF ist) dazu führt, dass der Dialog offen bleibt. In dem Fall sollte dann noch die Option bestehen, den timeout vorzugeben, bis wann das so sein soll (=> ${$response}[2]).

Wenn wir das haben, ist m.E. "der Fisch geputzt" (an der Stelle), und du darfst wieder eine "Unternummer" weiterzählen .

[drhirn]

Wichtiger wäre eigentlich, darüber nachzudenken, wie wir mit Kommazahlen umgehen. Rhasspy kann's nämlich nicht. Zumindest weiß ich nicht, wie.

Ich kann nur so einen Satz bauen:

Code Auswählen Erweitern

stelle die Heizung{Device} auf (0..100){Value_0}(komma)(0..10){Value_1} grad{Unit}

Das hilft uns aber nicht weiter. Wie könnten wir da tun?

synesthesiam hat im Rhasspy-Forum eine Lösung geliefert: Custom-Converter

https://community.rhasspy.org/t/using-real-numbers-in-sentences-0-5-22-point-5-etc/2501/7

[Beta-User]

  das geht ja mit großen Schritten auf's WE zu!

Dann (hoffentlich) zum Abschluss noch die beiden "fehlenden" Themen, von denen ich hoffe, sie ohne schädliche Nebenwirkungen erschlagen zu haben:
- Rückgabe eines ARRAYs für CustomIntent-Spezialisten (komplett ungetestet, dafür dokumentiert  ) und
- für den gDT-Type "media" wird jetzt nur noch gemappt, was auch an settern vorhanden ist. Ist grob angetestet, und sollte zum einen die gröbsten Unsauberkeiten beseitigen, die durch das vormalige generöse mapping entstanden waren, und zum anderen eine Demo dafür sein, wie man das prinzipiell lösen kann, nur zu mappen, was auch vorhanden ist. Sollte hilfreich sein für weitere gDT-Mapping-Typen, und theoretisch ist die Methode (wohl aber der aktuelle Code) nicht auf setter beschränkt. Allerdings würde ich bzgl. Abfragen (typische Readings) ggf. auch einfach mal warten, ob es da überhaupt Bedarf gibt bzw. welchen. Habe Sorge, dass zu viele Mappings zulasten der Trennschärfe gehen.

Wenn wir keine gröberen Schnitzer mehr finden, wäre das dann m.E. tauglich für 0.5.0 und den Gang Richtung svn, und es spräche dann auch gar nichts mehr dagegen, die dDT-Vorgehensweise auch in der Darstellung zum Default zu machen.

Apropos Darstellung:
Will eigentlich nicht zu viel Energie in das .md legen, aber auf die Schnelle ist mir neben der "Kleinigkeit", dass gDT irgendwo im Nachklapp erwähnt wird und diversen anderen Kleinigkeiten aufgefallen, dass "E.g. if currentVal is 23 C, part=1 results" sachlich nicht stimmt und eventuell manche noch offene Punkte abgehakt werden könnten  .

[drhirn]

Nachdem ich ja kein Custom-Intent Spezialist bin, magst du ein kurzes Beispiel mit $data und der Rückgabe eines Arrays posten? V.a., was man dann mit dem Array machen könnte?

gDT "media" habe ich jetzt gerade keine Ahnung, wie ich das testen könnte. Da muss ich wohl ein sehr ausführliches Dummy-Device anlegen. Oder einfach mal ein paar Set-Befehle aus meinem vorhandenen löschen? Hmm...

Da ich gDT für den 29. jetzt nicht ausführlich getestet habe, habe ich sie absichtlich noch nicht in der Doku erwähnt. Das war für mich von Anfang an ein Feature, auf dem ich eigentlich die Version 2 aufbauen wollte. Da's aber schon sehr gut funktioniert, wird's wohl eine kleiner Versionsnummer. Nichts desto trotz bin ich dafür, dass wir die Kaum-Erwähnung jetzt vorläufig mal so lassen.

Danke für den Hinweis mit dem Fehler in der Doku! Die ist halt auch noch nicht fertig. Irgend jemand hat mich ja mit Custom Intents abgelenkt

[Beta-User]

Nachdem ich ja kein Custom-Intent Spezialist bin, magst du ein kurzes Beispiel mit $data und der Rückgabe eines Arrays posten? V.a., was man dann mit dem Array machen könnte?

Mache ich bei Gelegenheit - das Problem ist, dass ich das selbst kaum verstehe , und vor weiteren Tests erst mal die Schnittstelle vom Konzept her "stehen" musste - irgendwo muss man ja anfangen (ähnlich wie mit dem gDT-Ding).
Für's erste sollte es reichen, wenn es mit den alten Intents fehlerfrei weiter läuft, der Rest kommt dann schon.

gDT "media" habe ich jetzt gerade keine Ahnung, wie ich das testen könnte. Da muss ich wohl ein sehr ausführliches Dummy-Device anlegen. Oder einfach mal ein paar Set-Befehle aus meinem vorhandenen löschen? Hmm...

Ich werde das über's WE mit meinen Echt-Geräten testen, mit dummy ist es bereits vor-getestet. Weiß nur noch nicht, wann ich dazu komme, daher ist das vorläufig eher zur Abrundung gedacht und für die, die ggf. grade mittesten. Man sieht ja direkt im Hash, ob alles ok ist.
Vermutlich werde ich dann noch "light" mit rgb,ct und hue (+set?) ergänzen. Wenn ich die Zusammenhänge richtig deute, braucht man für ein "Color"-mapping zusätzlich diese setter, und dann noch die Angabe in rhasspyColor. Eventuell könnte man überlegen, ob man eine Art "colorDefault" in "tweaks" hinterlegen kann, das dann (in welcher Reihenfolge, wenn es z.B. hue und rgb gibt?) greift, wenn ein "light" z.B. eines/beides kann?
EDIT: Zumindest meine dummy-Devices deuten darauf hin, dass es ohne geht; die Frage wäre dann also eher, ob man diesen Teil ggf. irgendwie generischer lösen kann/will. Dazu fehlt mir aber noch eine Idee...

Da ich gDT für den 29. jetzt nicht ausführlich getestet habe, habe ich sie absichtlich noch nicht in der Doku erwähnt. Das war für mich von Anfang an ein Feature, auf dem ich eigentlich die Version 2 aufbauen wollte. Da's aber schon sehr gut funktioniert, wird's wohl eine kleiner Versionsnummer. Nichts desto trotz bin ich dafür, dass wir die Kaum-Erwähnung jetzt vorläufig mal so lassen.

Da es funktioniert (vorbehaltich der Tests zu "media"), würde ich empfehlen, das vorzuziehen. Wer schon irgendwas in die Richtung bei sich in der config hat, wird sich sonst über eine umständliche Einzelkonfiguration vermutlich spätestens im Nachhinein wundern. Mir ist schon klar, dass du dich damit noch nicht so wohlfühlst, weil es (scheinbar) was neues ist und du mit der "zu Fuß"-Methode halt gut vertraut bist, aber im Ergebnis kommt 1:1 dasselbe raus (ggf. halt mit demselben Fehler, wie wenn man ein falsches manuelles Mapping macht, wie im Fall von dem FS20-Dimmer). Ist aber m.E. eine reine Gewohnheitsfrage, und der Stand ist soweit gediehen, dass m.E. eigentlich nichts schiefgehen kann.
(Die Grenzen des Verfahrens kann und darf man aber zeigen! Damit hat auch die "alte" Methode weiter ihre volle Berechtigung!)

Danke für den Hinweis mit dem Fehler in der Doku! Die ist halt auch noch nicht fertig. Irgend jemand hat mich ja mit Custom Intents abgelenkt

...alles zu seiner Zeit. Ist mir halt aufgefallen.

[drhirn]

Was ich bzgl. gDT noch nicht ausgiebig getestet habe ist, was passiert, wenn man ein gDT gesetzt hat, aber auch ein z.B. rhasspyColors haben möchte. Oder die gDT Setter mit rhasspyMapping überschreiben möchte. Also, wenn ich ein Device habe, dass zwar keinen "rhasspyName" und "rhasspyRoom" hat, dafür aber ein "rhasspyMapping".

Was ist dir denn an der MD noch aufgefallen?

[drhirn]

gDT und "blind": Da erscheinen mir "pct" und "dim" als nicht passend. Ich weiß leider nicht, wie ein Rollladen-Device in der Praxis aussieht. Hast du sowas? Wird da "state" gesetzt? Und wenn ja, müssen wir das wohl anders abhandeln.

[Beta-User]

Was ich bzgl. gDT noch nicht ausgiebig getestet habe ist, was passiert, wenn man ein gDT gesetzt hat, aber auch ein z.B. rhasspyColors haben möchte. Oder die gDT Setter mit rhasspyMapping überschreiben möchte. Also, wenn ich ein Device habe, dass zwar keinen "rhasspyName" und "rhasspyRoom" hat, dafür aber ein "rhasspyMapping".

Der Vergleich zwischen den Ergebnissen aus gDT und rhasspy-Attribut erfolgt "pro Attribut". Ist also gDT gesetzt, aber kein rhasspyName, wird ggf. der alexaname etc. verwendet, selbst wenn ein rhasspyMapping (z.B. für SetNumeric) da ist (letzteres verdrängt dann nur die mappings, die aber dann komplett).
Andersrum kannst du bei einem funktionierenden "light" (dimmer-) Device z.B. dann nur "rhasspyColors" setzen und darüber die Farben steuern (so jedenfalls die Vermutung aus dem Code).

Kurz: du siehst IMMER das Gesamtmapping im Hash, und wie einleitend in der cref geschrieben: die speziellere Angabe verdrängt immer die Allgemeine (da wo sie gilt).

Was ist dir denn an der MD noch aufgefallen?

Wenn ich dazu komme, schaue ich drüber und mache das dann per pull-request (sowas will ja auch geübt sein .)

gDT und "blind": Da erscheinen mir "pct" und "dim" als nicht passend. Ich weiß leider nicht, wie ein Rollladen-Device in der Praxis aussieht. Hast du sowas? Wird da "state" gesetzt? Und wenn ja, müssen wir das wohl anders abhandeln.

Habe ich und das ist bei mir auch produktiv so ok (jedenfalls, soweit ich das bisher getestet habe (v.a. mit SetNumericGroup)). Eingesetzte TYPE sind CUL_HM (Bl-PBU, nur Rollläden) und ZWave (Fibaro 222 und 223 an Jalousien, also drehbare Lamellen; der "Dreh"-Teil fehlt noch...). Bei den ZWave ist es - so oder so - etwas speziell, weil man da etwas nachhelfen muss, damit man "dim" auch als Reading bekommt. Ist aber häufig vorhanden, v.a. bei denen, die auch AutoShuttersControl nutzen.
Wenn nicht, geht halt die GetNumeric-Anfrage schief, aber der Rest paßt...

[Beta-User]

So, nachdem jetzt erste Tests durch sind, und mir dann auch beim Gegenlesen der .md noch Verbesserungsmöglichkeiten aufgefallen sind, noch ein paar kleinere Änderungen und Ergänzungen. Feine Sache, das...

[drhirn]

Danke für die Änderungen an der .md!

Was ist eine feine Sache?