Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

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

Jo. Und auch unsere westlichen Nachbarn, die Badener (nett formuliert ). Und wie das in Hessen oder der Pfalz gehandhabt wird, habe ich bisher nicht untersucht...

Deswegen [...]

Schaue ich mir an, aber eigentlich sehe ich diesen Teil auch nicht wirklich als meine aktuelle Baustelle an...

Ich mach's immer über FHEM

Jeder, wie er es gewohnt ist. Ich habe die sentences halt über das web-if bearbeitet, und da muss man dann sowieso aktiv werden, was die Frage nach dem Training angeht.

Attribute sollten Rhasspy eigentlich gar nicht interessieren.

? Neuer rhasspyRoom => updateSlots. dto. für channel, device-Namen etc. Oder übersehe ich mal wieder was?


Ja, da bin ich deiner Meinung.

Vorschläge sind willkommen, aber da die funktionalen Bauteile ja soweiso getrennt sind, ist es eigentlich nur "skinning", und ich bin daher für jeden zielführenden Vorschlag offen. Wollte nur zurückmelden, was ich so als "unbedarfter User" an Eindrücken hatte .

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

"useGenericAttrs"?"ausgeschlachtet" werden (hoffentlich) auch alexaName & siriName, ggf. ergänzt und (betr. hb-Mapping noch nicht) ausgewertet eben die beiden "generischen" schon erwähnten. Wobei ich mir bezgl. des homebridgeMappings noch nicht sicher bin. Das sieht recht kompliziert aus, und da es auch die Möglichkeit gibt, eben ein rhasspyMapping anzugeben, kann man das in diesen Fällen eventuell auch sein lassen (es sei denn, es liefert jemand Code).
Jedenfalls im Moment sollte es so sein, dass (bei Doppelungen) "rhasspy sticht generic" gilt...

Wird evtl. auch die Praxis zeigen

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

Bin mal auf das Ergebnis gespannt .

[drhirn]

Jo. Und auch unsere westlichen Nachbarn, die Badener (nett formuliert ). Und wie das in Hessen oder der Pfalz gehandhabt wird, habe ich bisher nicht untersucht...

Pfff, und ich hab immer geglaubt, wir Alemannen sind die besseren Deutschsprechenden

Schaue ich mir an, aber eigentlich sehe ich diesen Teil auch nicht wirklich als meine aktuelle Baustelle an...

Sehe ich auch so

? Neuer rhasspyRoom => updateSlots. dto. für channel, device-Namen etc. Oder übersehe ich mal wieder was?

Nein, aber ich. *kopf->tisch*

"useGenericAttrs"?

d'accord

Wobei ich mir bezgl. des homebridgeMappings noch nicht sicher bin. Das sieht recht kompliziert aus, und da es auch die Möglichkeit gibt, eben ein rhasspyMapping anzugeben, kann man das in diesen Fällen eventuell auch sein lassen (es sei denn, es liefert jemand Code).

Beim Homebridge-Mapping kann ich gar nicht helfen. Da hab ich null Erfahrung.

Jedenfalls im Moment sollte es so sein, dass (bei Doppelungen) "rhasspy sticht generic" gilt...

Das halte ich für einen guten Ansatz!

[drhirn]

Ich hätt's nicht geglaubt, aber das scheint Rhasspy-seitig zu funktionieren. Muss nur das Modul entsprechend umbauen.

Code Auswählen Erweitern


[de.fhem:SetTimer]
timer auf [((1..60){hour} (stunde|stunden))] [und] [((1..60){min} (minute|minuten))] [und] [((1..60){sec} (sekunde|sekunden))]
timer auf (1..60){hour} (einviertel{min:15}|einhalb{min:30}|dreiviertel{min:45}) (stunde|stunden)
timer auf (1..60){min} (einviertel{sec:15}|einhalb{sec:30}|dreiviertel{sec:45}) (minute|minuten)


[Beta-User]

Nein, aber ich.

Ok, das spricht aber doch auch eher dafür, bei einem devicemap-update auch ein slot-update hinterherzuschubsen, oder?
Es ist ja die Info (an FHEM), dass sich irgendwelche relevanten Attribute geändert haben, und das dann eben auch potentiell auf der Rhasspy-Seite direkt auch ankommen sollte.

d'accord

War auch ein Schnellschuss, aber dann machen wir das (bis auf weiteres) so...

Beim Homebridge-Mapping kann ich gar nicht helfen. Da hab ich null Erfahrung.

Ich auch nur dahingehend, dass "weniger ist mehr" gilt. Wenn man wirklich was braucht, wird das scheinbar recht schnell kompliziert, aber das ist eigentlich eher die Ausnahme - abgesehen von der "255"-er brightness. Aber die kann man mit map=percent abfackeln .
Hab's mal eingebaut, mal sehen, ob das schon alles war...

