Neue Version OWCOUNT

[Prof. Dr. Peter Henning]

Guten Morgen,

ich habe eine neue Version von OWCOUNT eingecheckt. Neben diversen kleineren Fixes enthält diese alle Modifikationen, die Norbert Truchsess seit meinem letzten Update vorgenommen hatte (meine Güte, das war im Februar ... irgendetwas frisst meine Zeit).

Zusätzlich läuft jetzt das tägliche und monatliche Logging stabil.

Unerwünschte Effekte sind nicht ausgeschlossen, also bitte testen.

LG

pah

[Prof. Dr. Peter Henning]

Und leider im letzten Schönheits-Edit einen Bug eingebaut - gefixt.

LG

pah

[det.]

Hallo pah,
ist das eine Auswirkung Deines Updates von heute früh?

Code Auswählen Erweitern

2014.01.12 15:01:03 1: Caluclating rate from oldval=23368.9, vval=23369, delt=300 as 0.000333333333328483
2014.01.12 15:01:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:06:03 1: Caluclating rate from oldval=23369, vval=23369.1, delt=300 as 0.000333333333328483
2014.01.12 15:06:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:11:03 1: Caluclating rate from oldval=23369.1, vval=23369.2, delt=300 as 0.000333333333340609
2014.01.12 15:11:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:16:03 1: Caluclating rate from oldval=23369.2, vval=23369.3, delt=300 as 0.000333333333328483
2014.01.12 15:16:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:21:03 1: Caluclating rate from oldval=23369.3, vval=23369.5, delt=300 as 0.000666666666669092
2014.01.12 15:21:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:26:03 1: Caluclating rate from oldval=23369.5, vval=23369.6, delt=300 as 0.000333333333328483
2014.01.12 15:26:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:31:03 1: Caluclating rate from oldval=23369.6, vval=23369.7, delt=300 as 0.000333333333340609
2014.01.12 15:31:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:36:03 1: Caluclating rate from oldval=23369.7, vval=23369.8, delt=300 as 0.000333333333328483
2014.01.12 15:36:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:41:03 1: Caluclating rate from oldval=23369.8, vval=23369.9, delt=300 as 0.000333333333340609
2014.01.12 15:41:03 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 15:46:05 1: Caluclating rate from oldval=23369.9, vval=23370, delt=302 as 0.000331125827809751
2014.01.12 15:46:05 1: Caluclating rate from oldval=0.828, vval=0.828, delt=302 as 0
2014.01.12 15:51:04 1: Caluclating rate from oldval=23370, vval=23370.1, delt=299 as 0.00033444816053025
2014.01.12 15:51:04 1: Caluclating rate from oldval=0.828, vval=0.828, delt=299 as 0
2014.01.12 15:56:04 1: Caluclating rate from oldval=23370.1, vval=23370.2, delt=300 as 0.000333333333340609
2014.01.12 15:56:04 1: Caluclating rate from oldval=0.828, vval=0.828, delt=300 as 0
2014.01.12 16:01:04 1: Caluclating rate from oldval=23370.2, vval=23370.3, delt=300 as 0.000333333333328483


nach Rückspielen der Version 21_OWCOUNT.pm 4199 2013-11-10 19:59:29Z ntruchsess $
sind die Log Ausgaben weg

[Prof. Dr. Peter Henning]

Ach ja, seufz ... tut mir leid.

Das war die Debug-Ausgabe, die ich nicht wieder herausgenommen habe. Zum Trost: Mein Log ist auch vollgemüllt.

Ist bereinigt.

LG

pah

[det.]

Hallo pah,
Nicht so schlimm, die Vorversion macht's ja bisher auch. Kannst Du bitte gelegentlich ein Beispiel in die  comandref integrieren, wie die Monats- und Jahreswerte richtig definiert werden. Hier im Forum steht dazu an vielen Stellen immer mal was, hat mich aber leider nicht zum Ziel geführt.
In Summe läuft OWX seit vielen Monaten wesentlich stabiler als der FS20 CUL Funk, der zum Glück nur noch für paar Sachen mit optischer Rückmeldung verantwortlich ist.

[ntruchsess]

hab die Änderungen grade in meinen Branch owx_asnc auf github übernommen.

- Norbert

[ntruchsess]

ach ja, wie wäre es denn wenn man die Tageszähler optional genauso filebasiert wie die Monatszähler machen würde? Dann würde die nämlich auch mit den ATiny25 basierten Countern von dougie funktionieren.

[Prof. Dr. Peter Henning]

@det:

Nach meiner Semantik gehört das nicht in die Commandref. Hier mein Testbeispiel:

- Der A-Kanal zählt Tastendrücke, ist also im inkrementierenden ("normalen") Modus = wird nicht täglich auf Null gesetzt. Diese Tastendrücke haben den Namen "GPunkte" erhalten (steht für Gummipunkte, um Fehlinterpretationen zuvorzukommen ...), die Anzahl der Gummipunkte/Minute heißt "GRate".

- Der B-Kanal zählt Impulse (à la Stromzähler - obwohl hier zu Testzwecken ein Timer dranhängt, der im Moment alle4 Sekunden ein Signal abgibt). Dabei steht jeder Impuls für 0,001 kWh => BFactor ist 0.001. Außerdem ist dieser Kanal im BMode=daily, es wird also jeden Nacht kurz vor Mitternacht der Mitternachtswert extrapoliert und als "day" Wert ausgegeben. Dieser Wert wird auch im internen Memory als "midnight B" gespeichert und vom Zählerstand abgezogen. Bei dem Testgerät sind das also pro Tag 21,6 kWh = 86400 Sekunden / 4 Sekunden * 0,001 kWh

- Das monatliche Logging erfolgt durch das FileLog  OWCM.FL, siehe dessen Definition darunter. Darin stehen Zeilen wie:
2014-01-09_23:59:42 OWC day: D09  GPunkte:  49.0 cts GPunktem:  49.0 cts  E-Energy:  21.6 kWh E-Energym:   21.60 kWh
2014-01-10_23:59:43 OWC day: D10  GPunkte:  89.0 cts GPunktem:  89.0 cts  E-Energy:  21.6 kWh E-Energym:   43.20 kWh
2014-01-11_23:59:39 OWC day: D11  GPunkte:  89.0 cts GPunktem:  89.0 cts  E-Energy:  21.6 kWh E-Energym:   64.80 kWh
2014-01-12_23:59:55 OWC day: D12  GPunkte:  89.0 cts GPunktem:  89.0 cts  E-Energy:  21.6 kWh E-Energym:  86.4 kWh
2014-01-13_23:59:11 OWC day: D13  GPunkte:  89.0 cts GPunktem:  89.0 cts  E-Energy:  21.6 kWh E-Energym: 108.0 kWh
Damit wird also in der 9. und der 15. Spalte der kumulierte monatliche Wert berechnet.  Dazu muss natürlich das Modul wissen, in welchem Device das Logging erfolgt - dazu wird das Attribut LogM auf OWCM.FL gesetzt. Man kann also jederzeit mit "get OWC month" fragen, was der bisherige monatliche Verbrauch ist - das Modul liest dann die entsprechende Datei.

- Das jährliche Logging wird ganz ähnlich gemacht, dazu muss dann natürlich LogY auf den Namen des Filelog OWCY.FL gesetzt werden.

define OWC OWCOUNT 1D.CE780F000000 60
attr OWC model DS2423
attr OWC room Obergeschoss

attr OWC AName GPunkte|
attr OWC ARate GRate|
attr OWC APeriod minute

attr OWC BName E-Energy|energy
attr OWC BRate E-Power|power
attr OWC BUnit kWh|kWh
attr OWC BFactor 0.001
attr OWC BMode daily

attr OWC LogM OWCM.FL
attr OWC LogY OWCY.FL

define OWC.FL FileLog /home/fhem/fhemlogs/OWC-%Y-%m-%d.log OWC.*GPunkte.*E-Energy.*
attr OWC.FL room Obergeschoss

define OWCM.FL FileLog /home/fhem/fhemlogs/OWCM-%Y-%m.log OWC.*day.*
attr OWCM.FL room Obergeschoss

define OWCY.FL FileLog /home/fhem/fhemlogs/OWCY-%Y.log OWC.*month.*
attr OWCY.FL room Obergeschoss

LG

pah

[Prof. Dr. Peter Henning]

@ntruchsess:

Ein Beispiel dafür findet sich in meinem  Modul 15_EMX.pm - da wird der Midnight-Wert in eine Datei gespeichert. Ich fand es aber hier einfach lustiger, mal den internen Speicher zu nutzen. Ich wusste bisher nicht, dass der DS2423-Nachbau - der übrigens von Tobias Müller stammt, siehe hier: http://www.tm3d.de/index.php/1-wire-device-mit-avr - keinen RAM hat. Einerseits wäre es keine Schwierigkeit, die Software von Müller so zu erweitern, dass sie auch den RAM anbietet.

Andererseits aber, und da bin ich konsequent: Ich werde nicht auch noch in diese Arbeit einsteigen, die Zeit habe ich einfach nicht. Mal sehen, ob ich nicht stattdessen einfach das aus dem EMX ins OWCOUNT übernehme, das erweitert die Anwendungsmöglichkeiten von OWCOUNT doch deutlich.

Frag mich in 2 Monaten noch einmal ...

LG

pah

[ntruchsess]

@pah: Mir geht's da schon fast genauso. Bei mir ist es aber nicht nur der Broterwerb - ich hab auch Opensource-seitig mittlerweile auch so viele Baustellen, dass es halt nur noch langsam weitergeht. Den Zeitaufwand seine eigene Software zu supporten, wenn sie unerwartet erfolgreich ist, unterschätzt man leicht. Aber vieleicht finde ich ja mal zwischendrin Zeit, das mit dem Tageszähler zu implementieren.

Gruß,

