tester gesucht: alexa-fhem reverse proxy & offizieller skill

Begonnen von justme1968, 16 Januar 2018, 17:47:54

Vorheriges Thema - Nächstes Thema

justme1968

hallo zusammen,

ich bin ja schon eine weile dabei aus alexa-fhem einen offiziellen skill zu machen. dazu ist es prinzipiell nötig einen cloud dienst zu haben der die zuordnung amazon account zu fhem installation treffen kann. der fhem verein ist bereit diesen dienst auf der vereins hardware laufen zu lassen.

damit es auch weiterhin nicht nötig ist fhem selber nach aussen zu öffnen oder zentral zugangsdaten zu hinterlegen ist die idee weiterhin lokale alexa-fhem instanzen zu haben, aber zusätzlich einen zentralen alexa-fhem reverse proxy zu dem sich die lokalen alexa-fhem instanzen verbinden.

für die verknüpfung des amazon accounts mit der fhem installation wird es eine dezentrale oauth komponente geben.

das ganze ist (erst mal) nur für die funktionen des smart home skills relevant

damit werden die folgenden punkte abgedeckt:
- fhem selber muss weiterhin nicht nach aussen geöffnet werden
- es ist weiterhin nicht möglich von aussen beliebige kommandos an ein lokales fhem zu senden
- das port forwarding wird nicht mehr nötig sein. alexa-fhem baut die verbindung von innen nach aussen zum proxy auf
- ein ipv6/ipv4 mapping sollte automatisch mit erledigt sein
- der proxy speichert keinerlei daten (auch nicht die zuordnung zwischen amazon anmeldung und fhem) sondern
  vermittelt nur die alexa events.

aktueller stand:
- eine erste version des reverse proxy ist fertig
- wenn der test mit den ersten anwendern (s.u.) erfolgreich ist wird es in schritt zwei die oauth komponente geben
- und als letztes dann den offiziellen skill
- eventuell (für ganz faule ohne datenschutz und -sicherheits bedenken ;)) gibt es danach vielleicht noch eine
   möglichkeit ohne alexa-fhem auszukommen. hierzu würden bestimmte komponieren dann direkt ins fhem
   alexa modul integriert


der erste test um den es jetzt geht soll nachweisen:
- das der reverse proxy wie vorgesehen funktioniert
- das es möglich ist die events fehlerfrei zu muliplexen
- das es möglich ist ohne zentrale datenspeicherung auszukommen
- es wird noch keine oauth komponente geben (d.h. es wird noch jeweils eigene private skills geben)
- es wird aber schon möglich sein einen einzigen zentralen aws lambda code zu verwenden

um das ganze zu testen bin ich auf der suche nach 2-3 freiwilligen die bereit sind zu testen:
- der/die jenige sollte schon einen eigenen skill eingerichtet haben und bereit sein das noch mal zu tun.
- alexa fhem sollte tatsächlich benutz werden ;)
- lage sein parallel zur eigenen produktiv/routine installation eine zweite alexa-fhem instanz aufzusetzen
  die erst mal nur einige wenige test geräte steuern wird
- am liebsten mindestens je 1x reines ipv4, reines ipv6, 1x dual stack


gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

juemuc

3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

jneroes


MadMax-FHEM

Hallo Andre,

mit IPV4 könnte ich dienen.

Aktuell teste ich Alexa gegen Google Home (läuft also eh schon so einiges parallel)...

Allerdings habe ich nur noch ein paar Tage Zeit, dann bin ich leider erst mal dienstlich bedingt ca. 2-3 Wochen weg :-|

Wo gibt's die Anleitung?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Chris8888

#4
Hallo Andre,

das sind wirklich gute Nachrichten! Klasse!

Gerne versuche ich zu helfen.
Ich habe einen Telekom-Anschluss mit IP v4&6 (dual Stack).
2 Alexa-Devices und heute 1x V2-Skill, aber nur den Einfachen, also ohne CustomSkill.

Ich hoffe, du hast keine zu hohen Erwartungen an Zeit und Linux-KnowHow...beides ist nur begrenzt vorhanden. ;-)

