Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Homoran]

@Kapitaen31 sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

Ich habe das Script als blockly geschrieben...

dann zeig es bitte als Screenshot hier eingebunden

[Kapitaen31]

@Homoran sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

@Kapitaen31 sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

Kein system.host...

als Experte?

habe sie gefunden. ich hatte nicht als Experte geschaut.
Ich würde alle mit "mem", "diskfree", "cpu" mitschreiben.

Oder noch andere ?

[OliverIO]

@Kapitaen31 sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

Okay, welche Logs sind da entscheidend?

Kernel-Log, speziell nach folgenden Schlüsselwörtern suchen

dmesg -T | grep <suchbegriff>

error
warn
segfault
oom
watchdog

systemd journal mit

sudo journalctl --since 2025-12-01 --until 2025-12-02

mit --since und --until wirst du den zeitraum einschränken müssen
mit seite auf/ab kannst du dann blättern und dann schaust du dir mal die 100 zeile vor dem absturz an.

da auch nach den gleichen suchbegriffen wie oben schauen.
halt irgendwelche probleme.
im zweifel kopieren und hier reinposten

[OliverIO]

@Kapitaen31 sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

mem

es gibt mehrere mit mem.
ja kannst du machen.
fügt der systemlast noch mehr dazu, aber dann wird, wenn es das ist, der absturtz ein wenig früher sein.

[Kapitaen31]

@Homoran sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

@Kapitaen31 sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

Ich habe das Script als blockly geschrieben...

dann zeig es bitte als Screenshot hier eingebunden

Es ist recht groß. Ich hoffe ihr könnte es lesen.

und die anderen Teile. Ich habe sie in mehrere Bilder unterteilt. Immer ein Trigger.

[OliverIO]

@Kapitaen31

oder du machst ein export.
dann können es andere zum prüfen importieren (ich nicht :) bei blockly bin ich raus)

[Kapitaen31]

@OliverIO sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

es gibt mehrere mit mem.

Ja, genau. Das meinte ich auch. ich habe noch CPU und load mit eingefügt.

[Kapitaen31]

@OliverIO sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

@Kapitaen31

oder du machst ein export.
dann können es andere zum prüfen importieren (ich nicht :) bei blockly bin ich raus)

Ja, genau. Das hatte ich oben schon gemacht.

[Homoran]

@Kapitaen31 sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

Es ist recht groß

ja, mobil kaum handlebar 😉

ich hab mich daher erst mal auf den Abend beschränkt, da fällt mir auf, dass dort max erreichbar eine Zahl (1|) ist.
in allen anderen Fällen ist es bool.

Ob das jetzt ein Problem im Vergleich ergibt entzieht sich meinem Wissen. es könnte durch implizite Typwandlung korrigiert werden.

[Homoran]

@Kapitaen31 sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

Das hatte ich oben schon gemacht.

aber bitte als Text in code-tags, ggf in spoiler.
nicht als downloadbare Datei unbekannten Formats und Inhalts

[Kapitaen31]

@OliverIO sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

Kernel-Log, speziell nach folgenden Schlüsselwörtern suchen

dmesg -T | grep <suchbegriff>

error
warn
segfault
oom
watchdog

Bei error erfolgt keine Ausgabe.
Bei warn erhalte ich folgendes:

PI@PIArgon:/var/log $ dmesg -T | grep warn
[Fr Jan 30 17:33:52 2026] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[Fr Jan 30 17:33:52 2026] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[Fr Jan 30 17:33:52 2026] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[Fr Jan 30 17:33:52 2026] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[Fr Jan 30 17:33:52 2026] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[Fr Jan 30 17:33:52 2026] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.

Bei segfault und oom erscheinen keine Ausgaben.
Bei watchdog:

PI@PIArgon:/var/log $ dmesg -T | grep watchdog
[Fr Jan 30 17:33:47 2026] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer

systemd journal mit

Wie lange dauert so eine Ausgabe ? Ich habe von 29.01. bis 30.01. den Zeitraum eingeschränkt.
Weil es erscheint bei mir nicht sofort die Ausgabe. Bisher zeigt der Befehl bei mir nichts.

[Kapitaen31]

