Moin Moin,
ich habe letztes Wochenende auf die ConfigDB migriert - und frage mich, ob es eine Lösung gibt, auch die Thermostat-Temperaturlisten in der configDB zu speichern?
Ich meine diese hier: https://wiki.fhem.de/wiki/HomeMatic_HMInfo_TempList/Weekplan - z.B. Wandthermostat oder Stellantrieb.
Danke, -MN
Im Moment nicht, weil das vermutlich von HMinfo nicht unterstützt wird. Die Frage gehört eher in den Homemtic Bereich, weil martin da vermutlich etwas tun müsste.
Danke,
dann versuche ich mal, den Thread zu verschieben. Hatte für configDB keine eigenes Forum gefunden...
Ciao, -MN
Zitat von: Morgennebel am 14 September 2017, 11:50:50
Hatte für configDB keine eigenes Forum gefunden...
Dann hattest Du aber nicht in die MAINTAINER.txt geschaut :)
Zitat von: betateilchen am 15 September 2017, 09:48:04
Dann hattest Du aber nicht in die MAINTAINER.txt geschaut :)
Nein. Ich versuche mich ja, mich mehr und mehr bei FHEM von der Kommandozeile zu entfernen und alte Gewohnheiten abzulegen...
Wir driften aber ab.
Ciao, -MN
Bevor ihr hier weiter die Pfanne für popcorn heizt:
Zitat von: betateilchen am 14 September 2017, 11:27:36
Die Frage gehört eher in den Homemtic Bereich, weil martin da vermutlich etwas tun müsste.
aus der commandref:
Zitat
Interaction with other modules
Currently the fhem modules
- 02_RSS.pm
- 55_InfoPanel.pm
- 91_eventTypes
- 93_DbLog.pm
- 95_holiday.pm
- 98_SVG.pm
will use configDB to read their configuration data from database
instead of formerly used configuration files inside the filesystem.
Ergo war - jedenfalls nach meinem Verständnis - die Frage eigentlich seit langem beantwortet, wohin verschieben (CUL_HM ist nicht gelistet, das Modul dürfte also anzupassen sein)...
Es ging darum, herauszufinden, welcher Forumbereich für Fragen zu configDB zuständig ist. Und das steht definitiv in der MAINTAINER.txt. Da hat überhaupt nix mit Konsolenbefehle oder ähnlichem zu tun.
Zitat von: Beta-User am 15 September 2017, 11:06:21
wohin verschieben (CUL_HM ist nicht gelistet, das Modul dürfte also anzupassen sein)...
Falsch. Es geht primär nicht um CUL_HM, sondern um HMInfo. Und DAS wiederum steht schon in meiner ersten Antwort hier im Thread.
Grundsätzlich ist es der configDB völlig egal, welches Modul seine Daten in die Datenbank ablegt. Damit das so einfach zu handhaben ist und der jeweilige Modulautor für das Schreiben und Lesen von "seinen" Dateien nicht unterscheiden muss, ob configDB genutzt wird oder nicht, wurden vor langer Zeit die Funktionen FileRead() und FileWrite() geschaffen, die genau für solche Zwecke verwendet werden sollten.
Bisher benutzt aber HMInfo leider immer noch die direkten File I/O Funktionen von perl zum Schreiben und Lesen. Deshalb werden die Listen nicht in der Konfigurationsdatenbank abgelegt und können deshalb auch nicht automatisch bei einer Migration berücksichtigt werden.
Martin als zuständiger Modulautor müsste also seine Dateioperationen auf FileRead() bzw. FileWrite() umstellen, dann würde das Ganze out-of-the-box auch mit configDB funktionieren und an der Datenbank selbst sind keine Änderungen notwendig.
Nach einem ersten Blick eben in die Moduldatei ist der Arbeitsaufwand dafür recht überschaubar.
*schubs*
Ich sage es nur ungern, aber glaubst nicht auch es wäre einfacher schnell einen Patch zu schreiben ;D
Nein.
Ok
*schubs*
*schubs*
Und ich werde das Thema solange hochschubsen, bis es erledigt wurde...
Ok, gesehen.
Nun, ist etwas mehr, aber (natürlich) machbar.
Je nachdem, wie Du das Ganze am Ende umsetzt (ein paar Hinweise stehen schon hier im Thread) sollten wir uns dann abstimmen, wie bei einer Migration bereits vorhandene zu HMInfo gehörende Dateien gefunden werden können. Wenn ich das weiß, kann ich diese Dateien in die automatische Migration mit einbeziehen.
Die Dateien, die bereits jetzt von configDB Anwendern benutzt werden und die im Dateisystem liegen, müssen von den Anwendern dann einmal manuell in die Datenbank importiert werden. Dazu könnte man eine entsprechende Ankündigung vor der Umstellung machen.
Es ist umgesetzt.
Die Dateien sollten doch zu finden sein.
Man kann sie hinlegen, wo man will. Und benennen, wie man will. Dafür sind die Attribute in hminfo da. Man legt das directory und den filenamen fest. Alles im commandref beschrieben.
Ich (zumindest) verwalte alle(ALLE) config Files in EINEM dir. Ich halte es für (mehr als) sinnvoll, tool, config und log zu trennen.
Ich sichere nur das setup dir. Das tool kann ich laden. Die logs kann ich auch sichern.
Die configDb sollte( fuer mich) auch dort hin.
Da fhem das nicht unterstützt arbeite ich ausserhalb von hm mit linux links
Dankeschön.
Ciao, -MN
Funktioniert aber irgendwie nicht richtig.
Ein
set HMinfo tempList save
liefert als Rückmeldung
file: ././tempList.cfg error:Error on reading ././tempList.cfg from database!
Offenbar wird bei einem save zuerst versucht, eine ggf. nicht vorhandene Datei zu lesen - warum auch immer.
Und die Pfadangabe ././ müsste mir auch mal bitte jemand erklären.
Nachtrag: Die Meldung mit dem Lesefehler der Datei ././tempList.cfg erscheint sogar dann, wenn die Datei mit dieser Pfadangabe in der Datenbank vorhanden ist.
Ok. Die Datei in der Datenbank darf nicht leer sein. Eine Leerzeile reicht schon, um das save auszuführen.
Aber wieso wird die Datei überhaupt erst gelesen, wenn ein "save" ausgeführt werden soll?
Nachtrag 2:
"get HMinfo configCheck" meckert trotzdem noch rum:
templist mismatch
sz_TC_Climate: sz_TC_Climate not found in file ././tempList.cfg
wz_TC_Climate: wz_TC_Climate not found in file ././tempList.cfg
ein "configdb fileshow ././tempList.cfg" liefert völlig korrekt:
entities:sz_TC_Climate
R_P1_0_tempListSat>24:00 17.0
R_P1_1_tempListSun>24:00 17.0
R_P1_2_tempListMon>24:00 17.0
R_P1_3_tempListTue>24:00 17.0
R_P1_4_tempListWed>24:00 17.0
R_P1_5_tempListThu>24:00 17.0
R_P1_6_tempListFri>24:00 17.0
R_P2_0_tempListSat>24:00 17.0
R_P2_1_tempListSun>24:00 17.0
R_P2_2_tempListMon>24:00 17.0
R_P2_3_tempListTue>24:00 17.0
R_P2_4_tempListWed>24:00 17.0
R_P2_5_tempListThu>24:00 17.0
R_P2_6_tempListFri>24:00 17.0
R_P3_0_tempListSat>24:00 17.0
R_P3_1_tempListSun>24:00 17.0
R_P3_2_tempListMon>24:00 17.0
R_P3_3_tempListTue>24:00 17.0
R_P3_4_tempListWed>24:00 17.0
R_P3_5_tempListThu>24:00 17.0
R_P3_6_tempListFri>24:00 17.0
entities:wz_TC_Climate
R_P1_0_tempListSat> 24:00 17.0
R_P1_1_tempListSun> 24:00 17.0
R_P1_2_tempListMon> 24:00 17.0
R_P1_3_tempListTue> 24:00 17.0
R_P1_4_tempListWed> 24:00 17.0
R_P1_5_tempListThu> 24:00 17.0
R_P1_6_tempListFri> 24:00 17.0
R_P2_0_tempListSat> 24:00 17.0
R_P2_1_tempListSun> 24:00 17.0
R_P2_2_tempListMon> 24:00 17.0
R_P2_3_tempListTue> 24:00 17.0
R_P2_4_tempListWed> 24:00 17.0
R_P2_5_tempListThu> 24:00 17.0
R_P2_6_tempListFri> 24:00 17.0
R_P3_0_tempListSat> 24:00 17.0
R_P3_1_tempListSun> 24:00 17.0
R_P3_2_tempListMon> 24:00 17.0
R_P3_3_tempListTue> 24:00 17.0
R_P3_4_tempListWed> 24:00 17.0
R_P3_5_tempListThu> 24:00 17.0
R_P3_6_tempListFri> 24:00 17.0
././ Ist kein Problem. Ergibt sich und ist schlicht etwas einfacher.
Klar sollte die datei existieren. Ok, ohne habe ich nicht probiert.
Das mit dem nicht finden verstehe ich nicht.
Was passiert beim save? Wird ins file geschrieben? Was?
was in die Datei geschrieben wurde, siehst Du in meinem vorherigen Beitrag.
Aber vielleicht solltest Du Dich erstmal um die immer noch kaputte 10_CUL_HM.pm kümmern, die quer durchs Forum immer mehr Installationen zerschießt.
da habe ich mich schon gekümmert. sollte wieder gehen, seit heute Morgen (SVN).
Das mit
set hm tempListG save
kann ich nicht glauben. da sollten die Devices aller deiner RTs geschrieben werden. Sind das nur die zwei? halt, das sind 2 TCs.
Ich denke gerade daran, die alte Version von CUL_HM neu einzulagern. dann sollte es wieder passen und wir können noch einmal testen.
Hast du noch Probleme mit der SVN Version?
OK, lass uns versuchen, die Probleme bei den tempList zu lösen. Vielleicht sollten wir Stück für Stück vorgehen.
1. Problem: das erstmalige Speichern mit "set hm tempList save" funktioniert nicht(dieses Problem ist unabhängig davon, ob man mit fhem.cfg oder configDB arbeitet!)
Zitat von: martinp876 am 11 Februar 2018, 21:30:44
Klar sollte die datei existieren. Ok, ohne habe ich nicht probiert.
Aktuell wird bei einem "set hm tempList save" ab Zeile 759 versucht, eine tempList zu lesen.
Wenn dies nicht funktioniert, wird das Speichern komplett abgebrochen.
my ($err,@RLines) = FileRead($fName);
return "file: $fName error:$err" if ($err);
Wie soll nach Deiner Vorstellung eine tempList erstmalig in eine FHEM Installation kommen, wenn sie nicht per "save" angelegt werden kann, weil es sie noch nicht gibt?
Für mich wäre es richtiger, bei einem Fehler nach FileRead() die Verarbeitung bis zum FileWrite() zu überspringen und dann die neue Datei zu schreiben. Der Abbruch der Verarbeitung an dieser Stelle ist m.E. kein korrektes Verhalten und vermutlich auch gar nicht so gewünscht.
Zitat von: martinp876 am 12 Februar 2018, 21:08:59
Wie das mit configdb und readfile zusammenspielt idt mir noch nicht klar.
Das ist nicht schlimm :)
Die Funktionen FileRead() und FileWrite() wurden seinerzeit in die fhem.pl eingebaut, damit sich Modulentwickler überhaupt keine Gedanken machen zu brauchen, ob ein Anwender mit fhem.cfg oder configDB arbeitet.
Hallo Martin,
Dir ist hoffentlich klar, dass Deine heutige Änderung an HMInfo eine ziemliche Katastrophe ist? Warum fängst Du jetzt wieder damit an, direkt ins Dateisystem zu schreiben, anstatt FileWrite() zu verwenden? Das ist doch völliger Unfug.
Es macht überhaupt keinen Sinn, die Existenz einer Datei im Filesystem zu prüfen und darauf zu reagieren. Bei einem FHEM Anwender, der mit configDB arbeitet, wird es dieses Datei im Dateisystem nie geben. Und in dem Fall nützt es auch überhaupt nichts, dieses Datei in das Dateisystem zu schreiben.
Hier mal mein Vorschlag, das Thema möglichst einfach zu lösen.
Index: 98_HMinfo.pm
===================================================================
--- 98_HMinfo.pm (revision 16204)
+++ 98_HMinfo.pm (working copy)
@@ -700,10 +700,10 @@
my %dl =("Sat"=>0,"Sun"=>1,"Mon"=>2,"Tue"=>3,"Wed"=>4,"Thu"=>5,"Fri"=>6);
my $ret;
- if (not -f $fName) { #create file if necessary
- open(aSave, ">$fName") || return("Can't open $fName: $!");
- print aSave "#init\n";
- }
+# if (not -f $fName) { #create file if necessary
+# open(aSave, ">$fName") || return("Can't open $fName: $!");
+# print aSave "#init\n";
+# }
if ($action eq "save"){
# foreach my $eN(HMinfo_getEntities("d")){#search and select channel
@@ -758,7 +758,8 @@
my @oldList;
my ($err,@RLines) = FileRead($fName);
- return "file: $fName error:$err" if ($err);
+# return "file: $fName error:$err" if ($err);
+ push (@RLines, "#init") if ($err);
my $skip = 0;
foreach(@RLines){
chomp;
Hm. Ich denke ich habe das close vergessen.
Klar wird erst gelesen.
Das file schreiben legt nur ein leeres file an. Dann existiert es. Das muss configdb nicht wissen, denke ich.
Was ist die kathastrophe?
Zitat von: martinp876 am 17 Februar 2018, 23:27:34
Was ist die kathastrophe?
Es funktioniert immer noch nicht mit configDB.
Nochmal...
Zitat von: betateilchen am 17 Februar 2018, 19:51:08
Es macht überhaupt keinen Sinn, die Existenz einer Datei im Filesystem zu prüfen und darauf zu reagieren. Bei einem FHEM Anwender, der mit configDB arbeitet, wird es dieses Datei im Dateisystem nie geben. Und in dem Fall nützt es auch überhaupt nichts, dieses Datei in das Dateisystem zu schreiben.
Du schreibst eine Datei direkt
ins Filesystem und versuchst dann, mit FileRead() diese Datei zu lesen. Bei Benutzern, die mit configDB arbeiten, versucht FileRead() automatisch, diese Datei aus der Datenbank zu lesen, wo sie immer noch nicht existiert. Und dann wird das "tempList save" nach wie vor abgebrochen.
Alles was Du tun muss, um das Problem zu lösen, ist folgendes:
1. Baue die Prüfung auf die Dateiexistenz und das Anlegen im Dateisystem wieder aus, das ist völlig überflüssig und hilft überhaupt nicht.
2. Sorge dafür, dass nach dem FileRead() im Fehlerfall nicht abgebrochen wird, sondern schreibe einen dummy-Eintrag in das dann leere array @RLines (damit es in Folge nicht zu perl warnings wegen uninitialize values kommt)
- return "file: $fName error:$err" if ($err);
+ push (@RLines, "#init") if ($err);
Fertig. Schon funktionieren die tempList sowohl mit fhem.cfg als auch mit configDB.
danke - aber ist schon drin
Hallo,
sollte es nicht prinzipiell auch funktionieren, wenn man bereits existierenden Temperaturlisten mittels
configdb fileimport mytemplist.cfg
importiert (der Pfad muss evtl. angepasst werden) und die dann verwendet wird.
Edit: Das funktioniert!
Außerdem stellt sich mir gerade noch die Frage, wie man die Files in der Datenbank anschließend am geschicktesten editiert bzw. welche Änderungen notwendig sind, damit das mittels
Edit files
möglich ist. Ich meine die für den Fall, dass die Files nicht in /opt/fhem/FHEM liegen sondern, wie im Wiki-Eintrag zu den Temperaturlisten beschrieben, in /opt/fhem/setup/. Exportieren und Importieren in eine Datei ist dann doch recht umständlich.
Danke für euren Support
Grüße
Zilon
Als hätte ich es geahnt. Nach dem ganzen hick hack hier hätte ich es lieber sein lassen sollen
files referenced but not found:
././heating/tempList/UrlaubIn.cfg - Error on reading ././heating/tempList/UrlaubIn.cfg from database!
---------components-----------
template : device : state
././heating/tempList/UrlaubIn.cfg:Badezimmer : HeizungsThermostatBadezimmer_Clima : file: ././heating/tempList/UrlaubIn.cfg error:Error on reading ././heating/tempList/UrlaubIn.cfg from database!
././heating/tempList/UrlaubIn.cfg:Isabel : HeizungsThermostatKinZimIsabel_Clima : file: ././heating/tempList/UrlaubIn.cfg error:Error on reading ././heating/tempList/UrlaubIn.cfg from database!
././heating/tempList/UrlaubIn.cfg:Steven : HeizungsThermostatKinZimSteven_Clima : file: ././heating/tempList/UrlaubIn.cfg error:Error on reading ././heating/tempList/UrlaubIn.cfg from database!
././heating/tempList/UrlaubIn.cfg:Wohnzimmer : HeizungsThermostatWohnzimmer_1_Clima : file: ././heating/tempList/UrlaubIn.cfg error:Error on reading ././heating/tempList/UrlaubIn.cfg from database!
././heating/tempList/UrlaubIn.cfg:Wohnzimmer : HeizungsThermostatWohnzimmer_2_Clima : file: ././heating/tempList/UrlaubIn.cfg error:Error on reading ././heating/tempList/UrlaubIn.cfg from database!
././heating/tempList/UrlaubIn.cfg:Wohnzimmer : WandThermostatWohnzimmer_Climate : file: ././heating/tempList/UrlaubIn.cfg error:Error on reading ././heating/tempList/UrlaubIn.cfg from database!
Files found in database:
------------------------------------------------------------
./heating/tempList/UrlaubIn.cfg
./heating/tempList/UrlaubOut.cfg
./heating/tempList/Winter.cfg
./heating/tempList/WinterFROST.cfg
Martin wäre das noch eine Baustelle für Dich? Hatte mich jetzt darauf verlassen das es klappt.
Oder liegt der Fehler bei mir?
Grüße
Guten Morgen Martin,
Ich muß mich bei Dir entschuldigen. Der Fehler lag in meiner Konfiguration. Genauer gesagt das Attribut configDir war falsch gesetzt
./configDir heating/tempList
Es muss natürlich
configDir heating/tempList
sein.
SORRY
Grüße
Leon
Kein Thema
Guten Abend,
gab es wieder Änderungen am hminfo? Ich bekomme neuerdings beim Ausführen vom set hm tempListG verify Fehlermeldungen der Art
fail : ././FHEM/my_weekplan.cfg:Heizung_Bad_Clima for Heizung_Bad_Clima: file: ././FHEM/my_weekplan.cfg error:Error on reading ././FHEM/my_weekplan.cfg from database!
Mein Attribut für das configDir lautet FHEM, das Attribut configTempFile entsprechend my_weekplan.cfg
Das Schreiben der Konfiguration mittels set hm tempListG save klappt problemlos, set hm tempListG status auch. Beim set hm tempListG restore bekomme ich jedoch trotz Änderungen an der Temperaturliste stets Meldungen, die mit "passed" beginnen. Die modifizierten Daten werden somit nicht geschrieben. Auch ein vorher ausgeführtes getConfig bei den Thermostaten schafft keine Abhilfe.
Grüße
Zilon
habe es gerade getestet. Funktioniert bei mir.
templist geändert - es folgt ein "restore" der betroffenen Devices. Verify funktioniert.
Ich nutze eine config-dir
Version ist aktuell
10_CUL_HM.pm 16525 2018-03-30 22:04:30Z martinp876
98_HMinfo.pm 16521 2018-03-30 15:00:33Z martinp876
98_HMtemplate.pm 16079 2018-02-04 12:27:05Z martinp876
ich habe mein configTempFile geändert. dann wird das File nicht gefunden (logisch). dann ein "save" - das File wird angelegt und gefunden. Das Verify funktioniert nicht, da die Templates nicht angelegt sind - auch logisch.
Mir unklar, was ich noch probieren kann. Nutzt du die config-DB? Das habe ich nun nicht getestet.
Was sagt ein "status" bei dir?
Ja, ich nutze die configDB.
Funktioniert status?
Hast du attr configdir gesetzt?
sollte gelöst sein - scheinbar nur mit configDB sichtbar.
Ja, jetzt funktioniert es wieder. Danke!
configDir hatte ich gesetzt und Status hat funktioniert.