SEPIA open-source Sprachassistent: Integration in FHEM?

Begonnen von sepia, 04 Juli 2019, 12:10:12

Vorheriges Thema - Nächstes Thema

sepia

Zitat von: whistler am 13 Februar 2020, 23:02:43
Ich habe nochmal getestet und im Docker hin und hergeschaltet. master läuft (auch wenn er manchmal hängen bleibt und der container 2 -3 up and downs braucht., mit der dev das gleiche.
Nur am Ende funktioniert beim master dann eben auch GET DEVICE und im dev dann nicht. Da er sich zum git verbindet holt er sich auch das tagesaktuelle dort ab.
Kann ich sonst noch irgendwie wo was nachschauen, mit dem Fehlerlogs kommen wir vermutlich so nicht weiter.

Die Fehlermeldung war "no devices found or failed to contact HUB" richtig?
Das kommt vom "integrations" Endpoint des Assist-Servers und bedeutet beim "getDevices" Aufruf vom Assist-Server zum FHEM HUB kommt aus irgendeinem Grund "null" zurück. In den Assist-Server Logs (sepia-assist-server/log.out) müsste noch eine zusätzliche Meldung auftreten: "FHEM - getDevices FAILED with msg.: ...". Kannst du sowas sehen?

Zitat von: whistler am 13 Februar 2020, 23:02:43
Also sobald ich über den Reverse Proxy den Aufruf mache, gehts ja wieder über SSL und dann kann ich auch den ASR Custom auswählen im Edge und Firefox.
Ahhhh, krass, die ganze Option verschwindet wenn man in Firefox über einen "unsicheren" Server geht. Ich kann das jetzt reproduzieren O_o. Mal gucken ob man da was machen kann, der muss scheinbar schon die Audio API sperren während ich die Kompatibilität prüfe. Ist mir auch neu.

Zitat von: whistler am 13 Februar 2020, 23:02:43
Zumindest per ws: erreicht er den Server und meckert dann immer noch über den Mikrofon Zugriff... Scheinbar reicht die SSL Verbindung nicht. und ws:// ist ihm dann zu wenig.

Jemand hat ein ganz ähnliches Problem in den GitHub Issues gepostet. Vielleicht hängt das mit dem gleichen Problem von oben zusammen.

Zitat von: whistler am 13 Februar 2020, 23:02:43
Dein alles über HTTPS verstehe ich noch nicht 100%, oder meinst du damit HTTPS und WSS?

Ja korrekt gesagt meinte ich SSL Verschlüsselung für beides, also HTTPS und WSS  :D

Zitat von: whistler am 13 Februar 2020, 23:02:43
Test ich mal
also server:20721/sepia z.b.?

Genau, wobei hier "server:20721/sepia" als "https://server:20721/sepia" interpretiert werden würde (wegen dem Pfad /sepia am ende denkt er das wäre ein Proxy und hofft dann auch noch der hat SSL ^^). Falls du also http brauchst kannst du auch die ganze URL eingeben z.B. "http://[my-IP]:20726/sepia". Andere valide Einträge: "192.168.0.10" (falls das ein Rechner mit SEPIA Server wäre, "raspberrypi.local:20721", "raspberrypi.local", usw. sollte alles erkannt werden. Wenn du dir nicht sicher bist kannst du es auch im Desktop Client testen, seit 2.4.1 gibt es eine neue Seite die alle Server Verbindungen anzeigt, erreichbar in der Login Box via "i" oder in den Settings auf Seite 1 ganz Oben (wo früher nur der Hostname stand).

whistler

#136
Zitat von: sepia am 14 Februar 2020, 00:06:12
Die Fehlermeldung war "no devices found or failed to contact HUB" richtig?
Das kommt vom "integrations" Endpoint des Assist-Servers und bedeutet beim "getDevices" Aufruf vom Assist-Server zum FHEM HUB kommt aus irgendeinem Grund "null" zurück. In den Assist-Server Logs (sepia-assist-server/log.out) müsste noch eine zusätzliche Meldung auftreten: "FHEM - getDevices FAILED with msg.: ...". Kannst du sowas sehen?

Mit war so als hätte ich da schon reingeschaut. Bei dem ganzen Testen kann da schonmal was untergehen oder durcheinander kommen. Aber du meinst sicher das hier :-)

2020-02-13 23:11:52 ERROR - FHEM - getDevices FAILED with msg.: No enum constant net.b07z.sepia.server.assist.parameters.SmartDevice.Types.cul
2020-02-13 23:11:52 ERROR - TRACE: java.base/java.lang.Enum.valueOf(Enum.java:240)
2020-02-13 23:11:52 ERROR - TRACE: net.b07z.sepia.server.assist.parameters.SmartDevice$Types.valueOf(SmartDevice.java:33)
2020-02-13 23:11:52 ERROR - TRACE: net.b07z.sepia.server.assist.smarthome.Fhem.buildDeviceFromResponse(Fhem.java:472)
2020-02-13 23:11:52 ERROR - TRACE: net.b07z.sepia.server.assist.smarthome.Fhem.getDevices(Fhem.java:168)
2020-02-13 23:11:52 ERROR - TRACE: net.b07z.sepia.server.assist.endpoints.IntegrationsEndpoint.smartHomeIntegration(IntegrationsEndpoint.java:135)


[EDIT]
Du willst ja sicher ein Testobjekt für deinen FHEM haben. Vielleicht reicht das schon:

define testCUL CUL none 4321



whistler

Zitat von: sepia am 14 Februar 2020, 00:06:12
Ja korrekt gesagt meinte ich SSL Verschlüsselung für beides, also HTTPS und WSS  :D

Okay dann hab ich das noch nicht 100% Prozent verstanden. :-) also mit dem WSS bzw. welche Stelle dann WSS sein muss.

