SEPIA open-source Sprachassistent: Integration in FHEM?

[whistler]

Hallo Florian,

ich hab schon neu kleine Liste mit wünschen angefangen beim testen

Super, danke für den Hinweis! Gibt man das einfach so im Terminal ein oder kommt das in eine Config Datei?
Der neue Wiki Eintrag ist übrigens hier: https://github.com/SEPIA-Framework/sepia-docs/wiki/Reverse-Proxy-Setup

das trägt man in die Konsole ein und aktiviert die entsprechenden Module die aufgerufen werden. Und die Doku hatte ich auch gesehen, deswegen dachte ich wäre eine Ergänzung gut. Reicht ja, wenn man drüber stolpert und sich der erste die Zähne erstmal dran ausbeisst.

Fehlermeldung im Apache log dazu würde in etwas so aussehen (bin ich aber zu spät drauf gekommen), wenn eins dieser Module nicht sauber installiert sind:

Code Auswählen Erweitern

AH01144: No protocol handler was valid for the URL /sepia/chat/messages/ (scheme 'ws'). If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.


Haben die beiden Lampen vorher den gleichen Namen gehabt (Internals->Name)? Dann kann es tatsächlich passieren, dass eine Lampe ignoriert wird
Ich bin bisher davon ausgegangen, dass das nicht vorkommt aber das gilt vermutlich nur für das übergeordnete "Name" Objekt O_O. Das lässt sich aber schnell fixen

Meinst damit den internen Namen im FHEM, dann sind diese unterschiedlich mindestens in der Kürzel Bezeichnung des Raumes. Wenn in FHEM das Feld sepia-name wieder zurück ändere lädt er wieder beide Devices Sauber im den Hub.

Wenn SEPIA sagt "Heizung Wohnzimmer in Wohnzimmer" dann weil der Name des Gerätes auch "Heizung Wohnzimmer" ist. Um das zu vermeiden könntest du mal versuchen Wohnzimmer in Klammern zu packen, also als Name "Heizung (Wohnzimmer)" oder "Heizung (Wohnzimmer) (2)". Das "müsste" eigentlich gehen ^^ ... ich fürchte da habe ich einen kleinen Logikfehler drin. Das kommt ganz oben auf die To-Do Liste

Ja das mit den Klammern zumindest bei den Zahlen hab ich schon gemerkt, das du sie wegfilterst bei der Antwort. Doppelte Klammern bleiben die letzten erhalten in deinem Beispiel dann Heizung (2).
Ich hab bei mir im Wohnzimmer tatsächlich zwei Heizkörper. Da tue ich mich noch etwas schwer mit. (Gleiches bei Rollo Lampen etc.)
Man hat halt wiederkehrende Dinge wie Deckenlampe pro Raum, Rolladen pro Raum, Heizung pro Raum.

Danke fürs Testen

Wenn wir durch testen helfen können immer gerne.

[klausw]

Ich habe auch die Apache Intengration als Reverse Proxy verfolgt.
Ich habe hier noch eine kleine Ergänzung vielleicht die noch mit ins Wiki könnte.
Beim Proxy müssen folgende Module aktiviert werden.

Code Auswählen Erweitern

a2enmod proxy proxy_http proxy_wstunnel

Mir fehlte der wstunnel. Dann springt der Android Client immer auf Online/Offline und verbindet nicht.
Nach dem aktivieren der Module und neustart des Apache geht er dann direkt komplett Online.

Oh stimmt.
Diese Module müssen auch aktiviert werden (waren sie bei mir schon wegen anderer Dienste)

Das wird im Terminal eingegeben
Der letzte Block in der Wiki sollte so aussehen:

Code Auswählen Erweitern


sudo a2enmod proxy proxy_http
sudo a2enmod proxy_wstunnel
sudo a2ensite sepia.conf
sudo systemctl reload apache2

[sepia]

Beim einrichten der Rolläden fiel mir noch auf: warum werden diese als  set type "Number (plain)"  angelegt? leuchtet mir nicht ein.
Die meisten dürften mit "open" / "0/100", "close/d" / "100/0", und oder prozent/level/position bedient werden - also am ehesen noch "Binary ON/OFF" ?

Hi Markus,
Der Typ Rollade (roller_shutter) wird (noch) nicht automatisch erkannt. Vermutlich kommt der state type "number (plain)" daher, dass der anfängliche Status des Gerätes eine Zahl ist (0 oder 100 ?). "On" und "off" sollte in jedem Fall zu der Aktion "up"/"down" führen und generell gehe ich davon aus das der User auch gerne mal "Rollos auf 50%" sagt. Für die nächste Version gucke ich mal, dass hier Prozent automatisch gesetzt wird

- Welche Möglichkeiten bietet sepia-set-cmds neben den im Beispiel angegebenen? Bzw. welche zustände/befehle können erkannt werden

sepia-set-cmds bietet bisher nur die Möglichkeit die "enable", "disable" und "set" Befehle zu definieren. Was auf der jeweils rechten Seite steht ist dabei völlig flexibel und kann alles sein was FHEM versteht. Im "set" Feld kann nur die Variable "val" bzw "value" benutzt werden zur Zeit, die die DeviceState Nummer repräsentiert, also "setze Gerät auf 50" -> val=50. Hast du hier zusätzliche Ideen, was du gerne machen würdest?

