Modulentwicklung für Rhasspy Sprachassistent

[drhirn]

Tatsächlich. Geht bei mir (zuhause) auch. Aber nur wenn ich set xxx mit angebe. Bin verwirrt. Dachte, ich hätte das im Büro auch getestet.

[Beta-User]

Das ist etwas "speziell", weil dieser Zweig prüft, ob es einen passenden (FHEM-) command dafür gibt. Baut man da einen Tippfehler rein oder verwendet "Kurzformen", klappt es leider nicht.

(Bin noch nicht entschieden, ob ich diesen Parser insgesamt geglückt finde...)

Wie dem auch sei: Danke für die Bestätigung, DASS es geht. Ergänzt du die Doku (cref) "irgendwie"? Das ist jedenfalls nicht selbsterklärend ...

[drhirn]

Ja, mach ich dann. Sobald ich weiß, wie das "irgendwie" aussehen soll.

[Ziton]

Danke fürs Willkommen heißen

Ich wollte auf das nicht übersetzte $Device hinaus.

Wie du schon beschrieben hast wird $Device in dem Moment in dem der Befehl mit "set xxxx ...." angeben wird, nicht übersetzt. An der Stelle nachvollziehbar.
Im ursprünglichen Sinn würde der Befehl aus meiner Sicht nur mit "open plugin://plugin.video.twitch/?channel_id=CHANNEL_ID&mode=play" hinterlegt.
Das Device wird über den Sprachbefehl erkannt. (Ansonsten Fehler)

"2021.05.25 13:43:55.487 5: Device selected (by hash, with room and channel)"

"open" sollte auch die Prüfung auf einen (FHEM-) command überstehen imho. [EDIT: Ist ja quatsch ... die Prüfung wird es NICHT überstehen und läuft deswegen derzeit in den Elseif zweig mit dem Doppelpunkt.]

Zusammenbauen würde er das Ganze aber nur wenn die cmd Prüfung den elseif zweig auf den Doppelpunkt übersteht.

Gruß Ziton

[Beta-User]

Ähm, hast du das jetzt mit dem konkret angegebenen Device-Namen und dem "set" getestet oder nicht (also mein "Sonos" durch den Namen deines Geräte ersetzt)? Ich bin immer noch verwirrt und meine, mit diesem Umweg ginge es...

(Ist eher so, dass ich mir überlege, ob es Sinn macht, hier ein "special"-Äquivalent zu "rhasspyChannels" zu bauen, das etwas flexibler ist, auch in der Rückmeldung usw.. Mir fehlt aber etwas der Überblick, wer sowas wie aus welchen Gründen verwendet...)

[Ziton]

Entschuldige, ja es funktioniert wenn man den kompletten Befehl in das Attribut übernimmt.

Bei dieser Vorgehensweise habe ich nun bei jedem Channel den Device Namen hart im Attribut verdrahtet. Das ist der Punkt auf den ich hinaus wollte.

Ich kann mir schon vorstellen dass das ein Sonderfall ist und könnte durchaus auch verstehen wenn ihr da keine Arbeit rein stecken wollt.

Bei meinem ersten Ansatz mit dem Befehl in Anführungszeichen dachte ich ich könnte das Problem umschiffen. Konnte aber aus dem Code nicht genau herauslesen
wofür dieser Fall gedacht war da er keinen Ausführungsteil enthielt.

[Beta-User]

Entschuldige, ja es funktioniert wenn man den kompletten Befehl in das Attribut übernimmt.

Sorry für die Nachfrage; ich habe manchmal das Problem, dass ich keine passende Hardware etc. habe und daher nicht sicher sein kann, ob die Trockenübung der Realität standhält ...

Bei dieser Vorgehensweise habe ich nun bei jedem Channel den Device Namen hart im Attribut verdrahtet. Das ist der Punkt auf den ich hinaus wollte.

Ich sehe ein, dass das "unschön" ist, aber im Moment sehe ich das als kleineren Schönheitsfehler an, da "rhasspyChannels" (und "rhasspyColors") "Sonderlocken" (als Attribute) sind und durch was generischeres ersetzt werden sollten. Also wenn an der Stelle überhaupt Aufwand reingesteckt werden sollte, dann mE. eher in den "Nachfolger" in "specials"...

Konnte aber aus dem Code nicht genau herauslesen wofür dieser Fall gedacht war da er keinen Ausführungsteil enthielt.

Sich in dem Code als Neuling zu orientieren ist m.E. nicht wirklich einfach. Diese Codestelle wird von einigen Funktionen intern aufgerufen und hat daher an der einen oder anderen Stelle Funktionalitäten, die man nicht verstehen kann, wenn man sie nur aus der einen Warte betrachtet, von der man grade "losgelaufen" ist (hier: von rChannels kommend).
Andererseits ist es grade aus dem Grund relativ schwierig, was umzubauen; es besteht dann immer die große Gefahr, dass man eine Stelle übersehen hat und der Umbau dann entweder gar nicht geht, oder nur mit großen Mühen.... Ich habe mich auch relativ lange nicht getraut, diese zentralen Stellen überhaupt anzufassen.

[Beta-User]

Sooo, für mutige (und FHEM-mäßig akuelle!) Tester und User....

(Intern wird jetzt die Register.pm zur Timerverwaltung genutzt. Das kommt mit dem update erst seit ein paar Tagen, ich hab's aber (mit RHASSPY) noch nicht intensiv getestet...)

Dafür kann das Ding jetzt vielleicht on-for-timer...

Beim gDT-Mapping ist mir auch was kaputt gegangen gewesen, das ist auch repariert.

sentence.ini zum Testen:

Code Auswählen Erweitern


[de.fhem:SetTimedOnOff]
(schalt|mach) (den|die|das) $de.fhem.Device-SetOnOff{Device} [in|im|in der|auf der] [$de.fhem.Room{Room}] für [((1..60){Hour!int} (stunde|stunden))] [und] [((1..60){Min!int} (minute|minuten))] [und] [((1..60){Sec!int} (sekunde|sekunden))] $OnOffValue{Value}

[DrBasch]

Guten Morgen.

Über Pfingsten bin ich jetzt doch aufs Produktivsystem gewechselt... mit einigen (mal wieder selbstverschuldeten  ) Schwierigkeiten. Insgesamt scheint neue Konfiguration mit Master und Satelliten (ehemaliges Testsystem +  Rhasspy Mobile App) jetzt aber zu laufen.

Aber der Reihe nach - first things first:

Bei dir habe ich jedenfalls das Gefühl, dass das sehr gut gelingen könnte, die Frage (und die Tonlage ) sind auf einem m.E. "passenden" Niveau.

Vielen Dank, ich fasse das als Kompliment auf, dass ich gerne und aufrichtig zurückgeben möchte.

- an der sentences.ini sollte man m.E. nicht direkt rumschrauben. "Zu meiner Zeit" hat direkt der vorhandene "Wie spät ist es"-Satz genügt, um von FHEM eine Antwort zu erhalten, jetzt muss man m.E. den intent anfassen und ein "de.fhem:" davorsetzen (bei ensprechender language/fhemId).
MAn. wäre das das "geschicktere" "hello world 1"-Erlebnis...

Der Vollständigkeit halber bestätige ich, dass bereits unter 0.4.15  nach

Code Auswählen Erweitern

define Rhasspy RHASSPY... kein leerer Intent mehr angelegt wurde/wird.
Nach Anlage von

Code Auswählen Erweitern

intents/de.fhem.GetTime.ini

Code Auswählen Erweitern


[de.fhem:GetTime]
(wie spät | wieviel uhr) ist es
was sagt die Uhr

funktioniert die Zeitansage inkl. "hello wold-Experience".

Daher sollte man dann nach der Vergabe des gDT-Attributs an ein (von der devspec erfasstes) reales Device mal "update devicemap" machen und sich anschließend erst das RHASSPY-list und dann die ganzen slots ansehen

Sooo, für mutige (und FHEM-mäßig akuelle!) Tester und User....
Beim gDT-Mapping ist mir auch was kaputt gegangen gewesen, das ist auch repariert.

Nach dem GetTime habe ich mich an die Konfiguration der Schaltsteckdosen für unsere Beleuchtung gemacht. Unter 0.4.15 wurde
nach

Code Auswählen Erweitern

attr <device> genericDeviceType switch
set Rhasspy update devicemap
list Rhasspy
partout kein (SetOnOff-/GetOnOff-)Intents gemappt.

Mit 0.4.16 werden jetzt beide Intents korrekt gemappt.
Jippie


Bzgl. Doku:
Bevor ich jetzt irgendeinen Unsinn mache möchte ich doch noch einmal nachfragen ob das so in Eurem Interesse wäre/ ich Eure Vorstellungen richtig verstanden habe:

Ich würde einen neuen Thread (z.B. "Mein Einstieg in Rhasspy" ) aufmachen und dort meine Erkenntnisse/Erfolge/Mißerfolge bei der Konfiguration teilen; mit Links als Hinweis auf die Grundeinrichtung bzgl. Rhasspy(https://rhasspy.readthedocs.io/en/latest/) und RHASSPY (https://github.com/fhem/fhem-rhasspy, cref). Von der Form her in Anlehnung an https://forum.fhem.de/index.php/topic,77724.msg696453.html#msg696453. Wäre das so okay für Euch?

[Beta-User]

ich fasse das als Kompliment auf, [...]

So war es gemeint gewesen!

Nach Anlage von [...] funktioniert die Zeitansage inkl. "hello wold-Experience".

partout kein (SetOnOff-/GetOnOff-)Intents gemappt.

Sorry, das war das, was mit "gDT-Mapping ist mir auch was kaputt gegangen gewesen" gemeint gewesen war .

Zur Tonlage noch - falls dir sowas nochmal über den Weg läuft: Bitte nicht zu lange den Fehler bei dir selbst suchen; die offensichtlichen "Wegmarken" prüfen, aber wenn es dann "seltsam wirkt", was das list hergibt => kurze Frage hier, und es sollte sich klären lassen.
(Das Probem war: Ich hatte den gDT-Attribut-Parser erweitert/generalisiert, aber eine Stelle übersehen und dort nicht die (neue) Syntax für den Funktionsaufruf eingebaut, was mir aber selbst nicht direkt aufgefallen war, weil mein "Testgerät" jetzt auch eine "GetState"-Abfrage "kann" und daher ein rhasspyMapping hat (was ich aber zum Zeitpunkt des Testens vergessen hatte...). Sowas kann (leider) vorkommen .

Bzgl. Doku:
[...]
Wäre das so okay für Euch?

Aus meiner Warte klingt das sinnvoll (auch wenn ich Grafana nicht im Einsatz und das verlinkte Beispiel auch nur grob überflogen habe).

Aus der Erfahrung mit Doku-Themen allgemein heraus wäre meine Bitte nur, jeweils klarzustellen, auf welche Fassung sich das bezieht, und dass es z.B. für die Rhasspy-(Dienst)-Themen sinnvoll ist, ggf. mal nachzusehen, ob es nicht an der "eigentlichen Quelle" Neuigkeiten gibt. (Es gibt User, die trotz solcher Hinweise meinen, sie hätten einen Anspruch auf fortlaufende Aktualisierungen, statt selbst aktiv zu werden).

[DrBasch]

[...]Bitte nicht zu lange den Fehler bei dir selbst suchen; die offensichtlichen "Wegmarken" prüfen, aber wenn es dann "seltsam wirkt", was das list hergibt => kurze Frage hier, und es sollte sich klären lassen.

OT: Danke für das "Angebot" ich bleibe aber im Moment lieber noch dabei unerwartetes Verhalten von FHEM/Modulen (ganz allgemein) erstmal selbst zu "untersuchen". Auf die Art und Weise lerne ich von Tag zu Tag ein bisschen mehr über FHEM, Perl und die zugrundeliegenden Datenmodelle/Funktionen.

Aus der Erfahrung mit Doku-Themen allgemein heraus wäre meine Bitte nur, jeweils klarzustellen, auf welche Fassung sich das bezieht...

Die Angaben von Versionsnummern hatte ich vor, mit einzupflegen.

[Beta-User]

Auf die Art und Weise lerne ich von Tag zu Tag ein bisschen mehr über FHEM, Perl und die zugrundeliegenden Datenmodelle/Funktionen.

Sehr gerne - nach meiner eigenen Erfahrung schadet das nicht (und es ist ggf. auch erlaubt, Fragen dazu zu stellen).

Wie in dem anderen Thread erwähnt, habe ich noch zwei Punkte in dem TimedOnOff-Intenthandler gefunden.

Eventuell diesen Teil tauschen (ungetestet, da war noch ein $value drin und wenn man die aktuelle Zeit nicht am Ende von der Zielzeit abzieht, ergibt das "ziemlich lange" Dauern...):

Code Auswählen Erweitern

            my $hour = 0;
            my $now1 = time;
            my $now = $now1;
            my @time = localtime($now);
            if ( defined $data->{Hourabs} ) {
                $hour  = $data->{Hourabs};
                $now1 = $now1 - ($time[2] * HOURSECONDS) - ($time[1] * MINUTESECONDS) - $time[0]; #last midnight
            }
            elsif ($data->{Hour}) {
                $hour = $data->{Hour};
            }
            $now1 += HOURSECONDS * $hour;
            $now1 += MINUTESECONDS * $data->{Min} if $data->{Min};
            $now1 += $data->{Sec} if $data->{Sec};

            $now1 += +DAYSECONDS if $now1 < $now;
            $now1 = $now1 - $now;

            $cmd .= " $now1";

[Beta-User]

Da ich die Tage vermutlich nicht ans Testen kommen werde, anbei zwei kleinere ungetestete Updates:
- die de-cfg enthält neben zwei fehlenden/neuen Übersetzungen einige kleinere Änderungen, die ich für "gut" hielt (eigentlich wäre es nett, wenn sich jemand mal die Mühe machen würde ggf. bessere Vorschläge zu machen, das ist alles nebenbei und auf die Schnelle entstanden).
Weiter ist eine Art "commandref" enthalten mit einletenden kurzen Erklärungen, für was der jeweilige Bereich gedacht ist.

- Dann ist in SetTimedOnOff der "Schnipsel" von gestern eingearbeitet, allerdings ohne große Tests. Wer nachsehen will, ob die Timer richtig gesetzt wurden, findet (bei den Geräten, die es über SetExtensions machen) die Infos zu dem Timer im list des jeweiligen (Ziel-) Geräts.

- Der Intent SetTimedOnOffGroup ist auch eingearbeitet, allerdings habe ich beim Testen festgestellt, dass hier - wie bei allen Gruppen-Anweisungen bisher - die Angabe des Raums verpflichtend gewesen zu sein scheint. Fand ich nicht so intuitiv und habe daher versucht, das auch auf die "Sprecher-Raum"-Logik umzubiegen, wenn der Room nicht da ist. (Ist komplett ungetestet, sentence.ini folgt ggf. nach eigenen Tests nach dem WE).

Kann also sein, dass das eine oder andere nicht erwartungsgemäß läuft, größere Schwierigkeiten erwarte ich aber nicht (vorausgesetzt, Register.pm ist vorhanden (=>FHEM also up to date), sonst wird das Modul nicht geladen...)

[Beta-User]

...jetzt hat es doch noch einen Kurztest gereicht...

(Ich habe aber auch ein Talent, mir die ungünstigsten Testbedingungen auszusuchen...)

Kurzfassung: das mit TimedOnOffGroup klappt, sentence.ini wie angekündigt:

Code Auswählen Erweitern

[de.fhem:SetTimedOnOff]
(schalt|mach) (den|die|das) $de.fhem.Device-SetOnOff{Device} [in|im|in der|auf der] [$de.fhem.Room{Room}] für [((1..60){Hour!int} (stunde|stunden))] [und] [((1..60){Min!int} (minute|minuten))] [und] [((1..60){Sec!int} (sekunde|sekunden))] $OnOffValue{Value}
(schalt|mach) (den|die|das) $de.fhem.Device-SetOnOff{Device} [in|im|in der|auf der] [$de.fhem.Room{Room}] bis um (0..24){Hourabs!int} uhr [(1..60){Min!int}] $OnOffValue{Value}

[de.fhem:SetTimedOnOffGroup]
(schalt|mach) (den|die|das) $de.fhem.Group-SetOnOff{Group} [in|im|in der|auf der] [$de.fhem.Room{Room}] für [((1..60){Hour!int} (stunde|stunden))] [und] [((1..60){Min!int} (minute|minuten))] [und] [((1..60){Sec!int} (sekunde|sekunden))] $OnOffValue{Value}
(schalt|mach) (den|die|das) $de.fhem.Group-SetOnOff{Group} [in|im|in der|auf der] [$de.fhem.Room{Room}] bis um (0..24){Hourabs!int} uhr [(1..60){Min!int}] $OnOffValue{Value}

Langfassung: Es klappt (mit allen Gruppen-Kommandos) nicht, wenn man Gruppennamen mit Leerzeichen verwendet - jedenfalls dann nicht, wenn die hinten stehen.
Auch sonst bekomme ich die Gruppen nicht unbedingt "ortsübergreifend" angesprochen, aber es wird mir heute/dieses WE wohl nicht reichen rauszufinden, woran das ggf. liegt...

Aber auch so: Ist cool, die Funktion ...
Viel Spaß beim Testen.

[Beta-User]

(erst mal nur als Idee: Eigentlich sollte es möglich sein, identische Sätze zu verwenden und dann intern von der Einzel- auf die Gruppenfunktion umzuleiten, wenn {Device} nicht vorhanden ist und dafür {Group}. Kann aber auch sein, dass das in der Praxis (früher oder später) ein Kuddelmuddel gäbe).
(Vielleicht abschaltbar per tweak?)

Meinungen dazu?