Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[paul53]

@TH-G sagte:

Wenn ich dein Script nach Zeile 63 einbaue, würde es doch zyklisch abgefragt werden oder?

Ja, das wäre aber kontraproduktiv. Mein Vorschlag passt die Variable grundlast per Trigger an, wenn sich der Status von Kühlen ändert. Bau es anstelle der leeren Zeile 62 ein.

if(getState('stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.KUEHLEN').val) grundlast +=  3000;
on('stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.KUEHLEN', function(dp) { // triggert bei Änderung des Status Kühlen
    if(dp.state.val) grundlast += 3000;
    else grundlast -= 3000;
});

// ab hier Programmcode, nichts ändern!
function processing() {

@TH-G sagte in Bitte Hilfe beim Erstellen einer kleinen Programmzeile:

Woher weiss das Skript das Kühlung aktiv ist?

Weil dann der Wert des Datenpunktes true ist.

[TH G]

@paul53

Habe ich in Zeile 62 eingefügt. Folgende Warnung kommt dann:

7.8.2020, 16:14:46.668 [info ]: javascript.0 (31544) Stop script script.js.common.SMA_Bat_Regelung_2_1
7.8.2020, 16:14:46.682 [info ]: javascript.0 (31544) Start javascript script.js.common.SMA_Bat_Regelung_2_1
7.8.2020, 16:14:46.731 [warn ]: javascript.0 (31544) at script.js.common.SMA_Bat_Regelung_2_1:62:4
7.8.2020, 16:14:46.735 [info ]: javascript.0 (31544) script.js.common.SMA_Bat_Regelung_2_1: registered 1 subscription and 0 schedules

[paul53]

@TH-G
Ich hatte getState falsch geschrieben (inzwischen korrigiert).

[TH G]

@paul53

Warnung ist immer noch da:

// PV-WR Register Definition, nur bei Bedarf anpassen
  var PV_Dev_Type = ModBusPV + ".inputRegisters.30053_DevTypeId", /*Typnummer*/
      PVWR_limit = ModBusPV + ".holdingRegisters.41255_WNomPrc";
      
if(getState('stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.KUEHLEN').val) grundlast +=  3000;
on('stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.KUEHLEN', function(dp) { // triggert bei Änderung des Status Kühlen
    if(dp.state.val) grundlast += 3000;
    else grundlast -= 3000;
});

// ab hier Programmcode, nichts ändern!
function processing() {
// Start der Parametrierung

[paul53]

@TH-G sagte:

Warnung ist immer noch da

Schau mal im Tab "Log" nach. Dort gibt es meist mehr Informationen. Ist die Datenpunkt-ID richtig geschrieben ?

[TH G]

@paul53

Ja der DP ist richtig: stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.KUEHLEN

javascript.0 2020-08-07 16:25:44.150 warn (31544) at script.js.common.SMA_Bat_Regelung_2_1:62:4
javascript.0 2020-08-07 16:25:44.145 warn (31544) getState "stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.KUEHLEN" not found (3)

[paul53]

@TH-G sagte:

"stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.KUEHLEN" not found (3)

Die Warnung sagt aus, dass der Datenpunkt nicht gefunden wurde.

[TH G]

@paul53

Verstehe aber er ist da und nutze diesen auch für VIS und da wird es richtig angezeigt.

Der DP ist auch über die Kopierfuktion kopiert worden, damit es keine Schreibfehler gibt.

[paul53]

@TH-G
Poste mal die RAW-Ansicht des Objektes in Code tags.

[TH G]

@paul53

Hallo Paul,

es gab für VIS damals auch das Problem, das es nicht möglich ist, ein leeres Feld zu triggern. Kann das hier auch das Problem sein?

https://forum.iobroker.net/topic/34677/triggern-dp-ohne-wert-nicht-möglich-true-leer-stiebel-isg/53

AlCalzone schrieb damals dazu:

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.

{
  "from": "system.adapter.stiebel-isg.0",
  "user": "system.user.admin",
  "ts": 1592375626112,
  "common": {
    "name": "KÜHLEN",
    "type": "boolean",
    "unit": "",
    "role": "indicator.state",
    "read": true,
    "write": false
  },
  "native": {},
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "_id": "stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.KUEHLEN",
  "type": "state"
}

[paul53]

@TH-G
Wird der Datenpunkt vom Adapter "stiebel-isg" erzeugt und geschrieben ? Dann erstelle ein Issue auf Github, dass der Wert nur false und true enthalten darf und nicht null.

[TH G]

@paul53

Das Thema ist schon mehrfach angesprochen worden und es scheint keine Lösung dafür zu geben.

So ist es ja für VIS gelöst worden. Kann man daraus nicht etwas auch für das Problem hier nutzen?

var Intervall;


on({id: "stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.KUEHLEN"/*KÜHLEN*/, change: "ne"}, function (obj) {
  var value = obj.state.val;
  var oldValue = obj.oldState.val;
  Intervall = setInterval(function () {
    if (getState("stiebel-isg.0.Info.STATUS.BETRIEBSSTATUS.KUEHLEN").val == true) {
      setState("0_userdata.0.Status_WP"/*Status_WP*/, 'Kühlen', true);
    } else {
      setState("0_userdata.0.Status_WP"/*Status_WP*/, 'nicht aktiv', true);
      (function () {if (Intervall) {clearInterval(Intervall); Intervall = null;}})();
    }
  }, 1000);
});

z.B. mit dem DP 0_userdata.0.Status_WP

Dort gibt es folgende Texteinträge:

Kühlen
Heizen
Warmwasser
nicht aktiv

[paul53]

@TH-G sagte:

mit dem DP 0_userdata.0.Status_WP

Dieser Datenpunkt zeigt immer den richtigen Zustand an ? Dann ändere es so:

if(getState('0_userdata.0.Status_WP').val == 'Kühlen') grundlast +=  3000;
on('0_userdata.0.Status_WP', function(dp) { // triggert bei Änderung des Status
    if(dp.state.val == 'Kühlen') grundlast += 3000;
    else grundlast = 550;
});

[TH G]

@paul53

Ja der stimmte bisher immer :-)

Habe ich geändert und keine Fehlermeldung mehr.

Ich werde das nun testen

Vielen Dank für deine Hilfe und Ausdauert!

[TH G]

@paul53

Erste Anwendung hat schon geklappt und die Grundlast wurde erhöht