Dieses Kapitel beschreibt, wie Daten und Einstellungen auf einen anderen Servern migriert werden können, z.B. wegen einem Wechsel des Servers.

Vorwort

Das Funktionsmodul Datensicherung V4 verfügt über eine Unterstützung zur Migration von Einstellungen und Daten zwischen Servern, auch basierend auf verschiedenen Modellreihen.

Um die Individualität des Zielservers (ID, lokale Crypto-Parameter usw.) und den Datenschutz zu erhalten und damit es keine Konflikte mit dem lokalen Netz des Zielservers nach der Migration gibt, wird aus Sicherheitsgründen kein vollständiger Klon erzeugt.

Deshalb empfhelen wir Ihnen die Prüfung nachfolgend dargestellter Punkte. Bitte lassen Sie sich nicht vom Umfang erschrecken, das meiste davon läßt sich zügig abarbeiten und einiges muss nur in besonderen Fällen beachtet werden.

Begriffe

• Quellserver ist derjenige Timberwolf Server, auf dem die Datensicherung angefertigt wurde

• Zielserver ist derjenige Timberwolf Server, auf dem die Datensicherung wiederhergestellt wird

• Migration ist der Vorgang, bei dem eine Datensicherung auf einem Zielserver wiederhergestellt wird, dessen TWS ID nicht die selbe ist wie die ID des Quellservers.

• Migration zwischen Modellreihen ist eine Migration, bei welcher Quell- und Zielserver aus verschiedenen Modellreihen stammen. Derzeit wird eine Migration zwischen Modellreihen nur von Servern der Modellreihe 3xx/9xx auf die Modellreihe 3500 unterstützt.

• ElabNET USB Backup Stick: Dies ist ein zertifizierter USB Stick, der mit allen Modellreihen des Timberwolf Servers und mit jeder Firmware ab V 3.5.1 genutzt werden kann. Dieser Stick wird zwingend für eine Migration benötigt, da nur mit diesem externen Datenträger eine Migration durchfürbar ist. Dieser USB Stick ist nicht mit einem Server verbunden. Sie können einen Stick für die Datensicherung mehrerer Server (hintereinander) verwenden, also auch mehrere USB Sticks an einem Server anschließen.

Gefahrenhinweise & Wissenswertes

Die Wiederherstellung einer Datensicherung auf einen Zielserver bedeutet, die meisten bestehenden Daten und Einstellungen auf dem Zielserver zu überschreiben. Dies ist unumkehrbar, sofern Sie über keine extern gespeicherte und aktuelle Datensicherung des Zielservers verfügen.

Im Einzelnen bedeutet eine Wiederherstellung aus einer Datensicherung:

• Serverfunktionen und Docker Container werden suspendiert: Fast alle Subsysteme werden bei Beginn der Wiederherstellung gestoppt. Dies betrifft auch alle APPs und Docker Container. Der betreffende Timberwolf Server stoppt damit alle Services, die Kommunikation über Bussysteme und IP-Protokolle mit externen Geräten, führt keine Logiken mehr aus, speichert keine letzten Werte im Dispatcher sowie keine Logs und Zeitserien und wird nach der Wiederherstellung automatisch NEU gestartet.

• Konfiguration: ALLE Einstellungen und Konfigurationen aller Funktionsmodule und Subsysteme werden zurückgesetzt und aus der Sicherung wiederhergestellt

• Objekte: Alle Objekte und deren letzten bekannten Objektwerte sowie Verknüpfungen werden zurückgesetzt und aus der Datensicherung wieder hergestellt.
  WARNUNG Die Timberwolf VISU ließt bei jedem Start die letzten Objektwerte aus dem System für eine sofortige Darstellung. Im Falle einer Wiederherstellung werden womöglich sehr alte Werte vom Quellserver restauriert, die mit dem automatischen Start - eines in der Datensicherung enthaltenen Visu-Profils - angezeigt werden.

• Logiken: ALLE Logiken inkl. Persistenzstatus werden zurückgesetzt und aus der Datensicherung wieder hergestellt.
  HINWEIS Ein gegebenenfalls konfigurierter Doktormodus einer Logikzelle wird nur dann aus der Sicherung wieder hergestellt, wenn die betreffende Logikzelle zum Zeitpunkt der Datensicherung in der Betriebsart “Persistenz” betrieben wurde. Der Grund dafür ist, dass während der Wiederherstellung der Logik-Service gestoppt wird und damit werden alle Einstellungen zum Doktormodus zurück gesetzt, außer eine Logikzelle ist persistent.

