Modulentwicklung für Rhasspy Sprachassistent

[drhirn]

Kann sein, dass das durch den Kommentar kommt, das scheint das ? : durcheinanderzubringen. (to be verified).
Habe den mal verschoben.

Das war's nicht

Aber die Sache mit dem Status funktioniert. Danke!

[Beta-User]

Ist auch mir zu kompliziert. Ich kann's nicht mal mehr dokumentieren.

"mehr" kommt mir deplaziert vor: Das war mal bei Komplexität 55 oder so, jetzt sind wir "nur noch" bei 41 .

Es sind auch mittlerweile unnötige Sachen dabei. Das "map=percent" im Mapping ist z.B. eigentlich überflüssig. Da reicht auch ein "{Unit:percent}" im Rhasspy-Satz.

Muss ich mir mal ansehen, aber m.E. müßte das beides sowieso schon jetzt über die (vorgeschaltete) Mapping-Analyse sowieso auf denselben Pfad genagelt worden sein. Grundsächtlich würde ich aber sagen:
Alte Zöpfe könnten wir abschneiden, wer jetzt einsteigen will, sollte lieber darauf "getrimmt" werden, "neuen" Input zu liefern. Um dazu aber eine halbwegs valide Richtung für mein Bauchgefühl zu haben, muss ich damit noch ein wenig rumspielen. Von daher steht z.B. der "Taimer" auf der Agenda: Da gibt es ein {min} {sec} - Beispiel in dem "in depth"-Video, in dem auch "halb" vorkommt; das hat es mir angetan...

Vielleicht sollten wir das einfach bei Gelegenheit komplett neu schreiben? Oder auch in mehrere Intents teilen?

Bin da unschlüssig und glaube, dass der Code jetzt soweit reduziert ist, dass man das lassen kann (bzw. sollte). Wenn das Device mal identifiziert ist, laufen - soweit ich das beurteilen kann - alle Zweige ordentlich durch, und man kann dasselbe Anliegen auf angenehm flexible Weise formulieren. Wenn es damit keine Probleme gibt, sehe ich keinen Änderungsbedarf.

Doku: $OnOffValue hätte mich noch interessiert, und ggf. sollte man {volUp} etc. auch in eine Rhasspy-Variable legen? (kann aber auch falsch sein...)

Das war's nicht

Wenn man sich das kritisch ansieht, wird auch klar, warum... Da sollte eigentlich einer Variablen ein Wert zugewiesen werden, aber die Variable fehlte...

Aber die Sache mit dem Status funktioniert. Danke!

Wenigstens etwas .

[drhirn]

"mehr" kommt mir deplaziert vor: Das war mal bei Komplexität 55 oder so, jetzt sind wir "nur noch" bei 41 .

Ich rede ja nur von mir, nicht von PerlCritic

Grundsächtlich würde ich aber sagen: Alte Zöpfe könnten wir abschneiden, wer jetzt einsteigen will, sollte lieber darauf "getrimmt" werden, "neuen" Input zu liefern.

Meine Rede! Auch wenn das Jens wahrscheinlich gar nicht gerne hört

Von daher steht z.B. der "Taimer" auf der Agenda: Da gibt es ein {min} {sec} - Beispiel in dem "in depth"-Video, in dem auch "halb" vorkommt; das hat es mir angetan...

Welches Video?

Doku: $OnOffValue hätte mich noch interessiert, und ggf. sollte man {volUp} etc. auch in eine Rhasspy-Variable legen? (kann aber auch falsch sein...)

Verstehe leider nicht, was du meinst.

[drhirn]

Wenn man sich das kritisch ansieht, wird auch klar, warum... Da sollte eigentlich einer Variablen ein Wert zugewiesen werden, aber die Variable fehlte...

Jeeeetzt verstehe ich, was der Code macht. Ich wollte dich schon bitten, mir den Teil zu erklären.

[Beta-User]

Jeeeetzt verstehe ich, was der Code macht. Ich wollte dich schon bitten, mir den Teil zu erklären.

"use warnings;" hat schon was für sich...

Ich rede ja nur von mir, nicht von PerlCritic

Na ja, vielleicht vergleichst du die 0.2.0-Variante mal mit der jetzigen... Imo war die alte "totaler Kauderwelsch", bei der jetzigen habe zumindest ich die Illussion, dass es stringent von oben nach unten geht und halbwegs erkennbar ist, was welcher Schritt macht. Wenn man es weiter eindampfen wollte, müßte man halt immer relativ viele Variablen übergeben, ich _glaube nicht_, dass das übersichtlicher wäre.


Meine Rede! Auch wenn das Jens wahrscheinlich gar nicht gerne hört

Muss er sich selbst äußern. Für den Moment sollte alles noch 100% kompatibel sein (abgesehen evtl. von dem CustomIntent-Thema, das ggf. kleine Anpassungen erfordert). Aber auch das mit dem map=percent macht m.E. Sinn, es ist nur eine etwas andere Schreibweise für das, was homebridgeMapping in >90% der vergleichbaren Fälle mit "factor" macht. Das darf von mir aus gerne bleiben, vermutlich ist das sogar hilfreich, wenn man "255"-er brightness-Werte hat. (Soweit bin ich noch nicht).

Welches Video?

Es gibt 3 sehr gute Videos zum Ganzen:
Gemeint gewesen war das hier: https://www.youtube.com/watch?v=sWVl0ZoXZEo (das mit dem Timer-Code werde ich mir mal ansehen, da muss ich vermutlich selbst das eine oder andere austesten)
Eine super Einführung zu Rhasspy an sich finde ich ist: https://www.youtube.com/watch?v=IsAlz76PXJQ

Und dann gab es da noch was auf Französisch zu Satelliten:
https://www.youtube.com/watch?v=oTYpTYo2re8

Verstehe leider nicht, was du meinst.

a) Du musst da irgendwo eine Variable/einen slot definiert haben. In meinen Tests konnte Rhasspy das nicht aus der getOnOff.ini auflösen:

Code Auswählen Erweitern

[de.fhem:GetOnOff]
ist [der|die|das] $de.fhem.Device{Device} [$de.fhem.Room{Room}] $OnOffValue{Status}b) beim 2. Teil war ich mir auch noch nicht sicher...

[drhirn]

Ah, das ist ein Slot, den ich schon ewig mit mir rum schleppe:

Code Auswählen Erweitern


(an|einschalten|ein|anschalten|aktiviere|aktivieren|anmachen|schließe|schließen|runter|zu|raus|ausfahren|rausfahren|läuft|rennt):an
(aus|ausschalten|ab|abschalten|deaktiviere|deaktivieren|ausmachen|öffne|öffnen|rauf|auf|rauf|rein|einfahren|reinfahren):aus


Den sollte ich vielleicht aus den Sätzen im GitHub rausnehmen

[drhirn]

Danke für die Videos. Kannte ich nicht.

Das mit Timer sollte einfach zu lösen sein. Gehe ich dann mal an.

[Beta-User]

Ähm, entfernen finde nicht die beste Lösung, früher oder später wird das ganze eh' etwas komplex, von daher schadet es nicht, sowas mal von Hand anzulegen...

Betr. Slots: "updateSlots" ruft jetzt (bei Hash-Nutzung) ja intern als erstes den Hash-update auf; eigentlich wäre es m.E. sinnvoll, da auch gleich den Trainingsaufruf mit reinzuknödeln.

Wenn das zutrifft, würde ich vorschlagen, "reinit" nach "update" umzubenennen und dann dort nur noch zwei Optionen anzubieten: language und slots.
Damit wäre die Userführung klarer: Hat man die Language-file angefasst, macht man dort ein update, damit das Modul das weiß, hat man an den FHEM-Geräten was geändert, muss man die slots updaten. That's all, den ganzen Rest drumrum braucht man nicht...
(Oder übersehe ich mal wieder was?)

Wenn meine Tests mit dem gDT über's WE (?) erfolgreich sind, und niemand sonst was Gegenteiliges berichtet, könnten wir Hash zur Pflicht machen, dann sollte der Code auch an der einen oder anderen Stelle wieder einfacher werden?

Timer ist fertig, aber noch nicht getestet, Code anbei, sentences.ini:

Code Auswählen Erweitern

