ich habe seit neustem das Problem, dass die HomeKit Bridge in der Homepage mit dem Status „Keine Antwort“ angezeigt wird und auch nicht mehr funktioniert. Das hinzufügen der Bridge über den Code etc… funktioniert. Es werden dann auch alle Geräte angezeigt und einlesen. Aber den Nutzung danach ist nicht mehr möglich. Hier ein Screenshot vom Debug Log.
Nach langem hin und her mit diesem Problem, bin ich auf die Windows-Firewall gestoßen, welche wohl nach einem der unzähligen Windows-Updates die Einstellung geändert hat. Trotz Freigabe der IPS.exe musste ich separat nochmal den Port 34587 für TCP und UDP freigeben.
Vielleicht hilft das den ein oder anderen mit ähnlichen Problemen. Interessant war, dass kurz nach dem Einrichten der Bridge trotz Firewall alles funktioniert hat. Erst nach ca. 10 - 15 Minuten erschien dann „Keine Antwort“.
Hallo zusammen,
ich habe Ip-symcon auf 5.1 aktualisiert und wollte Homebridge mit Hilfe aus Post #543 wieder zum laufen bewegen (unter 5.0 kein Problem).
Leider kann man die apk nicht laden und deshalb funktioniert es nicht.
Ich denke die Ursache für das Problem gefunden zu haben. Der Container startet dbus und avahi-deamon nicht automatisch beim Starten. Dies habe ich zum nächsten Update korrigiert. Ich freue mich auf Feedback! Du kannst das neue Image mit dem Tag 5.1-3122 ja mal ausprobieren.
paresy
habe gerade das neue Image 5.1-3122 probiert, und es ist einfach nur genial.
Ich musste nichts installieren, und wenn ich Symcon neu starte oder meine Synology wird alles automatisch gestartet.
Bei 5.0 musste immer nach Neustarts mit Eingabe von dbus und avahi-daemon gestartet werden.
Ich danke dir
könntest d beschreiben wie du den Container aufgebaut hast bzw. was bei der Synology zu beachten ist damit der HomeBridge Service über Bonjour sichtbar wird? Selbst mit der 5.1-3123 sehe ich den Service leider noch nicht
Danke im voraus.
UPDATE1:
Ich bin dem ganzen ein bisschen näher gekommen. Aber bei mir startet der deamon wohl nicht richtig. Was ist das Problem?
root@symcon:/# service avahi-daemon status
Avahi mDNS/DNS-SD Daemon is not running
root@symcon:/# service avahi-daemon start
* Starting Avahi mDNS/DNS-SD Daemon avahi-daemon [fail]
root@symcon:/# avahi-daemon --debug
Found user 'avahi' (UID 102) and group 'avahi' (GID 102).
Successfully dropped root privileges.
avahi-daemon 0.7 starting up.
chroot.c: chroot() helper started
dbus_bus_get_private(): Failed to connect to socket /var/run/dbus/system_bus_soc
ket: No such file or directory
WARNING: Failed to contact D-Bus daemon.
chroot.c: chroot() helper got command 0d
avahi-daemon 0.7 exiting.
chroot.c: chroot() helper got command 0c
chroot.c: chroot() helper exiting with return value 0
root@symcon:/#
UPDATE2:
Erst nach starten des dbus Dienstes lies sich auch der avahi starten. Allerdings sehr ich den Service immer noch nicht
root@symcon:/# /etc/init.d/dbus start
* Starting system message bus dbus [ OK ]
root@symcon:/# /etc/init.d/avahi-daemon start
* Starting Avahi mDNS/DNS-SD Daemon avahi-daemon [ OK ]
root@symcon:/# service avahi-daemon status
Avahi mDNS/DNS-SD Daemon is running
dbus & avahi-deamon müssen im Container leider noch manuell gestartet werden. Ähnlich ist es beim Bonjour-Dienst auf der Synology, dieser muss leider abgeschaltet werden. Noch weiß ich nicht warum, aber ich habe zum Beispiel die „Virtual Here USB Sharing“ App auch auf der Synology installiert und das hat sich mit dem Synology Bonjour-Dienst überhaupt nicht gebissen. Dieser Dienst (_vhusb._tcp.) läuft übrigens auch zusammen mit der HomeBridge problemlos. Es muss also ein Problem zwischen HomeBridge mDNS Service (bzw. Docker Container) und der Synology Bonjour-Dienstes sein.
In der aktuellen Symcon Beta starten wir die Dienste automatisch mit. Somit sollte nur noch notwendig sein, den Dienst auf der Synology deaktiviert zu haben. Der Unterschied ist, dass eine App den Bonjour Dienst von Synology mitnutzt. Ein Docker Container kann das (soweit ich weiß) nicht. Somit ersetzen wir quasi den Dienst und dafür muss er auf der Synology aus sein.
Ich habe den Docker-Container so angelegt, wie in in meiner Anleitung im Post #543. Konkret habe ich den alten Container abgeschaltet und den Neuen mit
neu erzeugt und danach noch das Netzwerk auf mein vorhandenes Symcon-Netzwerk geändert, da ich den Container ja innerhalb meines normalen Netzes betreibe.
Danach den Container nur neugestartet und das war es dann auch schon.
das mit deinem Netzwerk muss du mir nochmal erklären. Den Container habe ich auch über die Shell erstellt, wobei alle Einstellungen auch über die GUI machbar sind. Mein NAS ist in einem Server Netzwerk 172.16.5.0/24 (VLAN 5).
Im Bereich Docker --> Netzwerk habe ich 2 Default-Netzwerke (welche sich auch nicht löschen lassen). Einmal „bridge“ (172.17.0.0/16) und einmal das „host“. Hast du dann ein neues Symcon-Netzwerk angelegt, welches sich ja nicht im gleichen Netzt bewegen darf wie die NAS? Muss ich dieses Netz dann irgendwie routen? Bisher liefen alle meine Container auf dem „host“ Netzwerk, aber ich hätte dafür auch schon ein SmartHome 172.16.9.0/24 (VLAN 9) parat. Muss dieses dann an der NAS direkt auch verfügbar sein?
Dank im Voraus. Gruß Flo
Bei mir starten diese Dienste leider nicht automatisch mit. Kann ich dies irgendwie Debuggen? Gut wäre auch wenn der avahi-dienst über Variablen konfigurierbar wäre. Beispielsweise ipv6=off oder auch das mDNS Interface auswählbar.
um die Problematik mit der Subnetz-Beschränkung von Homekit bzw. Bonjour/avahi zu umgehen, habe ich den Docker-Container in mein normales Netz gepackt, so dass kein Gateway usw. notwendig ist.
Das Problem mit dem Netzwerk stellt sich aus meiner Sicht wie folgt dar:
a.) Bonjour/avahi funktioniert zunächst mal nur im gleichen Subnetz, d.h. es müssten alle Geräte im gleichen Subnetz wie der Docker-Container laufen. Theoretisch sollte man das Problem über die Reflector-Option enable-reflector=yes in der avahi-daemon.conf lösen können, das hat bei mir aber nicht funktioniert.
b.) Die Default-Bridge docker0 routet standardmässig nicht, dazu müsste in IPFORWARD eingerichtet werden
Will man also mit verschiedenen Subnetzen arbeiten, dann muss eigentlich zunächst sichergestellt werden, dass die Kommunikation aus dem Container mit der „Welt“ (und damit eben auch den HK-Devices) funktioniert. Und hier kommt dann eben leider das Thema dns-sd mit auf den Plan und die Bereitstellung der Anfragen über die Subnetz-Grenzen hinweg.
Da es mir nicht auf „normalem“ Wege gelungen ist, dass Symcon die dns-sd Anfragen auch in meinem normalen 192.x.x.x Netz (bei gleichzeitiger Erhaltung der Bonjour-Funktionalität für TimeMachine via Syno,also weiterhin aktivem Syno-Bonjour) bereitstellt, blieb mir nur der Weg des gemeinsamen Netzes.
Könnte sein, dass das nun doch funktioniert, denn ich hatte ja festgestellt, dass nach einem dbus/avahi Neustart im Docker-Container auch erst manuell die dns-sd Instanz erneut „reaktiviert“ (geändert) werden muss, bevor die HK-Anfragen im avahi-browser des Containers sichtbar waren. Da das mittlerweile mit dem neuen Image bei mir funktioniert, dürfte damit die Reihenfolge dbus->avahi->symcon dns-sd eingehalten sein. Die Frage ist, warum das bei Dir nicht funktioniert. Hast du in der console mit dmesg die logdatei angeschaut, ob ein Fehler aufgetreten ist ?
Da ich aber zum Zeitpunkt dieser Erkenntnis bereits auf das gemeinsame Netz umgestellt hatte, kann ich nicht sagen, ob das eigentliche Problem damit nicht eher aus der manuellen dbus/avahi Startaktion und der somit falschen Reihenfolge kommt.
Was ich gemacht habe:
ein „neues“ Docker Netzwerk mittels macvlan Treiber mit der gleichen Subnetzmaske wie mein normales Netz (also /24 bzw. 255.255.255.0) und der Verwendung einer statischen IP, im konkreten Fall aber ein IP-Range von 2^3=8 (/29) Adressen, muss ggfs. im DHCP-Server für die dynamische Vergabe blockiert werden. Muss aber auch mit einer einzelnen IP-Adresse (/32) funktionieren:
Beim Erstellen/Run des Containers kann dann dieses Netz direkt mit angegeben werden oder aber man löscht zunächst die Default-Bridge und wählt dann das neu erstellte eigene Netz.
Beim docker run… noch ein --network=<neuesNetzwerk> anzhängen, dann sollte er statt der docker0-bridge das eigene Netz verwenden
Damit Du aber VLANs verwenden kannst, kommst Du wohl um ein Netzwerk mit dem macvlan Treiber nicht drumherum (s.o.), der Bridge-Treiber dürfte nach meinem Verständnis nicht funktionieren. Solltest Du mal kontrollieren, wie Deine Vlans 5 + 9 angelegt sind.
Ein erster Test im Container ist auf jeden Fall mal den avahi-browser zu installieren und zu starten, um zu schauen, ob dort die Anfragen erzeugt werden, dann das gleiche auf der Syno, so sollte sich das etwas eingrenzen lassen.
ich klinke mich auch mal in diesen Thread ein, da ich auch Probleme mit der Verbindung zwischen Apple HomeKit und IPS habe.
Heute Abend hatte ich einen ersten Test gemacht (IPS 5.1, Apple HomeKit aus dem Module Store geladen, ein paar Einträge für dimmbare Lampen konfiguriert und anschließend das Pairing durchgeführt). Das hatte soweit auch prima funktioniert. Danach habe ich noch ein paar weitere Einträge hinzugefügt, die auch sofort in HomeKit sichtbar wurden. Das hat mich echt begeistert.
Dann habe ich aber ein Thermostat hinzufügen wollen (das in der HomeKit Bridge auch als OK angezeigt wurde). Das Gerät wurde in HomeKit nicht sichtbar. Daher habe ich kurzerhand das Haus in der HomeKit App gelöscht und versucht, die HomeKit Bridge neu zu pairen. Seitdem bekomme ich das Gerät „Symcon“ nicht mehr angezeigt, alle Pairingversuche sind seitdem gescheitert.
Was ist nun zu tun? Eine Deinstallation und erneute Installation aus dem Module Store hat auch keine Änderung gebracht.
Update:
Auf meinem iPad habe ich es nun geschafft, die HomeKit Bridge wieder zu pairen.
Scheint daher wohl ein Problem zu sein, das unmittelbar mit meinem iPhone zusammenhängt?!?
ich habe den Fehler gefunden und es ist eigentlich so lächerlich, dass ich es fast nicht zugeben möchte… :eek:
Steuerzentrale für mein HomeKit ist ein Apple-TV. Das ist mit einigen weiteren Videogeräten an eine schaltbare Steckdose angeschlossen - und diese Dose hatte ich ohne es zu bemerken während der Einrichtung ausgeschaltet…
Abends habe ich dann ferngesehen (und dafür war die Steckdose dann natürlich wieder eingeschaltet). Seitdem funktioniert das Pairing auch wieder. :rolleyes: