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

[haus-automatisierung]

@ticaki sagte in Bei bestimmtem String stürzt Javascript Instanz ab:

Der Bug liegt daran das messageToAsnc einen Wert als Rückgabe erwartet und "false" als kein Wert interpretiert wird. Denke ich mal. @haus-automatisierung ?

Das sollte auch funktionieren:

https://github.com/ioBroker/ioBroker.javascript/blob/939b0b0a70dd857684afc10be6732467fb3a5208/lib/sandbox.js#L3651-L3655

Du gibst ja als Objekt { result: false } zurück und nicht einfach nur false.

[ticaki]

@haus-automatisierung

Der TE gibt im seinem Beispiel code dort oben false zurück.

Oh sehe gerade das im Beispielcode auch ein Objekt zurück gegeben wird.
https://github.com/ioBroker/ioBroker.javascript/blob/master/docs/en/javascript.md#messagetoasync

Aber ist es da wirklich zwingend das ein Objekt (oder ein Wert != null/undefined/0/''/false) zurück gegeben werden muß?

                   if (res && res.error) {
                        reject(res.error);
                    } else {
                        resolve(res);
                    }

Wäre doch da sinnvoller oder? Kann gerne ne PR machen, hab gesehen dass das Verhalten sich in allen sendToAsync Varianten wiederholt.

[haus-automatisierung]

@ticaki sagte in Bei bestimmtem String stürzt Javascript Instanz ab:

Aber ist es da wirklich zwingend das ein Objekt (oder ein Wert != null/undefined/0/''/false) zurück gegeben werden muß?

Aktuell ja. Das ist analog zu sendTo implementiert. Würde das nicht umstellen - was ist der Mehrwert? Die Blockly-Bausteine generieren den Code ja momentan auch so, dass immer ein Objekt zurückgeliefert wird:

https://github.com/ioBroker/ioBroker.javascript/blob/939b0b0a70dd857684afc10be6732467fb3a5208/src/public/google-blockly/own/blocks_trigger.js#L998

Intern ist das ja ein einfaches sendTo. Und da arbeitet man ja eigentlich immer mit Objekten. Finde ich auch sauber gelöst.

[ticaki]

@haus-automatisierung
Da ist kein Vorteil, nur das im sendTo() für jsonConfig.json bei textSendTo ein String erwartet wird(kein Object), daher meine Fehlannahme. :)

[haus-automatisierung]

@ticaki Stimmt, wäre schöner wenn auch der Admin für textSendTo dann result.text nutzen würde und man auch dort ein Objekt zurückliefert.

[Ben1983]

@haus-automatisierung ok.
Dann sollte ja async meineFunktion.result gehen, oder?
Trotzdem stürzt ja komischerweise die Instanz ab… obwohl nur der Rückgabewert geloggt werden soll. Sollte das nicht trotzdem gehen?

[haus-automatisierung]

@ben1983 sagte in Bei bestimmtem String stürzt Javascript Instanz ab:

Dann sollte ja async meineFunktion.result gehen, oder?

Wenn Du ein Objekt an die Callback-Funktion übergibst, ja. So wie in der Doku zu finden.

PS: Strings mit <> zu vergleichen ist so eine Sache... da wirst Du noch Probleme bekommen (je nachdem ob eine 0 vorangestellt wird, oder nicht):

[ticaki]

@ben1983 sagte in Bei bestimmtem String stürzt Javascript Instanz ab:

@haus-automatisierung ok.
Dann sollte ja async meineFunktion.result gehen, oder?
Trotzdem stürzt ja komischerweise die Instanz ab… obwohl nur der Rückgabewert geloggt werden soll. Sollte das nicht trotzdem gehen?

Oben steht doch die Lösung die geht...

[Ben1983]

@haus-automatisierung ok danke.
Ja denke mache es so, dass ich wirklich den String splitten werde, denn nur aus einer Zeit kann man ja mit Date() nichts erzeugen. Werde dann auch ein Objekt übergeben.

Nur ne Frage: wie kann es denn sein, dass der Fehler jemandem den ioBroker zerschießt?

[haus-automatisierung]

@ben1983 sagte in Bei bestimmtem String stürzt Javascript Instanz ab:

Nur ne Frage: wie kann es denn sein, dass der Fehler jemandem den ioBroker zerschießt?

Eigentlich gar nicht. Mindestens der JavaScript-Adapter läuft ja in einem eigenen Prozess (außer der Compact-Mode ist aktiviert). Gibt da für mich keine technisch Erklärung für.

Wenn ich das fehlerhafte Script nun so nehme und ausprobiere, passiert wahrscheinlich wieder gar nix :)

[Ben1983]

@haus-automatisierung OK. Wundert mich jetzt auch etwas.

Hier mein finaler Code, der funktioniert.
Sollte das so ok sein?

// Prüfen,ob die angegebenen Zeit vor oder gleich der aktuellen ist
onMessage("TimeBeforeOrEqualNow",(messagedata,callback)=>{
    const now = new Date();
    const inputTime = new Date(`${now.getFullYear()}-${now.getMonth() + 1}-${now.getDate()}-${messagedata.time}`);
    if(inputTime){
        callback({result:inputTime <= now});
    }
    else{
        callback({result:false});
    }
});

async function checkTime(){
    log((await messageToAsync("TimeBeforeOrEqualNow",{time:"8:33"},{timeout:5000})).result);
}

checkTime();

@haus-automatisierung ich stehe nur irgendwie noch auf dem Schlauch, wie ich das in meine Logik unterbringen soll?
Also ich habe einen Trigger durch "$Selector.on((obj)=>{....}

wenn ich jetzt darin die Funktion nutzen möchte, kann ich ja gar kein await nutzen, da es nicht in einer async funktion ist.
Somit würde ja die If Abfrage mit "undefined" abgehakt werden, bevor ein result zurückkommen kann.

[Codierknecht]

@ben1983 sagte in Bei bestimmtem String stürzt Javascript Instanz ab:

wenn ich jetzt darin die Funktion nutzen möchte, kann ich ja gar kein await nutzen, da es nicht in einer async funktion ist.

Warum nicht? Mach doch eine draus.

on({id:'dein.dp.oder.selektor', change:"ne"}, async function () {
    // hier geht auch await
});

[Ben1983]

@codierknecht Danke... oh man, da bin ich gar nicht drauf gekommen, da es eine Arrow Function ist :-)