Modulentwicklung für Rhasspy Sprachassistent

Begonnen von drhirn, 11 März 2021, 15:59:50

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: drhirn am 01 Dezember 2021, 10:34:20
Was bedeutet das konkret?

Das bedeutet, dass alle die ihre sentences.ini (und ggf. rhasspyMappings) überarbeiten müssen, die diese Version nutzen möchten _und_ bisher noch die deutschen Begrifflichkeiten drin hatten (und/oder ungünstige Werte in state der Devices haben für on/off).
Also Type=Helligkeit geht nicht mehr, da muss brightness hin/kommen.

Zitat von: drhirn am 01 Dezember 2021, 10:35:51
Es muss nicht mal ein Leerzeichen angefügt werden. Auf "DEF" klicken und dann auf "modify xxx" reicht.
:) Dann ist es noch einfacher. Ich mache halt meistens das mit dem Leerzeichen, das funktioniert z.B. auch in den Attributen. Ist vermutlich dann ein unnötiger Hosenträger... ;D
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

So, ich hab euch allen, die ihr eine deutsche Wiki-Doku wolltet, mal ein bisschen was zum Abarbeiten vorgegeben (https://wiki.fhem.de/wiki/RHASSPY). Viel Spaß beim Übersetzen und Ergänzen. Ich mach mal Schluss für heute ;)

drhirn

Text-Zeilen, die grau sind, konnte ich - mangels Wissen - nicht übersetzen. Das müsste bitte jemand anderer machen. Am Besten so, dass auch ich verstehe, was gemeint ist ;)

Beta-User

#948
...irgendwie hatte sich da wohl was überschnitten, und jetzt finde mal die Unterschiede...

Hier mal die übersetzte Fassung:

[...]
(War leider weg...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Prof. Dr. Peter Henning

Öh...

Ich habe gerade die Sprache des Wiki-Eintrags etwas geglättet. Zumindest damit angefangen.

LG

pah

drhirn

Zitat von: Beta-User am 02 Dezember 2021, 17:37:40
...irgendwie hatte sich da wohl was überschnitten, und jetzt finde mal die Unterschiede...

Wie hat sich wann wo was überschnitten?

Beta-User

...hatte vorhin versucht, die in den code-tags zu findende Fassung ins Wiki zu packen. Da kam dann eine Meldung, dass sich das mit anderen zwischenzeitlichen Änderungen "beißen" würde - also habe ich das erst mal gelassen...

Scheint @pah gewesen zu sein. Sollte kein Problem sein, das zu integrieren, aber heute mache ich das nicht mehr... (bin nicht traurig, falls jemand anderes sich ein diff anschaut und das dann zusammenpuzzelt...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

OK, leider scheinen meine gestrigen Vorschläge doch versehentlich in den Orkus gewandert zu sein...

Jetzt ist es aktualisiert. Bei der Gelegenheit ist mir aufgefallen, dass bei den jetzigen sentences.ini-Beispielen meine "Schubser" im "neue Ufer"-Thread zur Nutzung der eingeschränkten slots noch nicht berücksichtigt sind und hoffe sehr, dass geplant ist...

Bei der Gelegenheit: Für ein "howto part 2" würde ich vorschlagen, dann auch sowas wie Gruppen-Schaltungen zu erläutern, und eine Doku zu "mainrooms" fehlt vermutlich auch noch (für die cref hole ich das nach)... (ich befürchte, diesen Hinweis versteht keiner...)

PS: Wegen des dialogischen "Interfacings" zwischen Messenger-Diensten und RHASSPY/Rhasspy bin ich jetzt über msgConfig/msgDialog gestolpert. Meine aktuelle Idee wäre, die betreffenden funktionalen Code-Bausteine aus msgDialog (umgebaut) in RHASSPY einzubauen. Damit hätte man die Option, nicht nur einfache Textkommandos entgegenzunehmen (was schon immer ging, aber irgendwie an mir vorbeigegangen war), sondern
- die Antwort (in Text) wieder an den Absender zu senden (statt zu sprechen);
- eventuell fehlende Informationen abzufragen;
- offene Dialoge zu gestalten ("Hi user, was willst du tun: Geräte schalten oder Informationen abrufen?" -> Geräte schalten -> "wo bzw. welche Geräte oder Gruppe?" ...)

Der Vorteil von RHASSPY ist ja, dass wir bereits eine relativ eindeutige Brücke von Sprache zu FHEM-Devices haben, und "wissen, was geht", und andererseits Optionen, pro Gerät auch spezifische Abfragen vorkonfigurieren zu können, ohne komplexe JSON-Strukturen vorzukonfigurieren. msgConfig seinerseits erlaubt es, im Prinzip beliebige Messenger-Dienste einzubinden :) .

Wird aber noch dauern, bis (vielleicht) das Gerüst steht...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Ich übernehme derzeit nur aus CRef/GitHub und formatiere entsprechend. Übersetzen tu ich nur nach Lust und Laune. Und ändern nur, wenn's unbedingt erforderlich ist.
Das wird's für mich dann aber im Großen und Ganzen gewesen sein.

Wer ändern/ergänzen will, möge das tun. Gröbere Änderungen können wir ja vorher hier oder auf der Diskussion-Seite der Wiki-Seite besprechen.

Was meinst du mit "mainrooms"?

Beta-User

Zitat von: drhirn am 03 Dezember 2021, 10:23:27
Was meinst du mit "mainrooms"?
Es gibt einen speziellen slot, in dem alle "Erstwerte" landen, die im "rooms"-Key bei jedem Device stehen. Der wird für Auswahldialoge genutzt. Ist ähnlich wie die etwas offensichtlichere "alias"-Funktionalität, und ich gehe mal davon aus, dass der Gesamtzusammenhang vom Tweak "ignoreKeywords" (rooms) über die Attributauswertung (room, rhasspyRoom) bis hin dazu, welche Auswahlmöglichkeit dann in $mainrooms bestehen, einigermaßen unklar ist ;D ...

Genauso dürften ein paar Praxisbeispiele dazu fehlen, welche Angaben man sinnvollerweise über "room"-Begrifflichkeiten abwickelt (eher "geografisch" orientiert), und was über Gruppenzugehörigkeiten (eher funktional orientiert). Also: "schließe alle rollläden im erdgeschoss", "mache sämtliche lichter im essbereich an". Setzt halt voraus, dass man entsprechend Werte in den Gruppen- und room-Attributen gesetzt hat, aber dann funktioniert das (mit den eingeschränkten slots!) m.E. ziemlich gut...

Zitat von: drhirn am 03 Dezember 2021, 10:23:27
Ich übernehme derzeit nur aus CRef/GitHub und formatiere entsprechend. Übersetzen tu ich nur nach Lust und Laune. Und ändern nur, wenn's unbedingt erforderlich ist.
Das wird's für mich dann aber im Großen und Ganzen gewesen sein.

Wer ändern/ergänzen will, möge das tun. Gröbere Änderungen können wir ja vorher hier oder auf der Diskussion-Seite der Wiki-Seite besprechen.
Verständlich, und irgendwo muss man auch anfangen, da ist der erste Schritt mit der Übersetzung schon ein Riesenschritt vorwärts.

Nur bekommen wir es an die User nicht ran, dass es sehr viel akkuratere Möglichkeiten gibt, einzelne (Gruppen von) Geräte/n zu adressieren, wenn wir im Wiki wieder alles in einen Topf werfen und überall nur $de.fhem:Device hinpappen. Für mich ist das wie Porsche nur im 1. Gang fahren ::) ...

