Perl - Modul 10_RHASSPY.pm "professionalisieren"

[Beta-User]

Zeile 1354 bei dir:
Es kann nur diese beiden Typen geben.

Wie wäre es dann mit

Code Auswählen Erweitern

    $type eq 'voice' ?
        readingsBulkUpdate($hash, 'voiceResponse', $response)
      : readingsBulkUpdate($hash, 'textResponse', $response);


Was von Rhasspy kommt, können wir selber festlegen. Da gibt's keine Vorgabe. Die User müssen sich dann einfach nur dran halten.

Dann werden wir das wohl versuchen, in diese Richtung umzubauen, oder?
Als ersten Schritt mal eine geringfügig abgespeckte cfg, die aus "soundVolume" nur "volume" macht...

Ich möchte aber schon ein bisschen Flexibilität bei behalten. Zum einen ist das mit "an Guidelines halten" so eine Sache. Zum anderen kann man das Zeug so absichtlich "missbrauchen". Ich steuer z.B. meinen Saugroboter über MediaControls .

Grundsätzlich sollte die Flexibilität nicht unter den Vorschlägen leiden, der Saugrobi sollte/könnte dann eben auf "cmdPlay" reagieren. Der Plan wäre, zumindest die Mapping-Möglichkeiten so zu erhalten, wie sie heute sind, nur ggf. diese leiser/lauter-zurück-Geschichte ggf. dann irgendwann (!) auszubauen und statt Helligkeit dann eben brightness zu verwenden (weil die zusätzliche Prüfung eben etwas Performance kostet)...

Aber das mit dem genericDeviceType ist eigentlich eine gute Idee!

Das hört man doch gerne .

Dann wird das Ziel hinter "devspec" jetzt vermutlich auch klarer...

[drhirn]

Grundsätzlich sollte die Flexibilität nicht unter den Vorschlägen leiden, der Saugrobi sollte/könnte dann eben auf "cmdPlay" reagieren. Der Plan wäre, zumindest die Mapping-Möglichkeiten so zu erhalten, wie sie heute sind, nur ggf. diese leiser/lauter-zurück-Geschichte ggf. dann irgendwann (!) auszubauen und statt Helligkeit dann eben brightness zu verwenden (weil die zusätzliche Prüfung eben etwas Performance kostet)...

Wie gesagt, wir sind da vollkommen flexibel. Wir können auch - wie von dir vorgeschlagen - pct nehmen.

Wir müssen nur dran denken, dass zwischen "stell die lampe auf 50" und "stell die lampe auf 50 prozent" ein Unterschied ist

[drhirn]

Und - weil's mir gerade wieder einfällt - $device ist eigentlich nicht, was ich bei der Sprachausgabe hören will. Ich möchte das als Sprachausgabe bekommen, was ich zuvor gesprochen habe. Deswegen habe ich bei RHASSPY_handleIntentGetOnOff "$deviceName" eingeführt. Damit ich nicht den FHEM-Namen zurück bekomme, sondern den rhasspyName.

[drhirn]

Bisher war's so, dass ich eigentlich alle SetNumeric-Geschichten in Rhasspy mit einem Satz abdecken konnte:

Code Auswählen Erweitern

\[stell|stelle|mach|mache|schalt|schalte] $de.fhem.Device{Device} [$de.fhem.Device{Room}] [auf|um] [(0..100){Value}] [(prozent|grad|dezibel){Unit}] [(heller|dunkler|wärmer|kälter|lauter|leiser){Change}]

Mit unserem Plan, müsste man für jede Änderung einen eigenen Satz bauen:

Code Auswählen Erweitern


\[mach] $de.fhem.Device{Device} lauter{Change:volumeUp}
\[mach] $de.fhem.Device{Device} leiser{Change:volumeDown}


Das nur zur Erklärung.

[drhirn]

Musste in onmessage noch den "type" ergänzen. Sonst hat RHASSPY_respond nicht funktioniert.

Code Auswählen Erweitern


    if ($mute) {
        $data->{requestType} = $message =~ m{${fhemId}.textCommand}x ? 'text' : 'voice';
        RHASSPY_respond($hash, $data->{requestType}, $data->{sessionId}, $data->{siteId}, q{ });
        return \@updatedList;
    }


[Beta-User]

Wie gesagt, wir sind da vollkommen flexibel. Wir können auch - wie von dir vorgeschlagen - pct nehmen.

Ich habe dazu auch noch keine abschließende Meinung; grundsätzlich ist "pct" halt in FHEM alles, was man zwsischen 0 und 100 (bzw. 99=>ZWave) regeln kann. Von daher würde sich das anbieten.
Tendenziell müssen wir das aber auch nicht "gleich" festlegen, erst wäre
- der Mechanismus umzustellen (die Übersetzung nach intern mit vorrangiger Prüfung auf was auch immer, das bräuchten wir vorerst ja nicht offenzulegen);
- die Verwaltung der mappings nach intern zu verlegen. Wenn wir nämlich mehrere Quellen haben, sollten wir irgendwie dem User zeigen, was ganz am Ende das mapping geworden ist?

