vorschlag: WeekdayTimer und {} schaltzeiten

Begonnen von justme1968, 29 September 2014, 09:47:56

Vorheriges Thema - Nächstes Thema

justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dietmar63

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.

Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Dietmar63

#2
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).
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

justme1968

genau so.

mir gefällt es sehr gut.

gruß
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dietmar63

#4
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.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

justme1968

ich hab im developer bereich eben einen hinweis auf beide erweiterungen hier gepostet.

das mit dem stacktrace gefällt mir auch.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

@Dietmar63: kannst du dein Patch fuer sunrise_el hier posten? Oder habe ich es uebersehen?

Dietmar63

#7
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.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

rudolfkoenig

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.

Dietmar63

#9
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.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

rudolfkoenig

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.

Dietmar63

#11
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.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

rudolfkoenig

Ich bin doch nicht gegen dem stacktrace, ich will es aber nur beim Bedarf einschalten, um die Leute nicht zu verwirren.

Dietmar63

#13
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.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Dietmar63

#14
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");   



Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

rudolfkoenig

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.

Dietmar63

Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Dietmar63

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;
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Dietmar63

@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.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

rudolfkoenig


Dietmar63

In meiner Version hatte ich diese  Meldungen komplett unterdrückt.
Mal sehen was die Allgemeinheit dazu sagt.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

P.A.Trick

Ä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)




Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

rudolfkoenig

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.

Dietmar63

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.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

P.A.Trick

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!
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

Puschel74

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

Grüße
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Dietmar63

Dann bekommen wir die Fehler endlich mal behoben
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Dietmar63

#27
@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
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.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

rudolfkoenig


justme1968

@Dietmar63: hast du schon eine idee wann du die zugehörigen WeekdayTimer änderungen eincheckst?

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dietmar63

Ich muss nur noch die Dokumentation anpassen - heute komme ich leider nicht mehr dazu
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

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?action=dlattach;topic=26529.0;attach=21230)

danke
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dietmar63

Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm