RHASSPY: Unterschied zwischen den Versionen

Aus FHEMWiki
Zeile 485: Zeile 485:
*Die Mapping-Logik (für Namen, mögliche Schaltzustände, etc.) ist wie folgt:
*Die Mapping-Logik (für Namen, mögliche Schaltzustände, etc.) ist wie folgt:
**Sind RHASSPY-spezifische Attribute gesetzt, werden ausschließlich diese verwendet. Natürlich nur für den Zweck des gesetzten Attributs. Ein gesetzter rhasspyName z.B. wird also nicht verhindern, dass die durch ''genericDeviceType'' ermittelten möglichen Schaltzustände ebenfalls gespeichert werden.
**Sind RHASSPY-spezifische Attribute gesetzt, werden ausschließlich diese verwendet. Natürlich nur für den Zweck des gesetzten Attributs. Ein gesetzter rhasspyName z.B. wird also nicht verhindern, dass die durch ''genericDeviceType'' ermittelten möglichen Schaltzustände ebenfalls gespeichert werden.
**Je spezifischer ein Attribut ist, desto eher wird es unspezifische überschreiben. ''alias'' wird also verhindern, dass der (technische) Device-Namen verwendet wird. Aber ein gesetztes Attribut ''rhasspyName''/''alexaName''/''siriName'' wird den ''Alias'' überschreiben. Sind zwei "gleichwertige" Attribute vorhanden (z.B. ''siriName'' und ''alexaName''), werden beide verwendet.
**Je spezifischer ein Attribut ist, desto eher wird es unspezifische überschreiben. ''alias'' wird also verhindern, dass der (technische) Device-Namen verwendet wird. Aber ein gesetztes Attribut ''alexaName'' oder ''siriName'' wird den ''Alias'' überschreiben. Sind zwei "gleichwertige" Attribute vorhanden (z.B. ''siriName'' und ''alexaName''), werden beide verwendet.
*Attribut-Werte werden typischerweise "Zeile für Zeile" gelesen. Wobei gilt, eine Zeile pro Wert/Befehl. Zeilenumbrüche sollten also an den richtigen Stellen gesetzt werden.
*Attribut-Werte werden typischerweise "Zeile für Zeile" gelesen. Wobei gilt, eine Zeile pro Wert/Befehl. Zeilenumbrüche sollten also an den richtigen Stellen gesetzt werden.


== Eigene Intents erstellen ==
== Eigene Intents erstellen ==

Version vom 2. Dezember 2021, 15:21 Uhr


Clock - Under Construction.svg An dieser Seite wird momentan noch gearbeitet.


RHASSPY
Zweck / Funktion
Anbindung von FHEM an den Rhasspy Sprachassistenten
Allgemein
Typ Contrib
Details
Dokumentation Thema
Support (Forum) Frontends/Sprachsteuerung
Modulname 10_RHASSPY.pm
Ersteller BetaUser (Forum /Wiki), drhirn (Forum /Wiki)
Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

Rhasspy ist eine Open-Source Lösung für Spracherkennung und Sprachsteuerung. Es besteht aus einer Sammlung von Scripten, die unter einer einheitlichen Bedienoberfläche zusammengefasst sind, die sehr flexibel genutzt und erweitert werden können. Die Besonderheit an Rhasspy ist, dass es nach der Installation komplett offline betrieben wird. Es wir also keine Sprache zur Erkennung an einen Server im Internet geschickt, und für den Betrieb nur für FHEM werden nur moderate Hardwareanforderungen gestellt - ein aktueller Raspberry Pi ab Modell 3B+ sollte in der Regel genügen.

Die Anbindung weiterer Räume ist über sogenannte "Satelliten" möglich. Dies kann z.B. ein Pi Zero mit Mikro und Lautsprecher sein, ein ESP32 mit entsprechender Hardware oder ein Mobiltelefon mit Android und der entsprechenden App.

Rhasspy besteht aus vielen unterschiedlichen Modulen (Hot-Word Erkennung, Text to Speech, Speech to Text, Intent Erkennung, ...). Alle diese Module kommunizieren miteinander über das MQTT-Protokoll.


Das Modul RHASSPY prüft Teile des MQTT-Traffics, konvertiert diese JSON-Nachrichten in FHEM-Befehle und sendet Nachrichten zurück an Rhasspy um z.B. Antworten über TextToSpeech auszugeben.

RHASSPY verwendet das 00_MQTT2_CLIENT.pm Modul um Nachrichten zu empfangen und zu senden. Daher ist es notwendig, ein MQTT2_CLIENT Device zu erstellen, bevor dieses Modul verwendet werden kann.

Hervorgegangen ist dieses Modul ursprünglich aus dem Snips-Modul, nachdem Snips an Sonos verkauft und somit eingestellt wurde. Danke also an Thyraz, der die grundlegenden Arbeiten erledigt hat!


