Amazon Alexa Plugin

[Salf]

Hi AndreK ,

ich war mir nicht ganz sicher welche Version ich genau nutzte (4p3 wars aber) und habe daher die folgende Master Version runtergeladen und komplett auf der NAS ersetzt. Jetzt funktionieren aber die ICONs und die Rollos sind nun auch in Alexa verfügbar. SetPercentage habe ich eben auch entfernt.

https://github.com/Andrek01/Alexa4PayloadV3 --> Master

Es kommt aber die selbe Fehlermeldung.

Alexa: invalid alexa action 'SetRangeValue' specified in item EG.Schlafzimmer.Rollladen.pos, ignoring item

Gruß Salf

[AndreK]

Hallo Salf ,

wenn ich das richtig sehe hast Du die letzte Version von meinem GitAccount im Einsatz ? Korrekt ? (Woher kommt sonst die Info mit SetRangeValue ?)
Es gibt diese Funktion(en) "RangeController"- zu Testzwecken (bisher alle Tests positiv), nur in diesem Stand, nicht im offiziellen Repo von shNG.

Falls oben nein - versuchst Du Funktionen zu nutzen welche nur dort (mein letzter Upload auf Git) implemtiert sind.
Wie bist Du vorgegangen. Hast Du die "p3_actions.py" aktualisiert/heruntergeladen, bzw. alle Dateien ? Oder hast Du nur versucht mit "Deinem" Stand diese Funktionen zu nutzen ?


Ich denke da ist das Plugin nicht auf dem letzten Stand. Müsstest Du direkt von meinem Git aktualisieren.

Hinweis : SetRangeValue und SetPercentage machen dann das gleiche - SetPercentage- kannst du hier weglassen - ich vermute das verwirrt Alexa nur.

Gruss Andre

[Salf]

HI,
ich nutzte aktuell das neue Plugin alexa4p3. Nun bekomme ich aber folgende Fehlermeldung:

Alexa: invalid alexa action 'SetRangeValue' specified in item EG.Schlafzimmer.Rollladen.pos, ignoring item

Hier mein ITEM dazu:

Rollladen:
  alexa_name: Schlafzimmer Rollladen
  alexa_device: EGSchlafzimmerRollladen
  alexa_description: Schlafzimmer Rollladen
  alexa_icon: EXTERIOR_BLIND
  alexa_proactivelyReported: 'False'
  alexa_retrievable: 'True'
  fahren:
    type: bool
    enforce_updates: true
    visu_acl: rw
    knx_dpt: 1
    knx_send: 4/1/1
    uzsu:
      type: dict
      cache: true
      visu_acl: rw
      uzsu_item: EG.Schlafzimmer.Rollladen.fahren
  pos:
    type: num
    visu_acl: rw
    knx_dpt: 5
    knx_init: 4/4/1
    knx_status: 4/3/1
    alexa_device: EGSchlafzimmerRollladen
    alexa_actions: "SetRangeValue AdjustRangeValue SetPercentage"
    alexa_retrievable: 'True'
    alexa_range_delta: 20
    alexa_item_range: 0-255
  stop:
    type: bool
    cache: true
    visu_acl: rw
    knx_dpt: 1
    knx_send: 4/2/1
    alexa_device: EGSchlafzimmerRollladen
    alexa_actions: Stop
    alexa_proactivelyReported: 'False'
    alexa_retrievable: 'False'

Könnt ihr euch das erklären? Oder wo kann ich nach dem Fehler suchen?

[yachti]

Das Problem mit dem fehlenden Webinterface vom AlexaCamproxy ist gelöst.
Pluginverzeichnis von alexacamproxy4P3 auf alexacamproxy4p3 gändert.
Plugin angepasst

