Zeitfunktion / Dauer des Zustandes einer GA

[enertegus]

Hi Martin,
das es noch ungeklärte Ungenauigkeiten von cycle() gibt, würde ich wie weiter oben vorgeschlagen vorgehen und afterc nutzen.

Weil es soviel Spass macht, mal hier ein Ansatz mit delayc.
Alarm geht an, wenn die maximale Zeit kein Impuls eingetroffen ist. Ansonsten ist die StoppZeit in Millisekunden.
[highlight=epc]
Max=1000000u64
Zeit=0u64
StoppZeit=10u64
GAEvent=AUS
Alarm=AUS

if delayc(change(GAEvent), Max, Zeit) then {
Alarm=EIN;
} endif

if event("InfoLedBus-0/3/8") then {
StoppZeit=Max-Zeit;
GAEvent=!GAEvent
} endif
[/highlight]
P.S: Cycle ist nicht ungenau. Das Problem vom Jambala im Zusammenhang mit Deinem 1-Wire Makros war schlichtweg die Menge an Debuginformationen, welcher u.a. die Timerabfrage überlastet haben. Steffi hat die Debuginfo per Switch deaktiviert und das sollte nun laufen.

[Jambala]

Das Problem vom Jambala im Zusammenhang mit Deinem 1-Wire Makros war schlichtweg die Menge an Debuginformationen, welcher u.a. die Timerabfrage überlastet haben. Steffi hat die Debuginfo per Switch deaktiviert und das sollte nun laufen.

Als ich die Performance Probleme mit cycle() hatte, lief Bernds Makro bei mir immer mit der Einstellung DebugLevel=HA7E_Debug_None, also keine UDP Debug Informationen.

Was hat Steffi darüber hinaus geändert?

[enertegus]

Als ich die Performance Probleme mit cycle() hatte, lief Bernds Makro bei mir immer mit der Einstellung DebugLevel=HA7E_Debug_None, also keine UDP Debug Informationen.

Die Variable war zwar aus, aber jede verschachtelte if- Abfrage wird beim Durchlauf invalidiert.

If X==EIN then {
If debug then...
Anweisung1
If debug then...
Anweisung2
} endif
Damit sind die Debuginformationen zwar nicht weitergereicht worden, aber bei jedem Schritt muss die debug-if Abfrage geprüft werden. Wir haben mit einen #ifdef DEBUG gearbeitet und nun werden im Release diese IF-Abfragen erst gar nicht mit in den Code uebernommen. Das hat den Code schon von der Größe her drastisch reduziert.

[bmx]

An dieser Stelle vielleicht mal die dringende Bitte (Featurewunsch) das der EibPC den Schleifendurchlauf mißt und mitteilt. Also minimale Zeit, maximale Zeit und Durchschnitt der letzten n Zeitscheiben.
Und dann würde ich gerne wissen, ob der EibPC die vorgegebenen Zeitscheiben durchsetzt oder - wenn der Code zu lange in der Abarbeitung benötigt - Zeitscheiben überspringt.

Gruß,
Bernd

[Brick]

Guten morgen allesamt..

kurze Frage nochmal, stimmt eigentlich meine Formel ???

ich bekomm alle paar Sekunden (habs aktuell noch mit der cycle-Funktion
gelöst und ist relativ genau was mir bis jetzt aufgefallen ist) den aktuellen
kWh Wert auf eine GA... jetzt will ich da drauß den akt. Verbrauch errechnen..

hab das wie folgt gemacht:

akt_Stromverbrauch= (3600f32/akt_deltaT)*akt_deltaStromverbrauch

(akt_deltaT sind Sekunden)

ist das so richtig.. oder berechnet man das anders ???

Gruß Martin

[enertegus]

An dieser Stelle vielleicht mal die dringende Bitte (Featurewunsch) das der EibPC den Schleifendurchlauf mißt und mitteilt. Also minimale Zeit, maximale Zeit und Durchschnitt der letzten n Zeitscheiben.

Also das Feature lehne ich entschieden ab, es ist nämlich schon da...
Hier wieder mit afterc (ziemlich nützlich diese afterc und delayc Funktionen):
[Highlight=epc]
// Berechnet die minimale und maximale Zyklusdauer
// der Verarbeitung. Dabei ist die Performance-Angabe im EibStudio immer
// als Offset dabei.
Max=10000000000000000000000000u64
Zeit=0u64
StoppZeit=Max
MaxZyklusZeit=0u64
MinZyklusZeit=Max
// Die erste Zyklus kann etwas länger dauern, da
// dieser alles initialisiert.
if afterc(after(systemstart(),10000u64), Max, Zeit) then {
StoppZeit=0u64;
} endif

if change(Zeit) then {
MaxZyklusZeit=max(StoppZeit-Zeit,MaxZyklusZeit);
MinZyklusZeit=min(StoppZeit-Zeit,MinZyklusZeit);
StoppZeit=Zeit;
} endif
[/Highlight]Die Zeitscheiben überspringen tut er nicht in dem Sinne, er vergisst auch nichts bei Überlast, lediglich die Timer werden - sollten sie innerhalb einer gewissen Zeit nicht abgearbeitet werden (ich glaube 1 Sekunde), verworfen. Zumindest mit der aktuellen FW arbeitet er so.
Die Minimale Zeit kann bei mir nicht unter 20ms fallen, dies die Zeit aus den Performanceeinstellungen ist.

[bmx]

Also das Feature lehne ich entschieden ab, es ist nämlich schon da...

das Du bist!

Die Zeitscheiben überspringen tut er nicht in dem Sinne, er vergisst auch nichts bei Überlast, lediglich die Timer werden - sollten sie innerhalb einer gewissen Zeit nicht abgearbeitet werden (ich glaube 1 Sekunde), verworfen. Zumindest mit der aktuellen FW arbeitet er so.

Und wie bekomme ich einen solchen Zustand mit außer das irgendwas nicht funktioniert?
Ich möchte jetzt nicht beschreiben wie ich das finde...

[enertegus]

Und wie bekomme ich einen solchen Zustand mit außer das irgendwas nicht funktioniert?

Du kannst nun mit dem Code die Maxtime messen und wenn die über 1000 steigt, erkennst Du es. Oder was ist das Problem?
EDIT: Ich hab zur Klarheit einen Kommentar im Code hinterlassen. Eigentlich dachte ich, der Code macht genau was Du wolltest.

[enertegus]

Ich habe das nun mal im Handbuch ergänzt. Im Kapitel soll einiges an "tiefer gehenden" Code beschrieben werden. Wird sicher noch wachsen im Laufe der Zeit...
Bitte um Kritik.

[bmx]

Moin, moin,

ist sicherlich ein guter Anfang. Wenn die Wertangabe für u64 im nächsten EibStudio gefixt wird, dann funktioniert es auch. Evtl. sollte ergänzt werden wie genau das mit den einzelnen Performance Angaben läuft.
Da würde es dann auch Sinn machen, wenn die Angaben zur Performance dann innerhalb des Programmes auch aufrufbar sind. Dann könnte die errechnete Zykluszeit um die Performance Zeit bereinigt werden.

Eine Übersicht der Threads, die parallel oder auch seriell ablaufen wäre natürlich auch hilfreich. Beispiel: Derzeit hat es für mich den Anschein, das von einer Zykluszeit von 50ms, die für Linux übrigbleiben nichts abgezogen wird, d.h. Ein Verarbeitungszyklus wird gestartet, danach wartet der Thread dann eben 50ms bis der nächste gestartet wird. Korrekt?

Gruß,
Bernd