• Reverse-Proxy und Grafana: Die Konfiguration des Reverse-Proxys und Grafana Konfiguration wird komplett aus der Sicherung ersetzt

• Timberwolf VISU: Alle Einstellungen der Timberwolf VISU wie VISU Profile, VISU Instanzen und Widgets werden komplett zurückgesetzt und durch die Sicherung ersetzt.
  WARNUNG Mit Ende der Migration startet der Server neu und die VISI Instanzen werden neu gestartet und lesen die letzten verfügbaren Werte aus dem Objektverteiler aus. Diese Werte stammen jedoch aus der Sicherungsdatei und können stark veraltet sein. Weisen Sie die Nutzer der VISU darauf hin. Mit Aufnahme des Betriebes und empfang aktueller Werte sollte sich Aktualität einstellen, sofern der Zielserver mit den selben Geräten verbunden ist und alle Transaktionen auf allen Subsystemen wie zuvor funktionieren.

• Nutzer-VPN: Alle Einstellungen zum Nutzer-VPN wie Zertifikate und Profile werden komplett aus der Sicherung ersetzt.
  HINWEIS Netzwerkeinstellungen des Quellservers werden von der Sicherung nicht erfasst und damit auch nicht auf dem Zielserver wiederhergestellt. Womöglich befindet sich der Zielserver auch in einem völlig anderen Netzwerk. Der User-VPN Server könnte dadurch nicht mehr von außen erreichbar sein und - je nach Einstellungen - könnte auch die interne ntRückroute nicht oder nicht passend konfiguriert sein.

• KNX-Einstellungen: Die KNX Programmierung des Stacks mit BAU-Schlüssel sowie alle im lokalen Projektspeicher befindlichen, zuvor importierten ETS Projekte werden gelöscht und mit den Einstellungen und Projekten aus der Sicherung ersetzt.
  HINWEIS Eine erneute KNX Programmierung ist zwar nicht nötig, allerdings übernimmt der Zielserver damit die Programmierung des KNX Stacks vom Quellserver. Dies bedeutet auch, dass alle Physikalischen Adressen (“PA”) übernommen und mit Restart aktiv am Bus sind. Eine parallele Nutzung von Quell- und Zielserver bei gleichzeitigem Anschluss beider Server am KNX Bus sollten Sie daher vermeiden. Entweder der eine, oder der andere Server ist am selben KNX System angeschlossen.
  HINWEIS Sollten Sie den Zielserver in einer anderen KNX Umgebung nutzen, dann empfehlen wir, den Zielserver erst dann am dortigen KNX Bus anzuschließen, wenn die passende Programmierung mit der ETS vorgenommen wurde. Bitte denken Sie daran, dass hierdurch KNX Objekte gelöscht oder anders belegt (mit anderen GAs, DPT) werden, die intern bereits (zu einem anderen Zweck am Quellserver) verknüpft waren. Gehen Sie daher jedes KNX Objekt einzeln durch und vergleichen GA Zuordnungen, DPT und alle internen Verknpfungen.

• 1-Wire Einstellungen: Mit der Wiederherstellung werden ALLE 1-Wire Einstellungen zu Busmaster und 1-Wire Geräten inkl. angelegter Transaktionen aus der Sicherung restauriert.
  HINWEIS Damit können nach der Migration Busmaster und Geräte angezeigt werden, die auf dem Zielserver nicht existent sind bzw. nicht an diesem angeschlossen sind. Zum Beispiel wird der in der Modellreihe 3xx / 9xx enthaltene Busmaster bei Wiederherstellung auf einem Zielserver anderer Modellreihen auf Grundlage der Informationen der Sicherungsdatei angezeigt und muss manuell gelöscht werden. Gleiches gilt für 1-Wire Geräte die am Zielserver nicht mehr - über welchen Busmaster auch immer - genutzt werden, um das Polling nicht existenter Geräte zu sparen. Bei iButtons ist darauf zu achten, dass diese für bestimmte 1-Wire Kanäle definiert sind, die nach einer Migration am Zielserver womöglich dort nicht existieren.

