Modulentwicklung für Rhasspy Sprachassistent

[drhirn]

Ich sag's euch ganz ehrlich: In Österreich hat gestern nach einem halben Jahr endlich die Gastronomie wieder aufgesperrt. Ich kann daher erst sinnvoll antworten, wenn mein Hirn wieder richtig funktioniert.

Bitte kriegt nicht den Eindruck ich würde nur meckern wollen...

Hab das nicht als meckern empfunden. Sehr hilfreiche Anmerkungen bisher.

[Beta-User]

Glückwunsch zur "neuen" alten Freiheit!
"Genieße es" ...


Anbei dann gleich der Versuch, Fehleingaben in der DEF sinnvoll zurückzumelden (angetestet) und das automatische Erstellen des Shortcut-Slots zu verhindern (ungetestet, aber optimistisch).
(Für sowas braucht man kaum länger als eine Frühstückspause ).

[DrBasch]

Anbei dann erst mal eine Version, die die uninitialized-Warnung bei nicht gesetztem IODev-Attribut vermeidet und dann auf Reading/Internal zurückgreift - samt entsprechender Anpassung der cref. Bin auch noch nicht ganz durch, aber mAn. wird das Attribut künftig nicht mehr automatisch gesetzt.

Mann, bist Du schnell...

Vermutlich wird sich das aber "nur" darauf beschränken müssen, das auf korrekte Schreibweise der "Schlüsselworte" (und evtl. die Zahl der unbenannten Parameter) zu checken.

Mehr als eine Testung der Schlüsselwortsyntax hatte ich mir auch nicht vorgestellt. Die Werte, die zugewiesen werden, hat mE jeder Anwender selbst zu verantworten. Eine Prüfung, ob der mit baseUrl übergebene String eine valide URL ist wäre natürlich ein Träumchen.
Was die Zahl der unbenannten Parameter helfen soll verstehe ich ehrlich gesagt gerade nicht... Wenn man es aber auf die Spitze treiben will, könnte man noch noch auf Duplikate testen.

a) Weiß nicht, ob wir den "automatisiert erstellten" OnOff-Slot (via rhasspy-de.cfg) bereits implementiert haben bzw. das schon im svn ist. Machbar wäre es jedenfalls dafür zu sorgen, dass erst mal jeder ein relativ schnelles "hello world" zustande bringen kann, ohne sich (bis dahin)  intensiver mit der Rhasspy-Seite auseinandersetzen zu müssen.
b) das mit den leeren Shortcuts ist auf der ToDo-Liste, sollte sich ohne größere Aufwände vermeiden lassen.
c) Für jeden Intent eine eigene ini anzulegen erscheint mir sinnvoll. Ist zwar im ersten Moment unübersichtlicher, aber bei Überarbeitungen deutlich weniger fehleranfällig.

Asche auf mein Haupt! die rhasspy-de.cfg hab ich mir ehrlich gesagt noch garnicht angeschaut.
Für mich war es einerseits gut, die leeren Shortcuts zu sehen ("It works!"). Andererseits hat es mich irritiert, weil wie gesagt keine sentences eingetragen wurden  ("It works... maybe?... partialliy?").
Spontan könnte ich mir auch vorstellen, dass man die Shortcuts.ini mit einer (sehr kurzen) "burn after reading" Einweisung füllt.

Meine Bitte bzw. mein Vorschlag:
Wir brauchen (wieder) jemanden wie cb2sela, der hilft, eine passende (de-) Doku zu verfassen und die verbleibenden Lücken in der Doku, in der cref, in der rhasspy-de.cfg aufzuspüren, (uninitialized-warnings zu jagen) und ggf. mal ausführlichere Rückmeldung zum "gDT-Way" gibt.

Ich werde heute Nacht mal anfangen meine Erfahrungen im Hinblick auf die Rhasspy Einrichtung - im Sinne einer Step-By-Step-Anleitung - zusammenschreiben. Ich muss ja sowieso noch vom Test- aufs Produktivsystem portieren und nochmal alles durchgehen. Wenn es dann dort läuft, fängt die eigentliche Konfiguration dann ja erst richtig an und ich werde mich intensiver mit der Doku und dem "FHEM und Rhasspy"-Thread auseinandersetzen müssen... will sagen: Ihr hört von mir

[Beta-User]

Mehr als eine Testung der Schlüsselwortsyntax hatte ich mir auch nicht vorgestellt. Die Werte, die zugewiesen werden, hat mE jeder Anwender selbst zu verantworten. Eine Prüfung, ob der mit baseUrl übergebene String eine valide URL ist wäre natürlich ein Träumchen.