AlexaCamProxy4P3: class_name:
AlexaCamProxy4P3
class_path: plugins.alexacamproxy4[COLOR=#FF0000]p[/COLOR]3
port: 443
video_buffer: 524280
cert_path: '/usr/local/smarthome/plugins/alexacamproxy4p3/fullchain.pem'
cert_path_key: '/usr/local/smarthome/plugins/alexacamproxy4p3/privkey.pem'
proxy_url: 'camproxy.domain.de' proxy_credentials: ''
proxy_auth_type: 'NONE'

Danke AndreK
Bitte noch README.md entsprechend anpassen

[yachti]

Hallo Andre,

Zugriff von intern bedeutet im Moment (kann man ja noch ändern), das nur Zugriffe von der "eigenen IP" ( "Public-IP" vom Provider zugeteilt) erlaubt werden.
Es läuft auf TCP-Basis so ab, dass der Request an die bekannnte Domain erfolgt (deine.domain.de), dein Router kennt seine eigene Adresse (die der Domain) und schickt
diese gar nicht raus sondern direkt wieder zurueck ins LAN (Hair-Pinning). Die Anfrage an den Cam-Proxy kommt somit von deiner "eigenen" IP (der bezogenen vom Provider).

Bei mir sieht die Konstellation etwas anders aus. Alle Zugriffe von extern nach intern gehen über einen ReverseProxy in der DMZ. Der ReverseProxy leitet an interne Adressen weiter. Intern habe ich eine eigene PKI. D.h. in den CAMproxy müssten meine Zertifikate eingebunden werden sonst kann der Reverseproy nicht weiterleiten. Der ReverseProxy vertraut der internen CA und die ausgestellten Zertifikate. Der Zugriff von extern zum ReverseProxy nur über Zertifikate einer Public CA oder Clientzertifikate meiner CA.

Um das Ganze mal von intern zu Testen habe ich die öffentlichen Zertifikate in dem Camproxy eingebunden und im DNS eine Splitdomain (CNAME auf camproxy.domain.de zur internen IP von SHNG).
Wie komme ich jetzt an die uuid des Streams?

Beim Zugriff mit VLC (ohne uuid) über camproxy.domain.de

2019-12-26 08:27:46 ERROR plugins.alexacamproxy4P3 ProxyCam4AlexaP3: SSL-Error - [Errno 9] Ungültiger Dateideskriptor

Bisher habe ich keine Applikation gefunden die der Umsetzung von Amazon folgen kann (rtsp via https). (weder VLC noch FFMPEG)
Falls Du hier noch Idee hast - Hinweise gerne willkommen.

Fällt mir adhoc auch nichts ein. Ich habe hier beide Möglichkeiten. Für FFMPEG habe ich im smartVISU Forum mal eine Anleitung geschrieben.
Ansonsten kann ich ab 07.01.mal bei uns in der Software-Entwicklung fragen ob die noch eine Idee haben. Streamplayer im FireTV aber dann sind wir schon bei Amazon

Ansonsten würde ich versuchen einen Test-Socket ins Plugin zu implemtieren. So dass man dann via VLC auf diesen Test-Socket zugreifen kann, dieser dann "Amazon-like", auf den CamProxy zugreift und das Ergebnis (den Stream) dann an den VLC zurücksendet.

Könne wir gerne testen nur mit sowas kenne ich mich nicht aus. Komme aus der Netzwerktechnik nix Programmierung.

Gruß
Michael

[AndreK]

Hallo Michael,

bin jetzt auch wieder dabei :-) - morgen kommt der nächste Teil der "Familiy" - dann geht es wieder etwas langsamer.
Zugriff von intern bedeutet im Moment (kann man ja noch ändern), das nur Zugriffe von der "eigenen IP" ( "Public-IP" vom Provider zugeteilt) erlaubt werden.
Es läuft auf TCP-Basis so ab, dass der Request an die bekannnte Domain erfolgt (deine.domain.de), dein Router kennt seine eigene Adresse (die der Domain) und schickt
diese gar nicht raus sondern direkt wieder zurueck ins LAN (Hair-Pinning). Die Anfrage an den Cam-Proxy kommt somit von deiner "eigenen" IP (der bezogenen vom Provider).
Nur diese Anfragen werden im Moment akzeptiert. Wenn Du nun versuchst direkt auf die Adresse zuzugreifen wird diese nicht akzeptiert. Die Verbindung wird abgerbrochen (=Obige Fehlermeldung = Log-Eintrag verbesserungswürdig).
Bin insgesamt ein Stück weiter es funktionieren nun :

        <= NONE  =>                            <= NONE =>    
echo    <= DIGEST => AlexaCamProxy             <= DIGEST =>    Camera

Basic-Auth muss noch hinzu, sollte aber kurzfristig möglich sein.
Bisher habe ich keine Applikation gefunden die der Umsetzung von Amazon folgen kann (rtsp via https). (weder VLC noch FFMPEG)
Falls Du hier noch Idee hast - Hinweise gerne willkommen.
Ansonsten würde ich versuchen einen Test-Socket ins Plugin zu implemtieren. So dass man dann via VLC auf diesen Test-Socket zugreifen kann, dieser dann "Amazon-like", auf den CamProxy zugreift und das Ergebnis (den Stream) dann an den VLC zurücksendet.

Ich denke ich kann nach nach "dem langen Wochende" (06.01.2020) mal ein update auf Git machen. Falls vorher geb ich Info.

Gruss Andre

[yachti]

Hi Andre,

Welchen Stand hattest Du den gezogen ?

Ich habe Stand heute gezogen.

Es wundert mich, dass Du kein Web-Interface in Deinen Screen-Shots hast ?

war mir auch aufgefallen. Im plugin ist ein webif Ordner mit Dateien aber ich dachte da es develope wohl noch nicht fertig.

URL aus deiner Proxy-URL (camproxy.domain.de) + einer UUID4

jetzt sehe ich schon etwas klarer. Hat mir zum Verständnis gefehlt.

Ich gebe Info sobald das zum Test soweit ist.

Ich bin jetzt die nächsten Tage zu Hause mit Zeit zum Testen.
Also wenn was hast lets go.

Schönen Abend

Michael

[AndreK]

Hi yachti ,

das plugin "AlexaCamProxy" ist noch nicht ganz fertig :-(. Welchen Stand hattest Du den gezogen ? ich hatte vor 2 Tagen innerhalb von Git umgezogen und eine Vorab-Version hochgeladen), ich bin hier gerade noch mit der Fertigstellung beschäftigt. (so ein paar Sicherheits-Features)
Es wundert mich, dass Du kein Web-Interface in Deinen Screen-Shots hast ?
Beim Neustart des Plugins wird pro Stream eine URL aus deiner Proxy-URL (camproxy.domain.de) + einer UUID4 gebildet. Diese kennt nur das Plugin !! - Wird aber im Web-Interface angezeigt. Beim Zugriff auf den Proxy + URL wird dann der eigentliche Stream aufgebaut.
Zugriff muss also immer über https://camproxy.domain.de/UUID4 aus dem Web-IF aufgebaut werden.
Das Plugin erlaubt im Moment nur einen Zugriff aus dem "eigenen" LAN. Adressen von Aussen werden geblockt.
Authorisierung zum Proxy funktioniert, in Verbindung mit -ohne Authorisierung zur Kamera- (das muss ich noch fertigstellen).
Ein Test sollte aus dem eigenen LAN mittels VLC-Player dann möglich sein. (rtsp via http bzw. https)
Ich gebe Info sobald das zum Test soweit ist.

Gruss Andre

[yachti]

Hallo,
ich habe jetzt auch auf das Plugin alexa4p3 umgestellt und klappt eigentlich soweit alles ganz gut. Wollte meine Markise auf EXTERIOR_BLIND anpassen bin da aber gescheitert. Werde das später nochmal anfassen und ggf. commiten.

Ich habe mich heute mal an das Plugin alexacamproxy4P3 gemacht Zugriff erfolgt über meinen nginx Reverseproxy wie auch beim alexa4p3 plugin.
Letsencrypt Zertifikate für den camproxy url sind erstellt und über ssllabs A+ geprüft.
Im Smarthomelog habe ich keine Fehler. Im nginx log auch nicht. Über VLC Player habe ich einen RTP Stream der Kamera mit den Daten im item. Die image_url ist im Webbrowser erreichbar. Auf die credentials für den proxy habe ich zum Testen fürs Erste verzichtet.
shng.PNG

plugin conf

AlexaCamProxy4P3:
    class_name: AlexaCamProxy4P3
    class_path: plugins.alexacamproxy4P3
    port: 443
    video_buffer: 524280
    cert_path: '/usr/local/smarthome/plugins/alexacamproxy4P3/fullchain.pem'
    cert_path_key: '/usr/local/smarthome/plugins/alexacamproxy4P3/privkey.pem'
    proxy_url: 'camproxy.domain.de'
    proxy_credentials: ''
    proxy_auth_type: 'NONE'