• Netzwerk Einstellungen und IP basierte Protokolle: Netzwerk Einstellungen werden nicht gesichert und damit auch nicht wiederhergestellt. Damit bleiben die Netzwerk Einstellungen durch die Migration unangetastet. Dies erlaubt, den Zielserver parallel zum Quellserver zu betreiben und auf beide Server gleichzeitig administrativ zugreifen zu können.
  HINWEIS Beim Reboot nach der Migration beginnen alle Dienste automatisch mit der Ausführung gemäß übernommener Konfiguration. IP basierte Dienste wie Modbus TCP, HTTP-/Rest-API, MQTT, IFTTT und ekey würden damit mit der - anderen - IP-Konfiguration des Zielservers starten, dies kann zu Problemen führen. Empfehlungen dafür unter Planung einer Sicherung für Migration und den Schritten nach erfolgter Migration.
  HINWEIS Bitte beachten Sie, dass im Falle des Rücksetzens auf Auslieferzustand, die Netzwerkeinstellungen auf DHCP zurückgesetzt werden.

• Aufzeichnungen: Alle Aufzeichnungen in Logs, Zeitserien und Logicscope (Doktormodus Aufzeichnung) werden zurück gesetzt und komplett aus der Sicherung ersetzt.

• Lizenzinformationen: Informationen zu Wartungsverträgen und Produktkäufe sind ausschließlich in der Timberwolf Cloud unter der jeweiligen ID gespeichert. Diese werden durch eine Migration nicht automatisch angepasst. Bitte klären Sie mit dem ElabNET Support, welche Form von Umzug / Anpassung für Ihren Fall möglich ist.

• Systeminformationen des Nutzers: Im Timberwolf Server können nutzerspezifische Informationen hinterlegt werden. Diese werden gesichert und bei einer Migration vom Zielserver übernommen. Falls in diesen Systeminformationen Angaben gemacht sind, die zum Quell- aber nicht zum Zielserver passen, kann dies nach der Migration am Zielserver zu Irritationen führen.

• Docker Volumes und TWS APP Daten Volumes: Alle bei der Sicherung mit eingeschlossenen Docker Volumes und TWS APP Daten Volumes werden wiederhergestellt. Bereits auf dem Server vorhandene Docker Volumes und TWS APP Daten Volumes mit derselben Benennung werden komplett ersetzt.

  • Docker Volumes, die vor der Wiederherstellung bereits auf dem Timberwolf Server vorhanden waren UND nicht in der Datensicherung enthalten sind, werden bei der Wiederherstellung nicht angetastet.

  • ALLE TWS APP Daten Volumes werden grundsätzlich im Rahmen der Wiederherstellung geleert. Nur diejenigen TWS APP Daten Volumes, die Bestandteil der Datensicherung waren, werden durch die Wiederherstellung aus der Sicherung wieder befüllt.

• Benutzerkonten: Lokale und verbundene globale Benutzerkonten inkl. der Passwort-Hashes werden aus der Sicherung restauriert, wobei das lokale Konto “admin” auf Werkseinstellungen zurückgesetzt wird (bitte zusätzlichen Hinweis unten beachten).
  HINWEIS Da der Zielserver ein anderes “Salz” benutzt für das Hashen der Passwörter, schlagen alle Logins mit anderem Benutzerkonten (außer “admin”) nach der Wiederherstellung fehl. Alle anderen Benutzer müssen das Passwort erneut anlegen.

• WARNUNG Globale Benutzerkonten: Benutzerkonten vom Typ Elab ID, die ZUVOR für die Anmeldung am Zielserver freigeschaltet waren, können auch nach der Migration zur Anmeldung genutzt werden, SOFERN die Datenschutz-Einstellungen dies erlauben (Aktivierung Timberwolf Cloud & Elab ID) UND zum Anmeldezeitpunkt eine Verbindung zur Timberwolf Cloud besteht.

• HINWEIS Neustart nach Wiederherstellung: Der Timberwolf Server wird nach der Wiederherstellung automatisch neu gestartet. Mit diesem Start werden alle Services und Dienste mit der aus der Sicherung übernommenen Konfiguration gestartet.

• WARNUNG Nur mit ElabNET USB Stick möglich: Eine Wiederherstellung von einem anderen Server kann ausschließlich mit dem “ElabNET Backup USB Stick” vorgenommen werden. Ein Umstecken einer SD- oder µSD Karte wird nicht unterstützt, da die IDs der jeweiligen Karte fest mit dem Quellserver verknüpft sind.