Die "Quittung" für falsche Parameter bekommt man eben durch "geht nicht" bzw. "offline", wenn es die URL ist. Ein bißchen Mitdenken darf dann der User auch .

Was die Zahl der unbenannten Parameter helfen soll verstehe ich ehrlich gesagt gerade nicht... Wenn man es aber auf die Spitze treiben will, könnte man noch noch auf Duplikate testen.

Wenn mehr als TYPE und NAME angegeben sind, liegt der Verdacht nahe, dass es zu viele sind, und ab 4 liegt sicher ein Fehler vor, aber

Ein bißchen Mitdenken darf dann der User auch

Solche Fehler führen aber in der Regel nicht zu schwerwiegenden Problemen, daher würde ich für meinen Teil sagen: lassen wir es an der Stelle gut sein...

Asche auf mein Haupt! die rhasspy-de.cfg hab ich mir ehrlich gesagt noch garnicht angeschaut.

Nevermind; es ist halt doch ein "größeres Puzzle", bei dem man typischerweise nicht alle Teile gleich beim ersten Anlauf findet und korrekt hinlegt. Ist in der Regel kein dauerhaftes Thema, weil (noch) die wenigsten mit englisch zufrieden sind ...

Für mich war es einerseits gut, die leeren Shortcuts zu sehen ("It works!"). Andererseits hat es mich irritiert, weil wie gesagt keine sentences eingetragen wurden  ("It works... maybe?... partialliy?").

Das "it works"-Gefühl sollte sich schon dadurch einstellen, dass einige slots erstellt werden (mit den letzten Versionen dann nochmal deutlich mehr, als bei den vorherigen Fassungen). Aber ein leeres und unfunktionales Shortcut.ini ist nicht gut und eine unbeabsichtige Nebenwirkung meiner in Code gegossener These, dass filigranere slots "gut" wären und lieber auch leere erstellt werden sollten (damit Rhasspy nicht von vornherein meckert, weil bestimmte Variablen aus den (noch nicht vorhandenen Muster-) sentences.ini nicht vorhanden sind).

Spontan könnte ich mir auch vorstellen, dass man die Shortcuts.ini mit einer (sehr kurzen) "burn after reading" Einweisung füllt.

Da Rhasspy das dann irgendwie zu verarbeiten versuchen würde und dann ggf. wieder versuchen, daraus MQTT-Payload zu generieren, ist das meinem Bauchgefühl nach keine gute Idee. Da Shortcuts ansonsten "autonom" ist, ist es hier egal, ob das nun erstellt wird oder nicht => raus damit...

Ich werde heute Nacht mal anfangen meine Erfahrungen im Hinblick auf die Rhasspy Einrichtung - im Sinne einer Step-By-Step-Anleitung - zusammenschreiben. Ich muss ja sowieso noch vom Test- aufs Produktivsystem portieren und nochmal alles durchgehen. Wenn es dann dort läuft, fängt die eigentliche Konfiguration dann ja erst richtig an und ich werde mich intensiver mit der Doku und dem "FHEM und Rhasspy"-Thread auseinandersetzen müssen... will sagen: Ihr hört von mir

Das mit dem Zusammenschreiben finde ich klasse, das mit dem Thread eher weniger.
"Mein" gedankliches Poblem: Da stehen ein paar Lösungen drin, die mAn. schon wieder "outdated" sind (aber ggf. weiter funktionieren!). Wenn wir eine "zeitgemäße" Anleitung haben wollen, wäre der Versuch (im Sinne aller Nachkommenden gedacht) hilfreicher, das _nur mit commandref_ und ggf. einem neuen Fragethread zu lösen. Wo es noch paßt, kann man dann ja direkt zu den betreffenden einzelnen Beiträgen/Abschnitten innerhalb des "Monsterthreads" verweisen.
Mehr Aufwand (v.a. für dich), aber ggf. hilfreich bzgl. der "alten Zöpfe". Dafür mit "Individualbetreuung"...

[DrBasch]

Wenn mehr als TYPE und NAME angegeben sind, liegt der Verdacht nahe, dass es zu viele sind, und ab 4 liegt sicher ein Fehler vor, ...

Das möchte ich gerade verstehen, tu mich aber noch etwas schwer damit...Meinst du mit TYPE/NAME z.B. "define ... baseUrl[TYPE]=127.0.0.1:12101[NAME]?

