@apollon77 Schick ich dir wenn ich von der Arbeit zurück bin.

Vielen Dank für deine Anregung die Zahlen aus dem String zu extrahieren.
Habs am Ende etwas anders umgesetzt mit nem switch case und das Ganze in eine Funktion mit Rückgabe gepackt.
Die Funktion extrahiert jetzt einwandfrei 0 ... 999.999.999.999 und ist leicht erweiterbar, da einfach nur der exponent als wort erkannt werden muss.

Wer will kann sich das hier gerne herunterladen als Blockly oder reine Funktion:
Download from GitHub

@apollon77 5.2.4 läuft nun absolut stabil. Herzliches Dankeschön für deine Bemühungen.

@xenon sagte in settimeout() id an obj binden [gelöst]:

Wie gesagt, ich habe es mittlerweile hinbekommen

Auch vor dem Wissen, dass dieser Thread nun fast 4 Jahre alt ist, wie sieht denn deine Lösung für dieses Problem aus?
Ich stehe aktuell vor genau derselben Problematik und wäre über eine Lösung dankbar.

@paul53 sagte in existsStateAsync liefert false negative:

Erstelle Issue auf Github.

Schon dabei. Dann löse ich Thread mal als gelöst. Vielen Dank für deine Hilfe.

@paul53 sagte in existsStateAsync liefert false negative:

Kommt es öfter vor, dass der MQTT-Adapter Objekte ohne Typ erstellt?

Also ich habe grade mal geschaut und es betrifft eigentlich nur die Datenpunkte unter zigbee2mqtt. Ich denke dass der JSON Payload nicht richtig verarbeitet wird.
Hier mal ne Übersicht eines Geräts von z2m im MQTT Adapter.

@paul53 sagte in existsStateAsync liefert false negative:

Wie wurde der DP erstellt?

Die Datenpunkte erstellt der MQTT Adapter als Client selbstständig so. Das habe ich mich eh schön häufiger gefragt, wieso haufenweise Datenpunkte als "Mixed" unter MQTT angelegt werden.

@paul53 super, danke dir. Also liegt das Problem bei der Erstellung der Datenpunkte des MQTT Adapters oder?

Hej Leute,

mal ne Frage zur Funktion await existsStateAsync(id). Bei mir liefert die Abfrage sporadisch falsch negative Antworten und so ganz bin ich noch nicht hinter gestiegen woran das liegen könnte. In meinem Skript werden die Abfragen dynamisch generiert und ggf. als Warnmeldung ins Log geschrieben mit der fehlerhaften. Jetzt habe ich die scheinbar fehlerhafte ID mal in einem separaten Skript geprüft und es liefert tatsächlich false zurück, OBWOHL die ID so stimmt. Selbst wenn ich diese ID aus meinem Objekte Ordner kopiere liefert sie false zurück.

Bevor ich ein Isue bei GitHub erstelle wollte ich euch nochmal fragen, ob ihr noch Ideen habt woran das liegen könnte?

@amg_666 sagte in if - if else Logik Problem:

Probiers doch einfach mal aus

Hmm klar kann man viele Sachen auch über try and error erlernen, aber ich bin eigentlich eher ein Fan davon auch die Hintergründe zu verstehen.
Vielleicht kannst du mir ja noch nähere Infos dazu geben, das wäre super.

Nichtsdesto trotz habe ich das Problem jetzt glaube ich gelöst mit der gegenseitigen Verriegelung der Schleifen durch ne boolsche Variable. Ich denke das war das Problem, dass die beiden Schleifen gleichzeitig in 2 verschiedenen Threads gelaufen sind und sich so gegenseitig beeinflusst haben.

@amg_666
Ich verstehe schon deine Argumentation, nur wüsste ich gerne wieso es bei javascript hierbei zu Problemen kommen kann?
Bin da eher mit C/C++ vertraut und dort kommt es eigentlich nicht zu solchen Phänomenen.

Ich denke aber das Problem liegt aktuell auch eher daran, dass wenn der Trigger innerhalb der Schleife erneut aufgerufen wird und die gegenteilige Abfrage wahr ist, die beiden Schleifen gegeneinander laufen aktuell.

@codierknecht
Die Schleife ist deshalb, weil das Nuki hin und wieder Befehle verschluckt und dann die Tür nicht auf oder abgeschlossen wird. Wieso das so ist, kann ich dir nicht verraten.
Das mit der Variable ist mir im Nachhinein auch noch aufgefallen, nur ich wüsste nicht wieso die Variable die äußere IF - IF ELSE Abfrage beeinflussen sollte?

Hej,
ich bin grade etwas verwundert über die Aktionen meines Skripts.

'use strict'

const home_id        = '0_userdata.0.member.home';
const door_state_id  = 'nuki.0.480179117.states.state';
const door_action_id = 'nuki.0.480179117.actions.action';

on({id: home_id, change: 'ne'}, async (obj) => {
    let state = obj.state.val;
    console.log('State: ' + state + ' ts: ' + formatDate(obj.state.ts, 'hh:mm:ss'));

    if (state == 0 || state == 3) {
        for (let i = 0; i < 5; i++) {
            console.log('closing');
            setState(door_action_id, {val: 2, ack: false}); // closing the door

            await wait(30 * 1000);

            state = (await getStateAsync(door_state_id)).val;
            if (state == 1 || state == 4) break;
        }
    }
    else if (state == 2) {
        for (let i = 0; i < 5; i++) {
            console.log('opening');
            setState(door_action_id, {val: 1, ack: false}); // opening the door

            await wait(30 * 1000);

            state = (await getStateAsync(door_state_id)).val;
            if (state == 2 || state == 3) break;
        }
    }
});

Für gewöhnlich kenne ich es so, dass nur eine der äußeren Bedingung ausgeführt werden, wenn die condition wahr ist. Allerdings scheint es so, dass hier ständig zwischen beiden hin und her geswitcht wird, ohne dass der Trigger auslöst. Dazu mal ein Auszug aus meinem LOG:

>2023-12-28 17:24:46.885  - info: javascript.0 (652) script.js.türschlösser.wohnungstuer: State: 2 ts: 17:24:46
>2023-12-28 17:24:46.885  - info: javascript.0 (652) script.js.türschlösser.wohnungstuer: opening
>2023-12-28 17:24:46.934  - debug: nuki.0 (1424) stateChange nuki.0.480179117.actions.action {"val":1,"ack":false,"ts":1703780686885,"q":0,"c":"script.js.türschlösser.wohnungstuer","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1703780686885}
>2023-12-28 17:24:56.998  - info: javascript.0 (652) script.js.anwesenheiten.anwesenheit: {"default":{"name":"Home","atHome":2,"atHomeID":"0_userdata.0.member.home"},"persons":[{"name":"Phil","atHome":2,"stateID":"mqtt.0.home.member.phil.presence","atHomeID":"0_userdata.0.member.persons.phil"},{"name":"Caro","atHome":2,"stateID":"mqtt.0.home.member.caro.presence","atHomeID":"0_userdata.0.member.persons.caro"},{"name":"Sabrina","atHome":0,"stateID":"mqtt.0.home.member.sabrina.presence","atHomeID":"0_userdata.0.member.persons.sabrina"}]}
>2023-12-28 17:24:57.043  - info: javascript.0 (652) script.js.anwesenheiten.anwesenheit: {"default":{"name":"Home","atHome":2,"atHomeID":"0_userdata.0.member.home"},"persons":[{"name":"Phil","atHome":2,"stateID":"mqtt.0.home.member.phil.presence","atHomeID":"0_userdata.0.member.persons.phil"},{"name":"Caro","atHome":2,"stateID":"mqtt.0.home.member.caro.presence","atHomeID":"0_userdata.0.member.persons.caro"},{"name":"Sabrina","atHome":0,"stateID":"mqtt.0.home.member.sabrina.presence","atHomeID":"0_userdata.0.member.persons.sabrina"}]}
>2023-12-28 17:25:01.231  - info: javascript.0 (652) script.js.türschlösser.wohnungstuer: closing
>2023-12-28 17:25:01.234  - debug: nuki.0 (1424) stateChange nuki.0.480179117.actions.action {"val":2,"ack":false,"ts":1703780701232,"q":0,"c":"script.js.türschlösser.wohnungstuer","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1703780701232}
>2023-12-28 17:25:01.467  - info: javascript.0 (652) script.js.anwesenheiten.anwesenheit: {"default":{"name":"Home","atHome":2,"atHomeID":"0_userdata.0.member.home"},"persons":[{"name":"Phil","atHome":2,"stateID":"mqtt.0.home.member.phil.presence","atHomeID":"0_userdata.0.member.persons.phil"},{"name":"Caro","atHome":2,"stateID":"mqtt.0.home.member.caro.presence","atHomeID":"0_userdata.0.member.persons.caro"},{"name":"Sabrina","atHome":0,"stateID":"mqtt.0.home.member.sabrina.presence","atHomeID":"0_userdata.0.member.persons.sabrina"}]}
>2023-12-28 17:25:16.887  - info: javascript.0 (652) script.js.türschlösser.wohnungstuer: opening
>2023-12-28 17:25:16.890  - debug: nuki.0 (1424) stateChange nuki.0.480179117.actions.action {"val":1,"ack":false,"ts":1703780716888,"q":0,"c":"script.js.türschlösser.wohnungstuer","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1703780716888}
>2023-12-28 17:25:31.232  - info: javascript.0 (652) script.js.türschlösser.wohnungstuer: closing
>2023-12-28 17:25:31.235  - debug: nuki.0 (1424) stateChange nuki.0.480179117.actions.action {"val":2,"ack":false,"ts":1703780731233,"q":0,"c":"script.js.türschlösser.wohnungstuer","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1703780731233}
>2023-12-28 17:25:46.889  - info: javascript.0 (652) script.js.türschlösser.wohnungstuer: opening
>2023-12-28 17:25:46.892  - debug: nuki.0 (1424) stateChange nuki.0.480179117.actions.action {"val":1,"ack":false,"ts":1703780746889,"q":0,"c":"script.js.türschlösser.wohnungstuer","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1703780746889}
>2023-12-28 17:26:01.234  - info: javascript.0 (652) script.js.türschlösser.wohnungstuer: closing
>2023-12-28 17:26:01.237  - debug: nuki.0 (1424) stateChange nuki.0.480179117.actions.action {"val":2,"ack":false,"ts":1703780761234,"q":0,"c":"script.js.türschlösser.wohnungstuer","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1703780761234}

MOD-EDIT: Code in code-tags gesetzt!

Ich hoffe man erkennt es, aber in der Konsole wird nur einmalig state mit Zeitstempel ausgegeben, was soweit auch richtig ist, denn home_id ändert sich auch nur einmalig. Und doch wird ständig zwischen den beiden setState hin und her geswitcht, was zur Folge hat, dass die Tür in unregelmäßigem Muster auf und zu geschlossen wird. Wer kann mir hier weiterhelfen?

Meine Vermutung liegt hierbei darauf, dass die Variable state durch verschiedene Datenpunkte beschrieben wird, allerdings verstehe ich nicht wo das problem liegen könnte, da beides vom Typ Number ist und eigentlich ja auch erst nach der iF - IF ELSE condition neu beschrieben wird.