• WARNUNG Rücksetzen Admin-Passwort: Das Passwort des Benutzerkontos "admin" wird bei der Wiederherstellung automatisch zurücksetzt auf dasjenige Passwort, das sich auf dem Geräteetikett des ZIELSERVERS befindet. Dieses Etikett sollte sich seitlich oder unten am Zielserver befinden. Prüfen Sie - BEVOR Sie mit der Migration beginnen - dass Sie dieses Passwort auf dem Geräteetikett lesen können. Führen Sie diese Migration nicht aus, falls Sie dieses Passwort JETZT NICHT VORLIEGEN haben, weil Sie sich danach womöglich nicht mehr anmelden können.

Vorbereitende Schritte vor der Migration

• Datensicherung Zielserver (opt.): Mit Migration werden Einstellungen und Daten des Zielservers aus der Datensicherung ersetzt. Dieser Vorgang ist unumkehrbar. Je nachdem, welche Daten und Einstellungen sich auf dem Zielserver befinden, ist es empfehlenswert, zuerst eine Datensicherung des Zielservers auf einen externen Datenträger vorzunehmen. Hierzu ist der ElabNET USB Backup Stick notwendig. Auf dem selben Stick können Sie eine Sicherung des Zielservers ablegen, als auch die Sicherung des Quellservers. Bei der Wiederherstellung zeigt Timberwolf Server stets die ID und die Modellreihe an, von der eine Datensicherung vorgenommen wurde.

• Zurücksetzen des Zielservers (opt.): Ggfls. möchten Sie den Zielserver vor der Migration auf den Auslieferzustand zurücksetzen, um jegliche Einstellungen und Daten zu löschen. Dies ist dann empfehlenswert, wenn der Server zuvor anderweitig in Benutzung war, z.B. gebraucht gekauft wurde. Damit wird eine komplette Bereinigung durchgeführt. Bitte unterbrechen Sie die Stromzufuhr hierbei nicht, da sonst die Gefahr besteht, dass der Rücksetzprozess zu einem Zeitpunkt unterbrochen wird, der einen anschließenden Reboot verhindert. Dies ist ein theoretischer Hinweis. Es wurde noch nie ein Timberwolf Server wegen eines Rücksetzprozesses in einen Zustand versetzt, dass ein anschließender Reboot nicht möglich war. Falls dies passieren soll, wenden Sie sich bitte an den Support.

• Update Zielserver: Bitte führen Sie ein Update der Firmware auf möglichst die gleiche Version durch, wie diese der Quellserver hat. Falls dies nicht möglich ist, weil nur eine neuere Version für den Update zur Verfügung steht, dann führen Sie das Update auf die neuere verfügbare Version durch. Wir empfehlen mindestens die aktuellste verfügbaren Insider Preview zur V4 zu nutzen oder - soweit verfügbar - die Firmware V4 oder neuer. Sofern die Hauptversion V4 noch nicht verfügbar ist, fragen Sie bitte beim Support nach einer Interim insider Lizenz an.

• Update Quellserver: Bitte führen Sie ein Update der Firmware auch auf dem Quellserver durch, nach Möglichkeit auf die selbe Firmware Version bei der Zielserver.

• Bussysteme abstecken: Wir empfehlen Ihnen, die Bussysteme KNX und 1-Wire vor Beginn der Migration vom Zielserver abzustecken. Damit soll vermieden werden, dass es zu unkontrollierter Interaktionen mit dem Bus kommt, insbesondere bei paralleler Nutzung beider Server am selben Bussystem mit geklonten Adressen (hier PA am KNX-TP). Dies gilt auch, wenn der Zielserver an einem komplett anderen KNX Bus genutzt werden soll. Hier wäre es gefährlich, wenn der Server mit der Konfiguration des Quellservers startet, im Falle einer abweichenden GA Struktur.

• Verfügbarkeit Admin Passwort prüfen: Das Passwort des Benutzerkontos "admin" am Zielserver wird bei der Migration zurücksetzt auf dasjenige Passwort, das sich auf dem Geräteetikett des Zielservers befindet. Dieses Etikett sollte sich seitlich oder unten am Zielserver befinden. Prüfen Sie unbedingt - BEVOR Sie mit der Migration beginnen - dass Sie dieses Passwort vorliegen haben. Führen Sie diese Migration nicht aus, falls Sie dieses Passwort NICHT VORLIEGEN haben.

Planung einer idealen Sicherung zur Nutzung für Migration

