Rhasspy Offline Sprachsteuerung

[tobetobe]

@joergeli
Hallo Jörg,

ja das mache ich. Morgen habe ich allerdings noch Reste eines handwerklichen Projektes zu erledigen und nachmittags einige Telcos wegen der Global Alliance. Kann also sein, dass ich erst am Freitag zum Testen komme. Fragen kann ich Kay heute noch.

Gruß
Thomas

[joergeli]

@tobetobe
Hallo Thomas,
ich habe Deine Diskussion im Rhasspy-Forum mit Kay Koch mitverfolgt.
Es erscheint mir etwas suspekt, dass er -sinngemäß- meint, es liegt am ioBroker MQTT-Adapter und ein weiterer MQTT-Server zwischengeschaltet werden soll.
Ist doch aber merkwürdig, daß ansonsten alle meine MQTT-Gerätschaften (incl. Rhasspy 2.4.19) mit dem MQTT-Adapter funktionieren.
Wie ich aber schon geschrieben hatte, werden ja Rhasspy 2.5-Topics im ioBroker-Log subscribed/published. Es kommen aber anschl. seitens Rhasspy 2.5 keine Messages an. Somit vermute!! ich, daß evtl. der Aufbau der Messages anders sein könnte, als bei Rhasspy 2.4.19. Aber ich bin kein MQTT-Spezi.

Hast Du mal probiert, ob WakeUp/Wakeword, bzw. Micro, noch funktioniert, wenn Du den externen MQTT in Rhasspy 2.5 aktivierst?

Etwas positives:
Nach kpl. Neuaufsetzen meines ioBroker-Raspis, ist der Average-Load wieder im grünen Bereich, d.h. unter 1.0.
Weiß der Teufel, was vorher die Last von heute auf morgen so nach oben getrieben hat, zumal ich keine Änderungen vorgenommen hatte.

Gruß
Jörg

[joergeli]

@tobetobe
Hallo Thomas,
ich habe gerade eine Rückmeldung zu meinem issue von synthesiam bekommen:
Your error suggests a malformed JSON message. Let me add some more logging the rhasspy-server so we can figure out what that message is.

Liege ich evtl. richtig mit meiner Vermutung, daß die MQTT-Message nicht korrekt formatiert ist.

Gruß
Jörg

[tobetobe]

@joergeli

Hallo Jörg,

mit meinem handwerklichen Projekt bin ich endlich fertig (Rollladenmotor in der Küche, Beleuchtung überm Fenster, neue Steckdosen und Schalter, spachteln, tapezieren streichen). Parallel habe ich immer wieder mit meinem seit einigen Wochen bestehenden Problem mit dem admin- und dem web-Adapter von ioBroker zu kämpfen gehabt. Jetzt, also heute Nachmittag, habe ich das Problem wohl endgültig lösen können. Dadurch hatte ich für Rhasspy leider gar keine Zeit. Ich fange morgen wieder damit an.

Ich verstehe ehrlich gesagt auch nicht, warum das ursächliche Problem mit dem MQTT-Adapter von ioBroker zu tun haben soll. In Anbetracht der Tatsache, dass Kay jedoch ein lauffähiges System zu haben scheint, ist mir diese Frage momentan auch ziemlich gleichgültig.

Momentan ist mein Stand, dass ich einen eigenen MQTT Docker am Laufen habe und sich meine beiden Rhasspys (also Master und Sat) mit diesem verbinden. Das sehe ich im Terminal.

Mit der Konfiguration und den Hinweisen von Kay werde ich jetzt weiter daran arbeiten, Rhasspy wieder wie zuvor mit 2.4.19 aber nun mit 2.5 und neuem MQTT broker zum Laufen zu bekommen.

Morgen kann ich dir mehr sagen - hoffentlich...

Gruß & Dir einen schönen Abend
Thomas

[tobetobe]

@joergeli

Oh, das hört sich vielversprechend an. Üblicherweise ist Synthesiam ja mit solchen Änderungen recht flott.

[tobetobe]

@joergeli

Hallo Jörg,
ich habe Nachrichten, evtl keine guten.

Aktueller Stand:
Ein zusätzlicher MQTT Broker (Server) läuft in einem Docker parallel zu meinem ioBroker. Installation war sehr simpel.
Der alte MQTT Broker, der als Adapter auf dem ioBroker lief, ist abgeschaltet (Instanz mqtt.0)
Parallel habe ich auf ioBroker einen MQTT Client eingerichtet, der den neuen Broker belauscht.

Mit dieser Konstellation werden alle Intents sauber erkannt und auch im MQTT Client angezeigt.
Änderung der Broker-Adresse in Rhasspy und Wiedereinschalten des alten MQTT Brokers: Timeout bei der Recognition.

Soweit, so gut. ABER: Die Datenstruktur ist mit 2.5 eine komplett andere. Bei dir war es sicherlich in 2.4.19 auch so, dass in den ioBroker Objekten unterhalb von mqtt.0 die Intents einerseits im Zweig "hermes" sowie andererseits auch im Zweig "rhasspy" aufgeführt wurden.

Nutzbar für die weitere Verarbeitung durch JS waren bei mir nur die Intents im Rhasspy-Zweig, da diese die wesentlichen Informationen, also Device, Status, Level usw enthielten. Im Hermes-Zweig steht dagegen der komplette JSON-String, ohne erkennbare Identifier. Das ist so natürlich wertlos bzw viel zu kompliziert.

Ebenfalls noch nicht getestet habe ich die Befehlseingabe über das Mikrofon. Bislang habe ich Kommandos nur über die Textzeile im Home-Register von Rhasspy eingegeben.

Eine weitere Änderung wird dich ebenfalls schmerzen: Der WakeListener und der CommandListener scheinen nicht mehr zu existieren. Zumindest sind sie bei mir auch nach längerer Laufzeit des Brokers und des Clients noch nicht aufgetaucht.

Leider lässt sich die Struktur nicht kopieren, oder wenn, dann nur als sehr langes Bildschirmfoto. Wenn du magst, kann ich dir das Ganze ja mal über TeamViewer zeigen und wir telefonieren parallel.

Gruß
Thomas

[joergeli]

@tobetobe
Hallo Thomas,
somit scheint sich meine Vermutung ja zu bestätigen, daß der Aufbau der Messages in der 2.5 anders ist.
Ich hatte ja geschrieben, das die 2.5er Topics sehr wohl im ioBroker MQTT auftauchen, aber keine Messages übermittelt werden.
Daß die Topics jetzt im HERMES-Zweig erstellt werden, ist m.E. erst mal nicht schlimm, da kann man sicherlich mit JS auch die Intents wieder abgreifen (müssen die JavaScripte halt neu gemacht werden).

@tobetobe sagte in Rhasspy Offline Sprachsteuerung:

Bislang habe ich Kommandos nur über die Textzeile im Home-Register von Rhasspy eingegeben.

Habe ich jetzt auch mal versucht, aber da kommt ebenfalls timeout (wie bei WakeWord und WakeUp-Button).
Das ist halt mein Hauptproblem: Es kommen keine Messages im ioBroker MQTT an.
Wenn etwas (was auch immer) ankommen würde, wäre das schon die halbe Miete.
Frage: Wenn Du ein Kommando über Textzeile eingibst, sieht man dann bei Dir was unter mqtt.0.hermes.nlu.query ?

@tobetobe sagte in Rhasspy Offline Sprachsteuerung:

Eine weitere Änderung wird dich ebenfalls schmerzen: Der WakeListener und der CommandListener scheinen nicht mehr zu existieren.

Ist m.E. auch nicht so schlimm, da ich die ja nur für den LED-Ring verwendet habe.
Das sollte bei funktionierendem HERMES ja dann HERMES-LED-Control (python) übernehmen.

Ich kann und will den ioBroker MQTT nicht ändern, da darauf noch div. andere Gerätschaften (ESP8266 Status-Displays, zusätzliche Haustürklingel, etc.) zugreifen.
Was mir nicht in den Kopf will, ist daß Rhasspy 2.4.19 damit funktioniert, aber mit 2.5 nichts in den (HERMES-)Objekten erscheint (irgendwas, auch wenn es nicht zu unserer bisherigen Struktur passt).

Ich persönlich kann bis dato auch noch keine Vorteile der 2.5er gegenüber der 2.4.19 erkennen, zumindest in unserer Konstellation mit ioBroker. Mag sein, daß es bei anderen, welche z.B. HASSIO verwenden, oder ihre Intent-Auswertung direkt mit Python machen, Vorteile bringt, aber deshalb muss ich nicht auf Biegen und Brechen auf die 2.5er umsteigen.

