SEPIA open-source Sprachassistent: Integration in FHEM?

[gestein]

Oder einfacher in Sepia ein Kommando definieren, dass ausgeführt wird, wenn etwas rückgemeldet werden soll.
z.B. in der Art "set <dumm-device> <Text>", wobei Text neben dem Text auch anderes enthalten könnte (wo soll ausgegeben werden etc.).

Ist natürlich nicht so fancy wie MQTT, sollte aber auch gehen.

lg, Gerhard

[whistler]

Oder einfacher in Sepia ein Kommando definieren, dass ausgeführt wird, wenn etwas rückgemeldet werden soll.
z.B. in der Art "set <dumm-device> <Text>", wobei Text neben dem Text auch anderes enthalten könnte (wo soll ausgegeben werden etc.).

Ist natürlich nicht so fancy wie MQTT, sollte aber auch gehen.

lg, Gerhard

Hi Gehard,

ja das hab ich mir auch gedacht. Aber mein Gedanke war. Sepia Schalte Deckenlicht an. und wenn man dann den Rückmeldetext bekommt per mqtt kann man es auswerten

Ob nun mqtt mehr fancy ist, ich habs nur pragmatisch gesehen. Schick wäre auch, wenn man den Payload vom Clexi Client umlenken kann. Die Ausgabe im Terminal, wenn man verbunden ist.

Wenn ich dich richtig verstanden habe meinst du das Kommando selber was man steuern will über Teach UI. Und jede Lampe/Gerät dort anlernen?
ich wollte mir den Overhead sparen

Gruß Basti

[gestein]

Hallo Basti,

da bin ich wohl noch zuwenig im Thema drinnen, um da wirklich mitdiskutieren zu können.
Ich dachte eher nur an die sprachlichen Rückmeldungen.
Für die Bestätigung von Aktionen (z.B. Statuswechsel) etc. muss dann wohl was anderes her.

Aber wie gesagt, da stehe ich noch ganz am Anfang meines Wissens.
(ich weiß ja noch nicht mal, was ein CLEXI-Server so den ganzen Tag tut noch nie gehört das Wort)

lg, Gerhard

[whistler]

Na ich versuche es mal zu erklären (Florian kann das bestimmt besser).

Der Clexi Server läuft im Hintergrund auf dem Headless Client um mit der Console in der Web GUI Kommunizieren zu können, bzw. dort einen User anmelden zu können.

Deine Idee war ja nicht schlecht, aber der Gedanke die "Audio Rückmeldung" generell umzulenken hatte ich auch schon länger, aber das hatte ich nach hinten geschoben bis die 2.5.0 fertig ist um nicht alle Baustellen gleichzeitig anzugehen.

Und da die Frage wieder aufkam hab ich nur das "verdrängte" Wissen wieder rausgekramt, weil ich das im Github irgendwann gelesen habe.

Und das es MQTT ist war eher Zufall, und ist nicht Zwingend das Mittel erster Wahl nur weil es alle benutzen.
Aber ich weiss wie du das meinst.

Na schauen wir mal. Vielleicht hat Florian für uns ja noch etwas Input was das Thema Broadcast umlenken angeht.
Ich glaub das steht auf der ToDo Liste für nach der 2.5.0

Gruß
Basti

[sepia]

[EDIT] Uups, 4 neue Nachrichten, die muss ich noch lesen ... unten die Antworten auf Basis von Seite 15 ^^

Weil ich ein paar überflüssige Raspberry pi zero habe, wollte ich mir zuerst mal ein Mikrophon kaufen und dann damit am raspberry zero herumspielen, bevor ich noch weitere in Betracht ziehe.

Der kleine Zero hat leider zu wenig RAM für Server und Client, aber wenn du den Server auf einer anderen Maschine lauf lässt sollte der Zero als Client ganz gut laufen. Ich hatte so eine Konstruktion mit ReSpeaker 2Mic Hat mal eine Weile auf meinem Schreibtisch liegen über einen Micro:Bit via Bluetooth getriggert (das Micro:Bit Skript ist auch im GitHub Repository mit dem SEPIA Installer zu finden).

