Modul HourCounter - Betriebsstundenzähler mit einem Fensterkontakt

[bluesky]

Hallo Zusammen

Das neu eingeführte Attribut Interval macht meine Grafik von meinem Heizölbrenner unbrauchbar und dies aus folgendem Grund: Ich werte mit einer Grafik die Brennerlaufzeit (Pulstime) und die Brennerabkühzeit (PauseTime) aus. Dies ergibt eine Grafik wie in Bild 1 (unterer Teil) zu sehen ist. Diese Grafik wurde vor der Einführung des Intervall Attribut erstellt. Die Brennzeit (violette Line) und Brennerabkühlzeit (braune Linie) verändern sich aufgrund der Aussentemperaturen und sind ohne grosse Aussentemperaturschwankungen stabil. Mit dem neuen ,,Zwangsupdate" Attribut Interval wird jedoch die Pausetime regelmässig unterbrochen, d.h. neu berechnet. Dadurch wird in der Grafik nicht mehr die tatsächliche Abkühldauer des Brenners dargestellt, d.h. nicht mehr die Zeit, die zwischen dem BrennerStop und dem nächsten BrennerStart vergeht (PausTime) sondern die Zeit bis zum nächsten ,,Zwangsupdate" durch den Intervall. Das Resultat ist in Bild 1 (oberer Teil) zu sehen. Hier nützt mir die PauseTime Linie nichts mehr.

Mögliche Lösung?
Ich habe versucht das Attribut Interval zu löschen, jedoch wird nach dem Defaultwert von 60Min immer noch ,,upgedatet". Für mich würde es sehr helfen, wenn dieses Attribut komplett deaktiviert werden könnte.

Vielen Dank für Eure Hilfe

[John]

Hi bluesky,

hab dein Problem verstanden.

Anbei die neue Version zum Testen.

2 neue Readings wurden eingeführt, die nur beim Flankenwechsel aktualisiert werden.
pauseTimeEdge, pulseTimeEdge.

Bitte rückmelden, wenn es passt.

John

[bluesky]

Hallo John

Vielen Dank für Deine rasche Antwort. Ich werde die angepasste Version rasch möglichst probieren und ich mich wieder melden.

Gruß bluesky

[bluesky]

Hallo John

Ich habe nochmals über die Lösung mit den zwei 2 neuen Readings pauseTimeEdge und pulseTimeEdge nachgedacht und verstehe diese nicht ganz.

Bis jetzt werte ich in der Grafik aus
pauseTimeIncrement    mit     $fld[3]/=60       -> Dies zeigt mir an wie lang der Brenner vom letzten BrennerStop bis zum nächsten BrennerStart abgeschaltet war.

pulseTimeIncrement     mit     $fld[3]/=60       -> Dies zeigt mir an wie lange der Brenner beim letzten Einschalten gebrannt hat.

Die Anzahl Brennstunden pro Tag erhalte ich mit pulseTimePerDay und die ganze Zeit bis anhin mit pulseTimeOverall.

-> Nun meine Frage:
Muss ich jetzt in der Grafik nur pauseTimeIncrement gegen pauseTimeEdge tauschen und pulseTimeIncrement gegen pulseTimeEdge, d.h. die Zähler  pulseTimePerDay /pulseTimeOverall und pauseTimePerDay/pauseTimeOverall bleiben die gleichen und berücksichtigen jetzt anstatt dem ,,Interval"nur noch die ,,Edge"Ereignisse? Ich hoffe Du verstehst was ich meine.

Vielen Dank nochmals für Deine Hilfe.

Gruß bluesky

[John]

Hallo  bluesky,

pauseTimeEdge und pulseTimeEdge ahmen das Verhalten von pauseTimeIncrement und pulseTimeIncrement vor der Einführung von interval nach.

-> Nun meine Frage:
Muss ich jetzt in der Grafik nur pauseTimeIncrement gegen pauseTimeEdge tauschen und pulseTimeIncrement gegen pulseTimeEdge, d.h. die Zähler  pulseTimePerDay /pulseTimeOverall und pauseTimePerDay/pauseTimeOverall bleiben die gleichen und berücksichtigen jetzt anstatt dem ,,Interval"nur noch die ,,Edge"Ereignisse? Ich hoffe Du verstehst was ich meine.

Ich denke du hast das richtig beschrieben
John

[bluesky]

Hallo John

