Modulentwicklung für Rhasspy Sprachassistent

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

Vorheriges Thema - Nächstes Thema

laberlaib

Zitat von: Beta-User am 25 März 2021, 22:21:06
Schon alleine wegen der cref: Mit ziemlicher Sicherheit => die letzte hier angehängte!
(EDIT: Ist nun auch im git unter https://github.com/drhirn/fhem-rhasspy/blob/0.4.6a/10_RHASSPY.pm verfügbar.)
Ich _glaube_, dass es möglich sein sollte, zwei (oder mehr) rhasspy-Dienste parallel laufen zu lassen (auf derselben Plattform), einen mit de-profile und einen mit "es", das ganze über einen Broker.

In der aktuellen cref sind ein paar Hinweise drin, wie ich _glaube/mir nach jetzigem Stand vorstelle_, dass man mehrere RHASSPY-Instanzen auf einem FHEM laufen haben kann.
Das habe ich nicht verstanden, ich würde optimalerweise MQTT-Rohdaten benötigen (siehe die Beispiele im Repo von drhirn), dann wird es evtl. klarer.

(Ich will nicht in dem anderen Thread zu viele Anwenderdetails diskutieren, die ich sowieso vermutlich noch nicht im Detail nachvollziehen kann; wenn es spezielle Themen gibt, die mit Mehrsprachigkeit zu tun haben, bitte melden und ggf. einfach einen neuen Thread dazu aufmachen?)

Danke wieder Mal für den ganzen Aufriss.
Das SNIPS-Modul hab ich sogar halbwegs verstanden, das was hier gerade entsteht...

Mehrere RHASSPY-FHEM-Instanzen sind nicht das Problem bei mir, da ich ja einfach alles doppelt anlegen kann - wie dann die Slots geupdatet werden ist eher ein Luxusproblem, zur Not mach ich das manuell bzw. bau mir irgendwas.
Das Problem ist eher, dass sich in Rhasspy die Services gegenseitig in die Quere kommen und dann mehrfach gestartet werden, wenn da zwei Master auf dem selben Broker laufen. Weil nur der Dialogservice kann nach Wakeword unterscheiden, die anderen nehmen die siteID. D.h. sobald die Soundübertragung von einem Satellite "Wohnzimmer" losgeht, dann hören beide Master zu und das setzt sich dann fort. Ich hatte dann nach einem Wakeword 2^3 = 8 Resultate: 1 Wakeword aktiviert 2 Soundstreams welche an 2 Spracherkenner weitergegeben werden und diese wieder rum an 2 Intenterkenner (oder so ähnlich).

Du hast mich gerade aber auf die Idee gebracht, zwei Instanzen auf einem Satelliten laufen zu lassen, unterschiedliche Wakewords dran zu hängen und unterschiedliche SiteId (Wohnzimmer, salon) zu geben und dann den SiteID-Trennermechanismus zu nutzen. Das wird vermutlich an der gleichzeitigen Nutzung der Soundhardware scheitern. Außer wiederum das wäre mit Pulseaudio irgendwie geregelt zu bekommen...
Dann bin ich aber wieder beim reinfrickeln in Software und da schlägt für mich derzeit MQTT-Gefrickel Pulseaudiogefrickel um längen. Ersteres ist irgendwie transparent, verständlich und im MQTT-Explorer nachvollziehbar; letzteres eine Blackbox.

Den Groupseperator erläutere ich bei Gelegenheit.

--
Proxmox, Homematic, G-Tags, Zigbee2MQTT, Rhasspy Sprachsteuerung im Aufbau (beta)

Beta-User

Auf die Schnelle ein paar Gedanken dazu:

Zitat von: laberlaib am 26 März 2021, 13:40:42Danke wieder Mal für den ganzen Aufriss.
Gerne :) !