Wir müssen nur dran denken, dass zwischen "stell die lampe auf 50" und "stell die lampe auf 50 prozent" ein Unterschied ist

Korrekt, wobei mein bisheriger Eindruck vom Code der war, dass "percent" eine separate Kategorie ist, die nicht deckungsgleich sein muss mit "Helligkeit" (dann: ggf. "pct")

Und - weil's mir gerade wieder einfällt - $device ist eigentlich nicht, was ich bei der Sprachausgabe hören will. Ich möchte das als Sprachausgabe bekommen, was ich zuvor gesprochen habe. Deswegen habe ich bei RHASSPY_handleIntentGetOnOff "$deviceName" eingeführt. Damit ich nicht den FHEM-Namen zurück bekomme, sondern den rhasspyName.

Sory, das war mir rausgegangen...

Wobei ich da ggf. was kürzeres vorschlagen würde ($devname, $r_name oder $alias?).

Bisher war's so, dass ich eigentlich alle SetNumeric-Geschichten in Rhasspy mit einem Satz abdecken konnte:

Code Auswählen Erweitern

\[stell|stelle|mach|mache|schalt|schalte] $de.fhem.Device{Device} [$de.fhem.Device{Room}] [auf|um] [(0..100){Value}] [(prozent|grad|dezibel){Unit}] [(heller|dunkler|wärmer|kälter|lauter|leiser){Change}]

Ins Unreine - geht so etwas:

Code Auswählen Erweitern

\[stell|stelle|mach|mache|schalt|schalte] $de.fhem.Device{Device} [$de.fhem.Device{Room}] [auf|um] [(0..100){Value}] [dezibel{Unit:decibel}][grad{Unit:degree}][prozent{Unit:percent}] [(heller|wärmer|lauter){Change:up}|(dunkler|kälter|leiser){Change:down}]
Aber ja, ich sehe das Problem, das ist wirklich relativ unübersichtlich und vermutlich dann doch über ein cfg-Mapping einfacher zu erledigen...
Wobei da jetzt wieder ein paar neue Dinge drin sind, mal sehen, was mir ggf. dazu im Lauf der Zeit noch in den Sinn kommt.

onmessage habe ich rüberkopiert, Danke für's reparieren...

[drhirn]

Wobei ich da ggf. was kürzeres vorschlagen würde ($devname, $r_name oder $alias?).

Ich bin da situationselastisch wie man bei uns in Österreich sagt . Wenn ich's mir aussuchen kann, hätte ich gerne etwas Sprechendes ohne Unterstriche.

Ins Unreine - geht so etwas:

Code Auswählen Erweitern

\[stell|stelle|mach|mache|schalt|schalte] $de.fhem.Device{Device} [$de.fhem.Device{Room}] [auf|um] [(0..100){Value}] [dezibel{Unit:decibel}][grad{Unit:degree}][prozent{Unit:percent}] [(heller|wärmer|lauter){Change:up}|(dunkler|kälter|leiser){Change:down}]

Ähm, ja. Könnte gehen. Hab's jetzt aber nicht ausprobiert. Solange man nicht "Stelle Device auf 100 Dezibel Grad Prozent" sagt

Stelle fest, du kennst dich mit Rhasspy schon gut aus

[Beta-User]

Ich bin da situationselastisch wie man bei uns in Österreich sagt . Wenn ich's mir aussuchen kann, hätte ich gerne etwas Sprechendes ohne Unterstriche.

