Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

Begonnen von DS_Starter, 19 Mai 2016, 22:52:13

Vorheriges Thema - Nächstes Thema

DS_Starter

Habe den "daylight saving time"-check noch verbessert um das Modul auch für die nächste Zeitumstellung vorbereitet zu haben.
Der Version 4.6.1 ist wieder im ersten Beitrag.
Ich checke die Version noch ein. Sie ist morgen wieder im update.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
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

JoeALLb

Hm, warum wird bei mir das diff für 2015-11 ausgelassen?
hier habe ich fast jeden Tag Werte in der DB stehen...
2015-11-27_19-24-23__XXYY__total__DIFF__2015-10   636.9493  2016-11-11 14:47:48
2015-12-16_21-14-49__XXYY__total__DIFF__2015-12   169.1893  2016-11-11 14:47:48

Liegt das daran dass mein Zähler übersprungen hat und am 1.10 neu von 0 angefangen hat? Ich denke, das sollte berücksichtigt werden, denn das ufhem-serreading berücksichtigt das auch!
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

Hallo JoeAllb,

Unabhängig von der Ursache werden mit dem Modul NUR in der DB vorhandene Werte ausgewertet. D.h. der Nutzer bzw. die schreibende Applikation hat dafür Sorge zu tragen dass die Daten im Sinne der Auswertung vollständig und integer sind.
DiffValue ermittelt den Differenzbetrag eines sich STETIG erhöhenden Wertes. Soweit zur Theorie.

Zu deinem speziellen Problem kann ich momentan nichts sagen. Dazu brauche ich mehr Infos. Mach mal bitte ein list des DbRep und auch einen verbose 4 Log. Dann sehen wir mehr.

VG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
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

JoeALLb

Nun ja, der Zähler hat halt einen Maximalwert, und wenn dieser überschritten wird, fängt er automatisch wieder bei 0 an, ähnlich wie bei einem Tacho beim Auto.
Aber in der Theorie würde es ja beim Umsprung auf 0 einen negativen DIFF-Wert geben. Den würde ich ignorieren und am nächsten Tag wieder neu die Differenz bilden...

