SEPIA open-source Sprachassistent: Integration in FHEM?

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

Vorheriges Thema - Nächstes Thema

sepia

#15
Hi Markus,

das ging aber fix ;D Hast du den kompletten SEPIA-Home build aus dem Dev-Branch gemacht? Ich hatte ja noch gar keine offizielle Test-Version veröffentlicht ^^.

Ich denke dass beim Laden der Einstellungen vom Server der Select Button leer bleibt könnte an einem kleinen Bug liegen der die Groß-Kleinschreibung nicht ignoriert. Hast du in der Server Config "FHEM" oder "fhem" stehen? Das Problem sollte aber nur im control HUB bestehen und kann erstmal umgangen werden wie du schon erwähnt hast.

ZitatDamit "Get Devices" funktioniert, muss das fhem attr "sepia-name" beim entsprechenden Gerät gesetzt sein

'sepia-name' hatte ich bisher gar nicht benutzt, sprich noch nicht gesetzt. Gelesen wird es aber falls es existiert. Der Fallback kommt aus FHEMs "Internals" -> "name". Ich bin davon ausgegangen, dass dieser Wert immer existiert was scheinbar nicht zwangsläufig der Fall ist. Einer von beiden MUSS existieren sonst wird das Gerät ignoriert. Falls 'sepia-type' nicht existiert kommt der Wert aus "Internals" -> "type" ins Spiel. Automatisch werden zur Zeit nur Lampen und Heizungen erkannt (oder zumindest wird es versucht ^^).

Übrigens nicht wundern wenn SEPIA in der App nur Lampen akzeptiert, ich habe bisher noch einen Type-Check drin und wollte mit dem Demo jetzt mal andere Geräte ausprobieren :)

Danke schon mal fürs Testen! 8)

[EDIT] Nachtrag:

Der Demo läuft und sieht sehr nützlich aus ^^. Ich musste allerdings den "Internals" key für den Namen von "name" zu "NAME" ändern bzw. ich checke nun beides damit die Liste der Devices nicht leer bleibt ;)
Ist zu erwarten, dass bei den keys Groß/Kleinschreibung generell variieren kann?

[EDIT2] Nachtrag2:

Mich beschleicht langsam das Gefühl der "name" Tag (Kleinbuchstaben) kam speziell von meinen Lampen :o Ich werde da mal etwas nachbessern und auch den 'sepia-name' Tag explizit ins Control HUB Interface einbauen ^^.

sepia

Ich habe einige Verbesserungen an der Test-Version vorgenommen, allerdings kam Gestern ein kleines Problemchen auf:

Die Lampen, mit denen ich bisher getestet habe (Philips Hue) konnten via "set pct 70" auf 70% Helligkeit gesetzt werden. Im FHEM Demo gibt es nun eine Lampe (ReadingLight) die den Parameter "pct" nicht unterstützt. Daraufhin habe ich es mit "set dim 70" und "set dim70%" versucht ... was aber auch nicht geht, da scheinbar nur diskrete Werte wie "dim68%" möglich sind :o. Nun wäre es ein ziemlicher Overkill jedesmal den nächstgelegenen dim Wert rauszusuchen. Gibt es dafür irgendwie eine bessere Lösung?  ::)

TRallala

habe FHEM eingetragen - aber das ist ja nun wirklich kein show-stopper.

Thema HUE/ set pct
Ich denke das liegt hauptsächlich an dem DemoGerät type FS20. Bei den meisten "neueren" dimmer typen sollte ein "set Licht pct x"  möglich sein, denke ich.

um das testen weiter zu bringen, lege dir einfach ein HUE Device an.
define HueLight HUEDevice 1

Um das ganze allerdings möglichst abstrakt zu halten, könnte/sollte man alle "set" kommandos eines Gerätes abgreifen. (kann dir nur leider nicht sagen wie  :-\ )

Ausserdem wird ein Import ALLER Geräte auch zum Overkill werden. Ich will gar nicht wissen wie hoch die Anzahl der Geräte  der Spitzenreiter hier so ist , sei es nur Licht und Heizung.
M.M.n. kann der Import ruhig nur auf Geräte erfolgen die ein "attr  sepia-name"  gesetzt haben.


