configDB - Aufbau der Datenbanktabellen

[wowogiengen]

Hallo,
um zukünftig bei Problemen auch ohne lauffähige FHEM-Installation diese wieder hinzubekommen,
würde ich gerne wissen, wie die einzelnen Tabellen aufgebaut sind, und wie sie miteinander in Verbindung stehen.

Z.B. würde ich gerne mit Hilfe eines SQL-Tools dann Attribute oder devices anlegen, ändern oder löschen wollen.
Mir ist klar, dass damit dann noch viel mehr kaputt gehen kann, aber wenn FHEM nicht läuft,
kann ich auch auf kein Attrib eines devices zugreifen, um dieses zu disablen...

Viele Grüße
Wolfgang

[betateilchen]

Z.B. würde ich gerne mit Hilfe eines SQL-Tools dann Attribute oder devices anlegen, ändern oder löschen wollen.

Wer sowas tun möchte, soll bitte bei fhem.cfg bleiben.

Es gibt grundsätzlich keine Notwendigkeit, als Anwender in der Datenbank manuell rumzupfuschen und ich werde das auch nicht unterstützen.

Die configDB bringt von Haus aus schon eine Reihe von recovery-Funktionalitäten mit, die dafür gedacht sind, bei Problemen zu unterstützen und die Funktionsbereitschaft von FHEM wieder herzustellen. Das hat bisher auch in fast allen Fällen funktioniert. Wenn etwas damit nicht lösbar war, wurde dafür eine Möglichkeit geschaffen, künftig auch diesen "Spezial-Fehlerfall" abzudecken.

[wowogiengen]

Hmmm,
genau das sagt mein Kollege auch immer "Es gibt grundsätzlich keine Notwendigkeit, als Anwender in der Datenbank manuell rumzupfuschen"... aber leider sind die Tools, die mir zur Verfügung stehen eben nicht ausreichend

Für die configDB wäre es meiner Ansicht nach toll, wenn man bestimmte Versionen der Konfiguration exportieren könnte, um diese für später wieder zu haben. Dazu gehört dann natürlich auch ein Reimport...

Bei meinem Problem gestern habe ich so oft auf Config-Speichern gedrückt, dass sehr viele Zwischenversionen in der DB waren, und ich (falls ich ein Reorg gemacht hätte) irgendwann mal die vermutlich noch funktionierende alte Version hätte raus geworfen.

Kann ich denn den Unterschied zwischen zwei alten DB-Versionen sehen? Am besten noch Device-bezogen?

Viele Grüße

Wolfgang

[Kulli]

Hmmm,
genau das sagt mein Kollege auch immer "Es gibt grundsätzlich keine Notwendigkeit, als Anwender in der Datenbank manuell rumzupfuschen"... aber leider sind die Tools, die mir zur Verfügung stehen eben nicht ausreichend

Für die configDB wäre es meiner Ansicht nach toll, wenn man bestimmte Versionen der Konfiguration exportieren könnte, um diese für später wieder zu haben. Dazu gehört dann natürlich auch ein Reimport...

Bei meinem Problem gestern habe ich so oft auf Config-Speichern gedrückt, dass sehr viele Zwischenversionen in der DB waren, und ich (falls ich ein Reorg gemacht hätte) irgendwann mal die vermutlich noch funktionierende alte Version hätte raus geworfen.

Kann ich denn den Unterschied zwischen zwei alten DB-Versionen sehen? Am besten noch Device-bezogen?

Viele Grüße

Wolfgang

Moin Wolfgang.
Ich nutze das alte config.cfg in Verbindung mit Backup und Git!
Das funktioniert perfekt!
Simples Textfile, kann man mit jedem Editor einsehen.
Das fhem backup ist sehr zuverlässig.
Und per Git push kannst du deine versionen ins git einchecken.
Für Bastelversuche kannst du auch branches erstellen. Wenn es gut war checkst du die in main, ein, wenn nicht lässt du es

config.db hatte ich mal versucht, aber wenn man viel rumdoktoren will, ist plaintext meiner meinung nach besser.

