Alexa Custom Skill für EDOMI (LBS 19000646 und 19000647)

[jonofe]

ja würde ich machen. Kannst du denn deinen Server von außen per HTTPS erreichen? Dann müsstest du ja sehen, ob es eine SSL Warnung gibt.

[Jurkoe]

Wenn ich die dyndns eingeben dann kommt die nginx welcome homepage und bei Eingabe von dyndns/edomi/ kommt folgende Fehlermeldung:
Unbenannt.PNG
Gehe davon aus, dass das korrekt ist.

LG Eneriko

[Jurkoe]

Hallo André, nur zur Info. Habe den Webserver nginx neu aufgesetzt und dann hat es funktioniert.
LG Eneriko

[Wingfighter]

sieht für mich so aus als hätten die beiden Timestamps eine unterschiedliche Auflösung. der zweite Timestamp hat 3 Stellen mehr als der current timestamp. Muss ich mir mal im Sourcecode anschauen. Ggf hat Amazon da was in der API geändert.

Hat sonst jemand dasselbe Problem?

Hallo jonofe

Der Statistik wegen.... Ich habe heute Deine Alexa-Edomi-Anbindung realisiert. Und auch bei mir ist es zu der Fehlermeldung gekommen.

    Application ID : OK
          KeyChain : OK
     SSL signature : OK
 Certificate parse : OK
SAN in certificate : OK
Certificate expiry : OK
timestamp validation failure.. Current time: 1501488322 vs. Timestamp: 1501488321850

Dieser Fehler tauchte ungefähr in der ersten Stunden nach der Fertigstellung der Custom-Skill-Einstellungen in der Developer-Console auf. Er ist dann ohne weitere Veränderungen weg gewesen und Alexa hat sich mit mir und Edomi unterhalten.

Ansonsten. Vielen Dank für die super Arbeit und die ausführliche Anleitung.

Gruß
wingfighter

[jonofe]

Danke für die Rückmeldung. Ich schaue mir das bei Gelegenheit noch mal an.
Wollte ja ohnehin beim Custom-Skill die Device-ID einbauen, so dass man die Info bekommt, von welchem Echo Device der Befehl geschickt wurde.

[jonofe]

Das klingt nicht schlecht ...

Alexa Smart Home Entertainment Capabilities

[Wingfighter]

Ich hatte eben nach Umstellung auf Reverse-Proxy wieder das Timestamp-Problem. Auch wenn das sicher nichts miteinander zu tun hat.
Da die beiden zu vergleichenden Timestamps mit unterschiedlichen Funktionen ermittelt werden ( time() und date("c") ), könnte es sein, dass deshalb Timestamps mit verschiedener Länge gespeichert bzw. verglichen werden.

function validateRequest($jsonRequest)
.
.
fail('timestamp validation failure.. Current time: ' . time() . ' vs. Timestamp: ' . $requestTimestamp);
. 

function handleSessionEndRequest($sessionEndRequest)
.
.
          "timestamp": "' . date("c") . '",
. 

Lösungsidee: Zeile 7 ändern

1function handleSessionEndRequest($sessionEndRequest)
2{
3   $RequestId = $sessionEndRequest['request']['requestId'];
4    $response = '{
5                  "type": "SessionEndedRequest",
6                  "requestId": "' . $RequestId . '",
7                  "timestamp": "' . date("c") . '",  --> "timestamp": "' . time() . '",
8                  "reason": "USER_INITIATED "
9                }
10                ';
11   return array(
12        'response' => $response
13    );
14} 

Das hat bei mir dann sofort funktioniert. Kann aber auch Zufall gewesen sein. Wie oben geschrieben, ging es ja beim ersten Mal nach einer gewissen Zeit auch ohne mein Zutun.

Möglicherweise gibt es ja noch andere Gründe, warum beide Timestamps unterschiedlich ermittelt werden. Dann hat dieser Änderungsvorschlag evtl. Seiteneffekte, die ich natürlich nicht überschaue.

[juliawf]

Hallo jonofe,

ich habe gelesen, dass die Alexa seit kurzem auch Szenen unterstützt. Dafür muss es, so wie es aussieht auch Smart Home Skills diese Funktion mitbringen.
Ist in diese Richtung schon was im LBS vorgesehen? bzw. ist die Funktion aktivierbar?

Gruß Waleri

[jonofe]

Szenen sind m.W. schon implementiert, aber dieses Feature ist nur in U.S. verfügbar und somit noch nicht verfügbar in Germany.

[jonofe]

Wingfighter : Guter Hinweis mit dem Timestamp und den beiden Funktionen. Da ich die Validierungsfunktion von extern übernommen habe, kann das natürlich der Grund sein. Ich schau mir das mal an, aber der Vorschlag scheint gut zu sein und das Problem hoffentlich zu lösen. Danke schon mal dafür.

[juliawf]

Szenen sind m.W. schon implementiert, aber dieses Feature ist nur in U.S. verfügbar und somit noch nicht verfügbar in Germany.

Ich kann seit dem letzten Update in meine Alexa App die Szenen sehen, allerdings nur die von Philips HUE.
Kannst du mir evtl. Sagen wie ich diese in Alexa SmartHome LBS aktiviere? In der Hilfe habe ich nichts gefunden.


IMG_3262.PNGIMG_3261.PNG

[jonofe]