Thema name/NAME
Kann es sein, dass deine Geräte den name unter Attributes haben? Alle meine Geräte haben unter INTERNALS immer und nur NAME.


Ich hoffe es gesellen sich hier noch ein, zwei weitere Meinungen hinzu...

sepia

ZitatUm das ganze allerdings möglichst abstrakt zu halten, könnte/sollte man alle "set" kommandos eines Gerätes abgreifen. (kann dir nur leider nicht sagen wie  :-\ )

Es gibt scheinbar 2 Möglichkeiten dafür. Auf oberster Ebene das Feld "PossibleSets" und dann noch "Attributes"->"webCmd". Beide zeigen allerdings unterschiedliche Daten an, für die Demo Lampe z.B.:

"PossibleSets":"dim0%:noArg dim100%:noArg dim06% dim100% dim12% dim18% dim25% dim31% dim37% dim43% dim50% dim56% dim62% dim68% dim75% dim81% dim87% dim93% dimdown dimup dimupdown off off-for-timer on on-100-for-timer-prev on-for-timer on-old-for-timer on-old-for-timer-prev ramp-off-time ramp-on-time reset sendstate timer toggle dim:slider,0,6.25,100 off-till blink off-till-overnight on-till intervals on-till-overnight"
und:
"webCmd": "on:off:dim:dim 50"

Als ich "dim:slider,0,6.25,100" gesehen habe dachte ich man könnte das vielleicht nutzen um auf ~70% zu "sliden", den Befehl kriege ich aber gar nicht zum Laufen ("set ReadingLight dim:slider,0,6.25,100" war mein Versuch).

ZitatAusserdem wird ein Import ALLER Geräte auch zum Overkill werden. Ich will gar nicht wissen wie hoch die Anzahl der Geräte  der Spitzenreiter hier so ist , sei es nur Licht und Heizung.
M.M.n. kann der Import ruhig nur auf Geräte erfolgen die ein "attr  sepia-name"  gesetzt haben.

Ich merke schon beim Demo dass es etwas unübersichtlich wird ;D , allerdings möchte ich auch vermeiden, dass der User irgendwelche Attribute im FHEM Interface per Hand setzen muss. Vielleicht fällt mir noch ein guter Kompromiss ein oder ich mache 'sepia-name' tatsächlich zur Pflicht ^^. Gestern hatte ich schon den neuen Wert 'hidden' für 'sepia-type' eingeführt, der das Gerät zunächst ausblendet und bei Befehlen ignoriert, mal gucken.

ZitatKann es sein, dass deine Geräte den name unter Attributes haben? Alle meine Geräte haben unter INTERNALS immer und nur NAME.

Der ist komischerweise tatsächlich unter "Internals". K.A. warum :-[

sledge

Hi,

meines Wissens ist da jetzt einiges an gefährlichem Halbwissen unterwegs.

Um zB alle möglichen set-Befehle zu erhalten, ist laut Doku

set <DEVICE> ?

der richtige Weg, sofern es korrekt implementiert wurde.

Und um zb Lampen zu dimmen, gibt es je nach Lampe unterschiedliche Methoden.

Die Yeelight zB reagiert auf "bright", HomeMatic gerne auf "pct" usw. Das hängt davon ab, wie es im entsprechenden Modul implementiert wurde.

Das von dir angeführte "webCmd": "on:off:dim:dim 50" wiederum bedeutet nichts anderes, als folgende Webcommands in der Weboberfläche darzustellen:

* On
* Off
* dim
* dim 50 - also direktes Dimmen auf  50%

Wie also dimmt man die Lampe korrekt?

set <DEVICE> dim 70 das sollte es sein.

Bitte ansonsten einfach mal die Einsteigerdoku lesen, da wird all das gut beschrieben.

HTH Tom

FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

TRallala

ZitatEs gibt scheinbar 2 Möglichkeiten dafür. Auf oberster Ebene das Feld "PossibleSets" und dann noch "Attributes"->"webCmd". Beide zeigen allerdings unterschiedliche Daten an, für die Demo Lampe z.B.:
Böse Falle - du musst die PossibleSets nehmen.  webCmd wird bei den meisten in Poduktivumgebungen Schaltern nicht gesetzt sein - es dient nur zur Darstellung von Sets in der Weboberfläche (daher der Name).
Wie mein Vorredner schon schreinb:  Vergiss dies direkt wieder.

Zum Import: Evtl. ist es eine Möglichkeit im voraus zu filtern, was bzw. welcher (fhem)Typ Importiert werden soll?

Habe ich noch nie verstanden, warum man Internals mit selben namen auch nochmal als attribut anlegt, nur dann in Kleinschreibung - hat mich auch schon mal verwirrt.

Zitatset <DEVICE> dim 70
das sollte es sein.
<= wird nicht funktionieren, da der dimmer vom Typ FS20 nur in 6 Schritten gedimmt werden kann.

sledge

Zitat von: TRallala am 08 November 2019, 13:13:04

  <= wird nicht funktionieren, da der dimmer vom Typ FS20 nur in 6 Schritten gedimmt werden kann.
Ist dann aber eher ein Spezialfall als die Regel - IMHO.
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

TRallala


...denk ich auch; hindert sepia aber gerade dran mit der Demo Version vernünftig zu testen.


zurück zum Test; @Florian:

habe zwei Geräte in Sepia importiert. beide im selben Raum. Wenn ich "den Raum" schalte, wird nur das erste Gerät geschaltet.

sepia

Hi Tom,

danke für die zusätzlichen Infos.

set <DEVICE> ?

Scheint über das "REST" interface nicht zu funktionieren. Da kommt nur "Unknown argument ?" zurück. Aus dem Rest der Diskussion würde ich aber schließen, dass "PossibleSets" die entsprechenden Infos enthält. Da dim XY bei neueren Geräten wohl meistens klappt würde ich zunächst wie folgt vorgehen:

  • Falls das Gerät eine Lampe ist und der Set-Wert eine Zahl, dann versuche "set dim XY"
  • Wenn die Lampe das nicht kann wird erstmal der Fehler ausgespuckt
  • Später kann man zusätzlich den "PossibleSets" Check einbauen und ggf. den diskreten Wert berechnen

@Markus:

ZitatZum Import: Evtl. ist es eine Möglichkeit im voraus zu filtern, was bzw. welcher (fhem)Typ Importiert werden soll?

Ja das wäre eine Möglichkeit. Vielleicht statt "Load Devices" 4 Buttons: "Load all devices" - "Load lights" - "Load heaters" - "Load sensors" ? Oder einfach direkt ein Selector mit allen unterstützen Types :)

Zitathabe zwei Geräte in Sepia importiert. beide im selben Raum. Wenn ich "den Raum" schalte, wird nur das erste Gerät geschaltet.

Ja das ist momentan noch zu erwarten. Der Einfachheit halber wähle ich bei mehreren Treffern momentan einfach das erste im Array ::) Da in der neuen Version auch die Unterscheidung via Zahlen möglich ist (Lampe 1, Lampe 2, etc.) könnte ich das jetzt eigentlich umbauen ^^. Die Geräte nach Namen zu unterscheiden habe ich übrigens bisher nicht eingebaut weil das sowohl von der Spracherkennung als auch dem Natural-Language-Understanding etwas tricky ist und deutlich mehr Aufwand erfordert. Über die Teach-UI von SEPIA könnte man sich aber selber Befehle eintragen die dann z.B. "Licht im Wohnzimmer" mappen auf "Licht 1 im Wohnzimmer. Licht 3 im Wohnzimmer" o.ä.  8)

sepia

Hallo zusammen,

ich habe mal eine neue Testversion gebaut und hier hochgeladen: LINK
Die Version ist vorkonfiguriert für FHEM auf localhost und hat einen Test-User mit Smart Home Rechten: uid1007, test12345 (der Admin hat das selbe Passwort ;-) ).
Wer etwas umstellen will kann einfach noch mal das Setup ausführen oder in den Docs gucken (die Smart Home Erklärung ist noch für openHAB aber überschneidet sich teilweise mit FHEM). Wer SEPIA noch nicht kennt: zum Starten wird lediglich JAVA benötigt.