@Homoran sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

@Kapitaen31 sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

Das hatte ich oben schon gemacht.

aber bitte als Text in code-tags, ggf in spoiler.
nicht als downloadbare Datei unbekannten Formats und Inhalts

Okay, dann mache ich es oben als spoiler.

[Homoran]

@OliverIO sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

bei blockly bin ich raus

@kapitaen31
dann mach doch bitte für @oliverio auch noch einen Export der Javascript Ansicht (ohne die letzte kilometerlange kryptische Zeile)

[Thomas Braun]

@Kapitaen31

Kannst auch damit mal schauen:

dmesg --level=emerg,alert,crit,err,warn -T

[Kapitaen31]

@Thomas-Braun sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

@Kapitaen31

Kannst auch damit mal schauen:

dmesg --level=emerg,alert,crit,err,warn -T

Hier ist die Ausgabe:

PI@PIArgon:~ $ dmesg --level=emerg,alert,crit,err,warn -T
[Fr Jan 30 20:18:41 2026] pci_bus 0000:01: supply vpcie3v3 not found, using dummy regulator
[Fr Jan 30 20:18:41 2026] pci_bus 0000:01: supply vpcie3v3aux not found, using dummy regulator
[Fr Jan 30 20:18:41 2026] pci_bus 0000:01: supply vpcie12v not found, using dummy regulator
[Fr Jan 30 20:18:43 2026] mmc1: Controller never released inhibit bit(s).
[Fr Jan 30 20:18:43 2026] usb 2-2: UAS is ignored for this device, using usb-storage instead
[Fr Jan 30 20:18:44 2026] usb 2-2: UAS is ignored for this device, using usb-storage instead
[Fr Jan 30 20:18:50 2026] systemd-journald[276]: File /var/log/journal/3a228e6261a14b389cf6e2129be3286a/system.journal corrupted or uncleanly shut down, renaming and replacing.
[Fr Jan 30 20:18:59 2026] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[Fr Jan 30 20:18:59 2026] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[Fr Jan 30 20:18:59 2026] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[Fr Jan 30 20:18:59 2026] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[Fr Jan 30 20:18:59 2026] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[Fr Jan 30 20:18:59 2026] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
[Fr Jan 30 20:19:00 2026] hci_uart_bcm serial0-0: supply vbat not found, using dummy regulator
[Fr Jan 30 20:19:00 2026] hci_uart_bcm serial0-0: supply vddio not found, using dummy regulator

[Meister Mopper]

@Kapitaen31 sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

Was ich gerade komisch finde das der Befehl

sudo systemctl status argononed

keine Ausgabe generiert....

Dann stimmt etwas mit dem Service nicht. Es müsste so ähnlich aussehen:

thomas@rpifr24:~ $ sudo systemctl status argononed
● argononed.service - Argon One Fan and Button Service
     Loaded: loaded (/usr/lib/systemd/system/argononed.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-01-27 08:00:55 UTC; 3 days ago
 Invocation: 235e1f92daad47fc85a1436fc4a0f835
   Main PID: 1735012 (python3)
      Tasks: 5 (limit: 3919)
        CPU: 20min 18.948s
     CGroup: /system.slice/argononed.service
             └─1735012 /usr/bin/python3 /etc/argon/argononed.py SERVICE

Notice: journal has been rotated since unit was started, output may be incomplete.
thomas@rpifr24:~ $

Ich hatte das Problem, dass bei gleicher Konstellation plötzlich der Lüfter permanent max lief.
Bei mir hat es geholfen, argononed zu deinstallieren und neu zu konfigurieren.
Offenbar wurde es bei der Umstellung von bookworm auf trixie nicht sauber mitgenommen.

Jetzt läuft es wieder geschmeidig.

[Kapitaen31]

@Homoran sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

@kapitaen31
dann mach doch bitte für @oliverio auch noch einen Export der Javascript Ansicht (ohne die letzte kilometerlange kryptische Zeile)

Hier kommt der die JavaScript Ansicht:

var MAX_Wert, MAX_erreichbar, MAX_aufdimmen_aktiv, MAX_aufdimmen, MAX_Text, MAX_Zyklus_beendet, MAX_Farbwert, MAX_ein_aus, MaxZeitplan, MAX_aus, MAX_ein, MAX_Helligkeit, Max_abends_aus, Wartezeit;

// Hue Lampe mit angegebenem Wert langsam einschalten.
async function Max_dimmen(MAX_Wert, MAX_erreichbar, MAX_aufdimmen_aktiv, MAX_aufdimmen, MAX_Text, MAX_Zyklus_beendet, MAX_Farbwert, MAX_ein_aus) {
  if (MAX_ein_aus == 'ein') {
    // Max wird  aufgeblendet (einschalten)
    if (getState('alias.0.OG.Flur.Licht.HelligkeitHueMax').val == 0) {
      setState('alias.0.OG.Flur.Licht.HelligkeitHueMax' /* Helligkeit Hue Max */, 5);
      console.warn('Max eingeschaltet! ');
    }
    setState('alias.0.OG.Flur.Licht.FarbTemperaturHueMax' /* Farb Temp Hue Max */, MAX_Farbwert);
    setState('javascript.0.Datenpunkte.Flur.Licht.Abdimmen_aktiv' /* Aufdimmen aktiv */, true, true);
    MAX_ein = setInterval(async () => {
      if (getState('alias.0.OG.Flur.Licht.HelligkeitHueMax').val < MAX_Wert && getState('alias.0.OG.Flur.Licht.Erreichbar Hue Max').val == MAX_erreichbar) {
        setState('alias.0.OG.Flur.Licht.HelligkeitHueMax' /* Helligkeit Hue Max */, (getState('alias.0.OG.Flur.Licht.HelligkeitHueMax').val + 5));
        console.log((String(MAX_Text) + String(getState('alias.0.OG.Flur.Licht.HelligkeitHueMax').val)));
      } else {
        (() => { if (MAX_ein) { clearInterval(MAX_ein); MAX_ein = null; }})();
        setState('javascript.0.Datenpunkte.Flur.Licht.Abdimmen_aktiv' /* Aufdimmen aktiv */, MAX_aufdimmen_aktiv, true);
        Wartezeit = setTimeout(async () => {
          Wartezeit = null;
          console.log((String(MAX_Zyklus_beendet) + String(getState('alias.0.OG.Flur.Licht.HelligkeitHueMax').val)));
        }, 3000);
      }
    }, 30000);
  } else if (MAX_ein_aus == 'aus') {
    // Max wird  abgeblendet (ausgeschalten)
    if (getState('javascript.0.Datenpunkte.Flur.Licht.Abdimmen_aktiv').val) {
      (() => { if (MAX_ein) { clearInterval(MAX_ein); MAX_ein = null; }})();
      (() => { if (MAX_aus) { clearInterval(MAX_aus); MAX_aus = null; }})();
      setState('javascript.0.Datenpunkte.Flur.Licht.Abdimmen_aktiv' /* Aufdimmen aktiv */, MAX_aufdimmen_aktiv, true);
    }
    MAX_aus = setInterval(async () => {
      if (MAX_Wert == 0) {
        if (getState('alias.0.OG.Flur.Licht.HelligkeitHueMax').val > 6 && getState('alias.0.OG.Flur.Licht.Erreichbar Hue Max').val == 1) {
          MAX_Helligkeit = true;
        } else {
          MAX_Helligkeit = false;
        }
      } else {
        if (getState('alias.0.OG.Flur.Licht.HelligkeitHueMax').val > MAX_Wert && getState('alias.0.OG.Flur.Licht.Erreichbar Hue Max').val == 1) {
          MAX_Helligkeit = true;
        } else {
          MAX_Helligkeit = false;
        }
      }
      if (MAX_Helligkeit) {
        setState('alias.0.OG.Flur.Licht.HelligkeitHueMax' /* Helligkeit Hue Max */, (getState('alias.0.OG.Flur.Licht.HelligkeitHueMax').val - 5));
        console.log((String(MAX_Text) + String(getState('alias.0.OG.Flur.Licht.HelligkeitHueMax').val)));
      } else {
        (() => { if (MAX_aus) { clearInterval(MAX_aus); MAX_aus = null; }})();
        setState('alias.0.OG.Flur.Licht.EingeschaltetHueMax' /* Ein Hue Max */, false);
        console.error(MAX_Zyklus_beendet);
      }
    }, 30000);
  }
}


// Hue Max automatisch morgens langsam einschalten
on({ id: [].concat(['javascript.0.Datenpunkte.Flur.Licht.CRON_Wochentag']).concat(['javascript.0.Datenpunkte.Flur.Licht.CRON_Monat']).concat(['javascript.0.Datenpunkte.Flur.Licht.CRON_Datum']).concat(['javascript.0.Datenpunkte.Flur.Licht.CRON_Std']).concat(['javascript.0.Datenpunkte.Flur.Licht.CRON_Min']), change: 'ne' }, async (obj) => {
  (() => { if (MaxZeitplan) { clearSchedule(MaxZeitplan); MaxZeitplan = null; }})();
  MaxZeitplan = schedule(getState('javascript.0.Datenpunkte.Flur.Licht.CRON_Min').val.toString().trim() + ' ' + getState('javascript.0.Datenpunkte.Flur.Licht.CRON_Std').val.toString().trim() + ' ' + getState('javascript.0.Datenpunkte.Flur.Licht.CRON_Datum').val.toString().trim() + ' ' + getState('javascript.0.Datenpunkte.Flur.Licht.CRON_Monat').val.toString().trim() + ' ' + getState('javascript.0.Datenpunkte.Flur.Licht.CRON_Wochentag').val.toString().trim(), async () => {
    console.warn('Neuer Zeitplan wurde für morgens einschalten angelegt.   ');
    if (compareTime(getAstroDate('dawn', undefined, 18), null, '<', null)) {
      console.warn(([(new Date().getTime()),'  ;   ',getAstroDate('dawn', undefined, 18)].join('')));
      (() => { if (MAX_aus) { clearInterval(MAX_aus); MAX_aus = null; }})();
      (() => { if (MAX_ein) { clearInterval(MAX_ein); MAX_ein = null; }})();
      await Max_dimmen(30, true, false, true, 'Max morgens einschalten +5. Wert:', 'Max Einschalt Zyklus morgens beendet. Wert: ', 2730, 'ein');
    }
  });
});
// Hue Max automatisch abends langsam einschalten
schedule({ astro: 'sunset', shift: 0 }, async () => {
  console.warn('Sonnenuntergang.  ');
  if (compareTime('21:36', 'null', '<')) {
    (() => { if (MAX_ein) { clearInterval(MAX_ein); MAX_ein = null; }})();
    (() => { if (MAX_aus) { clearInterval(MAX_aus); MAX_aus = null; }})();
    await Max_dimmen(100, 1, false, true, 'Max abends einschalten +5. Wert:', 'Max Einschalt Zyklus abends beendet. Wert: ', 2730, 'ein');
  }
});
// Hue Max automatisch abends langsam ausschalten
on({ id: [].concat(['javascript.0.Datenpunkte.Flur.Licht.CRON_datum_abends']).concat(['javascript.0.Datenpunkte.Flur.Licht.CRON_min_abends']).concat(['javascript.0.Datenpunkte.Flur.Licht.CRON_monat_abends']).concat(['javascript.0.Datenpunkte.Flur.Licht.CRON_std_abends']).concat(['javascript.0.Datenpunkte.Flur.Licht.CRON_wochentag_abends']), change: 'ne' }, async (obj) => {
  console.warn('Zeitplan MAX abends ausschalten wurde neu angelegt: ');
  (() => { if (Max_abends_aus) { clearSchedule(Max_abends_aus); Max_abends_aus = null; }})();
  Max_abends_aus = schedule(getState('javascript.0.Datenpunkte.Flur.Licht.CRON_min_abends').val.toString().trim() + ' ' + getState('javascript.0.Datenpunkte.Flur.Licht.CRON_std_abends').val.toString().trim() + ' ' + getState('javascript.0.Datenpunkte.Flur.Licht.CRON_datum_abends').val.toString().trim() + ' ' + getState('javascript.0.Datenpunkte.Flur.Licht.CRON_monat_abends').val.toString().trim() + ' ' + getState('javascript.0.Datenpunkte.Flur.Licht.CRON_wochentag_abends').val.toString().trim(), async () => {
    console.warn('Zeitplan MAX abends ausschalten gestartet: ');
    (() => { if (MAX_aus) { clearInterval(MAX_aus); MAX_aus = null; }})();
    (() => { if (MAX_ein) { clearInterval(MAX_ein); MAX_ein = null; }})();
    await Max_dimmen(0, 1, false, false, 'Max abends ausschalten -5. Wert:  ', 'Zyklus MAX ausschalten abends beendet!  Wert:  ', 2730, 'aus');
  });
});
// Hue Max automatisch morgens langsam ausschalten
schedule({ astro: 'dawn', shift: 20 }, async () => {
  console.warn('Sonnenaufgang 20min später.');
  (() => { if (MAX_aus) { clearInterval(MAX_aus); MAX_aus = null; }})();
  (() => { if (MAX_ein) { clearInterval(MAX_ein); MAX_ein = null; }})();
  await Max_dimmen(0, 1, false, false, 'Max morgens ausschalten -5. Wert:  ', 'Zyklus MAX ausschalten morgens beendet!  Wert:  ', 2730, 'aus');
});

[Kapitaen31]

@Meister-Mopper sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

Ich hatte das Problem, dass bei gleicher Konstellation plötzlich der Lüfter permanent max lief.
Bei mir hat es geholfen, argononed zu deinstallieren und neu zu konfigurieren.
Offenbar wurde es bei der Umstellung von bookworm auf trixie nicht sauber mitgenommen.

Jetzt läuft es wieder geschmeidig.

Ich hatte vorhin nochmals die Konfig neu gestartet. Jetzt erhalte ich auch eine Ausgabe:

PI@PIArgon:~ $ sudo systemctl status argononed
● argononed.service - Argon One Fan and Button Service
     Loaded: loaded (/lib/systemd/system/argononed.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-01-30 20:18:59 CET; 8min ago
   Main PID: 864 (python3)
      Tasks: 3 (limit: 3913)
        CPU: 106ms
     CGroup: /system.slice/argononed.service
             └─864 /usr/bin/python3 /etc/argon/argononed.py SERVICE

Jan 30 20:18:59 PIArgon systemd[1]: Started argononed.service - Argon One Fan and Button Service.

Ich hatte den PI auch nochmal neu gestartet.

[OliverIO]

@Kapitaen31 sagte in ioBroker auf PI4 stürzt immer mal wieder ab:

läuft bei dir auf dem raspi auch ein browser mit?
ansonsten ist das beschriebene problem wahrscheinlich nicht relevant, sollte aber auch behoben werden.
also 1) mit "vermüllen" ist gemeint, das da ein memory leak ist. d.h. da wird immer wieder speicher reserviert, der erst du neustart oder im browser mit neuladen behoben werden kann. solange genügend speicher da ist, kein problem, evtl hast du da auch noch nie was gemerkt, sollte aber behoben werden. weiß0 nicht wie safe da blockly ist.

ich habe das skript mal bei gemini reingeworfen (chatgpt geht gerade nicht)

---

Das sieht nach einem klassischen Blockly-Export für den ioBroker JavaScript-Adapter aus. Das Skript ist funktional, hat aber ein paar „Stolperfallen“, die im Alltag zu Problemen führen können (besonders beim Dimmen und den Zeitplänen).

Hier sind die kritischen Punkte, die ich gefunden habe:

1. Die "Erreichbarkeit"-Prüfung (MAX_erreichbar)

In der Funktion Max_dimmen fragst du den Status Erreichbar Hue Max ab.

• Das Problem: Wenn die Lampe über den Wandschalter stromlos gemacht wurde, ist sie "nicht erreichbar". Das Intervall läuft dann aber ewig weiter, weil die Bedingung getState(...).val == MAX_erreichbar nie erfüllt wird, aber auch kein else greift, das das Intervall stoppt.
• Folge: Das Skript "vermüllt" den Speicher mit laufenden Intervallen im Hintergrund.

2. Fehlende Initialisierung beim Neustart

Die Variable MaxZeitplan und Max_abends_aus werden erst gesetzt, wenn sich einer der CRON-Datenpunkte ändert (change: 'ne').

• Das Problem: Wenn du das Skript oder den ioBroker neu startest, sind diese Zeitpläne nicht aktiv, bis du die Werte in den Datenpunkten einmal manuell änderst.
• Lösung: Du solltest die schedule-Logik am Ende des Skripts einmal ohne Trigger aufrufen, damit sie beim Start sofort registriert wird.

3. Logik-Fehler beim "Abdimmen_aktiv"

Im else if (MAX_ein_aus == 'aus')-Teil setzt du:
setState('javascript.0.Datenpunkte.Flur.Licht.Abdimmen_aktiv', MAX_aufdimmen_aktiv, true);

• Das Problem: Du übergibst hier die Variable MAX_aufdimmen_aktiv. In deinem morgendlichen Ausschalt-Trigger ist dieser Wert aber auf false gesetzt. Das ist zwar technisch nicht falsch, aber die Variable heißt im Datenpunkt "Abdimmen_aktiv", was verwirrend sein kann, wenn sie beim Ausschalten auf false geht, obwohl der Prozess noch läuft.

4. Die compareTime bei Sonnenuntergang

if (compareTime('21:36', 'null', '<'))

• Das Problem: Das bedeutet: "Führe das Dimmen nur aus, wenn es vor 21:36 Uhr ist". Da der Sonnenuntergang im Sommer aber auch mal nach 21:36 Uhr sein kann, würde die Lampe an manchen Tagen im Jahr einfach gar nicht angehen. Prüfe, ob das so gewollt ist.

5. Intervall-Dauer vs. Schrittweite

Du dimmst alle 30 Sekunden um 5 Einheiten.

• Um von 0 auf 100 zu kommen, braucht das Skript 20 Schritte.
• (10 Minuten).
• Gefahr: Wenn während dieser 10 Minuten jemand manuell das Licht schaltet oder ein anderer Trigger feuert, kommen sich die Intervalle in die Quere, falls MAX_ein / MAX_aus nicht sauber gelöscht werden.

---

Zusammenfassung & Empfehlung

Fehlerquelle	Auswirkung	Lösung
Erreichbarkeit	Endlosschleife im Hintergrund	Ein else { clearInterval... } hinzufügen, falls Lampe offline.
Startverhalten	Zeitpläne nach Neustart inaktiv	Trigger-Logik einmal beim Skriptstart ausführen.
Variablen-Mix	MAX_erreichbar wird mal als true (Boolean) und mal als 1 (Zahl) übergeben.	JavaScript ist da tolerant, aber sauberer wäre es, immer den gleichen Typ zu nutzen.

Ein kleiner Tipp für ioBroker:
Anstatt Intervalle mit setInterval zu bauen, nutzen viele für Hue-Lampen das native transition (Übergangszeit) Kommando. Man kann beim setState einer Hue-Lampe oft ein JSON mitgeben: setState('id', {val: 100, ack: false, transition: 600}). Das würde die Lampe von alleine über 10 Minuten dimmen, ohne dass das Skript alle 30 Sekunden funken muss.

Soll ich dir zeigen, wie du den Teil für den automatischen Start nach einem Neustart ergänzt?

[OliverIO]

@Kapitaen31

zum vergleichmal noch chatgpt 5.2
sag mal welche ausgabe du besser findest bzw was dir mehr geholfen hat.

---

Ja – da sind ein paar echte „Blockly-Export“-Klassiker drin, die dir in ioBroker früher oder später Probleme machen (oder dafür sorgen, dass es nicht so läuft wie gedacht). Ich gehe die auffälligsten Punkte durch und sage jeweils warum das problematisch ist und wie du’s robust bekommst.

---

1) Parameter-Chaos vs. globale Variablen (und dadurch Logikfehler)

Max_dimmen() hat diese Signatur:

async function Max_dimmen(MAX_Wert, MAX_erreichbar, MAX_aufdimmen_aktiv, MAX_aufdimmen, MAX_Text, MAX_Zyklus_beendet, MAX_Farbwert, MAX_ein_aus)

Du rufst sie z.B. morgens so auf:

await Max_dimmen(30, true, false, true, ..., 2730, 'ein');

Aber im Code vergleichst du später:

getState('alias.0.OG.Flur.Licht.Erreichbar Hue Max').val == MAX_erreichbar

Und im Aufruf gibst du einmal true, einmal 1 (abends: Max_dimmen(100, 1, ...)).

➡️ Wenn der State ...Erreichbar Hue Max bei dir ein Zahl-Boolean ist (0/1), dann ist der Vergleich mit true zwar mit == oft „zufällig“ wahr (weil true == 1), aber das ist fragil. Wenn der State mal "true" oder true liefert, oder du auf === umstellst, knallt’s.

Robust fix: Normalisieren statt „magischen“ Typen:

const reachable = !!getState('alias.0.OG.Flur.Licht.Erreichbar Hue Max').val;
if (reachable === !!MAX_erreichbar) { ... }

Oder konsequent immer 1/0 verwenden.

---

2) MAX_aufdimmen wird nie verwendet