Gruß
Jörg

Nachtrag:
Ich habe mir gerade eben im Rhasspy-Forum Kays Beiträge bzgl. Node Red angesehen (nur angesehen, nicht importiert).
Sein Node Red greift da doch auch auf die Hermes-Topics zu ???:

[{“id”:“341f829c.eef3ee”,“type”:“mqtt in”,“z”:“27a1dcd5.ab7ad4”,“name”:“intentIsRecognized”,“topic”:“hermes/intent/#”,“qos”:“2”,“datatype”:“json”,“broker”:“6f747297.64151c”,“x”:110,“y”:520,“wires”:[[“bce45bd4.746cd8”]]},{“id”:“185bb0bc.bae1df”,“type”:“mqtt out”,“z”:“27a1dcd5.ab7ad4”,“name”:“saySomething”,“topic”:“hermes/tts/say”,“qos”:"",“retain”:"",“broker”:“6f747297.64151c”,“x”:980,“y”:520,“wires”:.....

z.B. topic”:“hermes/intent/# und “topic”:“hermes/tts/say”, warum soll das nicht via ioBroker MQTT broker, bzw. JS funktionieren, sondern muss stattdessen ein weiterer MQTT-client sein?
Bei uns war es bisher mit der V2.4.19 doch so, daß die Messages in den entspr. Topics im ioBroker MQTT-Adapter ankamen und dann mit JS weiter verwurstelt wurden.
Bei ihm kommen die Messages in den entspr. Topics (OK, die Topics heissen jetzt hermes.xyz statt rhasspy.xyz) eines MQTT-clients an und werden dann via Node Red weiter verarbeitet.
IMHO ist das vom Prinzip her das Gleiche, nur der Weg ist anders - aber vielleicht stehe ich ja total auf dem Schlauch.

[tobetobe]

Hallo Jörg,

ich grätsche mal in deine Fragen in etwas anderer Reihenfolge hinein.

@joergeli said in Rhasspy Offline Sprachsteuerung:

Frage: Wenn Du ein Kommando über Textzeile eingibst, sieht man dann bei Dir was unter mqtt.0.hermes.nlu.query ?

Ja, hinter "input" wird exakt der Sentence wieder gegeben, wie ich ihn in die Kommandozeile geschrieben habe. Mit dem dann nachfolgenden String fange ich (noch) nichts an:

{"input": "schalte die linkekuechenlampe ein", "siteId": "Satellite1", "id": "92d0fd65-a72f-49c4-b998-3410af0ceb88", "intentFilter": null, "sessionId": "92d0fd65-a72f-49c4-b998-3410af0ceb88", "wakewordId": null}

Anmerken muss ich, dass mqtt.0 mein abgeschalteter Adapter inm ioBroker ist. Dieser String kam über mqtt.1 herein, einer Instanz, die ich als Client betreibe und die auf den neuen Eclipse Broker zugreift, damit ich überhaupt mal was sehe.
Nur, damit du keine falschen Schlüsse ziehst...

@joergeli said in Rhasspy Offline Sprachsteuerung:

somit scheint sich meine Vermutung ja zu bestätigen, daß der Aufbau der Messages in der 2.5 anders ist.

Ja, sehe ich auch so.

@joergeli said in Rhasspy Offline Sprachsteuerung:

Daß die Topics jetzt im HERMES-Zweig erstellt werden, ist m.E. erst mal nicht schlimm, da kann man sicherlich mit JS auch die Intents wieder abgreifen (müssen die JavaScripte halt neu gemacht werden).

Ich finde das schon sehr lästig. So sieht nämlich ein mqqt.1.hermes.intent aus:

{"input": "true die hm-rpc.0.OEQ1861473.1 true .STATE", "intent": {"intentName": "ChangeDeviceState",
 "confidenceScore": 1.0}, "siteId": "Satellite1", "id": "92d0fd65-a72f-49c4-b998-3410af0ceb88", "slots": [{"entity": 
"device_name_switch", "value": {"kind": "Unknown", "value": "hm-rpc.0.OEQxxx.1"}, "slotName": "device", "rawValue": 
"linkekuechenlampe", "confidence": 1.0, "range": {"start": 9, "end": 30, "rawStart": 12, "rawEnd": 29}}, {"entity": 
"device_state", "value": {"kind": "Unknown", "value": "true"}, "slotName": "value", "rawValue": "ein", "confidence": 1.0, 
"range": {"start": 31, "end": 35, "rawStart": 30, "rawEnd": 33}}, {"entity": "state", "value": {"kind": "Unknown", "value": 
".STATE"}, "slotName": "state", "rawValue": "", "confidence": 1.0, "range": {"start": 36, "end": 42, "rawStart": 34, "rawEnd": 
33}}], "sessionId": "92d0fd65-a72f-49c4-b998-3410af0ceb88", "customData": null, "asrTokens": [[{"value": "true", 
"confidence": 1.0, "rangeStart": 0, "rangeEnd": 4, "time": null}, {"value": "die", "confidence": 1.0, "rangeStart": 5, 
"rangeEnd": 8, "time": null}, {"value": "hm-rpc.0.OEQxxx.1", "confidence": 1.0, "rangeStart": 9, "rangeEnd": 30, "time": null}, 
{"value": "true", "confidence": 1.0, "rangeStart": 31, "rangeEnd": 35, "time": null}, {"value": ".STATE", "confidence": 1.0, 
"rangeStart": 36, "rangeEnd": 42, "time": null}]], "asrConfidence": null, "rawInput": "schalte die linkekuechenlampe ein", 
"wakewordId": null}

Es erscheint mir ungleich komplexer, hier mit einem Skript die relevanten Informationen herauszufischen. Im Sinne einer simplen Migrationsstrategie von 2.4x auf 2.5 kann ich auch nicht nachvollziehen, warum es die einfach strukturierten ...rhasspy.intent nicht mehr gibt. Diese enthielten doch exakt das, was im Rhasspy Home Bereich bei einem erkannten Intent unterhalb von der Kommandozeile dargestellt wird, also das Device, der State, ggf der Level usw.

Ich werde Synthesiam darau ansprechen. Ich kann einfach nicht glauben, dass man es absichtlich allen Usern, die von 2.4.x kommen, zumuten möchte, ihre Skripte neu zu programmieren.

@joergeli said in Rhasspy Offline Sprachsteuerung:

Ich persönlich kann bis dato auch noch keine Vorteile der 2.5er gegenüber der 2.4.19 erkennen,

Ich bin ja noch gar nicht so recht in den funktionalen Bereich vorgedrungen, sehe aber bis jetzt:

• deutlich schneller, als 2.4.x, besser geeignet für Multiroom, also mehrere Satelliten, gefühlt auch eine bessere Erkennung

Von den Nachteilen, bzw. Hürden, die ich noch überwinden muss, um wieder auf einen zu 2.4.x vergleichbaren Stand zu kommen, spreche ich lieber nicht...

@joergeli said in Rhasspy Offline Sprachsteuerung:

Sein Node Red greift da doch auch auf die Hermes-Topics zu ???:

Stimmt. Das ist schon machbar, egal mit welcher Skript-Maschine und über welchen Weg. Ich gebe dir recht: einen MQTT Client braucht man sicher nicht unbedingt. Angenehm ist halt, dass man die Topics so im ioBroker Datenmodell sieht, man beobachten kann, was sich tut, und man einen sauberen Aufpunkt zum Abholen durch ein Skript hat. Wie gesagt halte ich den Aufwand und die Komplexität für unangemessen.

@joergeli said in Rhasspy Offline Sprachsteuerung:

(OK, die Topics heissen jetzt hermes.xyz statt rhasspy.xyz)

Das genau sehe ich anders. Wenn es nur eine Namensänderung und ein anderer Pfad wären, würde ich dir zustimmen. Kritisch sehe ich die gewaltige inhaltliche Änderung mit den Konsequenzen, alle Skripte neu aufsetzen zu müssen.

So, nun werde ich mal versuchen, Kays Nodered zu importieren - testweise.

Viele Grüße
Thomas

[joergeli]

@tobetobe sagte in Rhasspy Offline Sprachsteuerung:

Frage: Wenn Du ein Kommando über Textzeile eingibst, sieht man dann bei Dir was unter mqtt.0.hermes.nlu.query ?

Ja, hinter "input" wird exakt der Sentence wieder gegeben, wie ich ihn in die Kommandozeile geschrieben habe.

Bei mir tut sich unter mqtt.0.hermes.nlu.query nichts, ist aber ja auch mein bisheriger ioBroker MQTT und kein zusätzlicher MQTT-client.
Wie sieht es bei Dir mit WakeWord, bzw. Wakeup-Button aus? Hörst Du da die Beeps, oder bekommst Du timeout?

@tobetobe sagte in Rhasspy Offline Sprachsteuerung:

Ich werde Synthesiam darau ansprechen. Ich kann einfach nicht glauben, dass man es absichtlich allen Usern, die von 2.4.x kommen, zumuten möchte, ihre Skripte neu zu programmieren.

Ich vermute, daß gar nicht so viele User mit ioBroker, bzw. mit JS arbeiten.
Wenn ich mir die Threads im Rhasspy-Forum so ansehe, nutzen die meisten wohl HASSIO, bzw. pfriemeln da mit Python-Scripten direkt auf dem Rhasspy-Raspi rum.
Ich nutze zwar auch für ein paar andere Sachen Node Red, das ist aber aus meinen Anfangszeiten mit ioBroker und ich war bisher einfach zu faul, das auf JS umzubiegen. Node Red ist heute für mich aber keine Option mehr.

Ich habe mal nach HERMES MQTT Protokoll gegoogelt und es ist wohl so, daß HERMES bis dato von Snips verwendet wurde, daß ja nicht mehr existiert. Viele User sind wohl von Snips zu Rhasspy gewechselt und IMHO liegt deshalb das Hauptaugenmerk von Rhasspy jetzt auf HERMES - ob das jetzt für uns "iobroker" besser ist, kann ich nicht beurteilen.
Einfacher ist es nach den bisherigen Erfahrungen jedenfalls nicht.

Gruß
Jörg

[tobetobe]

Hallo Jörg,

@joergeli said in Rhasspy Offline Sprachsteuerung:

Bei mir tut sich unter mqtt.0.hermes.nlu.query nichts, ist aber ja auch mein bisheriger ioBroker MQTT und kein zusätzlicher MQTT-client.

Das verwundert mich nicht. Ich hatte ja bestätigt, dass ioBroker MQTT nicht funktioniert.

@joergeli said in Rhasspy Offline Sprachsteuerung:

Wie sieht es bei Dir mit WakeWord, bzw. Wakeup-Button aus? Hörst Du da die Beeps, oder bekommst Du timeout?

Ich hatte zwischenzeitlich mal Quittungstöne, als die Konfig noch auf Remote HTTP lief. Mit Hermes tut sich nix.

Befehle werden allerdings nicht nur sauber per Konsole erkannt, sonderm auch übers Mikro. Man muss sich halt denken, dass nach dem gesprochenen Wakeword der Beep kommt... Das tut also wenigstens.
Ansonsten bin ich noch dabei, mich zu diesem Thema einzulesen. Was ich bislang verstanden habe ist: Es gibt Töne vom Master, Töne vom Satelliten, Töne im Docker, Töne direkt im File System. Kurzum: Komplizierte Geschichte...

@joergeli said in Rhasspy Offline Sprachsteuerung:

Ich vermute, daß gar nicht so viele User mit ioBroker, bzw. mit JS arbeiten.

@joergeli said in Rhasspy Offline Sprachsteuerung:

Ich vermute, daß gar nicht so viele User mit ioBroker, bzw. mit JS arbeiten.

Die Einschätzung teile ich. Auch die zu deiner weiteren Beurteilung der Bedeutung von Hermes. Unlogisch bleibt es für mich aber dennoch, dass die Rhasspy/intents jetzt nicht mehr existieren. Ich habe dazu einen neuen Post eröffnet:

https://community.rhasspy.org/t/rhasspy-2-4-x-to-2-5-migration-strategy/818

Kay Koch hat darauf mit mit einem JS-Schnipsel geantwortet, das aber aus meiner Sicht so wie es da steht, gar nicht lauffähig ist. Zumindest bekomme ich auf "return" eine Fehlermeldung. Und mir fehlt der Trigger. Möchtest du dir das evtl mal angucken?

Dennoch: Wenn es so einfach ist, aus den Hermes/intent die relevanten Infos herauszuholen, wäre der Umbau der Skripte mglw gar nicht so aufwändig.

So, für heute reicht's

Gruß,
Thomas

[tobetobe]

@joergeli

Hallo Jörg,

du hast vielleicht gesehen, dass Kay Koch seine Nodered Skripte neu eingestellt hat, so dass man sie jetzt direkt importieren kann. dadurch konnte ich mir einiges anschauen und analysieren.

Um es kurz zu machen: Auch der MQTT Client als ioBroker Adapter scheint irgendwie anders zu arbeiten. Zumindest stellt er für die Intents nicht dieselben Informationen zur Verfügung, wie der externe MQTT Server, zB fehlt die SiteID. Auch werden gewisse Intents gar nicht erkannt und somit auch nicht dargestellt. Dies betrifft zB

sesion startet: hermes/dialogueManager/sessionStarted
finish session: hermes/dialogueManager/endSession

die nach meinem Verständnis der Ersatz für Wakeword- und Befehlserkennung sind. Diese beiden gibt es nur direkt am Broker.

Was ich an Kays "version 3" in Nodered gut sehen konnte, ist, dass die Slots mit den relevanten Schaltinformationen sehr leich extrahiert werden können. Dadurch habe ich mittlerweile ein gutes Gefühl, dass der Umbau meiner Skripte sich doch nicht als so aufwändig darstellt, wie zunächst befürchtet.

Wenngleich ich zugeben muss, dass ich das leichter in Nodered als in JS hinbekommen würde. Sprich: Ich bin bislang gescheitert... Dennoch sehe ich (zumindest für mich) kein Problem mehr darin, den MQTT-Adapter vom ioBroker nicht mehr zu nutzen.

Soweit meine heutigen Erkenntnisse, die dir hoffentlich auch hilfreich sind.

Gruß
Thomas

[joergeli]

@tobetobe
Hallo Thomas,
ich habe heute auch noch mal ein wenig getestet:

1.) mqtt.0-Instanz gestoppt.

2.) Neue mqtt.1-Instanz als Client eingerichtet.
Rhasspy2.5 auf einen zusätzlichen, externen MQTT konfiguriert -> Das ist ein Mosquitto MQTT Broker (Port 1883), der auf dem selben Raspi läuft wie ioBroker, also die gleiche IP hat ( und schon erfolgreich verschiedene Aufgaben verrichtet hat, bevor ich überhaupt mit ioBroker begonnen habe)
mqtt.1-Client mit der IP und Port des Mosquitto konfiguriert.
Ergebnis: Rhasspy reagiert auf WakeWord/WakeUp-Button, aber der mqtt.1-Client empfängt nichts vom Mosquitto.

