So, jetzt habe ich es geschafft und werde es hier mal niederschreiben. Aufgabe: Docker-Container auf v9 hochrüsten / ioBroker (Master) aus einem Backup wiederherstellen Gegeben: ioBroker in einem veralteten Docker-Container (v6 von Buanet, allerdings per update/upgrade auf den neuesten Stand gehalten inkl. node-js v18) Master im Multihost ioBroker als Slave in VM im Proxmox mit Zigbee-Instanz States werden in Redis in einem Docker-Container gespeichert Backups mit BackItUp-Adapter Hier meine Vorgehensweise, wie es geklappt hat: Vorgehen: alle Adapter in der bisherigen Installation auf den aktuellsten Stand gebracht und im Nachgang den js-controller ebenso upgedatet über den BackItUp-Adapter ein aktuelles Backup gemacht und zusätzlich die Konfiguration vom Adapter gesichert neuen Docker-Container mit latest-v9 gepullt und auf ein leeres iobroker-data -Verzeichnis "ausserhalb" schauen lassen Container starten, er installiert den ioBroker in einer jungfräulichen Version über die Weboberfläche die Grundeinstellungen vornehmen und im Nachgang das Repositorie anpassen, wenn man im Altsystem beta benutzt hatte Adapter (Admin, BackItUp) updaten und js-controller auf die aktuellste Version bringen Slave neu eingerichtet, also in meinem Fall eine neue VM mit aktuellsten Debian eingerichtet und darin ioBroker installiert siehe Anleitung Proxmox Wichtig! selbe IP-Adresse und Hostname vergeben, wie der alte Slave auf dem Slave die Weboberfläche aufrufen, ioBroker einrichten, aber im Nachgang alle Adapter löschen (Admin, BackItUp und Discovery) - js-controller ebenfalls auf den neuesten Stand bringen nun die Multihost-Verbindung einrichten, dies ging bei mir nur mit ìobroker setup custom dazu gibt's hier die Anleitung nach einem Neustart sollte der Slave im Reiter Hosts beim Master zu finden sein dann habe ich in meinem speziellen Fall noch eine zweite BackItUp-Instanz auf den Slave installiert in beiden BackItUp-Instanzen habe ich die im alten System gesicherte Konfiguration eingespielt im Master-BackItUp habe ich dann das letzte Backup geladen zum wiederherstellen es wird ein Restore angestossen und der Container automatisch neugestartet, danach werden alle Adapter/Instanzen nach und nach neu installiert (das dauert je nach Menge) sollte eine Instanz nicht installiert werden können (in meinem Fall der VIS-Adapter), dann diesen einfach neuinstallieren aus dem Adaptermenü, hatte bei mir gereicht, ansonsten deinstallieren und dann neu installieren die Instanzen waren alle auf Stop und die vom Slave nicht installiert, sollte dies nach einem Neustart beider Systeme immer noch so sein, dann die Instanz die auf dem Slave liegt starten, dieser wird dann so nachinstalliert bei einigen Instanzen die ich starten wollte, kam im Log die Meldung, dass dieser schon läuft, hier einfach Ruhe bewahren, nach einiger Zeit wird er grün Zigbee auf den Slave waren zwar alle Geräte da, aber kein Connect und es tat sich auch nichts Zigbee-Instanz beendet und dann händisch über FTP die Dateien shepherd.db und nvbackup.json aus dem Backup in das Verzeichnis /opt/iobroker/iobroker-data/zigbee_0 kopiert, danach Instanz wieder starten und alles ist korrekt So habe ich mein System auf den neuesten Stand bekommen, alles läuft und ist wieder sauber. Mit Sicherheit ist das ein oder andere auch anders zu lösen, aber so hat es bei mir geklappt. Danke an @Homoran @Meister-Mopper @FredF

Hallo menfis, soweit ich den maxcul -Adapter verstanden habe, kann dieser leider nur serielle Verbindungen herstellen. Verbindungen via LAN sind nun mal nicht seriell. Warum du allerdings zeitweise trotzdem eine Verbindung bekommst erschließt sich mir leider nicht. Entweder du schließt den geflashten Cube via USB an und reichts den USB-Port an deinen Docker-Container durch oder du wandelst den LAN-Anschluß in einen virtuellen ser. Anschluß um. Der geflashte MAX-Cube kann beides. Wie und ob das mit Docker funktioniert, kann ich dir nicht sagen, da ich den IOBroker als VM unter Proxmox betreibe und mich nicht ansatzweise mit Docker auskenne. Meine Lösung für mein System hast du ja sicher schon gefunden. Ich denke socat wird auch deine Problemlösung sein. Einfach mal etwas herum probieren. Viel Erfolg dabei. Jens

Vielen Dank an alle für die Hilfestellungen und Anregungen!

@reutli Ja. Evtl. mal neu starten (Oder sourcen), damit das auch übernommen wird.

@loverz sagte in InfluxDB Name von Datenpunkt geändert -> Daten übernehmen: Geht es auch, dass man den alten Datenpunkt in den neuen übernimmt? ALso umgekehrt? Moin, da als info nur influxDB V 1 genannt wird, mal gegoogelt ⇒ https://www.laub-home.de/wiki/Influxdb_umbenennen_von_Measurements Für influxDB V1 gibt es auch eine GUI https://github.com/CymaticLabs/InfluxDBStudio VG Bernd

