Amazon-Echo Logikbaustein

[golfsierra]

Noch eine Zusatzfrage ... Kann ich auch einen Taster simulieren? Ich habe einen Aktor, der Parallel zum Taster für das Garagentor hängt. Dieser wird vom QuadClient über eine TASTER-Funktion (Adresse a/b/c) ausgelöst. Bliebe der Aktor dauernd auf "1" so würde das Tor nie wieder zugehen. Das Tor schließt nach einer bestimmten Zeit automatisch wieder.

Über einen Custom Skill würde ich nun gerne "Alexa, sage ???, öffne das Garagentor" sagen.

Hier taucht wieder das Problem auf, dass bei on/off Objekten die Wortwahl wieder nicht stimmen wird (nicht EIN sondern ÖFFNE) und dass ich nicht weiß, wie ich das am Besten im HomeServer löse. Eventuell über eine Hilfsvariable?

ich nehme die Hilfsvariable x/y/z, die ich mit Alexa als "on only" verknüpfe. Wird der Wert "1", so startet in der Logik die Treppenhausfunktion, die nach 1 Sekunde sowohl a/b/c als auch die Hilfsvariable x/y/z wieder auf NULL setzt. Was sagt ihr dazu? Habt ihr bessere Ansätze?

Danke für Unterstützung
Gert

[wernerL]

Hallo Gert,

zu Problem 1)
Im "Interaction Model" habe ich für die Standardfälle die mir eingefallen sind (Beleuchtung, Öffnungsmelder, Wetterstation, Pool) die entsprechenden "Intent Schema" und "Sample Utterances" definiert. Um zu diesen Standardfragen die richtigen Formulierungen in den Antworten zu generieren habe ich teilweise Dinge eingebaut (z.B.: das Property-Mapping) die man sicher besser hätte lösen können/müssen. Wie ich jetzt leider feststelle, ist auch die Erweiterung für "Spezialfälle" nicht so ohne weiteres möglich. Du bekommst zwar jetzt vom Custom-Skill einen Wert geliefert (offen/geschlossen) aber die Formulierung der Antwort passt aber überhaupt nicht zu deiner Frage.
Ich fürchte das paßt weder zu ENUM_DOOR_WINDOW noch zu ENUM_PROPERTY.

Zur Lösung des Problems gibt es mehrere Ansätze (welcher hiervon der "richtige Weg" sein könnte muss ich allerdings noch genauer überlegen). Vielleicht hat der ein oder andere von euch diesbezüglich eine Idee oder Meinung?

Ansatz 1: Man könnte das ENUM_SWITCH_VALUE allgemeiner z.B.: als ENUM_STATE_VALUE (für boolsche also 0/1 Werte) definieren, und hier die Möglichkeit bieten andere Stati wie z.B.: belegt, besetzt, frei, ... aufzunehmen. In der Lambda-Funktion müsste man dann entsprechende Mappings aufbauen um die entsprechenden Antworten zu generieren. Bzw. man erweitert die Möglichkeit bei der Formatierung des Wertes über das "unit":"" Attribut um die entsprechenden Wörter für 0/1 also "frei"/"belegt" vorzugeben.

Ansatz 2: Ein weiteres Intent Schema für Belegt/Frei mit den entsprechenden ENUM's und "Sample Utterances" aufzunehmen macht denke ich keinen Sinn, da man damit X-Spezialfälle einbauen müsste.

Ansatz 3: Man versucht das Problem über das "text":"X/X/X" Attribut zu lösen. D.h. die Formulierung wird in einem 14-byte Textobjekt auf dem Homeserver bereit gehalten. Aktuell arbeiten die Abfragen auf das Textattribut allerdings nur mit den Formulierungen:

• Wie ist der Status {Article} {Appliance} {Praeposition} {Room}
• Wie der Status {Praeposition} {Room} {Article} {Appliance} ist
• Gib mir einen Statusbericht {Article} {Appliance} {Praeposition} {Room}
• Gib mir einen Statusbericht {Praeposition} {Room}
• nach dem Statusbericht {Article} {Appliance} {Praeposition} {Room}
• nach dem Statusbericht {Praeposition} {Room}