3.) Dann mal versucht, vom mqtt.1-Client direkt auf den internen MQTT von Rhasspy (via Port 1883, als auch via Port 12183) zuzugreifen --> am MQTT-Client kommt ebenfalls nichts an.

4.) mqtt.1-Instanz wieder gelöscht und mqtt.0-Instanz reaktiviert.

Somit stellt sich mir - als Laien - die Frage: Was wird in Node Red bzgl. MQTT anders gehandhabt, als in den MQTT-Adaptern???

Wenn Du mit Node Red besser klar kommst, als mit JS - nur zu, kein Problem.
Mir persönlich sind sowohl Node Red, als auch Blockly, zu viel "KlickiBunti".

Ich würde an Deiner Stelle aber primär erst mal die kpl. Grundfunktionalität von Rhasspy 2.5, also WakeWord-Erkennung, Intent-Übermittlung und anschl. eine einfache Kommandoausführung/Sprachausgabe testen.
Erst wenn das läuft, würde ich die komplexeren Sentences/Intents/Slots angehen.

Was mich betrifft, bin ich bei Rhasspy 2.5 wohl leider raus, werde aber natürlich weiter das Rhasspy-Forum verfolgen, ob es nicht doch noch eine Möglichkeit geben wird, Rhasspy 2.5 via ioBroker MQTT-Adapter zu betreiben.

Gruß
Jörg

