Modulentwicklung für Rhasspy Sprachassistent

[drhirn]

Grundsätzlich zu dem Thema: einfach den (vermutlich) passenden gDT setzen und dann schauen, was der analyzer daraus macht => RHASSPY-list.

Ich glaub, wir sollten's trotzdem irgendwann irgendwo dokumentieren .

Finde ich gut. Wie wäre es mit einem Eincheck-Vorschlag an wuppi68?

Antrag ist gestellt

[drhirn]

Da mir das mit der hotword-Reaktion als Idee gefallen hat, gibt's jetzt ein neues Attribut "rhasspyHotwords" (siehe commandref, da ist auch die einfachere Form via DEF zu finden). Wer die subscriptions manuell gesetzt hat, muss diese um "hermes/hotword/+/detected" ergänzen, damit was beim Modul ankommt.

Ich hab gerade folgende DEF:

Code Auswählen Erweitern

baseUrl=http://rhasspy:12101 defaultRoom=wohnzimmer language=de devspec=room=Rhasspy handleHotword

Stimmt das mit dem handleHotword so? Weil, ich bekomm da kein Reading. Erst, wenn ich das Attribut entsprechend setze.

[Beta-User]

Ich glaub, wir sollten's trotzdem irgendwann irgendwo dokumentieren .

Ja, Doku ist alles...

Bin allerdings eher skeptisch, ob man derartige "Selbstverständlichkeiten" wie das, was der gDT-Analyzer ermittelt, wirklich explizit dokumentieren sollte. Die User sollten mAn. lernen, sowas auszutesten und dann in die devicemap zu schauen, was RHASSPY daraus macht. Dann kann man bei Bedarf nachregeln, aber im Grundsatz sollten diese Dinge so sein, dass es einfach "funktioniert" und die User gar nicht groß nachdenken müssen. Das ganze ist ja auch so angelegt, dass ggf. an zentraler Stelle einfach eine Korrektur eingefügt werden kann, die dann für alle Betroffenen auch direkt wirksam wird.

Bei der Gelegenheit: Mir ist vorhin aufgefallen, dass z.B. gar nicht dokumentiert gewesen war, dass es einen "Specials"-Key namens "colorTempMap" gibt. (Ich hoffe nur, dass der auch funktioniert... )

Da wir derartige "Specials" schon an der einen oder anderen Stelle haben, habe ich die Anregung von Gisbert jetzt mal so umgesetzt, dass es ein generisches "Special" gibt, mit dem man beliebige Werte (in Value) an den SetNumeric(Group)-Intenthandler übergeben kann, und den dann nur für das Zieldevice ummappt. So kann z.B. auch eine Mischung zwischen "Gisbert-TYPE" und "CUL_HM/ZWave-TYPE"-Rollläden sauber und einheitlich angesteuert werden, und auch Somfy-Typen müßten sich zwanglos überreden lassen, in "myPosition" zu fahren:

Code Auswählen Erweitern

attr RollladenSchlafzimmer1 rhasspyMapping SetOnOff:cmdOn=DriveUp,cmdOff=DriveDown\
SetNumeric:cmdStop=Stop,type=setTarget,cmd=pct
attr RollladenSchlafzimmer1 rhasspySpecials numericValueMap:10='DriveSlit'


Status: Grob angetestet (einchecken dann, wenn Gisbert oder jemand anderes "paßt" ruft).

EDIT: man sollte die diffs immer erst nochmal durchsehen. Bitte den einen downloader, das nochmal auszutauschen, da war ein Kopier/Änder-Fehler drin!

[Beta-User]

Sorry, beim Testen sind mir jetzt noch ein paar "uninitialized"-Warnungen über den Weg gelaufen... Fix anbei.

EDIT: Modul ist im svn/contrib eingecheckt

[drhirn]

So, diskutieren wir mal drüber, wie wir jetzt dokumentieren sollen? Ich bin bereit, die Doku auf GitHub und Englisch als Sprache aufzugeben. Hätte dafür aber gerne einen guten Plan, wie wir die Doku im Wiki strukturieren .
Sollen wir alles auf eine Wiki-Seite packen, oder machen wir mehrere? Sollen wir die CRef wirklich so ausführlich lassen, oder verschieben wir Teile davon ins Wiki? Oder sollen wir die CRef nochmal auf deutsch ins Wiki übernehmen? Sollen wir das hier diskutieren, oder in einem eigenen Beitrag?