- Dient der sepia-type noch für weiteres ausser als filter beim aufrufen bzw. zur gruppierung?
   --> Wozu dienen type "device" und "other"?

sepia-type bestimmt auch wie manche set Befehle umgesetzt werden, z.B. für Rollos bewirkt ein "Rollo öffnen", dass "up" benutzt wird statt "on" usw..
Der Typ "Device" kann in Sätzen wie folgt benutzt werden "Setze Gerät 1 im Wohnzimmer auf XY". "Other" kann nicht durch Sprache erreicht werden, nur durch z.B. Befehle die via Teach-Interface erstellt werden, ist also so eine Art "unassigned" aber ignoriert das Gerät nicht vollständig wie "hidden".

Meinst damit den internen Namen im FHEM, dann sind diese unterschiedlich mindestens in der Kürzel Bezeichnung des Raumes. Wenn in FHEM das Feld sepia-name wieder zurück ändere lädt er wieder beide Devices Sauber im den Hub.[...]
Doppelte Klammern bleiben die letzten erhalten in deinem Beispiel dann Heizung (2).
[...]Man hat halt wiederkehrende Dinge wie Deckenlampe pro Raum, Rolladen pro Raum, Heizung pro Raum.

Soweit ich das sehe gibt es potentiell 3 "Namen". Die REST Api spuckt einen "name" auf oberster Eben aus, der vermutlich einzigartig ist, dann noch "Internals"->"name" und "Attributes"->"alias" (wenn ich das jetzt alles richtig in Erinnerung habe), die eher beliebig sind. Ich werde das noch mal gerade biegen für die nächste Version ^^.

Reicht ja, wenn man drüber stolpert und sich der erste die Zähne erstmal dran ausbeisst.

Das wird im Terminal eingegeben
Der letzte Block in der Wiki sollte so aussehen:

Erledigt, danke 

[TRallala]

Hi Florian,

vielen Dank für die ganzen Erklärungen!

    - Dient der sepia-type noch für weiteres ausser als filter beim aufrufen bzw. zur gruppierung?
       --> Wozu dienen type "device" und "other"?

sepia-type bestimmt auch wie manche set Befehle umgesetzt werden, z.B. für Rollos bewirkt ein "Rollo öffnen", dass "up" benutzt wird statt "on" usw..
Der Typ "Device" kann in Sätzen wie folgt benutzt werden "Setze Gerät 1 im Wohnzimmer auf XY".

<- bekomme ich leider nicht zum laufen. sobald ich "Device/Gerät" anspreche liefert mir sepia nichts zurück, bzw. kann nichts damit anfangen.

    - Welche Möglichkeiten bietet sepia-set-cmds neben den im Beispiel angegebenen? Bzw. welche zustände/befehle können erkannt werden

sepia-set-cmds bietet bisher nur die Möglichkeit die "enable", "disable" und "set" Befehle zu definieren. Was auf der jeweils rechten Seite steht ist dabei völlig flexibel und kann alles sein was FHEM versteht. Im "set" Feld kann nur die Variable "val" bzw "value" benutzt werden zur Zeit, die die DeviceState Nummer repräsentiert, also "setze Gerät auf 50" -> val=50. Hast du hier zusätzliche Ideen, was du gerne machen würdest?

Das Ganze hängt mit der vorhergehenden Frage zusammen.

Im Endeffekt würde ich gerne "raw-text" an ein Gerät übergeben um z.B. Wohnzimmer an fhem zu senden ohne dass Sepia dies als Raum oder halt irgendetwas anderes übersetzt.

Gruß
Markus

[sepia]

<- bekomme ich leider nicht zum laufen. sobald ich "Device/Gerät" anspreche liefert mir sepia nichts zurück, bzw. kann nichts damit anfangen.

Hmm, ich prüfe das noch mal Morgen, bin gerade auch nicht 100% sicher wie die Prioritäten gesetzt sind dabei

Im Endeffekt würde ich gerne "raw-text" an ein Gerät übergeben um z.B. Wohnzimmer an fhem zu senden ohne dass Sepia dies als Raum oder halt irgendetwas anderes übersetzt.

Kannst du dazu mal ein Beispiel geben? SEPIA versucht ja immer einen "set"-Befehl zu konstruieren oder einen "state" zu lesen. Wenn du sagt "Wohnzimmer an fhem" senden, wäre das dann sowas: "set [device] Wohnzimmer"?
[EDIT]
Ich könnte mir vorstellen, dass sowas z.B. für einen Staubsauger-Roboter Sinn macht :-D ... theoretisch könnte man das mit dem Teach-Interface machen, also man definiert den Satz "Sende Robo ins Wohnzimmer" und dann bei 'smart_device' '{"value":"device", "found":"Robo", "index":303}' und bei 'smart_device_value' '{"value":"Wohnzimmer", "type":"custom"}' ... dann sollte in FHEM "set [device 303] wohnzimmer" ankommen ... müsste ich aber auch noch mal testen ob das so durchläuft.

[TRallala]

    <- bekomme ich leider nicht zum laufen. sobald ich "Device/Gerät" anspreche liefert mir sepia nichts zurück, bzw. kann nichts damit anfangen.