item

tuercam:
    alexa_description: Türkamera
    alexa_name: Türkamera
    alexa_device: tuerkamera
    alexa_auth_cred: 'user:passwd'
    alexa_icon: CAMERA
    alexa_actions: InitializeCameraStreams
    alexa_camera_imageUri: http://host.domain.de/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPhkmUCeI9WG7C&user=user&password=passwd
    alexa_csc_uri: '{"Stream1":"rtsp://user:passwd@host.domain:554//h264Preview_01_main","Stream2":"rtsp:///user:passwd@host.domain:554//h264Preview_01_sub"}'
    alexa_stream_1: '{
    "protocols":["RTSP"],
    "resolutions":[{"width":1920,"height":1080}],
    "authorizationTypes":["NONE"],
    "videoCodecs":["H264"],
    }'
    alexa_stream_2: '{
    "protocols":["RTSP"],
    "resolutions":[{"width":1280,"height":720}],
    "authorizationTypes":["NONE"],
    "videoCodecs":["H264"],
    }'
    alexa_csc_proxy_uri: camproxy.domain.de
#    alexa_proxy_credentials: user:pwd

So jetzt zu meinem Problem. Ich habe keinen Echo show zum Testen. Webzugriff über die proxy_url funktioniert nicht "Keine Verbindung zum Server"
Die Alexa App kann ja kein Kamerastream wiedergeben. Die Kamera ist in der Alexa App als Gerät aktiv.
Hat jemand ne Idee wie man das testen kann?

Ich werde mir demnächst nen echo show 5 zulegen, würde aber jetzt schon mal testen wollen.

Gruß
Michael

[henfri]

Oh, Klasse.
Darf ich es Mal ausprobieren?

[AndreK]

Hallo henfri,

das Discovery für Payload V3 ist etwas anders aufgebaut, bei mir sieht das so aus :

{
  "directive": {
    "header": {
      "namespace": "Alexa.Discovery",
      "name": "Discover",
      "payloadVersion": "3",
      "messageId": "abc-123-def-456"
    },
    "payload": {
      "scope": {
        "type": "BearerToken",
        "token": "access-token-from-skill"
      }
    }
  }
}

Dann bekomm ich auch den richtigen Response.

Kurzer Spoiler zum nächsten Release, dann mit Web-Interface :
Anzeige aller Alexa-Devices mit zugeordneten Actions und entsprechendem shNG-Item
Action mit Payload V2 = rot, mit Payload V3 = grün, summarisch im Kopf grün wenn nur eine Payload-Version verwendet wurde, rot wenn zwei Payload-Versionen verwendet wurden.

2019-12-01-173124_1280x1024_scrot.png

Gruss Andre

[henfri]

Hallo Andre,

ich habe jetzt noch mal alle turnOn und turnOff mit einem großen T versehen und neu gestartet.
Damit wurden jetzt vier weitere Geräte gefunden.
Was mich wundert:

Wenn ich in
https://eu-west-1.console.aws.amazon...=configuration

{
  "header": {
    "messageId": "F8752B11-69BB-4246-B923-3BFB27C06C7D",
    "name": "DiscoverAppliancesRequest",
    "namespace": "Alexa.ConnectedHome.Discovery",
    "payloadVersion": "3"
  },
  "payload": {
    "accessToken": "1"
  }
}

Also payloadVersion: "3" konfiguriere und abschicke, bekomme ich:

</head>
    <body>
        <h1>Error response</h1>
        <p>Error code: 400</p>
        <p>Message: Bad Request.</p>
        <p>Error code explanation: 400 - unknown `header.namespace` 'Alexa.ConnectedHome.Discovery'.</p>
    </body>
</html>

2019-12-01T16:04:11.923Z    551d8fef-8e7d-416e-81d0-9c23a2a3dd25    SyntaxError: Unexpected token < in JSON at position 0
    at JSON.parse (<anonymous>)
    at IncomingMessage.res.on (/var/task/index.js:39:24)
    at emitNone (events.js:111:20)
    at IncomingMessage.emit (events.js:208:7)
    at endReadableNT (_stream_readable.js:1064:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)
