[GELÖST] Zeitplan arbeitet überhaupt nicht

[ticaki]

@stefan-falt
Der Zeit plan wird wohl gehen nur deine Annahme wie es abläuft ist wohl falsch...

Im log steht 1 dann 6 und irgendwann wenn der Zeitplan läuft die anderen Zahlen, aber sehe nicht was du da alles eingestellt hast.

[Stefan Falt]

@ticaki hi, danke für deine Zeit.
Das sieht man in einem Bild im ersten Post.

[ticaki]

@stefan-falt

und der läuft nicht um 22:00/22:01? usw?

[DJMarc75]

@stefan-falt Sind das eigene erstellte Datenpunkte welche Du beschreibst ? Falls nein verwende nicht "aktualisiere" sondern "steuere" Blöcke.

[Blockmove]

@stefan-falt
Nimmt man deinen Screenshot, dann stimmt das Verhalten.
Dein Zeitplan wird 1mal in der Minute ausgeführt.
Wenn du das Script startest, dann passt der Ablauf so mit Debug 1->6.
Debug 2->5 sollten dann bei jedem Minutenwechsel (22:01:00,22:02:00,...) erscheinen

[Codierknecht]

@stefan-falt sagte in Zeitplan arbeitet überhaupt nicht:

Ja, die sollen minürlich Ausgeführt werden. Wenn Batterie SOC <40% dann soll Schluss sein mit Auto laden.

Wozu mit einem Zeitplan, der wohl die meiste Zeit nix macht - außer Rechenzeit zu beanspruchen.

Mach das über einen Trigger, der bei Änderung von Batterie SOC feuert.
Wenn der Wert unter 40% sinkt, wird abgeschaltet.

Und wie @DJMarc75 schon schreibt: "Aktualisiere" nur für eigene Datenpunkte.
DP eines Adapters werden mit "Steuere" beschrieben.

[Jan1]

@codierknecht sagte in Zeitplan arbeitet überhaupt nicht:

Und wie @DJMarc75 schon schreibt: "Aktualisiere" nur für eigene Datenpunkte.
DP eines Adapters werden mit "Steuere" beschrieben.

Das hat mit eigenen und Adapter DPs wenig zu tun. "Steure" tut was aktiv, "aktualisieren" schreibt lediglich den neuen Wert rein und sonst nix und das ist bei jeden DP so, somit kann man das überall nutzen, wenn man weiß was man machen möchte und wo der Unterschied liegt.

[Homoran]

@jan1 sagte in Zeitplan arbeitet überhaupt nicht:

@codierknecht sagte in Zeitplan arbeitet überhaupt nicht:

Und wie @DJMarc75 schon schreibt: "Aktualisiere" nur für eigene Datenpunkte.
DP eines Adapters werden mit "Steuere" beschrieben.

Das hat mit eigenen und Adapter DPs wenig zu tun. "Steure" tut was aktiv, "aktualisieren" schreibt lediglich den neuen Wert rein und sonst nix und das ist bei jeden DP so, somit kann man das überall nutzen, wenn man weiß was man machen möchte und wo der Unterschied liegt.

nein, so ist das nicht!
steuere sendet mit ACK=false
aktualisiere mit ACK=true

Der Adapter, der ein Geröt steuern soll erkennt am fehlenden ACK, dass er was zu tun hat. Das erledigt er und setzt anschließend das ACK auf true, damit angezeigt wird, dass gearbeitet wurde und dies beendet ist.

[Jan1]

@homoran
ich weiß wie das funktioniert und hat eben bei jedem DP die gleiche Funktion, somit ist das nicht wirklich nur für eigene DPs und darum gehts. wenn ich nur was drin stehen haben will, dann nehme ich eben aktualisiere und da ist es mir erst mal egal was für dein DP das ist.
Wenn man den Unterschied kennt, dann wundert man sich auch nicht, dass man bei "aktualisieren" keine direkte Aktion zu erwarten braucht und so ist es!
Ist beim manuellen Setzen des DP ja genau so, wenn man da mit, oder ohne "bestätigt" macht, somit brauchst mir das nicht erklären.

