Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Vorhin ist mir in den screenshots aufgefallen, dass "alias" nicht in lowercase gewandelt wird. Anbei entprechende Korrektur, auch für die Paralellthemen...

[drhirn]

Der defaultRoom scheint nicht in einem list des Devices auf. Ist das Absicht? Nur im helper.

Und, weil du gerne spanisch in deinen Beispielen verwendest: Da heißt das Wohnzimmer z.B. "cuarto de estar". Die Leerzeichen sind da natürlich blöd. Können/sollen wir das im DEF irgendwie beachten?

[Beta-User]

Der defaultRoom scheint nicht in einem list des Devices auf. Ist das Absicht? Nur im helper.

Kann noch nicht nachvollziehen, was du meinst. Falls sich das wirklich auf das list des Devices bezieht: RHASSPY ändert an dem Device (abgesehen von den zusätzlichen Attributen via global) nichts, es wird alles im RHASSPY-Hash (unter helper) verwaltet.

Und, weil du gerne spanisch in deinen Beispielen verwendest: Da heißt das Wohnzimmer z.B. "cuarto de estar". Die Leerzeichen sind da natürlich blöd. Können/sollen wir das im DEF irgendwie beachten?

Hm, ich habe in meinen (deutschen) Gruppen und Namen teils auch Leerzeichen drin, und sehe in Leerzeichen im rhasspyRoom eigentlich auch keine besonderen Probleme. Übersehe ich was?

Anbei nochmal eine Aktualisierung, die jetzt auch die effektive "Namensliste" Komma-separiert im Geräte-Teilhash anzeigt und dann noch zusätzliche Slots für die Geräte jeder gDT-Gruppe anlegt (dafür war die Namensliste hilfreich). Der Teil funktioniert soweit, ich weiß aber noch nicht, ob das Verbesserungen an der Erkennungsrate bringt, dazu muss ich erst noch die sentences entsprechend anpassen. Wenn es was bringt, bin ich am überlegen, ob sowas auch für groups zielführend wäre. Aber eines nach dem anderen.

Happy testing.

[drhirn]

Ein List des Devices:

Code Auswählen Erweitern


Internals:
   CONFIGFILE FHEM/rhasspy-de.cfg
   DEF        baseUrl=http://rhasspy:12101 defaultRoom=cuarto de estar language=de useGenericAttrs=1
   FUUID      604dd2ff-f33f-1a4f-056c-ce4673ffea964c2d
   FVERSION   10_RHASSPY.pm:?/2021-04-19
   IODev      rhasspyMQTT2
   LANGUAGE   de
   MODULE_VERSION 0.4.9
   NAME       Rhasspy
   NR         20
   STATE      online
   TYPE       RHASSPY
   baseUrl    http://rhasspy:12101
   devspec    room=Rhasspy
   encoding   
   fhemId     fhem
   prefix     rhasspy
   useGenericAttrs 1

Da wird alles angezeigt, nur der defaultRoom nicht.

Und hier der helper:

Code Auswählen Erweitern


   helper:
     defaultRoom cuarto
     custom:

Da ist der Raum nach dem ersten Leerzeichen abgeschnitten.

[Beta-User]

Ah, jetzt ist der Bezugspunkt klar. habe das auch mal nach oben gezogen.

Was den spanischen defaultRoom angeht, müssen mal wieder Quotes her, damit parseParams das als Einheit zusammenhält:

Code Auswählen Erweitern

defmod RHASSPY RHASSPY devspec=room=Rhasspy,devstrich0\
baseUrl=http://192.168.33.99:12101 defaultRoom="cuarto de estar" language=de useGenericAttrs=0

(räusper, IP/blocking (!) und use-default...)

NACHTRAG 1: Bitte FHEM neu starten oder auf sonstige Weise sicherstellen, dass Modulhash und Code zusammenpassen (z.B. RHASSPY löschen und neu anlegen), wenn ihr im laufenden Betrieb auf diese Mudulfassung wechselt!
NACHTRAG 2: Neuen Slot hinzugefügt mit einem Gesamtslot, der alle Namen, Räume und Gruppennamen beinhaltet (zum "Vorauslernen" für spätere Auswahl?)

[drhirn]

(räusper, IP/blocking (!) und use-default...)

Wie bitte?

[Beta-User]

Wie bitte?

Deine angefragte DEF war die:

Code Auswählen Erweitern

DEF        baseUrl=http://rhasspy:12101 defaultRoom=cuarto de estar language=de useGenericAttrs=1

Da sind m.E. zwei nicht mustergültige Dinge drind:
a) useGenericAttrs=1 ist sowieso der default => unnötig, kann weg.
b) baseUrl=http://rhasspy:12101
Das zeigt nicht auf eine IP-Adresse sondern einen hostname. Der muss aufgelöst werden, und wenn es damit Probleme gibt, blockiert im schlechtesten Fall FHEM komplett, mindestens aber solange, bis ggf. httputils melden, dass da was nicht klappt (unterstellt, die werden intern verwendet was zu empfehlen wäre).

[Beta-User]

Nochmal eine Iteration.

Neben dem Umzug von "defaultRoom" direkt in Internals (Bitte FHEM neu starten oder auf sonstige Weise sicherstellen, dass Modulhash und Code zusammenpassen (z.B. RHASSPY löschen und neu anlegen), wenn ihr im laufenden Betrieb auf diese Mudulfassung wechselt!), sind da noch ein paar Kleinigkeiten rund um CustomIntents und triggernde Rückgaben eingearbeitet.
Und es gibt eine kleine Demo-myUtils samt zugehöriger cref, die man als Basis für weitere eigene Entwicklungen nehmen könnte. Den Dialog-Teil habe ich noch nicht weiter getestet, aber die Logik ist jetzt:

Der erste zurückgegebene Wert kann eine einfache Text-response sein, ein Hash (=> Dialog) oder ein Array (1. Element: response, kann wieder SCALAR oder HASH sein), 2. Element: zu triggernde Devices (Komma-Liste), 3. Element: ggf. anderer Timeout).

[drhirn]

a) useGenericAttrs=1 ist sowieso der default => unnötig, kann weg.

Altlast. Tut aber auch nicht weh

b) baseUrl=http://rhasspy:12101
Das zeigt nicht auf eine IP-Adresse sondern einen hostname. Der muss aufgelöst werden, und wenn es damit Probleme gibt, blockiert im schlechtesten Fall FHEM komplett, mindestens aber solange, bis ggf. httputils melden, dass da was nicht klappt (unterstellt, die werden intern verwendet was zu empfehlen wäre).

Wenn die Namensauflösung bei mir im Netzwerk nicht klappt, hab ich ganz andere Probleme als das

[Beta-User]

...ich spreche auch nicht nur für deinen Anwendungsfall, sondern für die Leute, die eine FritzBox die Namensauflösung machen lassen...
(Das Thema kommt so alle Monat mal hier im Forum hoch)

[Beta-User]

Und noch eine Iteration .

Neben den zusätzlichen gDT-slots (auf sentence-Seite bisher noch nicht getestet, aber es kommt mir zielführend vor!) und den Anpassungen bzgl. der Demo-myUtils "kann" die jetzt auch die setter soweit auseinandernehmen, dass man sowas wie ein auf eine 100-er-Skala normiertes HUE- und CT-Mapping generieren kann (die Wertebereiche sind bei meinen Geräten wirklich teilweise signifikant unterschiedlich!).
(lustig ist auch, dass die HUEDevice einen "stop"-Befehl kennen, was mir bisher entgangen war und jetzt im RHASSPY-list lustig ausschaut...)

Die Idee wäre, den Color-Intent aufzubohren, dass der auch generische Anweisungen versteht und das jetzt mal vorläufig "SetColorParms" getaufte Baby irgendwie verarbeiten kann. Wie das genau gehen soll, steht noch in den Sternen, aber wie meistens: irgendwo muss man halt mal anfangen...
(Man sollte das dann später mal auch als rhasspyMapping anlegen können, der Parser dürfte damit klarkommen).

(Btw.: das wäre dann ein neues feature, die bisherigen Vorbereitungen sind aber keine Revolution, von daher kann man diese Version m.E. am 29. durchaus als Grundlage verwenden.)

[drhirn]

Hmmmmm, was müsste ich an der Doku ändern?

Und die 99_RHASSPY_Demo_Utils.pm soll ein Beispiel für einen "Skill" sein? Also für einen Custom Intent, der nicht in der 99_myUtils.pm steht?

[Beta-User]

Hmmmmm, was müsste ich an der Doku ändern?

Auf was bezieht sich das?
- myUtils: siehe unten
- zusätzliche Slots: man kann damit ggf. einfach die in Frage kommenden Geräte in der sentences.ini eingrenzen, z.B. für Helligkeit:

Code Auswählen Erweitern

#brightness
(stelle|schalte|erhöhe|mache) $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [um] [(0..255){Value}] [prozent{Unit:percent}] (heller){Change:lightUp}
(stelle|schalte|senke|mache) $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [um] [(0..255){Value}] [prozent{Unit:percent}] (dunkler){Change:lightDown}
Das funktioniert dann aber nur noch, wenn auch die slots gefüllt sind, also an den in Frage kommenden Geräten der gDT gesetzt ist.
- color: Ist noch nicht fertig und evtl. nochmal isgesamt zu überarbeiten, würde ich im Moment nicht aktiv darstellen. Die Idee wäre, (einmal mehr) englische Keywords übergeben zu können (lightgreen, darkgrey,blue), und das Modul würde dann daraus einen Farbwert errechnen, den die Hardware versteht. Müßte man halt z.B. auch noch wissen, welchen Helligkeitswert man annimmt, wenn das Ding auf "Helligkeit 0" steht. Ist

Und die 99_RHASSPY_Demo_Utils.pm soll ein Beispiel für einen "Skill" sein? Also für einen Custom Intent, der nicht in der 99_myUtils.pm steht?

Es sind in der Demo-Utils drei "Skills" drin, und das ganze dann halt gleich als Package.

Meine Testinstallation sieht bei den rhasspyIntents grade so aus:

Code Auswählen Erweitern

attr RHASSPY rhasspyIntents Respeak=Respeak(NAME)\
SetAllOn=SetAllOn(Room,Type)\
SetCustomIntentsBasicTest=RHASSPY::Demo::BasicTest(siteId,Type)\
SetCustomIntentsDataTest=RHASSPY::Demo::DataTest(NAME, DATA)\
SetCustomIntentsDialogueTest=RHASSPY::Demo::DialogueTest(NAME,DATA)

Bzgl. Doku würde ich da erst mal gar nichts weiter machen. Die "alten" CusotmIntents sollten weiter funktionieren, und jetzt gibt es eben diese weiteren Demos, v.a. dazu, wie man ggf. DATA "auspackt". Vielleicht den Hinweis aufnehmen, dass man mit "help RHASSPY_Demo_Utils" eine (englische) Hilfe dazu bekommen kann.
DialogueTest müßte ich auch erst mal testen. "Eigentlich" müßte er gehen, das ist einfach ein Klon von der "shortcut"-Logik.

Bin grade noch am überlegen, ob es relativ einfach möglich ist, diese "Mehrfachnennungen" im list irgendwie zu vermeiden. Wenn der setter "pct" ist, ist ja doch sehr häufig auch der Rest (Reading usw.) "pct"...

[drhirn]

Woher weiß das Modul, wo die 99_RHASSPY_Demo_Utils.pm liegt? Bzw. wie sie heißt? Oder anders gefragt, muss die so heißen?

[Beta-User]

Da das eine "myUtils"-Datei ist, sollte die wie üblich ins FHEM- (Modul-) Verzeichnis.
Zur Namensgebung:
99 => automatisch laden
"Utils" => damit sie unter "edit files" erscheint

Rest: Frei wählbar, aber der Link auf die "Initialize"-Funktion muss bei anderem Namen angepaßt werden.

Anders gefragt: Was stört dich am Namen?