Im Wesentlichen habe ich alle Punkte von Oben umgesetzt und eine ganze Reihe neuer Gerätetypen hinzugefügt. Was mir allerdings beim letzten Test mit meinen "echten" Lampen aufgefallen ist, ist dass "set dim xy" nicht klappt bei den Philips Hue :-[ , da muss also dann doch später noch der "PossibleSets" Check rein.

Diese Woche komme ich wahrscheinlich nicht dazu an SEPIA zu arbeiten, ihr könnt also ganz in Ruhe testen ;-)

justme1968

auch von mir noch mal kurz der hinweis: tu dir den gefallen und kodiere nichts fest. keine device typen, keine set kommandos, ...

am besten ist es alles zur laufzeit auszulesen. statt set ? und list kann ich dir jsonlist2 empfehlen. da ist alles einfach zu parsen und vollständig.

das eigentliche problem ist aber die semantik der jeweiligen kommandos und readings automatisch zu erkennen. das geht nämlich nicht. du kannst bestenfalls die häufigsten kommandos wie on und off oder readings wie temperature automatisch verstehen. spätestens bei dummys oder mqqt kommst du hier ohne unterstützung durch den anwender aber nicht weiter. leider sind weder readings noch kommandos in fhem standardisiert. neben den unterschieden bei den devices kann sich jeder anwender bei den konfigurierbaren devices wie z.b. mqtt völlig frei austoben.

schau dir mal an wie das homebridgeMapping attribut funktioniert. damit kann man so ziemlich jede konfiguration abbilden ohne ein einziges byte quelltext ändern zu müssen. ja ich weiss es ist für viele nicht ganz einfach zu verstehen, es wird aber erfolgreich für die drei verbreitetsten sprachassitenen (siri, alexa und google home) verwenden. für siri und alexa waren z.b. in den letzen x monaten keine änderungen am jeweiligen connector nötig um neue devices in fhem zu unterstützen. nur wenn auf api seite neue dinge unterstützt werden sollen muss hier etwas getan werden.

ein weiterer vorteil wäre die kompatibilität zu den schon existierenden assistenten und damit ein einfacheres hin und her wechseln oder ausprobieren.


vielleicht hilft dir genericDeviceType bei der umsetzung des schalten nach geräte art (licht, heizung, ...)


die hue helligkeit geht über pct. nicht dim. so wie bei HomeMatic und damit vermutlich der größten anzahl an geräten.



ich glaube mittel und langfristig machst du dir einiges einfacher wenn du dir mal anschaust was für es für die anderen sprachassitenten schon an erfahrungen gab.

ansonsten weiter viel spass und viel erfolg :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

sepia

Hi justme :-)

Danke für die zusätzlichen Infos und Hinweise :)

Zitatstatt set ? und list kann ich dir jsonlist2 empfehlen. da ist alles einfach zu parsen und vollständig

Zur Zeit benutze ich "?cmd=jsonlist2 NAME ..." zum Auslesen eines Gerätes und "?cmd=set NAME STATE" zum Setzen eines neuen States.

Zitatschau dir mal an wie das homebridgeMapping attribut funktioniert

Ich habe das mal gegoogled und folgende Infos gefunden: Homebridge_User_Configs. Aus der Anleitung, die darin verlinkt ist (und der neuere Anleitung die in der alten Anleitung verlinkt ist ^^) ergibt sich folgendes Bild für mich:

  • Es wird ein zusätzlicher "Homebridge" Server benutzt, der in Node.js geschrieben wurde
  • Dieser stellt eine HomeKit kompatible Schnittstelle zur Verfügung
  • ... und übersetzt die Befehle dann intern (mit entsprechenden Plugins) in FHEM Befehle
  • Damit SEPIA das nutzen könnte müsste ich das HomeKit Protokoll verstehen und umsetzen (was Amazon und Google scheinbar gemacht haben)

