Amazon-Echo und KNX-Anbindung

[Hotstepper13]

Ich glaube das kam falsch an... das Alexa eine Internetverbindung braucht ist klar. Diese ist aber "nur" ausgehend, sprich das Echo kontaktiert den Amazon Webservice und auf der gleichen Verbindung kommt die Antwort vom Webservice.

Bei der HABridge wird augenscheinlich im Anschluss ein Request vom Echo direkt an die HABridge (also im internen Netzwerk) durchgeführt. Das Setup für den Logikbaustein läuft aktuell so dass das Echo den Lambda Service kontaktiert und dieser von aussen eine Verbindung in das interne Netzwerk (an eine sehr zentrale komponente) öffnet. D.h. ich muss mich mit dyndns, offenen Ports und ähnlichem Rumschlagen und dafür sorgen das diese entsprechend abgesichert sind.

Ich habe nun erstmal den Baustein installiert und eingerichtet. Werner beschreibt in seiner (übrigens sehr ausführlichen) Doku selbst das man optimalerweise einen ReverseProxy nutzen sollte. Da ich mit meinem Internetanschluss durchaus mal länger als einen Monat am Stück online bin, kann ich diverse kostenfreie dyndns dienste nicht nutzen und werde mir da wohl mit dem reverseproxy selbst etwas zurecht basteln.

Ich hoffe das die Frage nun etwas klarer rüber kommt

Gruß
Frank

[viceversa]

Bei mir hat die HA-Bridge auf der Synology einwandfrei funktioniert, bis ich ein Firmwareupdate auf der Synology gemacht habe.
Es gibt auch eine neue Version der HA-Bridge (Synology). Ich habe alles neu aufgesetzt, jedoch leider nicht die udp-Aufrufe notiert.

Daher weiß ich nicht mehr wie die UDP-Kommandos in Richtung Homeserver waren. Kann das noch mal jemand posten. Die Dropbox-Links funktionieren leider nicht.

Die Befehle lauteten etwa so: udp://192.168.1.xxx:8899/0x460005 Ich bin mir mit der Schreibweise /Syntax nicht sicher.

Danke!

[wernerL]

Hallo Frank,

ich fände es auch viel besser wenn die Anbindung des Echo an das interne Netzwerk im Prinzip so ähnlich ablaufen würde, wie das z.B.: Logitech mit MySqueezebox.com gemacht hat.
D.h. der Echo-KNX Adapter (also in meinem Fall der Logikbaustein) baut beim Start eine Verbindung zu einem (zu entwickelnden) Webservice auf und hält zur Nutzung des Rückkanals (für die Requests vom Echo) diese Verbindung offen. Dann könnte man sich, wie du ja auch geschrieben hast, den ganzen Aufwand mit Dyndns, Portweiterleitung, SSL(TLS) und den hierfür notwendigen Absicherungen sparen. Wie man dies, in Verbindung mit einem Lambda-Service umsetzen könnte, müsste man allerdings noch evaluieren.

Wenn man nun vom eigentlichen Entwicklungsaufwand hierfür absieht, wäre es meiner Meinung nach absoluter Overkill, wenn jeder einzelne Benutzer diese Infrastruktur installieren, konfigurieren und betreiben müsste. Das Betreiben der Lambda-Funktion ist zwar kostenlos (zumindest für die Anzahl Anfragen und Rechenzeit welche für einen einzelnen Haushalt anfallen dürften), für den Betrieb des zusätzlichen Webservices würden aber wohl Betriebskosten entstehen.
Somit würde es meiner Ansicht nur Sinn machen, wenn man diesen Dienst im Prinzip analog zu MySqueezebox.com, einmalig für alle Benutzer zur Verfügung stellen würde. Dann müsste auch nicht jeder Benutzer diesen Amazon-Konfigurationswahnsinn durchmachen. Allerdings tauchen damit wiederrum weitere Anforderungen auf: Ausfallsicherheit, Lastverteilung, ...

Ich fürchte es gibt zuwenige Amazon Echo-KNX Benutzer, welche bereit wären sich an den Entwicklungsaufwand und den laufenden Betriebskosten hierfür zu beteiligen.
Mal sehen was die Zukunft bringt, vielleicht zeigt sich ja Gira innovativ und bietet zur Anbindung des Echo an den Homeserver doch noch einen eigenen Cloud-Service an.

Viele Grüße
Werner

[Hotstepper13]

Hallo Werner,

ich stehe ja noch am Anfang der Einrichtung (gestern hab ich den Homeserver vorbereitet, die Config eingespielt, nen neuen vhost auf meinem Server angelegt).

Sobald ich in den Bereich der "Skills" komme, hoffe ich da etwas mehr Einblick zu bekommen und vielleicht was machen zu können. Der Vorteil ist das ich beruflich im Rahmen der IT von allem etwas mitbringe. Da die HABridge augenscheinlich auch direkt vom Echo angesprochen werden kann, muss es also irgendwelche Lösungen dafür geben. Dein Service für den Homeserver ist wirklich cool. Vor allem das man updates an der Struktur machen kann ohne den Homeserver neu zu deployen finde ich echt klasse. Wenn ich diesbezüglich etwas rausfinde, würde ich mich mit dir in Verbindung setzen, vielleicht kann ich da ja auch etwas beisteuern

Beste Grüße

Frank

[wernerL]

Hallo Frank,

gerne, wenn du noch was wissen möchtest, oder was beisteuern kannst melde dich.

Gruß Werner

[gunnar]

Das Problem mit dem HS SSL Server sehe ich tatsächlich als gravierend an. Ich habe gerade mit Erschrecken festgestellt das mein Homeserver noch auf der alten 4.2 läuft und aktuell die 4.5 verfügbar ist. Die ist von November 2016 und ich würde erwarten das da ein potentieller Fix enthalten ist.

Nein, um die SSL Problematik zu beheben braucht es ein komplettes Platform-Update (Linux, Python, Libs). Das macht man nicht in einem .x Produktionszweig. Dafür braucht es ein neues Major Release. Ich glaube nicht, dass da wirklich was passiert aktuell.

Nun erwäge ich auch noch eine Kombination der Lösungen. Ich habe einen eigenen (gemieteten) Server im Netz stehen. Diesen würde ich von meiner Fritzbox kontaktieren lassen um ihm die IP mitzuteilen (quasi als dyndns ersatz).

Davon rate ich ab. Es behebt das Problem nicht wirklich, da der Kanal von außen hin weiter offen ist. Unverschlüsselt wäre sogar noch schlimmer. Wenn du wirklich eine Absicherung machen möchtest, dann muß zwangsläufig ein SSL Reverse Proxy als Gateway in deinem Heimnetzwerk vorgeschalten sein. Idealerweise in einer DMZ, das wird aber nicht jeder so einfach zu Hause haben. Noch besser wäre eine Servlet auf dem Gateway, dass die Requests annimmt, inspiziert und dann nur gültige an den HS durchläßt.

Ich weiß noch nicht genau wie das Teil funktioniert, hoffe aber das bei einer direkten Anbindung (wie z.B. bei der HA Bridge) auch ohne internetverbindung noch eine interaktion möglich ist.

Das funktioniert nicht. Für das Verstehen der Sprache ist zwingend eine Internet-Anbindung erforderlich, selbst wenn die "Schalt-" Befehle lokal vom Echo abgesetzt werden könnten.

Bei der HABridge wird augenscheinlich im Anschluss ein Request vom Echo direkt an die HABridge (also im internen Netzwerk) durchgeführt.

Das liegt daran, dass der Hui Skill, der direkt von Amazon kommt, das so umsetzt. Ob das technisch bei einem HomeServer Skill auch gehen würde, weiß ich nicht. Es sieht nicht danach aus. Die meisten Skills arbeiten mit einem WebService zusammen.

D.h. der Echo-KNX Adapter (also in meinem Fall der Logikbaustein) baut beim Start eine Verbindung zu einem (zu entwickelnden) Webservice auf und hält zur Nutzung des Rückkanals (für die Requests vom Echo) diese Verbindung offen. Dann könnte man sich, wie du ja auch geschrieben hast, den ganzen Aufwand mit Dyndns, Portweiterleitung, SSL(TLS) und den hierfür notwendigen Absicherungen sparen. Wie man dies, in Verbindung mit einem Lambda-Service umsetzen könnte, müsste man allerdings noch evaluieren.

So macht es die Konkurrenz (openHAB 2). Ist aktuell auch noch ein bischen gefummel, aber es wird daran gearbeitet, dass man ein ETS Projekt direkt importieren kann und dann die Gruppenadressen drinnen hat. Der openHAB Service ist auch Open Source. Die Betriebskosten finanziert eine Foundation über Mitgliedsbeiträge.

Ähnliches müßte Gira eigentlich gerade entwickeln, wenn man das Thema nicht verschlafen will. Die Infrastruktur ist ja schon da.

-Gunnar

[Hotstepper13]

(Narf.. beim quoten ist der geschrieben text gelöscht worden.. also nochmal)
Soweit ich die Alexa Doku verstanden habe besteht die Einschränkung darin welche API man benutzt. Um Befehle im lokalen Netzwerk absetzen zu können, muss die HomeAutomation API (oder so ähnlich) verwendet werden. Ich bin noch nicht ganz durchgestiegen aber es sieht aktuell so aus als wenn diese API eine sogenannte Bridge anspricht. Die Hue Bridge ist die bekannteste und diese wird auch aktuell bei der HABridge emuliert. Deshalb ist der Funktionsumfang so eingeschränkt.

