SEPIA open-source Sprachassistent: Integration in FHEM?

[whistler]

Hallo Florian,

ich hab in dem Zuge nochmal etwas mit dem Satzbau rumgespielt.
sepia-name Deckenlicht
schalte das deckenlicht im wohnzimmer ein -> EIN OK
schalte deckenlicht im wohnzimmer aus -> AUS OK
schalte deckenlicht im wohnzimmer -> TOGGLE OK
schalte decken licht im wohnzimmer ein -> UPS
schalte decken licht im wohnzimmer aus -> UPS
schalte decken licht im wohnzimmer -> UPS

sepia-name Esstisch Licht
schalte das Esstisch Licht im wohnzimmer ein -> EIN OK
schalte Esstisch Licht im wohnzimmer aus -> AUS OK
schalte Esstisch Licht im wohnzimmer -> TOGGLE OK
schalte Esstischlicht im wohnzimmer ein -> UPS
schalte Esstischlicht im wohnzimmer aus -> UPS
schalte Esstischlicht im wohnzimmer -> UPS

sepia-name Esstisch Hintergrund Licht
schalte das Esstisch Hintergrund Licht im wohnzimmer ein -> EIN OK
schalte Esstisch Hintergrund Licht im wohnzimmer aus -> AUS OK
schalte Esstisch Hintergrund Licht im wohnzimmer -> TOGGLE OK
schalte Esstisch Hintergrundlicht im wohnzimmer ein -> UPS
schalte Esstisch Hintergrundlicht im wohnzimmer aus -> UPS
schalte Esstisch Hintergrundlicht im wohnzimmer -> UPS

sepia-type ist jeweils light.

Ich hab beim einsprechen per Sprache immer das genommen, was er aufgenommen hat, als im chat deswegen die Schreibweisen.
Ist dir das Thema bekannt oder hast du eine andere Idee wie man die Namen speicher sollte.

Die UPS Einträge sind immer dann wenn man in den chat reinschreibt und dann nicht genau darauf achtet mit den leerzeichen dazwischen wie er es vorher "aufgenommen" hat.

Ich hoffe das war verständlich genug erklärt soweit.

Danke & Gruß
Basti

[sepia]

Okay ich habs gerade einfach ausprobiert, zwei Interfaces angelegt MQTT und FHEM.
Jedes Device kann nur einem Interface zugeordnet werden. Richtig?

Jede "Device card" im SEPIA HUB kann nur ein Interface haben aber theoretisch kannst du das selbe Gerät auch über mehrere Interfaces steuern. Ich hatte zum testen z.B. mal meine Hue Lights über FHEM, openHAB und ioBroker laufen ^^.

Damit muss ich die Devices zwischen FHEM und SEPIA händisch herstellen oder?
Sind damit die Attribute in fhem auch ungültig? sepia-room sepia-name ....?

Ja und ja, leider. Das war eine bewusste Entscheidung, denn die Alternative wäre, dass ständig von jedem HUB alle Geräte geladen werden, auch wenn diese z.B. als "hidden" markiert sind (und es war einfacher umzusetzen). Es ist jetzt so, dass z.B. von FHEM nur noch der "state" geladen wird quasi "on-demand". Der ganze Rest passiert innerhalb von SEPIA. Wenn man sehr viele Geräte hat ist das sicher ärgerlich, aber der Vorteil ist, dass z.B. die "Registrierung" des FHEM Interfaces in dem Fall nicht mehr nötig ist und alles deutlich effizienter läuft.
Vielleicht gibt es aber die Möglichkeit eine "import" Funktion zu bauen, da muss ich mal drüber nachdenken

Und der Raum und Type ist quasi nur für Sepia interessant und taucht nicht im payload von MQTT mit auf, sondern ist nur für Sepia interessant für die Ermittlung des Geräts bei der Spracheingabe.

und über das Topic im Node-Red Beispiel wird dann der Raum etc. gesteuert.
Das war deine Diskussion in dem angesprochenen Github Issue wo es darum ging oder per topic oder payload.

Ja genau.

Hattest du über ein Sowohl als auch nachgedacht? Vielleicht auf der ToDo Liste?
Ist vermutlich Ansichtssache das Payload zu parsen geht ja fast von alleine im fhem und man erhält entsprechende Readings.

Meinst du als MQTT payload auch "room" und "type" etc. mit zu übergeben?
Die Idee kam mir schon in den Sinn, "deviceId" wäre eventuell auch nützlich, aber ich wollte erstmal abwarten ob es wirklich nötig ist bevor ich den payload overloade

Also ich glaube das "zusätzliche" ausgeben per MQTT um die TTS Ausgabe (an Sonos LMS) im Fhem zu lösen geht dann auf dem Weg nicht so direkt.
Und wird vermutlich nur über den Clexi gehen, wie von dir schon angedeutet.