Hmm, ich prüfe das noch mal Morgen, bin gerade auch nicht 100% sicher wie die Prioritäten gesetzt sind dabei

über die teach UI angelernt funktioniert es. Sollte m.M.n. aber auch so laufen, oder ?

Ich könnte mir vorstellen, dass sowas z.B. für einen Staubsauger-Roboter Sinn macht :-D ... theoretisch könnte man das mit dem Teach-Interface machen, also man definiert den Satz "Sende Robo ins Wohnzimmer" und dann bei 'smart_device' '{"value":"device", "found":"Robo", "index":303}' und bei 'smart_device_value' '{"value":"Wohnzimmer", "type":"custom"}' ... dann sollte in FHEM "set [device 303] wohnzimmer" ankommen ... müsste ich aber auch noch mal testen ob das so durchläuft.

Staubsauger Beispiel ist gut - genau das wäre das Ziel.
Momentan scheitert es daran, dass Sepia immer nach einem (integer) Wert fragt den er/sie/es schalten soll.
Falls

'smart_device_value' '{"value":"Wohnzimmer", "type":"custom"}'

schon realisierbar sein soll, scheitere ich an der syntax.


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

Gruß
Markus

[sepia]

über die teach UI angelernt funktioniert es. Sollte m.M.n. aber auch so laufen, oder ?

Habs gerade noch mal getestet, tatsächlich kann man Type "device" eigentlich nicht per Sprache triggern. Der Begriff ist leider so generisch, dass es etwas tricky ist das komplett allgemein zu machen, ABER ich glaube der User würde "Gerät" eh nie ohne Zusatzinformation benutzen oder? Dann könnte ich folgendes relativ zuverlässig erkennen "Gerät 1/2/3..." oder "Gerät mit Namen XY".

Staubsauger Beispiel ist gut - genau das wäre das Ziel.
Momentan scheitert es daran, dass Sepia immer nach einem (integer) Wert fragt den er/sie/es schalten soll.

Ja, der Smart Home Service ist dafür eigentlich nicht optimiert. Je länger ich darüber nachdenke desto mehr glaube ich, dass das eigentlich ein perfektes Beispiel wäre für einen kleinen custom Service über das SDK. Sagen wir es gibt ein Gerät namens "Robo" im Haushalt und Befehle für "Robo" wären "Schicke Robo ins Wohnzimmer" oder "Robo auf Modus eco" etc. könnte man das vermutlich gut abgrenzen und einen Konflikt mit dem Smart Home Service vermeiden.
Wenn Interesse besteht könnte ich dazu mal ein Beispiel machen. SDK Services sind in Java programmiert, der Code ist aber gut zu lesen mmn
Kriegen wir zum Testen einen FHEM Dummy erstellt?

Falls

'smart_device_value' '{"value":"Wohnzimmer", "type":"custom"}'

schon realisierbar sein soll, scheitere ich an der syntax.

Sieht eigentlich korrekt aus. Eventuell muss es kombiniert werden mit 'sepia-set-cmds'. Ich habe im Anhang mal 2 Bilder gemacht, wie es bei mir funktioniert. Allerdings sind mir auch beim Testen noch 2 kleinere Bugs aufgefallen, die ich mittlerweile behoben habe. Könnte also sein, dass du auf die neue Version warten müsstest

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

Kannst du mir noch mal den Unterschied genauer erklären anhand eines Beispiel Gerätes? Soweit ich weiß ist "state" immer genau ein Wert und "reading" ein Objekt mit mehreren Werten, richtig? Ist das z.B. gedacht für Sensoren, die Temperatur und Luftfeuchtigkeit aufzeichnen?
Vielleicht kann man das irgendwie in die 'set-cmds' oder den 'stateType' einbauen

[whistler]

Ja, der Smart Home Service ist dafür eigentlich nicht optimiert. Je länger ich darüber nachdenke desto mehr glaube ich, dass das eigentlich ein perfektes Beispiel wäre für einen kleinen custom Service über das SDK. Sagen wir es gibt ein Gerät namens "Robo" im Haushalt und Befehle für "Robo" wären "Schicke Robo ins Wohnzimmer" oder "Robo auf Modus eco" etc. könnte man das vermutlich gut abgrenzen und einen Konflikt mit dem Smart Home Service vermeiden.
Wenn Interesse besteht könnte ich dazu mal ein Beispiel machen. SDK Services sind in Java programmiert, der Code ist aber gut zu lesen mmn
Kriegen wir zum Testen einen FHEM Dummy erstellt?

Das klingt sehr gut. Sicher interessant.

Ich hab anhand des Bespiels mal den Teach Befehl ausgeführt. Zum Testen hab ich einen Dummy angelegt.
Aktuell gibt es scheinbar noch Probleme wenn per stateformat der Status umformatiert wird, manchmal schaltet er trotzdem und manchmal gibt er aus, das er den Status nicht erkennt und nicht schalten kann (z.B. Musikplayer SB_PLAYER / anderes Thema, kann ich seperat nochmal zu schreiben) (Zumindest wenn man im HUB den Powerbutton drückt)

[EDIT]
Ablauf: Schicke den Robo ins Wohnzimmer: Rückfrage 1: Wo ist das Gerät? "Wohnzimmer" / Rückfrage 2: Auf welchen Wert 100
Ich hatte es so verstanden, wenn auch nicht 100% das dein Bespiel, zumindest was fertiges an den Fhem schickt, mal unabhängig davon was im FHem dann passiert.
(Vielleicht hängt das mit deinen gefundenen Bugs zusammen die noch nicht eingecheckt sind) Hast du geplant diese ggf. ins DEV einzuchecken?
Er schickt dann ein vermutlich ein "set Robo 100" an Fhem zumindest ist das der neue state vom Gerät.
(Ist das der noch nicht eingecheckte Bugfix?)

für das stateformat: das sieht bei mir so aus, und sorgt dafür das er den Robo nicht schalten würde, weil er damit nichts anfangen kann.
attr Robo_Control stateFormat Location: state Zähler: garbage_cycle

[EDIT]
Wenn ich das richtig verstehe müsste man aktuell für jeden Raum einen Teachbefehl machen und nicht dynamisch über einen Befehl abfertigen oder?
Schicke Robo in die "Küche"
Schicke Robo ins "Wohnzimmer"
Ich hätte dabei noch folgenden Anwendungsfall
Schicke Robo zum "Esstisch", das wäre doch der Klassiker nach dem Sonntagsfrühstück
(Jetzt ist vermutlich das SDK doch die bessere wahl oder?)

PS: Vielleicht denkbar das man zusätzlich noch ein abweichendes reading für den on/off status definieren kann.
(oder geht das vielleicht sogar schon)

[whistler]

{"value":"device", "found":"Robo", "index":303}

das hat bei mir nicht geklappt dafür dein device;;Robo
(wobei er hier scheinbar den sepia namen und FHEM namen nimmt, gefühlt bei den vielen Kombinationen vom ausprobieren)

Sieht eigentlich korrekt aus. Eventuell muss es kombiniert werden mit 'sepia-set-cmds'. Ich habe im Anhang mal 2 Bilder gemacht, wie es bei mir funktioniert. Allerdings sind mir auch beim Testen noch 2 kleinere Bugs aufgefallen, die ich mittlerweile behoben habe. Könnte also sein, dass du auf die neue Version warten müsstest

Ich hab mal meine Einstellungen angehängt die dann ein "set Robo_Control wohnzimmer" an den Fhem schicken.

Leider wird hier sowohl bei plain als auch dem json auf dem Weg das Wort in lowercase gewandelt.
Und wie im Screenshot zu sehen wird der custom befehl zwar in Fhem gespeichert aber nicht wieder geladen.

PS: Florian, weisst du schon wann es die neue Version mit den zwei Bugfixen gibt, die evtl. hier rein spielen.

Vielen Dank und ein schönes Wochenende.

Gruß
Basti

[sepia]

Hi Basti,

ich habe so ein bisschen den Überblick verloren was aktuell genau geht bei dir und was nicht, aber ich versuche mal auf ein paar Sachen einzugehen
Vielleicht kannst du mir auch noch sagen, wie ich den Dummy reproduzieren kann? ^^

Wenn ich das richtig verstehe müsste man aktuell für jeden Raum einen Teachbefehl machen und nicht dynamisch über einen Befehl abfertigen oder?
Schicke Robo in die "Küche"
Schicke Robo ins "Wohnzimmer"
Ich hätte dabei noch folgenden Anwendungsfall
Schicke Robo zum "Esstisch", das wäre doch der Klassiker nach dem Sonntagsfrühstück
(Jetzt ist vermutlich das SDK doch die bessere wahl oder?)

Hehe der letzte Fall gefällt mir
Man kann Befehle über das Teach-Interface zwar auch etwas dynamischer definieren mit "execute commands", aber zur Zeit nur, wenn man damit einen Befehl ansprechen kann der schon existiert, z.B. der eigene Satz wäre "Prüfe <var1>" und der bekannte Satz "Zeig mir den Status von Sensor 1 im <var1>". Dann wäre das flexibel für alle Räume ("Prüfe Wohnzimmer" z.B.). Im Smarthome Service ist "Room" immer ein Standort, deswegen klappt das damit nicht, aber hätte "Robo" einen eigenen Service wird es flexibel. Der Service für "Robo" könnte vermutlich sehr einfach sein, vielleicht kann ich am Wochenende mal ein Beispiel basteln.

Aktuell gibt es scheinbar noch Probleme wenn per stateformat der Status umformatiert wird, manchmal schaltet er trotzdem und manchmal gibt er aus, das er den Status nicht erkennt und nicht schalten kann (z.B. Musikplayer SB_PLAYER / anderes Thema, kann ich seperat nochmal zu schreiben) (Zumindest wenn man im HUB den Powerbutton drückt)

Der "toggle" Knopf im Control HUB kann tatsächlich nur begrenzt entscheiden was eigentlich passieren soll beim drücken. Er berücksichtigt zwar die "set-cmds" States beim setzen, aber habe gerade noch mal nachgeguckt, er versteht beim lesen nur "on, off, open, closed" und reine Zahlen. Da könnte man eigentlich noch mal nachbessern, wenn "set-cmds" eh schon definiert ist ^^.