Anbei das List:
Internals:
   DATABASE   fhem
   DEF        myDbLogSQL
   LASTCMD
   NAME       calc_solar_year
   NOTIFYDEV  global,calc_solar_year
   NR         310
   NTFY_ORDER 50-calc_solar_year
   ROLE       Client
   STATE      connected
   TYPE       DbRep
   Helper:
     DBLOGDEVICE myDbLogSQL
   Readings:
     2016-11-11 14:47:48   2000-01-17__solar__total__DIFF__2000-01 -
     2016-11-11 14:47:48   2000-02-01__solar__total__DIFF__2000-02 -
     2016-11-11 14:47:48   2000-03-01__solar__total__DIFF__2000-03 -
     2016-11-11 14:47:48   2000-04-01__solar__total__DIFF__2000-04 -
     2016-11-11 14:47:48   2000-05-01__solar__total__DIFF__2000-05 -
     2016-11-11 14:47:48   2000-06-01__solar__total__DIFF__2000-06 -
     2016-11-11 14:47:48   2000-07-01__solar__total__DIFF__2000-07 -
     2016-11-11 14:47:48   2000-08-01__solar__total__DIFF__2000-08 -
     2016-11-11 14:47:48   2000-09-01__solar__total__DIFF__2000-09 -
     2016-11-11 14:47:48   2000-10-01__solar__total__DIFF__2000-10 -
     2016-11-11 14:47:48   2000-11-01__solar__total__DIFF__2000-11 -
     2016-11-11 14:47:48   2000-12-01__solar__total__DIFF__2000-12 -
     2016-11-11 14:47:48   2001-01-01__solar__total__DIFF__2001-01 -
     2016-11-11 14:47:48   2001-02-01__solar__total__DIFF__2001-02 -
     2016-11-11 14:47:48   2001-03-01__solar__total__DIFF__2001-03 -
     2016-11-11 14:47:48   2001-04-01__solar__total__DIFF__2001-04 -
     2016-11-11 14:47:48   2001-05-01__solar__total__DIFF__2001-05 -
     2016-11-11 14:47:48   2001-06-01__solar__total__DIFF__2001-06 -
     2016-11-11 14:47:48   2001-07-01__solar__total__DIFF__2001-07 -
     2016-11-11 14:47:48   2001-08-01__solar__total__DIFF__2001-08 -
     2016-11-11 14:47:48   2001-09-01__solar__total__DIFF__2001-09 -
     2016-11-11 14:47:48   2001-10-01__solar__total__DIFF__2001-10 -
     2016-11-11 14:47:48   2001-11-01__solar__total__DIFF__2001-11 -
     2016-11-11 14:47:48   2001-12-01__solar__total__DIFF__2001-12 -
     2016-11-11 14:47:48   2002-01-01__solar__total__DIFF__2002-01 -
     2016-11-11 14:47:48   2002-03-01__solar__total__DIFF__2002-03 -
     2016-11-11 14:47:48   2002-04-01__solar__total__DIFF__2002-04 -
     2016-11-11 14:47:48   2002-05-01__solar__total__DIFF__2002-05 -
     2016-11-11 14:47:48   2002-06-01__solar__total__DIFF__2002-06 -
     2016-11-11 14:47:48   2002-07-01__solar__total__DIFF__2002-07 -
     2016-11-11 14:47:48   2002-08-01__solar__total__DIFF__2002-08 -
     2016-11-11 14:47:48   2002-09-01__solar__total__DIFF__2002-09 -
     2016-11-11 14:47:48   2002-10-01__solar__total__DIFF__2002-10 -
     2016-11-11 14:47:48   2002-11-01__solar__total__DIFF__2002-11 -
     2016-11-11 14:47:48   2002-12-01__solar__total__DIFF__2002-12 -
     2016-11-11 14:47:48   2003-01-01__solar__total__DIFF__2003-01 -
     2016-11-11 14:47:48   2003-02-01__solar__total__DIFF__2003-02 -
     2016-11-11 14:47:48   2003-03-01__solar__total__DIFF__2003-03 -
     2016-11-11 14:47:48   2003-04-01__solar__total__DIFF__2003-04 -
     2016-11-11 14:47:48   2003-05-01__solar__total__DIFF__2003-05 -
     2016-11-11 14:47:48   2003-06-01__solar__total__DIFF__2003-06 -
     2016-11-11 14:47:48   2003-07-01__solar__total__DIFF__2003-07 -
     2016-11-11 14:47:48   2003-08-01__solar__total__DIFF__2003-08 -
     2016-11-11 14:47:48   2003-09-01__solar__total__DIFF__2003-09 -
     2016-11-11 14:47:48   2003-10-01__solar__total__DIFF__2003-10 -
     2016-11-11 14:47:48   2003-11-01__solar__total__DIFF__2003-11 -
     2016-11-11 14:47:48   2003-12-01__solar__total__DIFF__2003-12 -
     2016-11-11 14:47:48   2004-01-01__solar__total__DIFF__2004-01 -
     2016-11-11 14:47:48   2004-02-01__solar__total__DIFF__2004-02 -
     2016-11-11 14:47:48   2004-03-01__solar__total__DIFF__2004-03 -
     2016-11-11 14:47:48   2004-04-01__solar__total__DIFF__2004-04 -
     2016-11-11 14:47:48   2004-05-01__solar__total__DIFF__2004-05 -
     2016-11-11 14:47:48   2004-06-01__solar__total__DIFF__2004-06 -
     2016-11-11 14:47:48   2004-07-01__solar__total__DIFF__2004-07 -
     2016-11-11 14:47:48   2004-08-01__solar__total__DIFF__2004-08 -
     2016-11-11 14:47:48   2004-09-01__solar__total__DIFF__2004-09 -
     2016-11-11 14:47:48   2004-10-01__solar__total__DIFF__2004-10 -
     2016-11-11 14:47:48   2004-11-01__solar__total__DIFF__2004-11 -
     2016-11-11 14:47:48   2004-12-01__solar__total__DIFF__2004-12 -
     2016-11-11 14:47:48   2005-01-01__solar__total__DIFF__2005-01 -
     2016-11-11 14:47:48   2005-02-01__solar__total__DIFF__2005-02 -
     2016-11-11 14:47:48   2005-03-01__solar__total__DIFF__2005-03 -
     2016-11-11 14:47:48   2005-04-01__solar__total__DIFF__2005-04 -
     2016-11-11 14:47:48   2005-05-01__solar__total__DIFF__2005-05 -
     2016-11-11 14:47:48   2005-06-01__solar__total__DIFF__2005-06 -
     2016-11-11 14:47:48   2005-07-01__solar__total__DIFF__2005-07 -
     2016-11-11 14:47:48   2005-08-01__solar__total__DIFF__2005-08 -
     2016-11-11 14:47:48   2005-09-01__solar__total__DIFF__2005-09 -
     2016-11-11 14:47:48   2005-10-01__solar__total__DIFF__2005-10 -
     2016-11-11 14:47:48   2005-11-01__solar__total__DIFF__2005-11 -
     2016-11-11 14:47:48   2005-12-01__solar__total__DIFF__2005-12 -
     2016-11-11 14:47:48   2006-01-01__solar__total__DIFF__2006-01 -
     2016-11-11 14:47:48   2006-02-01__solar__total__DIFF__2006-02 -
     2016-11-11 14:47:48   2006-03-01__solar__total__DIFF__2006-03 -
     2016-11-11 14:47:48   2006-04-01__solar__total__DIFF__2006-04 -
     2016-11-11 14:47:48   2006-05-01__solar__total__DIFF__2006-05 -
     2016-11-11 14:47:48   2006-06-01__solar__total__DIFF__2006-06 -
     2016-11-11 14:47:48   2006-07-01__solar__total__DIFF__2006-07 -
     2016-11-11 14:47:48   2006-08-01__solar__total__DIFF__2006-08 -
     2016-11-11 14:47:48   2006-10-01__solar__total__DIFF__2006-10 -
     2016-11-11 14:47:48   2006-11-01__solar__total__DIFF__2006-11 -
     2016-11-11 14:47:48   2006-12-01__solar__total__DIFF__2006-12 -
     2016-11-11 14:47:48   2007-01-01__solar__total__DIFF__2007-01 -
     2016-11-11 14:47:48   2007-02-01__solar__total__DIFF__2007-02 -
     2016-11-11 14:47:48   2007-03-01__solar__total__DIFF__2007-03 -
     2016-11-11 14:47:48   2007-04-01__solar__total__DIFF__2007-04 -
     2016-11-11 14:47:48   2007-05-01__solar__total__DIFF__2007-05 -
     2016-11-11 14:47:48   2007-06-01__solar__total__DIFF__2007-06 -
     2016-11-11 14:47:48   2007-07-01__solar__total__DIFF__2007-07 -
     2016-11-11 14:47:48   2007-08-01__solar__total__DIFF__2007-08 -
     2016-11-11 14:47:48   2007-09-01__solar__total__DIFF__2007-09 -
     2016-11-11 14:47:48   2007-10-01__solar__total__DIFF__2007-10 -
     2016-11-11 14:47:48   2007-11-01__solar__total__DIFF__2007-11 -
     2016-11-11 14:47:48   2007-12-01__solar__total__DIFF__2007-12 -
     2016-11-11 14:47:48   2008-01-01__solar__total__DIFF__2008-01 -
     2016-11-11 14:47:48   2008-02-01__solar__total__DIFF__2008-02 -
     2016-11-11 14:47:48   2008-03-31_23-00-00__solar__total__DIFF__2008-03 344.7000
     2016-11-11 14:47:48   2008-04-30_23-00-00__solar__total__DIFF__2008-04 499.6000
     2016-11-11 14:47:48   2008-05-31_23-00-00__solar__total__DIFF__2008-05 692.0000
     2016-11-11 14:47:48   2008-06-30_23-00-00__solar__total__DIFF__2008-06 511.1000
     2016-11-11 14:47:48   2008-07-31_23-00-00__solar__total__DIFF__2008-07 585.6000
     2016-11-11 14:47:48   2008-08-31_23-00-00__solar__total__DIFF__2008-08 531.9000
     2016-11-11 14:47:48   2008-09-30_23-00-00__solar__total__DIFF__2008-09 406.0000
     2016-11-11 14:47:48   2008-10-31_23-00-00__solar__total__DIFF__2008-10 276.1000
     2016-11-11 14:47:48   2008-11-30_23-00-00__solar__total__DIFF__2008-11 219.3000
     2016-11-11 14:47:48   2008-12-31_23-00-00__solar__total__DIFF__2008-12 115.8000
     2016-11-11 14:47:48   2009-01-31_23-00-00__solar__total__DIFF__2009-01 235.1200
     2016-11-11 14:47:48   2009-02-28_23-00-00__solar__total__DIFF__2009-02 140.9000
     2016-11-11 14:47:48   2009-03-31_23-00-00__solar__total__DIFF__2009-03 339.9000
     2016-11-11 14:47:48   2009-04-30_23-00-00__solar__total__DIFF__2009-04 565.0000
     2016-11-11 14:47:48   2009-05-31_23-00-00__solar__total__DIFF__2009-05 609.0000
     2016-11-11 14:47:48   2009-06-30_23-00-00__solar__total__DIFF__2009-06 522.1000
     2016-11-11 14:47:48   2009-07-31_23-00-00__solar__total__DIFF__2009-07 544.3000
     2016-11-11 14:47:48   2009-08-31_23-00-00__solar__total__DIFF__2009-08 626.5000
     2016-11-11 14:47:48   2009-09-30_23-00-00__solar__total__DIFF__2009-09 435.5000
     2016-11-11 14:47:48   2009-10-31_23-00-00__solar__total__DIFF__2009-10 238.5000
     2016-11-11 14:47:48   2009-11-30_23-00-00__solar__total__DIFF__2009-11 220.0000
     2016-11-11 14:47:48   2009-12-31_23-00-00__solar__total__DIFF__2009-12 13.7000
     2016-11-11 14:47:48   2010-01-31_23-00-00__solar__total__DIFF__2010-01 80.6000
     2016-11-11 14:47:48   2010-02-28_23-00-00__solar__total__DIFF__2010-02 219.0000
     2016-11-11 14:47:48   2010-03-31_23-00-00__solar__total__DIFF__2010-03 366.0000
     2016-11-11 14:47:48   2010-04-30_23-00-00__solar__total__DIFF__2010-04 494.6000
     2016-11-11 14:47:48   2010-05-31_23-00-00__solar__total__DIFF__2010-05 394.5900
     2016-11-11 14:47:48   2010-06-30_23-00-00__solar__total__DIFF__2010-06 263.8000
     2016-11-11 14:47:48   2010-07-31_23-00-00__solar__total__DIFF__2010-07 621.4000
     2016-11-11 14:47:48   2010-08-31_23-00-00__solar__total__DIFF__2010-08 -
     2016-11-11 14:47:48   2010-09-30_23-00-00__solar__total__DIFF__2010-09 345.9000
     2016-11-11 14:47:48   2010-10-31_23-00-00__solar__total__DIFF__2010-10 324.2000
     2016-11-11 14:47:48   2010-11-30_23-00-00__solar__total__DIFF__2010-11 1.2000
     2016-11-11 14:47:48   2010-12-31_23-00-00__solar__total__DIFF__2010-12 33.6000
     2016-11-11 14:47:48   2011-02-28_23-00-00__solar__total__DIFF__2011-01 482.4100
     2016-11-11 14:47:48   2011-03-31_23-00-00__solar__total__DIFF__2011-03 324.5000
     2016-11-11 14:47:48   2011-04-30_23-00-00__solar__total__DIFF__2011-04 367.3700
     2016-11-11 14:47:48   2011-05-31_23-00-00__solar__total__DIFF__2011-05 -
     2016-11-11 14:47:48   2011-06-30_23-00-00__solar__total__DIFF__2011-06 133.1000
     2016-11-11 14:47:48   2011-07-31_23-00-00__solar__total__DIFF__2011-07 -
     2016-11-11 14:47:48   2011-08-31_23-00-00__solar__total__DIFF__2011-08 -
     2016-11-11 14:47:48   2011-09-30_23-00-00__solar__total__DIFF__2011-09 -
     2016-11-11 14:47:48   2011-10-31_23-00-00__solar__total__DIFF__2011-10 47.9000
     2016-11-11 14:47:48   2011-11-30_23-00-00__solar__total__DIFF__2011-11 315.0000
     2016-11-11 14:47:48   2011-12-30_23-00-00__solar__total__DIFF__2011-12 102.0500
     2016-11-11 14:47:48   2012-01-01__solar__total__DIFF__2012-01 -
     2016-11-11 14:47:48   2012-02-19_23-00-00__solar__total__DIFF__2012-02 -
     2016-11-11 14:47:48   2012-03-27_23-00-00__solar__total__DIFF__2012-03 -
     2016-11-11 14:47:48   2012-04-01__solar__total__DIFF__2012-04 -
     2016-11-11 14:47:48   2012-05-28_23-00-00__solar__total__DIFF__2012-05 -
     2016-11-11 14:47:48   2012-06-01__solar__total__DIFF__2012-06 -
     2016-11-11 14:47:48   2012-07-24_23-00-00__solar__total__DIFF__2012-07 29.4000
     2016-11-11 14:47:48   2012-08-01__solar__total__DIFF__2012-08 -
     2016-11-11 14:47:48   2012-09-11_23-00-00__solar__total__DIFF__2012-09 19.4000
     2016-11-11 14:47:48   2012-10-01__solar__total__DIFF__2012-10 -
     2016-11-11 14:47:48   2012-11-01__solar__total__DIFF__2012-11 -
     2016-11-11 14:47:48   2012-12-13_23-00-00__solar__total__DIFF__2012-12 -
     2016-11-11 14:47:48   2013-01-01__solar__total__DIFF__2013-01 -
     2016-11-11 14:47:48   2013-02-01__solar__total__DIFF__2013-02 -
     2016-11-11 14:47:48   2013-03-01__solar__total__DIFF__2013-03 -
     2016-11-11 14:47:48   2013-04-01__solar__total__DIFF__2013-04 -
     2016-11-11 14:47:48   2013-05-01__solar__total__DIFF__2013-05 -
     2016-11-11 14:47:48   2013-06-01__solar__total__DIFF__2013-06 -
     2016-11-11 14:47:48   2013-07-01__solar__total__DIFF__2013-07 -
     2016-11-11 14:47:48   2013-08-01__solar__total__DIFF__2013-08 -
     2016-11-11 14:47:48   2013-09-01__solar__total__DIFF__2013-09 -
     2016-11-11 14:47:48   2013-10-01__solar__total__DIFF__2013-10 -
     2016-11-11 14:47:48   2013-11-09_23-00-00__solar__total__DIFF__2013-11 -
     2016-11-11 14:47:48   2013-12-01__solar__total__DIFF__2013-12 -
     2016-11-11 14:47:48   2014-01-22_17-33-53__solar__total__DIFF__2014-01 125.7440
     2016-11-11 14:47:48   2014-02-28_23-37-35__solar__total__DIFF__2014-02 379.9520
     2016-11-11 14:47:48   2014-03-10_14-06-18__solar__total__DIFF__2014-03 145.5893
     2016-11-11 14:47:48   2014-04-01__solar__total__DIFF__2014-04 -
     2016-11-11 14:47:48   2014-05-01__solar__total__DIFF__2014-05 -
     2016-11-11 14:47:48   2014-06-01__solar__total__DIFF__2014-06 -
     2016-11-11 14:47:48   2014-07-01__solar__total__DIFF__2014-07 -
     2016-11-11 14:47:48   2014-08-01__solar__total__DIFF__2014-08 -
     2016-11-11 14:47:48   2014-09-30_23-57-36__solar__total__DIFF__2014-09 7.8960
     2016-11-11 14:47:48   2014-10-31_23-59-49__solar__total__DIFF__2014-10 364.6693
     2016-11-11 14:47:48   2014-11-30_23-59-38__solar__total__DIFF__2014-11 258.6800
     2016-11-11 14:47:48   2014-12-31_23-56-38__solar__total__DIFF__2014-12 127.5627
     2016-11-11 14:47:48   2015-01-31_23-59-33__solar__total__DIFF__2015-01 140.7707
     2016-11-11 14:47:48   2015-02-28_23-56-35__solar__total__DIFF__2015-02 284.0000
     2016-11-11 14:47:48   2015-03-31_23-58-47__solar__total__DIFF__2015-03 502.4987
     2016-11-11 14:47:48   2015-04-30_23-59-05__solar__total__DIFF__2015-04 641.2133
     2016-11-11 14:47:48   2015-05-29_21-50-46__solar__total__DIFF__2015-05 477.6187
     2016-11-11 14:47:48   2015-06-30_23-58-32__solar__total__DIFF__2015-06 609.3093
     2016-11-11 14:47:48   2015-07-31_23-57-02__solar__total__DIFF__2015-07 720.6053
     2016-11-11 14:47:48   2015-08-31_23-59-23__solar__total__DIFF__2015-08 493.0880
     2016-11-11 14:47:48   2015-09-03_10-25-12__solar__total__DIFF__2015-09 22.2400
     2016-11-11 14:47:48   2015-11-27_19-24-23__solar__total__DIFF__2015-10 636.9493
     2016-11-11 14:47:48   2015-12-16_21-14-49__solar__total__DIFF__2015-12 169.1893
     2016-11-11 14:47:48   2016-01-31_23-55-29__solar__total__DIFF__2016-01 119.7307
     2016-11-11 14:47:48   2016-02-21_19-01-07__solar__total__DIFF__2016-02 176.5173
     2016-11-11 14:47:48   2016-03-31_23-58-15__solar__total__DIFF__2016-03 405.3307
     2016-11-11 14:47:48   2016-04-11_08-55-34__solar__total__DIFF__2016-04 129.1147
     2016-11-11 14:47:48   2016-05-01__solar__total__DIFF__2016-05 -
     2016-11-11 14:47:48   2016-06-01__solar__total__DIFF__2016-06 -
     2016-11-11 14:47:48   2016-07-31_23-58-47__solar__total__DIFF__2016-07 173.0987
     2016-11-11 14:47:48   2016-08-31_23-56-41__solar__total__DIFF__2016-08 655.4907
     2016-11-11 14:47:48   2016-09-30_17-18-19__solar__total__DIFF__2016-09 583.5653
     2016-11-11 14:47:48   2016-10-01__solar__total__DIFF__2016-10 -
     2016-11-11 14:47:48   2016-11-01__solar__total__DIFF__2016-11 -
     2016-11-11 15:17:58   state           connected
   Dbloghash:
     CONFIGURATION /opt/fhem/db-mysql.conf
     DBMODEL    MYSQL
     DEF        /opt/fhem/db-mysql.conf .*:.*
     NAME       myDbLogSQL
     NR         70
     NTFY_ORDER 50-myDbLogSQL
     PID        11765
     REGEXP     .*:.*
     STATE      connected
     TYPE       DbLog
     dbconn     mysql:database=fhem;host=1.2.3.1;port=3306
     dbuser     fhemuser
     Helper:
       Dblog:
         State:
           Mydblogsql:
             TIME       1478873901.14212
             VALUE      connected
     Readings:
       2016-01-05 11:46:03   lastReduceLogResult Rows processed: 245075, deleted: 234890, updated: 2340, time: 507.40sec
       2016-11-11 15:18:21   state           connected