Ja genau, das sind eher 2 verschiedene Theme. Man könnte allerdings das Interface "missbrauchen" für gewisse Zwecke ^^. Ich spinne mal etwas rum, aber z.B. könnte man sich Geräte namens "Broadcaster 1, 2, 3 ..." erstellen, die als "Custom Config" (set commands) bestimmte MQTT Payloads haben wie '{ "enable" : "Good Morning", "disable" : "Good Night" }' und über die Teach UI dann sowas wie "Good Morning" mit dem Befehl "Switch on Broadcaster 1 device" überschreiben. Dann hätte man daraus einen speziellen MQTT Befehl gemacht den man irgendwo weiterverarbeiten kann. Ob das sinnvoll ist überlasse ich mal dem Leser (geht vermutlich noch einfacher mit einem eigenen Service).

Zumindest der "Rollback" auf das reine FHEM Interface klappt ohne viel Mucken.

Hehe ja, da sollte es keine Probleme geben. Das "Internal" Interface ist komplett nichtinvasiv

ich hab in dem Zuge nochmal etwas mit dem Satzbau rumgespielt.
sepia-name Deckenlicht
schalte das deckenlicht im wohnzimmer ein -> EIN OK
schalte deckenlicht im wohnzimmer aus -> AUS OK
schalte deckenlicht im wohnzimmer -> TOGGLE OK
...
...

Cool, danke für die Tests! Das gucke ich mir Morgen mal genauer an.

Gruß und schönen Abend,
Florian

[whistler]

Guten Morgen Florian,

ich hab glaubig noch was gefunden bzw. eine Frage.

Was ist das wenn der Sepia Client (Pseudo Headless Client) erst den Roten Ring hat also zum Empfang von Sprache und dann in einen Grauen dauerkreisenden Ring umspringt?

Mir war als hätte ich das schonmal gelesen. Auf einem Headless Client ja nicht so schön. Aktuell hängen die Geräte noch am HDMI bzw. VNC.
Aber eine Aktive Rückmeldung (ich weiss noch nicht wie) wäre natürlich Nice, das der Client nicht mehr Okay ist.
Quasi ein Healthy Status

Achso in dem Moment ist auch bei Online im Header dein Blinken fürs Wakeword weg, weil vermutlich das Micro sich "aufgehängt" hat.

Okay per Remote Terminal kann man noch ein Reload machen. Dort ist der Status vom Client auch noch Okay.

Gute Nacht.

Gruß
Basti

[sepia]

Was ist das wenn der Sepia Client (Pseudo Headless Client) erst den Roten Ring hat also zum Empfang von Sprache und dann in einen Grauen dauerkreisenden Ring umspringt?
[...]
eine Aktive Rückmeldung (ich weiss noch nicht wie) wäre natürlich Nice, das der Client nicht mehr Okay ist.
Quasi ein Healthy Status
[...]
Okay per Remote Terminal kann man noch ein Reload machen. Dort ist der Status vom Client auch noch Okay.

Hi,

Wenn das Mikro grau ist heißt das es gab einen Fehler beim In oder Output . Das passiert z.B. gerne mal wenn man den Client ganz normal über den Browser lädt und keine Interaktion mit dem Interface hatte (sprich irgendwas angeklickt hat) bevor das Wake-Word angeht oder die Sprachausgabe triggert. Im RPi Client wird das verhindert durch ein Browser Flag, das dieses "Sicherheitsfeature" deaktiviert. Gelegentlich kann es auch passieren, dass es ein Verbindungsproblem gab während der Ein-/Ausgabe.
Wenn man Zugriff hat auf ein Display kann man den Fehler normalerweise durch einen Long-Press auf das Mikrofon beheben. Das führt zum Audio Reset.
Wenn das im "headless" Modus passiert ist es leider wirklich zur Zeit noch ein Problem. Wie du bemerkt hast hilft da nur ein Reload via remote terminal  Ich überlege zur Zeit noch was man da am besten machen könnte. Vielleicht ein automatisches Neuladen der App nach einem Timeout, aber so dass irgendwie keine Endlosschleife entsteht 

Grüße

[whistler]

Hi,

Wenn das Mikro grau ist heißt das es gab einen Fehler beim In oder Output . Das passiert z.B. gerne mal wenn man den Client ganz normal über den Browser lädt und keine Interaktion mit dem Interface hatte (sprich irgendwas angeklickt hat) bevor das Wake-Word angeht oder die Sprachausgabe triggert. Im RPi Client wird das verhindert durch ein Browser Flag, das dieses "Sicherheitsfeature" deaktiviert. Gelegentlich kann es auch passieren, dass es ein Verbindungsproblem gab während der Ein-/Ausgabe.
Wenn man Zugriff hat auf ein Display kann man den Fehler normalerweise durch einen Long-Press auf das Mikrofon beheben. Das führt zum Audio Reset.
Wenn das im "headless" Modus passiert ist es leider wirklich zur Zeit noch ein Problem. Wie du bemerkt hast hilft da nur ein Reload via remote terminal  Ich überlege zur Zeit noch was man da am besten machen könnte. Vielleicht ein automatisches Neuladen der App nach einem Timeout, aber so dass irgendwie keine Endlosschleife entsteht 

Grüße

Nice wäre, wenn es irgendwo "mitgeschrieben" würde und man es zumindest im ersten Schritt mitbekommen würde
Langfristig natürlich ein Reset oder sowas in der Art
Aber ja ich hab da auch gerade keine Schlaue Idee.

Grüße

[whistler]

Jede "Device card" im SEPIA HUB kann nur ein Interface haben aber theoretisch kannst du das selbe Gerät auch über mehrere Interfaces steuern. Ich hatte zum testen z.B. mal meine Hue Lights über FHEM, openHAB und ioBroker laufen ^^.

Na dann müsstest du die Lampe z.b. drei mal im Sepia anlegen mit jeweils einem Device richtig? in dem Fall dann wohl eher eins mit MQTT und allen dreien verarbeiten Aber beim testen geht natürlich alles

Ja und ja, leider. Das war eine bewusste Entscheidung, denn die Alternative wäre, dass ständig von jedem HUB alle Geräte geladen werden, auch wenn diese z.B. als "hidden" markiert sind (und es war einfacher umzusetzen). Es ist jetzt so, dass z.B. von FHEM nur noch der "state" geladen wird quasi "on-demand". Der ganze Rest passiert innerhalb von SEPIA. Wenn man sehr viele Geräte hat ist das sicher ärgerlich, aber der Vorteil ist, dass z.B. die "Registrierung" des FHEM Interfaces in dem Fall nicht mehr nötig ist und alles deutlich effizienter läuft.
Vielleicht gibt es aber die Möglichkeit eine "import" Funktion zu bauen, da muss ich mal drüber nachdenken

Ja ist vermutlich einfacher die Entscheidung, wenn man nicht schon alles einmal eingerichtet hat und jetzt anfangen würde
Zum Thema Import. Vielleicht kann man "auch wenn du das natürlich sicher ungern hast" direkt in der DB ansetzen oder über die API.

Meinst du als MQTT payload auch "room" und "type" etc. mit zu übergeben?
Die Idee kam mir schon in den Sinn, "deviceId" wäre eventuell auch nützlich, aber ich wollte erstmal abwarten ob es wirklich nötig ist bevor ich den payload overloade

Das wäre quasi nice ja, dann müsste man nur ein Topic abonnieren und kann die Logik im MQTT Endpunkt machen, wobei das in dem TTS Szenario ja nur die halbe Miete wäre, denn man will ja das was geschaltet wurde haben, oder aber man würde davon ausgehen, das was da ankommt, bereits erledigt ist.
Dann könnte man die deviceid room type etc wieder zu einem "TTS fähigem Satz" zusammenbauen und ausgeben.

Ja genau, das sind eher 2 verschiedene Theme. Man könnte allerdings das Interface "missbrauchen" für gewisse Zwecke ^^. Ich spinne mal etwas rum, aber z.B. könnte man sich Geräte namens "Broadcaster 1, 2, 3 ..." erstellen, die als "Custom Config" (set commands) bestimmte MQTT Payloads haben wie '{ "enable" : "Good Morning", "disable" : "Good Night" }' und über die Teach UI dann sowas wie "Good Morning" mit dem Befehl "Switch on Broadcaster 1 device" überschreiben. Dann hätte man daraus einen speziellen MQTT Befehl gemacht den man irgendwo weiterverarbeiten kann. Ob das sinnvoll ist überlasse ich mal dem Leser (geht vermutlich noch einfacher mit einem eigenen Service).

Man verlagert damit quasi nur die Stellen wo man schrauben muss

Gruß
Basti

[sepia]

Nice wäre, wenn es irgendwo "mitgeschrieben" würde und man es zumindest im ersten Schritt mitbekommen würde

Ja, definitiv. Wenn man die LEDs des ReSpeaker integriert (oder beliebige LEDs, ich denke da wieder an eine CLEXI extension) könnte man es zumindest visualisieren, die events für "state":"loading" gibt es ja mittlerweile.

Na dann müsstest du die Lampe z.b. drei mal im Sepia anlegen mit jeweils einem Device richtig? in dem Fall dann wohl eher eins mit MQTT und allen dreien verarbeiten Aber beim testen geht natürlich alles

Ja, ja und ja 

Zum Thema Import. Vielleicht kann man "auch wenn du das natürlich sicher ungern hast" direkt in der DB ansetzen oder über die API.

Im Grunde sind die einzelnen Komponenten schon da, FHEM Device lesen, Custom Device schreiben. Ich frage mich gerade was eigentlich passieren würde wenn man erst im "FHEM Modus" ein Gerät liest, dann auf "Internal" Umschaltet und das Gerät einfach noch mal abspeichert ... vermutlich habe ich irgendwo nen reload drin der das verhindert ... aber vielleicht auch nicht haha

Das wäre quasi nice ja, dann müsste man nur ein Topic abonnieren und kann die Logik im MQTT Endpunkt machen ...

Man arbeitet da quasi mit zwei verschiedenen Weltanschauungen ^^. Ich glaube das MQTT Grundprinzip ist eigentlich 1 Topic pro Device aber man ist natürlich schnell in der Grauzone. Im moment gehe ich davon aus, dass man mit dem Topic Namen alles abbilden kann außer die Informationen über den Client. Vermutlich will man irgendwann wissen von welchem Client die Daten kommen und das lässt sich nicht im Topic abbilden weil die Quelle ja immer der SEPIA Server ist. Ich warte erstmal ab wie sich das Thema entwickelt