Im Prinzip ist die Presence-Erkennung ein script, dass als Hintergrund-Prozess läuft und kontinuierlich über einen Bluetooth-Adapter schaut, ob ein bestimmtes Bluetooth-Gerät (z.B. ein Schlüsselanhänger, GTag) erreichbar ist.
[...]
Das das lepresence-tool sehr einfach zu installieren ist, werde ich es mal mit einem headless Client versuchen.
Danke für den Tipp.

Damit das ganze gut funktioniert bräuchte man noch eine Funktion im SEPIA Client, die irgendwie auf den Status reagiert, vielleicht den Input blockiert wenn das Presence-Signal noch nicht gesendet wurde o.ä.. Die radikalere Methode, die natürlich jetzt schon geht, wäre den SEPIA Client zu starten und zu stoppen auf Basis des Signals ^^.
SEPIA hat verschiedene Schnittstellen, die dafür gut geeignet sind. Ich kann das ja mal auf die Roadmap setzen

Sonos wäre momentan ein eigenes Modul in fhem, bei dem man z.B. über "set SONOS speak Text" einen Text ausgeben kann.
Man kann auch andere TTS verwenden (z.B. Amazon Polly), oder man spielt ein vorher erzeugtes mp3 ab (über set <SONOS> PlayURI bzw. PlayURITemp).
Hier hilft https://wiki.fhem.de/wiki/SONOS
Zur Zeit wird auch eine einfachere Schnittstelle zu Sonos über MQTT entwickelt.
https://forum.fhem.de/index.php/topic,111711.msg1059442.html#msg1059442
Aber damit habe ich mich noch nicht beschäftigt.

Interessant. In SEPIA v2.5.0 gibt es jetzt auch MQTT Support für Smart Home Geräte, vielleicht kann man damit was erreichen (ich schreibe gerade an den Docs). Alternativ gibt es noch einen MQTT Demo Service mit dem mam beliebige Szenarios bauen kann oder die Schnittstelle des DIY Clients, die jetzt schon die TTS Events überträgt an den CLEXI Server. CLEXI ist ein mini Server der über eine WebSocket Verbindung ein "Remote Terminal" Zugriff auf den Client erlaubt. Basti, weiter oben im Thread, hatte auch schon mal gefragt ob man die Events nicht an ein MQTT System durchreichen kann.
Also, etwas viele Infos auf einmal, aber wie du siehst mangelt es nicht an Ideen und Optionen

Grüße,
Florian

[whistler]

[EDIT] Uups, 4 neue Nachrichten, die muss ich noch lesen ... unten die Antworten auf Basis von Seite 15 ^^

Ok dann warte ich mal die weiteren Antworten nach deinem Lesen ab

Und ja die tts events per mqtt zu verschicken wäre ja schon fast perfekt

Grüße
Basti

[sepia]

Ich schreibe lieber noch eine neue Antwort statt einen Edit zu machen sonst kommt es wahrscheinlich durcheinander ^^.

Also ich glaube wir sind ungefähr auf der selben Wellenlänge, zumindest kam das Thema 2mal zum CLEXI Server
Es gibt jetzt 4 Wege die mehr oder weniger sinnvoll sind. Ich fasse zusammen:

1) Der CLEXI Server leitet die TTS Events durch zu einem MQTT Server. Dazu müsste ich wohl am Besten ein MQTT Modul direkt in CLEXI einbauen. Der Vorteil wäre, dass man den Text von SEPIA direkt bekommt und damit dann machen kann was man will.
2) Man erstellt ein Gerät in FHEM für Sonos und schickt vorgefertigte Befehle dahin
3) Man erstellt ein MQTT Gerät über die neue "Internal HUB" Funktion und schickt vorgefertigte Befehle dorthin
4) Man bastelt sich einen eigenen Service übers SDK der Befehle per MQTT oder FHEM-Interface abschickt

Ich denke Option 1 ist am sinnvollsten für den konkreten Anwendungsfall.

@Florian: Kannst du mir vielleicht einen Tip geben, wenn ich im Code-UI bin möchte er gerne das ich mich einlogge beim Drücken auf Upload.
Meldung erscheint: You need to be logged in to upload a service!

ich hab es sowohl mit der uid1003 und uid1007 getestet. Die1007 hat tester,smarthomeguest,developer als Rolle.
Scheinbar reicht ihm das nicht.
[...]
(Was mir gerade einfällt hast du ggf. am Samstag über Tag an der Stelle noch noch nen Bugfix gemacht, dann müsste ich nochmal updaten, wenn der Fehler kurz vor Release noch drin war)

Hm, eigentlich müsste es genau so klappen. Geändert wurde da am Samstag glaub nix mehr, nur kurz vorher hatte ich den "Save File" Button hinzugefügt und etwas optimiert beim Code.
Kannst du dich noch mal ausloggen und komplett neu einloggen im SEPIA Control HUB. Vielleicht ist da was durcheinander gekommen.
Ich teste auch noch mal ob es bei mir geht.

[EDIT] Also bei mir geht es. User mit den gleichen Rollen, SDK aktiviert in den Core Settings (das würde aber eh eine andere Fehlermeldung senden).
Ich würde einmal nen Logout machen, Seite neu laden und dann noch mal versuchen.
Ach so übrigens der Admin darf glaub keine Services hochladen wenn ich mich recht erinnere

[whistler]

1) Der CLEXI Server leitet die TTS Events durch zu einem MQTT Server. Dazu müsste ich wohl am Besten ein MQTT Modul direkt in CLEXI einbauen. Der Vorteil wäre, dass man den Text von SEPIA direkt bekommt und damit dann machen kann was man will.
4) Man bastelt sich einen eigenen Service übers SDK der Befehle per MQTT oder FHEM-Interface abschickt

Ich denke Option 1 ist am sinnvollsten für den konkreten Anwendungsfall.

Also 1 wäre du musst in die Version was einbauen. Dann wäre es im Standard. Nice.
4 wäre man kann sich selber was bauen wie das Node-Red Sample vom Github. Für die ungeduldigen unter uns

Hm, eigentlich müsste es genau so klappen. Geändert wurde da am Samstag glaub nix mehr, nur kurz vorher hatte ich den "Save File" Button hinzugefügt und etwas optimiert beim Code.
Kannst du dich noch mal ausloggen und komplett neu einloggen im SEPIA Control HUB. Vielleicht ist da was durcheinander gekommen.
Ich teste auch noch mal ob es bei mir geht.

[EDIT] Also bei mir geht es. User mit den gleichen Rollen, SDK aktiviert in den Core Settings (das würde aber eh eine andere Fehlermeldung senden).
Ich würde einmal nen Logout machen, Seite neu laden und dann noch mal versuchen.
Ach so übrigens der Admin darf glaub keine Services hochladen wenn ich mich recht erinnere

Ja ich hab mich gerade nochmal ausgeloggt, bzw. zusätzlich einmal den Browser Task abgeschossen. Jetzt wo ich dein Edit gelesen hatte erinnerte ich mich auch das da was von wegen Admin war. aber es ging ja der 1003 und 1007 nicht. Jetzt geht es aber. Das ist dann der Output:

Code Auswählen Erweitern


net.b07z.sepia.sdk.services.uid1007.MqttDemo has been uploaded! (old triggers removed: 2)


