Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Chrunchy]

Ich würde auch auf Änderung prüfen, nicht auf Aktualisierung.

Ich kenne das Gerät nicht, würde aber vermuten, dass sich der Betriebsstatus mehr oder weniger zeitgleich bei Kühlen und Heizen aktualisiert, was dann dazu führt, dass das Script ja quasi zeitgleich doppelt getriggert wird. Deshalb change von "any" auf "ne" setzten.

Ansonsten würde ich erstmal ins Log Debuggen um zu sehen was überhaupt abgearbeitet wird.

[AlCalzone]

Das Problem ist, dass 3 verschiedene Trigger den gleichen Datenpunkt nutzen. Wird jetzt z.B. erst HEIZEN wahr, dann KÜHLEN falsch, dann wird in den Datenpunkt erst ganz kurz "Heizen" geschrieben, dann " ".

Du musst alles in einen Trigger verpacken. Hier nur Pseudocode, da kein Blockly zur Hand:

Trigger auf HEIZEN, KÜHLEN und WARMWASSER:
  Falls HEIZEN ist wahr, dann setze STATUS auf "Heizen"
  Sonst falls KÜHLEN ist wahr, dann setze STATUS auf "Kühlen"
  Sonst falls WARMWASSER ist wahr, dann setze STATUS auf "Warmwasser"
  Sonst setze STATUS auf ""

So ist sichergestellt, dass immer nur einer der Stati gültig ist.

[TH G]

@AlCalzone

Perfekt das wars, Danke

[TH G]

@AlCalzone

Leider funktioniert es auch nicht richtig. Es wird zwar sauber bei Kühlung in den Datenpunkt "Kühlen" reingeschrieben aber wenn das Kühlen vorbei ist wird nicht der andere Wert "nicht aktiv" reingeschrieben und es bleibt "Kühlen" im DP stehen.

[OstfrieseUnterwegs]

Die DP, auf die Du triggerst werden ja nicht alle exakt gleichzeitig gesetzt. Je nachem, welcher zuletzt im Adapter ankommt und vom Adapter gesetzt wird, der gewinnt.
Ich würde mal eine kleine Pause einbauen (mit Timeout Baustein) und damit sozusagen auf einen stabilen Zustand warten. Vlt 2 Sekunden oder so. Wie genau muss ein Timeout-Spezialist sagen :-)

[TH G]

@OstfrieseUnterwegs

Es ist doch egal wann was getriggert wird.

Wenn die Anlage Kühlt steht im DP des Adapters "True" und bei den anderen steht nichts. Also wird der Text "Kühlen" in meinen DP fürs VIS reingeschrieben.

Wenn Kühlen beendet ist steht in keinem der DP etwas, also müsste dann in meinem DP fürs VIS "nicht aktiv" reingeschrieben werden.

Bei Heizen und Warmwasser läuft es gleich ab aber er macht es nicht.

[Ralla66]

@TH-G

Frage doch false ab.
Wenn kühlen + heizen + WW ist false aktuallisiere DP mit nicht aktiv.

Nichts in den 3 Datenpunkten auch nicht gut da -> nichts <- nicht ausgewertet werden kann.
Schreibe da false rein wenn nicht wahr.

[AlCalzone]

@TH-G sagte in VIS nervt aber warum?:

Es wird zwar sauber bei Kühlung in den Datenpunkt "Kühlen" reingeschrieben aber wenn das Kühlen vorbei ist wird nicht der andere Wert "nicht aktiv" reingeschrieben

Logge doch mal die Änderungen der Datenpunkte. Scheint mir als würden die anderen nicht aktiv werden, wenn Kühlen vorbei ist.
Und sollten sie es überhaupt oder hast du ne Hysterese?

[TH G]

@AlCalzone @Ralla66

Also eigentlich funktioniert es und der aktuelle Status wird richtig in meinen DP geschrieben.

Was nicht geht ist, wenn alles vorbei ist und es keinen Wert "True" mehr in den drei DP des Adapters gibt, wird nicht die letzte Bedingung (mache) ausgeführt, den Text "nicht aktiv" in meinen DP reinzuschreiben.

[OstfrieseUnterwegs]

Verschiebe doch deine 'sonst' Anweisung vor den ganzen Falls-Block. Dann setzt du auf jeden Fall erstmal auf 'nicht aktiv' und danach werden deine Wenns abgearbeitet. Wenn keines zutrifft, bleibt er eben auf 'nicht aktiv'. Das erklärt zwar nicht, warum dein Script nicht macht, was man erwarten würde, könnte aber eine Lösung sein.