whistler

Zitat von: sepia am 14 Februar 2020, 00:06:12
Genau, wobei hier "server:20721/sepia" als "https://server:20721/sepia" interpretiert werden würde (wegen dem Pfad /sepia am ende denkt er das wäre ein Proxy und hofft dann auch noch der hat SSL ^^). Falls du also http brauchst kannst du auch die ganze URL eingeben z.B. "http://[my-IP]:20726/sepia". Andere valide Einträge: "192.168.0.10" (falls das ein Rechner mit SEPIA Server wäre, "raspberrypi.local:20721", "raspberrypi.local", usw. sollte alles erkannt werden. Wenn du dir nicht sicher bist kannst du es auch im Desktop Client testen, seit 2.4.1 gibt es eine neue Seite die alle Server Verbindungen anzeigt, erreichbar in der Login Box via "i" oder in den Settings auf Seite 1 ganz Oben (wo früher nur der Hostname stand).

Ich denke : oder / mag er das, das hatte ich deinem kommentar versucht, da gabs dann nen sed fehler nehme an beim suchen ersetzen.
habs mal jetzt nur als ip eingetragen, ggf. ergänzt du ja den port so wie es klingt :-)

sepia

Zitat von: whistler am 14 Februar 2020, 00:15:14
Mit war so als hätte ich da schon reingeschaut. Bei dem ganzen Testen kann da schonmal was untergehen oder durcheinander kommen. Aber du meinst sicher das hier :-)

2020-02-13 23:11:52 ERROR - FHEM - getDevices FAILED with msg.: No enum constant net.b07z.sepia.server.assist.parameters.SmartDevice.Types.cul
2020-02-13 23:11:52 ERROR - TRACE: java.base/java.lang.Enum.valueOf(Enum.java:240)
2020-02-13 23:11:52 ERROR - TRACE: net.b07z.sepia.server.assist.parameters.SmartDevice$Types.valueOf(SmartDevice.java:33)
2020-02-13 23:11:52 ERROR - TRACE: net.b07z.sepia.server.assist.smarthome.Fhem.buildDeviceFromResponse(Fhem.java:472)
2020-02-13 23:11:52 ERROR - TRACE: net.b07z.sepia.server.assist.smarthome.Fhem.getDevices(Fhem.java:168)
2020-02-13 23:11:52 ERROR - TRACE: net.b07z.sepia.server.assist.endpoints.IntegrationsEndpoint.smartHomeIntegration(IntegrationsEndpoint.java:135)


Ah! Da ist das Biest! "FHEM - getDevices FAILED with msg.: No enum constant net.b07z.sepia.server.assist.parameters.SmartDevice.Types.cul"
Er sucht einen Device Type den es nicht gibt! Hab gerade noch mal in den Code geguckt und denke ich verstehe jetzt was da passiert und wie man den Bug beheben kann. Stay tuned ^^.

Zitat von: whistler am 14 Februar 2020, 00:15:14
Okay dann hab ich das noch nicht 100% Prozent verstanden. :-) also mit dem WSS bzw. welche Stelle dann WSS sein muss.

