SEPIA open-source Sprachassistent: Integration in FHEM?

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

Vorheriges Thema - Nächstes Thema

sepia

Hallo FHEM Community  :)

Ich baue seit längerer Zeit an einem Projekt, dass ich SEPIA Framework bzw. SEPIA Open Assistant nenne.
Es ist ein persönlicher, intelligenter Assistent, der aus einem Server (Java), einer App (HTML) und mehreren zusätzlichen Tools (Control HUB, offline Spracherkennung, wake-word server, Node.js CLEXI server etc.) besteht, alles 100% open-source. Ausführliche Informationen gibt es hier:

https://sepia-framework.github.io/

News, Bilder und Videos gibt es hier:

https://twitter.com/sepia_fw

[EDIT]

--- Update ---

Mittlerweile ist FHEM voll integriert in SEPIA 8)

--- Originaler Beitrag ---

For einiger Zeit hatte ich bereits eine Smart Home Integration via openHAB gebaut, um meine Philips Hue Lights anzusteuern. Das funktioniert auch ganz gut, allerdings wollte ich demnächst mal die Funktionen ausbauen und hatte dabei auch über einen Connector für FHEM nachgedacht.

Meine Frage an die Community:
Gibt es Interesse an so einer Integration?

Die Features von SEPIA kurz zusammengefasst:
- 100% open source
- Der Server läuft (dank Java) auf Windows, Linux und MacOS. Ich nutze meistens einen Raspberry Pi. Das gesamte SEPIA-Home Bundle (SEPIA Server + WebServer inkl. Client, Tools und Proxy) ist gerade mal 150MB groß.
- Der Client läuft im Browser, Android und (theoretisch) iOS
- Kommunikation zwischen SEPIA Server und Client läuft über einen WebSocket Server, der auch von Usern als Chat-Server genutzt werden kann.
- Minimalistische Clients können auch direkt mit der REST API des Servers kommunizieren
- Spracherkennung läuft entweder nativ in Android, Chrome Browser und iOS oder über den eigenen STT Server (als Docker Container verfügbar), der mit eigenen Sprachmodellen (Englisch, Deutsch) trainiert werden kann.

Grüße,
Florian (SEPIA Erfinder)

dkreutz

Hallo Florian,

Was für ein Zufall - gestern Abend bin ich bei einer Recherche nach deutschsprachigen TTS-Engines/Modellen zufällig auch auf SEPIA gestoßen. Beeindruckend was Du da - soweit ich es verstehe - als "Einzelkämpfer" auf die Beine gestellt hast.

Was ich ad hoc nicht herausfinden konnte: welche Engine verwendet SEPIA für die Sprachausgabe (TTS)?

Neben Alexa und Google-Assistant wirst Du hier Benutzer von snips.ai und mycroft.ai finden. (Der fhem-skill für Mycroft stammt von mir).

VG Dominik
Raspberry Pi3B+ (Bullseye) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

sepia

Hi Dominik,

danke. Witzig, dass du es auch zufällig gefunden hattest ;D

Bzgl. TTS: Normalerweise nutzt SEPIA die im Client per default eingestellte TTS Engine. In Android ist das meist die offline oder online Variante von Google (man kann aber alles Mögliche aus dem Store installieren), bei Apple die Siri Stimme, in Firefox für Windows meistens die Microsoft offline Stimmen und in Chrome für Windows gibt es auch die Google Stimmen zur Auswahl (zusätzlich zu Microsoft).
Theoretisch hat der SEPIA Server auch die Möglichkeit Mp3s zum Client zu streamen die vom offline oder online Service der Firma Acapela erzeugt werden, diese Funktion habe ich aber seit langer Zeit nicht mehr getestet.
Es gibt auch einen Raspberry Pi Client der in Chromium läuft (über Openbox im Kiosk-Mode), für den hatte ich eSpeak integriert (weil ich die Stimme einfach geil finde für Roboter  ::)) und mit PicoTTS experimentiert (das war mal die alte Android offline TTS). PicoTTS klappt in der Commandline aber leider nicht im Chromium, deswegen war ich noch am überlegen, ob ich das über die alte Acapela Schnittstelle auch einbaue, so dass es vom SEPIA Server gemanagt wird.
Spannend finde ich auch die neue Mycroft Mimic2 Engine, aber ich habe gelesen, dass die für den Realfall noch zu viel Resourcen frisst und deswegen zu hohe Latenz hat.

Könntest du mir vielleicht einen kurzen Überblick geben über den Mycroft Connector und was alles nötig war dafür? Ich kenne mich noch nicht wirklich aus mit FHEM, aber bei openHAB konnte ich die Geräte über deren REST API abrufen und dann bei SEPIA integrieren (Name geben, Status lesen/schreiben, etc.).

Grüße

dkreutz

Eine echte REST-API gibt es nicht, es können FHEM-Kommandos per http/https oder telnet abgesetzt werden.
Der Status von Devices (State, Readings, Attribute) kann über einen http-Request mit dem Command "jsonlist2" abgefragt werden, das Ergebnis kommt dann im JSON-Format zurück.

Ich verwende im fhem-skill für Mycroft eine Python-Bibliothek (https://github.com/domschl/python-fhem) die alle Aufrufe kapselt.
Raspberry Pi3B+ (Bullseye) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

rudolfkoenig

ZitatEine echte REST-API gibt es nicht
Wobei ich gerne wuesste, was eine "echte" REST-API ist.

ZitatDer Status von Devices (State, Readings, Attribute) kann über einen http-Request mit dem Command "jsonlist2" abgefragt werden, das Ergebnis kommt dann im JSON-Format zurück.
...oder xmllist fuer XML Format oder list fuer Newline separiert oder man baut seine eigene Funktion, und ruft diese per HTTP/HTTPS/telnet auf.
Wobei "telnet" hier fuer TCP/IP "pur" steht, und nicht fuer das telnet Protokoll.
Man kann Fremdsysteme auch per MQTT anbinden, dafuer wird gerne das MQTT_GENERIC_BRIDGE als Hilfsmodul verwendet.

sepia

Es muss ja gar keine "echte" REST API sein, ein HTTP(S) Endpoint mit JSON Objekten war eigentlich schon das was ich meinte ;-)
Hätte Jemand vielleicht gerade einen Beispiel request parat oder einen Link zur Dokumentation? :-)

@Dominik: Ein Nachtrag bezüglich TTS. Hatte mich Gestern und Heute wieder mit dem Thema Raspberry Pi Client beschäftigt, da mein RPi4 (4GB) Gestern ankam ^_^ und dabei noch mal mit PicoTTS experimentiert. Das klappt jetzt doch so wie es soll ;D , ist zwar nicht zu vergleichen mit den state-of-the-art TTS Engines aber akzeptabel wenn man komplett unabhängig, kostenlos und Ressourcen schonend arbeiten will.

Auch zum Thema STT (Spracherkennung) noch ein interessanter Hinweis: In der Android App lief bei mir die Google Variante seit Wochen im OFFLINE Modus ohne dass ich es bemerkt hatte :o ;D . Selbst Straßennamen wurden zuverlässig erkannt und das ganz ohne Cloud. Leider finde ich dazu kaum nützliche Informationen seitens Google, aber die scheinen sich extrem verbessert zu haben. Es gab wohl mal die Meldung dass das neue, komprimierte offline Modell kommen soll, aber eigentlich erstmal nur in USA und für GBoard die Keyboard app von Google.

dkreutz

Zitat von: rudolfkoenig am 05 Juli 2019, 09:16:55
Wobei ich gerne wuesste, was eine "echte" REST-API ist.
Bei FHEM kann ich kein einheitliches Pattern erkennen, mit dem ich im Sinne des RESTful Architekturstils den Zustand von Devices abfragen oder ändern kann.

Bei Homesassistant kann ein Gerät über die URI "/api/states/<entity_id>" adressiert werden. Den Zustand eines Devices kann man mit einem GET abfragen und mit einem POST ändern. Die Payload ist dort im JSON-Format. Bei FHEM frage ich den Zustand mit "/cmd=jsonlist2 NAME=device_name" und schalte mit "/cmd=set device_name on"

Zitat von: sepia am 05 Juli 2019, 19:43:33
Es muss ja gar keine "echte" REST API sein, ein HTTP(S) Endpoint mit JSON Objekten war eigentlich schon das was ich meinte ;-)
Hätte Jemand vielleicht gerade einen Beispiel request parat oder einen Link zur Dokumentation? :-)
https://commandref.fhem.de/#JsonList2 plus https://commandref.fhem.de/#devspec
Raspberry Pi3B+ (Bullseye) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

rudolfkoenig

ZitatHätte Jemand vielleicht gerade einen Beispiel request parat
http://localhost:8083/fhem?cmd=jsonlist2&fwcsrf=csrf_947663951072259&XHR=1

Den Wert fuer fwcsrf holt man entweder aus dem fwcsrf Attribut des <body> Tags bei einem Aufruf ohne cmd, oder man setzt "attr WEB csrfToken" auf einen festen Wert.

klausw

Ich lese hier mal mit. An einer Integration in FHEM hätte ich durchaus Interesse.
Derzeit nutze ich Snips. Das geht halt leider nur in den eigenen vier Wänden.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

sepia

Zitat von: rudolfkoenig am 05 Juli 2019, 20:13:59
http://localhost:8083/fhem?cmd=jsonlist2&fwcsrf=csrf_947663951072259&XHR=1

Den Wert fuer fwcsrf holt man entweder aus dem fwcsrf Attribut des <body> Tags bei einem Aufruf ohne cmd, oder man setzt "attr WEB csrfToken" auf einen festen Wert.

Danke für den Hinweis! Das CSRF Token scheint bisher in der Dokumentation von jsonlist2 nicht aufzutauchen und ich hab mich schon gefragt wieso nix klappte :o. Der Sicherheitsaspekt erschließt sich mir aber noch nicht so ganz, wenn ich das Token selber aus dem Header lesen kann ??? (wahrscheinlich habe ich nicht gründlich genug gelesen ^^).

Habe gerade mal angefangen den alten SEPIA openHAB Service aufzubrechen und in ein allgemeineres Interface umzuwandeln. Ich denke das sollte auch für FHEM ganz gut klappen :-)

Updates folgen :D

TRallala

Hey Florian,

meinst du machst noch weiter mit der Anbindung an FHEM?

Würde (ich hoffe nicht nur mich) sehr freuen ein positives Update dazu zu bekommen. Das Framework läuft bei mir zum testen mittlerweile ganz gut und wartet nur noch drauf weiter trainiert zu werden.
Der passende Zeitpunkt alles miteinander auch an fhem anzudocken.

VG
Markus

sepia

Hi Markus,

freut mich dass SEPIA bei dir läuft! Wie der Zufall es so will hatte ich mir für heute auf die To-Do Liste gesetzt mal einen Schritt weiter zu kommen mit FHEM :-)

Die letzten beiden SEPIA Updates hatten sich mehr auf die Chat/Messenger Funktionen und die Konfigurierbarkeit des Natural-Language-Understanding (NLU) Moduls konzentriert, parallel hatte ich aber schon Anpassungen an dem Smart Home Service und den Parametern für 'SmartDevice' und 'Room' vorgenommen damit sich FHEM leichter integrieren lässt.

Der nächste Schritt ist nun ein kleines Tutorial für das SEPIA SDK in dem ich FHEM als Beispiel nutzen möchte für einen selbstgebauten Service (vermutlich Lampen Steuerung). Abhängig davon wie gut das klappt entscheide ich dann wie es weiter geht :-)

TRallala


Danke für das Update - freut mich wenns dann weiter geht!

VG von nebenan (DO)

sepia

