SEPIA open-source Sprachassistent: Integration in FHEM?

[TRallala]

Zitat von: sepia am Gestern um 13:01:51

    Ah! Gute Idee 
    [EDIT] Was passiert, wenn man später neue hinzufügt, muss ich das dann auch in FHEM neu schreiben? Oder kann ich über das HTTP Interface auch Werte schreiben, die nicht in der Auswahl sind?


Ja ich hatte befürchtet das so eine Frage kommt, denn die kann ich leider gerade so nicht beantworten. Vermutlich aber so wie du gerade auch die Attribute einfügst oder löscht.

fhem nimmt/setzt auch werte die nicht in der Liste stehen - ist zumindest bei userattr so.
um userattr in global nicht unnötig lang werden zu lassen, schlage ich allerdings vor die vorgabe gar nicht erst zu machen.. man muss zu 99% sowieso übers control hub eingreifen, dann kann man auch schnell den raum/typ (neu) setzen


mein Robo braucht als Befehl "zone Raumname". Komme ohne Service also momentan nicht drum herum für jeden Raum einen Befehl anzulernen.
schaut atm so aus:

When I say ...     "schicke Robo ins wohnzimmer"
Smart device:    <device>;;Staubsauger
Room:               empty

Action:    <set>
Value:     {"value":"zone Wohnzimmer", "type":"custom"}
Answer:  <1> fährt ins Wohnzimmer

in fhem:
sepia-name  Staubsauger
sepia-room  hallway
sepia-state-type text_raw
sepia-type  device


Funktioniert gut soweit - ist momentan allerdings auch mein einziges "device".

[whistler]

Kurzer Zwischenstand.

Ist das aktuell noch ein Problem? Wenn die Befehle aus dem "set-cmds" Objekt kommen, sollten die eigentlich nicht verändert werden. Bei standard States wie ON, OFF etc. macht das SEPIA FHEM Interface automatisch eine "toLowerCase" Konversion weil FHEM scheinbar "on" versteht aber "ON" nicht (zumindest war das damals in meinen Tests so).

ich konnte es nun reproduzieren mit der to lower case schreibweise. Und wenn die custom config gefüllt ist:

Code Auswählen Erweitern

{"set":"<val>","enable":"on","disable":"off"}

schreibt er alles klein, schreibt man es wieder rein, schreibt er gross.

[Edit]
In der Antwort wird bei <3> (trotz gefüllter custom config) alles klein ausgegeben in der Antwort.

Viele Grüße

[whistler]

Hallo zusammen,

ich hab zum Thema Befehle einfacher an FHEM zu schicken und mit zu loggen mal etwas gebaut. Aber da gibt es noch ein kleines Problem. Aber zuerst zur Idee.

Wir erstellen eine Art SepiaGateway bestehend aus dummy / notify / log (evtl. auch ein doif):

dummy:

Code Auswählen Erweitern

defmod SepiaGateway dummy
attr SepiaGateway room Steuerung->SEPIA
attr SepiaGateway sepia-room other
attr SepiaGateway sepia-set-cmds {"set":"<val>"}
attr SepiaGateway sepia-state-type text_raw
attr SepiaGateway sepia-type other


notify:

Code Auswählen Erweitern

defmod notify_SepiaGateway notify SepiaGateway:* {\
my $ExecCommand = $EVENT;;\
    Log 1,"Sepia Gateway Exceute: $ExecCommand" ;;\
fhem("$ExecCommand");;\
}
attr notify_SepiaGateway group Steuerung
attr notify_SepiaGateway room Steuerung->SEPIA


logging:

Code Auswählen Erweitern


defmod SepiaGateway_log FileLog ./log/SepiaGateway-%Y.log SepiaGateway
attr SepiaGateway_log group Logging
attr SepiaGateway_log icon time_note
attr SepiaGateway_log logtype text
attr SepiaGateway_log room Steuerung->SEPIA,System->Logging


Der Log,1 Eintrag bzw. das FileLog ist natürlich optional.

Im TEACH Modul sieht es dann wie folgt aus:

Code Auswählen Erweitern


When I say ...     "Schicke Robo ins Wohnzimmer"
Smart device:    <other>;;Robo
Room:               <other>

Action:    <set>
Value:     {"value":"set Robo_Control Wohnzimmer", "type":"custom"}
Answer:  <1> fährt ins Wohnzimmer


Damit lässt sich dann auch der setreading Befehle der ja schon mal gewünscht war auch realisieren.

Eine nächste (große!) Erweiterung wäre, wenn man nicht nur  <set device [room] state> bedienen könnte, sondern auch readings setzen kann <setreading device [room] reading value>.

Es gibt aber ein kleines Problem. Vielleicht hat jemand eine Idee. Ich sehe vermutlich nur den Wald vor lauter Bäumen nicht.

Das notify löst nur beim Wertwechsel aus im dummy, was ja sicher auch richtig ist, aber das kann man doch bestimmt irgendwie umgehen.
Wenn ich den Befehl der im value vom Teachmodul steht direkt als Befehl im fhem abschicke geht es mehrfach hinterheinander.
Evtl. eine Überprüfung die greift bei der externen Übergabe?

Vielleicht hat dazu jemand eine Idee.
[Edit]
Fügt man folgende Zeile am Ende des Notifys ein, wird der state überschrieben und somit ändert er sich beim nächsten Befehl, aber das geht sicher auch eleganter.
Zumal das natürlich auch einen Logeintrag generiert.

Code Auswählen Erweitern


fhem("setreading $NAME state -");


Vielen Dank.

[Jasdhewer]

Hallo,
jetzt wage ich mich endlich an das Projekt. Habe aber folgendes Problem. Ich kann mich nicht einloggen:

bei dieser Internetseite:
192.168.178.28:20721/tools/index.html

gebe ich bei Benutzername = Admin ein, welches ich in der Installation eingegeben habe.
bei Passwort= Assistant (aus der Installation)

Bei Authentication Server:
http://192.168.178.28:20721

Es heißt aber jedes Mal, dass der Login fehlgeschlagen ist. Was mache ich hier falsch? Über Hilfe freue ich mich sehr!

[TRallala]

Es gibt aber ein kleines Problem. Vielleicht hat jemand eine Idee. Ich sehe vermutlich nur den Wald vor lauter Bäumen nicht.

Das notify löst nur beim Wertwechsel aus im dummy, was ja sicher auch richtig ist, aber das kann man doch bestimmt irgendwie umgehen.
Wenn ich den Befehl der im value vom Teachmodul steht direkt als Befehl im fhem abschicke geht es mehrfach hinterheinander.
Evtl. eine Überprüfung die greift bei der externen Übergabe?

Vielleicht hat dazu jemand eine Idee.

Deine Config m.M.n genau so richtig und funktioniert(0hne sie getestet zu haben)
Wenn ich das richtig sehe, liegt das Verhalten bei sepia.
Sepia merkt sich den status und schickt einen Befehl nicht doppelt, bzw. "zwangsweise".

Damit lässt sich dann auch der setreading Befehle der ja schon mal gewünscht war auch realisieren.

hmm, hast du wohl recht.

gebe ich bei Benutzername = Admin ein, welches ich in der Installation eingegeben habe.
bei Passwort= Assistant (aus der Installation)

Assistant ist (hoffentlich) nicht dein Passwort... falls doch versuch mal als login name "uid1003"
Falls das auch nicht funzt: führe nochmal das Setup aus und lies genau wann welches passwort einzugeben ist.

[Jasdhewer]

