Modulentwicklung für Rhasspy Sprachassistent

[drhirn]

Der Vorschlag zum Ort resultiert aus der Überlegung, dass wir versuchen sollten sicherzustellen, dass sich der User ein paar essentielle Gedanken gemacht hat, bevor er mit dem "großen Ganzen" konfrontiert wird. Überspringen wir diesen Schritt, ist meine Sorge, dass der Supportaufwand pro User um ein vielfaches höher wird. So könnten wir darauf verweisen, dass er nochmal diese eine Seite von vorne bis hinten durchgehen soll...

Ja, seh ich auch so. Deswegen war auch mein Gedanke, das gleich am Anfang prominent zu platzieren. Von mir aus auch gerne als eigene Überschrift. Und der Inhalt verweist dann auf die Unterseite Schnellstart.

[Beta-User]

  Anders gesagt: Die Bausteinchen später umzusortieren, ist nicht die große Übung, wenn die Bausteinchen exisitieren...

Vielleicht sollten wir dann lieber erst mal Bausteinchen backen ...

[drhirn]

Hihi, ja. Ich hab schon den umgebauten Schnellstart im Ofen. Dauert aber noch ein bisschen, bis der durch ist.

[Prof. Dr. Peter Henning]

ist nicht die große Übung, wenn die Bausteinchen exisitieren...

Dann schau Dir mal "Die Türme von Hanoi" an.

LG

pah

[drhirn]

So hätte ich mir das vorgestellt: https://wiki.fhem.de/wiki/RHASSPY/Schnellstart

Die restlichen Informationen aus deinem Schnellstart werden dann in der Hauptseite untergebracht.

[Beta-User]

So hätte ich mir das vorgestellt: https://wiki.fhem.de/wiki/RHASSPY/Schnellstart

Sieht gut aus!

(kleine!) Kritikpunkte:
- reload ist m.E. unnötig. DEF initialisiert alles, und attr languageFile liest die de-Fassung auch komplett ein. Probleme gab es nur, wenn die Basiskeys erweitert wurden, was während der Entwicklung hin und wieder der Fall war. (So einen Fall sollte man eher unter "Spezialfälle" sehen und bei updates der Moduldatei grundsätzlich einen restart empfehlen)
- "set rhasspy update all" befindet sich m.E. in der Erklärung an der falschen Stelle. Für "[de.fhem:GetTime]" muss man erst mal nur der Aufforderung folgen, das Training wegen der Änderung der sentences zu starten.
Alle anderen Infos/Tags braucht man erst später.
- "unklar" ist mir noch, ob man direkt noch weiter wie $de.fhem.Device-SetOnOff gehen sollte (also: ($de.fhem.Device-switch | $de.fhem.Device-light | $de.fhem.Device-media){Device})), aber das ist dann eher ein Vertiefungs-Thema.

Sonst finde ich das (sehr!) gelungen, und es ist im Prinzip auch völlig ok, dass der Artikel an der Stelle endet.

Dann schau Dir mal "Die Türme von Hanoi" an.

a) das ist simple Mechanik, wenn man mal weiß, wie man zählen muss ;
b) hinkt der Vergleich, weil andere Spielregeln gelten .

Aber danke für den konstruktiven Einwand ...

EDIT: Nachtrag noch @drhirn: Da steht was von RHASSPY versteht "an" nicht. Ich bin ja geneigt, das aus Aufforderung anzusehen, diesen Sprach-Kompabilitätsrest direkt auszubauen, wollte aber sicherheitshalber nachfragen, ob Einwände bestehen...

[drhirn]

- reload ist m.E. unnötig. DEF initialisiert alles, und attr languageFile liest die de-Fassung auch komplett ein. Probleme gab es nur, wenn die Basiskeys erweitert wurden, was während der Entwicklung hin und wieder der Fall war. (So einen Fall sollte man eher unter "Spezialfälle" sehen und bei updates der Moduldatei grundsätzlich einen restart empfehlen)
- "set rhasspy update all" befindet sich m.E. in der Erklärung an der falschen Stelle. Für "[de.fhem:GetTime]" muss man erst mal nur der Aufforderung folgen, das Training wegen der Änderung der sentences zu starten.
Alle anderen Infos/Tags braucht man erst später.

