Rhasspy, mein Weg zu neuen Ufern: es läuft

[Beta-User]

@Gisbert:

Läuft jetzt eigentlich alles soweit und das mit siteId2room ist klar?

Ansonsten versuche mal:

Code Auswählen Erweitern

setreading Rhasspy siteId2room_Pixel4a wohnzimmer

Vielleicht wird dann klarer, was das bewirkt...

[Gisbert]

Hallo Jörg,

vielen Dank für die Nachfrage.
Die grundlegenden Funktionen funktionieren ja, so dass ich außer der täglichen Anwendung keine weiteren Änderungen vorgenommen habe.

siteId2room ist mir noch nicht klar. Ich hab das setreading ausgeführt.

Wünschenswert wäre ein durchgängig gesprochener Aufruf wie bei "Ok Google" auf dem Handy. Schön wäre auch eine etwas abwechslungsreichere Antwort wie "Gerne!" Wenn es so was gibt, dann würde ich es gerne nutzen.

Viele​ Grüße​ Gisbert​

[Beta-User]

Die grundlegenden Funktionen funktionieren ja, so dass ich außer der täglichen Anwendung keine weiteren Änderungen vorgenommen habe.

Das ist ja schon mal was...

Schön wäre auch eine etwas abwechslungsreichere Antwort wie "Gerne!" Wenn es so was gibt, dann würde ich es gerne nutzen.

Gibt es in der aktuellen Version . Ein Beispiel, wie man das umsetzen kann, ist in https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/rhasspy-de.cfg#L133 zu finden.

siteId2room ist mir noch nicht klar. Ich hab das setreading ausgeführt.

Gut.
Etwas länger: Bin erst mal davon ausgegangen, dass dein Handy als Satellit weiter als Pixel4a benannt ist?
Dann sorgt dieses Reading dafür, dass RHASSPY diesen Satelliten (also dein Handy) dem Raum "wohnzimmer" zuordnet.
Dazu muss man wissen, dass man im Rhasspy-Ökosystem Satelliten üblicherweise immer nach dem Raum  benennt, in dem sie zu finden sind, weswegen RHASSPY bei der Suche nach einem passenden Gerät bei fehlender Raumangabe (die ist bei dir in sentences.ini jetzt hoffentlich weiter optional?) zunächst in diesem Raum sucht, und die Aktion dann eben dort ausführt, (wenn das geht).

Da es ein Reading ist, kann man es ohne weiteres im laufenden Betrieb ändern. Dafür ist der Hilfscode/CustomIntent da...

Wünschenswert wäre ein durchgängig gesprochener Aufruf wie bei "Ok Google" auf dem Handy.

Da ich Google nicht kenne, kann ich nur raten, was gemeint ist:
- wakeword ginge auch für die App, aber wie gesagt: Das läuft nicht lokal, weswegen ich das (meistens) nicht nutze. Vielleicht programmiert ja mal jemand eine lokale Extension dafür, es gibt zumindest jetzt wieder etwas Bewegung (alternativ zu dem von pah gezeigten Weg) für die Generierung von eigenen wakewords: https://community.rhasspy.org/t/picovoice-offline-voice-ai-engine-gets-free-tier-for-up-to-3-users/3328.

- Den Dialog nicht gleich zuzumachen, nachdem der erste Kommand ausgeführt wurde, kann man seit neuestem experimentell einstellen. Dir würde ich erst mal noch davon abraten, weil das aus Gründen, die ich auch noch nicht kenne, manchmal etwas seltsam reagiert.

Ich vermute, mit Gruppen-Intents hast du bisher nicht experimentiert? Das wäre m.E. der nächste Schritt und könnte den "Schmerz" eventuell etwas lindern, falls es dieser zweite Punkt war.

Hoffe, v.a. das mit siteId2room  ist jetzt etwas klarer?

Grüße, Beta-User

[Gisbert]

Guten Morgen Jörg,

die abwechslungsreicheren Antworten habe ich heute morgen bemerkt; ich hab gestern abend das Modul upgedated. Jetzt bekomme ich "Jawohl", "zu Diensten", "Gerne", bin gespannt, wann "Sir, yes Sir" oder "Ai Captain" kommt

Kommt das Modul jetzt mit dem üblichen Fhem-Update, und was ist mit der cfg-Datei? Wird die dann auch automatisch upgedated?

