Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Das, was in sentences.ini für ConfirmAction => OK hinterlegt ist.

Die "stotterei" etc.  ist noch ein "todo"....

[Raemsna]

Das, was in sentences.ini für ConfirmAction => OK hinterlegt ist.

Die "stotterei" etc.  ist noch ein "todo"....

Vielen Dank (mal wieder) für die schnelle Hilfe. Ich wär nicht draufgekommen, wobei es total logisch ist... :/

Grüße

[Beta-User]

Vielen Dank (mal wieder) für die schnelle Hilfe. Ich wär nicht draufgekommen, wobei es total logisch ist... :/

Logisch vielleicht, aber leider bisher nicht dokumentiert...

Vielen Dank für das tolle Modul!!

Insgesamt ist die Implemetierung der aktuellen Rhasspy-Version in FHEM gut gelungen und funktioniert auch gut.

Ein fesses DANKE an euch für das nette feedback!

Nachdem bei RHASSPY grade wieder ein bißchen was los war, anbei mal wieder ein (eher kleines und noch ungetestetes) update, das einige der jüngst genannten Punkte aufgreift. Habe mal die Versionsnummer auf 0.5.0 gehoben, damit wir nicht wirklich irgendwann bei 0.4.99 ankommen, aber das soll nicht bedeuten, dass es was substantiell neues gäbe .