Das mit dem Zusammenschreiben finde ich klasse, das mit dem Thread eher weniger.
"Mein" gedankliches Poblem: Da stehen ein paar Lösungen drin, die mAn. schon wieder "outdated" sind (aber ggf. weiter funktionieren!).
Wenn wir eine "zeitgemäße" Anleitung haben wollen, wäre der Versuch (im Sinne aller Nachkommenden gedacht) hilfreicher, das _nur mit commandref_ und ggf. einem neuen Fragethread zu lösen. Wo es noch paßt, kann man dann ja direkt zu den betreffenden einzelnen Beiträgen/Abschnitten innerhalb des "Monsterthreads" verweisen.

Je mehr ich darüber nachdenke, umso mehr muss ich Dir Recht geben. Qualität vor Quantität!

Ich habe im Übrigen angefangen, meinen Installationsweg zu dokumentieren, musste aber von der Idee abrücken, das im Rahmen des Umzugs auf mein Haupt-FHEM zu machen... Ich habe also den Test-RasPi neu aufgesetzt und protokolliere nochmal stoisch alle Schritte mit. Bin jetzt mit der Rhasspy Einrichtung durch und würde dann morgen Abend mit der RHASSPY-Einrichtung weitermachen. Am WE kann ich dann hoffentlich das Protokoll gliedern und in eine lesbare Form formatieren.

[Beta-User]

Je mehr ich darüber nachdenke, [...]

Dann mal willkommen an Bord!

Du solltest dann möglichst die letzte hier verfügbare Fassung im Einsatz haben (und die zugehörige rhasspy-de.cfg).
@drhirn: spricht was dagegen, die im svn einzuchecken?

Bin jetzt mit der Rhasspy Einrichtung durch

Habe mir das Einrichtungs-git auch nochmal angesehen:
- Zu docker kann ich nichts beitragen, das dürfte aber aktuell sein (ich habe den debian-Weg genommen, siehe meinen gesonderten Thread dazu; heißt aber ausdrücklich nicht, dass das "besser" wäre, sondern nur, dass mir dieser Weg näher lag/sympatischer war!).
- an der sentences.ini sollte man m.E. nicht direkt rumschrauben. "Zu meiner Zeit" hat direkt der vorhandene "Wie spät ist es"-Satz genügt, um von FHEM eine Antwort zu erhalten, jetzt muss man m.E. den intent anfassen und ein "de.fhem:" davorsetzen (bei ensprechender language/fhemId).
MAn. wäre das das "geschicktere" "hello world 1"-Erlebnis...

Hat nämlich zwei Vorteile:
- man braucht keine Hardware und keine dummy (s.u.)
- man bekommt (hoffentlich) direkt nach der RHASSPY-Einrichtung eine Antwort - allerdings in schönstem "denglish" und ist damit gleich beim nächsten Thema, nämlich der language-file...

Dein "Erstling" mit dummy hatte m.E. zwei Nachteile:
- Es ist ein dummy!
- Du hattest es "klassisch" gemacht (mit rhasspyMapping)

dummy werden leider inflationär genutzt (OT: es ist besser geworden), von daher würde ich - so es irgend möglich ist - empfehlen, echte Hardware anzusteuern. Optimal wäre da ein farbiges HUEDevice (die bridge kann man ja mehrfach "anzapfen", also insbesondere auch von einem Testsystem aus), alternativ (aber schwieriger) eine dimmbare (und ggf. farbige) MQTT2_DEVICE-Leuchte (ob ursprünglich zigbee2mqtt, Tasmota oder Shelly oder sonst was ist egal); das ist nur etwas schwieriger, aber wer Testhardware hat, kann ja auch einen MQTT2_SERVER kurz dafür auf dem Testsystem aufziehen.   
dummy braucht darüber hinaus auch sinnvolle setList-Angaben, damit das mit genericDeviceType klappt, und da kommt vermutlich der eine oder andere ins Schleudern bzw. es wird auch der "Vorteil" der automatisierten Erkennung verwässert.
MAn. ist der "aha"-Effekt viel größer, wenn man reale Hardware nimmt, weil dann mehr oder weniger unmittelbar sichtbar wird, was RHASSPY erkennen/auswerten kann (und was ggf. nicht). (Wenn da noch was fehlt, können wir in dem Zuge dann auch noch nachlegen).

Bzgl. der unmittelbaren sentences.ini-Anpassung: In den letzten Versionen  sind  mehr slots verfügbar, so dass ein {Device} für einen OnOff-Intent m.E. nicht mehr optimal ist - man sollte das daher mAn. dann direkt wieder ändern, und fragt sich dann vermutlich, welchen Sinn die erste Änderung denn eigentlich hatte...