Info blue.png
In diesem Artikel und der commandref werden folgende Schreibweisen verwendet:
  • RHASSPY bezieht sich auf das FHEM-Modul oder das FHEM-Device
  • Rhasspy bezeichnet die (zentrale) Installation bzw. das Web-Interface, unter dem die Scriptsammlung verwaltet werden kann.



Info blue.png
Was Dialoge betrifft, verlässt sich RHASSPY auf die Mechanismen, die hier beschrieben sind. Dialoge werden also nicht funktionieren, sobald für das Dialogue-Management etwas anderes als RHASSPY eingestellt ist



Erste Schritte

Für Einsteiger in das Thema Rhasspy bzw. RHASSPY gibt es eine Schnellstart-Anleitung, die die ersten grundlegenden Schritte einfach erklärt: RHASSPY/Schnellstart

Es ist auf jeden Fall empfehlenswert, die Schnellstart-Anleitung zuerst durchzulesen, bevor man sich auf dieser Seite weiter in das Thema vertieft.


Installation des RHASSPY Moduls

Das Modul ist derzeit nicht in der "offiziellen" FHEM Distribution enthalten und muss daher manuell installiert werden. Dafür gibt es zwei Möglichkeiten.


FHEM SVN

Im SVN von FHEM ist die jeweils aktuelle "stable" Version des Moduls im contrib-Zweig zu finden. Diese kann mit folgendem Befehl, der im FHEM Befehls-Eingabefeld einzugeben ist, herunter geladen werden:

{ Svn_GetFile('contrib/RHASSPY/10_RHASSPY.pm', 'FHEM/10_RHASSPY.pm') }

Genauere Informationen zu dieser Vorgangsweise finden sich unter Update#Einzelne_Dateien_aus_dem_SVN_holen.

Nach Installation des Moduls muss FHEM neu gestartet werden.


FHEM Update und GitHub

Im GitHub-Repository des Moduls gibt es zwei Branches main und dev. In main ist die stabile Version des Moduls, in dev die jeweils aktuelle Entwicklungsversion. Aus Gründen der Stabilität ist natürlich die aus main zu bevorzugen.

Um das Modul zu installieren beziehungsweise zu aktualisieren, kann der update-Mechanismus von FHEM genutzt werden. Dazu muss das Repository in der Liste der vom update-Befehl verarbeiteten Repos aufgenommen werden:

update add https://raw.githubusercontent.com/fhem/fhem-rhasspy/main/controls_fhem-rhasspy.txt

Anschließend kann mit folgendem Befehl das Modul installiert oder aktualisiert werden:

update all https://raw.githubusercontent.com/fhem/fhem-rhasspy/main/controls_fhem-rhasspy.txt

Wählt man diesen Weg, wird das Modul auch automatisch aktualisiert, wenn ein Update von FHEM durchgeführt wird. Möchte man die Entwicklungsversion verwenden, muss in den beiden Befehlen main durch dev ersetzt werden.

Weitere Informationen zu dieser Vorgangsweise in der stehen in der CommandRef oder im FHEM-Wiki.

Nach Installation des Moduls muss FHEM neu gestartet werden.


Einrichtung MQTT2_CLIENT

Rhasspy kommuniziert hauptsächlich über das MQTT-Protokoll. Und zwar sowohl Rhasspy-intern, wie auch mit FHEM. Da dies auch für die übertragene Sprache und Audio-Dateien gilt und es daher zu sehr viel MQTT-Verkehr kommt, sollte der Rhasspy-interne MQTT-Server verwendet werden. Daher ist die Einrichtung eines MQTT2_CLIENT-Devices notwendig, um die für FHEM relevanten Daten zu beziehen.


Zuerst muss ein MQTT2_CLIENT Device erstellt werden, welches sich mit dem MQTT-Server (Mosquitto) von Rhasspy verbindet:

define <deviceName> MQTT2_CLIENT <ip-oder-hostname-des-mqtt-servers>:<port>


Anschließend wird die clientOrder gesetzt, um die richtige Benachrichtigungsreihenfolge einzustellen. Wird das MQTT2_CLIENT Device nur für RHASSPY verwendet, reicht hier die Angabe RHASSPY. Ansonsten müssen noch alle anderen Devices (z.B. MQTT_GENERIC_BRIDGE, MQTT2_DEVICE) angegeben werden.

attr <deviceName> clientOrder RHASSPY [device2] [device3]


Um die Topics einzuschränken, die das Device abonniert, müssen diese angegeben werden. Wird der MQTT-Server nur für RHASSPY verwendet, reicht die Angabe setByTheProgram. Ansonsten müssen alle für RHASSPY notwendigen Topics eingefügt werden.

attr <deviceName> subscriptions setByTheProgram

bzw.

attr <deviceName> subscriptions hermes/intent/+ hermes/dialogueManager/sessionStarted hermes/dialogueManager/sessionEnded hermes/nlu/intentNotRecognized hermes/hotword/+/detected


Beispiele
  • Rhasspy-interner MQTT-Server wird mit seinem Standard-Port verwendet. Rhasspy läuft auf der selben Maschine wie FHEM. MQTT2_CLIENT wird nur für RHASSPY verwendet.