"Neuerungen":
- gassistant scheint mit "blinds" statt "blind" zu arbeiten (https://forum.fhem.de/index.php/topic,124240.msg1188444.html#msg1188444). Daher gibt es jetzt eine Art "aliasing" für gDT "blinds" und "shutter". Das Vorgehen an sich ist generisch, man könnte das stressfrei auf ähnliche Fälle erweitern;
- da Gisbert unbedingt mit einem Rollladen starten wollte, ist mir aufgefallen, dass ein "stop"-Kommando doch auch ganz nett wäre. Könnte sein, dass es klappt, wenn der Rollladen so einen setter hat und man in "Change" für "stop" "cmdStop" übergibt ([de.fhem:SetNumeric] => ( halte | stoppe ) ( den | die ) $de.fhem.Device-blind{Device} [an] {Change:cmdStop}). Da ziemlich sicher meine Lamellen dann "falsch" stehen bleiben werden, gibt es auch noch einen weiteren Eintrag in den "specials" für venetian blinds... (Achtung: Status insgesamt ist komplett ungetestet ).
- die default-devspec hängt jetzt davon ab, ob man "gDT" nutzt. Wenn ja, werden alle Devices erfasst, bei denen einer gesetzt ist...
- die commandref war vielleicht etwas missverständlich, was das mit der devspec angeht, ist aus gegebenem Anlass auch renoviert.

Die Dialog-Geschichte inkl. Confirm und Cancel ist eine gute Sache. Derzeit sehe ich aber Grenzen bei Rhasspy selbst.
[...]
Das führt u.a. zur erwähnten "Stotterei", welche durch die IntentNotRecognized-Behandlung noch verstärkt wird.

Da das nervig ist, habe ich mal versucht, diesen Teil wegzuschalten. Ebenfalls ungetestet, Wiedereinschalten müßte mit "experimental=1" in der DEF gehen.

Im Hinterkopf habe ich auch noch den pah'schen Ansatz, ggf. auf bestimmte WakeWords direkt Aktionen auszuführen. An sich dürfte sowas als reines "Input-Device" einfacher mit MQTT2_DEVICE abzufackel sein, aber andererseits könnte es hilfreich sein, z.B. für bestimmte siteId's dann beim Erkennen eines bestimmten WakeWords auch bestimmte Vorbereitungs-Aktivitäten zu entfalten (Lautstärke der Musik runter, damit der eigentliche Sprechtext besser erkannt werden kann oä.). Von daher schadet eine zusätzliche Option innerhalb des Moduls vermutlich nicht. (FHEM- oder Perl-Kommandos, RHASSPY-Name, wakeword und siteId als Parameter auflösbar?).
Meinungen: Gerne...

Viel Spaß beim Testen, CU

EDIT: Anhang entfernt, da waren ein paar Kleinigkeiten beim Testen, die erst ausgebügelt werden müssen. Update folgt...

[Beta-User]

Gestern hatten sich leider (mind.) zwei kleinere Problemchen eingeschlichen bzgl. der default-devspec (wenn man was gesetzt hatte), und bei der Erstellung der "blind"-slots . Sollte mit der angehängten Version wieder funktionieren.

Da mir das mit der hotword-Reaktion als Idee gefallen hat, gibt's jetzt ein neues Attribut "rhasspyHotwords" (siehe commandref, da ist auch die einfachere Form via DEF zu finden). Wer die subscriptions manuell gesetzt hat, muss diese um "hermes/hotword/+/detected" ergänzen, damit was beim Modul ankommt.

Viel Spaß!

EDIT: Modul nochmal getauscht. Funktional keine Unterschiede, aber die commandref im Bereich der "Musterdefinitionen" von M2C und RHASSPY erweitert.

EDIT2: Scheint zumindest zum großen Teil zu funktionieren.
Hier ein "stopCommand"-Beispiel für meine ZWave-FGR-222

Code Auswählen Erweitern

attr Jalousie_Mitte rhasspySpecials venetianBlind:setter=positionSlat stopCommand="set Jalousie_Mitte positionSlat [Jalousie_Mitte:positionSlat]"


[laberlaib]

Hallo,

ich glaube, es gibt einen Bug beim einlesen der SiteIds.
Es wird dabei über die API gegangen:

Code Auswählen Erweitern

http://192.168.2.81:12101/api/profile?layers=profile

Code Auswählen Erweitern

{
    "dialogue": {
        "satellite_site_ids": "sat1,handylaib",
        "system": "rhasspy"
    },
    "intent": {
        "satellite_site_ids": "sat1,handylaib",
        "system": "fsticuffs"
    },
    "mqtt": {
        "site_id": "masterde"
    },
    "speech_to_text": {
        "satellite_site_ids": "sat1,handylaib",
        "system": "kaldi"
    },
    "text_to_speech": {
        "satellite_site_ids": "sat1,handylaib",
        "system": "nanotts"
    }
}

Aber lt. Rhasspydoku braucht man bei Master-Satellite-Aufbau keinen Dialoguemanager beim Master:
https://rhasspy.readthedocs.io/en/latest/tutorials/#server-with-satellites
(siehe Bild in der Anlage).

Mein per app angebundenes Handy (handylaib) war daher nicht auffindbar, trotz update slots. Erst nach dem ich einmal Dialogue Managerment an und konfiguriert hatte, war das der Fall.

Obs Auswirkungen hat(te)? Keine Ahnung. Bei mir hängt gerade unabhängig von der Eingabe (per Text direkt auf dem master oder auf der Handyapp) die Info am MQTT2-Device und kommt nicht weiter. Da muss ich noch mal reingucken.
Edit: Die IP des Masters hatte sich geändert und ich hatte diese sowohl im MQTT2-Device als auch im RHASSPY-Device geändert und letzteres auch durch einen reload 10_RHASSPY neu gestartet. Jetzt einen kompletten FHEM restart mal gemacht und es klappt. Im log hatte ich beim MQTT2-Dvice mit verbose 5 die Meldungen, dass was ankommt, drum habe ich das nicht regeloaded. Egal, klappt.
Merke: an irgendeiner Konfig mit vielen Abhängigkeiten rumspielen => Restart FHEM

laberlaib

[Beta-User]

Hmm, bin im Moment auch überfragt, ob/welche Auswirkungen das hat und wie man es ggf. "besser" machen kann.
Theoretisch könnte man alle Ober-Keys durchgehen, um dann die Werte in den "satellite_site_ids" nacheinander durchzugehen und ggf. zu ergänzen, was fehlt.

Allerdings habe ich jetzt beim schnellen Überfliegen des Codes keine Stelle gefunden von der ich annehmen würde, dass das irgendwelche Auswirkungen hat. Vermutlich übersehe ich was.

@drhirn: Deine Meinung?

die Info am MQTT2-Device

verstehe ich nicht bzw. meine Glaskugel meint, clientOrder am MQTT2_CLIENT wäre eventuell nicht/falsch gesetzt?

[laberlaib]

verstehe ich nicht bzw. meine Glaskugel meint, clientOrder am MQTT2_CLIENT wäre eventuell nicht/falsch gesetzt?

Nope, war eingestellt. Hatte auch "früher" funktioniert - erst nach dem ich die IP geändert hatte, da ich meinen Master ins mein offizielles IP-Schema gepresst hatte, wars aus mit der Herrlichkeit.
Aber ist egal, Ihr schreibt das ja auch in der Anleitung, dass das Effekte haben kann und mein Bugreport diesbezüglich ist ja auch... unbrauchbar, sagen wirs direkt.

[Beta-User]

Nope, war eingestellt. Hatte auch "früher" funktioniert - erst nach dem ich die IP geändert hatte, da ich meinen Master ins mein offizielles IP-Schema gepresst hatte, wars aus mit der Herrlichkeit.

Hatte neulich auch so einen ähnlichen Effekt, scheinbar liest M2C das Attribut nicht, wenn man die DEF ändert. Ein Neustart hatte das dann behoben, vielleicht hilft das bei dir auch (bzw. einfach das Attribut nochmal setzen, und eine "fake-Änderung" einbauen (zusätzliches Leerzeichen)).

Aber ist egal, Ihr schreibt das ja auch in der Anleitung, dass das Effekte haben kann und mein Bugreport diesbezüglich ist ja auch... unbrauchbar, sagen wirs direkt.

Na ja, hier jedenfalls zum Testen ein Vorschlag für das "siteIds-Problem" (Abschnitt ab Zeile 2739):

Code Auswählen Erweitern

    elsif ( $url =~ m{api/profile}ix ) {
        my $ref;
        if ( !eval { $ref = decode_json($data) ; 1 } ) {
            readingsEndUpdate($hash, 1);
            return Log3($hash->{NAME}, 1, "JSON decoding error: $@");
        }
        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});
            }
        }
        my @ids = uniq(split q{,},$siteIds);
        readingsBulkUpdate($hash, 'siteIds', join q{,}, @ids);
    }