Stimm das so ungefähr?
Falls das so passt dann frage ich mich ob es im FHEM Plugin des Homebridge Servers nicht genau das gleiche Problem gibt, was hier gerade besteht nämlich, dass man für jedes Gerät genau definieren muss welche set Befehle zuständig sind für z.B. Helligkeit, Temperatur usw.?
Abgesehen davon wäre HomeKit Support für SEPIA natürlich auch spannend, gibt es irgendwo eine Beschreibung des Protokolls? Läuft das über ein REST Interface oder vielleicht eine Socket Verbindung?

Zitatvielleicht hilft dir genericDeviceType bei der umsetzung des schalten nach geräte art

Diese Infos könnte man definitiv versuchen auszulesen um einmalig den Gerätetypen besser zu bestimmen. Im Grunde ist das das gleiche was der User im SEPIA Control-HUB setzen kann nur heißt das dort "sepia-type" statt "genericDeviceType".

Zitatdu kannst bestenfalls die häufigsten kommandos wie on und off oder readings wie temperature automatisch verstehen [...] leider sind weder readings noch kommandos in fhem standardisiert

Ich glaube der Scope für SEPIA ist zunächst mal die typischen Standardgeräte abzubilden und dazu noch die Möglichkeit im Zweifelsfall einen individuellen Befehl über SEPIAs Teach-UI direkt in der App zu erstellen (d.h. der User kann in der App einen bestimmten 'set' Befehl mit einem Satz verbinden, das geht in 2min, ist dann natürlich aber nicht mehr unabhängig vom HUB, aka FHEM etc.).

Zitatich glaube mittel und langfristig machst du dir einiges einfacher wenn du dir mal anschaust was für es für die anderen sprachassitenten schon an erfahrungen gab

Gibt es da eine Übersicht irgendwo? dkreutz hatte mal eine Python Library verlinkt (https://github.com/domschl/python-fhem) die er für den Mycroft FHEM Skill nutzt. Da konnte ich mir ein bisschen was abgucken weil es von der Schnittstelle passt. Ansonsten habe ich bisher nicht viel gefunden was über die HTTP Befehle läuft.

Zitatansonsten weiter viel spass und viel erfolg :)

Danke :D

justme1968

der name homebridgeMapping ist historisch weil ich es mir damals für homebridge-fhem ausgedacht habe. es ist aber weder homebridge spezifisch, noch wird es nur dort genutzt. alle drei wichtigen sprachassistenten (siri, alexa und google) bzw. deren fhem integration versehen es inzwischen mehr oder weniger gleich. es ist auch nicht an eine bestimme sprache oder einen bestimmten dienst gebunden.

es geht um eine recht allgemeine und (ohne code änderungen) erweiterbare beschreibung eines fhem device um readings und kommandos bestimmten semantischen bedeutungen zuzuordnen.

d.h. du baust in deinem code ein das das konzept Temperature verstanden wird und eventuell noch einen default das es für ein reading mit namen temperature automatisch funktioniert. der anwender kann dann aber völlig frei spezifizieren das bei seinem gerade relevanten gerät das reading anders heisst. z.b. Temperature oder temperatuer2 oder innen oder was auch immer.

das gleiche gilt für die kommandos die ausgeführt werden sollen. ein einfaches set <name> <value> reicht bald nicht mehr. sondern es ist z.b. ein set <name> <cmd> <value> nötig. oder der wertebereich auf beiden seiten ist verschieden und in beiden richtungen aufeinander abgebildet werden. auch das automatische erkennen des richtigen kommandos (ist es jetzt dim oder pct oder bri oder was ganz anderes) ist sogar bei der einfachen helligkeit nicht immer möglich weil es devices gibt die zwei oder drei davon können aber mit leicht unterschiedlicher bedeutung. von komplizierteren dingen wie der farbe von lampen und unterschiedlichen farbmodellen ganz zu schweigen.

wie das ganze prinzipiell aufgebaut ist findest du hier: https://github.com/justme-1968/homebridge-fhem


