Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[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

[AlCalzone]

@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.

[TH G]

@AlCalzone

Meinst du mit Null auch ein leeres Feld? Denn Null ist ja ein Wert aber ein leeres Feld?

[AlCalzone]

@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.

[FredF]

@AlCalzone sagte in VIS nervt aber warum? Trigger DP ohne Wert?:

"Leere" Datenpunkte in ioBroker haben den Wert null

Bei mir auch nicht:

[AlCalzone]

@FredF Du hast einen Default-Wert von "" vergeben (leerer String).

[Dragon]

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...

[TH G]

@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.

[AlCalzone]

@TH-G sagte in VIS nervt aber warum? Trigger DP ohne Wert?:

Für mich ist das ganze Verhalten nicht nachvollziehbar.

Für mich auch nicht. Ich habe dich zwar mehrfach nach Logs oder so gefragt, dass man die verschiedenen Zustände nachvollziehen kann, aber keine bekommen.

[FredF]

@AlCalzone sagte in VIS nervt aber warum? Trigger DP ohne Wert?:

@FredF Du hast einen Default-Wert von "" vergeben (leerer String).

Ja, beim manuellen Anlegen wird das auch nicht abgefragt.
Mit vergabe des Default-Wertes:

{
  "_id": "0_userdata.0.Neues_Objekt",
  "type": "state",
  "common": {
    "name": "Neues Objekt",
    "role": "",
    "type": "string",
    "read": true,
    "write": true,
    "desc": "Manuell erzeugt",
    "def": "null"
  },
  "native": {},
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1593265553701,
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Ist die Ausgabe aber genau so

[TH G]

@AlCalzone

Ich weiss aber ich finde keine Logs dazu, das ist mein Problem.

[AlCalzone]

@TH-G Du könntest z.B. mit dem history-Adapter alle States mitschreiben.

@FredF Wenn der State schon existiert, bringt eine Änderung des Default-Wert nichts mehr. Außerdem ist der String "null" ungleich null.