Viele Grüße
Christian
FHEM 6.0 auf einem PI4 mit div. Homematic-Komponenten, Alexa, Tablet-UI und Homebridge...und läuft einfach. Erweitert mit CCU3 und Homematic-IP...und läuft immer noch.

Thyraz

Verstehe ich das richtig, dass Nutzer dann später kein AWS Lamda mehr einrichten müssen oder dort Code pflegen?
Wird also hauptsächlich eine extreme Vereinfachung für neue Nutzer, oder?

Klingt auf alle Fälle super. :)

Gibt es denn sonst noch Vorteile (außer Port öffnen nicht mehr nötig und einer Lösung für IPV6/DSLite geplagte Unitymedia Kunden) oder Features die du dir dadurch in Zukunft erhoffst?


Zwecks testen:
Hätte das normal sehr gerne übernommen,
habe aber gerade beruflich zu wenig Zeit um das so intensiv zu testen, dass ich einer von 2-3 Testern sein sollte. ;)
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

owltownalf

Hallo,

würde auch testen.
Habe bisher noch nichts mit Alexa unter fhem gemacht und würde auf jeden Fall Unterstützung bei der Installation benötigen.

Ich habe zwei PIs mit fhem laufen und seit kurzem 2x Echo dot und 2x Sonos One (mit Alexa) in mein Haus einziehen lassen, und möchte nun auch meine fhem-Aktoren (homematic Heizung, Dimmer, Rolladenschalter, Intertechno, Fritz!Dect200,...) per Alexa kontrollieren.

Internet per 1&1, sollte IP4 sein.

Schönen Abend noch
Viele Grüße


OwltownAlf

no_Legend

Hi Andre,

kann auch testen.
Habe ein Multi WAN Setup, per PFsense.
IPV4 und IPV6 per KabelBW und eine DSL nur IPV4 per O2DSL.

3x mal Echo Gen2

Mit Alexa bisher nichts in FHEM gemacht.

Gruß Robert
IntelNUC mit Ubuntu mit FHEM immer aktuell,2x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
HM-SEC-KEY,HM-LC-BL1-FM,HM-SEC-SD,HM-Sen-DB-PCB,HM-Sec-RHS,HM-Sec-SC-2,HM-WDS10-TH-O,Harmony,Netamo, 433MHz Steckdosen uvm.

justme1968

schon mal danke für die vielen meldungen bisher.

ich brauche noch etwas bis die infrastruktur eingerichtet ist und melde mich dann wieder. für den aller ersten test wäre es gut wenn der/die freiwillige schon mal alexa-fhem installiert und konfiguriert hat.

das ganze ist war für die zukunft darauf ausgerichtet das einfach alles (oder so viel wie möglich) automatisch geht, das ist aber erst schritt zwei ;).
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Benni

#9
Hallo Andre,

ich erkläre mich auch gerne für Tests bereit!
Alles was Alexa, bzw deren Einrichtung einfacher macht finde ich gut ;)

Wenn ich es richtig verstanden habe geht es hierbei erst mal um die Umsetzung des Smarhome-Skills.

Ich arbeite derzeit vor allem über den Custom-Skill und die fhem-intents.

Ich gehe mal davon aus, dass ein Parallel-Betrieb weiterhin möglich ist.

alexa-fhem läuft bei mir sowieso auf einem separaten Raspberry, von daher ist neu aufsetzen/einrichten kein Problem.
(werde vorab schon mal ein aktuelles Image aufsetzen)

Bei mir stehen und lauschen derzeit 3 Dot und 1 Echo.

Gruß Benni.






sbiermann

Ich kann aus der neuen Alexa Version ein Docker Image machen, dann kann man gleich mehrere Versionen parallel auf einen Rechner betreiben und somit vergleichen.

justme1968

docker ist garnicht nötig um alexa-fhem mehrfach laufen zu lassen :). trozdem danke für das angebot. vielleicht nützt es ja jemandem.

mehr zum testen wie gesagt demnächst.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

no_Legend

Andre,

sollen wir nach Wiki installieren inklusive Developer Skill bei Amazon?

