Ip symcon bei der Zeitumstellung gecrasht

[tobitobsen]

Bei mir fehlt auch die zweite 2Uhr Stunde im Diagramme.

Da macht er lustige Kurven und nimmt die Stunde zweimal.

[gkoellne]

Hallo, ich hatte letzte Nacht das gleiche Problem. Ist mir die Jahre zuvor nicht aufgefallen. Gestern war ich zufällig noch wach und alle Symcon Automatismen reagierten nicht mehr. Die Console zeigte tausende “Zu viele gleichzeitige Scripte…” Meldungen. Habe diesen Beitrag gefunden und Symcon bis 03:00 gestoppt. Danach lief wieder alles normal.

Bei mir läuft IP-Symcon 8.1 auf Windows 11. Im Vergleich zu letztem Jahr gab es, abgesehen von den IP-Symcon Updates, 2 wesentliche Änderungen: Windows 11 und Anbindung eines Deye Wechselrichters über ModBus. Aus den Logs kann ich nicht herauslesen, ob ein bestimmter Timer das ganze verursacht hat.
Die wichtigste Erkenntnis für mich ist, dass es beim Rückstellen der Zeit zu Problemen kommen kann und nun weiß ich damit umzugehen.

Gruß
Gerry

[volkerm]

@tobitobsen

Bei mir fehlt auch die zweite 2Uhr Stunde im Diagramme.

Nein, die fehlt nicht. Du siehst das auch an der Zeitachse, die springt von ungeraden Werten (bis 01:00) zu geraden Werten (ab 02:00). Die doppelte Stunde ist im Diagramm enthalten.

Die “Rücksprünge” habe ich bei mir nicht in der doppelten Stunde, sind das eventuell verdichtete Werte die aus ihrer ursprünglichen Abfolge nochmal neu berechnet werden?

[volkerm]

@Silberstreifen

Das betroffene Script sieht wie folgt aus

<?php
#===========================================================================
#   wenn 5 Minuten keine Daten kommen, 
#   soll das Interface neu gestartet werden
#===========================================================================

if($_IPS['SENDER'] == 'TimerEvent'){
    IPS_LogMessage($_IPS['SELF'], 'SML-Interface wurde zurückgesetzt');
    exec('usbreset 0403:6015');
}else{
    IPS_SetScriptTimer($_IPS['SELF'], 300);
}

Das Script wird bei Aktualisierung einer Variablen alle 5 Sekunden aufgerufen.

Mal ein ganz banaler Gedanke: Solche Scripte die kurz vor der Zeitrückstellung aufgerufen werden dürften ja für eine volle zusätzliche Stunde warten, bis die erwartete Endzeit erreicht ist. Wer viel mit diesem Konstrukt arbeitet dürfte doch zwangsläufig viele wartende Threads produzieren bei Rückstellung der Uhr?

[Nall-chan]

@volkerm

dürften ja für eine volle zusätzliche Stunde warten

Warum? Hier gibt es nur einen Intervall und keine absolute Zeit.
Nur weil sich die angezeigte lokale Zeit ändert, machen wir ja keine Zeitreise.
Michael

[volkerm]

@Nall-chan

Warum? Hier gibt es nur einen Intervall und keine absolute Zeit.

Vordergründig trägt man ein Intervall ein, aber ich möchte wetten, dass innerhalb von IPS_SetScriptTimer() irgendwo ein UNIX-Timestamp der Zielzeit errechnet wird.

[Nall-chan]

@volkerm

UNIX-Timestamp der Zielzeit

Ja, welcher sich auch nicht ändert, da der immer UTC ist.
Michael

[volkerm]

@Nall-chan

Ja, welcher sich auch nicht ändert, da der immer UTC ist.

Wenn es richtig implementiert ist hättest du Recht, aber es scheint ja genau in diesem Zusammenhang IPS_SetScriptTimer() zu haken und es laufen zu viele wartende Scripte auf.

[Nall-chan]

Und das ist wohl der Grund warum @paresy die settings haben möchte.
Könnte mir vorstellen das es bei anderen Zeitmustern wo es um lokale Zeiten geht, wie jeden Morgen um 3:00 , eventuell ein Thema gibt.

[BlackOrca]

Hoffentlich kriegen die Spanier es durch das die EU diese zeitspielerei ohne sinn endlich ein Ende setzt…

Bis jetzt habe ich zumindestens bei unserem symcon keine Auffälligkeiten bemerkt…

[volkerm]

@Nall-chan

Könnte mir vorstellen das es bei anderen Zeitmustern wo es um lokale Zeiten geht, wie jeden Morgen um 3:00 , eventuell ein Thema gibt.

Hier gibt’s ein nettes Beispiel wie man beim Rechnen mit Zeitintervallen in die Falle laufen kann, je nachdem wie man es genau codiert.

100 minutes is less than 50? PHP paradoxes during time changes

Konkret relevant könnte dieses sein:

Ambiguous time (fall back):

// Attempt to create a time in the "overlap" on October 26, 2025
$dt = new DateTime('2025-10-26 02:30:00', new DateTimeZone('Europe/Prague'));
echo $dt->format('Y-m-d H:i:s T (P)');
// Output: 2025-10-26 02:30:00 CET (+01:00)

Here, PHP by default chooses the second occurrence of that time.

Wenn ich das auf IPS_SetScriptTimer() übertrage könnte die resultierende Laufzeit um 1h länger sein als beabsichtigt, wenn die Zielzeit in die doppelte Stunde fällt.