Vielen Dank für Deine erneute Antwort. Jetzt verstehe ich die 2 neuen Readings und werde dies so versuchen und dann weiter berichten.

Gruß bluesky

[Bartimaus]

Hallo Bartimaus,

das Modul-Konzept funktioniert anders.

Die Modul-Entwickler können sich darauf verlassen, dass die Werte aller Readings remanent sind, d.h. sie überdauern einen Shutdown.

Konkret werden diese in der Datei  ./log/fhem.save gespeichert.

Aber das Lesen dieser Datei wird vom FHEM-Kernel übernommen, nicht von den Modulen.

Ich vermute, daß auch diese Datei zerstört wurde.


John

Hallo,


mein FHEM muss auf einen neuen Raspi + neue SD-Karte umziehen.
Dh, es reicht, wenn ich die fhem.save auf das neue Gerät rüberkopiere, dann liest HorCounter das wieder ein oder sind weitere Schritte notwenig ?
Möchte ungern die bereit fleissig geloggten Daten verlieren...

[John]

Hallo Bartimaus,

in /log/fhem.save  sind die aktuellen Readings samt den zugeordneten Werten gespeichert.

Möchte ungern die bereit fleissig geloggten Daten verlieren...

Die Log-Dateien  findest du im Unterverzeichnis log.

Am besten machst du vom FHEM Verzeichnis ein komplettes Backup.

John

[Bartimaus]

Hi John,


ok

[bluesky]

Hallo John

Ich habe die Testversion 1.0.0.7 installiert, bekomme aber seltsame Werte zurück.

Problem 1:
In der Nacht wo kein Verbraucher eingeschaltet ist, zählt der HourCounter PulseTimeEdge und keine PauseTimeEdge.

2014-12-09_03:00:00 CounterWF pulseTimeEdge: 3600
2014-12-09_03:00:00 CounterWF pauseTimeIncrement: 3600
2014-12-09_03:00:00 CounterWF pauseTimeEdge: 0
2014-12-09_03:00:00 CounterWF pauseTimePerDay: 10800
2014-12-09_03:00:00 CounterWF pauseTimeOverall: 23199211
2014-12-09_03:00:00 CounterWF value: 0
2014-12-09_03:00:00 CounterWF tickHour: 1
2014-12-09_04:00:00 CounterWF pulseTimeEdge: 3600
2014-12-09_04:00:00 CounterWF pauseTimeIncrement: 3600
2014-12-09_04:00:00 CounterWF pauseTimeEdge: 0
2014-12-09_04:00:00 CounterWF pauseTimePerDay: 14400
2014-12-09_04:00:00 CounterWF pauseTimeOverall: 23202811

Problem 2:
Um 12.51.50 wird ein Verbraucher für 2270Sekunden eingeschaltet bis 13.29.40 Uhr
-> Es wird eine pauseTimeEdge um 13.00.00 und 13.29.40 gezählt obwohl der Verbraucher läuft.
-> Die errechnete pulseTimeEdge stimmt (32 + 1780) = 1812 nicht mit der tatsächlichen pulseTimeIncrement 2270Sek überein.

2014-12-09_12:51:50 CounterWF countsPerDay: 4
2014-12-09_12:51:50 CounterWF countsOverall: 712
2014-12-09_12:51:50 CounterWF pulseTimeEdge: 32
2014-12-09_12:51:50 CounterWF pauseTimeIncrement: 14
2014-12-09_12:51:50 CounterWF pauseTimeEdge: 14
2014-12-09_12:51:50 CounterWF pauseTimePerDay: 35857
2014-12-09_12:51:50 CounterWF pauseTimeOverall: 23224268
2014-12-09_12:51:50 CounterWF value: 1
2014-12-09_12:51:50 CounterWF 4
2014-12-09_13:00:00 CounterWF pulseTimeIncrement: 490
2014-12-09_13:00:00 CounterWF pulseTimeEdge: 32
2014-12-09_13:00:00 CounterWF pulseTimePerDay: 10943
2014-12-09_13:00:00 CounterWF pulseTimeOverall: 7780102
2014-12-09_13:00:00 CounterWF pauseTimeEdge: 14
2014-12-09_13:00:00 CounterWF value: 1
2014-12-09_13:00:00 CounterWF tickHour: 1
2014-12-09_13:29:40 CounterWF pulseTimeIncrement: 1780
2014-12-09_13:29:40 CounterWF pulseTimeEdge: 1780
2014-12-09_13:29:40 CounterWF pulseTimePerDay: 12723
2014-12-09_13:29:40 CounterWF pulseTimeOverall: 7781882
2014-12-09_13:29:40 CounterWF pauseTimeEdge: 14
2014-12-09_13:29:40 CounterWF value: 0