Was ist ja aber jetzt noch nicht verstehe
Wenn ich das Topic jetzt abonniere müsste sich doch im MQTT schon was tun oder? Z.b. Schalte Deckenlicht ein und ich die Bestätigung erhalte.
[EDIT]
Wenn ich jetzt aber nochmal was ändern will. Und neu hochlade, dann speichert er das nicht ab. (Im ersten Muster hatte ich die "falsche" IP genommen. Die Änderung hat er scheinbar dann nicht hochgeladen. Das erklärt auch warum im MQTT Broker nichts ankommt.
Kann ich das sonst auch löschen und neu hochladen?

[EDIT]
Scheinbar "frisst" er das nicht. Ich hab es der einfachheithalber als MQTTDemo wieder gespeichert. Vielleicht war das zu einfach gedacht. und wird von den Samples wieder überschrieben.

Ich hab es der einfachheithalber mal im MQTT.fx abonniert, um erstmal zu sehen ob überhaupt was ankommt.

Achso ja in den coresettings ist das sdk enabled. Aber wir du schon sagtest wäre vermutlich eine andere Fehlermeldung gekommen

[EDIT]
Ich hab mal einen Screenshot gemacht, wenn ich mich nach dem Upload auslogge und wieder anmelde.
Erhalte ich quasi eine leere Auswahlbox. Müsste da mein Eintrag nicht auftauchen?

[gestein]

Hallo Florian,

vielen Dank für Deinen Support.

Der kleine Zero hat leider zu wenig RAM für Server und Client, aber wenn du den Server auf einer anderen Maschine lauf lässt sollte der Zero als Client ganz gut laufen. Ich hatte so eine Konstruktion mit ReSpeaker 2Mic Hat mal eine Weile auf meinem Schreibtisch liegen über einen Micro:Bit via Bluetooth getriggert (das Micro:Bit Skript ist auch im GitHub Repository mit dem SEPIA Installer zu finden).

Ja, auf dem Zero würde nur der Client laufen. Der Server ist mein alter Rpi 3. Auf dem läuft sonst nix - nur der Sepia-Server.
Dafür würde im Endausbau wahrscheinlich je Zimmer ein Zero samt Microphone notwendig werden.

Damit das ganze gut funktioniert bräuchte man noch eine Funktion im SEPIA Client, die irgendwie auf den Status reagiert, vielleicht den Input blockiert wenn das Presence-Signal noch nicht gesendet wurde o.ä.. Die radikalere Methode, die natürlich jetzt schon geht, wäre den SEPIA Client zu starten und zu stoppen auf Basis des Signals ^^.
SEPIA hat verschiedene Schnittstellen, die dafür gut geeignet sind. Ich kann das ja mal auf die Roadmap setzen

Das war anders gemeint.
Das lepresence sollte einfach nur parallel zum Sepia laufen. Ich bräuchte keine eigene Schnittstelle, das Ganze ist für fhem.
Cool wäre es zwar, wenn Sepia wüßte wer in welchem Zimmer ist, aber ich glaube das ist zu komplex.

lg, Gerhard

[sepia]

Also 1 wäre du musst in die Version was einbauen. Dann wäre es im Standard. Nice.
4 wäre man kann sich selber was bauen wie das Node-Red Sample vom Github. Für die ungeduldigen unter uns

Ja genau. Der Vorteil ist, dass ich CLEXI Plugins unabhängig vom SEPIA release pushen kann, das sollte sich also nicht so lange ziehen diesmal ^^.

Wenn ich jetzt aber nochmal was ändern will. Und neu hochlade, dann speichert er das nicht ab. (Im ersten Muster hatte ich die "falsche" IP genommen. Die Änderung hat er scheinbar dann nicht hochgeladen. Das erklärt auch warum im MQTT Broker nichts ankommt.
Kann ich das sonst auch löschen und neu hochladen?
[...]
[EDIT]
Scheinbar "frisst" er das nicht. Ich hab es der einfachheithalber als MQTTDemo wieder gespeichert. Vielleicht war das zu einfach gedacht. und wird von den Samples wieder überschrieben.

Also das Prinzip ist, dass beim erneuten Hochladen die alten Daten überschrieben werden, wenn sich die Variable "CMD_NAME"" nicht ändert (hier z.B. String CMD_NAME = "mqtt").
Es gibt auch einen Server Endpoint um Services komplett zu löschen. Dummerweise ist der noch nicht im Control HUB eingebaut . Habs direkt mal (wieder) auf die To-Do Liste gesetzt ^^.

[EDIT]
Ich hab mal einen Screenshot gemacht, wenn ich mich nach dem Upload auslogge und wieder anmelde.
Erhalte ich quasi eine leere Auswahlbox. Müsste da mein Eintrag nicht auftauchen?

Es ist leider momentan noch so, dass in der Auswahl nur Services auftauchen die im GitHub Repository liegen (nach Druck auf "Online Repo."), sprich es gibt zur Zeit keine Möglichkeit die Daten vom SEPIA Server zu laden. Die liegen da auch nur als Java Bytecode . Ein Workaround ist den Service vom online Repo zu laden, zu bearbeiten und dann vorher mit dem (neuen) Button "Save File" auf der Festplatte zu speichern und beim nächsten mal von dort zu laden.

Die Verbindung zum MQTT Broker klappte jetzt noch nicht?

Ja, auf dem Zero würde nur der Client laufen. Der Server ist mein alter Rpi 3. Auf dem läuft sonst nix - nur der Sepia-Server.
Dafür würde im Endausbau wahrscheinlich je Zimmer ein Zero samt Microphone notwendig werden.

Wenn du die Zeros eh hast mach das so. Ich hatte bei mir allerdings bisher immer das Gefühl, dass die Wifi Verbindung der Kleinen deutlich instabiler ist. Ich weiß nicht ob das an der integrierten Antenne/Hardware liegt oder ob das Gerät insgesamt Performance Probleme hat. Am Besten du setzt erstmal einen auf und lässt den testweise ein paar Tage laufen.

Das war anders gemeint.
Das lepresence sollte einfach nur parallel zum Sepia laufen. Ich bräuchte keine eigene Schnittstelle, das Ganze ist für fhem.
Cool wäre es zwar, wenn Sepia wüßte wer in welchem Zimmer ist, aber ich glaube das ist zu komplex.

Ach so, haha. Naja die Idee wird jetzt wachsen in meinem Kopf ... wie bei Inception

Bin raus für Heute, gute Nacht wünsche ich euch
Florian

[whistler]

Die Verbindung zum MQTT Broker klappte jetzt noch nicht?

Nein geht immer noch nicht, so dachte ich ja auch, und hab die Datei bearbeitet (IP adresse angepasst) und hochgeladen.
Leider wird beim schalten von Lampen / Geräten über den client oder so aber nicht per mqtt verschickt, bzw. kommt nichts an.
[EDIT]
Layer 8 wie man so schön sagt
das kleine Zauberwort MQTT im Satz, dann läuft es auch. Mal sehen ob deine Demo dann auch irgendwo noch die Client Antwort versteckt.


Gute Nacht

[whistler]

Hallo Florian,

ich hab jetzt nochmal ein wenig mit dem MQTTDemo gespielt.
Abschicken klappt jetzt sobald man dann natürlich auch mqtt an den Anfang oder Ende schreibt. (Das könnte man per Regex ja anpassen)

Aber ich ich fände das direkte MQTT "SEPIA's MQTT Connector" sehr interessant.
Das ist vermutlich noch ein Teil wo noch Doku fehlt oder?

Das würde dann vermutlich parallel zum schalten auch MQTT Meldungen verfassen und es wäre kein RAW Text mehr.
Dein MQTT Demo schlüsselt ja schon ziemlich viel auf, bis auf den eigentlichen Namen.

Code Auswählen Erweitern

defmod ej3_MQTT_Sepia expandJSON MQTT_Sepia.*:.{.*} .*

Damit lässt sich zumindest bei vorhandenem MQTT Device der empfangene JSON String direkt in Readings zerlegen im Fhem.

Wenn du schon was "wenn auch unformatiertes" für Tester hast an Doku dann teste ich auch mal den anderen MQTT weg.

Vielen Dank und Klasse Arbeit.

Gruß
Basti

[sepia]

ich hab jetzt nochmal ein wenig mit dem MQTTDemo gespielt.
Abschicken klappt jetzt sobald man dann natürlich auch mqtt an den Anfang oder Ende schreibt. (Das könnte man per Regex ja anpassen)

Hi Basti. Ja das "mqtt" Schlüsselwort war nötig in dem Demo, um es deutlich abzutrennen von SEPIA's bereits bekannten Smart Home Befehlen.

Aber ich ich fände das direkte MQTT "SEPIA's MQTT Connector" sehr interessant.
Das ist vermutlich noch ein Teil wo noch Doku fehlt oder?

Das würde dann vermutlich parallel zum schalten auch MQTT Meldungen verfassen und es wäre kein RAW Text mehr.
Dein MQTT Demo schlüsselt ja schon ziemlich viel auf, bis auf den eigentlichen Namen.

Ja, an der Doku schreibe ich gerade
Der MQTT Connector funktioniert so, dass man in der Smart Home Sektion im SEPIA Control HUB selber Geräte erstellt und mit einem MQTT Topic/Channel verknüpft. SEPIA horcht dann auf diesem Kanal nach State Änderungen um das Device intern aktuell zu halten und published State Änderungen, die via SEPIA Client reinkommen in dem Topic als z.B. {"state": "70%"} für "Lampe auf 70%". Device type und room etc. werden durch den Topic Namen bestimmt.

Code Auswählen Erweitern

defmod ej3_MQTT_Sepia expandJSON MQTT_Sepia.*:.{.*} .*

Damit lässt sich zumindest bei vorhandenem MQTT Device der empfangene JSON String direkt in Readings zerlegen im Fhem.

Interessant. Ich hatte mich bisher noch nicht mit MQTT + FHEM beschäftigt, es ging immer eher um NodeRED, aber vielleicht sollte ich das mal nachholen 

Wenn du schon was "wenn auch unformatiertes" für Tester hast an Doku dann teste ich auch mal den anderen MQTT weg.

Die Smart Home Sektion in den Docs ist schon etwas gewachsen, wichtig ist der Teil "Internal HUB". Im Laufe des Tages sollte noch mehr dazu kommen, vielleicht auch schon der MQTT Teil
https://github.com/SEPIA-Framework/sepia-docs/wiki/Smart-Home-Controls#tutorial-sepia-internal-multi-hub

[sepia]

Die Anleitungen für die neue "Internal HUB" Funktion inklusive simultaner Nutzung von FHEM, openHAB, ioBroker und MQTT ist nun verfügbar 
https://github.com/SEPIA-Framework/sepia-docs/wiki/Smart-Home-Controls#tutorial-sepia-internal-multi-hub

[whistler]

Die Anleitungen für die neue "Internal HUB" Funktion inklusive simultaner Nutzung von FHEM, openHAB, ioBroker und MQTT ist nun verfügbar 
https://github.com/SEPIA-Framework/sepia-docs/wiki/Smart-Home-Controls#tutorial-sepia-internal-multi-hub

Kommt ja genau richtig

Ich hab direkt ne Frage (leider).

bisher hab ich ja fhem also HUB eingerichtet. Gedanklich, weil ich aus dem Schreiben nicht ganz schlau werde.
Ich stelle um auf Internal und hänge da Interface FHEM eine ebene tiefer wieder ein und dazu parallel dann MQTT?

Muss ich dann alles neu einstellen bzgl. Fhem oder liest er dann brav alles wieder wie gewohnt aus?

Danke dir. Vom Prinzip sieht die Doku auf den ersten Blick aber gut aus
[EDIT]
Okay ich habs gerade einfach ausprobiert, zwei Interfaces angelegt MQTT und FHEM.
Jedes Device kann nur einem Interface zugeordnet werden. Richtig?

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

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

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.

Und mal einen vorsichtigen schönen Feiertag (da ja nur teilweise heute)

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


Gruß
Basti