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

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

Vorheriges Thema - Nächstes Thema

drhirn

#60
Abgesehen davon, dass die Sentences nicht korrekt sind.

Der zweite Satz in [de.fhem:SetNumeric] ist ein MediaControls-Sentence.

Das mit dem Raum würde ich sicherheitshalber lieber so notieren:
[(im|in|in dem|auf dem|in der|auf der)] [$de.fhem.Room{Room}]

Beta-User

Zu dem Hinweis bzgl. stop: Das klappt (seit neuestem), wenn der blind das kann ;) . Stellt dann sogar bei Jalousien die Lamellen wieder auf den alten Stand, wenn man das entsprechend konfiguriert...

Deswegen schreibe ich ja, dass es sinnvoll ist, die eingeschränkten slots zu verwenden ;) . Sonst ist Verwirrung vorprogramiert....
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

Asche auf mein Haupt - ich hab mich schlicht bei rhasspyName und rhasspyRoom bei 2 von 5 Fhem-Devices verhauen - für mich ein leichter Gehirnverzwirner, da ich es immer anders gehandhabt habe. Kein Wunder, dass es dann wild durcheinander ging. Es macht aber Sinn den rhasspyName "rollladen" zu benennen und den rhasspyRoom "schlafzimmer,..." (in meinem Beispiel) zu benennen; das ist es ja auch das, was die Attributsnamen implizieren.

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

Gisbert

Guten Morgen Jörg,

man muss sich ja immer etwas sammeln, bevor man einen Sprachbefehl abschickt. Wenn nicht, dann beendet Rhasspy bei Unterbrechungen die Aufnahme. Soweit so gut.

Mir ist beim Ausprobieren dann aufgefallen, dass Rhasspy Informationen ergänzt, die gar nicht beabsichtigt waren.

In sentences.ini hab ich die Angabe eines Raumes zwingend erforderlich gemacht, da ein Sprachbefehl wie
Zitatfahre den Rollladen hoch
auf alle Rollläden zutriffen könnte, allerdings möchte ich nicht alle öffnen.

sentences.ini (Auszug):
[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)] $de.fhem.Room{Room} ((an|ein|hoch|auf){Value:on}|(aus|zu|runter){Value:off})


In de.fhem.Room steht:
schlafzimmer gisbert
schlafzimmer von felix
wohnzimmer
schlafzimmer felix
zimmer von felix
zimmer felix
network
schlafzimmer von gisbert
heizung
meinem schlafzimmer
schlafzimmer

Warum steht network und heizung drin? Ich hab es nirgends definiert. Es gibt aber in beiden Räumen Devices, die im Namen oder alias die Worte Schlafzimmer, Gisbert oder Felix enthalten. Oder könnten es Geräte mit on/off-Charakter sein, die Rhasspy veranlasst diese Räume aufzunehmen?

Wenn ich jetzt folgenden Satz spreche:
Zitatfahre den Rollladen hoch
gibt Rhasspy folgendes zurück:
Zitatfahre den Rollladen heizung hoch
Tatsächlich fährt er meinen Rollladen hoch.

Wie kann ich verhindern, dass Rhasspy Informationen ergänzt, die gar nicht beabsichtigt sind? Lieber wäre mir keine Aktion und die Aufforderung Informationen zu ergänzen.

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

Gisbert

Ergänzung:
Der gesprochene Befehl:
Zitatfahre den Rollladen im Arbeitszimmer hoch
wird zu:
Zitatfahre den Rollladen im Schlafzimmer hoch
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

drhirn

Dein Satz in der sentences.ini erwartet einen Raum. Wird der nicht gesprochen, nimmt Rhasspy irgendeinen aus dem Slot. Wie genau die Auswahl erfolgt, hab ich auch noch nicht rausgefunden.
Um dein gewünschtes Ziel zu erreichen und alle Rollläden hochfahren zu können, müsstest du alle in eine Gruppe stellen und dafür den Intent SetOnOffGroup verwenden. Und natürlich "alle Rollläden" sprechen.

"network" und "heizung" werden schon irgendwo vorkommen. Ich vermute, als FHEM-Attribut "room".

"Arbeitszimmer" ist in dem Slot, den du gepostet hast, nicht enthalten. Deswegen nimmt Rhasspy einfach das, was am ähnlichsten klingt.

Beta-User

OK, vielleicht an der Stelle auch nochmal der Hinweis auf https://wiki.fhem.de/wiki/RHASSPY/Vertiefung, speziell (seit grade) https://wiki.fhem.de/wiki/RHASSPY/Vertiefung#.22must_match.22-Prinzip.

Ergo: Bitte mache den Raum wie bereits mehrfach empfohlen OPTIONAL! Solche ständigen Hinweise haben in der Regel einen Grund, auch wenn es in der Masse der Stellrädchen nicht immer gleich verständlich sein mag, warum etwas empfohlen wird, was einem zunächst unlogisch vorkommt...

Prüfe dann deine Annahme, ob "alle Rollläden" gefahren werden, wenn du eine raumlose Ansage machst ;) . (Und nein, wir werden zur Lösung dieses Themas erst später kommen!)

Danach wäre mein Tipp, dir https://wiki.fhem.de/wiki/RHASSPY#Beispiel:_Raumwechsel anzusehen.

Zu guter Letzt: Wenn dir irgendwelche übertragenen Bestandteile in den slots seltsam vorkommen, bist du praktisch immer gut beraten, ein rhasspy-list nach dem betreffenden Bestandteil zu durchsuchen. Es gibt eher selten Ausnahmen zu diesem Grundprinzip.
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,

vielen Dank für die prompte Antwort. Ich werde mir alle Dokumente anschauen und die Vorschläge umsetzen.

Die Räume hatte ich schon optional definiert. Als das geschilderte Verhalten auftrat, dachte ich, dass es mit zwingend erforderlichen Räumen nicht auftritt. Ich werde die Räume wieder optional angeben.

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

Gisbert

Zitat"network" und "heizung" werden schon irgendwo vorkommen. ...
"Arbeitszimmer" ist in dem Slot, den du gepostet hast, nicht enthalten. Deswegen nimmt Rhasspy einfach das, was am ähnlichsten klingt.

Die Sache mit den Räumen "network" und "heizung" hat sich geklärt. Ich hatte in beiden Fhem-Räumen ein dummy-Device mit einem Attribut gDT versehen - wohl zum Üben bei den ersten Gehversuchen (ich Optimist, denn jetzt sind es immer noch Gehversuche).

Was mich allerdings nachdenklich stimmt ist, dass Rhasspy gnadenlos nach einer Lösung sucht.
Der gesprochene Satz: "fahre den rollladen im Klo hoch" wird zu "fahre den Rollladen in meinem Schlafzimmer hoch" - da sehe ich sprachlich zwischen "Klo" und "meinem Schlafzimmer" einen großen Unterschied. Ich würde etwas mehr Verbindlichkeit erwarten und im Zweifelsfall bei unklarer Aussprache oder Versprechern eher ein "Bitte wiederhole ..." als irgendeinen Befehl. Gibt es denn keine Möglichkeit, dass bei unklarer Lage lieber nichts gemacht wird?

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 07 Dezember 2021, 21:23:30
Was mich allerdings nachdenklich stimmt ist, dass Rhasspy gnadenlos nach einer Lösung sucht.
Dieses "must match"-Prinzip hat mir eine ganze Zeitlang auch Kopfzerbrechen bereitet...

Aus diesem Kopfzerbrechen sind zwei Dinge entstanden (Rhasspy hatte eine Vorliebe für meinen Verstärkter, und ich fand es nicht so lustig, dass das das "Lieblingszielgerät" von Rhasspy war :o ):
- zum einen die Option, bestimmte Geräte (oder Aktionen) nur nach Bestätigung auszuführen. Aus heutiger Sicht zwar ein wichtiger Schritt in Richtung von Dialogen, aber an sich ein workaround, dessen Anwendung ich zwischenzeitlich stark begrenzt habe.
- zum anderen die vielen slots. MAn. ist deren "korrekte" Verwendung der richtige Weg, um für hinreichend gute Ergebnisse zu sorgen. Setzt voraus, dass man prinzipiell sinnvolle Anweisungen spricht. "Mach den Rollladen im Klo zu" wird immer ein Problem bleiben, wenn es einen solchen dort nicht gibt...

Zitat
Der gesprochene Satz: "fahre den rollladen im Klo hoch" wird zu "fahre den Rollladen in meinem Schlafzimmer hoch" - da sehe ich sprachlich zwischen "Klo" und "meinem Schlafzimmer" einen großen Unterschied.
Na ja, wenn du unbedingt einen Room sprechen mußt, ist Rhasspy "gezwungen", einen auszuwählen... Wobei jetzt nicht ganz klar ist, ob Rhasspy noch das "Klo" sauber übergeben hatte, und die Abweichung zur Erwartung woanders (in RHASSPY) passiert ist (a), oder ob das schon ein "Problem" in der STT-Engine war (b). Wie dem auch sei, im nächsten update werden dann auch nochmal mehr Room-slots erzeugt werden, so dass man insbesondere auch für "blind"-Geräte dann auch eine eingeschränkte Raumliste verwenden kann...
Das führt aber im Zweifel dazu, dass aus "Klo" wirklich "Wohnzimmer" wird, weil "Klo" kein zulässiger Wert ist (entsprechend der Logik aus (b) iVm dem "must-match"-Prinzip).

