configDB - config-Files - erweitern für weitere Module?

[Beta-User]

Hallo betateilchen,

bin grade (mit) dabei zu überlegen, wie man "vitoconnect" von altem Ballast befreien könnte. Da sind aktuell noch zwei "mapping"-Varianten hart vercoded (>1000 Zeilen insges.), die Readings (und set-Befehle) "schöner" (also Anwender-lesbarer) machen.

Die funktionieren zum Teil nicht mal (mehr?) wirklich, werden aber von einem Gutteil der bisherigen User verwendet, schlicht weil es früher nicht wirklich eine Alternative gegeben hatte.

Statt jetzt (gefühlt) unendlich lange Attribute zu pflegen, würde ich gerne vorschlagen, diese in Mapping-files auszulagern, dann kann die weiter verwenden, wer will, und auf die Art eventuell auch "schöne" Readingnamen (bzw. sets) generieren, ich denke da insbesondere an Client-Devices für einzelne Funktionsbereiche.
Mein aktueller Code, der das allerdings alles noch nicht nutzt, wäre hier zu finden: https://forum.fhem.de/index.php?msg=1338905

Sowas könnte ggf. auch hilfreich sein für weitere Module, die "unschöne" Reading-Namenskonventionen haben (Home Connect?).

Wenn ich das richtig zusammengepuzzelt habe, "müßte" man nur Zeile 667 in configDB.pm dahingehend ändern, dass für die automatische Import-Funktion die defspec geändert wird:

Code Auswählen Erweitern

@def = _cfgDB_findDef('i:CONFIGFILE=.+','CONFIGFILE');
Habe jetzt nicht geprüft, ob irgendwelche Module außer den dort bereits genannten TYPE dieses Internal verwenden, gehe aber nicht davon aus. CONFIGFILE paßt aus der Liste der bisherigen Varianten am besten zu ./conf, aber es darf gerne auch was anderes sein.

Falls du das so (oder so ähnlich) einchecken wolltest, kann ich gerne noch einen commandref-Vorschlag liefern .

OT und als Merker an mich selber: Will dann auch gleich die "$data{confFile}"-Option mit nutzen, Querverweise:
https://forum.fhem.de/index.php?topic=95375.0
https://forum.fhem.de/index.php?topic=131992.0
(vitoconnect hat derzeit keine notifyFn(), und die nur wegen der global:FILESAVE einzubauen widerstrebt mir im Moment noch etwas).

[betateilchen]

So einfach ist das nicht.

Solange es noch zu viele Module gibt, die entweder eigene FileHandles öffnen um Dateien zu lesen oder den forcetype=>'FILE' für die eigenen Dateien fest verdrahten, macht eine solche universelle Lösung in configDB keinen Sinn. Außerdem hat eine ganze Reihe von Entwicklern bereits bekundet, dass sie daran nichts ändern wollen. (Wahrscheinlich aus Unkenntnis, wie einfach sie es hätten, wenn sie denn die bereitgestellten generischen Funktionen verwendeten.)

Falls es ein bestimmtes Modul gibt, das mit CONFIGFILE arbeitet und korrekt mit der Datei umgeht (und nicht die transparente Lösung mit FileRead() unterwandert), werde ich das Modul gerne in configDB für die Migration aufnehmen. Einfach eine Nachricht an mich schicken.

[Beta-User]

Danke für die schnelle und klare Antwort. Dann werde ich das erst mal so vorbereiten, ist sowieso schon genug Arbeit, das umzubasteln...