Modulentwicklung für Rhasspy Sprachassistent

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

Vorheriges Thema - Nächstes Thema

drhirn

Zitat von: Beta-User am 04 Juni 2021, 08:35:36
Was "excerpt" angeht: das war wirklich im Sinne von "auszugsweise" gemeint, es gibt ja noch ein paar mehr als die auf der Liste, oder?
Ja, ich hab da deswegen eine dritte Version des Textes ins Spiel gebracht. Die ist allerdings auch nicht ganz richtig sehe ich gerade.

Zitatund dann wäre da noch die Frage der Vervollständigung der Doku im Hinblick auf "optimales Vorgehen" bzw. Abrundung der automatisiert (via de-cfg) erstellten slots. Da wäre z.B. noch der OnOff-Slot bzw. hoch/runter-Verfeinerungen usw.. Habe da auch noch keine abschließende Meinung zu, _glaube aber_, dass wir gut daran täten,  von vornherein "filigranere" Slots (Device-xy und OnOff-xy) zumindest vorzustellen und (via Modul und de-cfg) vorzubereiten.

Was meinst du mit "optimales Vorgehen"?
Aber ja, wir können gerne die automatisch erstellten Slots in der Doku genauer erklären.

ZitatDa ich im Moment nicht glaube, dass noch besonders viele Anwendungshinweise dazu kommen, wäre ich  eher für eine "cref only"-Variante.
Wie wird denn das in der FHEM-Community gesehen? Ich persönlich verwende extrem oft die ganze CRef im Web. Da ist es wahnsinnig lästig, wenn da zwischendurch eine riesiger Abschnitt für ein Device kommt.
Und die CRefs werden in FHEM jedes Mal mitgeladen. Ob man sie gerade braucht, oder nicht. Da geht eine ausführliche CRef natürlich auf die Performance.


ZitatWas die Roadmap für 0.5/0.6 angeht, hätte ich folgende Punkte auf der Liste:
- automatisches Umschalten von Einzel- auf Gruppenkommando (wenn eine Gruppe in dem JSON ist, aber kein Device);
- (mehr) Bestätigungsoptionen
Ich hab eigentlich nur "wie lange noch" beim Timer auf meiner Liste

Beta-User

Zitat von: drhirn am 04 Juni 2021, 10:02:07
Was meinst du mit "optimales Vorgehen"?
Na ja, an der Stelle war eigentlich "nur" gemeint: bilde Sätze, die z.B. nur für Rollläden passen und verwende dann einen On/Off-slot, der auch nur öffne/schließe bzw. auf/zu in on bzw. off umwandelt. Sowas ist m.E. jedenfalls zweckmäßig, bevor man anfängt, (dann ggf. überflüssige?) Bestätigungsdialoge einzurichten.
(Will aber nicht behaupten, dass das bei mir schon "fertig" wäre).

Etwas generischer aber vorneweg: setze gDT, damit überhaupt die "engeren" slots verfügbar sind bzw. mit sinnvollem Content an Rhasspy übermittelt werden.

ZitatIch hab eigentlich nur "wie lange noch" beim Timer auf meiner Liste
Können wir ja auch gerne für die nächste Version mit aufnehmen. Da die Timer als at angelegt werden, sollte sowas eigentlich recht einfach zu machen sein (internal NTM abfragen, "etwas rechnen" und eine Ausgabe machen analog zum Timer setzen...). Und in den Readings steht es ja eigentlich auch...
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

#707
Nach einer ConfirmAction ordnet die Rhasspy-Basis keine Intents mehr zu, obwohl die Worte eindeutig erkannt wurden.
Ein "ja bitte" wird weiterhin erkannt - natürlich mit der Meldung, dass gerade nicht danach gefragt wurde.
Kann sein, dass meine exotische Installation daran schuld ist.

In 10_RHASSPY.pm fand ich folgende Zeile, welche ich auskommentiert habe:IOWrite($hash, 'publish', qq{hermes/dialogueManager/configure $json});
Hintergrund ist, dass offensichtlich der IntentFilter nach der ConfirmAction nicht zurückgesetzt wird.

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.

Beta-User

#708
Zitat von: JensS am 06 Juni 2021, 14:12:07
Nach einer ConfirmAction ordnet die Rhasspy-Basis keine Intents mehr zu, obwohl die Worte eindeutig erkannt wurden.
Interessante Feststellung - bisher war ich davon ausgegangen, dass Rhasspy nicht in der Lage wäre, die Intent-Filter überhaupt im laufenden Betrieb zu ändern... Das scheint eine Fehlannahme zu sein bzw. zwischenzeitlich überholt (entsprach aber meinen damaligen Tests, die aber (nach heutigem Kenntnisstand) auch aus anderen Gründen schiefgehen mussten).