Daher sollte man dann nach der Vergabe des gDT-Attributs an ein (von der devspec erfasstes) reales Device mal "update devicemap" machen und sich anschließend erst das RHASSPY-list und dann die ganzen slots ansehen . (bin nur unschlüssig, ob man erst mal "nur vorhandene slots generieren" aktivieren sollte?).

Das möchte ich gerade verstehen, [...]

An DefFn() wird die Definition

Code Auswählen Erweitern


define myPorcupine RHASSPY Element3 Element4 Element5
(parseParams ist aktiviert) als Liste (Array) mit den unbenannten Elementen beginnend ab "myPorcupine" (=> NAME als Internal) übergeben. Das Beispiel hat also 5 unbenannte Argumente, das Modul verarbeitet offiziell aber nur zwei (NAME und TYPE (=RHASSPY)).

Bei

Code Auswählen Erweitern


define myPorcupine RHASSPY Element6 Element5=bla Element3="das ist ein Test" Element4="blub"
hätte man 3 unbenannte Argumente und 3 benannte, das "richtig fehlerhafte" Beispiel

Code Auswählen Erweitern


define myPorcupine RHASSPY Element6 Element5=bla Element3=das ist ein weiterer Test Element4="blub"
liefert 7 unbenannte und 3 benannte.
Klarer jetzt?

[DrBasch]

Dann mal willkommen an Bord!

Danke und Ahoi, Käpt'n

Du solltest dann möglichst die letzte hier verfügbare Fassung im Einsatz haben (und die zugehörige rhasspy-de.cfg).

Klar, ich hatte schon die gestern von Dir hier eingestellte Version (0.4.15, glaube ich) gezogen und werde - wenn es soweit ist - nochmal nachschauen ob Ihr schon wieder nachgelegt habt.

- Zu docker kann ich nichts beitragen, das dürfte aber aktuell sein (ich habe den debian-Weg genommen, siehe meinen gesonderten Thread dazu; heißt aber ausdrücklich nicht, dass das "besser" wäre, sondern nur, dass mir dieser Weg näher lag/sympatischer war!).

Docker + Rhasspy-Container laufen schon. Die docker-Installation ist imho der einfachste/userfreundlichste (aber nicht unbedingt "bessere" Installationsweg). Am der .venv-Variante war ich zuvor gescheitetert: u.a. gibt es mit der aktuellen Rhasspy bzw. RasPi OS-Version Probleme bei der Compilierung, so man das Makefile händisch editieren muss.
Ich suche mir aber nochmal deine Ausführungen bezgl. debian dazu raus. Es schadet mE nicht die Installationsvarianten zu dokumentieren und "docker-free" wäre mir persönlich auch lieber. Meine euphorische Docker-Phase hab ich hinter mir...