[volkerm]

@Nall-chan

Ja, welcher sich auch nicht ändert, da der immer UTC ist.

Ich habe da mal was ausprobiert … du erzeugst kurz vor der Zeitumstellung einen neuen Zeitstempel, der 30 Minuten später liegen soll. Ergebnis: da kommt ungewollt noch eine Stunde dazu.

[tobitobsen]

Ah ja, du hast recht. Die Stunde ist da.

Stelle ich auf “Roh” passt es. Gehe ich mit der Auflösung auf “Minütlich” oder größer habe ich den Sprung wieder da.

Auch nach dem ich alle Variablen Reaggregiert habe.

[Thomas]

Hänge mich da mal rein, die letzten Jahre keine Auffälligkeiten, aber heute auch

Der IPS_Watchdog hat das System um 2b:04 neu gestartet (Habe vergessen den auszuschalten, wie die letzten Jahre). Das aktuelle Log-file ist 2Gigabyte (Zu viele gleichzeitige Scripte…).

Immerhin hat dann wohl ab 3:00 Uhr wieder alles funktioniert.

Ach ja, Windows Symcon 8.1

[Silberstreifen]

@Thomas

IPS_Watchdog

Ich muss mal doof fragen: Was ist das? Ist mir bisher noch nicht untergekommen. Hast Du das selbst programmiert? So einen Watchdog würde ich auch gerne nutzen.

Grüße

Jürgen

[waxipedia]

Hallo zusammen,

zur Zeitumstellung heute Nacht ist bei mir hier erwähntes merkwürdiges Verhalten aufgetreten. Ein eigentlich unauffälliges Überwachungs-Script wurde plötzlich mit extrem hoher Frequenz ausgeführt – es gab innerhalb von etwa 30 Minuten über 6000 Logeinträge und dutzende Push-Nachrichten auf dem iPhone.

Hier das betreffende Script:

$StatusVariable = IPS_GetParent($_IPS['SELF']);

if ($_IPS['SENDER'] == "TimerEvent")
{
    // Timer ausschalten
    IPS_SetScriptTimer($_IPS['SELF'], 0);

    // Aus-Befehl
    if (GetValueBoolean($StatusVariable) == true)
    {
        $Message = "Warnung: Das Gerät \"" . IPS_GetName($StatusVariable) . "\" ist nicht erreichbar.";
        WFC_PushNotification(28314, "HomeSweetHome", $Message, "", 0);
    }

    SetValueBoolean($StatusVariable, false);
}
else
{
    if (GetValueBoolean($StatusVariable) == false)
    {
        $Message = "Warnung: Das Gerät \"" . IPS_GetName($StatusVariable) . "\" ist wieder erreichbar.";
        WFC_PushNotification(28314, "HomeSweetHome", $Message, "", 0);
    }

    SetValueBoolean($StatusVariable, true);

    // Timer anschalten
    IPS_SetScriptTimer($_IPS['SELF'], 60 * 25); // 25 Minuten
}

Der Spuk begann genau mit der Zeitumstellung – das Script wurde unkontrolliert ausgelöst, offenbar mehrfach gleichzeitig.
Nach einer halben Stunde war dann wieder Ruhe. Im Log häuften sich währenddessen Meldungen wie:

„Zu viele gleichzeitige Scripts“

Auch andere, ähnlich aufgebaute Scripte mit

IPS_SetScriptTimer($_IPS['SELF'], timeout);

scheinen betroffen gewesen zu sein.

Des weiteren hat das Modul DeviceMonitor ebenfalls zum fehlerhaften Verhalten mit ähnlichen Logeinträgen beigetragen.

Vielleicht hilft dieser Hinweis den Entwicklern, das Verhalten rund um Timer und Zeitumstellung etwas genauer einzugrenzen.

Christian

[Thomas]

IPSWatchDog

AKTUELLE VERSION: 3.0.2 Basic vom 19.09.2012 Hallo ihr IPS Nutzer, Ich habe lange verzweifelt nach einem Programm gesucht, dass mir den IPS-Server überwacht und bei Bedarf neu startet. Zu oft passierte es bei mir, dass entweder der IPS-Server-Service ausgestiegen ist oder aber aus irgend einem Grunde keine Skripte mehr ausgeführt wurden. Nach längerer, erfolgloser Suche beschloss ich, mir ein solches WatchDog Programm selbst zu programmieren. Das Ergebnis ist IPSWatchDog. Vielleicht hat j…

[Silberstreifen]

ok, danke. Das hatte ich nicht auf dem Schirm. Das ganze hat aber für mich 2 Nachteile

1. Der Download-Link ist tot
2. Der Watchdog scheint für Windows zu sein.

Trotzdem danke

Jürgen

[volkerm]

Der Rücksprung in den Daten scheint bei den alten Diagrammen im Webfront nicht aufzutreten.

[volkerm]

@waxipedia

Der Spuk begann genau mit der Zeitumstellung – das Script wurde unkontrolliert ausgelöst, offenbar mehrfach gleichzeitig.

Und das bei einer geplanten Verzögerung von 25 Minuten, nicht wie bei den Beispielen oben im Sekundenbereich.

Wenn wir es mal rein von den Symptomen betrachten:
IPS_SetScriptTimer() erzeugt hier offenbar eine Zielzeit in der Vergangenheit bzw. negative Verzögerung, die zum sofortigen Start eines weiteren Scripts führt, usw … eine ganze Kettenreaktion ist die Folge.