#13
Sooooo, es hat noch etwas länger gedauert als geplant, da ich das Smart Home Interface etwas erweitern musste und einen neuen Server Endpoint erschaffen habe, aber die FHEM Integration ist nun in der Testphase  ::)
Hier ein kleiner Überblick, das ganze Funktioniert praktisch identisch zur openHAB Integration (falls damit schon Jemand experimentiert hatte). Kommentare willkommen:

  • In der SEPIA Server Config trägt man zunächst 'fhem' als HUB Namen ein und die Host Adresse, z.B. http://localhost:8083/fhem
  • Danach öffnet man den SEPIA Control HUB (admin-tools), logged sich mit dem Admin (oder einem User mit entsprechender Rolle) ein und öffnet die Smart Home Seite
  • Hier hat man nun die Möglichkeit die Daten vom Server zu laden und dann auf "Register" zu klicken. Der 'register' Button erstellt im Falle von FHEM die neuen, globalen Attribute "sepia-name, sepia-type, sepia-room, sepia-data, sepia-mem-state" auf dem FHEM Server, damit die Steuerung durch SEPIA besser konfiguriert werden kann.
  • Nun kann man den Button "get devices" anklicken, der über die Web Schnittstelle von FHEM alle Geräte ausliest (cmd=jsonlist2) und im SEPIA Control HUB darstellt. Das CSRF Token wird dabei vom Server automatisch bei Bedarf aus dem Header der basic FHEM Antwort ausgelesen.
  • In der Device Liste kann man nun den Gerätetypen und den Raum einstellen, in dem sich das Gerät befindet. Geräte die SEPIA ignorieren soll können auf Typ: hidden gestellt werden. Die 'Type' und 'Room' Daten werden in die vorher erstellten Attribute übertragen (sepia-type, sepia-room) und beeinflussen somit keinerlei alte Einstellungen von FHEM.
  • Danach kann es direkt losgehen. In der SEPIA App funktionieren Befehle wie "Schalte das Licht im Wohnzimmer auf 50%" oder "Licht 1 im Schlafzimmer". Der Name des Gerätes wird bisher noch ignoriert, aber die Nummer wird erkannt, falls es eine Nummer im FHEM Namen des Gerätes gibt.
Klingt das sinnvoll für euch? :)

Bisher teste ich nur mit Lampen, da ich selber keine anderen Geräte habe :o , aber ich habe gesehen, dass es scheinbar einen DEMO Modus gibt? Kann man den nutzen um Geräte wie Heizungen, Jalousien, etc. zu simulieren? Das wäre wichtig um zu prüfen, ob der Parameter beim "set" Befehl richtig konvertiert wird.

TRallala

#14
Hi Florian,

Super Sache, erstmal danke für die Mühe!!

Dann zur Demo - dafür gibts eine demo cfg:
perl fhem.pl fhem.cfg.demo
da sind schon jede Menge Geräte konfiguriert.

Würde auch genere gleich testen, aber bei deiner Anleitung komm ich allerdings bei Punkt 1 schon nicht mal los:
In der SEPIA Server Config trägt man zunächst 'fhem' als HUB Namen ein und die Host Adresse, z.B. http://localhost:8083/fhem
<= sollte auch den dev server benutzen  :o

Habe über die Core Settings der Tools Seite folgendens eingetragen:

    "smarthome_hub_host=http://localhost:8083/fhem",
    "smarthome_hub_host=http\://localhost\:8083/fhem",     <= ":"  auskommentieren
    "smarthome_hub_name=FHEM",

danach ein Neustart. Unter "SmartHome" bleibts jedoch bei "openHAB" als Option.  Wo bin ich also falsch abgebogen? dev...

Jetzt hängts allerdings beim registrieren.. Error: missing HUB server or host address
siehe Anhang

<= gelöst:

1. man wähle das System "FHEM" aus
2. Load Hub Info
3. Select System wird geleert, wenn jetzt versucht wird zu registrieren, schlägt dies fehl
3.a. also erneut "FHEM" auswählen
4. Register Sepia   funktioniert.
5. Damit "Get Devices" funktioniert, muss das fhem attr "sepia-name" beim entsprechenden Gerät gesetzt sein (macht nur Sinn, fehlt jedoch in der Beschreibung oben)



Morgen gehts weiter.