Etwas Kopfzerbrechen bereitet mir noch ob - und wenn ja in welcher Form - man in einem Wiki auf die Installation der Treiber eingehen kann/sollte/muss. Für die ReSpeaker z.B. muss man ja seeed-voicecard-Treiber installieren, die Originaltreiber (https://github.com/respeaker/seeed-voicecard sind derzeit ohne Kernel-Downgrade nicht verwendbar und der fork von HinTak ist ... naja ... halt ein fork. Wie lange gibt es den noch?
Wenn man auf die Installation von ReSpeaker-Treibern eingeht, was "bietet" man Usern an, die z.B. eine PS Eye Camera an den Start bringen wollen? ("Nix" ist diesbzgl. sicher _eine_ Lösung).
Was mich gleich zur nächsten Unschlüssigkeit bringt: Wo holt man den User ab? / Wo steigt man - i.S.e Wiki-HowTo - ein? / Welche "Voraussetzungen" (hard- bzw. softwareseitig) sollten definiert werden?

- an der sentences.ini sollte man m.E. nicht direkt rumschrauben. "Zu meiner Zeit" hat direkt der vorhandene "Wie spät ist es"-Satz genügt, um von FHEM eine Antwort zu erhalten, jetzt muss man m.E. den intent anfassen und ein "de.fhem:" davorsetzen (bei ensprechender language/fhemId).

Na, dass werde ich heute abend dann gleich ausprobieren...
Das denglische Text to Speech hab ich schon kennengelernt: "Sorry but something seems not to work as expected" -> ROTFL.

- Du hattest es "klassisch" gemacht (mit rhasspyMapping)

Stimmt, obgleich ich quasi jeden Anlauf mit devspec=genericDeviceType=.+ begonnen habe. Als es dann nicht funktioniert hat, hab ich verbogen was ich konnte, in der Hoffnung es zum Laufen zu kriegen... Und dabei - wie du ja auch angemerkt hast - das ein oder andere Mal "attr Dummy setList on off" vergessen.

...von daher würde ich - so es irgend möglich ist - empfehlen, echte Hardware anzusteuern...

HUEDevices hab ich leider nicht. Kurzfristig werde ich versuchen Schaltsteckdosen, Heizkörperthermostaten, Fenstersensoren anzusteuern. Mittelfristig kommen dann sicherlich noch eine (derzeit noch orginalverpackte) zigbee Leuchte, eine HarmonyOne und Sonos-Devices dazu.

Ferner sehe ich dann noch CALENDAR-Devices ("Welche Termine habe ich/haben wir/hat XYZ heute?"), ABFALL- und Wetter-Module ("Wann kommt die Müllabfuhr?", "Wie wird das Wetter?/Wird es regnen?" o.s.ä) u. PostMe-Listen für Einkaufszettel/ToDo-Listen ein (Keine Ahnung, ob das überhaupt realiserbar ist, dürfte von seiten Rhasspys offline-"Wortschatz" schwierig werden). Das sehe ich aber eher als "Privat-Projekte" die ich nicht in ein Wiki/cref sondern bestenfalls in einen Thread dokumentieren würde.

Daher sollte man dann nach der Vergabe des gDT-Attributs an ein (von der devspec erfasstes) reales Device mal "update devicemap" machen und sich anschließend erst das RHASSPY-list und dann die ganzen slots ansehen

...Ist notiert! Mach ich.

Klarer jetzt?

Definitiv! Jetzt verstehe ich, was du mit

Wenn mehr als TYPE und NAME angegeben sind, liegt der Verdacht nahe, dass es zu viele sind, und ab 4 liegt sicher ein Fehler vor

meintest.

Sorry, wenn ich so viel nachhake... Ich bin bzgl. MQTT, Softwareentwicklung (iHa die modulare FHEM-Architektur) und Perl echt unerfahren und gedanklich auf die Wege fixiert, die mir bei kleinen Projekten und Problemstellungen geholfen haben.

[Beta-User]

Klar, ich hatte schon die gestern von Dir hier eingestellte Version (0.4.15, glaube ich) gezogen und werde - wenn es soweit ist - nochmal nachschauen ob Ihr schon wieder nachgelegt habt.

Dachte ich mir, und - jedenfalls von meiner Seite - wird es immer erst mal hier die Info geben, was es neues gibt (und zumindest rudimentär, was sich geändert hat).
Im Moment sollte da erst mal wenig neues kommen, allenfalls Reaktionen auf gefundene "uninitialized" bzw. aufgegriffene Anregungen von mutigen "Matrosen" .

Docker + Rhasspy-Container [...] debian [...] ob - und wenn ja in welcher Form - man in einem Wiki auf die Installation der Treiber eingehen kann/sollte/muss.

Klares statement von meiner Seite: Die Rhasspy-Installation muss der User "alleine" hinbekommen.
Man _kann_ ggf. einen Weg (docker) als "geprüftes Muster" mit aufnehmen, aber eben unter dem für externe Projekte "üblichen Vorbehalt", dass das nur eine Momentaufnahme ist und man bitte im externen Projekt nachfragen soll, wenn was unklar ist. Man kann auch gerne auf die "hardwarelose" Variante verweisen, die ich unter Debian mit der App betreibe, aber auch da sollte (mAn.) nicht mehr als der Link zum Thread zu finden sein. Sonst wird das uferlos und veraltet auch zu schnell...

Was mich gleich zur nächsten Unschlüssigkeit bringt: Wo holt man den User ab? / Wo steigt man - i.S.e Wiki-HowTo - ein? / Welche "Voraussetzungen" (hard- bzw. softwareseitig) sollten definiert werden?

Wieder meine 2ct: Als Vorbemerkung (im Prinzip) nur rein, wo man Hinweise findet, um (mind.) ein lauffähiges Rhasspy am Start zu haben, aber der eigentliche Einstieg ist: der Dienst läuft, "wie spät ist es" schickt einen MQTT-JSON auf den Weg, die Aufgabe ist ab jetzt, diesen in FHEM auszuwerten und was sinnvolles daraus zu machen...

Das denglische Text to Speech hab ich schon kennengelernt: "Sorry but something seems not to work as expected" -> ROTFL.

Solche - mal mehr, mal weniger erheiternden - Momente braucht es (bei mir war es die Uhrzeit, und die "allSets" von einem MQTT2_DEVICE vorgelesen zu bekommen, hat auch seinen Reiz (da sind die ganzen attrTemplate-Namen mit drin, ist gefühlt endlos )...), und es ist m.E. auch hilfreich klarzustellen, dass es schon ein ziemlich gutes Zwischenergebnis ist, wenn man zum ersten Mal überhaupt eine Rückmeldung bekommt!

(Wer an dieser Stelle ist, sollte in etwa knapp die Hälfte des Weges haben, btw.! (Aber erst mal eher in der Ausbaustufe "Pfad"  ))

Stimmt, obgleich ich quasi [...]

qed.
(fyi: ich hatte bisher nur den unbestimmten Verdacht, dass das früher oder später jemandem passieren wird und eigentlich nicht damit gerechnet, dass das direkt im Schwarzen ladet...)

HUEDevices hab ich leider nicht.

Was es konkret ist, ist nicht ganz so wichtig. Meine Empfehlung ist ein "onoff"-Device, wenn möglich dimmbar, optimalerweise farbig (da sind nämlich (v.a. bei HUEDevice bzw. allem, was "echtes HUE" kann...) die ersten Stolpersteinchen zu erwarten).
Alternativ ein Rollladenaktor, der aber Krach macht und vergleichsweise träge ist, wenn man korrekte Ergebnisse checken will. Da sollten die meisten Typen ootb laufen, von daher ist das "zweitbeste Wahl".
HK-Thermostate sollten "zur Not" auch gehen, bisher getestet habe ich aber nur CUL_HM, da könnte es also schwierig werden, wenn der setter anders ist als bekannt usw.. (Bei ZWave fehlt z.B. vermutlich "desired-temp" als Reading)
Fenstersensoren hatten wir bisher nicht, aber "contact" als gDT-Typ zu ergänzen sollte ggf. kein Hexenwerk sein, wenn "state" paßt (insbesondere "gekippt" gibt es aber noch nicht als Satz...).

Sonos könnte als "media" auch klappen, ist aber ein Experimentierfeld.

Beim Rest werden wir sehen, was Privatprojekt ist, und wo ggf. Optionen bestehen, eins nach dem anderen, ist doch schon mal was, wenn das Sonos auf play/pause, lauter/leiser und ein/aus reagiert, oder?

Sorry, wenn ich so viel nachhake... Ich bin bzgl. MQTT, Softwareentwicklung (iHa die modulare FHEM-Architektur) und Perl echt unerfahren und gedanklich auf die Wege fixiert, die mir bei kleinen Projekten und Problemstellungen geholfen haben.

Das ist a) völlig ok und b) sehr hilfreich, weil du damit die Chance hast, genau die Fragen zu stellen, die die Mehrzahl der FHEM-User auch hat.