Zitat
Das SNIPS-Modul hab ich sogar halbwegs verstanden, das was hier gerade entsteht...
Das SNIPS-Modul kannte ich nicht, aber m.E. ist durch die ganzen Änderungen vieles für die Einrichtung _vereinfacht_ worden. Insbesondere ist es durch die "language" und "prefix"-Optionen möglich, zwei sehr unterschiedliche Instanzen von RHASSPY in einem FHEM laufen zu lassen - beide jeweils mit einem anderen "Master" (an der Stelle fremdlich ich noch etwas mit den Begrifflichkeiten), also der eine z.B. auf localhost:12101 und der andere auf localhost:12102.

Aber falls das die Rückmeldung war, dass die cref in der jetzigen Form (noch) nicht verständlich ist: Bin für Verbesserungsvorschläge offen (und drhirn vermutlich dankbar!)...

Zitat
Mehrere RHASSPY-FHEM-Instanzen sind nicht das Problem bei mir, da ich ja einfach alles doppelt anlegen kann - wie dann die Slots geupdatet werden ist eher ein Luxusproblem, zur Not mach ich das manuell bzw. bau mir irgendwas.
Wenn jede RHASSPY-Instanz ihren Master kennt, sollten auch die (von FHEM aus geschriebenen) slots sauber up-to-date zu halten sein.

Zitat
Das Problem ist eher, dass sich in Rhasspy die Services gegenseitig in die Quere kommen und dann mehrfach gestartet werden, wenn da zwei Master auf dem selben Broker laufen. [...]
Ich kann zwar das Problem erahnen, aber eigentlich müßte das ganze doch so intelligent sein, dass "erst mal" nur der (jeweilige) Master aufgeweckt wird (setzt unterschiedliche Wakewords voraus) und halt "seinen" Dialog mit dem einen Satelliten führt. Aber evtl. fehlt mir da noch die praktische Erfahrung mit dem Ganzen.

Zitat[...] Pulseaudiogefrickel [...]
Falls dir das Stichwort MPD was sagt: Auf der Hardware, auf der mein derzeitiger Master untergegracht ist, läuft auch ein MPD. Da ich von daher wußte, dass Audioausgaben durch unter anderen Usern laufende Services ein ziemlicher Showstopper sind, habe ich es vorsichtshalber für rhasspy genauso gemacht: beides wird in der user-Sphäre nach (automatischem) login automatisch gestartet, so dass auch (gleichzeitiger) Zugriff auf die Soundschnittstellen gar kein Problem sind (bzw. wären...).
Der Artikel hier wäre ggf. ein geeigneter Startpunkt: https://wiki.ubuntuusers.de/MPD/MPD_auf_der_Benutzerebene/

Und dem Bauchgefühl nach müßte es auch möglich sein, rhasspy doppelt unter demselben User mit unterschiedlichen Profilen zu starten.
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 26 März 2021, 14:08:39
Und dem Bauchgefühl nach müßte es auch möglich sein, rhasspy doppelt unter demselben User mit unterschiedlichen Profilen zu starten.

Das ist ganz sicher so.

Wichtig für laberlaib: Du brauchst natürlich zwei unterschiedliche Broker! In Folge dessen auch 2 MQTT2_DEVICEs.

laberlaib

