Closed nicoh88 closed 3 years ago
andiweli
commented
3 years ago Ich hab nicht wirklich eine Lösung parat, aber seit ich vom iPad mit Homeapp an der Wand auf ein Apple TV für die "Zentrale" gewechselt bin, habe ich das Problem auch nicht mehr.
jensweigele
commented
3 years ago Hi Nico,
welche Yahka Version hast du drauf? (es gab einige Bonjour fixes mit der aktuellsten Master-Version)
Ich denke aber unabhängig davon auch nicht, dass Yahka für die Probleme verantwortlich ist. Wir haben in der Firma ein eigenes Protocol in unseren iOS Geräten, welches die anderen iOS Clients im gleichen Netzwerk ebenfalls über Bonjour sucht/findet. Dort hatte ich nun schon öfter das Problem, dass manche Access-Points den Bonjour Traffic blockieren (manche sofort, manche erst nach einigen Minuten). Bonjour arbeitet viel mit Broadcasts und irgendein Filter in den APs blockt den Traffic. Billige/Einfache APs "brechen" auch teilweise zusammen wenn mehrere Geräte Bonjour anfragen senden bzw. viel Netzwerktraffic verursachen.
Zwei Vorschläge zur weiteren Eingrenzung:
nicoh88
commented
3 years ago Ich hab nicht wirklich eine Lösung parat, aber seit ich vom iPad mit Homeapp an der Wand auf ein Apple TV für die "Zentrale" gewechselt bin, habe ich das Problem auch nicht mehr.
Danke für die Info. Habe ingesamt drei HomeKit-Steuerzentralen: iPad an der Wand am Dauerstrom, HomePod und HomePod mini. In der Regel ist immer der große HomePod die aktive Zentrale, die anderen beiden stehen auf Standby.
Hi Nico,
welche Yahka Version hast du drauf? (es gab einige Bonjour fixes mit der aktuellsten Master-Version)
Ich hatte die Master-Version vom "Dec 23, 2020" (State Selector is now reading the objects on every opening) drauf. Habe jetzt die Master von Heute (Release of 0.13.0) drauf und werden nochmal testen.
Ich denke aber unabhängig davon auch nicht, dass Yahka für die Probleme verantwortlich ist. Wir haben in der Firma ein eigenes Protocol in unseren iOS Geräten, welches die anderen iOS Clients im gleichen Netzwerk ebenfalls über Bonjour sucht/findet. Dort hatte ich nun schon öfter das Problem, dass manche Access-Points den Bonjour Traffic blockieren (manche sofort, manche erst nach einigen Minuten). Bonjour arbeitet viel mit Broadcasts und irgendein Filter in den APs blockt den Traffic. Billige/Einfache APs "brechen" auch teilweise zusammen wenn mehrere Geräte Bonjour anfragen senden bzw. viel Netzwerktraffic verursachen.
Ok, danke für die Info.
Zwei Vorschläge zur weiteren Eingrenzung:
- Alle Anti-Spoof, Anti Intrusion, Firewall etc. Geschichten ausschalten auf den APs
- kaufe dir mal ein Lightning auf Ethernet Adapter und schau ob es kabelgebunden funktioniert (wobei ich nicht weiß, ob das iPad dann weiterhin als Steuerzentrale fungiert, da es laut Apple ja am Strom angeschloßen sein muss - vielleicht vorher noch ein Lightning-Port-Multiplier holen, damit du das iPad auch laden kannst).
Danke für deine Vorschläge, werde ich testen. Ich bin die letzten Stunden nochmal in mich gegangen und habe überlegt, was sich die letzten 1-2 Monate geändert hat:
Linksys WRT1900AC auf TP-Link Archer C719.07.3 auf 19.07.4bzw. 19.07.5Ich werde jetzt erstmal alle OpenWRT-Geräte auf 19.07.3 downgraden und testen. Das Gute, das Problem tritt eigentlich jeden Morgen, beim Wechsel der Etage und Ausführen der Szene "Indirekte Beleuchtung", am iPad an der Wand auf.
Spannend ist und bleibt, dass alle anderen Geräte außer das iPad mit den Geräten der YAHKA-Bridge funktionieren. Des Weiteren reicht ein ausgeführter Netzwerk-Scan am iPad, damit die Geräte der YAHKA-Bridge wieder verfügbar sind.
Ich halte euch auf dem Laufenden!
Gruß Nico
nicoh88
commented
3 years ago Soooooo, ich habe ein paar Neuigkeiten, aber noch keine 100%ige Lösung. Ich arbeitet noch meine Liste ab, um alles andere ausschließen zu können - mal taucht das Problem nach 8 Stunden auf, mal erst nach 48 Stunden. Daher dauert es immer so lange... ⏳
Wenn das Problem am iPad an der Wand auftritt, haben ALLE HomeKit-Steuerzentralen im Netzwerk (2 HomePods) auch keine Verbindung zur YAHKA-Instanz. Geräte einer andere Homebridge-Instanz im Netzwerk (läuft auf dem gleichen System) und die Kameras der YAHKA-Instanz (bekanntermaßen eigener mDNS) sind verfügbar. -> Aber, mobile iOS-Geräte, die nicht dauerhaft aktiv im WLAN sind, wie iPhones, Apple Watch, iPads, die ab und an in den Standby gehen und die WLAN-Verbindung neu aufbauen, haben keine Probleme die YAHKA-Instanz zu erreichen. Da, wie bekannt, iOS Geräte die sich im gleichen Netzwerk wie die HAPs befinden, garnicht über die Steuerzentralen eine Verbindung aufbauen, sondern direkt mit den HAPs kommunizieren. -> Aber, von extern, beim Deaktivieren der WLAN-Verbindung oder eben unterwegs, ist die YAHKA-Instanz, wenn das Problem besteht, auch nicht erreichbar.
Ich habe sicherheitshalber die zwei "ü" in den Bezeichnungen der Kameras in "ue" geändert - falls die "xn-" mDNS-Namen irgendwo Probleme machen sollten. Ohne Erfolg, Problem besteht weiterhin!
Alle HomeKit-Steuerzentralen (iPad mit Dauerstrom an der Wand, HomePod WZ und HomePod min Bad) stromlos gemacht und somit neugestartet. Ohne Erfolg, Problem besteht weiterhin!
Aktuell teste ich das OpenWRT Downgrade auf 19.07.3.
Ich bin mittlerweile sehr sicher, dass irgendwann, aus noch unbekannten Gründen, der mDNS-Name iobroker-yahka-822b.local wegfliegt und ein paar Sekunden später wieder verfügbar ist. Aber die dauerhaft im WLAN befindlichen Geräte / HomeKit-Steuerzentralen dies erst nach einem WLAN-Reconnect mitbekommen.
Bestätigung dazu bekomme ich im DNS-Query von meiner Pi-Hole, normalerweise wird der interne DNS-Server bei Bonjour- / Avahi-mDNS garnicht erst abgefragt, sondern nur, wenn er im Netzwerk nicht verfügbar ist! Dies ist scheinbar manchmal der Fall - 4 Screenshots:
Im Vergleich der mDNS der Homebridge-Instanz auf dem gleichem System.
npm list -g
├─┬ homebridge@1.1.7
│ ├─┬ chalk@4.1.0
│ │ ├─┬ ansi-styles@4.3.0
│ │ │ └─┬ color-convert@2.0.1
│ │ │ └── color-name@1.1.4
│ │ └─┬ supports-color@7.2.0
│ │ └── has-flag@4.0.0
│ ├── commander@5.1.0
│ ├─┬ hap-nodejs@0.7.10
│ │ ├─┬ bonjour-hap@3.6.2
...
Zur Info, warum "Blocked": Alle *.local DNS-Abfragen werden sicherheitsmäßig, wie bei vielen DNS-Servern, blockiert, wenn diese lokal nicht verfügbar - somit werden die Upstream-DNS (1.1.1.1 8.8.8.8, etc.) nicht abgefragt.
Eine dauerhafte Lösung wird vermutlich das hinterlegen von, in meinem Fall, iobroker-yahka-822b.local im Local DNS von Pi-Hole.
Als IT'ler ist mir aber die Fehler-Ursachen-Analyse sehr wichtig, daher werde ich noch einige weitere Dinge, wie die OpenWRT-Version, sowie IGMP-Spoofing (bisher nicht aktiv) und Pi-Hole ausschließen.
Gruß Nico
jensweigele
commented
3 years ago Mit dem aktuellen Master, gibt es nun eine Option auf der Bridge/Kamera/Device, um auf die vorherige Bonjour-Bilbiothek zurück zu gehen. Teste mal bitte ob es dadurch besser wird.
MacPro-de
commented
3 years ago Das hat sich erledigt - ich habe jetzt die 0.14.0 und teste: Ich habe dieses Problem hier auch und würde die Version ebenfalls gerne testen, aber auch, wenn ich die yahka master über github installiere, scheine ich noch die 0.13.0 zu erhalten.
Ich verwende iobroker unter Ubuntu Server 20.04 und habe dort netplan.io, systemd-resolvd und sogar die Firewall deinstalliert und verwende jetzt wieder avahi, ifupdown und resolvconf. Trotzdem verschwinden alle yahka Geräte immer wieder nach einer Weile. Ich nutze das Programm "Discovery" unter macOS und überwache damit den mDNS-Bereich "_hap._tcp". Ich habe dann auch noch die IP-Adresse des iobroker Hosts geändert. Danach hat es mehrere Stunden lang problemlos funktioniert, aber dann sind die Geräte trotzdem wieder aus mDNS verschunden. Auch ein yahka Adapter Neustart bewirkt, dass die Geräte wieder für ein paar Minuten in mDNS erscheinen.
MacPro-de
commented
3 years ago In der 0.14.0 habe ich im yahka-Adapter die Bridge und alle Kameras so konfiguriert, dass die vorherige Bonjour-Bibliothek verwendet wird und alles läuft jetzt seit über einer Stunde problemlos. Dann habe ich eine zusätzliche Kamera angelegt, bei der diese Option nicht aktiviert ist und die verschwindet ca. 2 Minuten nach dem yahka-Start aus mDNS. Es scheint also (zumindest bei mir) wirklich an der neuen mDNS-Bibliothek zu liegen.
nicoh88
commented
3 years ago Ich habe bei mir noch nicht die neue NPM-Version 0.13.1 installiert (inkl. aktivieren von Use Legacy Advertiser) und kann die Lösung meines Problems noch nicht bestätigen, bisher ist das Problem, seit dem Downgrade auf OpenWRT 19.07.3 nicht mehr aufgetreten - ist aber auch noch keine 48 Stunden her.
Ich gehe aber anhand von #212 mittlerweile stark davon aus, dass das Problem nicht OpenWRT oder Pi-Hole auslöst und mit Use Legacy Advertiser behoben ist - deshalb mache ich hier schonmal zu. 👍
Spannend 😕, dass bei mir ein WLAN-Reconnect ausreicht um das Problem zu lösen und es erst nach 8-48 Stunden auftritt, nicht nach 2 Minuten, wie bei anderen Usern im Issue #212 und homebridge/HAP-NodeJS#856.
Danke für deine Recherche @jensweigele 🎉
nicoh88
commented
3 years ago Nachtrag, natürlich hat Use Legacy Advertiser mein Problem gelöst.
Weiterhin bleibt offen, warum, dass Problem bei anderen nach 1-5 Minuten aufgetreten ist und bei mir erst nach 12-48 Stunden. Vielleicht irgendein OpenWRT-DNS-Cache oder Pi-Hole-Cache.
Gruß
Hallo HomeKit-Freunde,
vorab erstmal ein gesundes neues Jahr euch allen! Ich möchte heute ein Problem mit euch Teilen, bei dem ich noch keine 100%ige Lösung habe. Ich glaube auch nicht, dass es an YAHKA liegt. Da hier aber einige versierte Personen unterwegs sind, wollte ich mal eure Meinungen / Ideen einholen.
Umgebung
Fehler
Nach ein paar Stunden, bisher kein erkennbares Muster, sind die Geräte der iobroker Yahka-Instanz nicht verfügbar. Szenen werden nicht ausgeführt, Geräte werden mit dem roten Schriftzug "Keine Antwort" angezeigt.
Analyse
Das finde ich spannend, weil Yahka somit fast als Problemauslöser ausscheidet - da die Kameras über einen eigenen mDNS- / Bonjour-Namen angesprochen werden. Vielleicht werden die von der Home App aber auf andere Art und Weise abgefragt?!
Workaround
Eure Meinung?
Was meint der Rest?
Gruß & Danke Nico