Monatsrückblick Januar/Februar 2026 ist online!

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

[Codierknecht]

@stefan-falt
Der Wizard ist für Zeitpläne ziemlicher Käse.

Nimm den passenden Trigger

Und stelle dann ein:

[Stefan Falt]

@codierknecht
Da bringt der mir diese Fehlermeldung wenn es über Mitternacht geht ...

[Codierknecht]

@stefan-falt
Alternative:

[Stefan Falt]

@codierknecht Klappt. Dankeschön.