Wenn es nicht anders geht, räume ich bei Gelegenheit hinterher, aber eigentlich dürfte der Aufwand minimal sein, das gleich mit einzupflegen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Zitat von: Beta-User am 03 Dezember 2021, 10:46:14
Es gibt einen speziellen slot, in dem alle "Erstwerte" landen, die im "rooms"-Key bei jedem Device stehen. Der wird für Auswahldialoge genutzt. Ist ähnlich wie die etwas offensichtlichere "alias"-Funktionalität, und ich gehe mal davon aus, dass der Gesamtzusammenhang vom Tweak "ignoreKeywords" (rooms) über die Attributauswertung (room, rhasspyRoom) bis hin dazu, welche Auswahlmöglichkeit dann in $mainrooms bestehen, einigermaßen unklar ist ;D ...

Ähm, ja :D

ZitatNur bekommen wir es an die User nicht ran, dass es sehr viel akkuratere Möglichkeiten gibt, einzelne (Gruppen von) Geräte/n zu adressieren, wenn wir im Wiki wieder alles in einen Topf werfen und überall nur $de.fhem:Device hinpappen. Für mich ist das wie Porsche nur im 1. Gang fahren ::) ...

Wenn es nicht anders geht, räume ich bei Gelegenheit hinterher, aber eigentlich dürfte der Aufwand minimal sein, das gleich mit einzupflegen.

Wo ich eh schon korrigiert, hab ich das hinzugefügt.

Ansonsten bin ich so weit fertig. Sollte alles da sein, was in CRef und GitHub steht. Jetzt seid ihr dran. Viel Spaß!

Beta-User

Zitat von: drhirn am 03 Dezember 2021, 14:11:52
Ähm, ja :D
...am besten mal ausprobieren und mit den Parametern rumspielen... Sonst schreibe ich mir die Finger wund und bekomme es eh' nicht erklärt... ::)

ZitatWo ich eh schon korrigiert, hab ich das hinzugefügt.

Ansonsten bin ich so weit fertig. Sollte alles da sein, was in CRef und GitHub steht. Jetzt seid ihr dran. Viel Spaß!
Danke! Ich versuche dann bei Gelegenheit nochmal drüberzugehen, wäre aber überhaupt nicht undankbar, wenn sich jemand anderes der Sache annehmen würde.
(Eigentlich hatte ich mal angenommen, dass die slot-Namen selbsterklärend wären und irgendwann jemand rufen würde: "Das ist ja g...(anz toll)!" und dann ab da dann "der Fisch geputzt" wäre. Scheint eine grobe Fehleinschätzung gewesen zu sein, oder ich hab's bisher noch nicht geschafft, das so zu erklären, dass es jemand versteht ::) ...).

Am WE will ich aber wenn möglich erst mal testen, ob RHASSPY mit Telegram spricht, dann könnt ihr euch dann wieder mit neuen unverstandenen features rumschlagen :P und Vorschläge liefern, wie man das verbessern kann...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Gisbert

ZitatBei der Gelegenheit ist mir aufgefallen, dass bei den jetzigen sentences.ini-Beispielen meine "Schubser" im "neue Ufer"-Thread zur Nutzung der eingeschränkten slots noch nicht berücksichtigt sind und hoffe sehr, dass geplant ist...

Hallo Jörg,

Das kommt ganz sicher noch, WE steht ja vor der Tür :). Mitgelesen habe ich die ganze Zeit, auch in diesem Thread hier. Der Hinweis im "neuen Ufer"-Thread auf ein Youtube-Video war auch sehr hilfreich.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Beta-User

Hallo zusammen,

kleiner update zu zwei Aspekten:

Zum einen gibt es jetzt mit gdt2groups noch einen weiteren Tweak, der das Einrichten erleichtern soll (siehe commandref);

Zum anderen bin ich mit dem msgDialog-Thema immerhin mal soweit, dass es ein Attribut dafür gibt und die Eventverarbeitung startet, wenn man mit Telegram was reinschickt. Wer da mitwerkeln will, muss vermutlich etwas tiefer in das Coding einsteigen und mal einen msgDialog eingerichtet haben, sonst ist das sicher komplett unverständlich.
Für heute mache ich an der Stelle mal Schluss...

Grüße, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Prof. Dr. Peter Henning

Diverse Inkonsistenzen in der Schnellstart-Anleitung behoben.

LG

pah