Ich hab irgendwie den Kontext verloren, an welcher Stelle war das? :D Generell ist es so, dass eine Seite, die über HTTPS geöffnet wird nur noch Quellen zulässt, die ebenfalls sicher sind, also HTTPS (z.B. Hostname) oder WSS (z.B. CLEXI oder ASR Websocket Server).
Firefox ist jetzt scheinbar auch noch so restriktiv, dass es nicht mal mehr nach der Erlaubnis fürs Mikrofon fragt, wenn es nicht eine localhost oder HTTPS Website ist O_o :-(

Zitat von: whistler am 14 Februar 2020, 00:15:14
Ich denke : oder / mag er das, das hatte ich deinem kommentar versucht, da gabs dann nen sed fehler nehme an beim suchen ersetzen.
habs mal jetzt nur als ip eingetragen, ggf. ergänzt du ja den port so wie es klingt :-)

Verteufelte Sonderzeichen! Es mag sein, dass "sed" da Probleme hat >:( . Ich guck mal was ich das "escapen" muss und wie. Bis dahin einfach per Hand in die "~/clexi/www/sepia/settings.js" eintragen ;-)

whistler

Zitat von: sepia am 14 Februar 2020, 00:54:57
Ah! Da ist das Biest! "FHEM - getDevices FAILED with msg.: No enum constant net.b07z.sepia.server.assist.parameters.SmartDevice.Types.cul"
Er sucht einen Device Type den es nicht gibt! Hab gerade noch mal in den Code geguckt und denke ich verstehe jetzt was da passiert und wie man den Bug beheben kann. Stay tuned ^^.

Kannst du sagen welches Device Schuld ist, also im FHEM, welche SEPIA gerade nicht versteht? :-) Vielleicht kann ich temporär bei mir einen Zwischenlösung machen.

Zitat von: sepia am 14 Februar 2020, 00:54:57
Ich hab irgendwie den Kontext verloren, an welcher Stelle war das? :D Generell ist es so, dass eine Seite, die über HTTPS geöffnet wird nur noch Quellen zulässt, die ebenfalls sicher sind, also HTTPS (z.B. Hostname) oder WSS (z.B. CLEXI oder ASR Websocket Server).
Firefox ist jetzt scheinbar auch noch so restriktiv, dass es nicht mal mehr nach der Erlaubnis fürs Mikrofon fragt, wenn es nicht eine localhost oder HTTPS Website ist O_o :-(

Ich habe SSL per Apache Reverse Proxy und leite sie wir damals raus gefunden entsprechend um.
Der Websocket für den chat und message wird auch über den Proxy umgeleitet. ich komme aber nur per ws: dran und nicht per wss: Verstehe gerade nicht wo ich was vergessen habe.
Es ist quasi das Wiki Sample im Apache.
Der ASR hört scheinbar auch per ws: aber auch den bekomme ich nicht per wss: hin. bestimmt nur eine Dumme Kleinigkeit :-)
Sobald der Client über SSL verbunden ist und der ASR Server antwort, wenn auch nur per ws: kommt die Frage nach dem Mikro im Firefox. diese kann man dann auch Zugriff zulassen Klicken und es kommt das Icon für das aktive Micro. Aber im Client (also Chat verlauf) schreibt er in Rot UI: Mikrofon nicht richtig erkannt oder Zugriff verweigert.


Zitat von: sepia am 14 Februar 2020, 00:54:57
Verteufelte Sonderzeichen! Es mag sein, dass "sed" da Probleme hat >:( . Ich guck mal was ich das "escapen" muss und wie. Bis dahin einfach per Hand in die "~/clexi/www/sepia/settings.js" eintragen ;-)

Wodran erkenne ich nun das er korrekt zum Server verbunden ist?
Direkt noch eine zweite Frage, müsste ich nicht auch noch dem Client eine uid zuweisen können oder läuft das in dem Fall über die clexi-xxx und device id?

Viele Grüße
Basti

sepia

#141
Zitat von: whistler am 14 Februar 2020, 01:05:06
Kannst du sagen welches Device Schuld ist, also im FHEM, welche SEPIA gerade nicht versteht? :-) Vielleicht kann ich temporär bei mir einen Zwischenlösung machen.

Irgendwas, was in "internals" -> "type" mit "cul" anfängt scheinbar oder dieser Wert hat sich irgendwie in "sepia-type" eingeschlichen.
Ich habe einen potentiellen Fix im Dev Branch committed :-)

Zitat von: whistler am 14 Februar 2020, 01:05:06
Ich habe SSL per Apache Reverse Proxy und leite sie wir damals raus gefunden entsprechend um.
Der Websocket für den chat und message wird auch über den Proxy umgeleitet. ich komme aber nur per ws: dran und nicht per wss: Verstehe gerade nicht wo ich was vergessen habe.

Hm da weiß ich gerade auch nicht. Wenn er den Server unter ws://... findet müsste der Proxy ja zumindest korrekt weiterleiten. Das SSL Zertifikat liegt auf dem Apache?