Du übergibst MAX_aufdimmen, aber im Code taucht die Variable nirgendwo sinnvoll auf (sie wird nicht gelesen). Das ist kein Crash, aber ein Hinweis: Blockly hat dir Paramater reingezogen, die du gar nicht brauchst.

➡️ Ergebnis: schwer wartbar, und du glaubst evtl. „das beeinflusst was“, tut es aber nicht.

---

3) Falsche/inkonsistente Nutzung von compareTime()

Du hast mehrere Varianten:

a) Morgens:

if (compareTime(getAstroDate('dawn', undefined, 18), null, '<', null)) {

Das sieht aus wie Blockly-„Compare Time“ in der 4-Argument-Variante. Kann funktionieren, ist aber seltsam (null/null).

b) Abends:

if (compareTime('21:36', 'null', '<')) {

Hier ist 'null' ein String, nicht null.

➡️ Das ist sehr wahrscheinlich ein Fehler. Je nach Implementierung von compareTime ist 'null' ein ungültiger Zeitpunkt und die Funktion liefert dann immer false oder verhält sich unerwartet.

Vermutlich wolltest du: „wenn aktuelle Zeit < 21:36“ oder „wenn 21:36 < aktuelle Zeit“. Dafür ist die typische Blockly-Semantik:

• compareTime('21:36', null, '<') → vergleicht '21:36' mit jetzt
• oder compareTime(null, '21:36', '<') je nach Variante

Konkreter Verdacht: Dein Abend-Einschalten läuft evtl. nie, weil der Vergleich falsch ist.

---

4) Du setzt „EingeschaltetHueMax“ nur beim Ausschalten – aber nicht beim Einschalten

