SEPIA open-source Sprachassistent: Integration in FHEM?

lucca111 · 07 Februar 2020, 20:39:08

Hallo, ich bin auch Snips vorbelastet und hab jetzt mal testweise einen Pi3 mit Raspian und Sepia zum laufen gebracht. Nun habe keine Verbindung zu meinen FHEM Raspberry der in meinen lokalen Netzwerk ist. User und Passwort im Fhem Web hab ich mal auf "user:test12345" gestellt.
In Sepia dann "smarthome_hub_auth_type=Basic" ; "smarthome_hub_auth_data=dXNlcjp0ZXN0MTIzNDU=" wie im Beispiel gesetzt.
Leider werden keine Geräte gefunden. Vielleicht kann jemand helfen?

Gruß Lucca

GUI:
{
"result": "fail",
"error": "Could not register SEPIA Framework inside smart home HUB. See assist-server log for errors."
}

LOG:
22020-02-07 19:26:39 ERROR - FHEM - registerSepiaFramework: Failed! Could not load global attributes. Msg.: {"STRING":"<!DOCTYPE html PUBLIC \" ---> bla,bla,bla ---> body><\/html>","HTTP_REST_SUCCESS":true}

EDIT : GELÖST
Wenn man es richtig macht klappt es auch. Wieder mal dumm angestellt.
Beim "smarthome_hub_host" hatte ich "http://192.168.178.40:8083" eingetragen.
Muss aber natürlich noch "/fhem" mit hinten ran "http://192.168.178.40:8083/fhem"
Na mal sehen wie weit ich jetzt so komme....

@Sepia Danke für dein super Arbeit hier.

lucca111 · 08 Februar 2020, 14:28:24

Nun bin ich soweit das ich mein PS3eye als Mircophone über USB und normale Lautsprecher am 3,5 Klinke verkabelt habe.
Mit

Code Auswählen

arecord --format=S16_LE --duration=5 --rate=16000 --file-type=raw out.raw kann ich eine Aufnahme machen und mit

Code Auswählen

aplay --format=S16_LE --rate=16000 out.raw die Aufnahme abpielen. Soweit so gut es funktioniert prima.
Im Sepia Chatfenster habe ich testweise mal ein Radiostream abgespielt, höre aber nichts. Wenn ich aufs Mikro klicke kommt die Meldung
"UI: Mikrofon nicht richtig erkannt oder Zugriff verweigert."
Bei Snips musste ich den Snips-Audioserver vorher konfigurieren. Gibt es hier auch noch so etwas oder was habe ich übersehen?

gruß Lucca

whistler · 12 Februar 2020, 12:56:04

Hallo Florian,

hoffe du bist gut aus dem Urlaub zurück gekommen.

Zitat von: sepia am 01 Februar 2020, 02:27:14
Wer das Installationsskript testen möchte muss im Schritt 'bash install_sepia_client.sh' noch ein 'dev' anhängen, da noch nichts im GitHub Master ist, sprich 'bash install_sepia_client.sh dev' (ich hoffe das klappt ^^, sonst müsste man die Client Daten manuell rüberkopieren nach ~/clexi/www/sepia/).

Kannst du das Stichwort noch ins Wiki vom dev Eintragen. Das hab ich hier vemutlich gelesen und wahrgenommen, aber dann nicht mehr auf dem Schirm gehabt als ich das Setup durchlaufen bin.
Daher hat er natürlich nicht sauber gearbeitet, und immer fehlende settings.js Fehler geworfen.

https://github.com/SEPIA-Framework/sepia-installation-and-setup/tree/dev/sepia-client-installation/rpi

Vielleicht kannst du das nochmal ins Wiki schreiben, das man die Info auch direkt dort hat, ohne das man vorher hier den Kommentar gelesen haben muss.

Kann ich den Client im Trockenlauf testen? im Hub gibt es leider aktuell keine Meldungen wenn ich connect oder disconnect klicke.
Vielleicht hängt das auch mit meinem vorherigen Problem Docker vs. Dev Install zusammen.

Ich würde gerne weiter Testen, also wenn du mal 1-2 Tipps hast danke dir.

Zusatzhinweis: was Vermutlich das Hauptproblem ist: auf den Pis läuft bereits ein apache2 (max2play image) auf Port 80 (hab ich bereits auf Port 81 verschoben)
Vermutlich kommen sie sich dennoch in die quere. Dann beim Aufruf von Port 80 trotzdem die apache2 default seite angezeigt wird.

[EDIT] Vermutlich liegt es an der LXDE Umgebung, da hören dann meine Linuxkenntnisse langsam auf, Openbox hängt damit zusammen.
Wenn ich das richtig verstehe, müsste nur das openbox "autostart" auf die LXDE Umgebung angepasst werden.
Ich versuche mich dann mal daran.
Beim Blanko Raspi Lite läuft es durch.

Das Problem mit dem Server bleibt aber stehen.

Gruß
Basti

Haecksler · 12 Februar 2020, 15:59:41

Hallo zusammen,
habe nun SEPIA am Laufen, funktioniert soweit auch alles wie es soll.
Nun stellt sich die Frage wie ich am einfachten den erkannten Text ("STT") an meine Talk2Fhem-Instanz senden kann.

Gibt es es eine Systemvariable die den Text zur Verfügung stellt?

Gruß,
Stefan

whistler · 12 Februar 2020, 18:39:10

Zitat von: whistler am 01 Februar 2020, 13:14:28
Würde gerne einer der Testkandidaten sein. Hat denn jemand sonst sepia im Docker am laufen und kann sagen ob es mit der dev vom github bzw. dem Preview Zip von hier auch Probleme gibt oder Problemlos läuft.

Aktuell ist es wieder so, dass ich im SmartHome hab ein Load Hub Info machen kann, und auch SEPIA Register wo er das global attr im Fhem aktualisiert.
Was aber nicht geht. er fragt keine devices mehr ab. Egal welcher Typ in der Dropdown gewählt wird.

