Modulentwicklung für Rhasspy Sprachassistent

[drhirn]

In deinem RHASSPY-Device gibt's nur die siteId "kueche". Mach mal ein set xxxx fetchSiteIds. Und gerade auch noch ein set xxx update all zur Sicherheit.

[Ziton]

Hat keine Veränderung gebracht
Ich vermute das über den Befehl nur siteid's von Satellites übertragen werden?!

[drhirn]

Das stimmt natürlich. Und das ist irgendwie nicht schlau. Bei mir ist die Base ohne Audiogeräte und rechnet nur. Deswegen hab ich nie daran gedacht, dass die Base vielleicht auch Befehle entgegen nimmt.

Funktionieren Geräte in der "kueche"?

[Ziton]

Geräte in der Küche funktionieren gleichermaßen alle bisher eingerichteten Befehle mit Ausnahme von SetOnOff

Das heißt in beiden Räumen funktionieren derzeit Befehle für:
GetOnOff
SetNumeric
MediaChannels
GetTime
GetWeekDay
SetTimer
SetMute
ReSpeak

Der Problem ist irgendwie schwer auszumachen. Wie gesagt es scheint als würde er beim Unterprogramm "sub handleIntentSetOnOff" aussteigen weil kein Value vorhanden ist. Aber ich verstehe nicht warum bzw. wo er den Wert verliert.

Nun ja jetzt geht es erstmal ein bisschen in die Sonne. Ich danke dir sehr für deine Unterstützung.

[drhirn]

Die beiden Logzeilen Device = ... und Value = ... habe ich eingefügt um mich dem Problem zu nähern. Anscheinend ist kein Wert enthalten. Da steigt mein Verständnis jetzt aber leider aus. Weiter oben steht "Parsed value: on for key: value"

Hab's! Du hast "{value}" in deinen Sentences klein geschrieben, kann das sein? Da muss ein großes "V" hin ({Value})

[Beta-User]

Hab's! Du hast "{value}" in deinen Sentences klein geschrieben, kann das sein? Da muss ein großes "V" hin ({Value})