die drei implementierungen für siri, alexa und google sind zwar intern ähnlich weil sie nacheinander entstanden sind und so voneinander abgeschaut haben. sie sind aber prinzipiell komplett unabhängig und bilden nicht aufeinander ab. was bei homekit auch nicht möglich wäre. du kannst weder eigene sprache dort hinein füttern (im prinzip jedenfalls) und auch nicht an erkannte sätze kommen.

auch die feste zuordnung eines satzes zu einem set reicht spätestens dann nicht mehr wenn verschiedene geräte in verschiednen räumen jeweils mit dem gleichen satz gesteuert werden sollen.

die einzige gemeinsamkeit ist das sie auf die gleiche art konfigurierbar sind und man so recht einfach von einem assistenten zum andern wechseln oder mehr als einen einsetzen kann ohne viel an der konfogiration zu machen.

mit dem alexaMapping (leider wieder ein name der assitenten spezifisch ist) habe ich auch den umgekehrten weg angefangen. d.h. der anwender kann in fhem allgemein beschreiben welche gesprochene anfrage was bewirken soll.


ZitatDiese Infos könnte man definitiv versuchen auszulesen um einmalig den Gerätetypen besser zu bestimmen. Im Grunde ist das das gleiche was der User im SEPIA Control-HUB setzen kann nur heißt das dort "sepia-type" statt "genericDeviceType".
der unterschied wäre das alles in fhem konfiguriert wird und für alle assitenten gilt.


ZitatIch glaube der Scope für SEPIA ist zunächst mal die typischen Standardgeräte abzubilden
eben weil ich glaube das genau das der falsche ansatz wollte ich hier etwas dazu schreiben. wenn du am anfang mit fest codierten geräten anfängst kommst du entweder in teufels küche wenn du nach und nach alles mögliche einbauen musst oder es bleibt bei einer hand voll erkannter devices und dein modul wird nur von wenigen eingesetzt werden. die fhem welt ist sehr divers. wenn du gleich am anfang darauf vorbereitet bist machst du es dir wirklich einfacher.


du findest alexa-fhem und homebridge-fhem auf gitub und kannst dir anschauen wie die verbindung zu fhem aufgebaut wird und wie die events ausgewertet werden.

aber mir ging es garnicht so sehr um konkreten code sonder mehr um das konzept nichts fest in den code einzubauen. das funktioniert sehr schnell nicht mehr. und es wäre schade noch ein fhem projekt/frontend zu haben das nach kurzer zeit nicht mehr weiter entwickelt wird.

wenn das für deinen fall nicht weiter relevant ist: vergiss einfach was ich gesagt habe.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

sepia

Hi Andre,

ich versuche immer noch zu verstehen, wie Homebridge bzw. das homebridgeMapping und SEPIA zusammenkommen können. Vielleicht kannst du mir bei folgenden Fragen noch mal etwas nachhelfen :-)

Zitates geht um eine recht allgemeine und (ohne code änderungen) erweiterbare beschreibung eines fhem device um readings und kommandos bestimmten semantischen bedeutungen zuzuordnen.
[...]
ein einfaches set <name> <value> reicht bald nicht mehr. sondern es ist z.b. ein set <name> <cmd> <value> nötig. oder der wertebereich auf beiden seiten ist verschieden und in beiden richtungen aufeinander abgebildet werden. auch das automatische erkennen des richtigen kommandos (ist es jetzt dim oder pct oder bri oder was ganz anderes) ist sogar bei der einfachen helligkeit nicht immer möglich weil es devices gibt die zwei oder drei davon können aber mit leicht unterschiedlicher bedeutung. von komplizierteren dingen wie der farbe von lampen und unterschiedlichen farbmodellen ganz zu schweigen.

