Leistungsprognose für Wechselrichter

Begonnen von ch.eick, 18 Januar 2021, 08:35:46

Vorheriges Thema - Nächstes Thema

Jewe

Habe das nun so übernommen:
defmod SENSOR_Strom_Power_cur.notify notify MQTT2_Stromzaehler.SENSOR_Strom_Power_cur:.* \
{\
 EnergieCounter($NAME,"SENSOR_Strom_Power_cur");;;; \
}
attr SENSOR_Strom_Power_cur.notify DbLogExclude .*
attr SENSOR_Strom_Power_cur.notify room Stromverbrauch,notify

Wenn ich nur die negativen Wert haben möchte, reicht es vmtl. nicht nur ein - voranzustellen: MQTT2_Stromzaehler.SENSOR_Strom_Power_cur:-.*
oder doch?

kask

#2536
Wenn du positiv wie negativ wird würde ich die EnergieCounterInOut nehmen.
Die Energiecounter sub macht aus den negativen eh positive und dann wird beides gemischt bzw. addiert.

Ansonsten ausprobieren.

Oder Integral.
Es kommt ganz drauf an wie die Daten reinkommen.
Ist es ein Wert den dein Gerät ausgibt der dem Durchschnitt seit dem letzen "senden" entspricht und vieleicht alle 30sec. übermittelt wird, dann ist inetragl dein Freund.
Ist es ein "jetzt" wert und der kommt schnell ändernd rein. Dann wirst du mit integral keine Freude haben. 
Da so wie ich das bei mir festgestellt habe der Wert nur Sekundengenau verrechnet wird. Und die Sekunden werden abgerundet also 2,9s = 2s verrechnet. So kam es mir vor und deckt sich mit der commandref.
Und dann wird das ganze sehr ungenau. von 2,9 zu 2 sind es dann mal geschmeidige 30% Unterschied. je größer der interval umso geringer wird die Ungenauigkeit.
Und, wie erwähnt, was sendet dein Gerät genau? Einen Wert der gerade ansteht oder ein Durschnittswert aus Zeit x oder dem letzten senden oder what ever.

Vieleicht kann aber einer was dazu sagen der das genau weiß was da passiert. Habe ich mir den code dazu noch nicht angeschaut.






Jewe

Zitat von: kask am 23 Mai 2023, 21:26:33Wenn du positiv wie negativ wird würde ich die EnergieCounterInOut nehmen.
Die Energiecounter sub macht aus den negativen eh positive und dann wird beides gemischt bzw. addiert.

Und, wie erwähnt, was sendet dein Gerät genau? Einen Wert der gerade ansteht oder ein Durschnittswert aus Zeit x oder dem letzten senden oder what ever.

Habe nun auf EnergieCounterInOut umgestellt und werden Morgen mal schauen was passiert.

In der Anleitung des Zähler steht nur Momentanbezug. Den intervall kann ihc nicht finden. Aber es ändert sich ständig, 1-2s. Also dann bin ihc ja mit Deiner Lösung vmtl. auf dem richtigen weg.

Danke Euch allen.

stefanru

Hi kask,

die Zeit der Datenabfrage sollte eigentlich keine Rolle spielen bei integral.
Außer natürlich du bekommst so selten Werte dass schon dadurch eine große Abweichung entsteht.
Je kürzer desto genauer das ist klar.
Aber wie gesagt die Werte sind absolut stimmig bei mir und passen auch zur Summer auf dem Anbieterportal.

Wenn du aber wissen willst wie oft ich abfrage, hatte 30 Sekunden und jetzt 15 Sekunden.

In der ComandRef steht dazu:
integral: das Gegenteil von differential. Das Ergebnis wird um das Produkt aus der Zeit-Differenz und der Durschnittswert der letzten zwei Readings erhöht.
result += (time - timeold) * (oldval + value) / 2

Und hier der original Thread vom Ersteller:
https://forum.fhem.de/index.php?topic=26300.0

Gruß,
Stefan

kask

Wenn das so ist, dann ist es ja nicht auf jede Sekunde abgerundet. Bei mir waren da massive Abweichungen mit integral.
Ich Probier das nochmal aus. Möchte ich jetzt wissen.
Und wie gsagt, das es bei dir so super passt kann viele Gründe haben. z.B. was sendet dein Gerät an Wert? Istwert oder gemittelt aus einer Zeitperiode.

kask

#2540
Ich habe das jetzt mal getestet und beobachtet das seit einiger Zeit.
Die Werte laufen auseinander. Der Integral über die Userreadings zählt weniger.
Beide werden auf das gleiche Ereigniss getriggert und zählen auch augenscheinlich immer zur gleichen Zeit.
Komisch, Komisch.

Wieso da in der integral funktion die Zeitdifferenz >= 1.0 sec sein soll(muß) erschliesst sich mir garnicht.
Bei der differential macht es Sinn damit der Wert nicht utopisch groß werden kann. Wird ja dividiert. Aber die Integral funktion mulipliziert (mikroskopisch klein also ;) ) also ist das total unnötig. Oder sehe ich da etwas nicht? Oder verstehe da was falsch.

Edit: In einer Stunde habe ich ca. 0.05kWh differenz. Bei ~100-600W(doofe Uhrzeit zum testen). Startwert war ca. 412.879xxxx
Nach 1,5h waren es schon 0,1kWh bei höherer Last.
Nach 2,5h sind es ca. 0,25kWh differenz.

@Jewe
Vieleicht kannst du ja auch mal gucken wie das bei dir mit den Userreadings aussieht.

Jewe

Hey,
wir waren gestern Erfolgreich, es funktiniert. 333Wh Eingespeist :-)

Die Userreadings hab ich nun auch mal eingefügt und später mal anschauen.

Jens

kask

Das ist gut. Bzw. Glück im Unglück oder umgekehrt. Jetzt weißt du was du verschenkst, vorher hast du nur geahnt ;D

330Watt eingespeist bei einem Einrichtungszähler mit Rücklaufsperre ist eher doof, aber hilft dir zum optimieren jetzt.

Man munkelt das der Zähler nicht saldierend sein soll. kA. ob das stimmt.

DS_Starter

ESXi 6.5 @NUC6i5SYH+FHEM auf Debian, DbLog/DbRep MariaDB
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

stefanru

Ok,

das ist ja wirklich interessant.

Es kann sein, dass ich hier wirklich den bei mir berechnete Werte mit Werten von dem Portal vergleiche die auch nur berechnet sind.
Und vielleicht verwenden sie für das Portal einfach den selben Ansatz?

Ich werde das Integral userReading mal gegen einen Wert laufen lassen den ich auch wirklich von der Anlage als Summe erhalte und melde mich dann wie das aussieht bei mir.

Gruß,
Stefan
 


DS_Starter

#2545
Wegen der Zeitberechnung...

das userReading integral verwendet zur Zeiterfassung gettimeofday() ->

    In array context returns a two-element array with the seconds and microseconds since the epoch

d.h. es gehen Sekunden und Microsekunden ein. Wenn man Perl time() verwendet, sind es nur volle Sekunden:

time

    Returns the number of non-leap seconds since whatever time the system considers to be the epoch

Daraus können sich Diskrepanzen ergeben.
Verwendet also besser gettimeofday() für eine Zeitmessung um genauere und vergleichbare Werte zu erhalten.
ESXi 6.5 @NUC6i5SYH+FHEM auf Debian, DbLog/DbRep MariaDB
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

kask

hmmm,

time() = 1684963346.13119   <- Das sind Sekunden, aber mit Kommastelle ;)
gettimeofday() = 1684963347.29519

Hab es mal beides getestet..liefert beides das gleiche ...mehr oder weniger..zumindest bei mir.

Gucke ich mir denoch mal an.

Jewe

Zitat von: kask am 24 Mai 2023, 22:16:47Man munkelt das der Zähler nicht saldierend sein soll. kA. ob das stimmt.

Also das kann ich nicht bestätigen. Der Zähler zeigt auch negativ Werte an. Leider dreht er nicht zurück :-)


DS_Starter

ESXi 6.5 @NUC6i5SYH+FHEM auf Debian, DbLog/DbRep MariaDB
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Jewe

Zitat von: kask am 24 Mai 2023, 19:53:56@Jewe
Vieleicht kannst du ja auch mal gucken wie das bei dir mit den Userreadings aussieht.

Also nun läuft es eine weile so und man sihet schon wie die Werte auseinander laufen.