Im Anhang noch das längere Logfile für den Zeitraum.

Mache ich einen Überlegungsfehler oder kann das so nicht funktionieren?

Gruß bluesky

[John]

Hallo bluesky,

ich habs gesehen, es liegt noch einiges im Argen.

Bald gibts die neue Version.

John

[John]

@alle HourCounter-Anwender

Mit Einführung des zyklischen Updates wurden erhebliche Änderungen notwendig,
die Änderungen an der bestehenden Konfiguration erfordern können.

Dies führt zum Versions-Sprung 1.0.1.0.

Die operativen Readings werden nun regelmässig aktualisert.
(countsOverall, countsPerDay,pauseTimeIncrement..)

Um die Datenflut zu begrenzen muss man  mit event-min-interval und event-on-change-reading arbeiten:
   

Code Auswählen Erweitern

event-min-interval                 tick.*:0,.*:3600
event-on-change-reading            .*     

Während der Puls-Phase wird nun pulseTimeIncrement, pulseTimePerDay, pulseTimeOverall stets neu berechnet.
Analog hierzu die Readings der Pause-Phase.

pauseTimeEdge nimmt den wert der letzten vollständigen Pausen-Phase auf. Analog hierzu pulseTimeEdge.


Änderungen in 99_UtilsHourCounter
* value, countsOverall können nicht mehr als Trigger innerhalb von 99_UtilsHourCounter verwendet werden,
  da diese nun auch aktualisiert werden, wenn sich der Wert nicht ändert.
* die Steuerung in diesem Modul erfolgt nun ausschliesslich über die tick*-Readings
  (siehe angehängte Datei)

entsprechend muss sich auch der Notify ändern der 99_UtilsHourcounter aufruft

Code Auswählen Erweitern

  define CN.EVENT notify CN\..*:tick.* { appHCNotify("%NAME","%EVTPART0","%EVTPART1");;}


Bitte zunächst die angehängten Dateien übernehmen, nach einer entsprechenden Test-Phase
wird die neue Version eingechecked.

Ich bitte um zahlreiche Rückmeldungen.

Version 1.0.1.0 wurde eingecheckt.

John

[bluesky]

Hallo John

Ich habe die Version 1.0.7 getestet und verstehe jetzt von den errechneten Daten nicht mehr viel (im Vergleich zur Version ohne Interval, wo ich die Wert noch nachvollziehen konnte).

Ich habe im Modul HourCounter bei den Attributen folgende Werte eingetragen (obwohl ich keine Ahnung habe, was die genau bewirken sollten).

Code Auswählen Erweitern

event-min-interval                 tick.*:0,.*:3600
event-on-change-reading            .*    

Ein Beispiel von den Werten, die ich nicht verstehe:
In der Nacht z.B. läuft von 23 bis 05.30Uhr kein Verbraucher, was einer PauseTimeIncrement von 23400Sek entspricht. (390Min).

Die Werte, die ich von ,,Show preprocessed input" für die Grafik erhalten sind aber (nur Zeitraum 24- 05.30Uhr)

2014-12-11_00:00:00 28.25
2014-12-11_01:00:00 28.25
2014-12-11_02:00:00 28.25
2014-12-11_03:00:00 28.25
2014-12-11_04:00:00 28.25
2014-12-11_05:00:00 28.25
2014-12-11_05:30:00 390
#4:CounterWF.pauseTimeEdge\x3a::$fld[3]/=60
-> Dieser Eintrag von 05.30Uhr mit 390Min stimmt, jedoch sollten die anderen Werte, da pauseTimeEdge, doch gar nicht erscheinen?

In der gleichen Zeit 24-05.30Uhr sollten doch auch keine PulseTimeEdge Werte generiert werden (der Verbraucher ist ja aus).
2014-12-11_00:00:00 382.066666666667
2014-12-11_01:00:00 382.066666666667
2014-12-11_02:00:00 382.066666666667
2014-12-11_03:00:00 382.066666666667
2014-12-11_04:00:00 382.066666666667
2014-12-11_05:00:00 382.066666666667
2014-12-11_07:00:00 382.066666666667
#4:CounterWF.pulseTimeEdge\x3a::$fld[3]/=60