Zitat von: whistler am 14 Februar 2020, 01:05:06
Wodran erkenne ich nun das er korrekt zum Server verbunden ist?
Direkt noch eine zweite Frage, müsste ich nicht auch noch dem Client eine uid zuweisen können oder läuft das in dem Fall über die clexi-xxx und device id?

Äh ja habe vergessen, dass du ja noch im "setup" bist  ::) Es gibt noch den Befehl "call login user [uid] pwd [mein-passwort]" um den User anzumelden. Davor und danach müsste aber "call test" funktionieren. Es gibt auch noch "ping all" da müsste der Client zumindest mit einer Statusmeldung antworten. Das kleine "?" oder der Befehl "help" zeigen auch noch mal eine Liste mit möglichen Befehlen.
Grundsätzlich ist der Ablauf so:
- Der Client fährt hoch, meldet sich mit "be right there" Audio und startet den CLEXI Server
- Falls der "headless" Modus an ist wird die "settings.js" gelesen mit den Einstellungen für "hostname" und CLEXI Zugriff (und diversen anderen Einstellungen)
- Falls der Client sich dann nicht schon selber anmeldet (weil ein Login gespeichert ist) geht er nach ca 8s in den "setup" Modus und meldet sich akustisch mit "ready for Setup"
- ab dann kann man "call login ..." benutzen und müsste ein Feedback bekommen wie z.B. "Login successful"

whistler

Zitat von: sepia am 14 Februar 2020, 01:25:21
Irgendwas, was in "internals" -> "type" mit "cul" anfängt scheinbar oder dieser Wert hat sich irgendwie in "sepia-type" eingeschlichen.
Ich habe einen potentiellen Fix im Dev Branch committed :-)

Bingo läuft :-)

Nun muss ich mich doch damit beschäftigten wie ich dein TTS Install Paket in den Docker Container bekomme. Ich hatte versucht dein Dockerfile anzupassen und selbst zu kompilieren.
Aber das hat leider nicht geklappt und irgendwann hab ich dann aufgegeben :-)


Zitat von: sepia am 14 Februar 2020, 01:25:21
Hm da weiß ich gerade auch nicht. Wenn er den Server unter ws://... findet müsste der Proxy ja zumindest korrekt weiterleiten. Das SSL Zertifikat liegt auf dem Apache?

Ja das das liegt auf dem Apache aktualisiert sich brav selber ist ebenfalls ein Let's Encrypt. Läuft auch für alles Problemlos nur halt das Websocket will nicht.
Macht denn dein nginx Sample was direkt darüber steht das ganze schon so?
Heisst man kann die URLs per HTTPS bzw. WSS aufrufen. Dann versuche ich das nochmal adaptieren auf apache Ebene.


Zitat von: sepia am 14 Februar 2020, 01:25:21
Äh ja habe vergessen, dass du ja noch im "setup" bist  ::) Es gibt noch den Befehl "call login user [uid] pwd [mein-passwort]" um den User anzumelden. Davor und danach müsste aber "call test" funktionieren. Es gibt auch noch "ping all" da müsste der Client zumindest mit einer Statusmeldung antworten. Das kleine "?" oder der Befehl "help" zeigen auch noch mal eine Liste mit möglichen Befehlen.
Grundsätzlich ist der Ablauf so:
- Der Client fährt hoch, meldet sich mit "be right there" Audio und startet den CLEXI Server
- Falls der "headless" Modus an ist wird die "settings.js" gelesen mit den Einstellungen für "hostname" und CLEXI Zugriff (und diversen anderen Einstellungen)
- Falls der Client sich dann nicht schon selber anmeldet (weil ein Login gespeichert ist) geht er nach ca 8s in den "setup" Modus und meldet sich akustisch mit "ready for Setup"
- ab dann kann man "call login ..." benutzen und müsste ein Feedback bekommen wie z.B. "Login successful"

Ja genau sowas meinte ich. Hab ich die Doku überlesen oder gibts die noch nicht? :-)
Den Client guck ich mir dann später an. So klingt das doch schon viel runder. :-)
Headless Modus hatte ich irgendwo gelesen kann man per URL mitgeben :-)

Ich teste damit später mal, jetzt wo ich wieder die Verbindung zum Fhem habe.

Danke nochmal für den schnellen Bugfix :-)

whistler

#143
Hallo zusammen,

Zitat von: sepia am 13 Februar 2020, 21:28:46
Den Android Client interessiert das alles nicht, aber sobald du im Browser bist muss der entweder über eine localhost Adresse laufen (ich hoste mir den Client z.B. oft via lokalem Webserver auf meinem PC) oder alles über HTTPS machen.

Ich hab nach einer alternative temporär gesucht, bis ich das mit dem wss verstanden haben oder jemand einen Tipp hat. :-)

Unter Windows 10 kann man scheinbar recht einfach mit Boardmitteln die Ports auf Localhost biegen:

Windows 10 Sepia auf locahost mappen - alternative zum lokalen Client
cmd als Admin starten die IPs anpassen und die Standard Ports werden gemappt:


set SepiaServerIP=192.168.1.x
set SepiaSTTIP=192.168.1.x
netsh interface portproxy add v4tov4 listenport=20726 connectaddress=%SepiaServerIP%  connectport=20726 listenaddress=127.0.0.1
netsh interface portproxy add v4tov4 listenport=20721 connectaddress=%SepiaServerIP%  connectport=20721 listenaddress=127.0.0.1
netsh interface portproxy add v4tov4 listenport=20722 connectaddress=%SepiaServerIP%  connectport=20722 listenaddress=127.0.0.1
netsh interface portproxy add v4tov4 listenport=20723 connectaddress=%SepiaServerIP%  connectport=20723 listenaddress=127.0.0.1
netsh interface portproxy add v4tov4 listenport=20741 connectaddress=%SepiaSTTIP% connectport=20741 listenaddress=127.0.0.1


Damit funktioniert der Mikrofonzugriff über localhost im Firefox und im Edge (Wobei da scheinbar der Browser den Mic Stream nicht mehr anhält. und somit den Stream nicht verarbeitet)

Wenn du magst kann du mich, also den Eintrag ins Wiki verewigen, wenn sinnvoll.

Allerdings ist die Qualität nicht so optimal in der Erkennung der Wörter. Als STT Server läuft aktuell noch das Standard Docker Image.

[EDIT]
Beispielsatz wenn er brauchbare setze erkennt, klappt es doch mit der Erkennung, aber:
schalte den musik player im badezimmer an -> Führt erst zu einem Okay, und dann zu vertan.
schalte den musikplayer im badezimmer an (Per Texteingabe) -> Das wiederrum schaltet dann auch korrekt
(Kein Teach IT Befehl sondern echt)

Was muss dafür angepasst werden oder wie startet ihr die "musikplayer"?

Aus "Schicke Robo zur Probefahrt" wird "schicke den ruhm zur probefahrt".
Aus "Schicke Robo in die Küche" wird "schicker euro in die küche".

Schönes Wochenende.

whistler

Hallo Florian,

Ich glaube unter https://github.com/SEPIA-Framework/sepia-stt-server gibts einen kleinen Zahlendreher.

Unter REST API am ende, wird aus 20741 dann plötzlich 20471.

sepia

#145
Zitat von: whistler am 14 Februar 2020, 01:40:29
Bingo läuft :-)

Yeah  8)

Zitat von: whistler am 14 Februar 2020, 01:40:29
Nun muss ich mich doch damit beschäftigten wie ich dein TTS Install Paket in den Docker Container bekomme. Ich hatte versucht dein Dockerfile anzupassen und selbst zu kompilieren.
Aber das hat leider nicht geklappt und irgendwann hab ich dann aufgegeben :-)

Ich teste noch ein, zwei Sachen für die neue Version und wollte dann mal ein Update des Docker Containers machen.

Zitat von: whistler am 14 Februar 2020, 01:40:29
Ja das das liegt auf dem Apache aktualisiert sich brav selber ist ebenfalls ein Let's Encrypt. Läuft auch für alles Problemlos nur halt das Websocket will nicht.
Macht denn dein nginx Sample was direkt darüber steht das ganze schon so?
Heisst man kann die URLs per HTTPS bzw. WSS aufrufen. Dann versuche ich das nochmal adaptieren auf apache Ebene.

Ja, bei mir läuft alles über SSL mit Let's Encrypt, auch die Websocket Server. Kennst du die SSL Info Seite aus den Docs? Die Nginx Konfiguration von dort ist ziemlich genau das was ich nutze (im Wesentlichen auch identisch mit der aus der Proxy Info Seite).

Zitat von: whistler am 14 Februar 2020, 01:40:29
Ja genau sowas meinte ich. Hab ich die Doku überlesen oder gibts die noch nicht? :-)
Den Client guck ich mir dann später an. So klingt das doch schon viel runder. :-)
Headless Modus hatte ich irgendwo gelesen kann man per URL mitgeben :-)

Die Doku gibts noch nicht ^^. Erstmal den Release fertig machen ;-)
"Headless mode" geht über "&isHeadless=true", genau. Wobei das im Client selber noch keine wirkliche Auswirkung auf das Display hat sondern nur besagt "lade die settings.js, verbinde dich mit CLEXI, gehe automatisch in Setup Modus". Die einzige Auswirkung auf die Services etc. bisher ist, dass keine externen URLs mehr geöffnet werden, damit der Client nicht "headless" auf einen anderen Browser Tab springt :P

Zitat von: whistler am 14 Februar 2020, 01:40:29
Unter Windows 10 kann man scheinbar recht einfach mit Boardmitteln die Ports auf Localhost biegen:

Windows 10 Sepia auf locahost mappen - alternative zum lokalen Client
cmd als Admin starten die IPs anpassen und die Standard Ports werden gemappt: ...

Cool! Ich hatte auf der SSL Info Seite gerade angefangen eine Sektion "quick Fixes" anzulegen. Da passt das ja wie die Faust aufs Auge ;D

Zitat von: whistler am 14 Februar 2020, 01:40:29
Damit funktioniert der Mikrofonzugriff über localhost im Firefox und im Edge (Wobei da scheinbar der Browser den Mic Stream nicht mehr anhält. und somit den Stream nicht verarbeitet)

Das ist der Chromium Edge oder? Dazu hatte ich im Microsoft Insider Forum schon mal einen Bug-Report erstellt. Die API funktioniert nicht richtig, spuckt aber auch keinen Fehler aus. Die Hoffnung ist, dass Microsoft endlich mal die eigene Spracherkennung einbaut, in Win10 haben sie die Engine ja eh schon integriert und alles läuft offline :)

Zitat von: whistler am 14 Februar 2020, 01:40:29
Allerdings ist die Qualität nicht so optimal in der Erkennung der Wörter. Als STT Server läuft aktuell noch das Standard Docker Image.
...
Aus "Schicke Robo zur Probefahrt" wird "schicke den ruhm zur probefahrt".
Aus "Schicke Robo in die Küche" wird "schicker euro in die küche".

::) =) Das wird das zentrale Thema für SEPIA v2.4.2 ;) Man kann zwar jetzt schon das Sprachmodell anpassen, aber das ist noch viel zu umständlich und man muss fehlende Wörter selber ins Wörterbuch eintragen mit den passenden Phonems. Zahlen sind auch noch nicht so der Knaller.
Ziel ist das Sprachmodell aus einer robusten Basis + Teach-UI Commands aufzubauen und das automatisch aus dem Control HUB raus per 2 Klicks. Dazu muss ich aber noch mal an den STT Server ran.

Zitat von: whistler am 14 Februar 2020, 01:40:29
schalte den musik player im badezimmer an -> Führt erst zu einem Okay, und dann zu vertan

Ich vermute das kollidiert mit dem Service "Client Controls". Wenn du z.B. auf dem Android Handy die VLC App installiert hast versucht er daraus Musik zu starten und prüft ein paar Sekunden später ob irgendwas läuft (Android Intent Krams). Wenn er dann nix registriert kommt "Habs versucht aber bin nicht sicher obs geklappt hat" o.Ä..
Du könntest über die Assistant Test Seite im Control HUB mal prüfen welchen Service er da ausführen wollte ('interpret' oder 'understand' Endpoint).

Ich fände es auch höchst interessant, wenn man über FHEM Musik in verschiedenen Räumen steuern könnte!  :D

Zitat von: whistler am 14 Februar 2020, 01:40:29
Ich glaube unter https://github.com/SEPIA-Framework/sepia-stt-server gibts einen kleinen Zahlendreher.
Unter REST API am ende, wird aus 20741 dann plötzlich 20471.

Uuups, danke! ;D Habs korrigiert.



whistler

Zitat von: sepia am 14 Februar 2020, 17:58:42
Ich teste noch ein, zwei Sachen für die neue Version und wollte dann mal ein Update des Docker Containers machen.

Ja dann warte ich mal und lerne dann, was ich falsch gemacht habe. das libspico zeug krieg ich nicht integriert. Aber meine VM ist nun erstmal auf dem aktuellen Stand.
Ich guck mal, wenn ich da das STT noch nachinstalliert kriege passt das auch erstmal.

Zitat von: sepia am 14 Februar 2020, 17:58:42
Ja, bei mir läuft alles über SSL mit Let's Encrypt, auch die Websocket Server. Kennst du die SSL Info Seite aus den Docs? Die Nginx Konfiguration von dort ist ziemlich genau das was ich nutze (im Wesentlichen auch identisch mit der aus der Proxy Info Seite).


