NEWS
Triggern DP ohne Wert nicht möglich (true/leer)-stiebel-isg
-
@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? -
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.
-
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.
-
@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... -
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.
-
@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.
-
@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. -
@Ralla66 das ist unsinn. Wenn keiner der drei datenpunkte true ist, dann trifft der sonst-fall zu.
-
Unsinn ist falsch,
Richtig ist :
Wenn keiner der drei datenpunkte true ist, dann trifft der sonst-fall zuDer 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.
-
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.
-
@TH-G
Deklarieren und Vorbesetzen das A und O.
5 - nix = 2 geht das ?
Das geht wiederum 5 - x = 2 -
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.
-
@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
-
@TH-G Was sind denn die ganzen Warnungen in deinem Log? Löscht der Adapter die Objekte etwa komplett und nicht nur die Werte? Wechsle mal auf das Log-Tab von ioBroker, da sieht man mehr.
-
Meinst du mit Null auch ein leeres Feld? Denn Null ist ja ein Wert aber ein leeres Feld?
-
@TH-G "Leere" Datenpunkte in ioBroker haben den Wert null. Was ein Problem sein könnte, wäre ein Datenpunkt ohne zugehöriges Objekt (welches dessen Eigenschaften definiert) oder ein Adapter der das Objekt mitlöscht wenn es keinen Wert hat.
-
@AlCalzone sagte in VIS nervt aber warum? Trigger DP ohne Wert?:
"Leere" Datenpunkte in ioBroker haben den Wert null
Bei mir auch nicht:
-
@FredF Du hast einen Default-Wert von "" vergeben (leerer String).
-
Ich würde vom gefühl darauf tippen, dass das Problem Die Trigger sind in dem Skript oben. Wer sagt dir denn, dass wenn einer der Datenpunkte sich ändert nicht mehrere wahr sein können. Wenn es einzelne Datenpunkte sind kann es ja sein, dass zwei davon zur gleichen Zeit auf True stehen und dann wäre das Skript so nicht möglich denke ich. Wenn es tatsächlich so, dass alle beiden Datenpunkte auf False gesetzt werden wenn einer der anderen auf True steht, dann solltest du ein 1000MS Timeout zwischen Trigger und Logik setzen. Für den Fall, dass mehrere Datenpunkte True sein können, aber sich immer nur einer verändert, funktioniert das so nicht. Dann musst du mehrere Blocklys schreiben. Ist aber nur eine Vermutung...
-
@David-Froebus @AlCalzone
Es wird immer nur einer der DP geändert niemals mehrere.
Ich habe Blockly so oft umgebaut das ich nun am Ende bin. Der aktuelle Status wird immer erkannt aber NIEMALS das Ende. Wenn also kein True mehr in einem der drei DP steht wird nicht der Text "nicht aktiv" in meinem DP fürs VIS geschrieben.
Habe es auch mit Timeout probiert und mit mehreren Blocklys.
Es wird im Logikmodul einfach nicht "sonst" ausgeführt.
Für mich ist das ganze Verhalten nicht nachvollziehbar.