[Homoran]

@jan1 sagte in Zeitplan arbeitet überhaupt nicht:

wenn ich nur was drin stehen haben will, dann nehme ich eben aktualisiere und da ist es mir erst mal egal was für dein DP das ist.

umgekehrt wäre es nachvollziehbar!

ein Adapter-DP benötigt zwingend steuere, (wenn darüber etwas gesteuert wird).
Aber nicht steuete macht etwas aktiv, sondern der Adapter reagiert aktiv darauf.

[haus-automatisierung]

@jan1 sagte in Zeitplan arbeitet überhaupt nicht:

ich weiß wie das funktioniert und hat eben bei jedem DP die gleiche Funktion, somit ist das nicht wirklich nur für eigene DPs

Genau deswegen ist "aktualisiere" nur für eigene Datenpunkte sinnig.

Warum sollte man bestätigte Werte in Namespaces von Adaptern schreiben? Das ergibt in keinem Szenario einen Sinn.

[Jan1]

@haus-automatisierung
Nur weil Dir dazu nichts einfällt, heißt das nicht, dass man das nur dort nutzen darf und darum gehts.

Es wurde geschrieben, "nur für eigene Datenpunkte" und das ist falsch. Ob das dann Sinn macht, oder nicht, entscheidet derjenige der darin ein Sinn sieht, recht einfach

Hier wurde grundsätzlich der Unterschied nicht erkannt und deshalb funktioniert das Script nicht, wobei wie erkannt, das ganze über Zeitplan eh nicht wirklich sinnvoll ist und wenn unbedingt mit Zeitplan, dann als CRON, weil der wenigstens immer funktioniert.

[Stefan Falt]

@ticaki said in Zeitplan arbeitet überhaupt nicht:

und der läuft nicht um 22:00/22:01? usw?

Ja, das ist so. Der Zeitplan läuft nicht, bzw. Ich würde erwarten dass jede Minute Debugpunkt "2" kommt, es passiert aber nichts.

[Stefan Falt]

@jan1 said in Zeitplan arbeitet überhaupt nicht:

... wobei wie erkannt, das ganze über Zeitplan eh nicht wirklich sinnvoll ist und wenn unbedingt mit Zeitplan, dann als CRON, weil der wenigstens immer funktioniert.

Hallo, danke für deine Zeit. Warum funktioniert Zeitplan nicht, aber CRON? Ist die Funktion defekt?
Ich will nur jede Minute mal was prüfen - die Register Ändern ... das kommt eigentlich später.

[Stefan Falt]

@codierknecht said in Zeitplan arbeitet überhaupt nicht:

Mach das über einen Trigger, der bei Änderung von Batterie SOC feuert.
Wenn der Wert unter 40% sinkt, wird abgeschaltet.

Ich denke das ist keine gute Idee. Das Laden soll ja um 22:00 Uhr beginnen. Der Ruhestrom im Haus (Mal von Kühlschrank abgesehen) ist 50 Watt. Deshalb könnte Rechnerisch erst knapp drei Stunden später das erste mal der SOC geändert werden und das Laden beginnen.
Außerdem glaube ich nicht, dass ein Timer jede Minute so viel Ressourcen braucht.

Und wie @DJMarc75 schon schreibt: "Aktualisiere" nur für eigene Datenpunkte.
DP eines Adapters werden mit "Steuere" beschrieben.

Das werde ich tun.

Danke für Deine Zeit.

[Blockmove]

@haus-automatisierung said in Zeitplan arbeitet überhaupt nicht:

@jan1 sagte in Zeitplan arbeitet überhaupt nicht:

ich weiß wie das funktioniert und hat eben bei jedem DP die gleiche Funktion, somit ist das nicht wirklich nur für eigene DPs