P.S.
Meine erst letzte Woche mühsam wieder hergestellte ioBroker-Installation fasse ich im Moment nicht mehr an, denn als ich gestern zur Sicherheit ein Image der Micro-SD ziehen wollte, habe ich festgestellt, daß wohl mein USB-Multi-Karten-Adapter den Geist aufgegeben hat. Gottseidank hat er die ioBroker-SD-Karte nicht mit in den Abgrund gerissen.
Ein Ersatz USB-Adapter ist aber schon bestellt.

[tobetobe]

@joergeli
Hallo Jörg,

dann sind wir ja mit deinen und meinen Erkenntnissen auf demselben Level. Warum dein mqtt.1 nichts vom Mosquitto empfängt, verstehe ich allerdings nicht. Genau so hatte ich es ja bei mir auch implementiert, allerdings mit dem Ergebnis, dass der mqtt.1 nicht alles empfängt, was der Mosquitto bereitstellt. Aber gar nichts? Merkwürdig.

Deine Frage zu den Unterschieden Adapter versus Mosquitto ist berechtigt. Vielleicht sollte man diese nicht an das Rhasspy Team sonder ans ioBroker Team richten. Das hielte ich nach allen bisherigen Erfahrungen, die wir beide gleichermaßen gemacht haben, für sinnvoller. Möchtest du das noch übernehmen, oder soll ich?

Zu Nodered: Ja, ich komme damit besser zurecht. Wie jedoch schon gesagt, würde auch ich lieber auf JS setzen und meine Skripte behalten, zumal ich den Aufwand, meine JS Skripte anzupassen für minimal halte: Leider reicht mein Wissen über JS nicht aus.

Zu deinem Hinweis: Die Grundfunktionalität ist ja gegeben, WakeWord wird korrekt (und schnell) erkannt und der Intent wird ebenfalls blitzschnell an Mosquitto übergeben. Jetzt muss ich nur noch meine Devices triggern. Wenn ich einmal in der Lage war, das mit JS für ein Intent hinzubekommen, habe ich schlagartig meine alte Funktionalität wieder hergestellt, da alle Skripte auf der "Eingangsseite" gleich funktionieren. Insofern gibt es für mich keinen Unterschied zwischen einfacher und komplexer Befehlsausführung.

Nach allem, was ich bisher gelesen habe, muss das Abholen der Intents bei Mosquitto so ähnlich in JS organisiert werden, wie du das mit den WakWords gemacht hast. Ich habe mich also entschieden, nicht mehr zu 2.4.19 zurückzukehren, nach dem Motto: Das Kamel geht nur nach vorne durchs Nadelöhr.

Thema Ton- und Sprachausgabe ist allerdings nochmal ein anderes Thema, welches mir momentan aber auch noch nicht so wichtig ist.

@joergeli said in Rhasspy Offline Sprachsteuerung:

Was mich betrifft, bin ich bei Rhasspy 2.5 wohl leider raus

Das ist natürlich eine traurige Nachricht. Mit wem kann ich mich nun austauschen? Zum Glück habe ich in meinem früheren Leben mal ne Einzelkämpferbefähigung erworben...

Schade, denn ich glaube, wir beide haben hier durchaus schon einiges bewegt. Deine Entscheidung kann ich aber durchaus auch gut nachvollziehen.

Aber ernsthaft: Ich kann diese Beitrag hier gern mit meinen weiteren Erfahrungen fortführen, auch in der Hoffnung, dass noch der eine oder andere ioBroker User aufspringt und auch du dann irgend wann an den Punkt kommst, hier wieder mitzumischen.

Zu PS: So ging's mir auch kürzlich. Zum Glück war der Media Markt noch offen und ich konnte mir rasch einen neuen HAMA Adapter zulegen. Wobei ich es allerdings bevorzuge, meine Backups mit dd auf meine NAS zu ziehen, da ich an meine SD-Karte gar nicht mehr herankomme.

Ja, da bleibt es mir nur, dir für deinen immer hilfreichen und gefühlt sehr freundschaftlichen Austausch zu danken. Machs gut, bleib gesund und komm bald wieder.

Gruß
Thomas

[joergeli]

Hallo Thomas,

@tobetobe sagte in Rhasspy Offline Sprachsteuerung:

dann sind wir ja mit deinen und meinen Erkenntnissen auf demselben Level. Warum dein mqtt.1 nichts vom Mosquitto empfängt, verstehe ich allerdings nicht. Genau so hatte ich es ja bei mir auch implementiert, allerdings mit dem Ergebnis, dass der mqtt.1 nicht alles empfängt, was der Mosquitto bereitstellt. Aber gar nichts? Merkwürdig.
Deine Frage zu den Unterschieden Adapter versus Mosquitto ist berechtigt. Vielleicht sollte man diese nicht an das Rhasspy Team sonder ans ioBroker Team richten. Das hielte ich nach allen bisherigen Erfahrungen, die wir beide gleichermaßen gemacht haben, für sinnvoller. Möchtest du das noch übernehmen, oder soll ich?

Wie gesagt, ich stecke nicht genug in der MQTT-Materie drin, als das ich da was zu sagen könnte.
Ich fürchte auch, daß die ioBroker-Community da nicht viel zu sagen kann, zumal der MQTT-Adapter ja ansonsten mit allem möglichen MQTT-Geraffel (incl. Rhasspy 2.4.19) funktioniert.
Da wir beide nicht die genaue MQTT-Funktionsweise von Rhasspy 2.5 kennen, können wir m.E. wohl auch hier im ioBroker-Forum kaum auf Hilfe hoffen, zumal ja auch Kay gesagt hat, daß er es mit dem ioBroker MQTT nicht hinbekommen hat.

Ich denke eher, Du/Wir müssten die Rhasspy-Community dazu ermuntern, sich mit ioBroker, bzw. dessen MQTT zu befassen. Ich lese da zwar öfters, daß externe MQTT-Broker verwendet werden, aber nicht in Verbindung mit ioBroker, sondern z.B. Home Assistant, Hass.io und Node-RED.
Irgendwie sagt mir aber mein Bauchgefühl, daß es wahrscheinlich nur eine Kleinigkeit seitens Rhasspy 2.5 ist, daß die MQTT-Intents im ioBroker MQTT-Adapter nicht erkannt werden, zumal ja die entspr. Topics unter mqtt.0 sehr wohl angelegt werden.

@tobetobe sagte in Rhasspy Offline Sprachsteuerung:

Zu Nodered: Ja, ich komme damit besser zurecht. Wie jedoch schon gesagt, würde auch ich lieber auf JS setzen und meine Skripte behalten, zumal ich den Aufwand, meine JS Skripte anzupassen für minimal halte: Leider reicht mein Wissen über JS nicht aus.

Wenn Du es schaffst, mit Node Red das/die kpl.Intent/s in einen ioBroker-Datenpunkt zu schreiben, kann ich Dich gern unterstützen, den Inhalt anschl. via JS aufzudröseln, um z.B. wieder mehrere einzelne Datenpunkte ( Intent, Slot, etc.) zu schreiben. Damit kann man dann wieder entspr. Aktionen auslösen/triggern.
War Blödsinn, was ich hier geschrieben habe: nicht, daß ich Dich nicht weiterhin unterstützen will, sondern daß Rhasspy 2.5 ja wahrscheinlich Rückmeldungen auch nur über Node Red erkennt, also nicht noch einen Umweg über JS einbauen.
Wenn ich Kay's 3tes Node Red-Script richtig interpretiert habe, verwendet er aber auch in Node Red Funktionsblöcken JS-Code.

@tobetobe sagte in Rhasspy Offline Sprachsteuerung:

Das ist natürlich eine traurige Nachricht. Mit wem kann ich mich nun austauschen? Zum Glück habe ich in meinem früheren Leben mal ne Einzelkämpferbefähigung erworben...
Schade, denn ich glaube, wir beide haben hier durchaus schon einiges bewegt. Deine Entscheidung kann ich aber durchaus auch gut nachvollziehen.

Ich habe ja nicht gesagt, daß ich mich kpl. zurückziehe, Du kannst mich gerne weiterhin ansprechen.
In Node Red bin ich ja auch nicht ganz unbeleckt, ist nur halt lange her, als ich damals was damit gemacht habe.

@tobetobe sagte in Rhasspy Offline Sprachsteuerung:

Aber ernsthaft: Ich kann diese Beitrag hier gern mit meinen weiteren Erfahrungen fortführen, auch in der Hoffnung, dass noch der eine oder andere ioBroker User aufspringt und auch du dann irgend wann an den Punkt kommst, hier wieder mitzumischen.