[SetTimer]
two_to_nine = (zwei:2 | drei:3 | vier:4 | fünf:5 | sechs:6 | sieben:7 | acht:8 | neun:9)
one_to_nine = (ein:1 | <two_to_nine>)
teens = (zehn:10 | elf:11 | zwölf:12 | dreizehn:13 | vierzehn:14 | fünfzehn:15 | sechzehn:16 | siebzehn:17 | achtzehn:18 | neunzehn:19)
tens = (zwanzig:20 | dreissig:30 | vierzig:40 | fünfzig:50)

one_to_fifty_nine = (<one_to_nine> | <teens> | <tens> [<one_to_nine>])
two_to_fifty_nine = (<two_to_nine> | <teens> | <tens> [<one_to_nine>])

hour_half_expr = (<one_to_nine>{hour} und (ein halb){min:30})
hour_expr = (((eine:1){hour}) | ((<one_to_nine>){hour}) | <hour_half_expr>) (stunde | stunden)

minute_half_expr = (<one_to_fifty_nine>{min} [und] ((eine | eine) halb){sec:30})
minute_expr = (((eine:1){min}) | ((<two_to_fifty_nine>){min}) | <minute_half_expr>) (minute | minuten)

second_expr = (((eine:1){sec}) | ((<two_to_fifty_nine>){sec})) (sekunde | sekunden)

time_expr = ((<hour_expr> [[und] <minute_expr>] [[und] <second_expr>]) | (<minute_expr> [[und] <second_expr>]) | <second_expr>)

setze [einen] timer für <time_expr>
EDIT: Kurzformen in der ini statt der langen Variante

[drhirn]

Ähm, entfernen finde nicht die beste Lösung, früher oder später wird das ganze eh' etwas komplex, von daher schadet es nicht, sowas mal von Hand anzulegen...

Ich möchte die Sentences nur als Beispiel-Sammlung haben, die jeder ergänzen kann. Von daher sollten da keine Querverweise kommen.
Und ich möchte mit der Doku auch eigentlich keine Rhasspy-Doku machen. Die gibt's schon. Fokus soll auf dem Modul sein.

Betr. Slots: "updateSlots" ruft jetzt (bei Hash-Nutzung) ja intern als erstes den Hash-update auf; eigentlich wäre es m.E. sinnvoll, da auch gleich den Trainingsaufruf mit reinzuknödeln.

Oft überlegt, immer dagegen entschieden. Wenn du dann viel mit Rhasspy ausprobierst, wird dir auffallen, dass ein Training gleich nach einer Änderung nicht immer sinnvoll ist. Weil du vielleicht davor noch einen Slot ändern musst z.B. Oder du nicht immer warten willst, bis das Training abgeschlossen ist. Das kann unter Umständen nämlich ganz schön lange dauern.

Wenn das zutrifft, würde ich vorschlagen, "reinit" nach "update" umzubenennen und dann dort nur noch zwei Optionen anzubieten: language und slots.

Derzeit muss ich nach jeder Änderung an einem FHEM-Device ein reinit machen. Auch wenn ich nur rhasspyXXX Attribute ändere. Gibt keinen Grund, da dann jedes Mal ein updateSlots zu machen.

Für ein Produktiv-System wäre das dann durchaus von Vorteil, da ändert man nicht viel. Jetzt könnte ich das noch nicht brauchen. Da wär mir lieber, ich müsste nicht ständig ein reinit machen

Code Auswählen Erweitern

Wenn meine Tests mit dem gDT über's WE (?) erfolgreich sind, und niemand sonst was Gegenteiliges berichtet, könnten wir Hash zur Pflicht machen, dann sollte der Code auch an der einen oder anderen Stelle wieder einfacher werden?

Ich bräuchte da bitte noch Hinweise, was sich genau dadurch ändert. Damit ich's nachstellen und dokumentieren kann.

two_to_nine = (zwei:2 | drei:3 | vier:4 | fünf:5 | sechs:6 | sieben:7 | acht:8 | neun:9)
one_to_nine = (ein:1 | <two_to_nine>)
[...]

Reicht nicht das?

Code Auswählen Erweitern

(1..60)

[drhirn]

EDIT: Kurzformen in der ini statt der langen Variante

ini?

Wär's nicht einfacher, wenn wir einen Rhasspy-Satz z.B. so bauen:

Code Auswählen Erweitern

\[stell|stelle] (taimer|countdown) [im|auf dem|auf der|in der] [$de.fhem.Room{Room}] (in|auf) (0..60){Value} [(ein viertel|einhalb|dreiviertel){Value2}] [(sekunden|minuten|stunden){Unit}]
Und das Value2 dann im Modul auseinandernehmen?