Genau deswegen ist "aktualisiere" nur für eigene Datenpunkte sinnig.

Warum sollte man bestätigte Werte in Namespaces von Adaptern schreiben? Das ergibt in keinem Szenario einen Sinn.

Die Aussage ist zu pauschal.
Folgendes Szenario:
Ein Adapter soll mehrere Werte mit einem Übernahmesignal senden.
Bei den einzelnen Werten muss der Adapter erstmal gar nichts machen.
Also können die bestätigt sein.
Erst wenn das Übernahmesignal kommt, muss der Adapter aktiv werden.
Also reicht es wenn das Übernahmesignal nicht bestätigt ist und die Aktion auslöst.

Fazit: In der Automatisierung gibt ist nicht nur schwarz und weiß

[haus-automatisierung]

@blockmove sagte in Zeitplan arbeitet überhaupt nicht:

Ein Adapter soll mehrere Werte mit einem Übernahmesignal senden.
Bei den einzelnen Werten muss der Adapter erstmal gar nichts machen.
Also können die bestätigt sein.

Dann ist der Adapter aber nicht gut implementiert. Angenommen das Übermitteln des Befehls funktioniert nicht, dann würden da jede Menge bestätigte Werte stehen, die falsch sind. Das ist gegen das Konzept des ack-flags. Ich kenne keinen Adapter der so arbeitet - gibt es da einen?

Wenn das die Anforderung ist, wäre es viel schlauer die ganzen Werte unbestätigt zu setzen und dann mit einem weiteren Datenpunkt die Übermittlung anzustoßen. Dann könnte der Adapter auch nur das übermitteln was unbestätigt ist und übermittelt werden soll. Und die einzelnen Werte könnten validiert und bestätigt werden.

Alternativ könnte man auch ein JSON mit den Werten auf einem Datenpunkt unbestätigt schreiben. Oder in einem anderen Format.

Man kann ja bewusst nur unbestätigte Werte auf Datenpunkte schreiben, welche mit write: true definiert sind. Die anderen verwaltet der Adapter selbst.

Siehe auch https://forum.iobroker.net/topic/61876/bestätigt-acknowledged-flag-bedeutung-ein-mysterium

[Stefan Falt]

@blockmove Hallo,
inzwischen habe ich rausgefunden woran es liegt, dass mein Zeitplan nicht geht:
Er wurde von mir von 22:00 bis 05:00 Uhr eingestellt.

Hier soll die Lösung zum Problem sein:
https://forum.iobroker.net/topic/21132/blockly-zeitplan-intervallspanne-22h-4h

Jetzt muss ich nur noch rausfinden, wie ich diesen CRONn Ausdruck editieren kann ...

[Codierknecht]

@stefan-falt sagte in [GELÖST] Zeitplan arbeitet überhaupt nicht:

Wenn Batterie SOC <40% dann soll Schluss sein mit Auto laden.

Also ich würde das prinzipiell so machen:

Trigger wäre die Batterieladung.
Solange die größer als 40% ist und nicht Nacht, wird geladen.

So zumindest habe ich die Aufgabe verstanden.

[Blockmove]

@codierknecht said in [GELÖST] Zeitplan arbeitet überhaupt nicht:

@stefan-falt sagte in [GELÖST] Zeitplan arbeitet überhaupt nicht:

Wenn Batterie SOC <40% dann soll Schluss sein mit Auto laden.

Also ich würde das prinzipiell so machen:

Trigger wäre die Batterieladung.
Solange die größer als 40% ist und nicht Nacht, wird geladen.

So zumindest habe ich die Aufgabe verstanden.

Die ursprüngliche Aufgabe war:
Zwischen 22 und 5Uhr soll geladen werden solange der SOC > 40% ist.

Deine Lösung ist davon abhängig dass der SOC regelmässig aktualisiert wird.
Ist dies nicht der Fall, passiert um 22Uhr nix.