Der aussagekräftigste Test in diesem Thread ist der Routertausch. Derselbe ZimaOS-Server und derselbe mobile Client, die sich über das TP-Link-Deco-Mesh nicht finden konnten, funktionierten sofort, als der Server hinter dem vom ISP bereitgestellten ZTE-Router getestet wurde. Das deutet im Ausgangsfall auf ein Problem mit der lokalen Erkennung bzw. Multicast-Kommunikation hin und nicht darauf, dass der ZimaOS-Server selbst offline war.
Im Thread wurden anschließend Änderungen an Avahi aus der Community ausprobiert, darunter die Aktivierung des mDNS-Reflectors. Der ursprüngliche Verfasser bestätigte jedoch, dass diese Änderungen das Deco-Problem nicht behoben haben. Das aktuelle ZimaOS bietet bessere Ausweichmöglichkeiten: In der aktuellen Get-Started-Dokumentation steht, dass Nutzer das Gerät bei fehlender lokaler Erkennung direkt über seine IP-Adresse im Browser öffnen können. Außerdem bietet die Remote ID/Network ID einen weiteren Weg zur Geräteidentifikation.
Dies war kein reines iOS-Problem
Auf Seite 2 betonte santhora, dass auch Android den Server nicht finden konnte. Damit war ein eng begrenztes iOS-Berechtigungsproblem oder ein Apple-spezifisches Client-Problem ausgeschlossen.
Die Topologie war einfach: Deco-Haupteinheit → 2,5-GbE → Beelink-ZimaOS-Server, während die Smartphones über WLAN mit dem Deco-System verbunden waren.
Der Test mit dem ISP-Router war der beste Isolationstest
Die Client-Isolierung war bereits deaktiviert
Die Quelle überprüfte die Client-/Isolierungseinstellung des Deco-Systems und gab an, dass sie deaktiviert war. Die Smartphones und das ZimaOS-Gerät wurden außerdem mit derselben Deco-Einheit getestet, ohne dass die Erkennung wiederhergestellt werden konnte.
Das ist wichtig, denn „AP-Isolierung deaktivieren“ ist eine sinnvolle erste Prüfung, war hier aber nicht die endgültige Lösung.
Die Änderung am Avahi-Reflector funktionierte nicht
Eine Antwort aus der Community schlug vor, /etc/avahi/avahi-daemon.conf zu bearbeiten und den Reflector zu aktivieren. Der Nutzer probierte es aus und meldete keine Änderung.
Da der Workaround scheiterte, empfahl der Thread, die Änderung rückgängig zu machen. Lassen Sie alte Änderungen an der Erkennung nicht einfach bestehen, nur weil sie in einem Forum vorgeschlagen wurden.
Das aktuelle ZimaOS unterstützt ausdrücklich den direkten Zugriff per IP-Adresse im Browser
In der aktuellen IceWhale-Get-Started-Dokumentation steht, dass Sie bei fehlender Geräteerkennung durch ZimaClient die Server-IP-Adresse in der DHCP-Clientliste des Routers nachschlagen und diese IP-Adresse in einem Browser eingeben sollen. Der Einrichtungs-/Dashboard-Bildschirm ist derselbe.
Verwenden Sie den aktuellen Fallback über die direkte IP-Adresse, bevor Sie Avahi ändern.
Die Remote ID bietet einen weiteren unterstützten Identifikationsweg
Die aktuelle ZimaOS-Dokumentation stellt unter Einstellungen → Netzwerk eine Remote ID/NetworkID bereit. Behandeln Sie sie wie ein Zugangsdatenmerkmal, da sie zur Identifikation und Freigabe des Zugriffs auf das Gerät verwendet werden kann.
Weitere Informationen finden Sie im aktuellen Zugriffsmodell über die Remote ID.
Was Sie am Deco- oder einem anderen Mesh-System prüfen sollten
- Client-/AP-Isolierung;
- Trennung des Gastnetzwerks;
- Weiterleitung von Multicast/mDNS zwischen kabelgebundenen und drahtlosen Segmenten;
- VLAN-Trennung;
- Verhalten der Mesh-Knoten beim Wechsel der Clients;
- Firmware-Updates und herstellerspezifische Multicast-Optionen.
Eine normale Internetverbindung und erfolgreiche Ping-Anfragen beweisen nicht, dass die Multicast-Diensterkennung weitergeleitet wird.
FAQ zur ZimaClient-Erkennung
Hat das Deaktivieren von IPv6 den Ausgangsfall behoben?
Nein. Der Nutzer berichtete ausdrücklich, dass das Deaktivieren von IPv6 nicht geholfen habe.
Hat die Aktivierung des Avahi-Reflectors das Deco-Mesh-Problem behoben?
Nein. Der ursprüngliche Verfasser probierte es aus und meldete keine Änderung.
Was ist der sicherste aktuelle Fallback, wenn die lokale Erkennung fehlschlägt?
Verwenden Sie die LAN-IP-Adresse des Geräts in einem Browser oder stattdessen den unterstützten Remote-ID-/Remotezugriffsweg, anstatt nicht verifizierte Änderungen an Host-Diensten vorzunehmen.