Es gibt aber noch andere Produkte, z.B. von Honewell, die danach aussehen als wenn sie Heimautomatisierung vollständig unterstützen würden.

Nein, um die SSL Problematik zu beheben braucht es ein komplettes Platform-Update (Linux, Python, Libs). Das macht man nicht in einem .x Produktionszweig. Dafür braucht es ein neues Major Release. Ich glaube nicht, dass da wirklich was passiert aktuell.

Nun das hängt davon ab welcher Prozess an dieser Stelle die SSL Funktionalitäten bereistellt. Ich gehe davon aus das ein Firewareupdate beim Homeserver gleichzusetzen ist mit einem Betriebssystemupdate und nicht einfach nur eine neue Software einspielt.

Davon rate ich ab. Es behebt das Problem nicht wirklich, da der Kanal von außen hin weiter offen ist. Unverschlüsselt wäre sogar noch schlimmer. Wenn du wirklich eine Absicherung machen möchtest, dann muß zwangsläufig ein SSL Reverse Proxy als Gateway in deinem Heimnetzwerk vorgeschalten sein. Idealerweise in einer DMZ, das wird aber nicht jeder so einfach zu Hause haben. Noch besser wäre eine Servlet auf dem Gateway, dass die Requests annimmt, inspiziert und dann nur gültige an den HS durchläßt.

Durch die Verwendung eines Reverseproxy kann man aber die Portfreigabe auf eine statische IP einschränken und hat somit ein plus an Sicherheit weil der ReverseProxy selbst durch aktuelle Libraries "gesichert" ist.

@Werner
Hattest du in Richtung HomeAutomation API etwas geforscht?

Beste Grüße

Frank

[wernerL]

Hi Frank,

meinst du damit, ob ich mich allgemein über Home Automation API's informiert habe?
Nein, ich habe mir nur die Smart Home API von Amazon angeschaut und wollte diese eigentlich auch nur als "Proof of Concept" umsetzen, um zu evaluieren ob eine direkte Anbindung an den Gira Homeserver realisierbar ist und die "Antwortzeiten" im vertretbaren Rahmen liegen.
Den Custom Skill habe ich dann später "draufgesetzt", wobei ich immer mehr feststellen muss, das ich durch den doch sehr generischen Ansatz der Konfigurationsdatei an Grenzen Stoße was die Umsetzung gewisser Features angeht (z.B.: Definition und Steuerung von Raffstores mit Lamellenverstellung).

Gruß Werner

[wernerL]

Hi Frank,

ich bin bei meiner Suche bzgl. Amazon Echo und Long-Polling auf folgenden Forum-Eintrag gestoßen:

One of the things that is currently being leveraged by other skills is SQS: https://aws.amazon.com/sqs/ It's still going to require a device inside your network, but no inbound port requirements as it's based on long polling.
The Echo-Sonos skill @ https://github.com/rgraciano/echo-sonos has an example, and I used the idea recently to port my own HA hub's skill to SQS to eliminate my port forwards.

Damit könnte evtl. das Umsetzbar sein, was ich oben angesprochen habe.

Ich habe mir daraufhin die AWS-Seite bzgl. der Kosten für SQS angeschaut:

Amazon SQS kostenloses Kontingent*
Der Einstieg in Amazon SQS ist kostenlos. Alle Kunden erhalten jeden Monat ein kostenloses Kontingent von 1 Mio. Amazon SQS-Warteschlangenanfragen. Einige Anwendungen können ggf. im Rahmen dieses kostenlosen Kontingents ausgeführt werden.

Als einzelner Haushalt dürfte man da wohl drunter bleiben.
Ich schaue mir das bei Gelegenheit mal genauer an, ob damit etwas möglich wäre.

Viele Grüße
Werner

[Hotstepper13]

Ich habe gestern nochmal ein wenig recherchiert... theoretisch haben wir alles in unserem Netz was wir brauchen um den Homeserver direkt mit Alexa zu verbinden.

Die HomeAutomation funktioniert wohl in der Regel mit einem Discovery (DAS dürfte bei uns der Knackpunkt sein). Das Echo sucht im eigenen Netz mittels Broadcast (also Netzwerkanfrage an "alle" adressen) nach entsprechenden Devices und diese werden dann vom Echo direkt angesprochen. Dabei kommt wohl u.a. upnp zum Einsatz.

Einen sehr interessanten Artikel habe ich dazu auf englisch gefunden: http://www.makermusings.com/2015/07/...me-automation/

Darüber hinaus gibt es wohl auch den IOBroker, der bereits einen fertigen Alexa Skill mitbringt, allerdings genau wie die HABridge ein Stück Infrastruktur im eigenen Netzwerk braucht und auch wieder aus der Cloud angesprochen wird. Könnte die Installation vereinfachen aber nicht die Dinge lösen die ich gerne umgehen möchte. Ich versuche gerade die Installation auf meiner Synology, bin aber irgendwie schon total abgeschreckt wie komplex das doch alles ist.

Nach meinem Verständnis hat der Homeserver bereits alle Daten die wir brauchen würden um eine Erkennung durch Alexa zu ermöglichen. Über die Visualisierung wissen wir welche Funktionalitäten ein Device zur Verfügung stellt bzw. welche Befehle das Device ausführen kann.

Wenn ich das richtig sehe, wurde der IOBroker Skill auch von einem "freien" Entwickler erstellt und als offizielles Alexa Plugin Integriert. Die Frage ist nun also welche Möglichkeiten haben wir um dem Homeserver die notwendigen Discoverymechanismen beizubringen. Dann kann man entweder überlegen ob man eine bestehende Integration (wie z.B. Wemo in obigem Beispiel) verwendet oder versucht eine direkte Integration selber zu schreiben.

Deinen Fortschritt bei der Erstellung eines eigenen Webservers als Logikbaustein zu Grunde gelegt, dürfte es auch machbar sein dort ein upnp discovery irgendwie hinzufriemeln.

Was ich allerdings nicht abschätzen kann ist die Sicherheitsauswirkung im lokalen Netz. Soweit ich upnp richtig verstanden habe, würde jeder Client der im lokalen Netz unterwegs ist und die entsprechenden upnp pakete beachtet damit auch Zugriff auf Automatisierung bekommen. Damit würde es reichen ein wlan zu hacken um die "begrenzte" Kontrolle über die Automatisierung übernehmen zu können. Du hast ja bereits einen Lookupmechanismus implementiert, bei dem man die gesamte Konfiguration als json auslesen kann. Ich könnte mir also vorstellen das wir es nur hinbekommen müssen das Alexa diese Informationen "findet" und daraus die richtigen Befehle ableitet.

Wenn das funktioniert, bräuchte man keine Lamda Services, Portforwardings oder ähnlichen Schnickschnack mehr. Die Internetverbindung würde nur noch ausgehend benutzt um die Sprache zu synthetisieren. Alles andere bleibt im lokalen netz.

Gruß
Frank

[wernerL]

Hallo Frank,

ich habe im Thread "Amazon-Echo Logikbaustein" zu dem Thema Sicherheitsauswirkungen auch noch etwas geschrieben.
Nachdem dieses Thema doch sehr Logikbaustein spezifisch ist, würde ich vorschlagen, dass wir uns darüber in dem anderen Thread weiter unterhalten.

Gruß Werner

[viceversa]

Hier noch mal die Lösung wie man die Verbindung zwischen dem Echo und dem Homeserver mit Hilfe einer Synology Diskstation herstellen kann.
Voraussetzung ist die Installation der HA-Bridge auf der Synology Diskstation nach dieser Anleitung:

https://en.robbshop.nl/about-z-wave/...n-via-synology

Und so wird die HA-Bridge (V4.1.4) und der Homeserver (IP-Telegramme empfangen) konfiguriert:

Im zweiten Bild (Homeserver) muß in der Registerkarte Befehle natürlich noch der entsprechende Eintrag gemacht werden.

[schroeter9999]

Hallo zusammen,
mit dem Ein- und Ausschalten bin ich jetzt auch so weit...

Leider habe ich beim Dimmen das gleiche problem wie der Jan... Über die HA Bridge Oberfläche geht es, über Alexa werden die Bytes für die Lichtwerte 'zerägt'... konnte da noch kein Muster erkennen.

Bash... ist leider nicht meins... Ist da jemand weitergekommen?

Viele Grüße
Marcus

[Hotstepper13]

Hallo Marcus,

aktuell geht es zwar noch nicht aber meine Bridge sollte in der nächsten Version in Verbindung mit Werners Logikmodul auch das dimmen hinbekommen.

Weitere Details: https://knx-user-forum.de/forum/%C3%...nternettraffic

Gruß
Frank

[Wolbolar]

Hallo Zusammen,

nachdem hier ja viel über so Lösungen wie HA Bridge gesprochen wurde wollte ich nur mal für alle die noch nicht darüber gestolpert sind darauf aufmerksam machen das der am besten zur Zeit bewertete SmartHomeSkill im deutschen Amazon Store für IP-Symcon auch reibungslos mit KNX funktioniert.
http://alexa.amazon.de/spa/index.htm...l_dsk_skb_sh_4


Eventuell ist das ja für den ein oder anderen auch einen Alternative, zusätzlich kann man dann als Nebeneffekt natürlich auch noch alles andere was nicht KNX ist aber über IP-Symcon gesteuert wird wie Heimkino Komponenten auch mit Sprache steuern.