Heute ist mir was passiert, das hatte ich noch nie.
Ich habe auf dem Windows-Server eine Software aktualisert. Auf einmal hat der Rechner angefangen zu spinnen. Alles wurde langsam, die Netzwerkverbindungen brachen teilweise ab. Symcon lief im Hinergrund und ich hatte die Konsole auf. Dann kam es schubweise zu Problemen innerhalb von IPS. Die laufenden Threads sind bis zur Maximal-Anzahl gestiegen, dann kamen ein paar Fehlermeldungen, dann lief es kurz normal, dann wieder das Gleiche.
Irgendwann war alles so langsam, dass ich den IPS-Dienst beenden und den Rechner neu starten wollte. Dann ging aber plötzlich gar nichts mehr und ich musste den Rechner hart ausschalten und neu starten.
Nach dem Start meldet sich IPS nicht per Push-Nachricht, wie es normal der Fall ist. Ich habe dann die Konsole geöffnet und mich verbunden und es war einfach alles weg. Ein komplett leeres IPS. Ich habe dann im Datenverzeichnis geguckt und die settings.json war einfach komplett zurückgesetzt und hatte nur noch wenige KB. Mir blieb dann nichts anderes übrig als die settings.json von heute Nacht zu nehmen. Die restlichen Daten waren alle noch da.
Der Dienst läuft jetzt wieder, aber der Inhalt der ganzen Variablen ist natürlich Müll und passt auch nicht mehr zu den geloggten Werten. Und kurisoerweise liefern zwei Modbus-Geräte jetzt auf zwei Adressen Werte, die eigentlich falsch sind, obwohl diese immer nur gelesen werden.
Wie kann sowas kommen, dass die settings.json einfach hart gelöscht/zurückgesetzt wird?
Das hatte ich noch nie. Normal wird die ja alle paar Minuten neu auf Platte geschrieben. Selbst wenn der Rechner dann aus geht, ist ja noch die letzte Version da.
Löscht Symcon die Datei, wenn inhaltlich irgendwas nicht stimmt. Selbst wenn die Datei korrupt gewesen wäre, hätte ich sie ja vielleicht noch reparieren können, aber komplett leer, wie bei einem neuen System…
Ich vermute der überforderte Rechner hatte eine korrupte Datei. Diese wurde dann beim Neustart entsprechend mit einer leeren Settings überschrieben. Aber halb so wild. Symcon sichert die Settings täglich im Datenverzeichnis unter „backup“. Da findest du dann settings.json-Dateien der letzten Tage. Im Dateinamen steckt noch ein Zeitstempel. Such dir da also die neueste, beende dein Symcon, nehm den Zeitstempel raus und ersetze die settings.json im Hauptverzeichnis, und starte neu. Du verlierst zwar deine Arbeiten von heute, aber alles andere bleibt erhalten.
Ja, das habe ich ja gemacht. Es läuft auch wieder. Ich konnte mir nur keinen Reim drauf machen, wie die settings.json einfach zurückgesetzt werden kann. Dann müsste sie ja gerade beim Schreiben auf die Platte kaputt gegangen sein. Vermutlich durch das Beenden des Dienstes, was nicht mehr sauber funktioniert hat. Hätte ich den Rechner einfach aus gemacht, wäre wahrscheinlich nichts passiert.
Einzige noch bestehende Problem:
Die Variablenwerte sind halt alle veraltet und passen nicht mehr zum Archiv - das wird sich mit der Zeit wieder einschwingen.
Die beiden Modbus-Geräte liefern falsche Werte. Mir ist schleierhaft, wieso. An den Geräten selbst hat sich ja nichts geändert und die werden auch nur gelesen. Das muss ich mir mal in Ruhe ansehen.
Die Multicast-I/O von der KNX-Discovery-Instanz kommt nicht mehr hoch: 29.05.2026, 16:23:49 | Event Control | Wiederverbinden [Multicast Socket (EIB Discovery #16135)] fehlgeschlagen = Ein ungültiges Argument wurde angegeben. Keine Ahnung, warum das so ist. Neustart bringt auch nichts.
Trotzdem ist das spannend wie es passieren konnte. Wir haben hier mehrere Sicherheitsmechanismen, die normalerweise greifen. Wenn die settings.json korrupt ist, nehmen wir immer automatisch eine aus dem Backup Order. Da wir die Datei nur schreiben und nie löschen darf es nicht passieren, dass diese weg ist. Auch das Erstellen von der Backup Datei ist ein Copy Operation. Somit sollte zu jedem Zeitpunkt eine settings.json verfügbar sein. Und falls korrupt beim Neustart → Dann wird eine alte genommen.
Und, falls wir aus dem Backup Ordner welche laden, kopieren wir die korrupte Datei in eine settingsXXXXXXXX.failure.json, sodass du genau nachsehen kannst, was da schief gelaufen ist.
Ich habe noch mal geschaut und meiner Meinung nach wird niemals die Datei gelöscht.
Nein, habe ich testweise alles abgeschaltet. Die Probleme fingen gestern mit einem Update des UniFi-Servers an.
Habe jetzt eben den ganzen TCP/IP-Stack und Winsockets zurückgesetzt. Jetzt kommt zumindest die UDP-Verbindung wieder hoch. Multicast geht weiterhin nicht.
Ich muss später noch mal in Ruhe gucken. Bin froh, dass zumindest die Grundfunktionen gerade wieder gehen. Ich traue dem Braten aber nicht. Hatte heute auch schon wieder mehrfache Neustarts des IPS-Dienstes.
Wenn alle Stricke reißen, muss ich IPS erst mal auf ein anderes System umziehen, bis ich weiß, was da nicht stimmt.
Also das mit der leeren Setting.json kann ich in der Form von @Slummi bestätigen - ist allerdings schon sicherlich 1 Jahr aus. Auch an eine settingsxxx.failure.json könnte ich mich nicht entsinnen.
Die Sache mit dem Socket Zugriffsproblem kenne ich - das verfolgt mich seit Jahren von Zeit zu Zeit nach einem Rechnerneustart.
Dann hilft es bei mir immer den Rechner nochmals neu zu starten.
Ich hatte dies auch schon mal in einem Thread zur Diskussion gebracht - leider damals ohne Rückmeldung.
Ich hab auch noch keine Möglichkeit gefunden dies zu prüfen und darauf zu reagieren.
Hope - it helps i little bit.
Da hätte ich noch eine Frage zur Sicherung der settins.json.
Auf einem windows Server 2016 läuft Symcon. Im Backup Verzeichnis sind 25 Settingsxxxx.json
aber nur von 2025 (die letzte am 16.08.2025). Wann werden die erzeugt?
Ich habe den Multicast-I/O jetzt erst mal ans Laufen gekriegt.
Ich bin mir zwar noch nicht so ganz sicher, ob das wirklich die Ursache war, aber es geht aktuell wieder.
Ich habe auf meinem Netzwerkdapater mehrere IPv4-Adressen aus unterschiedlichen Netzen. Das liegt daran, dass die tollen Smart Meter Gateways in Deutschland ja feste IP-Adressen auf der HAN-Schnittstelle kriegen, die man nicht ändern kann. Ich hatte keine Lust mir dafür extra Routen einzurichten und habe einfach den IPS-Server direkt dran gehängt.
Das war bisher zwar nie ein Problem, aber vielleicht ist zwischenzeitlich irgendwas durcheinander geraten und die Multicast-Adresse hat sich irgendwie an die falsche IP gebunden. Ich habe die zweite Adresse temporär raus genommen und den Dienst neu gestartet, dann kam der I/O wieder hoch. Danach wieder die zweite Adresse hinzugefügt. Mal gucken, ob es jetzt erst mal so bleibt.
Jetzt muss ich noch ergründen, was bei den Modbus-Geräten schief gelaufen ist, dass die plötzlich andere Zählerstände senden als vor dem Crash. Wahrscheinlich wieder irgendwelche verrückten Zufälle, die man sich nicht erklären kann.