Hallo Niels,
ich habe weiterhin Probleme mit dem automatischen Wiederverbinden der App. Ich habe mich von meiner Assistentin beraten lassen und sie meint, ich solle einen Forumsbeitrag verfassen 
Ich hoffe, ihre Analyse hilft dir weiter:
Die iOS-App verbindet sich bei mir nach dem Aufwecken aus dem Hintergrund bzw. nach einem Netzwerkwechsel wiederholt nicht automatisch neu: Die Verbindungsversuche scheitern an toten Sockets, und die App wartet dann auf eine manuelle Verbindungsauswahl, statt sich selbst wieder zu verbinden. Der Server ist dabei nachweislich erreichbar (alle Requests, die ankommen, liefern Status 200). Ich habe drei Fälle mit dem App-Log aufgezeichnet und kann die vollständigen Logs gerne nachreichen. (Die längeren Zeitlücken im Log sind kein Hängen der App, sondern die Wartezeit, bis ich die Verbindung manuell ausgewählt habe.)
Umgebung:
- App: 9.0.4 (554002768926d9d9d47baa74740bad5826aeaa7f, 23.7.2026), iOS, iPhone
- Server: IP-Symcon 9.1 auf Intel NUC, erreichbar lokal über Port 3777 und 82 sowie per ipmagic
Muster 1 (Kontext, vermutlich nur kosmetisch)
Nach jedem WebSocket-Abbruch schlägt das Delta-Update ausnahmslos fehl und die App lädt den vollen Snapshot:
23:40:11: Make request: VISU_GetSnapshotChanges , params: [53323, 9062388], status code: 200
23:40:11: Failed to update snapshot diff of ws://192.168.178.86:82/wfc/53323/api/: Request range is bigger than message buffer (-32603)
23:40:12: Make request: VISU_GetSnapshot , params: [53323], status code: 200
Auffällig: Die Snapshot-IDs steigen von 9,06 Mio. auf 23,27 Mio. in ca. 12 Stunden (tagsüber deutlich schneller als nachts). Falls das ein fortlaufender Nachrichtenzähler ist, wäre das im Mittel eine dreistellige Zahl von Nachrichten pro Sekunde und würde erklären, warum der Puffer schon nach kurzer Abwesenheit nicht mehr ausreicht. Der Voll-Snapshot-Fallback funktioniert, macht Reconnects aber langsamer.
Muster 2 (eigentliches Problem)
Nach iOS-Suspend arbeitet die App mit toten Sockets weiter und verbindet nicht automatisch neu.
Um 05:24:22 beginnt ein Reconnect mit „Starting to get snapshot“, dann wurde die App von iOS suspendiert. Beim nächsten Öffnen laufen alle Verbindungsversuche in tote Dateideskriptoren, und statt einer automatischen Wiederverbindung musste ich die Verbindung manuell auswählen:
05:24:22: Starting to get snapshot
07:53:36: Checking Ping: true - null
07:53:36: Could not load snapshot from http://192.168.178.86:3777/api/: ClientException: Bad file descriptor
07:53:36: Network Connection State changed = IPSConnectionState.connectionSingularFail
07:53:36: Error during handover: ClientException: Bad file descriptor
Erst nach der manuellen Auswahl (08:08:47) kam die Verbindung wieder zustande. Ein zweiter Fall identisch: 08:16:08 Reconnect → 08:16:12 Bad file descriptor → wieder Auswahl nötig, Verbindung erst um 08:17:07.
Muster 3
Nach einem Netzwerkwechsel scheitern ALLE Verbindungsversuche mit errno 48.
Um 12:04:08 schlagen sämtliche Ziele - auch die anderer hinterlegter Visualisierungen in der Auswahlliste - identisch fehl:
12:04:08: Error during connection attempt to http://192.168.178.86:3777/: ClientException with SocketException: Connection failed (OS Error: Address already in use, errno = 48)
12:04:08: Error during connection attempt to http://192.168.178.86:82/: ... (OS Error: Address already in use, errno = 48)
12:04:43: Error during connection attempt to https://xxxxxxxx.ipmagic.de: ... Failed host lookup ... (errno = 8)
Da wirklich jedes Ziel denselben Fehler liefert, sieht das nach nicht aufgeräumten lokalen Sockets im Netzwerk-Stack der App aus (Suspend bzw. WLAN/Mobilfunk-Wechsel). Auch hier landete ich in der Visu-Auswahl; erst nach „Create new network / Dispose network“ und manueller Auswahl kam um 12:05:20 wieder eine Verbindung zustande (über ipmagic/wss).
Fragen:
- Sind Muster 2 und 3 bekannt? Für mich sieht es so aus, als müsste die App nach dem Aufwecken aus dem Suspend ihre Sockets konsequent verwerfen und automatisch neu verbinden, statt in Bad file descriptor / Address already in use zu laufen und auf eine manuelle Verbindungsauswahl zu warten.
- Zu Muster 1: Lässt sich der Message-Puffer für VISU_GetSnapshotChanges serverseitig vergrößern, oder ist der Voll-Snapshot-Fallback bei hoher Message-Rate der vorgesehene Weg?
Hier die vollständigen Logs der drei Fälle:
symcon_app_log_anonymisiert.txt (69,2 KB)
LG Burkhard
Resourcen werden jetzt besser aufgeräumt. Da könnte also mit der nächsten Version Besserung kommen
Dann spare ich mir das Nachstellen und berichte, wie es mit der nächsten Version läuft.