Beim Dimmen „ein“ setzt du:

• Helligkeit ggf. auf 5
• Farbtemperatur
• Abdimm-aktiv true
• und erhöhst Helligkeit

Beim Dimmen „aus“ machst du am Ende:

setState('alias.0.OG.Flur.Licht.EingeschaltetHueMax', false);

➡️ Aber beim Einschalten setzt du EingeschaltetHueMax nicht auf true. Wenn andere Logik oder Visualisierung davon abhängt, ist das inkonsistent.

---

5) Race-Conditions / parallele Intervalle: nicht konsequent gestoppt

Du stoppst Intervalle zwar oft, aber nicht überall:

• Beim Start von Max_dimmen('ein') stoppst du nicht automatisch ein evtl. laufendes MAX_ein oder MAX_aus (nur in den Schedules machst du das davor).
• Im aus-Zweig stoppst du nur dann sofort, wenn Abdimmen_aktiv true ist:

if (getState('...Abdimmen_aktiv').val) {
  clearInterval(MAX_ein); clearInterval(MAX_aus);
}

➡️ Wenn Abdimmen_aktiv aus irgendeinem Grund false ist, können alte Intervalle weiterlaufen und du startest zusätzlich MAX_aus. Dann schreiben zwei Timer gegeneinander.

Robust fix: Immer am Anfang von Max_dimmen() beide Intervalle killen, unabhängig vom Flag.