Sicher ist alles einfacher geworden und alle festen Texte sind raus, aber sowas
if ( defined $hash->{helper}{shortcuts}{$data->{input}}{conf_timeout} && !$data->{Confirmation} ) {
braucht erst einmal Zeit, sich ins Hirn zu fressen (mindestens wenn man kein Dr. ist).

Zitat von: Beta-User am 26 März 2021, 14:08:39
Falls dir das Stichwort MPD was sagt: Auf der Hardware, auf der mein derzeitiger Master untergegracht ist, läuft auch ein MPD. Da ich von daher wußte, dass Audioausgaben durch unter anderen Usern laufende Services ein ziemlicher Showstopper sind, habe ich es vorsichtshalber für rhasspy genauso gemacht: beides wird in der user-Sphäre nach (automatischem) login automatisch gestartet, so dass auch (gleichzeitiger) Zugriff auf die Soundschnittstellen gar kein Problem sind (bzw. wären...).
Der Artikel hier wäre ggf. ein geeigneter Startpunkt: https://wiki.ubuntuusers.de/MPD/MPD_auf_der_Benutzerebene/
Danke, ich klick mich da mal durch. Ich dachte immer, dass wäre eher so was wie Squeezeserver/box.

Wichtig ist, dass das auch für das Mikrofon gilt. Und im Schreiben fällt mir dann auf, dass ja der Befehl für den einen Satellitenservice gleichzeitig im anderen auf das Wakeword untersucht wird: Wenn also Alexa Porcupinen kaufen soll, dann habe ich ein Problem. Bei einem Satellite wird afaik die Hotworderkennung ausgeschalten, wenn er gerade etwas an die Spracherkennung streamt.

Im Grunde ist das MQTT-Zeug eigentlich auch sehr einfach zu testen:
- Broker mit -v starten, Kommunikation aufzeichnen und die topics merken welche jeweils beschrieben werden.
- Beide Instanzen auf eigenen Broker setzen, wobei einer extern aber auf der gleichen Maschine läuft, dann ist es einfacher mit der mosquittoconfig.
- Die Bridgekonfiguration kann soweit ich da bisher verstehe In und Out, d.h. es reicht, wenn bspw. jeweils auf dem Satellite die Bridge konfiguriert ist. Diese gibt dann die entsprechenden Topics weiter bzw. holt sich die notwendigen. An den Zentralinstanzen muss man dann nur die Satellitennamen reinkonfigurieren (das muss man eh immer) und die Inbetriebnahme eines Satelliten erfordert immer etwas mehr Arbeit (Automatischer Start per cron, Soundkarte installieren etc) da fällt dann die Bridgekonfiguration auch nicht mehr ins Gewicht.

Hätte ich mich nicht nachts um 22:00 Uhr letztes Wochenende komplett verrannt und verkonfiguriert, hätte ich das schon am Start.

Ich berichte weiter.

Zitat von: drhirn am 26 März 2021, 14:55:20
Das ist ganz sicher so.

Wichtig für laberlaib: Du brauchst natürlich zwei unterschiedliche Broker! In Folge dessen auch 2 MQTT2_DEVICEs.

Zwei Broker für die Zentralinstanzen hab ich auch und auch alles was dazu gehört. Das hat mit auch 0.2 funktioniert.
--
Proxmox, Homematic, G-Tags, Zigbee2MQTT, Rhasspy Sprachsteuerung im Aufbau (beta)

Beta-User

Zitat von: laberlaib am 26 März 2021, 15:02:37
Sicher ist alles einfacher geworden und alle festen Texte sind raus, aber sowas
if ( defined $hash->{helper}{shortcuts}{$data->{input}}{conf_timeout} && !$data->{Confirmation} ) {
braucht erst einmal Zeit, sich ins Hirn zu fressen (mindestens wenn man kein Dr. ist).
Da hast du dir aber eine schöne Stelle ausgesucht ;D ;D ;D ...

Bin auch kein Dr., und als "normaler Anwender" braucht man ja eigentlich auch nicht ganz so weit unter das Auto liegen...

Zitat
Danke, ich klick mich da mal durch. Ich dachte immer, dass wäre eher so was wie Squeezeserver/box.
Ist nicht ganz falsch, aber ich nutze das als netzwerkfähigen Audioplayer mit direkter Soundausgabe an den Verstärker (den muss(te) ja jemand befüllen (als der noch keinen LAN-Port hatte).

Wichtig in dem Zusammenhang war eben die Frage, wie man den gemeinsamen Zugriff auf pulseaudio ermöglichen kann, habe aber k.A., ob das auch das Mikro umfasst.

Zitat
Zwei Broker für die Zentralinstanzen hab ich auch [...]
Mein Bauchgefühl meint, dass es mit nur einem Broker einfacher sein sollte, kann aber auch falsch liegen.
Aber bei zwei Sprachen müssen es zwei Dienste sein, die jeweils Wakeword und speechrecogn. machen, und ich neige zu der Auffassung, dass (auch) die Audioübertragung optimalerweise nur über MQTT laufen sollte (da sonst unterschiedliche UDP-Ports gewählt werden müßten).

In meiner Welt wären das also ein mosquitto und auf der FHEM-Seite 1xMQTT2_CLIENT, 2xRHASSPY.

Aber vermutlich bin ich nicht tief genug in der Materie drin...
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 26 März 2021, 15:38:01

In meiner Welt wären das also ein mosquitto und auf der FHEM-Seite 1xMQTT2_CLIENT, 2xRHASSPY.

Aber vermutlich bin ich nicht tief genug in der Materie drin...

Stimmt, könnte jetzt funktionieren. Wenn's zwei unterschiedliche Sprachen sind und die Rhasspy-Sentences richtig benannt werden (z.B. [es.fhem.SetOnOff] und [de.fhem.SetOnOff]).

Beta-User

Zitat von: drhirn am 26 März 2021, 16:02:44
Stimmt, könnte jetzt funktionieren. Wenn's zwei unterschiedliche Sprachen sind und die Rhasspy-Sentences richtig benannt werden (z.B. [es.fhem.SetOnOff] und [de.fhem.SetOnOff]).
Oder die andere Option gewählt wird, das bisher vermutlich noch unverständliche "fhemId" zu setzen :P . Aber das ist eher für den Fall gedacht, dass man mehrere FHEM-Instanzen hat (oder unterschiedliche User mit unterschiedlichen Rechten auf derselben Instanz)...

Aber klar, die sentences müssen dann (jeweils) auch zum gewünschten "Ziel" (RHASSPY-Instanz auf irgendeiner fhemId) führen ;) . Hoffe, das auch halbwegs klar in der cref dargestellt zu haben, welches Schräubchen für welchen Fall getweakt werden sollte...?
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

#142
Zu dem hier nochmal:
Zitat von: Treibhaus am 25 März 2021, 09:46:52
Guten Morgen,

wie generiert man Text -> Sprachausgabe nach den neuen Updates.

Zitat von: Beta-User am 25 März 2021, 10:32:12
Vorgezogene Doku[...]
Kommt darauf an:Shortcuts ("alte" Syntax ) und CustomIntent:
ton aus={fhem ("set lampe1 off")}In beiden Fällen wird Perlcode ausgeführt. Was da zurückkommt, sollte als response verwendet werden (=>wenn es nicht klappt, ist es ein bug), ausgenommen der Fall, dass "nichts" (echtes undef) zurückkommt; dann sollte die "DefaultConfirmation" ertönen.

Shortcuts neu enthält dann noch die Option, bei erfolgreicher Ausführung "r:" anzugeben, und da die Response reinzuschreiben.
Die Langfassung nochmal:

Ich habe keine Ahnung, wie es früher funktioniert hat. Da stand zwar was zu einem nicht mehr existenten Attribut in die Richtung in der bisherigen commandref, aber Code dazu gab es nicht, (auch schon nicht in 0.2.0).

Mein Vorschlag dazu ist, über shortcuts Perl-Code aufzurufen, der dann den anzusagenden Text zurückgibt. Will sagen: Das, was in dem Ausgangsbeitrag mal steand, geht (fast) noch 1:1, du musst nur (zusätzlich) klarmachen, dass Perl ausgeführt werden soll => passende Klammern drumrum, und schon findest du im list auch den freundlichen Hinweis, dass es als Perl-Code erkannt worden  ist:
attr RHASSPY shortcuts ton aus={fhem ("set lampe1 off")}\
i="du bist cool" f="set $NAME speak siteId='wohnzimmer' text='Danke du auch'"\
i="ton an" p={fhem ("set $NAME on")} n=lampe1 c="Bitte bestätigen!"\
Witze={Witze()}


Bei der Gelegenheit noch: FHEM hat interne Routinen für das Handling von files => es geht auch eleganter:
sub Witze {
  my ($err, @Witze_array) = FileRead("./Witze_erzaehlen.txt");
  return $err if $err; #Wir bekommen direkt eine Fehlermeldung angesagt, wenn etwas schief geht (englisch halt...)
  my $Zufall = int(rand(@Witze_array+1)); #sicher mit der +1? Muss m.E. weg...
  chop $Witze_array[$Zufall]; #hat das letzte Zeichen weg
  #Log3('rhasspy',3 , "RHASSPY: $Witze_array[$Zufall]");
  return $Witze_array[$Zufall];
}


Nachtrag:
Da auch "Witze=Witze()" als Perl-Command im list angezeigt wird, habe ich in der angehängten Fassung das Handling umgestellt.

Da sind auch einige noch nicht wirklich getestete Änderungen bzgl. der Verwaltung der "Gruppen-Queue" drin, damit man keine anonymen subs braucht und das ganze ggf. auch "mischen" kann, falls weitere (Gruppen) Anweisungen dazukommen...
Außerdem könnte "Cancel" für timer gehen ;) .
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

JensS

#143
Danke für deine Kommentare, so kann ich dazu lernen.

Witze():
Die letzte Fassung war speicherschonender, da die Variable immer nur eine Zeile enthält. Und man weiß ja nicht, wie groß die Datei mal wird.
https://forum.fhem.de/index.php/topic,113180.msg1133690.html#msg1133690
Zitatmy $Zufall = int(rand(@Witze_array+1)); #sicher mit der +1? Muss m.E. weg...
Wenn das Witzearray 124 Zeilen erfasst, wird bei int(rand(124)) niemals die Zeile 124 vorgelesen. Daher dachte ich, +1 könnte nicht schaden.

Mehrsprachigkeit:
Man müsste tatsächlich zwei separate Systeme (Rhasspy & FHEM-Bridge) mit unterschiedlichen Ports aufbauen und das Mikro zweimal abgreifen. Eventuell geht das ja mit PyAudio.?

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

laberlaib

#144
Eine einfach Konfiguration ohne die Nutzung eines gemeinsamen Brokers für eine Sprache:
Zentralinstanz: Internen Broker auf 12183
Satellite: Externen Broker auf localhost 1883, gestartet mit "mosquitto -c mosquitto.conf", was man auch als Service hinterlegen kann.
In der mosquitto.conf das hier ergänzt:

#connection bridge2Spain
connection bridge2Spain
address 192.168.2.122:12183
try_private true
topic hermes/audioServer/+/audioFrame out
topic hermes/audioServer/+/playFinished out
topic hermes/hotword/+/detected out

topic hermes/asr/# in
topic hermes/audioServer/+/playBytes/# in
topic hermes/dialogueManager/# in
topic hermes/hotword/toggleOff in
topic hermes/hotword/toggleOn in
topic hermes/intent/# in
topic hermes/nlu/# in
topic hermes/tts/# in


Das "tüt mir leid, es kein widdrgabegerrt aktf" hat hier für Lacher gesorgt.

Jetzt werd ich morgen die bridge2Germany integrieren und schauen, ob sich das System verschluckt.

Das Problem liegt niemals bei FHEM sondern immer in Rhasspy, wo jede Instanz Intentrecogniction macht. Und man kann eben nie sagen, ob ein deutscher Satz nicht auch irgendwie einen spanischen (oder englischen oder plattdeutschen o.ä.) auslöst. Das muss verhindert werden. Weil denkbar ist ja nicht nur, dass man unterschiedliche Sprachen hat sonden einfach die Genauigkeit erhöhen will. "Fettes Brot" soll nicht auf die Einkaufsliste (Wakeword "Tante Emma") sondern in aus den Boxen (Wakeword "Hey DJ") kommen.
Dann lehre ich den jewieligen Zentralinstanzen nur die notwendigen Intents in den sentences.ini und fertig.

Zitat von: Beta-User am 26 März 2021, 15:38:01
Bin auch kein Dr., und als "normaler Anwender" braucht man ja eigentlich auch nicht ganz so weit unter das Auto liegen...
Das war eher als Seitenhieb auf DrHirn gedacht.

Edit: Rhasspy hat die Top 3 im Unterforum Sprachsteuerung erobert!


Edit2: Was du heute kannst besorgen:
mosquitto.conf erweitert:
connection bridge2Germany
address 192.168.2.121:12183
try_private true
topic hermes/audioServer/+/audioFrame out
topic hermes/audioServer/+/playFinished out
topic hermes/hotword/+/detected out

topic hermes/asr/# in
topic hermes/audioServer/+/playBytes/# in
topic hermes/dialogueManager/# in
topic hermes/hotword/toggleOff in
topic hermes/hotword/toggleOn in
topic hermes/intent/# in
topic hermes/nlu/# in
topic hermes/tts/# in


/usr/lib/rhasspy/rhasspy-dialogue-hermes/rhasspydialogue_hermes/___init___.py
auf den beiden Zentralinstanzen in Zeile ~150 erweitert:
        #self.wakeword_ids: typing.Set[str] = set(wakeword_ids or [])
        #ZENTRALINSTANZ DE
        #self.wakeword_ids = ["alexa"]
        self.wakeword_ids = ["snowboy"]

bzw.
        #self.wakeword_ids: typing.Set[str] = set(wakeword_ids or [])
        #ZENTRALINSTANZ ES
        #self.wakeword_ids = ["snowboy"]
        self.wakeword_ids = ["alexa"]


Die Spanische Instanz versteht immer nur lauter/leiser und findet um diese Uhrzeit bei schlafenden Kindern und Frauen weiterhin kein Wiedergabegerät.
Die Deutsche Instanz macht irgendwas aber von der bekomme ich derzeit noch 2 Oks - besser als 8 und da lässt sich sicherlich noch was filtern.
Edit3: Also zur Verdeutlichung: Wenn sie jeweils angesprochen werden. Wenn nicht, dann bleiben sie komplett still. Es antwort also immer nur eine.

Ich habe jeweils zum Testen immer das Wakeword auf "Alexa" gestellt, "Snowboy" versteht mich nur einmal von 10 Versuchen.
Das Ignorieren durch den Dialogmanager funktioniert aber:
Angereichert mit ein wenig Debugging/Warning von mir:
[WARNING:2021-03-26 22:10:02,419] rhasspydialogue_hermes: Ignoring wake word id=alexa
[WARNING:2021-03-26 22:10:02,419] rhasspydialogue_hermes: len(self.wakeword_ids)
[WARNING:2021-03-26 22:10:02,419] rhasspydialogue_hermes: 1
[WARNING:2021-03-26 22:10:02,420] rhasspydialogue_hermes: self.wakeword_ids
[WARNING:2021-03-26 22:10:02,420] rhasspydialogue_hermes: ['snowboy']


Edith4:
Wenn das Testrhasspydevice auf FHEM meint, es müsste auch ein OK schicken, dann ist klar warum das doppelt kommt.
Für mich siehts nach einer funktionierenden, einfachen Lösung aus.
Jetzt wirklich ins Bett und morgen skalieren.


--
Proxmox, Homematic, G-Tags, Zigbee2MQTT, Rhasspy Sprachsteuerung im Aufbau (beta)

JensS

@laberlaib
Dann kannst du alles mit einer Rhasspy-Instance abfrühstücken? Das wird wahrscheinlich nicht funktionieren. Selbst für die Rückgabe brauchst du einen separaten es-TTS.
Ganz zu schweigen vom STT. Kaldi kann angeblich kein spanisch. Da müsstest du wohl auf pocketsphinx ausweichen.
Wie bereits geschrieben, wirst du wohl nicht um zwei Komplett-Installationen und extra M2D + RHASSPY in FHEM nicht herumkommen.
Das würde einem Zero leider das Leben kosten...

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

laberlaib

#146
Man man man, wenn die Clubs noch länger zu sind, dann programmiert hier noch jemand Skynet.

Zitat von: JensS am 26 März 2021, 23:24:04
@laberlaib
Dann kannst du alles mit einer Rhasspy-Instance abfrühstücken? Das wird wahrscheinlich nicht funktionieren. Selbst für die Rückgabe brauchst du einen separaten es-TTS.
Ganz zu schweigen vom STT. Kaldi kann angeblich kein spanisch. Da müsstest du wohl auf pocketsphinx ausweichen.
Wie bereits geschrieben, wirst du wohl nicht um zwei Komplett-Installationen und extra M2D + RHASSPY in FHEM nicht herumkommen.
Das würde einem Zero leider das Leben kosten...

Gruß Jens

Zentralinstanzen sind ja nicht das Problem: Proxmox liefert ausreichend von allem.
Aber Satelliten sind rar, da diese auch gleich kabel mitbringen, Audiohardware wollen etc. Aber die machen ja nichts außer sich aktivieren, Audio wo hin schicken und audio empfangen - die TTSGenerierung geschieht ja auf dem Master und den gibts dann in vielen Sprachen.

Siehe mein Edit oben - es scheint zu klappen.
Edit: und das neuste Edit oben ist, dass ich den Grund für da doppelte OK gefunden habe...
--
Proxmox, Homematic, G-Tags, Zigbee2MQTT, Rhasspy Sprachsteuerung im Aufbau (beta)

laberlaib

#147
Da meine Konfiguration läuft wollte ich mal auf 0.46a umsteigen und hab hier gleich mal ein:
€: Sie unten, ist wohl ein Tippfehler, das Protokollzeug kann man geflisslich überlesen, ich lass es mal aus historieschen Gründen drin.
2021.03.27 20:41:34 5: handleIntentSetOnOff called
Not a SCALAR reference at ./FHEM/10_RHASSPY.pm line 1229.

Bei Verbose 5
2021.03.27 20:41:34 5: RHASSPY: [RHASSPY_DE] Parse (IO: RhasspyMasterDeMQTT2): Msg: hermes/intent/de.fhem_SetOnOff => {"input": "schalte die Stehlampe an", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "MasterDe", "id": "d6798865-76ff-4a8e-92b6-c0e81c7013fd", "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "Stehlampe"}, "slotName": "Device", "rawValue": "stehlampe", "confidence": 1.0, "range": {"start": 12, "end": 21, "rawStart": 12, "rawEnd": 21}}, {"entity": "Value", "value": {"kind": "Unknown", "value": "an"}, "slotName": "Value", "rawValue": "ein", "confidence": 1.0, "range": {"start": 22, "end": 24, "rawStart": 22, "rawEnd": 25}}], "sessionId": "d6798865-76ff-4a8e-92b6-c0e81c7013fd", "customData": null, "asrTokens": [[{"value": "schalte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}, {"value": "die", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 11, "time": null}, {"value": "Stehlampe", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 21, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 22, "rangeEnd": 24, "time": null}]], "asrConfidence": null, "rawInput": "schalte die stehlampe ein", "wakewordId": null, "lang": null}
2021.03.27 20:41:34 5: Parsed value: SetOnOff for key: intent
2021.03.27 20:41:34 5: Parsed value: schalte die Stehlampe an for key: input
2021.03.27 20:41:34 5: Parsed value: MasterDe for key: siteId
2021.03.27 20:41:34 5: Parsed value: Stehlampe for key: Device
2021.03.27 20:41:34 5: Parsed value: schalte die stehlampe ein for key: rawInput
2021.03.27 20:41:34 5: Parsed value: d6798865-76ff-4a8e-92b6-c0e81c7013fd for key: sessionId
2021.03.27 20:41:34 5: Parsed value: 1 for key: probability
2021.03.27 20:41:34 5: Parsed value: an for key: Value
2021.03.27 20:41:34 5: handleIntentSetOnOff called
Not a SCALAR reference at ./FHEM/10_RHASSPY.pm line 1229.


