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

[liv-in-sky]

@automatisierer-0 glaube nicht, dass dies lange gutgehen würde - da solltlest du eine externe lösung finden, die du über iobroker steuern kannst

[Automatisierer 0]

@paul53
Und was muss ich dafür tun?
Wie geht das?

[paul53]

@automatisierer-0 sagte: Wie geht das?

Javascript oder Blockly?
Was soll wann alle 100 ms passieren?

[Automatisierer 0]

@paul53
Alle 100ms soll eine interne Variable um 1 decrementiert werden.

[paul53]

@automatisierer-0 sagte: Alle 100ms soll eine interne Variable um 1 decrementiert werden.

Blockly-Beispiel:

[OliverIO]

@automatisierer-0 sagte in Cron mit Auflösung 100ms:

@paul53
Alle 100ms soll eine interne Variable um 1 decrementiert werden.

warum muss das alle 100ms passieren?
reicht auch alle 1000ms = 1sekunde um 10?

[Asgothian]

@automatisierer-0 sagte in Cron mit Auflösung 100ms:

@paul53
Alle 100ms soll eine interne Variable um 1 decrementiert werden.

Warum dieses ?

• Wenn es eine interne Variable ist kannst Du darauf nicht triggern.
• Wenn es ein ioBroker State ist werden die setState befehle deinen ioBroker auf Dauer lahmlegen
• Wenn es für eine Restzeitberechnung notwendig ist kannst Du einfach
  -- den Startzeitpunkt als timestamp sichern (ist in ms)
  -- immer beim Refresh vergleichen wieviel Zeit vergangen ist (aktueller Timestamp - gespeicherter Timestamp) / 100, dann hast du es in 100 ms.
  -- Das erreichen der "0" vorausberechnen und einfach mit einem Timeout auf die Zeit springen wo du den - Event haben willst.

@oliverio sagte in Cron mit Auflösung 100ms:

warum muss das alle 100ms passieren?
reicht auch alle 1000ms = 1sekunde um 10?

Auch dieses ist letztendlich nur bedingt zielführend. An Stelle von einem Aufruf alle 100 ms kommt da ein (unnötiger?) Aufruf jede Sekunde. Das scheint vielleicht besser, ist aber letztendlich das gleiche in langsamer.

Generell sind diese "Heartbeat" Funktionalitäten wo regelmässig ein Zähler modifiziert wird von der Ressourcenseite kritisch und zumeist auch unnötig. Über die Timestamps kommt man immer an die relevanten Laufzeiten heran und die meisten Aktionen lassen sich "event" getrieben darstellen.

A.

[fastfoot]

@thomas-braun sagte in Cron mit Auflösung 100ms:

So kurze cron shedules sind gefährlich.

nee, da nicht möglich :-)

[Thomas Braun]

@fastfoot

Das ist eine Informatiker-Antwort. :-D

[fastfoot]

@thomas-braun ja ok, hab wohl zuviel auf stackoverflow rumgestöbert in letzter Zeit :-)

[paul53]

@asgothian sagte: Wenn es für eine Restzeitberechnung notwendig ist

Wenn diese Restzeit eine Auflösung von 0,1 s haben soll, kann durchaus eine Variable mit dem 100-ms-Intervall runter gezählt werden.

[Asgothian]

@paul53 sagte in Cron mit Auflösung 100ms:

@asgothian sagte: Wenn es für eine Restzeitberechnung notwendig ist

Wenn diese Restzeit eine Auflösung von 0,1 s haben soll, kann durchaus eine Variable mit dem 100-ms-Intervall runter gezählt werden.

Kann, aber wozu ? Ich glaube kaum das jemand in der Darstellung die 100 ms sehen kann. Und wenn es in der Darstellung darauf geht auf die nächsten 100 ms genau zu sein kann man die Differenz dear Zeitstempel auf die nächsten 100 ms Runden.

Ich bleibe dabei - aus meiner Sicht sind die meisten “Heartbeat” Konstrukte ressourcenverschwendung.

A.

[Automatisierer 0]

@asgothian
Es ist keine der drei angeführten Anforderungen.
Ich möchte nach einem eingehenden Daetnpunkttrigger (Änderung eines Datenpunkts) nach einer Sekunde eine Aktion durchführen.
Wenn ich nun den cron mit einer Sekunde Triggerzeit nehme, dann kommt dieser cron-Trigger zwischen 1ms bis 999ms nach dem eingehenden Datenpunkttrigger, je nach Zufall. Und das ist zu unpräzise.

Daher kommen die 100ms. (ich weiss dass ich da noch imme eine Ungenauigkeit von 1-99ms habe, aber dies reicht aus.)

[fastfoot]

@automatisierer-0 sagte in Cron mit Auflösung 100ms:

Ich möchte nach einem eingehenden Daetnpunkttrigger (Änderung eines Datenpunkts) nach einer Sekunde eine Aktion durchführen.

in dem Fall ist setTimeout() dein Freund