[gelöst] MQTT2_CLIENT bzw. Client-Modul dazu verhindert longpoll?

[Beta-User]

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 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!

[rudolfkoenig]

Ich sehe mit folgendem fhem.cfg keine longpoll Probleme:

Code Auswählen Erweitern

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.

[drhirn]

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 (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.

Code Auswählen Erweitern


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


Code Auswählen Erweitern


defmod Rhasspy RHASSPY rhasspyMQTT2 Wohnzimmer
attr Rhasspy IODev rhasspyMQTT2


[Beta-User]

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...

[drhirn]

Mit einem falschen Port kann ich nichts mehr testen

Aber, es tritt auch mit folgender Config auf:

Code Auswählen Erweitern


defmod MQTT2_SERVER MQTT2_SERVER 1883 global
attr MQTT2_SERVER autocreate no


Code Auswählen Erweitern


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


Code Auswählen Erweitern


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.

[Beta-User]

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...

[JensS]

...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

[drhirn]

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.

[drhirn]

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.

[Beta-User]

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

indirekt: Zeile 140:

Code Auswählen Erweitern

RHASSPY_subscribeTopics($hash) if isIODevMQTT2_CLIENT($hash);

oder direkt: Zeile 245:

Code Auswählen Erweitern

IOWrite($hash, 'subscriptions', join(' ', @topics));

[drhirn]

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

Code Auswählen Erweitern

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.

[drhirn]

Die Aussage oben war falsch. Muss weiter testen.

[Beta-User]

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?

[rudolfkoenig]

Hier 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.

[drhirn]

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.