Und dann Neustart.
Geschalten werden soll dieser Dummy:
defmod du_Dummyschalter dummy
attr du_Dummyschalter rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off\
GetOnOff:currentValue=state,valueOff=off
attr du_Dummyschalter rhasspyName Stehlampe
attr du_Dummyschalter rhasspyRoom Wohnzimmer
attr du_Dummyschalter room Rhasspy


Das ist mein RHASSPY:
defmod RHASSPY_DE RHASSPY room=Rhasspy defaultRoom=Wohnzimmer language=de
attr RHASSPY_DE IODev RhasspyMasterDeMQTT2
attr RHASSPY_DE rhasspyMaster http://192.168.2.121:12101
attr RHASSPY_DE room Rhasspy
attr RHASSPY_DE verbose 5


Ist eine eben aufgesetzte neue Installation von FHEM.

Edit: würde mal sagen Tippfehler:
https://github.com/drhirn/fhem-rhasspy/blob/0.4.6a/10_RHASSPY.pm
ab Zeile 1227
 
    my $room;
    $room = $
    $data->{siteId};


mal "_;" angefügt, jetzt läufts.

Und wie gut ist das bitte mit der Sprachkonfig? Hat auf Anhieb geklappt.

Die prefix-Geschichte für unterschiedliche Attribute, die geht noch nicht wenn ich das richtig verstehe.
Aber die Slots werden schon in Abhängigkeit der Sprache gefüttert, das konnte ich sehen.
D.h. ich schreib alles zur Benennung in die rhasspy*-Attribute rein und lösche dann auf meinem Master die wieder raus, die er nicht lernen muss - damit kann ich erstmal leben.