Leider wird hier sowohl bei plain als auch dem json auf dem Weg das Wort in lowercase gewandelt

Welches Wort war das genau?
Oh ich sehe im Screenshot gerade das Semikolon muss ein Komma sein im JSON: "{"set":"<val>", "enable":"on", "disable":"off"}
Im Screenshot des Teach-Interfaces fällt mir noch auf, dass die Angabe zum "Room" hier vermutlich falsch ist, denn das ist der Raum in dem Robo_Control gesucht wird, nicht der Zielort.

(Vielleicht hängt das mit deinen gefundenen Bugs zusammen die noch nicht eingecheckt sind) Hast du geplant diese ggf. ins DEV einzuchecken?
[...]
weisst du schon wann es die neue Version mit den zwei Bugfixen gibt, die evtl. hier rein spielen.

Die Bugs in der aktuellen Version haben sicher noch Einfluss auf deine Tests. Die zwei Fixes, die ich letzte Woche erwähnte sind bereits im dev-branch. Zur Zeit arbeite ich noch an Verbesserungen um endlich einen guten "headless" Raspberry Pi Client anbieten zu können. Ziel ist es damit noch vor Februar fertig zu werden, aber vielleicht erzeuge ich schon mal eine Version zum testen der FHEM Änderungen die Tage.

[whistler]

Hallo Florian,

danke für deine Rückmeldung. Ich hab dir jetzt nochmal einen Ablauf geschrieben (Inkl. Bonus für dich am Ende) 

Ich hab mit dem Dummy angefangen und dann die verschiedenen Varianten mit Screenshots dokumentiert.

Es liegt scheinbar am plain mit dem kleinschreiben. Das wort ist egal. Test Wohnzimmer war es bei mir.

Ja der Zielort für das Device der ist an dem Falle identisch, etwas ungeschickt vielleicht. Da kommt mein Beispiel am Ende zur Unterscheidung ja ganz gut.

So wie du Zeit hast. Ich hatte schon einen Workaround gebaut und nachgelagert in notify, was den Robo triggert, den ersten Buchstaben wieder gross geschrieben

Den Headless Client, das wäre was ich hatte schon angefangen mit Chromium, aber da gehts schon los mit dem Mikro zugriff VNC Zugriff etc auf den PI.
Commandozeile wäre ja schon schicker.

Man kann das Teach UI nicht zufällig auch per Skript überfallen, natürlich kann ich die Stelle jetzt suchen gehen, wo es gespeichert wird.
Aber vielleicht muss ich das ja gar nicht. Ich würde also Teach "per Editor" nehmen oder SDK. Vermutlich nicht so gern gesehen ist ja beim Fhem auch so. (Zurecht manchmal)

Der Dummy war bei mir so im Einsatz, daher ging das recht fix. Nicht über die Punkte im Item wandern, er ist vorhin schon mal ein durchs Wohnzimmer gefahren weil ich nicht aufgepasst habe.

Vielen Dank und ein schönes Wochenende und gute Nacht.

PS: Hab gerade nochmal kurz ins Code-UI geschaut, aber dafür ist es nun zu spät.

[whistler]

Hallo Florian,

es hörte sich ein bisschen so als ob du gerne Praxisbeispiele brauchst, was ja auch Sinn macht.
Ich probiere mich gerade an der Kaffeemaschine bei Namen mit Klammerwerten scheitere ich gerade auf die eine sowie andere Schreibweise beim device. Er meldet kein passendes Gerät gefunden.

Daher würde gerne nochmal auf die json Formatierung eingehen.

Ich könnte mir vorstellen, dass sowas z.B. für einen Staubsauger-Roboter Sinn macht :-D ... theoretisch könnte man das mit dem Teach-Interface machen, also man definiert den Satz "Sende Robo ins Wohnzimmer" und dann bei 'smart_device' '{"value":"device", "found":"Robo", "index":303}' und bei 'smart_device_value' '{"value":"Wohnzimmer", "type":"custom"}' ... dann sollte in FHEM "set [device 303] wohnzimmer" ankommen ... müsste ich aber auch noch mal testen ob das so durchläuft.

Fhem Daten:
name AZ_Senseo
sepia-name Kaffeemaschine (Arbeitszimmer)
sepia-room study
sepia-room-index 303
sepia-set-cmds {"number":"brew <val>cup","enable":"ON","disable":"OFF"}
sepia-type coffee_maker


[Edit]
Das mit dem smart_device im teach hatte beim Robo nicht geklappt, aber mit dem <device>;; nimmt er den Namen auch nicht. evtl. wegen der Leerzeichen?
Im Chat direkt funktioniert aber: Kaffeemaschine (Arbeitszimmer) an / Kaffeemaschine (Arbeitszimmer) aus

[Edit2]
Ich habs gefunden, es gibt scheinbar noch einen kleinen Fehler. Sobald ich den Raum auf <livingroom> einstelle im Teach gibt es eine Antwort. Da mein Debugging vom Robo gestern noch an war.
Hatte ich mich beim testen schon gewundert warum ich Meldungen kriege. Soll heissen er schickt dann die Commandos ebenfalls an den Robo. kann ich auch sehen im state kommt auch der angepasste Befehl für die Kaffemaschine dann an. Ich bin gestern über den Manager im Teachmodul gegangen und habe so den Robo mit den Räumen "geklont". Das gleiche mit der Kaffeemaschine.
Aber selbst wenn ich einen neuen Eintrag anlege, will diese unabhängig das <device<;;AZ_Senseo eingetragen ist, auch nach einem Reload und STRG+F5 im Browser den Robo füttern.

Er soll am Ende ein set AZ_Senseo ON / OFF / brew 1cup / brew 2cup an Fhem schicken.

Hab so direkt im Wiki nichts gefunden dazu, lese sonst gerne dort auch nochmal nach.

Vielen Dank.

Gruß
Basti

[whistler]

Hallo Florian,

gute Nachricht ich habs doch selber hinbekommen und es funktioniert.

Fhem Daten:
name AZ_Senseo
sepia-name Kaffeemaschine (Arbeitszimmer)
sepia-room study
sepia-set-cmds {"number":"brew <val>cup","enable":"ON","disable":"OFF"}
sepia-type coffee_maker

Im Teach Modul dann:
<coffee_maker>;;Kaffeemaschine (Arbeitszimmer)
<study>
<set>
{"value":"brew 2cup","type":"custom"}


Wenn der Typ <device> im <livingroom> passt nimmt er scheinbar den ersten den er finden kann.
Diesen führt er dann unabhängig vom Namen der dahinter steht aus.

Man muss als auch in den eckigen klammern korrekt den Typ angeben, was ja Sinn macht.

Irgendwas zum loggen oder so wäre schön, damit man schneller seinen Fehler finden kann.


Ich hatte zwischendurch auch testweise die Dev eingespielt, dabei und danach (auch mit dem normalen Build stand):
- Gabs dann Fehler im Docker bei der Elastic mit Connection Refuse und Java VM Speicherfehler
- Der HUB konnte zwar mit LOAD HUB INFO erreicht werden und auch SEPIA REGISTER ging (neues attr im fhem zum save), aber beim Geräte holen gabs nen Fehler in Rot

Vielleicht kennst du das verhalten in der einen oder anderen Form. Ansich hab ich am Ende nichts anders gemacht


Eine Anmerkung / Idee in den Zusammenhang noch was die Attr Felder angeht:
sepia-set-cmds sepia-name sepia-type sepia-room sepia-room-index sepia-data sepia-mem-state sepia-state-type sepia-set-cmds
->
sepia-name sepia-room:livingroom,diningroom,kitchen,bedroom,bath,study,office,childsroom,garage,basement,garden,shack,hallway,other,unassigned sepia-type:light,heater,tv,music_player,fridge,oven,coffee_maker,roller_shutter,power_outlet,sensor,device,other,hidden sepia-room-index sepia-data sepia-mem-state sepia-state-type sepia-set-cmds

die Auflistung hatte ich mir aus deinen sourcen mal zusammen kopiert und muss sie bei mir natürlich jedes mal überschreiben.
Dann kann man im fhem bei den Attributen bequem per Auswahlliste die Räume etc. setzen.

Vielleicht wäre das aber allgemein praktisch.

- sepia-set-cmds war bei mir nach dem letzten SEPIA REGISTER doppelt drin. Vielleicht vom ganzen Testen.

Gruß
Basti

[sepia]

Hi Basti,

danke für die ganzen Tests und neuen Infos
Mal gucken was ich ad-hoc beantworten kann ^^

Es liegt scheinbar am plain mit dem kleinschreiben. Das wort ist egal. Test Wohnzimmer war es bei mir.

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

Den Headless Client, das wäre was ich hatte schon angefangen mit Chromium, aber da gehts schon los mit dem Mikro zugriff VNC Zugriff etc auf den PI.
Commandozeile wäre ja schon schicker.

Die aktuelle "headless" Version nutzt immer noch den Chromium, da es momentan zu lange dauern würde einen komplett neuen Python/Node.js/etc. Client zu bauen und dieser auch nicht alle Feature anbieten könnte. Allerdings habe ich es so gelöst, dass man über den SEPIA Control HUB eine Art "terminal" bekommt mit dem man Befehle an den Client schicken kann und States als Events bekommt. Ich denke das wird ganz nett, wenn es fertig ist 

Man kann das Teach UI nicht zufällig auch per Skript überfallen, natürlich kann ich die Stelle jetzt suchen gehen, wo es gespeichert wird.
Aber vielleicht muss ich das ja gar nicht. Ich würde also Teach "per Editor" nehmen oder SDK. Vermutlich nicht so gern gesehen ist ja beim Fhem auch so. (Zurecht manchmal)

Zur Zeit nicht ^^. Im Grunde nutzt der Client ja nur die APIs des Teach-Servers und man könnte sicherlich etwas bauen, was Befehle aus einer Text-Datei importiert oder einer Kommandozeile, aber das wäre auf der Prio-Liste eher unten angesiedelt zur Zeit ^^. Wobei ... es gibt da vielleicht doch was. Der Assist-Server liest beim Start Befehle ein aus den Dateien in "SEPIA/sepia-assist-server/Xtensions/Assistant/commands/*" z.B. "teachIt_de.txt" für Deutsch. Das Format ist etwas eigen aber im kompatibel mit dem was das Teach-UI erstellt. Z.B. is dort der Befehl für "Uhrzeit" definiert als (User Text;; p1=...;; p2=...;; ...):