Gruß Robert
IntelNUC mit Ubuntu mit FHEM immer aktuell,2x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
HM-SEC-KEY,HM-LC-BL1-FM,HM-SEC-SD,HM-Sen-DB-PCB,HM-Sec-RHS,HM-Sec-SC-2,HM-WDS10-TH-O,Harmony,Netamo, 433MHz Steckdosen uvm.

justme1968

ja. da es erst mal nur um die weiterleitung geht und die authentifizierung erst danach kommt ist der developer skill noch voraussetzung. eine ganz normale installation noch wiki (smart home skill reicht) und damit ein paar geräte schalten ist eine gute vorbereitung.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

no_Legend

Danke.

Alles klar ich schau mal wie weit ich komme.

Gruß Robert
IntelNUC mit Ubuntu mit FHEM immer aktuell,2x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
HM-SEC-KEY,HM-LC-BL1-FM,HM-SEC-SD,HM-Sen-DB-PCB,HM-Sec-RHS,HM-Sec-SC-2,HM-WDS10-TH-O,Harmony,Netamo, 433MHz Steckdosen uvm.

justme1968

hallo zusammen,

der test wird sich leider noch etwas verzögern da mir zwei dinge dazwischen gekommen sind. ein mal etwas privates und zum anderen eine mail von amazon dazu beta test das notifikation api.

mit dem notification api ist es möglich nachrichten an einen echo zu schicken. vermutlich wird nur das vorhandensein angezeigt und man muss dann zurück fragen. aber immerhin.

die notifications möchte ich gerne noch in den test mit einbauen. leider funktioniert es noch nicht und ich weiss nicht ob ich etwas falsch mache, die doku fehlerhaft ist, oder ob noch etwas freigeschaltet werden muss.

die echo show und spot können scheinbar zumindest text nachrichten direkt anzeigen. das kann ich aber nicht testen da ich die nicht habe.

ich melde mich sobald es mehr gibt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Groej

Hallo,

super Idee das Ganze. Ich hab meinen Smarthome Skill zwar im Moment nicht in Betrieb weil ich vor kurzem den Raspi gewechselt habe aber wollte ihn wieder in Betrieb nehmen.

Hab einen Echo Dot und der Spot ist bestellt und soll ja bald kommen.

Gruß

Jörg
FHEM - RaspPi2 - KNXD - KNX - CUL 868 - FS20 - HMS - WH3080 - Signalduino 433 MHz - Telegram - Anel Elektronik IP Steckdosen - BME280

Kai-Alfonso

Hallo,

ich würde mich auch gerne zum testen anbieten. Ich selber nutze schon recht lange den Alexa Smarthome Skill und für meine Rollladen den Custom Skill. Zu Hause habe ich ein Dot und ein normales Echo. Gute Idee übrigens - ich bin jetzt nicht so der Fan von Smarthome Komponenten, die eine Cloud benötigen und Alexa war da eine riesige Ausnahme, die ich gemacht hat. Ich mach halt nicht gerne Port Forwarding :-)
Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)

flipkill

Hallo,

auch ich kann gerne als Tester dienen :) Kann sowohl eine feste IPv4 als auch eine feste IPv6 bieten :)

Gruß Jan

steve6502

Ich wäre auch dabei. Anbindung ist ip4&6 bei Fritzbox mit täglich wechselnder IP.

Einen Echo Spot zum Anzeigen von Nachrichten habe ich auch hier stehen. Übrigens tauchen beim "normalen" Echos dann nicht einfach "Cards" in der Alexa App auf? Oder sind Cards und Notification zwei verschiedene Dinge?

Gruß S.

steve6502

@justme1968 btw wäre es nicht am einfachsten, die bestehende Lambda Funktion zu lassen und nur um einen db basierten lookup für Host und Port zu erweitern?

Wenn die Persistenz dafür eine z.b. eine DynamoDB von AWS ist, dann brauchst Du nur noch eine Seite hosten, die die Verknüpfung des Amazon-Kontos mit der Host-Port-Angabe abfrägt und persistiert. Diese Seite selbst nutzt Oauth naheliegender Weise LWA dann hast direkt die Identität um den Lookup zu machen.

Was in der Tat immer noch gemacht werden müsste ist die Port Freigabe.

Gruß S.

justme1968

abgesehen davon das ich nicht sicher bin ob es wirklich einfach wäre... es hätte die folgenden nachteile:

- port forwarding immer noch nötig
- ipv4/ipv6 problem immer noch da
- zentrale datenhaltung
- irgend eine art von user registrierung/abmeldung nötig
- zusätzliche kosten durch DynamoDB

die angedachte proxy lösung hat dagegen den vorteil:
- kein port forwaring nötig
- keine registrierung nötig
- keine persistente datenhaltung
- der benutzer startet bei sich zuhause den dienst wenn er ihn verwenden möchte und stoppt ihn wieder
  wenn er das nicht mehr möchte.

das es weder eine registering noch eine permanente datenhaltung gibt halte ich aus mehreren gründen für wichtig:
- gebot der datensparsamkeit
- was nicht gespeichert ist kann nicht missbraucht werden
- wenn nichts gespeichert ist gibt es auch keine Verantwortlichkeit für gespeicherte daten

im übrigen geht das ganze im prinzip schon. ich hatte meine lokale instanz schon so laufen. d.h. das forwarding
   problem (inklusive ipv6) ist gelöst. ich muss nur noch schauen wie das skaliert.


die eigentliche herausforderung ist der oauth teil und der ist bei beiden varianten mindestens gleich aufwändig.

ich warte aktuell immer noch auf eine vernünftige antwort von amazon wegen dem notification api. die rückmeldung die ich bisher bekommen habe ging leider komplett am thema vorbei.


notification und cards sind erst mal zwei verschiedene dinge. ein skill kann aktuell nur aktiv werden wenn der benutzer per sprache irgend eine interaktion startet. die antwort darauf kann dann eine gesprochene ausgabe sein oder ein card die dann bei passendem device oder in der app angezeigt wird.

die notification erlauben es einem skill von sich aus (ohne das der anwender die interaktion gestartet hat) aktiv zu werden und dem benutzer anzuzeigen das es 'etwas neues gibt'.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

steve6502

#22
Hi,

kann gut sein, dass ich nicht komplett verstanden habe wie deine Lösung genau funktioniert, aber ich sehe zwei Herausforderungen:

1. Skalierung: der RProxy muss viel incoming Connections halten, das skaliert viel schlechter als eine Lambda Funktion die dipatched.

2. Zuordnung der Connections zu einem Alexa Request ohne zentrale Datenhaltung. Wie soll das denn gehen. Wenn der Skill installiert wird erhält
das Alexa System ein Access Token des jeweiligen OAuth Providers z.B. LWA. Den Token kann man validieren (egal wo in der Aufrufkette) und zum
Abrufen bestimmter Profil Informationen benutzen (Amazon UserId bei LWA). Alexa-Fhem kennt aber das Access Token aber nicht und dem lokalen alexa-Fhem die Amazon ID mitzugeben reicht nicht, weil die ja nicht sicher ist. Die bekommt jeder, der auch LWA nutzt. Vielleicht sogar noch einfacher.

Wie also soll die zuordnung eines bestimmten Connects von aussen zu eine request vom Alexa Backend (lambda) funktionieren?

Gruß S.

justme1968

um 1. mache ich mir gedanken wenn es ein paar hundert oder tausend anwender gibt. bis dahin sollte das problemlos skalieren.

2. also.. das ist ganz einfach :)

der witz bei oauth ist ja gerade das man zu keinem zeitpunkt einem fremden system seine login daten übermitteln muss, sondern die autorisierung verteilt d.h. vom system das den benutzer kennt direkt selber gemacht wird. es gibt keinen grund das verteilen nicht noch weiter bis hin zum client zu machen. dann geht das ohne feste accounts, ohne registrierung und ohne shared secrets. nur mit einer jeweils lokal erzeugten id. diese muss der anwender ein einziges mal in seinem fhem system nachschauen und genau ein mal bei der initialen oauth anmeldung in die login maske eingeben.