Aber für die Hilfe (Device specific help) bekomme ich das hier:
No help found for module: rhasspy
Sollte da nicht das kommen, was ganz unten steht, also cref?
--
Proxmox, Homematic, G-Tags, Zigbee2MQTT, Rhasspy Sprachsteuerung im Aufbau (beta)

drhirn

Zitat von: laberlaib am 27 März 2021, 21:44:35
Edit: würde mal sagen Tippfehler:
https://github.com/drhirn/fhem-rhasspy/blob/0.4.6a/10_RHASSPY.pm
ab Zeile 1227
 
    my $room;
    $room = $
    $data->{siteId};


mal "_;" angefügt, jetzt läufts.

Das soll wohl
$room = $data->{siteId};
heißen. Hab eine korrigierte Version auf GitHub hochgeladen.

Zitat
Aber für die Hilfe (Device specific help) bekomme ich das hier:
No help found for module: rhasspy
Sollte da nicht das kommen, was ganz unten steht, also cref?
Geht bei mir. Kann es sein, dass das erst nach deiner Änderung passiert ist? Schau mal nach, ob das bei dir noch UTF-8 codiert ist und die Zeilenenden (EOL) auf LF (Unix) stehen. FHEM mag das gar nicht, wenn da was falsch codiert ist.

laberlaib

