Triggern DP ohne Wert nicht möglich (true/leer)-stiebel-isg

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

[apollon77]

@fastfoot Sagen wir es mal so: Er kann einen "anderen" wert haben

[TH G]

@AlCalzone

So funktioniert es jetzt:

[AlCalzone]

@TH-G Du solltest zusätzlich vor dem Ausführen des Intervalls einen Stop erzwingen. Sonst kann es sein, dass Kopien des Intervalls laufen, die sich mit der Zeit anhäufen.

[TH G]

@alcalzone

Hallo, ich muss das Thema nochmals aktivieren.

Ich bekommen massenweise Warnungen im Log und ich würde das gerne lösen.

So sieht es derzeit aus:

Ich brauche bitte nochmals Hilfe was ich tun kann.

[fastfoot]

@th-g said in Triggern DP ohne Wert nicht möglich (true/leer)-stiebel-isg:

Ich brauche bitte nochmals Hilfe was ich tun kann.

Im Tab Log findest du mehr Infos, welche sind das? Ausserdem solltest du, anstatt den Wert von Heizung nochmals auszulesen, den tatsächlichen Wert benutzen, zu finden im Trigger Block.