Norbert

[det.]

@pah,
vielen Dank für das anschauliche Beispiel. Das wird sicher vielen beim Verständnis der Sache hilfreich sein.

[Prof. Dr. Peter Henning]

Ich habe die Anregung aufgegriffen und eine Version von OWCOUNT erstellt, die beim Setzen des Attributes "nomemory=1" statt des internen Speichers eine Datei verwendet.

Selbstverständlich wird auch automatisch geprüft, ob es sich um die Software-Nachbildung des DS2423 handelt - und dann automatisch "nomemory=1" gesetzt.
Diese Software-Nachbildung bekommt dann auch den Attributwert "model=DS2423emu".

Da das noch mit heißer Nadel genäht ist, hänge ich es hier mal zum Testen an.

LG

pah

[Wzut]

beim Setzen des Attributes "nomemory=1" statt des internen Speichers eine Datei verwendet.

Diese Datei bzw Dateien werden allerdings nicht automatisch erzeugt sondern müssen von Hand im FHEM/ angelegt werden (  OWCOUNT_<name>_14.dat & -15.dat ) sonst gibt es jede Menge Einträge im log

Ich habe mit der aktuellen Version aber noch das Problem das ich wesentlich mehr Einträge in meinen logs habe als es nach eingestelltem Intervall sein dürften ( Intervall auf 120  log Einträge aber ca. im 30 Sekunden Takt )
Auszug aus dem log kurz vor Mitternacht (D13 sollte ja eigentlich nur 1x drin stehen) :

Code Auswählen Erweitern


2014-02-13_23:58:01 Zaehler day: D13  A:   0.0 kWh AM:   0.0 kWh  DG-Energy: 101.8 kWh DG-EnergyM: 188.6 kWh
2014-02-13_23:58:32 Zaehler day: D13  A:   0.0 kWh AM:   0.0 kWh  DG-Energy: 101.8 kWh DG-EnergyM: 290.4 kWh
2014-02-13_23:59:00 Zaehler day: D13  A:   0.0 kWh AM:   0.0 kWh  DG-Energy: 101.8 kWh DG-EnergyM: 392.1 kWh
2014-02-13_23:59:11 Zaehler day: D13  A:   0.0 kWh AM:   0.0 kWh  DG-Energy: 101.8 kWh DG-EnergyM: 494.0 kWh
2014-02-13_23:59:31 Zaehler day: D13  A:   0.0 kWh AM:   0.0 kWh  DG-Energy: 101.8 kWh DG-EnergyM: 595.8 kWh

Zuerst hatte ich einen ähnlichen Fehler vermutet wie die letzten Tage in OWTHERM, aber nach einigem Suchen bin ich fündig geworden in der get Abfrage

Code Auswählen Erweitern

$hash->{PRESENT} = 1;
    #-- only one counter will be returned
    OWCOUNT_FormatValues($hash);
     return "OWCOUNT: $name.raw $a[2] => ".$hash->{owg_val}->[$page-14];

  #-- check syntax for getting counters
  }elsif( $reading eq "counters" ){
    return "OWCOUNT: Get needs no parameter when reading counters"
      if( int(@a)==1 );
    $ret1 = OWCOUNT_GetPage($hash,14);
    $ret2 = OWCOUNT_GetPage($hash,15);

    #-- process results
    $ret .= $ret1
      if( defined($ret1) );
    $ret .= $ret2
      if( defined($ret2) );
    if( defined($ret1) || defined($ret2) ){
      return "OWCOUNT: Could not get values from device $name, reason: ".$ret;
    }
    $hash->{PRESENT} = 1;
    #-- both counters will be returned
    return "OWCOUNT: $name.counters => ".OWCOUNT_FormatValues($hash);
 
Die Aufrufe von OWCOUNT_FormatValues sind verantwortlich für die zusätzlichen Ausgaben.
Hintergrund  bei mir : Ich habe auf einem anderen Server einen cronjob laufen der alle 30 Sekunden vom FHEM Server mit get <name> raw (A,B) die aktuellen Zählerstände holt. Ich habe für mich jetzt den ersten der beiden   OWCOUNT_FormatValues Aufrufe auskommentiert und liefere damit meinem anderen Server halt den letzten zyklisch ermittelteten Wert von GetValues.

[Prof. Dr. Peter Henning]

It's not a bug, it's a feature.

Das Modul ist nicht darauf eingerichtet, dass alle paar Sekunden externe Abfragen nach dem Zählerstand kommen - das triggert nämlich jedesmal den Bus.

Warum denn nicht einfach den Wert verwenden, der im Hash steht ?

LG

pah

[Wzut]

Ok , in der Form ( aus der Ferne )

Code Auswählen Erweitern

/opt/fhem/fhem.pl 192.168.0.10:7072 '{sprintf("%i",$defs{Zaehler}{owg_val}[1])}'
statt
/opt/fhem/fhem.pl 192.168.0.10:7072 "get Zaehler raw B"

oder geht es noch eleganter ?