[RHASSPY 0.5] - offene Themen

Begonnen von Beta-User, 23 Dezember 2021, 16:33:55

Vorheriges Thema - Nächstes Thema

Beta-User

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

Zitat von: Beta-User am 10 Mai 2022, 11:35:13
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...
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

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:

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

Beta-User

Zitat von: Beta-User am 16 Mai 2022, 14:47:18
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:
[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 ::) ...
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

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

drhirn

Zitat von: Beta-User am 17 Mai 2022, 19:24:36(mein "verstärker" ist nur im Wohnzimmer für "Szenen" zu haben...)

Warum ist der dann im scene-Slot?

Beta-User

Zitat von: drhirn am 17 Mai 2022, 21:06:02
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 ::) .
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

Beta-User

#22
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
Zitat von: Beta-User am 18 Mai 2022, 09:14:36
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:
[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:
[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 8) . Bin mal auf eure Rückmeldungen gespannt!
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

Beta-User

#23
Zitat von: Beta-User am 20 Mai 2022, 12:21:16
das heute abend/über das WE dann einzuchecken[...]
Ansonsten ist das Ding nunmehr ziemlichst rund 8) .
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 8) ...

[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:
( <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})


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

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

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

Beta-User

Long time no see...

gregorv hat in CustomIntent mit Dialog en paar Anstöße gegeben, die ich hier mal als weitere Punkte vermerke:

Zitat von: Beta-User am 17 Oktober 2024, 13:17:39Aber bevor wir darüber diskutieren, sollten wir m.E. mal definieren, wie wir vorgehen wollen. Mein Vorschlag:
- Das mit "resetInput" fertig machen und einchecken. Dazu müßte man m.E. die angehängten Dateien checken, ob das Zusammenspiel soweit paßt, dass bisherige User keine Probleme haben.
- Danach könnte man sich mit einem globalen (sentences-) Key für "führe den Dialog weiter" befassen. Ziel auch hier: Zwischenversion einchecken.
- Dann eventuell checken, ob man "specials" findet (Zwischenversion...)
- zuletzt wäre das mit myUtils dran.

[...]
Grundsätzlich fehlt mir grade v.a. die Zeit zum Testen, von daher werde ich mal im Hauptthread darauf hinweisen, dass wir hier am diskutieren sind. Vielleicht findet sich zumindest jemand, der testet, dass es mit diesen Zwischenversionen keine Probleme mit seiner bisherigen Funktionalität gibt?!?
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