unterm strich läuft es darauf hinaus das die zentrale datenhaltung durch eine gerade ausreichende menge an informationen in einem teil des token selber ersetzt wird. der restliche sensitivere teil des tokens ist jeweils mit einem key den nur der betreffende client kennt verschlüsselt. da jeder client nur seine eigenen daten entschlüsseln muss, gibt es keine verteilten schlüssel. da ein gutes kryptographisches system im prinzip nur von der sicherheit der schlüssel abhängt und hier die schlüssel niemals woanders als bei jedem einzelnen benutzer selber liegen funktioniert das ganze.

im folgenden gehen die bezeichnungen für die unterschiedlichen token arten etwas durcheinander. das ist aber in diesem fall egal weil die behandlung im prinzip gleich ist und jeder user lokal nur seine eigenen token verifiziert.


der oauth provider ist eben nicht mehr lwa sondern alexa-fhem bzw. der proxy. die token erzeugt aber jede installation selber. und validiert diese auch. der token besteht im prinzip aus mehreren teilen. einen teil der die zuordnung zu einem bestimmen benutzer erlaubt und einen teil der die autorisierung enthält. beides ist so verknüpft das beide teile nur genau in dieser kombination zusammen gültig sind.

wenn der anwender seinen lokalen dienst startet meldet er sich mit dieser id am proxy an. der proxy muss nur den id teil des tokens 'verstehen' um das komplette event dem richtigen empfänger zuzuordnen. jeder teilnehmer ist dann selber dafür verantwortlich auch den authorisierungs teil des tokens zu prüfen. den er ja auch selber erzeugt hat. das ganze funktioniert weil jeder nur seine eigenen daten prüft und nicht für jemand anderen. es müssen also keine secrets verteilt werden die es jemand anderm ermöglichen einen gefälschten authorisierungs teil für jemanden anders zu erzeugen.


auch der refresh der token läuft genau so ab. der proxy hat gerade genug information um den request zum richtigen client durch zu stellen. dieser erzeugt den neuen token und sendet ihn über den proxy zurück.


wenn der benutzer seine verbindung wieder zu mache gibt es keine zuordnung eines events zu einer existierenden verbindung mehr und amazon bekommt vom proxy einen 'client nicht erreichbar' fehler.


es gibt keine id/token/sonstige daten die besonders geschützt werden müssen. es sind immer mindestens zwei komponenten nötig damit ein event auch beim client ankommt. selbst wenn das token verloren geht erzeugt man sich ein neues und aktiviert den skill neu.


die id an sich ist nicht schützenswert. auch bei amazon nicht. zum einen ist sie nicht  mit einer identität oder sonstigen daten verknüpft, zum anderen bekommt jeder skill bei jeder aktivierung eine neue user id von amazon. es ist also nicht möglich den benutzer über mehrere anmeldungen hinweg zu verfolgen.

jeder der ein lwa token hat kann dies gegenüber dem amazon server verifizieren und bekommt eine zugehörige benutzer id. man kann also die id auch gleich als sichtbares teil des token haben.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

steve6502

okay verstanden, damit musst Du allerdings wirklich selber einen OAuth Provider bauen, den man so auch nicht "von der Stange" nehmen kann, weil Du die Token Erzeugung dezentral delegierst. Das ist sozusagen "der Preis" auf die zentrale Datenhaltung verzichten zu können, weil Du die gleiche Information quasi opaque im Token selbst unterbringst.

Clever, aber etwas aufwändiger als OAuth ala carte.

Gruß S.

coolice

Zitat von: justme1968 am 09 Februar 2018, 17:11:30
um 1. mache ich mir gedanken wenn es ein paar hundert oder tausend anwender gibt. bis dahin sollte das problemlos skalieren.

2. also.. das ist ganz einfach :)

der witz bei oauth ist ja gerade das man zu keinem zeitpunkt einem fremden system seine login daten übermitteln muss, sondern die autorisierung verteilt d.h. vom system das den benutzer kennt direkt selber gemacht wird. es gibt keinen grund das verteilen nicht noch weiter bis hin zum client zu machen. dann geht das ohne feste accounts, ohne registrierung und ohne shared secrets. nur mit einer jeweils lokal erzeugten id. diese muss der anwender ein einziges mal in seinem fhem system nachschauen und genau ein mal bei der initialen oauth anmeldung in die login maske eingeben.