[laberlaib]

Danke.
wenn ich das Handy meiner Frau "anschließe" werde ichs mal auf diese Weise probieren.
Stichwort Handy der Frau:

Ich habe jetzt ein rhasspy-es.cfg quasi fertig. 4-5 neu hinzugekommene Sätze muss ich noch mal nachfragen/verifizieren.
https://github.com/laberlaib/fhem-rasspy-some-data
Ein paar Fragen dazu:

1) Hätte ich jetzt meine alte spanische Sprachdatei nicht überarbeitet, dann hätten da Sätze gefehlt. Hätte das was ausgemacht oder ist auch für die eine Englische Fallbackdatei sowieso immer implementiert? Dies ist so nur für "commaconversion", "units" und "mutated_vowels" angegeben.
2) "User" ist klar; heißt das aber auch, dass bei einem FHEM-Update-Befehl (hinterlegte controls für 10_RHASSPY vorausgesetzt) die rhasspy-de.cfg auch nicht aktualisiert wird und man das händisch machen muss?
3) slots: Hier werden derzeit Farbbezeichnungen in HEX-Werte "übersetzt". D.h. ich müsste für ein komplettes File auch die Bezeichnungen ins spanische übersetzen (von einer Farbtabelle abschreiben)?
Ist das auch der Ort, wo ich eigenen Slots einbringen kann oder gibt es dafür eine andere Funktion?

ich würde dann einfach ein weiteres RHASSPY-DEVICE mit

Code Auswählen Erweitern

language=es fhemId=fhemEs prefix=rhasspyEs anlegen,

Code Auswählen Erweitern

attr <rhasspy> configFile ./FHEM/rhasspy-es.cfg setzen und ab die Post.

[Beta-User]

1) Hätte ich jetzt meine alte spanische Sprachdatei nicht überarbeitet, dann hätten da Sätze gefehlt. Hätte das was ausgemacht oder ist auch für die eine Englische Fallbackdatei sowieso immer implementiert? Dies ist so nur für "commaconversion", "units" und "mutated_vowels" angegeben.

