(Gelöst) Umzug fhem.cfg zu configDB gerät mehrfach vorhanden

Begonnen von SamNitro, 03 Mai 2018, 15:49:31

Vorheriges Thema - Nächstes Thema

SamNitro

Hallo, nach meinem Umzug auf configDB dachte ich zuerst das mal alles reibungslos funktioniert hat, doch da habe ich mich getäuscht.

meine fhemconfig hat jetzt über 17.000 einträge und alle geräte ca 18 mal.

wie bekomme ich das bereinigt?

(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

Beta-User

configDB ermöglicht eine Versionierung, die aktuelle config ist immer die Version 0. Du hast also schlicht auch "einige" ältere Versionen gespeichert.
Siehe z.B. die folgenden Auszüge der comnmandref:
Zitatconfigdb diff <device> <version>

Zitatconfigdb reorg [keep]
Deletes all stored versions with version number higher than [keep].
Default value for optional parameter keep = 3.
This function can be used to create a nightly running job for database reorganisation when called from an at-Definition.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

SamNitro

Achso, könntest du mir evtl noch sagen wo man das einstellt wie viele Versionen der speichern soll?
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

SamNitro

bei jeder Änderung die ich mache erstellt der mir von jedem gerät eine neue version  :-\
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

Beta-User

Zitat von: SamNitro am 03 Mai 2018, 16:13:40
bei jeder Änderung die ich mache erstellt der mir von jedem gerät eine neue version  :-\
Works as designed, das ermöglicht eine Versionierung ;) .

So wie ich die commandref verstehte, gibt es da keinen Parameter, den man für die Anzahl der vorgehaltenen Versionen einstellen könnte.

Der bereits vorgeschlagene Weg ist der, ggf. per "at" ein "configdb reorg [keep]" anzustoßen. Wenn du also 10 Versionen haben willst und das jede Nacht laufen soll:
define configDB_verkleinern at *02:45:00 configdb reorg 10
Oder du machst das halt immer mal wieder bei Gelegenheit...

Btw.: Wie oft speicherst du denn die config? Das macht doch nur bei wirklichen Änderungen Sinn, und da kann man dann ja am Ende bzw. nach einiger Zeit dann wirklich das "reorg" absetzen!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

SamNitro

#5
ok dachte es wäre ein Fehler in den Einstellungen.
Dann ist alles in Ordnung und ich werde es über ein at lösen danke für deine Erklärung :)

Edit:
ZitatBtw.: Wie oft speicherst du denn die config?
Nach jeder Änderung z.b. raum oder so...


Aber warum macht er dann direkt von jedem gerät eine neue Version?
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

Beta-User

Keine Ahnung, warum immer die ganze config versioniert wird; aber andererseits: wie sollte sonst sichergestellt sein, dass alles zusammenpaßt? So ist klar: Alle devices mit Version 453 müßten zusammen funktionieren...

Es gibt übrigens doch ein "attr ... maxversions" für die Obergrenze der vorzuhaltenden Versionen; hatte ich beim Überfliegen leider übersehen. Aber damit wäre das at überflüssig.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

SamNitro

(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

betateilchen

Zitat von: Beta-User am 03 Mai 2018, 16:17:58
So wie ich die commandref verstehte, gibt es da keinen Parameter, den man für die Anzahl der vorgehaltenen Versionen einstellen könnte.

Doch gibt es. "configdb attr maxversions 5" Default für reorg ist übrigens 3. Wenn man also "configdb reorg" ohne angegebenen Parameter durchführt, bleiben automatisch nur die letzten 3 Versionen in der Datenbank.

Zitat von: Beta-User am 03 Mai 2018, 16:17:58
Btw.: Wie oft speicherst du denn die config?

Vermutlich mal wieder jemand, der ein notify auf jede Änderung triggert und dabei ein "save" ausführt.

Zitat von: Beta-User am 03 Mai 2018, 16:28:14
Keine Ahnung, warum immer die ganze config versioniert wird;

Weil es das Konzept von FHEM ist. Auch bei fhem.cfg wird immer die komplette Konfiguration gespeichert und nicht nur die Änderungen.

Zitat von: Beta-User am 03 Mai 2018, 16:28:14
Es gibt übrigens doch ein "attr ... maxversions" für die Obergrenze der vorzuhaltenden Versionen

Falsche Syntax :)

Ausserdem empfehle ich für die Bereinigung der Datenbank grundsätzlich das Vorgehen mit dem at. Ist ein maxversions gesetzt, wird nämlich bei jedem Abspeichern ein reorg durchgeführt, was schonmal eine gewisse Zeit dauern kann.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

SamNitro

Zitat von: betateilchen am 04 Mai 2018, 21:50:23

Vermutlich mal wieder jemand, der ein notify auf jede Änderung triggert und dabei ein "save" ausführt.

So schlimm ist es bei mir dann doch nicht, aber wenn ich Änderungen getroffen habe dann drücke ich zwischendurch schon ein paar mal auf speichern  ;D
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)