D.h. wenn du im Homserver über den Ultraschallsensor an der Decke ein 14-byte Textobjekt entsprechend belegst, solltest du z.B. Alexa folgendermaßen fragen können:
Alexa, frag ??? Wie ist der Status des Parkplatz in der Tiefgarage. Man könnte natürlich darüber nachdenken evtl. so eine Art Fallback Mechanismus auf das "text" Attribut zu machen wenn kein "value" Attribut gefunden wurde. Allerdings kann ich die daraus resultierenden Seiteneffekte aktuell nicht abschätzen.

zu Problem 2)
Hier würde ich definitiv auf das "text":"X/X/X" Attribut gehen. Evtl. kann man die Formulierungen entsprechend anpassen bzw. erweitern.

zu Problem 3)
Ich kann mich nicht daran erinnern irgendetwas spezielles gemacht zu haben, damit die Anfragen im Verlauf auftauchen. Ich kann es mir zwar eigentlich nicht vorstellen, aber könnte es etwas mit einer Ländereinstellung (Österreich) zu tun haben?

Frage an die anderen Benutzer des Logikbausteins: Werden Smart-Home Skill Anfragen bei euch im Verlauf aufgeführt?

Viele Grüße
Werner

[wernerL]

Noch eine Zusatzfrage ... Kann ich auch einen Taster simulieren

Ich bin jetzt nicht der Homeserver-Logik Profi, aber ich würde auch versuchen, dass über die Treppenhausfunktion zu lösen.
Um beim Custom-Skill allerdings "öffne" sagen zu können, müsste ich den Custom-Skill noch erweitern.

Gruß Werner

[golfsierra]

zu Problem 1)
Im "Interaction Model" habe ich für die Standardfälle die mir eingefallen sind (Beleuchtung, Öffnungsmelder, Wetterstation, Pool) die entsprechenden "Intent Schema" und "Sample Utterances" definiert. Um zu diesen Standardfragen die richtigen Formulierungen in den Antworten zu generieren habe ich teilweise Dinge eingebaut (z.B.: das Property-Mapping) die man sicher besser hätte lösen können/müssen. Wie ich jetzt leider feststelle, ist auch die Erweiterung für "Spezialfälle" nicht so ohne weiteres möglich. Du bekommst zwar jetzt vom Custom-Skill einen Wert geliefert (offen/geschlossen) aber die Formulierung der Antwort passt aber überhaupt nicht zu deiner Frage.
Ich fürchte das paßt weder zu ENUM_DOOR_WINDOW noch zu ENUM_PROPERTY.

Frage: Was wäre, wenn ich für diese Abfrage einen eigenen Skill mit eigenem Wording mache? Geht das einfacher?
Dann frage ich Lampen mit "Alexa, frage HomeServer ...." und den Parkplatz mit "Alexa, frage Tiefgarage ..." ab.
Wenn der Custom Skill nur auf belegt/frei reagieren muss kann man ja vielleicht da leichter "hardcoded" eine Lösung finden ...
Dann könnte ja "Alexa, frage TIEFGARAGE ob der Parkplatz belegt ist" eine bessere Antwort bringen.

Leider ist mir aber beim Custom Skill übrigens aufgefallen, dass immer ROOM UND APPLIANCE angegeben werden müssen. Stimmt das?

"Alexa, frage ??? ob der Parkplatz in der Tiefgarage belegt ist" FUNKTIONIERT
"Alexa, frage ??? ob der Parkplatz belegt ist" FUNKTIONIERT NICHT

Somit wird "Alexa, frage TIEFGARAGE ob der Parkplatz belegt ist" wohl aus nicht funktionieren ...

Ich lasse das "Projekt Parkplatzbelegung" nun mal ruhen und warte, ob die Experten da eine Lösung finden. Meine Kenntnisse reichen da leider nicht mehr aus.

zu Problem 2)
Hier würde ich definitiv auf das "text":"X/X/X" Attribut gehen. Evtl. kann man die Formulierungen entsprechend anpassen bzw. erweitern.

