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

[ChristianG]

@haus-automatisierung, danke für die schnelle Antwort. Ohje, dann muss ich mir eine andere Lösung überlegen. Falls der Adapter mal automatisch wegen einem Fehler einen Neustart macht, bleibt die Heizung dann bis zum nächsten Nacht-Check an :/

[Nordischerjung]

@christiang
Mach es doch so. Leg dir einen DP in 0_userdata an und prüfe ob der geschaltet wurde. Wenn JS neu startet wird der blaue Fallsblock einmal ausgeführt.

[ChristianG]

@nordischerjung vielen Dank! Werde ich sofort umsetzen. :) Hatte erst die Idee mit einem Timestamp der regelmäßig überprüft wird, aber mit true and false macht es viel mehr sinn und ist auch einfacher in der Abfrage.

[ChristianG]

Ich habe eine weitere Frage:

Wenn der Block ausgeführt wird und wieder ausgeführt wird, gibt es dann zwei Timeouts oder wird der erste überschrieben? Will umgehen, dass bei mehrfachem drehen des Thermostats mehrere Timeouts laufen oder irgendwas crashed weil viele Timeouts auslösen.

Dachte ich löse es wie im nächsten Bild zu sehen, aber dann killt er scheinbar alle Timeouts direkt und dreht wieder auf 0 bei der Heizung.

[paul53]

@christiang sagte: dann killt er scheinbar alle Timeouts

Nein, der letzte Timeout, der nicht mehr innerhalb von 60 Minuten gestoppt wird, ist wirksam.

[ChristianG]

@paul53 Das ist werkwürdig. Dann frage ich mich warum der die Heizung wieder direkt auf 10 dreht :/. Vll ist das stoppen vom Timeout schneller als das neue ausführen? Kanns mir nicht erklären. Das script sagt in keinem Punkt dreh direkt wiede runter. Wenn ich das stop raus mache geht es an der Heizung.

[paul53]

@christiang sagte: warum der die Heizung wieder direkt auf 10 dreht

Keine Ahnung: Ich kenne diese Thermostate nicht.
Du steuerst den Sollwert, der dadurch wieder triggert.

[ChristianG]

@paul53 kann es sein, dass er bei einem stop das im Timeout dann ausführt? Ansonsten kann ich es mir nicht erklären :angry:

[OliverIO]

@christiang
wenn das skript bei stopp den timeout nicht selbst löscht/deaktiviert, dann bleibt der solange bestehen, bis er ausgeführt wurde (settimeout) oder bis der adapter gestoppt wird (setinterval).

letzteres erzeugt dann auch ein kleinen memory leak, da, wenn man das timeout handle nicht mehr hat, da nicht mehr dran kommt.
wenn das skript sehr oft ausgeführt würde, dann wird der/die/das memory leak immer größer.

[haus-automatisierung]

@oliverio sagte in timout Frage:

wenn das skript bei stopp den timeout nicht selbst löscht/deaktiviert, dann bleibt der solange bestehen, bis er ausgeführt wurde

Bitte zu der Aussage mal die Stelle im Quellcode verlinken. Wäre aus meiner Sicht ein Bug. Weil die Timeouts ja in der Sandbox / nodejs VM laufen. Wenn das Script gestoppt wird, dürften die nicht mehr existieren. Der Context ist ja ein komplett anderer, als der von der JavaScript-Instanz.

https://github.com/ioBroker/ioBroker.javascript/blob/d273e8aa90e40da1527bb692a3ded515ccdad065/lib/sandbox.js#L2386-L2409

[OliverIO]

@haus-automatisierung
ok, ich revidiere.
die timeouts werden aber nur deswegen gestoppt, weil
im sandboxcode von iobroker die nativen funktionen settimeout setinterval abgefangen werden, die handles gemerkt und bei beenden der vm, dann alle ordentlich abgemeldet werden.
https://github.com/ioBroker/ioBroker.javascript/blob/58f2b57d18be7937a1e94d81892599a36741a4e1/lib/sandbox.js#L2386

ohne das (von dem ich ausgegangen bin) würden die timeouts erst bei prozessende enden, da javascript nur einen eventloop hat und der scriptadapter nur in einem prozess läuft.
für jedes script wird zwar ein eigener context eröffnet, aber kein eigener prozess.

hier mein testcode

const fs = require('fs');
let filename = "/opt/iobroker/iobroker-data/test.txt";
fs.unlink(filename,()=>{
    console.log("file deleted");
    setTimeout(()=>{
        console.log("timeout");
        fs.writeFile(filename,"test",()=>{
            console.log("written");
        });
    },5000)
});
console.log("exit");
stopScript("");

interessanterweise hat ein anderer versuch das skript mit "throw Error" zu stoppen zu einem stopp der ganzen adapter instanz geführt.

Also dann wäre die Aussage von oben, das auch bei stop des Skripts die timeouts ordentlich aufgeräumt werden und kein memory leak entsteht.

[haus-automatisierung]

@oliverio sagte in timout Frage:

interessanterweise hat ein anderer versuch das skript mit "throw Error" zu stoppen zu einem stopp der ganzen adapter instanz geführt.

Das tritt erst seit nodejs 16 auf. Ich habe auch noch kein Idee, warum. Gibt es auch einen Issue zu: https://github.com/ioBroker/ioBroker.javascript/issues/1022

Normalerweise sollte das hier gefangen werden: https://github.com/ioBroker/ioBroker.javascript/blob/d273e8aa90e40da1527bb692a3ded515ccdad065/main.js#L1700-L1709

Falls Du eine Idee hast, immer her damit :)

[OliverIO]

@haus-automatisierung

nur ne grobe Ahnung durch kurz googlen ermittelt:
Sollte es nicht eigentlich

throw new Error

heißen. da es das Error-Objekt ja noch nicht gibt.
d.h. der Fehler liegt in der Typescript-Deklaration das
der Editor da keinen Fehler anzeigt?

und da es das ur-Error-Objekt ist, greift der catch-Handler nicht sondern es wird der unhandled rejection Handler des prozesses verwendet
https://nodejs.org/api/process.html#event-unhandledrejection