Modulentwicklung für Rhasspy Sprachassistent

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

Vorheriges Thema - Nächstes Thema

drhirn

Zitat von: Beta-User am 13 Dezember 2021, 10:48:33:) Scheinbar fehlt zu der msgConfig-Geschichte entweder Info oder ein "teaser", oder ist alles klar?

Ich versteh nicht ganz, warum ich einem Sprachassistenten Textnachrichten schicken sollte?

Beta-User

Zitat von: drhirn am 13 Dezember 2021, 11:12:30
Ich versteh nicht ganz, warum ich einem Sprachassistenten Textnachrichten schicken sollte?
Gute Frage! Ohne die Babble-Runde wäre ich auch nicht auf den Gedanken gekommen... ;D

Also:
1. Manche Leute diktieren ihre Text-Messages, finden es aber ansonsten total unnötig, mit Computern zu reden ;) . Wenn ich denen jetzt anbiete, mit dem ihnen vertrauten Messenger auch das Licht in ihrem Zimmer ausmachen zu können, werden die vermutlich nicht auf den Gedanken kommen, dass sie grade mit einem Computer geredet haben :P , das feature aber ggf. trotzdem gerne nutzen 8) .

2. RHASSPY etabliert ja so oder so schon einen (optional: mehrsprachigen!) Zwischenlayer, der es erlaubt, von Text auf "Device" zu schließen, im Prinzip beliebige Aktionen auszuführen und passende (flexibel anpassbare) Rückmeldungen zu geben. Die STT- und TTS-Anteile sind dabei nur ein Aspekt, der "Mitteilteil" besteht eigentlich aus Textbausteinen, die auch als solche ausgetauscht werden.
Daher stellte sich plötzlich die Frage, warum man das eigentlich nicht auch ohne die "äußeren" Input/Output-Anteile nutzen sollte? Antwort: Es geht ohne weiteres, also warum eigentlich nicht...

3. Vor längerem habe ich mal mit msgDialog rumexperimentiert. An sich ist das nett, aber relativ aufwändig zu konfigurieren: man muss das händisch für jedes Device/jede Anfrage im msgDialog selbst (JSON-encoded) hinterlegen. Da ist die RHASSPY-Methode (z.B. über GetState), alle "Antwortsätze" direkt im abzufragenden Device zu hinterlegen (oder für bestimmte Typen vorgefertigte Antworten vorzuhalten) sehr viel angenehmer 8) . (Vermutlich habe ich auch noch nicht alle Optionen in msgDialog rausgefunden, kann schon sein, dass da "mehr geht", als das nach meinem halbherzigen Versuch den Eindruck machte, und die Option, Inline-keyboards zu generieren, finde ich eigentlich auch klasse; mal sehen...).

Anders gesagt: Wer seinem FHEM Textnachrichten schicken will, um damit Steuerungsbefehle abzusetzen oder Informationen abzufragen, hat damit eben eine weitere, sehr flexible Option ;) .
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

Ist schon ok. Kein Problem damit. Versteh's nur persönlich nicht ;D

Hab das mal mit Talk2FHEM realisiert. Ist auch ein guter Weg. Da ist's dann v.a. egal, ob die Anfrage via Messenger, Sprachassistent oder sonst was kommt.

Beta-User

Talk2FHEM hatte ich auch (im Wiki, nicht im realen FHEM) immer mal wieder angesehen, aber ehrlich gesagt hat mich dann der Wiki-Artikel immer wieder nicht überzeugt. Das sah so ähnlich aus wie meine msgDialog-Versuche: Sehr "statisch"... Man ändert irgendwo den Device-Namen, und schon klemmt es. Nicht gut.
M.E. ist das in etwa so, wie wenn man RHASSPY ohne gDT vergleicht mit RHASSPY mit gDT: Ist einfach eine ganz andere Liga...

Und da das "RHASSPY-de-Layer" eh' da ist, finde ich die Doppelung völlig unnötig :) , zumal es vermutlich verwirrend ist, wenn man für die eine "Bedienweise" bestimmte Begrifflichkeiten hat und für die nächste dann wieder andere (?).

msgConfig ist im Übrigen auch nicht beschränkt auf einen bestimmten "Output-Layer", sondern man kann das dynamisch konfigurieren, und z.B. Sprachausgaben bei Anweisenheit realisieren und Text-Messages bei Abwesenheit ;) . Geantwortet wird nämlich an einen RESIDENT, nicht an ein bestimmtes Gerät 8) .

