Perl - Modul 10_RHASSPY.pm "professionalisieren"

[Beta-User]

Hmm, ok, dann muss ich wohl mal downgraden... Hatte jetzt eher vermutet, dass 5.32.x Probleme macht, weil "will be fatal in ..." da true ist . (es gab da ein paar verdächtige regexe, "unescaped left brace..." und so...)

lampe2 bekomme ich mit RHASSPY geschaltet, "longpoll-los", versteht sich, es steht NIX im log (verbose 3). Aber damit kann ich zumindest das durchreichen versuchen nachzuvollziehen.

Bzgl. Fremdsprachen: https://forum.fhem.de/index.php/topic,119044.0.html
(Es geht da wirklich eher darum, gewisse Optionen generell vorzusehen, die dann ggf. "recht einfach" von den Usern angepaßt werden können, wenn man sie denn braucht; der Aufwand, das zu implementieren, sollte halt im Rahmen bleiben. Ein zentraler Hash hat zudem den Vorteil, dass man das auch einfacher pflegen kann, wie wenn es überall verstreut ist).

[drhirn]

Dass die Franzosen immer davon ausgehen, dass man sie eh versteht, fasziniert mich schon einigermaßen...

Aber du rennst diesbezüglich bei mir offene Türen ein. Ich seh das einfach nur als "Verbesserung". Priorität hat bei mir derzeit eher "Fehlerfreiwerdung".

[Beta-User]

Nachdem es mir auch gelungen ist, FHEM mit passender Testsmessage abzuschießen, vorab erst mal  eine, bei der das zumindest auf dem 5.32.1 dann nicht mehr passiert war, hoffe, das ist auch 5.28-kompatibel... (da ist trotzdem ein 1-er Warning im Log, aber darum können wir uns später kümmern).

Da ist jetzt am Ende von Parse eine Zeile drin, die uns ins log schreibt, was denn von Parse() zurückgeliefert wird. Bei MGB ist es der Name (bzw. die Namen) des angesteuerten Devices, und so sollte das auch hier sein. Wäre nett, wenn du das kurz testen könntest.

[drhirn]

Guten Morgen!

Stürzt jetzt nicht mehr ab.

Hier das Rhasspy-Log:

Code Auswählen Erweitern


2021.02.24 08:08:29.091 5: Parsed value: wohnzimmer-snowboy-d7762105-c690-44bd-9b39-61d92274ad69 for key: sessionId
2021.02.24 08:08:29.091 5: Parsed value: wohnzimmer for key: siteId
2021.02.24 08:08:29.091 5: mutated_vowels regex is SCALAR(0x5605cc54fe10)
2021.02.24 08:08:29.092 5: RHASSPY: [Rhasspy] Parse returned ARRAY(0x5605cc62e000)
2021.02.24 08:08:32.186 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetOnOff => {"input": "deckenlampe an", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "deckenlampe"}, "slotName": "Device", "rawValue": "deckenlampe", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "rawEnd": 11}}, {"entity": "OnOffValue", "value": {"kind": "Unknown", "value": "an"}, "slotName": "Value", "rawValue": "ein", "confidence": 1.0, "range": {"start": 12, "end": 14, "rawStart": 12, "rawEnd": 15}}], "sessionId": "wohnzimmer-snowboy-d7762105-c690-44bd-9b39-61d92274ad69", "customData": null, "asrTokens": [[{"value": "deckenlampe", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 14, "time": null}]], "asrConfidence": null, "rawInput": "deckenlampe ein", "wakewordId": "snowboy", "lang": null}
2021.02.24 08:08:32.186 5: Parsed value: wohnzimmer-snowboy-d7762105-c690-44bd-9b39-61d92274ad69 for key: sessionId
2021.02.24 08:08:32.187 5: Parsed value: wohnzimmer for key: siteId
2021.02.24 08:08:32.187 5: Parsed value: an for key: Value
2021.02.24 08:08:32.187 5: Parsed value: SetOnOff for key: intent
2021.02.24 08:08:32.187 5: Parsed value: deckenlampe for key: Device
2021.02.24 08:08:32.187 5: Parsed value: 1 for key: probability
2021.02.24 08:08:32.187 5: Parsed value: deckenlampe an for key: input
2021.02.24 08:08:32.187 5: Parsed value: deckenlampe ein for key: rawInput
2021.02.24 08:08:32.188 5: handleIntentSetOnOff called
2021.02.24 08:08:32.188 5: Device selected: lampe1
2021.02.24 08:08:32.188 5: rhasspyMapping selected: cmdOn=on,cmdOff=off
2021.02.24 08:08:32.188 5: Running command [on] on device [lampe1]
2021.02.24 08:08:32.189 5: RHASSPY: [Rhasspy] Parse returned ARRAY(0x5605cc781420)
2021.02.24 08:08:32.979 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-snowboy-d7762105-c690-44bd-9b39-61d92274ad69", "siteId": "wohnzimmer", "customData": "snowboy"}
2021.02.24 08:08:32.979 5: Parsed value: wohnzimmer for key: siteId
2021.02.24 08:08:32.979 5: Parsed value: wohnzimmer-snowboy-d7762105-c690-44bd-9b39-61d92274ad69 for key: sessionId
2021.02.24 08:08:32.979 5: mutated_vowels regex is SCALAR(0x5605cc54fe10)
2021.02.24 08:08:32.980 5: RHASSPY: [Rhasspy] Parse returned ARRAY(0x5605cc62d670)


