Home Assistant App - Unendliche Möglichkeiten 😀

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. :grinning:

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 :slight_smile:

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 :slight_smile:

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?

Ja verwende auch den .de Server.
So sieht bei mir die GerÀteintergration aus

1 Like

Die Anleitung zur Alexa-Integration sagt:

Alternatively, you can only include specific devices using the include_devices key. NOTE: include_devices only 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.
01

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.

  1. 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?

  2. 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?

  3. 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! :joy::grinning:

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 :sweat_smile:

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 :wink:

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 :sweat_smile:
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:

  1. vhost in QNAP aktivieren:
    Über Web-Admin-Seite, Systemsteuerung/Webserver/Virtueller Host
    Virtueller Host aktivieren, aber keinen Eintrag einfĂŒgen

  2. 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

  3. 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:
vhost

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