Nun ich habe mal geändert (UseableBattery ist ein INTERNES 14-Byte KO):

{"name":"Batterie", "text":"UseableBattery"}

Aber wie rufe ich nun korrekt auf?
"Alexa, frage ??? wie ist der Wert der Batterie in der Tiefgarage?"
"Alexa, frage ??? wie ist der Status der Batterie in der Tiefgarage?"
"Alexa, frage ??? wie ist der Inhalt der Batterie in der Tiefgarage?"

Ich bekomme auch im TEST immer folgende Fehlermeldungen:
<speak> Ich konnte den Statusbericht nicht abfragen, weil bei der Anfrage für der batterie in der tiefgarage ein Fehler zurückgemeldet wurde. Das in der JSON-Konfiguration angegebene KNX-Objekt UseableBattery wurde nicht gefunden. </speak>"

Da sich das KO in einem Unterordner befindet habe ich auch versucht Pfadangabe zum Objekt zu probieren. Ergebnis:

<speak> Ich konnte den Statusbericht nicht abfragen, weil bei der Anfrage für der batterie in der tiefgarage ein Fehler zurückgemeldet wurde. Das in der JSON-Konfiguration angegebene KNX-Objekt Auto/Charging/UseableBattery wurde nicht gefunden. </speak>"



LG Gert

[wernerL]

Hallo Gert,

zu Problem 1) Ich schaue mal was ich machen kann.

zu Problem 2) Um ein internes KO-Objekt in der JSON-Konfiguration verwenden zu können, musst du diesem im Gira-Experten eine "Homeserver interne Gruppenadresse" geben. Hierzu gibt es das im Gira Experten unter Kommunikationsobjekte -> Intern -> das Eingabefeld Gruppenadresse.
Irgendwo in der Doku steht, welche Adressbereiche für die Haupt-/Mitttelgruppe/0-255 hier zulässig sind. Ist die Adresse ungültig wird diese rot dargestellt.
Ich habe bei mir z.B.: "100/0/0-255" im Einsatz.

Gruß Werner

[golfsierra]

Um ein internes KO-Objekt in der JSON-Konfiguration verwenden zu können, musst du diesem im Gira-Experten eine "Homeserver interne Gruppenadresse" geben

Okay, genau das war meine Frage vor einigen Tagen. Mit der Gruppen Adresse funktioniert es natürlich.
auf die Frage " Alexa, frage ??? Wie ist der Status der Batterie in der Tiefgarage? Liefert Sie z.B. "72" als Antwort. So weit so gut

Nur wie manage ich es nun, dass sie mit " Der Ladestand deiner Batterie beträgt 72 %" antwortet?
Noch besser wäre es natürlich, wenn Sie die Antwort gleich mit einem zweiten Parameter Verknüpfung würde. Ich habe im Bus ja auch das KO für die Reichweite.Mein Wunsch wäre es nun eine Antwort wie diese zu hören: " Der Ladestand deiner Batterie beträgt 72 %. Das entspricht einer Reichweite von 143 Kilometern."

Ich will also nicht den Status eines einzelnen Objekts, sondern den Status einer ganzen Gruppe abfragen und Alexa soll die passenden Füllworte dazwischen einfügen. Im Prinzip möchte ich das erreichen, was dieser i3 Fahrer mit seinem BMW geschafft hat: https://mobile.twitter.com/i3fahrer/...92880907935745

LG Gert

[golfsierra]

Hallo Werner,
also ich habe jetzt einen Trick gefunden mein Problem mit dem Elektroauto zu lösen. Ich setze die gesamten Informationen am HomeServer als Text zusammen und lasse Alexa dann eigentlich nur diesen Text des KOs "vorlesen". Klappt eigentlich ganz gut!

eine Sache verwirrt mich aber noch:

{"room":"Elektroautp", "appliances":[
{"name":"Ladung", "text":"x/y/z", "aliases":["Batterie", "Reichweite"]}
]},

Frage ich: "Alexa, frage ??? wie ist der Status der Ladung von Elektroauto?" kommt eine astreine Antwort.

