[RHASSPY 0.5] - offene Themen

[Beta-User]

Hallo zusammen,

damit das im "Großthread" nicht untergeht, hier mal die aktualisierte Liste der "offenen Punkte", Fragen, zu klärenden Dinge bei der Weiterentwicklung von RHASSPY.

Bei manchem ist mir selbst nicht (mehr) klar, ob das noch relevant ist, anderes scheint mir geklärt - es wäre sinnvoll, wenn hier dann nur die Meldung "ist erledigt" erfolgt, damit man besser tracken kann, was der Stand ist. Vertiefte Diskussionen sollten m.E. dann weiter im Hauptthread erfolgen.

Hier jetzt also erst mal die aktualisierte Liste:

# Farben:
  Warum die Abfrage nach rgb? <code>if ( defined $data->{Colortemp} && defined $mapping->{rgb} && looks_like_number($data->{Colortemp}) ) {</code>
  Gibt auch Lampen, die können nur ct (Beta-User: unklare Frage: der fragliche Zweig wird nur bei "falschem ct" angesteuert, ansonsten wird schon vorher "nativ" ct verwendet)

# Custom Intents
- Bei Verwendung des Dialouges wenn man keine Antwort spricht, bricht Rhasspy ab. Die voice response "Tut mir leid, da hat etwas zu lange gedauert" wird
   also gar nicht ausgegeben und: (Beta-User: klingt nach "silent cancelation", grade keine Idee).

   PERL WARNING: Use of uninitialized value $cmd in pattern match (m//) at fhem.pl line 5868. (Beta-User: nicht mehr zuordenbar)

# Sonstiges, siehe insbes. https://forum.fhem.de/index.php/topic,119447.msg1148832.html#msg1148832
- kein "match in room" bei GetNumeric
- "kind" und wie man es füllen könnte (mehr Dialoge)
- Bestätigungsdialoge - weitere Anwendungsfelder (erledigt, oder?)
- gDT: mehr und bessere mappings? (auch weitgehend erledigt, v.a. mit "info" (s.u.)
- Farbe und Farbtemperatur (fast fertig? oder fertig?)
- Hat man in einem Raum einen Satelliten aber kein Device mit der siteId/Raum, kann man den Satelliten bei z.B. dem Timer nicht ansprechen, weil der Raum nicht in den Slots ist.
  Irgendwie müssen wir die neue siteId in den Slot Rooms bringen (erl. mit extrarooms?)

# Parameter-Check für define? Anregung DrBasch aus https://forum.fhem.de/index.php/topic,119447.msg1157700.html#msg1157700 (erl.)

# Doku zu den "üblichen Formaten" (z.B. JSON-Keywords beginnen mit Großbuchstaben)? (erl. (?))

#defaultRoom (JensS):
- überhaupt erforderlich? (Beta-User: finde ich zwischenzeitlich hilfreich)
- Schreibweise: RHASSPY ist raus, Rhasspy scheint der überkommene Raumname für die devspec zu sein => ist erst mal weiter beides drin

# GetTimer implementieren?
https://forum.fhem.de/index.php/topic,113180.msg1130139.html#msg1130139
(Beta-User: möglich, aber geringe Prio. Vielleicht mag jemand einen (sauberen!)  CustomIntent als Beispiel liefern

# Wetterdurchsage
Ist möglich. Dazu hatte ich einen rudimentären Intent in diesem Thread erstellt. Müsste halt nur erweitert werden.
https://forum.fhem.de/index.php/topic,113180.msg1130754.html#msg1130754 (evtl. ersetzt durch STATE-Abfrage/gDT info?)

Grüße,

Beta-User

EDIT: Aktuelle Developer-Version angehängt (falls nicht via svn aktueller).

[JensS]

#Custom Intents
- Version: 10_RHASSPY.pm 25369 2021-12-29 Beta-User
- Mikro nach Sprachanweisung "Stehlampe an" gemutet

Code Auswählen Erweitern

hermes/tts/say {"text": "bestätige stehlampe an", "siteId": "wohnzimmer", "lang": null, "id": "d615d8e4-7076-4aed-bb2f-a119d2d3eb2b", "sessionId": "wohnzimmer-alexa-8662b492-5f36-481f-85c5-6d50d838e1ec", "volume": null}
hermes/audioServer/wohnzimmer/playFinished {"id": "d615d8e4-7076-4aed-bb2f-a119d2d3eb2b", "sessionId": "d615d8e4-7076-4aed-bb2f-a119d2d3eb2b"}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "d615d8e4-7076-4aed-bb2f-a119d2d3eb2b", "sessionId": "wohnzimmer-alexa-8662b492-5f36-481f-85c5-6d50d838e1ec"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/startListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-8662b492-5f36-481f-85c5-6d50d838e1ec", "lang": null, "stopOnSilence": true, "sendAudioCaptured": true, "wakewordId": null, "intentFilter": null}
hermes/asr/textCaptured {"text": "", "likelihood": 0, "seconds": 0, "siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-8662b492-5f36-481f-85c5-6d50d838e1ec", "wakewordId": null, "asrTokens": null, "lang": null}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-8662b492-5f36-481f-85c5-6d50d838e1ec"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/intentNotRecognized {"input": "", "siteId": "wohnzimmer", "id": null, "customData": null, "sessionId": "wohnzimmer-alexa-8662b492-5f36-481f-85c5-6d50d838e1ec"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-8662b492-5f36-481f-85c5-6d50d838e1ec", "siteId": "wohnzimmer", "input": "", "customData": "alexa"}
hermes/dialogueManager/endSession {"customData": "alexa","intentFilter": null,"sessionId": "wohnzimmer-alexa-8662b492-5f36-481f-85c5-6d50d838e1ec","siteId": "wohnzimmer","text": "Tut mir leid, da hat etwas zu lange gedauert"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "Tut mir leid, da hat etwas zu lange gedauert", "siteId": "wohnzimmer", "lang": null, "id": "3d980faf-5091-47ec-bfe0-667b532049de", "sessionId": "wohnzimmer-alexa-8662b492-5f36-481f-85c5-6d50d838e1ec", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "3d980faf-5091-47ec-bfe0-667b532049de", "sessionId": "wohnzimmer-alexa-8662b492-5f36-481f-85c5-6d50d838e1ec"}
hermes/audioServer/wohnzimmer/playFinished {"id": "3d980faf-5091-47ec-bfe0-667b532049de", "sessionId": "3d980faf-5091-47ec-bfe0-667b532049de"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-8662b492-5f36-481f-85c5-6d50d838e1ec"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-8662b492-5f36-481f-85c5-6d50d838e1ec", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
Scheint zu laufen. Das gleiche Ergebnis gibt es bei "Audio Playing" => "Disabled"

Gruß Jens

[Prof. Dr. Peter Henning]

Immer noch offen: Erwartete Bestätigungsnachricht, wenn TTS auf "Hermes MQTT" gestellt ist. Ich suche mir nach wie vor einen Wolf...

LG

pah

[Beta-User]

Weitere Punkte, damit die irgendwo gesammelt sind:
- "encode": (https://forum.fhem.de/index.php/topic,126088.0.html) Ersetzen von decode_json durch "nicht-transformative" Varianten (Test läuft bereits);
- Umstellung auf "setNotifyDev()";
- Rückmeldung zu den AMAD.*-Schnittstellen sind bisher weiter Mangelware
- "auto-training": Ändert man relevante Attribute, soll Rhasspy relativ direkt die aktualisierten Infos automatisch erhalten (Idee von martinp876). code dazu ist am werden.

Bei Gelegenheit wird dann im "Entwicklungs-Thread" mal wieder ein update kommen, das zumindest die ersten beiden Punkte erschlagen sollte.

[Beta-User]

Hier jetzt mal die vorläufige "Gesamtliste" (nach meiner Bewertung). Was durchgestrichen ist, fliegt raus, wenn es keinen halbwegs zeitnahen Widerspruch gibt:

# Farben:
  Warum die Abfrage nach rgb? <code>if ( defined $data->{Colortemp} && defined $mapping->{rgb} && looks_like_number($data->{Colortemp}) ) {</code>
  Gibt auch Lampen, die können nur ct (Beta-User: unklare Frage: der fragliche Zweig wird nur bei "falschem ct" angesteuert, ansonsten wird schon vorher "nativ" ct verwendet)

# Custom Intents
(ist schon raus, siehe Rückmeldung von JensS)

   PERL WARNING: Use of uninitialized value $cmd in pattern match (m//) at fhem.pl line 5868. (Beta-User: nicht mehr zuordenbar)

# Sonstiges, siehe insbes. https://forum.fhem.de/index.php/topic,119447.msg1148832.html#msg1148832
- kein "match in room" bei GetNumeric (müßte eigentlich über die "priority outside room" gelöst sein
- "kind" und wie man es füllen könnte (mehr Dialoge)  (scheint derzeit keinen weiteren Bedarf zu geben?)
- Bestätigungsdialoge - weitere Anwendungsfelder (erledigt, oder?) "im Prinzip erledigt" - was noch nicht optimal läuft, sind die "kontinuierliche Eingaben" (DEF => sessionTimeout) und Dialoge bei AMAD-Input (Sprachausgabe=>Mikro wieder einschalten)
- gDT: mehr und bessere mappings? (auch weitgehend erledigt, v.a. mit "info" (s.u.) (scheint derzeit keinen weiteren Bedarf zu geben?)
- Farbe und Farbtemperatur (fast fertig? oder fertig?)
- Hat man in einem Raum einen Satelliten aber kein Device mit der siteId/Raum, kann man den Satelliten bei z.B. dem Timer nicht ansprechen, weil der Raum nicht in den Slots ist.
  Irgendwie müssen wir die neue siteId in den Slot Rooms bringen (erl. mit extrarooms?)

# Parameter-Check für define? Anregung DrBasch aus https://forum.fhem.de/index.php/topic,119447.msg1157700.html#msg1157700 (erl.)

# Doku zu den "üblichen Formaten" (z.B. JSON-Keywords beginnen mit Großbuchstaben)? (erl. (?))

#defaultRoom (JensS):
- überhaupt erforderlich? (Beta-User: finde ich zwischenzeitlich hilfreich)
- Schreibweise: RHASSPY ist raus, Rhasspy scheint der überkommene Raumname für die devspec zu sein => ist erst mal weiter beides drin

# GetTimer implementieren?
https://forum.fhem.de/index.php/topic,113180.msg1130139.html#msg1130139
(Beta-User: möglich, aber geringe Prio. Vielleicht mag jemand einen (sauberen!)  CustomIntent als Beispiel liefern

# Wetterdurchsage
Ist möglich. Dazu hatte ich einen rudimentären Intent in diesem Thread erstellt. Müsste halt nur erweitert werden.
https://forum.fhem.de/index.php/topic,113180.msg1130754.html#msg1130754 (evtl. ersetzt durch STATE-Abfrage/gDT info?) (das müßte ggf. noch etwas besser getestet werden, läuft aber prinzipiell)

Erwartete Bestätigungsnachricht, wenn TTS auf "Hermes MQTT" gestellt ist. Ich suche mir nach wie vor einen Wolf...

(m.E. kein RHASSPY (Modul-) Thema)

- "encode": (https://forum.fhem.de/index.php/topic,126088.0.html) Ersetzen von decode_json durch "nicht-transformative" Varianten (Test läuft bereits); (Implementiert in den letzten Versionen, bisher keine Klagen)
- Umstellung auf "setNotifyDev()"; (Implementiert in den letzten Versionen, bisher keine Klagen)
- Rückmeldung zu den AMAD.*-Schnittstellen
eigene rudimentäre Tests: das läuft soweit, bei Gelegenheit muss ich mir mal ansehen, ob/welche Events es gibt, an denen man ggf. erkennen könnte, dass eine "dialogische" Sprachausgabe "fertig" ist. Sonst müßte ggf. dann die Zeit geschätzt werden, die es braucht (wie?). Attributname wäre zu überdenken.

- "auto-training": Ändert man relevante Attribute, soll Rhasspy relativ direkt die aktualisierten Infos automatisch erhalten (Idee von martinp876). code dazu ist am werden. in der aktuellen Version implementiert, aber weiter noch nicht getestet (DEF: autoTraining-key).


In Summe sieht die mutmaßlich verbleibende Liste dann doch recht überschaubar aus .

[Prof. Dr. Peter Henning]

Na, dann füge der Liste doch mal etwas hinzu: Wir wollen ja verschiedene Sprachassistenten miteinander vergleichen.

Wir brauchen also einen Benchmark, der in der eingeschränkten Domain der Hausautomatisierung relevante Ergebnisse liefert. In unseren Forschungsarbeiten nutzen wir GLUE (https://github.com/nyu-mll/GLUE-baselines), das ist aber viel zu allgemein.

Ich hänge mal eine Datei an, die ca. 170 Sätze enthält, die bei mir reibungslos erkannt werden. Teilweise handelt es sich dabei um komplette Dialoge, bei denen eine Rückfrage gestellt wird und die nächste Antwort in den Dialog einfließt.

Dafür muss ich mir noch ein Annotationsformat ausdenken.

Was hat das nun mit RHASSPY zu tun? Im Modul sollte ein set ... test <dateiname> implementiert werden. Die entsprechende Routine holt sich einen Satz nach dem anderen aus der angegebenen Datei und protokolliert den Rücklauf aus der Spracherkennung.

Meine Wunschliste also:
1. Dass in 10_RHASSPY.pm eine solche Testfunktion integriert wird
2. Dass Ihr mir (und zwar ohne irgendwelche kryptischen Konfigurationsdateien) einfach Listen von Sätzen zukommen lasst, die man in das Testsystem mit einbauen kann.

Die zweite angehängte Datei ist ein Beispiel dafür wie wir unsere Rasa-KI trainieren, stammt aus dem CoLA-Datenbestand.

LG

pah

[Beta-User]

Bin zwar nicht sicher, ob "wir" den Vergleich wollen .

Habe gewisse Zweifel ob das ganze zielführend ist, weil die Erkennungsrate von Rhasspy ja u.a. von der verwendeten NLU-Engine, deren Einstellungen (open transcription mode aktiviert oder nicht, Grenzwerteinstellungen bei der Erkennung usw.) und nicht zuletzt von den "sentences.ini" (und slots etc.) abhängt, aber das ist ja z.B. bei rivescript (?)/Babble auch nicht anders... (Rhasspy benutzt per default afaik auch im Untergrund rivescript/Perl). Die Beispielsätze sind zum Teil auch anders, als meine sehr auf die direkte Ansteuerung von Geräten zugeschnittenen, und ob das Ergebnis verwertbar (im Sinne von: kann eine Schaltaktion etc. ableiten) wäre, ist auch nicht unbedingt gesagt, selbst, wenn ein intent erkannt wird...

Anmerkungen:
- Weiß nicht, wann ich dazu komme, das im Livesystem zu testen. "An sich" müßte ( ) es klappen;
- getestet habe ich:
-- Auslesen der Datei
-- Schreiben des Ergebnisses (aber nur mit leeren bzw. Kommentar-Zeilen);
- Wenn der Prozess irgendwo hängt, müßte im list (unter "helper->test") zu sehen sein, wie weit RHASSPY gekommen ist;
- Ein Internal dient als Zähler; solange das sichtbar ist, wartet RHASSPY auf eine Antwort, die an den Test-Code weiterzugeben ist, die normale Intent-Verarbeitung sollte solange nicht aufgerufen werden;
- mit einem "stop" als Dateinamen kann man den Modus beenden, falls was schiefgegangen ist;
- es erfolgt keine irgendwie geartete aktive Rückmeldung, wenn RHASSPY damit durch ist;
- die Texte werden "stumpf" verschickt, es erfolgt lediglich eine Prüfung auf "leere Zeilen" und "scheint Kommentar zu sein".

EDITs:
- Bitte beim Testen auch mal schauen, ob der intentFilter wirklich auf "alles" gesetzt ist, sonst kann es natürlich zu "false negatives" bei den deaktivierten Intents kommen...
- Das Ganze setzt wie bei den msgDialog- und AMAD.*-Varianten voraus, dass die siteId der RHASSPY-Instanz für die Texterkennung freigegeben ist!

Viel Spaß und wie immer auf eigene Gefahr! (ein save vor dem Starten eines Tests kann nicht schaden )

[Beta-User]

"An sich" müßte ( ) es klappen

Tut es - zumindest bei einem sehr kurzen Test .

Weil
- das Ergebnis (wg. des ersten Tests bewußt) "seltsam" aussah,
- dieses direkt ein paar Verbesserungsoptionen an meinen sentences aufzuzeigen scheint, und
- dieses ja eigentlich auch nur ein Zwischenergebnis ist,
gibt's anbei noch eine weitere Testversion zu diesem Thema .

Wenn alles klappt wie gedacht (intensiveres Testen im Echtsystem muss wieder warten...), sollte
- die Ergebnisfile nur noch da Rückmeldungen enthalten, wo ein Ergebnis kam;
- auch die Auswertung für diverse "Abfragen" in den Ergebnissen enthalten sein (für die ganzen "setter" wäre es ggf. sehr viel schwieriger!);
- ein neues Reading etwas mehr Aufschluss geben, was die "ratio" betrifft und wo das ganze zu finden ist.

Konzipiert ist es jetzt als "get". Neben der File als Input gibt es jetzt auch die Option, einfach nur einen einzelnen Satz zu übergeben.
Dann werde ich mich wohl bei Gelegenheit dran machen, ein paar neue Testsätze zu bilden und v.a. auch die "info" gDT's etwas mehr in der Installation zu verteilen . Mir dreut, dass da auch noch Optimierungsbedarf am Modul selbst aufgezeigt wird... (GetNumeric mit "Feuchtigkeit" könnte ja von "humidity" nach "moisture" gehen, wenn ersteres nicht vorhanden ist, z.B.).

EDIT: Kurzcheck zeigt: Mit der file funktioniert es wie gewünscht, mit einem einzelnen Satz noch nicht... Die Vorversion ist jedenfalls überholt :

testResult => tested 153 sentences, failed: 135. See FEST_result.txt for detailed results.

[Beta-User]

Mal wieder ein update...

Hier jetzt mal die vorläufige "Gesamtliste" (nach meiner Bewertung).

- was noch nicht optimal läuft, sind die "kontinuierliche Eingaben" (DEF => sessionTimeout) und Dialoge bei AMAD-Input (Sprachausgabe=>Mikro wieder einschalten)

- gDT: mehr und bessere mappings? (auch weitgehend erledigt, v.a. mit "info" (s.u.) (scheint derzeit keinen weiteren Bedarf zu geben?)

# GetTimer implementieren? (erledigt, jedenfalls, was die über RHASSPY gesetzten Timer angeht)

# Wetterdurchsage
ersetzt durch STATE-Abfrage/gDT info?) (das müßte ggf. noch etwas besser getestet werden, läuft aber prinzipiell)

- Rückmeldung zu den AMAD.*-Schnittstellen
eigene rudimentäre Tests: das läuft soweit, bei Gelegenheit muss ich mir mal ansehen, ob/welche Events es gibt, an denen man ggf. erkennen könnte, dass eine "dialogische" Sprachausgabe "fertig" ist. Sonst müßte ggf. dann die Zeit geschätzt werden, die es braucht (wie?). Attributname wäre zu überdenken.

- "auto-training": Ändert man relevante Attribute, soll Rhasspy relativ direkt die aktualisierten Infos automatisch erhalten (Idee von martinp876). code dazu ist am werden. in der aktuellen Version implementiert, aber weiter noch nicht getestet (DEF: autoTraining-key). Tweak zum abschalten, bisher keine Probleme bekannt



Neu: Testen von "Multi-Kommandos" wie:
- "mach das Licht am Esstisch und die Stehlampe an
- schließe alle Rollläden im Wohnzimmer und Esszimmer

(bisher nur in der aktuellen Developer-Version, https://forum.fhem.de/index.php/topic,119447.msg1217486.html#msg1217486)

[Beta-User]

Vorschlag: Im allerersten Post des Threads auf wichtige Zwischenergebnisse hinweisen, mit Link auf den entsprechenden Post.

Etwas modifiziert: Im ersten Beitrag dieses Threads ist ab jetzt ggf. die/eine Entwicklerversion zu finden, so es eine solche gibt.

Die jeweiligen Änderungen werden dann vorerst jeweils mit einem eigenen Beitrag in diesem Thread bedacht, damit die Doku an anderer Stelle besser paßt. Sollte halbwegs übersichtlich bleiben so.

Falls jemand Anmerkungen oder Fragen hat, die direkt mit dem Code zu tun haben oder Fehler/Warnings berichten will/muss, bitte direkt in https://forum.fhem.de/index.php/topic,119447.0.html schreiben, für einzelne Aspekte zur Anwendung bitte ggf. einfach einen separaten Thread aufmachen und [RHASSPY] davor schreiben...

Zusammenfassung von dem, was die letzte svn-Fassung bringt:

Also: Aktualisierte Fassung ist im svn, damit ist
- das "multicommand"-feature allgemein verfügbar...
- (hoffentlich) das Schalten aus dem Test per File heraus Geschichte;
- die Rückmeldung nach Test per File auch wieder lesbar.

Ergänzungen der aktuellen Entwicklerversion:
- Formatierung der Rückgabe für's Testen jetzt ähnlich zu pah's Vorschlag aus https://forum.fhem.de/index.php/topic,119447.msg1217876.html#msg1217876
- Bei Gruppen-Etiketten gibt es jetzt auch sowas wie eine "Hauptgruppe"
Die Hauptgruppen werden z.B. bei "was kannst du schalten" dann zusätzlich zu den "aliases" mit gelistet. Leider sind das dann uU. (und eben jetzt erst recht) viele Elemente, so dass das manchem ggf. auch "too much" ist. Aber in irgendeinen Apfel muss man halt erst mal beißen...

Viel Spaß beim Testen, läuft bei mir derzeit schon im Hauptsystem, war aber "heiß", bis es mal lief (Abstürze und so, allerdings nicht ganz unerwartet (save statefile hilft)... Kann leider nicht ausschließen, dass ich was übersehen habe .

[Prof. Dr. Peter Henning]

Folgt Ihr eigentlich dem Thread hier:  https://community.rhasspy.org/t/the-future-of-rhasspy/3373

Sieht aus meiner Sicht nicht gut aus.

LG

pah

[JensS]

In https://community.rhasspy.org/t/the-future-of-rhasspy/3373/38 sieht es wieder etwas besser aus, wenngleich in jedem Fall ein Interessenkonflikt im Raum steht.

Gruß Jens

[drhirn]

Folgt Ihr eigentlich dem Thread hier:  https://community.rhasspy.org/t/the-future-of-rhasspy/3373

Ja. Hab auch schon an RHASSPY gezweifelt.
Aber, wir haben ja insofern Glück, als dass das ganze System auf dem Hermes-Protokoll aufbaut. Irgendjemand wird da schon irgendwann was anderes daraus machen. Red ich mir zumindest ein

[Beta-User]

Nun ja, meine 2ct zu diesem Thema:
- es war eigentlich vor allem vor dieser Verlautbarung beängstigend ruhig, was gewisse Hinweise/Fragen anging, von daher fand ich das "prinzipiell wird es weitergehen" eher ermutigend;
- Rhasspy läuft prinzipiell. Es weiter zu pflegen ist deutlich einfacher, als es zu entwickeln. Ich gehe daher davon aus, dass das Projekt weiterlebt, unabhängig von der Frage, ob es "den" aktiven "Guru" dahinter gibt oder nicht.
- Rhasspy ist "nur" eine Art Sammlung von Scripts, die untereinander per standardisiertem Protokoll (eher lose) verwoben sind. Das sollte es einigermaßen leicht machen, Teile zu aktualisieren, hinzuzufügen, ...

Es muss sich halt "nur" jemand finden, der sich kümmert und ggf. die Entscheidungen trifft bzw. kompetent moderiert.

Ich bin optimistisch, was das angeht, bisher sind mir keine überzeugenden Alternativen bekannt, und der Bedarf ist da...

[Beta-User]

Im ersten Post gibt es wieder ein update.

Funktional sollte es "nur" die Nachfragen bei doppelten matches "outside room" bringen, die hier als fehlend hochgepoppt waren:

Jetzt bekomme ich auf den Befehl "schalte das licht an" die Antwort "Tut mir leid, ich konnte kein passendes Gerät finden". Das kann eigentlich nicht sein, denn es gibt 2 Geräte, die einen rhasspyName "licht" haben. Eigentlich gute Voraussetzungen für eine Nachfrage seitens Rhasspy.

Dazu waren aber ein paar etwas tiefere Eingriffe in den Code erforderlich (die Rückfrage-Anfragen laufen jetzt alle über denselben Code), und ich bin mir auch noch nicht siechr, ob alle diese neuen Anfragen gut finden werden (oder ob man das abschaltbar machen sollte)...

Wie dem auch sei: Wäre nett, wenn ihr testen könntet, weil meine Phantasie erfahrungsgemäß nicht groß genug ist, alle möglichen Nebenwirkungen vorab zu erahnen...
Meine eigenen Tests waren soweit ok, aber nicht besonders intensiv.

Sinnvollerweise würde ich empfehlen, statt ChoiceRoom/ChoiceDevice-Intents alles in einen "Choice"-Intent zusammenzuführen. Der kann dann nämlich auch "ausdrücklich" mit sowas wie "Nimm das Licht im Esszimmer" umgehen, was es einfacher machen sollte, zum einen sprachliche Vielfalt zu ermöglichen, und zum anderen das gewünschte Ergebnis zu erzielen...

[Beta-User]

Noch ein Mini-Update im ersten Post betreffend unserer netten "intent not recognized"-Diskussion...

Diese Themenkreise habe ich dazu bisher wahrgenommen:
1. Rückmeldung an den Sprecher: "so geht es nicht"
2. Logging entsprechender "Sätze"
3. "Weiterverarbeitung" (bis hin zur Ergänzung der sentences.ini)

Punkt 1 funktioniert bis dato nicht - ich habe es bei meinen kurzen Tests nicht geschafft, auch eine "siteId" nach $data zu verfrachten, damit weiß "respond" nicht, wohin das gehen soll... Kann sein, dass das was anderes ist, wenn man den Dialog offen hält, dann könnte das eventuell gehen (wobei das dann ggf. über zwischengespeicherte Sitzungsdaten rekonsturiert wurde).

Punkt 2 kann per "normalem FHEM-Logging" erfüllt werden, wenn man den (evtl. undokumentierten) Key "experimental=1" in der DEF setzt. Dann wird triggernd das Reading "intentNotRecognized" gefüllt (mit der session id und dem rawInput).

Punkt 3 könnte funktionieren, es muss aber einen "custom intent" geben namens "intentNotRecognized". Wie man den da sinnvoll reinmogelt, habe ich mir bisher nicht überlegt, getestet ist es ebensowenig. Aber falls es klappt, ist es eben ein "custom intent", über den beliebiger Perl-Code aufgerufen werden kann und an den man auch DATA übergeben könnte...

Sieht mir insgesamt aber eher wie eine Sackgasse aus - aber das zu wissen, ist ja auch schon mal was...

[Beta-User]

Bisher keine Rückmeldung zu den letzten beiden Posts (und dem aktualisierten Code)?

OK...

Na ja, hier jedenfalls mal meine aktuellen "Choice"-Sätze:

Code Auswählen Erweitern


[de.fhem:Choice]
den=<de.fhem:SetOnOff.den>
choose= ( nimm [bitte] | [bitte] nimm | ich hätte gerne | [ich] (wähle|nehme) )

<choose> [ <den> [( Gerät | $de.fhem.Aliases{Device} )] ] ( aus ( dem | der ) | im | den | die ) $de.fhem.MainRooms{Room}
<choose> [ <den> ] $de.fhem.Aliases{Device} [ ( aus ( dem | der ) | im | den | die ) $de.fhem.MainRooms{Room} ]
<choose> [ ( die Szene | den Modus ) ] $de.fhem.Scenes [Modus] [ [( am | vom )] $de.fhem.Aliases{Device} ] [( aus ( dem | der ) | im | den | die ) $de.fhem.MainRooms{Room} ] [bitte]

Wie man vielleicht sehen kann, ist das ganze etwas "offener", der Sprecher hat also auch die Möglichkeit, ggf. nochmal das Device zu ändern, wenn eigentlich nur nach dem Raum gefragt ist und umgekehrt.
Weiter ist da eine Szenenauswahl vorbereitet, allerdings fehlt wohl die "Eingangssequenz", mit der man eine Szenenauswahl anschubsen kann ("sag mir welche Szenen/Szenarien/... du kennst").

[Beta-User]

Weiter ist da eine Szenenauswahl vorbereitet, allerdings fehlt wohl die "Eingangssequenz", mit der man eine Szenenauswahl anschubsen kann ("sag mir welche Szenen/Szenarien/... du kennst").

Nachtrag: zumindest in meinen sentences war doch schon was drin:

Code Auswählen Erweitern

[de.fhem:SetScene]
<de.fhem:SetOnOff.cmdmulti> <de.fhem:SetOnOff.den> $de.fhem.Device-scene{Device} [<de.fhem:SetOnOff.rooms>] auf [ ( die Szene | den Modus ) ] $de.fhem.Scenes
<de.fhem:SetOnOff.cmdmulti> <de.fhem:SetOnOff.den> $de.fhem.Device-scene{Device} [<de.fhem:SetOnOff.rooms>] auf $de.fhem.Scenes Modus
Welche (Szenen | Szenarien | Einstellungen){Get:scenes} (kennt|kann) [(der | die | das)] $de.fhem.Device-scene{Device}
...und kaum weiß man, was man sucht, gibt's dazu auch Code in der aktuellen Version. (Hatten wir nicht sogar schon eine Dsikussion bzgl. der "Vermischung" von Set- und Get-Intents... Je mehr ich über das ganze Nachdenke, desto weniger braucht es imo diese Trennung .)

Ich weiß aber leider nicht mehr, ob ich diesen Teil schon getestet hatte ...

[drhirn]

Hatten wir. In Bezug auf Timer
https://forum.fhem.de/index.php/topic,119447.msg1215707.html#msg1215707

Und das mit den Szenen hab ich mal getestet. Und jetzt gerade auch. Dabei ist mir was aufgefallen. Dazu gleich mehr im "Enwicklungs"-Thread

[Beta-User]

Neuer Versuch für "SetScene" - dieses Mal wirklich nur mit "setze"-Anweisungen, aber der Möglichkeit, mehr oder weniger "offen" zu sagen, dass man noch nicht weiß, wie es genau gehen könnte...

Code Auswählen Erweitern

[de.fhem:SetScene]
<de.fhem:SetOnOff.cmdmulti> <de.fhem:SetOnOff.den> $de.fhem.Device-scene{Device} [<de.fhem:SetOnOff.rooms>] auf [ ( die Szene | den Modus ) ] $de.fhem.Scenes [Modus]
<de.fhem:SetOnOff.cmdmulti> [<de.fhem:SetOnOff.den> $de.fhem.Device-scene{Device}] <de.fhem:SetOnOff.rooms> auf [ ( die Szene | den Modus ) ] $de.fhem.Scenes [Modus]

<de.fhem:SetOnOff.cmdmulti> <de.fhem:SetOnOff.den> [$de.fhem.Device-scene{Device}] [<de.fhem:SetOnOff.rooms>] auf( eine Szene | einen  Modus ){Get:scenes}

Klappt prinzipiell, Schwachpunkt ist aber noch, dass man bei gleichnamigen Devices dann zum Teil eine Auswahl angeboten bekommt, die effektiv gar nicht besteht (mein "verstärker" ist nur im Wohnzimmer für "Szenen" zu haben...)

[drhirn]

(mein "verstärker" ist nur im Wohnzimmer für "Szenen" zu haben...)

Warum ist der dann im scene-Slot?

[Beta-User]

Warum ist der dann im scene-Slot?

Na ja, im Wohnzimmer passt das, im Esszimmer aber nicht (andere YAMAHA_AVR-Instanz, aber gleiche rhasspyNames). Das "Problem" ist, dass "getDeviceByName()" jedenfalls im Moment noch nicht in der Lage ist, bei gleich benannten Geräten zu erkennen, wenn eines bestimmte Dinge _nicht kann_. Bin bisher nur noch nicht über den Punkt gestolpert, weil mein Satellit zumeist im "richtigen Raum" war... Mal schauen, ob sich da noch was verbessern läßt .

[Beta-User]

Hallo zusammen,

im ersten Thread gibt es wieder eine "Testversion", ich gedenke das heute abend/über das WE dann einzuchecken, hier schon mal das "changelog":

1. Identifikation von Devices

Das "Problem" ist, dass "getDeviceByName()" jedenfalls im Moment noch nicht in der Lage ist, bei gleich benannten Geräten zu erkennen, wenn eines bestimmte Dinge _nicht kann_. Bin bisher nur noch nicht über den Punkt gestolpert, weil mein Satellit zumeist im "richtigen Raum" war... Mal schauen, ob sich da noch was verbessern läßt .

Die Funktion ist jetzt überarbeitet und sollte nur noch Devices berücksichtigen, die "das angefragte" auch umsetzen können.

Anders herum gab es  Restriktionen bei "isValidData()", das noch nicht mitbekommen hatte, dass die Device-Ermittlung hinreichend genau sein sollte, dass mit weniger Daten entweder ein Device ermittelt werden kann oder eine Rückfrage erfolgen könnte...

Na ja, jedenfalls funktioniert jetzt (auch ohne funktionierenden customFloat-Filter auf der Rhasspy-Seite) sowas hier:

Code Auswählen Erweitern

[de.fhem:SetNumeric]
[...]
<cmdmulti> [<den>] $de.fhem.Device-thermostat{Device} [<rooms>] auf (5..25  [(komma:. (0|5)|(ein halb). 5))]){Value} Grad{Type:temperature}
<cmdmulti> <rooms> auf (5..25  [(komma:. (0|5)|(ein halb). 5))]){Value} Grad{Type:temperature}

2. Choice
Sinnvollerweise sollte man den generischen "Choice"-Intent benutzen statt der alten gesplitteten:

Code Auswählen Erweitern

[de.fhem:Choice]
den=<de.fhem:SetOnOff.den>
choose= ( nimm [bitte] | [bitte] nimm | ich hätte gerne | [ich] (wähle|nehme) )

<choose> [ <den> [( Gerät | $de.fhem.Aliases{Device} )] ] ( aus ( dem | der ) | im | den | die ) $de.fhem.MainRooms{Room}
<choose> [ <den> ] $de.fhem.Aliases{Device} [ ( aus ( dem | der ) | im | den | die ) $de.fhem.MainRooms{Room} ]
<choose> [ ( die Szene | den Modus ) ] $de.fhem.Scenes [Modus] [ [( am | vom )] $de.fhem.Aliases{Device} ] [( aus ( dem | der ) | im | den | die ) $de.fhem.MainRooms{Room} ] [bitte]
Dadurch hat man als Sprechender die Möglichkeit, ggf. z.B. wegen des Raums dann noch korrigierend einzugreifen, wenn eine Zuordnung nicht so richtig passen sollte oder man sich versprochen hat...

3. intentNotRecognized
Bei allen nicht erkannten Intents meldet RHASSPY jetzt zurück, dass es damit nichts anfangen konnte...
(OT: Bei mir in der Installation immer noch offen ist, wie man die Einstellungen auf der Rhasspy-Seite für STT so vornimmt, dass man nicht zwanghaft bei einem "bekannten" intent landet - mit einem möglicherweise "unschlagbaren" confidence level...)

Ansonsten wurde noch etwas aufgeräumt - (hoffentlich) nix dramatisches ...

Alles in allem habe ich den Eindruck, dass die letzten verbliebenen Baustellen sind:
- der weitere Umgang mit den "not recognized"-Geschichten
- mögliche Wechsel von Gruppen- auf Einzelschaltung und umgekehrt (oder auch: ist "die Beleuchtung" jetzt ein Gruppenname oder ein einzelnes Device...?!?)

Ansonsten ist das Ding nunmehr ziemlichst rund . Bin mal auf eure Rückmeldungen gespannt!

[Beta-User]

das heute abend/über das WE dann einzuchecken[...]
Ansonsten ist das Ding nunmehr ziemlichst rund .

Ist drin, seit eben dann noch mit einem "kleinen Zusatz", der es m.E. "noch runder" macht und von dem ich hoffe, dass er ebenfalls positiven Anklang findet:

SetNumeric - Factor
Im Zuge der Durchsicht, was andere so an "Show me"-Postings hatten ist mir was über den Weg gelaufen, das ich cool fand:
https://community.rhasspy.org/t/some-example-sentences-for-german/1685
Die Idee war dort, konkrete Änderungswerte für "lauter" und "deutlich lauter" zu hinterlegen . Da mir meine Standardänderung bei leiser/lauter auch meistens (!) etwas zu klein ist, landete es auf meinem "könnte man ja mal überlegen, wie das geht"-Stapel. Umgesetzt ist es jetzt etwas generischer ...

Code Auswählen Erweitern

[de.fhem:SetNumeric]
den=<de.fhem:SetOnOff.den>
etwas=(etwas | ein ( wenig| bißchen){Factor:0.75} | merklich{Factor:1.5} | deutlich{Factor:2} | sehr viel{Factor:3} )
etwasProzent=( <etwas> | [um] [(0..100){Value}] [prozent{Unit:percent}] )
etwasLauter=( <etwas> | [um] [(0..10){Value!int}] [dezibel{Type:volume}] )
etwasGrad=( <etwas> | [ um ] [(0..10){Value!int}|(ein halbes){Value:0.5} ] [grad{Type:temperature}] )

Probleme konnte ich bisher nicht erkennen, diese <etwas>-Variable ist bei mir dann auch im entsprechenden Gruppenintent verwendet...

EDIT: eine Sache hatte noch nicht funktioniert: ZWave ist immer etwas "speziell", wenn es um seine Zustände geht... Daher wird jetzt bei SetNumeric pauschal geschaut, ob neben einer Zahl noch was anderes im Reading steht (im Prinzip eine Art ReadingNum()-Funktion), und wenn ja, nur der Zahlenanteil extrahiert...
sentence dazu:

Code Auswählen Erweitern

( <cmddrive> | <cmdmulti> ) [<den>] $de.fhem.Device-blind{Device} [<de.fhem:SetOnOff.rooms>] (<etwas> | ein [(kleines{Factor:0.75} | großes{Factor:2} ) ] Stück{Value:15}) (auf{Change:setUp} | zu{Change:setDown} )
(öffne{Change:setUp} | schließe{Change:setDown} ) [<den>] $de.fhem.Device-blind{Device} [<de.fhem:SetOnOff.rooms>] (<etwas> | ein [(kleines{Factor:0.75} | großes{Factor:2} ) ] Stück{Value:15})

Bin mal auf eure Rückmeldungen gespannt!

EDIT: Die svn-Version kommt jetzt auch mit den Ergänzungen der Test-Sentences für die amazon-id's klar.

[Beta-User]

Neuer update im svn:
- bei mehreren "aktiven Geräten" wird jetzt rückgefragt, wenn es mehrdeutig ist (Diskussion ab hier: https://forum.fhem.de/index.php/topic,119447.msg1223137.html#msg1223137)
- "priority"-Setzungen werden dabei jetzt auch berücksichtigt

[Beta-User]

Neuer update im svn:
- Es gab ein Problem mit Gruppenanweisungen in der letzten Version, das scheinbar bisher keiner bemerkt hat...
- Für MPD sind jetzt ein paar features drin, von denen ich bisher auch nicht in vollem Umfang weiß, ob sie funktionieren.

Meine MediaControls-sentences sehen in etwa so aus:

Code Auswählen Erweitern

song=lied|titel|song
songs = lieder |titel |songs
by=( von [(den | der [Band] )] )
to=( tu | bis )

[...]

play = (spiele:cmdPlaySelected | (spiele (auch|noch)):cmdAddSelected ){Command}
<play> ( ((ein paar):5) | 10 | 15 | 20 | 100){RandomNr} <songs> von $de.artists{Artist}
<play> $de.albAndArt
spiele{Command:cmdPlaylist} $de.playlists{Playlist} <atDevice>

Die Felder sind in der commandref erklärt, wie die slots gebaut werden, ist Gegenstand im Entwicklungs-Thread (dort ist das script in der aktuellen - vermutlich noch nicht finalen Fassung - zu finden).

Jetzt muss ich erst mal meinen MPD (oder genauer gesagt: das OS von dem Rechner, auf dem der läuft) updaten, dann sehen wir weiter...