Zitat von: sepia am 14 Februar 2020, 17:58:42
Die Doku gibts noch nicht ^^. Erstmal den Release fertig machen ;-)
"Headless mode" geht über "&isHeadless=true", genau. Wobei das im Client selber noch keine wirkliche Auswirkung auf das Display hat sondern nur besagt "lade die settings.js, verbinde dich mit CLEXI, gehe automatisch in Setup Modus". Die einzige Auswirkung auf die Services etc. bisher ist, dass keine externen URLs mehr geöffnet werden, damit der Client nicht "headless" auf einen anderen Browser Tab springt :P
Okay dann hab ich deine Doku verpasst sehr schön :-) Direkt erstes Feedback, das mit dem login hat geklappt zumindest auf dem Test headless Client.

Mein Problemkind ist vermutlich nicht in den Setupmodus gegangen, dafür aber erstmal hochgefahren. Also versuche ich mal den "halben" headless mode danke für.
ich nehme mal an ich tausche das isApp=true durch isHeadless=true. Ich probiere es einfach mal aus :-)

Zitat von: sepia am 14 Februar 2020, 17:58:42
Cool! Ich hatte auf der SSL Info Seite gerade angefangen eine Sektion "quick Fixes" anzulegen. Da passt das ja wie die Faust aufs Auge ;D
Ja ich hab kurz überlegt, Windows 10 IIS und dann den rest installieren, das war mir aber zu unständlich für mal eben :-)

Zitat von: sepia am 14 Februar 2020, 17:58:42
Das ist der Chromium Edge oder? Dazu hatte ich im Microsoft Insider Forum schon mal einen Bug-Report erstellt. Die API funktioniert nicht richtig, spuckt aber auch keinen Fehler aus. Die Hoffnung ist, dass Microsoft endlich mal die eigene Spracherkennung einbaut, in Win10 haben sie die Engine ja eh schon integriert und alles läuft offline :)

Also Anwendungsfall wäre ein HTPC mit Win10 der eh läuft, daher wäre dort ebenfalls ein Headless Client was Feines, aber eins nach dem anderen. Nur als gedanken was noch so alles geht :-)
Oder halt der Bürorechner oder oder oder :-) Und wenns Offline stattfindet, kann ja das Wakework an sein :-)

Zitat von: sepia am 14 Februar 2020, 17:58:42
::) =) Das wird das zentrale Thema für SEPIA v2.4.2 ;) Man kann zwar jetzt schon das Sprachmodell anpassen, aber das ist noch viel zu umständlich und man muss fehlende Wörter selber ins Wörterbuch eintragen mit den passenden Phonems. Zahlen sind auch noch nicht so der Knaller.
Ziel ist das Sprachmodell aus einer robusten Basis + Teach-UI Commands aufzubauen und das automatisch aus dem Control HUB raus per 2 Klicks. Dazu muss ich aber noch mal an den STT Server ran.

Okay ich wollte ja nur mal so sicher gehen, das ob ich an meinem Einstellungen Hardware drehen muss oder ob es eben so ist, wie es noch ist :-)

Zitat von: sepia am 14 Februar 2020, 17:58:42
Ich vermute das kollidiert mit dem Service "Client Controls". Wenn du z.B. auf dem Android Handy die VLC App installiert hast versucht er daraus Musik zu starten und prüft ein paar Sekunden später ob irgendwas läuft (Android Intent Krams). Wenn er dann nix registriert kommt "Habs versucht aber bin nicht sicher obs geklappt hat" o.Ä..
Du könntest über die Assistant Test Seite im Control HUB mal prüfen welchen Service er da ausführen wollte ('interpret' oder 'understand' Endpoint).

okay ich glaube wir reden aneinander vorbei :-) In fhem hab ich musikplayer als device musikplayer angelegt. und in jedem raum gibt es einen. :-)
Der Test war übrigends im Browser, aber wo ist eigentlich egal. :-)

Du kannst es reproduzieren wenn du "musik player" angibst, dann spricht er nicht den fhem musikplayer an.
Wenn du aber "musikplayer" zusammen nimmst, dann steuert er den player und schaltet ihn an oder aus. :-) jenachdem was du sagst.

Zitat von: sepia am 14 Februar 2020, 17:58:42
Ich fände es auch höchst interessant, wenn man über FHEM Musik in verschiedenen Räumen steuern könnte!  :D

Jetzt schliesst sich der Kreis, warum ich meinte muss ich alles neu installieren. :-) bzw. ich nicht möchte. (Max2play = Image für Multiroom mittels squeezelite) Basiert auf dem Logitech Musik Server.
Den squeezelite Client gibts dann für Linux Windows etc. https://www.max2play.com/ und https://wiki.fhem.de/wiki/Squeezebox_Modul