Frage ich: "Alexa, frage ??? wie ist der Status der Reichweite von Elektroauto?" meckert Alexa und meint: "ich konnte den Statusbericht nicht abfragen, weil ich DER Reichweite von Elektroauto nicht finden konnte"

Also probiere ich es ohne Artikel: "Alexa, frage ??? wie ist der Status Reichweite von Elektroauto?" Nun meckert Alexa und meint: "ich konnte den Statusbericht nicht abfragen, weil ich DIE Reichweite von Elektroauto nicht finden konnte"

Batterie und Reichweite sind jedoch sowohl in den Slottypes angelegt im Skill als auch als KNX Geräte im Dot hinzugefügt worden. Kann man bei Objekten vom Typ "text:x/y/z" keine Aliase verwenden? Nur bei Schaltobjekten? Das wäre nämlich sehr schade ...

LG Gert

[wernerL]

Guten Morgen Gert,

Okay, genau das war meine Frage vor einigen Tagen

Bei deiner Frage zu den internen KO's habe ich wohl dein Problem nicht richtig verstanden.
Nachdem ich in den Beispielen immer mit "X/X/X" gearbeitet habe, kam ich leider nicht auf die Idee dies noch genauer zu erklären - sorry.

... ich habe jetzt einen Trick gefunden ...

Wie ich sehe, hätte ich diesen Punkt auch genauer beschreiben müssen. Denn genau so, muß das "text"-Attribut verwendet werden.
Der Homeserver baut die gesamte Antwort zusammen und Alexa liest den Text 1:1 vor.

Kann man bei Objekten vom Typ "text:x/y/z" keine Aliase verwenden?

Doch kann man schon. Wichtig ist hierbei allerdings darauf zu achten, dass bei Aliasnamen der Raum/Bereich nicht implizit vorangestellt wird, und dass die verwendeten Subjektnamen auch in den Enum's "ENUM_APPLIANCE", und "ENUM_ROOM" hinterlegt sind.

zu deiner JSON-Konfiguration und deinen Formulierungen:

{"room":"Elektroauto", "appliances":[
  {"name":"Ladung", "text":"x/y/z", "aliases":["Batterie", "Reichweite"]}
]}

Durch dieses JSON-Fragment definierst du einen Raum/Bereich="Elektroauto" und drei Geräte/Objekte nämlich "Ladung", "Batterie", "Reichweite".
Hinweis: Nachdem der Wert in "room" immer dem Wert in "name" vorangestellt wird, ist das Objekt "Ladung" gewissermaßen im Raum/Bereich "Elektroauto" definiert.
Um das Sprachkommando möglichst gut zu erkennen sollte:

• in der Auflistung ENUM_ROOM der Wert "Elektroauto" enthalten sein.
• in der Auflistung ENUM_APPLIANCE die Werte "Ladung", "Batterie", "Reichweite"

Formulierung: wie ist der Status der Ladung von Elektroauto?
passt perfekt zu: GetText Wie ist der Status {Article} {Appliance} {Praeposition} {Room}

Formulierung: wie ist der Status der Reichweite von Elektroauto?
passt eigentlich perfekt zu: GetText Wie ist der Status {Article} {Appliance} {Praeposition} {Room}

Das Problem ist jedoch, die Reichweite ist zwar als Alias unter dem Bereich Elektroauto definiert, aber für Aliase wird der Raum/Bereich nicht implizit dem Alias vorangestellt.
Die Reichweite ist also sozusagen global definiert und somit nur ohne den Bereich also mit dem Sprachkommando "Wie ist der Status der Reichweite" abfragbar.
Um mit deiner Formulierung abzufragen, müsstest du den Alias von "Reichweite" auf "Elektroauto Reichweite" umstellen.
Aber nicht vergessen danch die JSON-Konfiguration neu "hochzuladen" und die Suche nach KNX-Objekten durchzuführen.

Ich weiß, das ist nicht einfach zu verstehen und 100% glücklich bin ich damit auch nicht.

Allgemeiner Tipp bei solchen Fehlern: Falls man es sich technisch zutraut, ist es hilfreich bei diesen Fehlern in das Cloudwatch-Log der Lambda-Funktion zu schauen.

Allgemeine Hinweise zur Sprachproblematik:
Der nachfolgende Teil ist leider etwas technisch, aber ich hoffe ich habe es einigermaßen verständlich erklärt.

Die Komplexität bei dem Ganzen ist einfach ein gewisses maß an "Natursprachlichkeit" hinzubekommen.
Das beginnt beim Erkennen des Sprachkommandos mit dessen vielzahl an möglichen Formulierungen
und endet beim "Zusammenbauen" der passenden Formulierung als Antwort.

Der Ablauf ist hierbei folgender:

• Alexa "analysiert" das Sprachkommando und versucht mittels des Custom-Skills die eigentliche Absicht (Intent) und die dazugehörigen Parameter zu ermitteln und liefert diese dann an die Lambda-Funktion
• die Lambda-Funktion versucht mittels der Parameter ein in der JSON-Konfiguration definiertes Objekt zu lokalisieren
• konnte das Objekt gefunden werden, wird das Kommando weiter an den Logikbaustein gesendet
• der Logikbaustein setzt das Kommando um, führt also die Wertänderung oder die Wertabfrage durch und sendet das Ergebnis an die Lambda-Funktion zurück
• die Lambda-Funktion baut die Formulierung der Antwort zusammen. Hierzu benutzt sie einen kleinen Trick. Es werden nämlich, der bei der Anfrage verwendete Artikel und die Präposition als zusätzliche Parameter an die Lambda-Funktion übergeben. Diese werden ausschließlich für den Versuch verwendet, die korrekt Formulierung der Antwort zu generieren. Dieser Trick kann aber nicht über das Problem hinwegtäuschen, dass die Lambda-Funktion leider kein deutsch kann. Böse Stimmen mögen behaupten, dass auch der Entwickler, nachdem dieser aus Bayern kommt, kein deutsch kann aber lassen wir das.

Dieser Ablauf wurde allerdings durch die Einführung des "text"-Attributes ein wenig aufgeweicht: Hier muss die Formulierung der Antwort komplett vom Homeserver gemacht werden.

Aktuell sind im Custom-Skill folgende "Intents" also Absichten definiert:

• DiscoverAppliances (für die Suche nach KNX-Objekten)
• GetValue (zur Abfrage des "value":"" Attributes)
• GetCountValue (zur Abfrage des "value":"" Attributes unter der Interpreation, dass es sich um einen Zähler handelt)
• GetOnOffValue (zur Abfrage des "onOff":"" Attributes)
• GetPercentValue (zur Abfrage des "percent":"" Attributes)
• GetDoorWindowState (zur Abfrage des "value":"" Attributes unter der Interpreation, dass es sich um einen Tür/Fenster Status handelt)
• GetText (zur Abfrage des "text":"" Attributes)
• SetOnOffValue (zur Wertänderung des"onOff":"" Attributes)
• SetPercentValue (zur Wertänderung des"percent":"" Attributes)

Für jede dieser Absichten werden zusätzlich "Sample Utterances" also Mustersätze hinterlegt. z.B.:...

• GetValue Wie ist {Article} {Property} {Praeposition} {Room}
• GetValue Wie ist {Article} {Appliance} {Praeposition} {Room}
• GetText Wie ist der Status {Article} {Appliance} {Praeposition} {Room}

Mit Hilfe dieser Mustersätz und den dazugehörigen Werten in den "Custom Slot Types" also den ENUM-Aufzählungen, versucht Alexa das Sprachkommando zu "matchen".
Wie an den drei Mustersätzen schon erkennbar ist, unterscheiden sich die Formulierungen zum Teil nur marginal.
Dies führt jetzt leider zum Teil dazu, dass Formulierungen welche auf die Abfrage eines "text"-Attributes gehen sollten, in wirklichkeit das "value"-Attribut abfragen, was dann zu einem Fehler führt. Dazu kommt natürlich immer noch die Problematik, was Alexa tatsächlich überhaupt verstanden hat.

Viele Grüße
Werner

