Perl - Modul 10_RHASSPY.pm "professionalisieren"

[drhirn]

Code Auswählen Erweitern

RHASSPY: [Rhasspy] Parse (MQTT2_CLIENT : 'rhasspyMQTT2'): Msg: hermes/intent/de.fhem_SetOnOff => {"input": "lampe wohnzimmer an", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "lampe"}, "slotName": "Device", "rawValue": "lampe", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "wohnzimmer"}, "slotName": "Room", "rawValue": "wohnzimmer", "confidence": 1.0, "range": {"start": 6, "end": 16, "rawStart": 6, "rawEnd": 16}}, {"entity": "OnOffValue", "value": {"kind": "Unknown", "value": "an"}, "slotName": "Value", "rawValue": "ein", "confidence": 1.0, "range": {"start": 17, "end": 19, "rawStart": 17, "rawEnd": 20}}], "sessionId": "wohnzimmer-snowboy-36079a54-2f9f-4f14-a4c0-294511c4c5e6", "customData": null, "asrTokens": [[{"value": "lampe", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "wohnzimmer", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 16, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 17, "rangeEnd": 19, "time": null}]], "asrConfidence": null, "rawInput": "lampe wohnzimmer ein", "wakewordId": "snowboy", "lang": null}

[Beta-User]

Hmm, kommt aus #499 von M2C...

Eher schwierig zu ändern... Wenn es sein müßte, könnte man nur die Umkehr-Anweisung absetzen, bevor man onmessage aufruft. Die Frage ist aber, ob das lohnt, denn eigentlich steckt die Info dann ja nochmal in der Payload. Von daher wäre eher die Frage, ob man es von da nimmt?

[drhirn]

Von daher wäre eher die Frage, ob man es von da nimmt?

Verstehe ich nicht. Von wo soll man's nehmen?

Wir könnten auch einfach die Intent-Namen umbauen. Der Grund für den Doppelpunkt war beim Snips-Modul, dass man Snips-Intents von FHEM-Intents unterscheiden konnte. FHEM behandelt nur die mit Doppelpunkt. Das doofe ist, so ein Unterstrich ist halt sehr verbreitet. Und ich kann mir die Anfragen schon vorstellen, warum der Intent jetzt von Rhasspy und FHEM gleichzeitig angenommen wurde.

[drhirn]

Die gute Nachricht ist, wenn ich in RHASSPY_onmessage die Doppelpunkt durch Unterstriche ersetze, scheint das ganz gut zu funktionieren.

[Beta-User]

[hat sich weitestgehend erledigt, selber Gedanke]
Da habe ich jetzt Schwierigkeiten, den Hintergrund zu verstehen. Unterscheiden sich Sende- und Empfangsrichtung nur dadurch, dass "snips" den Doppelpunkt im Topic verwendet und FHEM den "_"? Das wäre in der Tat schwierig.

Sonst habe ich nur das Problem gefunden, dass die Weiterverarbeitung nicht läuft mangels match im Topic.

Beiseitigt die beigefügte Version dieses Problem?

[drhirn]

Nun, möchte man Intents von Rhasspy/Snips selbst intepretieren lassen (für z.B. Sachen, mit denen FHEM nichts zu tun hat), muss man irgendwie unterscheiden, welche Intents für Rhasspy und welche für FHEM sind. Die beiden abonnieren ja das selbe Topic (hermes/intent/+). Deswegen hat das Snips-Modul nur Intents mit Doppelpunkt verarbeitet. Alle anderen hat Snips (die Python Software) verarbeitet.
Mit Sende-/Empfangsrichtung hat das nichts zu tun. Geht nur um's Empfangen.

Die neue Version "behebt" das Problem, ja.

[Beta-User]

Ginge das nicht akkurater über "..[.]fhem[:_]"?

(Tappe da aber ziemlich im Nebel, nicht allzu ernst nehmen...)
Jedenfalls wollte Rudi den Doppelpunkt nicht (und ich selbst finde allgemein Sonderzeichen im Topic nicht gut).

