Amazon Echo an Symcon anbinden inklusive Proxy

pull neu, mehr bilder im skill setup ordner

ach ja stimmt, die rolle muss man anlegen, pull nochmal, mehr bilder dazu hochgeladen

PS: Ich bin einfach der Anleitung von Amazon gefolgt: https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/steps-to-create-a-smart-home-skill

Super, vielen vielen Dank!

Ich hab immer die ganze Zeit irgendwo noch einen Fehler in Lambda beim Testen :confused:

{
  "stackTrace": [
    [
      "/var/task/lambda_function.py",
      14,
      "lambda_handler",
      "access_token = event['payload']['accessToken']"
    ]
  ],
  "errorType": "KeyError",
  "errorMessage": "'payload'"
}

hast du das test event konfiguriert:

einfach den vorhandenen JSON string durch den folgenden ersetzen


{
  "header": {
    "payloadVersion": "2",
    "namespace": "Alexa.ConnectedHome.Discovery",
    "name": "DiscoverAppliancesRequest"
  },
  "payload": {
    "accessToken": "someaccesstoken"
  }
}

ah, du hast wohl die datei hochgeladen? ich habe den code einfach im inline editor stehen, im drop down fuer „Code entry type“ auf „Edit code inline“ stellen.

einen noch, dann darf ich editieren… :confused:

Danke funktioniert jetzt , hab das erste Geraet in Alexa. Nebenbei muss noch bemerkt werden,
dass Trigger noch enabled werden muss. Ist standarmaessig disabled.

sauber! freut mich :slight_smile:

Wenn noch jemand lust und vor allem Zeit hat, das alles zusammen fassend in einen wiki artikel im git repo zu beschreiben, gebe ich gerne comitter rechte dafuer :slight_smile:

PS: oh ja, die trigger aktivierung war auch mein letzter schritt :smiley:

was koennte man jetzt noch tun um die einrichtung zu erleichtern?

macht es sinn die web hooks zusammen zu fassen und nur ein einziges script zu verwenden? und dann per query param steuern was das script tun/anzeigen soll, z.B.
http: //xyz.ipmagic.de/hook/alexa?action=terms
http: //xyz.ipmagic.de/hook/alexa?action=login
http: //xyz.ipmagic.de/hook/alexa?action=discover
etc. pp.

ich sehe keinen weg vorbei an dem amazon Setup, es sei denn wir hosten irgendwo einen proxy service (muss SSL haben). Wenn wir ein proxy service einrichten, dann wuerden wir die oauth scriptye dort hosten und beim login muesste dann jeder user seine IPS connect ID dort eintragen damit der proxy service die alexa befehle an die jeweiligen IPS instanzen weiter routen kann. ich denke das ist mit relativ wenig aufwand realisierbar. Wenn dann noch die scripte/webhooks durch ein richtiges modul ersetzt werden ist es kinderkram das einzurichten.

Wie gesagt DaveRichter arbeitet an einem Modul. Es sind aber noch Rahmenbedingungen und technische Sachen zu klären also bitte noch Geduld haben. Alles was hier erarbeitet wird ist wertvoll und wenn sinnvoll kann das ins Modul mit aufgenommen werden. Mit dem Modul wird es nicht notwendig sein webhooks anzulegen. Es gibt dann voraussichtlich eben nur eine RedirectionEndpoint und das ist der Oauth IP-Symcon Endpoint. Den Token bekommt die IP-Symcon Installation dann über IP-Symcon Connect. Kommuniziert wird über die WebOAuth Instanz unter Kerninstanzen. Dies geht aber erst ab 4.1 Beta sobald das in der Stable aufgenommen wurde und Details geklärt sind kann das dann auch als PHP Modul ab 4.1 arbeiten.

An 4.1 Beta ist das möglich IP-Symcon ist der Oauth Endpunkt und vergibt den Token über IP-Symcon Connect. Ab 4.1 Beta lassen sich dann also OAuth Module bauen die eine OAuth Authenifizierung nutzten. Es erfolgt dann also aus dem Modul jeweils die Anmeldung beim Dienst in dem Fall Echo das Modul bekommt den Token und fertig. Eine Skill Konfiguration auf User Ebene ist dann nicht mehr notwendig.

ok, dann halte ich die fuesse still.

Ist Dave Richter einer der Entwickler bei IPS?