Extrem cool wär ja, wenn man einfach EIN Markdown-File erstellen könnte, das dann automatisch in HTML für die Cref und Wiki-Markdown umgewandelt wird . Für die CRef hab ich sowas mal gesehen glaub ich. Für's Wiki halt leider nicht.

[Beta-User]

Sorry, das hier hatte ich gestern nicht beantwortet:

Ich hab gerade folgende DEF:

Code Auswählen Erweitern

baseUrl=http://rhasspy:12101 defaultRoom=wohnzimmer language=de devspec=room=Rhasspy handleHotword

Stimmt das mit dem handleHotword so? Weil, ich bekomm da kein Reading. Erst, wenn ich das Attribut entsprechend setze.

So sollte das auch ohne Attribut klappen.

Code Auswählen Erweitern

baseUrl=http://rhasspy:12101 defaultRoom=wohnzimmer language=de devspec=room=Rhasspy handleHotword=1
Der Teil ist eigentlich auch schon in der commandref (define und Attribut) enthalten .

Soweit ich das im Moment überblicken kann, fehlt in der commandref eigentlich nur das mit der neuen setter-Idee - da bin ich aber noch nicht dazu gekommen, irgendwas substantielles auszutesten => might be subject to changes...

Alles andere sollte zumindest als Stichwort (und jeweils - wo erforderlich - mit einem Mini-Beispiel-Schnipsel) in der commandref enthalten sein.

So, diskutieren wir mal drüber, wie wir jetzt dokumentieren sollen? [...] Sollen wir die CRef wirklich so ausführlich lassen, oder verschieben wir Teile davon ins Wiki?

Eine commandref sollte
1. es (global gedacht) ermöglichen, ein Modul in Betrieb nehmen zu können, ohne weitere Doku dazu zu brauchen;
2. alle Optionen enthalten/dokumentieren, die man im Modul (bzw. in den durch das Modul verteilten Attribute) einstellen kann;

Ad 1.: gefühlter Erfüllungsgrad: na ja, vielleicht grade so . Ist in dem Fall aber so oder so schwierig, weil auch Konfiguration auf der Rhasspy-Seite erforderlich ist, und sich das wechselseitig bedingt. Daher ggf. die Überlegung, einen engl. Quickstart in die commandref zu packen. Wird dadurch halt noch länger... Die Frage ist dann höchstens, ob man dann auf eine ergänzende en-Doku irgendwo anders verzichten könnte

Ad 2.: gefühlter Erfüllungsgrad: m.E. eigentlich mehr als passabel. V.a. finde ich es gut und richtig, mehr oder weniger kurze Erläuterungen zu den rhasspy-Attributen direkt bei den Geräten zu sehen, selbst wenn die "Kurzfassung" bei "Specials" schon etwas lang ist...
Dies Teile sind aber eigentlich die, die die Gesamtlänge der commandref im Wesentlichen bedingen. Da würde ich ungern Abstriche machen wollen, manches braucht ggf. noch etwas Feinschliff, mir sind auch grade wieder ein paar Kleinigkeiten beim Drübersehen aufgefallen.

Ich bin bereit, die Doku auf GitHub und Englisch als Sprache aufzugeben. Hätte dafür aber gerne einen guten Plan, wie wir die Doku im Wiki strukturieren .

An Github hing ich ja noch nie , und für den allgemeinen Fahrplan bzgl. english sollte man vermutlich vorab klären, wie viel/was und wie in die commandref soll. Zumindest wesentliche Teile zu def/set/attr sind im Moment gedoppelt, der derzeitige Mehrwert der dortigen Doku sind die hinteren Teile ab #intents.
Nach meinem jetzigen Bauchgefühl würde es Sinn machen, den (noch zu übersetzenden) Quickstart und diesen hinteren Teil als Rhasspy/en ins Wiki zu übernehmen? (Und aus der commandref dann dahin zu verlinken).

Sollen wir alles auf eine Wiki-Seite packen, oder machen wir mehrere? [...] Oder sollen wir die CRef nochmal auf deutsch ins Wiki übernehmen? Sollen wir das hier diskutieren, oder in einem eigenen Beitrag?

