FHEM Forum

Hallo,


bei
attr global exclude_from_update 98_HTTPMOD.pm
wird mir schön diese meldung angezeigt.
update: skipping FHEM/98_HTTPMOD.pm, matches exclude_from_update

bei
attr global exclude_from_update 10_KNX.pm
nicht.
Hier wird lediglich

UPD FHEM/10_EnOcean.pm
UPD FHEM/10_KNX.pm
UPD FHEM/10_MYSENSORS_DEVICE.pm
beim fehlen des Attributes angezeigt, oder eben nichts,
UPD FHEM/10_EnOcean.pm
UPD FHEM/10_MYSENSORS_DEVICE.pm

wenn es gesetzt ist.

Ersteres finde ich natürlich schöner!
Die Ursache konnte ich im Code leider nicht ausmachen!

sG
Joe

Es gibt in update.pm keine Sonderbehandlung von KNX.pm (oder sonst einem Modul). Die Meldung wird ausgegeben, falls man nicht eine einzelne Datei angegeben hat, der regexp matcht, und Laenge/Zeitstempel der lokalen Datei nicht mit dem auf dem Server uebereinstimmt.
Bevor ich eine halbe Stunde mit dem Nachstellen verbringe: bist du _ganz_ sicher, dass deine Angaben alle so richtig sind?

Und bist Du ganz sicher, dass Du zwischen dem Verändern/Setzen/Löschen des Attributes jeweils Dein FHEM neu gestartet hattest?

Zitat von: rudolfkoenig am 25 Juni 2018, 11:00:06
bist du _ganz_ sicher, dass deine Angaben alle so richtig sind?

Ja. Anbei weitere Details!!

Zitat von: rudolfkoenig am 25 Juni 2018, 11:00:06
... Die Meldung wird ausgegeben, falls man nicht eine einzelne Datei angegeben hat,...

auch bei nur einer Datei hatte ich die Meldung erhalten.
nachdem ich nun ein Teilupdate gemacht habe (ich wollte für euch die Anzahl der Ergebnisse reduzieren), bekomme ich die Meldung gar nicht mehr angezeigt.
Auch nicht mit mehreren Dateien angegeben.

anbei die Tests:
fhem> fhem> deleteattr global exclude_from_update
fhem> update check

fhem
List of new / modified files since last update:
UPD FHEM/10_EnOcean.pm
UPD FHEM/10_KNX.pm
UPD FHEM/10_MYSENSORS_DEVICE.pm
UPD FHEM/98_HTTPMOD.pm


=>> Erwartetes Ergebnis!

fhem> attr global exclude_from_update 10_KNX.pm 98_HTTPMOD.pm
fhem> update check

fhem
List of new / modified files since last update:
UPD FHEM/10_EnOcean.pm
UPD FHEM/10_MYSENSORS_DEVICE.pm

=>> jetzt hätte ich mir die "skipping" Nachricht erwartet!

fhem> attr global exclude_from_update .*
fhem> update check

fhem
nothing to do...

=>> Erwartetes Ergebnis (nach der obrigen Aussage von Rudi), wobei der "skipping"-Hinweis natürlich schöner wäre!

Auch die Größe und das Datum einer Datei scheinen keinen Einfluss zu haben:
rm 98_HTTPMOD.pm
touch -d 20180101  98_HTTPMOD.pm

mit dem Ergebnis:
attr global exclude_from_update 10_KNX.pm 98_HTTPMOD.pm
fhem> update check

fhem
List of new / modified files since last update:
UPD FHEM/10_EnOcean.pm
UPD FHEM/10_MYSENSORS_DEVICE.pm
=>> jetzt hätte ich mir die "skipping" Nachricht erwartet! da 2 dateien angegeben waren und das Datum sowie die Dateilänge von 98_HTTPMOD.pm definitiv nicht mehr übereinstimmten.

Zitat von: betateilchen am 25 Juni 2018, 11:02:38
Und bist Du ganz sicher, dass Du zwischen dem Verändern/Setzen/Löschen des Attributes jeweils Dein FHEM neu gestartet hattest?

Nein habe ich nicht! Seit wann muss man das für ein verändertes Attribut?

Hier der test extra für diese Vermutung:
fhem> attr global exclude_from_update 10_KNX.pm 98_HTTPMOD.pm
fhem> save
Wrote configuration to fhem.cfg
fhem> shutdown restart
root@fhem:~# telnet XXX

fhem> update check

fhem
List of new / modified files since last update:
UPD FHEM/10_EnOcean.pm
UPD FHEM/10_MYSENSORS_DEVICE.pm




Zurück ohne dieses Attribut:
fhem> deleteattr global exclude_from_update
fhem> update check

fhem
List of new / modified files since last update:
UPD FHEM/10_EnOcean.pm
UPD FHEM/10_KNX.pm
UPD FHEM/10_MYSENSORS_DEVICE.pm
UPD FHEM/98_HTTPMOD.pm


=> Fazit: Mir kommt die Funktion leider immer noch inkonsistent vor.

sG Joe

Ich habe auf einem testsystem ein update durchgefuehrt, dann in FHEM/controls_fhem.txt fuer die vier gezeigten Dateien die Zeitstempel geaendert, und dann:

% telnet localhost 7072

fhem> attr global exclude_from_update 10_KNX.pm 98_HTTPMOD.pm
fhem> save
Wrote configuration to fhem.cfg
fhem> update check

fhem
List of new / modified files since last update:
UPD ./fhem.pl
UPD FHEM/10_EnOcean.pm
update: skipping FHEM/10_KNX.pm, matches exclude_from_update
UPD FHEM/10_MYSENSORS_DEVICE.pm
update: skipping FHEM/98_HTTPMOD.pm, matches exclude_from_update
UPD FHEM/HttpUtils.pm

fhem> deleteattr global exclude_from_update
fhem> update check

fhem
List of new / modified files since last update:
UPD ./fhem.pl
UPD FHEM/10_EnOcean.pm
UPD FHEM/10_KNX.pm
UPD FHEM/10_MYSENSORS_DEVICE.pm
UPD FHEM/98_HTTPMOD.pm
UPD FHEM/HttpUtils.pm


Evtl. wichtig fuers Verstaendnis:
- Es wird Zeitstempel/Groesse aus der lokalen controls_fhem.txt mit der aus https://fhem.de/fhemupdate/controls_fhem.txt verglichen, und beim Unterschied und Eintrag in exclude_from_update die "skipped" Meldung ausgegeben
- danach wird auch die "wirkliche" Dateigroesse verglichen, es sei denn, updateNoFileCheck ist gesetzt oder configDb wird verwendet. Falls die Groesse nicht passt (und excludeFromUpdate nicht zutrifft), dann wird die Datei auch dann heruntergeladen, falls die Daten in der lokalen controls.txt passen.

Zusammengefasst: Falls exclude_from_update gesetzt ist, dann gibt es die Meldung nicht bei jedem update, sondern jeweils nur dann, wenn die Remote-Version sich geaendert hat.

Hallo Rudi,

danke für die Erläuterung. Das erklärt es.
Bei HTTPMOD hat sich die Remote-Version geändert, bei KNX nicht.
Verzeih, wenn ich das dennoch etwas "inkonsistent" empfinde, da mir immer bekannt sein müsste, welche Version sich remote gerade geändert hat.
Aber vermutlich ist das nicht wichtig, vorallem da es nur auftritt, wenn jemand lokal eine Datei manuell verändert/austauscht, sich also an der Entwicklung beteiligt.... :D


DANKE, und entschuldige bitte die entstandene Mühe.

sG
Joe.

Zitat von: JoeALLb am 25 Juni 2018, 11:48:31
Nein habe ich nicht! Seit wann muss man das für ein verändertes Attribut?

Naja, es war nur eine Idee, da es sich bei 98_update.pm nicht um ein Modul handelt, das devices erzeugt, sondern einen Befehl bereitstellt und das deshalb auch gar nicht selbst Attribute besitzt. Da kann es schon vorkommen, dass Variablen beim erstmaligen Laden des Moduls (erste Ausführung eines Befehls) initialisiert werden und dann die vorhandenen Werte eventuell bei einer zweiten Ausführung immer noch vorhanden sind.

Aber Rudi hat ja die tatsächliche Ursache bereits aufgeklärt.