Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

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

[FredF]

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

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

Ok. Einen Default-Wert kann aber beim manuellen Anlegen eines Objekts dennoch nicht mitgeben werden.

[TH G]

@AlCalzone

Der History Adapter überfordert mich leider, sorry

Gibt es eine alternative Möglichkeit?

[Homoran]

@AlCalzone
Es gab schon mal einen Thread in dem ein State nicht true/false hatte sondern nur true/"leer"
Ich glaube da ging es um KNX - bin mir aber nicht sicher.

Ich glaube auch da war ein Triggern nicht möglich.

@TH-G
Was hat das ganze mit dem Titel vis nervt zu tun?

[TH G]

@Homoran

Das war der Auslöser mit VIS, dass es aber nun doch so ein anderes Problem ist, war nicht abzusehen. Hatte die Überschrift schon angepasst und werde das nun nochmal machen.

[AlCalzone]

@TH-G sagte in Triggern DP ohne Wert nicht möglich (true/leer)-stiebel-isg:

Der History Adapter überfordert mich leider, sorry

Ist nicht schwer... Neben dem Datenpunkt, den du überwachen willst (in deinem Fall die 3) ganz rechts auf den Schraubenschlüssel klicken.
Dort dann den Haken bei "aktiviert" setzen. Standardeinstellungen kannst du sonst lassen.

Im Tab "Tabelle" siehst du dann die Änderungen:

[TH G]

@AlCalzone

History Adapter schau ich mir dann nochmal an :-)

Ich habe es gerade nochmals genau beobachtet

Ich habe nun für die drei DP eigene Blocklys angelegt wie

on({id: "stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.WARMWASSERBEREITUNG"/*WARMWASSERBEREITUNG*/, change: "any"}, function (obj) {
  var value = obj.state.val;
  var oldValue = obj.oldState.val;
  if (getState("stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.WARMWASSERBEREITUNG").val == true) {
    setState("0_userdata.0.Status_WP"/*Status_WP*/, 'Warmwasser', true);
  } else {
    setState("0_userdata.0.Status_WP"/*Status_WP*/, 'nicht aktiv', true);
  }
});

Es wird wenn "True" in STATUS.BETRIEBSSTATUS.WARMWASSERBEREITUNG steht auch der Text in meinen DP für VIS geschrieben.

Ändert sich aber der Status von True auf "Nichts" wird im Logikmodul nicht "Sonst" ausgeführt.

Im Log steht nur das:

javascript.0 2020-06-29 10:02:00.303 info (1584) script.js.common.Tecalor_Betriebsart_Aktuell_Warmwasser: registered 1 subscription and 0 schedules
javascript.0 2020-06-29 10:02:00.299 info (1584) Start javascript script.js.common.Tecalor_Betriebsart_Aktuell_Warmwasser

[Chrunchy]

@TH-G Versuch es doch mal so...

on({id: "stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.WARMWASSERBEREITUNG"/*WARMWASSERBEREITUNG*/, change: "any"}, function (obj) {
  var value = obj.state.val;
  var oldValue = obj.oldState.val;
  var tmp = "nicht aktiv";
  if (getState("stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.WARMWASSERBEREITUNG").val == true) {
    tmp = "Warmwasser";
  } setState("0_userdata.0.Status_WP"/*Status_WP*/, tmp, true);
});

[AlCalzone]

@TH-G Ich glaube ich weiß was das Problem ist.
Der Adapter nutzt die expire-Funktion, um states automatisch nach gewisser Zeit zurück (auf null) zu setzen. Scheint als bekommt der JS-Adapter diese Änderung nicht mit. Ich hör mich mal um, was man da tun kann.

Workaround wäre tatsächlich ein Intervall zusätzlich zum Trigger.

[TH G]

@AlCalzone

Danke

Wo würdest du denn den Intervall im Blockly einbauen?

So geht es leider nicht:

[apollon77]

Äääähm Leute ... bitte baut mal das getState da aus aus dem Trigger!

Wenn ein "on" Trigger triggert kann es sein das "getState" noch den alten Wert hat. Immer das übergebene State object nutzen!

Also:

on({id: "stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.WARMWASSERBEREITUNG"/*WARMWASSERBEREITUNG*/, change: "any"}, function (obj) {

  var value = obj.state.val;

  var oldValue = obj.oldState.val;

  var tmp = "nicht aktiv";

  if (value == true) {

    tmp = "Warmwasser";

  } setState("0_userdata.0.Status_WP"/*Status_WP*/, tmp, true);

});

[fastfoot]

@apollon77 sagte in Triggern DP ohne Wert nicht möglich (true/leer)-stiebel-isg:

Äääähm Leute ... bitte baut mal das getState da aus aus dem Trigger!

Wenn ein "on" Trigger triggert kann es sein das "getState" noch den alten Wert hat. Immer das übergebene State object nutzen!

Hallo, bisher hörte ich in Diskussionen immer, dass der State dann evtl schon einen neuen Wert hat und man es deshalb unterlassen sollte, mal davon abgesehen dass man eh den Wert, der schon mitgeliefert wird, nehmen sollte. Könntest du den Sachverhalt bitte etwas näher erläutern? Im Moment des GetState() wurde der Triggerwert doch schon ermittelt, wie kann man da noch den alten Wert bekommen? Danke!