[AlCalzone]

@TH-G @OstfrieseUnterwegs Ich vermute eher dass der Trigger gar nicht erst ausgelöst wird. Oder wir rennen hier in das Problem, dass die erneuten Abfragen im Trigger einen alten Wert zurückgeben.
Von daher wäre Logging mal gut...

[TH G]

@AlCalzone

Es steht leider nichts im Log.

Ich habe weiter verschiedenen Versionen mit Blockly getestet es geht einfach nicht. Auch den Vorschlag von @OstfrieseUnterwegs bringt leider nichts.

Es sieht so aus, als wenn es keinen Trigger gibt weil die Felder vom Adapter leer sind.

[AlCalzone]

@TH-G sagte in VIS nervt aber warum?:

weil die Felder vom Adapter leer sind.

Vielleicht kannste die mal mit dem History-Adapter aufzeichnen, um nachzuvollziehen, was in welcher Reihenfolge passiert.

[Ralla66]

@TH-G sagte in VIS nervt aber warum?:

Es sieht so aus, als wenn es keinen Trigger gibt weil die Felder vom Adapter leer sind.

Dann fülle diese wie oben beschrieben mit false.
Trigger auf -> wurde aktuallisiert -<.

Auf was soll denn -> sonst <- reagieren , auf -> Nichts -< im DP geht nicht.
Letzt endlich findet ja kein Vergleich statt.
Kann das Programm gar nicht.
Deklarieren und Vorbesetzen das A und O.

[AlCalzone]

@Ralla66 das ist unsinn. Wenn keiner der drei datenpunkte true ist, dann trifft der sonst-fall zu.

[Ralla66]

@AlCalzone

Unsinn ist falsch,
Richtig ist :
Wenn keiner der drei datenpunkte true ist, dann trifft der sonst-fall zu

Der sonst Fall:
Ab in die Routine, wenn nix da ist kannste nix vergleichen oder sonst was.
Dachte immer bis jetzt Routinen sind Logisch aufgebaut.

Prog mal NIX, dann weißte wie groß das wird.

[TH G]

@AlCalzone @Ralla66

Also es funktioniert tadellos wenn ich als Trigger einen Zeitintervall nehme. Allerdings müllen mit die Warnungen den Log voll und das möchte ich nicht.

Für mich ist es nun eindeutig.

Es kann nicht getriggert werden, wenn der Trigger DP nach einem Wert keinen Wert mehr hat.

Die Frage ist jetzt nur, ist das ein iobroker oder Adapter Fehler, denn so sollte das Verhalten nicht sein.

[Ralla66]

@TH-G
Deklarieren und Vorbesetzen das A und O.
5 - nix = 2 geht das ?
Das geht wiederum 5 - x = 2

[TH G]

@Ralla66

Ich bin der Meinung, wenn eine leeres Feld nicht als Trigger dienen kann und "leer" ist in meinen Augen auch ein Zustand, dann sollte das über den Adapter abgefangen werden oder mit einem Zustand versehen werden.

[AlCalzone]

@TH-G Ein leeres Feld (Wert null) kann definitiv als Trigger dienen.

createState("testwert", () => {

    on("testwert", obj => {
        log(obj.state.val);
    });

    setTimeout(() => {
        setState("testwert", true);
    }, 1000);

    setTimeout(() => {
        setState("testwert", null);
    }, 2000);

    setTimeout(() => {
        setState("testwert", true);
    }, 3000);

});

Log-Ausgabe:

javascript.0	2020-06-27 11:43:12.329	info	(1052) script.js.Testtest: true
javascript.0	2020-06-27 11:43:11.329	info	(1052) script.js.Testtest: null
javascript.0	2020-06-27 11:43:10.333	info	(1052) script.js.Testtest: true
javascript.0	2020-06-27 11:43:09.237	info	(1052) script.js.Testtest: registered 0 subscriptions and 0 schedules
javascript.0	2020-06-27 11:43:09.200	info	(1052) Start javascript script.js.Testtest

---

@Ralla66 ich weiß gar nicht warum du überhaupt diskutierst. Vergleiche mit "NIX" funktionieren einwandfrei. null ist schließlich auch nur ein bestimmter Wert:

Welcome to Node.js v12.16.3.
Type ".help" for more information.
> null === true
false