Wenn Sie die Migration der Einstellungen und Daten auf einen anderen Timberwolf Server planen, dann empfehlen wir, den Quellserver vor der Sicherung so anzupassen, dass es weder bei parallelem Doppelbetrieb noch bei der Nutzung des Zielservers in einem anderen technischen Umfeld als der Quellserver zu unerwarteten Problemen kommen kann.

Der Zielserver wird nach der Wiederherstellung der Sicherung automatisch gestartet und nimmt sofort seine Funktionen mit den neuen Einstellungen auf. Dies bedeutet, dass der Zielserver über alle Subsysteme und angeschlossenen Bussysteme zu kommunizieren beginnt, Logiken ausgeführt, Zeitreihen ergänzt werden und eine eingerichtete VISU publiziert wird. Dies kann, insbesondere bein parallelem Betrieb zum Quellserver im gleichen Netz, aber auch bei Migration zu einem Server in einer anderen Umgebung, zu Interaktionen kommen, die je nach Umfang der Konfiguration schwer überblickbar sein können.

Die sicherste Vorgehensweise besteht darin, alle Funktionen des Quellservers soweit möglich zu suspendieren, erst dann die Sicherung vorzunehmen, am Zielserver keine Bussysteme parallel anzustecken und erst dann zu migrieren.

VOR der Sicherung:

• Informieren: Wir empfehlen alle anderen Nutzer in diesem smarten gebäude darüber zu informieren, dass es durch die vorbereitenden Maßnahmen zu einer eingeschränkten Nutzbarkeit von Funktionen kommen kann.

• Timberwolf VISU Instanzen beenden: Stoppen Sie alle Timberwolf VISU Instanzen, damit die VISU nicht mehr veröffentlicht wird. Dies dient dazu, dass keine falschen Anzeigen entstehen durch nachfolgende Schritte und die VISU auch nicht nach Migration automatisch am Zielserver gestartet wird (mit veralteten, da zwischengespeicherten Werten aus der Datensicherung)

• Logiken und Verknüpfungen prüfen: Im nächsten Schritt werden wir Sie bitten, alle IP-basierenden Protokolle zu suspendieren. Dies kann zu Problemen mit laufenden Logiken und Verknüpfungen führen. Bitte prüfen Sie Ihre Automatisierungen und Logiken hinsichtlich der nachfolgend angeratenen Suspendierung aller IP-Protokolle und Dienste. Prüfen Sie auch alle Logiken hinsichtlich der Persistenzeinstellungen, da hiermit der aktuelle Status einer Logik mitgespeichert und nach Migration am neuen Server genau si

• Alle IP-Protokolle und Dienste suspendieren: Stoppen Sie die Ausführung aller IP-Dienste in den Verbindungseinstellungen, soweit dies betrieblich möglich ist. Dies gilt für Modbus TCP, HTTP-/Rest-API, MQTT und IFTTT. Bei der Sicherung wird diese suspendierte Einstellung der IP-Protokolle mit gespeichert, damit starten diese Dienste am Zielserver nach der Migration nicht und damit nicht unkontrolliert und schon gar nicht doppelt und parallel zum Quellserver und mit anderen Netzwerkeinstellungen. Prüfen Sie zuvor die Auswirkungen ausbleibender Interaktionen über diese IP-Dienste in Verbindung mit Logiken und anderen Bussystemen. Ggfls. müssen Sie Logiken deshalb anhalten bzw. auch die Kommunikation über KNX / 1-Wire / Modbus RTU einschränken oder stoppen.