Ich hab mir für die Doku extra eine neue Testumgebung angelegt. Und das zuerst so getestet, wie du das geschrieben hast. Und das hat eben dann erst funktioniert, nachdem ich reload/update all gemacht habe. Das reload war nicht immer nötig. Weiß nicht, warum ich das gebraucht habe. Aber bevor Fragen aufkommen, dachte ich mir, ich schreib's einfach rein. Schadet ja nicht. Das "update all" war definitiv notwendig, weil das Modul noch nichts von dem neuen Intent wusste. Erst nach dem update all war der im Reading "intents" vorhanden.

aber das ist dann eher ein Vertiefungs-Thema.

Finde ich auch

EDIT: Nachtrag noch @drhirn: Da steht was von RHASSPY versteht "an" nicht. Ich bin ja geneigt, das aus Aufforderung anzusehen, diesen Sprach-Kompabilitätsrest direkt auszubauen, wollte aber sicherheitshalber nachfragen, ob Einwände bestehen...

Einwände hab ich keine. Notwendig finde ich es aber nicht. Weil, kann ja sein, dass es nicht bei "an" und "aus" bleibt. Gibt ja noch andere Wörter dafür ("ein" z.B.).

[Beta-User]

Ich hab mir für die Doku extra eine neue Testumgebung angelegt. Und das zuerst so getestet, wie du das geschrieben hast. Und das hat eben dann erst funktioniert, nachdem ich reload/update all gemacht habe. Das reload war nicht immer nötig. Weiß nicht, warum ich das gebraucht habe.

Ich habe den Verdacht, dass das eine andere Urache hat, die eher im Zusammenspiel mit MQTT2_CLIENT zu suchen ist. Jedenfalls erschließt sich mir der reload an der Stelle nicht - abgesehen ggf. davon, dass man das dann braucht, wenn man language in global anfasst. Dann muss man auch die DEF von RHASSPY anfassen - (aber ein reload hilft in diesem Fall auch nicht)

Aber bevor Fragen aufkommen, dachte ich mir, ich schreib's einfach rein. Schadet ja nicht. Das "update all" war definitiv notwendig, weil das Modul noch nichts von dem neuen Intent wusste. Erst nach dem update all war der im Reading "intents" vorhanden.

Das Reading ist aber nur Kosmetik, die Auswertung der Messages sollte so oder so stattfinden, wenn das zu den Internals paßt, was reinkommt.

Einwände hab ich keine. Notwendig finde ich es aber nicht. Weil, kann ja sein, dass es nicht bei "an" und "aus" bleibt. Gibt ja noch andere Wörter dafür ("ein" z.B.).

Na ja, die Botschaft wäre eher: alles, was sinngemäß "on" ist, ist eben genau als on zu übergeben, und die "hoch"- und "runter"-Anweisungen sind nur noch mit dem korrespondierenden englischen Key zu übergeben. (Der code ist an der Stelle eigentlich unnötig kompliziert, und wenn wir ihn vereinfachen können, fallen halt ein paar Zeilen wieder weg, weil auch ein, zwei zentrale Hashes nicht mehr benötigt werden...).

[drhirn]

Ich hab das jetzt nochmal getestet. In einer ganz frischen Umgebung.

Stimmt, wenn ich die Sprache im DEF umstelle, brauche ich kein Reload. Wenn ich aber - nach einrichten des RHASSPY-Devices - die Sprache in global ändere, muss ich entweder einmal die DEF von RHASSPY öffnen und (ohne Änderung) wieder speichern. Oder eben einen Reload machen. Da ich aber im Satz im Wiki ein ein "kann nötig sein" habe und ein reload ja eigentlich nicht weh tut, könnte man das - umformuliert - schon drinnen lassen.

Bezüglich "update all" der selbe Effekt, wie gestern schon. Solange ich das nicht gemacht habe, erkennt Rhasspy zwar den Satz "wie spät ist es", findet aber keinen Intent dazu. Was echt schräg ist. Und es ist egal, wie oft ich trainiere. Geht erst nach einem udpate all. "update devicemap" reicht nicht. Kann ich mir nicht erklären. Und teste das jetzt gleich nochmal.

[drhirn]

Bezüglich "update all" der selbe Effekt, wie gestern schon. Solange ich das nicht gemacht habe, erkennt Rhasspy zwar den Satz "wie spät ist es", findet aber keinen Intent dazu. Was echt schräg ist. Und es ist egal, wie oft ich trainiere. Geht erst nach einem udpate all. "update devicemap" reicht nicht. Kann ich mir nicht erklären. Und teste das jetzt gleich nochmal.

Und jetzt passiert's natürlich nicht mehr. Obwohl ich alles genau gleich gemacht habe. Aber, es muss irgendwie an Rhasspy gelegen sein.

[Beta-User]

Bezüglich "update all" der selbe Effekt, wie gestern schon. Solange ich das nicht gemacht habe, erkennt Rhasspy zwar den Satz "wie spät ist es", findet aber keinen Intent dazu. Was echt schräg ist. Und es ist egal, wie oft ich trainiere. Geht erst nach einem udpate all. "update devicemap" reicht nicht. Kann ich mir nicht erklären. Und teste das jetzt gleich nochmal.

Das "mehr" liegt an fetchIntents(), vielleicht kannst du mal "fetchIntents($defs{<rhasspy-Name>})" testen? Dann bastle ich das noch in "update" mit rein...

Da ich aber im Satz im Wiki ein ein "kann nötig sein" habe und ein reload ja eigentlich nicht weh tut, könnte man das - umformuliert - schon drinnen lassen.

So ein Satz "riecht" nach fehlerhafter Programmierung, von daher hätte ich ihn gerne draußen. DEF anfassen als Anleitung wäre für mich ok.

[drhirn]

Das "mehr" liegt an fetchIntents(), vielleicht kannst du mal "fetchIntents($defs{<rhasspy-Name>})" testen? Dann bastle ich das noch in "update" mit rein...

Nicht nötig, siehe oben.

So ein Satz "riecht" nach fehlerhafter Programmierung, von daher hätte ich ihn gerne draußen. DEF anfassen als Anleitung wäre für mich ok.

Haha, alles klar. Hab's geändert. Weiß nur nicht, ob jeder versteht, was damit gemeint ist. https://wiki.fhem.de/wiki/RHASSPY/Schnellstart#Basissprache

[Beta-User]

Nicht nötig, siehe oben.

Danke.

Haha, alles klar. Hab's geändert. Weiß nur nicht, ob jeder versteht, was damit gemeint ist. https://wiki.fhem.de/wiki/RHASSPY/Schnellstart#Basissprache

Habe da ein kleines Beispiel ergänzt, weiß allerdings nicht, ob das jedem weiterhilft...

Anbei dann wieder ein (weitgehend ungetestetes!) update. Das
- kann nicht mehr die de-mappings verstehen und
- sollte einige mehr "SetOnOff"-Typen erkennen (darunter auch den 0/1-Fall (?) vom Nebenthread)

Also falls du grade eh' am Testen bist...

[drhirn]

- kann nicht mehr die de-mappings verstehen und

Was bedeutet das konkret?

[drhirn]

Habe da ein kleines Beispiel ergänzt, weiß allerdings nicht, ob das jedem weiterhilft...

Es muss nicht mal ein Leerzeichen angefügt werden. Auf "DEF" klicken und dann auf "modify xxx" reicht.