Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Die neue "Default-Branch" ist jetzt 0.4.7b.

Funktioniert wirklich gut!
Aber ich bereu's eh schon, dass ich drauf herum geritten bin. Das verwirrt nur. In Zukunft wird wieder mit den rhasspy-Attributen gearbeitet.

Ähm, so war das nicht gemeint, jetzt bin ich es, der bereut, das als "so unvollkommen" dargestellt zu haben...
Fakt ist doch:
a) mich freut es  sehr, dass du es getestet und für grundsätzlich gut befunden hast! 
b) wird die Interessenten am 29. am ehesten interessieren, wie sie schnell mal testen können bzw. "progress" machen können => Gerade das FS20-Dimmer-Ding ist super geeignet, um Möglichkeiten und Grenzen zu erläutern. In realen "modernen" Installationen wird es tendenziell eher besser funktionieren, weil CUL_HM, ZWave, HUEDevice und MQTT2_DEVICE in der Mehrzahl der Fälle (bis auf die Color-Themen) ootb laufen (behaupte ich mal in meinem jugendlichen Leichtsinn)! 
Und wer die gDT schon gesetzt hatte, wird evtl. direkt 1:1 loslegen können (von speziellen Mappings abgesehen, für die man auch sonst eben dann homeBridgeMapping setzen müßte...)
c) Die allgemeine Vorgehensweise ist damit einfach zu erläutern: vieles passiert ggf. automatisch, und wer damit nicht glücklich ist, kann das list ansehen,  rausfinden, wo es hakt und ggf. dann die "zusätzlichen" Attribute so setzen, dass es im Ergebnis paßt.
d) Ein bißchen Werbung zur Mitwirkung kann an der Stelle auch nicht schaden. Der "2Mapping"-Code ist eigentlich nicht besonders schwierig; wer etwas Übung hat, kann da gut was anflanschen, das dann allen das Leben erleichtert. Vielleicht findet sich sogar einer der "alten Hasen", der sich mit homeBridgeMapping auskennt und da einen 2RHASSPY-Parser beisteuern kann und will...?

Von daher sehe ich in dieser generellen "gDT-als -Startpunkt"-Vorgehensweise eher die Zukunft, und mAn. ist es auch soweit "ok", dass man es als "default" durchgehen lassen kann...
Vielleicht bekommen wir noch das "thermostat"-Thema mit der Temperaturabfrage bis zum 29. hin, dann ist doch eigentlich alles supi , und wenn's noch LightScene reicht, ist es kaum zu toppen .

PS: zum Thema Timer und Wecker ist es so still ...

[drhirn]

Ähm, so war das nicht gemeint, jetzt bin ich es, der bereut, das als "so unvollkommen" dargestellt zu haben...

Es ging mir eher darum, dass es eventuell ein paar bereits aktive Nutzer verwirren könnten. V.a., weil's nicht wirklich dokumentiert ist.

Vielleicht bekommen wir noch das "thermostat"-Thema mit der Temperaturabfrage bis zum 29. hin, dann ist doch eigentlich alles supi

Das wär sehr gut!

PS: zum Thema Timer und Wecker ist es so still ...

Ja, leider. Aber zu den anderen Intents eh auch bis jetzt .

[drhirn]

Gibt eine neue Rhasspy-Version: https://community.rhasspy.org/t/rhasspy-2-5-10-released/2619

[drhirn]

^ weil ich in den Release-Notes gerade gesehen habe

Only one satellite within a group should start recording if more than one detect the wake word at the same time

Die Gruppen liegen mir schon länger im Magen, ich wollt's nur bisher nicht erwähnen, sondern mir für eine später Version aufsparen. Aber schadet eigentlich nicht, es zu wissen.

Es gibt die Möglichkeit, Gruppen von Satelliten zu definieren. Wenn man z.B. in einem Raum mehrere hat (was bei mir dann der Fall sein wird). Die werden dann, wenn ich das richtig in Erinnerung habe, wie folgt benannt:

Code Auswählen Erweitern

gruppenname.satellitenname

also z.B.

Code Auswählen Erweitern

wohnzimmer.schreibtisch
wohnzimmer.esstisch

Wir sollten dann sicherstellen, dass so eine siteId richtig als "wohnzimmer" erkannt wird. In einer späteren Version dann.

[drhirn]

Wenn ich nach einem FHEM Neustart gleich ein update devicemap ausführe, bekomme ich eine Perl-Warnung:

Code Auswählen Erweitern

PERL WARNING: Use of uninitialized value $devgroups in split at ./FHEM/10_RHASSPY.pm line 1302

Zeile 1302 ist bei mir:

Code Auswählen Erweitern


sub RHASSPY_allRhasspyGroups {
...
        for (split m{,}xi, $devgroups ) {
...
}


[drhirn]

Spiele gerade mit Shortcuts.

Code Auswählen Erweitern

i="geh kochen" p={fhem ("set $NAME on")} n="Stehlampe" c="möchtest du schweinsbraten?"

Meine (offensichtliche) Antwort auf diese Frage ist immer "Ja". Was zu diesen Sentences passen würde:

Code Auswählen Erweitern


[de.fhem:ConfirmAction]
(ja | tu es | ist ok ){Mode:OK}
(lass es | nein | abbrechen | abbruch ){Mode:Cancel}


Leider bekomme ich keinen Schweinsbraten, sondern offenbar immer einen Timeout.

Code Auswählen Erweitern


2021.04.11 11:18:08.729 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_Shortcuts => {"input": "geh kochen", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-snowboy-6171a983-2d53-4c4f-aadc-681505f5f3c6", "customData": "snowboy", "asrTokens": [[{"value": "geh", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "kochen", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 10, "time": null}]], "asrConfidence": null, "rawInput": "geh kochen", "wakewordId": "snowboy", "lang": null}
2021.04.11 11:18:08.730 5: Parsed value: geh kochen for key: rawInput
2021.04.11 11:18:08.730 5: Parsed value: Shortcuts for key: intent
2021.04.11 11:18:08.730 5: Parsed value: wohnzimmer-snowboy-6171a983-2d53-4c4f-aadc-681505f5f3c6 for key: sessionId
2021.04.11 11:18:08.730 5: Parsed value: geh kochen for key: input
2021.04.11 11:18:08.730 5: Parsed value: wohnzimmer for key: siteId
2021.04.11 11:18:08.730 5: Parsed value: 1 for key: probability
2021.04.11 11:18:08.731 5: handleIntentShortcuts called with geh kochen key
2021.04.11 11:18:08.731 5: Response is: HASH(0x55e246a34518)
2021.04.11 11:18:23.009 5: Response is: Tut mir leid, da hat etwas zu lange gedauert


Muss ich da etwas anders machen? Bzw., funktioniert das bei euch?

[Beta-User]

Das mit der Confirmation funktioniert bei mir (@Rhasspy 2.5.10  ), und ich kann an deinen Sätzen im Moment auch nicht erkennen, wo das Problem liegen könnte.
Ich habe  in dem Confirmation-Zusammenhang aber ein anderes "Problem": Das "nein" (für Stille...) wird als Confirmation intent erkannt, aber keiner ist in der Lage, das zu händeln.
OK, nach dem alten Code ist das logisch, weil in dem Fall $data nicht mit übergeben wurde. Nur: das zu ergänzen hilft dem nicht ab... Hä?!?

Die unititialized-Meldung sollte "erlegt" sein, danke für's Melden (das war so ein "typischer" Fall, den ich mal hier zum Abschuss freigegeben hatte...).

Wir sollten dann sicherstellen, dass so eine siteId richtig als "wohnzimmer" erkannt wird. In einer späteren Version dann.

Besser jetzt und gleich ...
Ist nicht besonders getestet, müßte aber eigentlich funktionieren, und auch in der b-Version hätte man "einfach" nur passende siteId2room-Readings setzen müssen .
(Ok, ich weiß, Doku. Meine eigentliche Idee dazu ist aber noch nicht fertig und besonders gut getestet...)

Es ging mir eher darum, dass es eventuell ein paar bereits aktive Nutzer verwirren könnten. V.a., weil's nicht wirklich dokumentiert ist.

Na ja, wer die "alten" Attribute hat, braucht das ja für den Teil nicht ändern, sollte ja (weitestgehend, wenn man von Namenskonventionen absieht) funktionieren. Und wie viel Doku braucht es dazu?
Wenn es "fertiger" ist, sollte man es mAn.  in der cref prominenter präsentieren im Sinne von: bitte "use" setzen, aber das war es dann auch schon fast (abgesehen von einer "schöneren" Liste...)

Ja, leider. Aber zu den anderen Intents eh auch bis jetzt .

Na ja, eigentlich wollte ich nur zu diesem speziellen Punkt, der ja bei Einführung durchaus nicht direkt Begeisterung hervorgerufen hatte, ein "das ist ja jetzt aber tatsächlich klasse, wie das jetzt gelöst ist" hören ...

[drhirn]

Das mit der Confirmation funktioniert bei mir (@Rhasspy 2.5.10  ), und ich kann an deinen Sätzen im Moment auch nicht erkennen, wo das Problem liegen könnte.

Ich bekomm immer ein intentNotRecognized:

Code Auswählen Erweitern


hermes/nlu/query
{
  "input" : "ja",
  "siteId" : "wohnzimmer",
  "id" : null,
  "intentFilter" : [ "ConfirmAction" ],
  "sessionId" : "wohnzimmer-snowboy-9eddd51b-a285-4027-8e5a-472af90c426f",
  "wakewordId" : "snowboy",
  "lang" : null,
  "customData" : "snowboy"
}

hermes/nlu/intentNotRecognized
{
  "input" : "ja",
  "siteId" : "wohnzimmer",
  "id" : null,
  "customData" : "snowboy",
  "sessionId" : "wohnzimmer-snowboy-9eddd51b-a285-4027-8e5a-472af90c426f"
}


Es hat also wohl irgendwie mit meinen Sentences zu tun. Denk ich. Ich hab aber deine genommen, also keine Ahnung, was bei mir anders ist.

[drhirn]

Die unititialized-Meldung sollte "erlegt" sein, danke für's Melden (das war so ein "typischer" Fall, den ich mal hier zum Abschuss freigegeben hatte...).

Sieht gut aus, danke!

Besser jetzt und gleich ...
Ist nicht besonders getestet, müßte aber eigentlich funktionieren, und auch in der b-Version hätte man "einfach" nur passende siteId2room-Readings setzen müssen .

Ich kann's halt derzeit nicht testen. Weil ich zu wenig Satelliten habe. Andererseits ... ich könnte mal schauen, was passiert, wenn ich zwei Docker-Satelliten auf das selbe Mikro los lasse.

Wenn es "fertiger" ist, sollte man es mAn.  in der cref prominenter präsentieren im Sinne von: bitte "use" setzen, aber das war es dann auch schon fast (abgesehen von einer "schöneren" Liste...)

Wenn "use" gesetzt ist aber kein gDT-Attribut gesetzt, hat das ja eigentlich keine Auswirkungen, oder? Überraschend wird's nur, wenn man schon gesetzte gDT-Attribute von anderen Sprachsteuerungen hat und nicht damit rechnet, dass diese Geräte dann in Rhasspy auftauchen.
Ich überleg nämlich gerade, was passiert, wenn wir "use" automatisch setzen bzw. der "default" 1 ist.

Na ja, eigentlich wollte ich nur zu diesem speziellen Punkt, der ja bei Einführung durchaus nicht direkt Begeisterung hervorgerufen hatte, ein "das ist ja jetzt aber tatsächlich klasse, wie das jetzt gelöst ist" hören ...

Undankbares Pack! Genießen alle das Wochenende, anstatt uns zu loben.
Kannst du mir einen Gefallen tun, und ein paar gesprochene deutsche Beispielsätze für Timer schreiben?

Im GitHub gibt's jetzt die 0.4.7c

[Cordula]

Zunächst einmal:

Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,
Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,
Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,
Aber wirklich ich finde es toll, wie ihr das Modul weiterbringt. Ich will ja immer nur was.

Aber nach dem Lob noch eine Rückmeldung. Ich habe einen Shortcut mit  Confirmation (4.7c) getestet. Mit dem gleichen Ergebnis, wie bei dir:
hermes/nlu/intentNotRecognized

[drhirn]

Hast du den gleichen Shortcut/Sentence genommen, wie ich?

[Cordula]

Nein
Hier mein Shortcut:

Code Auswählen Erweitern

i="rapunzel an" f="set Az.Anycubic on" c="Soll ich wirklich den 3d-Drucker einschalten" ct=10\

Und hier der Sentence-Eintrag:

Code Auswählen Erweitern

[de.fhem:ConfirmAction]
(ja | tu es | ist ok ){Mode:OK}
(lass es | nein | abbrechen | abbruch ){Mode:Cancel}


Code Auswählen Erweitern


hermes/nlu/intentNotRecognized
{"input": "ja", "siteId": "arbeitszimmer", "id": null, "customData": null, "sessionId": "arbeitszimmer-Okay Kalle-601bf1c5-81d6-4ba8-8586-0038a7ae401d"}


[JensS]

Ja, leider. Aber zu den anderen Intents eh auch bis jetzt .

Habe heute alle sentences und mappings auf englisch umgestellt und bin erfreut, dass es funktioniert. 
Wenn ich irgendwo helfen kann, lasst es mich wissen.

Durch den Hinweis von drhirn habe ich die Version 2.5.10 installiert - danke für die Info. Da soll ja einiges möglich sein.
Z.B. Kaldi Mixed Language Model Weight soll nun tatsächlich funktionieren. Das wäre ein großer Sprung, da ein riesen Wortschatz dran hängt.
Leider läuft das bisher nur mit Docker und die eigenständige Debian-Installation erweist sich als langwierig...

Für den 29. sehe ich gute Chancen zur weiteren Verbreitung und Unterstützung. Die Intents im Forum sind ein guter Anfang. Diese Infos gebündelt als ein README für die deutsche Version im Github bzw. zukünftig im Wiki würde ich als Schlüssel zur Verbreitung ansehen.

Gruß Jens

[drhirn]

Wenn ich irgendwo helfen kann, lasst es mich wissen.

Ganz, ganz wichtig wäre mir derzeit, mich mit Tests zu unterstützen und die Erkenntnisse im anderen Thread zu vermerken. Was wie getestet wurde und ob das Ergebnis so war, wie erwartet.
Schön wäre auch, wenn an der Doku mitgewirkt würde. Gerne auch auf deutsch übersetzen. Aber wirklich nur übersetzen, nicht ergänzen. Sonst laufen sie auseinander. Haupt-Doku hätte ich gerne immer in englisch.

Z.B. Kaldi Mixed Language Model Weight soll nun tatsächlich funktionieren. Das wäre ein großer Sprung, da ein riesen Wortschatz dran hängt.
Leider läuft das bisher nur mit Docker und die eigenständige Debian-Installation erweist sich als langwierig...

Möchtest du erklären, was das genau macht und was sich dadurch für Möglichkeiten ergeben? Ich hatte noch keine Zeit, mich damit zu beschäftigen.

[JensS]

Ok, wie schon erwähnt, ist mein englisch nicht sonderlich gut aber ich werde in meinem Fork eine Datei eröffnen.

Mixed Language Model Weight soll (so habe ich es verstanden) alle deutschen Wörter mit in die Erkennung einfließen lassen. Sobald mein separates Kaldi läuft, werde ich hoffentlich mehr dazu schreiben können.
Du hast ja Docker am Start und bist bestimmt schneller.