• Systeminformationen des Nutzers: Passen Sie ggfls. die Angaben in den Systemeinstellungen des Nutzers so an, dass nach der Migration keine Irritationen in der Web-APP des Zielservers entstehen (etwa weil Sie die ID des Quellservers sich in Kopf-. und Fußzeilen oder auf der Anmeldeseite anzeigen lassen, Farbkodierungen bei mehreren Servern nutzen usw.

Durchführen der Sicherung am Quellserver

Nehmen Sie nun die Sicherung am Quellserver so vor, wie in diesem Kapitel beschrieben: Datensicherung vornehmen

Durchführen der Migration

• Informieren: Wir empfehlen alle anderen Nutzer in diesem smarten gebäude darüber zu informieren, dass es folgend zu einer eingeschränkten Nutzbarkeit von Funktionen kommt.

Maßnahmen nach erfolgter Migration

Wichtige Maßnahmen NACH der Migration (auf anderen Server gleiches Modell bzw. anderen Server unterschiedliches Modell)

• Elab ID: Benutzerkonten vom Typ Elab ID, die VOR der Migration durch Wiederherstellung für die Anmeldung am ZIELSERVER freigeschaltet waren, können auch nach der Wiederherstellung zur Anmeldung genutzt werden, SOFERN die in der Sicherungsdatei hinterlegten Datenschutz-Einstellungen dies erlauben oder die Datenschutzeinstellungen anschließend angepasst werden (hierbei Aktivierung Timberwolf Cloud & Elab ID) UND zum Anmeldezeitpunkt (künftig, irgendwann) eine Verbindung zur Timberwolf Cloud besteht (weil die Verknüpfung des ZIELSERVERS zur Elab ID in der Timberwolf Cloud hinterlegt ist und dies durch die Rücksicherung nicht berührt wird)
  Sie müssen in der Benutzerverwaltung alle ElabID trennen und dann über die Schaltfläche “Bestehende Elab ID mit diesem Server nutzen” neu verbinden (hierfür sind die jeweiligen Passwörter anzugeben).
  
  Elab ID Benutzerkonten, die zuvor auf dem QUELLSERVER angelegt wurden, von dem die Datensicherung stammt und NICHT für die Nutzung mit dem ZIELSERVER ZUVOR freigeschaltet wurden, können anschließend erst dann wieder am ZIELSERVER genutzt werden, wenn diese jeweils durch den Benutzer "admin" zuerst getrennt und anschließend über die Schaltfläche “Bestehende Elab ID mit diesem Server nutzen” erneut verbunden werden. Für diese Verknüpfung wird das jeweilige Passwort benötigt.
  
  HINWEIS Dieser Schritt ist insbesondere ERFORDERLICH, falls Sie IFTTT auf dem Quellserver benutzt haben und IFTTT auf dem Zielserver weiterbetreiben möchten, da die Verbindung zum IFTTT Service auf einer Elab ID basiert und deren Re-Verknüpfung mit dem Zielserver essentiell für IFTTT ist.

• Benutzerverwaltung: Die Anmeldung mit LOKALEN Benutzerkonten ist zunächst nicht mehr möglich. Nur der Benutzer "admin" kann eine Reaktivierung für jedes LOKALE Benutzerkonto durch Vergabe eines Passwortes vornehmen. Das Kennwort des Benutzerkonto “admin” wurde durch die Migration auf Werkseinstellungen zurückgesetzt und entspricht der Angabe auf dem Geräteetikett.

• Support-VPN: Der Status und die Konfiguration des Support-VPN sind nicht in der Datensicherung enthalten und werden auch nicht wieder hergestellt. Prüfen Sie den Status und die Konfiguration des Support-VPN nach der Migration, ob diese Ihren Wünschen entspricht.

• TWS VISU: Falls der VISU Client sich nicht mehr mit dem Zielserver verbindet, dann setzen Sie in den lokalen VISU Client Einstellungen den Cache zurück (dies initiiert einen neuen Schlüsselaustausch mit dem Zielserver für das VISU Protokoll)

Systeminformationen

Datenschutzeinstellungen

Achtung bei IP-Services, KNX PAs, grünes Kabel

Wichtige Maßnahmen NACH der Wiederherstellung

• Doktormodus ggfls. wieder aktivieren (weil komplett für alle Logiken ohne Persistenz durch Restart des Services zurückgesetzt)

• IFTTT: Zeigt neue Server an, die Applets müssen umgesetzt werden. Beachten Sie dazu die separate Anleitung im Unterkapitel.

• Dazu rufen Sie die Web-APP bzw. die APP von IFTTT auf um Applets zu bearbeiten.

• 

Zusätzlich, falls Sie den Server vor der Rücksicherung auf Auslieferzustand zurückgesetzt haben

• Netzwerkkonfig wurde dadurch auf DHCP geändert, damit andere IP und in Portainer nachführen

Zusätzlich, bei geänderter IP und / oder einem anderen Netz mit geänderter Namensauflösung

• Portainer nachführen, MacVLAn etc. macVLAN Netzwerkkonfig wird nicht restauriert, andere IP und in Portainer nachführen

• Prüfen Reverse-Proxy-Ziele

• ekey anpassen im Falle einer anderen IP

• Firewalls, Filter, NAT-Regeln, Port-Forwardung, Routing, MQTT Einschränkungen und sonstige Geräte anpassen im Falle einer anderen IP, PiHole

• KNXnet/IP Nutzung durch dritte Dienste / geräte prüfen

• Kompletter Chec