ZitatIn 10_RHASSPY.pm fand ich folgende Zeile, welche ich auskommentiert habe:IOWrite($hash, 'publish', qq{hermes/dialogueManager/configure $json});
Hintergrund ist, dass offensichtlich der IntentFilter nach der ConfirmAction nicht zurückgesetzt wird.
Dieser Fix deaktiviert im Endeffekt die ganze Filterung. Bin den Code jetzt nochmal durchgegangen und habe ein paar Stellen umgestellt, die diesen Codeteil nutzen, da waren definitiv noch Unsauberkeiten drin. Die Umstellungen sind bisher aber (funktional) noch nicht getestet. Damit könnte es jetzt wieder - einschließlich der Filterung - wieder so klappen, wie es ursprünglich gedacht war.

Zitat von: JensS am 06 Juni 2021, 14:12:07
Kann sein, dass meine exotische Installation daran schuld ist.
Glaube ich zwar nicht, dass deine Installation die eigentliche Ursache ist, aber falls doch, wäre es klasse, wenn du testen könntest, ob es mit der angehängten Fassung dann klappt wie es soll. Dann wären wir nämlich an der Stelle wieder einen großen Schritt weiter :) .
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

Funktioniert leider nicht. Wieso machst du überhaupt ein configure?
In continueSession hast du doch schon alles abgefrühstückt, was muss.
https://docs.snips.ai/reference/dialogue#payload-4

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.

Beta-User

...gute Frage. Muss ich mir nochmal im Gesamtzusammenhang ansehen, ist schon wieder eine Weile her...

Was Doku angeht, bin ich mir nicht so sicher, ob das noch 100% aktuell ist, was bei snips zu finden ist; https://rhasspy.readthedocs.io/en/latest/reference/#dialogue-manager sollte den aktuellen Stand wiedergeben. Mein gedanklicher Ansatz war - soweit ich das aus dem Kopf zusammenbringe - grundsätzlich die Bestätigungs- und Auswahl-Intents zu deaktivieren, und nur zu aktivieren, wenn sie gebraucht werden. Das Deaktivieren müßte nach meinem Verständnis über "configure" laufen, ob der intentFilter das dann für die Session überspielen kann, wäre die spannende Frage.
So richtig viele funktionsfähige Dialog-Beispiele habe ich aber auch nicht gefunden, kann schon sein, dass das doch anders läuft. Ganz außen vor kann man den DialogManager (und das configure) aber mAn. nicht lassen - aber man muss ihn aber ggf. anders bzw. seltener überhaupt aufrufen, wenn das vorübergehende Aktivieren über "continue" gemacht werden kann.

(Needs testing, wird dauern...)
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

Ok, den Filter kannst du vielleicht mit "intentFilter":nullzurücksetzen.
Interessant wäre, wenn man den ConfirmAction-Filter negieren könnte.
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.

JensS

#712
@Beta-User
Bin die ganze Sache mit dem intentFilter nochmal durchgegangen und habe ein paar Ansätze.

Dein intentFilter funktioniert und braucht (entgegen meiner ersten Annahme) nicht zurückgesetzt werden, da er nur für die Session gilt.

"configure ... intents ... intentId ... enable" ist die Ursache für die Dienstquittierung von Rhasspy nach ConfirmAction, da das (vermutlich) global wirkt.

Wenn eine ausreichend lange Sequenz (ja bitte|nein danke) erkannt werden muss, wäre ein configure nicht unbedingt erforderlich.

Das Hermes-Protokoll ist mittlerweile ein Standard, den nicht nur Rhasspy/Snips nutzt. Unter "hermes intentFilter" findet man eventuell was im Web.

Gruß Jens

p.s. Wenn https://docs.snips.ai/reference/hermes#sending-text-to-the-nlu-component-for-slot-detection nur für die Session gilt, könnten die ConfirmActions in der Sprachdatei einem eigenen Slot hinterlegt und der Slotname der Session übergeben werden. Nur eine Vermutung - haltbare Infos sind nicht leicht zu finden...

p.p.s. So ein freier Tag setzt viele Ideen frei.  :)
Das p.s. sollte auch im contuineSession als zusätzliche Option zu intentFilter funktionieren. Dazu wird ein Slot de.fhem.confirmAction angelegt und mit (ja bitte){Mode:OK} befüllt.
In sentences.ini wird nur der Intent [de.fhem:confirmAction] ohne Inhalt definiert.
Das hat (vermutlich) zur Folge, dass die Worte trainiert aber nicht zur ASR genutzt werden.
Bei continueSession wird dann der intentFilter de.fhem:confirmAction mit der Option "slot":"de.fhem.confirmAction" aufgerufen. Ob das geht?


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.

Beta-User

#713
Anbei mal eine Fassung, die den dialogManager nur noch @startup aufruft.

