Perl - Modul 10_RHASSPY.pm "professionalisieren"

[drhirn]

Was ich schon immer "seltsam" fand, war das mit dem "Zwangsraum". Daher gibt es jetzt als Vorschlag einen Parameter für die DEF mit dem sinnigen Namen "devspec". Damit kann man jetzt (hoffentlich) z.B. auch folgendes machen (auch für das folgende: alle Parameter sind optional!):

Code Auswählen Erweitern

defmod RHASSPY RHASSPY devspec=room=Rhasspy,room=MQTT2_DEVICE,lampe3,alexaName=.+

Der Raum in der DEF dient nur als "Ausweichraum", sollte im Befehl kein Raum gesprochen werden (aber mehrere Devices mit dem selben rhasspyName in unterschiedlichen rhasspyRooms vorkommen).
Habe ich also ein Device mit rhasspyName "licht" im rhasspyRoom "wohnzimmer" und ein Device "licht" im rhasspyRoom "schlafzimmer" und spreche das Kommand "licht ein" im rhasspyRoom "küche", wird das "licht" in dem Raum geschalten, der im DEF steht. Theoretisch. Ausprobiert hab ich das nie.

Weiter habe ich den Verdacht, dass man ggf. auch weitere Topics bzw. Unterscheidungsmerkmale braucht, wenn man z.B. unterschiedliche FHEM-Instanzen und/oder mehrere User hat, die unterschiedliches dürfen bzw. per RHASSPY ansteuern können sollen. Daher gibt es jetzt vorsorglich mal den Vorschlag, eine "fhemId" vergeben zu können...?

Code Auswählen Erweitern

defmod RHASSPY RHASSPY fhemId=fhem2

Das entzieht sich vollkommen meiner Expertise. FHEM ist bei mir nur Backend. Die User bedienen Schalter oder TabletUI. Ich sehe für sowas also - für mich - keine Verwendung. Und würde das Thema auch nicht angehen, bevor nicht der Wunsch danach kommt. Das wird sonst alles zu kompliziert.

Generell scheint es so zu sein, dass wir auf der "de->en"-Mapping-Seite ziemlich beschäftigt damit sind, zwischenzeitlich(!) unglücklich gewordene Entscheidungen aus der Vergangenheit wieder gradezubiegen.

Es war einfach nie ein "fertiges" Modul. Für die wenigen deutschsprachigen User hat's gereicht, was Thyraz gemacht hat.

Paradebeispiel:

Code Auswählen Erweitern

starte{Command:play} die wiedergabe $de.fhem.Device{Device}Da frage ich mich, warum dann nicht gleich das passende Mapping an dieser Stelle mitgegeben wird:

Code Auswählen Erweitern

starte{Command:cmdPlay} die wiedergabe $de.fhem.Device{Device}Das ist auch für einen Franzosen vermutlich recht einfach anzupassen, oder...?

Hab ich mir auch schon überlegt. Spricht nichts dagegen.

Wenn "brightness" nicht mehr Helligkeit heißt, kann man auch "raten", dass ein setter/Reading "brightness" ggf. der Wert ist, den man wissen bzw. steuern will, eventuell wäre sogar "pct" in der FHEM-Welt die erste Wahl, die man austestet.
Und wenn es keinen rhasspyName gibt, aber einen alexaName und die devspec paßt, warum sollte man dann nicht die homebridgeMappings ausschlachten und das Device durch RHASSPY ansteuerbar machen?

Könnte man
Aber wieder Aufwand. Ich hätte lieber gerne vorerst eine Version, in der mal alles funktioniert, was es bisher an Features gab. Danach bin ich für alles offen.

Jetzt wünsche ich erst mal viel Spaß beim Testen und freue mich über Rückmeldungen zu meinen Gedanken...

Ich mache mich frisch und fröhlich ans Werk...

Danke dir!

[Beta-User]

Ich mache mich frisch und fröhlich ans Werk...

Danke dir!

Dann erst mal viel Spaß!

Könnte man
Aber wieder Aufwand. Ich hätte lieber gerne vorerst eine Version, in der mal alles funktioniert, was es bisher an Features gab. Danach bin ich für alles offen.

Da liegt ganz klar die Prio!

Die "features" bzw. sonstigen Vorbereitungen sollten nicht "hindern" oder besonders gefählich sein, du wirst es am diff sehen, dass devspec und fhemId relativ moderate Eingriffe in den Code sind...

