Das klingt nach nem Plan 
Ich bin jetzt ein ganzes Stück weiter gekommen.
Doch am Ende wird nicht geschaltet.
In den Einstellungen von Alexa werden mir meine HM Geräte gezeigt. Sage ich nun "Alexa, Wohnzimmer Licht an! Bestätigt sie mir mit OK den Schaltbefehl, ich sehe auch in der IPS Console das der control-thread ausgeführt wird doch wird das Licht nicht geschaltet. Was kann ich tuen um herauszufinden woran das liegt.
Das Lambda Testskript konnte ich ebenfalls ausführen und mir wurden meine 2 Test HM Geräte (Schalter/Dimmer) aufgelistet.
Im Log von IPS sehe ich nur:
22.12.2016 03:26:12*| 19721*| dimm () to
Hallo
Benutzt du dieses control-thread Script ?
$deviceId = $_IPS['deviceId'];
$value = $_IPS['value'];
$alexaName = GetValue (@IPS_GetVariableIDByName("alexa_name", $deviceId));
$alexaType = GetValue (@IPS_GetVariableIDByName("alexa_type", $deviceId));
IPS_LogMessage($_IPS['SELF'], "dimm " .$deviceId . " (".$alexaType.") to " . $value);
if ( $alexaType == "dimmer" ) {
$value = $value / 100.0;
HM_WriteValueFloat( $deviceId, "LEVEL", $value);
} else if ( $alexaType == "switch" ) {
HM_WriteValueBoolean($deviceId, "STATE", $value == 100);
} else if ( $alexaType == "shutter" ) {
SC_Move($deviceId, $value);
}
Alexa schickt dir die $deviceID deines Geraetes. Das Script sucht jetzt in deiner Instanz nach den beiden Variablen
„alexa_name“ und „alexa_type“ die du wahrscheinlich nicht angelegt hast.
du rufts direkt das control-thread script auf, du musst im webhook aber mit dem control-endpoint einsteigen, deswegen ist bei dir deviceId und value nicht gesetzt.
Nachtrag: die beiden scripte muessen leider getrennt sein damit die eigentlich steuerung asynchron ablaeuft. PHP/Python sind nicht meine Sprachen, verbesserungen nehme ich gerne an. Gibt es z.B. einen Weg einen Thread zu starten im selben script?
Moin,
hier mal ein paar Screenshots. Vielleicht entdeckt jemand einen Fehler?
Ist da etwas falsch?
Grüße,
Christoph
Aender mal die Permisison von „AWSLambdaExecute“ auf „AWSLambdaBasicExecutionRole“
wenn das nicht hilft, dann lege mal selber eine Policy an und kopieren folgenden code rein, dann die angelegte policy der rolle zuweisen. du musst noch an drei stellen deine eigenen werte angeben:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "logs:CreateLogGroup",
"Resource": "arn:aws:logs:eu-west-1:ANPASSEN:*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:eu-west-1:ANPASSEN:log-group:/aws/lambda/ANPASSEN:*"
]
}
]
}
unter Resource musst du die ARN deiner Lambda kopieren
Das hat leider nichts gebracht.
Edit:
Deinen Edit habe ich noch nicht getestet, wird jetzt gemacht
Wenn ich das Discover-Script direkt aus dem Browser aufrufe, kommt:
[{"applianceId":"15955","manufacturerName":"Homematic","modelName":"model 01","version":"1.0.0","friendlyName":"Lampe","friendlyDescription":"Lampe","isReachable":"True","actions":[ "turnOn", "turnOff", "setPercentage", "incrementPercentage", "decrementPercentage"],"additionalApplianceDetails":{ "extraDetail1":"switch", "extraDetail2":"", "extraDetail3":"", "extraDetail4":""}}]
Passt das?
ja, das sieht soweit gut aus
Ja super ger
Gesendet von iPhone mit Tapatalk
ich habe gerade mal eine neue leere rolle angelegt, keine policy hinzugefuegt, die tests funktionieren trotzdem, glaube immer weniger das es daran bei dir liegt 
Wenn der Test gesendet wird muss symcon! Die software irgendwas zurück senden können? Also muss ich noch irgendwas einrichten? Fernzugriff funktioniert, connect ID funktioniert! Sonst gibt es doch Nix oder?
Gesendet von iPhone mit Tapatalk
so… da lauft was schief, ich sehe in meinen Lambda logs zugriffe mit diversen access tokens 
:rolleyes:
scheinbar habe ich nicht erfolgreich meine IDs geschwaerzt. Da sind auch discovery requests mitten in der nacht, wenn alexa nicht periodisch nach neuen geraeten sucht dann war das auch jemand anders
kontrolliert nochmal eure ULRs & ARNs.
Ich denke mal dieses gilt fuer Leute bei denen es nicht funktioniert , oder?
ja klar
kann mir nur gerade nicht erklaeren wie das kommen kann, denn die lambda funktion wird vom skill aufgerufen, also muss jemand die ARN meiner lambda bei sich im skill eingetragen haben. … Noch kann ich keine DDOs attacke feststellen, aber in ein paar tagen werde ich die funktion und den skill mit neuen IDs neu aufsetzen, sicher ist sicher. Auch werde ich in die scripte mal etwas sicherheit einpflegen, etwa das access token pruefen.
Das hatte ich Dir geschrieben das der Skill mit Oauth fest verknüpft wird wenn Du also dir Redirect URL öffentlich macht was Du nicht solltest dann läuft auch alles über dein Lambda und die 1 Mio Zugriffe sind schneller weg als Du Dir denkst. Entweder bastelt sich also da jeder selber eine OAuth Anbindung mit eigenen Redirect URL oder ist müsst halt warten bis dies von IP-Symcon freigegeben ist und dann über IP-Symcon läuft.
Abgesehen davon hat das auch Datenschutzgründe wenn alles über Dein Lambda läuft. Also entweder ist jeder in den Lage sich seine eigene OAuth Lösung zu basteln oder aber eben abwarten bis die Rahmen Bedingungen geklärt sind und dann auf IP-Symcon grünes Licht gibt.
Ich hoffe, dass ich das nicht bin… Ich habe die Screenshots allerdings erst runtergeladen, als sie schon geschwärzt waren. Ich prüfe das mal.
nene, oauth lauft ueber IPS, da lauft weder was ueber meinen skill noch ueber meine lambda, das richtet doch jeder selber ein! die redirect URL ist kein geheimnis, die wird auch nirgends eingetragen, die ist fuer leute die eine firewall betreiben und diese dort ggf. eintragen muessen. die redirect ULR wird der oauth login seite dynamisch mitgegeben, mein script hat die auch nicht hart codiert, sondern wertet diese aus und wenn man den link klickt wird man genau an diese adresse die von amazon uebergeben wurde verlinkt. der ganze oauth kram verknuepft auch nicht den skill mit der lambda und IPS sondern dient lediglich der generierung des access tokens welches dann spaeter bei jeder kommunikation skill-IPS mitgeschickt wird. im endpoint script muesste eigentlich noch eine pruefung rein ob das access_token mit dem uebereinstimmt was man in token.php eingetragen hat.
abgesehen davon denke ich das selbst wenn alle hier im forum die auch eine alexa haben ueber eine einzige Lambda gehen wuerden, dann waeren die million aufrufe wohl noch genug, und falls nicht, 1mio weitere aufrufe kosten mich dann 20 cent, das wuerde ich sogar noch sponsoren 1mio aufrufe sind 23 pro minute, ich habe gestern genau 24 aufrufe gemacht (sieht man im monitoring) und das wahrscheinlich nur weil es noch neu ist. Um von einem pro stunde auf 23 pro minute zu kommen koennten es bei gleichem nutzungsverhalten 1380 leute verwenden… also sooo schnell wie su glaubts kommt man nicht auf die mio aktivierungen
PS: ich habe nochmal genau nachgeschaut, scheinbar macht alexa periodisch device discoveries, denn die ID die nachst verwendet wurde ist mein access token, und das war IMHO von anfang an im script von mir anonymisiert. Die andere ID von eben, das war ich scheinbar selber als ich die tests mit der rolle ausgefueghrt habe, die werden mit einem anderen Access token ausgefuehrt, glaube es ist alles gut.
Okay. Ich werde gleich den ganzen Kram löschen und noch mal neu hochziehen. Vielleicht klappt es ja dann.
Hat jemand Symcon auf dem RaspBerry am laufen oder seid ihr alle auf Windows unterwegs? Gerade bei den es funktioniert!? Wobei es dürfte doch eigentlich kein unterschied ergeben oder?
Gesendet von iPhone mit Tapatalk