Mein Pixel4a ist nach wie vor als Satellit vorhanden, und die Räume sind nach wie vor in sentences.ini weiter optional definiert. Mit deiner Erklärung ist siteId2room damit verständlich.

Mit Gruppen-Intents habe ich mich noch nicht beschäftigt. Ein Wakeword bei der Android-App wäre zwar schön, ist aber bei Weitem nicht so essentiell wie die tatsächliche Funktionalität.

Viele​ Grüße​ Gisbert​

[drhirn]

Gibt es in der aktuellen Version . Ein Beispiel, wie man das umsetzen kann, ist in https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/rhasspy-de.cfg#L133 zu finden.

Coooool!

[Beta-User]

die abwechslungsreicheren Antworten habe ich heute morgen bemerkt; ich hab gestern abend das Modul upgedated. Jetzt bekomme ich "Jawohl", "zu Diensten", "Gerne", bin gespannt, wann "Sir, yes Sir" oder "Ai Captain" kommt

Coooool!

Diese Art, Alternativen anzugeben  sollte übrigens zwischenzeitlich _überall_ funktionieren (nicht überall selbst getestet...).

Kommt das Modul jetzt mit dem üblichen Fhem-Update, und was ist mit der cfg-Datei? Wird die dann auch automatisch upgedated?

Im Moment kommt nichts automatisch, man kann die Files aus dem contrib-Verzeichnis laden, was aber in deinem Fall nicht erforderlich ist, du bist mit den Files aus dem Nebenthread im Moment eh' auf Stand.

Mal sehen, vielleicht geht RHASSPY irgendwann in den normalen FHEM-update-Zyklus, im Moment würde ich gerne zumindest solange warten, bis die neuen Funktionen einigermaßen getestet sind.

Die languageFile sollte man eh' manuell anfassen, das wird man auch künftig manuell machen sollen (ist aber eher eine "Einmalaktion"). Warum, hatte ich hier oder im "Entwicklungs-Thread" neulich man eingehender erläutert.

Mein Pixel4a ist nach wie vor als Satellit vorhanden, und die Räume sind nach wie vor in sentences.ini weiter optional definiert. Mit deiner Erklärung ist siteId2room damit verständlich.

Danke, dann erst mal viel Spaß beim testen. Erläuterungen zur myUtils sollte im Wiki zu finden sein, ansonsten hat die auch eine (sehr kurze) commandref, die man mit "helpRHASSPY_Utils_siteId2room" aufrufen kann (Verbesserungsvorschläge dürfen gemacht werden)...

Mit Gruppen-Intents habe ich mich noch nicht beschäftigt.

