Zitat von: rudolfkoenig am 19 August 2014, 22:32:10
Ich habe update neu gebaut, damit
- es einfacher und (fuer mich) verstaendlicher wird
- es genauere Fehlermeldungen liefert
- es eine einfache Moeglichkeit bietet den alten Zustand vor dem update zu restaurieren.
...
Ich habe jetzt zwar stundenlang update+restore gespielt, und ich finde keine Probleme mehr, aber ich habe bestimmt einige Kombinationen vergessen, deswegen bitte testen und Probleme melden, wie ueblich im Bereich Sonstiges.
Auf zwei Systemen mit fhem.cfg erfolgreich getestet.
Zum Testen mit configDB hatte ich noch keine Zeit.
Hallo,
habe gerade update gestartet und erhalte u.a. die Meldung:
File(s) skipped for an update! Size does not correspond:
==> 55_GDS.pm: size from controlfile: 40736 bytes, size after download: 44860 bytes
==> 71_YAMAHA_AVR.pm: size from controlfile: 78451 bytes, size after download: 78213 bytes
Eine Reihe weiterer Module wurde erfolgreich aktualisiert.
Viele Grüße
Boris
Das ist noch das alte Modul, erkennbar an der Fehlermeldung. Das Neue sollte melden:
Zitat55_GDS.pm is 44860 bytes, not 40376 as expected
aborting.
Die Meldung im neuen Modul war aber kaputt (dumpt die ganze Datei statt nur den Namen), danke fuer den Hinweis, das habe ich jetzt gefixed und eingecheckt.
Abgesehen davon erwarte ich nicht, dass die neue Version dieses Problem nicht hat, deswegen speichert sie diese Datei als FHEM/55_GDS.pm.corrupt, falls attr global verbose 5 ist. Ich wuesste gerne, was dein Proxy an dem Inhalt geaendert hat, vielleicht kriegen wir raus, mit welchem HTTP Header-Eintrag FHEM ihn davon abhalten kann.
Ah, natürlich.
Habe mir gerade das 98_update.pm aus dem SVN gezogen.
reload 98_update.pm
attr global verbose 5
update
Got remote controlfile with 1335 entries.
MKDIR /opt/fhem/restoreDir
MKDIR /opt/fhem/restoreDir/2014-08-20
Got local controlfile with 1335 entries.
mv /opt/fhem/FHEM/OWNet.* /opt/fhem/unused
mv /opt/fhem/FHEM/release.* /opt/fhem/unused
mv /opt/fhem/FHEM/99_updatefhem.* /opt/fhem/unused
mv /opt/fhem/FHEM/99_CULflash.* /opt/fhem/unused
mv /opt/fhem/FHEM/99_JsonList.* /opt/fhem/unused
mv /opt/fhem/FHEM/99_backup.* /opt/fhem/unused
mv /opt/fhem/FHEM/99_update.* /opt/fhem/unused
mv /opt/fhem/FHEM/*.jpg /opt/fhem/www/images/default
mv /opt/fhem/FHEM/*.png /opt/fhem/www/images/default
mv /opt/fhem/FHEM/*.gplot /opt/fhem/www/gplot
mv /opt/fhem/FHEM/*.js /opt/fhem/www/pgm2
mv /opt/fhem/FHEM/*.svg /opt/fhem/www/pgm2
mv /opt/fhem/FHEM/*.css /opt/fhem/www/pgm2
mv /opt/fhem/FHEM/*.html /opt/fhem/docs
mv /opt/fhem/www/pgm2/*.gplot /opt/fhem/www/gplot
mv /opt/fhem/www/pgm2/*.jpg /opt/fhem/www/images/default
mv /opt/fhem/www/pgm2/*.png /opt/fhem/www/images/default
mv /opt/fhem/www/pgm2/*.html /opt/fhem/docs
UPD FHEM/21_OWID.pm
MKDIR /opt/fhem/restoreDir/2014-08-20/FHEM
UPD FHEM/55_GDS.pm
UPD FHEM/71_YAMAHA_AVR.pm
UPD FHEM/91_eventTypes.pm
UPD FHEM/98_autocreate.pm
UPD FHEM/98_update.pm
update finished, "shutdown restart" is needed to activate the changes
Diesmal gab es kein Gemecker. Erstaunlich...
Viele Grüße
Boris
ähm... irgendwas stimmt da im Zusammenhang mit fheminfo bzw. sendStatistics wohl noch nicht.
(http://up.picr.de/19273349rn.png)
Die fast 4000 Zeilen HTML Ausgabe am Ende des Screenshots zieht sich über unzählige Seiten. (siehe Anhang)
Dein Anhang ist statistics.html als Quelltext.
Ich habe leider gestern zum Schluss nicht nur in der Doku den Hinweis von statistics.cgi auf statistics.html korrigiert, sondern auch im Code von fheminfo, was natuerlich Unsinn ist. Habs gefixed.
wo Du gerade bei kleinen Korrekturen bist:
update finished, "shutdown restart" is needed to activate the changes
Fhem info:
Zwischen den beiden Zeilen wünsche ich mir der Übersichtlichkeit wegen eine Leerzeile.
Sehe ich das eigentlich richtig, dass der update-Lauf nun nicht mehr an den "Morgen-Zyklus" gebunden ist, sondern jederzeit alle aktualisierten Dateien geladen werden können?
Die Leerzeile habe ich eingefuegt.
Update ist weiterhin an den "Morgen-zyklus" gebunden, ich habe es nur gestern und heute ein paarmal per Hand aufgerufen.
Zitat von: rudolfkoenig am 20 August 2014, 21:08:46
Update ist weiterhin an den "Morgen-zyklus" gebunden, ich habe es nur gestern und heute ein paarmal per Hand aufgerufen.
Danke für die Info.
Ich müsste mal noch testen, was passiert, wenn die 99_Utils.pm per Update kommt und diese Datei auf Benutzerseite in der configDB abgelegt ist. Mach ich bei Gelegenheit.
Hallo,
kann es sein, dass jetzt alle Ausgaben von updatecheck und fheminfo im Logfile landen? Das ist bei mir mit den neuesten Versionen jetzt so.
Beste Grüße
Dirk
Ja. Ich habe das loggen beim check jetzt entfernt, fheminfo bei einem normalen update bleibt.
Hallo Rudolf,
habe bei mir bewusst noch
backup_before_update=1
gesetzt.
Damit wird aber auch bei einem
update check
ein Backup durchgeführt. Ist das so gewollt?
Viele Grüße,
Andreas
Nein, geaendert, eingecheckt.
Alles klar, vielen Dank.
Habe mal an meinem 2. System ein update force gemacht.
restoreDir mit 2014-08-21 Folder wurde angelegt also soweit alles ok.
update ckeck bringt richtigerweise -->
List of new / modified files since last update:
nothing to do...
Wenn ich update eingebe läuft der Eventmanager los. :-\
Ist da was faul oder habe ich was übersehen?
Events:
2014-08-21 14:39:56 Global global nothing to do...
2014-08-21 14:39:56 OREGON BTHR918N temperature: 22.7
2014-08-21 14:39:56 OREGON BTHR918N humidity: 44
2014-08-21 14:39:56 OREGON BTHR918N pressure: 973
Gruß Billy
Wenn update_in_background gesetzt ist (und es ist per default), laeuft der Event-Manager, bzw. im telnet der inform timer los. Aber das ist nicht neu.
Danke, war mir bisher nie aufgefallen!
Hallo Kollegen,
ich habe gerade ein Update auf die letze dev Version durchgeführt.
Muss ich nun den Backup Befehl deaktivieren?
Im Log steht bei einem Update nun folgendes:
2014.08.22 10:28:48 2: Backup with command: tar -cf - fhem.cfg ./log/fhem.save ./certs ./CHANGED ./configDB.pm ./contrib ./demolog ./docs ./FHEM ./fhem.cfg ./fhem.cfg.demo ./fhem.cfg~ ./fhem.pl ./log ./login as: pi ./README_DEMO.txt ./restoreDir ./unused ./www |gzip > ./backup/FHEM-20140822_102848.tar.gz
2014.08.22 10:31:59 1: backup tar: ./login: Cannot stat: No such file or directory
tar: as\:: Cannot stat: No such file or directory
tar: pi: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
Man muss nicht backup deaktivieren, es ist nur fuer manche Aufgaben ueberfluessig geworden.
Das Problem in deinem Fall hat nichts mit dem neuen Version von update zu tun, sondern damit, dass backup nicht mit Dateinamen klarkommt, die ein Leerzeichen enthalten.
Sieht so aus, als müsse da noch was escaped werden:
2014.08.22 10:44:26 1: UPD www/images/default/dim06%.png
2014.08.22 10:44:26 4: HttpUtils url=http://fhem.de/fhemupdate/www/images/default/dim06%.png
2014.08.22 10:44:26 4: http://fhem.de/fhemupdate/www/images/default/dim06%.png: HTTP response code 400
2014.08.22 10:44:26 4: HttpUtils http://fhem.de/fhemupdate/www/images/default/dim06%.png: Got data, length: 345
2014.08.22 10:44:26 1: Got 345 bytes for www/images/default/dim06%.png, not 2328 as expected,
2014.08.22 10:44:26 1: saving it to www/images/default/dim06%.png.corrupt .
Zitat von: rudolfkoenig am 22 August 2014, 10:48:21
Man muss nicht backup deaktivieren, es ist nur fuer manche Aufgaben ueberfluessig geworden.
Das Problem in deinem Fall hat nichts mit dem neuen Version von update zu tun, sondern damit, dass backup nicht mit Dateinamen klarkommt, die ein Leerzeichen enthalten.
Wo kommen denn die Namen mit Leerzeichen her? Gestern lief das Backup noch ohne Probleme durch. Haben Die sich mit dem letzen Update eingeschlichen?
Wofür brauche ich das Backup denn noch konkret?
Das update sah übrigens so aus:
2014.08.22 10:03:54 1: MKDIR ./restoreDir
2014.08.22 10:03:54 1: MKDIR ./restoreDir/2014-08-22
2014.08.22 10:03:54 1: UPD FHEM/36_WMBUS.pm
2014.08.22 10:03:54 1: MKDIR ./restoreDir/2014-08-22/FHEM
2014.08.22 10:03:54 1: UPD FHEM/98_update.pm
2014.08.22 10:03:54 1: UPD FHEM/WMBus.pm
2014.08.22 10:03:54 1:
2014.08.22 10:03:54 1: update finished, "shutdown restart" is needed to activate the changes.
2014.08.22 10:03:55 1: Shutdown restart habe ich durchgeführt.
Danach das Backup über "backup" gestartet. Dan kamen die Fehlermeldungen.
@slor:
Das neue update sichert nur die Dateien, die sie selbst ueberschreibt. Mann kann also schnell auf die letzte Version eines Moduls zurueckgreifen, falls der aktuelle Probleme bereitet. Die eigenen Aenderungen (fhem.cfg) und die gesammelten Daten (fhem.state/log) werden nicht gesichert.
Eine Datei namens "login as: pi" sollte FHEM nicht anlegen, ich tippe auf ein Copy&Paste Fehler.
@Wolfpunk:
In der Tat, habs gefixed und eingecheckt.
Ich fände es gut wenn es ähnlich wie fürs Backup
attr global backupdir
ein
attr global restoreDir
Geben würde.
Im Augenblick hängt das ja wohl am
attr global modpath
Billy
Ich bin z.Zt. der Ansicht, dass es nicht so flexibel sein soll. Erleichtert fuer den Normalanwender den Umzug, und das System bleibt einfacher. Fortgeschrittene koennen den Speicherort mit OS-Mitteln (Symlink/etc) verschieben.
Zitat von: rudolfkoenig am 22 August 2014, 11:10:01
@slor:
Eine Datei namens "login as: pi" sollte FHEM nicht anlegen, ich tippe auf ein Copy&Paste Fehler.
Keine Ahnung warum die "login as: pi" dort rumlag. Die wurde im März 14 dort angelegt. Ich habe Sie jetzt mal verschoben und schwups geht auch das Backup wieder. Komisch, warum es die ganze Zeit (bis gestern) ohne zu Meckern lief mit dieser Datei?
Hallo,
bei einem Update Check wird bei mir ein Restore Verzeichnis angelegt und dann kommt "Nothing to do... "
Wenn ich danach ein Update mache, werden aber doch neue Dateien heruntergeladen.
Irgendwie ist die Prüfung bei mir nicht sauber - zudem macht es mMn keinen Sinn, schon bei einem Check das Restoreverzeichnis anzulegen.
Gruß Christoph
Ich kann keinen der beiden Punkte nachvollziehen. Update check legt bei mir kein Verzeichnis an, und falls es nothing to do meldet, dann ist das beim update bzw dem equivalenten "update all" nicht anders.
Ich habe jetzt die MKDIR Meldungen auf verbose 4 verbannt, und restore hat eine "restore finished" Meldung bekommen.
Hallo,
hier ist ein Auszug aus meinem Log
2014.08.24 09:53:37 1: MKDIR ./restoreDir/2014-08-24
2014.08.24 09:53:37 1: nothing to do...
2014.08.24 12:29:35 1: UPD FHEM/98_SVG.pm
2014.08.24 12:29:35 1: MKDIR ./restoreDir/2014-08-24/FHEM
2014.08.24 12:29:35 1: UPD FHEM/99_Utils.pm
2014.08.24 12:29:36 1: UPD docs/commandref.html
2014.08.24 12:29:37 1: MKDIR ./restoreDir/2014-08-24/docs
2014.08.24 12:29:37 1:
2014.08.24 12:29:37 1: update finished, "shutdown restart" is needed to activate the changes.
2014.08.24 12:29:37 1:
2014.08.24 12:29:44 1: Fhem info:
Release : 5.5
Branch : DEVELOPMENT
OS : linux
Arch : mips-linux
Perl : v5.12.2
uniqueID : 07f4f50a43295873f8930c78d4dfffad
upTime : 23:33:03
Defined modules:
CUL_HM : 150
Dashboard : 1
FB_CALLMONITOR : 1
FHEMWEB : 10
FileLog : 15
HCS : 1
HMLAN : 1
HMinfo : 1
SVG : 14
SWAP : 1
SYSMON : 1
THRESHOLD : 6
Weather : 1
at : 12
autocreate : 1
average : 2
cloneDummy : 8
dewpoint : 1
Morgens um 9:53 habe ich "update check" ausgeführt, und um 12:26 habe ich dann das "update" gemacht.
Macht es Sinn vor dem Ganzen mal auf verbose 5 umzustellen ?
Gruß Christoph
habe heute mal fhem als service unter win7 installiert. Das erste Update funktionierte gut. Update force danach (hatte zwischenzeitlich 2 Module ausgetauscht) lief nicht
ZitatMKDIR ./restoreDir
MKDIR ./restoreDir/2014-08-24
UPD ./CHANGED
writing ././CHANGED failed: Inappropriate I/O control operation, trying to restore the previous version and aborting the update
restoreDir und 2014-08-24 wurden sauber angelegt. Selber Fehler auch nach das file changed einmal gelöscht wurde
Stimmt, windows gibts ja auch noch.
Da fehlte
binmode(FD);
in FHEM/98_update.pm, vor der Zeile
print FD $content;
danach hat es mit dem update geklappt. Allerdings scheint windows mit "updateInBackground" nicht zu harmonieren, damit hoert update nach 50/60 downloads auf, und im frontend sieht man auch nichts. Wenn ein Windows-Experte oder -Liebhaber das mal anschaut und mir Patches schickt, dann baue ich das ein.
Hallo Rudi,
könntest Du bitte den Aufruf der Update-Funktion für configDB wieder einbauen, der im alten update-Modul enthalten war?
Index: 98_update.pm
===================================================================
--- 98_update.pm (revision 6452)
+++ 98_update.pm (working copy)
@@ -317,6 +317,8 @@
return;
}
+ cfgDB_FileUpdate("$root/$fName") if(configDBUsed());
+
return 1;
}
Auf meinen Testsystemen erfolgreich im Einsatz.
Danke!
Update Force unter Win hat mit deiner Änderung nun funktioniert und er hat brav alles neu geladen.
@betateilchen: eingecheckt.
danke.
Hallo Rudi,
hast Du irgendeinen Plan, die Anzahl der in ./restoreDir angelegten Backupverzeichnisse irgendwie zu begrenzen?
Ich denke da an etwas ähnliche wie nrarchives oder so...
Viele Grüße
Udo
Zitat von: betateilchen am 25 August 2014, 19:07:41
hast Du irgendeinen Plan, die Anzahl der in ./restoreDir angelegten Backupverzeichnisse irgendwie zu begrenzen?
Ist das nicht schon vorhanden?
CommandRef:
◦restoreDirs update sichert jede Datei vor dem Überschreiben mit der neuen Version aus dem Web. Für diesen Zweck wird zuerst ein restoreDir Verzeichnis in der global modpath Verzeichnis angelegt, und danach ein Unterverzeichnis mit dem aktuellen Datum. In diesem Verzeichnis werden vor dem Überschreiben die alten Versionen der Dateien gerettet. Die Voreinstellung ist 3, d.h. die
letzten 3 Datums-Verzeichnisse werden aufgehoben, und die älteren entfernt. Falls man den Wert auf 0 setzt, dann ist dieses Feature deaktiviert.
Danke für den Hinweis, das hatte ich übersehen.
Hallo Rudolf,
ich schon wieder. ;)
Habe bei mir immer noch bewusst
backup_before_update=1
gesetzt.
Bei der einmaligen Eingabe von
update
wird allerdings immer zwei mal ein Backup (=zwei Backup-Dateien im Backup-Verzeichnis) durchgeführt.
Sieht für mich so aus, als ob
update
trotz nur einmaliger Eingabe zweimal ausgeführt wird.
Im Web-Frontend passiert während des gesamten Update-Prozesses (Backup + Update) nichts, bis irgendwann (nach Abschluss des zweiten Backups + Updates?) die Meldung "Keine Daten empfangen" erscheint.
Wäre nett, wenn Du Dir das 'mal anschaust.
Hier der Auszug aus dem Log:
2014.08.27 08:54:32 2: Backup with command: tar -cf - fhem.cfg ./log/fhem.save /opt/fhem/CHANGED /opt/fhem/config /opt/fhem/configDB.pm /opt/fhem/contrib /opt/fhem/credentials.cfg /opt/fhem/demolog /opt/fhem/docs /opt/fhem/FHEM /opt/fhem/fhem.cfg /opt/fhem/fhem.cfg.demo /opt/fhem/fhem.pl /opt/fhem/log /opt/fhem/README_DEMO.txt /opt/fhem/restoreDir /opt/fhem/unused /opt/fhem/www |gzip > /opt/fhem/backup/FHEM-20140827_085432.tar.gz
2014.08.27 08:55:35 1: backup tar: Entferne führende ,,/" von Elementnamen
2014.08.27 08:55:35 1: backup done: FHEM-20140827_085432.tar.gz (15998991 Bytes)
2014.08.27 08:55:35 1: Backup: tar: Entferne führende ,,/" von Elementnamen
backup done: FHEM-20140827_085432.tar.gz (15998991 Bytes)
2014.08.27 08:55:36 1: UPD FHEM/00_HMLAN.pm
2014.08.27 08:55:36 1: UPD FHEM/10_CUL_HM.pm
2014.08.27 08:55:37 1: UPD FHEM/98_ComfoAir.pm
2014.08.27 08:55:38 1: UPD FHEM/98_HMinfo.pm
2014.08.27 08:55:38 1: UPD FHEM/98_HTTPMOD.pm
2014.08.27 08:55:38 1: UPD FHEM/98_statistics.pm
2014.08.27 08:55:38 1: UPD docs/commandref.html
2014.08.27 08:55:41 1:
2014.08.27 08:55:41 1: update finished, "shutdown restart" is needed to activate the changes.
2014.08.27 08:55:41 1:
2014.08.27 08:55:45 1: Fhem info:
Release : 5.5
Branch : DEVELOPMENT
OS : linux
Arch : arm-linux-gnueabihf-thread-multi-64int
Perl : v5.14.2
uniqueID : 18f364a9f6691c6c4af037478c12cd7a
upTime : 12:54:38
Defined modules:
CUL : 2
CUL_HM : 33
CUL_MAX : 1
Calendar : 1
Dashboard : 1
FHEMWEB : 8
FLOORPLAN : 1
FileLog : 36
HMinfo : 1
HTTPMOD : 6
MAX : 8
PRESENCE : 4
SVG : 17
SYSMON : 1
THRESHOLD : 2
Twilight : 1
Weather : 1
at : 30
autocreate : 1
dummy : 25
eventTypes : 1
holiday : 1
notify : 28
readingsGroup : 3
structure : 2
telnet : 1
watchdog : 2
weblink : 3
Defined models per module:
CUL_HM : ActionDetector,CCU-FHEM,HM-ES-PMSw1-Pl,HM-LC-Bl1PBU-FM,HM-Sen-MDIR-O-2
Transmitting this information during an update:
onUpdate (Note: You can change this via the global attribute sendStatistics)
server response: ==> ok
2014.08.27 08:55:48 2: Backup with command: tar -cf - fhem.cfg ./log/fhem.save /opt/fhem/CHANGED /opt/fhem/config /opt/fhem/configDB.pm /opt/fhem/contrib /opt/fhem/credentials.cfg /opt/fhem/demolog /opt/fhem/docs /opt/fhem/FHEM /opt/fhem/fhem.cfg /opt/fhem/fhem.cfg.demo /opt/fhem/fhem.pl /opt/fhem/log /opt/fhem/README_DEMO.txt /opt/fhem/restoreDir /opt/fhem/unused /opt/fhem/www |gzip > /opt/fhem/backup/FHEM-20140827_085548.tar.gz
2014.08.27 08:56:53 1: backup tar: Entferne führende ,,/" von Elementnamen
2014.08.27 08:56:53 1: backup done: FHEM-20140827_085548.tar.gz (16530876 Bytes)
2014.08.27 08:56:53 1: Backup: tar: Entferne führende ,,/" von Elementnamen
backup done: FHEM-20140827_085548.tar.gz (16530876 Bytes)
2014.08.27 08:56:53 1: nothing to do...
Viele Grüße,
Andreas
Seufz, ich will nicht auch noch backup neu schreiben, den verwende ich gar nicht. Aber vielleicht habe ich Glueck, und das Probem sitzt nicht in backup.
Koenntest Du bitte so einen Problemfall mit "attr global verbose 5" protokollieren?
Tritt das Problem immer auf?
Auch ohne "updateInBackground" ?
Bitte alle 3 Fragen beantworten, nicht nur ausgewaehlte :)
Dass update 2-mal aufgerufen wurde, sehe ich in deinem Log nicht, aber tar (aus backup) wurde 4-mal aufgerufen.
Hierzu ein paar Beobachtungen von mir zu genau diesem Thema:
Das Problem mit der doppelten Ausführung von im Frontend eingegebenen Befehlen tritt fhem-weit (!) immer dann auf, wenn eine Aktion länger als (circa) 60 Sekunden dauert. Warum auch immer. (Browser Problem? Javascript Problem? FHEMWEB Problem?)
Per Telnet tritt das Phänomen nie auf.
Mit dem neuen update Modul scheint das Problem allerdings beim update-Befehl (alleine) zumindest behoben. Ich hatte vorher den Effekt mit dem doppelt ausgeführten Update (bei abgeschaltetem backup) regelmäßig auf meinem Produktivsystem, aber nie auf dem Entwicklungssystem. Offenbar hat die Laufzeit bestimmter Aktionen auch noch etwas mit der "Größe" der fhem-Installation zu tun, genauer: mit der Anzahl der definierten devices und/oder der Anzahl der geladenen/verwendeten Module.
Hallo Rudolf,
Zitat von: rudolfkoenig am 27 August 2014, 09:41:15
Koenntest Du bitte so einen Problemfall mit "attr global verbose 5" protokollieren?
Anbei die zwei Logs, einmal mit updateInBackground=0 (zwei Backupdateien wurden erzeugt) und einmal mit updateInBackground=1 (damit wurden sogar drei Backup-Dateien erzeugt).
Zitat von: rudolfkoenig am 27 August 2014, 09:41:15
Tritt das Problem immer auf?
Ja, immer bei Aufruf von "update", auch wenn das Ergebnis "Nothing to do..." ist.
Zitat von: rudolfkoenig am 27 August 2014, 09:41:15
Auch ohne "updateInBackground" ?
s.o.
Vielen Dank,
Andreas
Auch bei mir wird Backup 3 mal ausgeführt bei update in Background. Die Dateien haben dabei eine unterschiedliche Größe, sodass ich denke, dass auch die Restore Files 3 mal angelegt werden.
Kann es sein, dass das neue update-Modul das Attribut "exclude_from_update" schlichtweg ignoriert?
@betateilchen:
nein, hoechstens dass es nicht funktioniert. Ist (wie dokumentiert) eine Liste von Regexps.
@scooty:
in der nicht-blockierenden updateInBackground=1 Variante sehe ich nur ein Update bzw. Backup, d.h. diese Version is mAn vom Problem nicht betroffen.
In der blockierenden Version sind es zwei updates, nach Abschluss des ersten updates+backup, was leider genau eine Minute dauert, schickt der Browser eine zweite Aufforderung, ich gehe davon aus, dass dies nicht manuell ausgeloest wurde, um mich zu aergern :)
Neue Fragen:
- welchen Browser verwendest du bzw. tritt das Problem auch mit einem anderen auf
- ist das FHEMWEB Attribut redirectCmds gesetzt?
- tritt das Problem auch in der leeren "Home-Ansicht" auf? Mit "Home Ansicht" meine ich die Seite ohne Geraete, die man nach dem Klick auf das FHEM-Icon bekommt.
Zitat von: rudolfkoenig am 28 August 2014, 08:52:44
@betateilchen:
nein, hoechstens dass es nicht funktioniert.
ok. Es funktioniert bei mir nicht mehr.
Besser formuliert?
Nicht ausreichend besser, da es bei mir funktioniert.
Also bitte soviel sagen, dass ich es nachstellen, oder wenigstens eingrenzen kann.
Ich hatte gestern vor dem Update das globale Attribut gesetzt auf "00_HMLAN.pm,10_CUL_HM.pm,HMConfig.pm" weil ich wusste, dass die Dateiversionen aus dem SVN zu diesem Zeitpunkt schon aktueller und fehlerbereinigt waren, aber die drei Dateien wurden trotzdem (kaputt-)aktualisiert, auch klar erkennbar im Logfile.
Mehr kann ich zum Nachstellen nicht bieten.
Hallo Rudolf,
Zitat von: rudolfkoenig am 28 August 2014, 08:52:44
in der nicht-blockierenden updateInBackground=1 Variante sehe ich nur ein Update bzw. Backup, d.h. diese Version is mAn vom Problem nicht betroffen.
Leider doch, mit updateInBackground=1 wurden sogar drei Backup-Dateien erzeugt, hier das "zusammengedampfte" Log "updateInBackground1.txt" mit den entsprechenden drei Backup-Kommandos:
.
.
2014.08.27 11:17:56 2: Backup with command: tar -cf - fhem.cfg ./log/fhem.save /opt/fhem/CHANGED /opt/fhem/config /opt/fhem/configDB.pm /opt/fhem/contrib /opt/fhem/credentials.cfg /opt/fhem/demolog /opt/fhem/docs /opt/fhem/FHEM /opt/fhem/fhem.cfg /opt/fhem/fhem.cfg.demo /opt/fhem/fhem.pl /opt/fhem/log /opt/fhem/README_DEMO.txt /opt/fhem/restoreDir /opt/fhem/unused /opt/fhem/www |gzip > /opt/fhem/backup/FHEM-20140827_111753.tar.gz
.
.
2014.08.27 11:19:01 2: Backup with command: tar -cf - fhem.cfg ./log/fhem.save /opt/fhem/CHANGED /opt/fhem/config /opt/fhem/configDB.pm /opt/fhem/contrib /opt/fhem/credentials.cfg /opt/fhem/demolog /opt/fhem/docs /opt/fhem/FHEM /opt/fhem/fhem.cfg /opt/fhem/fhem.cfg.demo /opt/fhem/fhem.pl /opt/fhem/log /opt/fhem/README_DEMO.txt /opt/fhem/restoreDir /opt/fhem/unused /opt/fhem/www |gzip > /opt/fhem/backup/FHEM-20140827_111901.tar.gz
.
.
2014.08.27 11:20:11 2: Backup with command: tar -cf - fhem.cfg ./log/fhem.save /opt/fhem/CHANGED /opt/fhem/config /opt/fhem/configDB.pm /opt/fhem/contrib /opt/fhem/credentials.cfg /opt/fhem/demolog /opt/fhem/docs /opt/fhem/FHEM /opt/fhem/fhem.cfg /opt/fhem/fhem.cfg.demo /opt/fhem/fhem.pl /opt/fhem/log /opt/fhem/README_DEMO.txt /opt/fhem/restoreDir /opt/fhem/unused /opt/fhem/www |gzip > /opt/fhem/backup/FHEM-20140827_112011.tar.gz
.
.Zitat von: rudolfkoenig am 28 August 2014, 08:52:44
In der blockierenden Version sind es zwei updates, nach Abschluss des ersten updates+backup, was leider genau eine Minute dauert, schickt der Browser eine zweite Aufforderung, ich gehe davon aus, dass dies nicht manuell ausgeloest wurde, um mich zu aergern :)
Und so etwas traust Du mir zu? :-[ ;)
Nein, manuell wurde von mir nichts ausgelöst.
Zitat von: rudolfkoenig am 28 August 2014, 08:52:44
Neue Fragen:
- welchen Browser verwendest du bzw. tritt das Problem auch mit einem anderen auf
Chrome und Firefox zeigen das gleiche Verhalten.
Zitat von: rudolfkoenig am 28 August 2014, 08:52:44
- ist das FHEMWEB Attribut redirectCmds gesetzt?
Nicht explizit, daher gehe ich davon aus, dass der Defaultwert 1 benutzt wird.
Zitat von: rudolfkoenig am 28 August 2014, 08:52:44
- tritt das Problem auch in der leeren "Home-Ansicht" auf? Mit "Home Ansicht" meine ich die Seite ohne Geraete, die man nach dem Klick auf das FHEM-Icon bekommt.
Ja, die heutigen update-Testläufe (mit Chrome und Firefox) habe ich explizit aus der "Home-Ansicht" gestartet.
Vielen Dank fürs Kümmern,
Andreas
Zitat von: rudolfkoenig am 28 August 2014, 08:52:44
In der blockierenden Version sind es zwei updates, nach Abschluss des ersten updates+backup, was leider genau eine Minute dauert, schickt der Browser eine zweite Aufforderung
Meine Rede, seit mehreren Wochen, zu diesem Thema, zuletzt hier im Thread:
Zitat von: betateilchen am 27 August 2014, 09:53:56
Das Problem mit der doppelten Ausführung von im Frontend eingegebenen Befehlen tritt fhem-weit (!) immer dann auf, wenn eine Aktion länger als (circa) 60 Sekunden dauert. Warum auch immer. (Browser Problem? Javascript Problem? FHEMWEB Problem?)
Per Telnet tritt das Phänomen nie auf.
Das Fehlverhalten ist nicht browserspezifisch - zumindest konnte ich bisher keinen (gängigen) Browser finden, in dem das Problem nicht auftritt.
@betateilchen:
laut (alten) Doku war exclude_from_update auch frueher schon space getrennt (und jetzt auch), aber frueher wurde die Dateiname als Regexp gegen dem ganzen Attribut geprueft ($exclude =~ m/$fname/, mAn etwas verrueckt), deswegen klappt es aber auch mit Komma. Jetzt wird das Attribut an Space aufgeteilt, und jeder der Teile wird geprueft ($fname =~ m/$excl[$i]/).
Ich wuerde gerne bei meiner Loesung bleiben, falls nix Wesentliches dagegen spricht.
@ scooty: ich schau das heute Abend mal an.
Ich habe kein Problem damit, von Komma auf Leerzeichen umzustellen, wenn es anders nicht (mehr) funktioniert.
Was ich aber völlig schräg finde, ist die Tatsache, dass solche Listenangaben in Attributen fhemweit völlig willkürlich definiert sind. Mal mit Komma, mal mit Leerzeichen und was weiß ich noch alles. Man muss eigentlich für jedes Modul erstmal ergründen, was nun die korrekte Syntax ist. Könnte man nicht Bestrebungen einleiten, das generell zu vereinheitlichen? In diesem Fall wäre ich dann doch wieder für eine kommagetrennte Liste, da Attributwerte in Listen ja durchaus auch Leerzeichen enthalten können wie bei room(s) und group(s)
Neue Erkenntnisse zum Thema:
Mit Leerzeichen zur Trennung funktioniert es grundsätzliche.
Aber... zwei Probleme gibt es trotzdem:
- die ausgelassenen Dateien sollten mit einem entsprechenden Vermerk ebenso geloggt werden wie die tatsächlich aktualisierten, sonst kommt man nie drauf, dass da Dateien ausgelassen wurden.
- löscht man nach dem update das attribute exclude_from_update und führt dann nochmal ein Update aus, werden die fehlenden Dateien nicht aktualisiert. Vermutlich weil das lokale Kontrollfile vom Auslassen nix mitbekommen hat.
Hallo,
bei mir wird immer mich bei einem Update Check ein altes Restoreverzeichnis gelöscht und ein neues leeres angelegt. Wenn ich das drei Tage hintereinander mache, habe ich keine Dateien mehr, die ich zurückspielen könnte.
Könnte jemand das mal prüfen, oder bin ich der einzigste bei dem das so passiert. Das löschen wird übrigens im WebIf angezeigt, das Neuanlegen nicht.
Gruß Christoph
PS. Update Check sagte Nothing to do - ein anschließendes Update hat zwei Dateien upgedatet.
Parameter restoreDirs in der commandref (http://fhem.de/commandref.html#update) "ist Dein Freund"...
"Wiki-Promotion";) oder: http://www.fhemwiki.de/wiki/FHEM_Command_Beispiele#update_... und den dort verlinkten Ankündigungs-Beitrag von Rudi
PS: Wiki-Verbesserungen erwünscht...
Hallo,
damit komme ich nicht weiter. Ich habe "update check" gemacht. Dort soll eigentlich nur geprüft werden ob es neue Versionen gibt.
Das Ergebnis war, ein altes RestoreDir wurde gelöscht, ein neues leeres mit heutigem Datum angelegt und angezeigt "Nothing to do ...".
Wenn nur gecheckt wird, warum werden dabei schon Verzeichnisse gelöscht und erstellt ?
Anschließend habe ich ein "update" eingegeben und es wurden zwei Dateien erneuert. Wieso wurden diese bei Check nicht angezeigt ?
Das mit den 3 RestoreDirs finde ich vollkommen ok. Wenn aber jetzt der Check schon eines löscht und ein neues anlegt, habe ich nach drei Checks ohne zwischenzeitliches Update drei leere Verzeichnisse.
Gruß Christoph
Stimmt. Das Löschen und Anlegen der Verzeichnisse sollte noch verbessert werden. Ich denke, da muss Rudi nochmal ran :)
Anlegen eines Verzeichnisses nur, wenn es auch wirklich benutzt wird.
@Bennemannc: kann ich nicht nachvollziehen, anlegen und loeschen der restoreDirs werden bei check nicht durchgefuehrt (war auch so Absicht, sicherheitshalber gerade getestet). Allerdings war die Pruefung auch check/all/force nicht case insensitive, das habe ich jetzt geaendert.
@betateilchen: ich habe jetzt eine zusaetzliche Ausgabe beim Anlegen der restoreDir/YYYY-MM-DD Verzeichnis, sowie beim skippen einer Datei in der Exclude-Liste (letzteres allerdings nur loglevel 4) hinzugefuegt.
Und man kann jederzeit einzelne Dateien mit Angabe der Dateiname herunterladen, unabhaengig vom controlfile, da wird die lokale control-Datei auch nicht erneuert.
Hallo Rudolf,
dann werde ich morgen mal mit verbose 5 loggen, mal sehen was da abgeht. Bei mir ist dieses Verhalten reproduzierbar (FB 7362 SL).
Ich habe aber auch noch folgende Meldung im Log stehen, mit der ich nichts anfangen kann.
/etc/version: /etc/init.d/rc.conf: line 4: can't create /var/env: Permission denied
rm: can't remove '/var/htmltext.db': Permission denied
ln: /var/htmltext.db: File exists
rm: can't remove '/var/TZ': Permission denied
ln: /var/TZ: File exists
Bei der Fritte kann man doch nichts nach /etc/init.d/ schreiben - das ist doch readonly. /var/env ist -rw-r--r-- root root, das könnte man mit chown oder chmod ändern, aber da stehen Daten von AVM drin. /var/htmltext.db ist ein Link auf /etc/htmltext.db - also ro Dateisystem, /var/TZ geht ebenfalls nach /etc/...
Das Ganze kommt seit kurzem nach jedem shutdown restart.
Gruß Christoph
Shutdown restart fuehrt nur perl mit allen Argumenten aus, wie da irgendetwas mit /etc reinkommt ist mir schleierhaft. Von ln ganz zu schweigen.
Zitat von: rudolfkoenig am 29 August 2014, 20:07:55
@betateilchen: ich habe jetzt eine zusaetzliche Ausgabe beim Anlegen der restoreDir/YYYY-MM-DD Verzeichnis, sowie beim skippen einer Datei in der Exclude-Liste (letzteres allerdings nur loglevel 4) hinzugefuegt.
Danke.
Zitat von: rudolfkoenig am 29 August 2014, 20:07:55
Und man kann jederzeit einzelne Dateien mit Angabe der Dateiname herunterladen,
Schade. Das war vorher einfacher. Da konnte man nach dem Löschen des exclude-Attributes einfach die fehlenden Dateien per update "nachladen".
Hallo Zusammen,
ich habe 2 RPi´s ....
beim Update des ersten kommem die Meldungen..
Got remote controlfile with 1337 entries.
MKDIR ./restoreDir/2014-09-08
RMDIR: ./restoreDir/2014-08-31
rm ./restoreDir/2014-08-31/configDB.pm
rm ./restoreDir/2014-08-31/CHANGED
rm ./restoreDir/2014-08-31/docs/commandref_DE.html
rm ./restoreDir/2014-08-31/docs/commandref.html
rmdir ./restoreDir/2014-08-31/docs
rm ./restoreDir/2014-08-31/www/pgm2/fhemweb_slider.js
rm ./restoreDir/2014-08-31/www/pgm2/fhemweb_time.js
rm ./restoreDir/2014-08-31/www/pgm2/fhemweb.js
rmdir ./restoreDir/2014-08-31/www/pgm2
rmdir ./restoreDir/2014-08-31/www
rm ./restoreDir/2014-08-31/FHEM/98_statistics.pm
rm ./restoreDir/2014-08-31/FHEM/98_restore.pm
Bei zweiten kommt das nix !
Liegt das am "attr global verbose 3" bzw "attr global verbose 5"
danke
Klaus
Die rm und rmdir Meldungen kommen ab verbose 4.
Hi,
ich finde es etwas schwierig zu lesen, wenn die Meldungen vom Update im Event Monitor ausgegeben werden.
Die Sensoren schicken schon so viele Events, dass ich Meldungen aus dem Update nicht mehr sehen kann.
Würde es Sinn machen, die Update Meldungen noch separat (in einem Popup oder auf einer extra Seite) auszugeben?
Schöne Grüße
Daniel
ich fände es auch gut wenn nur die update meldungen kommen ohne die events. vor allem wenn das update durch ist wäre es schön wenn keine weiteren meldungen mehr kommen und alles vorbei scrollt. bei installationen mit vielen devices kommt da schnell einniges zusammen.
Eine pause taste im Eventmonitor wäre eh toll...
spricht eigentlich etwas dagegen, für den Fall, dass das update nicht im Hintergrund ausgeführt wird, das CHANGED auch nach dem "update" anzuzeigen und nicht nur nach einem "update check"?
Du meinst den Ausschnitt aus der CHANGED Datei?
Erstens weiss ich nicht warum es nur manchmal (falls nicht im Hintergrund ausgefuehrt) angezeigt werden soll.
Zweitens finde ich den angezeigten Ausschnitt zu lang, am liebsten wuerde ich nur Aenderungen anzeigen, die wirklich nur seit dem letzten update ins CHANGED File gekommen sind, das erfordert aber ein bisschen parsen/pruefen/etc. Bin prinzipiell aber nicht dagegen, muss nur gemacht werden.
Zitat von: rudolfkoenig am 22 September 2014, 14:28:55
Erstens weiss ich nicht warum es nur manchmal (falls nicht im Hintergrund ausgefuehrt) angezeigt werden soll.
Weil bei der Hintergrundausführung ohnehin alles durch den Event-Monitor scrollt und man kaum eine Chance hat, das wirklich zu lesen.
Was den "Ausschnitt" angeht - im Normalfall würde es reichen, zum Beispiel die ersten 15 Zeilen der Datei anzuzeigen.
Habe den Filter beim Hintergrundausfuehrung auf global gesetzt. Achtung, console.js muss explizit neu geladen werden, sonst kommt die alte, nicht filterfaehige Version aus dem Browser Cache.
Update check zeigt nur die neuen Zeilen aus der CHANGED Datei an.
Nach dem "echten" update werden diese Zeilen auch angezeigt.
Funktioniert prima, danke!
RMDIR: ./restoreDir/2014-09-23
UPD ./CHANGED
UPD FHEM/34_NUT.pm
UPD FHEM/42_SYSMON.pm
UPD FHEM/98_SVG.pm
UPD docs/commandref.html
UPD docs/commandref_DE.html
New entries in the CHANGED file:
- feature: SYSMON: improvement: support network information (IP, IPv6) on german linux
- feature: Synology DiskStation NAS basic spk file creation
- change: 34_NUT: readingFnAttributes added; creation of units deleted;
changed attr asReadings to use comma instead of space
update finished, "shutdown restart" is needed to activate the changes.
Fhem info:
Hallo,
ich habe seit einiger Zeit (den Zeitpunkt kann ich leider nicht genau sagen) den Effekt, das bei einem "Update" das Backup zweimal ausgeführt wird. Aber (leider) nur manchmal. Ein Problem wurde schon hier
http://forum.fhem.de/index.php/topic,26329.msg195132.html#msg195132 (http://forum.fhem.de/index.php/topic,26329.msg195132.html#msg195132)
beschrieben. Der Logeintrag dafür sieht folgendermaßen aus:
Zitat2014.12.17 17:02:40 2: Backup with command: tar -cf - /etc/fhem.cfg /var/log/fhem/fhem.save /usr/share/fhem/10_FRM.pm /usr/share/fhem/backupfhem.sh /usr/share/fhem/certs /usr/share/fhem/CHANGED /usr/share/fhem/configDB.pm /usr/share/fhem/contrib /usr/share/fhem/docs /usr/share/fhem/FHEM /usr/share/fhem/restoreDir /usr/share/fhem/unused /usr/share/fhem/www |gzip > /usr/share/fhem/backup/FHEM-20141217_170240.tar.gz
2014.12.17 17:03:32 1: backup tar: Removing leading `/' from member names
2014.12.17 17:03:32 1: backup done: FHEM-20141217_170240.tar.gz (6764067 Bytes)
2014.12.17 17:03:33 1: RMDIR: /usr/share/fhem/restoreDir/2014-12-12
2014.12.17 17:03:33 1: UPD ./CHANGED
2014.12.17 17:03:33 1: UPD ./fhem.pl
2014.12.17 17:03:34 1: UPD FHEM/00_THZ.pm
2014.12.17 17:03:34 1: UPD FHEM/01_FHEMWEB.pm
2014.12.17 17:03:34 1: UPD FHEM/02_RSS.pm
2014.12.17 17:03:34 1: UPD FHEM/10_OWServer.pm
2014.12.17 17:03:34 1: UPD FHEM/10_ZWave.pm
2014.12.17 17:03:34 1: UPD FHEM/23_LUXTRONIK2.pm
2014.12.17 17:03:35 1: UPD FHEM/30_HUEBridge.pm
2014.12.17 17:03:35 1: UPD FHEM/31_LightScene.pm
2014.12.17 17:03:35 1: UPD FHEM/33_readingsGroup.pm
2014.12.17 17:03:35 1: UPD FHEM/42_SMARTMON.pm
2014.12.17 17:03:35 1: UPD FHEM/59_PROPLANTA.pm
2014.12.17 17:03:35 1: UPD FHEM/70_ENIGMA2.pm
2014.12.17 17:03:35 1: UPD FHEM/70_JSONMETER.pm
2014.12.17 17:03:36 1: UPD FHEM/70_PHTV.pm
2014.12.17 17:03:36 1: UPD FHEM/70_PIONEERAVR.pm
2014.12.17 17:03:36 1: UPD FHEM/70_PushNotifier.pm
2014.12.17 17:03:36 1: UPD FHEM/72_FRITZBOX.pm
2014.12.17 17:03:36 1: UPD FHEM/91_eventTypes.pm
2014.12.17 17:03:36 1: UPD FHEM/98_HTTPMOD.pm
2014.12.17 17:03:37 1: UPD FHEM/98_HourCounter.pm
2014.12.17 17:03:37 1: UPD FHEM/98_cmdalias.pm
2014.12.17 17:03:37 1: UPD FHEM/98_statistics.pm
2014.12.17 17:03:37 1: UPD FHEM/TcpServerUtils.pm
2014.12.17 17:03:37 1: UPD docs/commandref.html
2014.12.17 17:03:39 1: UPD docs/commandref_DE.html
2014.12.17 17:03:40 1: UPD www/pgm2/fhemweb_readingsGroup.js
2014.12.17 17:03:40 1:
2014.12.17 17:03:40 1: New entries in the CHANGED file:
2014.12.17 17:03:40 1: - added: 42_SMARTMON: Frontend to smartctl (maintainer: hexenmeister)
2014.12.17 17:03:40 1: - feature: 70_PushNotifier added line break in Messages (xusader)
2014.12.17 17:03:40 1: - feature: readingsGroup: added valuePrefix and valueSuffix attributes
2014.12.17 17:03:40 1: added collapsed/collapsible to visibility attribute
2014.12.17 17:03:40 1: added visibility command
2014.12.17 17:03:40 1:
2014.12.17 17:03:40 1: update finished, "shutdown restart" is needed to activate the changes.
2014.12.17 17:03:40 1:
2014.12.17 17:03:40 1: Please consider using the global attribute sendStatistics
2014.12.17 17:03:52 2: Backup with command: tar -cf - /etc/fhem.cfg /var/log/fhem/fhem.save /usr/share/fhem/10_FRM.pm /usr/share/fhem/backupfhem.sh /usr/share/fhem/certs /usr/share/fhem/CHANGED /usr/share/fhem/configDB.pm /usr/share/fhem/contrib /usr/share/fhem/docs /usr/share/fhem/FHEM /usr/share/fhem/restoreDir /usr/share/fhem/unused /usr/share/fhem/www |gzip > /usr/share/fhem/backup/FHEM-20141217_170352.tar.gz
2014.12.17 17:04:47 1: backup tar: Removing leading `/' from member names
2014.12.17 17:04:47 1: backup done: FHEM-20141217_170352.tar.gz (7212562 Bytes)
2014.12.17 17:04:48 1: nothing to do...
in der fhem.cfg habe ich folgendes definiert:
attr global restoreDirs 3
attr global backup_before_updateIch habe schon einmal versucht mit "Verbose 5" mehr mitzuloggen, dann trat das Problem aber nicht auf. Wenn ich "Update" ein zweites Mal starte, wird Backup nur einmal ausgeführt. Ich weiß, wenig Infos um den Fehler zu finden. Ich versuche "Verbose 5" beim nächsten "Update" nochmals.
Viele Grüße
Achim
Hallo,
beim heutigen "Update" wurde das Backup wieder 2x ausgeführt. Die Logdatei mit "verbose 5" ist angehängt. Ich hoffe das sich damit die Ursache herausfinden lässt.
Viele Grüße
Achim
Ich habe den Anhang gekuerzt:
12:42:40 4: HTTP FHEMWEB:192.168.178.28:57118 GET /fhem&cmd=update
12:42:40 5: Cmd: >update<
12:42:40 5: Cmd: >backup<
....
12:43:44 4: 32104:FHEMWEB:192.168.178.28:57118: /fhem&cmd=update / RL:1976 ...
....
12:43:57 4: HTTP FHEMWEB:192.168.178.28:57320 GET /fhem&cmd=update
12:43:57 5: Cmd: >update<
12:43:57 5: Cmd: >backup<
....
12:44:56 1: nothing to do...
12:44:56 4: 32104:FHEMWEB:192.168.178.28:57320: /fhem&cmd=update / RL:1217 ...
Da sieht man, dass das erste update/backup um 12:42:40 per HTTP bestellt wurde, es laeuft bis 12:43:44, wo FHEMWEB dem Browser die Ergebnisse meldet. 13 Sekunden danach kommt vom Browser das update Befehl nochmal. Wenn das nicht manuell ausgeloest wurde, dann muesste man rausfinden, wie es dazu kam. Ich habe dafuer im Moment aber keine Erklaerung.
Vermutlich ist "attr global updateInBackground" ein akzeptabler Workaround.
Hallo,
wenn ich die doppelten Backups und Updates habe, kommt nach einiger Zeit der Ausführung dass das Frontend keine Verbindung mit dem FHEM mehr hat. Dann mache ich ein "F5" und FHEM wird wieder angezeigt. Wahrscheinlich wird da der Update-Befehl erneut ausgeführt. Die Anzeige dass das erste Update durchgeführt wurde, bekomme ich nicht. Nur das vom zweiten Update "nothing to do".
Bei nur wenigen neuen Updates habe ich den Effekt des doppelten Ausführens nicht. Ich teste das mit dem "UpdateinBackground". Muss eben nur warten, bis wieder eine größere Menge an Updates vorhanden sind. Ich will an meinem PROD System nicht so viel herumschrauben und mein TEST System ist gerade zum Mediacenter geworden. Kommt Zeit (und DHL) - kommt neuer RPi :)
Viele Grüße
Achim
Hallo,
bin mir nach dem Lesen hier jetzt nicht sicher, ob es Zweifel gibt, welche Funktion das Problem auslöst.
Bei mir passiert der doppelte Backup auch, wenn ich manuell "backup" mache - also auch ohne update.
Viele Grüße
Jürgen
Hallo Rudi,
das serverseitige Updateskript scheint im Ordner ./FHEM/ Dateien zu ignorieren, die nicht .pm Dateien sind.
Ich habe für eine einfache Verwendung durch Anwender ein für 02_RSS und 55_InfoPanel verwendbares Layout-Template eingecheckt. Diese Datei heißt "template.layout", analog zu den templates für gplot, die aber in einem anderen Verzeichnis liegen. Die template.layout zwar ist über SVN problemlos zu beziehen, aber 98_update.pm ignoriert diese Datei. Da diese Datei unter "Own modules and helper files" nur dann angezeigt wird, wenn sie in ./FHEM/ liegt, hilft das Abspeichern an eine andere Stelle nicht weiter.
Lässt sich das ohne großen Aufwand ändern?
Zitatdas serverseitige Updateskript scheint im Ordner ./FHEM/ Dateien zu ignorieren, die nicht .pm Dateien sind.
Das ist korrekt, allerdings kannst du das auch einfach ueberpruefen, es ist in contrib/fhemupdate.pl eingecheckt.
Was genau moechtest du denn aendern?
Ich hab das skript gesucht, aber nicht gefunden, danke für den Hinweis.
Was ich gerne hätte? Dass die Datei template.layout per Update mit ausgeliefert wird, also @filelist2 um ein Element erweitern:
"FHEM/.*.layout",
Habs eingebaut und fhemupdate.pl ausgefuehrt.
Danke schön.