defmod rhasspyMQTT2 MQTT2_CLIENT localhost:12183
attr rhasspyMQTT2 clientOrder RHASSPY
attr rhasspyMQTT2 subscriptions setByTheProgram
  • Rhasspy läuft auf einem eigenen Server und verwendet einen externen MQTT Server mit eigener Port-Einstellung. MQTT2_CLIENT wird für RHASSPY, aber auch MQTT_GENERIC_BRIDGE und MQTT2_DEVICE verwendet.
defmod rhasspyMQTT2 MQTT2_CLIENT 192.168.1.122:1884
attr rhasspyMQTT2 clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr rhasspyMQTT2 subscriptions hermes/intent/+ hermes/dialogueManager/sessionStarted hermes/dialogueManager/sessionEnded hermes/nlu/intentNotRecognized hermes/hotword/+/detected [zusätzliche Subscriptions für andere MQTT-Module]


Definition von RHASSPY (DEF)

define <name> RHASSPY <baseUrl> <devspec> <defaultRoom> <language> <fhemId> <prefix> <useGenericAttrs> <handleHotword> <encoding>
Info green.pngRHASSPY verwendet sehr oft <parseParams>. Nicht nur im Define, sondern z.B. auch, um Attribut-Werte auszuwerten. Es sollten also alle Parameter im Define in der Form key=value angegeben werden.).
Info green.pngRHASSPY führt jede Menge Daten aus unterschiedlichen Quellen zusammen um seine Funktion erfüllen zu können. Die endgültige Daten-Struktur, die RHASSPY verwendet, kann mittels des list-Kommandos angezeigt werden. Es wird empfohlen, sich diese Daten-Struktur auf jeden Fall anzusehen. Vor allem dann, wenn etwas nicht wie gewünscht funktioniert.

Alle Parameter sind optional. Die meisten werden im Normalfall gar nicht benötigt (z.B. fhemId, prefix). Sollten sie aber verwendet und später geändert werden, kann es zu unvorhergesehenem Verhalten kommen. Speziell beim Einstieg in das Thema RHASSPY sollten nicht mehr, als die ersten drei verwendet werden. Ausgenommen eventuell noch language, möchte man eine andere Sprache als Englisch oder Deutsch verwenden.


baseUrl
Die URL zum Rhasspy-Webservice. Sollten eine Base und mehrere Satelliten verwendet werden, die URL zur Base. Bitte sicherstellen, dass die Adresse richtig ist (IP und Port)! Default ist baseUrl=http://127.0.0.1:12101.
devspec
devspec der Geräte, die mit Rhasspy gesteuert werden sollen. Wenn der genericDeviceType-Support aktiviert ist, ist der Default devspec=genericDeviceType=.+, sonst wird devspec=room=Rhasspy verwendet. Ohne ein passendes Match in der devspec wird kein Gerät mit dem Modul interagieren, egal, ob sonst irgendwelche RHASSPY-spezifischen Attribute beim Gerät gesetzt sind. Genauere Informationen, wie z.B. eine Liste von Geräten oder Kombinationen aus Geräten und Räumen (z.B. devspec=room=livingroom,room=bathroom,bedroomlamp) verwendet werden können, finden sich in der CommandRef.
defaultRoom
Der Name des Standard-Raumes, der verwendet wird, wenn im Sprachkommando kein Raum enthalten ist und auch kein passender für das Device gefunden werden kann. Default ist defaultRoom=default.
language
Sprache, in der mit Rhasspy gesprochen wird. Der Standard-Wert hängt vom global-Device ab. Dieser ist standardmäßig language=en.
fhemId
Wird verwendet um auf MQTT-Seite zwischen mehreren Installationen des RHASSPY-Moduls zu unterscheiden. Ist auch ein Teil des Topic-Trees, auf den die jeweilige RHASSPY-Instanz hört. Default ist fhemId=fhem.
prefix
Wird verwendet um auf FHEM-Seite zwischen mehreren Installationen des RHASSPY-Moduls zu unterscheiden. Praktisch, wenn man mehrere Instanzen von RHASSPY auf einer FHEM Installation laufen hat und z.B. verschiedene Bezeichner für Gruppen und Räume haben möchte (z.B. unterschiedliche Sprachen). Default ist prefix=rhasspy.
useGenericAttrs
Üblicherweise verwendet RHASSPY - wie auch einige andere FHEM Module für Sprachassistenten - das Attribut genericDeviceType um Schaltmöglichkeiten von Geräten automatisch zu erkennen. Dieser Parameter fügt das Attribut genericDeviceType zur globalen Attributliste hinzu. Der Wert 0 verhindert dieses hinzufügen. Default ist useGenericAttrs=1.
encoding
Sollte es Probleme mit Umlauten geben, kann das Character-Encoding geändert werden. Default ist encoding=utf8.
handleHotword
Triggert das Reading hotword, wenn ein Hotword erkannt wurde (und erstellt das Reading, falls noch nicht vorhanden). Weitere Informationen dazu stehen beim Attribut rhasspyHotwords. Default ist handleHotword=0


