FHEM Forum

Hi Rudi, (oder ein anderer "Wissender"),

habe etwas mit dem RHASSPY-Modul "gespielt" und das kompatibel zu dem MQTT2-IOs gemacht.
Über clientOrder kann man Geräte dieses TYPE auch beiden IO's (M2S und M2C) als Client unterschieben, soweit kein Problem.

Jetzt gibt es Berichte, dass das Modul in der aktuellen Form longpoll verhindert/ausknipst (was unter 00_MQTT.pm nicht der Fall war), und ich habe keine Idee, was die Ursache dafür sein kann, zumal das entweder nur CLIENT betrifft (und nicht SERVER), oder irgendwas zu tun hat mit der Interaktion mit der Gegenstelle (ein Spracherkennungsdienst, der vom fraglichen Modul neben MQTT auch mit httputils angesprochen wird).

Den eigentlichen Thread dazu findest du unter https://forum.fhem.de/index.php/topic,118926.0.html (https://forum.fhem.de/index.php/topic,118926.0.html) samt Link zum aktuellen Modulcode.
Meine erste Vermutung, es könnte ein nicht beendeter bulk-update sein, hat sich nicht bestätigt, das war alles sauber...

Danke vorab für's schauen!

Ich sehe mit folgendem fhem.cfg keine longpoll Probleme:
define w FHEMWEB 8083 global
define t telnet 7072

define m2s MQTT2_SERVER 1883
define rs RHASSPY m2s BLAroom
define d dummy
attr d room BLAroom


Ich habe auch die 50+ Beitraege im verlinkten Thread durchgelesen, hat aber nicht geholfen.
Bin nichtmal sicher, dass ich die richtige Version des Moduls heruntergeladen habe :)

Wenn ich helfen soll, dann brauche ich eine genaue Anleitung zum Nachstellen.

Danke für's Einklinken Rudi!

Die richtige Version ist die 0.2.0: https://github.com/drhirn/fhem-rhasspy/blob/0.2.0/10_RHASSPY.pm
Dir fehlt noch ein MQTT2_CLIENT, kann das sein?

Das Longpoll nicht geht ist nur eine Vermutung von mir. Sobald ich das Rhasspy-Device initialisiert habe, sehe ich in FHEMWEB keine aktuellen Zustände mehr, sondern muss immer die Seite aktualisieren (F5). Lösche ich das Device wieder, geht alles ganz normal.
Ich habe beim Attribut longpoll in FHEMWEB sowohl "1" als auch "websocket" versucht. Das macht keinen Unterschied.

Mit der master-Branch (https://github.com/drhirn/fhem-rhasspy/blob/master/10_RHASSPY.pm) (basiert auf 00_MQTT), gibt's das Verhalten nicht. Funktionell gibt's zwischen master und 0.2.0 kaum Unterschiede. Nur eben den Umbau auf MQTT2_DEVICE.

Hier meine DEFs (als quasi Anleitung). Keine Hexerei.


defmod rhasspyMQTT2 MQTT2_CLIENT rhasspy:12183
attr rhasspyMQTT2 clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICE



defmod Rhasspy RHASSPY rhasspyMQTT2 Wohnzimmer
attr Rhasspy IODev rhasspyMQTT2


Auch von meiner Seite Danke für's drübersehen, und sorry für den etwas unpräzisen  Link

Wie geschrieben: bei meinem eigenen Test mit der Modulfassung aus dem git von drhirn iVm. M2S hatte ich auch keine Auffälligkeiten feststellen können, aber auch den Dienst nicht am laufen.

@drhirn:
- Tritt das auch auf, wenn du einen "falschen" Port im M2C angibst? (Dann könnte man zumindest mal ableiten, ob es mit der Verbindung zur Gegenstelle zu tun hat (M2C<=>mosquitto) oder mit dem Modul an sich (RHASSPY<=>M2C))...

- Und: Interessant wäre ggf. noch, ob das auch auftritt, wenn man statt M2C+mosquitto M2S nutzt. (Man kann doch den docker-internen mosquitto durch was externes ersetzen, wenn ich das richtig interpretiere?) Das umgebaute RHASSPY-Modul sollte auch mit M2S funktionieren...

Mit einem falschen Port kann ich nichts mehr testen ;)

Aber, es tritt auch mit folgender Config auf:


defmod MQTT2_SERVER MQTT2_SERVER 1883 global
attr MQTT2_SERVER autocreate no