@TRallala
vielen Dank für deine Antwort:
Im setup wird man doch gefragt:
"Admin" --> Da kann ich nun was schreiben, z.B. Smarthome. Danach geht es direkt im Setup weiter und im Setup steht dann als nächstes "Assistant" und man muss wieder etwas eingeben sonst geht es ja nicht weiter im Setup, z.B. MeinPasswort. Ist das nun richtig oder wo genau muss ich ein Passwort eingeben? Ich dachte, dass diese beiden Abfragen entsprechend die login daten (Benutzername und Passwort) sind??? Gibt es auch eine Möglichkeit manuel das Passwort/ Benutzername auszulesen? Irgendwo muss es ja abgelegt sein?

[TRallala]

Ich dachte, dass diese beiden Abfragen entsprechend die login daten (Benutzername und Passwort) sind???

Stimmt auch, deine beschreibung was du gemacht hast war  nur etwas irritierend.

Code Auswählen Erweitern

Gibt es auch eine Möglichkeit manuel das Passwort/ Benutzername auszulesen? Irgendwo muss es ja abgelegt sein?
somehow gehasht in 

Code Auswählen Erweitern

SEPIA/sepia-assist-server/Xtensions/assist.properties
unter

Code Auswählen Erweitern

universal_superuser_pwd

hast du admin@sepia.localhost oder uid1003 als login versucht?

[Jasdhewer]

@TRallala
vielen Dank, die Datei hat mir sehr weitergeholfen. Ich kam jetzt endlich rein:

Der login-Benutzer ist in meinem Fall: "uid1003" (wie auch in der Datei angegeben)
Das Passwort ist bei mir "Admin"! Also die erste Abfrage im Setup. Ich verstehe aber nicht für was dann "Assistent", d.h. die zweite Abfrage im Setup ist?
Noch etwas. Das PW ist in der Datei verschlüsselt, was ja auch Sinn macht.
Aber wie gesagt es funktioniert jetzt bei mir.
Vielen Dank dir noch einmal!

[whistler]

Deine Config m.M.n genau so richtig und funktioniert(0hne sie getestet zu haben)
Wenn ich das richtig sehe, liegt das Verhalten bei sepia.
Sepia merkt sich den status und schickt einen Befehl nicht doppelt, bzw. "zwangsweise".

@Florian kannst du was zu dem verhalten von Sepia sagen?

Ich hab nochmal ne Frage. Hat von euch schon jemand den Sepia Client im Firefox am laufen mit Nutzung des Mikrofons.
per https Verbindung via Reverse Proxy fragt zumindest der Firefox mal nach dem Zugriff auf das Mikrofon.

Sicherheitszugriff für Mikrofon und Kamera hat sich ja in den letzten Wochen Monaten in Chrome und Firefox geändert.

Nach Zugriffserlaubnis im Firefox und erneutem Klicken auf den Aufnahme Button im Sepia Client erhalte ich dann folgende Meldung

Code Auswählen Erweitern


UI: Mikrofon nicht richtig erkannt oder Zugriff verweigert.


In den Einstellungen ist als custom Socket für ASR folgendes eingetragen:

Code Auswählen Erweitern


ws://192.168.1.11:9000/stt/socket

Vielleicht ist auch dass das Problem? dann müsste ich das auch noch per SSL über den Proxy schieben?
(Fällt mir gerade beim schreiben hier so ein).

Jemand eine Idee was das sein könnte.

Danke.

[sepia]

Hallo Zusammen,

sorry, dass ich gerade etwas hinterherhinke mit den Antworten, arbeite noch fleißig am nächsten Update in der Hoffnung es vielleicht Morgen noch zum release Kandidaten zu schaffen, bevor ich dann ab Samstag eine Woche im Urlaub bin

Das klingt gut, ist ja fast wie an Weihnachten, wenn man auf die Geschenke wartet als Kind.
Vielleicht könnte man die states / events auch an fhem weitergeben, um dort darauf reagieren zu können. Ein paar Ideen dazu:
- hotworderkennung pro device (in dem Fall als der client android / browser headless)
- was erkannt wurde
- Gerät Online / Offline
- Vielleicht bietet das Snips Addon: https://github.com/Thyraz/Snips-Fhem bzw.  ja noch ein paar Ideen, die man einbauen könnte.
Ich kann das sonst bei Gelenheit nochmal detailierter formulieren.