[Beta-User]

Hmm, irgendwo ging $device verloren, da war so eine "definiere mal vorsorglich ein paar Variablen"-Orgie im Weg...
So triggern dann auch wieder die Updates am Zieldevice.

Dann gibt es eine "sort_unique", könnte man vermutlich ausbauen, um das ganze gleich mit länger vor kürzer zu bekommen...? (Falls es auch in größerem Maßstab funktioniert => auch an anderer Stelle "recyceln").

Den Hash-lookup habe ich erst mal deaktiviert, damit keiner Anlass hat, sich über unnötige Logeinträge zu beschweren.

Irgendwie bin ich grade am überlegen, ob es jetzt nicht an der Zeit wäre, onmessage() (teilweise?) in Parse() zu integrieren, aber onmessage ist angeblich schon "high complexity", von daher sollte man das wohl eher zwar tun, dabei aber die Sache eher vereinfachen (durch Aufruf "speziellerer" Subs)...

Tendenziell würde ich mich jetzt erst mal wieder zurückhalten und mal abwarten, was dir selbst zum Code noch einfällt (unterstellt, das funktioniert erst mal alles soweit wieder zur Zufriedenheit)?

[Beta-User]

Hm, einen habe ich doch noch, nämlich das mit der anonymen sub in RHASSPY_ReplaceReadingsVal()...

Auch das scheint zu funktionieren, viel mehr weiß ich mal wieder nicht .

[drhirn]

Woooooow, jetzt funktioniert's wirklich wieder. Das Update der Devices mein ich.  Danke!

Meine To-Dos sind momentan:

1. überlegen, was ich zu Mittag esse
2. versuchen, deine ganzen Verbesserungen zu verstehen
3. den Timer verbessern
4. überprüfen, warum die FHEM-Befehle bei Shortcuts nicht mehr ausgeführt werden
5. Code aufräumen

Dazu eine Frage:
Wenn ich da wirklich siteIDs auslesen soll, wie das im anderen Thread überlegt wurde, sollte ich das fast bei Initalisierung des Moduls machen. Wie verpönt ist das? Und wie gehe ich das am Besten (=FHEM konformsten) an?

[drhirn]

Hm, einen habe ich doch noch, nämlich das mit der anonymen sub in RHASSPY_ReplaceReadingsVal()...

Haha, perfekt! Die wollte ich auch schon mal angehen. Aber keine Ahnung, was die tut. Jetzt erspar ich mir das

[Beta-User]

Woooooow, jetzt funktioniert's wirklich wieder. Das Update der Devices mein ich.  Danke!

Danke für die Rückmeldung!

Dann ist der wichtigste Schritt in Richtung 0.3 wohl gegangen...?

Meine To-Dos sind momentan:

1. überlegen, was ich zu Mittag esse
2. versuchen, deine ganzen Verbesserungen zu verstehen
3. den Timer verbessern
4. überprüfen, warum die FHEM-Befehle bei Shortcuts nicht mehr ausgeführt werden
5. Code aufräumen