Dann wäre das m.E. der nächste Schritt. Bitte im Wiki die "Fortgeschrittenen-Seite" konsultieren (https://wiki.fhem.de/wiki/RHASSPY/Vertiefung) .

[JensS]

Ein Wakeword bei der Android-App wäre zwar schön

Das geht doch, wenngleich es nur im eignen WLAN Sinn macht.
Es gibt einige Posts dazu. https://forum.fhem.de/index.php/topic,113180.msg1132773.html#msg1132773

Gruß Jens

[denis.robel]

Ich spiele seit kurzer Zeit mit Rhassspy, weil ich mein Snips nun leider ablösen musste.

Grundsätzlich funktioniert es, aber leider nicht so easy wie Snips.

Ich habe noch ein paar offene Fragen:

1. Kann man Rhasspy eigentlich so konfigurieren, dass an der base ein Mic und ein Lautsprecher dran ist und zusätzlich noch Satelliten anbinden?

2. Wie kann ich einen MPD damit steuern? (mit Snips ging das über Snips channels)

3. Wie kann man die Empfindlichkeit beim wake word beeinflussen?

4. Wie könnte man eine Wetteransage umsetzen?

VG Denis

[Beta-User]

Grundsätzlich funktioniert es, aber leider nicht so easy wie Snips.

Snips kenne ich nicht, es würde mich aber interessieren, wo Snips "einfacher" war.
(Ok, RHASSPY ist seit gut einem Jahr deutlich umfangreicher in seinen Optionen im Detail, als RHASSPY 0.2 es war. Aber diese Optionen braucht man erst, wenn etwas nicht so funktioniert wie gedacht.)

1. Kann man Rhasspy eigentlich so konfigurieren, dass an der base ein Mic und ein Lautsprecher dran ist und zusätzlich noch Satelliten anbinden?

Klar. Das ist vermutlich die häufigste bei FHEM-Usern eigesetzte Variante und in https://rhasspy.readthedocs.io/en/latest/tutorials/#server-with-satellites beschrieben.

Prinzipiell geht RHASSPY davon aus, dass es genau eine Base gibt, mit dem es kommuniziert. Die Satelliten sollten daher insbesondere "intent" über diese Base abwickeln (nur die kennt insbesondere die ganzen slots, die FHEM automatisch erstellt).

2. Wie kann ich einen MPD damit steuern? (mit Snips ging das über Snips channels)

Klar. Für die Basisfunktionalität reicht es, ihn mit

Code Auswählen Erweitern

attr myMPD genericDeviceType media
zu kennzeichnen und ggf. die devspec am RHASSPY zu ergänzen.

Meine "Sätze" dazu (die Variable für Räume muss dafür vorhanden sein):

Code Auswählen Erweitern

[de.fhem:MediaControls]
( (stoppe|stop){Command:cmdStop} | (starte|start){Command:cmdPlay} ) [die wiedergabe] [am] [$de.fhem.Device-media{Device}][<de.fhem:SetOnOff.rooms>]
(pausiere | halte ){Command:cmdPause} [die wiedergabe] [am] [$de.fhem.Device-media{Device}] [<de.fhem:SetOnOff.rooms>] [an]
(nächstes|nächster){Command:cmdFwd} (lied|titel) [[(am|auf dem)] $de.fhem.Device-media{Device}] [<de.fhem:SetOnOff.rooms>]
(vorheriges|voriges|vorheriger|voriger){Command:cmdBack} (lied|titel) [$de.fhem.Device-media{Device}] [<de.fhem:SetOnOff.rooms>]


rhasspyChannels gibt es auch, das muss aber als userattr separat zugelassen werden. Ich vermute, dass der Weg über eine LightScene für Kanalwechsel usw. einfacher wäre*.

3. Wie kann man die Empfindlichkeit beim wake word beeinflussen?

Ja, siehe Rhasspy-Doku. Hängt halt vom verwendeten System ab... https://rhasspy.readthedocs.io/en/latest/services/#wake-word-detection

4. Wie könnte man eine Wetteransage umsetzen?

Mache ich über GetState*, siehe Rückmeldung zu "get <RHASSPY> test_sentence ...":

Code Auswählen Erweitern

wie wird das wetter heute => GetState {"Device":"wetter","Type":"heute","confidence":1,"customData":null,"input":"wie heute das wetter heute","intent":"GetState","lang":"de","rawInput":"  wie wird das wetter heute","sessionId":"defhem_234_testmode","siteId":"defhem"} => Response: heute Den ganzen Tag lang Klar. Es hat zwischen 3 und 19 Grad und Wind bis 9 Kilometer pro Stunde.
Das geht jetzt (seit ein paar Tagen, aktuelle svn-Version) auch für Type morgen und übermorgen und greift auf ein Weather-Device zu, wobei letzteres im Prinzip beliebig ist.

Bin noch nicht sicher, ob das der optimale Weg ist, aber hier mal ein "Satz" dazu:

Code Auswählen Erweitern

wie ( ist | wird ){Type:heute} [das] wetter{Device} [ ( heute | morgen{Type:morgen} | übermorgen{Type:übermorgen} ) ]
und das Device (auszugsweise):

Code Auswählen Erweitern

attr DeinWetter genericDeviceType info
attr DeinWetter rhasspyMapping GetState:type=heute,response=heute [DeinWetter:fc1_condition] Es hat zwischen [DeinWetter:fc1_tempLow] und [DeinWetter:fc1_tempHigh] Grad und Wind bis [DeinWetter:fc1_wind] Kilometer pro Stunde.\
GetState:type=morgen,response=morgen [DeinWetter:fc2_condition] Es gibt zwischen [DeinWetter:fc2_tempLow] und [DeinWetter:fc2_tempHigh] Grad und Wind bis [DeinWetter:fc2_wind] Kilometer pro Stunde.\
GetState:type=übermorgen,response=Übermorgen [DeinWetter:fc3_condition] Es gibt zwischen [DeinWetter:fc3_tempLow] und [DeinWetter:fc3_tempHigh] Grad bei Wind bis [DeinWetter:fc3_wind] Kilometer pro Stunde.
attr DeinWetter rhasspyName wetter

* bedeutet: Bin noch nicht sicher, was der beste Weg ist, und das ist Thema beim "RHASSPY mit Testsuite optimieren"-Thread...

[denis.robel]

Spannend ist, dass sobald ich für das Wakeword

den host:port:sitedid eintrge, geht die Wakeword Erkennung an der Base über die PS3 Eye nicht mehr. Lösche ich die Einträge klappt es von der Base.

Ich nutze Porcupine.

Mein Setup ist Fhem auf einem PI, mit eigenem MQTT2 Server auf 1883

Rhasspy im Container auf nem separaten Pi mit PS3 Eye, mit internem MQTT auf 20183

Ich habe im FHEM ein MQTT Client angelegt, der auf den internen MQTT Broker von RHASSPY zugreift und ein RHASSPY device.

Ich bekomme aber Wakeword detection von der App nicht hin.

Gibt es irgendwo ein Tutorial für den Mischbetrieb Lokales Mic an der Base + Sateliten via UDP?




 

[Beta-User]

Na ja, eigentlich ist das ein Thema, das m.E. besser im Rhasspy-Forum aufgehoben wäre.
Da meine base headless läuft, kann ich wenig weiterhelfen, gehe aber nach Lektüre dieses Threads bzw. Beitrags: https://community.rhasspy.org/t/udp-wakeword-detection-with-rhasspy-mobile-app/1795/17 davon aus, dass du auch den lokalen Audio-Input von der Base in einen UDP-Stream umleiten mußt (wie auch immer das genau geht).
Vielleicht hängst du dich direkt an den verlinkten Thread ran, da bekommst du vermutlich zu diesem Teilaspekt am schnellsten Hilfe.

[drhirn]

Gibt es irgendwo ein Tutorial für den Mischbetrieb Lokales Mic an der Base + Sateliten via UDP?

Das hat eigentlich alles mit UDP nichts zu tun. Am besten zu Beginn mal gar nicht von "UDP" verwirren lassen. Da geht es nur darum, dass nicht alles an den MQTT-Server übertragen wird, dass eigentlich gar nicht übertragen werden muss, weil man's auch lokal verarbeiten kann. Also, lassen wir das mal einfach außer Acht.

Grundsätzlich ist dein Setup kein Problem. Aber schauen wir zuerst mal, dass an der Base alles läuft und lassen bis dahin die Satelliten (bzw. App) links liegen. Ok?

Wie ist denn die Base derzeit konfiguriert? Kannst du bitte mal die profile.json der Base posten?

[denis.robel]

danke für die Rückmeldung.

ich habe hier was vom Jens gelesen ,dass das wahrscheinlich nicht geht:

https://forum.fhem.de/index.php/topic,113180.msg1132773.html#msg1132773

Ich werde erst einmal im Rhasspy Forum schauen und melde mich wieder.

[Beta-User]

ich habe hier was vom Jens gelesen ,dass das wahrscheinlich nicht geht:

Zwei Beträge vor dem verlinkten (https://community.rhasspy.org/t/udp-wakeword-detection-with-rhasspy-mobile-app/1795/15):

Should be fixed in 2.5.11 and with other wakeword than raven.

@drhirn:
Ich bin da auch nicht so richtig drin, aber die App (und die ESP32-Lösung) kennen nur UDP als Transportlayer für die Wakeword-Geschichte.

Eigentlich sieht für meine diesbezüglich aber nicht allzu erfahrenen Augen das nach der Lösung für solche Fälle aus, was in https://rhasspy.readthedocs.io/en/latest/audio-input/#pyaudio unter "UDP Audio Streaming" beschrieben ist.

[drhirn]

@drhirn:
Ich bin da auch nicht so richtig drin, aber die App (und die ESP32-Lösung) kennen nur UDP als Transportlayer für die Wakeword-Geschichte.

Ja. Wurde mir gerade auch bewusst, als ich die App eben wieder mal getestet habe.