Code Auswählen Erweitern

Wieviel Uhr ist es;;  command=chat;;  reply=Es ist <local_time_hhmm> Uhr;;

er ist vorhin schon mal ein durchs Wohnzimmer gefahren weil ich nicht aufgepasst habe.

es hörte sich ein bisschen so als ob du gerne Praxisbeispiele brauchst

Immer gerne :-D Das hilft vor allem auch um eventuelle Workarounds zu finden

Ich habs gefunden, es gibt scheinbar noch einen kleinen Fehler. Sobald ich den Raum auf <livingroom> einstelle im Teach gibt es eine Antwort. Da mein Debugging vom Robo gestern noch an war. Hatte ich mich beim testen schon gewundert warum ich Meldungen kriege. Soll heissen er schickt dann die Commandos ebenfalls an den Robo. kann ich auch sehen im state kommt auch der angepasste Befehl für die Kaffemaschine dann an. Ich bin gestern über den Manager im Teachmodul gegangen und habe so den Robo mit den Räumen "geklont". Das gleiche mit der Kaffeemaschine.
[...]
Wenn der Typ <device> im <livingroom> passt nimmt er scheinbar den ersten den er finden kann.
Diesen führt er dann unabhängig vom Namen der dahinter steht aus.

Hab ich das richtig verstanden, er hat den Robo getriggert obwohl er eigentlich die Kaffeemaschine triggern sollte weil beide vom Typ "device" waren bzw. in dem Teach-UI als "device" versucht wurden anzusprechen?
Generell ist die Logik so:

• Wenn der User sagt "Gerät an" und es gibt nur 1 im ganzen System, dann wird das genommen
• Wenn der User sagt "Gerät an" und es gibt mehrere in verschiedenen Zimmern, dann wird nach dem Zimmer gefragt
• Wenn der User sagt "Gerät an" und es gibt mehrere in dem selben Zimmer, dann ... bin ich gerade nicht sicher . Es könnte sein, dass dann das erste gewählt wird. Ein Vergleich des Namens findet nicht statt.

Punkt 3 war bei dir der Fall? In dem Kontext wäre das definitiv ein Bug Es könnte auch Punkt 1 gewesen sein, d.h. "Device" wurde aktiviert weil es das einzige war im System (Kaffeemaschine war ja coffee_maker).

Man muss als auch in den eckigen klammern korrekt den Typ angeben, was ja Sinn macht.

Ja, das ist in jedem Fall nötig, sprich ein Gerät kann nur gefunden Werden wenn der Typ übereinstimmt, der Name ist dann egal.

Irgendwas zum loggen oder so wäre schön, damit man schneller seinen Fehler finden kann.

Ein Log Eintrag der z.B. den FHEM "set" Befehl zusammen mit dem SEPIA Device Objekt anzeigt (und ggf. dem User Input)? Vielleicht könnte ich ein Smart Home Log-Level in die Config einbauen.

Ich hatte zwischendurch auch testweise die Dev eingespielt, dabei und danach (auch mit dem normalen Build stand):
- Gabs dann Fehler im Docker bei der Elastic mit Connection Refuse und Java VM Speicherfehler
- Der HUB konnte zwar mit LOAD HUB INFO erreicht werden und auch SEPIA REGISTER ging (neues attr im fhem zum save), aber beim Geräte holen gabs nen Fehler in Rot
Vielleicht kennst du das verhalten in der einen oder anderen Form. Ansich hab ich am Ende nichts anders gemacht

Hmm komisch, an der Elastic wurde eigentlich nichts geändert, aber in den GitHub Issues scheint es einen User mit ähnlichem Fehler zu geben. Für die nächste Version mache ich einen neuen Docker Container und teste das alles mal durch mit Smart Home.

sepia-name sepia-room:livingroom,diningroom,kitchen,bedroom,bath,study,office,childsroom,garage,basement,garden,shack,hallway,other,unassigned sepia-type:light,heater,tv,music_player,fridge,oven,coffee_maker,roller_shutter,power_outlet,sensor,device,other,hidden sepia-room-index sepia-data sepia-mem-state sepia-state-type sepia-set-cmds

die Auflistung hatte ich mir aus deinen sourcen mal zusammen kopiert und muss sie bei mir natürlich jedes mal überschreiben.
Dann kann man im fhem bei den Attributen bequem per Auswahlliste die Räume etc. setzen.

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?

Grüße!

[whistler]

Hi Florian,

dann versuche ich mal zu antworten.

Ist das aktuell noch ein Problem? Wenn die Befehle aus dem "set-cmds" Objekt kommen, sollten die eigentlich nicht verändert werden.

Ich kann es nicht mehr reproduzieren, gerade beim testen wurde es sowohl mit <plain>;;Test korrekt geschrieben als auch {"value":"Test","type":"custom"}

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

Zum Thema gross Kleinschreibung bei ON OFF / on off kann ich zumindest sagen, das z.B. Tasmota und MQTT Devices gerne ON OFF als set nutzt, das kann man dann zwar per Eventmap umbiegen, aber ich weiss gerade nicht ob es so gut ist, das du ON OFF immer on lower umwandelst. beliebt wäre in dem Zusammenhang noch toggle.

