[gelöst] Ausführung trotz Triggern Zeitplan

[DJMarc75]

@woupi sagte in Ausführung trotz Triggern Zeitplan:

Meinst Du, dass ich einen neuen Datenpunkt setzten soll, also z.B. Liste_PV_Mittelwert?

Richtig und zwar den DP auch als Liste (Array) anlegen.

Dieser wird dann unten im Skript dann jedesmal mit den neuen Werten geschrieben. So wird bei einem Neustart vom Skript, der Instanz oder der kompletten Maschine gewährleistet dass Du nicht immer bei NULL anfängst

[woupi]

@djmarc75
super, vielen Dank.

Mit der Geschichte String, Number, array usw stehe ich noch total auf Kriegsfuss.
Ich weiß zwar grundsätzlich was was ist, aber immer, oder besser gesagt oft, wenn ich mir sicher bin, das ich z.B. Number nehmen muss, weil es sich um eine Zahl handelt was ich speichern/übergeben möchte, kommt nachher ein Fehler im log und ich mach dann string raus.

Naja irgendwann werde ich das auch noch verstehen.

Wärst Du so lieb und könntest mir das mit dem array bezogen auf die Liste erklären, muss nicht jetzt sein, ich würde es nur gerne verstehen, damit ich nicht jedes mal auf ein neues mit sowas hier um die Ecke komme. Auch was das für Auswirkungen hat, wenn ich das nicht mache, als bei der Variablen habe ich das ja nicht gemacht.

Aber nur wenn Du Lust und Zeit hast.

Danke
VG
Sascha

[DJMarc75]

@woupi sagte in Ausführung trotz Triggern Zeitplan:

Auch was das für Auswirkungen hat, wenn ich das nicht mache, als bei der Variablen habe ich das ja nicht gemacht.

kurz und knapp dazu: eine Variable überlebt keinen SkriptNeustart

@woupi sagte in Ausführung trotz Triggern Zeitplan:

mit dem array bezogen auf die Liste erklären

Array = Liste ... nur halt auf englisch

@woupi sagte in Ausführung trotz Triggern Zeitplan:

Mit der Geschichte String, Number, array usw stehe ich noch total auf Kriegsfuss

String = Zeichenkette (Text und Zahlen usw - alles gemischt)
Number = Zahl - da werden auch nur mathematische Werte akzeptiert
Array = Liste (wie oben kurz erläutert)

Wenn Du an einen DP etwas übergeben willst dann musst Du natürlich wissen was der zu beschreibende DP für ein Typ ist denn nur dieser jeweilige Typus wird erfolgreich übergeben.

Bin jetzt nicht so der Erklärbär und hoffe Dich nicht zu verwirren

[woupi]

@djmarc75 sagte in Ausführung trotz Triggern Zeitplan:

Bin jetzt nicht so der Erklärbär und hoffe Dich nicht zu verwirren

Nein, danke, besser etwas, als gar nichts.

Grob habe ich das so auch schon so gewusst, ich weiß nicht, wo da mein Problem ist.
Ein Beispiel ist eventuell einfacher:

An "SetHeatPump" wird eigentlich nur die Zahl "0" übergeben.
Zuerst habe ich daher den DP "SetHeatPump" als number angelegt.
Leider hat das nicht funktioniert. Der DP hatte dann zwar die 0, aber die Pumpe wurde nicht ausgeschaltet.
Dann habe ich den DP als String angelegt. Dann hat zwar beides funktioniert, nun kam aber im log etwas in der Art, dass ich ein number an einen string übergebe und das in zukünftigen Versionen Probleme verursachen könnte.
Daraufhin habe ich dann noch das "nach String" davor gesetzt und nun sind keine Fehler mehr da und es läuft.

Das Spielchen habe ich dann mit ganz vielen DP.

Warum auch immer.

VG
Sascha

[DJMarc75]

@woupi sagte in Ausführung trotz Triggern Zeitplan:

An "SetHeatPump" wird eigentlich nur die Zahl "0" übergeben.

Dann zeig mal die Objektdaten von dem DP (den Bleistift rechts neben dem DP im Objektbaum anklicken)

[DJMarc75]

@woupi sagte in Ausführung trotz Triggern Zeitplan:

aber die Pumpe wurde nicht ausgeschaltet.

?? diese wird aber nicht in dem von Dir gezeigten Skript gesteuert.
Der DP Deiner Pumpe ist dann wichtig zu sehen, also die Objektdaten - und das Skript in dem Du diesen DP ansteuerst.