Meine Bitte wäre:
Vermutlich wird die Diskussion über das eine oder andere Detail bei der Einrichtung von konkreten Geräten schon eine Art hilfreicher Doku für alle die, die auf dem jetzigen Stand einsteigen wollen. Wenn du dafür einen eigenen Thread aufmachst, kann man auf den "Prototypen" verweisen, und das ist in der Regel unterhaltsam für die, die das dann irgendwann nachlesen oder nachbauen...
(Es gibt zu diversen mqtt2-attrTemplate-Varianten ein paar solcher Threads, und meistens ist es mir wohl gelungen, solche "Projektchen" zur beiderseitigen Zufriedenheit zu "coachen" (hoffe ich zumindest...). Bei dir habe ich jedenfalls das Gefühl, dass das sehr gut gelingen könnte, die Frage (und die Tonlage ) sind auf einem m.E. "passenden" Niveau.

Immer dann, wenn wir wirklich am Modul was schrauben müssen (neue TYPE für Heizkörperthermostate, z.B.), kommen wir hierher zurück, fixen das Problem und machen im "Prototype"-Thread weiter, wenn klar ist, wie es geht?

[drhirn]

Soooo, wo fang ich an. Hab da ja doch was verpasst.

Vielleicht zum Einstieg mal zur Doku:

• Ich werde keine Wiki-Seite erstellen und auch keine deutsche Doku schreiben. Unterstütze aber gerne, wenn das jemand vor hat.
• Hauptdoku ist und bleibt/soll bleiben CRef (kurz) und GitHub (länger)
• Hinweise, Korrekturen, etc. für die beiden nehme ich aber natürlich dankend an. Bzw. kann jeder via Git mitarbeiten.
• Je verstreuter Dokus sind und je mehr davon's gibt, desto schneller werden sie auseinander laufen. Desto mehr User haben wir, die aufgrund einer veralteten/falschen Doku nicht zum gewünschten Ziel kommen
• Wenn Wiki, dann nur Beispiele, Tips & Tricks oder ähnliches. Keine Dokumentation über das Modul oder Rhasspy
• Generell keine Dokumentation über Rhasspy (Sentences, Slots, Grammatik, Installation, etc.). Das gibt's alles schon extern in guter Form. Wer dazu Fragen hat, wäre im Rhasspy-Forum besser aufgehoben.

Unsere Probleme dabei:
- drhirn und andere, die die Vorversionen schon im Einsatz hatten, haben ihre Systeme "nach guter alter Väter Sitte" konfiguriert und "fremdeln" (noch) etwas mit dem gDT-Ansatz

Üüüüüberhaupt nicht wahr! In meinem produktiven FHEM ist alles, was ging, via gDT konfiguriert

Den "FHEM und Rhasspy"-Thread hab ich zu gemacht. Den Hinweis auf die Anleitung von cb2sela als veraltet markiert.

Wenn die Doku (halbwegs) fertig ist und die aktuelle dev-Version keine größeren Schwächen mehr zeitigt, wäre ggf. dann der Zeitpunkt gekommen, das ganze dann auch "scharf" zu schalten, also das Modul in den regulären update-Zyklus aufzunehmen (wir sollten aber ggf. wissen, wer von den 10 (in statistics) "gemeldeten" Installationen schon auf dem MQTT2_CLIENT-IO ist, damit wir nicht versehentlich/unangekündigt jemanden "abschießen").

Hmm. Ich hätte gerne noch eine breitere Userbasis bevor wir aus contrib raus gehen. Von den 10 gemeldeten Installationen sind wahrscheinlich schon mal drei von mir.

und einen kurzen Blick auf Eure Rhasspy Konfiguration erhaschen konnte bin ich nachfolgend dazu übergegangen für jede intention eine eigene .ini anzulegen. Ist dieses Vorgehen okay, oder kann/sollte man besser alle intentions einfach in die sentence.ini kloppen?

Das kannst du machen, wie du möchtest. Ich bevorzuge den Weg über viele verschiedene .ini Dateien. Einfach, weil ich's übersichtlicher finde. Für Rhasspy macht das aber keinen Unterschied.

Im Github readme wird unter "Attributes (ATTR)" noch (das alte) "configFile" anstelle von "languageFile" erklärt

Danke, ist in der dev-Branch korrigiert

@drhirn: spricht was dagegen, die im svn einzuchecken?

Nein, gar nicht. Mache ich, sobald ich zuhause bin. Also vom Büro. Nicht, dass noch einer glaubt, ich würde seit Mittwoch meine neue alte Freiheit genießen

Ferner sehe ich dann noch CALENDAR-Devices ("Welche Termine habe ich/haben wir/hat XYZ heute?"), ABFALL- und Wetter-Module ("Wann kommt die Müllabfuhr?", "Wie wird das Wetter?/Wird es regnen?" o.s.ä) u. PostMe-Listen für Einkaufszettel/ToDo-Listen ein (Keine Ahnung, ob das überhaupt realiserbar ist, dürfte von seiten Rhasspys offline-"Wortschatz" schwierig werden). Das sehe ich aber eher als "Privat-Projekte" die ich nicht in ein Wiki/cref sondern bestenfalls in einen Thread dokumentieren würde.

Das sehe ich wiederum ganz anders. Das wären genau die Sachen, die ich mir im Wiki vorstellen würde. Und auch sehr gerne selbst als Modul vom Modul zur Verfügung hätte. Einkaufszettel ist aber in der Tat nicht ganz einfach. Irgendwo im Forum glaube ich aber eine Liste mit möglichen Produkten gesehen zu haben, die man dann einfach nur in die Custom Words integrieren müsste.

Zu vorkonfigurierten sentence.ini-Files ein klares Nein von mir. Das kann zu einem Saustall führen, wenn man im Nachhinein Präfix oder Sprache ändert weil man mit der Konfiguration noch nicht ganz fertig war.

Hab ich was übersehen, auf das ich noch antworten sollte?

Ich werde jetzt mal die neuen Files auf GitHub übernehmen und die main-Branch daraus machen.

[Beta-User]

Vielleicht zum Einstieg mal zur Doku:

Aye, Mr. Admiral!

(Ich spekuliere darauf, dass sich >80% der "echten" aktuellen Einsteigerporbleme in dem Muster-Thread direkt und einigermaßen dauerhaft klären lassen; ob und wie man das dann ggf. zusammenfasst, werden wir erst später entscheiden können).

Üüüüüberhaupt nicht wahr! In meinem produktiven FHEM ist alles, was ging, via gDT konfiguriert

Eine Rückmeldung dazu, yippie! 
Hast du eine grobe Schätzung, welchen Anteil "alles, was ging" in etwa hat?
Müßte mal schauen, aber ich meine, bei meinen 3 "Musterräumen" im Produktivsystem gibt es genau ein klassisches rhasspyMapping (weil ich irgendwann in der Anfangsphase von FHEM leider nicht realisiert habe, dass man bei MySensors den "Endpunkten" eigene Readingnamen verpassen kann und ich jetzt nur deswegen nicht unbedingt die historischen Daten über den Jordan schicken wollte, um "passende" Reading-Namen zu generieren  ...)

Das sehe ich wiederum ganz anders. Das wären genau die Sachen, die ich mir im Wiki vorstellen würde. Und auch sehr gerne selbst als Modul vom Modul zur Verfügung hätte. Einkaufszettel ist aber in der Tat nicht ganz einfach. Irgendwo im Forum glaube ich aber eine Liste mit möglichen Produkten gesehen zu haben, die man dann einfach nur in die Custom Words integrieren müsste.

Zur Klarstellung: Das ist durchaus interessant, aber eben in "Ausbaustufe 2+".

Modell in etwa:
Grundstufe 1 => Rhasspy+RHASSPY laufen, was via gDT direkt zu erschlagen ist, ist erschlagen.
Grundstufe 2 => Räume, Gruppen und Devices sind so benannt, dass alles soweit rund läuft, spezielle Devices haben eigene rMappings, "specials" sind implementiert wo erforderlich
Ausbaustufe 1 => Shortcuts und ggf. erste kleine CustomIntents
Ausbaustufe 2 => this is where fun starts...

bzgl. Custom Words und Einkaufsliste: Man kann von FHEM aus eigene slots generieren ... (und dabei entscheiden, ob der bestehende überschrieben werden soll; ist aber von meiner Seite bisher ungetestet...)

Code Auswählen Erweitern

Zu vorkonfigurierten sentence.ini-Files [...]
Nachvollziehbare Position. In der Praxis brauchen wir m.E. sowas wie einen brauchbaren Startpunkt (=> Muster-Thread, damit man ggf. auch mal etwas ausführlicher diskutieren kann, welchen slot man denn ggf. für was verwendet und warum... (ich bin da auch noch nicht durch, und hab' erst mal versucht, überhaupt eine Diskussionsgrundlage zu schaffen, sonst ist das sehr abstrakt).

Hab ich was übersehen, auf das ich noch antworten sollte?

Bestimmt, aber das geht mir ziemlich sicher auch nicht anders .
Wichtige Punkte kommen aber erfahrungsgemäß sowieso wieder in der einen oder anderen Form auf den Tisch...

Ich werde jetzt mal die neuen Files auf GitHub übernehmen und die main-Branch daraus machen.

Thx!

[drhirn]

Eine Rückmeldung dazu, yippie! 
Hast du eine grobe Schätzung, welchen Anteil "alles, was ging" in etwa hat?

Naja, ich verwende Rhasspy derzeit nur, um den TV ein- und auszuschalten, Lichtszene im Wohnzimmer zu ändern, Timer zu setzen und die Temperatur abzufragen. Und eigentlich war auch der Plan, die Heizung zu kontrollieren. Das hat sich aber endlich erledigt. Zumindest für die nächsten paar Monate. Also bis auf Lichtszene und Timer ist überall gDT gesetzt.

[drhirn]

@Beta-User: Warum hast du das Erstellen von Scene-Slots auskommentiert?

[Beta-User]

Ähm, habe ich...?
Oder nur in Teilen? Dunkle Erinnerung: es war "too much" und ist an anderer Stelle untergebracht?

(Das Ergebnis müsste bei einem device_map-update via MQTT relativ einfach zu begutachten sein).

[drhirn]

Hab mich vertan. Auf meiner Testumgebung im Büro wurden die Slots nicht erstellt. Zuhause schon.

Aktuelle Versionen sind im SVN

[Beta-User]

...ist schon eine Weile her, aber dunkel schimmert da was, dass auch das so ein Thema war, wo ich dann hinterher dachte, dass es in diesem Fall besser ist, die leeren Intents nicht zu erstellen (analog zu der Diskussion um Shortcuts):

Da Rhasspy das dann irgendwie zu verarbeiten versuchen würde und dann ggf. wieder versuchen, daraus MQTT-Payload zu generieren, ist das meinem Bauchgefühl nach keine gute Idee. Da Shortcuts ansonsten "autonom" ist, ist es hier egal, ob das nun erstellt wird oder nicht => raus damit...

Vermute also, dass es in der Testumgebung keine SetScene-Optionen gibt...?