Die erste Frage würde ich dann beantworten, wenn wir den Gesamtumfang sehen.
1:1 zu übersetzen finde ich nicht den großen Mehrwert, v.a. ist das Aufwand/Nutzen-Verhältnis m.E. nicht akzeptabel (schon klar, dass es einige User gibt, die sich mit englisch schwer tun, aber denen ist m.E. anders besser geholfen*).
Mittelfristig ist die Diskussion vermutlich im Wiki-Bereich besser aufgehoben, andererseits sind hier die derzeitigen User beieinander und können direkt ihre Meinung äußern. Das Problem dabei ist nur, dass die meisten vermutlich im Wesentlichen die Einrichtung noch "old-school" gemacht hatten, und daher diese komplett andere Herangehensweise über genericDeviceType, die ich grade propagiere (teilweise (!) & noch) nicht nachvollziehen können?

ad * - im Moment fehlt nach meinem Geschmack ungefähr folgendes:
- eine Art "einfach"-sentences.ini mit allen slots, die man direkt verwenden kann, ohne dass sich die Dinge gegenseitig ins Gehege kommen (=>Verwendung der eingeschränkten slots und weniger Varianten, also nicht "(schalte|mach)", sondern nur "schalte", aber dafür bei an/aus -media/-switch/-light und bei auf/zu -blind)
- die Darstellung der kompletten Konfiguration von diversen "Muster-Geräten", also z.B.
-- blind: eines CUL_HM-Rollladens, einer ZWave-Jalousie und eines "Custom"-Rollladens ohne numerischen Setter;
-- light: auch hier mehrere Varianten, ggf. mit Szenen (HUEDevice), ...
Meine Erwartung: So kann man sich das Zusammenspiel der Attribute besser erarbeiten?

@pah: Speziell deine Meinung als "Novize" und Experte in der Vermittlung derartigen Wissens zu diesem ganzen Themenkreis würde mich sehr interessieren!
(@all others: Das bedeutet ausdrücklich nicht, dass ihr ruhig bleiben solltet!).

Extrem cool wär ja, wenn man einfach EIN Markdown-File erstellen könnte, das dann automatisch in HTML für die Cref und Wiki-Markdown umgewandelt wird . Für die CRef hab ich sowas mal gesehen glaub ich. Für's Wiki halt leider nicht.

Entsprechender Converter-Tools gibt es, allerdings vergesse ich immer, wie das geht, und m.E. müßte man so oder so klären, ob eine "Einheitsdokumentation" sinnvoll ist (ich meine: nein).

Anbei auch die (funktional nicht geänderte) Fassung mit den kleineren Änderungen an der commandref.

[drhirn]

Sorry, das hier hatte ich gestern nicht beantwortet:So sollte das auch ohne Attribut klappen.

Code Auswählen Erweitern

baseUrl=http://rhasspy:12101 defaultRoom=wohnzimmer language=de devspec=room=Rhasspy handleHotword=1
Der Teil ist eigentlich auch schon in der commandref (define und Attribut) enthalten .

Das =1 war mir nicht klar. Ist auch in der CRef so nicht beschrieben. Und im Define-Code fehlt's auch.

Über alles andere muss ich zuerst nachdenken.

[ph1959de]

Zum Thema "dokumentieren" - insbesondere im Wiki - habe ich folgende Vorschläge (und teilweise schon umgesetzt):

• [erledigt]die Seite RHASSPY wird von einer Weiterleitungsseite zur "Standard" Modulseite im Wiki; die Seite heißt genau wie das Modul und das in identischer Schreibweise, damit ist sie auch prädestiniert für die {{Infobox Modul}} Vorlage. Damit sind auch Basisinformationen wie Autor, Modultyp, Forenbereich, etc. gleich dokumentiert
• Darüber hinaus kann die Seite Modul-spezifische Informationen, Beispiele, Status, ... enthalten
• [erledigt] "Infobox Modul" wird aus der Seite Fhem-rhasspy entfernt; es wird (üblicherweise nur einmal, beim ersten Auftreten) die Modulseite wiki-üblich "verlinkt" ([[RHASSPY]])
• Der Rest pass so, wie er gerade ist

Ich habe die meisten Code-/Konfigurationsbeispiele auf <syntaxhighlight> Tags (lang="Text", sollte jemand einen passenden Lexer kennen, kann das natürlich gern angepasst werden) umgestellt, damit werden unter Anderem auch Formatierungsprobleme mit URLs vermieden.