Zitat von: JensS am 08 Juni 2021, 09:13:38
@Beta-User
Bin die ganze Sache mit dem intentFilter nochmal durchgegangen und habe ein paar Ansätze.

Dein intentFilter funktioniert und braucht (entgegen meiner ersten Annahme) nicht zurückgesetzt werden, da er nur für die Session gilt.
Danke für den Schubs, ich hatte das mit dem intentFilter nicht mehr im Fokus und den Code (und die auffindbare Doku) nochmal unter diesem Blickwinkel durchgesehen. Bisher war das so gelöst gewesen, dass sowohl der intentFilter gesetzt (nur für die Dauer der Session gültig) wie auch der global wirkende dialogManager aufgerufen wurde. Der setzt aber "nur" die jeweils ausgewählten Intents auf aktiv oder deaktiv, von daher wäre es auch programmtechnisch logisch, dass man das innerhalb einer Session auch ändern kann, ohne gleich alles umzukonfigurieren...
Falls es ohne die "globale Erlaubnis" auch geht, müsste das mit der angehängten Fassung funktionieren, getestet habe ich es noch nicht.

Zitat
Wenn eine ausreichend lange Sequenz (ja bitte|nein danke) erkannt werden muss, wäre ein configure nicht unbedingt erforderlich.
Wichtig wäre, dass die Erstinitialisierung klappt, dann scheint auch das mit den ggf. sehr kurzen Sequenzen kein Problem mehr zu sein, weil die dann nur zum Tragen kommen, wenn sie (für die Session) aktiviert werden.

Zitat
Das Hermes-Protokoll ist mittlerweile ein Standard, den nicht nur Rhasspy/Snips nutzt. Unter "hermes intentFilter" findet man eventuell was im Web.

Gruß Jens

p.s. Wenn https://docs.snips.ai/reference/hermes#sending-text-to-the-nlu-component-for-slot-detection nur für die Session gilt, könnten die ConfirmActions in der Sprachdatei einem eigenen Slot hinterlegt und der Slotname der Session übergeben werden. Nur eine Vermutung - haltbare Infos sind nicht leicht zu finden...
Na ja, im Detail scheint es Unterschiede zwischen snips und Rhasspy zu geben. Beim Überfliegen der diversen Fundstellen ist mir z.B. aufgefallen,  dass die intentFilter als JSON-Array zu übergeben sind (selbst, wenn es nur ein Wert ist (?), siehe https://community.rhasspy.org/t/one-wake-word-phrase-followed-by-multiple-commands/438) und Rhasspy nlu scheinbar kein "partialQuery" zu kennen scheint, siehe https://rhasspy.readthedocs.io/en/latest/reference/#natural-language-understanding. Müßte man ggf. nachfragen, ist aber mAn. ein anderes Thema, das ggf. zu den "Choice"-Geschichten passen würde.

Na ja, eines nach dem anderen, mir kommt es so vor, als würde sich der Nebel so langsam vollends lichten und wir kämen insgesamt auch an dem Thema voran :) .
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

Zitathttps://rhasspy.readthedocs.io/en/latest/reference/#natural-language-understanding
Danke für den Hinweis. Die Originalquellen zu Rhasspy hatte ich schon aus dem Blick verloren...
Leider taucht da die Option slot in continueSession nicht auf.  :(
Deine neue Version teste ich gleich.
ZitatAnbei mal eine Fassung, die den dialogManager nur noch @startup aufruft.
Sorry, ob meiner Bequemlichkeit - wo, in den tausenden Zeilen ist was geändert?
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.

Beta-User

Zitat von: JensS am 08 Juni 2021, 10:55:47
Danke für den Hinweis. Die Originalquellen zu Rhasspy hatte ich schon aus dem Blick verloren...
Leider taucht da die Option slot in continueSession nicht auf.  :(
Deine neue Version teste ich gleich.Sorry, ob meiner Bequemlichkeit - wo, in den tausenden Zeilen ist was geändert?
Eigentlich sind nur die dialogManager-Aufrufe deaktiviert (und das Erweitern der gespeicherten Daten), diese Änderungen hatte ich aus Bequemlichkeit mit dem "#dialog"-Hinweis kenntlich gemacht, damit ich die selbst auch wiederfinde ::) . (Und die Nummer hochgedreht).
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

Ah, danke - die Beta-User'sche Syntax macht Sinn...
Um das confirmAction-Thema in meiner Installation als gelöst zu betrachten, habe ich noch ein paar Fragen/Anmerkungen.
Wie sehen die Intents in der sentences.ini richtig aus? Aktuell bei mir:[de.fhem:ConfirmAction]
(ja bitte){Mode:OK}

[de.fhem:CancelAction]
(nein danke){Mode}

CancelAction endet bei mir mit einem Timeout, egal ob "nein danke" oder nichts erkannt wird.
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.

Beta-User

#717
Zitat von: JensS am 08 Juni 2021, 11:15:56
Ah, danke - die Beta-User'sche Syntax macht Sinn...
Sowas hört man doch gerne 8) ...

