Hallo Rudi,
seit ca. 13.05. wird nach einem configdb backup das Webfrontend von FHEM nicht mehr dargestellt. In Firefox kommt die Meldung:
Fehler: Verbindung unterbrochen
Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.
Die Website könnte vorübergehend nicht erreichbar sein, versuchen Sie es bitte später nochmals.
Wenn Sie auch keine andere Website aufrufen können, überprüfen Sie bitte die Netzwerk-/Internetverbindung.
Wenn Ihr Computer oder Netzwerk von einer Firewall oder einem Proxy geschützt wird, stellen Sie bitte sicher, dass Firefox auf das Internet zugreifen darf.
Bei Safari bleibt der Bildschirm weiß. Betateilchen meinte, ich sollte dich mal darauf ansprechen, da er hier auf ein Fronten-Problem tippt. Siehe hierzu auch http://forum.fhem.de/index.php/topic,23628.0.html (http://forum.fhem.de/index.php/topic,23628.0.html)
Danke
Klaus
Hier noch mein Senf zur Wurst:
Vermutung 1: Das Problem hängt mit Befehlen zusammen, deren Ausführung lange dauert.
Vermutung 2: Irgendwas führt dann dazu, dass der im Frontend eingegebene Befehl noch einmal zur Ausführung gebracht wird und deshalb das backup zweimal hintereinander läuft.
Die doppelte Ausführung des Backups tritt nur bei Aufruf im Frontend auf. Startet man das backup über telnet, wird es genau einmal ausgeführt.
@betateilchen: waere es nicht sinnvoll, das Backup im Hintergrund zu machen, genau wie update das macht?
@Klaus: wie lange dauert denn dein backup?
@Rudi: hättest Du das backup nicht aus mir bis heute unerfindlichen und völlig unverständlichen Gründen nicht in 98_backup.pm für alle configDB-Benutzer generell verboten, hätten wir überhaupt kein Problem und es würde einfach funktionieren wie immer. Mein Backup macht inhaltlich exakt das gleiche wie Deines. Ich habe den Code für das Lesen der Verzeichnisse und das tar 1:1 kopiert.
Es würde viel mehr Sinn machen, eine vorhandene und funktionierende Lösung verwenden zu dürfen, anstatt alles zweimal programmieren zu müssen.
Das Backup bei Klaus dauert ca 75 Sekunden.
Zitat von: rudolfkoenig am 16 Mai 2014, 09:07:14
@Klaus: wie lange dauert denn dein backup?
Hallo Rudi,
letzter Backup laut Logfile 1:26 Minuten:
2014.05.16 07:35:29 2: Backup with command: tar -cf - ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg ./fhem.cfg_ori ./fhem.pl ./fhem.png ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140516_073529.tar.gz
2014.05.16 07:36:55 1: backup done: FHEM-20140516_073529.tar.gz (34397169 Bytes)
Gruß Klaus
@betateilchen: ich glaube das Wort "unerfindlich" ist nicht richtig, "unverstaendlich" waere besser.
Ich habe es damit begruendet, dass ich kein backup Befehl zulassen will, der die Konfiguration nicht sichert.
Und das Backup ist "meins" in dem Sinn, dass ich es komissarisch betreue.
Tritt das Problem bei dir auch auf?
@Klaus: ist das Problem Firefox spezifisch?
Zitat von: rudolfkoenig am 16 Mai 2014, 09:27:02
@Klaus: ist das Problem Firefox spezifisch?
nein, dass das Frontend nicht geladen wird, tritt auch bei Safari auf MAC und und bei Chrome auf Windows auch. Dort wurde eben auch der Backup gerade wieder 2 mal nacheinander ausgführt. Muss mal suchen, wie man dort den Cache löscht.
Nachtrag, Chrome ist dabei etwas mitteilsamer:
Die Webseite kann nicht geladen werden, da der Server keine Daten gesendet hat.
Laden Sie die Webseite erneut.
Klicken Sie auf die Schaltfläche zum erneuten Laden, um die für das Laden der Seite erforderlichen Daten erneut zu senden.
Fehlercode: ERR_EMPTY_RESPONSENachtrag 2: trotz löschen des Cache wurde im Chromebrowser das Backup wieder 2 x ausgeführt:
2014.05.16 09:36:57 2: Backup with command: tar -cf - ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg ./fhem.cfg_ori ./fhem.pl ./fhem.png ./FrameRSS.jpg ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140516_093657.tar.gz
2014.05.16 09:37:59 1: backup done: FHEM-20140516_093657.tar.gz (34417829 Bytes)
2014.05.16 09:38:04 2: Backup with command: tar -cf - ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg ./fhem.cfg_ori ./fhem.pl ./fhem.png ./FrameRSS.jpg ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140516_093804.tar.gz
2014.05.16 09:39:17 1: backup done: FHEM-20140516_093804.tar.gz (34417829 Bytes)
2Gruß
Klaus
Zitat von: rudolfkoenig am 16 Mai 2014, 09:27:02
Ich habe es damit begruendet, dass ich kein backup Befehl zulassen will, der die Konfiguration nicht sichert.
Und das Backup ist "meins" in dem Sinn, dass ich es komissarisch betreue.
Rudi, es geht nicht darum, ob es Deins ist oder nicht. Ich hatte Dich als Maintainer des Moduls damals lediglich darum gebeten, eine Fehlermeldung zu fixen, die bei configDB keinen Sinn macht. Mehr nicht. Und noch: configDB kann mit einer leeren Konfiguration starten, deshalb ist Dein Argument "kein backup der die Konfiguration nicht sichert" für mich keine Begründung.
Es wäre schön, wenn Du das nochmal überdenken würdest und die damals vorgeschlagene Änderung nur in Bezug auf die Fehlermeldung umsetzen könntest. Dann hätten wir bei update und backup genau die gleiche Transparenz für die configDB-Anwender, die wir auch sonst an allen Stellen geschaffen haben und alles wäre gut. Und auch das Problem von Klaus wäre damit sofort gelöst.
Zitat von: rudolfkoenig am 16 Mai 2014, 09:27:02
@betateilchen:
Tritt das Problem bei dir auch auf?
Bei mir gibt es keine Backups, die so lange dauern, deshalb konnte ich das Problem bei mir noch nicht reproduzieren.
ZitatEs wäre schön, wenn Du das nochmal überdenken würdest
Ich habe nachgedacht, und bin der Ansicht, dass wenn aus der Backup-Datei die alte Konfiguration nicht hergestellt werden kann, dann ist das kein backup.
@Klaus: kannst Du bitte das verbose der FHEMWEB Instanz auf 4 setzen (attr WEB verbose 4), und das Befehl erneut ausfuehren? Danach interessiert mich, was im FHEM Log steht.
Zitat von: rudolfkoenig am 16 Mai 2014, 22:11:31
Ich habe nachgedacht, und bin der Ansicht, dass wenn aus der Backup-Datei die alte Konfiguration nicht hergestellt werden kann, dann ist das kein backup.
Ich halte diese Ansicht nach wie vor für nicht richtig. configDB hat im Gegensatz zu fhem.cfg den entscheidenden Unterschied, dass fhem selbst ohne eine gesicherte Konfiguration wieder lauffähig aus der Sicherung wiederhergestellt werden kann. Eine fhem-Installation besteht nicht nur aus dem Inhalt der fhem.cfg sonden beinhaltet ggf auch viele vom Benutzer selbst angelegte Dateien, die für fhem benötigt werden (floorplan, eigene css usw). Gerade diese Dateien begründen die viel größeren Probleme, wenn sie für eine Wiederherstellung nicht zur Verfügung stehen. Und genau diese Dateien werden mit dem regulären Backup mitgesichert. Ich verstehe nach wie vor nicht, warum Du den Anwendern der configDB diese problemlos funktionierende Möglichkeit der Datensicherung so vehement verweigerst. Der Inhalt der configDB selbst ist nur ein kleiner Puzzlestein im gesamten Backup-Mosaik. Aber wegen eines fehlenden Puzzlesteins ein Mosaik zu verwerfen, ist unsinnig. Es bleibt ein Mosaik, das eventuell einen kleinen Schönheitsfehler hat. Wegen einem Sprung in einer Fliese in Deinem Badezimmer würdest Du doch wahrscheinlich auch nicht das gesamte Badezimmer neu kacheln oder das Badezimmer nicht mehr benutzen.
Bitte mal für mich als Erklärung wie das gemeint ist das aus einem Backup der configdb die alte Konfiguration nicht wieder hergestellt werden kann? Sorry ich versteh das so nicht - Rudi, kannst du mir das etwas Abflüssen (rein zum Verständnis)
Ich dachte ein Backup der dB hat alle configs inne. Daher dachte ich bisher das zu dem bisherigen Backup "nur" das Backup der dB angehängt werden muss.
Ich bin der Ansicht, dass wenn man "backup" ausfuehrt, und das Ergebnis sichert, man alles zum Restaurieren haben sollte, ohne ene zusaetzliche Sicherung der Datenbank durchzufuehren. betateilchen ist der Ansicht, dass bei einer FHEM Installation mit Datenbank die Sicherung aus zwei Teilen besteht: 1. FHEM-Backup, 2. DB-Backup.
Zitat von: Rudibetateilchen ist der Ansicht, dass bei einer FHEM Installation mit Datenbank die Sicherung aus zwei Teilen besteht: 1. FHEM-Backup, 2. DB-Backup.
Was Rudi hier behauptet, ist
definitiv NICHT meine Ansicht. Und genau diesen Trugschluss versuche ich ihm seit Wochen - leider erfolglos - darzulegen.
Hallo Ihr 2,
wäre schön, wenn Ihr 2 Euch mal auf einen Kompromiss einigen könntet. Ich denke, Ihr habt beide teilweise Recht. Wie wäre es denn, wenn man sich auf Rudi's backup einigt, jedoch dieses Kommando prüft, ob configdb genutzt wird und gibt dann eben eine GROßE und DEUTLICHE Warnung aus, dass man die Daten der SQL Datenbank mit entsprechenden Hilfmitteln (je nach eingesetzter DB) sichern muss.
Und ganz nebenbei fände ich es noch toll, wenn nach dem Backup der FHEM Screen wieder erscheint ;)
Viele Grüße
Klaus
Wäre ich ein Moderator, würde ich euch beiden ja den dringenden Tipp geben, mal ein Bierchen miteinander zu trinken.
So lese ich halt mit, wie zwei ausgesorochen fähige Köpfe ihre Energie und Zeit damit verschwenden, einen reichlich unsinnigen Diskurs zu führen.
Rudi fühlt sich angegriffen, Betateilchen unverstanden. Merkt ihr eigentlich, dass euch das zum Einen öfter passiert und zum Anderen nicht weiter bringt?
Sorry für das OT.
Das Thema Backup halte ich auch in fhem für wichtig. Meine mir unterstellten Backupadmins würden hier eher eine Lösung Suchen bei der das Backup möglich umfangreich und vom Inhalt verlässlich ist. Lieber zuviel als zuwenig im Backup haben als später fest zu stellen das was wichtiges fehlt.
Wohl daher versteh ich die gesamte Diskussion nicht. In meinem Verantwortungsbereich gibt es zum Glück einen klar definierten zweck eines Backups.
Für mich ist wichtig das ich fhem neu aufsetzen kann und mit dem Backup wieder in den Zustand versetzen kann in dem es zu dem Zeitpunkt war. Das ist auch ohne configdb nicht gegeben, was ich vor Wochen merken musste - das waren bei mir z.b. eigene .js und .svg Dateien.
Das ist keine Kritik an Rudi, es ist im Moment halt so.
Das ist bisher auch ein Grund die configdb nicht produktiv zu nutzen. Und ich möchte einen Befehl absetzen um ein Backup zu bekommen und nicht noch mich separat um die DB zu kümmern - auch wenn das anders gesehen wird. Aber das Leben ist kein Wunschkonzert und nicht alle sehen das wie ich, und das ist auch gut so.
@betateilchen: wenn ich das nicht verstanden habe, bitte klaer mich auf. Ich habe folgendes verstanden: bei configDB sind alle FHEM-Konfigurationen in der Datenbank, und nicht im Filesystem. Das backup Kommando fasst aber nur Dateien aus dem Filesystem an -> ergo sind in dem erstellten Backupdatei keine Konfigurationsdaten. Ein configDB Benutzer muss also unbedingt auch die Datenbank sichern, damit beim Restaurieren alles vorhanden ist. Irgendwie habe ich die Befuerchtung, dass du davon ausgehst, dass die Datenbank nicht restauriert werden muss, da sie auf einem anderen Rechner ist, oder es eh anderweitig gesichert wird.
@Klaus: mit deinem Vorschlag (Warnung an dem Benutzer) kann ich leben, aber wir warten erstmal ab, was der Stand ist, ich will ja keine Geruechte ins Welt setzen, solche gibt es im FHEM Umfeld schon genug.
@svenson08: ich habe das Modul auch nur geerbt. Wenn sich jemand dafuer interessiert, kann ich es gerne abgeben.
Ich selbst verwende es nicht, da ich den Rechner komplett sichere, und das nicht aus FHEM-heraus.
Zitat von: svenson08 am 17 Mai 2014, 17:27:37
Das ist bisher auch ein Grund die configdb nicht produktiv zu nutzen. Und ich möchte einen Befehl absetzen um ein Backup zu bekommen und nicht noch mich separat um die DB zu kümmern
Exakt das wäre längst gegeben, wenn Rudi einfach nur die vor vielen Wochen vorgeschlagene Änderung in das backup-Modul eingebaut hätte, anstatt sich darüber gedanken zu machen, ob ER das backup für sinnvoll hält oder nicht.
Der ganz normale Backup-Prozess hätte dann dafür gesorgt, dass die gesamte Konfiguration EINSCHLIESSLICH der Datenbank mitgesichert wird, unter einer einzigen vom Benutzer zu erfüllenden Voraussetzung: Die Datenbank müsste dazu im fhem Verzeichnis liegen.
Zitat von: svenson08 am 17 Mai 2014, 09:26:00
Ich dachte ein Backup der dB hat alle configs inne. Daher dachte ich bisher das zu dem bisherigen Backup "nur" das Backup der dB angehängt werden muss.
Das war mein ursprünglicher Plan - dazu hätte es der bereits erwähnten winzigen Änderung bedürft, im Backup Modul eine Fehlermeldung abzufangen, die nur auftritt, wenn configDB benutzt wird.
Zitat von: Rince am 17 Mai 2014, 16:45:45
Wäre ich ein Moderator, würde ich euch beiden ja den dringenden Tipp geben, mal ein Bierchen miteinander zu trinken.
Ich hatte auf dem Treffen in Karlsruhe schon eine weitere Klärung der Backup-Frage vorgeschlagen, konnte damals aber leider kein echtes Interesse, eine Klärung herbeiführen zu wollen, erkennen.
Zitat von: Klaus Rubik am 17 Mai 2014, 16:37:51
Und ganz nebenbei fände ich es noch toll, wenn nach dem Backup der FHEM Screen wieder erscheint ;)
Auch das wäre nebenbei mit gelöst.
Zitat von: rudolfkoenig am 17 Mai 2014, 18:18:28
Ein configDB Benutzer muss also unbedingt auch die Datenbank sichern, damit beim Restaurieren alles vorhanden ist.
Ein configDB Benutzer muss nur dann die Datenbank eigenverantwortlich sichern, wenn sie sich nicht im fhem Verzeichnispfad befindet.
Genau so ist das aber auch mit allen anderen von fhem benutzten Dateien, die NICHT im fhem-Verzeichnis liegen.
Ich verstehe bis heute nicht, warum Du das Ganze plötzlich davon abhänging machst, ob ein Benutzer, der configDB nutzt, irgendwelche Daten ausserhalb von fhem ablegt oder ob das ein Benutzer, der fhem.cfg nutzt, tut. Für mich ist diese von Dir praktizierte Verweigerungshaltung
"configDB Nutzer dürfen das Backup-Modul nicht benutzen" nach wie vor rein willkürlich und unerfindlich.
Zitat@svenson08: ich habe das Modul auch nur geerbt. Wenn sich jemand dafuer interessiert, kann ich es gerne abgeben.
Ich selbst verwende es nicht, da ich den Rechner komplett sichere, und das nicht aus FHEM-heraus.
Das weis ich, darum will ich auch nicht das du als Vorwurf siehst. Ich sichere mit dem Backup Befehl und meinen kompletten Pi. Aber ich denk an den Nutzer der das nicht macht und der nicht weis wie es geht. Die Benutzer freundlichere Lösung sollte doch auch das Ziel sein. Und wenn es nur die Fritz box user wären an die man denkt
@betateilchen
Willst du nicht das Modul Übernehmen? Das Know how dazu hast du nach meiner Einschätzung. Ich müsste mich da zuviel einarbeiten, was mir über den Sommer nur schwer gelingen würde. Auch ist mein perl noch nicht so gefestigt....
Zitat von: svenson08 am 17 Mai 2014, 18:40:05
@betateilchen
Willst du nicht das Modul Übernehmen?
An dem Modul sind keinerlei Änderungen nötig, ausser der ursprünglich gewollten Änderung, die das Abfangen einer Fehlermeldung betrifft. Dazu habe ich seinerzeit bereits einen funktionierenden Patch vorgeschlagen.
http://forum.fhem.de/index.php/topic,20117.msg147122.html#msg147122
Anstatt den Patch einzubauen, hat Rudi seinerzeit sowohl das update- als auch das backup-Modul angefaßt und geändert, nur um configDB Nutzern die Backupmöglichkeit grundsätzlich und vollständig verweigern zu können.
Selbst wenn ich das backup-Modul übernehmen würde (wozu es keine Notwendigkeit gibt) könnte ich die gewünschte Änderung damit nicht mehr vornehmen, weil configDB Nutzer aktuell an zwei Stellen grundlos benachteiligt werden und die Sperre auch in update.pm wieder zurückgebaut werden muss.
Die einfachste und für alle am transparentesten Lösung wäre einfach die, dass Rudi den schon im März von mir vorgeschlagenen Patch in die 98_backup.pm übernimmt und auch die benachteiligende Änderung in der 98_update.pm wieder ausbaut.
ZitatAnstatt den Patch einzubauen, hat Rudi seinerzeit sowohl das update- als auch das backup-Modul angefaßt und geändert, nur um configDB Nutzern die Backupmöglichkeit grundsätzlich und vollständig verweigern zu können.
Ich würde an Rudis Stelle hier auch auf stur schalten. Nicht weil es technisch notwendig wäre, sondern weil ich mich massiv angegriffen fühlen würde.
Ist ne blöde Situation.
Letztlich solltest du, Betateilchen, Rudi eine Brücke bauen, so dass Rudi den Patch einbauen kann, ohne dabei sein Gesicht zu verlieren.
Vielleicht würde ein "entschuldige Rudi, ich hab mich damals schlecht ausgedrückt" ausreichen? Aber das ist Rudis Sache.
Weder braucht betateilchen sich zu entschuldigen, noch habe ich ein Problem damit "mein Gesicht zu verlieren", bzw. meine Meinung zu aendern.
Wenn ich es recht verstanden habe, FHEM macht vielleicht ein Backup der Datenbankdatei, aber sicher ist das nicht: Falls der Anwender kein sqlite verwendet, oder per config die sqlite-Datei nicht in modpath liegt, dann wird die Konfiguration samt DB nicht gesichert.
Ich haette kein Problem auch bei configDB das Backup durchzufuehren, wenn der Benutzer per Warnhinweis (wie vom Klaus vorgeschlagen) gewarnt wird. Den Hinweis koennen wir unterdruecken, wenn configDB per Funktion verraet, dass die Datei im Backup ist.
Hallo,
also den Vorschlag von Rudi finde ich doch als gangbaren Weg, ich denke nun ist es nach der ausführlichen Diskussion Zeit sich die Hand zu reichen und den Vorschlag umzusetzen.
Ohne jetzt zusätzliches Öl ins Feuer giessen zu wollen, aber kann mir jemand erklären, welchen Nachteil configDB User bei update haben :o?
Viele Grüße und gute Nacht
Klaus
Was ist eigentlich der Vorteil der Datenbank? Ich sicher immer einfach meine komplette Pi sd Karte nach einer Woche ;)
Zitat von: rudolfkoenig am 17 Mai 2014, 22:25:05
Wenn ich es recht verstanden habe,
...
Falls der Anwender kein sqlite verwendet, oder per config die sqlite-Datei nicht in modpath liegt, dann wird die Konfiguration samt DB nicht gesichert.
Du hast immer noch nicht verstanden, dass diese von Dir hier seit Wochen vehement breitgetretene Behauptung schlichtweg FALSCH ist. Es kommt nicht darauf an, welches Datenbanksystem verwendet wird, sondern wo die Datenbank abgelegt ist. Und damit verhält sich die Datenbank exakt identisch zu allen anderen von fhem verwendeten Dateien, die sich nicht im direkten fhem-Pfad, der von 98_backup gesichert wird, befinden.
Ich verstehe nach wie vor nicht, warum Du diese völlig sinnlose Differenzung ausschliesslich bei der configDB einführen musstest. Wenn ich beispielsweise RSS Layouts ausserhalb von fhem speichere, werden sie von 98_backup.pm auch nicht mit gesichert.
Die Sache mit dem Hinweis können wir gerne einbauen. Aber ich würde dabei im Falle der Nutzung von configDB den Anwender generell immer darauf hinweisen, dass er für die Datensicherung seiner Konfigurationsdatenbank selbst verantwortlich ist. 98_backup.pm kann nicht ohne weiteres feststellen, ob die Sicherung eine Datenbank enthält oder nicht, das das gesamte fhem zur Laufzeit überhaupt nicht weiss (und auch gar nicht wissen muss), wo die Datenbank tatsächlich liegt.
Zitat von: Blackcat am 18 Mai 2014, 10:32:55
Was ist eigentlich der Vorteil der Datenbank? Ich sicher immer einfach meine komplette Pi sd Karte nach einer Woche ;)
Das ist ein völlig anderes Thema und gehört hier nicht her. Du kannst das aber bereits mehrfach erklärt hier im Forum nachlesen.
Zitat von: betateilchen am 18 Mai 2014, 10:40:46
Du hast immer noch nicht verstanden, dass diese von Dir hier seit Wochen vehement breitgetretene Behauptung schlichtweg FALSCH ist. Es kommt nicht darauf an, welches Datenbanksystem verwendet wird, sondern wo die Datenbank abgelegt ist. Und damit verhält sich die Datenbank exakt identisch zu allen anderen von fhem verwendeten Dateien, die sich nicht im direkten fhem-Pfad, der von 98_backup gesichert wird, befinden.
Hallo Betateilchen,
so ganz bin ich da nicht bei Dir, einfach nur die DB Files zu sichern mag bei SQlite ausreichen, bei "vernünftigen" Datenbank-Systemen wie z. B. Oracle musst du die Datenbank zumindest in einen konsistenten "Backup-Mode" versetzten, damit alle Daten auch aus den DB Caches in den Files liegen. Daher sollte die DB immer mit DB Spezifischen Backups und wenn es nur ein SQL Export ist gesichert werden.
Viele Grüße
Klaus
Zitat von: Klaus Rubik am 18 Mai 2014, 11:10:24
Daher sollte die DB immer mit DB Spezifischen Backups und wenn es nur ein SQL Export ist gesichert werden.
Das ist völlig richtig. Aber das ist eine Aufgabe, die ich in configDB für mehrere denkbare Datenbanksysteme weder umsetzen kann noch will. Deshalb liegt die Verantwortung der Datenbanksicherung beim Anwender. Es steht ihm völlig frei, z.B. über einen Cronjob regelmäßig einen Datenbank-Dump zu erzeugen, der im fhem-Pfad abgelegt und damit von 98_backup mitgesichert wird.
Allerdings ist das Problem im Falle von configDB nicht so dramatisch wie beispielsweise bei DbLog (wo es eine Diskussion über Backupmöglichkeiten innerhalb von fhem noch nie gab!) denn der grundlegende Unterschied ist, dass die configDB nicht permanent geöffnet ist, sondern nur geöffnet wird, wenn man wirklich etwas daraus lesen oder hinschreiben möchte, danach wird die Verbindung sofort wieder abgebaut. Insofern wird auch eine low-level Sicherung auf Datenbankebene in den allermeisten Fällen funktionieren, denn bei einer geschlossenen Datenbank gibt es keine Daten mehr im Cache, die noch nicht in die Datenbank geschrieben sind.
SQLite bietet in diesem Zusammenhang den Vorteil, dass dort quasi alle Ebenen verschwunden sind und wir uns wirklich nur auf Dateiebene bewegen. Es bedeutet aber nicht, dass SQLite die einzige Möglichkeit bietet, eine Sicherung aus fhem heraus zu ermöglichen. Deshalb fand ich auch den von Rudi schon vor längerem formulierten Vorschlag, ich solle mich bei configDB auf SQLite als einzige Möglichkeit beschränken, dann würde er die Sicherung per 98_backup wieder ermöglichen, völlig absurd.
Zitat von: RudiNoch ein Vorschlag, um zu zeigen dass ich nicht bockig bin: Du streichst den Support fuer andere Datenbanken in configDB, dann werde ich dein Patch einbauen (vorausgesetzt es ist getestet und funktioniert).
Wie gesagt, ich fände die Lösung mit dem regulärem backup-Befehl von Rudi und einer entsprechenden Warnung bei Einsatz von configDB einen gangbaren Weg und würde mich freuen, wenn die Grundsatzdiskussionen ein Ende fänden und das Thema umgesetzt wird.
In diesem Sinne, einen schönen und produktiven Sonntag 8)
ich schlage folgenden Patch vor:
Index: 98_backup.pm
===================================================================
--- 98_backup.pm (revision 5883)
+++ 98_backup.pm (working copy)
@@ -54,7 +54,7 @@
my $msg;
my $ret;
- return "Backup is not supported for configDB" if(configDBUsed());
+ Log 1, "configDB users are responsible for a working database backup!" if(configDBUsed());
# set backupdir
my $backupdir;
@@ -81,12 +81,18 @@
}
}
- # get pathnames to archiv
- push @pathname, $configfile;
- Log 4, "backup include: '$configfile'";
- $ret = parseConfig($configfile);
- push @pathname, $statefile;
- Log 4, "backup include: '$statefile'";
+ if(configDBUsed()) {
+ # add configDB configuration file
+ push @pathname, 'configDB.conf';
+ Log 4, "backup include: 'configDB.conf'";
+ } else {
+ # get pathnames to archiv
+ push @pathname, $configfile;
+ Log 4, "backup include: '$configfile'";
+ $ret = parseConfig($configfile);
+ push @pathname, $statefile;
+ Log 4, "backup include: '$statefile'";
+ }
$ret = readModpath($modpath,$backupdir);
# create archiv
Die zugehörige Änderung in 98_update.pm müsste Rudi bitte selbst zurückbauen.
Habs eingecheckt, und auch update.pm angepasst.
Danke! :)
Zitat von: rudolfkoenig am 19 Mai 2014, 11:45:28
Habs eingecheckt, und auch update.pm angepasst.
Danke.
Könntest Du bitte in 98_update.pm noch diese Änderung (Umbenennung der Funktion) umsetzen:
http://forum.fhem.de/index.php/topic,22927.msg162825.html#msg162825
Dann kann ich die alten Funktionen aus der configDB komplett entsorgen. Alle anderen Module, die auf die alten Funktionen zugriffen, sind bereits angepaßt.
Habs geaendert und eingecheckt.
Hallo,
am Grundproblem, dass die FHEM Seite nach dem Backup wieder angezeigt wird, hat sich leider nichts geändert.
Folgende Effekte treten auf:
Kommando: configdb backup
Logfile:
2014.05.20 11:47:09 2: Backup with command: tar -cf - ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg ./fhem.cfg_ori ./fhem.pl ./fhem.png ./FrameRSS.jpg ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140520_114709.tar.gz
2014.05.20 11:48:13 1: backup done: FHEM-20140520_114709.tar.gz (34489317 Bytes)
Komando: backup
Logfile:
2014.05.20 11:49:20 1: NOTE: make sure you have a database backup!
2014.05.20 11:49:20 2: Backup with command: tar -cf - configDB.conf ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg ./fhem.cfg_ori ./fhem.pl ./fhem.png ./FrameRSS.jpg ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140520_114920.tar.gz
2014.05.20 11:50:25 1: backup done: FHEM-20140520_114920.tar.gz (34488860 Bytes)
2014.05.20 11:50:39 1: NOTE: make sure you have a database backup!
2014.05.20 11:50:39 2: Backup with command: tar -cf - configDB.conf ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg ./fhem.cfg_ori ./fhem.pl ./fhem.png ./FrameRSS.jpg ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140520_115039.tar.gz
2014.05.20 11:51:57 1: backup done: FHEM-20140520_115039.tar.gz (34482586 Bytes)
In beiden Fällen wird die FHEM Seite nicht wieder aufgebaut. Wenn man nur backup aufruft, dann werden 2 Backups durchgeführt.
Gruß
Klaus
Vermutlich ist meine bitte untergegangen:
Zitat@Klaus: kannst Du bitte das verbose der FHEMWEB Instanz auf 4 setzen (attr WEB verbose 4), und das Befehl erneut ausfuehren? Danach interessiert mich, was im FHEM Log steht.
Zitat von: rudolfkoenig am 20 Mai 2014, 12:05:39
Vermutlich ist meine bitte untergegangen:
Hallo Rudi,
ja, hatte ich übersehen, sorry.
Hier der Log-Auszug:
2014.05.20 12:06:40 4: HTTP FHEMWEB:192.168.0.100:58690 GET /fhem?detail=WEB
2014.05.20 12:06:41 4: /fhem?detail=WEB / RL:10604 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.05.20 12:06:41 4: HTTP FHEMWEB:192.168.0.100:58690 GET /fhem/pgm2/style.css
2014.05.20 12:06:41 4: HTTP FHEMWEB:192.168.0.100:58693 GET /fhem/pgm2/svg.js
2014.05.20 12:06:41 4: HTTP FHEMWEB:192.168.0.100:58695 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.05.20 12:06:41 4: HTTP FHEMWEB:192.168.0.100:58690 GET /fhem/pgm2/fhemweb_slider.js
2014.05.20 12:06:41 4: HTTP FHEMWEB:192.168.0.100:58696 GET /fhem/pgm2/fhemweb.js
2014.05.20 12:06:41 4: HTTP FHEMWEB:192.168.0.100:58697 GET /fhem/pgm2/fhemweb_multiple.js
2014.05.20 12:06:41 4: HTTP FHEMWEB:192.168.0.100:58694 GET /fhem/pgm2/fhemweb_noArg.js
2014.05.20 12:06:42 4: HTTP FHEMWEB:192.168.0.100:58695 GET /fhem/pgm2/fhemweb_textField.js
2014.05.20 12:06:42 4: HTTP FHEMWEB:192.168.0.100:58690 GET /fhem/pgm2/fhemweb_time.js
2014.05.20 12:06:42 4: HTTP FHEMWEB:192.168.0.100:58693 GET /fhem/pgm2/fhemweb_svg.js
2014.05.20 12:06:42 4: HTTP FHEMWEB:192.168.0.100:58690 GET /fhem/icons/favicon
2014.05.20 12:06:42 4: HTTP FHEMWEB:192.168.0.100:58690 GET /fhem/pgm2/darkCommon.css
2014.05.20 12:06:42 4: HTTP FHEMWEB:192.168.0.100:58690 GET /fhem/pgm2/dashboard_darkstyle.css
2014.05.20 12:06:42 4: HTTP FHEMWEB:192.168.0.100:58695 GET /fhem/images/default/icoEverything.png
2014.05.20 12:06:42 4: HTTP FHEMWEB:192.168.0.100:58690 GET /fhem/images/default/fhemicon_dark.png
2014.05.20 12:06:42 4: HTTP FHEMWEB:192.168.0.100:58696 GET /fhem/images/default/energy.png
2014.05.20 12:06:42 4: HTTP FHEMWEB:192.168.0.100:58697 GET /fhem?cmd={AttrVal(%22WEB%22,%22room%22,%22%22)}&XHR=1
2014.05.20 12:06:42 4: /fhem?cmd={AttrVal(%22WEB%22,%22room%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2014.05.20 12:06:42 4: HTTP FHEMWEB:192.168.0.100:58693 GET /fhem/images/default/Wecker.Immer.png
2014.05.20 12:06:53 4: HTTP FHEMWEB:192.168.0.100:58690 GET /fhem&room=Unsorted&cmd=backup
2014.05.20 12:06:53 1: NOTE: make sure you have a database backup!
2014.05.20 12:06:54 2: Backup with command: tar -cf - configDB.conf ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg ./fhem.cfg_ori ./fhem.pl ./fhem.png ./FrameRSS.jpg ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140520_120654.tar.gz
2014.05.20 12:07:58 1: backup done: FHEM-20140520_120654.tar.gz (34490917 Bytes)
2014.05.20 12:07:59 4: /fhem&room=Unsorted&cmd=backup / RL:7948 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.05.20 12:07:59 4: Closing connection FHEMWEB:192.168.0.100:58696
2014.05.20 12:07:59 4: Closing connection FHEMWEB:192.168.0.100:58697
2014.05.20 12:07:59 4: Closing connection FHEMWEB:192.168.0.100:58690
2014.05.20 12:07:59 4: Closing connection FHEMWEB:192.168.0.100:58693
2014.05.20 12:07:59 4: Closing connection FHEMWEB:192.168.0.100:58694
2014.05.20 12:07:59 4: Closing connection FHEMWEB:192.168.0.100:58695
2014.05.20 12:08:00 4: Connection accepted from FHEMWEB:192.168.0.100:58922
2014.05.20 12:08:00 4: HTTP FHEMWEB:192.168.0.100:58922 GET /fhem&room=Unsorted&cmd=backup
2014.05.20 12:08:00 1: NOTE: make sure you have a database backup!
2014.05.20 12:08:00 2: Backup with command: tar -cf - configDB.conf ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg ./fhem.cfg_ori ./fhem.pl ./fhem.png ./FrameRSS.jpg ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140520_120800.tar.gz
2014.05.20 12:09:08 1: backup done: FHEM-20140520_120800.tar.gz (34490917 Bytes)
2014.05.20 12:09:10 4: /fhem&room=Unsorted&cmd=backup / RL:7947 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.05.20 12:09:14 4: Closing connection FHEMWEB:192.168.0.100:58922
Hoffe es hilft...
Viele Grüße
Klaus
Anmerkung: configdb backup gibts seit heute nicht mehr.
Zitat von: betateilchen am 20 Mai 2014, 12:24:34
Anmerkung: configdb backup gibts seit heute nicht mehr.
Funktioniert aber noch (bringt zumindest keinen Fehler) und im Commandref solltest Du es auch noch löschen ;)
Zitat von: Klaus Rubik am 20 Mai 2014, 12:27:18
Funktioniert aber noch
Ich glaube, wenn der Entwickler "heute" sagt, meint er i.d.R. "morgen", da die Neuerungen ja erst am darauffolgenden Tag per Update verteilt werden. ;)
Benni hats verstanden 8)
Zitat von: betateilchen am 20 Mai 2014, 12:51:24
Benni hats verstanden 8)
Im Grundsatz ich auch, dachte aber dass die Änderungen bereits in den von Rudi gestern eingecheckten Modulen schon drin war 8)
Diese Änderung erfolgt nicht in Rudis Modulen, sondern in meinen. Und ich verteile solche grundlegenden Änderungen nicht mehr zeitgleich, um Reihenfolgeprobleme während des fhem-updates zu vermeiden.
Hallo Rudi,
hast Du das Thema noch auf dem Schirm?
Viele Grüße
Klaus
Ja, ist aber leider hinten in der Liste, weil ich dafuer mehr Zeit an einem Stueck brauche.
fhem.pl und alle seine Module sind vermutlich unschuldig, da zwei entsprechende HTTP requests kommen:
Zitat/fhem&room=Unsorted&cmd=backup ...
Bleibt nur noch der Browser selbst oder fhemweb.js, um das auseinanderzufieseln brauche ich Zeit.
ok, danke für den Status. Ich weiß ja, wie ich wieder an die FHEM Seite kommen ;)
die Sache mit einer doppelten Ausführung scheint hier auch aufzutreten - im Ablauf eines updates
http://forum.fhem.de/index.php/topic,22091.msg171317.html#msg171317
@Klaus: ich kriege das Problem zwar reproduziert, aber nur dann, falls ich beide Attribute setze:
attr WEB refresh 60
attr WEB redirectCmds 0
Falls diese bei dir auch gesetzt sind, dann ist das Verhalten normal und beabsichtigt.
Falls nicht, dann:
- zeig uns bitte die komplette WEB Attributliste.
- verwendest du spezielle Web Module wie readingsGroup, Dashboard, WebViewControl o.ae? Wen ja, welche?
- funktioniert das Problem mit einem simplen "sleep 120" auch?
- ab welchem sleep Argument gibt es kein Problem mehr?
Hallo Rubi,
bin gerade unterwegs, geb dir die Infos spätestens heute Abend. Vorab shon mal folgende Infos:
FHEMWEB Definition:
define WEB FHEMWEB 8083 global
attr WEB stylesheetPrefix dark
attr WEB sortRooms Alarm_Melder Energie Heizung Garten System Schlafzimmer Dusche Familie Robin Buero Bad Wohnzimmer Kueche WC Keller
attr WEB roomIcons Alarm_Melder:Wecker.Immer Energie:energy Heizung:sani_heating_temp@orange System:edit_settings@lightblue Garten:scene_garden@green Bad:control_building_s_og Buero:control_building_s_og Familie:control_building_s_og Robin:control_building_s_og Kueche:control_building_s_eg WC:control_building_s_eg Wohnzimmer:control_building_s_eg Dusche:control_building_s_dg Schlafzimmer:control_building_s_dg Keller:control_building_s_kg
attr WEB menuEntries ConfigInfo,cmd=configdb+info,UpdateCheck,cmd=update+check,Backup,cmd=backup,Update,cmd=update,Restart,cmd=shutdown+restart
attr WEB defaultRoom Energie
attr WEB longpoll 0
attr WEB column Energie:SMAUtils|dummy,SVG|FBDECT Garten:FS20,at,SVG|CUL_WS,Wetterbericht,I2C_BMP180,TRX_WEATHER,THRESHOLD Alarm_Melder:TRX_SECURITY|HMS,dummy,watchdog System:SYSSTAT,SYSMON|I2C_TSL2561,speedtest,SVG Schlafzimmer:FS20,at,watchdog|CUL_FHTTK,FHT,TRX_SECURITY,notify,SVG Familie:FS20|CUL_FHTTK,FHT,SVG Buero:PRESENCE,WOL|CUL_FHTTK,FHT,SVG Wohnzimmer:FS20,PRESENCE|CUL_FHTTK,FHT,I2C_TSL2561,WOL,SVG Keller:FS20,PRESENCE,THRESHOLD|CUL_FHTTK,FHT,HMS,TRX_SECURITY,SVG Robin:PRESENCE,TRX_SECURITY|CUL_FHTTK,FHT,SVG Heizung:TRX_LIGHT,TRX_WEATHER,dummy|Aussentemperaturen,Heizungsstatus,SVG
Sleep 120 funktioniert, weiter Tests mit anderen Zeiten heute Abend.
readingsGroup setze ich ein, die anderen nicht
Viele Grüße
Klaus
Hallo Rudi,
mit sleep konnte ich das Problem nicht nachstellen, habe es in 60 Sekundenschritten bis 300 probiert.
Gruß
Klaus
Ich kriege das Problem mit deinen Attributen nicht reproduziert. Ich vermute, dass es kein generisches Problem ist, sonst haetten wir schon mehrere "bei mir auch" Beschwerden, es muss also an irgendeine Kombination von Attributen/Umstaenden liegen, die Aufgabe ist es rauszufinden, welche Kombination das ist.
Tritt das Problem bei Dir immer auf?
Zitat von: rudolfkoenig am 30 Mai 2014, 09:34:30
Tritt das Problem bei Dir immer auf?
ja, immer wenn ich einen Backup durchführe.
Hast Du dir mal das von betateilchen referenzierte Problem angeschaut, geht das in die gleiche oder eine ähnliche Richtung?
Zitat von: betateilchen am 24 Mai 2014, 21:58:36
die Sache mit einer doppelten Ausführung scheint hier auch aufzutreten - im Ablauf eines updates
http://forum.fhem.de/index.php/topic,22091.msg171317.html#msg171317
Viele Grüße
Klaus
Das referenzierte Problem hat vermutlich die gleiche Ursache wie deins, ich kann es auch nicht reproduzieren, und ich habe keine Idee, wieso der Browser auf die Idee kommt, die Abfrage erneut aubzuschicken.
Hallo Rudi,
ich habe heute vor dem Update eine Backup ausgeführt, dabei wurde der Backup nur einmal ausgeführt, FHEM wurde aber im Browser nicht mehr dargestellt. Verhalten wie gehabt.
Nach dem Update von heute und dem anschliessenden Shutdown Restart habe ich wieder einen Backup durchgeführt, diesmal wurde dieser wieder 2 mal ausgeführt und FHEM kam im Browserfenster nicht zurück.
Hier noch der gesamte Log-Auszug:
2014.05.30 10:22:12 1: NOTE: make sure you have a database backup!
2014.05.30 10:22:13 2: Backup with command: tar -cf - configDB.conf ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg_ori ./fhem.pl ./fhem.png ./FrameRSS.jpg ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140530_102213.tar.gz
2014.05.30 10:23:22 1: backup done: FHEM-20140530_102213.tar.gz (34514607 Bytes)
2014.05.30 10:23:58 3: FS20 set Poolpumpe off
2014.05.30 10:24:24 3: owo OpenWeatherMap_senden: started: SendData
2014.05.30 10:24:27 3: owo OpenWeatherMap_senden: htmlResponse: 200 OK
2014.05.30 10:24:38 3: SMAspot called
2014.05.30 10:25:08 3: update get http://fhem.de/fhemupdate4/svn/FHEM/FhemUtils/release.pm
2014.05.30 10:25:08 1: update check Releases => local: Fhem 5.5 (DEVELOPMENT) remote: Fhem 5.5 (DEVELOPMENT)
2014.05.30 10:25:08 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
2014.05.30 10:25:21 1: update saving statefile
2014.05.30 10:25:21 3: update get http://fhem.de/fhemupdate4/svn/./CHANGED
2014.05.30 10:25:21 3: update get http://fhem.de/fhemupdate4/svn/./fhem.pl.txt
2014.05.30 10:25:21 3: update get http://fhem.de/fhemupdate4/svn/FHEM/00_HMLAN.pm
2014.05.30 10:25:22 3: update get http://fhem.de/fhemupdate4/svn/FHEM/00_THZ.pm
2014.05.30 10:25:22 3: update get http://fhem.de/fhemupdate4/svn/FHEM/01_FHEMWEB.pm
2014.05.30 10:25:22 3: update get http://fhem.de/fhemupdate4/svn/FHEM/10_CUL_HM.pm
2014.05.30 10:25:23 3: update get http://fhem.de/fhemupdate4/svn/FHEM/10_ZWave.pm
2014.05.30 10:25:23 3: update get http://fhem.de/fhemupdate4/svn/FHEM/23_LUXTRONIK2.pm
2014.05.30 10:25:23 3: update get http://fhem.de/fhemupdate4/svn/FHEM/33_readingsGroup.pm
2014.05.30 10:25:23 3: update get http://fhem.de/fhemupdate4/svn/FHEM/36_JeeLink.pm
2014.05.30 10:25:23 3: update get http://fhem.de/fhemupdate4/svn/FHEM/55_GDS.pm
2014.05.30 10:25:24 3: update get http://fhem.de/fhemupdate4/svn/FHEM/70_JSONMETER.pm
2014.05.30 10:25:24 3: update get http://fhem.de/fhemupdate4/svn/FHEM/70_PHTV.pm
2014.05.30 10:25:24 3: update get http://fhem.de/fhemupdate4/svn/FHEM/71_YAMAHA_AVR.pm
2014.05.30 10:25:24 3: update get http://fhem.de/fhemupdate4/svn/FHEM/71_YAMAHA_BD.pm
2014.05.30 10:25:25 3: update get http://fhem.de/fhemupdate4/svn/FHEM/72_FB_CALLMONITOR.pm
2014.05.30 10:25:25 3: update get http://fhem.de/fhemupdate4/svn/FHEM/98_ComfoAir.pm
2014.05.30 10:25:25 3: update get http://fhem.de/fhemupdate4/svn/FHEM/98_HMinfo.pm
2014.05.30 10:25:25 3: update get http://fhem.de/fhemupdate4/svn/FHEM/98_statistics.pm
2014.05.30 10:25:25 3: update get http://fhem.de/fhemupdate4/svn/docs/commandref.html
2014.05.30 10:25:26 3: update get http://fhem.de/fhemupdate4/svn/docs/commandref_DE.html
2014.05.30 10:25:28 3: update get http://fhem.de/fhemupdate4/svn/www/gplot/SM_DB_all.gplot
2014.05.30 10:25:28 3: update get http://fhem.de/fhemupdate4/svn/www/gplot/power8top10.gplot
2014.05.30 10:25:29 3: update get http://fhem.de/fhemupdate4/svn/www/pgm2/ios6touchpadstyle.css
2014.05.30 10:25:30 1: update 24 file(s) have been updated.
2014.05.30 10:25:30 1: update A new version of fhem.pl was installed, 'shutdown restart' is required!
2014.05.30 10:25:46 0: Server shutdown
2014.05.30 10:26:10 3: WEB: port 8083 opened
2014.05.30 10:26:11 3: WEBphone: port 8084 opened
2014.05.30 10:26:11 3: WEBtablet: port 8085 opened
2014.05.30 10:26:12 3: Opening CUL_0 device /dev/ttyAMA0
2014.05.30 10:26:13 3: Setting CUL_0 baudrate to 38400
2014.05.30 10:26:13 3: CUL_0 device opened
2014.05.30 10:26:13 3: CUL_0: Possible commands: mBCFAIZOGMRTVWXefltux
2014.05.30 10:26:13 3: Opening RFXTRXUSB device /dev/ttyUSB0
2014.05.30 10:26:13 3: Setting RFXTRXUSB baudrate to 38400
2014.05.30 10:26:14 3: RFXTRXUSB device opened
2014.05.30 10:26:14 1: TRX: Init OK
2014.05.30 10:26:14 1: TRX: Init status: '433.92MHz transceiver, firmware=71, protocols enabled: LaCrosse Hideki OREGON HOMEEASY AC ARC X10 '
2014.05.30 10:26:14 3: telnetPort: port 7072 opened
2014.05.30 10:26:20 3: Opening fbaha device 192.168.0.1:2002
2014.05.30 10:26:20 3: fbaha device opened
2014.05.30 10:26:20 1: FBAHA fbaha registered with handle: 00000008
2014.05.30 10:26:29 2: CUL_IR IODev device didn't answer Ir command correctly: raw => T10693B02F0T10693B82F1T052200BA001B02
2014.05.30 10:26:29 2: Switched IR_Dev irReceive to ON_NR
2014.05.30 10:26:30 3: Connecting to database mysql:database=fhem;host=nas10;port=3306 with user fhemuser
2014.05.30 10:26:30 3: Connection to db mysql:database=fhem;host=nas10;port=3306 established for pid 12171
2014.05.30 10:26:31 3: Connection to db mysql:database=fhem;host=nas10;port=3306 established
2014.05.30 10:26:32 3: I2C_TSL2561_Define device created
2014.05.30 10:26:38 3: owo OpenWeatherMap_senden: started: SendData
2014.05.30 10:26:40 3: owo OpenWeatherMap_senden: htmlResponse: 200 OK
2014.05.30 10:26:40 1: usb create starting
2014.05.30 10:26:42 1: usb create end
2014.05.30 10:26:42 2: FHEM ready
2014.05.30 10:26:42 0: Server started with 353 defined entities (version $Id: fhem.pl 6001 2014-05-29 10:25:01Z rudolfkoenig $, os linux, user fhem, pid 12171)
2014.05.30 10:27:32 1: NOTE: make sure you have a database backup!
2014.05.30 10:27:32 2: Backup with command: tar -cf - configDB.conf ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg_ori ./fhem.pl ./fhem.png ./FrameRSS.jpg ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140530_102732.tar.gz
2014.05.30 10:28:51 1: backup done: FHEM-20140530_102732.tar.gz (34532390 Bytes)
2014.05.30 10:28:54 1: NOTE: make sure you have a database backup!
2014.05.30 10:28:54 2: Backup with command: tar -cf - configDB.conf ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg_ori ./fhem.pl ./fhem.png ./FrameRSS.jpg ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140530_102854.tar.gz
2014.05.30 10:30:18 1: backup done: FHEM-20140530_102854.tar.gz (34532390 Bytes)
Hier noch eine Übersicht der aktuellen Versionen:
# $Id: fhem.pl 6001 2014-05-29 10:25:01Z rudolfkoenig $
# $Id: configDB.pm 5947 2014-05-23 18:35:31Z betateilchen $
# $Id: 00_CUL.pm 5487 2014-04-08 11:29:41Z rudolfkoenig $
# $Id: 09_CUL_FHTTK.pm 5207 2014-03-12 19:05:33Z matscher $
# $Id: 18_CUL_HOERMANN.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 10_CUL_IR.pm 3580 2013-08-02 16:17:38Z betateilchen $
# $Id: 14_CUL_WS.pm 5379 2014-03-30 16:34:01Z rudolfkoenig $
# $Id: 93_DbLog.pm 5782 2014-05-08 06:15:58Z tobiasfaust $
# $Id: 00_FBAHA.pm 5819 2014-05-11 14:17:21Z rudolfkoenig $
# $Id: 10_FBDECT.pm 5819 2014-05-11 14:17:21Z rudolfkoenig $
# $Id: 01_FHEMWEB.pm 6001 2014-05-29 10:25:01Z rudolfkoenig $
# $Id: 11_FHT.pm 5070 2014-02-28 07:48:55Z rudolfkoenig $
# $Id: 95_FLOORPLAN.pm 5051 2014-02-26 12:36:45Z betateilchen $
# $Id: 10_FS20.pm 5326 2014-03-26 07:15:25Z rudolfkoenig $
# $Id: 92_FileLog.pm 5876 2014-05-16 19:54:51Z rudolfkoenig $
# $Id: 12_HMS.pm 5097 2014-03-02 15:25:08Z rudolfkoenig $
# $Id: 51_I2C_BMP180.pm 5770 2014-05-06 19:20:46Z klauswitt $
# $Id: 73_PRESENCE.pm 5434 2014-04-04 15:43:23Z markusbloch $
# $Id: 02_RSS.pm 5885 2014-05-18 13:29:39Z borisneubert $
# $Id: 99_SMAUtils.pm
# $Id: 99_SUNRISE_EL.pm 5851 2014-05-13 19:39:03Z rudolfkoenig $
# $Id: 98_SVG.pm 5956 2014-05-24 13:04:04Z rudolfkoenig $
# $Id: 42_SYSMON.pm 5833 2014-05-12 18:07:38Z hexenmeister $
# $Id: 32_SYSSTAT.pm 5746 2014-05-04 19:49:29Z justme1968 $
# $Id: 45_TRX.pm 5957 2014-05-24 13:46:29Z wherzig $
# $Id: 46_TRX_ELSE.pm 5719 2014-05-01 19:18:38Z wherzig $
# $Id: 46_TRX_LIGHT.pm 5955 2014-05-24 12:39:07Z wherzig $
# $Id: 46_TRX_SECURITY.pm 5616 2014-04-23 20:51:14Z wherzig $
# $Id: 46_TRX_WEATHER.pm 5719 2014-05-01 19:18:38Z wherzig $
# $Id: 99_Utils.pm 5488 2014-04-08 11:32:17Z rudolfkoenig $
# $Id: 98_WOL.pm 5519 2014-04-13 19:17:22Z dietmar63 $
# $Id: 59_Weather.pm 5810 2014-05-10 11:17:40Z borisneubert $
# $Id: 90_at.pm 5319 2014-03-25 10:11:47Z rudolfkoenig $
# $Id: 98_autocreate.pm 5268 2014-03-20 20:46:00Z rudolfkoenig $
# $Id: 98_average.pm 5443 2014-04-05 06:37:49Z rudolfkoenig $
# $Id: 98_backup.pm 5893 2014-05-19 09:45:08Z rudolfkoenig $
# $Id: 98_dewpoint.pm 5099 2014-03-02 16:29:34Z betateilchen $
# $Id: 98_dummy.pm 4934 2014-02-15 08:23:12Z rudolfkoenig $
# $Id: 95_holiday.pm 5956 2014-05-24 13:04:04Z rudolfkoenig $
# $Id: 99_myUtils.pm 3417 2014-03-22 Klaus Rubik $
# $Id: 91_notify.pm 5470 2014-04-07 08:32:35Z rudolfkoenig $
# $Id: 98_openweathermap.pm 5500 2014-04-09 18:57:05Z betateilchen $
# $Id: 33_readingsGroup.pm 5993 2014-05-28 14:18:59Z justme1968 $
# $Id: 32_speedtest.pm 4756 2014-01-27 21:15:50Z justme1968 $
# $Id: 98_structure.pm 5050 2014-02-26 08:29:44Z rudolfkoenig $
# $Id: 98_telnet.pm 4844 2014-02-08 07:54:03Z rudolfkoenig $
# $Id: 91_watchdog.pm 5622 2014-04-24 08:04:29Z rudolfkoenig $
# $Id: 98_weblink.pm 5608 2014-04-23 10:57:16Z rudolfkoenig $
# $Id: 55_weco.pm 5517 2014-04-13 00:37:45Z betateilchen $
Viele Grüße
Klaus
Passiert das Problem auch mit der demo config (fhem.demo.cfg)?
Zitat von: rudolfkoenig am 30 Mai 2014, 11:25:14
Passiert das Problem auch mit der demo config (fhem.demo.cfg)?
Hallo Rudi,
wo finde ich diese?
Gruß
Klaus
Subversion oder ab 5.5. im Standardpaket. Achtung: fhem.cfg.demo benoetigt auch das demolog Verzeichnis.
Per update wird es nicht aktualisiert.
Gibt es hier schon eine Lösung? bei mir passiert das wieder erneut.
Gruß Martin