Vielleicht hat jemand einen Tipp / Hinweis / Idee.

Vielen Dank und allen ein schönes Wochenende.

[UPDATE]: Ich habe nun mal komplett eine VM, anstatt des Docker Containers erstellt.
Leider gibt es dort immer noch die Zugriffsprobleme vom Hub wie oben schon beschrieben.

ZitatNo items found or no access to smart home system.

Wenn jemand eine Idee hat, immer her damit. Danke.

Haecksler · 12 Februar 2020, 18:58:37

Also ich habe das ganze auf einem Ubuntus 18.04 Server in einem LXD Container (auch Ubuntu 18.04) laufen....ohne Probleme

sepia · 13 Februar 2020, 02:03:46

Hallo Zusammen

Bin wohlbehalten aus dem Urlaub zurück und bereit den nächsten Release fertigzustellen

.
Hat jemand noch gröbere Bugs entdeckt in der Zwischenzeit? ^^ (speziell im Zusammenhang mit FHEM).

In letzter Zeit hatte ich öfters von Problemen mit SEPIA im Docker Container oder einer VM gehört. Vielleicht kann ich da die kommenden Tage mal genauer drauf gucken bzw. zumindest einen neuen Docker Container testen und bauen.

Zitat von: whistler am 01 Februar 2020, 12:57:36habe ich mir angeschaut, aber noch nicht 100% durchgestiegen, bzw. wie dann ein Befehl aussehen sollte. wie im Robo Beispiel.
Vielleicht kannst du da die Syntax nochmal etwas genauer aufsplitten. Vielleicht finde ich in der Zwischenzeit noch was im Wiki.
Deine Textdateien die eingelesen werden hab ich auch geschaut. Da hab ich überlegt, ob du dort zu den Sprachfiles nicht noch eine _custom oder ähnlich hinterlegen kannst. da könnte man dann updatefähige eigene Bausteine reinpacken.

Punkt 1 werde ich nachholen ^^. Punkt 2 ist eigentlich eine gute Idee, ich setze das mal auf die To-Do Liste

Zitat von: whistler am 01 Februar 2020, 12:57:36Das hab ich soweit verstanden, vielleicht habe ich mir hier auch etwas kompliziert ausgedrückt. Ich trage ja den websocket zum stt server ein. Danach versucht er auch auf das Mikrofon zuzugreifen. Es ist auch erlaubt und blinkt. Und dann gibt es aber nochmal den Textzugriff verweigert. Vor dem hinterlegen des STT Server gibt es zusätzlich die Meldung das er einen Server braucht und nicht finden kann.

Bei meinen letzten Tests in Firefox lief das eigentlich ganz gut. Was die Browser allerdings nie zulassen ist, wenn du den Client von HTTPS startest und dann auf einen nicht-HTTPS (bzw. wss) Server zugreifen willst. Chrome(ium) hat allerdings zur Not einen Flag für "insecure origins". Ist das vielleicht bei dir der Fall? Welches Betriebssystem war das?

Zitat von: lucca111 am 08 Februar 2020, 14:28:24Nun bin ich soweit das ich mein PS3eye als Mircophone über USB und normale Lautsprecher am 3,5 Klinke verkabelt habe.
[...]
Bei Snips musste ich den Snips-Audioserver vorher konfigurieren. Gibt es hier auch noch so etwas oder was habe ich übersehen?
gruß Lucca

Hi Lucca,
einen Audioserver gibt es nicht bei SEPIA (nur einen TTS endpoint im kommenden Release), aber Audio im RPi ist extrem zickig irgendwie. Wie genau sieht dein Setup gerade aus? RPi4 + Ps3eye + Klinke Ausgang? Das Ps3eye hat bei mir immer ziemlich Probleme gemacht

Hast du eines der neuen Skripts von ->hier<- benutzt um einen SEPIA RPi Client aufzusetzen?

Zitat von: whistler am 12 Februar 2020, 12:56:04
Kannst du das Stichwort noch ins Wiki vom dev Eintragen. Das hab ich hier vemutlich gelesen und wahrgenommen, aber dann nicht mehr auf dem Schirm gehabt als ich das Setup durchlaufen bin.

Hab ich schnell mal angefügt. Sobald das ganze im Master ist muss ich den 'wget' Link allerdings eh auch noch mal anpassen und nehme es dann wieder raus

Zitat von: whistler am 12 Februar 2020, 12:56:04
Zusatzhinweis: was Vermutlich das Hauptproblem ist: auf den Pis läuft bereits ein apache2 (max2play image) auf Port 80 (hab ich bereits auf Port 81 verschoben)
Vermutlich kommen sie sich dennoch in die quere. Dann beim Aufruf von Port 80 trotzdem die apache2 default seite angezeigt wird.

[EDIT] Vermutlich liegt es an der LXDE Umgebung, da hören dann meine Linuxkenntnisse langsam auf ...

Ich würde zur Zeit dringend empfehlen einen SEPIA Client nur auf einem ganz frisch installierten Raspbian Buster Lite zu testen. Konflikte mit anderen Packages sind nicht unwahrscheinlich, vor allem im Audio-System. Apache und Nginx gleichzeitig ist vermutlich auch nicht so gut ^^. Ich hatte vor einiger Zeit auch mal eine Version mit LXDE konfiguriert, das habe ich der Einfachheit halber aber zunächst mal auf die Warteliste gesetzt.

Zitat von: Haecksler am 12 Februar 2020, 15:59:41
Hallo zusammen,
habe nun SEPIA am Laufen, funktioniert soweit auch alles wie es soll.
Nun stellt sich die Frage wie ich am einfachten den erkannten Text ("STT") an meine Talk2Fhem-Instanz senden kann.

Hi Stefan,
mit den neuen RPi Clients, die zur Zeit noch im Dev Branch sind, könnte man theoretisch auch den erkannten Text broadcasten (bisher werden da nur die "states" des Assistenten übertragen um in Zukunft z.B. LEDs am RPi zu triggern). Ansonsten gibt es auch noch einen MQTT Demo im SEPIA Extensions Repo, den du über den SEPIA Control HUB installieren kannst und der einige Smart Home Befehle erkennen kann wenn der Satz mit "mqtt" anfängt oder endet.

whistler · 13 Februar 2020, 13:10:30

Willkommen zurück

Zitat von: sepia am 13 Februar 2020, 02:03:46
Hat jemand noch gröbere Bugs entdeckt in der Zwischenzeit? ^^ (speziell im Zusammenhang mit FHEM).

Bei mir bleiben noch die HUB Fehlermeldungen, wenn ich die Devices auflisten will. (Register HUB klappt aber nach wie vor)
Sowohl im Docker, als auch in der frisch installierten VM. Ich hab beim kopieren der custom propertie Files gesehen, das die "originale" mittlerweile gewachsen sind, ich nehme aber an, das was nicht in der custom zieht wird aus der normalen nachgeladen. (Jeweils der DEV Stand) Im Log kann ich nichts finden, oder ich gucke an der falschen stelle.

Zitat von: sepia am 13 Februar 2020, 02:03:46
In letzter Zeit hatte ich öfters von Problemen mit SEPIA im Docker Container oder einer VM gehört. Vielleicht kann ich da die kommenden Tage mal genauer drauf gucken bzw. zumindest einen neuen Docker Container testen und bauen.

Punkt 1 werde ich nachholen ^^. Punkt 2 ist eigentlich eine gute Idee, ich setze das mal auf die To-Do Liste

Zitat von: sepia am 13 Februar 2020, 02:03:46
Bei meinen letzten Tests in Firefox lief das eigentlich ganz gut. Was die Browser allerdings nie zulassen ist, wenn du den Client von HTTPS startest und dann auf einen nicht-HTTPS (bzw. wss) Server zugreifen willst. Chrome(ium) hat allerdings zur Not einen Flag für "insecure origins". Ist das vielleicht bei dir der Fall? Welches Betriebssystem war das?

Windows 10 64 bit, im Edge geht es, wenn ich dann direkt die URL Nehme und den ASR angebe. Aber der Fragt jedesmal den Zugriff aufs Mikrofon an. Im Firefox will es aktuell gar nicht, Da hab ich die Auswahl nicht für die ASM (Not support) hab ich mit der 0.21 Web App die aktuellste Version.

Zitat von: sepia am 13 Februar 2020, 02:03:46
Ich würde zur Zeit dringend empfehlen einen SEPIA Client nur auf einem ganz frisch installierten Raspbian Buster Lite zu testen. Konflikte mit anderen Packages sind nicht unwahrscheinlich, vor allem im Audio-System. Apache und Nginx gleichzeitig ist vermutlich auch nicht so gut ^^. Ich hatte vor einiger Zeit auch mal eine Version mit LXDE konfiguriert, das habe ich der Einfachheit halber aber zunächst mal auf die Warteliste gesetzt.

Hast du da zufällig die Skripte vom Testen noch und würdest sie als not supported zur Verfügung stellen, ich hab mal testweise einen PI Blank installiert, aber in der Endversion möchte ich natürlich nicht alle Pis neu installieren versteht sich denke ich.
Apache und NGinx kommen sich nur noch in die Quere, weil er versucht zusätzlich in der Config die Defaultsite zu laden. Ich konnte es soweit einschränken das der Nginx als Proxy läuft und wenn ich den Node Server Manuell per ssh aufrufe klappt auch die Anzeige im Browser das er ihn erreicht über den nginx reverse proxy. es Findet natürlich kein Audio statt.

Zitat von: sepia am 13 Februar 2020, 02:03:46
Hi Stefan,
mit den neuen RPi Clients, die zur Zeit noch im Dev Branch sind, könnte man theoretisch auch den erkannten Text broadcasten (bisher werden da nur die "states" des Assistenten übertragen um in Zukunft z.B. LEDs am RPi zu triggern). Ansonsten gibt es auch noch einen MQTT Demo im SEPIA Extensions Repo, den du über den SEPIA Control HUB installieren kannst und der einige Smart Home Befehle erkennen kann wenn der Satz mit "mqtt" anfängt oder endet.

Die Leds vom respeaker Modul wären auch Schick, sofern du die nicht sowieso auch meintest.

Vielen Dank.

whistler · 13 Februar 2020, 16:28:33

Hallo Florian,

nochmal als Ergänzung zu den Tests mit dem headless Client (oder Display Variante).

Zitat von: sepia am 13 Februar 2020, 02:03:46
Ich würde zur Zeit dringend empfehlen einen SEPIA Client nur auf einem ganz frisch installierten Raspbian Buster Lite zu testen. Konflikte mit anderen Packages sind nicht unwahrscheinlich, vor allem im Audio-System. Apache und Nginx gleichzeitig ist vermutlich auch nicht so gut ^^. Ich hatte vor einiger Zeit auch mal eine Version mit LXDE konfiguriert, das habe ich der Einfachheit halber aber zunächst mal auf die Warteliste gesetzt.

Hast du da zufällig die Skripte vom Testen noch und würdest sie als not supported zur Verfügung stellen, ich hab mal testweise einen PI Blank installiert, aber in der Endversion möchte ich natürlich nicht alle Pis neu installieren versteht sich denke ich.
Apache und NGinx kommen sich nur noch in die Quere, weil er versucht zusätzlich in der Config die Defaultsite zu laden. Ich konnte es soweit einschränken das der Nginx als Proxy läuft und wenn ich den Node Server Manuell per ssh aufrufe klappt auch die Anzeige im Browser das er ihn erreicht über den nginx reverse proxy. es Findet natürlich kein Audio statt.

[UPDATE]
Ich hab jetzt dein openbox autostart skript in ein bash skript gepackt und lasse es nun als display starten. Dann kommt auch der chromium mit localhost:8080 hoch. einloggen kann ich mich, wenn ich die Server URL wie bei der App ganz normal eintrage.
Bekomme aber bei dem Versuch vom HUB aus Remote zuzugreifen folgende Meldung:

Code Auswählen

CLEXI closed. Reason: 1005
CLEXI server says welcome. Info: {"msg":"not authorized","version":"CLEXI Node.js server v0.8.1"}
CLEXI connected
CLEXI connecting ...

Die gleiche Meldung erhalte ich auch beim Zugriff vom raspian lite Test Client, also die Testinstallation raspian lite + headless Client.

Kleine Frage am Rande: Sehe ich das richtig das du im openbox autostart skript aktuell noch fest das headless als 1 mitgibst?

sepia · 13 Februar 2020, 18:59:10

Zitat von: whistler am 13 Februar 2020, 13:10:30Bei mir bleiben noch die HUB Fehlermeldungen, wenn ich die Devices auflisten will. (Register HUB klappt aber nach wie vor) Sowohl im Docker, als auch in der frisch installierten VM. Ich hab beim kopieren der custom propertie Files gesehen, das die "originale" mittlerweile gewachsen sind, ich nehme aber an, das was nicht in der custom zieht wird aus der normalen nachgeladen. (Jeweils der DEV Stand) Im Log kann ich nichts finden, oder ich gucke an der falschen stelle.

Hi Basti. Ich fasse noch mal kurz zusammen um sicher zu gehen:
- Du hast jeweils eine SEPIA Home Installation als Docker Container (nachträglich upgedated) und eine als VM.
- Beide Systeme können "GET DEVICES" nicht ausführen, "Register" klappt aber
- Ein drittes (?) System ohne virtuelle Umgebung funktioniert ohne Fehler (?)

Kannst du über den Chat im Client denn die Geräte steuern?

Bzgl. properties files: Welche der 3 Versionen (custom, test und "default") geladen wird hängt vom Start-Parameter ab, der für die jeweilige JAR Datei benutzt wird. In der SEPIA-Home Release-Version wird standardmäßig "--my" angehängt, was dazu führt, dass die xx.custom.properties geladen wird. In der letzten Version sind glaube ich 2 oder 3 Einträge für den neuen TTS Endpoint hinzugekommen, falls die in deiner nicht existieren wird aber einfach intern der Standardwert gesetzt.

Zitat von: whistler am 13 Februar 2020, 13:10:30Windows 10 64 bit, im Edge geht es, wenn ich dann direkt die URL Nehme und den ASR angebe. Aber der Fragt jedesmal den Zugriff aufs Mikrofon an. Im Firefox will es aktuell gar nicht, Da hab ich die Auswahl nicht für die ASM (Not support) hab ich mit der 0.21 Web App die aktuellste Version.