[Beta-User]

Ich möchte die Sentences nur als Beispiel-Sammlung haben, die jeder ergänzen kann. Von daher sollten da keine Querverweise kommen.
Und ich möchte mit der Doku auch eigentlich keine Rhasspy-Doku machen. Die gibt's schon. Fokus soll auf dem Modul sein.

Im Prinzip richtig. Gebe aber zu Bedenken, dass erst durch den (einmaligen) Blick auf "Slots" klarer wird, was der Befehl von FHEM aus eigentlich macht...
Ansonsten sollten die Sätze in der Tat eher erläutern, welchen Input FHEM denn in etwa erwartet.

Oft überlegt, immer dagegen entschieden. Wenn du dann viel mit Rhasspy ausprobierst, wird dir auffallen, dass ein Training gleich nach einer Änderung nicht immer sinnvoll ist. Weil du vielleicht davor noch einen Slot ändern musst z.B. Oder du nicht immer warten willst, bis das Training abgeschlossen ist. Das kann unter Umständen nämlich ganz schön lange dauern.

Ok, das mag sein. Evtl.: zwei update-slot-Varianten mit und ohne Training? Da der FHEM-Hash-Teil sehr fix geht, könnte man m.E. auf den trainings-setter verzichten?
(Für meine Tests hatte ich das Training praktisch immer über das Web-Interface von Rhasspy gemacht, und das Modul macht es so oder so nicht ständig, sondern nur auf Nutzeranweisung).

Derzeit muss ich nach jeder Änderung an einem FHEM-Device ein reinit machen. Auch wenn ich nur rhasspyXXX Attribute ändere. Gibt keinen Grund, da dann jedes Mal ein updateSlots zu machen.

Die Frage wäre, ob es schadet, wenn FHEM ggf. "zu oft" die slots updated.
Bei den Attributen ist es halt so, dass man als User dann wissen muss, ob es - aus Rhasspy-Sicht - "new news" gibt. Wenn nein, macht es keinen Sinn, wenn ja, macht es sehr viel Sinn.
Ich _glaube_, die Nutzerführung ist einfacher, wenn wir das ganze unter einer update-Gruppe zusammenfassen und ggf. dann eben nur mehr Varianten anbieten, also z.B. (neben language) devicemap, devicemap+slot devicemap+slot+train, nur slot, nur train).

Ich bräuchte da bitte noch Hinweise, was sich genau dadurch ändert. Damit ich's nachstellen und dokumentieren kann.

Also: Es gibt einen neuen optionalen Parameter: addDGTAttrs (Bennenung können wir gerne diskutieren). Setzt man den auf z.B. 1, werden
a) zwei weitere globale Attribute verfügbar
b) die der devspec entspechenden Devices automatisch mit ausgewertet, an denen genericDeviceType gesetzt ist. Muss allerdings erst noch testen, inwieweit das klappt. Mit etwas Glück sollten (mind.) CUL_HM, ZWave und MAX - switch/light/thermostat direkt funktionieren... (abgesehen von Farbe).
Kannst ja mal schauen, ob und was da bei dir wie im Hash landet .

(@JensS: So sollte dann auch halbwegs transparent sein, was das Modul im Hintergrund macht).

Reicht nicht das?

Code Auswählen Erweitern

(1..60)