[whistler]

Ja, definitiv. Wenn man die LEDs des ReSpeaker integriert (oder beliebige LEDs, ich denke da wieder an eine CLEXI extension) könnte man es zumindest visualisieren, die events für "state":"loading" gibt es ja mittlerweile.

Gib mir mal ein Tipp wo man die Daten am besten abgreifen kann vom Client? Die landen ja nur in der Remote Console am Server, wenn man sich dahin verbunden hat.

Der MQTTDemo Service bekommt davon nichts mit richtig? Kann der denn zumindest vielleicht "Durchlauferhitzer" spielen? Heisst. Er "horcht" mit was passiert und SEPIA schaltet aber trotzdem die FHEM Lampe (Ich nenn sie nun einfach mal so).
Oder macht er wie ich vermute einen Overlaod der Klasse und damit gibt es den Weg zurück zum schalten des Clients nicht?

Nach deiner Einschätzung würde ich mich sonst mal da durch graben.
Die schon mehrfach erwähnte Clexi extension gibts da was zum selber bauen? Also wo man ansetzen kann?

Und ja ich verstehe das du jetzt erstmal die Rückmeldung abwarten willst mit der neuen Version

Schönes Wochenende
Gruß
Basti

[sepia]

Gib mir mal ein Tipp wo man die Daten am besten abgreifen kann vom Client? Die landen ja nur in der Remote Console am Server, wenn man sich dahin verbunden hat.

Ja ich fürchte im Moment geht es nicht anders als mit einem WebSocket Client für CLEXI der die dann weiterleitet (bzw. dem CLEXI Plugin von dem ich schon mal sprach). Ich überlege gerade was man am Besten machen könnte ohne dass es für den User schon wieder eine neue "settings" Datei erfordert

Der MQTTDemo Service bekommt davon nichts mit richtig? Kann der denn zumindest vielleicht "Durchlauferhitzer" spielen? Heisst. Er "horcht" mit was passiert und SEPIA schaltet aber trotzdem die FHEM Lampe (Ich nenn sie nun einfach mal so).
Oder macht er wie ich vermute einen Overlaod der Klasse und damit gibt es den Weg zurück zum schalten des Clients nicht?

Theoretisch geht das, es gibt eine redirect Funktion für Services, d.h. Befehl empfangen, irgendwas machen (z.B. einen MQTT broadcast) und dann weiterleiten an den originalen Smart Home Service, aber um das sauber hinzukriegen müsste ich vermutlich einiges erklären und auch selber noch mal ausprobieren.

Nach deiner Einschätzung würde ich mich sonst mal da durch graben.
Die schon mehrfach erwähnte Clexi extension gibts da was zum selber bauen? Also wo man ansetzen kann?

Ja, ein bisschen ^^:
Im Grunde könnte man wahrscheinlich einfach den CLEXI Broadcaster hacken ^^:
https://github.com/bytemind-de/nodejs-client-extension-interface/blob/master/xtensions/clexi-broadcaster.js
Die Funtion "broadcast" schickt die Nachricht zum CLEXI Client (SEPIA remote terminal z.B.). Man könnte da einfach den MQTT Server einbinden oder irgendeine Aktion die auf den Message Inhalt reagiert. Das Ganze ist in Node.js geschrieben

[whistler]

Ja ich fürchte im Moment geht es nicht anders als mit einem WebSocket Client für CLEXI der die dann weiterleitet (bzw. dem CLEXI Plugin von dem ich schon mal sprach). Ich überlege gerade was man am Besten machen könnte ohne dass es für den User schon wieder eine neue "settings" Datei erfordert

Theoretisch geht das, es gibt eine redirect Funktion für Services, d.h. Befehl empfangen, irgendwas machen (z.B. einen MQTT broadcast) und dann weiterleiten an den originalen Smart Home Service, aber um das sauber hinzukriegen müsste ich vermutlich einiges erklären und auch selber noch mal ausprobieren.

Ja, ein bisschen ^^:
Im Grunde könnte man wahrscheinlich einfach den CLEXI Broadcaster hacken ^^:
https://github.com/bytemind-de/nodejs-client-extension-interface/blob/master/xtensions/clexi-broadcaster.js
Die Funtion "broadcast" schickt die Nachricht zum CLEXI Client (SEPIA remote terminal z.B.). Man könnte da einfach den MQTT Server einbinden oder irgendeine Aktion die auf den Message Inhalt reagiert. Das Ganze ist in Node.js geschrieben

oder den MQTTDemo Service "Hacken", wenn du erlaubst, den Devicename hattest du freundlicherweise im Demo eingebaut nur auskommentiert.
Evtl. würde er auch nicht "Absender" Client an der Stelle preis geben.

Code Auswählen Erweitern


info.setCustomTriggerRegX("^(mqtt2)\\b.*|.*\\b(mqtt2)$", EN);
info.setCustomTriggerRegX("^(mqtt2)\\b.*|.*\\b(mqtt2)$", DE);
info.setCustomTriggerRegXscoreBoost(10); //boost service to increase priority over similar ones