Unterstriche finde ich auch nicht so prickelnd, ich bevorzuge halt prinzipiell eher "kurz und knackig", von daher ist die spontane Tendenz eher zu $alias, aber letztlich ist mir das "juck wie jack". Falls das mit der "erweiterten maping-Analyse" kommt, wird man eben voraussichtlich diesen "Label" (ohne $) auch im List vom RHASSPY-Device über den möglichen Werten finden; spätestens dann ist auch für die User klarer, was gemeint ist (die werden eh' zu 95+% copy/paste machen...)

Ähm, ja. Könnte gehen. Hab's jetzt aber nicht ausprobiert. Solange man nicht "Stelle Device auf 100 Dezibel Grad Prozent" sagt

Klar, Unsinn kann man damit treiben, wobei die Frage im Raum steht, ob dann mehrfach die "Unit" im JSON auftaucht. ..?

Stelle fest, du kennst dich mit Rhasspy schon gut aus

Ein gewisses Gesamtbild schwebt schon vor meinen Augen, auch wenn ich bisher noch keinen Docker am Laufen habe... Es wird also so langsam.
Jedenfalls ist mein Eindruck sehr positiv, das sieht alles einigermaßen staight forward aus .

Prinzipiell wäre eben die Frage, wie oft man sowas editieren muss und inwieweit es copy/paste von vorhandenen Vorlagen ist.
Wenn es zu 99,5%+ funktioniert und man dann nur einmalig einen etwas komplexeren Ausdruck editieren/anpassen muss, neige ich (leicht) zu der Auffassung, dass es aus User-Sicht besser ist, sowas nur an einer Stelle anfassen zu müssen


Was ganz anderes: Gibt es eigentlich die Option, eine "SPELL"-Anweisung zurückzugeben.
Anwendungfall: wir können ein Mapping nicht auflösen und wollen dem User mitteilen, welches das übergebene "keyword" war.

[drhirn]

Prinzipiell wäre eben die Frage, wie oft man sowas editieren muss und inwieweit es copy/paste von vorhandenen Vorlagen ist.

Die "Sätze" in Rhasspy? Muss man 1x erstellen. Sofern sie passen, braucht man das dann nie wieder.

Was ganz anderes: Gibt es eigentlich die Option, eine "SPELL"-Anweisung zurückzugeben.
Anwendungfall: wir können ein Mapping nicht auflösen und wollen dem User mitteilen, welches das übergebene "keyword" war.

Verstehe ich nicht. Wir können in die reponse ja packen, was wir wollen.

[Beta-User]

@Beta-User
Meine Tests musste ich wieder einstellen, da meine CustomIntents mit Übergabe von Werten (z.B. SetAllOff) nur Fehler gebracht haben.

Ich hoffe, die Ursache gefunden zu haben, aktualisierter Code anbei.

Die "Sätze" in Rhasspy? Muss man 1x erstellen. Sofern sie passen, braucht man das dann nie wieder.

Nachdem ich auch die "Sätze" für diese SetAllOn-Geschichte mal etwas näher angesehen habe, scheint es mir so zu sein, dass man auch das "Problem" aus

Ähm, ja. Könnte gehen. Hab's jetzt aber nicht ausprobiert. Solange man nicht "Stelle Device auf 100 Dezibel Grad Prozent" sagt

wohl durch passende Syntax gut lösen kann. Neige daher noch mehr dazu, das auf der "sentences.ini"-Ebene zu lösen und das Modul gleich passend beliefern zu lassen...

Verstehe ich nicht. Wir können in die reponse ja packen, was wir wollen.

Klar. Meine eigentliche Frage war: wie bringen wir die Sprachausgabe dazu, etwas zu buchstabieren? Leerzeichen zwischen die einzelnen Buchstaben packen?

[drhirn]

Ja. Habe ich nicht wirklich zum Ausdruck gebracht. Bin ebenfalls dafür, dass die sentences.ini schon alles richtig liefert.

Klar. Meine eigentliche Frage war: wie bringen wir die Sprachausgabe dazu, etwas zu buchstabieren? Leerzeichen zwischen die einzelnen Buchstaben packen?

Ja, das funktioniert.

[drhirn]

Bei den Mappings gibt's ja die Möglichkeit, ein response= anzugeben. Das war eigentlich dazu gedacht, eine individuelle Sprach-Antwort festzulegen.

Code Auswählen Erweitern

SetOnOff:cmdOn=on,cmdOff=off,response=Okidoki

Jetzt kann man da auch Aufrufe zu Sachen in der myUtils.pm unterbringen. Was cool ist.
Aber eine einfache Sprachausgabe geht nicht mehr .

Ich finde leider den Teil im Code nicht, wo das abgehandelt wird. Oder kapier's nicht. Kannst du mir da helfen?

[Beta-User]

Ähm, auf die Schnelle ist das schwierig, ich breche grade die ganzen Hashes auf, um diese interne Kompabilitätsebene einzuziehen.

Des Pudels Kern sollte eigentlich das hier sein:
https://github.com/drhirn/fhem-rhasspy/blob/0.4.2beta/10_RHASSPY.pm#L1714
Das ist im wesentlichen unverändert, von daher deutet es darauf hin, dass das mapping kaputt ist. Den Code, um das zu ermitteln, haben wir aber afaik nicht substantiell angefasst...

[drhirn]

Ah, genau. Da war das. Danke! Ich schau mal, was ich raus finde.

[drhirn]

Keine Ahnung, warum das überhaupt funktioniert hat...
Finde auch im Code von Thyraz keine Erklärung dafür. Ich glaube langsam, ich bilde mir das nur ein. Andererseits hab ich in meinem produktiven FHEM ein Mapping gefunden. Es muss also irgendwie funktioniert haben. Ich kann's nur leider nicht mehr überprüfen.