Der Raum in der DEF dient nur als "Ausweichraum", sollte im Befehl kein Raum gesprochen werden (aber mehrere Devices mit dem selben rhasspyName in unterschiedlichen rhasspyRooms vorkommen).

Da sprechen wir von unterschiedlichen Dingen, sorry, wenn ich da in die falsche Kiste gegriffen habe: der default-room hat mich bisher nicht wirklich beschäftigt, aber "devspec" wird bei der Ermittlung der überhaupt zu beobachtenden Devices eine wesentliche Rolle (bisher starr: "room=Rhasspy"). Dieser Parameter sollte also die Ersteinrichtung deutlich vereinfachen (ich arbeite da an der Stelle potentiell auch für mich selbst...).

Das entzieht sich vollkommen meiner Expertise. FHEM ist bei mir nur Backend. Die User bedienen Schalter oder TabletUI. Ich sehe für sowas also - für mich - keine Verwendung. Und würde das Thema auch nicht angehen, bevor nicht der Wunsch danach kommt. Das wird sonst alles zu kompliziert.

Na ja, ich bin auch "Einheitsuser", alles läuft in einem System, bisher stressfrei. Es gibt aber einige User, die einige FHEM parallel betreiben. Da kann es durchaus vorkommen, dass die unterschiedliche Befehle an unterschiedliche FHEM schicken wollen. Noch viel mehr denke ich allerdings über die Frage nach, wie sich das verhält, wenn unterschiedliche User ins Spiel kommen. Kann aber durchaus sein, dass mir da irgendein Bausteinchen auf der Rhasspy-Seite fehlt . Aber wenn ich mit FHEM sprechen kann, wollen das ziemlich sicher noch ein paar mehr, und das muss dann so klappen, dass mir keiner die Musik leiser dreht, der nicht auch im Raum ist...

Es war einfach nie ein "fertiges" Modul. Für die wenigen deutschsprachigen User hat's gereicht, was Thyraz gemacht hat.

Schon klar, dass das erst mal für den "Eigenbedarf" konzipiert war. Ich komme jetzt eben da irgendwie "quer" rein und versuche, das ganze irgendwie abstrakt zu verstehen und generisch auszulegen, damit "jeder" es relativ leicht auf seine Bedürfnisse anpassen kann - auch, was z.B. die Rückmeldesätze an sich angeht. Bisher hat das nach meinem Eindruck relativ gut geklappt, ohne dass wir (dauerhaft) massive Probleme bekommen hätten. Btw.: die Grundstruktur von Thyraz ist und war m.E. solide ausgearbeitet, alles baut solide aufeinander auf und man kann "die Planken" recht gut nach und nach wechseln.

Hab ich mir auch schon überlegt. Spricht nichts dagegen.

Dann sollten wir das in diese Richtung weiterverfolgen, auch was "Helligkeit" und Co. angeht.
Das könnte man dann ähnlich lösen wie bei "zurück": die de-en-Übersetzung als Zwischenschritt einbauen, wo es auf direktem Weg nicht klappt, diesen Hash dann aber (mittelfristig) nicht mehr in der cfg zeigen.
Apropos cfg: Da war die Idee, einen "default"-Hash und einen "user"-Hash zu bauen. In "user" könnte dann stehen, was der einzelne anders haben will wie in default; dann kann man nämlich den default ggf. leichter ändern, wenn sich dazu eine Notwendigkeit ergibt...

Aber Rom und so: erst machen wir das ganze wieder 100% funktional .

[drhirn]

Ich habe jetzt mal die DEF angepasst:

Code Auswählen Erweitern

defmod Rhasspy RHASSPY devspec=room=Musik Wohnzimmer de

Und dann ein updateSlots gemacht. Dabei hat er mir nur noch die Devices hoch geladen, die im Raum "Musik" sind. Das scheint also zu funktionieren.

[Beta-User]

Ich habe jetzt mal die DEF angepasst:

Code Auswählen Erweitern

defmod Rhasspy RHASSPY devspec=room=Musik Wohnzimmer de

Und dann ein updateSlots gemacht. Dabei hat er mir nur noch die Devices hoch geladen, die im Raum "Musik" sind. Das scheint also zu funktionieren.

Den Teil hatte ich sogar getestet...

Btw.: Bitte möglichst aus "pädagogischen Gründen" die DEF nur noch in der "parseParams"-Hash-kompatiblen Schreibweise posten, also

Code Auswählen Erweitern