defmod rhasspyMQTT2 MQTT2_CLIENT fhem-test:1883
attr rhasspyMQTT2 clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICE



defmod Rhasspy RHASSPY rhasspyMQTT2 Wohnzimmer
attr Rhasspy IODev rhasspyMQTT2


Also wenn ich alles über FHEM abwickle. Was übrigens keine so gute Idee ist, weil Rhasspy enorm Traffic verursacht. Alles, was durch's Mikro rennt, wird an die Base übertragen, die dann die Verarbeitung macht. Da kommt schon was zusammen.

Dass dann die Verbindung zum Dienst kaputt ist, ist klar.

Demnach liegt es an der Interaktion zwischen RHASSPY und CLIENT. Das mAn. einzige, was beide (M2S und M2C, im RHASSPY-Modul) unterscheidet, ist die ausdrückliche Mitteilung der subscriptions. => kannst du mal testen, was passiert, wenn du das am RHASSPY-Modul auskommentierst und dann das ganze wieder auf den richtigen Port legst?
Kann sein, dass dann die Kommunikation nicht klappt, aber dann haben wir es wenigstens eingegrenzt...

Zitat von: drhirn am 21 Februar 2021, 09:30:49
...Alles, was durch's Mikro rennt, wird an die Base übertragen, die dann die Verarbeitung macht. Da kommt schon was zusammen.

Was vom Mikro kommt geht jeweils lokal zum Wakeword-Detector. Erst nach Erkennung des Wakewords wird die gesprochene Anweisung zur Base übertragen. Diese überträgt dann die Antwort per MQTT an die Satelliten.
Gruß Jens

Zitat von: JensS am 21 Februar 2021, 09:44:13
Was vom Mikro kommt geht jeweils lokal zum Wakeword-Detector. Erst nach Erkennung des Wakewords wird die gesprochene Anweisung zur Base übertragen. Diese überträgt dann die Antwort per MQTT an die Satelliten.

Wenn UDP in Rhasspy konfiguriert ist, ja. Sobald der Satellit das Wakeword aber erkannt hat, läuft alles Audio zur Base, bis die den Befehl an den Satelliten erteilt, nicht mehr zuzuhören.

Zitat von: Beta-User am 21 Februar 2021, 09:37:28
Das mAn. einzige, was beide (M2S und M2C, im RHASSPY-Modul) unterscheidet, ist die ausdrückliche Mitteilung der subscriptions. => kannst du mal testen, was passiert, wenn du das am RHASSPY-Modul auskommentierst und dann das ganze wieder auf den richtigen Port legst?

Ich weiß jetzt leider nicht, was genau du meinst. Also was ich auskommentieren soll.

Zitat von: drhirn am 21 Februar 2021, 09:49:51
Ich weiß jetzt leider nicht, was genau du meinst. Also was ich auskommentieren soll.

indirekt: Zeile 140:
RHASSPY_subscribeTopics($hash) if isIODevMQTT2_CLIENT($hash);

oder direkt: Zeile 245:
IOWrite($hash, 'subscriptions', join(' ', @topics));

Macht keinen Unterschied.

Es ist halt unglaublich schwer zu debuggen. Und es hängt nicht Longpoll generell wie ich gerade festgestellt habe. Ich bin mir ziemlich sicher, dass gestern ein "set lampe1 on" in der Kommandozeile von FHEM die Readings der Lampe nicht geändert hat. Erst nach einem Reload der Seite. Das funktioniert aber heute irritierenderweise. Ebenso mit einem DOIF, das ich gerade zu Testzwecken geschrieben habe. Auch damit werden die Readings der Lampe ohne Aktualisierung der Seite gesetzt.

Setze ich aber z.B. ein
set Rhasspy textCommand lampe ein
ab (was ebenfall ein "set lampe1 on" bewirkt), muss ich die Seite der Lampe manuell aktualisieren. Geschalten wurde sie aber.

Die Aussage oben war falsch. Muss weiter testen.

OK, dann scheint die story etwas anders zu sein als zunächst verstanden: Es geht nur um die Sichtbarkeit von Änderungen, die durch RHASSPY veranlaßt wurden, NICHT um irgendwas, was außerhalb stattfindet...?

Ich werd' mir das bei Gelegenheit mal ansehen. Irgendwo beim Improt habe ich auch "fhem" als Funktion gesehen; das sollte man m.E. eher über AnayzeCommand() (?) oder CommandSet()/CommandSetReading() lösen...