Eine Anregung noch: an manchen Stellen würde {{RandNotiz...}} dem {{Hinweis}} vorziehen, weil dadurch der Lesefluss nicht so stark unterbrochen wird.

Zum großen Thema "EIN Markdown" habe ich leider keine Lösung parat.

Peter

[Beta-User]

[...] und teilweise schon umgesetzt):

Danke! (auch für die weiteren Anmerkungen)

Irgendwie war es mir entgangen, dass im Wiki seit meinem ersten Wurf schon wieder von mehreren Seiten einiges erfolgt ist, sorry!

im Define-Code fehlt's auch.

Na ja, es findet sich was in den "extended examples"...

Über alles andere muss ich zuerst nachdenken.

Ging/geht mir auch so!

Vielleicht noch einige Anmerkungen von meiner Seite zum Ganzen:
- RHASSPY war für mich erst notwendiges Übel (ich konnte nicht von drhirn fordern, dass bestimmte "Soll-Anforderungen" eingehalten werden, ohne selbst zu zeigen, wie es geht ), dann eine nette Fingerübung, um in Perl mal "richtig was" zu machen . Mit 0.4.xx hatten wir dann einen Stand erreicht, der ungemein flexibel ist , und bei dem (nach ein paar Handgriffen) sehr vieles automatisch geht, der aber noch in "rhasspyMapping" verhaftet war;
- das lief jetzt völlig stressfrei für einige Monate, und das anscheinend nicht nur bei mir, sondern auch bei anderen.
Soweit so gut. Die (Doku-) Struktur paßte zum Nutzerkreis (lauter "Eingeschworene") und war eigentlich zweitrangig (aber gemessen an diesen Maßstäben exzellent!), weil bei denen ja soweiso jeder im großen und ganzen weiß, wie es prinzipiell funktioniert.
- zwischenzeitlich ist nicht nur eine kleine Schar weiterer Interessenden/Nutzer dabei, sich mit dem Thema zu befassen, sondern mir ist vor ein paar Tagen mal eine Spiegel-Beilage in die Hände gefallen, in der die Botschaft sinngemäß an mehreren Stellen hieß: Man braucht Internet (im Sinne einer "cloud"), um "richtige" Hausautomatisierung zu machen...

Das war dann für mich der Anlass, das Gegenteil zu beweisen und die jüngsten Umbauten in Angriff zu nehmen, mit den Zielen:
- der User soll für "Standard-Geräte" nicht viel mehr machen müssen wie diese RHASSPY zu unterstellen (=idR. gDT setzen) und ein paar "Namenslabel" dranzupappen (Prio 1);
- ein Interface zu generieren, dass man ggf. die Spracherkennung (speech to text) auch "außerhalb" machen lassen kann (Mitbewohner diktiert was mit "seinem Lieblings-System" an Telegram, z.B.), das dann intern mit Rhasspy als backend ausgewertet und für RHASSPY vorbereitet wird (Prio 2).

Denn: FHEM ist cloud-free, (was nicht bedeutet, dass man es nicht anders machen darf (!),) und es sollte eine gute (und m.E. daher auch offizielle) Lösung _wie_ RHASSPY/Rhasspy geben, mit der man den "Inputweg" Sprache bedienen kann. Soweit ich das bisher beurteilen kann, gibt es keine ernsthafte Konkurrenz, so dass ich aus diesem Grund dazu tendieren würde, sogar den Schritt in Richtung eines offiziellen Moduls zu erwägen, falls nicht einer der Experten (insbes. @pah) sich gegenteilig dazu äußert.

PS: ich schreibe das nicht unbedingt gerne, weil ein nicht unerheblicher support-Aufwand zu befürchten ist. Da das Modul an sich aber steht, und der "Stresstest" mit diesem außergewöhnlichen "blind" gezeigt hat, wie flexibel die Lösung im Ergebnis ist, kann man m.E. diesen Schritt jetzt prinzipiell gehen. Doku ist dazu dann eben "notwendiges Übel", und wir sollten die beiden "Neulinge" bitten, den Weg für "users to come" (mit) vorzubereiten. "whatever it takes"...

[drhirn]

Zum Thema "dokumentieren" - insbesondere im Wiki - habe ich folgende Vorschläge (und teilweise schon umgesetzt):