defmod Rhasspy RHASSPY devspec=room=Musik defaultRoom=Wohnzimmer language=de
Ist vermutlich für die meisten Einsteiger leichter zu verarbeiten, wenn man es immer macht, selbst wenn die Auswertung kompatibel ist, solange man bei den "alten" Argumenten die Reihenfolge einhält... Für die neuen Argumente wird aber gar nicht mehr in das unnamed-Array geschaut...

Ich nehme an, du pflichtest mir bei, dass das eine kleine aber feine Modifikation ist, oder...?

betr. bugfixing auch gleich noch eine Sache:
Bisher gab es immer eine "seltsame" Meldung, wenn man das configFile-Attribut gelöscht hat. Die habe ich eben noch ausgemerzt.

[drhirn]

Ich hätte drei Fragen zum Timer (der ist aktualisiert seit heute; im GitHub verfügbar).

1. Wie bekomme ich das in die Sprach-Datei und wie kann ich's dann auswerten

Code Auswählen Erweitern

my @unitHours = ('stunde','stunden','hour','hours','heure','heures');

Ich muss ja die siteIds abfragen, damit ich nachsehen kann, ob es im gewünschten Raum einen Satelliten gibt. Ich dachte mir, ich schreib das nach $hash->{helper}{siteIds}. Deshalb
2. Geht das schöner?

Code Auswählen Erweitern

    my @siteIds = split /,/,$hash->{helper}{siteIds};
    my $timerRoom = $siteId;
    if ( grep {/^$room$/i} @siteIds ) {$timerRoom = $room};
3. Die siteIds bräuchte ich schon beim Start von FHEM bzw. des Moduls. Wo baue ich den Aufruf von fetchSiteIds am schlausten ein und wie?

[Beta-User]

Ad 1: Da meine ich, das eigentlich schon mal eingebaut gehabt zu haben; es gibt in der cfg. jedenfalls einen Hash mit "units", in der dann nur das drin steht, was für die jeweilige Sprache relevant ist, allerdings als regex, der Code drumrum war also anders, ich find's aber grade leider nicht mehr. Ist dann aber ähnlich wie bei "upward"...

Ad 3: Dürfte in firstInit() gut aufgehoben sein (alternativ RHASSPY_Define()). Unterschied zwischen beidem: zum firstInit()-Zeitpunkt sind alle Geräte und Attribute bereits bekannt; wenn also die Rückmeldung via MQTT kommt, sollte man bis dahin warten, damit auch der CLIENT sicher läuft.

Ad 2: Da fehlt mir noch das Bruchstückchen, was denn als Rückmeldung beim Modul ankommt, damit man es in einen Hash schieben kann. Grundsätzlich finde ich diese grep-Konstruktion notorisch der Umgehung des Hash-lookup-features von Perl verdächtigt .
Eigentlich _glabe_ ich, dass es mal wieder ein Hash sein sollte, der in $hash->{helper}{siteIds} zu finden sein sollte, nämlich mit den
siteId => room-Paaren. (oder ist das wirklich immer identisch?)Dann wieder die übliche Logik

Code Auswählen Erweitern

my $timerRoom = $hash->{helper}{siteIds}->{$siteId} // ... (=> default room);
Aber ohne Basisdaten ist das schwierig...

[Beta-User]

Nachtrag:
a) das split dient hier ja nur dazu, ein Array zu bekommen, dessen einziger Zweck es dann wieder ist, dass man darüber ein grep macht.
Das schreit m.E. danach, das direkt mit einer regex zu machen...

b) die Doppelung zwischen Internal und Reading erschließt sich mir nicht, zumal das Reading ja auch einen Neustart überlebt.

Anbei der Versuch, das anders zu lösen, gleich auch mit der regex-Lösung für die Timer-Geschichte.

[drhirn]

Die Doppelung ist einfach nur zum Spaß da. Als Notnagel, falls das mit dem Internal nicht funktioniert .

Ich finde Internal aber schöner. Sonst werden's langsam ganz schön viele Readings. Und wenn man's schafft, dass das Internal eh gleich beim Start geschrieben wird, ist es ja egal, wenn's keinen Neustart überlebt.

[Beta-User]

Die Doppelung ist einfach nur zum Spaß da. Als Notnagel, falls das mit dem Internal nicht funktioniert .

Ach so, das war vorher gar nicht da...?

Ich finde Internal aber schöner. Sonst werden's langsam ganz schön viele Readings. Und wenn man's schafft, dass das Internal eh gleich beim Start geschrieben wird, ist es ja egal, wenn's keinen Neustart überlebt.