---

Ad Nachtrag: Kommen denn Befehle in RHASSPY an?

ZitatHier meine DEFs (als quasi Anleitung). Keine Hexerei.

Stimmt, das ist aber noch lange keine Anleitung.
Habs versucht damit, natuerlich ohne Erfolg.

Bitte nicht annehmen, dass ich ueber telepatische Kraefte verfuege, alles weiss, was Ihr macht,  und durch draufschauen Probleme loese.
Lieber annehmen, ich waere ein Anfaenger, und alles Schritt fuer Schritt erklaeren.
Da ich kein Hardware habe, brauche ich vermutlich ein "attr global verbose 5" FHEM Log zusaetzlich.

Zum besseren Verständnis: Ich werde jetzt immer 10_RHASSPY schreiben, wenn ich vom FHEM-Modul rede. Und Rhasspy, wenn ich den Sprachassistenten meine.

Moment. Ich hab jetzt mal beide von dir erwähnten Zeilen auskommentiert. Warum empfängt 10_RHASSPY immer noch Befehle?

Es gibt eine Set-Funktion "trainRhasspy". Damit wird Rhasspy angewiesen, das Sprachmodell zu trainieren. Den Befehl schicke ich via "HttpUtils_NonblockingGet" an das HTTP-API von Rhasspy. Wenn das Training fertig ist, wird das Reading "lastHttpApiResponse" von 10_RHASSPY mit der Antwort befüllt. Dieses Reading aktualisiert sich magischerweise immer, ohne Reload der Seite
Das selbe mache ich bei "updateSlots". Da werden alle Device-Namen, Räume, etc. gesammelt und ebenfalls an das HTTP-API geschickt. Das Reading "lastHttpApiResponse" hat sich da aber noch nie automatisch aktualisiert. Mit noch nie meine ich, seit ich die Funktion eingebaut habe. Das ist schon lange her.

Alle anderen Readings haben mit MQTT-Subscriptions zu tun. Die aktualisieren sich seit MQTT2_DEVICE nicht mehr automatisch.

Bei meinen Test hab ich zwei Browser-Tabs offen. In einem hab ich 10_RHASSPY offen, im anderen einen Raum mit zwei Dummys. Lampe1 und Lampe2. Die werden per Sprachbefehl (oder "set Rhasspy textCommand ...") zwar korrekt geschalten, deren Status ändert sich im Browser-Tab aber eben nur, wenn ich die Seite aktualisiere.
Verwende ich im ersten Tab ein DOIF um die Lampen zu schalten, wird die Anzeige im zweiten Tab aber korrekt aktualisiert.

Soviel zu meinem Test-Verfahren.

Rudis Wünsche werden im nächsten Post erfüllt. Ich werde es zumindest versuchen.

Beim Erstellen des Logs für Rudi ist mir aufgefallen, dass MQTT2_CLIENT eiskalt die ganze MQTT-Kommunikation mithört. Und da kommt ganz schön was zusammen (Audio).
Hier ein Ausschnitt: rhasspyMQTT2: dispatch autocreate=no\000rhasspyMQTT2\000hermes/audioServer/wohnzimmer/audioFrame\000RIFF$\010\000\000WAVEfmt \020\000\000\000\001\0

Ich kann mich dunkel erinnern, dass ich vor Urzeiten (bei Snips noch) zuerst FHEM Mqtt-Server spielen habe lassen. Aber dann auf einen externen Mosquitto gewechselt bin, weil FHEM mit der Verarbeitung der ganzen Anfragen Probleme hatte. Und ich glaube, da hatte ich auch das Phänomen mit nicht aktualisierenden Readings.

Kann das sein? Und wenn ja, kann ich irgendwie verhindern, dass MQTT_CLIENT alles mithört?

Im Anhang das (riesige) Log

@Rudi:

Rhasspy (https://rhasspy.readthedocs.io/en/latest/) ist ein Sprachassistent, der aus verschiedensten Python-Modulen zusammengesetzt ist. Sämtliche dieser Teile kommunizieren via MQTT miteinander (via Hermes Protokoll).

Das 10_RHASSPY (https://github.com/drhirn/fhem-rhasspy/blob/0.2.0/10_RHASSPY.pm) Modul für FHEM macht nichts anderes, als sich in diese MQTT-Kommunikation einzuhängen und Intents auszuwerten, sofern sie nach einem gewissen Schema (z.B. de.fhem:SetOnOff) benannt sind.

Dazu muss zum einen natürlich das Modul installiert sein, zum anderen müssen auch die zu schaltenden Devices mit bestimmten Attributen versehen werden. Das sind:

• rhasspyName - Der Name, unter dem das Device angesprochen werden soll
• rhasspyRoom - Der physische Raum, in dem sich das Device befindet
• rhasspyMapping - Die Befehle, mit den das Gerät gesteuert werden kann
• room - Um vom Modul angesprochen werden zu könne, müssen die Devices im FHEM-room Rhasspy sein

Ein ganz einfaches Dummy-Device könnte z.B. so aussehen:

defmod lampe dummy
attr lampe rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off\
GetOnOff:currentVal=state,valueOff=off
attr lampe rhasspyName lampe,radio
attr lampe rhasspyRoom wohnzimmer,schlafzimmer
attr lampe room Rhasspy
attr lampe setList toggle on off


Die Logik zur Spracherkennung läuft ausschließlich in der "Rhasspy-Base" ab. Dort werden auch Slots (Devices, Räume, Farben, etc.) und Sentences/Intents (z.B. "schalte das licht ein") definiert.
Ein gültiger Intent zum Steuern obiger Lampe wäre z.B.

[de.fhem:SetOnOff]
\[schalte] lampe{Device} (an|aus){Value}

("schalte" ist optional, deswegen in eckigen Klammern; {Device} und {Value} sind "Slot-Namen", die 10_RHASSPY unter anderem auswertet; "an" und "aus" können beide verwendet werden)

Spricht man jetzt den Satz "lampe an", verarbeitet die Rhasspy-Base diesen und schickt eine MQTT-Nachricht an hermes/intent/de.fhem:SetOnOff. Die könnte z.B. so aussehen:
{"input": "lampe 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": "OnOffValue", "value": {"kind": "Unknown", "value": "an"}, "slotName": "Value", "rawValue": "an", "confidence": 1.0, "range": {"start": 6, "end": 8, "rawStart": 6, "rawEnd": 9}}], "sessionId": "wohnzimmer-snowboy-05371e8d-da8a-45ec-a7cd-859c1285c68e", "customData": null, "asrTokens": [[{"value": "radio", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 8, "time": null}]], "asrConfidence": null, "rawInput": "lampe an", "wakewordId": "snowboy", "lang": null}

10_RHASSPY weißt durch den "intentName", dass es zuständig ist. Es wertet den Inhalt aus ("Device", "Value", "siteId" oder "room" wenn vorhanden) und bastelt daraus ein FHEM-Kommando. Welches dann auch ausgeführt wird. Anschließend wird eine Antwort an hermes/dialogueManager/endSession gesendet, damit Rhasspy weiß, dass die Session abgeschlossen ist.


Um zu testen brauchst du also eine Rhasspy-Instanz. Da würde sich Docker anbieten.

docker-compose.yml:

version: '3'

services:
    rhasspy:
        image: "rhasspy/rhasspy"
        container_name: rhasspy
        restart: unless-stopped
        volumes:
            - ".config/rhasspy/profiles:/profiles"
            - "/etc/localtime:/etc/localtime:ro"
            - "/etc/asound.conf:/etc/asound.conf"
        ports:
            - "12101:12101"
            - "12183:12183"
        command: --user-profiles /profiles --profile de
        devices:
          - "/dev/snd:/dev/snd"
        ipc: host


12101 ist der Port des Webinterfaces
12183 ist der Port des "internen" MQTT-Servers

Das jetzt genau zu erklären, sprengt ein bisschen den Rahmen. Hier ist ein praktischer Getting-Started-Guide: https://rhasspy.readthedocs.io/en/latest/tutorials/#getting-started-guide (https://rhasspy.readthedocs.io/en/latest/tutorials/#getting-started-guide)


Zu 10_RHASSPY.pm:
Damit das Modul sich zu Rhasspy verbinden kann, braucht es in Version 0.2.0 (https://github.com/drhirn/fhem-rhasspy/blob/0.2.0/10_RHASSPY.pm) ein MQTT2_DEVICE mit geänderter clientOrder:

defmod <Devicename> MQTT2_CLIENT <MQTT url:port der Rhasspy-Base>
attr <Devicename> clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICE


Dieses MQTT2_CLIENT Device muss dann als IODev von 10_RHASSPY.pm verwendet werden.
defmod <Devicename> RHASSPY <IODev> <Standardraum>
"<Standardraum>" dient nur dazu, 10_RHASSPY zu sagen, welchen Raum es verwenden soll, wenn ich Sprachkommando keiner angegeben wird.

Im 10_RHASSPY-Device muss dann noch die URL zum Rhasspy-Base HTTP-API angegeben werden, damit die Slots aktualisiert werden können:
attr <10_RHASSPY-Devicename> rhasspyMaster http://<URL der Rhasspy-Base>:12101

Anschließend ein Test-Device mit den oben genannten Attributen versehen und in den Raum "Rhasspy" legen.

Dann "set updateSlots" und "set trainRhasspy" im 10_RHASSPY ausführen.


Anschließend kannst du - sollte ich nichts vergessen haben - mit "set textCommand ..." Befehle ausführen. Z.B.:
set <10_RHASSPY-Devicename> textCommand lampe an


Ist das irgendwie hilfreich? Wenn Fragen offen sind, gerne! Ansonsten hab ich heute morgen die CmdRef korrigiert, die funktioniert jetzt. Und es gibt das README (https://github.com/drhirn/fhem-rhasspy/blob/0.2.0/README.md) auf GitHub.

Zitat von: drhirn am 21 Februar 2021, 11:14:36
Beim Erstellen des Logs für Rudi ist mir aufgefallen, dass MQTT2_CLIENT eiskalt die ganze MQTT-Kommunikation mithört. Und da kommt ganz schön was zusammen (Audio).
[...]
Kann das sein? Und wenn ja, kann ich irgendwie verhindern, dass MQTT_CLIENT alles mithört?

OK, dann hätte ein Blick in die Doku genügt...

@drhirn: Setz' die Subscriptions bei MQTT2_CLIENT mal auf "setByTheProgram" und aktiviere diese beiden Zeilen wieder.

@Rudi, sorry für die Frage, war mir bisher nicht bewußt, dass es da diesen "kleinen aber feinen" Unterschied gibt, da muss ich mir auf für das attrTemplate-Thema @MGB noch was überlegen...

Doku hätte mir nichts genützt, weil ich's eh nicht verstanden hätte ;).

Leider war das dann wohl nicht der Grund. Keine Änderung im Verhalten.

Hier das aktuelle (jetzt natürlich wesentlich kleinere Log):


2021.02.22 08:52:22.906 5: rhasspyMQTT2: dispatch autocreate=no\000rhasspyMQTT2\000hermes/dialogueManager/sessionStarted\000{"sessionId": "wohnzimmer-snowboy-509a272f-b819-4af4-b214-c107e7c14a67", "siteId": "wohnzimmer", "customData": "snowboy", "lang": null}
2021.02.22 08:52:22.906 4: RHASSPY_Parse called, short Topic is hermes/dialogueManager/
2021.02.22 08:52:22.907 4: grep found hermes/dialogueManager/
2021.02.22 08:52:22.907 5: RHASSPY: [Rhasspy] Parse (MQTT2_CLIENT : 'rhasspyMQTT2'): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-snowboy-509a272f-b819-4af4-b214-c107e7c14a67", "siteId": "wohnzimmer", "customData": "snowboy", "lang": null}
2021.02.22 08:52:22.907 5: Parsed value: wohnzimmer for key: siteId
2021.02.22 08:52:22.908 5: Parsed value: wohnzimmer-snowboy-509a272f-b819-4af4-b214-c107e7c14a67 for key: sessionId
2021.02.22 08:52:26.615 5: rhasspyMQTT2: dispatch autocreate=no\000rhasspyMQTT2\000hermes/intent/de.fhem_SetOnOff\000{"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-509a272f-b819-4af4-b214-c107e7c14a67", "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.22 08:52:26.616 4: RHASSPY_Parse called, short Topic is hermes/intent/
2021.02.22 08:52:26.616 4: grep found hermes/intent/
2021.02.22 08:52:26.616 5: RHASSPY: [Rhasspy] Parse (MQTT2_CLIENT : '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-509a272f-b819-4af4-b214-c107e7c14a67", "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.22 08:52:26.616 5: Parsed value: deckenlampe ein for key: rawInput
2021.02.22 08:52:26.616 5: Parsed value: an for key: Value
2021.02.22 08:52:26.617 5: Parsed value: wohnzimmer for key: siteId
2021.02.22 08:52:26.617 5: Parsed value: deckenlampe an for key: input
2021.02.22 08:52:26.617 5: Parsed value: wohnzimmer-snowboy-509a272f-b819-4af4-b214-c107e7c14a67 for key: sessionId
2021.02.22 08:52:26.617 5: Parsed value: 1 for key: probability
2021.02.22 08:52:26.617 5: Parsed value: SetOnOff for key: intent
2021.02.22 08:52:26.618 5: Parsed value: deckenlampe for key: Device
2021.02.22 08:52:26.618 5: handleIntentSetOnOff called
2021.02.22 08:52:26.618 5: Device selected: lampe1
2021.02.22 08:52:26.618 5: rhasspyMapping selected: cmdOn=on,cmdOff=off
2021.02.22 08:52:26.618 5: Cmd: >set lampe1 on<
2021.02.22 08:52:26.619 4: dummy set lampe1 on
2021.02.22 08:52:26.619 5: Running command [on] on device [lampe1]
2021.02.22 08:52:27.456 5: rhasspyMQTT2: dispatch autocreate=no\000rhasspyMQTT2\000hermes/dialogueManager/sessionEnded\000{"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-snowboy-509a272f-b819-4af4-b214-c107e7c14a67", "siteId": "wohnzimmer", "customData": "snowboy"}
2021.02.22 08:52:27.456 4: RHASSPY_Parse called, short Topic is hermes/dialogueManager/
2021.02.22 08:52:27.457 4: grep found hermes/dialogueManager/
2021.02.22 08:52:27.457 5: RHASSPY: [Rhasspy] Parse (MQTT2_CLIENT : 'rhasspyMQTT2'): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-snowboy-509a272f-b819-4af4-b214-c107e7c14a67", "siteId": "wohnzimmer", "customData": "snowboy"}
2021.02.22 08:52:27.457 5: Parsed value: wohnzimmer for key: siteId
2021.02.22 08:52:27.457 5: Parsed value: wohnzimmer-snowboy-509a272f-b819-4af4-b214-c107e7c14a67 for key: sessionId


Hmm, das sieht schon mal besser aus, (und ist auch auffschlussreich hinsichtlich der Funktionsweise usw.).
Allerdings kann ich nach der Bereinigung der Flut im Moment erst recht keinen Grund mehr erkennen, warum longpoll aus dem Tritt kommen sollte....

Nachdem ich gestern Abend die 0.2.0 getestet habe, wurde mein Logfile (./log/Rhasspy_Intent.log Rhasspy:lastIntentPayload.*) nicht weiter gefüllt.
Es scheint, als wurde kein Event ausgelöst.
Gruß Jens

Wenn ich mit "mosquitto_pub -i id -t topic -m msg" an MQTT2_CLIENT mit "attr global verbose 5" was sende, dann schaut das so aus:

Zitat2021.02.22 22:28:36 5: m2c: dispatch autocreate=simple\000m2c\000topic\000msg
2021.02.22 22:28:36 4: MQTT2_DEVICE_Parse: MQTT2_m2c topic => topic
2021.02.22 22:28:36 5: Starting notify loop for MQTT2_m2c, 1 event(s), first is topic: msg
2021.02.22 22:28:36 5: End notify loop for MQTT2_m2c

In eurem Log sehe ich kein "Starting notify loop", d.h. RHASSPY_Parse hat nicht den Namen des betroffenen Geraetes zurueckgeliefert.

Argh, also mein Fehler, sorry...

Danke für's Schubsen, dann sollte es vollends gelingen, das auch an der Stelle gradezuziehen ::) .

@drhirn:
update folgt irgendwann dann noch, aber kannst du bis dahin bitte auch schauen, ob das mit den subscriptions immer zuverlässig klappt. Da gab es auch irgendein Problem, das aber über einen etwas längeren timer bei der Initialisierung gelöst sein sollte...

Kurze Rückmeldung:
Funktioniert jetzt wohl alles, wie es soll (bzw. der weitere Weg ist klarer), siehe https://forum.fhem.de/index.php/topic,118926.msg1135195.html#msg1135195

So langsam habe ich auch eine nähere Vorstellung, warum der Matching-Mechanismus @MySensors und MQTT-alt aus Sicht der Wissenden nicht so prickelnd ist... (hab's irgendwo weit unten auf der Liste, das ggf. für MySensors umzubauen).