---

6) setInterval(async () => { ... }) – async im Interval ohne Nutzen

Du nutzt async in den Interval-Callbacks, aber du await-est da drin praktisch nichts (außer in setTimeout, was auch ohne async geht).

➡️ Kein direkter Fehler, aber: falls du später await einbaust, kann es passieren, dass ein neuer Interval-Tick startet, bevor der alte fertig ist (Überlappung). Besser: kein async im setInterval oder einen „Lock“ setzen.

---

7) Schwellenwerte beim Ausschalten: mögliche Endlosschleife / nie ganz aus

Im Ausblend-Zweig:

if (MAX_Wert == 0) {
  if (helligkeit > 6) MAX_Helligkeit = true; else false;
}
...
if (MAX_Helligkeit) helligkeit -= 5
else stop + ausgeschaltet=false

➡️ Du dimmst runter bis <= 6, dann stoppst du und setzt EingeschaltetHueMax=false. Aber du setzt die Helligkeit nicht auf 0. D.h. sie kann bei 6 stehen bleiben.

• Wenn dein Gerät bei 6 noch sichtbar leuchtet: bleibt an.
• Wenn du später „ein“ startest, hast du nicht „aus=0“ als Ausgangslage.

Wenn du wirklich „aus“ willst, setz beim Ende explizit auf 0.

