Fehler während Datenübername von 1.9

[HandyCap87]

Hallo,
ich habe heute einen Versuch gestartet meine Daten der alten OpenWB 1.9 auf 2.1.9 zu übernehmen. Nachdem ich alle Komponenten in 2.1.9 konfiguriert (inkl. Neustart), das Backup von 1.9 hochgeladen und alle zu übernehmenden Komponenten ausgewählt hatte, kam es nach ein paar Minuten zu einer Fehlermeldung:
Es ist ein interner Fehler aufgetreten: 'MigrateData' object has no attribute 'all_received_topics'

Code: Alles auswählen

Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 350, in _daily_log_entry
    "timestamp": datetime.datetime.strptime(f"{file[:-4]} {time}", "%Y%m%d %H:%M").timestamp(),
  File "/usr/lib/python3.9/_strptime.py", line 568, in _strptime_datetime
    tt, fraction, gmtoff_fraction = _strptime(data_string, format)
  File "/usr/lib/python3.9/_strptime.py", line 349, in _strptime
    raise ValueError("time data %r does not match format %r" %
ValueError: time data '20240529 :' does not match format '%Y%m%d %H:%M'
2026-01-26 16:00:07,203 - Fehler beim Konvertieren des Logs vom 20211217.csv
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 276, in convert
    new_entries = self._daily_log_entry(old_file_name)
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 345, in _daily_log_entry
    for row in csv_reader:
_csv.Error: line contains NUL
2026-01-26 16:01:43,121 - Fehler beim Konvertieren des Logs vom 20181119.csv
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 276, in convert
    new_entries = self._daily_log_entry(old_file_name)
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 345, in _daily_log_entry
    for row in csv_reader:
_csv.Error: line contains NUL
2026-01-26 16:03:50,167 - Fehler beim Konvertieren des Logs vom 20200219.csv
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 276, in convert
    new_entries = self._daily_log_entry(old_file_name)
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 345, in _daily_log_entry
    for row in csv_reader:
_csv.Error: line contains NUL
2026-01-26 16:38:40,254 - Fehler beim Konvertieren des Tages-Logs vom 20240529.csv, Reihe ['', '2916859.683333333', '9086547.302321821', '20272910.16700383', '0', '0', '0', '', '3358632.73993947', '3176205.305277778', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '10', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0']
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 350, in _daily_log_entry
    "timestamp": datetime.datetime.strptime(f"{file[:-4]} {time}", "%Y%m%d %H:%M").timestamp(),
  File "/usr/lib/python3.9/_strptime.py", line 568, in _strptime_datetime
    tt, fraction, gmtoff_fraction = _strptime(data_string, format)
  File "/usr/lib/python3.9/_strptime.py", line 349, in _strptime
    raise ValueError("time data %r does not match format %r" %
ValueError: time data '20240529 :' does not match format '%Y%m%d %H:%M'
2026-01-26 16:39:03,270 - Fehler beim Konvertieren des Logs vom 20211217.csv
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 276, in convert
    new_entries = self._daily_log_entry(old_file_name)
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 345, in _daily_log_entry
    for row in csv_reader:
_csv.Error: line contains NUL
2026-01-26 16:40:47,265 - Fehler beim Konvertieren des Logs vom 20181119.csv
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 276, in convert
    new_entries = self._daily_log_entry(old_file_name)
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 345, in _daily_log_entry
    for row in csv_reader:
_csv.Error: line contains NUL
2026-01-26 16:43:07,637 - Fehler beim Konvertieren des Logs vom 20200219.csv
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 276, in convert
    new_entries = self._daily_log_entry(old_file_name)
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 345, in _daily_log_entry
    for row in csv_reader:
_csv.Error: line contains NUL
2026-01-26 16:55:50,928 - Fehler beim Konvertieren des Tages-Logs vom 20240529.csv, Reihe ['', '2916859.683333333', '9086547.302321821', '20272910.16700383', '0', '0', '0', '', '3358632.73993947', '3176205.305277778', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '10', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0']
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 350, in _daily_log_entry
    "timestamp": datetime.datetime.strptime(f"{file[:-4]} {time}", "%Y%m%d %H:%M").timestamp(),
  File "/usr/lib/python3.9/_strptime.py", line 568, in _strptime_datetime
    tt, fraction, gmtoff_fraction = _strptime(data_string, format)
  File "/usr/lib/python3.9/_strptime.py", line 349, in _strptime
    raise ValueError("time data %r does not match format %r" %
ValueError: time data '20240529 :' does not match format '%Y%m%d %H:%M'
2026-01-26 16:57:06,522 - Fehler beim Konvertieren des Logs vom 20211217.csv
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 276, in convert
    new_entries = self._daily_log_entry(old_file_name)
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 345, in _daily_log_entry
    for row in csv_reader:
_csv.Error: line contains NUL
2026-01-26 17:03:35,983 - Fehler beim Konvertieren des Logs vom 20181119.csv
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 276, in convert
    new_entries = self._daily_log_entry(old_file_name)
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 345, in _daily_log_entry
    for row in csv_reader:
_csv.Error: line contains NUL
2026-01-26 17:12:06,057 - Fehler beim Konvertieren des Logs vom 20200219.csv
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 276, in convert
    new_entries = self._daily_log_entry(old_file_name)
  File "/var/www/html/openWB/packages/helpermodules/data_migration/data_migration.py", line 345, in _daily_log_entry
    for row in csv_reader:
_csv.Error: line contains NUL

Die Daten wurden scheinbar übernommen, aber es kommt beim Laden der Diagramme immer zu einer Fehlermeldung:
Fehler beim Berechnen des Strom-Mix

Auch sehe ich meinen als Smart Home hinzugefügten Shelly nicht im Standarddiagramm.

Ich frage mich, ob ich auf 2.1.9 bleiben soll oder doch zurück auf 1.9 muss.

Viele Grüße

[aiole]

Rein softwaremäßig ist 2.1.9 schon die richtige Wahl. Allerdings ist eine 100% Übernahme der Altwerte nicht immer gegeben.
D.h. -> neues Logging.

Ev. hängt es auch daran, dass zu viele Punkte aktiviert sind. Dann würde ich erstmal einzeln testen. Dank Auslesen aus dem 1.9.304-Backup geht erstmal nichts verloren und die 2.1.9 kann man ja notfalls wieder auf Werkseinstellung zurücksetzen.

[HandyCap87]

Schon komisch, warum das nicht gehen soll. Hatte ja nichts besonderes außer einem Shelly. Hatte extra lange gewartet, dass die Software reifen kann, und jetzt fühlt es sich selbst mit 2.1.9 noch an wie Beta.

Jetzt muss ich das Zurücketzen inkl Datenübernahme noch ein paar mal durchlaufen, weil ich nicht weiß, welche Datenquelle für Probleme sorgt. Zudem möchte ich eigentlich alle meine alten Werte behalten.

Oder ich gehe auf die alte Version und openWB fixt das Problem.

[openWB]

Gefühlt hast du eher zu lange gewartet.
Support für 1.9 gibt es von uns auch nur noch kostenpflichtig.

[HandyCap87]

Gefühlt hast du eher zu lange gewartet.
Support für 1.9 gibt es von uns auch nur noch kostenpflichtig.

Eigentlich ist es Logik von 2.1.9. Die Migration ist Bestandteil der neuen Software. Und wie gesagt, ich habe nichts spezielles. Sollte ja alles glatt laufen.

[aiole]

Ja. Allerdings erwarte ich nun auch nicht, dass ich meine Win95-Daten 1:1 nach Win11 hole. Je länger der Abstand, desto größer das Risiko, dass etwas klemmt. Wenn es passiert, ist es eine Aufwandsabschätzung.

Es gibt sicher openWB-Leute, die deinem Problem auf den Grund gehen können. Allein deine Konfig ist ja eine aus Millionen Möglichkeiten, da jede Komponente eine Variable darstellt.

Wenn dir die Daten heilig sind, ist es letztlich "nur" eine Frage des Einsatzes bzw. Preises. Die Daten kannst du auch selbst aus dem Backup extrahieren. Die liegen in irgendwelchen Ordnern, die man in einem separaten Linux mounten kann (! nur für Leute, die damit umgehen können https://www.diskinternals.com/linux-reader/).

[HandyCap87]

Ja. Allerdings erwarte ich nun auch nicht, dass ich meine Win95-Daten 1:1 nach Win11 hole. Je länger der Abstand, desto größer das Risiko, dass etwas klemmt. Wenn es passiert, ist es eine Aufwandsabschätzung.

Es gibt sicher openWB-Leute, die deinem Problem auf den Grund gehen können. Allein deine Konfig ist ja eine aus Millionen Möglichkeiten, da jede Komponente eine Variable darstellt.

Wenn dir die Daten heilig sind, ist es letztlich "nur" eine Frage des Einsatzes bzw. Preises. Die Daten kannst du auch selbst aus dem Backup extrahieren. Die liegen in irgendwelchen Ordnern, die man in einem separaten Linux mounten kann (! nur für Leute, die damit umgehen können https://www.diskinternals.com/linux-reader/).

Das stimmt nicht ganz. Windows ist ein Betriebssystem. OpenWB ist eine Softwarelösung. Es gibt mehr als nur ein Betriebssystem. Und der Kern von OpenWB ist Energie. Wenn ich meine Energiedaten jetzt nicht rüber bekomme, ist das nicht gerade gute Arbeit. Ich erwarte nicht, dass exotischeSchnitte123 in der neuen Welt funktioniert, aber wenn ich alle meine Partitionen nach dem Windowsupgrade verliere und bei 0 anfangen muss, dann überlege ich mir, ob ich das richtige Produkt habe.

PS: ich bin selbst ITler. Habe Datenmigrationen mit Chef (für Oracle DB, Servicebus, Java EE) geschrieben. Ich bin mir über die Komplexität darüber bewusst. Aber die Energiedaten zu verlieren ist im Kontext mit OpenWB schon ziemlich schwach.

Kurzum, ich gehe auf 1.9 zurück (und dann sehe ich auch wieder meine Wärmepumpe über Shelly im LiveMonitor).

[ChristophR]

Warst Du überhaupt auf der letzten Version 1.9.304?
Das hast Du nicht direkt geschrieben, ist aber für die Übernahme wichtig.

Wenn Du ITler bist, sollte schon der Wechsel des Betriebssystems in 2.x z.B. aus Sicherheitsgründen ein zusätzlicher Ansporn für den Wechsel sein...

[HandyCap87]

Warst Du überhaupt auf der letzten Version 1.9.304?

Ja, ich hatte mich vorbereitet und diese Bedingung war mir bewusst. Ich hab aber auch bemerkt, dass 2 nicht alle Features von 1 bietet (oder setzt diese zumindest anders um).

Wenn Du ITler bist, sollte schon der Wechsel des Betriebssystems in 2.x z.B. aus Sicherheitsgründen ein zusätzlicher Ansporn für den Wechsel sein...

OpenWB sitzt bei mir hinter der Firewall und in einem eigenen Subnet. Im Notfall hätte ich den Display ausgeschalten. Die fehlenden Daten, der chaotische MQTT Baum und die Verbannung von Smart Home Geräten aus dem LiveMonitor sind für mich wichtigere Argumente.

[derNeueDet]

Wird das OS denn im der V2.x jetzt auch mit aktualisiert?

VG
Det