Info blue.png
Nach dem Definieren eines RHASSPY-Modules sollte das IODev manuell gesetzt werden um ein automatische IO-Zuweisung zu verhindern. Z.B. attr <deviceName> IODev <m2client>.


Beispiele

Läuft Rhasspy auf der selben Maschine wie FHEM, die Sprache ist im global-Device bereits richtig eingestellt und der Standardraum entspricht der siteID, die in Rhasspy vergeben wurde:

define Rhasspy RHASSPY

Läuft Rhasspy auf einem anderen System wie FHEM, der Standard-Raum enspricht nicht dem, was Rhasspy liefert, die Sprache soll auch anders sein und es sollen sowohl Geräte mit vorhandenem genericDeviceType Attribut, als auch die Geräte device_a1 und device_xy gesteuert werden:

define Rhasspy RHASSPY baseUrl=http://192.168.1.210:12101 defaultRoom="Büro Lisa" language=de devspec=genericDeviceType=.+,device_a1,device_xy handleHotword=1


Set-Befehle (SET)

customSlot
Erstellt einen neue - oder überschreibt einen alten - Slot in Rhasspy
slotname und slotdata sind verpflichtend
overwrite ist optional. Default ist overwrite=true. Das Setzen eines anderes Wertes verhindert das Überschreiben einen bereits bestehenden Slot mit gleichem Namen.
training ist optional. Default ist training=true. Das Setzen eines anderen Wertes verhindert ein Training von Rhasspy nach dem Speichern des Slots.
Beispiele:
set <rhasspyDevice> customSlot mySlot a,b,c overwrite training
set <rhasspyDevice> customSlot slotname=mySlot slotdata=a,b,c overwrite=false


fetchSiteIds
Liest alle in Rhasspy vorhandenen siteIDs aus und speichert sie im Reading siteIds. Wird z.B. verwendet, um festzustellen, auf welchem Satelliten der User über das Ende eines Timers benachrichtigt werden soll.
Muss immer ausgeführt werden, wenn eine neue siteId in Rhasspy hinzugefügt wird (neuer Satellit z.B.).
Beispiel:
set <rhasspyDevice> fetchSiteIds


play
Sendet eine WAV Datei an Rhasspy.
siteId und <path> sind verpflichtend!
Optional kann die Anzahl der Wiederholungen (Default: 1) und die Dauer der Pause zwischen den jeweiligen Wiederholungen (Default: 15) angeben werden.
Beispiele:'
set <rhasspyDevice> play siteId="default" path="/opt/fhem/test.wav"
set <rhasspyDevice> play siteId="default" path="./test.wav" repeats=3 wait=20


speak
Sendet einen Text an das TTS-Sytem, welches ihn dann als Sprache ausgibt.
Beide Argumente siteId und text sind verpflichtend!
Beispiel:
set <rhasspyDevice> speak siteId="wohnzimmer" text="This is a test"


textCommand
Sendet ein Text-Kommando an Rhasspy.
Example:
set <rhasspyDevice> textCommand schalte das licht ein


trainRhasspy
Startet das Training von Rhasspy.
Beispiel:
set <rhasspyDevice> trainRhasspy


update
devicemap
Wenn an der Konfiguration von RHASSPY oder an den von ihm gesteuerten Geräten etwas geändert wurde, muss dieser Befehl ausgeführt werden, um die Datenstruktur von RHASSPY zu aktualisieren, Rhasspy von den Änderungen zu informieren (Slots z.B.), ein Training zu starten, etc.
Beispiel:'
set <rhasspyDevice> update devicemap
devicemap_only
Aktualisiert die Datenstruktur von RHASSPY. Es werden weder Slots in Rhasspy geändert, noch das Training gestartet.
Beispiel:
set <rhasspyDevice> update devicemap_only
slots
Aktualisiert (bzw. erstellt) alle Slots in Rhasspy mit den aktuellen Geräten, Räumen, usw.
Erstellte/Aktualisierte Slots sind z.B.:
  • de.fhem.AllKeywords
  • de.fhem.Device
  • de.fhem.Device-genericDeviceType
  • de.fhem.Group
  • de.fhem.Room
  • de.fhem.MediaChannels
  • de.fhem.Color
  • de.fhem.NumericType
(Hinweis: Die ersten beiden Teile de und fhem hängen von der DEF des RHASSPY-Devices ab)
Beispiel:
set <rhasspyDevice> update slots
slots_no_training
Wie slots, aber ohne Training nach dem Update.
Beispiel:
set <rhasspyDevice> update slots_no_training
language
Liest das das Sprach-File (languageFile) neu ein.
Muss immer ausgeführt werden, wenn in diesem File oder dem Attribut languageFile etwas geändert wurde!
Beispiel:
set <rhasspyDevice> update language
intent_filter
Setzt die Intent Filter, die vom Rhasspy Dialogue Manger verwendet werden zurück. Details dazu bei intentFilter im rhasspyTweaks-Attribut.
Beispiel:
set <rhasspyDevice> update intent_filter
all
Aktualisiert die Devicemap und das languageFile
Beispiel:
set <rhasspyDevice> update all


volume
Stellt die Lautstärke der gewünschten siteId auf einen Wert zwischen 0 and 1 (float).
Beide Argumente siteId volume sind verpflichtend.
Beispiel:
set <rhasspyDevice> siteId="default" volume="0.5"


Info blue.png
Bitte nicht vergessen, dass nach jeder Änderung an RHASSPY oder an einem von RHASSPY gesteuerten Gerät ein update devicemap ausgeführt werden muss!


Attribute (ATTR)

Um RHASSPY zum Laufen zu bringen, müssen unterschiedliche Attribute gesetzt werden. Dabei gibt es

  • Attribute, die im RHASSPY-Device selbst gesetzt werden müssen und
  • Attribute, die in den Devices gesetzt werden müssen, die von RHASSPY kontrolliert werden sollen.

Letztere werden im Abschnitt #Tbd behandelt.

In diesem Abschnitt werden die Attribute behandelt, die auf das RHASSPY-Device selbst wirken.


IODev
Das MQTT2_CLIENT Device, welches die MQTT-Nachrichten für RHASSPY liefert.
Beispiel:
attr <rhasspyDevice> IODev rhasspyMQTT2


forceNext
Wenn dieses Attribut auf 1 gesetzt ist, leitet RHASSPY eingehende MQTT-Nachrichten an andere MQTT2-IO-Client Module wie MQTT2_DEVICE weiter, auch wenn das Topic zu einem von RHASSPY abonnierten passt.
Standardmäßig werden diese Nachrichten nicht weitergeleitet um eine bessere Kompatibilität mit dem autocreate-Feature des MQTT2_DEVICE sicher zu stellen.
Siehe dazu das clientOrder-Attribut in der CommandRef zum MQTT2_CLIENT Device.
Das Setzen dieses Attributs in einer RHASSPY-Instanz kann auch andere eventuell vorhandene RHASSPY-Instanzen beinflussen.
Default ist 0
Beispiel:
attr <rhasspyDevice> forceNext 1


languageFile
Pfad zur Sprach-Datei
Ist dieses Argument nicht gesetzt, wird ein Standard-Set an englischen Sätzen für die Sprachantworten verwendet.
Die Datei selbst muss ein gültiges JSON-File sein, dass sich nach der Struktur aus den englischen Standardwerten richtet.
Eine deutsche Beispiel-Datei ist in SVN und GitHub vorhanden. Man kann aber einfach ein Dump der englischen Struktur machen (replace RHASSPY by your device's name: {toJSON($defs{RHASSPY}->{helper}{lng})}, das Ergebnis dann bearbeiten und es als eigenes languageFile verwenden.
Im Standard-Set sind auch einige Variablen enthalten. Auch die können im eigenen File verwendet werden.
languageFile erlaubt auch eine Kombination aus vorhandenen und eigenen Sätzen. Dazu können die eigenen Sätzen einfach im Sub-Tree user abgelegt werden.
Beispiel: (vorausgesetzt, die Sprach-Datei ist im selben Verzeichnis wie fhem.pl):
attr <rhasspyDevice> languageFile ./rhasspy-de.cfg


response
Hinweis:: Die Verwendung dieses Attributs ist nicht mehr empfohlen. Bessere Alternative ist die Sprach-Datei.


rhasspyHotwords
Kann verwendet werden, um benutzerdefinierte Aktionen auszuführen, sobald ein bestimmtes Hotword erkannt wurde. Dazu sind keine speziellen Konfigurationsschritte in anderen FHEM Devices notwendig.
Wenn mittels Attribut oder DEF aktiviert, wird ein Reading hotword erstellt und mit dem erkannten Hotword und der siteId befüllt um ein Event-Handling zu ermöglichen.
NOTE: As all hotword messages are sent to a common topic structure, you may need additional measures to distinguish between several RHASSPY instances, e.g. by restricting subscriptions and/or using different entries in this attribute.
Ein Hotword pro Zeile, Syntax entweder einfach oder erweitert
Beispiele:
bumblebee_linux = set amplifier2 mute on
porcupine_linux = livingroom="set amplifier mute on" default={Log3($DEVICE,3,"device $DEVICE - room $ROOM - value $VALUE")}
Im ersten Beispiel wird der Befehl immer ausgeführt, wenn das Hotword bumblebee_linux erkannt wurde.
Im zweiten nur, wenn das Hotword porcupine_linux in der siteId livingroom erkannt wurde.
$DEVICE wird ausgewertet als der Name des RHASSPY Devices, $ROOM als siteId und $VALUE als das verwendete Hotword.


rhasspyIntents
Definiert einen benutzerdefinierten Intent.
Ein Intent pro Zeile.
Beispiel:
attr <rhasspyDevice> rhasspyIntents SetCustomIntentsTest=SetCustomIntentsTest(siteId,Type)
in Kombination mit folgendem myUtils-Code
sub SetCustomIntentsTest {
my $room = shift;
my $type = shift;
Log3('rhasspy',3 , "RHASSPY: Room $room, Type $type");
return "RHASSPY: Room $room, Type $type";
}
schreibt einen Log-Eintrag nach jedem Aufruf dieses Intents.
Die folgenden Argumente können dabei übergeben werden:
  • NAME => Name des RHASSPY-Devices
  • DATA => komplette JSON-$data (wie intern geparsed), in JSON kodiert
  • siteId, Device etc. => jedes Element, das in JSON-$data existiert
Wird von der Funktion ein einfacher Text zurück geliefert, wird dieser als response angesehen. Wenn der Rückgabewert nicht definiert ist, wird die Standard-response verwendet.
Es kann aber auch ein HASH oder ARRAY übergeben werden.
Im Falle eines ARRAYs wird das erste Element als response interpretiert und kann ein reiner Text sein, womit der Dialog beendet wird. Ist das erste Element ein HASH wird die Dialog-Session fortgesetzt. Eine offene Dialog-Session wird per Default nach 20 Sekunden beendet. Diese Zeitspanne kann aber auch geändert werden, in dem im ARRAY als zweiter Wert eine Zahl übergeben wird. Das zweite Element kann aber auch eine komma-getrennte Liste an Geräten sein, die geändert (geschalten) wurden. Das dient dazu, damit die Geräte auch Events liefern, was ansonsten nicht der Fall wäre. Siehe dazu den "d"-Parameter beim Attribut rhasspyShortcuts.
If HASH type data (or $response in ARRAY) is returned to continue a session, make sure to hand over all relevant elements, including especially intentFilter if you want to restrict possible intents. It's recommended to always also activate CancelAction to allow user to actively exit the dialoge.
Siehe dazu auch den Abschnitt #Eigene Intents erstellen.


rhasspyShortcuts
Hiermit können benutzerdefinierte Sätze erstellt werden ohne die sentences.ini in Rhasspy bearbeiten zu müssen.
Diese Shortcuts werden zu Rhasspy hochgeladen, sobald das updateSlots Set-Kommando ausgeführt wird.
Ein Shortcut pro Zeile, Syntax ist entweder einfach oder erweitert.
Beispiele:
mute on=set amplifier2 mute on
lamp off={fhem("set lampe1 off")}
i="du bist cool" f="set $NAME speak siteId='livingroom' text='danke dir! du bist noch viel cooler!'"
i="schalte den ton aus" p={fhem ("set $NAME mute off")} n=amplifier2 c="soll ich den ton wirklich ausschalten?"
i="ich hab hunger" f="set Herd on" d="Herd" c="möchtest du schweinsbraten?"
Erklärung zu den Abkürzungen:
  • i => intent
Zeilen, die mit i beginnen, werden als erweiterte Syntax interpretiert. Soll die erweiterte Syntax verwendet werden, ist das i also Pflicht!
  • f => FHEM Befehl
Syntax wie von der FHEM Kommandozeile gewohnt
  • p => Perl Befehl
Syntax wie von der FHEM Kommandozeile gewohnt, eingerahmt in geschwungenen Klammern ({}). p hat Vorrang vor f
  • d => Device Name(en, Komma getrennt)
Device Name(n), die an fhem.pl als upgedated übergeben werden sollen. Das wird benötigt um weitere Aktionen in FHEM und das Longpolling zu triggern.
Hinweis: Wenn Perl-Funktionen aufgerufen werden, wird der Rückgabewert dieser Funktion verwendet, sofern kein explizites Device angegeben ist.
  • r => Response
Sprachanwort, die ausgegeben wird. Ist r nicht gesetzt, wird der Rückgabewert der aufgerufenen Funktion verwendet.
In den Antwortsätze werden set magic-ähnliche Ersetzungen verarbeitet. Es ist also auch eine Zeile wie i="what's the time for sunrise" r="at [Astro:SunRise] o'clock" gültig.
Mit den folgenden Abkürzungen kann auch nach einer Bestätigung für den Befehl gefragt werden:
  • c => Entweder Zahl oder Text. Wenn Zahl, wird sie als Timeout für den Abbruch des Dialogs behandelt. Wenn Text wird dieser als Sprachausgabe zur Bestätigung verwendet.
  • ct => Numerischer Wert für das Timeout des Dialogs in Sekunden. Default ist 15.
Siehe hier für weitere Informationen zu Bestätigungen.


rhasspyTweaks

Mit diesen Einstellungen können benutzerdefinierte Optimierungen an RHASSPY vorgenommen werden.

  • timerLimits
Wird verwendet um den Timer anzuweisen mit z.B. "gestellt auf 30 Minuten" oder "gestellt auf 10:30" zu antworten
timerLimits=90,300,3000,2*HOURSECONDS,50

Hierbei müssen fünf Werte gesetzt werden, corresponding with the limits to timerSet responses.
Obiges Beispiel also würde dazu führen, unter einer eingestellten Zeit von 90 Sekunden mit der Sekundenangabe geantwortet wird. In Minuten und Sekunden solange der Timer kürzer als 300 Sekunden ist. Usw. Der letzte Wert ist das Limit in Sekunden, wenn der Timer im "Uhrzeit"-Format gestellt ist.

  • timerSounds
Standardmäßig antwortet der Timer mit einer Sprachnachricht, wenn er abgelaufen ist. Soll lieber eine WAV-Datei verwendet werden, kann das hier eingestellt werden.
timerSounds= default=./yourfile1.wav eier=3:20:./yourfile2.wav kartoffeln=5:./yourfile3.wav
Die Keys in dieser Code-Zeile sind Beispiele und deren Name - bis auf default frei wählbar. Der Name muss aber zu den Label-Tags für die Timer in den Rhasspy-Sentences passen.
default ist optional. Wenn gesetzt, wird dieses WAV-File für alle benannten Timer verwendet, für die kein Keyword in der Konfiguration ist.
Die beiden Nummern sind optional. Die erste legt fest, wie oft die WAV-Datei wiederholt werden soll (Default: 5). Die zweite definiert die Pause in Sekunden zwischen den Wiederholungen (Default: 15). Ist nur eine Zahl gesetzt, wird diese als gewünschte Anzahl an Wiederholungen interpretiert.
  • updateSlots
Ändert diverse Aspekte des Erstellens und Updatens von Slots
  • noEmptySlots=1
Per Default generiert RHASSPY einen zusätzlichen Slot für jeden genericDeviceType, der erkannt wird. Unabhängig davon, ob er bei einem Gerät gesetzt ist. Das kann zu leeren Slots führen.
Ist der Wert 1, werden keine leeren Slots erstellt.
  • overwrite_all=false
RHASSPY überschreibt alle vorhandenen Slots wenn ein updateSlots ausgeführt wird. Ist das nicht gewünscht, muss dieser Wert auf false gesetzt werden.
  • timeouts
Die Keywörter confirm und default können verwendet werden, um das Standard-Timeouts (15s/20s) für Dialoge zu ändern.
Beispiel:
timeouts: confirm=25 default=30
  • confirmIntents
Hiermit kann eingestellt werden, dass für bestimmte Intents immer ein Bestätigung erfragt wird. Unterstützt werden derzeit alle "set-"-Intents.
Dazu werden Intent=regex-Paare verwendet.
Intent ist der Name des gewünschten Intents
regex ist eine Regex, die eine bestimmte Gruppe (für Gruppen-Intents) oder einen bestimmten Device-Namen beschreiben muss.
Beispiel:
confirmIntents=SetOnOffGroup=light|blinds SetOnOff=blind.*
Befehle werden nur nach einer positiven Bestätigung ausgeführt. Das bedeutet, es muss unbedingt ein Mode:OK-Wert vom ConfirmAction-Intent gesendet werden. Jede andere Wert für Mode wird als Abbruch gewertet. Es kann aber auch der eigene Intent CancelAction für den Abbruch verwendet werden.
Beispiel:
[de.fhem:ConfirmAction]
( yes, please do it | go on | that's ok | yes, please ){Mode:OK}
( don't do it after all ){Mode}

[de.fhem:CancelAction]
( let it be | oh no | cancel | cancellation ){Mode:Cancel}
  • confirmIntentResponses
Üblicherweise ist die Bestätigungs-Frage ein "Echo" des ursprünglich gesprochenen Befehls. Dies kann für jeden Intent geändert werden,

You may change this for each intent specified using $target, ($rawInput) and $Value als parameters.
Beispiel:
confirmIntentResponses=SetOnOffGroup="really switch group $target $Value" SetOnOff="confirm setting $target $Value"
$Value may be translated with defaults from a words key in languageFile, for more options on $Value and/or more specific settings in single devices see also confirmValueMap key in rhasspySpecials.

  • intentFilter

Atm. Rhasspy will activate all known intents at startup. As some of the intents used by FHEM are only needed in case some dialogue is open, it will deactivate these intents (atm: ConfirmAction, CancelAction, ChoiceRoom and ChoiceDevice(including the additional parts derived from language and fhemId))) at startup or when no active filtering is detected. You may disable additional intents by just adding their names in intentFilter line or using an explicit state assignment in the form intentname=true (Note: activating the 4 mentionned intents is not possible!). For details on how configure works see Rhasspy documentation.

  • ignoreKeywords

You may have also some technically motivated settings in the attributes RHASSPY uses to generate slots, e.g. MQTT, alexa, homebridge or googleassistant in room attribute. The key-value pairs will sort the given value out while generating the content for the respective slot for key (atm. only rooms and group are supported). value will be treated as (case-insensitive) regex with need to exact match.
Beispiel:
ignoreKeywords=room=MQTT|alexa|homebridge|googleassistant|logics-.*
Note: requires restart to take full effect, will only affect content from general room, group or alexaRoom attributes.

Readings / Events

IODev
Das eingestellte IO-Device
intents
Eine Liste der in Rhasspy vorhandenen Intents
lastIntentPayload
Inhalt des letzten Intents der von FHEM empfangen wurde
lastIntentTopic
Das MQTT-Topic des letzten Intents
listening_roomname
Ein Reading für jeden Raum bzw. jede siteId
Wechselt auf 1 sobald ein Hotword erkannt wurde und zurück auf 0, sobald die Dialog-Session beendet ist.
Kann z.B. verwendet werden, um den Ton eines TVs auszuschalten, während Rhasspy auf ein Kommando hört.
mute_roomname
Zeigt an, ob ein Raum / eine siteId vom Intent SetMute stumm geschalten wurde und somit keine Befehle ausführt.
Jeweils ein Reading für jede siteId.
Default ist 0.
responseType
Der Typ der letzten Antwort (text/voice).
voiceResponse and textResponse
Antwort auf das letzte Sprach-/Text-Kommando.
siteIds
Listet alle siteIds auf.
Kann mit fetchSiteIds aktualisiert werden.
state
Zeigt an ob RHASSPY mit Rhasspy verbunden ist
training
Letzte zurückgelieferte Antwort auf einen trainRhasspy-Befehl.
updateSlots
Letzte zurückgelieferte Antwort nach einem updateSlots-Befehl.
hotword
Wenn aktiviert, beinhaltet dieses Reading das letzte verwendete Hotword und von welcher siteId es aufgerufen wurde.
voiceResponse
Letze Sprach-Antwort auf einen Sprach-Befehl

FHEM-Devices für die Verwendung mit Rhasspy konfigurieren

Um ein Gerät mit Rhasspy steuern zu können, muss Rhasspy einige Details über das Gerät kennen. Diese werden bekannt gemacht, in dem bei den Geräten Attribute gesetzt werden, die anschließend vom RHASSPY-Modul ausgewertet und an Rhasspy gesendet werden.

Der einfachste - und empfohlene - Weg, dies zu erreichen, ist durch Setzen des Attributs genericDeviceType. Das Modul erkennt dann die möglichen Schalt - und Abfragemöglichkeiten des Gerätes automatisch.

Sollte genericDeviceType (gDT) nicht ausreichen, gibt es noch weitere Attribute, die stattdessen oder ergänzend dazu verwendet werden können (z.b. rhasspyName, rhasspyRoom, ...). Die Namen dieser Attribute beginnen alle mit dem prefix, das in der DEF des RHASSPY-Moduls gesetzt wurde. Diese Dokumentation verwendet das Prefix rhasspy.

Sind sowohl genericDeviceType als auch Spezial-Attribute vorhanden, werden die von gDT gesammelten Möglichkeiten durch die der Spezial-Attribute überschrieben.


Wichtig:

  • Nach JEDER Änderung an den folgenden Attributen muss ein update devicemap ausgeführt werden. Sonst erfahren weder RHASSPY, noch Rhasspy von der Änderung.
  • RHASSPY sammelt alle Informationen aus diesen Attributen in seinem eigenen Device-HASH. Dieser wird durch das update devicemap-Kommando aktualisiert und kann mittels list-Befehl angezeigt werden. Für diesen HASH werden alle Namen und sonstige "Labels" in Kleinbuchstaben umgewandelt. Sollte man Slots händisch befüllen, muss also darauf geachtet werden, dass Rhasspy ebenfalls Werte in Kleinbuchstaben liefert.
  • Die Mindestvoraussetzungen für ein FHEM Device um mit RHASSPY zusammenzuarbeiten sind:
    • Das Device muss von der devspec im Define des RHASSPY-Devices abgedeckt werden
    • Es muss mindestens eines der folgenden Attribute (im Normalfall genericDeviceType) im Device gesetzt sein.
  • Die Mapping-Logik (für Namen, mögliche Schaltzustände, etc.) ist wie folgt:
    • Sind RHASSPY-spezifische Attribute gesetzt, werden ausschließlich diese verwendet. Natürlich nur für den Zweck des gesetzten Attributs. Ein gesetzter rhasspyName z.B. wird also nicht verhindern, dass die durch genericDeviceType ermittelten möglichen Schaltzustände ebenfalls gespeichert werden.
    • Je spezifischer ein Attribut ist, desto eher wird es unspezifische überschreiben. alias wird also verhindern, dass der (technische) Device-Namen verwendet wird. Aber ein gesetztes Attribut alexaName oder siriName wird den Alias überschreiben. Sind zwei "gleichwertige" Attribute vorhanden (z.B. siriName und alexaName), werden beide verwendet.
  • Attribut-Werte werden typischerweise "Zeile für Zeile" gelesen. Wobei gilt, eine Zeile pro Wert/Befehl. Zeilenumbrüche sollten also an den richtigen Stellen gesetzt werden.

Eigene Intents erstellen

Beispiele

Links