State und Event broadcasting ist definitiv ein Thema dabei. Für das Interface zwischen dem Client und dem "remote Terminal" nutze ich einen Node.js Server, den ich vor einer ganzen Weile mal gebaut hatte um Bluetooth Beacon Signale an SEPIA weiterzuleiten: CLEXI. Damals dachte ich noch nicht über MQTT nach, aber man könnte eine Erweiterung bauen für CLEXI, die die Events an einen Broker durchreicht. Bisher werden Events für Login, Logout, speaking, listening, loading und idle weitergeleitet ans "Terminal".

Dabei hätte ich noch einen Featurewunsch:
Wieviel Uhr ist es | Wie spät ist es | Was sagt die Uhr;;  command=chat;;  reply=Es ist <local_time_hhmm> Uhr;;
Schau mal hier ein, hier wurde entsprechend ein wenig was in dem Hinblick für Snips gebaut: https://forum.fhem.de/index.php/topic,89548.930.html
[Edit]
Hast du einen Beispielaufruf fürs Teachmodul über die API zum aus und einlesen?

Dieses Feature wäre sicherlich sinnvoll, habe ich mal auf die Liste gesetzt. Für die Antworten geht es übrigens schon reply=Antwort A||Antwort B||Antwort C;;
Die Antwort wird dann zufällig ausgewählt. Das ganze System mit Antworten ist eigentlich noch viel komplexer, aber später mehr dazu ^^.
Ein erstes, einfaches Beispiel habe ich gerade mal exportiert und eine neue Sektion in den SEPIA Docs erstellt  ->click me<-

Dann verwirrt natürlich der "Eintrag hinter <device>;; wenn er nicht greift, bzw. noch nicht greift
Wenn die Bezeichnung ignoriert wird, dann hat er ja alles richtig gemacht, und nebenbei für etwas Verwirrung gesorgt.

Ganz ignoriert wird er nicht ... falls eine Zahl drin steht Die Hoffnung ist natürlich diese Informationen später auch komplett zu verwenden, der Schritt dahin wäre auch gar nicht so weit, zumal für Werte aus dem Teach-Interface ja nicht mal ein robustes Fuzzy-Matching nötig wäre (das braucht man dann wieder wenn das ganze per natürlicher Sprache gesagt wird), aber braucht noch etwas Zeit

mein Robo braucht als Befehl "zone Raumname". Komme ohne Service also momentan nicht drum herum für jeden Raum einen Befehl anzulernen.
schaut atm so aus:

When I say ...     "schicke Robo ins wohnzimmer"
Smart device:    <device>;;Staubsauger
Room:               empty

Action:    <set>
Value:     {"value":"zone Wohnzimmer", "type":"custom"}
Answer:  <1> fährt ins Wohnzimmer

in fhem:
sepia-name  Staubsauger
sepia-room  hallway
sepia-state-type text_raw
sepia-type  device

Funktioniert gut soweit - ist momentan allerdings auch mein einziges "device".

Ah sehr gut, genau so hatte ich mir das vorgestellt 
Ich gucke mir aber auf jeden Fall mal die bereits besprochenen Konflikte mit mehreren Devices etc. an.

ich konnte es nun reproduzieren mit der to lower case schreibweise. Und wenn die custom config gefüllt ist:
{"set":"<val>","enable":"on","disable":"off"}
schreibt er alles klein, schreibt man es wieder rein, schreibt er gross.

"<val>" kam in diesem Fall aus einem eigenen Teach-UI Befehl? Ansonsten kann das ja zur Zeit glaub nur eine Zahl sein oder übersehe ich jetzt selber was? ^^