[betateilchen]

config.db hatte ich mal versucht, aber wenn man viel rumdoktoren will, ist plaintext meiner meinung nach besser.

Wenn man viel rumdoktern will, macht man das am besten und sichersten im FHEM Frontend und dafür ist es völlig egal, wohin die Konfiguration am Ende abgespeichert wird.

Die Grundsatzdiskussion über besser oder schlechter müssen wir aber jetzt nicht zum 728. Mal hier im Forum führen.

[wowogiengen]

config.db hatte ich mal versucht, aber wenn man viel rumdoktoren will, ist plaintext meiner meinung nach besser.

Wenn man viel rumdoktern will, macht man das am besten und sichersten im FHEM Frontend und dafür ist es völlig egal, wohin die Konfiguration am Ende abgespeichert wird.

Die Grundsatzdiskussion über besser oder schlechter müssen wir aber jetzt nicht zum 728. Mal hier im Forum führen.

Ich glaube, dass beides seine Vor- und Nachteile hat, aber mir ist es schon passiert, dass ich etwas über das Frontend geändert habe, und dann fhem neu gestartet habe, um die Änderungen wirksam werden zu lassen - dazu muss das aber dann in die DB gespeichert werden. Und dann lief fhem nicht mehr hoch, also habe ich keine einfache! Möglichkeit mehr, die Änderung wieder rückgängig zu machen - man kann ja nicht einfach die DB modifizieren (weil deren Aufbau closed source ist), und somit ärgert man sich da dann mit rum.

Bei einer Config über Dateien mache ich mir davon ein Backup, und spiele die paar Dateien wieder ein, wenn fhem nicht läuft, und das wars dann...

Ich habs inzwischen aufgegeben, aus FHEM mehr herausholen zu wollen, als das was ich jetzt mit Müh und Not hinbekommen habe.
Mir graust vor der Umstellung auf Homematic-IP, da Homematic nun EOL ist, und man nichts mehr neu beziehen kann...

Viele Grüße
Wolfgang

[betateilchen]

In Deinem Beitrag steckt eine ganze Menge unsinniger Behauptungen.

aber mir ist es schon passiert, dass ich etwas über das Frontend geändert habe, und dann fhem neu gestartet habe, um die Änderungen wirksam werden zu lassen - dazu muss das aber dann in die DB gespeichert werden. Und dann lief fhem nicht mehr hoch, also habe ich keine einfache! Möglichkeit mehr, die Änderung wieder rückgängig zu machen

Doch, hast Du. configDB bietet diverse Recovery-Mechanismen. Übrigens war genau dieses Szenario (Änderungen, die im Nachgang dazu führen, dass FHEM nicht mehr startet) vor vielen Jahren der Anlass, configDB überhaupt zu bauen, damit man mehrere Versionen der Konfiguration zur Verfügung hat und im Fehlerfall ohne großen Aufwand wieder auf die vorherige Version zurückkehren kann.

Deshalb ...

- man kann ja nicht einfach die DB modifizieren

... muss man in einem solchen Fall auch gar nichts in der DB modifizieren, configDB bietet diese Option out-of-the-box.

- man kann ja nicht einfach die DB modifizieren (weil deren Aufbau closed source ist)

In FHEM ist nix closed source. Schon alleine wegen der Lizenz, unter der FHEM steht, nicht.


Übrigens - offtopic:

Mir graust vor der Umstellung auf Homematic-IP, da Homematic nun EOL ist, und man nichts mehr neu beziehen kann...

Diese Umstellung habe ich bei mir gerade gemacht (genauer: ich betreibe mein FHEM aktuell im Mischbetrieb mit beiden Systemen) und da steckt keinerlei Raketentechnik drin, die man nicht bewältigen könnte.

Und viele "alten" Homematic Komponenten gibt es nach wie vor als Neugeräte im Abverkauf, auch wenn dafür teilweise horrende Preise aufgerufen werden, was für mich letztendlich der Anstoß war, auf die günstigeren HMIP Produkte umzusteigen.