Attributes:
   DbLogExclude .*
   aggregation month
   allowDeletion 0
   comment    2016-01-17 00:00:00
   device     solar
   reading    total
   timeout    600
   timestamp_begin 2000-01-17 00:00:00
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

ZitatAber in der Theorie würde es ja beim Umsprung auf 0 einen negativen DIFF-Wert geben. Den würde ich ignorieren und am nächsten Tag wieder neu die Differenz bilden...

Und was machen wir wenn der Nutzer eine Aggregation Woche oder Monat einstellt und der Zähler in der Mitte der Periode auf Null geht. Fängt dann die Woche oder der Monat mit 0 an ?
So einfach liegen die Dinge leider nicht ....
Möglciherweise fängt ddie neue Zählung auch garnicht bei 0 an usw.

Aber mir fehlt noch das verbose 4 log. Es kommt vor allem auf die SQL-Statemants an ob das Modul richtig selektiert. Wenn das da ist kann ich mir das mal anschauen. Aber dauert etwas weil ich momentan sehr eingespannt bin.

Gruß
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
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

JoeALLb

Zitat von: DS_Starter am 11 November 2016, 16:26:11
Und was machen wir wenn der Nutzer eine Aggregation Woche oder Monat einstellt und der Zähler in der Mitte der Periode auf Null geht. Fängt dann die Woche oder der Monat mit 0 an ?

das userReading evaluiert das ja bei jedem event und zählt einfach nur die differenz dazu.
Wir müssten demnach vermutlich nach einem min suchen und schauenn ob das Min eines Monats kleiner ist als der Monatsanfang.
Die Rechnung würde dann lauten:
"letzter Eintrag vor MonatsMin"-MonatsAnfagg + MonatsEnde-MonatsMin, oder so ähnlich...

Log 4 kommt erst nächste Woche, bin unterwegs und am Handy gehts so schlecht...

Danke fürs ansehen, schönes Wochenende...
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

#201
Hi Joe,

Zitat"letzter Eintrag vor MonatsMin"-MonatsAnfagg + MonatsEnde-MonatsMin , oder so ähnlich...

Ja genau ;)

Nehmen wir es mal ein bisschen auseinander. Nehmen wir an , es soll ein halbes Jahr in Monatsaggregationen mit diffValue ausgewertet werden. Nun werden zunächst innerhalb der vom Nutzer angegebenen Zeitgrenzen (time) die Selects in kalendarischen! Monatsscheiben (Perioden) aufgebaut, in diesem Fall 6 Scheiben der allgemeinen Art:

Select ...... where time >= Periode-begin und time < Periode-ende

und zur Abarbeitung / Auswertung an den Hintergrundprozess übergeben. Das ist wichtig damit alle Aktionen des Moduls nicht blockierend ausgeführt werden!

Nun findet in einer Periode zu einem unbekannten Zeitpunkt eine Nullung statt. Prinzipiell leicht festzustellen dass es passiert ist, nur ist völig unklar WANN es innerhalb der Periode aufgetreten ist. Um das festzustelllen, müßte nun ein neuer Evaluationsprozess initiiert werden, der über entsprechend kleinteilige Selects die betreffende Periode wiederholt untersucht und im Ergebnis eine möglichst exakte Näherung des genauen Zeitpunkts der Nullung liefert.
Wie kleinteilig die Selects sein müssen bzw. wie genau die Iteration stattfinden soll, wäre auch zu betrachten. Es ist sicherlich nachzuvollziehen, dass je ungenauer dieser Null-Zeitpunkt ermittelt wird, je größer die Abweichung des diffValue-Ergebnisses von dem tatsächlichen Differenzwertwert der entsprechenden Periode ausfallen wird.
Ggf. wäre ein ganzer Monat in Minutenscheiben! zu untersuchen. Das Verfahren kann sicherlich durch Iterationsmechanismen optimiert werden, führt aber dennoch zu einer signifikanten Komplexitätserhöhung des Gesamtprozesses.

Wäre der Nullpunkt möglichst exakt ermitttelt (time-null), wäre im nächsten Step dann die betroffene Monatsperiode in zwei kleinere Perioden zu unterteilen:

Select ...... where time >= Periode-begin und time < time-null
Select ...... where time >= time-null und time < Periode-ende

und zu summieren.  EDIT: Ggf. finden ja in einer Periode mehrere Nullungen (z.B. durch Stromausfall) statt. Dann wäre der Prozess noch weiter zu unterteilen.

Wenn dieser obige Prozess in der Gesamtheit abgeschlossen ist, könnten die restlichen Monatsscheiben abgearbeitet werden und die Ergebnisse zusammengefasst an den FHEM-Hauptprozess zurückgegeben werden um die Readings zu generieren. Auch das folgt aus den non-blocking Ansatz.

Die Vorgehensweise Datenbankinhalte auszuwerten unterscheidet sich also signifikant von einer einfachen Differenzberechnung zwischen Readingwerten beim Auftreten eines Events.

Sollte sich jemand in der Lage sehen, so etwas in den Ablauf hineinzuprogrammieren kann er mir gern einen Patch liefern.


Was man allerdings tun kann, und ich selbst mache es so, ist bei Zählerwerten immer die Differenzwerte in der DB speichern und dann mit der sumValue-Funktion des Moduls auszuwerten. Das ist eben bei Geräten sinnvoll bei denen die Gefahr besteht dass sie auf 0 zureckgesetzt werden.
In meinem Fall des SMA Energy Meters liefert das SMAEM-Modul bereits Differenzwerte bei den Messungen. Der SMA Meter wird bei Stromausfall auf 0 zurückgesetzt.

Wenn das in deinem Fall nicht nativ vom Zählermodul geliefert wird, kann wie von dir geschrieben ein userreading die Differenzen berechnen und diese Differenzen in der DB gespeichert und später ausgewertet werden.
Sollte das nicht möglich (oder gewünscht sein) könnte man die erste Auswertung an diesem Nullpunkt enden lassen und mit einem weiteren DbRep-Device die Auswertung ab diesem Nullpunkt fortführen.
Das entspräche quasi dem Begin einer neuen Abrechnungsepoche.

Ich warte dann mal auf dein verbose 4 log und schaue mir die Sache dann nächste Woche mal genauer an.

EDIT: Was auch wichtig ist zu wissen / zu beachten ist, dass diffValue IMMER mindestens ZWEI Werte innerhalb einer Aggreagtionsperiode zwingend benötigt um daraus eine Differenz zu berechnen !  D.h. wenn innerhalb der entspr. Periode nur EIN Wert enthalten ist, kann keine Differenz berechnet werden. Das werde ich demnächst in der Commandref bzw. im Wiki auch nochmal einprägsamer hinterlegen, damit man diesen Zusammenhang berücksichtigt.

Schönes WE und Grüße
Heiko



ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
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

JoeALLb

Ich glaube, du siehst das zu kompliziert!
Der Zeitpunkt de rnullung lässt sich leicht herausfinden!

Select timestamp, min(value) from history where device and timestamp between xx and yy.


Der unmittelbare Eintrag davor ist
select timestamp,value from history where device and timestamp < $timestampMIN order by timestamp desc limit 1


Der unmittelbare Eintrag danach ist
select timestamp,value from history where device and timestamp > $timestampMIN order by timestamp limit 1


Dann habe ich schon alles zusammen, um zu rechnen.


Eine andere, vielleicht noch einfachere Methode wäre schlichtweg:
Bilde ein Array mit allen Diffs des Zeitraums(also von Eintrag zu eintrag) , und zähle nur die positiven zusammen!
Das gibge sogar über eine temporäre tabelle...
Der Code könnte so lauten:
create temporary table mytable as
SELECT 
    timestamp, DEVICE, reading,
      value,
       if(value-@VDay < 0, 0 , value-@VDay) as diff,
    @VDay:= value as valueVortag
FROM history where device='powersolar' and reading='total' order by timestamp;

select sum(diff) from mytable where diff>0;

Ich kenn mich in SQL aus, leider nicht so in perl, weswegen ich hier nicht sonderlich helfen kann...

FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

ZitatIch glaube, du siehst das zu kompliziert!

Ja, kann natürlich sein.

Dein Ansatz gefällt mir auf den ersten Blick ohne es genauer angeschaut zu haben was sich aus dem non-blocking Ansatz ergibt.

Aber dennoch ... nehme deine Verfahrens-Idee mal auf und wir schauen ob es zum Ziel führt.  :)

Danke und Gruß
Heiko

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
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

DS_Starter

Also der Ansatz mit einem Diff-Array scheint mir vielversprechend.
Bevor ich weiter einsteige, habe ich ein paar Versuche im SQL-Editor unternommen.
Allerdings kommt mit dem SQL

SELECT
    timestamp, DEVICE, reading,
      value,
       if(value-@VDay < 0, '0' , value-@VDay) as diff,
    @VDay:= value as valueVortag
FROM history where device='MySTP_5000' and reading='etotal'
ORDER BY `history`.`timestamp`  DESC


immer "Null" heraus. Wobei ich ebenfalls der Meinung bin, dass das SQL so wie von dir vorgeschlagen auch funktionieren sollte. Irgenwo scheint aber noch ein Fehler zu sein. Die Ergebnis-Tabelle habe ich als Screenshot angehängt.
Hab momentan keine Zeit weiter zu forschen ... vllt. fällt dir addhoc noch etwas dazu ein.


ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
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

JoeALLb

Du hast die Sortierung durch das DESC umgekehrt,
darum trifft value-@VDay < 0 nie zu (außer in meinem sonderfall).
Ändere es daher in value-@VDay > 0 und es sollte gehen:

(Im Übrigen habe ich einen Sensor der nach jedem Stromausfall erneut bei 0 beginnt ;-) )

SELECT
    timestamp, DEVICE, reading,
      value,
       if(value-@VDay > 0, '0' , value-@VDay) as diff,
    @VDay:= value as valueVortag
FROM history where device='MySTP_5000' and reading='etotal'
ORDER BY `history`.`timestamp`  DESC
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

Hmm, habs jetzt nochmal mit ">" sowie ohne DESC getestet. Hat in beiden fällen noch nicht funktioniert.
Screenshot wieder anbei.
Es ist doch so dass wenn value-@VDay < 0 zutrifft diff mit 0 bzw. mit der Differenz aus value - @VDay (der Normalfall) gefüllt wird.
Und das sollte auch so papassen.
Kann mir das momentan noch nicht erklären ...
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
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

JoeALLb

Nö... achtung!
Entweder > UND desc, oder < ohne DESC.

mit DESC vergleichst den aktuellen Wert mit dem mit dem nächst jüngeren, ohne DESC bvergleichst Du umgekehrt.


habs getestet, bei mir funktioniert es!
Anbei noch eine Variante die das DiffTotal gleich ohne temporäre Tabelle mit berechnet.

Anbei mit Screenshot

SELECT
    timestamp, DEVICE, reading,
      value,
       if(value-@VDay < 0, @diff:= 0 ,@diff:= value-@VDay) as diff,
       @diffTotal:= @diffTotal + @diff as diffTotal ,
    @VDay:= value as valueVortag
FROM history where device='powersolar' and reading='total'
ORDER BY `history`.`timestamp`  limit 100;
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

ZitatNö... achtung! Entweder > UND desc, oder < ohne DESC.

Ja das ist klar. Wollte nur sagen, habe es mit beiden Varianten bei mir getestet.

Du siehst ja auch in meinem letzten Screenshot dass auch die Variante "<" ohne DESC ebenfalls nicht das erwartete Ergebnis gebracht hat.
Nun habe ich auch noch die letzte Variante exakt genauso wie von dir geschrieben (nur andere device, readings) ausgetestet.
-> Screenshot

-> Null.  Also ich stehe da momentan vor einem Rätsel.



ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
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

JoeALLb

Hm... versuch mal zuvor diese Zeile, um die variablen zu definieren...

set @VDay=0,  @diff=0, @diffTotal=0;


Habs eben auf der Kommandozeile versucht, da hat es nur mit diesem Set zuvor funktioniert.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270