[woupi]

@djmarc75

{
  "common": {
    "name": "SetHeatpump",
    "desc": "Manuell erzeugt",
    "role": "variable",
    "type": "string",
    "read": true,
    "write": true,
    "def": ""
  },
  "type": "state",
  "native": {},
  "_id": "mqtt.0.panasonic_heat_pump.commands.SetHeatpump",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1683196270031
}

[woupi]

@djmarc75
Doch, funktioniert auch, also so wie es jetzt da steht.

[DJMarc75]

@woupi sagte in Ausführung trotz Triggern Zeitplan:

"type": "string",

is klar dass der bei Number nicht reagiert und im LOG dann ein Vermerk steht

[woupi]

@djmarc75

Das hast du falsch verstanden, jetzt meckert ja nichts mehr.
Zuerst hatte ich den dp als number angelegt.

[DJMarc75]

@woupi sagte in Ausführung trotz Triggern Zeitplan:

Zuerst hattecich den dp als number angelegt.

Ich sehe da aber nur einen DP unter mqtt welcher als String angelegt ist:

{
  "common": {
    "name": "SetHeatpump",
    "desc": "Manuell erzeugt",
    "role": "variable",
    "type": "string",
    "read": true,
    "write": true,
    "def": ""
  },
  "type": "state",
  "native": {},
  "_id": "mqtt.0.panasonic_heat_pump.commands.SetHeatpump",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1683196270031
}

[woupi]

@djmarc75
Ja logisch, den anderen habe ich da ja auch gelöscht.

Ich habe das was ich gemacht hatte und dann geändert habe, beschrieben, nicht den jetzt Zustand.
Und halt, dass es so wie ich es jetzt habe läuft.
Ich verstehe nur nicht, warum das vorher mit number nicht funktioniert hat.

[DJMarc75]

@woupi sagte in Ausführung trotz Triggern Zeitplan:

Ich verstehe nur nicht, warum das vorher mit number nicht funktioniert hat.

Ich auch nicht, aber das kann man jetzt auch nicht nachvollziehen da es jetzt passt

Da hat im Skript "vorher" iwas halt net gepasst

[woupi]

@djmarc75
Ok, danke.
Also grundsätzlich hätte das so funktionieren müssen, siehst du auch so, richtig?
VG
Sascha

[DJMarc75]

@woupi sagte in Ausführung trotz Triggern Zeitplan:

richtig?

richtig

[Homoran]

@woupi sagte in Ausführung trotz Triggern Zeitplan:

@homoran
Ich gehe davon aus, dass du die logs meinst,
werde versuchen mich dran zu halten, ist ja eigentlich auch einfacher.

ja meine ich!
ich kann jetzt nicht mitspielen, da auf dem Handy das log nicht zu entziffern ist

[woupi]

@homoran

Oh, sorry, das war mir nicht klar.
Bin gerade auch unterwegs, mach ich später.

[DJMarc75]

@woupi sagte in Ausführung trotz Triggern Zeitplan:

mach ich später

mach das in zukünftigen Beiträgen, nicht in diesem Denn hier ist alles geklärt @Homoran und @woupi hat es verstanden !!

[woupi]

@djmarc75
leider nein, bin gerade nach Hause gekommen und es wurde zum ersten Mal seit fast 4 Wochen nicht wie gewollt WW bereitet.
Warum konnte ich jetzt auf die schnelle noch nicht herausfinden.
Es gibt zwar einen Fehler, der kann mit dem WW aber nichts zutun haben, das hätte bereits um 14:00 starten sollen.

Da muss ich morgen Früh mal in Ruhe bei schauen, aber eventuell kann sich ja mal einer den Fehler ansehen:

2023-05-20 16:01:00.003 - error: javascript.0 (1020) script.js.Wärmepumpe.WP_Steuerung: TypeError: Cannot read property 'push' of null
2023-05-20 16:01:00.004 - error: javascript.0 (1020) at Object.cb (script.js.Wärmepumpe.WP_Steuerung:77:12)
2023-05-20 16:01:00.004 - error: javascript.0 (1020) at Immediate. (/opt/iobroker/node_modules/iobroker.javascript/lib/scheduler.js:89:109)
2023-05-20 16:01:00.004 - error: javascript.0 (1020) at processImmediate (internal/timers.js:466:21)

Hier der geänderte Schnipsel:

[Homoran]

@woupi Schnipsel bringen normalerweise nichts.

Aber tausch erst einmal den Zeitplan gegen einen eifachen CRON