[wowogiengen]

Hallo betateilchen,

In Deinem Beitrag steckt eine ganze Menge unsinniger Behauptungen.

manches mag für dich unsinnig sein, aber für mich war es zu dem Zeitpunkt als ich das Problem hatte, leider die Realität...

Doch, hast Du. configDB bietet diverse Recovery-Mechanismen. Übrigens war genau dieses Szenario (Änderungen, die im Nachgang dazu führen, dass FHEM nicht mehr startet) vor vielen Jahren der Anlass, configDB überhaupt zu bauen, damit man mehrere Versionen der Konfiguration zur Verfügung hat und im Fehlerfall ohne großen Aufwand wieder auf die vorherige Version zurückkehren kann.

Deshalb ...

Für mich hat es sich zu dem Zeitpunkt auch nicht einfach aus der Doku oder dem Wiki erschlossen, was ich in so einem Fall tun muss - vielleicht war es zu versteckt, oder zu verklausuliert, aber ich habs auf jeden Fall nicht in der Zeit gefunden und anwenden können, die mir lieb gewesen wäre.

In FHEM ist nix closed source. Schon alleine wegen der Lizenz, unter der FHEM steht, nicht.

Ich hab nach der Funktionsweise und dem Aufbau der Tabellen in der configDB gefragt, und als Antwort von dir dann damals bekommen:

Wer sowas tun möchte, soll bitte bei fhem.cfg bleiben.

Es gibt grundsätzlich keine Notwendigkeit, als Anwender in der Datenbank manuell rumzupfuschen und ich werde das auch nicht unterstützen.

Ist das dann nicht closed source?

Mir ist klar, dass ich damit dann die DB auch komplett zerstören kann, aber in dem Moment war mir die "Rettung" meiner Konfiguration dann wichtiger.

Aber ich sehe schon, die Diskussion hier führt zu nichts.

Viele Grüße
und ein schönes Wochenende...

Wolfgang

PS.: Homematic-IP... wie fange ich die Umstellung an? Gibt hierfür ja bestimmt auch einen Wiki-Eintrag?

[betateilchen]

Für mich hat es sich zu dem Zeitpunkt auch nicht einfach aus der Doku oder dem Wiki erschlossen, was ich in so einem Fall tun muss - vielleicht war es zu versteckt, oder zu verklausuliert, aber ich habs auf jeden Fall nicht in der Zeit gefunden und anwenden können, die mir lieb gewesen wäre.

Es steht im dritten und vierten Satz der commandref.

Du darfst diesen Dateianhang nicht ansehen.

Wer sowas tun möchte, soll bitte bei fhem.cfg bleiben.

Es gibt grundsätzlich keine Notwendigkeit, als Anwender in der Datenbank manuell rumzupfuschen und ich werde das auch nicht unterstützen.

Ist das dann nicht closed source?

Nein, ist es nicht.

Die Tatsache, dass ich die Internas und meine Gedankengänge bei der Entwicklung nicht erklären möchte, hat nichts mit "open source" oder "closed source" zu tun.

"closed source" würde bedeuten, dass es irgendwelche Geheimnisse gäbe, z.B. precompiled libraries. Das ist hier aber nicht der Fall. Die Datenbankstrukturen liegen offen, und wie die Tabellen verknüpft werden, steht in den Moduldateien von FHEM.

PS.: Homematic-IP... wie fange ich die Umstellung an? Gibt hierfür ja bestimmt auch einen Wiki-Eintrag?

Weiß ich nicht, nach einem Wiki-Eintrag hatte ich nicht gesucht, ich habe es mit eigenem Nachdenken versucht - und auf Anhieb geschafft. Viele WiKi Einträge schaffen mehr Frust als dass sie nützen, deshalb mag ich sie nicht und deshalb gibt es von mir z.B. auch keine Wiki-Einträge zur configDB.

Außerdem ist das hier das falsche Unterforum und der falsche Thread, um über die Homematic-Umstellung zu diskutieren.