Nein nicht Füße stillhalten :). DaveRichter ist auch nur ein sehr engagierter User der halt auch PHP Module bastelt. Er freut sich über jeden Input und Hilfe. Aber koordinieren kann das nur einer mit Oauth und IP-Symcon sonst gibt das Chaos und es gibt geplant dann ja auch nur einen Redirect Endpunkt und ein Modul. Aber alles was dieses Modul können wird kommt hier aus dem Forum und basiert auf den Ideen hier, also bitte nicht zurückhalten mit Ideen.

Wie ein Oauth Modul funktioniert sieht man bei
GitHub - paresy/SymconMisc: Symcon Misc Modules
das Locative Modul ist ein Beispiel wer will kann das ja mal ausprobieren dann seht ihr wie einfach das dann hoffentlich später funktioniert.

Danke nochmal. Das funktionioniert einwandfrei.
Die Sache mit den zusaetzlichen Variablen bei jeder Instanz hab ich mal bei mir rausgenommen.
War mir zu umstaendlich.
Ich hab einfach eine Kategorie angelegt und da erstellt ich nur noch Links.
Ich discovere nur diesen Ordner. Fuer VariablenLinks und Links auf FS20 funktioniert bei
mir alles perfekt.

Alexa.png

Hey ho,

sorry das ich hier einfach zwischen grätsche :slight_smile:
aber module kann es später beliebige geben, ich habe die Lambda function so gebaut das man quasi beliebige module „anhängen“ kann :slight_smile: eine Doku wird es dann auch noch geben, mit dingen die die Lambda function so alles kann :smiley:
ich will ja die flexibilität von Symcon nicht beeinträchtigen :smiley:

Grüsse
Dave

das mit den links ist glaube ich echt mit weniger Arbeit verbunden als die Variablen anzulegen. Der Link name ist dann der device friendly name? Wie setzt du den alexa_type? Der wird ja derzeit von meinem script verwendet um den richtigen befehl zu verwenden?

Noch besser:). Wäre aber trotzdem wünschenswert wenn sich da alle zusammentun. Jedes PHP Modul hat ja seine eigenen GUIDs und ich persönlich fände es schon praktisch wenn ich in IP-Symcon eine Instanz über die GUID suche dann nicht am Schluss 4 verschiedene Module mit eigenen GUIDS installieren zu müssen von denen jedes seine Vorzüge hat aber doch nicht alles abdeckt. Daher fände imho schon wünscheswert wenn es am Schluss einen Master mit den Grundfunktionen und GUIDs für Echo gibt. Das hindert ja dann trotzdem niemand daran den Master zu forken und Verbesserungen einzubringen oder den Fork für sich anzupassen und zu nutzen. Zumindest ist dann aber gewährleistet das sich hinter einer bestimmten GUID immer eine Echo Instanz verbirgt. Das macht es dann auch einfacher z.B. zukünftig von anderen Modulen über die GUID zuzugreifen.

Wenn das über ein Konfigurationsformular gelöst wird ist das auch nicht mehr Arbeit. Für jeden Link den Du anlegst brauchst Du auch ein paar Mausklicks und Umbenennen musst Du den Link dann ja auch noch passend. Da ist es auch nicht langsamer den Namen im Form einzugeben und die Instanz auszuwählen die Du beim Link ja auch auswählen musst. Und Du hast dann nur einen Konfigurator im Objektbaum und nicht unzählige Links was vielleicht etwas übersichtlicher ist.

Du hast Recht , aber meine Loesung soll ja nicht das endgueltige sein.
Nur die Form gibt es noch nicht und man will ja „spielen“:smiley:

Ich kann ja mal eine Form zum „spielen“ hochladen dann könnt ihr Euren Senf dazugeben ob das was wäre. Ich melde mich wenn ich da was zusammengefrimmelt habe.

das waer super! wie kann man da drauf zugreifen auf das was im formular konfiguriert wurde? ich muss aus dem formular das JSON fuer die device discovery zusammen schustern. Das formular muesste value quadruples konfigurierbar machen: deviceID, deviceVendor, deviceType, alexaName. Wenn du dafuer ein beispiel hast baue ich das ein.

aus der kombination vendor und type kann man dann spaeter den richtigen Befehl herausfinden den man braucht um das geraet anzusteuern.