Na ja, wenn die Readings nur geschrieben werden, wenn was (halbwegs) wichtiges passiert, finde ich das mit vielen Readings nicht schlimm, v.a., wenn man darauf achtet, nicht zu viele Trigger-loops auszulösen. Von daher kann man den update auch bedingt durch das Vorhandensein des Readings auslösen, falls sich sowieso kaum was ändert?

Grundsätzlich finde ich diese Sache aber als Reading besser aufgehoben: Das ist nichts, was vom Modul selbst direkt verwaltet wird, sondern es kommt "von außen" und kann auch von Rhasspy aus geändert werden (k.A., ob sich Clients da "abmelden" können und man das dann "gepusht" bekommt; wenn das so wäre, ist es m.E. deutlich eher Reading als Internal...

[drhirn]

Das Reading schon, das Internal hab ich am Wochenende eingebaut.

Das mit "von außen" ist ein Argument. Aber es ist keine Information, die man wissen muss. Und es wird nichts gepushed. Änderungen gibt's nur, wenn ein Satellit weg- oder dazu kommt. Und das passiert alles manuell. Und wahrscheinlich so gut wie nie.

[Beta-User]

Zwei von den gelisteten Items sollten mit der Fassung anbei gelöst sein.

Wie das mit SetMute ablaufen soll, ist mir leider unklar, aus dem Code alleine bin ich nicht schlau geworden, und nur das Reading listening_.* zu setzen, wäre zwar möglich gewesen, aber vermutlich zu oberflächlich, da soll ja wohl irgendwas nach irgendwohin rausgehen, oder?

Wirfst du noch den "Media"-Hash aus deiner cfg auf github?


Und habe ich das richtig verstanden, dass wir uns mit sowas "beliefern" lassen könnten:

Code Auswählen Erweitern

mache $de.fhem.Device{Device} heller{brightness:up}
mache $de.fhem.Device{Device} leiser{volume:down}bzw. (der Spur nach):

Code Auswählen Erweitern

mache $de.fhem.Device{Device} leiser{Command:volDown}
(Wenn ja: wie käme das dann via MQTT an?)

[drhirn]

SetMute stellt $mute auf true od. false. Wenn true, hört das Modul zwar noch zu (um mute wieder false setzen zu können), führt aber keine sonstigen Befehle aus. Das führt dazu, dass die Dialogue-Session (hermes/dialogueManager/endSession) nicht mehr beendet wird. Was wir sonst mit RHASSPY_respond machen, wenn ein Befehl ausgeführt wird.

"Media"-Hash ist entfernt. Danke für den Hinweis.

Und ja, heller/dunkler, leiser/lauter, wärmer/kälter geht auch.
Ein Mapping sieht z.B. so aus:

Code Auswählen Erweitern


SetNumeric:currentVal=volume,cmd=volume,minVal=0,maxVal=99,step=10,type=Lautstärke


Und von Rhasspy kommt folgendes:

Code Auswählen Erweitern


Msg: hermes/intent/de.fhem_SetNumeric => {"input": "mach radio lauter", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 0.6666666666666667}, "siteId": "default", "id": "cf521ed9-8de4-4bc2-82ae-77ed9a854e0c", "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "radio"}, "slotName": "Device", "rawValue": "radio", "confidence": 1.0, "range": {"start": 5, "end": 10, "rawStart": 5, "rawEnd": 10}}, {"entity": "Change", "value": {"kind": "Unknown", "value": "lauter"}, "slotName": "Change", "rawValue": "lauter", "confidence": 1.0, "range": {"start": 11, "end": 17, "rawStart": 11, "rawEnd": 17}}], "sessionId": "cf521ed9-8de4-4bc2-82ae-77ed9a854e0c", "customData": null, "asrTokens": [[{"value": "mach", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 4, "time": null}, {"value": "radio", "confidence": 1.0, "rangeStart": 5, "rangeEnd": 10, "time": null}, {"value": "lauter", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 17, "time": null}]], "asrConfidence": null, "rawInput": "mach das radio lauter", "wakewordId": null, "lang": null}

Ich hab das in der device_playload.txt ergänzt.

[Beta-User]

Hm, ok, ich meine, das Problem mit den _anderen Messages_, die im "muted"-Zustand eintrudeln können nun verstanden zu haben...

Könnte in dieser Fassung gelöst sein...



Bei dem lauter (etc.)-Thema sprechen wir noch von verschiedenen Dingen -
du vom Ist-Zustand, ich vom Soll-Zustand (definiert durch mein Bauchgefühl...):

Worauf ich raus will ist folgendes: Wir haben zum einen in Change@rhasspy-de.cfg einige Übersetzungen und regexe drin, die man nur deswegen braucht, weil von Rhasspy eben deutsche Schlüsselbegriffe geliefert werden. Die werden dann mehr oder weniger umständlich gemappt...

In Schritt 1 wäre zu fragen, ob man das mapping nicht auch so machen kann:

Code Auswählen Erweitern

SetNumeric:currentVal=volume,cmd=volume,minVal=0,maxVal=99,step=10,type=volumeSound
Schritt 2 wäre etwas radikaler:

Code Auswählen Erweitern

SetNumeric:currentVal=volume,cmd=volume,minVal=0,maxVal=99,step=10Da wir einen "passenden" Namen "volume" haben, könnten wir ggf. auch einfach "tippen", dass sich der Modulautor des Zielgeräts an https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV gehalten hatte und sich (per default) auch ableiten läßt, dass currentVal=volume auch zugleich das cmd-Reading ist...Da müßte man sich dann nur noch klar werden, ob das durch volumeSound erstetzte "Matchword" in RHASSPY nicht gleich nur "volume" heißen sollte bzw. der "value" statt "lauter" eben "volUp"...
Letzteres in:

Code Auswählen Erweitern

Msg: hermes/intent/de.fhem_SetNumeric => {"input": "mach radio lauter", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 0.6666666666666667}, "siteId": "default", "id": "cf521ed9-8de4-4bc2-82ae-77ed9a854e0c", "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "radio"}, "slotName": "Device", "rawValue": "radio", "confidence": 1.0, "range": {"start": 5, "end": 10, "rawStart": 5, "rawEnd": 10}}, {"entity": "Change", "value": {"kind": "Unknown", "value": "volUp"}, "slotName": "Change", "rawValue": "lauter", "confidence": 1.0, "range": {"start": 11, "end": 17, "rawStart": 11, "rawEnd": 17}}], "sessionId": "cf521ed9-8de4-4bc2-82ae-77ed9a854e0c", "customData": null, "asrTokens": [[{"value": "mach", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 4, "time": null}, {"value": "radio", "confidence": 1.0, "rangeStart": 5, "rangeEnd": 10, "time": null}, {"value": "lauter", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 17, "time": null}]], "asrConfidence": null, "rawInput": "mach das radio lauter", "wakewordId": null, "lang": null}(oder eben gleich nur "up" bzw. "down", vermutlich (!) ist es egal, grade machen wir ja auch nur pauschal "upward" in der cfg...)

Schritt 3 könnte dann ggf. auf den ganzen Schnickschnack verzichten, und einfach (per änderbarem default) unterstellen, dass ein genericDeviceType speaker eben einen passenden setter bzw. ein passendes Reading hat... (entsprechend für blind oder light)

Der Weg wäre dann:
- Usern mitteilen, dass sie zukünftig die englischen Schlüsselbegriffe liefern sollen.
- Übersetzungen wieder "ins Modul" (aus der cfg) nehmen, im Code dann immer zuerst prüfen, ob wir schon ein passendes Schlüsselwort geliefert bekommen => keine Umwege, Fremdsprachler können direkt die englischen Begriffe liefern...
(Wenn nein: Komfort für die heutigen Nutzer: mit der internen "Tabelle" übersetzen...)

Hoffe, es ist jetzt klarer, dass ich _glaube_, dass die Übersetzung schon auf der Rhasspy-Seite erfolgen sollte. Das ist zwar eventuell im ersten Moment etwas schwieriger/umständlicher zu konfigurieren, aber - soweit ich das beurteilen kann - die Mehraufwände scheinen relativ moderat zu sein, und man muss sowieso vieles manuell konfigurieren, damit die Erkennung passt...?

Was wir ggf. noch bräuchten, wäre eine Art qualifizierter Rückmeldung, damit man Typos etc. leichter findet?

[drhirn]

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

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 .

Aber das mit dem genericDeviceType ist eigentlich eine gute Idee!

[drhirn]

Zeile 1354 bei dir:

#Beta-User: könnte effizienter notiert werden, wenn sicher ist, dass es nur diese beiden $type geben kann...

Es kann nur diese beiden Typen geben.