Zitat
CancelAction endet bei mir mit einem Timeout, egal ob "nein danke" oder nichts erkannt wird.
Ups, da war noch die "alte" Logik mit customData drin. Habe den betreffenden intent-handler (ab #3882) entsprechend "Confirm" angepaßt, jetzt müsste es ohne Timeout durchlaufen.

Zitat
Wie sehen die Intents in der sentences.ini richtig aus?
Das paßt so.
Weiterführende Anmerkungen:
- ConfirmAction ruft CancelAction auf, wenn nicht "{Mode:OK}" in den JSON übergeben wird; die "alte" Einheitssyntax funktioniert weiter
- CancelAction braucht an sich gar keinen "Mode", es kennt nur "weg damit..." Schaden tut es aber auch nicht...

Jetzt wäre interessant, ob die Auswahl-Geschichten auch weiter klappen, aber eigentlich sehe ich keine Gründe, warum nicht.

Was mir noch nicht ganz klar ist: Wie ist das mit dem Deaktivieren der slots bei einem Neustart von Rhasspy? FHEM macht das ja nur einmalig. Meine Erwartungshaltung wäre: Rhasspy merkt sich das "configure" (und bisher habe ich noch keine gegenteiligen Hinweise gefunden).
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

#718
Danke - passt!
"ja bitte" und "nein danke" sowie Stille werden richtig verarbeitet und geben entsprechene Antworten.
Ein intentNotRecognized (wie spät ist es) wird erwartungsgemäß von der Basis mit sessionEnded quittiert.
Für 10_Rhasspy.pm scheint die Session allerdings noch nicht vorbei zu sein, da einhermes/dialogueManager/endSession {"sessionId":"wohnzimmer-alexa-0b6762e9-eb47-4eef-b439-54ec1a54e529","siteId":"wohnzimmer","text":"Tut mir leid, da hat etwas zu lange gedauert"}
nachgeschoben wird. Die Ausgabe hört man natürlich nicht mehr, da die Basis die Session zuvor als beendet erklärt hat.

Insgesamt ist eine funktionierende und nützliche Erweiterung!

Zur Haltbarbeit von configure muss ich dich leider enttäuschen. Die ist abgelaufen, wenn die Basis neu gestartet wird.

p.s. Für einige SetOnOff-Devices würde ich gern die ConfirmAction nutzen. Rasensprenger, Teichbefüller, Weidezaungerät uem habe ich aus Sichereitsgründen noch nicht in Rhasspy intergriert. Für jedes Device zwei rhasspyShortcuts anzulegen, bläht die Config auf.
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.

Beta-User

Zitat von: JensS am 08 Juni 2021, 12:03:21
Danke - passt!
"ja bitte" und "nein danke" sowie Stille werden richtig verarbeitet und geben entsprechene Antworten.
OK, also sind wir an der Stelle wirklich deutlich weitergekommen, danke für den support!

Zitat
Ein intentNotRecognized (wie spät ist es) wird erwartungsgemäß von der Basis mit sessionEnded quittiert.
Für 10_Rhasspy.pm scheint die Session allerdings noch nicht vorbei zu sein, da einhermes/dialogueManager/endSession {"sessionId":"wohnzimmer-alexa-0b6762e9-eb47-4eef-b439-54ec1a54e529","siteId":"wohnzimmer","text":"Tut mir leid, da hat etwas zu lange gedauert"}
nachgeschoben wird. Die Ausgabe hört man natürlich nicht mehr, da die Basis die Session zuvor als beendet erklärt hat.
Das muss ich mir nochmal im Detail ansehen. Es ist nachvollziehbar, warum das passiert - der Timer läuft ja noch. Zum Unterbinden müßte man jetzt aber entweder "externe endSession"-Topics abonnieren und auf die sessionId auswerten, um den "richtigen" Timer zu killen, oder "irgendwie" die intentNotRecognized-Message rausfiltern. Falls du grade Topic/Payload zum ganzen Ablauf hast: das wäre hilfreich...

ZitatZur Haltbarbeit von configure muss ich dich leider enttäuschen. Die ist abgelaufen, wenn die Basis neu gestartet wird.
Nicht schön... Bedeutet, wir müssten irgendwie mitbekommen, wann Rhasspy neu gestartet wird. (Klar ist: nach jedem Training; das könnte man abgreifen. Aber sonst...?!?) Oder eben "auf Verdacht" doch immer mal wieder die defaults wiederherstellen (was ich aber lieber vermeiden würde).
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