Schwieriger wird es uU., wenn man die zulässigen Kommandos usw. für verschiedene RESIDENTS beschränken will. Dafür braucht man dann vermutlich unterschiedliche Rhasspy-Services+RHASSPY-Instanzen, aber man kann zumindest den "Sprachschatz" gemeinsam nutzen, wenn man denselben prefix für die Attribut-Namen beibehält... (Das wird alles vermutlich noch "lustig").
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

#994
ZitatIch versteh nicht ganz, warum ich einem Sprachassistenten Textnachrichten schicken sollte?
In der nächsten Generation von Messengern wird die STT-Funktion angeboten.

LG

pah

P.S.: Welches ist denn nun die aktuellste Version des RHASSPY-Moduls?

Könnte man die jeweils im ersten Post des Threads hinsetzen, ode rim Github?


Beta-User

Habe eben ein update ins svn (contib) geschoben.

Da kann man jetzt u.a. auch
- experimentell einen "sessionTimeout" setzen (umbenannt). Dann macht RHASSPY die Sitzung nicht immer gleich zu. Klappt manchmal, aber wenn irgendwas quer hängt (not recognized), gibt es das bekannte Gestottere, das ganze scheint aber sehr viel besser zu laufen als bisher gewohnt;
- die msgDialog-Schnittstelle ist leicht verbessert, (der sessionTimeout-Parameter ist auch dort umbenannt);
- ich habe einen gDT "info" erfunden, der (wenn alles mal funktioniert) dann dazu dienen soll, beliebige Geräte abfragbar zu machen (man kann sich z.B. vorlesen/zusenden  lassen, was man via stateFormat in einen HTTPMOD geschrieben hat, und einen update anschubsen). Muss aber noch verbessert werden, ist erst mal eine Art preview...

Vor allem:
Es sollten alle Antworten "würfelbar" sein. Dazu einfach alternative Sätze/Antworten per Pipe (|) trennen, ein passendes update für languageFile mit kleinen Beispielen ist auch im svn zu finden (die Struktur ist leicht erweitert wegen der STATE-Abfragen => Neustart erforderlich)

Wie immer würde ich mich über Rückmeldungen freuen (das war die letzte Zeit eher etwas mau), und ggf. Vorschläge zur Code-Verbesserung...

Soweit erst mal die Kurzfassung.
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

Sei bitte so nett, und häng's auch hier immer an. Damit ich's auf GitHub laden kann.

Beta-User

#997
Zitat von: drhirn am 18 Dezember 2021, 08:36:46
Sei bitte so nett, und häng's auch hier immer an. Damit ich's auf GitHub laden kann.
Bitte schön :) .
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

#998
Zitatdas war die letzte Zeit eher etwas mau
Klar. Wenn Du schneller entwickelst, als wir testen können...

LG

pah

P.S.:

Zitat1.PERL WARNING: Use of uninitialized value $siteIds in split at /opt/fhem/FHEM/10_RHASSPY.pm line 3165.
2. Ein Attribut "configFile" gibt es im Modul nicht

Beta-User

Zitat von: Prof. Dr. Peter Henning am 18 Dezember 2021, 12:24:57
Klar. Wenn Du schneller entwickelst, als wir testen können...
...und teilweise auch schneller, also ich selbst (komplett) testen kann...
Ich fasse das mal als Kompliment auf.

Es waren halt teilweise auch sehr wenige Downloads gewesen für die Testversionen, und das war irritierend, da anders als "früher". Klar, es läuft für die meisten soweit, no need to change. Aber etwas mehr Neugier hätte ich erwartet, auch zu den Doku-Themen.
Zur Klarstellung: Bei @pah und @drhirn habe ich gesehen, wo z.B. was im Wiki passiert ist, an dem ich ablesen kann, wo die Einarbeitung ggf. grade ist bzw. wo unklar ist, für was man bestimmte Optionen überhaupt braucht (weil z.B. durch alte Methoden gelöst).

Das ging also eher in Richtung des Rests...

@pah: speziell interessiert hätte mich vor allem, ob meine Überlegungen zur Messenger-Integration grundsätzlich in die richtige Richtung gehen, oder eher nicht. (Aber auch da: die letzte Rückmeldung wegen der Frage von drhirn hatte ich in diese Richtung als "positiv" bewertet...)

Zitat
1.PERL WARNING: Use of uninitialized value $siteIds in split at /opt/fhem/FHEM/10_RHASSPY.pm line 3165.
2. Ein Attribut "configFile" gibt es im Modul nicht
Ad 1.: Danke für den Hinweis. "Sollte" eigentlich nicht passieren, aber vermutlich muss man in diesem "undefined"-Fall dafür sorgen, dass RHASSPY die siteIds anfordert. Das scheinst du noch nicht gemacht zu haben.