Zitat von: drhirn am 28 März 2021, 09:25:30
Geht bei mir. Kann es sein, dass das erst nach deiner Änderung passiert ist? Schau mal nach, ob das bei dir noch UTF-8 codiert ist und die Zeilenenden (EOL) auf LF (Unix) stehen. FHEM mag das gar nicht, wenn da was falsch codiert ist.

Exakt das wars, danke.

Ich übersetze nun mal die Sprachkonfigration ins Spanische und folgende Frage:
Ist das fehlende "M" bei den letzten beiden Absicht?
    'DefaultConfirmation' => "OK",
    'DefaultConfirmationTimeout' => "Sorry too late to confirm",
    'DefaultCancelConfir' => "Thanks aborted",
    'DefaultConfirReceived' => "ok will do it",


Und dann ist Sprache super kompliziert (dies ist nun ausdürcklich kein Featurerequest sondern eine Feststellung und es wird dafür passende Formulierungen für die Sprachkonfiguration geben): aus "ausgeschaltet" wird im spanischen (französischen, italienischen) je nach Geschlecht "apagdo" oder "apagada". Des Weiteren "ist" es dort ein Uhr, "sind" es aber zwei Uhr.
--
Proxmox, Homematic, G-Tags, Zigbee2MQTT, Rhasspy Sprachsteuerung im Aufbau (beta)