ich hab zum Thema Befehle einfacher an FHEM zu schicken und mit zu loggen mal etwas gebaut. Aber da gibt es noch ein kleines Problem. Aber zuerst zur Idee.

Wir erstellen eine Art SepiaGateway bestehend aus dummy / notify / log (evtl. auch ein doif):
...

Interessante Sache!
Ich kenne mich mit FHEM Skripten noch nicht so gut aus, aber ich interpretiere das so: Man schickt via SEPIA ein "set" Kommando an den Dummy und der Dummy "übersetzt" es intern via "Notify" in einen etwas anderen Befehl + Log? Passt das so?
Und das Problem ist jetzt, dass Notify nur ausgelöst wird, wenn sich der Befehl ändert? Oder schickt SEPIA erst gar nichts ab?
SEPIA hat ein "Feature", das hier eventuell von Bedeutung ist. Wenn der neue "set" state identisch ist mit dem alten führt SEPIA keine Aktion aus. Beim Licht das bereits auf 50% steht sagt SEPIA dann einfach "Das Licht ist bereits auf 50%". Geprüft wird das durch auslesen des state kurz vor dem neuen setzen. Vielleicht könntest du den alten state nach dem notify irgendwie modifizieren, damit er nicht mehr identisch ist? Optimalerweise so, dass SEPIA bei "Was ist der Status von ...?" noch etwas sinnvolles sagen kann ^^.

Der login-Benutzer ist in meinem Fall: "uid1003" (wie auch in der Datei angegeben)
Das Passwort ist bei mir "Admin"! Also die erste Abfrage im Setup. Ich verstehe aber nicht für was dann "Assistent", d.h. die zweite Abfrage im Setup ist?
Noch etwas. Das PW ist in der Datei verschlüsselt, was ja auch Sinn macht.
Aber wie gesagt es funktioniert jetzt bei mir.
Vielen Dank dir noch einmal!

Es gibt in SEPIA zwei "Core" User, den 'Admin' und 'Assistant'. 'Assistant' is quasi SEPIA. Der Witz ist, dass SEPIA sich im Chat Server genau so einloggt wie der User Der zweite Witz ist, dass alle Teach-UI Befehle und SDK Services, die der 'Assistant' User "lernt" ALLEN Usern zur Verfügung stehen.
Im Setup wird man deshalb nach 2 Passwörtern gefragt, einmal Admin und einmal Assistant. Login in den Control HUB ist üblicherweise dein eigener User oder Admin. Der Admin hat standardmäßig die ID "uid1003" der Assistant "uid1005".

Ich hab nochmal ne Frage. Hat von euch schon jemand den Sepia Client im Firefox am laufen mit Nutzung des Mikrofons.
per https Verbindung via Reverse Proxy fragt zumindest der Firefox mal nach dem Zugriff auf das Mikrofon.

Firefox unterstützt leider die Spracherkennung via Web Speech API nicht, deshalb muss der Browser auf den SEPIA STT Server zurückgreifen Der Client erkennt Firefox und schaltet deshalb beim Start automatisch von "native" ASR auf "socket" und erwartet dann die URL zu dem STT Server. Das Docker Image gibt es bisher leider nur für 64bit x64 Systeme. Einige Verbesserungen dazu stehen ganz oben auf der To-Do Liste ^^.

[Jasdhewer]

vielen Dank schon mal.
Ich habe noch eine Frage, die ich wahrscheinlich zu Beginn hätte stellen sollen... : Kann ich SEPIA auch ohne FHEM betreiben? Ich habe auf dem Raspi nur PIVCCU3 und iobroker?
Habe in den Einstellungen die IP-Adresse von iobroker und den Namen eingetragen, (der server wird grün, aber es werden keine Devices gefunden). Bei der IP-Adresse von PIVCCU3 gleiches Problem...

[sepia]

Hallo
SEPIA läuft bisher nur mit FHEM und openHAB als Smart Home Zentrale. ioBroker habe ich auf der To-Do Liste, mit PIVCCU3 hatte ich bisher keinen Kontakt.

----

So, ich bin leider nicht mehr ganz fertig geworden mit dem nächsten, offiziellen Release, aber hier mal eine recht stabile Preview: DOWNLOAD v2.4.1 Preview. Vielleicht hat ja Jemand Lust etwas damit zu experimentieren ^^.

Es sind viele der besprochenen Änderungen und Fixes drin, z.B.:

• Neuer Raum: Wintergarten (sunroom)
• Korrektes Sammeln der Geräte via ID statt Name damit Geräte mit gleichem Namen nicht verschwinden
• "Raum Nummer 2" geht jetzt auch (vorher nur "Raum 2")
• Device und Raum Namen werden korrekt durchgereicht ohne "lower-case" Konversion
• Device Namen werden jetzt auch benutzt um den besten Treffer zu finden (macht im Grunde nur Sinn wenn der Name via Teach-UI definiert wurde, (noch) kein Fuzzy Matching, die Namen müssen also 100% übereinstimmen für einen Match)
• Bei mehreren Geräten des selben Typs im selben Raum (ohne definierten Device Name und ohne Index, also z.B. "Licht im Wohnzimmer") wird gefragt, ob das erste benutzt werden soll. Die Lösung ist noch nicht optimal, aber besser als ein "zufälliger" Treffer
• Diverse kleine Verbesserungen und Fixes hier und da
• Die Skripte für die lokale Java Installation sind auch enthalten ([SEPIA]/java/)

Außerdem gibt es 2 größere Erweiterungen:

• Text-to-speech (TTS) kann jetzt komplett über den SEPIA Server generiert werden, statt im Client. Dazu habe ich einen alten TTS Endpoint "modernisiert". In den Client Settings kann die Sprachausgabe bei "Voice engine" auf "Custom" umgestellt werden. Damit das ganze auch funktioniert muss einmal im upgedateten SEPIA-Home Setup (setup.sh) der Punkt "install TTS voices" ausgeführt werden. Im SEPIA Control HUB gibt es auch eine neue Seite für TTS Tests.
• Es gibt jetzt eine Art "Remote Terminal", zu finden im SEPIA Control HUB auf der neuen Seite "Client Connections". Der Client hat dafür einen neuen "headless" Mode bekommen (URL-Flag "isHeadless=true"), der automatisch nach 8s Login Screen einen Setup Modus aktiviert, die neue Datei "settings.js" im Client Verzeichnis einliest und sich dann versucht mit dem Server fürs "Remote Terminal" zu verbinden.

Beides ist primär für eine "headless" Raspberry Pi Installation gedacht. Die Skripte dafür sind hier zu finden: https://github.com/SEPIA-Framework/sepia-installation-and-setup/tree/dev/sepia-client-installation/rpi

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

Ich habe das ganze bisher auf einem Raspberry Pi Zero und einem RPi 3 getestet, jeweils mit Raspbian Buster und ReSpeaker 2-Mic HAT bzw. einem USB Mikrofon (Amazon Basics Kondensator Mic) + Sound Output via Headphone Jack (Klinke Kabel).

Ab Morgen bin ich eine Woche im Urlaub und kann wahrscheinlich nur bedingt auf Fragen eingehen, werde aber sicher mal reinschauen ^^. Hoffe das Meiste erklärt sich von selbst ...  ... und ihr habt Lust zu testen Das "Remote Terminal" hat auch einen "help" Befehl

[Jasdhewer]

ok. Danke. Dann werde ich wohl warten müssen...
Viel Vergnügen im Urlaub

[whistler]

Ein erstes, einfaches Beispiel habe ich gerade mal exportiert und eine neue Sektion in den SEPIA Docs erstellt  ->click me<-

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.