Ad 2.: Es war mal die Überlegung, welchen Namen man für das vergeben sollte, was dann im Internal configFile (für configDB muss das so heißen) zu finden sein soll. "Früher" waren das wirklich nur sprachspezifische Sachen, aber nachdem man darüber auch slots an Rhasspy übergeben kann, wäre fast die Frage, ob man languageFile umbenennt...
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

Ich bin mit der aktuellen Version des Moduls nicht zufrieden. Wenn ich es installiere, macht das zugehörige MQTT2_DEVICE eine Verbindung zu Rhasspy auf, die alle Audiodaten empfängt. Ich kann zwar autocreate abschalten - aber wer um Himmels Willen braucht denn die ganzen Audioframes? Diese Netzlast will ich eigentlich vermeiden.

LG

pah

Beta-User

Zitat von: Prof. Dr. Peter Henning am 18 Dezember 2021, 18:04:11
Ich bin mit der aktuellen Version des Moduls nicht zufrieden. Wenn ich es installiere, macht das zugehörige MQTT2_DEVICE eine Verbindung zu Rhasspy auf, die alle Audiodaten empfängt. Ich kann zwar autocreate abschalten - aber wer um Himmels Willen braucht denn die ganzen Audioframes? Diese Netzlast will ich eigentlich vermeiden.

Ähm. Es ist nicht RHASSPY dafür verantwortlich, dass du die Entscheidung getroffen hast, nicht die eingeschränkten subscriptions zu nutzen und den ganzen "Schmodder" mit MQTT2_DEVICE abzugreifen...
(Oder verstehe ich da was falsch?)

Betr. #3156ff würde ich mal folgendes vorschlagen:
        my $siteIds;
        for (keys %{$ref}) {
            next if !defined $ref->{$_}{satellite_site_ids};
            if ($siteIds) {
                $siteIds .= ',' . encode($cp,$ref->{$_}{satellite_site_ids});
            } else {
                $siteIds = encode($cp,$ref->{$_}{satellite_site_ids});
            }
        }
        if ( $siteIds ) {
            my @ids = uniq(split m{,},$siteIds);
            readingsBulkUpdate($hash, 'siteIds', join q{,}, @ids);
        }

(Neu ist eigentlich nur die if-Abfrage am Ende - ich weiß ehrlich gesagt nicht, warum Rhasspy anscheinend komplett leeren Content zurückgibt, oder ich verstehe den Mechanismus noch nicht ganz, kann auch sein.)

@drhirn: Habe versucht, den "Komma"-Konverter in Gang zu bringen (wie jetzt von mir im Wiki für die Theorie hinterlegt). Das klappt aber leider aus irgendeinem Grund nicht, für einen Schubs wäre ich dankbar ::) .
In Python wollte ich mich eigentlich nicht auch noch reinarbeiten ::) und weiß nicht mal, was auf der Murmel an Version verfügbar ist; vielleicht wäre Perl einfacher ;) ...
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

Zitat
Ähm. Es ist nicht RHASSPY dafür verantwortlich, dass du die Entscheidung getroffen hast, nicht die eingeschränkten subscriptions zu nutzen und den ganzen "Schmodder" mit MQTT2_DEVICE abzugreifen...
(Oder verstehe ich da was falsch?)
Da verstehst Du etwas falsch. ICH habe gar keine Subscriptions ausgeführt - das muss alles aus dem Modul stammen.

LG

pah

Beta-User

Die Empfehlung ist, subscriptions im M2C auf setByTheProgram zu setzen. Ist das der Fall?

RHASSPY interessiert sich jedenfalls nur für einen Teil der messages, (wenn ich richtig informiert bin...)

M2C steht per default auf "#"...
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

Anders gesagt:
Die subscriptions, die RHASSPY bei "setByTheProgram" beim M2C anmeldet, sind in @topics (#271ff) zu finden.

Mit
mosquitto_sub -h <server-ip> -p 12183 -v -t +/hotword/+ -t +/intent/# -t +/dialogueManager/# -t +/nlu/# -t +/tts/#
kann man mitlauschen, was RHASSPY so in etwa zu sehen bekommt - und im übrigen dann rausfiltert und nicht (ohne entsprechende Anweisung) an M2D weitergibt...

Jedenfalls bei meinen bisherigen Tests kamen da keine Audio-Frames, sondern nur Text/JSON. Was übersehe ich?
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