Auf jeden Fall Deine weiteren Erfahrungen schreiben!
Ich lese natürlich mit und mein Rhasspy 2.5-Testsystem liegt auch weiterhin für neue Schandtaten griffbereit.

Gruß
Jörg

P.S.
Neuer USB-Karten-Adapter ist heute gekommen und SD-Image ist schon auf (Windows-)Festplatte gezogen.
Von dort kopiere ich es auf mein NAS.
Ich bin nicht so der Freund von dd, zumal es bei einem Raspi ja kein Problem ist, diesen runter zu fahren, Micro-SD umstecken, Image ziehen, Micro-SD wieder in Raspi stecken.
Dauert ( bei einer 16 GByte-Karte ) ca. 25 Min.

[joergeli]

@tobetobe
Hallo Thomas,

Es geschehen noch Zeichen und Wunder ...
... und ich melde mich von der Ersatzbank zurück

Ich habe heute doch noch mal die neueste Rhasspy 2.5-pre installiert.
In den Rhasspy-Settings den externen Mosquitto-Broker eingetragen, der auf dem gleichen Raspi läuft, wie ioBroker:

Anschl. meine normale mqtt.0 ioBroker-Server-Instanz gestoppt.

Dann eine neu mqtt.1 Client-Instanz angelegt.
Diese Client-Instanz mit dem Mosquitto verbunden ( 192.168.192.29, 1883).
In der Client-Instanz auf hermes/# subscribed und als Prefix für alle Topics ebenfalls hermes/# eingetragen.

Anschl.WakeWord und Kommando gesprochen, Beeps waren hörbar und wie durch Zauberhand erschienen jetzt unter den mqtt.1-Objekten die entspr. Intents:

Natürlich passen die Intents noch nicht zu meinen bisherigen JS zur Weiterverarbeitung, da müsste ich die JS erst anpassen - sollte aber möglich sein.

Aber wo Licht ist, ist auch Schatten.
1.) mqtt.1-Instanz trennt und verbindet sich häufig:

2.) Es werden unter mqtt.1.hermes.audiserver.<siteID>.audioFrame fortlaufend Daten (WAV ?) empfangen:

3.) Es werden immer mehr Objekte unter playBytes angelegt, je mehr Kommandos man absetzt (das sind wohl wav-Dateien ?) und müllen die Objekte zu

Zu Punkt 2 - fortlaufender WAV-Empfang - meine ich, im Rhasspy-Forum schon mal was gelesen zu haben.
Das erzeugt schließlich unnötigen Netzwerk-Traffic und belastet auch ioBroker.

Soweit mein Hoffnungsschimmer am Horizont ....
Gruß
Jörg

Nachtrag:
Mir ist gerade bewußt geworden, daß ich die Probleme unter Punkt 2 und 3 selbst "hausgemacht" habe.
Ich kann ja im Client auf die Topics einschränken, die ich subscriben will.
Wenn ich z.B. nur die intents haben will, subscribe ich in der mqtt.1- Client-Instanz nur hermes/intents/# und als Prefix für alle Topics ebenfalls hermes/intents/#.

[tobetobe]

@joergeli

Guten Morgen Jörg,

da kann man mal wieder sehen, wie wichtig Ersatzspieler für die Teamleistung sind
Da muss ich doch gleich mal meinen mqtt.1 reaktivieren. Wobei das, glaube ich, mein Problem nicht löst, wie ich aus em ganzen JSON Gewusel meine relevanten Slots herausgefiltert bekomme.

Die von dir geschilderten Nebeneffekte mit wav usw hatte ich auch bereits mal gesehen. Mir ist noch nicht ganz klar, welche Relevanz das hat, und ob man diese ggf ausgefiltert bekommt, wenn man UDP konfiguriert. Das wollte ich mir auch noch anschauen. Dein Hinweis zum richtigen Definieren der Subscription bzw der Prefixes m Client ist naürlich richtig. Allerdings wird hier ja nur an der Datensenke gefiltert, erzeugt wird der ganze Müll an der Datenquelle trotzdem. Wann läuft einem da die SD voll?

Auf alle Fälle wieder ein großer Schritt nach vorne. Vielen Dank und noch einen schönen Sonntag

Thomas

[joergeli]

@tobetobe

Hallo Thomas,

ich habe den Test-Raspi mit Rhasspy 2.5-pre jetzt auf dem gleichen Stand, wie meinen Raspi mit der 2.4.19.
Eins vorweg: Außer einem kleinen Geschwindigkeits-Vorteil kann ich keine großartigen Änderungen/Vorteile erkennen.

Aber der Reihe nach:
1.) Ich habe bemerkt, daß auf dem 2.5er-Raspi ebenfalls ein Mosquitto (Port 1883) läuft, also nicht nur der interne Broker auf Port 12183. Keine Ahnung, ob der immer vorhanden ist, ich habe ihn jedenfalls nicht wissentlich installiert.

Ich habe daraufhin in Rhasppy einen externen MQTT aber mit der lokalen IP und Port 1883 eingestellt.
In mqtt.1 ebenfalls die entspr. IP und Port 1883 eingetragen.
---> Intents kommen unter mqtt.1 an.

Dann noch mal in Rhasspy den internen MQTT (Port 12183) aktiviert, aber auf den kann sich mqtt.1 nicht verbinden.
Ich vermute, weil der im Docker-Container läuft und deshalb nicht erreichbar ist.

2.) In ioBroker mqtt.1-Client folgende Topics subscribed:
hermes/intent/#, hermes/hotword/#,hermes/asr/#,hermes/dialogueManager/#, hermes/nlu/#
Ich habe bewußt nicht hermes/# genommen, weil ja dann - wie bereits erwähnt - die Datenpunkte zugemüllt werden.
BTW:
@tobetobe sagte in Rhasspy Offline Sprachsteuerung:

Allerdings wird hier ja nur an der Datensenke gefiltert, erzeugt wird der ganze Müll an der Datenquelle trotzdem. Wann läuft einem da die SD voll?

Bist Du Dir sicher, daß der Müll in der Datenquelle gespeichert wird?
Ich glaube nicht, denn dort gibt es ja keine ioBroker-Datenpunkte in denen gespeichert werden könnte.
Wenn jeder MQTT-Broker die Topics, die er published, speichern würde, müsste jedes System irgendwann in die Knie gezwungen werden. Just my 2 cents.

3.) Topics mit JS aufbereiten:
Ich weiß, Du verwendest lieber Node Red, aber ich glaube, auch damit wirst Du um JS nicht ganz herumkommen.
In Node Red kannst Du zwar Funktionsblöcke verwenden, die Dir das entspr. JSON aufdröseln, aber ich meine, das wird innerhalb der Funktionsblöcke ebenfalls mit JS programmiert.

Ich weiß, daß Deine Sentences/Slots anders aufgebaut sind als meine (ich verwende keine Slots), will Dir aber trotzdem an einem Besíspiel zeigen, wie ich es gelöst habe:
Mein "Lampen"-Sentence:

[Lampen]
lampen_name = (moodlight |stimmungslicht|fernsehlicht|esstischlampe|essecke|wandspots|regal|couchjoerg|couchrenate|hydro|ledcube|radio ) {name}
lampen_state = (ein | aus) {state}
schalte [ (die | den | das )]  <lampen_name> <lampen_state>

gesprochenes Kommando: Snowboy, schalte die Wandspots ein....

--> erzeugtes JSON:

{
    "intent": {
        "name": "Lampen",
        "confidence": 1
    },
    "entities": [
        {
            "entity": "name",
            "value": "wandspots",
            "value_details": {
                "kind": "Unknown",
                "value": "wandspots"
            },
            "raw_value": "wandspots",
            "start": 12,
            "end": 21,
            "raw_start": 12,
            "raw_end": 21
        },
        {
            "entity": "state",
            "value": "ein",
            "value_details": {
                "kind": "Unknown",
                "value": "ein"
            },
            "raw_value": "ein",
            "start": 22,
            "end": 25,
            "raw_start": 22,
            "raw_end": 25
        }
    ],
    "slots": {
        "name": "wandspots",
        "state": "ein"
    },
    "text": "schalte die wandspots ein",
    "raw_text": "schalte die wandspots ein",
    "tokens": [
        "schalte",
        "die",
        "wandspots",
        "ein"
    ],
    "raw_tokens": [
        "schalte",
        "die",
        "wandspots",
        "ein"
    ],
    "wakeword_id": "snowboy"
}

In einem JS drösele ich jetzt das Intent "Lampen" auf:

const lampen     = 'mqtt.1.hermes.intent.Lampen'       // Lampen, bzw. Funksteckdosen

//______________________________________________
// Lampen, bzw. Funksteckdosen
on({id: lampen, change: "any"},function(obj) {
    let empf_code = getState(lampen).val ;
    //log ("EMPF-CODE: " + empf_code);
    let empf_json = JSON.parse(empf_code);

  
    let name = empf_json.slots[0].value.value;
     //log ("name: " + name);
    let state = empf_json.slots[1].value.value;
     //log ("state: " + state);

 if(name == "wandspots" && state == "ein") { 
    setState ('hm-rpc.2.CUX4000001.7.PRESS_LONG', true); 
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.Licht_Wandspots_An', true);
 }
else if(name == "wandspots" && state == "aus") { 
    setState ('hm-rpc.2.CUX4000001.7.PRESS_SHORT', true); 
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.Licht_Wandspots_Aus', true);
}

else if(name == "regal" && state == "ein") { 
    setState ('hm-rpc.2.CUX4000001.1.PRESS_LONG', true); 
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.Licht_Regal_An', true);
 }
else if(name == "regal" && state == "aus") { 
    setState ('hm-rpc.2.CUX4000001.1.PRESS_SHORT', true); 
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.Licht_Regal_Aus', true);
}

else if(name == "couchjoerg" && state == "ein") {
    setState ('hm-rpc.2.CUX4000001.10.PRESS_LONG', true);
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.Licht_CouchJoerg_An', true);
}
else if(name == "couchjoerg" && state == "aus") {
    setState ('hm-rpc.2.CUX4000001.10.PRESS_SHORT', true);
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.Licht_CouchJoerg_Aus', true);
}

else if(name == "couchrenate" && state == "ein") {
    setState ('hm-rpc.2.CUX4000001.3.PRESS_LONG', true);
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.Licht_CouchRenate_An', true);   
}
else if(name == "couchrenate" && state == "aus") {
    setState ('hm-rpc.2.CUX4000001.3.PRESS_SHORT', true);
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.Licht_CouchRenate_Aus', true);
}

else if(name == "hydro" && state == "ein") {
    setState ('hm-rpc.2.CUX4000001.8.PRESS_LONG', true);
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.Licht_HydroTV_An', true);     
}
else if(name == "hydro" && state == "aus") {
    setState ('hm-rpc.2.CUX4000001.8.PRESS_SHORT', true);
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.Licht_HydroTV_Aus', true);    
}

else if(name == "ledcube" && state == "ein") {
    setState ('hm-rpc.2.CUX4000001.5.PRESS_LONG', true);
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.LED-Wuerfel_An', true);     
}
else if(name == "ledcube" && state == "aus") {
    setState ('hm-rpc.2.CUX4000001.5.PRESS_SHORT', true);
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.LED-Wuerfel_Aus', true);    
}

else if(name == "essecke" && state == "ein") {
    setState ('hm-rpc.2.CUX4000001.2.PRESS_LONG', true); 
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.Licht_Essecke_An', true);
}
else if(name == "essecke" && state == "aus") {
    setState ('hm-rpc.2.CUX4000001.2.PRESS_SHORT', true);
    setState ('broadlink2.0.RM:0x27a9_34:ea:34:55:3a:50.L.Licht_Essecke_Aus', true);
}

else if(name == "esstischlampe" && state == "ein") { setState ('shelly.0.SHSW-1#2C7AEF#1.Relay0.Switch', true); }
else if(name == "esstischlampe" && state == "aus") { setState ('shelly.0.SHSW-1#2C7AEF#1.Relay0.Switch', false); }

else if(name == "fernsehlicht" && state == "ein") { fernsehlicht_ein(); }
else if(name == "fernsehlicht" && state == "aus") { fernsehlicht_aus(); }

else if(name == "radio" && state == "ein") { setState ('javascript.0.Silvercrest.On', true); }
else if(name == "radio" && state == "aus") { setState ('javascript.0.Silvercrest.On', false); }


//log ( name + " ist " + state );
sendTo("paw.0",'Tablet_Jörg',{tts: name + " wurde " + state + "geschaltet" }); 
});

Beachte in der 1. Zeile den Datenpunkt mqtt.1.hermes.intent.Lampen
Wenn sich dieser Datenpunkt ändert ( on({id: lampen, change: "any"},function(obj) { ......,
dann parse den Empfangscode.
Fülle aus dem geparsten Code die beiden Variablen name und state:

 let name = empf_json.slots[0].value.value;
     //log ("name: " + name);
    let state = empf_json.slots[1].value.value;
     //log ("state: " + state);

Prüfe anhand der beiden Variablen, was passieren soll:

#z.B.:
 if(name == "wandspots" && state == "ein") { 
    setState ('hm-rpc.2.CUX4000001.7.PRESS_LONG', true); 
 }

Wenn also name=wandspots und state=ein, setState ('hm-rpc.2.CUX4000001.7.PRESS_LONG', true);
Somit werden meine Wandspots über hm-rpc eingeschaltet.

Die anderen Lampen werden mit den weiteren else if-Bedingungen geprüft.

Hinweis bei mir werden die intents je nach Bedingung in verschiedenenen Datenpunkten gespeichert:

const rolladen   = 'mqtt.1.hermes.intent.Rolladen'     // Rolladen
const lampen     = 'mqtt.1.hermes.intent.Lampen'       // Lampen, bzw. Funksteckdosen
const drucker    = 'mqtt.1.hermes.intent.Drucker'      // 3D Drucker
const fenster    = 'mqtt.1.hermes.intent.Fenster'      // Anzahl offene Fenster
const regen      = 'mqtt.1.hermes.intent.Regen'        // Regen heute
const ereignis   = 'mqtt.1.hermes.intent.Ereignis'     // Heutige Termine
const zeit       = 'mqtt.1.hermes.intent.Zeit'         // Uhrzeit
const datum      = 'mqtt.1.hermes.intent.Datum'        // Datum
const temperatur = 'mqtt.1.hermes.intent.Temperatur'   // Temperatur

Ich glaube mich zu erinnern, daß Du immer im gleichen Datenpunkt speicherst und dann entspr. weiter auswertest.
Mein Beispiel sollte nur erläutern, wie man das empfangene JSON aufsplitten kann:

 let name = empf_json.slots[0].value.value;
     //log ("name: " + name);
    let state = empf_json.slots[1].value.value;
     //log ("state: " + state);

Das hat mich ziemlich Zeit gekostet, da das JSON ein mehrdimensionales Array ist und ich in dieser Form kein entspr. Beispiel im Internet finden konnte. Ich konnte das nur mir Try & Error und log name/state herausfinden.

3.) Wakeword-Erkennung:
Das mache ich wie bei der 2.4.19, aber jetzt über die entspr. Hermes-Datenpunkte.
Es erfolgt bei mir nur eine entspr. Sprachausgabe mittels PAW-Adapter auf meinem Tablet.

//################################################################################################
// WakeWord-Erkennung
const wake   = 'mqtt.1.hermes.asr.startListening'      // Wakeword erkannt
const befehl = 'mqtt.1.hermes.asr.textCaptured'      // Text erkannt
const unbekannt = 'mqtt.1.hermes.nlu.intentNotRecognized' // Text nicht erkannt

on({id: wake, change: "any"},function(obj) {
    wakeword();       
});

on({id: befehl, change: "any"},function(obj) {
    befehl_empf();   
});

on({id: unbekannt, change: "any"},function(obj) {
    nicht_erkannt();
});


function wakeword(){
    lautstaerke(); // Lautstaerke Tablet auf 15 setzen
    sendTo("paw.0",'Tablet_Jörg',{tts: "ja"  }); // Sprachausgabe mittels PAW-Adapter auf Tablet/Smartphone
}

function befehl_empf(){ 
    lautstaerke(); // Lautstaerke auf 15 setzen
    sendTo("paw.0",'Tablet_Jörg',{tts: "Moment bitte,    "  }); // Sprachausgabe mittels PAW-Adapter auf Tablet/Smartphone
}

function nicht_erkannt(){ 
    lautstaerke(); // Lautstaerke auf 15 setzen
    sendTo("paw.0",'Tablet_Jörg',{tts: "Entschuldigung, ich habe dich leider nicht verstanden" });
}

// Ende WakeWord-ErkennungsScript
//################################################################################################

4.) Hermes-LED-Control
Habe ich nicht zum Laufen bekommen.
Ich bekomme immer eine Fehlermeldung "Configuration File not found", wenn ich den HLC-Service starte.
Googeln nach doesem Problem hat nichts gebracht, da es jemand anderes auch hatte, aber beim Autor KiboOst wohl noch nie aufgetreten ist und er somit keine Lösung anbieten konnte

Also mache ich das wie gehabt über mein "LED-Ring-Workaround"-Python Script (was aber wohl mit Deinem Matrix Voice nicht funktioniert). Im Python-Script habe ich dazu ebenfalls die neuen HERMES-Datenpunkte eingetragen.

5.) Direkte Sprachausgabe via pico-TTS:
Habe ich nicht getestet und werde es wohl auch nicht verwenden, da mir die Sprachausgabe über mein Tablet ausreicht.