Ähnlich ist es mit den pulseTimeIncrement Werten, die in der Nacht doch gar nicht vorhanden sind, da der Verbraucher nicht läuft.
2014-12-11_00:00:00 382.066666666667
2014-12-11_01:00:00 382.066666666667
2014-12-11_02:00:00 382.066666666667
2014-12-11_03:00:00 382.066666666667
2014-12-11_04:00:00 382.066666666667
2014-12-11_05:00:00 382.066666666667
2014-12-11_05:30:00 0
#3:CounterWF.pulseTimeIncrement\x3a::$fld[3]/=60


Die Grafik, die ich daraus erhalte, ist auch seltsam.

Da ich den neuen HourCounter mit dem Intervall, den ich nicht benötige und die daraus resultierenden Werte/Grafiken nicht mehr nachvollziehen kann, habe ich den alten HourCounter (ohne Intervall) wieder eingebaut. Ich weiss, dass ist keine gute Lösung, jedoch funktioniert diese für mich. Vielen Dank trotzdem für Deine Hilfe mit den ,,Edge" Werten zu versuchen, den Zustand vor dem Intervall Update wieder aufzuzeigen.

Gruss bluesky

[bluesky]

Hallo John

Noch ein Beispiel:

Um 09:52:05 wird ein Verbraucher eingeschaltet, die Einträge im Logfile sind:
2014-12-11_09:52:05 CounterWF countsPerDay: 2
2014-12-11_09:52:05 CounterWF countsOverall: 727
2014-12-11_09:52:05 CounterWF pulseTimeIncrement: 0
2014-12-11_09:52:05 CounterWF pulseTimeEdge: 10510
2014-12-11_09:52:05 CounterWF pulseTimePerDay: 10510
2014-12-11_09:52:05 CounterWF pulseTimeOverall: 7850668
2014-12-11_09:52:05 CounterWF pauseTimeIncrement: 5215
2014-12-11_09:52:05 CounterWF pauseTimeEdge: 5215
2014-12-11_09:52:05 CounterWF pauseTimePerDay: 25015
2014-12-11_09:52:05 CounterWF pauseTimeOverall: 23313960
2014-12-11_09:52:05 CounterWF value: 1
2014-12-11_09:52:05 CounterWF 2
2014-12-11_09:52:05 CounterWF tickUpdated: 48
2014-12-11_09:52:05 CounterWF tickChanged: 25

Der Verbraucher war ja vorher abgeschaltet, warum wird dann eine pulseTimeEdge: 10510 aufgeführt?

Gruss bluesky

[John]

Hi bluesky,

..(obwohl ich keine Ahnung habe, was die genau bewirken sollten).

Wenn du das verstanden hast, wirst du auch deine Daten verstehen.

Zur Erklärung:

Wenn du event-on-change-reading und event-min-interval   löscht passiert folgendes:

Immer dann wenn das Modul ein Reading beschreibt, wird ein Event gefeuert.
Auch dann wenn sich das Reading nicht ändert.

Nun wollen wir daß die Readings nur noch dann einen Event auslösen, wenn sie sich tatsächlich ändern.
Das erreichen wir mit:

event-on-change-reading            .* 

.* ist ein regular Expression, der die Namen der Readings einschränken kann, für die event-on-change-reading gelten soll.
Im vorliegenden Fall bedeutet dies: die Regel gilt für alle Readings.

Wenn nun Readings dabei sind, die über Stunden oder Tage keine Änderung haben, wirst du keinen einzigen Eintrag in deinem Log-File finden,
da ja keine Events gefeuert wurden.

Es wäre vielleicht gut, wenn die Readings wenigsten 1x pro Stunde, auch ohne Änderung eine Event feuern würden.
Das erreicht man mit

event-min-interval .*:3600

Im Klartext: wenn ein Reading aktualisiert wird, soll es spätestens nach einer Stunde (3600 sec) nach dem letzten Event einen neuen Event feuern
auch wenn es sich nicht geändert hat.

Wenn du event-min-interval  nur für pauseTimeOverall alle 2 Minuten willst, müsste es wie folgt lauten:

tick.*:0,pauseTimeOverall:120

John