htime nicht zuverlässig?

[enertegus]

Für mich ist das indiskutabel!

Hört. hört ...

Es kann einfach nicht angehen, dass der Code quasi "zufällig" nicht ausgeführt wird. Robust geht anders!!!

Das ist nicht zufällig, sondern der Programmierung geschuldet. Ich habe das oben erklärt, wo die Ursache zu suchen ist. Wenn es zu einer Überlastung des EibPC kommt (wir arbeiten an einem event im Ereignisspeicher), und die verdächtigen Kandidaten offengelegt sind, sollte hier erst mal das auf der Userseite weiterverfolgt werden. Auch auf meinem i7 schaffe ich es, diesen durch ein Programm in die knie zu zwingen, ohne daran zu denken, dass mir Intel da irgendwelche Vorschriften macht.
htime wird von mir seid 5 Jahren verwendet und geht wunderbar. Uwe! hat das auch schön erläutert, was die Absicht von htime ist.
Ich möchte das aber hier nicht weiter ausdiskutieren und biite, sich am Threadthema orientieren.

[saft6luck]

Hört. hört ...

Ja, hört, hört

Das ist nicht zufällig, sondern der Programmierung geschuldet.

Wenn das Kommando nicht ausgeführt wird, weil der eibPC WAS macht? Code ausführen??? Für mich ist das zufällig! Soll der Anwender alle Kombinationen aller Eventketten prüfen? Dir scheint dir Tragweite eines solchen "Schluckaufs" nicht klar zu sein?
Wirf das Kommando raus, wenn es nicht funktioniert und du keine andere Lösung hast. Lösungen gäbe es genügend!

Für eine Haussteuerung ist das untragbar. Darf man den eibPC also nur für "unwichtige" Dinge verwenden? Ist das deine Einstellung zur Robustheit von Prozessen in der Hausautomatisierung??

Ich habe das oben erklärt, wo die Ursache zu suchen ist. Wenn es zu einer Überlastung des EibPC kommt (wir arbeiten an einem event im Ereignisspeicher), und die verdächtigen Kandidaten offengelegt sind, sollte hier erst mal das auf der Userseite weiterverfolgt werden.

Ich habe das Problem schon lange vor dem ominösen Wunderground Makro gefunden, lange bevor du das Problem erkannt hattest und habe einfach mal abgewartet was da so von Enertex noch kommt. Bisher nicht viel.

Die Prozessorauslastung kann man messen, die Objekte werden jetzt angezeigt. Eventspeichereinträge sind für den Müll (siehe Eventspeichereinträge nach Neustart -> da kam bis jetzt keine Antwort mehr!!!), denn sie treten erst nachher auf.

Auch auf meinem i7 schaffe ich es, diesen durch ein Programm in die knie zu zwingen, ohne daran zu denken, dass mir Intel da irgendwelche Vorschriften macht.

Der i7 führt aber alles aus, auch wenn es dauert. Der denkt sich nicht, dass der Anwender zwar speichern wollte vor dem Beenden, das Speichen wurde aber nicht rechtzeitig beantragt, daher ist mal einfach alles weg.

htime wird von mir seid 5 Jahren verwendet und geht wunderbar. Uwe! hat das auch schön erläutert, was die Absicht von htime ist.

Die Absicht von htime ist es also, den Code nicht auszuführen, wenn der Zeitpunkt nicht exakt getroffen wird? Na, das ist ja genial, außer der eibPC hat Lücken in der Ausführung.

Ich möchte das aber hier nicht weiter ausdiskutieren und biite, sich am Threadthema orientieren.

Das ist das Threadthema!!!!! "htime nicht zuverlässig?"

[rennsemmel]

Energetus, auch wenn ich mich damit wiederhole: In diesem Fall bin ich ebenso der Meinung, dass htime nicht wie im Handbuch beschrieben funktioniert. Es gibt eine klare Limitierung, die abhängig ist, wie der eiBPC programmiert ist.

Es sei denn der eiBPC kann Zeitsprünge in die Zukunft generieren...

[klaus]

Das ist das Threadthema!!!!! "htime nicht zuverlässig?"

Genau das ist der Punkt. htime() macht genau das was in der Doku steht. Prüfen, ob eine Zeit GENAU erreicht ist. Wenn, aus welchen Gründen immer, eine Verzögerung im Programm auftritt, dann ist das nicht das Problem von htime, sondern schlicht unsauber programmiert. Die selbe Problematik hat man in JEDER anderen Programmierumgebung ebenfalls. Wenn ich beispielsweise unter Windows mit GetSystemTime() die Systemzeit auf genau 23:30:00 prüfe und mein Prozess bekommt genau in dieser einen Sekunde keine Rechenzeit zugeteilt, dann geht die Prüfung eben nicht auf. Da hat niemand Schuld dran. Das ist von der Konzeption her dann eben schlecht programmiert und entsprechend fehleranfällig.