Die aktuelle "headless" Version nutzt immer noch den Chromium, da es momentan zu lange dauern würde einen komplett neuen Python/Node.js/etc. Client zu bauen und dieser auch nicht alle Feature anbieten könnte. Allerdings habe ich es so gelöst, dass man über den SEPIA Control HUB eine Art "terminal" bekommt mit dem man Befehle an den Client schicken kann und States als Events bekommt. Ich denke das wird ganz nett, wenn es fertig ist 

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.

Zur Zeit nicht ^^. Im Grunde nutzt der Client ja nur die APIs des Teach-Servers und man könnte sicherlich etwas bauen, was Befehle aus einer Text-Datei importiert oder einer Kommandozeile, aber das wäre auf der Prio-Liste eher unten angesiedelt zur Zeit ^^. Wobei ... es gibt da vielleicht doch was. Der Assist-Server liest beim Start Befehle ein aus den Dateien in "SEPIA/sepia-assist-server/Xtensions/Assistant/commands/*" z.B. "teachIt_de.txt" für Deutsch. Das Format ist etwas eigen aber im kompatibel mit dem was das Teach-UI erstellt. Z.B. is dort der Befehl für "Uhrzeit" definiert als (User Text;; p1=...;; p2=...;; ...):

Code Auswählen Erweitern

Wieviel Uhr ist es;;  command=chat;;  reply=Es ist <local_time_hhmm> Uhr;;

Hab ich gefunden Naja vielleicht nur Gewöhnungssache Dabei hätte ich noch einen Featurewunsch:

Code Auswählen Erweitern

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?

Ich hab gerade verschiedene Ideen, aber erstmal warte ich auf eine generelle Rückmeldung zu der Idee.

Hab ich das richtig verstanden, er hat den Robo getriggert obwohl er eigentlich die Kaffeemaschine triggern sollte weil beide vom Typ "device" waren bzw. in dem Teach-UI als "device" versucht wurden anzusprechen?
Generell ist die Logik so:

• Wenn der User sagt "Gerät an" und es gibt nur 1 im ganzen System, dann wird das genommen
• Wenn der User sagt "Gerät an" und es gibt mehrere in verschiedenen Zimmern, dann wird nach dem Zimmer gefragt
• Wenn der User sagt "Gerät an" und es gibt mehrere in dem selben Zimmer, dann ... bin ich gerade nicht sicher . Es könnte sein, dass dann das erste gewählt wird. Ein Vergleich des Namens findet nicht statt.

Punkt 3 war bei dir der Fall? In dem Kontext wäre das definitiv ein Bug Es könnte auch Punkt 1 gewesen sein, d.h. "Device" wurde aktiviert weil es das einzige war im System (Kaffeemaschine war ja coffee_maker).

Ja, das ist in jedem Fall nötig, sprich ein Gerät kann nur gefunden Werden wenn der Typ übereinstimmt, der Name ist dann egal.

Es war auf jedenfall Tricky und es gibt folgende Geräte:
device garden Pumpe
device livlingroom Robo_Control
coffee_maker study Kaffeemaschine (Arbeitszimmer)
coffee_maker kitchen Kaffeemaschine (Küche)

device livingroom -> matched -> Robo (OK)
device study -> machted -> Sorry kein passendes Gerät gefunden (OK)
coffee_maker livingroom -> matched -> kein passendes Gerät gefunden (OK)

Also es gibt mindestens noch ein zweites device aber im garten nämlich die Pumpe. Heisst Punkt 1 kann eigentlich nicht zutreffen. Aber hat er trotzdem genommen.
bzw. 1 Gerät im livingroom da wäre der match mit raumangabe.

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.

Ein Log Eintrag der z.B. den FHEM "set" Befehl zusammen mit dem SEPIA Device Objekt anzeigt (und ggf. dem User Input)? Vielleicht könnte ich ein Smart Home Log-Level in die Config einbauen.

Zumindest hätte ich dann vermutlich recht schnell gesehen was er macht Vielleicht würde auch schon das Log im ersten Schritt reichen,
wo er dann am Ende bei Welcher Wert? bzw. Welches Gerät? oder kein passendes Gerät gefunden auskommt. Entsprechend der Chatausgabe.

Hmm komisch, an der Elastic wurde eigentlich nichts geändert, aber in den GitHub Issues scheint es einen User mit ähnlichem Fehler zu geben. Für die nächste Version mache ich einen neuen Docker Container und teste das alles mal durch mit Smart Home.

Also vorgehen ist (läuft per Skript durch, daher passiert immer das gleiche):

• Dein Build Skript mit dev laufen lassen
• dann Docker stoppen
• sepia.*.jar files löschen damit die alten files weg sind (ist aber egal ob mir oder ohne)
• ZIP entpacken in den SEPIA Ordner (ohne die custom.properties files)
• Besitzer und Rechte setzen
• docker starten (hier kommt kommen dann die drei dienste mit einem Fail hoch auch zwischendurch beim normalen build) das ganze macht man 5 mal hintereinander davon klappt es dann einmal

Ich war froh als er wieder lief Die Java Version müsste auch mal aktualisiert werden.

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.


Viele Grüße