Ist mir jetzt erst aufgefallen, dass die Alexa Integration auch einen Sensor für laufende Timer und aktive Wecker liefert. Vor allem der Sensor next alarm ist ganz interessant. So lassen sich Automationen in Abhängigkeit eines aktiven Weckers ausführen. Wie z.B. 20 min vor dem eigentlichen Wecker das Licht langsam hoch dimmen oder die Kaffeemaschine einschalten. 
3 Likes
Klingt interessant.
Bisher war es mir immer zu umständlich, die HueGo als Lichtwecker parallel zum Alexa-Wecker zu stellen. Wenn man das so auslesen kann, noch einen Zeitversatz für den Homey-Wecker (z.B. -15min), dann mit dem Homey-Wecker die HueGo als Lichtwecker vorab einschalten.
Es wird nie langweilig 
Hi, nochmal eine Nachfrage dazu. Welche Alexa-Integration verwendest du? Die mit Developer/AWS-Account und CustomSkill? Oder habe ich nur nicht richtig gesucht und es gibt noch etwas einfacheres?
Der Zugriff mir SSL über :443 wäre echt blöd. Das wird schon für Webserver/NAS verwendet. Kann Alexa tatsächlich nicht auf andere Ports mit SSL zugreifen?
Diese hier:
1 Like
Kannst du bitte nal schauen, wie die Wecker-Entität heißt?
Ich habe in der Alexa-Integration nur die Echo-Geräte als Whitelist angegeben, um nicht alle anderen Geräte doppelt zu haben (z.B. Hue). Ich vermute, dass ich den Wecker als Gerätename in die Whitelist aufnehmen muss.
Danke
Sind jeweils Sensoren,
Also sensor.Gerätename_next_alarm
_next_reminder
_next_timer
Hm. Dann hätten die zu den Echos eigentlich da sein sollen. Ich habe aber nur je einen Mediaplayer je Echo.
Ich nehme an, du hast auch amazon.de als Server?
Die Anleitung zur Alexa-Integration sagt:
Alternatively, you can only include specific devices using the
include_deviceskey. NOTE:include_devicesonly loads devices that have been listed and functions like a black list. If you don’t include the Alexa guard or the switches, then you will not see them.
D.h. nur den Echo in der Whitelist eintragen genügt nicht. Dann fehlen die Sensoren.
Ich hatte auch befürchtet, dass die Integration alle Alexa-Geräte liest (auch Hue, Schalter usw.). Es sind aber tatsächlich nur die Echo-Geräte.
Ich habe jetzt nmur die Lautsprecherzonen und die Alexa-App (Telefon) in die Exclude-Liste aufgenommen.
Das Debug-Log war recht hilfreich dafür:
Hallo @Undertaker/Uwe,
du hast ja die Homeassistant App in Homey eingerichtet. Wie hast du HA und die App konfiguriert? Ich bekomme beim Eintragen der URL+Token immer einen Verbindungsfehler.
Ich habe HA mit SSL konfiguriert. Ist das ein Problem, d.h. kann die HA App kein SSL?
Verwendest du auch SSL oder rein Http?
Danke fürs Nachschauen…
Mein Problem ist aktuell:
Wenn ich über die normale MqttClientApp gehe unf Flows anlege (Topic subscribe), dann werden die Flows von Homey öfter deaktiviert. Selbst nach Aktivierung ist die Subscription anscheinend weg und der Flow reagiert nicht mehr auf Aktualisierungen. Deshalb wollte ich die HA App testen.
Bei mit läuft das nur über http.
MQTT Broker läuft auf Homey
MQTT Client auch auf Homey
MQTT Hub auch auf Homey
HA hat die IP Adresse und Port vom Homey Broker bekommen.
Client dto
Den Hub Broadcast nötigenfalls händisch starten, dass alle Homey Geräte gesendet werden. Falls etwas nicht geht, erst den Raspi neu starten und dann die Homey Apps in der Reihenfolge Broker, Client, Hub. Dann nochmal händisch beim Hub den Broadcast auslösen und bei HA beobachten, wie die Geräte aufschlagen.
Hast du deine Passwort geprüft, ob da immer das Gleiche verwendet wurde ?
Hallo Uwe,
bei mir sieht es so aus:
- MWTT Broker aus NAS-Container (http)
- HA auf NAS-Container (https)
- MQTT-Client auf Homey
- MQTT Hub auf Homey
Das läuft soweit auch stabil.
HA wird über eine https-URL aufgerufen. Leider kann man HA nur entder/oder einstellen. Man kann leider nicht “für außen” SSL und intern über einen anderen Port http einrichten.
Die HomeAssistand-App in Homey verwendet die https-URL und einen Langzeit-Token.
Trotzdem kommt der Verbindungsfehler. Ich vermute langsam, dass die App keine https->Verbindungen unterstützt. Aber auf http zurück ist auch keine Option.
Der Entwickler meldet sich leider auch nicht auf Anfragen…da kommt wohl auch kein Update mehr.
Ein “Problemchen” habe ich allerdings.
Es gibt Entitäten in HA (innr-Plug aus Homey), die zwar den aktuellen Status aus Homey anzeigen, sich aber aus HA heraus nocht schalten lassen. Der Schalter springt in HA immer zurück. Schalte ich das Gerät in Homey, dann zeigt HA das korrekt an.
Noch schlimmer war es, als ich in Homey mit dem MQTT-Client Flows als MQTT-Subscriber erstellt hatte.
Der Flow wurde dann öfter von Homey deaktiviert (weil der ioBroker 20 Updates in je 1sec Abstand geschickt hatte). Darauf hin scheint der MQTT-CLient Probleme zu haben. Dann sind alle Entitäten in HA zwar noch vorhanden, aber nicht mehr schaltbar. So als ob Homey die Subscriptions gelöscht hätte. Da half of nur noch ein Homey-Reboot. Seit die Flowss deaktiviert sind, hatte ich bisher keine solchen Ausfälle mehr.
Das bringt mich aber zu der Frage, wie das Zusammenspiel zw. Hub, Client und HA ist.
-
Der Hub sendet nur Daten an den MQTT-Broker (und verwendet dazu den Homey-Client?). Ich habe gesehen, dass der Hub die Geräte einzeln unter der Topic homie/homey… anlegt. Die homeassistant-Topic hat dann die HA-Typen mti der Referenz auf die homie-Topic und dient m.W. nur dazu, dass HA die Geräte automatsich über diese Topic lesen und typisieren kann.
Ich vermute, dass HA dann zwar die homeassistant-Topic anzeigt, intern aber die Referenz homie/homey… verwendet? -
Der Client ist Subscriber und nimmt Änderungen von MQTT entgegen? Schaltet dann der Client die Homey-Geräte, wenn man in HA das Gerät schaltet?
-
Wo könnte dann das Problem bei fehlenden Reaktionen liegen, wenn Homey nicht auf Änderungen seitens HA reagiert? Ist der MQTT-Client die Ursache?
Hi Ronny,
mit den NAS Containern kenne ich mich leider gar nicht aus. Ich hab zwar zwei Qnap 4 Bay am Laufen, aber die sind nur Datengrab und Filmspeicher.
Da ich keine https Verbindungen verwende, kann ich auch wenig dazu sagen. Die normalen Verbindungen sind bei mir auch nicht Sicherheitsrelevant, weil eine Armada von Sicherheitsvorkehrungen das überflüssig macht.
Dein Problemchen kenne ich. Ich hab mich allerdings noch nie darum gekümmert, weil Homey bei mir alles macht und ich in HA noch nie wirklich die Schalter benutzt habe.
Mir sind aber einige Entitäten aufgefallen, die nie Werte bekommen. Beim Batterie Stand kommt das häufiger vor. Ich gehe mal davon aus, dass das ein Bug in der App ist.
Ich sehe das Zusammenspiel der Apps so:
Der Broker ist nur der Server, der die eingehenden Daten allen angeschlossenen Clients zur Verfügung stellt.
Der Client nimmt geänderte oder neue Daten entgegen.
Der Hub sendet lediglich die Homey Geräte und Änderungen aufbereitet an den Broker.
Hi @Osorkon, du als HA Insider, kannst du @RonnyW weiter helfen und mich nötigenfalls korrigieren ?
1 Like
Kann leider nichts mehr zum Thema Zusammenspiel HA und Homey beitragen. Bin kugellos glücklich! 
Die Themen MQTT Homey -> HA
und die HA App HA-> Homey waren zwar schöne Spielereien aber eben halt nur Spielereien.
Ganz überzeugt hat mich das ganze nicht.
Nicht umsonst habe ich den Weg HA only gewählt.
Ich hoffe ich bin in diesem Thread richtig und Ihr habt ein paar Tipps für mich.
Ich nutze einen Homey und seit kurzem einen Pi 4 mit HA. Dieser soll die bisher von Homey nicht unterstützten Geräte steuern und zu Google Home oder besser noch direkt zu Homey zusammenführen.
Mein erster Versuch war die manuelle Installation von google assistant über die entsprechenden Anleitungen von HA. Leider bekomme ich meine App nicht zum Laufen, auf github gibt es entsprechende Einträge in den Issues und ich warte auf eine Lösung der Entwickler.
Danach habe ich versucht diese App zu installieren. Auf dem Homey hat es wunderbar geklappt, nur fehlt die Resource auf github für die HA App. Auch hier gibt es ein Issue, der Entwickler scheint nicht mehr aktiv zu sein.
Nun bleibt meine letzte Lösung MQTT, welche ich auch auf beiden Plattformen erfolgreich installiert habe. Client und Hub auf dem Homey, den Broker auf dem HA. Die Entitäten werden beim HA auch angzeigt, aber jegliche Versuche, eine HUE Lampe zu steuern oder die Blinds hoch oder runterzufahren, funktionieren nicht. Die Schalter sind da, lösen aber bei Homey keine Reaktion aus.
Habt Ihr zu irgendeinem meiner drei Versuche Hilfe?
Herzlichen Dank!!!
Du wirfst vermutlich zu viele Dinge in deiner Frage zusammen, so dass mir die eigentliche Frage nicht ganz klar ist 
Ich veruche mal eine Zusammenfassung:
- Du hast Homey und HA parallel laufen
- In Homey hast du Hue-Lampen. Die willst du über HA steuern.
Soweit korrekt?
Ich habe dazu die MQTT-Client und MQTT-Hub-App in Homey installiert. Die Client-App ist an den MQTT-Broker angebunden.
HA ist ebenfalls an diesen Broker angebunden.
In der MQTT-Hub-App (App-Einstellungen) startet man den Broadcast. Damit werden die Homey-Geräte mit ihren Eigenschaften im Broker veröffentlicht. In HA sind sie damit verwendbar.
In HA sollte man jetzt die Lampen schalten können und der Zustand sollte sich in Homey ändern.
Die HA-App für Homey (aus dem Community-Store) funktioniert bei mir nicht. HA läuft bei mir über SSL, damit kommt die App nicht klar. Deshalb kann ich dazu nicht viel sagen.
Ich hatte auch versucht, Entitäten (eigene brechnete Sensoren-Werte) von HA über MQTT zu veröffentlichen. Das funktioniert auch. Man sieht die Werte im MQTT-Broker (geprüft über die MQTT-Explorer Windows-App). Aber das Einbinden in Homey ist nicht zufriedenstellend. Man muss je Wert einen Flow anlegen (Trigger über MQTT-Client-App und der MQTT-Topic) und dann den Wert übernehmen (z.B. in ein virtuelles Gerät). Bei mir klappt das aber nicht. Die Flows werden immer von Homey deaktiviert (zu oft aufgerufen?) und die Client-App hängt sich dabei auf.
Ich hoffe, das hilft weiter. Falls nicht, einfach weiter fragen 
Kurze Anmerkung zur Homey-Homeassistant-App:
Ich habe HA nun wieder für http-Zugriffe konfiguriert. Über http funktioniert die Homey-HA-App. Der Test zeigt damit auch, dass die App keinen Zugriff über SSL ermöglicht.
Damit läuft der interne Zugriff über http statt https (http://server:8123).
Das ist zwar schade, aber auch egal. Die Lösung heißt: ReverseProxy!
Damit der Zugriff von außen über SSL läuft, habe ich den Apache-Webserver im QNAP-NAS um vhosts und reverse proxy ergänzt.
Ich kann damit den externen Zugriff über eine Subdomain (https://ha.dyndnsservername) per vhost auf die interne http-Adresse umleiten (http://server:8123).
D.h. von außen ist alles SSL-Verschlüsselt, intern nicht.
Das hat auch den Vorteil, dass ich nun statt dem separaten Port einfach eine Suubdomain verwenden kann und der Standard-Port 443 verwendet wird. Das könnte in Zukunft auch Alexa-Zugriffe ermöglichen, wo Port 443 vorausgesetzt wird.
Falls jemand Hilfe und Beispiel-Konfigs für vhost/reverse proxy im QNAP-NAS braucht, kann sich gern hier melden.
Edit:
die Subdomain ist leider nur intern möglich, indem man im Router (oder wie bei mir im AdGuard-DNS) die Subdomain auf die IP des NAS einstellt. Ein Aufruf von extern ist so leider nicht möglich. Ich hatte gehofft, dass der Aufruf trotz subdomain auf die DynDNS-IP geht. Es ist aber anscheinend ein offizieller DNS-Eintrag notwendig. Also doch nur eine Lösung für Leute mit offizieller Domain, zu der man selbst Subdomains registrieren kann.
Ich bin auch dabei, die Variante als Docker auf meinem Synology zu realisieren. Darf ich fragen, welche Container du verwendest? Dort gibt es so viele Unterschiedliche
Danke im voraus
LG
HomeAssistant-Container:
https://hub.docker.com/r/homeassistant/home-assistant
Im NAS nach homeassistant/home-assistant suchen (auf Docker-Hub)
Einstellungen:
Umgebungsvariablen:
variable = TZ
value = Europe/Berlin
Share-Zuordnung:
/config => /share/ContainerData/Homeassistant (hier dein Freigabeverzeichnis wählen
Am besten suchst du nach einer Anleitung für HA-Docker auf Synology für die genauen Variablen/Pfadangaben. Die sollten aber ähnlich sein. Auf jeden Fall musst du /config auf ein Freigabeverzeichnis mounten, damit du die Congif-Files ändern kannst.
Zusätzlich habe ich noch den MQTT-Broker als Docker installiert (statt auf Homey):
eclipse-mosquitto vom Docker-Hub
1 Like
ReverseProxy mit Apache für HomeAssistant:
Noch ein Nachtrag zum vorherigen Post zur Verwendung von ReverseProxys für die Weiterleitung der Aufrufe zu HomeAssistant. Ich wollte das noch ergänzen, damit ihr eine funktionierende Vorlage habt.
Der IST-Stand:
- HA läuft mit SSL
- Aufrufe vom Browser oder HA-Android-App funktioniert.
- Zugriff mit der HA-Homey-App funktioniert nicht (SSL nicht unterstützt)
Das Ziel:
- Zugriff von HA-Homey-App über http und Weiterleitung an HA mt SSL per ReverseProxy
Mit folgenden Anpassungen im QNAP-NAS ist das möglich:
-
vhost in QNAP aktivieren:
Über Web-Admin-Seite, Systemsteuerung/Webserver/Virtueller Host
Virtueller Host aktivieren, aber keinen Eintrag einfügen -
Apache-Config:
/mnt/HDA_ROOT/.config/apache/apache.conf editieren.
Zeile anfügen:
Include /etc/config/apache/extra/httpd-proxy.conf
Datei ./extra/httpd-proxy.conf anlegen mit diesem Inhalt:
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so -
vhost-Konfig:
Datei ./extra/httpd-vhosts-user.conf editieren und folgende Zeilen anfügen:Listen 8124
<VirtualHost :8124>
ServerName dyndnsname.de
ProxyPreserveHost On
ProxyRequests Off
ProxyVia Off
SSLProxyEngine On
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
ProxyPass /api/websocket ws://dyndnsname.de:8123/api/websocket
ProxyPassReverse /api/websocket ws://dyndnsname.de:8123/api/websocket
ProxyPass / https://dyndnsname.de:8123/
ProxyPassReverse / https://dyndnsname.de:8123/
RewriteEngine on
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /(.) wss://dyndnsname.de:8123/$1 [P,L]
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule /(.*) https://dyndnsname.de:8123/$1 [P,L]
Die Foren-Software verschluckt leider einige Zeichenkombinationen (Punkt-Stern bei RewriteRule). Deshalb die Konfig nochmal als Bild:
Bedeutung:
Listen 8124: Der Webserver lauscht auf diesem Port, d.h. man kann einen neuen Port defininieren für den Aufruf und spätere Weiterleitung. Es kann ein beliebiger freier Port verwendet werden.
VirtualHost: vhost wird für angegebenen Port 8124 aufgerufen
ServerName: Filter für aufgerufenen Server. Kann weggelassen werden, wenn nur der Port relevant ist.
SSL-Parameter: Aktiviert SSL für Weiterleitung (https-Aufruf). Zertifikats-Prüfungen können ggf. ausgeschaltet werden (wenn selfsigned).
ProxyPass/Reverse: Weiterleitung auf den HA-SSL-Port (für http und websocket)
Mit dieser Variante kann man HA über die URLs aufrufen:
http://dyndnsname.de:8124 (für http über ReverseProxy)
https://dyndnsname.de:8123 (für https Original HA-Port)
Diese Variante zur Weiterleitung (http=>https) kann auch umgekehrt verwendet werden (https=>http).
Dazu müssen die aufgerufenen URLs angepasst werden (http statt https, ws statt wss).
Außerdem muss noch SSL aktiviert werden und das zu verwendende Zertifikat angegeben werden (innerhalb von <VirtualHost *:8124>, hier der Standard-QNAP-Ort):
SSLEngine on SSLCertificateFile /mnt/HDA_ROOT/.config/QcloudSSLCertificate/cert/cert SSLCertificateKeyFile /mnt/HDA_ROOT/.config/QcloudSSLCertificate/cert/key
und diese Zeilen löschen:
SSLProxyEngine On SSLProxyVerify none SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off
Links, mit denen ich gearbeitet hatte:
https://emby.media/community/index.php?/topic/56909-how-to-setup-reverse-proxy-access-to-emby-on-qnap/
https://httpd.apache.org/docs/2.4/vhosts/examples.html