Es gibt genug Möglichkeiten diese Problematik zu umgehen. Wenn man chtime nicht als Alternative verwenden will, wäre es auch möglich folgenden Ansatz zu verwenden:

if hour() == 23 and minute() == 30 then tuwas endif

[rennsemmel]

Ich (und manch anderer) bin dort anderer Meinung.

Aber aus meiner Sicht bringst Du es auf den Punkt mit der Aussage:
"...Prüfen, ob eine Zeit GENAU erreicht ist. Wenn, aus welchen Gründen immer, eine Verzögerung im Programm auftritt, dann... "

Das steht so nicht im Handbuch und ist auch nicht zu verallgemeinern mit einem anderen (z.B. Windows) System. In den Systemen sollten diese Verhalten abgefangen werden oder ein klarer Hinweis auf die Limitierung angegeben werden.

Ich suche keine Alternative, die habe ich schon längst programmiert. Hier geht es um htime und dessen Funktionsweise und dass viele Generationen nach uns nicht wieder in dieses oder solch geartete Fettnäpfchen treten.

[saft6luck]

Genau das ist der Punkt. htime() macht genau das was in der Doku steht. Prüfen, ob eine Zeit GENAU erreicht ist.

In der Anleitung wird nicht beschrieben, dass der Zeitpunkt im Programmlauf evtl. nicht vorhanden ist. Eine genaue Prüfung eines Zeitpunktes erfordert zwingend, dass ich den Zeitpunkt auch sicher erreichen kann.

NB wird auf diesen "genauen" Zeitpunkt im Handbuch nur eingegangen, weil man evtl. zu spät dran sein könnte. Der Ausgang toggelt, im Gegensatz zu chtime(). Auf diesen Unterschied soll hingewiesen werden.

Wenn, aus welchen Gründen immer, eine Verzögerung im Programm auftritt, dann ist das nicht das Problem von htime, sondern schlicht unsauber programmiert. Die selbe Problematik hat man in JEDER anderen Programmierumgebung ebenfalls.

Nein!

Denn in anderen Programmiersprachen mag es eine Entscheidung des Programmierers sein, wie er die Programmausführung gestaltet und welches Kommando er dann wie zu einer "Funktion" zusammensetzt, um die Zeit abzufragen und daraus einen Vergleich zu gestalten. Solche (am Ende evtl. falsche) Entscheidungen können zu Programmierfehlern führen.

Beim eibPC wird ein Kommando zur Verfügung gestellt, dass explizit eine Schaltuhr darstellen soll. Das ist sicher kein Programmierfehler, wenn dieses Kommando dann eingesetzt wird.

NB Das Problem "Schluckauf" (wie ich es sehe) kann einen genauso bei den anderen Zeitfunktionen, cycle() oder Zeiträumen, wie 1 bis wenige Sekunden treffen. Bei htime() ist es evtl. nur sehr schnell sichtbar, weil Schaltuhren nun mal eine wohl definierte Schaltzeit haben (sollen) und das Kommando ja schließlich hierfür gedacht ist. Bei anderen Kommandos wird man erst in Kombination auf diesen Effekt treffen, was dann eben den Einzelfall trifft -> es wird immer wieder Leute mit diesem Problem geben.

Es gibt genug Möglichkeiten diese Problematik zu umgehen. Wenn man chtime nicht als Alternative verwenden will, wäre es auch möglich folgenden Ansatz zu verwenden:

if hour() == 23 and minute() == 30 then tuwas endif

Das sehe ich auch so, allerdings nicht durch solche fehleranfällige Konstrukte. Sobald man auf die Ebene 'Sekunde' geht ist das Problem schon wieder da (abgesehen davon, dass man sehr genau wissen muss, was man macht und der "Schluckauf" ja auch eine Minute dauer könnte).
Es gibt schon bei der Entwicklung des Compilers (falls das überhaupt der richtige Teil der Kette ist) die Möglichkeit, Kommandos entsprechend sicher zu gestalten (siehe Hinweis von Uwe).

Der Hinweis im Handbuch, so man denn das "genau" als exakten Zeitpunkt lesen will, müsste dann heißen:
"Beachten Sie bitte, dass der Zeitpunkt u.U. nicht exakt eingehalten werden kann, wenn sich z.B. durch die Programmausführung eine Verzögerung ergibt."

EDIT:

Je länger ich darüber nachdenke, umso absurder ist die Idee ein Kommando, welches eine Schaltuhr darstellen soll, durch andere Konstrukte umgehen zu wollen/müssen.

Gerade ein Beispiel wie:
[highlight=epc]
if (hour() == 23) && (minute() == 30) && (second() == 30) then tuwas endif
[/highlight]

zeigt eine Stolperfalle, die durch ein "sicheres" Kommando des eibPCs vermieden werden (können) sollte. Nicht umgekehrt!