Grundsätzlich gibt es spezielle Befehle für Szenen in der Smarthome API, die ich allerdings gerade nicht griffbereit habe.
Einfach mal nach Alexa Smarthome API in Google suchen, dann müsste die API Doku auftauchen und darin stehen die Utterances, die man verwenden muss. Ob das dann direkt funktioniert kann ich allerdings nicht versprechen.

[ThorstenGehrig]

Hallo,
erstmal ein "hut ab" für die Leisung hier!
Und gleich ein feedback: Aufgrund des ersten posts - und dem deutlichem Hinweiß auf den "Custom Skill" ... habe ich erstmal das Smarthome-Skill von Panzaeron (https://knx-user-forum.de/forum/proj...art-home-skill) implementiert - und dachte mir das ich "irgendwann" (=> jetzt) mich zusätzlich um ein Custom Skill kümmere.
Beim lesen der 32 Seiten sehe ich dann das hier beides gemacht wird... das könntest du vielleicht im ersten post mal aktualisieren. Danke.
Dann habe ich eine Frage zum Smarthome Skill - wenn ich es recht sehe geht der "setLockState" im Alexa Smarthome Command Validator.
Das ist ja eigentlich für Schlösser vorgesehen (die man ja bekanntlich öffnet und schließt)... hat schon jemand damit ausprobiert Garagentüren und Rollladen damit zu steuern? Frei nach dem Motto
* Alexa öffne/schließe die Garage
* Alexa öffme/schließe den Rollladen Wohnzimmer
Irgendwelche %-Positionen sind damit zwar nicht anfahrbar - das brauche ich aber bei einer Garage nicht und bei den Rollladen wird die Beschattung von Autokatiken geregelt - also keine Notwendigkeit für manuelle "rollladen auf 60%"...
Und wenn wir irgendwann mal beim Smarthome skill seheen welcher Dot/Echo angesprochen wurde können wir sogar die Raumbezeihnung sparen: Alexa öffne/schließe den Rollladen.

Gruß
Thorsten

[jonofe]

Dann habe ich eine Frage zum Smarthome Skill - wenn ich es recht sehe geht der "setLockState" im Alexa Smarthome Command Validator.
Das ist ja eigentlich für Schlösser vorgesehen (die man ja bekanntlich öffnet und schließt)... hat schon jemand damit ausprobiert Garagentüren und Rollladen damit zu steuern? Frei nach dem Motto
* Alexa öffne/schließe die Garage
* Alexa öffme/schließe den Rollladen Wohnzimmer

Bislang waren die Lock Commands nur für U.S., d.h. in englisch verfügbar. In der API wird dies zwar nicht ausdrücklich erwähnt, allerdings habe ich dort auch nicht die deutschen Befehle gefunden. Hast du da irgendwo mehr Infos gesehen?

[jonofe]

Ich hatte eben nach Umstellung auf Reverse-Proxy wieder das Timestamp-Problem. Auch wenn das sicher nichts miteinander zu tun hat.
Da die beiden zu vergleichenden Timestamps mit unterschiedlichen Funktionen ermittelt werden ( time() und date("c") ), könnte es sein, dass deshalb Timestamps mit verschiedener Länge gespeichert bzw. verglichen werden.

function validateRequest($jsonRequest)
.
.
fail('timestamp validation failure.. Current time: ' . time() . ' vs. Timestamp: ' . $requestTimestamp);
. 

function handleSessionEndRequest($sessionEndRequest)
.
.
"timestamp": "' . date("c") . '",
. 

Lösungsidee: Zeile 7 ändern

1function handleSessionEndRequest($sessionEndRequest)
2{
3 $RequestId = $sessionEndRequest['request']['requestId'];
4 $response = '{
5 "type": "SessionEndedRequest",
6 "requestId": "' . $RequestId . '",
7 "timestamp": "' . date("c") . '", --> "timestamp": "' . time() . '",
8 "reason": "USER_INITIATED "
9 }
10 ';
11 return array(
12 'response' => $response
13 );
14} 

Das hat bei mir dann sofort funktioniert. Kann aber auch Zufall gewesen sein. Wie oben geschrieben, ging es ja beim ersten Mal nach einer gewissen Zeit auch ohne mein Zutun.

Möglicherweise gibt es ja noch andere Gründe, warum beide Timestamps unterschiedlich ermittelt werden. Dann hat dieser Änderungsvorschlag evtl. Seiteneffekte, die ich natürlich nicht überschaue.

Habe mir das noch mal angeschaut. Das sind nicht die beiden Timestamps, die verglichen werden. Es wird der lokale Timestamp mit dem Timestamp der von Amazon kommt verglichen. Das was du gepostet hast, ist das Setzen eines Timestamps in der Antwort an den Amazon Alexa Service.
Wäre interessant zu sehen, wie der Timestamp des JSON requests vor der Fehlermeldung aussah, der von Amazon kam, denn grundsätzlich liefert time() und auch strtotime() einen UNIX Zeitstempel. Dieser sollte immer Die Anzahl der Sekunden seit 01.01.1970 sein. Und genau das wird hier verglichen (strtotime(AMAZON-TimeStamp - time()). Falls jemand noch ein Log mit diesem Fehler hat, dann bitte man den Timestamp posten. Sollte ungefähr so aussehen:

[timestamp] => 2017-08-04T10:37:40Z

Die unterschiedliche Auflösung im Log liegt vermutlich nur daran, dass bei der Ausgabe das strtotime() vergessen wurde und der requestTimestamp einfach so ausgegeben wurde. Habe das mal korrigiert und auch im positiven Fall das Logging des Timestamps aktiviert. Ist beim nächsten Update dann dabei.