Vielleicht.
Deine Ankündigung, das direkt selbst anzugehen, hat mich bewogen "vor der Zeit" was ungetestetes zu posten, das für mich erst mal halbwegs plausibel klang, auch um das eine oder andere zu lernen. Von daher: Schauen wir mal, was am Ende daraus entsteht...
(Ich hatte irgendwie gestern abend etwas rumgespielt, aber da wollte das mit dem Timer nicht. Vermutlich hätte ich in die sentences.ini schauen sollen, aber ich wollte erst mal vor allem auch wissen, wie "intuitiv" manches automatisch geht  .

ini?

sentences.ini (dafür war doch dieser verschachtelte code, oder? Da standen erst {minutes}, im Modulcode aber {min}...)

Wär's nicht einfacher, wenn wir einen Rhasspy-Satz z.B. so bauen:

Code Auswählen Erweitern

\[stell|stelle] (taimer|countdown) [im|auf dem|auf der|in der] [$de.fhem.Room{Room}] (in|auf) (0..60){Value} [(ein viertel|einhalb|dreiviertel){Value2}] [(sekunden|minuten|stunden){Unit}]
Und das Value2 dann im Modul auseinandernehmen?

Wie geschrieben: Ich wollte auch erst noch selbst ein Gefühl dafür bekommen, wie das mit den Variablen etc. funktioniert und wollte keinesfalls behaupten, dass das das Gelbe vom Ei ist, was ich da irgendwo aufgegabelt habe .

(Und interessant wird noch die Frage, wie wir "stelle einen Wecker auf dreiviertel zwölf" vercoden - ihr kennt im schönen Österreich ja auch diese vorwärtsgewandte Sichtweise... (andere sagen "viertel vor", und das ist fast genauso lustig ).

[drhirn]

(Und interessant wird noch die Frage, wie wir "stelle einen Wecker auf dreiviertel zwölf" vercoden - ihr kennt im schönen Österreich ja auch diese vorwärtsgewandte Sichtweise... (andere sagen "viertel vor", und das ist fast genauso lustig ).

Also, bevor ich mir deinen Post nochmal genau durchlese und antworte, muss ich darauf reagieren.

Nein! Nie, nimmer, niemals werde ich etwas für "viertel" und "dreiviertel" zwölf programmieren. Diese "Zeitverwendung" ist so absurd! So oft war ich schon zu früh/spät irgendwo, weil ich's als Westösterreicher auch nach 20 Jahren im Osten nicht kapiert habe, was die damit meinen. Und die machen's nicht mal alle gleich. Alle (mir bekannten) Sprachen verwenden "viertel vor" und "viertel nach". Die Ostösterreicher sollen das auch endlich lernen zefix!

[Beta-User]

Nix Ostösterreicher, ich bin weiter westlich: https://www.youtube.com/watch?v=Q4_0W5ZJYcU

(und zum einen ist es logischer, immer nach vorne zu denken (mal abgesehen von "tsee nach tswelve"), zum anderen ist es ein netter Denksport, das (kompatibel mit Westösterreichischen Gepflogenheiten) zu coden)

[drhirn]

Im Prinzip richtig. Gebe aber zu Bedenken, dass erst durch den (einmaligen) Blick auf "Slots" klarer wird, was der Befehl von FHEM aus eigentlich macht...

Deswegen hab ich die Verwendung des Slots in meinen Sentences jetzt einfach durch (an|ein) ersetzt.

(Für meine Tests hatte ich das Training praktisch immer über das Web-Interface von Rhasspy gemacht, und das Modul macht es so oder so nicht ständig, sondern nur auf Nutzeranweisung).

Ich mach's immer über FHEM

Bei den Attributen ist es halt so, dass man als User dann wissen muss, ob es - aus Rhasspy-Sicht - "new news" gibt.

Attribute sollten Rhasspy eigentlich gar nicht interessieren.

Ich _glaube_, die Nutzerführung ist einfacher, wenn wir das ganze unter einer update-Gruppe zusammenfassen und ggf. dann eben nur mehr Varianten anbieten, also z.B. (neben language) devicemap, devicemap+slot devicemap+slot+train, nur slot, nur train).

Ja, da bin ich deiner Meinung.

Also: Es gibt einen neuen optionalen Parameter: addDGTAttrs (Bennenung können wir gerne diskutieren).

Da müssen wir auf jeden Fall drüber diskutieren
"useGenericDeviceTypes" z.B.? Oder eine leicht abgekürzte Variante?

Kannst ja mal schauen, ob und was da bei dir wie im Hash landet .

Mach ich

Von daher: Schauen wir mal, was am Ende daraus entsteht...

So wie meine Tests derzeit aussehen, wird's eine Kombination aus unseren Varianten

[drhirn]

Nix Ostösterreicher, ich bin weiter westlich: https://www.youtube.com/watch?v=Q4_0W5ZJYcU

(und zum einen ist es logischer, immer nach vorne zu denken (mal abgesehen von "tsee nach tswelve"), zum anderen ist es ein netter Denksport, das (kompatibel mit Westösterreichischen Gepflogenheiten) zu coden)

Moment. Was? Schwaben verwenden auch "dreiviertel Zwölf"?