Englisch-Default ist direkt im Modul enthalten. Prinzipiell kann man nur Sätze modifizieren, die das Modul aus dieser "Grundstruktur" "kennt". Als Erweiterungen zugelassen sind nur einige weitere Elemente, darunter eben diese "Farbe-zu-Nummer"-Geschichte, die dann direkt dazu genutzt werden kann, Rhasspy-Slots zu generieren.

Die in contrib enthaltene de-Fassung sollte ein paar Erläuterungen dazu enthalten.

Der prinzipielle Mechanismus für die eigentlichen Sätze ist der: Was zugelassen ist, steht in englisch im Modul. Da sind auch die zugelassenen Variablen zu finden. Dann wird "drübergeklatscht", was in der Sprachdatei in "default" zu finden ist, und zuletzt der "user"-Bereich nochmal drübergegelegt. Ergo bleiben die englischen Werte sichtbar, wenn man irgendwo eine Lücke hat und kann dann das gezielt nacharbeiten. Super wäre es, für "es" auch eine vollständige "neutrale" Fassung in "default" zu haben und eine (teilweise) "individualisierte" Ergänzung in "user".

2) "User" ist klar; heißt das aber auch, dass bei einem FHEM-Update-Befehl (hinterlegte controls für 10_RHASSPY vorausgesetzt) die rhasspy-de.cfg auch nicht aktualisiert wird und man das händisch machen muss?

Da im Moment alles in contrib liegt, wird so oder so nichts per update aktualisiert. Für die Sprachdatei fände ich einen automatischen update auch extrem schwierig, weil da in der Regel eben auch User-Daten drin stehen. Stellt man fest, dass irgendwo was fehlt (weil die engl. Sätze drin bleiben), kann man (für "de") den "default"-Teil einfach aus dem svn rauskopieren.
(Das ist der tiefere Sinn hinter der Aufteilung an sich).

3) slots: Hier werden derzeit Farbbezeichnungen in HEX-Werte "übersetzt". D.h. ich müsste für ein komplettes File auch die Bezeichnungen ins spanische übersetzen (von einer Farbtabelle abschreiben)?
Ist das auch der Ort, wo ich eigenen Slots einbringen kann oder gibt es dafür eine andere Funktion?

Ja, das ist einer der Orte dafür (shortcuts gibt es z.B. auch noch, und uU. bei "specials"/scene (?), und einen setter), und ja, wenn du spanische Farben sagen können willst, wäre das m.E. der richtige Ort dafür.

ich würde dann einfach ein weiteres RHASSPY-DEVICE mit

Code Auswählen Erweitern

language=es fhemId=fhemEs prefix=rhasspyEs anlegen,

Code Auswählen Erweitern

attr <rhasspy> configFile ./FHEM/rhasspy-es.cfg setzen und ab die Post.

So wäre die Theorie .

Bin mal gespannt, ob das alles so klappt oder wir nicht irgendwo das eine oder andere weitere Problem finden. Prinzipiell fände ich es übrigens nicht schlecht, für "RHASSPY spricht spanisch" einen separaten Thread zu haben.

[drhirn]

Aber lt. Rhasspydoku braucht man bei Master-Satellite-Aufbau keinen Dialoguemanager beim Master:
https://rhasspy.readthedocs.io/en/latest/tutorials/#server-with-satellites
(siehe Bild in der Anlage).

Witzig. Ich hab's aus irgendeinem Grund genau umgekehrt konfiguriert. DialogueManager an der Base aktiv, am Satellit nicht. Was erklärt, warum Dialoge bei mir nicht funktioniert haben

Unabhängig davon - laberlaib hat's inzwischen selbst beantwortet - seh ich darin auch kein Grund für das Verhalten.

[Beta-User]

Hallo zusammen,

mal wieder ein paar "Kleinigkeiten"...:

Alles, was an diese RHASSPY-Instanz gehen soll, braucht "de.fhem:" vorneweg. In der sentences.ini muss der Intent also so benannt werden:

Code Auswählen Erweitern

[de.fhem:GetTime]


=> Doku/commandref zu den intents ergänzt

In den "keywords" [...] manches von vornherein keinen Sinn macht (room: googleassistant),

=> neuer "tweak" "ignoreKeywords"
(Status: scheint zu funktionieren)

EDIT: der Code aus https://forum.fhem.de/index.php/topic,119447.msg1188968.html#msg1188968 betr. die siteId-Ermittlung ist auch übernommen. Scheint soweit zu klappen...

RHASSPY vielleicht um eine Funktion für text2intent zu erweitern? Mal sehen...

Erste Ansätze dazu sind drin. Weiß im Moment weder, ob das überhaupt in der Praxis funktioniert (lt. Doku sollte es), noch, ob es sinnvoll ist, die siteId mitgeben zu können (das erste Wort wird als siteId interpretiert, der Rest gibt den Text).

Na ja, jedenfalls könnte man jetzt z.B. was via Telegram oä. an FHEM senden, einen Eventhandler hernehmen, der die Message auswertet und an RHASSPY weitergibt und dann hoffen, dass das Ergebnis paßt... (Status an der Stelle ausdrücklich experimentell, für den Normalbetrieb aber hoffentlich erst mal irrelevant)

Außerdem gibt es noch ein paar mehr gDT's, die grundsätzlich berücksichtigt werden könnten, aber ob das im Detail dann klappt, wird sich auch zeigen => ebenfalls eher experimentell, aber vermutlich auch für den Normalbetrieb unkritisch...

Generell scheint mir, dass bei der gDT-Auswertung noch etwas Nacharbeitsbedarf bestehen könnte in Richtung auf onCmd=ON usw.. Ziehe ich ggf. nach, wenn Gisbert seine getAllSets() gezeigt hat.

Wie üblich: Viel Spaß beim Testen, bin mal auf eure Rückmeldungen zu den bisherigen Neuerungen in 0.5 gespannt . Bisher war es verdächtig ruhig (=> braucht keiner, hat keiner getestet, ...?)

CU

[laberlaib]

Bin mal gespannt, ob das alles so klappt oder wir nicht irgendwo das eine oder andere weitere Problem finden. Prinzipiell fände ich es übrigens nicht schlecht, für "RHASSPY spricht spanisch" einen separaten Thread zu haben.

Ich bin dran - die handyapp enciendet die lampara schon und danach wird die Stehlampe wieder ausgeschalten.
Probleme hatte ich mit dem Attribut clientOrder vom MQTT-Device: Da wurde mir mal gesagt, dass das nur ein MQTT Device braucht und das dasnn für alle gilt. Aber ohne das hatte ich im mqtt2_rhasspy_es unter Interals/Clients nur Clients ":MQTT_GENERIC_BRIDGE:MQTT2_DEVICE:" stehen.
Aber sonst siehts gut aus, und dank Proxmox-VM-Master ist das ja auch echt schnell aufgesetzt.

[Beta-User]

...und noch ein (funktional gesehen) Mini-update.

Interessanter dürften die Erweiterungen in der commandref sein, zusammen mit

Unter https://wiki.fhem.de/wiki/Rhasspy habe ich jetzt mal einen "Quick-Start" ins Wiki gestellt.

sollte es jetzt einfacher sein, RHASSPY einzurichten, ohne erst gefühlte 1000 Seiten Entwicklungsthread zu lesen....

(bzgl. der Github-Seite hatte Gisbert einen Typo gemeldet, und zwischenzeitlich bin ich nicht sicher, wie man bzgl. des Doku-Themas sinnvollerweise weiter macht...)

[drhirn]

(bzgl. der Github-Seite hatte Gisbert einen Typo gemeldet, und zwischenzeitlich bin ich nicht sicher, wie man bzgl. des Doku-Themas sinnvollerweise weiter macht...)

Tja. Wir sind jetzt auf jeden Fall da, wo ich eigentlich nicht hinwollte: Ich muss drei Dokumentationen im Auge behalten.

Das mit dem Typo auf GitHub hab ich übersehen. Was war das?