[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...