6.) mqtt.1-Instanz trennt und verbindet sich häufig
das habe ich immer noch (s. auch Screenshot in vorigem Post)
das habe ich pragmatisch "gelöst", in dem ich das Logging der mqtt.1-Instanz von "info" auf "warn" umgestellt habe, damit mir das ioBroker-Log nicht zugemüllt wird. (Nicht schön, aber quick and dirty)

Fazit:
Rhasspy 2.5-pre läuft (mit Klimmzügen) jetzt zwar, aber vom Hocker reißt es mich gegenüber der 2.4.19 nicht.
Für mich pers. nur eine Aufhübschung des GUI und ein kleiner Geschwindigkeitsvorteil und mehr Konfigurationsaufwand seitens ioBroker/MQTT.
Bei mir bleibt die 2.5er jedenfalls erst mal auf dem Test-Raspi
Evtl. bringt es für Dich ja Vorteile, weil Du mit Master/Satellit arbeitest?

Gruß
Jörg

[tobetobe]

Hallo Jörg,

@joergeli said in Rhasspy Offline Sprachsteuerung:

ich habe den Test-Raspi mit Rhasspy 2.5-pre jetzt auf dem gleichen Stand, wie meinen Raspi mit der 2.4.19.

Respekt, da hast du sicher einiges an Zeit investiert. Toller Erfolg - Glückwunsch! Ich hänge noch hinterher, da ich mich zunächst einmal mit mqtt und dem Aufbau von Aufrufen/Abfragen beschäftigt habe...

@joergeli said in Rhasspy Offline Sprachsteuerung:

2.5er-Raspi ebenfalls ein Mosquitto (Port 1883) läuft,

Davon hatte ich im Forum gelesen. Da ich dies nie nachgestellt habe, konnte ich den damit verbundenen Vorteil nicht erkennen. Gut, dass du ihn jetzt aufgezeigt hast (den Vorteil).

@joergeli said in Rhasspy Offline Sprachsteuerung:

Bist Du Dir sicher, daß der Müll in der Datenquelle gespeichert wird?

Nein, ich weiß ja nicht, wie programmiert wurde. Von daher war es nur eine Vermutung und eine Frage, die ich mir gestellt habe. Wenn der mqtt.1 Client das alles speichern würde, wäre es allerdings auch nicht besser. Heißt für mich momentan nur, dass ich das im Auge behalten möchte.

@joergeli said in Rhasspy Offline Sprachsteuerung:

3.) Topics mit JS aufbereiten:
Ich weiß, Du verwendest lieber Node Red
Nein, nein, das ist durchaus überhaupt nicht so. Meine gesamten Rhasspy-Skripts basieren auf JS. Diese versuche ich seit Tagen erfolglos umzubauen. Ich verstehe von JS nur zu wenig, nicht im Prinzip, aber bei der richtigen, fehlerfreien Syntax. Deshalb habe ich gesagt, dass es mir leichter fallen würde, die alte Funktionalität mit Nodered wieder herzustellen, was ich aber gar nicht will. Ich will meine JS Skripte umbauen und weiter verwenden.

Deine Beispiele dürften mir dabei nun wesentlich weiterhelfen. Herzlichen Dank dafür.

@joergeli said in Rhasspy Offline Sprachsteuerung:

Ich glaube mich zu erinnern, daß Du immer im gleichen Datenpunkt speicherst

Nein, auch ich habe unterschiedliche Datenpunkte für die verschiedenen Aktionen. Allerdings rufe ich sehr ähnliche Funktionen, zB ChangeLight, ChangeDimmer, ChangeBlind mit Wildcart auf, also mit Change*. Und danach fische auch ich die Slots heraus, die aber je nach Inhalt von "*" unterschiedlich sein können. Das macht aber für mcih auch nicht so den großen Unterschied. Wichtig ist, dass ich das mit der Adressierung der Intents und dem Auslesen der Slots wieder hinbekomme. Mit deinen Hinweisen sehe ich aber nun, wie es gehen könnte. Getestet habe ich bislang noch nichts...

@joergeli said in Rhasspy Offline Sprachsteuerung:

3.) Wakeword-Erkennung:
Das mache ich wie bei der 2.4.19, aber jetzt über die entspr. Hermes-Datenpunkte.
Das ist für mich auch eine der wichtigen Funktionen, die ich in 2.4.19 schon hatte. Deine Ausführung stimmt mich ebenfalls hoffnungsvoll.

@joergeli said in Rhasspy Offline Sprachsteuerung:

4.) Hermes-LED-Control

Hat für mich momentan auch Priorität 99. Die Skripte und Wakeword haben Vorrang.

@joergeli said in Rhasspy Offline Sprachsteuerung:

5.) Direkte Sprachausgabe via pico-TTS:

Sprachausgabe war unter 2.4.19 ebenfalls kein (Software)Problem. Knifflig war die richtige Hardware-Einstellung zu finden. Ich hoffe, ich bekomme das wieder hin.

@joergeli said in Rhasspy Offline Sprachsteuerung:

6.) mqtt.1-Instanz trennt und verbindet sich häufig

Das Problem hatte ich beim Testen zwischenzeitlich auch einmal. Allerdings konnte ich es relativ eindeutig mit hohem Verkehrsaufkommen korellieren. Ich habe dann auch die Topics reduziert (die standen zum Annähern ans Thema zunächst einfach auf #) und das Problem war behoben. Mit meinem Odroid habe ich allerdings auch eine ganz andere Verarbeitungsleistung zur Verfügung, als du mit deinem Pi4. Kann sein, dass der bei Last empfindlicher reagiert.

@joergeli said in Rhasspy Offline Sprachsteuerung:

Evtl. bringt es für Dich ja Vorteile, weil Du mit Master/Satellit arbeitest?

Kann sein. ich habe mir zum Lernen, besser Verstehen usw einen zweiten Satelliten (Pi3 mit 3€ Mikrofon) aufgebaut. Der Setup war ein Klacks und die Performance ist ebenfalls sehr gut.

Nun will ich testen!!!

[joergeli]

@tobetobe
Hallo Thomas,

ich wollte - hauptsächlich mir selber noch mal klar machen - , wie ich beim Parsen des json-codes auf meine Parameter, die ich ja nur durch Try & Error herausgefunden habe, gekommen bin:

let name = empf_json.slots[0].value.value;
let state = empf_json.slots[1].value.value;

Also, Rhasspy gibt bei "schalte die wandspots ein" folgendes Intent JSON aus ( in Rhasspy GUI Click auf "Show JSON"):

{
    "intent": {
        "name": "Lampen",
        "confidence": 1
    },
    "entities": [
        {
            "entity": "name",
            "value": "wandspots",
            "value_details": {
                "kind": "Unknown",
                "value": "wandspots"
            },
            "raw_value": "wandspots",
            "start": 12,
            "end": 21,
            "raw_start": 12,
            "raw_end": 21
        },
        {
            "entity": "state",
            "value": "ein",
            "value_details": {
                "kind": "Unknown",
                "value": "ein"
            },
            "raw_value": "ein",
            "start": 22,
            "end": 25,
            "raw_start": 22,
            "raw_end": 25
        }
    ],
    "slots": {
        "name": "wandspots",
        "state": "ein"
    },
    "text": "schalte die wandspots ein",
    "raw_text": "schalte die wandspots ein",
    "tokens": [
        "schalte",
        "die",
        "wandspots",
        "ein"
    ],
    "raw_tokens": [
        "schalte",
        "die",
        "wandspots",
        "ein"
    ],
    "wakeword_id": "snowboy"
}

Wenn ich das dann in JS mit

log ("EMPF-CODE: " + empf_code);

anzeigen lasse, gibt das ein (für menschliche Augen) unleserliches JSON aus:

EMPF-CODE: {"input": "schalte die wandspots ein", "intent": {"intentName": "Lampen", "confidenceScore": 1.0}, "siteId": "volti", "id": null, "slots": [{"entity": "name", "value": {"kind": "Unknown", "value": "wandspots"}, "slotName": "name", "rawValue": "wandspots", "confidence": 1.0, "range": {"start": 12, "end": 21, "rawStart": 12, "rawEnd": 21}}, {"entity": "state", "value": {"kind": "Unknown", "value": "ein"}, "slotName": "state", "rawValue": "ein", "confidence": 1.0, "range": {"start": 22, "end": 25, "rawStart": 22, "rawEnd": 25}}], "sessionId": "volti-snowboy-c1906f0e-4a6e-4540-a5a5-6f542f3bae33", "customData": null, "asrTokens": [[{"value": "schalte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}, {"value": "die", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 11, "time": null}, {"value": "wandspots", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 21, "time": null}, {"value": "ein", "confidence": 1.0, "rangeStart": 22, "rangeEnd": 25, "time": null}]], "asrConfidence": null, "rawInput": "schalte die wandspots ein", "wakewordId": "snowboy"}

Deshalb habe ich mir die Mühe gemacht, dieses JSON in eine Textdatei zu kopieren und mit Notepad++ zu strukturieren (d.h. Zeilenumbrüche einfügen und die entspr. Klammern halbwegs untereinander darzustellen), damit man es besser lesen kann. Da wurde mir dann auch klar, woher die beiden Parameter kommen:

EMPF-CODE:
{
"input":	"schalte die wandspots ein",
"intent": 	{	"intentName": "Lampen",
				"confidenceScore": 1.0
			},
"siteId": "volti",
"id": null,
"slots": [
			{ //<--- slots[0]
				"entity": "name",
				"value": { //<---slots[0].value
							"kind": "Unknown",
							"value": "wandspots"	//<------- = slots[0].value.value
						},
				"slotName": "name",
				"rawValue": "wandspots",
				"confidence": 1.0,
				"range": {
							"start": 12,
							"end": 21,
							"rawStart": 12,
							"rawEnd": 21
						}
			},
			{ //<--- slots[1]
				"entity": "state",
				"value": {  //<---slots[1].value
							"kind": "Unknown",
							"value": "ein"		//<------- = slots[1].value.value
						},
				"slotName": "state",
				"rawValue": "ein",
				"confidence": 1.0,
				"range": {
							"start": 22,
							"end": 25,
							"rawStart": 22,
							"rawEnd": 25
						}
			}
		],
"sessionId": "volti-snowboy-36f74062-40c8-47eb-a05c-96d87fd476fb",
"customData": null,
"asrTokens": [
				[
					{
						"value": "schalte",
						"confidence": 1.0,
						"rangeStart": 0,
						"rangeEnd": 7,
						"time": null
					},
					{
						"value": "die",
						"confidence": 1.0,
						"rangeStart": 8,
						"rangeEnd": 11,
						"time": null
					},
					{
						"value": "wandspots",
						"confidence": 1.0,
						"rangeStart": 12,
						"rangeEnd": 21,
						"time": null
					},
					{
						"value": "ein",
						"confidence": 1.0,
						"rangeStart": 22,
						"rangeEnd": 25,
						"time": null
					}
				]
			],
"asrConfidence": null,
"rawInput": "schalte die wandspots ein",
"wakewordId": "snowboy"
}

Das komische dabei ist nur, daß im Intent JSON von Rhasspy folgendes steht:

    "slots": {
        "name": "wandspots",
        "state": "ein"
    },

somit hatte ich zuerst vermutet, daß die Parameter so aussehen müssten:

let name = empf_json.slots.name;
let state = empf_json.slots.state;

dem ist aber nicht so, wie man jetzt im strukturierten Code erkennen kann.
Auch der Begriff

"entities": [ //als Mehrzahl

taucht im strukturierten Code nicht auf - für mich recht merkwürdig.

Fazit:
Im JS das empfangene JSON mitloggen und - auch wenn es Mühe macht - das JSON in eine Textdatei kopieren und manuell strukturieren. Das führt wohl am schnellsten zum Ziel, um die entspr. Parameter auszufiltern.

Gruß
Jörg

[tobetobe]

@joergeli
Guten Morgen Jörg,

ich bin gestern nicht soweit gekommen, wie ich wollte. Begonnen habe ich mit dem neuesten pull. Danach ging erst einmal garnichts mehr und ich musste die Grundfunktionen (Wakeword erkennen, Befehl entgegennehmen und Befehl verstehen) zunächst wiederherstellen. Was mir dabei geholfen hat, ist die Art, wie bei meinem Master/Sat-System die Docker-Prozesse gestartet werden. Bei mir beginnen die Aufrufe mit:

docker run -it     -v "$HOME/...

Der schöne Vorteil ist, dass man im Terminal nun alles mitverfolgen kann, was passiert, da sämtliche DEBUGs und Fehler gelistet werden. So fiel mir auf, dass auf meinem Sat irgendwelche Daten PingPong spielten. Ich musste den mqtt.1 Client abschalten, danach war es gut.

Von daher würde ich dir auch empfehlen, mal mit diesen Parametern zu starten.

Nun stehe ich vor der Frage, ob ich entweder meine Skripte so umbaue, dass sie alles direkt bei meinem Mosquitto abholen, oder wie ich ggf die Parameter des mqtt.1 Client verändern muss, damit dieses PingPong nicht stattfindet.

Im ersten Fall müsste ich alles so aufbauen, wie du das mit require(http) gemacht hast, halt nur mit require(mqtt). Der zweite Fall wäre einfacher, da ich in der bekannten ioBroker-Adressierung bleibe.

Alles nur hinderliche Steine auf dem Weg nach vorne...

So, nun zu deinem letzten Post.

@joergeli said in Rhasspy Offline Sprachsteuerung:

Parameter, die ich ja nur durch Try & Error herausgefunden habe

Mit denen liegst du ja schon mal garnicht so falsch. Was du mit direkter Adressierung [0] und [1] machst, passiert bei mir übrigens durch den Aufruf der Schleife, die die Ergebnisse der Abfragen an den entsprechenden Stellen in das Array schreibt.:

    var intentResult = 'mqtt.1.hermes.intent.Change*';
    var intentArray = [];

    for(var i = 0; i < intentResult.length; i++)
    {
    console.log(intentResult[i]);
    intentArray.push(intentResult[i]);
    }

Das aber nur am Rande.

@joergeli said in Rhasspy Offline Sprachsteuerung:

Rhasspy gibt bei "schalte die wandspots ein" folgendes Intent JSON aus ( in Rhasspy GUI Click auf "Show JSON"):

Diese Ausgabe darfst du nicht mit den JSON-Rohdaten verwechseln. Sie ist bereits von Rhasspy aufbereitet, damit es diese schön leserliche Struktur gibt. Durch die Aufbereitung kommt auch der Begriff "entities" im Plural herein, der ja in den Rohdaten nicht auftaucht, wie du richtig erkannt hast.

@joergeli said in Rhasspy Offline Sprachsteuerung:

Deshalb habe ich mir die Mühe gemacht, ... Da wurde mir dann auch klar, woher die beiden Parameter kommen:

Absolut hilfreich. Die gleiche, oder zumindest eine sehr ähnliche Ausgabe dieses Roh-JSON bekommst du übrigens auch im Terminal, sodass du dir den separaten Aufruf sparen kannst.

@joergeli said in Rhasspy Offline Sprachsteuerung:

Das komische dabei ist nur, daß im Intent JSON von Rhasspy folgendes steht:

Nachvolliziehbar, da diese Daten ja für diese Darstellung aufbereitet wurden. Im Prinzip ist dies also eine Liste der im Befehl verwendeten Slots, die wiederum jeweils aus der Entity (vor dem Doppelpunkt) und dem Value (nach dem Doppelpunkt) bestehen. Also erster Slot Entity "name" mit dem Value "Wandspots" und zweiter Slot mit Entity "state" mit dem Value "ein".

Soweit verstehe ich das alles. Ich hoffe, meine Überlegungen konnten dir weiter helfen.

Grüße
Thomas