unterm strich läuft es darauf hinaus das die zentrale datenhaltung durch eine gerade ausreichende menge an informationen in einem teil des token selber ersetzt wird. der restliche sensitivere teil des tokens ist jeweils mit einem key den nur der betreffende client kennt verschlüsselt. da jeder client nur seine eigenen daten entschlüsseln muss, gibt es keine verteilten schlüssel. da ein gutes kryptographisches system im prinzip nur von der sicherheit der schlüssel abhängt und hier die schlüssel niemals woanders als bei jedem einzelnen benutzer selber liegen funktioniert das ganze.

im folgenden gehen die bezeichnungen für die unterschiedlichen token arten etwas durcheinander. das ist aber in diesem fall egal weil die behandlung im prinzip gleich ist und jeder user lokal nur seine eigenen token verifiziert.


der oauth provider ist eben nicht mehr lwa sondern alexa-fhem bzw. der proxy. die token erzeugt aber jede installation selber. und validiert diese auch. der token besteht im prinzip aus mehreren teilen. einen teil der die zuordnung zu einem bestimmen benutzer erlaubt und einen teil der die autorisierung enthält. beides ist so verknüpft das beide teile nur genau in dieser kombination zusammen gültig sind.

wenn der anwender seinen lokalen dienst startet meldet er sich mit dieser id am proxy an. der proxy muss nur den id teil des tokens 'verstehen' um das komplette event dem richtigen empfänger zuzuordnen. jeder teilnehmer ist dann selber dafür verantwortlich auch den authorisierungs teil des tokens zu prüfen. den er ja auch selber erzeugt hat. das ganze funktioniert weil jeder nur seine eigenen daten prüft und nicht für jemand anderen. es müssen also keine secrets verteilt werden die es jemand anderm ermöglichen einen gefälschten authorisierungs teil für jemanden anders zu erzeugen.


auch der refresh der token läuft genau so ab. der proxy hat gerade genug information um den request zum richtigen client durch zu stellen. dieser erzeugt den neuen token und sendet ihn über den proxy zurück.


wenn der benutzer seine verbindung wieder zu mache gibt es keine zuordnung eines events zu einer existierenden verbindung mehr und amazon bekommt vom proxy einen 'client nicht erreichbar' fehler.


es gibt keine id/token/sonstige daten die besonders geschützt werden müssen. es sind immer mindestens zwei komponenten nötig damit ein event auch beim client ankommt. selbst wenn das token verloren geht erzeugt man sich ein neues und aktiviert den skill neu.


die id an sich ist nicht schützenswert. auch bei amazon nicht. zum einen ist sie nicht  mit einer identität oder sonstigen daten verknüpft, zum anderen bekommt jeder skill bei jeder aktivierung eine neue user id von amazon. es ist also nicht möglich den benutzer über mehrere anmeldungen hinweg zu verfolgen.

jeder der ein lwa token hat kann dies gegenüber dem amazon server verifizieren und bekommt eine zugehörige benutzer id. man kann also die id auch gleich als sichtbares teil des token haben.
Hallo, gibt es hier schon was neues?


Gesendet von iPhone mit Tapatalk

justme1968

leider noch nicht. ich hatte die ganze zeit auf antwort von amazon bezüglich des notification api gewartet. wurde aber immer wieder vertröstet. dann hatte ich ziemlich viel anderes zu tun.

sobald wieder etwas luft ist kommt eine erst test version ohne notification api.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

meddie

Hallo,

wie ist denn der Stand aktuell?

Danke
VG Eddie

justme1968

meine eigene version läuft aber es dauert leider noch etwas bis es weiter geht. mir ist etwas dazwischen gekommen. sorry.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Snooper166


jneroes


Markus M.

Wenn es irgendwann hoffentlich mal daran geht, den Skill auf Englisch zu testen, gib mir bitte Bescheid!


Zitat von: jneroes am 13 Juni 2018, 17:23:46Finde ich auch einen interessanten Ansatz.
https://skills-store.amazon.de/deeplink/dp/B07B9QMTFQ?deviceType=app&share&refSuffix=ss_copy
Unterstützt nur Lampen, Steckdosen, Schalter, Ventilatoren und Temperatur Sensoren - das ist leider nicht sehr viel.
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

oeiber


AlpenFlizzer

Hi Leute!

Ich bin mal so frei und erkundige mich nach den derzeitigen Stand der Dinge. Der letzte Beitrag ist ja schon etwas her...

Gibt es bezüglich diesem Thema etwas neues?

Grüße,
Sascha

awel

Hallo,
ich bin auch neugierig: Gibt es etwas neues oder ist das Projekt eines Alexa-Fhem-Skills eingeschlafen oder gar gestorben?
Gruß
awel

dadoc

Guten Abend,
Ich schaue so ca. alle drei Monate immer mal, ob es in Sachen fhem-Skill für Alexa Fortschritte gibt. Aber entweder suche ich falsch oder es geht tatsächlich nicht voran? Falls dem so ist: Was könnt man tun, damit es hier - fast zwei Jahre nach der Markteinführung in Deutschland - weitergeht? Ich habe zwar die bisherigen Lösungen ausprobiert, bin aber der Meinung, dass sie entweder weit unter den Möglichkeiten bleiben oder irre kompliziert sind und einem stetigen Wandel (lies: Nach-/Neukonfigurations-Bedarf) unterliegen. Und wenn man sich dann Skills wie die von IOBroker annschaut, kommt schon so etwas wie Neid auf...
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

awel

Zitat von: justme1968 am 24 Mai 2018, 10:21:35
meine eigene version läuft aber es dauert leider noch etwas bis es weiter geht. mir ist etwas dazwischen gekommen. sorry.
Das war die letzte Information, seitdem gibt es nicht einmal mehr Antworten auf Fragen.
Ich denke, das Vorhaben ist Geschichte. Schade.

Jetzt muss -wie immer- jeder für sich selbst entscheiden, wie wichtig ihm neuere Entwicklungen sind und ob er nicht bei einem Wechsel der Hardware auch gleich das ganze System wechselt. Bei mir steht bald ein Wechsel auf einen DS-Lite-Zugang an; das wird mit der jetzigen Fhem-Alexa-Lösung äußerst hampelig; der offizielle Smart-Home-Skill wäre eine prima Lösung gewesen. Vielleicht gehöre ich aber auch nicht mehr zur Zielgruppe von Fhem...
Grüße
Achim

dadoc

Vielleicht sollten wir André ein Stipendium ausloben, damit er mehr Zeit für das Alexa-Thema aufwenden kann;)  Er ist schließlich derjenige, der wohl am Tiefsten in dieses Thema vorgedrungen ist. Und er braucht für sich ganz bestimmt nicht einen allgemeinverständlichen Skill wie wir ihn brauchen :/
Klar, ich habe leicht reden, aber ich finde es mittlerweile in der Diskussion mit anderen IOTlern etwas peinlich, dass ausgerechnet fhem hier nicht vorankommt, zumal ich nicht erklären kann, was genau das Problem ist.
Ich für meinen Teil wäre bereit, einen Beitrag in einen Topf zu werfen, wenn das die Entwicklung (z.B. auch durch den Kauf evtl. notwendiger Hardware) voranbringt. Habe ich auch bei ftui und anderen Non-Profit-Projekten sehr gern getan.
André, sag an!
Grüße
Martin
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

raimundl

Ich möchte einen Beitrag von mir zu diesem Thema hier verlinken:

https://forum.fhem.de/index.php/topic,81534.msg846155.html#msg846155

Meines Erachtens fehlt hier die Information, ob das Projekt weiterentwickelt wird oder als beendet zu betrachten ist.

LG
Homematic: Licht, Heizung, Alarm, Alexa ... auf einen RaspberryPi3+mit OS "Stretch" und RPI-RF-MOD mit piVCCU3 (HMCCU), ca. 40 HM Komponenten, alexa, MobileAlerts, Hue Ledstripes....

dadoc