Ganz ignoriert wird er nicht ... falls eine Zahl drin steht Die Hoffnung ist natürlich diese Informationen später auch komplett zu verwenden, der Schritt dahin wäre auch gar nicht so weit, zumal für Werte aus dem Teach-Interface ja nicht mal ein robustes Fuzzy-Matching nötig wäre (das braucht man dann wieder wenn das ganze per natürlicher Sprache gesagt wird), aber braucht noch etwas Zeit

Ah sehr gut, genau so hatte ich mir das vorgestellt 
Ich gucke mir aber auf jeden Fall mal die bereits besprochenen Konflikte mit mehreren Devices etc. an.

Wäre gut ja (doppelte Lampen im gleichen Raum (Heizung und Rollos)

"<val>" kam in diesem Fall aus einem eigenen Teach-UI Befehl? Ansonsten kann das ja zur Zeit glaub nur eine Zahl sein oder übersehe ich jetzt selber was? ^^

Ja genau so war es, würde ich dann in der nächsten Version testen.

Interessante Sache!
Ich kenne mich mit FHEM Skripten noch nicht so gut aus, aber ich interpretiere das so: Man schickt via SEPIA ein "set" Kommando an den Dummy und der Dummy "übersetzt" es intern via "Notify" in einen etwas anderen Befehl + Log? Passt das so?
Und das Problem ist jetzt, dass Notify nur ausgelöst wird, wenn sich der Befehl ändert? Oder schickt SEPIA erst gar nichts ab?
SEPIA hat ein "Feature", das hier eventuell von Bedeutung ist. Wenn der neue "set" state identisch ist mit dem alten führt SEPIA keine Aktion aus. Beim Licht das bereits auf 50% steht sagt SEPIA dann einfach "Das Licht ist bereits auf 50%". Geprüft wird das durch auslesen des state kurz vor dem neuen setzen. Vielleicht könntest du den alten state nach dem notify irgendwie modifizieren, damit er nicht mehr identisch ist? Optimalerweise so, dass SEPIA bei "Was ist der Status von ...?" noch etwas sinnvolles sagen kann ^^.

genau der Befehl wird dann komplett an den Dummy geschickt. (gleiches gilt dann für das setreading "Problem"), kurz danach hab ich die Anpassung gemacht (Vermutlich untergegangen) und es zumindest mit einem state - erweitert. Damit wird quasi innerhalb des notify erst der Befehl ausgeführt und dann der state zurück auf - gesetzt. (kann natürlich jeder andere Wert sein.
Ja das mit dem Zurücksetzen des state auf was sinnvolles hab ich auch schon überlegt. ist mir aber direkt nichts eingefallen. Das device wäre ja nur ein gateway proxy teach device. die Mehrfachantworten sind natürlich mal nicht schlecht für den ersten Schritt. Es wird gleichzeitig jeder befehl der über den Dummy geschickt wird, dann auch direkt ins mitangelegte LogDevice geschrieben. und zusätzlich nochmal ins Fhem log. (natürlich kein muss sondern optional)

Firefox unterstützt leider die Spracherkennung via Web Speech API nicht, deshalb muss der Browser auf den SEPIA STT Server zurückgreifen Der Client erkennt Firefox und schaltet deshalb beim Start automatisch von "native" ASR auf "socket" und erwartet dann die URL zu dem STT Server. Das Docker Image gibt es bisher leider nur für 64bit x64 Systeme. Einige Verbesserungen dazu stehen ganz oben auf der To-Do Liste ^^.

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

Ist ggf. dem Firefox die Websocket Verbindung nicht sicher genug?

Vielen Dank und einen schönen Urlaub.

[whistler]

So, ich bin leider nicht mehr ganz fertig geworden mit dem nächsten, offiziellen Release, aber hier mal eine recht stabile Preview: DOWNLOAD v2.4.1 Preview. Vielleicht hat ja Jemand Lust etwas damit zu experimentieren ^^.

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.