So, jetzt bin ich verwirrt . V.a., weil ich ja gerade gestern Änderungen vorgenommen habe.

RHASSPY soll die Haupt-Seite werden?
Rhasspy und fhem-rhasspy Weiterleitungen auf RHASSPY?

Ich könnte gut damit leben. In meinem Kopf hieß das Modul nur einfach immer fhem-rhasspy um Verwechslungen vorzubeugen (Rhasspy/RHASSPY).

Eine Anregung noch: an manchen Stellen würde {{RandNotiz...}} dem {{Hinweis}} vorziehen, weil dadurch der Lesefluss nicht so stark unterbrochen wird.

Jup, war noch geplant.

[Beta-User]

RHASSPY soll die Haupt-Seite werden?
Rhasspy und fhem-rhasspy Weiterleitungen auf RHASSPY?

Vorab: "Rhasspy" war vermutlich in der Tat keine gute Idee, da im Internet case-sensitive immer Mist ist. RHASSPY als Modul-Seite finde ich daher gut, und ich finde es auch gut, dass es eine weitere Seite gibt (Benennung weiß ich noch nicht so recht...).

Die "Modulseite" kann m.E. durchaus Basics zur Einrichtung enthalten, wobei ich dazu neigen würde, nur die "simple" Variante (incl. MQTT2_CLIENT) darzustellen, vielleicht noch was zu "devspec" und "baseId" zu sagen und für die ganzen anderen Optionen auf den "Quickstart" und/oder die commandref zu verweisen.

Ansonsten hatte ich "ganz früher" mal gespickelt, wie das anderswo so gemacht wird und hatte mir den Link auf diese Seite als "Basistemplate" notiert: https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa.

[drhirn]

Mit Weiterleitungen bekommen wir das schon hin.

Ich hätte den Quickstart auf eine eigene Seite ausgelagert (RHASSPY/Schnellstart) und unter Umständen etwas gekürzt. Den aber gleich am Anfang der Seite RHASSPY prominent verlinkt. Auf der Seite RHASSPY dann detailliertere Informationen zur Funktionsweise.
Ich bin mir nur noch nicht sicher, wie wir mit den Intents tun sollen. Eigene Seite für alle, eigene Seite für jeden einzelnen (bissi übertrieben) oder die gleich auf RHASSPY einbauen.

[Beta-User]

Ich bin mir nur noch nicht sicher, wie wir mit den Intents tun sollen. Eigene Seite für alle, eigene Seite für jeden einzelnen (bissi übertrieben) oder die gleich auf RHASSPY einbauen.

Intents und sentences.ini sind m.E. "Vorder- und Rückseite" der Medaille. Das muss zusammenpassen, und einen "Grundstock" zu haben, schadet m.E. nicht. Meine momentane Tendenz zu diesem Punkt wäre, eine "vereinfachte" sentences.ini (aber unter Verwendung der spezifischen slots) bereitzustellen. Das als "Abschluss" zum QuickStart? Da müssen uU. nicht alle Intents rein, was genau, wäre noch zu klären (die timer-Geschichten sind halt direkt ziemlich komplex).
Da sich die slots von FHEM aus automatisch füllen, wäre so der erste Erfolg sehr schnell zu erzielen und die slots sind dann eigentlich auch direkt verständlich, weil erkennbar ist, was man sagen muss... Das verbleibende Problem dabei sind ggf. die "unaussprechlichen Namen", die man erst beseitigen muss, aber was das angeht, sollte auch nach den ersten Abschnitten im Quickstart klar sein, wie das läuft?

[drhirn]

Hmmmmm
Den Quickstart hätte ich nach "Erstes Gerät steuern" beendet. Sonst ist's ja kein Quickstart mehr

[Beta-User]

Hmmmmm
Den Quickstart hätte ich nach "Erstes Gerät steuern" beendet. Sonst ist's ja kein Quickstart mehr

...die Argumentation hat was für sich...

So war auch mein erster Gedanke, als ich mit dem Artikelchen gestartet war. Dann ist mir aufgefallen, dass da irgendwie ein paar auf der Hand liegende Fragen nach einer Antwort schreien (Gruppen, nummerische Werte, Farben), und der aktuelle Status quo ruft eigentlich auch noch nach "und wie geht es jetzt weiter" mit ein paar Links und Hinweisen.

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...