Ich tippe mal hier wird die Entscheidung getroffen. (bin leider jetzt kein Java Spezi)
ich hatte das testweise auf "mqtt2" umgestellt um das zu testen.
Irgendwo weiter unten biegt er dann ab nehme ich an, wenn das regex greift oder nicht.
Kann es sei den das es mit "RegXscroeBoost" zusammen hängt?
[EDIT] ja wenn man die Zeile rausnimmt geht er dran vorbei.

Ansonsten mach ich das wie immer Code kürzen und gucken was passiert. viel kaputt machen kann da ja erstmal nicht

Randfrage zur Python-Bridge:
Würde dir auch die Daten abfangen und "umleiten" und das eigentlich kommando würde dort ebenfalls nicht ankommen?

Aktueller Stand:
Den Text der im Payload vom MQTT Demo ankommt lässt sich automatisch in Readings runterbrechen (Hatte ich weiter vorher schonmal erwähnt).
Ich hab das Payload noch um den Devicenamen erweitert (hattest du wie erwähnt schon auskommentiert drin.
Aktuell natürlich noch alles quick und dirty. Ich könnte ihn auch direkt darüber schalten lassen und eine Rückmeldung geben.

Perhaps a Bug:
Was mir aufgefallen ist beim scrollen (es fällt der Scrollbalken im Code Block zum runterscrollen. Wenn man einmal STRG + F im Firefox drückt um die Browsersuche anzuschalten wird er eingeblendet.

Noch eine Performance Frage. Vermutlich in die Richtung wo du drauf angespielt hast. Es dauert so 2-3 Sekunden bis der Befehl dann im Fhem angekommen ist, und die Meldung im Sepia Client zurück kommt.

Wenn ich das MQTT Demo laufen lasse, kommt die Meldung sofort, vermutlich liegt es daran da er ja auf keine Rückmeldung wartet.

Customizing ist was feines Nur Java ... (Aber ja ich kann mir die Gründe dazu denken)

[EDIT]
Ich hab da noch was anderes gefunden:
https://github.com/SEPIA-Framework/sepia-python-bridge/blob/master/README.md

Der Abschlusssatz klingt doch genau nachdem was hier gebraucht wird, also der Einspringpunkt, wenn ich das nicht völlig falsch verstanden habe

too keep most of SEPIA's default functions intact .

Aber mit der eintrag in der config


Vielen Dank
Gruß
Basti

[sepia]

oder den MQTTDemo Service "Hacken", wenn du erlaubst, den Devicename hattest du freundlicherweise im Demo eingebaut nur auskommentiert.

Erlaubt ist alles
Aber wollten wir nicht den Mikrofon Zustand? Den kriegst du nur von den App Events.
Also:
- Details über den ausgeführten Befehl und das NLU Ergebnis: SEPIA Server
- Details über die App Events (listening, loading, speaking): SEPIA Client

[...]
Irgendwo weiter unten biegt er dann ab nehme ich an, wenn das regex greift oder nicht.
Kann es sei den das es mit "RegXscroreBoost" zusammen hängt?
[EDIT] ja wenn man die Zeile rausnimmt geht er dran vorbei.

Für die regular expressions ist das Modul 'getKeywordAnalyzerResult' in der NLU-Chain zuständig. Das funktioniert so:
- Erst werden alle regular expressions durchlaufen und geguckt welche davon greifen. Hier im Beispiel wären das dann alle Sätze die mit "mqtt2" anfangen oder enden.
- Für alle Services, die eine passende RegExp hatten werden dann die Parameter geprüft (device type, room, etc. in diesem Fall)
- Da sich der Smart Home Service und der MqttDemo ziemlich ähnlich sind ist die Wahrscheinlichkeit groß, dass beide gültige Treffer erzielen, deshalb wird dann für beide eine "score" berechnet, die mit dem "setCustomTriggerRegXscoreBoost" künstlich "geboosted" werden kann. 10 ist in dem Beispiel schon ziemlich hoch, weshalb es fast sicher ist, dass der Service dann am Ende gewinnt

Randfrage zur Python-Bridge:
Würde dir auch die Daten abfangen und "umleiten" und das eigentlich kommando würde dort ebenfalls nicht ankommen?

Im Grunde ja nur das Problem ist, dass die Daten die du haben willst zu dem Zeitpunkt noch nicht existieren. Konkret heißt das entweder du gehst in das Python-Bridge Modul ohne die Infos zu haben (wenn es in der NLU-Chain vor 'getKeywordAnalyzerResult' kommt) oder du kommst nicht rein weil der Keyword-Analyzer schon ein Ergebnis gefunden hat.
Der sinnvollste Ort für einen MQTT publish wäre demnach direkt am Ende der NLU-Chain und vor dem Service "getResult".
Das ist eigentlich genau der Punkt, an dem der SEPIA "/understand" Endpoint sein Ergebnis ausspuckt (siehe 'Assistant Testing' Seite im Control HUB).

Aktueller Stand:
Den Text der im Payload vom MQTT Demo ankommt lässt sich automatisch in Readings runterbrechen (Hatte ich weiter vorher schonmal erwähnt).
Ich hab das Payload noch um den Devicenamen erweitert (hattest du wie erwähnt schon auskommentiert drin.
Aktuell natürlich noch alles quick und dirty. Ich könnte ihn auch direkt darüber schalten lassen und eine Rückmeldung geben.

Das heißt wenn du diese Funktion (NLU -> MQTT) brauchst fängst du deinen Satz einfach mit "mqtt ..." an bzw. endest mit "... via mqtt"? Oder hast du noch an der regular expression gewerkelt?

Perhaps a Bug:
Was mir aufgefallen ist beim scrollen (es fällt der Scrollbalken im Code Block zum runterscrollen. Wenn man einmal STRG + F im Firefox drückt um die Browsersuche anzuschalten wird er eingeblendet.

Browser machen mich wahnsinnig manchmal. Zum Glück ist wenigstens der IE11 mittlerweile fast komplett ausgestorben ^^.

Noch eine Performance Frage. Vermutlich in die Richtung wo du drauf angespielt hast. Es dauert so 2-3 Sekunden bis der Befehl dann im Fhem angekommen ist, und die Meldung im Sepia Client zurück kommt.

Wenn ich das MQTT Demo laufen lasse, kommt die Meldung sofort, vermutlich liegt es daran da er ja auf keine Rückmeldung wartet.

Ja genau. Ich denke die 2-3 Sekunden extra kommen von dem ping-pong SEPIA -> FHEM -> SEPIA. Ist das ein RPi der im Wifi hängt?

Customizing ist was feines Nur Java ...

Hehe, ja die Entscheidung ist vor vielen Monden gefallen im SEPIA Urvater ILA ... ich habs eigentlich nie bereut, denn Java macht den Code extrem gut wartbar und ich musste über die Jahre einiges komplett aufbrechen und dann wieder flicken ^^. Es konnte ja keiner ahnen, dass ein paar Jahre später alle nur noch auf dem Python Hype-Zug sitzen ... deswegen gibts auch die "Python Bridge" ^^, aber das ist noch ziemlich low-level von der Integration.

Welche Programmiersprache würdest du am liebsten nutzen?

[EDIT]
Ich hab da noch was anderes gefunden:
https://github.com/SEPIA-Framework/sepia-python-bridge/blob/master/README.md
[...]

Siehe Kommentar zur Python-Bridge weiter oben

[whistler]

Erlaubt ist alles
Aber wollten wir nicht den Mikrofon Zustand? Den kriegst du nur von den App Events.
Also:
- Details über den ausgeführten Befehl und das NLU Ergebnis: SEPIA Server
- Details über die App Events (listening, loading, speaking): SEPIA Client

Wir sind ja bei zwei Sachen jetzt, erstmal das was ich selber machen kann. Dachte ich also am Server.
Nicer wäre dann natürlich am Client. Oder generell vielleicht über den Server den Status abfragen welche Clients sind überhaupt da.

Für die regular expressions ist das Modul 'getKeywordAnalyzerResult' in der NLU-Chain zuständig. Das funktioniert so:
- Erst werden alle regular expressions durchlaufen und geguckt welche davon greifen. Hier im Beispiel wären das dann alle Sätze die mit "mqtt2" anfangen oder enden.
- Für alle Services, die eine passende RegExp hatten werden dann die Parameter geprüft (device type, room, etc. in diesem Fall)
- Da sich der Smart Home Service und der MqttDemo ziemlich ähnlich sind ist die Wahrscheinlichkeit groß, dass beide gültige Treffer erzielen, deshalb wird dann für beide eine "score" berechnet, die mit dem "setCustomTriggerRegXscoreBoost" künstlich "geboosted" werden kann. 10 ist in dem Beispiel schon ziemlich hoch, weshalb es fast sicher ist, dass der Service dann am Ende gewinnt

Dann hab ich das System ja gestern schon richtig verstanden und komme im Code nur nicht an den Punkt, wo ich beide Gewinnen lassen kann.
Das er quasi den SmartHome Service und den MQTT Demo nacheinander laufen lässt.
Ich war sogar fast kurz davor mal Github den Code zu laden und offline nach den Stichwörtern zu suchen.
Das hatte ich zwar auch mal online direkt im repository hinbekommen, aber das geht nicht mehr (Keine Ahnung warum ist auch nicht schlimm).

Im Grunde ja nur das Problem ist, dass die Daten die du haben willst zu dem Zeitpunkt noch nicht existieren. Konkret heißt das entweder du gehst in das Python-Bridge Modul ohne die Infos zu haben (wenn es in der NLU-Chain vor 'getKeywordAnalyzerResult' kommt) oder du kommst nicht rein weil der Keyword-Analyzer schon ein Ergebnis gefunden hat.
Der sinnvollste Ort für einen MQTT publish wäre demnach direkt am Ende der NLU-Chain und vor dem Service "getResult".
Das ist eigentlich genau der Punkt, an dem der SEPIA "/understand" Endpoint sein Ergebnis ausspuckt (siehe 'Assistant Testing' Seite im Control HUB).

Das heißt wenn du diese Funktion (NLU -> MQTT) brauchst fängst du deinen Satz einfach mit "mqtt ..." an bzw. endest mit "... via mqtt"? Oder hast du noch an der regular expression gewerkelt?

Code Auswählen Erweitern

To use the Python bridge with your SEPIA-Home installation open the properties file of your SEPIA assist server (usually found at ~/SEPIA/sepia-assist-server/Xtensions/assist.custom.properties) or use the Control-HUB to modify the line that starts with: nlu_interpretation_chain=.... This line represents the NLU interpretation chain of SEPIA. Each entry is one 'step' of the chain and steps are executed from left to right until the best NLU result is found.
If you're running the Python bridge server on the same machine as SEPIA-Home you can add it to the chain like this: ...,WEB:http\://127.0.0.1\:20731/nlu/get_nlu_result,.... Where you put it exactly is up to you but I'd recommend to place it between getPublicDbSentenceMatch (the step that takes care of custom commands defined via the Teach-UI) and getKeywordAnalyzerResult (the most flexible NLU step) too keep most of SEPIA's default functions intact ;-) .

Deswegen hatte ich mich ja über diesen Punkt Gestern Abend oder Heute Morgen gefreut, das beschreibt ja auch was du nochmal wiederholt hast, nur das ich die Einstellung bei mir nicht finden kann
Also entweder noch nicht vorhanden oder schon wieder weg Oder aber ich blind.

Browser machen mich wahnsinnig manchmal. Zum Glück ist wenigstens der IE11 mittlerweile fast komplett ausgestorben ^^.

Kenn ich aber ich wollte es nur mitgeteilt haben.

Ja genau. Ich denke die 2-3 Sekunden extra kommen von dem ping-pong SEPIA -> FHEM -> SEPIA. Ist das ein RPi der im Wifi hängt?

Das war in dem Falle die Sepia App auf dem Handy und ja wifi, wobei ich mir gedacht habe soviele daten werden doch da nicht geschoben, und den text hatte ich geschrieben nicht eingesprochen Ich hab mal nen Screenshot von nem Pi3 mit LAN Anbindung angehängt das sollte sogar der 3+ sein.
Vor dem Pi hab ich einmal per app an handy schalten lassen quasi die Deckenlampe an. (13:17:37 -> 13:17:56 Uhr)
Ich hab schon öfter gedacht hmmm was macht der da

Und nochmal zur Klärung der Server läuft auf einer VM also kein PI sondern echte Hardware glaube 2 Kerne und 4 GB Ram.

Hehe, ja die Entscheidung ist vor vielen Monden gefallen im SEPIA Urvater ILA ... ich habs eigentlich nie bereut, denn Java macht den Code extrem gut wartbar und ich musste über die Jahre einiges komplett aufbrechen und dann wieder flicken ^^. Es konnte ja keiner ahnen, dass ein paar Jahre später alle nur noch auf dem Python Hype-Zug sitzen ... deswegen gibts auch die "Python Bridge" ^^, aber das ist noch ziemlich low-level von der Integration.

Welche Programmiersprache würdest du am liebsten nutzen?

Siehe Kommentar zur Python-Bridge weiter oben

Naja letztendlich ist es ja egal. ob Java oder Python oder whatever.
Also Programmieren eher in VB/VBA/VBScript/ASP/HTML/Javascript.
Regex hab ich irgendwann mit angefangen weil das halt im Fhem und sicher auch anderen super praktisch ist aber du weisst ja selber wie mächtig und hilfreich das sein kann.
node.js kenn ich wird ja auch immer mehr, hab ich aber nie selber mit angefangen. Wäre vermutlich ein einarbeiten.
Perl wegen Fhem Php mag ich nicht so
Powershell batch
und python meistens da wo es mal schnell sein muss
mqtt das mittel der wahl um daten von a nach b zu schieben

Du merkst da ist kein C/C++ in der Liste daher bin ich nie Tief abgetaucht in die Zeiger und Klassenwelt. Klar bekommt nam das hin aber weit weg.
und ja wenn man ne Android App programmiert gehts auch nicht ohne Java, wenns Nativ sein soll.

Also zurück zum Thema da ich den Score vermutlich nicht so beeinflussen kann das der Smarthome und MQTTDemo Service parallel die Dinge durchlaufen, wäre die Frage ob der Einspringpunkt aus deiner Readme per nlu Zurück in die Zukunft oder so ähnlich?
Sprich ob ich was übersehen habe, oder es das tatsächlich bei mir nicht gibt.

Es gibt halt immer einen Unterschied muss ich auf ne neue Version warten, oder kann ich es selber einbauen.
Wobei du ja schon einige Ideen in den Standard übernommen hast. Was vielleicht dem einen oder anderen ja auch helfen könnte dann bei ähnlichen Ideen.

Vielen Dank für deine Antwort
Gruß
Basti

[whistler]

Ja, ein bisschen ^^:
Im Grunde könnte man wahrscheinlich einfach den CLEXI Broadcaster hacken ^^:
https://github.com/bytemind-de/nodejs-client-extension-interface/blob/master/xtensions/clexi-broadcaster.js
Die Funtion "broadcast" schickt die Nachricht zum CLEXI Client (SEPIA remote terminal z.B.). Man könnte da einfach den MQTT Server einbinden oder irgendeine Aktion die auf den Message Inhalt reagiert. Das Ganze ist in Node.js geschrieben

Damit es nicht zu unübersichtlich wird. Ich versuch glaubig das mal. ob ich das per mqtt weitergeleitet bekomme
Ich hab da schon eine Idee, und in der Console taucht es schon im clexi log auf

[EDIT]
Da es ja nur bei mir läuft kann ich ja mit Fehlerroutinen gut ungehen Ist halt nur noch nicht Update sicher
meintest du mit Clexi-Extension das man eine echte Extension einbauen kann?

Also aktueller Stand ist, das ich dachte ich wäre fertig Aber mein Gedanke in den Settings den Voice Output auszuschalten sorgt dafür das er gar nicht mehr generiert wird, sondern nur noch der Text im Chat erzeugt wird, was am dann am Server nicht ankommt, bzw. kein Broadcast mehr erzeugt.

[whistler]

Hallo zusammen,

ich hab mal einen ersten Entwurf erstellt, wie man die TTS Ausgabe per MQTT vom Client umleiten kann auf sein TTS System.

Ich hab das ganze versucht möglichst einfach zu halten und eine kurze Schritt für Schritt Anleitung als PDF angehängt.

Viel Spass damit und gerne Feedback.

[EDIT]
Der Workaround für den Doppelten Sound bei der Ausgabe geht nur bedingt, denn durch das Client muten fehlt auch der coin bei der Ausgabe

Schönes Wochenende.

Gruß
Basti

[sepia]

Ich fürchte wir haben jetzt zu viele Punkte parallel diskutiert Ich versuche mal es etwas zu reduzieren, Falls ich was wichtiges übersehen habe frag einfach noch mal .

Dann hab ich das System ja gestern schon richtig verstanden und komme im Code nur nicht an den Punkt, wo ich beide Gewinnen lassen kann.

Es kann nur einer gewinnen. Bei der gleichen "score" gewinnt der, der als erstes da war
Ich frage mich langsam ob der WebSocket Chat-Server nicht eigentlich der Punkt ist wo man ansetzen sollte. Der könnte vielleicht beim broadcast zum SEPIA Client die Nachricht zusätzlich zu einem MQTT Broker schicken. Das passt auch thematisch irgendwie besser als irgendwelche Hacks imr Assist-Server.

Das war in dem Falle die Sepia App auf dem Handy und ja wifi, wobei ich mir gedacht habe soviele daten werden doch da nicht geschoben, und den text hatte ich geschrieben nicht eingesprochen Ich hab mal nen Screenshot von nem Pi3 mit LAN Anbindung angehängt das sollte sogar der 3+ sein.
Vor dem Pi hab ich einmal per app an handy schalten lassen quasi die Deckenlampe an. (13:17:37 -> 13:17:56 Uhr)
Ich hab schon öfter gedacht hmmm was macht der da

Das ist definitiv zu lang und darf höchstens bei den erstem 1-2 requests passieren wenn sich der Server noch "warm" läuft. Ich würde als erstes mal den Server neustarten. Eventuell lohnt es sich auch im Control HUB auf der "Server Connections" Seite mal die Statistiken des Assist-Servers abzurufen. Seit v2.5.0 bröselt der auch noch besser auf welche Services und API calls wie viel Zeit im Schnitt benötigen.
Wifi am Client war bei mir eigentlich nie ein Problem aber Wifi am Server sollte man vermeiden, nicht so sehr wegen der Datenmengen (die sind klein) sondern eher weil Wifi gerne mal Mikro-Aussetzer hat

Also Programmieren eher in VB/VBA/VBScript/ASP/HTML/Javascript. [...]

Javascript reicht für CLEXI und ich hab auch schon ein paar mal versucht das irgendwie ins SDK zu integrieren, da habe ich aber noch keine gute Lösung gefunden bisher.
C++ packe ich auch nicht an übrigens

meintest du mit Clexi-Extension das man eine echte Extension einbauen kann?

Ursprünglich ja, aber nachdem ich in den Code geguckt habe denke ich das passt besser in die vorhandene Broadcaster Extension.

ich hab mal einen ersten Entwurf erstellt, wie man die TTS Ausgabe per MQTT vom Client umleiten kann auf sein TTS System.
Ich hab das ganze versucht möglichst einfach zu halten und eine kurze Schritt für Schritt Anleitung als PDF angehängt.

Cool, gucke ich mir Morgen sofort an!

Grüße und gute Nacht

[EDIT]
Ok ich war zu neugierig und hab doch direkt reingeguckt.
Auf den ersten Blick sieht das eigentlich genau so aus wie ich mir das vorgestellt hatte :-D , nice!
Ich überlege Morgen mal was man wegen der Sprachausgabe noch machen könnte.