Dazu eine Frage:
Wenn ich da wirklich siteIDs auslesen soll, wie das im anderen Thread überlegt wurde, sollte ich das fast bei Initalisierung des Moduls machen. Wie verpönt ist das? Und wie gehe ich das am Besten (=FHEM konformsten) an?

Vermutlich wird 4. recht einfach zu lösen sein, wenn du durch 2. mal soweit durch bist (das ist nur eine vage Vermutung). Das mit dem Aufräumen geht dann vermutlich auch "nebenbei". Dabei halt aufpassen, ob das, was die Prototypes suggerieren auch richtig ist (siehe unseren Attribute-Fall).

Was mehrere Sprachen/RHASSPY-Instanzen angeht, hatte ich auch schon die Frage im Hinterkopf, ob es nicht sinnvoll wäre, das ähnlich zu machen wie bei MGB: Da kann man für jede Instanz ein eigenes "MQTT-Präfix" definieren, das dann in den (global verfügbaren) Attributnamen wieder auftaucht. Fände ich für Schritt 1 erst mal gut (die Notation in MGB mit den Konstanten gefällt mir dagegen nicht so sehr).
MGB "sammelt" bei der Initialisierung auch erst mal alles ein, das wäre vermutlich auch für RHASSPY eine gute Idee, wobei das ziemlich "Bauchgefühl" ist, denn so ganz verstanden habe ich die Zusammenhänge noch nicht.

Weiter fand ich es "befremdlich", bei einem "onOff"-Device überhaupt ein Mapping angeben zu müssen (jedenfalls war es bei dem Muster-dummy dabei, was mir suggeriert, man würde es benötigen). Ich würde mal pauschal annehmen, dass das der Default für alle Devices ist. Eventuell schwirren dann noch Stichworte wie genericDeviceType im Raum, wobei ich noch keine Idee habe, wie und wo man das nutzen kann...

Ggf. solltest du dir mal jsonlist und jsonlist2 zu Gemüte führen.

Aber Rom und so, erst mal guten Appetit!

Haha, perfekt! Die wollte ich auch schon mal angehen. Aber keine Ahnung, was die tut. Jetzt erspar ich mir das

Ersetzungen vornehmen. Aber das Ding sah' von der Struktur her "schwierig" aus (eher: man muß wissen, nach was man sucht, um es umzubauen), deswegen dachte ich, es würde dir gefallen, wenn es von der Liste käme... Deiner Rückmeldung entnehme ich, dass auch der Teil weiter funktioniert?

[drhirn]

Dann ist der wichtigste Schritt in Richtung 0.3 wohl gegangen...?

Eindeutig.

Vermutlich wird 4. recht einfach zu lösen sein, wenn du durch 2. mal soweit durch bist (das ist nur eine vage Vermutung).

2 wird länger dauern
4 dürfte in der Tat eher leicht sein. Das Kommando wird richtig gebaut, kommt aber irgendwie falsch an. Tippe auf ein "Umwandlungsproblem" der geschwungenen Klammern.

Was mehrere Sprachen/RHASSPY-Instanzen angeht, hatte ich auch schon die Frage im Hinterkopf, ob es nicht sinnvoll wäre, das ähnlich zu machen wie bei MGB: Da kann man für jede Instanz ein eigenes "MQTT-Präfix" definieren, das dann in den (global verfügbaren) Attributnamen wieder auftaucht.

Klingt nach einem guten Plan!

Weiter fand ich es "befremdlich", bei einem "onOff"-Device überhaupt ein Mapping angeben zu müssen (jedenfalls war es bei dem Muster-dummy dabei, was mir suggeriert, man würde es benötigen). Ich würde mal pauschal annehmen, dass das der Default für alle Devices ist. Eventuell schwirren dann noch Stichworte wie genericDeviceType im Raum, wobei ich noch keine Idee habe, wie und wo man das nutzen kann...

Das Mapping ist keine Pflicht. Du kannst ohne halt den Status des Gerät nicht abfragen .
Warum Thyraz das damals so gelöst hat, weiß ich nicht. Ich schätze mal, um flexibel zu bleiben. Es soll ja Geräte geben, deren "Ein-Status" nicht "on" ist.

Ggf. solltest du dir mal jsonlist und jsonlist2 zu Gemüte führen.

Kenn ich ausnahmsweise mal beide
Warum?

Aber das Ding sah' von der Struktur her "schwierig" aus (eher: man muß wissen, nach was man sucht, um es umzubauen), deswegen dachte ich, es würde dir gefallen, wenn es von der Liste käme... Deiner Rückmeldung entnehme ich, dass auch der Teil weiter funktioniert?

Mir ist in einem Kurztest nichts Negatives aufgefallen. Bin mir halt nicht sicher, warum Thyraz eine abgespeckte Variante gebaut hat. Und nicht-sprechende Variablen sind halt ein bisschen mühsam .

[Beta-User]

4 dürfte in der Tat eher leicht sein. Das Kommando wird richtig gebaut, kommt aber irgendwie falsch an. Tippe auf ein "Umwandlungsproblem" der geschwungenen Klammern.

Falls ich was beitragen kann, bräuchte ich eine Anleitung für dummies und passende topic/payload-Schnipsel + RAW-defs .

Klingt nach einem guten Plan!

Dann wäre auch hier Schritt 1, alle Vorkommen des Präfixes im Code durch eine entsprechende Variable zu ersetzen. Die kann dann aus der DEF kommen, Code dazu fände sich in MGB (btw.: die cref von RHASSPY ist an der Stelle überholt).

Das Mapping ist keine Pflicht. Du kannst ohne halt den Status des Gerät nicht abfragen .

Na ja, wenn man als default von einen onOff-Gerät und on bzw. off (als lc(state)) ausgeht, sollte das häufig schon befriedigende Ergebnisse erbringen...

Warum Thyraz das damals so gelöst hat, weiß ich nicht. Ich schätze mal, um flexibel zu bleiben. Es soll ja Geräte geben, deren "Ein-Status" nicht "on" ist.

Man könnte ihn fragen. Aber es spricht ja nichts dagegen, eine Mapping-Option zu haben, nur eben nicht verpflichtend, sondern "//" .

Kenn ich ausnahmsweise mal beide
Warum?

Ich hatte die lange nicht auf dem Radar . Darüber bekommst du Rückmeldung, welche Setter ein Device hat, so dass darüber auch rauszubekommen sein sollte, ob onOff zulässig ist, ohne dass man es explizit in irgendeinem mapping angibt...

Mir ist in einem Kurztest nichts Negatives aufgefallen. Bin mir halt nicht sicher, warum Thyraz eine abgespeckte Variante gebaut hat. Und nicht-sprechende Variablen sind halt ein bisschen mühsam .

Den Grund kenne ich auch nicht (s.o.), aber der Code kam mir an der Stelle irgendwie verbogen vor, daher der Versuch, das funktionsgleich "sauber" zu machen. Ob es Abgespeckt war, hat mich an der Stelle nicht unbedingt interessiert.
Die Adressierung ist aber mAn. weiter eindeutig und hinreichend "sprechend", da ist kein wesentlicher Unterschied zu vorher (außer, dass man die "interne sub" jetzt nicht mehr versehentlich "von außen" ansprechen kann (früher: in main!)...

(@JensS als potentiellem "Tester":
Ich höre deine Skepsis, was die massiven Umbauten angeht, nehme aber an, dass zwischenzeitlich halbwegs klar ist, dass das packaging das Gefahrenpotential eher verkleinern sollte...
Die Sub's betr. genericDeviceType habe ich gesehen, werde aber erst mal zuwarten, ob/welche Ideen da von eurer Seite kommen. Zum Hintergrund: ich kenne das ganze Thema Sprachsteuerung  nur vom Hörensagen und kann daher diese ganzen Dinge nicht wirklich gut einordnen und hatte auch auf die Schnelle nicht die zündende Idee, wo die Funktionen grade andocken (aber auch nicht lange nachgedacht)...).

Werde jetzt wie gesagt erst mal zuwarten. Falls konkrete Fragen sind, bitte einfach stellen, ihr seht ja auch an der Rückmeldung von Wzut und betateilchen, dass durchaus der eine oder andere mitliest, der ggf. sogar besser helfen kann.

[drhirn]

Sodala, los geht's

Bezüglich Shortcuts hast du zu viele Parameter als Pflicht angenommen und mir "// return" abgebrochen, wenn die nicht da waren. Deshalb wurden die nie ausgeführt.

Da mal der aktuelle Code: https://github.com/drhirn/fhem-rhasspy/blob/testing/10_RHASSPY.pm

Ich hab das wieder hin gebogen. Es funktioniert alles.

Allerdings hab ich da wieder das "Status-Ändert-Sich-Nicht"-Problem beim geschalteten Device. Mir ist ja inzwischen klar, warum. Aber ich hab noch nicht ganz verstanden, wie ich das lösen könnte. Auch in Anbetracht dessen, dass ein Shortcut nicht immer ein FHEM-Befehl sein muss.
Selbiges übrigens auch mit set textCommand ..

Die Shortcuts werden im 10_Rhasspy-Device angelegt, deswegen hier nur ein Attribut:

Code Auswählen Erweitern


attr Rhasspy shortcuts ton aus={fhem ("set RXV777 off")}\
ton an={fhem ("set RXV777 on")}\
du bist cool={fhem ("set Rhasspy speak siteId='wohnzimmer' text='Danke du auch'")}


MSG:

Code Auswählen Erweitern


Msg: hermes/intent/de.fhem_Shortcuts => {"input": "ton an", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-snowboy-4f44e811-513a-4f44-9144-97b7b221f66f", "customData": null, "asrTokens": [[{"value": "ton", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 6, "time": null}]], "asrConfidence": null, "rawInput": "ton an", "wakewordId": "snowboy", "lang": null}


Darf ich dich diesbezüglich nochmal aus der "Rente" zurück holen?

[Beta-User]

  Perl-defined-or scheint also zwischenzeitlich klar zu sein .

Das Aktualisierungs-Thema ist da tieferliegend.

Erste Maßnahme sollte wohl sein, dafür zu sorgen, dass immer zumindest der Name der RHASSPY-Instanz zurückgeliefert wird, das passiert vermutlich im Moment gar nicht.

Ein paar (ggf. nicht vollständig durchdachte) Ansatzpunkte im Anhang. Grundproblem bleibt, dass wir eigentlich irgendwie das geschaltete Device ermitteln müßten. Ist aber schwierig zu konfigurieren. Die Alternative könnte sein, den Shortcut-Befehl mit einem InternalTimer Aufzurufen, dann wäre Parse() beendet, wenn das Device effektiv geschalten wird...

[Beta-User]

Ist aber schwierig zu konfigurieren.

Hab' mir den shortcut-Pfad mal angesehen. Tendenziell würde ich die ganze Syntax und auch den Ablauf ändern...
Skizze:
- Gleich bei der Attribut-Eingabe einen Parser drüberlaufen lassen, der
-- einen hash erstellt mit den shortcuts;
-- ggf. einen Syntax-Check macht, wo Perl angesagt ist;
-- unterscheiden kann zwischen Perl-Anweisungen und fhem-Kommandos;
-- ein "Rückgabedevice" erlaubt (sonst den Namen der Instanz).

Syntax eventuell in diese Richtung (ungetestet, sollte ggf. ParseParams-kompatibel sein):

Code Auswählen Erweitern

attr Rhasspy shortcuts i="ton aus" f="set RXV777 off" n=RXV777\
i="ton an" f="set $NAME on" n=RXV777\
i="du bist cool" f="set $NAME speak siteId='wohnzimmer' text='Danke du auch'"\
i="führe Perl myFunction aus" p='myFunction("argument")' n="device1,device2"

(Alte Syntax könnte man dann mit dem split in "i" und "p" trennen). ggf. könnte man noch "r" erlauben für eine bestimmte Rückgabe/ein response-pattern).

- Dann müßte man halt die Aufrufe ändern etc...
- und vorher noch EvalSpecials drüberlaufen lassen, damit manche Parameter aufgelöst werden können (ist einfacher portierbar, aber nicht zwingend).

Grundsätzlich die richtige Richtung oder zu kompliziert?

[drhirn]

Ist schon kompliziert und fehleranfällig.
Im Grunde sind die Shortcuts ja eigentlich auch nur ein Intent. Und deswegen gehört das eigentlich sowieso aus "onmessage" raus. Damit hätten wir das Problem eventuell schon gelöst. So die kurze Überlegung gestern vor'm Einschlafen.

Ich bin nur unglücklicherweise heute morgen von meinem Arbeitgeber ordentlich mit Arbeit eingedeckt worden. Das verhindert momentan eine ausgiebige Beschäftigung mit dem interessanteren Thema FHEM + Rhasspy