---

8) Doppelbelegung / uneindeutige Zustände: „Abdimmen_aktiv“

Du setzt:

• beim Einschalten: Abdimmen_aktiv erst auf true, später auf MAX_aufdimmen_aktiv (bei dir meist false)
• beim Ausschalten: setzt du es auf MAX_aufdimmen_aktiv

➡️ Der Name passt nicht: du nutzt es als „läuft gerade ein Dimmer-Zyklus“ (lock), aber setzt es am Ende auf einen Parameterwert, der in deinen Aufrufen immer false ist. Das ist okay, aber dann brauchst du keinen Parameter dafür.

---

9) Cron-Strings aus States: Gefahr von „kaputtem Cron“ ohne Validierung

Du baust Cron so:

min + ' ' + std + ' ' + datum + ' ' + monat + ' ' + wochentag

Wenn einer der States leer ist oder * falsch gesetzt wird, erzeugst du einen ungültigen Cron und schedule() kann still scheitern oder Exceptions werfen.

➡️ Blockly macht das gern, aber produktiv solltest du mindestens loggen, welcher Cron konkret gesetzt wurde und ob schedule() eine ID zurückgab.

---

10) Kleinigkeiten, aber echte Wartungsbremsen

• Sehr viele globale Variablen, die eigentlich nur Timer-Handles sind (MAX_ein, MAX_aus, Wartezeit).
• MAX_Wert == 0 vs === – mit .val aus ioBroker kann auch string kommen. Dann ist == wieder „zufällig“ korrekt.

---

Was ich konkret als „Minimal-Fix“ empfehlen würde (ohne alles umzubauen)

1. Am Anfang von Max_dimmen immer alles stoppen:

• clearInterval(MAX_ein), clearInterval(MAX_aus), optional clearTimeout(Wartezeit)

2. Erreichbar immer booleanisieren

• const reachable = !!getState(...).val;
• und MAX_erreichbar ebenfalls !!MAX_erreichbar

3. compareTime('21:36', 'null', '<') korrigieren

• sehr wahrscheinlich muss 'null' → null (ohne Quotes) oder die Argumente anders.

4. Beim Ausschalt-Ende Helligkeit auf 0 setzen

• setState(...Helligkeit..., 0);

5. Optional: EingeschaltetHueMax beim Einschalten auf true.

---

Wenn du willst, kann ich dir als nächsten Schritt eine bereinigte Version 1:1 auf Basis deines Codes posten (gleiches Verhalten, aber mit den oben genannten Fixes, weniger Parametern, sauberem Timer-Handling). Ich würde dafür nur kurz wissen:

• Liefert alias.0.OG.Flur.Licht.Erreichbar Hue Max bei dir 0/1 oder true/false?
• Soll „aus“ wirklich auf 0 gehen oder bewusst bei 6 stoppen?