Dazu hatte ich eh noch ein Attentat auf dich vor.
Ähnlich wie die Anfrage von @Haecksler mit dem states und Talk2Fhem.
Dann schiebe ich das direkt mal ein. Die Module machen nämlich auch TTS Ausgaben, übergeben dazu den Text an
http://translate.google.com/translate_tts?ie=UTF-8&tl=<LANG>&q=<TEXT>&client=tw-ob.
Nun kannst du dir sicher vorstellen, worauf es hinausläuft. Text an die Sepia TTS Engine übergeben und dann zurück zu bekommen. Du kannst die URL auch direkt im Brower abschicken, aber du kennst das sicher. Teste mal: http://translate.google.com/translate_tts?ie=UTF-8&tl=de&q=Guten Abend SEPIA&client=tw-ob.

Vermutlich eher was für deine ToDo Liste. :-) Oder geht das über Umwege schon :-)

Damit hier keine Langeweile aufkommt :-)

Grüße
Basti

sepia

Zitat von: whistler am 14 Februar 2020, 19:39:19
ich nehme mal an ich tausche das isApp=true durch isHeadless=true. Ich probiere es einfach mal aus :-)

"isApp" besser behalten. Der Parameter erzwingt den Status "App" (wer hätte das gedacht) als Gegensatz zu "Website". Die Konsequenz ist, dass der Login nicht nach 1 Tag abläuft sonder das Token glaub 1 Jahr gültig bleibt (wie z.B. in Android etc.).

Zitat von: whistler am 14 Februar 2020, 19:39:19
Also Anwendungsfall wäre ein HTPC mit Win10 der eh läuft, daher wäre dort ebenfalls ein Headless Client was Feines, aber eins nach dem anderen. Nur als gedanken was noch so alles geht :-)

Definitiv erwünscht ^^. In Windows ist alles im Grunde ja ziemlich unproblematisch. Man konfiguriert den Client einfach übers Display (oder Remote Desktop) und packt sich dann ne .bat Datei oder Ähnliches in den Autostart, die den Browser mit "headless" Parameter startet. CLEXI für das "remote Terminal" und sogar Nginx laufen auch in Windows. Das System macht halt nur generell jede Menge Krams im Hintergrund unangekündigt ::)

Zitat von: whistler am 14 Februar 2020, 19:39:19
Jetzt schliesst sich der Kreis, warum ich meinte muss ich alles neu installieren. :-) bzw. ich nicht möchte. (Max2play = Image für Multiroom mittels squeezelite) Basiert auf dem Logitech Musik Server.
Den squeezelite Client gibts dann für Linux Windows etc. https://www.max2play.com/ und https://wiki.fhem.de/wiki/Squeezebox_Modul

Oh, spannend!  ;D

Zitat von: whistler am 14 Februar 2020, 19:39:19
Dazu hatte ich eh noch ein Attentat auf dich vor.
Ähnlich wie die Anfrage von @Haecksler mit dem states und Talk2Fhem.
Dann schiebe ich das direkt mal ein. Die Module machen nämlich auch TTS Ausgaben, übergeben dazu den Text an
http://translate.google.com/translate_tts?ie=UTF-8&tl=<LANG>&q=<TEXT>&client=tw-ob.
Nun kannst du dir sicher vorstellen, worauf es hinausläuft. Text an die Sepia TTS Engine übergeben und dann zurück zu bekommen. Du kannst die URL auch direkt im Brower abschicken, aber du kennst das sicher. Teste mal: http://translate.google.com/translate_tts?ie=UTF-8&tl=de&q=Guten Abend SEPIA&client=tw-ob.

Ah ja der gute alte Google Translator, den hab ich vor ca. 4 Jahren schon zu diesem Zweck "vergewaltigt" ;D (das Projekt hieß ILA Voice Assistant). Es gibt auch Javascript Libraries die den mehr oder weniger "heimlich" als TTS Engine verkaufen. Ich bin persönlich kein großer Fan davon weil es im Grunde von Google nur "geduldet" wird und wenn man es ganz genau nimmt sogar gegen deren AGB verstößt (frag mich jetzt nicht wo das steht ^^). Ich bin sogar mal irgendwann geblockt worden von Google weil ich wohl zu viele Requests hatte =). Eigentlich ein Trauerspiel, dass in den vielen Jahren keine ernsthafte Konkurrenz aufgetaucht ist in Sachen Qualität und Einfachheit. SEPIA hat auch eine uralte Schnittstelle zu Acapela, zu denen hatte ich ganz guten Kontakt. Die könnte man bei Bedarf vielleicht mal etwas aufpolieren. Theoretisch müsste die sogar immer noch gehen, man muss sich nur nen Test-Account machen und dann irgendwas in den SEPIA Settings einstellen ^^.