@camouflagge Viel Text, aber leider nicht so viel Information. :-) Zeig' doch mal deine Einstellungen: MQTT Adapter als Broker Datenpunkt, der published werden soll "mqtt in" Node Wie sieht der Payload aus?

Läuft wieder alles Danke nochmals

@marc-berg DANKE!!! das wars.

@marc-berg danke!!! das war es auch bei mir. wer kann wohl denn beantworten, ob an anderer stelle was angepasst werden kann, um das intervall herunterregeln zu können? mir üwrde reichen, wenn der adapterstatus alle paar minuten aktualisiert würde. mir geht es um einen möglichst sparsamen server - in jeglicher hinsicht.

@rolf-achim said in Admin-Adapter startet nach Update nicht mehr - gelöst: @mcm57 Wenn man den aktuellen Update für einen Adapter über die Admin-Konsole einspielt, bekommt man eine Warnung, falls node.js nicht kompatibel ist. Wenn man aber im Experten-Modus eine frühere Version installiert, kommt keine Warnung. Man sieht nur im Logfile, das es nicht funktioniert hat. [image: 1699016963890-4e656d99-76a2-426d-b05b-e15c3051b589-image.png] Wenn dem so ist - und ich bezweifle nicht was du schreibst - mach bitte ein issue im admin repo auf. Das sollte geprüft werden obd as so gewunschen ist.

@loverz sagte in Adapter Updates sehr langsam, viele Warnmeldungen: das kommt aber bei jedem Adapter Update. Natürlich, weil diese Hinweise jedesmal kommen, wenn npm durch deine Installation schaut und diese Dinger entdeckt.

@dp20eic ja, ich hatte dann nun auch das hier gefunden: https://forum.iobroker.net/topic/52456/iobroker-restlos-deinstallieren/4?_=1699011743223 Danke Dir

@thomas-braun said in Backup wiederherstellen mit Adadpter Backitup: Was haste denn da für einen Backup-Server? SMB/CIFS? NFS? CIFS. Jetzt hat es aber hingehauen! Das Problem war, glaube ich zumindest, dass ich bei SMB Typ immer 3.1.1 ausgewählt hatte. Habe daraufhin nochmal in meiner Synology nachgesehen und dort war die Grenze von SMB 1 bis maximal SMB 2 angegeben. Habe diese dann auf SMB 3 erhöht. Danach hat es funktioniert. Vielen Dank für die Hilfestellung!

@paul53 Hallo Paul, ich habe das Script gerade ausprobiert. Top! Gibt es eine Möglichkeit die Verknüpfungen mit den Programmen auch automatisch mit ändern zu lassen, oder gibt es eine Möglichkeit pro Datenpunk die Programme anzeigen zu lassen, mit welchem der Datenpunkt verknüpft ist.

@bernd-0 sagte in In meiner Installation steckt der Teufel: nur das Netzteil vom Pi ausgeschalten hatte. Und genau darum macht man sowas nie, nie, nie. Immer sauber herunterfahren. sudo poweroff

@haus-automatisierung sorry

@ilovegym Ich habe heute den Benchmark nochmal laufen lassen, nachdem iobroker zwecks update eh gestoppt war: redis-benchmark -h 10.10.10.194 -q -n 100000 PING_INLINE: 30102.35 requests per second, p50=0.823 msec PING_MBULK: 27034.33 requests per second, p50=0.959 msec SET: 27196.08 requests per second, p50=1.007 msec GET: 28960.32 requests per second, p50=0.887 msec INCR: 27322.40 requests per second, p50=0.815 msec LPUSH: 29481.13 requests per second, p50=0.887 msec RPUSH: 27337.34 requests per second, p50=0.959 msec LPOP: 27449.90 requests per second, p50=0.927 msec RPOP: 26288.12 requests per second, p50=0.999 msec SADD: 26702.27 requests per second, p50=0.975 msec HSET: 27137.04 requests per second, p50=0.967 msec SPOP: 29629.63 requests per second, p50=0.863 msec ZADD: 26766.60 requests per second, p50=0.975 msec ZPOPMIN: 28019.05 requests per second, p50=0.919 msec LPUSH (needed to benchmark LRANGE): 29949.09 requests per second, p50=0.791 msec LRANGE_100 (first 100 elements): 19630.94 requests per second, p50=1.359 msec LRANGE_300 (first 300 elements): 9054.69 requests per second, p50=2.887 msec LRANGE_500 (first 500 elements): 6617.70 requests per second, p50=3.935 msec LRANGE_600 (first 600 elements): 6332.72 requests per second, p50=4.423 msec MSET (10 keys): 27723.87 requests per second, p50=0.975 msec Gruss, Jürgen

soweit ich weis: gar nicht, ist nicht vorgesehen. Du musst also auf ioBroker Seite per Skript rechnen.

@peterpan1108 LOG's in Code Tag packen ..bitte [image: 1698952452613-ae8bed1b-88af-40d5-8349-540da58f854f-grafik.png]

@thomas-braun sagte in Unterschiedlicher Zeitstempel: @valbuz Dann ist es nicht die Systemzeit/Zeitzone. Also ist NodeRed auf UTC und der ioBroker berücksichtigt die lokale Zeit. Keine Ahnung ob man NR da entsprechend konfigurieren kann oder muss. War mir bis jetzt eben noch nie aufgefallen... :man-shrugging: