Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Ist das FHEM auf der docker-Installation aktuell?

Die Funktion zum Setzen des NOTIFYDEV via devspec ist noch nicht besonders alt (setNotifyDev()), und wenn NotifyFn() aktiviert werden soll, muss dieser Command durchlaufen. Das Deaktivieren geht dagegen auch mit einer etwas älteren fhem.pl (notifyRegexpChanged () - die setzt dann auch das Internal auf 1). Wenn es das ist, ist nur komisch, dass das Modul überhaupt lädt... (OK, hab's grade testweise mit was anderem versucht - die Existenz einer zu importierenden Funktion wird nicht geprüft...) Aber schmiert FHEM dann nicht ab...? Sehr seltsam, das!

EDIT: siehe https://svn.fhem.de/trac/changeset/25541/trunk/fhem/fhem.pl und https://forum.fhem.de/index.php/topic,125381.0.html

[drhirn]

Verwende das Image fhem:dev. Und ein Update hab ich vor dem Test gemacht. Also alles aktuell.

Image fhem:latest macht - wie erwartet - keinen Unterschied

[Beta-User]

Hmm, bin grad etwas verloren. Das wäre - neben der Abwesenheit der Funktion - eigentlich nur nachvollziehbar, wenn

Code Auswählen Erweitern

{devspec2array('global')}
kein Ergebnis liefern würde...

Die relevanten Codezeilen sind ab #1581 zu finden, vielleicht unmittelbar vor der letzten Abfrage (#1594) mal eine Logausgabe einbauen, was bis dahin in $devsp steht?

[drhirn]

"disable_msgDialog" wird bei mir nicht ausgeführt

[Beta-User]

Aha, in der einen Installation gibt es anscheinend ein msgConfig, in der anderen nicht...

(Nicht eben übersichtlich, diese Indirektionen ...)

Kannst du mal am Ende von #1537 noch eine Abfrage einbauen?

Code Auswählen Erweitern

return 'No global configuration device defined: Please define a msgConfig device first' if !$modules{msgConfig}{defptr} && $attrVal;

[drhirn]

Kannst du mal am Ende von #1537 noch eine Abfrage einbauen?

Code Auswählen Erweitern

return 'No global configuration device defined: Please define a msgConfig device first' if !$modules{msgConfig}{defptr} && $attrVal;

Fieser Edit

Ja, jetzt funktioniert's.

[Beta-User]

Fieser Edit

Ups, da warst du aber schnell...

Ja, jetzt funktioniert's.

Habe diese Version jetzt wieder ins svn eingecheckt, weil jetzt auch fortgesetzte Dialoge über AMAD.* klappen. Jetzt könnte man sich dran machen, das Event auszuwerten, das nach Abschluss des speak commands erscheint, um dann das Mikro wieder anzuschalten:

Code Auswählen Erweitern

lastSetCommandState setCmd_done
Dazu muss das AMADDevice aber erst mal nach NOTIFYDEV... (ein andermal...)

[Beta-User]

Hatte hier jemand Pizza Quattro Stagioni bestellt?!?

Nun, meinen Vorschlag hast du ja. Ob du was draus machst, ist natürlich dir überlassen.

Ich hätte eine über, sehr frisch aus dem Ofen . Also Vorsicht: könnte sehr heiß sein, zu scharf, whatever...

Was bringt die?
Man kann (vorerst) dem Intent "SetOnOff" "fremde" bzw "zu viele" Datenfelder übergeben, also z.B.:

- Device 1 + Device 2 + Device(n)
-- zu übergebende Keys: {Device}, {Devicex}; (sicherheitshalber sollte man {Device} in diesen Fällen immer als erstes bzw. mindestens füllen);
-- für jedes {Devicex} muss halt der Schlüsselnamen mit "Device" beginnen, der Rest sollte beliebig sein;
-- Trockenübung mit {Device} und {Device1} hat funktioniert,

- Device 1 + Gruppe a
(noch nicht getestet, ad {Device} siehe oben),

- "Device mit Name xy" in Raum 1 + Raum 2
-- ad {Device} s.o., die Room-Keys sind dann wieder wie bei den Devices, also der erste am besten {Room}, der Rest {Roomx} mit "x" für irgendwas;
-- grob angetestet,

- "Device mit Name xy" + "Device mit Name YZ" in Raum a + Raum b
(noch nicht getestet, ad {Device}/{Room} siehe oben).

Das ganze ist generisch angelegt, im Prinzip sollte sich mit wenig Code-Änderung in den Einzelintents mehr oder weniger alles von Einzel- auf Gruppen-Intent umbiegen lassen, was heute da ist, und auch die Gruppen-Intents müßten sich relativ zwanglos aufbohren lassen .

Bestätigungen habe ich erst mal noch nicht dazugenommen, kann aber sein, dasss auch das bereits funktioniert. Prinzipiell wird erst mal alles gesammelt und geschaut, ob ein Device bzw. eine Gruppe dabei ist, die so oder so eine Bestätigung haben will, wenn ja, ist die für alles erforderlich (einmalig).
Dazu gibt es noch einen speziellen Gruppen-Namen "virtualGroup", unter dem man für sowas noch eine eigene Bestätigungsanforderung anfordern kann.
Intern findet ein Wechsel vom Einzel- zum Gruppen-Intent statt, was bedeutet, dass
- für eventuelle Bestätigungen auch ein eventuell gesetzter Tweak für allgemeine Gruppen-Schaltanweisungen beachtet wird, und
- ggf. "partOf"-Anweisungen für Gruppenschaltungen an den beteiligten Devices relevant werden (z.B. wenn man statt eines Geräts dann auf eine HUE-Gruppe oder FHEM-structure verwiesen hat)

Vermutlich haben jetzt alle viele Fragezeichen auf der Stirn? Dann erst mal ausprobieren, eventuelle Probleme melden und wegen der ggf. in der Beschreibung hier unklaren Details vorab mal rund um https://wiki.fhem.de/wiki/RHASSPY/Vertiefung#Gruppen-Intents nachlesen.

Falls es aus der Einleitung nicht klar geworden war: Nutzung auf eigenes Risiko!

PS: Da ist dann noch etwas weitgehend ungetesteer Code drin für
- Event-Handling betr. das Wiedereröffnen des Mikros@AMAD.* und
- das Thema "continous dialogues".
Kann sein, dass es insbesondere im Hinblick auf letzteren Punkt auch einige regressions gibt ...

[JensS]

Hatte hier jemand Pizza Quattro Stagioni bestellt?!?

Danke, hab sie gleich gegessen, obwohl sie noch heiß ist.
Licht im Wonhzimmer und im Flur an.  = läuft
Licht und Stehampe im Wohnzimmer an. = läuft
EDIT: Licht und Stehlampe an. = Licht im Schlafzimmer und Stehlampe im Wohnzimmer gehen an
Zu weiteren Tests komme ich später.

Gruß Jens

[Beta-User]

 
Kurz nachgedacht, und ja, das mit 2 Devices und keinem Raum ist eine Lücke, wenn die nicht beide in dem "Sprechraum" sind, muß mal schauen, wie man diesen "Sonderfall" abfangen kann.

Was mich (leider) mehr beschäftigt:
Eventuell gibt es ein größeres Problem, wenn man die messenger-Schnittstelle anspricht (wenn das das Problem ist, gilt das vermutlich identisch für AMAD.*). Bitte also im Moment diese Schnittstellen vorsichtshalber nicht benutzen!
Muss aber auch erst mal schauen, wo das Problem genau liegt, kann dauern...

EDIT: Aber das mit der raumlosen "Sammlung" scheint mit dem Anhang hier jetzt zumindest mal zu klappen...

[JensS]

Funktioniert noch nicht.

"Licht" ist jeweils die Deckenbeleuchtung in jedem Raum.

Bei "Licht an" - gesprochen im WZ, geht das Licht im WZ an.
Bei "Licht und Stehlampe" an - gesprochen im WZ, geht jetzt das Licht im Flur und die Stehleuchte im WZ an.
Bei "Licht und Stehlampe im Wohnzimmer an" - gehen Licht und Stehlampe im WZ an.

[Beta-User]

Funktioniert noch nicht.

Ok, irgendwie nachvollziehbar...

Die Fassung im Anhang sollte das geringfügig besser machen, komplett lösen läßt sich ein an der Stelle sichtbar werdendes Grundproblem allerdings nicht (s.u.).

Vorab aber die Info: Die messenger-Schnittstelle war in der Tat kaputt, das ist jetzt wieder auf einem (hoffentlich) funktionierenden Stand (testen kann ich den Teil aber voraussichtlich erst am WE), ob AMAD.* klappen, kann ich auch noch nicht sagen. Für den Teil ist jetzt eine Erweiterung der NotifyFn() drin, der "activateVoiceInput" ausführen sollte, wenn eine Sprachausgabe fertig ist und der Dialog fortgesetzt werden soll (wie erwähnt: ungetestet!).

Nun zum Grundproblem:

"Licht" ist jeweils die Deckenbeleuchtung in jedem Raum.

Wir lassen "relativ unpräzise" Anweisungen zu und versuchen daher, aus den ggf. sehr spärlichen Infos den (z.B. für eine Schalt-Anweisung erforderlichen) "Rest" zu ermitteln. Wenn sich dann ergibt, dass etwas nicht geht, stellt sich die Frage, was passieren soll. Ergibt sich aus dem Kontext des Intents ("SetOnOff") und des Sprach-Raums ("siteId") nichts eindeutiges, bekommt man eine Rückmeldung.

Wird die Eindeutigkeit durchbrochen (z.B. durch ein weiteres {Devicex}), stellt sich die Frage, was passieren soll, wenn nur ein Teil "aufgelöst" werden kann. Bisher läuft der Code kommentarlos durch und schaltet halt, was ermittelt werden konnte.

Besser (optimal?) wäre es, wenn man zusätzlich zu "erledigt" dann noch die Info bekommen würde, dass (und welche) Teile eben nicht zugeordnet werden konnten. Dann wird aber die Antwortlogik nochmal deutlich komplexer als bisher...
In Ansätzen sind Gedanken dazu da, (u.a.) daher auch noch eine kleine Erweiterung der de-cfg. Aber das so umzusetzen, dass es komplett (=in allen denkbaren Verästelungen!) funktioniert, dürfte was größeres werden.

EDIT: Licht und Stehlampe an. = Licht im Schlafzimmer und Stehlampe im Wohnzimmer gehen an

Falls das mit der Ausgangsversion so war, stellt sich die Frage nach dem Kontext. Die beigefügte Version dürfte de facto wieder dasselbe Ergebnis bringen, allerdings auf einem anderen Weg ermittelt, und es sollte identisch zu dem sein, was auch je eine einzelne Anweisung ergeben hätte.

Falls ich dazu noch was im Detail nachvollziehen soll, bräuchte ich etwas mehr Kontext. (Die Zwischenversion von gestern abend hatte die Rauminfo ganz gelöscht, und das war nun auch wieder des Guten zu viel...).

[Beta-User]

Nachträge noch:
- Mit einer (zusätzlichen) Gruppen-Angabe scheint es auch durchzulaufen.
- Das "Eindeutigkeits-Thema" hat auch (schon immer) eine Kehrseite: Wenn man einen Raum angibt, darin aber das explizit angefragte Gerät gar nicht vorhanden ist (aber sonst irgendwo), wird das Gerät "trotzdem" geschaltet. "Eigentlich" müßte der Code einen Unterschied machen, ob die Raum-Info "nur" aus dem "Sprach-Raum" abgeleitet ist, oder ob sie explizit angewiesen gewesen war. Spannend...

Um den letzten Punkt eventuell etwas zu verdeutlichen: "Mach die Nachtischlampe aus" gesprochen/erkannt im Wohnzimmer, ergibt vermutlich keine Irritationen, wenn dann im Schlafzimmer ein Schaltvorgang ausgelöst wird. Wird von der Spracherkennung aber "Mach die Nachtischlampe im Wohnzimmer aus" geliefert, impliziert das, dass der Sprecher entweder ein anderes Gerät oder einen anderen Raum meint - oder die Spracherkennung ggf. falsch war; eigentlich sollte man sowas dann "dialogisch" klären.

[Beta-User]

...das mit dem

"Mach die Nachtischlampe aus" [...] "Mach die Nachtischlampe im Wohnzimmer aus"

hat mir keine Ruhe gelassen...

Also Code angeschaut, und siehe da: Wenn man keinen Match im Room hatte, kam danach ein "for (keys ...)" gefolgt von einem "wenn 'das' paßt, gib 'das' zurück". Jetzt muss man dazu wissen, dass ein solcher Zugriff zu zufälligen Ergebnissen (!) führt! (Jedenfalls dann, wenn es nicht aus anderen Gründen eindeutig ist - wer CUL_HM nutzt und Anfang letzten Jahres ein update gemacht hatte, kann vielleicht nachvollziehen, was das in etwa bedeutet).
Wie dem auch sei - es kam der "Autsch, das geht ja mal gar nicht"-Impuls...

Ergebnis anbei, wie "üblich" in großen Teilen ungetestet...

News da drin:
- die zentrale Funktion zur {Device}=>FHEM-Name-Findung akzeptiert ein paar weitere Argumente, mit denen sich insbesondere feststellen läßt, ob es ein "abgeleiteter" Raumname ist, oder ob der schon in den Ausgangsdaten drin war;
- wenn ja: match im Room ist zwingend! (=> Änderung im Verhalten!)
- wenn nein:
-- ein "sort"-Pflaster für den Zugriff auf die Raum-"keys" (=> gesteuerterer Zufall);
-- Beachtung von "priority outsideRoom" (kann sein, dass das nicht funktioniert) => erster match = Ergebnis;
-- Sammlung aller passend benannter Devices
=> genau eines? => Ergebnis;
=> keins oder mehr als eines? => kein Ergebnis. (=> Änderung im Verhalten!)

Ansonsten ist noch "überall" der Wechsel von Einzel- (bzw. Mehrfach-Gruppe oder -Raum) zu Gruppen-Intent reingeknödelt (also überall da, wo es einen Intent mit "Group" am Ende gibt).

Mal sehen, was ihr dazu meint...

EDIT: kleines update, das ggf. noch "false dupes" aussortiert, wenn ein und dasselbe Device in mehreren Räumen zu finden ist...

[JensS]

Wow, ich bin begeistert!

Alles Folgende ist im Wohnzimmer gesprochen.
Licht im Wonhzimmer und im Flur an.  = läuft
Licht und Stehampe im Wohnzimmer an. = läuft
Licht und Stehlampe an. = läuft
Nachttischlampe und Licht an. = läuft (Nachttischlampe im SZ un Licht im WZ)
Flurlicht und Nachttischlampe an. = läuft
Licht und Nachttischlampe im Flur an. = läuft (Licht im Flur und Nachttischlampe im SZ)
u.v.m....

Gruß Jens