END RequestId: 551d8fef-8e7d-416e-81d0-9c23a2a3dd25
REPORT RequestId: 551d8fef-8e7d-416e-81d0-9c23a2a3dd25    Duration: 144.56 ms    Billed Duration: 200 ms    Memory Size: 512 MB    Max Memory Used: 21 MB    
RequestId: 551d8fef-8e7d-416e-81d0-9c23a2a3dd25 Process exited before completing request

In https://github.com/smarthomeNG/plugi...d%20Lambda.pdf steht auch nur V2 (daher ist bei mir im Test-Event V2 spezifiziert).


Mal ganz unabhängig vom Test-Event: Muss ich bei Amazon in der Konsole irgendwo V3 spezifizieren?

Ich denke aber, dass ich das richtige Plugin nutze:
alexav3.PNG

Gruß,
Hendrik

[henfri]

Hallo Andre,
Vielen vielen Dank ich dachte ich hätte alle erwischt. Mir ist nicht ganz klar warum Amazon hier nicht für eine abwärtskompatibilität gesorgt hat das wäre ja recht einfach gewesen.
Ich spreche jetzt mal ins unreine:
Mein Vorschlag wäre dass sobald ein V3 Parameter erkannt wird V3 angenommen wird und dann eine Warning oder ein Error gemeldet wird wenn auch noch V2 auftaucht.

Ein zusätzlicher Parameter bringt wieder das Problem mit dass die Frage ist was der Default sein soll.
Die meisten werden den Parameter gar nicht setzen.
Ich denke heute sollte default V3 sein. aber dann bekommen natürlich alle die noch nicht umgestellt haben meine warning die gar nicht nötig ist.
wenn man V2 als Default macht bekommen alle die das Plugin neu einrichten und den Parameter nicht setzen eine warning.

Daher mein Vorschlag. Mein Vorschlag ist also quasi ein autodetect.

Viele Grüße und noch einmal vielen Dank für das tolle plugin,
Hendrik

[AndreK]

Hallo henfri ,

das der Lichterschlauch funktioniert ist schonmal gut, Deine Hinweise zur Doku nehme ich auf.
Zu Deinem Problem. Ich vermute Du hast Deinen Skill auf Payload 3 umgestellt (sonst würde ja der Lichterschlauch nicht funktionieren).
Dein Discovery-Response auf OneDrive ist noch in Payload V2, ich denke Du hast in der Lambda Testfunktion das Discovery noch mit Payload V2 abgesetzt.
Der Response zeigt Actions aus Payload V2 (V2 = turnOn / V3 = TurnOn). Ich denke wenn Du alle Actions auf V3 umstellst hast Du alle
Geräte auch in der App.

Da das Plugin beim Validieren (erfolgt beim Start von smarthomeNG) der Devices im Moment nicht weiß welcher Payload beim Skill eingestellt ist kann hier keine Prüfung erfolgen.
Man könnte einen zusätzlichen Parameter in etc /etc/plugin.yaml einführen um dann zu prüfen ob alle Actions für die richtige Payload-Version parametriert sind.

Meinungen zum zusätzlichen Parmeter ?

Gruss Andre

[henfri]

Hallo,

neuer Post für ein weiteres Problem:
Es tauchen nicht alle Geräte, die ich in den Yamls definiert habe in der Alexa-App auf. Auch nachdem ich nach neuen Geräten gesucht habe.
Ich habe in den Yamls nach alexa_name gesucht: 51 Ergebnisse.
Ein Read-Request unter
https://eu-west-1.console.aws.amazon.com/
ergibt 50 Ergebnisse. Der ganze Output hier:
https://1drv.ms/t/s!AvbzKdYzkh6gkgWT...ddMdN?e=P4xaeo
In der Alexa-App finden sich nur 29 Geräte aus sh.py.
Allerdings reagieren auch Geräte, die nicht in der App sind (z.B. "Ecklampe") mit dem Bestätigungston, schalten aber nicht.
Ich meine aber dass es auch Geräte gibt, die nicht in der App sind, aber normal funktioniern.

Woran kann das liegen?

Gruß,
Hendrik