es wäre ein schönes feature wenn WeekdayTimer die {} variante zum bestimmen der schaltzeit für jeden in frage kommenden wochentag getrennt aufrufen und dabei datum und wochentag als variablen zur verfügung stellen würde.
- dann würde z.b. ein Lampe Mo-Fr|{sunrise_abs("HORIZON=10")}|on Sa,So{sunrise_abs("HORIZON=20")}|on {sunset_abs("REAL")}|offin den internals die richtigen schaltzeiten im voraus anzeigen.
- die {} perl funktion könnte z.b. auch auf einen kalender zugreifen und die schaltzeiten davon abhängig machen. wieder mit korrekter anzeige in den internals für alle 7 tage.
- wenn man undef als rückgabe wert erlaubt könnte man eine schaltzeit unterdrücken und z.b. auf ferien oder schichtpläne reagieren
gruss
andre
sunset_abs müsste natürlich erweitert werden so das man das datum übergeben kann.
Ich lasse mir den Vorschlag mal durch den Kopf gehen.
Das größte Problem wird darin bestehen sunset/sunrise zu erweitern. Es ist ziemlich fest an das Tagesdatum gekoppelt. Man könnte eventuell zusätzliche Funktionen sunrise($datum ...) ergänzen.
so?
Ich dachte erst es könnte recht kompliziert werden. War es aber nicht.
Dem Modul 99_SUNRISE_EL habe ich zwei neue Funktionen spendiert, die zusätzlich als ersten Parameter ein Tagesdatum im Format epoch vertragen. Das Modul konnte ich abwärtskompatibel erweitern.
sub sunrise_abs_dat(@)
sub sunset_abs_dat (@)
werden so aufgerufen:
sunset_abs_dat($date, ...) ... wie sunset_abs
$date muss im Format epoch (liefert time()) mitgegeben werden.
Die Definition von WD sieht dann so aus:
define hc5 WeekdayTimer Brunnen de so-sa|{sunrise_abs_dat($date)}|on so-sa|{sunset_abs_dat($date)}|off;
Die Funktionen zur Ermittlung der Schaltzeiten kennen standardmäßig die Variable $date (epoch).
genau so.
mir gefällt es sehr gut.
gruß
andre
Meinen Teil kann ich ja leicht selbst einchecken.
Für das Modul sunrise ist ja Rudi zuständig. Wie können wir ihn überzeugen die Änderung zu übernehmen?
Ich habe noch eine weitere Neuerung in der Schublade. Leider habe ich noch kein Schreibrecht auf Development - zwar beantragt, aber wie das so in einer Bürokratie ist, noch nicht genehmigt.
Ich habe folgendes gebaut. Warnungen erzeugen einen kompletten stacktrace:
2014.10.02 19:39:45 3: --- Ende stack trace ---
2014.10.02 19:39:45 3: (-10)main::CallFn called by fhem.pl(524)
2014.10.02 19:39:45 3: (-9)main::FW_Read called by fhem.pl(2655)
2014.10.02 19:39:45 3: (-8)main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm(357)
2014.10.02 19:39:45 3: (-7)main::FW_fC called by ./FHEM/01_FHEMWEB.pm(521)
2014.10.02 19:39:45 3: (-6)main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm(1728)
2014.10.02 19:39:45 3: (-5)main::CommandModify called by fhem.pl(871)
2014.10.02 19:39:45 3: (-4)main::CallFn called by fhem.pl(1479)
2014.10.02 19:39:45 3: (-3)main::WeekdayTimer_Define called by fhem.pl(2655)
2014.10.02 19:39:45 3: (-2)main::Heating_Control_Define called by ./FHEM/98_WeekdayTimer.pm(75)
2014.10.02 19:39:45 3: (-1)main::Heating_Control_ParseSwitchingProfile called by ./FHEM/98_Heating_Control.pm(170)
2014.10.02 19:39:45 3: (+0)main::__ANON__ called by ./FHEM/98_Heating_Control.pm(299)
2014.10.02 19:39:45 3: --- Begin stack trace ---
2014.10.02 19:39:45 3: === End of Warnig ===
2014.10.02 19:39:45 3: Use of uninitialized value $timeString in pattern match (m//) at ./FHEM/98_Heating_Control.pm line 299.
2014.10.02 19:39:45 3: === Begin of Warnig ===
Es ist möglich die Ausgabe ins FHEM-Log zu lenken und timestamps zu ergänzen.
Das Beste wäre die Erweiterung ins fhem.pl zu integrieren. In Development würde ich das gern diskutieren, aber ohne Schreibrecht kann ich das nicht zur Verfügung stellen.
ich hab im developer bereich eben einen hinweis auf beide erweiterungen hier gepostet.
das mit dem stacktrace gefällt mir auch.
gruss
andre
@Dietmar63: kannst du dein Patch fuer sunrise_el hier posten? Oder habe ich es uebersehen?
Ich passe die Dokumentation auch gleich mit an, dann ist es vollständig.
Was hälst du von der Möglichkeit bei Warnungen/Fehler im log immer einen stacktrace generieren zu können?
Insbesondere wenn unartige Module falsche Parameter an localtime() liefern, kann man dann wenigstens den Verursacher und den Zeitpunkt des Fehlers besser ermitteln.
Die Warnungen lassen sich so auch ins fhem.log umlenken. Das hat den Vorteil, dass man nicht von der Console starten muss, um die die Fehlermeldung zu Gesicht zu bekommen, die dann sowieso nicht mehr kommen:
Zur Zeit habe ich es in die 99-utis eingebaut:
########################################################################
sub stacktrace() {
my $i = 1;
my $max_depth = 50;
Log 3, "--- Begin stack trace ---";
while ( (my @call_details = (caller($i++))) && ($i<$max_depth) ) {
my $txt = sprintf ("(%+02d)%-35s called by ", 2-$i, $call_details[3], );
Log 3, $txt . $call_details[1] . "(" . $call_details[2] . ")" ;
}
Log 3, "--- Ende stack trace ---";
}
########################################################################
$SIG{__WARN__} = sub {
my($message) = @_;
my $reg = '(redefined)';
my($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time);
my $ts = sprintf ("%04d-%02d-%02d_%02d:%02d:%02d",$year+1900,$mon+1,$mday,$hour,$min,$sec);
print STDERR "<<<<<<<<<<<<<< " . $ts . " " . $message;
if ($message=~/$reg/g ) {
;
} else {
Log 3, "=== Begin of Warnig ===";
Log 3, $message;
Log 3, "=== End of Warnig ===";
stacktrace();
}
};
Über das genaue Wie kann man sich immer noch unterhalten. Gut wäre wenn man über die fhem.cfg steuern könnte.
Vorstellbar wären Modi mit vollständigem stacktrace oder aber nur das Umlenken der Warnungen ins LOG.
Insbesondere Anfänger sollten davon sehr profitieren.
ZitatIch passe die Dokumentation auch gleich mit an, dann ist es vollständig.
Ok.
ZitatWas hälst du von der Möglichkeit bei Warnungen/Fehler im log immer einen stacktrace generieren zu können?
Gerne, ich schlage vor, dass der Stacktrace an "global verbose 5" (== debugging) geknuepft ist.
Warnungen sollten immer ins Log umgelenkt werden. Die Einbindung in fhem.pl kann ich uebernehmen, falls kein Veto kommt.
Warnungen kommen doch so selten, dass man es auch an "global verbose 3" binden kann.
Achtung:
wenn du es einfach so einbaust verändert du auch die Ausgabe der Warnungen, die sonst sämtlich ins normal Log laufen. Das wäre für die Fehlersuche nicht gut.
Mit der Funktion wird der Standardhandler für Warnungen von Perl durch diese Routine ersetzt, und keine Warnung mehr ins normale Perllog ausgegeben. Das habe ich durch die Zeile:
print STDERR "<<<<<<<<<<<<<< " . $ts . " " . $message;
dann wieder selbst übernommen.
Man muss also differnziert vorgehen:
immer
print STDERR "<<<<<<<<<<<<<< " . $ts . " " . $message;
ausführen.
Eventuell immer die Warnung auch ins fhem.log schreiben:
Log 3, $message;
und auf Wunsch (global verbose 3 oder so ...) den stacktrace zuschalten.
Das eigentliche Problem habe ich selbst nach mehrmaligen Lesen nicht verstanden.
Wieso ist es ein Problem, wenn Warnungen nur in fhem-log auftauchen?
Ich wuerde Warnunngen ohne Stacktrace immer (Log 0) protokollieren, mit stacktrace ab verbose 5. Der auch bisher sichtbare Warnungstext hat in den meisten Faellen ausgereicht. Wenn man es nicht zuordnen kann, dann kann man demnaechst verbose hochdrehen, um einen zusaetzlichen Stacktrace zu bekommen.
manchmal findet man im Perl-Error Log folgende Fehlermeldungen:
Zitat
Argument "\x{4e}\x{6f}..." isn't numeric in localtime at fhem.pl line 2394.
Argument "\x{4e}\x{6f}..." isn't numeric in localtime at fhem.pl line 2394.
syswrite() on closed filehandle GEN26263 at fhem.pl line 536.
Use of uninitialized value $1 in numeric lt (<) at (eval 5164) line 1.
Use of uninitialized value $1 in concatenation (.) or string at (eval 5164) line 1.
Use of uninitialized value $code in concatenation (.) or string at FHEM/HttpUtils.pm line 150.
Use of uninitialized value $code in numeric eq (==) at FHEM/HttpUtils.pm line 153.
Use of uninitialized value $code in numeric eq (==) at FHEM/HttpUtils.pm line 153.
Use of uninitialized value $code in numeric eq (==) at FHEM/HttpUtils.pm line 153.
Mit diesen Meldungstexten kann man leider nicht auf die wirkliche Ursache und den Zeitpunkt schließen, wann der Fehler in welchem Zusammenhang auftrat.
Mit einen stacktrace() wie in Java kann man den Verusacher einfacher einkreisen.
Bei den obigen Beispielen wäre es hilfreich zu wissen wer jeweils die Fuktion unter fhem.pl line 2394 bzw. HttpUtils.pm 153 aufgerufen hat. Ein stacktrace() wäre da sehr hilfreich.
Weiteres (konstruiertes) Beispiel:
ohne stacktrace() bekommst du nur ins perl.log geschrieben:
ZitatArgument "asdfghjklM-vM-d" isn't numeric in localtime at fhem.pl line 2394
mit stacktrace() bekommst du wahlweise auch ins fhem.log:
HeizungKueche.log HeizungWohnen.log perfTop.log Wetterdaten.log hcs.log fhem20140924-221505.log
2014.10.03 15:52:49 3: --- Ende stack trace ---
2014.10.03 15:52:49 3: (-10)main::CallFn called by fhem.pl(524)
2014.10.03 15:52:49 3: (-9)main::FW_Read called by fhem.pl(2655)
2014.10.03 15:52:49 3: (-8)main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm(357)
2014.10.03 15:52:49 3: (-7)main::FW_fC called by ./FHEM/01_FHEMWEB.pm(521)
2014.10.03 15:52:49 3: (-6)main::AnalyzeCommandChain called by ./FHEM/01_FHEMWEB.pm(1731)
2014.10.03 15:52:49 3: (-5)main::AnalyzeCommand called by fhem.pl(759)
2014.10.03 15:52:49 3: (-4)main::AnalyzePerlCommand called by fhem.pl(819)
2014.10.03 15:52:49 3: (-3)(eval) called by fhem.pl(803)
2014.10.03 15:52:49 3: (-2)main::dayCare called by (eval 138)(1)
2014.10.03 15:52:49 3: (-1)main::FmtDateTime called by ./FHEM/99_Utils_Ort.pm(140)
2014.10.03 15:52:49 3: (+0)main::__ANON__ called by fhem.pl(2394)
2014.10.03 15:52:49 3: --- Begin stack trace ---
2014.10.03 15:52:49 3: === End of Warnig ===
2014.10.03 15:52:49 3: Argument "asdfghjklM-vM-d" isn't numeric in localtime at fhem.pl line 2394.
2014.10.03 15:52:49 3: === Begin of Warnig ===
Bei der zweiten Version weißt du wann das Problem auftrat und kannst im stacktrace sehen, dass FmtDateTime() von dayCare() aufgerufen wurde. Achtung: ich nutze eine alte Version von fhem.pl, führe selten Updates aus.
Ich bin doch nicht gegen dem stacktrace, ich will es aber nur beim Bedarf einschalten, um die Leute nicht zu verwirren.
Das habe ich auch nicht so empfunden.
Ich habe es nur noch mal deutlich machen wollen, wie die Funktionalität hilfreich sein kann.
Bei mir läuft es rund um die Uhr mit und stört praktisch nicht.
Ich bin der Meinung, dass wenn man es separat erst einschalten muss, um davon zu profitieren, es nicht wirklich wertvoll ist. Binde es vielleicht erst einmal bei dir ein und warte ab, wann du den Nutzen daraus ziehst. Danach kannst du entscheiden, ob es stört, wenn man es rund um die Uhr mitlaufen lässt.
Jeder hier kann sich den Code selbst in die 99_Utils.pm einbauen.
Hier der versprochene Patch für 99_SUNRISE_EL.
Zwei neue Funktionen abwärtskompatibel ergänzt:
sunrise_abs_dat()/sunset_abs_dat() return the absolute time of the corresponding event to a given date(no 24 hours added).
sub sunrise_abs_dat(@)
sub sunset_abs_dat (@)
# to calculate the sunrise of today + 7 days
my $date = time() + 7*86400;
sunrise_abs_dat($date);
# to calculate the sunrise of today + 7 days 6 degrees below horizon
my $date = time() + 7*86400;
sunrise_abs_dat($date, "CIVIL");
Habe dein SUNRISE_EL Patch eingecheckt.
Stacktrace ist auch drin ab verbose 3, ich habe die Formatierung etwas vereinfacht, und einen primitiven Schutz gegen Rekursion eingebaut.
Sehr schön - Danke!
Hallo Rudi,
sieht erst einmal so ganz gut aus!
Dir ist klar, dass du durch die Herausnahme folgender Zeile kein Hinweis mehr ins normale PerlErrorLog läuft. Das könnte für den Einen oder Anderen etwas gewöhnungnsbedürftig sein. Ich persönlich finde es gut.
print STDERR "<<<<<<<<<<<<<< " . $ts . " " . $message;
@Rudi:
habe noch ein kleines Problem gefunden:
ein reload auf eine Funktion erzeugt eine Menge Hinweise auf redefinierte Funktionen. Der stacktrace bleibt aus weil er über einen regex ausgesteuert wird.
2014.10.05 20:38:50 1: PERL WARNING: Subroutine morgens redefined at ./FHEM/99_Utils_Ort.pm line 40.
2014.10.05 20:38:50 1: PERL WARNING: Subroutine DeviceOnForTimer redefined at ./FHEM/99_Utils_Ort.pm line 35.
2014.10.05 20:38:50 1: PERL WARNING: Subroutine DeviceOnForTimer_Dummy redefined at ./FHEM/99_Utils_Ort.pm line 30.
2014.10.05 20:38:50 1: PERL WARNING: Subroutine tagesdatum redefined at ./FHEM/99_Utils_Ort.pm line 25.
2014.10.05 20:38:50 1: PERL WARNING: Subroutine timeStamp redefined at ./FHEM/99_Utils_Ort.pm line 19.
2014.10.05 20:38:50 1: PERL WARNING: Subroutine Utils_Ort_Initialize redefined at ./FHEM/99_Utils_Ort.pm line 14.
Und was genau ist das Problem?
In meiner Version hatte ich diese Meldungen komplett unterdrückt.
Mal sehen was die Allgemeinheit dazu sagt.
Ähm ist zwar OT, aber wie kann ich nun vorgehen wenn ich so eine Meldung im log finde?
PERL WARNING: Use of uninitialized value $args[2] in concatenation (.) or string at ./FHEM/98_weblink.pm line 120.
2014.10.06 21:20:44.292 3: stacktrace:
2014.10.06 21:20:44.293 3: main::__ANON__ called by ./FHEM/98_weblink.pm (120)
2014.10.06 21:20:44.294 3: main::weblink_FwFn called by ./FHEM/01_FHEMWEB.pm (2344)
2014.10.06 21:20:44.295 3: main::FW_devState called by ./FHEM/95_Dashboard.pm (633)
2014.10.06 21:20:44.295 3: main::BuildGroup called by ./FHEM/95_Dashboard.pm (567)
2014.10.06 21:20:44.296 3: main::BuildGroupWidgets called by ./FHEM/95_Dashboard.pm (520)
2014.10.06 21:20:44.297 3: main::BuildDashboardCenterRow called by ./FHEM/95_Dashboard.pm (474)
2014.10.06 21:20:44.298 3: main::Dashboard_SummaryFN called by ./FHEM/95_Dashboard.pm (312)
2014.10.06 21:20:44.299 3: main::DashboardAsHtml called by (eval 967) (1)
2014.10.06 21:20:44.300 3: (eval) called by fhem.pl (894)
2014.10.06 21:20:44.300 3: main::AnalyzePerlCommand called by ./FHEM/98_weblink.pm (95)
2014.10.06 21:20:44.301 3: main::weblink_FwFn called by ./FHEM/01_FHEMWEB.pm (1369)
2014.10.06 21:20:44.302 3: main::FW_showRoom called by ./FHEM/01_FHEMWEB.pm (736)
2014.10.06 21:20:44.303 3: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (393)
2014.10.06 21:20:44.304 3: main::FW_Read called by fhem.pl (2902)
2014.10.06 21:20:44.305 3: main::CallFn called by fhem.pl (594)
Vermutlich hat ein weblink der Sorte cmdList ein Argument mit weniger als 2x :
Dazu wird aber der stacktrace nicht benoetigt, das sieht man auch sonst.
Bisher wäre den meisten Nutzern von fhem das Problem verborgen geblieben, weil die FM nur ins PerlErrorLog geschrieben wurde. Und zwar so:
ZitatUse of uninitialized value $args[2] in concatenation (.) or string at ./FHEM/98_weblink.pm line 120.
Im staktrace() kannst du nun aber sehen, dass das Problem irgendwie mit dem Aufbau des Dashboard zu tun hat: Viele Funktionen in Dashboard rufen sich nacheinander auf, um die Darstellung zu realisieren. Ganz am Anfang steht DashboardAsHtml() ganz zuletzt BuildGroup() ...
Wenn du dem Entwickler von Dashboard diesen stacktrace() zur Verfügung stellst, wird er das Problem vermutlich leicht lösen können.
Zitat von: rudolfkoenig am 06 Oktober 2014, 22:50:04
Vermutlich hat ein weblink der Sorte cmdList ein Argument mit weniger als 2x :
Dazu wird aber der stacktrace nicht benoetigt, das sieht man auch sonst.
Danke Rudolf, das war es!
PS: Ich finde den Stacktrace cool! Werde mich mal mehr mit perl beschäftigen! Danke fuer die Funktion!
Hallo,
Zitat von: Dietmar63 am 06 Oktober 2014, 20:28:19
In meiner Version hatte ich diese Meldungen komplett unterdrückt.
Mal sehen was die Allgemeinheit dazu sagt.
Geht schon los ;)
http://forum.fhem.de/index.php/topic,27662.msg205802.html#msg205802 (http://forum.fhem.de/index.php/topic,27662.msg205802.html#msg205802)
Grüße
Dann bekommen wir die Fehler endlich mal behoben
@Rudi:
Hier hatte ich dir einen Patch für 99_SUNRISE_EL.pm zukommen lassen.
http://forum.fhem.de/index.php/topic,27471.msg205160.html#msg205160 (http://forum.fhem.de/index.php/topic,27471.msg205160.html#msg205160)
Leider muss ich noch eine Verbesserung nachliefern.
Es hat sich herausgestellt, dass bei den neuen Funktionen die Berechnung nach einem abgelaufenen ss oder sr nicht auf den nächsten Tag verschoben werden darf. Die Doku bleibt gleich, weil sich an den Schnittstellen nichts geändert hat.
Die neuen Funktionen habe ich auf Sommer-/Winterzeit-Festigkeit geprüft:
2014.10.14 19:16:25 3: sunrise of 2014-10-28 18:16:25->06:32:06
2014.10.14 19:16:25 3: sunrise of 2014-10-27 18:16:25->06:30:23
2014.10.14 19:16:25 3: sunrise of 2014-10-26 18:16:25->06:28:40
2014.10.14 19:16:25 3: sunrise of 2014-10-25 19:16:25->07:26:57
2014.10.14 19:16:25 3: sunrise of 2014-10-24 19:16:25->07:25:14
Bitte bei Gelegenheit einchecken.
Eingecheckt
@Dietmar63: hast du schon eine idee wann du die zugehörigen WeekdayTimer änderungen eincheckst?
gruss
andre
Ich muss nur noch die Dokumentation anpassen - heute komme ich leider nicht mehr dazu
kein problem.
gruss
andre
funktioniert perfekt und wie beabsichtigt.
und mit den _abs_dat funktionen lässt sich der sonnen auf und untergang jetzt netter nebeneffekt auch direkt plotten: http://forum.fhem.de/index.php/topic,23912.msg217310.html#msg217310 (http://forum.fhem.de/index.php/topic,23912.msg217310.html#msg217310)
(http://forum.fhem.de/index.php?action=dlattach;topic=26529.0;attach=21230)
danke
andre
fhem 5.6 war dann doch ein Ansporn.