Hallo zusammen, ich möchte noch mal auf o.g. Youtube Video von Simon zurück kommen. Ich habe die Schritte mehrfach wie beschrieben durchgeführt und komme immer wieder an der gleichen Stelle zu dem gleichen Fehler. Da ich damit nicht alleine zu sein scheine, mache ich es noch einmal zum Thema.
Ich hatte tatsächlich ein purge auf 365 Tage eingestellt, das hatte eine Datenbank von 27Gb zur folge. Jetzte habe ich auf 90 Tage reduziert und die Datenbank ist nur noch 11Gb groß. Das Backup ist nach wie vor 7Gb groß.
Auch, wegen der aktuellen Probleme mit der MariaDB ab Core 2024.8.* habe ich mich entschlossen, meine DB wieder zurück auf die interne SQLliteDB zu migrieren.
Eine gute Anleitung bietet das Video von @simon42
Leider habe ich dabei ein Problem, welches aktuell verhindert, die virtuelle Python-Umgebung zu installieren.
Wenn ich über das Advanced SSH Add-On oder auch über die Terminal-Instanz meines MacBook auf HA zugreife, bekomme ich dieses Bild:
Update:
Nicht wirklich!
Solange ich über das Add-On zugreifen funktioniert es, sobald ich aber von extern (Terminal des MAC-Book) zugreife habe ich wieder die “#”.
Und der Zugriff über das Add-On funktioniert ja nicht mehr, wenn ich
ha core stop
eingegeben habe.
Werde es morgen mal von meinem WIN-PC aus probieren.
konntest Du das Problem lösen? Ich habe die gleiche Meldung und überlege, ob ich das RAM der virtuellen HA Umgebung erhöhen, das habe ich in einem anderen Forum gelesen.
VG Guido
habe eben das Problem gelöst, mit genügend RAM/Speicher geht es. Meine virtuelle Umgebung auf meinem Synology NAS habe ich jetzt temporär von 6 auf 16 GB RAM erhöht, 8 waren nicht ausreichend. Ist knapp 2 Stunden gelaufen, meine DB File ist aber acuh fast 6 GB groß.
VG Guido
Der “gesicherte Modus” ist ausgeschaltet, aber sobald ich mich über
ssh User@HA-IP
und anschließend
Passwort
verbinde habe ich wieder das “#” in der Eingabezeile.
Neustart von HA und dem SSH-Add-On habe ich gemacht.
Und es ist egal ob ich mich über das HA-Terminal oder das MAC-Terminal
oder den WIN-PC (putty) anmelde, immer das gleiche.
Ich werde wohl zur Umstellung einfach das MariaDB-Add-On löschen und dann mit einer jungfräulichen SQLlite neu anfangen müssen.
Update:
So, die Migration von MariaDB => SQLlite ist erfolgreich durchgeführt!
Ich habe es einfach mal mit dem MAC-Terminal und dem “#”-Zeichen anstatt des “∼”-Zeichen wie im Video versucht und es hat alles geklappt.
Warum ich gestern kurzfristig das “∼” mal hatte weiss ich nicht.
Ich habe auch irgendwo gelesen, dass Ganze ohne die Option --use-buffered-cursors laufen zu lassen. Da bin ich aber nicht der DB Experte, ob das zu einem veränderten Resultat führt.
VG Guido
Ich habe eine externe MariaDB auf einer Synology und dies funktionierte einwandfrei bis nun auf die Probleme der DB.Migration infolge der Core 2024.8.x. Ich musste nie etwas von MariaDB installieren.
Der Eintrag unter recorder war: mysql://user:password@192.168.xxx.x:3307/homeassistant?charset=utf8mb4
Nun will ich den weg zurück zu SQLite, den verbindungsstring mit: mysql2sqlite -f /config/home-assistant_v2.db -d 192.168.xxx.x:3307/homeassistant -u user -p -V --use-buffered-cursors
Ergab nach eingabe des Passwortes die Meldung:
mysql2sqlite version 2.3.0 Copyright (c) 2019-2024 Klemen Tusar
2024-08-27 12:57:27 ERROR 2003: Can't connect to MySQL server on 'localhost:3306' (111 Connection refused)
2003: Can't connect to MySQL server on 'localhost:3306' (111 Connection refused)
Wo kann ich nun die Adresse und den Port ändern?
Gruss Geni
Moin zusammen, ich habe es eben noch einmal auf einem Windows System getestet. Auch dort bekomme ich das “Killed” Ergebnis nach Transferring table state_attributes. Wenn ich mir im File Editor die angelegte db anschaue, zeigt er ‘utf-8’ codec can’t decode byte 0x8b in position 99: invalid start byte.
Wäre toll wenn jemand einen Tip hätte. Ich werde aber trotzdem mal den RAM meines NUC aufrüsten.
Die Konvertierung auf dem HA Server hat bei mir auch nicht funktioniert. Das mysql2sqlite Tool konnte irgendwie die Datenbank nicht finden. Eine weitere Recherche im Netz hat mir auf dem HA Forum die Lösung gezeigt. Die Idee dabei ist, dass die Konvertierung nicht auf dem HA-Server läuft sondern lokal auf deinem Laptop oder PC. Das geht auch viel schneller. Im Prinzip sollte es ein Linux Rechner sein, aber ich hab einfach unter Windows 11 ein WSL Fenster geöffnet.
Die Konvertierung lief bei mir so:
1. In der HA Oberfläche diese Schritte ausführen:
wie immer ein HA Gesamt-Backup machen
#db_url=... in configuration.yaml auskonfigurieren
2. SSH Verbindung auf HA-Server ausführen und diese Schritte ausführen:
ha core stop → die MariaDB Datenbank wird nicht weiter beschrieben
3. WSL Fenster öffnen und diese Schritte ausführen, die konvertierte Datenbank home-assistant_v2.db liegt dann auf dem lokalen PC:
ha core start → eine initiale home-assistant_v2.db anlegen
ha core stop → Schreiben in initial home-assistant_v2.db verhindern
nun home-assistant_v2.db vom lokalen PC via samba share nach \\homeassistant.fritz.box\config\home-assistant_v2.db kopieren
ha core start → HA wieder starten
Diese Schritte haben bei mir funktioniert, d.h. alle Daten wurden konvertiert und HA läuft normal hoch und die Messwert/Events-History ist so wie vor der Umwandlung.
Moin, danke für die Info. Ich habe mittlerweile den RAM vom NUC von 4GB auf 16GB erweitert. Werde die Tage mal versuchen, ob das geholfen hat.
Sonst teste ich auch mal die „lokale“ Variante.
Hallo, ich stehe auch davor, gerne MariaDB von der Synology NAS zurück zu HA zu SQLite zu migrieren.
Soweit scheint alles zu klappen, aber beim ausführen des Befehls aus Simons VIdeo scheint er Probleme zu haben, sich in Mariadb einzuloggen.
ich habe eingegeben:
die DB liegt auf dem NAS (da muss doch dann sicher die IP als host eingetragen werden?)
dann fragt er auch nach dem passwort, aber dann kommt immer die Meldung:
mysql2sqlite version 2.3.0 Copyright (c) 2019-2024 Klemen Tusar
unable to open database file
ich hab mal rumgespielt, selbst egal, bei welchem database Name, den es auch gar nicht gibt, fragt er das PW ab, und meldet dann den Fehler.
Also findet er irgendwie die Datenbank nicht? Was mache ich hier falsch?
Muss ich MariaDB auf dem NAS stoppen, oder muss es laufen?
Hoffe, jemand kann mir den entscheidenden Tipp geben.
da kommt leider der gleiche Fehler, aber danke für den Tipp, so spare ich mir wenigstens das PW eingeben.
Ich hatte zwischenzeitlich schonmal mit einem anderen linuxrechner probiert, da gab es auch zuerst verschiedene Fehle in der Prozedur, aber irgendwann hat der befehl dann geklappt, und der hat die DB gefunden und angefangen zu kopieren. Dann ist leider irgendwas ma Rechner passiert, als ich nicht da war. Und ab jetzt kriege ich es nicht reproduziert, also sowohl von linux aus, als auch von windows aus kommt nun immer diese Fehlermeldung.
Moin, ich habe jetzt auch noch mal einen Versuch gestartet. RAM auf 16GB erhöht. Jetzt bekomme ich auf Mac und auf Windows immer
unable connect to database
Auch mit o.g. Befehl. Datenbank liegt direkt mit auf dem NUC
Meine DB ist 17GB groß. Ganz schön gewachsen 