Zitat
Ich würde etwas mehr Verbindlichkeit erwarten und im Zweifelsfall bei unklarer Aussprache oder Versprechern eher ein "Bitte wiederhole ..." als irgendeinen Befehl. Gibt es denn keine Möglichkeit, dass bei unklarer Lage lieber nichts gemacht wird?
Das Grundproblem ist, dass zumindest die per default verwendete STT-engine immer behauptet, das Ergebnis wäre klar. Ergo muss RHASSPY erst mal davon ausgehen, diese Behauptung wäre zutreffend (deshalb wird es bisher auch nicht geprüft).
Unterstellt, (a) wäre das "Problem":
- An sich schaut RHASSPY immer zuerst, ob die Aktion im gewünschten Raum klappt (und eindeutig ist). Geht das, wird genau das gemacht.
- Geht es nicht im Raum, wird geschaut, ob es nur genau eine Option gibt, das außerhalb des gewünschten Raumes zu machen. Wenn ja, wird geschaltet.
- Wenn auch das nicht eindeutig* ist (oder es mehrere Optionen im Wunsch-Raum gibt), erfolgt eine Rückfrage, und man kann den Raum bzw. das  Gerät auswählen.

Falls also (a) das Problem gewesen war, unterstelle ich, dass es schlicht keinen zweiten Rollladen gegeben hat?

* Man kann für mehr Eindeutigkeit sorgen, indem man bestimmte Geräte als "vorzugswürdig" kennzeichnet...

Hoffe, das hilft irgendwie 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

Gisbert

Hallo Jörg,

hab nicht alles im Detail verstanden.
Was ich aber mitnehme ist, dass Rhasspy präzise Anweisungen verlangt, d.h. man muss sich beim Sprachbefehl konzentrieren und nicht einfach drauf los plappern.

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

Weiß nicht, das war eigentlich eher nicht die Botschaft. Natürlich ist es wichtig, so zu sprechen, dass das zu dem paßt, was über sentences.ini abgebildet ist, aber in etwa genauso wichtig ist es, dass das, was sich als mögliche Sätze aus diesem "Verzweigungs-Muster" in den sentences.ini ergibt auch ausführbar ist. Deutlich sprechen mag auch helfen...
Neben gut strukturierten Sätzen ist es essentiell, dass die slots "sauber" sind, vielleicht solltest du da erst mal mit weniger Optionen für Räume arbeiten.

Hast du jetzt eine siteId2room-Logik für deinen mobilen Satelliten eingerichtet?

Nach meinem Eindruck wird das ganze nämlich schnell besser, wenn man zum einen nicht immer den Raum ansagen muss, und zum anderen mehr (verschiedene) Geräte da sind, die gesteuert werden können.
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,

ZitatHast du jetzt eine siteId2room-Logik für deinen mobilen Satelliten eingerichtet?
Das habe ich nicht. Ich plane nur mit meinem Handy (das sauteuere Teil, was mit meiner linken Hand verwachsen ist ;D) als Spracheingabegerät.
Wenn ich die Limits kenne, kann ich mich ja darauf einstellen. Vermögende Leute haben Hauspersonal, die die Bitten der Herrschaften ausführen, unser einer macht es mit Technik wett.

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

Gisbert, das war ein weiterer Zaunpfahl!

Ich nutze auch mehr oder weniger ausschließlich die Gedächtnisprothese, und habe mir was zum Thema überlegt, dass das Ding mal im Wohnzimmer, mal im Esszimmer oder im Büro ist...

Just do it!
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

ZitatWas ich aber mitnehme ist, dass Rhasspy präzise Anweisungen verlangt,
Darum gibt es Babble, mit den angeschlossenen Chatbot kann ich gut diskutieren.

ZitatVermögende Leute haben Hauspersonal, die die Bitten der Herrschaften ausführen, unser einer macht es mit Technik wett.
Vermögende Leute mit Intelligenz nutzen technisches Hauspersonal, wie eine KI.

LG

pah