Ja, den Thread habe ich auch mit Interesse verfolgt, zumal ich an Standort 2 Zaps HMCCU im Einsatz habe.
Ich denke auch, dass eine klare Ansage von Andre hilfreich wäre - dann wüssten alle, woran sie sind. Aktiv ist er ja noch im Forum, wenn auch sehr sporadisch (zuletzt Ende Oktober).
Standort 1: FS20 mit CUL und FHEM auf Raspi. HM-Komponenten (Heizung, Rollladen, Schalter). HM IP über Raspimatic (testweise)
Standort 2: Homematic (Wired) über CCU2 und PocketHome HD
3 x Raspi3 mit piCorePlayer/Kodi für Multiroom Audio (+ Tablets/iPeng/iPods

Sailor

Hallo andre

Wie schon angeboten, ich wäre ebenfalls als Tester dabei.

Mit mir eine Zweisprachige Familie und meinen Söhnen im Grundschulalter, die arme Alexa seit Tagen nicht in Ruhe lassen.

Also wenn es Fehler zu finden gibt, dann werden die beiden kleinen Katastrophen-User sie finden!  ;D

Nur Mut Andre, vielleicht ist die Geschichte mit dem Stipendium gar nicht so eine schlechte Idee.
Eine zweckgebundene Spende an den fhem-Verein dürfte die Wahl der Mittel sein.

Gruß vom hintern-Deich
    Sailor
******************************
Man wird immer besser...

gvzdus

Hallo, ich habe die letzten Tage in die Tasten gehauen und eine Lösung "betatest-bereit".

Siehe hier: https://forum.fhem.de/index.php/topic,94817.0.html

Amenophis86

Hier hatte sich ja einiges getan durch den connector etc aber geht inzwischen auch die eigenständig Push Notification? Das hattest du mal in ein paar Posts vorher gesagt Andre, dass das kommen soll.

Und ja, das alexa Modul ist mir bekannt, mag ich aber nicht :)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

justme1968

der thread hier hat sich in zwischen erledigt da alles in den fhem connector skill eingeflossen ist und dort umgesetzt wurde.

der prinzipielle mechanismus aus alexa-fhem daten an amazon zu senden ist implementiert und wird beim set <alexa> add <name> kommando verwendet um die amazon seite zu aktualisieren ohne alexa-fhem neu zu starten.

das damals von amazon angekündigte api für push hat amazon nicht weiter verfolgt und eingestellt. die neue version die das ganze ersetzen soll gibt es aktuell nur in amerika. wie leider ein paar andere features auch.

es bleibt nur zu warten...
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

MadMax-FHEM

Zitat von: Amenophis86 am 24 März 2019, 10:22:45
Und ja, das alexa Modul ist mir bekannt, mag ich aber nicht :)

Warum?

Ich bin ja mit dem "nicht-Alexa-Modul" schon seit Beginn unterwegs (auch alle "alten" Varianten, noch von Markus)...
...und habe auch lange gehadert... ;)

Aber seit der Umstellung auf NPM-Login läuft es erstaunlich gut.
Daher bin ich grad beim Umzug von meinem Testsystem auf mein "Pre-Hauptsystem" (dort kommt erst mal alles noch mal "sauber installiert" eine zeitlang hin [auch wegen Speicherfresser etc.] bevor es dann auf das Hauptsystem kommt)...
Wenn es bis Ostern ohne Probleme läuft kommt es auf's Hauptsystem :)

Wie geschrieben langsam macht es einen guten Eindruck und einiges lässt sich halt schön damit umsetzen...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Amenophis86

Zitat von: MadMax-FHEM am 24 März 2019, 11:01:34
Warum?

Weil der Login bisher immer wieder Probleme gemacht hat, damit nicht zuverlässig war und somit für mich keine Option :) Verfolge aber die Entwicklung und bin gespannt, wie es sich mit dem NPM weiter entwickelt.

Zitat von: justme1968 am 24 März 2019, 10:40:09
das damals von amazon angekündigte api für push hat amazon nicht weiter verfolgt und eingestellt. die neue version die das ganze ersetzen soll gibt es aktuell nur in amerika. wie leider ein paar andere features auch.

Mmmmh danke für die Info, dann muss ich wohl weiterhin noch warten und hoffen.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...