Das beschreibt ja ziemlich gut das Ausgangsproblemchen, aber ich fasse noch mal kurz zusammen. Das NLU Modul von SEPIA konvertiert Sätze in abstrakte "Absichten" (intent) des Users, z.B. "Lampe 1 im Wohnzimmer auf 70% setzen bitte" -> Service:smart_home, Device:light, Index:1, Room:livingroom, Action:set, Value:70%. Damit der Smart Home Service in SEPIA diesen "intent" ausführen kann greift er auf ein Smart Home Modul zu, das auf einem generalisierten Interface basiert (getState, setState, etc.). Für FHEM muss dieses Modul z.B. nun verstehen wie es "action:set, value:70%" für das Gerät "light,1,livingroom" ausführt und scheitert dabei zunächst, denn es weiß nicht welches der korrekte "set"-Befehl ist (dim, pct, bri, ...?).
Dieses Problem, unter dem alle Sprachassistenten und generalisierte UIs (z.B. HomeKit App) leiden, versucht nun das homebridgeMapping anzugreifen, indem es die "set"-Befehle weiter generalisiert bzw. remapped auf die folgenden Optionen, die für jedes Gerät in einer Konfigurationsdatei zugeordnet werden:

  • On
  • Brightness
  • Hue
  • Saturation
  • TargetTemperature
  • ...

Hab ich das soweit richtig verstanden?
Falls ja wäre die nächste Frage: Wie kann ich das neue Mapping über das HTTP Interface von FHEM ansprechen?

Zitatauch die feste zuordnung eines satzes zu einem set reicht spätestens dann nicht mehr wenn verschiedene geräte in verschiednen räumen jeweils mit dem gleichen satz gesteuert werden sollen

In SEPIA gibt es hier 2 Szenarios.

Szenario 1: Der User hat einen SEPIA Server und nutzt das Handy als SEPIA Client. Da das Handy üblicherweise erstmal nicht weiß in welchem Raum es sich befindet (wobei ich nicht ausschließe dass man dieses Feature einbauen könnte über zB BLE Beacons o.ä.) würde der User keinen Befehl definieren, der nicht eindeutig ist. Z.B. der Befehl "Licht" würde immer mit der Frage zurück kommen "welches Licht?". Einen eigenen Satz zu definieren ist hier nur sinnvoll wenn man a) mit "Licht" auch wirklich ein bestimmtes meint oder b) man ein spezielles Gerät hat mit individuellen States wie z.B. "Reinigungsroboter auf Modus super-sauber" was vom generalisierten Interface nicht abgedeckt wird.

Szenario 2: Der User hat mehrere SEPIA "smart displays" (Server + Client in einem Kasten). In diesem Fall kann der Befehl "Licht" abhängig vom Raum sein. Der SEPIA Service kann den Raum anhand der device ID des Gerätes finden.

Zitateben weil ich glaube das genau das der falsche ansatz wollte ich hier etwas dazu schreiben. wenn du am anfang mit fest codierten geräten anfängst kommst du entweder in teufels küche wenn du nach und nach alles mögliche einbauen musst oder es bleibt bei einer hand voll erkannter devices und dein modul wird nur von wenigen eingesetzt werden.

Ich bin da definitiv deiner Meinung und wenn es bereits ein Hilfsmittel gibt, dass die oben beschriebene Generalisierung (das Mapping) vornimmt, dann gucke ich mir das gerne an :) Allgemein vielleicht noch mal der Hinweis, dass SEPIA in der Komplexität der Befehle natürlich eh limitiert ist, da das Erkennen natürlicher Sprache schon kompliziert genug ist :-[ dennoch wäre es natürlich klasse wenn der User auch nicht standardisierte Aktionen ausführen kann indem er selber einen Satz definiert (in der SEPIA App) und (ggf.) einem homebridgeMapping Befehl zuordnet, der dann in FHEM angepasst werden kann falls sich das Gerät ändert (vorausgesetzt ich habe das jetzt richtig verstanden)  8).

Haecksler

Hallo,
hier eine etwas "OFF-TOPIC" frage bzgl. der FHEM Integration von SEPIA.

Ist es möglich, den gesamten Sprachkontent der Spracheingabe an FHEM weiterzuleiten?

Hintergrund ist, dass ich im Augenblick TASKER (für Testzwecke) in Verbindung mit Talk2Fhem nutze, dies funktioniert so gut, dass ich nun auf der Suche nach Möglichkeiten für fest installierte Peripheriegeräten mit Hotword-Erkennung bin (ALEX bzw. Google kommen nicht in Frage).
Hier wäre SEPIA ggf. eine Alternative zu Snips.ai.

Lg,
Stefan