Hallo Rudolf,
mir ist aufgefallen, dass das
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
FileLog device unnötigerweise über jedes event informiert wird, mit dem es jedoch nichts anfangen kann. Damit also sehr oft unnötig Rechenzeit verschwendet wird.
Mit dem angehängten Patch wird das auf 'global' events reduziert.
Ein reines default dummy device, welches gar keine events erzeugt, kenne ich nicht, sonst hätte ich das gewählt.
Wäre schön, wenn Du das übernehmen würdest, falls ich nicht eine wesentliche Funktion dieser notifies übersehen habe.
Gruß und Danke, Ansgar.
Ich habe zunehmend Probleme mit dem Hartkodieren von Namen. Ich bin selbst dabei nicht unschuldig, fuer diesen Fall testet FileLog.pm auf REGEXP eq "'fakelog'.
Besser waere meiner Ansicht nach den Regexp in fhem.cfg auf Logfile zu setzen, und die Tests in FileLog auf REGEXP eq NAME zu aendern. Das wird zwar nach einem update keinen direkten Vorteil bringen, ist aber auf Dauer mAn sauberer. Meinungen?
Hallo Rudolf,
Hinweis: Es gibt noch zwei weitere Abfragen auf $hash->{REGEXP} eq 'fakelog' in FileLog.
ZitatBesser waere meiner Ansicht nach den Regexp in fhem.cfg auf Logfile zu setzen, und die Tests in FileLog auf REGEXP eq NAME zu aendern. Das wird zwar nach einem update keinen direkten Vorteil bringen, ist aber auf Dauer mAn sauberer. Meinungen?
Persönlich habe ich damit keine Schmerzen.
Jeder muss dann seine config darauf anpassen. Es sei denn, Du baust eine automatische Kompatibilitätsübersetzung mit ein. Damit haben dann vielleicht andere Schmerzen.
Edit:
'Logfile' ist natürlich ebenso hartkodiert.
Generell so eine Abfrage auf REGEXP eq NAME zu nutzen sehe ich aber nicht. Selbstnotfizierender code mit zustandsabhängigen Abbruch, falls das gebraucht würde/wird, wäre damit dann problematisch.
Gruß, Ansgar.
Hallo Rudolf,
'global' events könnte man (mit noch unveränderter Prüfungslogik) auch noch so von Logfile fernhalten.
notifyRegexpChanged($hash, $hash->{REGEXP},
($hash->{NAME} eq 'Logfile' && $hash->{REGEXP} eq 'fakelog') ); #noansi: avoid Logfile fakelog to be notified by everything
Gruß, Ansgar.
Das ist mir bewusst, ist aber noch mehr hartkodiert.
Zu meinem erstaunen gibt es drei weitere Module, die mit fakelog herumspielen, wenn ich was aendern werde, muessen die Maintainer auch benachrichtigt werden.
Hallo Rudolf,
ZitatZu meinem erstaunen gibt es drei weitere Module, die mit fakelog herumspielen, wenn ich was aendern werde, muessen die Maintainer auch benachrichtigt werden.
... und auch fhem/www/frontend/www/frontend/app/ChartController.js schaut nach fakelog.
Gruß, Ansgar.
Ich schlage vor ein paar Tage Geduld zu haben, womoeglich hat noch einer der Betreoffennen was zu sagen.
Hallo Rudolf,
ZitatIch schlage vor ein paar Tage Geduld zu haben, womoeglich hat noch einer der Betreoffennen was zu sagen.
Sehe ich auch so.
Alle fakelog "Nutzer" wollen zumindest ein Log, in das sonst nichts via Events rein geschrieben wird, wenn ich es richtig interpretiere.
Sie würden somit auch von von dem ursprünglichen Ansinnen des notifies Sparen wollens profitieren.
Das fakelog entfernen bringt teilweise Probleme bezüglich Erkennung solcher Log devices, wie ich es verstehe.
Zitatist aber noch mehr hartkodiert.
Also wäre das der weniger hartkodierte Vorschlag.
notifyRegexpChanged($hash, $hash->{REGEXP}, ($hash->{REGEXP} eq 'fakelog') ); #noansi: avoid Logfile/fakelog to be notified by everything
und so in etwa, was Dir vorschwebt.
notifyRegexpChanged($hash, $hash->{REGEXP}, ($hash->{REGEXP} eq $hash->{NAME}) ); #no fakelog any more for all non regular log devices, but name eq regexp in future
Gruß, Ansgar.
Was ist denn das eigentliche "Problem" (außer der Verarbeitungszeit)?
Es gab vor nicht allzu langer Zeit schonmal eine Änderung bezüglich fakelog, die mir seinerzeit einiges durcheinandergebracht hat und die manuelle Änderungen an meinen FHEM Installationen erforderten.
Solche Änderungen an derartig grundlegenden Stellen von FHEM sollte man besser nur dann machen, wenn etwas nicht oder nicht mehr funktioniert. So eine Situation sehe ich aktuell aber nicht.
Aus rein "kosmetischen" Gründen. wie jetzt vorgeschlagen, halte ich das nicht für gerechtfertigt.
Hallo betateilchen,
ZitatWas ist denn das eigentliche "Problem" (außer der Verarbeitungszeit)?
Bezüglich der eigentlich gewünschten Änderung, Verarbeitungszeit unnütz durch das System schiessender Events bzw. deren unnütze Auswertung und Ablehnung durch die notifyFn (in diesem Fall jedes Event an jedes 'fakelog' FileLog device).
Für HM auf einem langsameren oder stark ausgelasteten System ist das auf jede Fall zu vermeiden, um kurze Antwortzeiten durch FHEM zu ermöglichen.
Ansonsten machen Event/notify Sparmaßnahmen FHEM agiler. Nicht umsonst wurde mal NOTIFYDEV/notifyhash eingebaut.
ZitatAus rein "kosmetischen" Gründen.
'fakelog' hartkodiert ist Rudolf dabei aufgefallen/aufgestoßen (nebst der Zusatzabfrage auf das ebenfalls hartkodierte 'Filelog').
'fakelog' war allerdings auch schon hartkodiert im Modul drin, die Abfrage macht es also nicht schlimmer, als es derzeit schon ist.
ZitatEs gab vor nicht allzu langer Zeit schonmal eine Änderung bezüglich fakelog,
Worum ging es da?
Gruß, Ansgar.
Wenn man alle in den vergangenen drei Jahren mit heißer Nadel zusammengestrickten und offiziell eingecheckten "Module" einem grundsätzlichen Code review unterziehen würde, wäre der Performancegewinn sicherlich sehr viel höher als der jetzt hier in FileLog angedachte. Einiges, was da veröffentlicht wurde, sieht intern echt gruslig aus.
Zitat von: noansi am 07 August 2021, 12:06:18
Worum ging es da?
Da ging es um eine Änderung mit der Folge, dass plötzlich und ohne Vorwarnung im Frontend die set-Befehle nicht mehr vorhanden waren.
Hallo Zusammen,
um die 'faklog' nutzenden Module/Dateien mal zu nennen, weil es möglicherweise nicht mehr in Erinnerung ist:
00_SIGNALduino.pm
39_gassistant.pm
39_alexa.pm
ChartController.js
Gruß, Ansgar.
Zitat von: noansi am 13 August 2021, 21:21:28
um die 'faklog' nutzenden Module/Dateien mal zu nennen, weil es möglicherweise nicht mehr in Erinnerung ist:
39_alexa.pm
Explizit wegen dieses Moduls kam es Anfang 2019 zu der von mir im vorherigen Beitrag genannten früheren Änderung.
https://forum.fhem.de/index.php/topic,95351.0.html
(um auch das nochmal in Erinnerung zu rufen)
Ich habe in fhem.cfg in der Logfile Zeile fakelog nach Logfile geaendert.
In FileLog.pm wird zusaetzlich zu fakelog auch nach REGEXP eq NAME geprueft.
Fuer betateilchen (#95351 (https://forum.fhem.de/index.php/topic,95351.0.html)) wird jetzt in diesem Fall bei set das clear Befehl zugelassen.
Bei Gelegenheit sollten die Maintainer folgender Dateien ueberlegen, ob man fakelog nicht loswerden koennte:
configDB.pm
FHEM/00_SIGNALduino.pm
FHEM/39_alexa.pm
FHEM/39_gassistant.pm
für alexa und gassistant: wie damals schon gesagt: im prinzip ja, allerdings wird dann einiger code kopiert und ist dann mindestens drei mal da. das möchte ich wirklich vermeiden.
wenn ich zurück bin überlege ich mal ob man denn vorhandenen code besser mehrfach nutzen kann.
auf die schnelle fäll mir statt implizit über den namen zu gehen ein explizites und dokumentiertes attribut displayOnly oder .displayOnly ein. das könnte man setzen um den gewünschten effekt zu erhalten.
Bei der 00_SIGNALduino.pm wird das fakelog nur dazu verwendet um im "Information menu" über eine url das "Last Flashlog" auszugeben, gibts dafür eine andere Möglichkeit?
sub SIGNALduino_FW_Detail($@) {
my ($FW_wname, $name, $room, $pageHash) = @_;
my $hash = $defs{$name};
my @dspec=devspec2array("DEF=.*fakelog");
my $lfn = $dspec[0];
my $fn=$defs{$name}->{TYPE}."-Flash.log";
my $ret = "<div class='makeTable wide'><span>Information menu</span>
<table class='block wide' id='SIGNALduinoInfoMenue' nm='$hash->{NAME}' class='block wide'>
<tr class='even'>";
if (-s AttrVal('global', 'logdir', './log/') .$fn)
{
my $flashlogurl="$FW_ME/FileLog_logWrapper?dev=$lfn&type=text&file=$fn";
$ret .= "<td>";
$ret .= "<a href=\"$flashlogurl\">Last Flashlog<\/a>";
$ret .= "</td>";
}
...
Gruß Ralf
ZitatBei der 00_SIGNALduino.pm wird das fakelog nur dazu verwendet um im "Information menu" über eine url das "Last Flashlog" auszugeben, gibts dafür eine andere Möglichkeit?
Klar, selbst programmieren :)
ZitatKlar, selbst programmieren
hab ich nun auch gemacht, das Dialogfenster hab ich vom fhemweb abgeschaut.
sub SIGNALduino_FW_Detail {
...
if (-s AttrVal("global", "logdir", "./log/") .$fn)
{
$ret.="<td><a href='#showLastFlashlog' id='showLastFlashlog'>Last Flashlog</a></td>";
#$ret .= "<a href=\"$flashlogurl\">Last Flashlog<\/a>";
}
...
<script>
$( "#showLastFlashlog" ).click(function(e) {
e.preventDefault();
FW_cmd(FW_root+\'?cmd={SIGNALduino_FW_getLastFlashlog("'.$FW_detail.'")}&XHR=1\', function(data){SD_dispLastFlashlog(data)});
});
...
function SD_dispLastFlashlog(txt)
{
var div = $("<div id=\"SD_LastFlashlog\">");
$(div).html(txt);
$("body").append(div);
$(div).dialog({
dialogClass:"no-close", modal:true, width:"auto", closeOnEscape:true,
maxWidth:$(window).width()*0.9, maxHeight:$(window).height()*0.9,
title: "last Flashlog",
buttons: [
{text:"close", click:function(){
$(this).dialog("close");
$(div).remove();
}}]
});
}sub SIGNALduino_FW_getLastFlashlog
{
my $name = shift;
my $filename = AttrVal("global", "logdir", "./log/") . "$defs{$name}->{TYPE}-Flash.log";
my $ret;
my $openflag = 1;
open my $fh, "<", $filename or $openflag = 0;
if ($openflag) {
$ret = do { local $/; <$fh> };
#$ret = FW_htmlEscape($ret);
$ret = "<pre>$ret</pre>";
$ret =~ s/\n/<br>/g;
Log3 $name, 4, "getLastFlashlog: filename=$filename";
close $fh;
}
else {
$ret = "$filename not found";
}
return $ret;
}Zu was wird dies benötigt?
$ret = "<pre>$ret</pre>";Gruß Ralf
die idee war ja den code wieder zu verwenden statt zu duplizieren. das ganze am ende 4 oder 5 mal zu haben ist nicht wirklich elegant ...