Hallo,
ich habe heute einen Zwischenstecker mit Leistungsmessung angelernt. Soweit ist alles wie beim normalen Zwischenstecker nur das ich Kanal 2 mit den Messwerten haben.
Nun bietet das Gerät nur den geräteeigenen Verbrauchswert als Reading (der vermutlich bei Spannungabbruch reseted wird). Die CCU zeigt im Device aber noch den Energie-Zähler CCU2 an (welcher sicher immer weiter hochgezählt wird ohne reset bei Spannungsabbruch um eine dauerhafte Messung zu haben, macht ja CUL_HM auch so zb bei Regenmenge, Verbrauch usw).
Wie kann ich nun den CCU Wert in FHEM einbinden? Es müsste ja ein Reading der CCU sein, eine Systemvariable ist es nicht
Ich glaube nicht, dass man da ran kommt.
dieser wert wird durch ein systeminternes script gebaut
object chn = dom.GetObject('3969');
object oBoot = chn.DPByControl('POWERMETER.BOOT');
object oEnergyCounter = chn.DPByControl('POWERMETER.ENERGY_COUNTER');
object oSysVarEnergyCounter = dom.GetObject('svEnergyCounter_3969_NEQ1808818:2');
object oSysVarEnergyCounterOldVal = dom.GetObject('svEnergyCounterOldVal_3969');
boolean bootFlag = oBoot.Value();
real devVal = oEnergyCounter.Value();
real devValMax = oEnergyCounter.ValueMax();
real oldDevVal = oSysVarEnergyCounterOldVal.Value();
real diffVal = 0.0;
real sysVarVal = oSysVarEnergyCounter.Value();
integer tmp_devVal = (devVal.ToString().ToFloat() * 100000).ToInteger();
integer tmp_oldDevVal = (oldDevVal.ToString().ToFloat() * 100000).ToInteger();
if (oldDevVal <= 0) {
oSysVarEnergyCounterOldVal.State(devVal);
oSysVarEnergyCounter.State(devVal);
} else {
if ( ( bootFlag == true ) && ( tmp_devVal < tmp_oldDevVal ) ) {
diffVal = devVal;
} else {
if (tmp_devVal >= tmp_oldDevVal) {
diffVal = devVal - oldDevVal;
}
if ((tmp_devVal > 0) && (tmp_devVal < tmp_oldDevVal)) {
diffVal = (devVal + devValMax) - oldDevVal;
}
}
if (devVal > 0) {
oSysVarEnergyCounterOldVal.State(devVal);
}
oSysVarEnergyCounter.State(sysVarVal + diffVal);
}
und schreibt es in die variabl oSysVarEnergyCounter.State
ich glaube das wäre der lösungsansatz
http://answers.mediola.com/1915243/Energiez%C3%A4hler-CCU2-nach-mediola-Neo
eigene systemvariable setzen wenn sich der wert ändert. hat den vorteil auch bei reset des steckers (hatte gelesen da geht der ccu wert auch verloren) noch den wert habe und vor dem
erhöhen prüfen kann
wert_neu < wert_alt ----> wert_alt = wert_alt + wert_neu
wert_neu > wert_alt ----> wert_alt = wert_neu (oder wert_alt = wert_alt + diff(wert_alt und neu) )
die eigene variable sollte ich ja auslesen können
Irgendwie scheint die CCU auch interne Systemvariablen zu führen, an die man über die normalen Variablen-Funktionen nicht ran kommt.
Der Name ist auch einigermaßen ungewöhnlich: svEnergyCounter_3969_NEQ1808818:2
Die 3969 dürfte die Geräte-ID der Steckdose oder des Kanals 2 sein.
Theoretisch könnte man aus diesen Angaben einen direkten Zugriff basteln. Es ist aber zu befürchten, dass EQ-3 mit einem Firmware Update irgendwann mal Änderungen vornimmt und das dann nicht mehr funktioniert. Von solchen undokumentierten Dingen sollte man die Finger weglassen. Da ist der andere Weg über eine eigene Systemvariable schon besser.
Gibt es eigentlich in FHEM keine Möglichkeit, einen solchen Counter zu realisieren?
doch, müsste man in ein helpermodul bauen wie zb average oder rain.
beim ks300 ist die funktion im device-modul, bei cul_hm dort mit drin. da sieht man schon das solche Kumulierung öfter gebraucht wird. einige machens es in myutils, andere in ihren devicemodulen. hier wäre es sinnvoll das auszulagern (wie zb dewpoint keinen sinn macht in lacrosse, cul_hm, ks300 je separat einzubauen)
anbei noch für die ccudef-readingname die werte falls du sie brauchst
Zitat
^(.+\.)?CURRENT:current;
^(.+\.)?ENERGY_COUNTER:energy;
^(.+\.)?FREQUENCY:frequency;
^(.+\.)?POWER:power;
^(.+\.)?VOLTAGE:voltage;
wie gedacht setzt sich nach firmwareupdate/stromenausfall der wert zurück. die ccu zählt weiter brav den internen zähler hoch
ZitatEnergie-Zähler CCU2
207.80 Wh
0.06 EUR
ZitatEnergie-Zähler Gerät
6.00 Wh
0.00 EUR
und das program das mir den wert in eine eigene variable schreibt die hmccu auslesen kann
var myVal=dom.GetObject('svEnergyCounter_3969_NEQ1808818:2').Value();
dom.GetObject("az_sw_lm01_count").State(myVal.ToString(2));
Die nächste Version wird dafür eine Lösung enthalten.
Ungefähr so:
attr mydev ccucalculate inc:ENERGY_USAGE:2.ENERGY_COUNTER
Erzeugt ein Reading ENERGY_USAGE. In diesem Reading wird der Verbrauch aufaddiert, auch wenn FHEM oder die CCU neu gestartet werden.
Zusätzlich wird ein Reading ENERGY_USAGE_old angelegt, sobald der Wert im Device zurückgesetzt wird. Das wird benötigt, damit der alte Stand nicht "vergessen" wird.
Ich check das demnächst ein. Dann kannst Du mal testen.
danke, werde ich testen.
ich habe parallel auch versucht ein 98_sumup helpermodul auf basis rain zu basteln da die [reading]_sum allein zwar toll ist, aber [reading]_sumhour, [reading]_sumday, ...month, ...year auch interessant sind. da man hier aber viel mit den timestamps rechnen muss ist das schon etwas komplizierter. aber die grundversion war deiner lösung ähnlich, aber auch auf andere devices anwendbar was nicht nur ccu usern zugute kommen würde
alte summe kleiner als reading?
ja:
|_ prüfen ob unser alter, "gecachter" readingswert größer als der neue des ext devices ist ...
denn dann wurde es resetet und der neu wert muss auf die alte summe addiert werden
|_ wenn nicht muss die differenz aus neuen wert und alten wert auf die summe addiert werden
nein: nicht setzen wir einfach das neue reading als summe
So ein Helper Modul wäre natürlich toll. Wenn es dann noch min, max und average unterstützt, wäre das die Kür.
Hatte auch überlegt, sowas zu bauen. Habe aber genug zu tun mit HMCCU, sodass ich einfach nicht die Zeit für ein neues Modul habe.
ein unser reading vom typ monotonic sollte genau machen was du möchtest.
mir ist aufgefallen das rain genau das macht was ich/wir hier wollen, da es grundsätzlich jedes reading akzeptiert.
mit einer definition wie folgt
DEF .*._lm.* energy energy_bla energy_calc
bekomme ich alle readings die ich will.
eigentlich muss man nur das modul rain neu benennen, die statischen readingnamen "rain_" im code ersetzen und den definepart etwas modifiezieren und es wäre universell
(was ich bei mir schon habe, jedoch nicht sicher bin ob man das so einchecken darf ohne rücksprache mit dem rain-erfinder und rudi weil helpermodul)
2017-04-28 13:26:53 energy 2996.4
2017-04-28 13:26:53 energy_calc_all cH: 0.0 lH: 2996.4 cD: 0.0 lD: 2996.4 IR: 1 Rnow: 0.0 Rdif: 2996.4
2017-04-28 13:26:53 energy_calc_d_curr 0.0
2017-04-28 13:26:53 energy_calc_d_last 2996.4
2017-04-28 13:26:53 energy_calc_d_start 2996.4
2017-04-28 13:26:53 energy_calc_d_trig_tsecs 1493443800
2017-04-28 13:26:53 energy_calc_h_curr 0.0
2017-04-28 13:26:53 energy_calc_h_last 2996.4
2017-04-28 13:26:53 energy_calc_h_start 2996.4
2017-04-28 13:26:53 energy_calc_h_trig_tsecs 1493379000
2017-04-28 13:26:53 energy_calc_now_diff 2996.4
2017-04-28 13:26:53 energy_calc_now_rate 0.0
2017-04-28 13:26:53 energy_calc_now_value 2996.4
2017-04-28 13:26:53 energy_calc_tsecs 1493378813
Die Version 4.0.003 von 88_HMCCU.pm enthält nun einige neue Funkionen für das Attribut ccucalculate für HMCCUDEV und HMCCUCHN.
Unter anderem gibt es die Funktion "inc", die ein Reading erzeugt, das bei einem Reset des zugrunde liegenden Wertes trotzdem weiter korrekt hochzählt.
Dazu kommen Funktionen wie min, max, avg usw.
@justme1968: du hast recht. Ein userreading vom Typ monotonic entspricht genau der gewünschten Funktion. Ich habe HMCCU trotzdem um die Funktion ergänz, da die direkte interne Berechnung in HMCCU etwas schneller ist als userreadings, die ja immer wieder durch Notify durch müssen.
user readings gehen nicht durch ein notify sondern werden direkt im readingsEndUpdate behandelt. der overhead ist also recht klein.
Danke, wieder was gelernt. Mal sehen, dann werfe ich meine Funktion ggf wieder raus. Muss ja nicht sein, dass es für die gleiche Sache zwei Lösungen gibt. Verwirrt die Nutzer nur.
Hallo zusammen,
ich habe das mal probiert mit:
attr mydev ccucalculate inc:ENERGY_USAGE:6.ENERGY_COUNTER
für ein HmIP-PSM, anfänglich scheint es zu funktionieren, jedoch wird der Wert irgendwann 4-5 stellig (wenn man lange genug wartet auch 6 stellig usw.), obwohl der Ausgangswert 6.ENERGY_COUNTER nach wie vor noch 2-3-stellig ist.
:-(
Der Post ist ja nun auch schon gut 3 Jahre alt, insofern die Frage: macht man das heutzutage anders oder ist dort ein Bug?
Ich benutze die aktuellste FHEM Version, 0 ausstehende Updates, und RaspberryMatic aktuellste Version auf einer CCU3.
Danke.