Rhasspy, mein Weg zu neuen Ufern: es läuft

Begonnen von Gisbert, 19 November 2021, 23:08:07

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: Gisbert am 19 April 2022, 21:56:02
das Problem war ärgerlich wie einfach zu lösen.
:) Schön, dass du die Ursache gefunden hast.

Deine implizite Rückmeldung zu RHASSPY vs. Google Assistant fand ich übrigens sehr motivierend  8) !

Hatte schon gezweifelt, ob alles ok ist oder ob du irgendein aktuelles und frustrierendes Problem hast, das dich so nervt, dass du RHASSPY den Rücken gekehrt hast oder vor der Fülle an Möglichkeiten kapituliert ::) .
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

Gisbert

Hallo Jörg,

ich verfolge interessiert deine weiteren Entwicklungen, ohne jedoch Details nachvollziehen zu können.

Ich hab mir gedacht, dass eine Kommunikation ganz schön wäre. Deshalb hab ich aus dem Wiki die folgenden Zeilen in sentences.ini ergänzt (zur Vollständigkeit die gesamte Datei):
[de.fhem:SetNumeric]
(fahre|fahr|stelle|stell) [den|die|das] $de.fhem.Device-blind{Device} [(im|in|in dem|auf dem|in der|auf der) $de.fhem.Room{Room}] auf Lücke{Value:10}
(halte|stopp|stoppe) [den|die|das] $de.fhem.Device-blind{Device} [(im|in|in dem|auf dem|in der|auf der) $de.fhem.Room{Room}] [an] {Change:cmdStop}

[de.fhem:SetOnOff]
(schalte|schalt|mache|mach|stelle|stell|fahre|fahr) [den|die|das] $de.fhem.Device-SetOnOff{Device} [(im|in|in dem|auf dem|in der|auf der|an der) $de.fhem.Room{Room}] ((an|ein|hoch|auf){Value:on}|(aus|zu|runter){Value:off})

[de.fhem:ChoiceRoom]
nimm [das Gerät] ( aus ( dem | der ) | im | den | die ) $de.fhem.MainRooms{Room}

[de.fhem:ChoiceDevice]
ich hätte gerne [das Gerät] $de.fhem.Aliases{Device}

[de.fhem:CancelAction]
(lass es | nein | abbrechen | abbruch ){Mode:Cancel}

[de.fhem:ConfirmAction]
( ja mach | tu es | ist ok | aber gerne doch ){Mode:OK}


In Fhem habe ich ausgeführt:
set <mydevice> update all

Es gibt jetzt 2 Fhem-Geräte mit dem rhasspyName-Attribut "licht", eines davon mit dem rhasspyRoom-Attribut "wohnzimmer", das andere "haustür".
Wenn ich in der Android-App sage: "schalte das licht an", kommt keine Rückfrage, es wird das Licht im "wohnzimmer" angeschaltet.
Bei der "haustür" ist die Funktionalität gegeben, denn der Befehl "schalte das licht an der haustür an" wird ausgeführt.

Anders verhält es sich bei folgendem Befehl: "halte den Rollladen an" - hier bekomme ich die Anwort von der App: "Tut mir leid, ich konnte kein passendes Gerät finden".
Wenn ich dann anschließend sage (Mikrofon erneut angeschaltet): "nimm das Gerät im Schlafzimmer von ..." bekomme ich die Anwort: "Warte gerade nicht auf eine Auswahl".

Im Wiki steht:
ZitatEigene Dialoge
Über Custom Intents in Verbindung mit passenden Rückgabewerten aus myUtils-Perl-Code lassen sich Sitzungen offen halten und so eigene Dialoge gestalten. (siehe Intents in eigenen Dateien)
Der Link am Schluss funktioniert nicht.

Ich hab auch von AMAD gelesen, das ich auch in Fhem nutze. Was hat es damit auf sich, oder mit anderen Worten, wie kann ich das in Zusammenhang mit Rhasspy nutzen.

Viele Grüße
Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Beta-User

Zitat von: Gisbert am 08 Mai 2022, 15:10:39
Wenn ich in der Android-App sage: "schalte das licht an", kommt keine Rückfrage, es wird das Licht im "wohnzimmer" angeschaltet.
Bei der "haustür" ist die Funktionalität gegeben, denn der Befehl "schalte das licht an der haustür an" wird ausgeführt.
Wenn direkt etwas geschaltet wird, ist aus RHASSPY-Sicht eine Eindeutigkeit gebeben. Das sollte eine der folgenden beiden Ursachen haben:
- Entweder du hast "Prioritäten" gesetzt (vermutlich noch nicht), oder
- dein Satellit befindet sich im "wohnzimmer" (siteId2room-Reading)?
Wenn es letzteres ist: Entweder das Reading mal löschen, oder es in den Raum "haustür" verlegen, oder in einen anderen Raum, in dem es _kein_ Device "licht" gibt...


Zitat
Anders verhält es sich bei folgendem Befehl: "halte den Rollladen an" - hier bekomme ich die Anwort von der App: "Tut mir leid, ich konnte kein passendes Gerät finden".
Kennt denn dein Rollladen einen "stop"-Befehl? Wenn ja: wie sieht der betreffende Abschnitt in deinem RHASSPY-devicelist-list aus?

Zitat
Wenn ich dann anschließend sage (Mikrofon erneut angeschaltet): "nimm das Gerät im Schlafzimmer von ..." bekomme ich die Anwort: "Warte gerade nicht auf eine Auswahl".
Wenn die Sache aus RHASSPY-Sicht "fertig" ist, werden die Sitzungsdaten gelöscht, das Einschalten des Mikrofons durch dich als User startet eine neue Sitzung. Einfach so in einen Auswahldialog reinzugehen ist jedenfalls derzeit nicht möglich/vorgesehen.

Zitat
Im Wiki steht:Der Link am Schluss funktioniert nicht.
Danke, ist repariert!

Zitat
Ich hab auch von AMAD gelesen, das ich auch in Fhem nutze. Was hat es damit auf sich, oder mit anderen Worten, wie kann ich das in Zusammenhang mit Rhasspy nutzen.
Im Prinzip kann AMAD.* die "mobile app" ersetzen (abgesehen von der wakeword-Funktionalität). Ich habe z.B. einen (leider nicht mit einem Icon versehenen) shortcut auf dem Handy, mit dem der "activateVoiceInput"-flow gestartet wird.
Damit das funktioniert, muss eigentlich nur das AMADDevice als "allowed" in dem RHASSPY-Attribut eingetragen sein. Bitte aber darauf achten, dass sich das nicht mit irgendwas anderem "beißt", das du ggf. bisher im Einsatz  hast.
Es wäre ggf. sinnvoll, für den AMAD.*-Teil einen separaten Thread zu starten, das ist evtl. noch für andere User interessant (und bisher komplett undurchsichtig)...
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

Prof. Dr. Peter Henning

#108
Zitatund bisher komplett undurchsichtig
Na ja, sagen wir: nicht gut dokumentiert. Wird sich möglicherweise ändern, eines meiner nächsten Buchprojekte wird sich speziell mit Sprachsteuerung im SmartHome befassen.

Der Knackpunkt hierbei ist, dass die Spracherkennung auf den Android-Devices (mit Google...) einfach um Klassen besser ist als alles, was mit Open Source derzeit hinzubekommen ist. Mein Workflow ist also

Wakeword (in Rhasspy) -> MQTT Message aus Rhasspy an einen MQTT2_CLIENT -> Einschalten VoiceInput auf AMAD-Device -> Analyse des von Google erhaltenen Textes (Intent-Erkennung, bzw. Chatbot hinten dran) durch Babble -> Schaltbefehl an FHEM (ohne oder mit Sprachausgabe als Bestätigung, oder Abfrage von Daten aus FHEM (und Umwandlung in verständliche Sprache) oder nur Sprachantwort (z.B. vom Chatbot -> Triggern der Sprachausgabe (entweder auf AMAD-Devices, oder holen von Sprach-MP3-Dateien von Amazon Polly zur Ausgabe auf Linux-Geräten oder BOSE SoundTouch.

Zur Sprachausgabe nutze ich in der Regel Amazon Polly. Und zwar auch auf den AMAD-Devices mit derselben Stimme. Das geht deshalb, weil der Sprachsynthesedienst Ivona vor einigen Jahren von Amazon aufgekauft worden ist, und eine ziemlich alte App von Ivona immer noch gut funktioniert. Und auf Linux bzw. BOSE-Geräten wird halt der Text an Amazon Polly gesendet und für Null Euro als MP3 zurückgesendet. Da dabei vor-erzeugte MP3-Dateien mit aktualisierten Daten zusammengefügt werden, ist das auch cloud-sicher (nicht cloud-frei...) Der chinesische Geheimdienst kann von mir aus gerne erfahren, welche Temperatur in meinem Schlafzimmer herrscht.

Eine klare Erkenntnis aus meinen Forschungsprojekten kann ich nicht oft genug zitieren: Jedes Sprachsteuerungssystem benötigt eine "dialog closure" am Ende, die auf noch so absurde Fragen und Antworten der Nutzer reagiert und immer irgendetwas zurückliefert, das eben nicht eine mehr oder weniger höfliche Form von "Das habe ich nicht verstanden" ist.

Das alles kann man mit oder ohne das Modul RHASSPY machen.

LG

pah

Gisbert

#109
Hallo Jörg,

Amad spare ich mir dann für später auf.

Ich habe das Reading siteId2room-Reading gelöscht, es hatte den Wert "wohnzimmer"; das erklärt dann wohl, dass ohne Angabe eines Raumes der Raum "wohnzimmer" genommen wurde.

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.

Das Attribut enableMsgDialog hat den Wert 0. Kann es daran liegen? Wie kann ich den Wert ändern (außer mit setreading)?

Viele Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Beta-User

Zitat von: Gisbert am 08 Mai 2022, 20:39:31
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 das einen rhasspyName "licht" haben. Eigentlich gute Voraussetzungen für eine Nachfrage seitens Rhasspy.

Das Attribut enableMsgDialog hat den Wert 0. Kann es daran liegen? Wie kann ich den Wert ändern (außer mit setreading)?
Das sieht mir nach einem Bug aus, muss ich mir ansehen.
Alles, was "msg" in der Benennung hat, hat mit wieder einer anderen Schnittstelle zu tun, das dürfte nicht mit der fehlenden Rückfrage zusammenhängen.

Die commandref enthält ein paar Infos, wie die Werte in dem Attribut ggf. aussehen sollten (ist aber wie AMAD ein separtes Thema!).

Zitat von: Prof. Dr. Peter Henning am 08 Mai 2022, 17:10:21
Na ja, sagen wir: nicht gut dokumentiert. Wird sich möglicherweise ändern, eines meiner nächsten Buchprojekte wird sich speziell mit Sprachsteuerung im SmartHome befassen.
Na ja, es gab bisher auch wenig Interessenten, um wesentlich mehr zu machen (und ggf. fertig zu entwickeln...) wie das, was jetzt in der Attribut-commandref zu finden ist...

Zitat
Eine klare Erkenntnis aus meinen Forschungsprojekten kann ich nicht oft genug zitieren: Jedes Sprachsteuerungssystem benötigt eine "dialog closure" am Ende, die auf noch so absurde Fragen und Antworten der Nutzer reagiert und immer irgendetwas zurückliefert, das eben nicht eine mehr oder weniger höfliche Form von "Das habe ich nicht verstanden" ist.
Danke für den nochmaligen Hinweis.

Das mit "intent not recognized" ist in der Tat so ein offener Faden, bei dem wir insgesamt noch nicht zu einem befriedigenden "was wollen wir damit machen" gekommen sind (in den anderen Fällen sollte eigentlich immer irgendwas zurückkommen, oder übersehe ich grade was?).

Zitat
Das alles kann man mit oder ohne das Modul RHASSPY machen.
Klar. Im Prinzip kann man RHASSPY auch als "dummes Zwischen-Interface" zu Rhasspy nutzen, ohne devicemap etc. zu füllen. Tendenziell meint mein Bauchgefühl zwar, dass es weiter sinnvoll ist, alle Admin- und notify-Routinen im Modul abzubilden, aber das kann täuschen...
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

Zitat von: Beta-User am 08 Mai 2022, 21:28:47
Das mit "intent not recognized" ist in der Tat so ein offener Faden, bei dem wir insgesamt noch nicht zu einem befriedigenden "was wollen wir damit machen" gekommen sind (in den anderen Fällen sollte eigentlich immer irgendwas zurückkommen, oder übersehe ich grade was?).
Da RHASSPY die sentences.ini auswertet, ist der "Open transcription mode" nicht wirklich zu gebrauchen. Die Sprachdaten zu einem Onlinedienst zu schicken, bringt nur teilweise etwas. Google und Co keinnen beispielsweise nicht die verwendeten RhasspyNamen, Gruppen, Räume,...
Interessant wäre die Auswertung von "intent not recognized" und anschließende Analyse durch eine KI (rasa o.a.). Dadurch könnten Absichten erlernt werden, welche dann von RHASSPY gezielt als Rückfrage gestellt werden.

ZitatKlar. Im Prinzip kann man RHASSPY auch als "dummes Zwischen-Interface" zu Rhasspy nutzen, ohne devicemap etc. zu füllen. Tendenziell meint mein Bauchgefühl zwar, dass es weiter sinnvoll ist, alle Admin- und notify-Routinen im Modul abzubilden, aber das kann täuschen...
Genau dahin ging der Ansatz des modularen Aufbaus von RHASSPY, ähnlich wie bei SIGNALduino und den Modulen SD_WS. etc..
Man könnte je nach Bedarf oder Kenntnis, RHASSPY mit den gewünschten Module zusammenstellen.

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.

Prof. Dr. Peter Henning

ZitatInteressant wäre die Auswertung von "intent not recognized" und anschließende Analyse durch eine KI (rasa o.a.). Dadurch könnten Absichten erlernt werden, welche dann von RHASSPY gezielt als Rückfrage gestellt werden.

Pardon, aber da muss ich klar widersprechen. Eine KI kann keinerlei Absichten aus nicht erkannten Sätzen lernen, und bei Rasa geht das schon gar nicht.

Babble schreibt übrigens alle nicht erkannten Sätze in eine Datei. In meinem RiveScript-Chatbot gibt es einen rudimentären Lernmodus, mit dem ich dem System neue Räume und Geräte hinzufügen kann.


LG

pah

JensS

Zitat von: Prof. Dr. Peter Henning am 09 Mai 2022, 05:44:25
Pardon, aber da muss ich klar widersprechen. Eine KI kann keinerlei Absichten aus nicht erkannten Sätzen lernen, und bei Rasa geht das schon gar nicht.
Schade, ich ging davon aus, dass Rasa auf Tensorflow basiert und RHASSPY die möglichen Sätze in der sentences.ini als Datenmenge zur Erkennung bereitstellt. Man könnte den Satz sich mit der höchsten Wahrscheinlichkeit durch eine Rückfrage mittels RHASSPY bestätigen/verneinen lassen und so (bei mehrmaliger Bestätigung) einen weiteren Datensatz in Tensorflow hinzufügen. Aber wenn das nicht geht, geht's halt nicht.

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

Zitat von: Beta-User am 08 Mai 2022, 21:28:47
Das sieht mir nach einem Bug aus, muss ich mir ansehen.
Kein bug, sondern schlicht bisher nicht als "Mache einen Request"-Pfad ausgelegt/vorgesehen. Finde ich aber an sich eine sinnvolle Ergänzung, muss aber erst mal selbst darauf rumtesten => wird (vermutlich kurz) dauern...

Zitat
Das mit "intent not recognized" ist in der Tat so ein [...]
... schwieriges Thema...
Mal abgesehen von allem anderen, ist es "im Prinzip" auch noch ziemlich anonym  :( . Wie man aus https://rhasspy.readthedocs.io/en/latest/reference/#nlu_intentnotrecognized ablesen kann, ist da zwar die siteId mitgeliefert, aber damit ist noch lange nicht gesagt, dass FHEM/RHASSPY das in irgendeiner Form interessieren _müßte_. Zwar wird es in einer "Einheits-Normal-Installation" so sein, dass eine RHASSPY-Instanz da ist und nur ein FHEM (und auch keine andere Automatisierung iVm. Rhasspy), aber trotzdem habe ich sehr große Skrupel, einfach alles "unerkannte" durch RHASSPY einfach wieder "zuhauen" zu lassen. Das ergäbe im schlimmsten Fall unerwünscht geschlossene sessions mit mehrsprachigen "kannitverstahn"-Audio-Rückmeldungen...
Wenn, muss m.E. der "Administrator" sowas aktiv anschalten müssen.
Oder übersehe ich was?!?

Ansonsten:
Selbst wenn man wüßte, für welche siteId's eine RHASSPY-Instanz (ggf. iVm. bestimmten wakewords) dann "zuständig" sein soll, wäre es auch mit einem im Hintergrund gut funktionierenden KI-Tool schwierig zu entscheiden, an welcher Stelle denn eine Anpassung in der FHEM-Konfiguration vorzunehmen wäre. Dazu eine passende Logik zu entwerfen erscheint mir in keiner Relation zum Nutzen zu stehen.

Was das loggen von intentNotRecognized angeht:
An sich scheint mir das eine sehr gute Idee zu sein, von daher würde ich dazu neigen eine Option vorzusehen, $data in ein ein triggerndes Reading umleiten zu können. Dann kann man es mit den üblichen Bordmitteln (FileLog) mitschneiden. Ergänzend wäre dann aber die Frage, ob man nicht auch "erkannte", aber mangels min-confidence-Level verworfene Messages dann (bei ausreichendem/einstellbarem "Abstand" zum "ok"-Level auch gleich da reinschiebt...

Meinungen zum Ganzen?
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

#115
Beim intentNotRecognized wird ja etwas erkannt und ausgegeben. Von der NLU wird nur kein passender Intent gefunden.
"wie spät ist es jetzt" wird nicht erkannt, weil "jetzt" zuviel ist. Wird der Text mit den vorhandenen Intents verglichen, kann der enthaltene Intent "wie spät ist es" gefiltert werden und der Intent könnte nach einer Rückfrage über sessionContinue: "Meinst du - wie spät ist es?" per hermes/nlu/query (mit den aktuellen Session-Daten) an die Session zurückgegeben werden.
Wenn der Sprecher immer wieder "jetzt" dranhängt, könnte man "wie spät ist es jetzt" als Alias zu "wie spät ist es" abspeichern und künftig sofort zurückgeben.
Die Mehrsprachigkeit ist durch den Startparameter von Rhasspy gegeben.
Klar ist das hoch gegriffen. Du hattest "intentNotRecognized" zur Sprache gebracht - hier ist eine Idee dazu.  ;)

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

Zitat von: Gisbert am 08 Mai 2022, 20:39:31
"Tut mir leid, ich konnte kein passendes Gerät finden".
Update ist im "offene Themen"-Thread zu finden.

Falls Fragen zum Code an sich vorhanden sein sollten, bitte im allg. "Entwicklungs"-Thread posten, mit der Frage, wie denn sinnvollerweise die "Choice"-sentences zu bilden wären, können wir uns gerne hier kurz befassen (ich habe dazu noch keine "postbare" Idee).
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

Prof. Dr. Peter Henning

Zitatwie spät ist es jetzt
ist ein typisches Beispiel für einen Satz, der ohne Kontext nicht interpretierbar ist. Das kann man mit Amazon Alexa gut ausprobieren
"Alexa, wie spät ist es jetzt" ==> aktuelle Uhrzeit
"Alexa, wie früh ist es" ==> aktuelle Uhrzeit
"Alexa, wie spät ist es morgen" ==> Datum von morgen
"Alexa, wie früh ist es morgen" ==> "Das könnte Deine Frage beantworten..." dann Datum von morgen
"Alexa, wie früh ist es vorgestern" ==> "Das weiß ich leider nicht"
"Alexa, wie spät ist es jetzt in Timbuktu" ==> Datum und Uhrzeit in Timbuktu

Hier wird also offenbar zunächst fest substituiert "wie spät" ==> Ausgabe Zeit/Datum.
Dann aber ist ein Zeitpunkt und ein Ort festzustellen, und dafür gibt es default-Annahmen.

LG

pah

Beta-User

Zitat von: Beta-User am 10 Mai 2022, 09:52:52
(ich habe dazu noch keine "postbare" Idee).
da grade im Development-Thread die Frage auf Auswahl kam, hier nochmal der betreffende Auszug aus dem 0.5 - Offene Punkte-Thread:
Zitat von: Beta-User am 20 Mai 2022, 12:21:16
2. Choice
Sinnvollerweise sollte man den generischen "Choice"-Intent benutzen statt der alten gesplitteten:
[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...
Der Vollständigkeit halber - <de.fhem:SetOnOff.den> ist
den=(den|die|das)
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