Ist das schon der neuste Edge, der auf Chromium basiert? Der kann nämlich theoretisch die "native" ASR, aber praktisch ist das buggy, weil Microsoft es scheinbar nicht vollständig implementiert hat. Der SEPIA STT Server (ASR engine "custom") müsste aber auf Firefox und Edge laufen. Die wiederholte Frage nach Mikrofon Zugriff kommt normalerweise, wenn du kein SSL Zertifikat hast und nicht via Localhost arbeitest (localhost oder 127.0.0.1). Es gibt mehrere Möglichkeiten dieses Problem zu umgehen, z.B. selbst signierte Zertifikate, die man im Proxy reinlädt oder gleich echte Zertifikate (im SEPIA Ordner gibt es ein paar Hilfestellungen für Duck DNS + Let's Encrypt). Man könnte auch auf dem System mit Browser einen Proxy nutzen und dann über Localhost arbeiten. Die Sache mit den Zertifikaten war schon immer eins der nervigsten Problemchen, deswegen arbeiten die neuen "headless" Clients alle auf Localhost.
In Firefox funktioniert zur Zeit gar nichts bei dir?

Zitat von: whistler am 13 Februar 2020, 13:10:30Hast du da zufällig die Skripte vom Testen noch und würdest sie als not supported zur Verfügung stellen, ich hab mal testweise einen PI Blank installiert, aber in der Endversion möchte ich natürlich nicht alle Pis neu installieren versteht sich denke ich...

Ich habe gerade mal gesucht und dabei festgestellt, dass ich mich vertan hab, es war LightDM als Login Manager, nicht LXDE

Theoretisch läuft auch alles irgendwie mit der Raspbian Desktop Installation aber ich kann die Clients momentan offiziell nur auf sauberem Raspbian Lite unterstützen, mit genau den Packages, die das Installationsskript vorsieht. Ich verstehe, dass du deine RPis nicht alle neu installieren willst, aber ich würde eh nicht empfehlen irgendwelche andere Software auf den gleichen Geräten laufen zu lassen, höchstens vielleicht bei einem RPi4 ab 2 GB RAM. Ich habe in den letzten Wochen meine PIs so oft neu installiert, dass eine komplette Installation vom Formatieren der SD Karte bis zum ersten "SEPIA wie gehts" nicht länger als 5min dauert (die Zeit nicht mitgerechnet wo das Skript automatisch arbeitet)

Zitat von: whistler am 13 Februar 2020, 13:10:30
Die Leds vom respeaker Modul wären auch Schick, sofern du die nicht sowieso auch meintest.

Die hatte ich im Sinn

Zitat von: whistler am 13 Februar 2020, 13:10:30
CLEXI server says welcome. Info: {"msg":"not authorized","version":"CLEXI Node.js server v0.8.1"}

Das könnte ein Problem mit den letzten Änderungen im Dev Branch von Gestern sein. Der CLEXI Server kann optional jetzt die Server ID als Passwort nutzen. Wenn deine anderen Tools 1-2 Tage älter sind schicken die aber die entsprechenden Header zum authentifizieren noch nicht mit. Guck mal in "~/clexi/settings.json" ob es da einen Eintrag "idIsPassword":true gibt und setz den auf "false".

Zitat von: whistler am 13 Februar 2020, 13:10:30
Kleine Frage am Rande: Sehe ich das richtig das du im openbox autostart skript aktuell noch fest das headless als 1 mitgibst?

Ja, aber je nachdem welche Version der Installationsskripts du hast müsste es eine "setup.sh" geben, die als Option das Switchen zwischen "headless" und "display" ermöglicht (die macht aber auch nichts anderes als diesen Wert auf 1 oder 0 zu setzten). Vorsicht: Wenn der Wert auf "display" steht, dann verbindet sich der Client nicht mehr automatisch mit dem "remote terminal" (CLEXI Server) falls die Daten dazu nicht noch zufällig gespeichert sind und man muss alle Einstellungen über das Display vornehmen.

whistler · 13 Februar 2020, 19:53:19

Zitat von: sepia am 13 Februar 2020, 18:59:10
Hi Basti. Ich fasse noch mal kurz zusammen um sicher zu gehen:
- Du hast jeweils eine SEPIA Home Installation als Docker Container (nachträglich upgedated) und eine als VM.
- Beide Systeme können "GET DEVICES" nicht ausführen, "Register" klappt aber
- Ein drittes (?) System ohne virtuelle Umgebung funktioniert ohne Fehler (?)

Hi Florian,

einen Docker Cointainer (Stand 2.40 vom 31.12.2019) da geht die Funktion mit dem HUB.
Alles was danach kommt geht nicht mehr (gleicher Docker Container mit DEV Skript compiliert und aktualisiert)
Die VM ist ein Debian Buster und ich installiert dort mit einem Sepia User. Ich wollte es entgegen deiner Anleitung unter /opt installieren, aber das klappt nicht so gut.
dann die Rechte teilweise beim Durchlaufen fehlen (anderes Thema). Aber mit deinen Default Pfaden konnte ich installieren. Hier auch der aktuellste Stand vom dev.

Ja es geht beim DEV Stand jeweils das Load HUB, dann die "LED" grün. Und bei Register Sepia muss ich die Änderung im FHEM Speichert mit attr grobal.
Aber beim GET DEVICES sagt er geht nicht.

Ein Drittes System gibt es nicht (ich switche zwischen master und dev hin und her), aber solangsam wird es dann unübersichtlich

Die VM war dafür gedacht zu gucken ob der Fehler dort weg ist. Ich hab mir dein Backup Skript abgeschaut, um zu gucken wie du die "Daten" kopierst.

Daher wäre in dem Falle ja ein Log oder sowas in der Art gut, um zu wissen wo er abbiegt, oder eben nicht.

Es gibt den STT Server noch in einer weiteren VM. Der läuft dort auch. Da ging es von der Handy APP (Android) Auch immer. Auch wenn die Erkennung schwangt, aber das ist ein anderes Thema.

Zitat von: sepia am 13 Februar 2020, 18:59:10
Kannst du über den Chat im Client denn die Geräte steuern?

Nein beim steuern im Chat kommt die sinngemäße Meldung (Leider gibt es ein Problem mit dem Smarthome HUB)

Zitat von: sepia am 13 Februar 2020, 18:59:10
Bzgl. properties files: Welche der 3 Versionen (custom, test und "default") geladen wird hängt vom Start-Parameter ab, der für die jeweilige JAR Datei benutzt wird. In der SEPIA-Home Release-Version wird standardmäßig "--my" angehängt, was dazu führt, dass die xx.custom.properties geladen wird. In der letzten Version sind glaube ich 2 oder 3 Einträge für den neuen TTS Endpoint hinzugekommen, falls die in deiner nicht existieren wird aber einfach intern der Standardwert gesetzt.

Dann passt meine Vermutung ja soweit.

Zitat von: sepia am 13 Februar 2020, 18:59:10
Ist das schon der neuste Edge, der auf Chromium basiert? Der kann nämlich theoretisch die "native" ASR, aber praktisch ist das buggy, weil Microsoft es scheinbar nicht vollständig implementiert hat. Der SEPIA STT Server (ASR engine "custom") müsste aber auf Firefox und Edge laufen. Die wiederholte Frage nach Mikrofon Zugriff kommt normalerweise, wenn du kein SSL Zertifikat hast und nicht via Localhost arbeitest (localhost oder 127.0.0.1). Es gibt mehrere Möglichkeiten dieses Problem zu umgehen, z.B. selbst signierte Zertifikate, die man im Proxy reinlädt oder gleich echte Zertifikate (im SEPIA Ordner gibt es ein paar Hilfestellungen für Duck DNS + Let's Encrypt). Man könnte auch auf dem System mit Browser einen Proxy nutzen und dann über Localhost arbeiten. Die Sache mit den Zertifikaten war schon immer eins der nervigsten Problemchen, deswegen arbeiten die neuen "headless" Clients alle auf Localhost.
In Firefox funktioniert zur Zeit gar nichts bei dir?

Edge Version 11.0.18362.476 21.12.2019. Das ist wohl noch die alte Version. Ist auch nicht so schlimm. habe gerade nochmal getestet. per ASR Server (ws://192.168.1.x:9000/stt/socket)
Fragt er wenn runden knopf fürs Mikro klicken im Browser ob ich Zugriff haben darf aufs Mikrofon.
Kann ich bei gelegenheit mal Updaten und testen auf dem neuen Edge.
[EDIT] Der neue Edge bietet nur noch Native an, und ich kann nicht custom auswählen.

Firefox, funktionierte bisher zumindest soweit das ich ASR Custom eintragen konnte, da kommt jetzt die Meldung not supported. Also keine Auswahl.

Die Version 2.4.0 habe ich per apache als Reverse Proxy laufen. Du erinnerst dich vielleicht. Da läuft dann auch der chat etc. alles drüber. Aber der sepia STT Server, läuft weiterhin intern per IP der müsste vermutlich auch noch über den Reverse Proxy mit angesprochen werden. Ich habe es auch versucht, qausi die Einträge für den Chat in der config zu "Klonen" und anzupassen bin da aber gescheitert.

Dann benötigt sowohl die HTTPS Kommunikation als auch der wss ein Zertifikat hab ich das richtig verstanden?
Also müsste der STT Server auch noch hinter den Proxy, was ja sinn macht, extern hab ich am Handy bisher immer nen VPN auf.

[ABER] Es gibt allerdings auch ein aber, die User Steuerung im Adminbereich sagt dann zum Beispiel bearbeiten geht nicht, weil nicht im Privaten Netzwerk.

@klausw: vielleicht hast du hier noch eine idee oder tipp? Du hattest ja die erste websocket Konfiguration für den apache reverse Proxy auch schon zurecht gebaut.
Das man das auch für STT Server Weitergabe hinbekommt.

Zitat von: sepia am 13 Februar 2020, 18:59:10
Ich habe gerade mal gesucht und dabei festgestellt, dass ich mich vertan hab, es war LightDM als Login Manager, nicht LXDE
Theoretisch läuft auch alles irgendwie mit der Raspbian Desktop Installation aber ich kann die Clients momentan offiziell nur auf sauberem Raspbian Lite unterstützen, mit genau den Packages, die das Installationsskript vorsieht. Ich verstehe, dass du deine RPis nicht alle neu installieren willst, aber ich würde eh nicht empfehlen irgendwelche andere Software auf den gleichen Geräten laufen zu lassen, höchstens vielleicht bei einem RPi4 ab 2 GB RAM. Ich habe in den letzten Wochen meine PIs so oft neu installiert, dass eine komplette Installation vom Formatieren der SD Karte bis zum ersten "SEPIA wie gehts" nicht länger als 5min dauert (die Zeit nicht mitgerechnet wo das Skript automatisch arbeitet)

Naja, wenn da nicht drauf laufen würde wäre es so einfach das stimmt. Ich habe natürlich verständnis dafür das du nur den einen weg supporten kannst. Ich hab daher auf einer SD Karte eine frische Zweitinstallation gemacht, und da komm ich ja auch fast bis zum Ziel.

[EDIT] https://github.com/SEPIA-Framework/sepia-docs/issues/9#issuecomment-546301426 Ist das vorgehen mit dem neuen Client auch ungültig?

Das wäre quasi mein Testclient:

Tut es dort was nicht kann ich den Fehler melden
Funktioniert alles gut, muss ich bei mir suchen
oder mal vorsichtig nachfragen

Zitat von: sepia am 13 Februar 2020, 18:59:10
Das könnte ein Problem mit den letzten Änderungen im Dev Branch von Gestern sein. Der CLEXI Server kann optional jetzt die Server ID als Passwort nutzen. Wenn deine anderen Tools 1-2 Tage älter sind schicken die aber die entsprechenden Header zum authentifizieren noch nicht mit. Guck mal in "~/clexi/settings.json" ob es da einen Eintrag "idIsPassword":true gibt und setz den auf "false".

Den gleichen gedanken hatte ich heute mittag beim schauen der Änderungen auch,
bisher noch keine Zeit zum testen gehabt. Habs gerade nachgeholt. Der Raspian Lite Client spricht auch brav seine zwei Sätze an Anfang. Und click auf connect scannt er fleissig scheinbar schon Bluetooth Umgebung, Zumindest wird dort Blau angedruckt.
Das scheint also zu Klappen, ich guck dann mal mit meinen "not supportet" Client weiter.
[EDIT] Der funktioniert auch soweit und verbindet sich auch per Remote Console und schreibt fleissig auch Bluetooth Erkennungen auf.

Aber vielleicht hab ich es überlesen. Wie spreche ich den Client nun an? Ist dort Wakeword integriert? Oder bin ich doch gedanklich schon einen Schritt zu weit? Bei mir ist Respeaker Mic 2 drauf.

Zitat von: sepia am 13 Februar 2020, 18:59:10
Ja, aber je nachdem welche Version der Installationsskripts du hast müsste es eine "setup.sh" geben, die als Option das Switchen zwischen "headless" und "display" ermöglicht (die macht aber auch nichts anderes als diesen Wert auf 1 oder 0 zu setzten). Vorsicht: Wenn der Wert auf "display" steht, dann verbindet sich der Client nicht mehr automatisch mit dem "remote terminal" (CLEXI Server) falls die Daten dazu nicht noch zufällig gespeichert sind.

Okay ich hab die Stelle gesucht, aber dann wohl einfach übersehen.

Noch eine kurze Frage: SEPIA Server in dem Zusammenhang, ist ja schon noch noch am Client mit Clexi gemeint oder? Sobald ich nämlich wirklich die SEPIA Server IP Eintrage funktioniert es nicht mehr.

Ich hoffe ich konnte genügend Input liefern.

Vielen Dank und einen schönen Abend.

PS: Das Problem mit dem HUB GET DEVICE hätte bei mir gerade die höchste Prio

Haecksler · 13 Februar 2020, 20:14:31

Zitat
Hi Stefan,
mit den neuen RPi Clients, die zur Zeit noch im Dev Branch sind, könnte man theoretisch auch den erkannten Text broadcasten (bisher werden da nur die "states" des Assistenten übertragen um in Zukunft z.B. LEDs am RPi zu triggern). Ansonsten gibt es auch noch einen MQTT Demo im SEPIA Extensions Repo, den du über den SEPIA Control HUB installieren kannst und der einige Smart Home Befehle erkennen kann wenn der Satz mit "mqtt" anfängt oder endet.

Habe ich getestet und funktioniert soweit, allerdings ist es nicht einfach für mich den Java-Code zu verstehen.
Wie komme ich an den normalizedText? Über nluResult?
Noch ein Hinweis, mit meinem Standarduser (Roles: user,smarthomeadmin,smarthomeguest) habe ich keine Berechtigung das MqttDemo zu laden und beim Admin kann keine Rolle hinzugefügt werden, d.h. ich musste zum Testen den Code anpassen....ist das so gedacht?

Lg

sepia · 13 Februar 2020, 21:28:46

Zitat von: whistler am 13 Februar 2020, 19:53:19
einen Docker Cointainer (Stand 2.40 vom 31.12.2019) da geht die Funktion mit dem HUB.
Alles was danach kommt geht nicht mehr (gleicher Docker Container mit DEV Skript compiliert und aktualisiert)

Ok interessant, ich überlege noch mal was sich da geändert haben könnte.

Zitat von: whistler am 13 Februar 2020, 19:53:19
Die VM ist ein Debian Buster und ich installiert dort mit einem Sepia User. Ich wollte es entgegen deiner Anleitung unter /opt installieren, aber das klappt nicht so gut.

Ja, einerseits gibt es da Probleme mit den Zugriffsrechten und dazu kommt noch, dass in manchen Linux Scripts zum Starten etc. der Pfad "~/SEPIA" hardcoded ist

... das ist sicher nicht optimal aber wurde irgendwann nötig. Ich muss das irgendwann mal durch eine Umgebungsvariable ersetzten. Generell gilt: abseits der Instruktionen aus den "Anleitungen" bewegt man sich auf dünnes Eis

Zitat von: whistler am 13 Februar 2020, 19:53:19
[EDIT] Der neue Edge bietet nur noch Native an, und ich kann nicht custom auswählen.

das verwirrt mich jetzt total, der ist ja im Grunde identisch mit Chrome/Chromium.

Zitat von: whistler am 13 Februar 2020, 19:53:19...Aber der sepia STT Server, läuft weiterhin intern per IP der müsste vermutlich auch noch über den Reverse Proxy mit angesprochen werden. Ich habe es auch versucht, qausi die Einträge für den Chat in der config zu "Klonen" und anzupassen bin da aber gescheitert.

Irgendwo hatte ich dazu mal was geschrieben, finde es aber selber nicht mehr

Vielleicht hilft die Nginx Config aus dem STT Server weiter: https://github.com/SEPIA-Framework/sepia-stt-server/blob/master/nginx_config/stt

Zitat von: whistler am 13 Februar 2020, 19:53:19
Dann benötigt sowohl die HTTPS Kommunikation als auch der wss ein Zertifikat hab ich das richtig verstanden?
Also müsste der STT Server auch noch hinter den Proxy, was ja sinn macht, extern hab ich am Handy bisher immer nen VPN auf.

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.

Zitat von: whistler am 13 Februar 2020, 19:53:19
[ABER] Es gibt allerdings auch ein aber, die User Steuerung im Adminbereich sagt dann zum Beispiel bearbeiten geht nicht, weil nicht im Privaten Netzwerk.

Ja stimmt, das Sicherheitsfeature müsstest du dann in den Server settings mit der Option "allow_global_dev_requests":true deaktivieren wenn du von Extern drauf willst. Im eigenen Netzwerk kannst du aber immer direkt über http://[IP]... auf den Server gehen. Im Control HUB brauchst du ja kein HTTPS.

Zitat von: whistler am 13 Februar 2020, 19:53:19
[EDIT] https://github.com/SEPIA-Framework/sepia-docs/issues/9#issuecomment-546301426 Ist das vorgehen mit dem neuen Client auch ungültig?

Teilweise findet sich das in der "~/.config/openbox/autostart" wieder, kannst du aber ignorieren für die neue Version.

Zitat von: whistler am 13 Februar 2020, 19:53:19
Aber vielleicht hab ich es überlesen. Wie spreche ich den Client nun an? Ist dort Wakeword integriert? Oder bin ich doch gedanklich schon einen Schritt zu weit? Bei mir ist Respeaker Mic 2 drauf.

In der Einstellung "Message typ: SEPIA client" kannst du mal den Befehl "call test" versuchen (vorher richtige Device ID ins Feld darüber eintragen).
In der Einstellung "Remote Button" kannst du das Mikrofon triggern mit "deviceId [ID] button mic".
Wake-word ist standardmäßig in der "~/clexi/www/sepia/settings.js" deaktiviert und kann aktiviert werden über '"useWakeWord": true, "autoloadWakeWord": true'. Danach ist ein Neustart des Clients über das "remote terminal" nötig via "call reload".

Zitat von: whistler am 13 Februar 2020, 19:53:19
Noch eine kurze Frage: SEPIA Server in dem Zusammenhang, ist ja schon noch noch am Client mit Clexi gemeint oder? Sobald ich nämlich wirklich die SEPIA Server IP Eintrage funktioniert es nicht mehr.

Meinst du die Option aus dem Client "setup.sh" Skript bzw. den Eintrag "host-name" aus der "~/clexi/www/sepia/settings.js"? Da müsste schon die IP Adresse deines SEPIA Servers rein, bzw. genau das, was du sonst im Client als "host" angibst (in diesem Fall ist kein HTTPS nötig).

Zitat von: whistler am 13 Februar 2020, 19:53:19
Ich hoffe ich konnte genügend Input liefern.

Vielen Dank und einen schönen Abend.

Deine Tests helfen auf jeden Fall sehr weiter, danke und ebenfalls schönen Abend

Zitat von: Haecksler am 13 Februar 2020, 20:14:31
Habe ich getestet und funktioniert soweit, allerdings ist es nicht einfach für mich den Java-Code zu verstehen.
Wie komme ich an den normalizedText? Über nluResult?

Cool!

Ja, über 'nluResult.input.text' (normalized) und 'nluResult.input.textRaw' (falls auch das original benötigt wird).

Zitat von: Haecksler am 13 Februar 2020, 20:14:31
Noch ein Hinweis, mit meinem Standarduser (Roles: user,smarthomeadmin,smarthomeguest) habe ich keine Berechtigung das MqttDemo zu laden und beim Admin kann keine Rolle hinzugefügt werden, d.h. ich musste zum Testen den Code anpassen....ist das so gedacht?

Man übersieht das vermutlich leicht, aber hier steht die Lösung

Du musst deinem User noch die Rolle "developer" geben.

Grüße,
Florian

sepia · 13 Februar 2020, 22:37:29

Zitat von: whistler am 01 Februar 2020, 12:57:36
habe ich mir angeschaut, aber noch nicht 100% durchgestiegen, bzw. wie dann ein Befehl aussehen sollte. wie im Robo Beispiel.
Vielleicht kannst du da die Syntax nochmal etwas genauer aufsplitten. Vielleicht finde ich in der Zwischenzeit noch was im Wiki.
Deine Textdateien die eingelesen werden hab ich auch geschaut. Da hab ich überlegt, ob du dort zu den Sprachfiles nicht noch eine _custom oder ähnlich hinterlegen kannst. da könnte man dann updatefähige eigene Bausteine reinpacken.

Ich habe ein zweites Beispiel in die Liste aufgenommen: https://github.com/SEPIA-Framework/sepia-docs/blob/master/API/teach-server.md#custom-smart-home-command
Es basiert auf @TRallala 's Beispiel ein paar Posts zuvor.

Der Server liest jetzt außerdem auch Dateien mit dem Suffix "_custom.txt" automatisch (falls sie existieren), also z.B. "chats_de_custom.txt". Dabei werden Inhalte aus "chats_de.txt" überschrieben

whistler · 13 Februar 2020, 23:02:43

Zitat von: sepia am 13 Februar 2020, 21:28:46
Ok interessant, ich überlege noch mal was sich da geändert haben könnte.

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.

Zitat von: sepia am 13 Februar 2020, 21:28:46
Ja, einerseits gibt es da Probleme mit den Zugriffsrechten und dazu kommt noch, dass in manchen Linux Scripts zum Starten etc. der Pfad "~/SEPIA" hardcoded ist ... das ist sicher nicht optimal aber wurde irgendwann nötig. Ich muss das irgendwann mal durch eine Umgebungsvariable ersetzten. Generell gilt: abseits der Instruktionen aus den "Anleitungen" bewegt man sich auf dünnes Eis

Da sagst du was

Zitat von: sepia am 13 Februar 2020, 21:28:46
das verwirrt mich jetzt total, der ist ja im Grunde identisch mit Chrome/Chromium.

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.

Zitat von: sepia am 13 Februar 2020, 21:28:46
Irgendwo hatte ich dazu mal was geschrieben, finde es aber selber nicht mehr Vielleicht hilft die Nginx Config aus dem STT Server weiter: https://github.com/SEPIA-Framework/sepia-stt-server/blob/master/nginx_config/stt

So halb, im Apache läuft das scheinbar ein wenig anders, so wie mit dem chat und message, ich kriege das gerade aber nicht adaptiert. Zumindest per ws: erreicht er den Server und meckert dann immer noch über den Mikrofon Zugriff. wss: bekomme ich nicht hin. Sobald ich die URL Minimal ändere "damit sie falsch ist" sagt er wieder ASR Server nicht erreichbar". Korrigiere ich wieder kommt die Meldung mit kein Zugriff aufs Mikrofon. Das Fehlerbild ist aber das gleiche wie wenn ich direkt ws://192.168. also die interne IP Eintrage. Er hat auch was von Ein skript versucht ... und hat dann gesperrt.
Scheinbar reicht die SSL Verbindung nicht. und ws:// ist ihm dann zu wenig.

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.

Dein alles über HTTPS verstehe ich noch nicht 100%, oder meinst du damit HTTPS und WSS?
Du meinst quasi den Teil den beim headless Client das node.js übernimmt? Da wäre ich ja auch localhost

Zitat von: sepia am 13 Februar 2020, 21:28:46
Ja stimmt, das Sicherheitsfeature müsstest du dann in den Server settings mit der Option "allow_global_dev_requests":true deaktivieren wenn du von Extern drauf willst. Im eigenen Netzwerk kannst du aber immer direkt über http://[IP]... auf den Server gehen. Im Control HUB brauchst du ja kein HTTPS.

Teilweise findet sich das in der "~/.config/openbox/autostart" wieder, kannst du aber ignorieren für die neue Version.

Passt

Zitat von: sepia am 13 Februar 2020, 21:28:46
In der Einstellung "Message typ: SEPIA client" kannst du mal den Befehl "call test" versuchen (vorher richtige Device ID ins Feld darüber eintragen).
In der Einstellung "Remote Button" kannst du das Mikrofon triggern mit "deviceId [ID] button mic".
Wake-word ist standardmäßig in der "~/clexi/www/sepia/settings.js" deaktiviert und kann aktiviert werden über '"useWakeWord": true, "autoloadWakeWord": true'. Danach ist ein Neustart des Clients über das "remote terminal" nötig via "call reload".

Test ich mal

Zitat von: sepia am 13 Februar 2020, 21:28:46
Meinst du die Option aus dem Client "setup.sh" Skript bzw. den Eintrag "host-name" aus der "~/clexi/www/sepia/settings.js"? Da müsste schon die IP Adresse deines SEPIA Servers rein, bzw. genau das, was du sonst im Client als "host" angibst (in diesem Fall ist kein HTTPS nötig).

also server:20721/sepia z.b.?

Gerne und Danke