Haben wir denn jetzt ein erntshaftes Problem oder eher nicht?

(Allg. Anmerkung noch: diese hart vercodeten Topics finde ich seltsam, aber vermutlich geht das nur mir so...?)

[drhirn]

Könnte man natürlich so auch machen. Das "fhem" alleine sollte ja reichen. Das in Rhasspy zu ändern (also den Doppelpunkt rausnehmen) ist überhaupt kein Problem. Verstehe Rudis Ansicht vollkommen. Somit haben wir kein Problem

Das einzige Problem ist, dass die von dir verwendete Modul-Version nicht mehr die aktuellste war. Jetzt muss ich irgendwie rausfinden, wie ich das in GitHub richtig mergen kann

Wie meinst du hart vercodeten Topics? Die drei @topics?

[drhirn]

Mein Hirn versagt gerade, brauche nochmal deine Hilfe.

Code Auswählen Erweitern

qr/^hermes\/intent\/.*[:_]/
filtert ja brav den Intent-Namen "de.fhem:GetTime"

Wie müsste es bei "de.fhem.GetTime" (ohne Doppelpunkt) heißen, wenn ich auf ".fhem." filtern will? Oder von mir aus "_fhem_" weil der Punkt in Regexen ja wieder schwierig ist?

[Beta-User]

...sollte normales regex sein. Mit sowas sollten sich alle Fälle erschlagen lassen:

Code Auswählen Erweitern

qr/^hermes\/intent\/.*[._]fhem[.:_]/
Details siehe regex101.com.

Dann warte ich jetzt mal, bis du alles auf Stand hast.

Vermutlich ist es einfacher, ein diff zu erzeugen zwischen deiner github-Version und deiner aktuellsten und diesen dann in diese Fassung hier einzuarbeiten.

[drhirn]

Ja, hätte ich auch geglaubt. Tut aber leider nicht.

Egal, ich führ das alles mal zusammen und kümmer mich dann darum.

[drhirn]

https://github.com/drhirn/fhem-rhasspy/blob/testing/10_RHASSPY.pm

Das sieht jetzt mal sehr gut aus. Funktioniert soweit alles.
Was mir aber auffällt: Sobald ich das Rhasspy-Device definiere, aktualisiert sich FHEMWEB nicht mehr automatisch. Muss immer auf F5 drücken, um die aktuellen Readings/States/etc. zu sehen. Kennst du das Problem?

[Beta-User]

Keine Idee, was das für Einflüsse auf FHEMWEB haben könnte. Betrifft das nur das RHASSPY-Device oder allgemein? (Wenn ersteres: kann sein, dass da manche Readings nur aktualisiert werden, wenn MQTT als IO verwendet wird).

Ansonsten sollte es eher mit etwas anderem zu tun haben.




Mit "harten" topics war @topics gemeint, ja. Ist das immer richtig?


Generell: War das ein Startschuss in Richtung "bau 00_MQTT aus..."?
Vermutlich sollte man erst noch etwas testen, ich würde da noch etwas abwarten.

[drhirn]

Keine Idee, was das für Einflüsse auf FHEMWEB haben könnte. Betrifft das nur das RHASSPY-Device oder allgemein? (Wenn ersteres: kann sein, dass da manche Readings nur aktualisiert werden, wenn MQTT als IO verwendet wird).

Es ist definitiv das Rhasspy-Device schuld. Sobald ich das lösche, ist alles wieder normal.
Betrifft nicht nur Readings aus dem Rhasspy-Device, sondern alle anderen Devices auch. Irgendwas scheint das Longpolling/Websocket zu stören.
Passiert seit unseren Änderungen gestern.

Die @topics sind immer richtig, ja.

00_MQTT können wir schon ausbauen. Die 4 User, die das Modul verwenden haben ja noch die master-Branch zur Verfügung.

[drhirn]

Die Branch 0.2.0 ist übrigens die aktuelle MQTT2_DEVICE Branch