Monatsrückblick Januar/Februar 2026 ist online!

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

[Codierknecht]

@blockmove sagte in [GELÖST] Zeitplan arbeitet überhaupt nicht:

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

Um 22:00 Uhr nicht. Aber der Wert wird sich ja ziemlich regelmäßig ändern.
Ob das Laden dann um 22:05 oder um 22:17 startet, dürfte ja reichlich Wumpe sein.

Dann kommen da halt noch 2 Zeitplan-Trigger hinzu.

• Um 22:00 Uhr einschalten, falls SOC > 40%
• Um 05:00 Uhr auf jeden Fall abschalten

Ich bin mir aber ziemlich sicher, dass das so völlig stabil und ohne Probleme läuft.

[Blockmove]

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

@blockmove sagte in [GELÖST] Zeitplan arbeitet überhaupt nicht:

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

Um 22:00 Uhr nicht. Aber der Wert wird sich ja ziemlich regelmäßig ändern.
Ob das Laden dann um 22:05 oder um 22:17 startet, dürfte ja reichlich Wumpe sein.

Dann kommen da halt noch 2 Zeitplan-Trigger hinzu.

• Um 22:00 Uhr einschalten, falls SOC > 40%
• Um 05:00 Uhr auf jeden Fall abschalten

Ich bin mir aber ziemlich sicher, dass das so völlig stabil und ohne Probleme läuft.

Klar selbst mit vermeintlich einfachen Regeln kann man bei ioBroker und Javascript schnell Instabilitäten bekommen.
Deshalb wurden ja auch die Async-Funktionen eingeführt.
Ich hab irgendwann mal mein Energiemanagement von Eventsteuerung (on) auf zyklische Steuerung (interval) umgestellt.

[Blockmove]

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

Also ich würde das prinzipiell so machen:

Ich bin absolut nicht der Blockly-Fan.
Hier mal das Prinzip, wie ich "wichtige" Dinge in ioBroker versuche zu lösen.
Ist für diesen Fall wahrscheinlich zuviel des Guten.

Da es Zustände gibt, bei denen Events auch mal nicht erfasst werden, arbeitete ich bei sowas lieber mit Intervall (60s).
Zuerst werden die relevanten Werte in Variablen eingelesen.
Dadurch bleiben Zustände während der Scriptverarbeitung konsistent (hier eher unwichtig).

Ich weiß gerade nicht, ob der Zeitvergleich "nicht zwischen" tagesübergreifend funktioniert. Daher eben mit "zwischen und Negation

[Codierknecht]

@blockmove sagte in [GELÖST] Zeitplan arbeitet überhaupt nicht:

Da es Zustände gibt, bei denen Events auch mal nicht erfasst werden, arbeitete ich bei sowas lieber mit Intervall (60s).

Um genau diese unnützen Intervalle zu vermeiden, gibt es Events.
Da wird etwas 1.440 x am Tag aufgerufen und soll tatsächlich wie oft laufen? 1x? 2x?
Wenn die Trigger nicht ausgelöst werden, hat Dein System ein Problem. Dem sollte man nachgehen.
Das mit 'nem Intervall zu lösen, kann nur als Notbehelf dienen. Es behebt ja nicht die eigentliche Ursache.

@blockmove sagte in [GELÖST] Zeitplan arbeitet überhaupt nicht:

Ich weiß gerade nicht, ob der Zeitvergleich "nicht zwischen" tagesübergreifend funktioniert. Daher eben mit "zwischen und Negation

Ja - das funktioniert nicht immer sauber.
Muss aber nicht zusätzlich negiert werden. Es gibt ja statt "zwischen" auch "nicht zwischen" ;-)

[Blockmove]

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

@blockmove sagte in [GELÖST] Zeitplan arbeitet überhaupt nicht:

Da es Zustände gibt, bei denen Events auch mal nicht erfasst werden, arbeitete ich bei sowas lieber mit Intervall (60s).

Um genau diese unnützen Intervalle zu vermeiden, gibt es Events.
Da wird etwas 1.440 x am Tag aufgerufen und soll tatsächlich wie oft laufen? 1x? 2x?
Wenn die Trigger nicht ausgelöst werden, hat Dein System ein Problem. Dem sollte man nachgehen.
Das mit 'nem Intervall zu lösen, kann nur als Notbehelf dienen. Es behebt ja nicht die eigentliche Ursache.

Tja, ich bin beruflich in der Sparte tätig.
Bei Steuerungen unterscheidet man zwischen Eventsteuerung und zyklischer Steuerung.
Beides hat seine Berechtigung und Anwendung.
Bei einfachen Aufgaben (z.B. Lichtsteuerung) reichen meist Events.
Wird es komplexer (viele Auslöser, gegenseitige Abhängigkeiten) wird es mit einer zyklischen Steuerung einfacher und besser beherschbar.

Wie bereits oben geschrieben, ist es für so eine Aufgabe zuviel des Guten. Aber es zeigt eine Alternative.
1440 Events/Tag sind für ein System wie ioBroker übrigends nicht.
Der Adapter meines PV-Speichers aktualisiert die Leistungsdaten alle 20s. Da hätte ich deutlich mehr Events wenn ich darauf triggern würde.

[Stefan Falt]

@blockmove
Hallo,
inzwischen läuft es wie ich will, wenn auch erst ab 0:00 Uhr ... ich habe noch nicht rausgefunden wie man den CRON Ausdruck editiert.
Kann man das so lassen?