Zur "brightness"-Logik:
- für Rhasspy ist das das "Schlüsselwort für "Leuchtmittel" => bitte Zahlenwert liefern!
- für FHEM ist es eher ein Indikator, dass nicht von 0-100 (bzw. 99) gestellt werden kann, sondern 0-255.
Das Modul verhält sich jetzt - ohne explizite Angabe - (hoffentlch) genau nach der FHEM-Logik, wenn es "brightness" geliefert bekommt und entscheidet das mapping anhand des setter-Namens.

Sollte in > 80% das "richtige" Ergebnis liefern, aber eben bei weitem nicht immer...

Das halte ich für einen guten Ansatz!

Das war auch meine Schlussfolgerung nach den ersten Tests gestern. Man kann zwar manches direkt verwerten, aber z.B. die rhasspyNames machen schon Sinn, selbst, wenn der Rest automatisch läuft und z.B. ein Switch als solcher erkannt und eingebunden wird...
Ist halt alles noch etwas im Fluß, aber wenn wir mit dieser "kleinen Lösung" und ein paar Ergänzungen (speaker, player, oder wie das ggf. heißt) dann das meiste ohne weitere Nutzereingriffe "abgefackelt" bekommen, wäre das schon richtig g*l...

Ich hätt's nicht geglaubt, aber das scheint Rhasspy-seitig zu funktionieren. Muss nur das Modul entsprechend umbauen.

Hattest du Zweifel?!?

Btw.: Das Modul sollte schon jetzt mit hour, min und sec "können", "Value"+"Unit" ist nur noch eine Art Kompabilitätslayer...

[drhirn]

Hattest du Zweifel?!?

An dir nicht. Aber ich war mir nicht sicher, was Rhasspy mit so vielen Klammern macht.

Btw.: Das Modul sollte schon jetzt mit hour, min und sec "können", "Value"+"Unit" ist nur noch eine Art Kompabilitätslayer...

Ja, kann es. Abgesehen davon, dass wir $time statt $value brauchen. Und ich mir jetzt überlegen muss, wie ich die "Setzen-Erfolgt"-Rückmeldung mache.

[JensS]

Danke für den Link, auch wenn mir völlig schleierhaft ist, warum die Jungs das als root laufen lassen...?

Nichts hält länger als ein Provisorium... 
Willkommen in der Welt der Beta-Tester! 

[Beta-User]

Nichts hält länger als ein Provisorium... 
Willkommen in der Welt der Beta-Tester! 

...sowas hatte ich schon vermutet...

Dann mal auch ein herzliches Willkommen im Kreis der Beta-User. (Ich habe das Modul im Echtsystem am Start, no risk, no fun...)
Klingt so, als wären Hashes nunmehr doch nicht nur was für große Dachböden...?



... die Rückmeldung in Sekunden ist vielleicht wirklich etwas gewöhnungsbedürftig ...

Würde vorschlagen, den für das at verwendeten String zu teilen und dann die Uhrzeit zurückzugeben.
Die Luxusvariante wäre, in Unit nicht seconds zu schreiben, wenn wir von der neuen Variante kommen, sondern (irgend) was anderes, und/oder danach zu unterscheiden, ob es bis zur Zielzeit mehr oder weniger wie z.B. 100 Sek. sind...? (Oder drei Varianten zu bauen, falls wir noch im Bereich bis z.B. 15 Minuten sind?)
Wie das mit den Hashes funktioniert, ist ja jetzt soweit klar, wobei ich hier ein "sprechendes" Etikett draufkleben würde, z.B. ...->{hour}.

[drhirn]

Unit habe ich ganz vernichtet. Brauchen wir nicht mehr.
Die Textausgabe ist aber etwas komplexer. Weil's halt leider auch einen Unterschied macht, ob 1 Stunde oder 2 StundeN.
Aber ich bin gerade auf einem guten Weg. Glaub ich

[JensS]

Dann mal auch ein herzliches Willkommen im Kreis der Beta-User. (Ich habe das Modul im Echtsystem am Start, no risk, no fun...)
Klingt so, als wären Hashes nunmehr doch nicht nur was für große Dachböden...?

Danke für's Willkommen. 
Solange man nicht verschwenderisch mit dem Platz auf dem Dachboden umgeht, sind Hashes super. Ich habe mir den Code noch nicht wirklich angeschaut, hatte aber auf Grund der Posts die Vermutung, dass bereits vorhandene Werte doppelt vorgehalten werden.
Zum Thema Timer hatte Roman einen Beitrag. https://forum.fhem.de/index.php/topic,113180.msg1130139.html#msg1130139
Könnt ihr Werners Bierflasche optional mit einbauen?
Ich freue mich jedenfalls, dass das Modul von einem Code-Jongleur so fachkräftige Hilfe erfährt und warte geduldig auf eine endgültige Version.
Gruß Jens

[drhirn]

So, ich hab mal denen neuen Timer zu GitHub (0.4.5beta) gestellt. Work in progress. Nur damit ihr seht, wie ich mir das vorstelle. Musste halt auch die rhasspy-de.cfg ändern.

Funktioniert mit dem oben geposteten Rhasspy-Sätzen:

Code Auswählen Erweitern


[de.fhem:SetTimer]
timer auf [((1..60){hour} (stunde|stunden))] [und] [((1..60){min} (minute|minuten))] [und] [((1..60){sec} (sekunde|sekunden))]
timer auf (1..60){hour} (einviertel{min:15}|einhalb{min:30}|dreiviertel{min:45}) (stunde|stunden)
timer auf (1..60){min} (einviertel{sec:15}|einhalb{sec:30}|dreiviertel{sec:45}) (minute|minuten)


[Beta-User]

So, Zwischenstand zum Thema genericDeviceType:

Der Hash wird mit der (leider noch auf meiner gestrigen Version basierenden) Version jetzt aufgebaut, die einzelnen Elemente werden - soweit ich das vorläufig überblicken kann - auch sauber gemischt.
Testgeräte für "nur-gDT" bzw. gDT+rhasspy-Names/Room waren: CUL_HM-Thermostat, ZWave-on/off, blind-Geräte beider Gattungen und ein MQTT2-Tasmota-Licht (pct-dimmbar).

Was Timer angeht, hätte ich da auch gerne deine neue Fassung eingebaut, aber das sah' gestern noch wirklich nach WIP aus. Tipp: Für's Testen reicht es erst mal, die Sätze in die de-cfg zu schreiben und dann ein language-update zu machen. Wenn dann klar ist, wie es geht, kann man es dann in die en-Fassung nachtragen. (Auf github lag/liegt noch eine alte de-cfg, wenn ich das richtig sehe).

Soweit erst mal von meiner Seite...
EDIT: das mit dem Timer wollte ich jetzt doch wissen, ist eingearbeitet, language-file anbei.

[drhirn]

(Auf github lag/liegt noch eine alte de-cfg, wenn ich das richtig sehe).

Öhm, nein. Die ist schon aktuell. Letzter Stand gestern abend.

[JensS]

Bin mal drübergeflogen hab gleich ein paar Fragen:

"define Rhasspy RHASSPY" scheint zu reichen - das gefällt mir. Im Code bzw. ref stehen verschiedene Ersatz-Standardräume (RHASSPY,Rhasspy,default). Wozu brauche ich das Ding überhaupt? Er soll ja notwendig sein aber ich habe nirgends einen Bezug dazu gefunden. Als SiteId bei "set Rhasspy speak ..." wird ja "default" gesetzt.

Passiert ein Response oder SessionEnd, wenn SetMute aktiv ist, und z.B. nach der Zeit gefragt wird?

Zeile 2009: "    my $contenttype = q{application/json};" scheint überflüssig zu sein.

Ist eine Erweiterung des Timers mit Begriffen machbar? Bei mehreren Timern gleichzeitig, könnte man so erfahren, welcher gerade abgelaufen ist. Eine Liste mit Begriffen könnte in die Sprachdatei und per updateSlots verteilt werden. Für mich auch noch interessant - die Möglichkeit, eine .wav abzusetzen.

Nochmals Danke für Eure viele Arbeit!!!

Gruß Jens

[Beta-User]

Öhm, nein. Die ist schon aktuell. Letzter Stand gestern abend.

Ähm, sorry, dann habe ich da wohl was durcheinandergewürfelt...

Es war noch eine Kleinigkeit bei den Räumen verquer, das sollte jetzt auch in der Fassung anbei geklärt sein.

Es sind mir beim Rumtesten noch ein paar andere "Kleinigkeiten" aufgefallen, aber dazu ein andermal mehr.

Ist eine Erweiterung des Timers mit Begriffen machbar? Bei mehreren Timern gleichzeitig, könnte man so erfahren, welcher gerade abgelaufen ist. Eine Liste mit Begriffen könnte in die Sprachdatei und per updateSlots verteilt werden.

Das mit den Begriffen fände ich auch gut, das mit dem "Programm" in der Einkaufsliste war in dem Zusammenhang ggf. interessant?
(sollte man vorsehen, würde "label" vorschlagen?)

Hätte dann auch noch zwei Wünsche:
- Es sollte die Möglichkeit geben, einen (ebenfalls optional benannten) "Wecker" zu stellen. Dazu müßte man aber unterscheiden, ob eine Dauer (hour) oder eine Uhrzeit (hourAbs?) übergeben wird. sollte weder bei den sentences noch im Code ein großes Problem darstellen.
- Die heutige Rückgabe finde ich nicht so gelungen, würde nochmal auf das hier zurückkommen:

Die Luxusvariante wäre, [in der Antwort] danach zu unterscheiden, ob es bis zur Zielzeit mehr oder weniger wie z.B. 100 Sek. sind...? (Oder drei Varianten zu bauen, falls wir noch im Bereich bis z.B. 15 Minuten sind?)

Will sagen: Wenn der Timer erst in einer Stunde abläuft, würde ich eher die Uhrzeit zurückgeben als die Zeitdifferenz in Stunden. Das sollte auch für "Wecker" intuitiver sein?

"define Rhasspy RHASSPY" scheint zu reichen - das gefällt mir.

Im Prinzip ja, wobei es vermutlich empfehlenswert ist, language=de zu setzen, sonst muss man immer die Labels bei den sentences anpassen, oder?
Ansonsten finde ich das mit parseParams auch sehr elegant, das macht es wirklich einfach, beliebig Parameter zu setzen, oder es eben sein zu lassen .

Im Code bzw. ref stehen verschiedene Ersatz-Standardräume (RHASSPY,Rhasspy,default). Wozu brauche ich das Ding überhaupt? Er soll ja notwendig sein aber ich habe nirgends einen Bezug dazu gefunden. Als SiteId bei "set Rhasspy speak ..." wird ja "default" gesetzt.

Dazu kann ich noch wenig sagen, im Moment ist es (fast) so, wie es immer war... (nur bei Hash-Nutzung wird alles auf Kleinschreibung "getrimmt").

Passiert ein Response oder SessionEnd, wenn SetMute aktiv ist, und z.B. nach der Zeit gefragt wird?

Wenn muted,  erfolgt nie eine Reaktion. An sich finde ich das logisch, aber wenn Bedarf besteht, müßte man sich das mal ansehen.

Zeile 2009: "    my $contenttype = q{application/json};" scheint überflüssig zu sein.

Muss ich mir mal ansehen, wird etwas dauern.

Für mich auch noch interessant - die Möglichkeit, eine .wav abzusetzen.

Mit dem Teil "Audiowiedergabe" habe ich mich noch nicht befasst, aber playWav als Funktion ist ja da, sollte also eigentlich keine größere Sache sein.
(Ich habe aber noch keine Vorstellung, was da von woher gespielt werden soll).

Danke auf alle Fälle auch für's drübersehen!

[JensS]

Danke für deine ausführliche Antworten!

Wenn muted,  erfolgt nie eine Reaktion. An sich finde ich das logisch, aber wenn Bedarf besteht, müßte man sich das mal ansehen.

Wenn eine Session eröffnet wurde, muss es ein SessionEnd in irgendeiner Art geben. Ansonsten wartet die Basis bis zum Timeoutfehler.

Mit dem Teil "Audiowiedergabe" habe ich mich noch nicht befasst, aber playWav als Funktion ist ja da, sollte also eigentlich keine größere Sache sein.

Wär ne tolle Sache!

nur bei Hash-Nutzung wird alles auf Kleinschreibung "getrimmt"

...sehe ich kritisch, da in den Rhasspy-Attributen bzw. sentences.ini beides erlaubt ist.

Dazu kann ich noch wenig sagen, im Moment ist es (fast) so, wie es immer war...

Der Standardraum sollte der SiteId entsprechen, welche im Standardfall genutzt wird und kein siteId="Küche" mitgegeben wird.
Bei "set Rhasspy speak hallo" ertönt in diesem Raum ein "hallo". Bei mir ist es aktuell das Wohnzimmer. Dazu habe ich die hardgecodete Variable von "default" auf "Wohnzimmer" gesetzt.
Da bei der Installation von Rhasspy, die siteId immer zuerst "default" lautet, würde ich vorschlagen, den Standardraum mit "default" bei undef vorzubelegen. Das würde Einsteigern das Testen mit "set Rhasspy (speak|textCommand|play|etc.)" erleichtern und schnell zum gewünschten Erfolg führen.

Dazu müßte man aber unterscheiden, ob eine Dauer (hour) oder eine Uhrzeit (hourAbs?) übergeben wird.

Ist auf jeden Fall eine nützliche Erweiterung.

Code Auswählen Erweitern

Zeile 2009:"    my $contenttype = q{application/json};"
Da ist mir aufgefallen, dass die Variable definiert wird aber keine Übergabe bzw. Auswertung stattfindet.

Gruß Jens

p.s.

Ich habe aber noch keine Vorstellung, was da von woher gespielt werden soll

Schau mal hier: https://forum.fhem.de/index.php/topic,113180.msg1130450.html#msg1130450
Die Get-Variante von Roman (vv.) ist auch interessant. "Wann sind die Kartoffeln fertig?" könnte man mit "Der Kartoffel-Timer ist in 10 Minuten abgelaufen." beantworten.