P.S.: Da hat es sich Amazon mit der aktuellen Implementierung des Smart-Home Skill leicht gemacht, bis auf den einen fixen Satz bei der Veränderung der Raumtemperatur bekommt man immer nur "Okay".

[golfsierra]

Danke für die ausführliche Erklärung. Prinzipiell habe ich es eh so verstanden. Einige Details waren für mich interessant und neu. Dass der "value" Wert auch als Zähler verwendet werden kann war mir so nicht bewusst und eröffnet mir schon wieder neue "Spielereien".
Ich nehme mal an die INTERPRETATION hängt von der Definition des KOs ab? Also wenn 1-Bit dann ein Fenster (offen/geschlossen), was ja eben aktuell das Problem bei meinen Parkplätzen ist und wenn 8- oder 16-Bit dann als Zähler (zum Beispiel wieviele Fenster offen sind)
werde ich gleich nach der Arbeit probieren ...

das bringt mich jetzt aber auf die Idee, das "der Parkplatz ist offen"-Problem auch über ein Textattribute zu lösen. Dann hast DU weniger Arbeit und ich kann mir den Text komplett frei zusammenstöpseln ...

und du glaubst wirklich, dass Bayern schlechter Deutsch sprechen als wir Oberösterreicher?

LG Gert

[wernerL]

Na ja,

ich fürchte das wir beide nicht gerade den Ruf haben besonders Hochdeutsch zu sprechen .

LG Werner

[JuergenK]

Erstmal Lob. Tolles Konzept.!!

Ich steh aber grad leider etwas am Schlauch: Ich versuch mal die Grundfunkion aufzubauen und bekomme leider im Debug (HS) immer wieder die folgende Meldung (einfacher ein/aus Befehl). Er versteht anscheinend "turnOn" nicht:

2017-02-01 11:27:53 | ERROR Control: unsupported operation 'turnOn' for appliance with id='1_1'. (messageId='xyz')

Woran kann das liegen?

Juergen

[wernerL]

Hallo Jürgen,

erstmal Danke für dein Lob.

Die Request-Parameter sind nicht korrekt. Zum Einschalten muss der Request so aussehen:
https://XXX.XXX.XXX:XXXX/control?app...d=1_1&request=TurnOnRequest&accessToken=XXXXXXXXXXXXX&messageId=xyz

Der Logikbaustein hat scheinbar folgendes empfangen:
https://XXX.XXX.XXX:XXXX/control?app...d=1_1&request=turnOn&accessToken=XXXXXXXXXXXXX&messageId=xyz

Habe ich da noch einen Fehler in der Doku im Wiki?

Viele Grüße
Werner

[JuergenK]

Dane Werner, ja, das wars - mein Fehler

[Hilli]

Hallo,
ich habe gestern Nachmittag angefangen die Verbindung vom Homeserver zur Alexa einzurichten! Bis zum Punkt 2.3.1 Test der AWS Anbindung hat alles gut funktioniert, nun hänge ich leider etwas. Die Funktion in AWS Lambda wurde eingerichtet. So wie ich die Github Anleitung verstanden habe soll man nun ein Test-Event kein kopieren zum testen, siehe Screenshots, dann bekomme ich aber nur die Meldung wie in Bild 3! Das kann doch so nicht richtig sein, oder?
Das schalten der Lichter über den Browser mit https funktioniert bereits!
Kann mir jemand einen Tipp geben!
Gruß Joachim


AWS Lambda-Frage_1.pngAWS Lambda-Frage_2.pngAWS Lambda-Frage_3.png

[wernerL]

Hallo Joachim,

du hast leider das Test-Event an der falschen Stelle rein kopiert. Du hast nämlich gerade den Code der Lambda-Funktion mit dem Test-Event ersetzt.
Lade das ZIP-File GiraHS_V0.3.zip nochmal hoch. Also bei "Code Entry Type" -> Upload a .ZIP File ...
Nachdem du die Lambda-Funktion wieder hochgeladen hast, rufe Actions -> Configure Test-Event auf.
In dem sich öffnenden Fenster ersetze den vorhandenen Text durch das gewünschte Test-Event und klicke auf "Save and test"

Viele Grüße
Werner