Jedenfalls war auch in dem JSON-Blob nur ein kleines "value" enthalten, und damit funktioniert es nicht. (Das hat höchstens mal mit einer sehr alten Fassung funktioniert.

(ad Doku: Weiß nicht, ob wir irgendwo stehen haben, wie die Formate im einzelnen "üblicherweise" sind => JSON-Keywords beginnen alle mit Großbuchstaben?)

Wie kommt RHASSPY drauf, dass das gültige Szenen sind?

Nun ja, es gibt in dem Device einen entsprechenden scene-Setter...

Im Anhang eine Fassung, die daraus "sprechbare" Scenen-Namen macht und das dann auch ohne händische Eingriffe (wäre via "specials" zu korrigieren gewesen) so an Rhasspy übergibt, dass es zumindest keine Fehler werfen sollte.

Habe jetzt mal zum einen cref zu diesem "special" erweitert und die Option eingebaut, einfach alle Szenen an einem "szenen-fähigen" Device zu deaktivieren, indem man da "all=none" setzt.


In der angehängten Fassung könnte dann auch mein Problem mit der "Leerzeichengruppe" gelöst sein (ich vermute, es war weniger das Leerzeichen, und eher der Umstand, dass das die letzte Gruppe in den verfügbaren Gruppen war => erweiterte Regex sollte das lösen, ist ungetestet)

Hmm. Ist jetzt nur so ein Bauchgefühl, aber ich tät's getrennt lassen. Wobei das mit dem Tweak schon was hätte. Aber ich tendiere eher dazu, eine Rückmeldung zu bekommen, wenn es ein Gerät nicht gibt. Bevor RHASSPY einfach irgendwas schaltet.

Na ja, beide sentences unterscheiden sich nur in Nuancen, und die Frage ist eher, ob man "versehentliches Heranziehen" des falschen Intents durch Rhasspy damit überspielen möchte. Es passiert ja trotzdem nicht "irgendwas", sondern (hoffentlich) das, was der Sprecher eigentlich erreichen möchte (in der Regel weiß er ja gar nicht (mehr), ob er jetzt ein Einzeldevice schaltet oder eine Gruppe - oder anders formuliert: idealerweise muss er sich das nicht merken ).

Zum "User"-Bereich in der Sprachdatei: Ist der wirklich brauchbar? Ich mein, bei einem Update muss ich sowieso editieren. Da kann ich doch gleich auch meine "alten" Sätze wieder rein bauen. Einfacher ist's zwar. Aber angreifen muss ich's sowieso. Wär's da nicht praktischer, wir liefern eine Standard-Datei, binden aber auch zusätzlich Dateien ein, die ähnlich heißen (rhasspy-de-user.cfg z.B.)?

Was bedeutet "brauchbar"?
Falls "funktional": ja
Falls "die beste Lösung": Weiß nicht, aber wenn man es aus framework-Gesichtspunkten heraus beurteilt vermutlich schon. configDB kann beim Konvertieren afaik nur genau eine configfile übernehmen...
Anders gewendet: Ich fürchte mehr User-Fehler, wenn wir das auf mehr Konfigurationsmöglichkeiten verteilen, und halte das mit den verschiedenen Bereichen daher auch aus diesem Grund für (im Ergebnis) einfacher.

Ist es möglich für ausgewählte Intents eine Bestätigung einzufordern? Gelegentlich aktiviert sich Rhasspy selbst und erkennt einen Sprachbefehl obwohl nahezu stille im Raum herrscht.
Oft nicht weiter schlimm aber bei dem ein oder anderen Schaltbefehl wäre es mir lieber wenn rhasspy vorher nochmal nachfragt.

Generelle Bestätigungsmöglichkeiten sind derzeit noch nicht implementiert, das Interesse war bisher nicht übermäßig groß. (bei shortcuts geht das aber!)
Sowas (vollends) zu implementieren dürfte nicht allzu schwierig sein, ist aber Aufwand, auch beim Testen. Falls größeres Interesse besteht, würde ich das mal auf die Agenda nehmen... (Mein persönliches Problem, das mit in diese Richtung geschubst hatte, ist jetzt eher dadurch gelöst, dass mehr Slots zur Verfügung stehen, so dass Rhasspy "treffsicherer" ist).

Gibt es eine Empfehlung welchen Weg man beschreiten sollte wenn ich Rhasspy in mehreren Räumen einsetzen möchte?
Ich tendiere zur Zeit eher dazu Satellites aufzusetzen. Dann hat man die Sprachkonfiguration an einer Stelle. Derzeit gibt es aber, soweit ich es durchblicke, keine Möglichkeit einen "room <-> siteID" Mapping vorzunehmen oder? Ist so etwas ggf. noch in Planung?

Bevorzugte Lösung wäre der Vorschlag von drhirn hier, und es wäre klasse, wenn jemand, der das mit der Gruppenoption nutzt Rückmeldung geben könnte, dass es funktioniert wie gedacht:

Doch, gibt's. Du musst die Satelliten in deren Web-GUI nur so benennen, wie der Raum heißt, in dem deine Geräte sind. Also so, wie das FHEM-room oder FHEM-rhasspyRoom Attribut heißt. Meine Satelliten heißen z.B. "wohnzimmer", "küche" und "vorraum".

Willst du mehrere Satelliten im selben Raum haben kannst du die z.B. so benennen: "wohnzimmer.sofa", "wohnzimmer.esstisch", etc. Das ist eine Option von Rhasspy, das Modul sollte damit umgehen können. Ich hab das aber noch nicht getestet.

Es gibt aber noch eine weitere Variante: Über ein spezielles Reading, Details finden sich (hoffentlich) in der cref der myUtils-Funktion für "fliegende Satelliten", das feature kann man aber auch ohne den myUtils-Code nutzen.

[Ziton]

Hab's! Du hast "{value}" in deinen Sentences klein geschrieben, kann das sein? Da muss ein großes "V" hin ({Value})

Kleiner Fehler großer Wirkung!
Ich bedanke mich fürs finden und entschuldige mich für die Umstände. Ich kann zumindest versichern, dass der Fehler bei mir nicht mehr vorkommen wird 

Generelle Bestätigungsmöglichkeiten sind derzeit noch nicht implementiert, das Interesse war bisher nicht übermäßig groß. (bei shortcuts geht das aber!)
Sowas (vollends) zu implementieren dürfte nicht allzu schwierig sein, ist aber Aufwand, auch beim Testen. Falls größeres Interesse besteht, würde ich das mal auf die Agenda nehmen... (Mein persönliches Problem, das mit in diese Richtung geschubst hatte, ist jetzt eher dadurch gelöst, dass mehr Slots zur Verfügung stehen, so dass Rhasspy "treffsicherer" ist).

Habe gesehen das mit der letzten Version mehr Slots erzeugt werden. Ich werde daraufhin meine Sentences auch nochmal untersuchen und ggf. anpassen. (natürlich immer mit {Value} )

Bevorzugte Lösung wäre der Vorschlag von drhirn hier, und es wäre klasse, wenn jemand, der das mit der Gruppenoption nutzt Rückmeldung geben könnte, dass es funktioniert wie gedacht

Habe es so umgesetzt wie von drhirn vorgeschlagen. Gruppen Funktionen habe ich noch nicht in Gebrauch. Vielleicht schaffe ich es sie diese Woche mal auszuprobieren.

Zum Abschluss noch eine Frage zur Sprachdatei. Wo muss ich die Übersetzung für $weekDay hinpacken? Die werden nämlich derzeit noch auf Englisch mit deutscher Aussprache ausgegeben

[Beta-User]

Kleiner Fehler großer Wirkung!
Ich bedanke mich fürs finden und entschuldige mich für die Umstände. Ich kann zumindest versichern, dass der Fehler bei mir nicht mehr vorkommen wird 

Nevermind; wir alle stolpern hin und wieder über solche "Kleinigkeiten"... (ich zumindest)

Habe gesehen das mit der letzten Version mehr Slots erzeugt werden. Ich werde daraufhin meine Sentences auch nochmal untersuchen und ggf. anpassen. (natürlich immer mit {Value} )

Bin mal gespannt, wie sich das bei dir auswirkt. (Ich verwende bisher kein wakeup-word, aber deine Probleme scheinen _auch_ typisch zu sein, wenn das zu viele false positives bringt => sensitivity anpassen)

Zum Abschluss noch eine Frage zur Sprachdatei. Wo muss ich die Übersetzung für $weekDay hinpacken? Die werden nämlich derzeit noch auf Englisch mit deutscher Aussprache ausgegeben

Ausgegeben wird, was das hier liefert:

Code Auswählen Erweitern

strftime( '%A', localtime );
Bin nicht sicher, nach welchen Kriterien das arbeitet, aber an irgendeiner Stelle ist dein FHEM nicht "deutsch".

@drhirn:
Das ist trotzdem ein Problem, weil eben grade nicht international... (=> Problem auf mehrsprachigen Systemen). Habe allerdings auch grade keine Idee, wie man das besser machen könnte... Müßte man ggf. auch bei Gelegenheit mal auf $wday anpassen....

[drhirn]

Zum Abschluss noch eine Frage zur Sprachdatei. Wo muss ich die Übersetzung für $weekDay hinpacken? Die werden nämlich derzeit noch auf Englisch mit deutscher Aussprache ausgegeben

weekDay hat nichts mit der Sprachdatei zu tun. Der nimmt die Spracheinstellung des Systems (OS, Perl). Ist nicht ganz optimal gelöst. War damals von mir aber auch nur ein Test-Intent, der irgendwie geblieben ist .
Ich wollte gerade testen, was genau du umstellen musst. Ich kann's dir leider nicht sagen, bei mir ist und bleibt die Ausgabe deutsch (beim FHEM-Docker-Image).

[drhirn]

Nevermind; wir alle stolpern hin und wieder über solche "Kleinigkeiten"... (ich zumindest)

Ich auch

@drhirn:
Das ist trotzdem ein Problem, weil eben grade nicht international... (=> Problem auf mehrsprachigen Systemen). Habe allerdings auch grade keine Idee, wie man das besser machen könnte... Müßte man ggf. auch bei Gelegenheit mal auf $wday anpassen....

Wie eben geschrieben, ist nicht optimal. Aber es war eh der Wunsch, da ein ganzes Datum als Ausgabe zu bekommen. Wäre auch sinnvoller. Sollte ich dazu kommen, baue ich das dann gleich richtig ein und um.

[Raemsna]

Weil ich grad bei den Rhasspy Threads interessiert mitlese und Wochentag o.Ä. gelesen habe.

Bin auch so bisschen am Überlegen, wie ich mir Termine in meine Kalender per Spracheingabe legen kann.
Bin da gestern über folgendes gestolpert (kennt ihr wahrscheinlich schon):

https://snips-nlu.readthedocs.io/en/latest/builtin_entities.html

https://rhasspy.readthedocs.io/en/latest/intent-recognition/#snips-nlu

Das sollte auch in Rhasspy genutzt werden können und vereinfacht vielleicht viele Themen (auch wenn es aktuell nicht alles auch auf Deutsch gibt):

Code Auswählen Erweitern

AmountOfMoney snips/amountOfMoney Grammar Entity de, en, es, fr, it, ja, ko, pt_br, pt_pt
Duration snips/duration Grammar Entity de, en, es, fr, it, ja, ko, pt_br, pt_pt
Number snips/number Grammar Entity de, en, es, fr, it, ja, ko, pt_br, pt_pt
Ordinal snips/ordinal Grammar Entity de, en, es, fr, it, ja, ko, pt_br, pt_pt
Temperature snips/temperature Grammar Entity de, en, es, fr, it, ja, ko, pt_br, pt_pt
Datetime snips/datetime Grammar Entity de, en, es, fr, it, ja, ko, pt_br, pt_pt
Date snips/date Grammar Entity en
Time snips/time Grammar Entity en
DatePeriod snips/datePeriod Grammar Entity en
TimePeriod snips/timePeriod Grammar Entity en
Percentage snips/percentage Grammar Entity de, en, es, fr, it, ja, pt_br, pt_pt
MusicAlbum snips/musicAlbum Gazetteer Entity de, en, es, fr, it, ja, pt_br, pt_pt
MusicArtist snips/musicArtist Gazetteer Entity de, en, es, fr, it, ja, pt_br, pt_pt
MusicTrack snips/musicTrack Gazetteer Entity de, en, es, fr, it, ja, pt_br, pt_pt
City snips/city Gazetteer Entity de, en, es, fr, it, ja, pt_br, pt_pt
Country snips/country Gazetteer Entity de, en, es, fr, it, ja, pt_br, pt_pt
Region snips/region Gazetteer Entity de, en, es, fr, it, ja, pt_br, pt_pt

[Beta-User]

Habe mir das mit den Wochentagen mal angesehen, und jetzt erst mal eine etwas andere Lösung eingebaut:

"localtime" wird weiter genutzt, aber wer es braucht, kann einen speziellen Bereich "words" in "user" nutzen, um das Ergebnis umzumappen, das das liefert:

Code Auswählen Erweitern

"user":
{
  "responses": {
    "DefaultConfirmation": "Gerne!",
    "DefaultError": "Da paßt irgend was nicht"
  },
  "words": {
    "Monday": "Montag",
    "Tuesday": "Dienstag",
    "Wednesday": "Mittwoch",
    "Thursday": "Montag",
    "Friday": "Freitag",
    "Saturday": "Samstag",
    "Sunday": "Sonntag"
  }
},
An sich sollte das sowohl hinreichend sein für User, die mehrere Sprachen parallel brauchen, wie auch für die, die - aus welchen Gründen auch immer - das System auf en lassen wollen, aber de-Ausgaben haben möchten.

(Wiederfinden wird Freude machen...)

(Ob man Rhasspy auch bei der Ausgabe bewegen kann, bestimmte Dinge zu übersetzen, wäre auch so eine Frage, mit der ich mich bisher nicht beschäftigt hatte...).

[drhirn]

Dann gleich so, da ist dann das ganze Datum dabei

Code Auswählen Erweitern


# Handle incoming "GetWeekday" intents
sub handleIntentGetWeekday {
    my $hash = shift // return;
    my $data = shift // return;

    Log3($hash->{NAME}, 5, "handleIntentGetWeekday called");

    my $weekDay  = strftime( '%A', localtime );
    $weekDay  = $hash->{helper}{lng}{words}->{$weekDay} if defined $hash->{helper}{lng}{words}->{$weekDay};
    my $month = strftime( '%B', localtime );
    $month  = $hash->{helper}{lng}{words}->{$month} if defined $hash->{helper}{lng}{words}->{$month};
    my $year = strftime( '%G', localtime );
    my $day = strftime( '%e', localtime );
    my $response = $hash->{helper}{lng}->{responses}->{weekdayRequest};
    $response =~ s{(\$\w+)}{$1}eegx;

    Log3($hash->{NAME}, 5, "Response: $response");

    # Send voice reponse
    return respond ($hash, $data->{requestType}, $data->{sessionId}, $data->{siteId}, $response);
}


Neue Version von 10_RHASSPY.pm und rhasspy-de.cfg ist im dev-Branch auf GitHub.

[drhirn]

Nun ja, es gibt in dem Device einen entsprechenden scene-Setter...

Im Anhang eine Fassung, die daraus "sprechbare" Scenen-Namen macht und das dann auch ohne händische Eingriffe (wäre via "specials" zu korrigieren gewesen) so an Rhasspy übergibt, dass es zumindest keine Fehler werfen sollte.

Habe jetzt mal zum einen cref zu diesem "special" erweitert und die Option eingebaut, einfach alle Szenen an einem "szenen-fähigen" Device zu deaktivieren, indem man da "all=none" setzt.

Also, "all=none" tut. Die Szenen-Namen kommen leider noch immer falsch an.

Code Auswählen Erweitern


( Frühlingsblüten ){Scene:Frühlingsblüten#[id=wZdk5cpy35oldlw]}


Woher kommt der Scene-Setter bei dem Device?

Code Auswählen Erweitern


Internals:
   DEF        6  IODev=hueBridge2
   FUUID      60250efd-f33f-dc90-065c-6bf31c51dc378fac
   FVERSION   31_HUEDevice.pm:0.239120/2021-03-08
   ID         6
   INTERVAL   
   IODev      hueBridge2
   NAME       HUEDevice6
   NR         325
   STATE      off
   TYPE       HUEDevice
   desired    0
   manufacturername dresden elektronik
   modelid    FLS-H3
   name       Color temperature light 1
   swversion  020C.20000053
   type       Color temperature light
   uniqueid   00:21:2e:ff:ff:00:5a:3e-0a
   READINGS:
     2021-05-28 11:16:00   IODev           hueBridge2
     2021-05-28 11:16:06   alert           select
     2021-05-28 11:16:06   bri             254
     2021-05-28 11:16:06   colormode       ct
     2021-05-28 11:16:06   ct              500 (2000K)
     2021-05-30 23:18:23   onoff           0
     2021-05-30 23:18:23   pct             0
     2021-05-28 11:16:06   reachable       1
     2021-05-28 11:16:06   rgb             ffb16e
     2021-05-30 23:18:23   state           off
   helper:
     alert      select
     battery    -1
     bri        254
     colormode  ct
     ct         500
     devtype   
     effect     
     hue        -1
     lastseen   
     mode       
     on         0
     pct        0
     reachable  1
     rgb        ffb16e
     sat        -1
     update_timeout 1
     xy         
     json:
       manufacturername dresden elektronik
       modelid    FLS-H3
       name       Color temperature light 1
       productname Color temperature light
       swversion  020C.20000053
       type       Color temperature light
       uniqueid   00:21:2e:ff:ff:00:5a:3e-0a
       capabilities:
         control:
           ct:
             max        500
             min        153
         streaming:
       config:
         archetype  classicbulb
         direction  omnidirectional
         function   functional
       state:
         alert      select
         bri        254
         colormode  ct
         ct         500
         mode       homeautomation
       swupdate:
         lastinstall 2021-02-11T11:02:22
         state      notupdatable
Attributes:
   IODev      hueBridge2
   alias      Stehlampe
   color-icons 2
   devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
   genericDeviceType light
   group      Wohnzimmer
   icon       hue_filled_lightstrip
   model      FLS-H3
   rhasspyRoom wohnzimmer
   room       Beleuchtung,HUEDevice,Rhasspy,Wohnzimmer->Licht
   subType    ctdimmer
   userattr   light lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 light_map structexclude
   webCmd     pct:dimDown:dimUp:toggle:on:off


[Beta-User]

Also, "all=none" tut. Die Szenen-Namen kommen leider noch immer falsch an.

Code Auswählen Erweitern


( Frühlingsblüten ){Scene:Frühlingsblüten#[id=wZdk5cpy35oldlw]}


Hmm, hatte versucht, einen setter aus deinen Angaben zu basteln, damit hatte es funktioniert, "all" war eigentlich nur als Notlösung gedacht...

Woher kommt der Scene-Setter bei dem Device?[...]

Der Ablauf ist der:
Bei der Erstellung/dem Update der devicemap wird (z.B.) "getAllSets('HUEDevice6')" aufgerufen und dann analysiert, was da zurückkommt. Jetzt sollte es bei einem update eigentlich so sein, dass "vorne" der "Techname" stehen bleibt, und hinten dann nur noch der "Klarname" übrig bleibt (ggf. sogar mit Leerzeichen), und (nur) der/die dann auch weiter an Rhasspy geschickt wird/werden.
Ergo wird irgendwas anders bei getAllSets() geliefert, als ich angenommen hatte (input wäre hilfreich), oder der Slot ist jetzt komplett leer (gar keine scenes?) und wird deswegen nicht wieder überschrieben, oder ich übersehe mal wieder was.