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

Hi Markus,

ZitatEvtl. wäre diese Abfrage das was Du für ein ganzes Jahr als Tagesabfrage suchst ?

Jo klar.  Mit entsprechenden Aufwand lässt sich vieles machen und auseinandersteuern :) 

Danke für die Hinweise. Vielleicht hast du ja mal Lust von dem DbRep-Modul ausgehend eine Testversion mit deinen Selectvorschlägen zu bauen ?
MySQL nutze ich auch.
Aber es ist eben unabdingbar dass auch SQLite und eigentlich auch PostgreSQL mit dem Modul klarkommen (PostgreSQL hat aber noch keiner gemeldet).

Man muß eben immer auch Nebenbedingungen berücksichtigen. Z.B. gebe ich bei maxValue den Zeitstempel des als Maxwert selektierten Datensatzes im Reading aus. Das sind so kleine Goodies.

Ich verwende noch Zeit für den SMAInverter und dann ist erstmal wieder SSCAM dran. Lange vernachlässigt ...

Also schauen wir mal.

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

DS_Starter

Morgen Markus,

auch wenn größere Änderungen bei DbRep momentan nicht auf meiner Agenda stehen war ich doch neugierig  ;) und habe mal Für SQLite die Abfrage gestartet:

SELECT DAY(TIMESTAMP) , SUM(VALUE) FROM history where DEVICE LIKE 'SMA_Energymeter' AND READING LIKE 'Einspeisung_WirkP_Zaehler_Diff' AND TIMESTAMP >= '2016-01-01' AND TIMESTAMP < '2016-12-31' GROUP BY DAY(TIMESTAMP)

SQLite kann damit nicht umgehen:

no such function: DAY: SELECT DAY(TIMESTAMP) , SUM(VALUE) FROM history where DEVICE LIKE 'SMA_Energymeter' AND READING LIKE 'Einspeisung_WirkP_Zaehler_Diff' AND TIMESTAMP >= '2016-01-01' AND TIMESTAMP < '2016-12-31' GROUP BY DAY(TIMESTAMP)

Wenn jemand andere Ergebnisse mit SQLite vorweisen kann ... gerne posten.

Schönen Tag zusammmen,
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

Xunil66

Morgen Heiko,

ich werde mal versuchen eine eigene Version des Moduls mit group_by selects zu bauen. Dazu noch eine kurze Frage zwecks Testsystem. Macht es mehr Sinn in FHEM alles 3 mal in die DBs ( mySQL, SQlite und Postgres) zu schicken oder per cron export import zu syncronisieren ?

Markus
(FHEM Installation auf Raspberry PI mit Jessie Lite )

DS_Starter

Hi Markus,

Ich würde mit Export Import arbeiten. DbLog ist nach wie vor blockierend und belastet dein FHEM wenn du parallel in die verschiedenen DBs schreibst.
Freue mich dass du unterstützt. :)  Das hilft mir bei meinem knappen Zeitbudget.
Ich helfe dir gerne bei Fragen, auch mit PM wenn es nicht von allgemeinem Interesse ist.

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

DS_Starter

Hallo zusammen,

im Startbeitrag habe ich die aktualisierte V4.7.7 eingefügt.
Funktional ist lediglich hinzugekommen dass die benötigten Module hinsichtlich ihres Installationsstatus überprüft werden und die DbRep Entwicklungsversion als Internal dargestellt wird.

Ansonsten ist nur etwas Code aufgeräumt und reviewed.

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

Hi,
diese Zahlen sind meines Erachtend völlig legitim, sie lösen auch keine Warnung aus, aber das Ergebnis stimmt nicht.

INSERT IGNORE  INTO history VALUES ('2016-10-05 00:00:00','Test','typ','event','test','49047','manuell');
INSERT IGNORE  INTO history VALUES ('2016-10-07 00:00:00','Test','typ','event','test','49147','manuell');
INSERT IGNORE  INTO history VALUES ('2016-11-01 00:00:00','Test','typ','event','test','50000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-11-02 00:00:00','Test','typ','event','test','51000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-12-01 00:00:00','Test','typ','event','test','60000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-12-02 00:00:00','Test','typ','event','test','60000','manuell');


Bei diesem Zähler habe ich pro Monat 2 Werte. Lt. LOG habe ich 60000-49047, also 10953 kw Strom verbraucht.
Die Readings sehen so aus:
2016-09-01__stromverbrauch__2016-09 -
2016-10-07_00-00-00__stromverbrauch__2016-10 100.0000
2016-11-02_00-00-00__stromverbrauch__2016-11 1000.0000
2016-12-02_00-00-00__stromverbrauch__2016-12 -


Zählen also nur 1100 kw Strom.

Folgende Fehler erkenne ich daraus (denke ich):
1. Das Datum ist zu strickt eingegrenzt
2016-11-01 00:00:00 = 2016-10-31 23:59:59 [59..], sollte(muss) also für den Oktober noch mitgezählt werden! (Die FHEM-Plots rechnen diesen Datumswert ebenfalls noch mit! Siehe Screenshot))
Die letzte Sekunde geht also nahtlos in die erste und endet dort, wo der nächste tag beginnt. und das ust eben der nächste Tag um 00:00:00
2. Zwischen November und Dezember habe ich 10000kw Strom verbraucht. Die Korrektur von Fehler 1 könnte schon die Korrektur für diesen Fehler sein.

Meine Device-Config ist:
defmod calc_Test DbRep myDbLogSQL
attr calc_Test DbLogExclude .*
attr calc_Test aggregation month
attr calc_Test allowDeletion 0
attr calc_Test device test
attr calc_Test diffAccept 50000
attr calc_Test reading test
attr calc_Test readingNameMap stromverbrauch
attr calc_Test timeout 15200
attr calc_Test timestamp_begin 2016-09-01 00:00:00


Edit1:
Nachtrag: der SQL für den Oktober müsste also
select * from history where device="test" and timestamp between '2016-10-01 00:00:00' and '2016-11-01 00:00:00';
lauten
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

#246
Hi Joe,

die Abgrenzung mit between:

select * from history where device="test" and timestamp between '2016-10-01 00:00:00' and '2016-11-01 00:00:00';

hatte ich Anfangs so. Hat sich nicht bewährt weil dieser Wert dann im nächsten Abrechnungszeitraum ebenfalls, also doppelt gezogen wurde (wenn auf Zeitgrenze 00:00:00 angegeben).
Deswegen erfolgte die Änderung so wie es jetzt ist.

Da es sich um manuelle Eingaben handelt würde ich die nicht unbedingt auf die Zeitgrenze 00:00:00 legen.

Abgesehen davon hat das Modul aufgrund deiner Angaben völlig recht. Warum ? Weil du angegeben hast dass du im November 51000 - 50000 kWh verbraucht hast = 1000, im Dezember hingegen 60000 - 60000 = 0  (bzw. "-") !

Was hier fehlt ist der Endstand im November, die fehlende Differenz von 9000 kWh zwischen dem angegebenen  Endwert von 51000 im Nov und dem Anfangswert von 60000 im Dez. Möglicherweise hast du die ja garnicht verbraucht sondern nur einen andren Zähler eingebaut  ;) (philosoph. Betrachtung am Rande).

Bei manuellen Einträgen bitte immer darauf achten dass diese Angaben im Sinne der Auswertung auch Sinn machen. Der Endwert einer Auswertungsperiode sollte auch immer der Anfangswert der nächsten Periode sein (bzw. mit einer hinreichend kleinen Differenz).
In deinem Bespiel hast du zw. Nov. und Dez. 9000 kWh "unterschlagen".

Bei automatischen Erfassungen alle x-Sekunden/Minuten stellt sich diese Frage nicht.

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

Zitat von: DS_Starter am 09 Dezember 2016, 12:44:06
hatte ich Anfangs so. Hat sich nicht bewährt weil dieser Wert dann im nächsten Abrechnungszeitraum ebenfalls, also doppelt gezogen wurde (wenn auf Zeitgrenze 00:00:00 angegeben).

[code]INSERT IGNORE  INTO history VALUES ('2016-10-07 00:00:00','Test','typ','event','test','49000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-11-01 00:00:00','Test','typ','event','test','50000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-12-01 00:00:00','Test','typ','event','test','51000','manuell');
Was kann da doppelt gezählt werden?

In diesem Beispielszeitraum wurden 2000 verbraucht. Egal wie du es drehst, das Datum mit 00:00:00 wird hier niemals doppelt gezählt, daher ist dies sicher die richtige variante!
Es wäre also eklatant falsch, hier die 00:00:00 nicht mitzurechnen! Das würde maximal einen Fehler an anderer Stelle bder Berechnung beschönigen, aber richtig wird es dadurch nicht!




Zitat von: DS_Starter am 09 Dezember 2016, 12:44:06
Abgesehen davon hat das Modul aufgrund deiner Angaben völlig recht. Warum ? Weil du angegeben hast dass du im November 51000 - 50000 kWh verbraucht hast = 1000, im Dezember hingegen 60000 - 60000 = 0  (bzw. "-") !
Nein, hat es eben nicht! Das Modul verfälscht die Werte massiv!
Ich habe ihm nicht gesagt, dass er Werte die am Monatsübergang entstanden sind einfach unberücksichtigt lassen soll...
Es ist eindeutig, dass ich in dem Zeitraum mehr Strom verbraucht habe, als dein Modul mir anzeigt. Auch die Jahressumme stimmt somit natürlich nicht.
Nur weil das Modul den 1.1. 00:00:00 nicht korrekt betrachtet, ignoriert es einfach völlig korrekte Werte.

Zitat von: DS_Starter am 09 Dezember 2016, 12:44:06
Da es sich um manuelle Eingaben handelt würde ich die nicht unbedingt auf die Zeitgrenze 00:00:00 legen.

Nein, es sind bewußt abgefragte Werte (mit AT).
Wenn ich das korrigieren wollte müsste ich meine Datensätze verdoppeln und 2 Abfragen machen,
eine um 31.10. 23:59:59 und eine weitere um 1.11. 00:00:01. und das nur, weil das Modul mit dem korrekten Eintrag um 00:00:00 nicht zurecht kommt?
und seinen VWert dann völlig ignoriert?
Wie gesagt, andere FHEM-Module handhaben das korrekt! Sieh dir die Plots an, dort sieht man auch die Werte, die aus der Datenbank abgerufen wurden..  (Anbei ein Screenshot)
Ich finde es einfach zusätzlich verwirrend, wenn dein Modul andere

Zitat von: DS_Starter am 09 Dezember 2016, 12:44:06
Was hier fehlt ist der Endstand im November, die fehlende Differenz von 9000 kWh zwischen dem angegebenen  Endwert von 51000 im Nov und dem Anfangswert von 60000 im Dez. Möglicherweise hast du die ja garnicht verbraucht sondern nur einen andren Zähler eingebaut  ;) (philosoph. Betrachtung am Rande).

Bei automatischen Erfassungen alle x-Sekunden/Minuten stellt sich diese Frage nicht.
Selbst wenn das Zeitfenster kleiner ist, ignorierst du immer einen Wert um  00:00:00....
selbst für wenige Minuten bedeutet dies dennoch immer eine Verfälschung der Werte.
Dies trifft auf alle Szenarien zu  und ist somit imer ein Feher! Sorry

Genau genommen ignoriet das Modul sämtliche Werte zwischen dem letzten der Vorperiode und dem ersten Messwert der Nachfolgeperiode. Egal wie viel Zeit da vergeht (bei meinem Stromzäghler manchmal 4 Stunden) wird sämtlicher Verbtauch hier einfach ignoriert. Wenn die die Monate also zusammenzähle, fehlen diese Werte komplett.  Bei jedem Periodenübergang fehlen demnach
Werte, um so mehr Periodenübergänge es gibt, umso größer wird der Fehler.

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 Joe,

zunächst sollten wir einmal davon ausgehen dass DbRep kein Abrechnungstool für Energieunternehmen ist sondern in der Datenbank vorhandene Werte auswertet.

ZitatIn diesem Beispielszeitraum wurden 2000 verbraucht. Egal wie du es drehst, das Datum mit 00:00:00 wird hier niemals doppelt gezählt, daher ist dies sicher die richtige variante!

Ich sehe es etwas anders Joe. Bitte betrachte immer die abgeschlossenen Auswertungszeiträume / Aggregationen. In deinem Beispiel sagst du es wurden 2000 verbraucht. Das ist zwar richtig, allerdings nicht wenn man den Oktober bzw. November für sich als Betrachtungszeitraum abgrenzt.
Die Aussage dass mit der Zeitangabe 00:00:00 nichts doppelt gezählt wird, wurde schon hier diskutiert: https://forum.fhem.de/index.php/topic,53584.msg496812.html#msg496812 und deswegen auch geändert.

ZitatEs ist eindeutig, dass ich in dem Zeitraum mehr Strom verbraucht habe, als dein Modul mir anzeigt. Auch die Jahressumme stimmt somit natürlich nicht.

So ?  Hast du mal mit der Begin = Jahresanfang und Ende = Jahresende  und Aggregation = no gerechnet ?
Also ich gehe davon aus dass es stimmen wird.

Deine weiteren Anmerkungen möchte ich momentan nicht kommentieren.
Es können zwar immer Fehler auftreten, davor ist niemand gefeit, aber mir gefällt dieser Ton hier momentan überhaupt nicht.  :(

ZitatGenau genommen ignoriet das Modul sämtliche Werte zwischen dem letzten der Vorperiode und dem ersten Messwert der Nachfolgeperiode.

Wie gesagt es ist kein Abrechnungstool für Energieunternahmen sondern ein Hilfsmittel um seine DB-Inhalte nach bestimmten Kriterien (die auch bestimmten Rahmenbedingungen unterliegen)  auszuwerten.

Wenn es für dich so nicht passt dann ändere das Modul doch und wir schauen ob es dann besser klappt.
Wie gesagt wir hatten schon ein paar Betrachtungen (siehe Link) durch.

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

Zitat von: DS_Starter am 09 Dezember 2016, 14:56:45
Die Aussage dass mit der Zeitangabe 00:00:00 nichts doppelt gezählt wird, wurde schon hier diskutiert: https://forum.fhem.de/index.php/topic,53584.msg496812.html#msg496812 und deswegen auch geändert.

Da fehlt aber ein Beispiel von Bobby! Die Werte können sich nicht doppelt auswirken (Bei DIFF... bei anderen Zählmethoden schon, aber da ist der Fall ja soewieso ganz anders gelagert!
DIFF stimmt immer nur mit Berücksichtigung dieser Werte)! Kann es sein, dass Bobby's Meldung nicht bezüglich DIFFs war? ( Ich hab kein Beispiel von ihm dazu gefunden)

Ich denke, für die Kombination DIFF und AGGREGATTIOn wurde dadurch ein der Fehler erst eingeschleust.

Zitat von: DS_Starter am 09 Dezember 2016, 14:56:45
So ?  Hast du mal mit der Begin = Jahresanfang und Ende = Jahresende  und Aggregation = no gerechnet ?
Also ich gehe davon aus dass es stimmen wird.
Ja klar. Dies zeigt aber eindeutig, dass die Aggregation( in Kombination mit DIFF) falsch ist (wenn dohne Aggregation korrekte Werte rauskommen, mit jedoch nicht)!

Zitat von: DS_Starter am 09 Dezember 2016, 14:56:45
Es können zwar immer Fehler auftreten, davor ist niemand gefeit, aber mir gefällt dieser Ton hier momentan überhaupt nicht.  :(
Wie soll ich mich denn ausdrücken? Du kannst nicht sagen, dass ich mich nicht bemüht habe, und keine Zeit in Beispiele und Screenshots gesteckt habe.

Zitat von: DS_Starter am 09 Dezember 2016, 14:56:45
Wie gesagt es ist kein Abrechnungstool für Energieunternahmen sondern ein Hilfsmittel um seine DB-Inhalte nach bestimmten Kriterien (die auch bestimmten Rahmenbedingungen unterliegen)  auszuwerten.

Verlangt auch niemand. Und dennoch geht es falsch und anders wie andere FHEM-Module mit den selben Daten und den selben Rahmenbedingungen
(gib mir einen Monatsplot <=> gib mir eine Monatsaggregation)
um.
Bei Aggregation und DIFF liefert es immer falsche Werte. Vielleicht sollte man diese Kombination dann einfach sperren(wobei dies die einzige ist, die mich aktuell interessiert).
[/quote]
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

#250
ZitatDu kannst nicht sagen, dass ich mich nicht bemüht habe, und keine Zeit in Beispiele und Screenshots gesteckt habe.

Natürlich nicht. Wir geben uns schließlich alle gemeinsam Mühe, wir haben schließlich auch schon einges mit viel Schweiß  zusammen angepasst (DIFF) oder ?
Aber ich denke du weißt was ich damit meine.

ZitatJa klar. Dies zeigt aber eindeutig, dass die Aggregation( in Kombination mit DIFF) falsch ist (wenn dohne Aggregation korrekte Werte rauskommen, mit jedoch nicht)!

Würde ich jetzt so global nicht unterschreiben. Ich werte sehr häufig mit DIFF und Tagesaggregation aus. Das klappt , aber ich habe auch jede Minute Messwerte

ZitatBei Aggregation und DIFF liefert es immer falsche Werte. Vielleicht sollte man diese Kombination dann einfach sperren(wobei dies die einzige ist, die mich aktuell interessiert).

Bloss nicht. Genau die verwende ich auch zuhauf (Tagesaggregation und Monatsaggregation) . Aber wie gesagt mit häufigen in der DB vorhandenen Messwerten. und das klappt (zumindest in der Genauigkeit von ca. 0,0x die für mich ok sind).

Mir fällt addhoc kein allgemein gültiges Lösungsszenario ein.
Du kannst ja mal für dich nur für die Diff-Funktion das Select auf "between" ändern.

Aber das löst natürlich nicht das Problem dass wenn du z.B. nur am 26.11. und am 10.12. einen Messwert hast genau am 01.12. keine Messgröße hast die man auswerten könnte. Wir hatten schon mal mit einer Auffüllfunktion gespielt die die nicht vorhandenen Werte nach einem Durchschnittsverfahren in der DB ersetzen um so ansatzweise die Abschätzung durchführen zu können. Selbst mit "between" kommt man da nicht weiter.

Eigentlich braucht man immer zwei Messwerte in der DB um einen Nullpunkt herum. Zum Beispiel wenn man eine Stundenaggregation macht genauso.
Etwas  praktikableres fällt mir dazu momentan nicht ein.

Vielleicht kommt das Modul in genau diesen Grenzfällen an seine Einsatzgrenzen.
Möglicherweise fällt uns noch etwas ein ... aber mir grad nicht. Ob es praktikabel machbar wäre für jedes denkbar mögliche Aggregationsszenario einmal in die vergangene Periode zu gucken kann ich jetzt nicht beurteilen, halte es aber für ziemlich schwierig.

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

Hallo Heiko,

... danke fürs weiter mitüberlegen :D, ich denke(hoffe), wir verstehen uns schon...

Zitat von: DS_Starter am 09 Dezember 2016, 15:51:51
Würde ich jetzt so global nicht unterschreiben. Ich werte sehr häufig mit DIFF und Tagesaggregation aus. Das klappt , aber ich habe auch jede Minute Messwerte
Die Fehlwerte sind bei minütlichen Einträgen halt sehr klein, aber auch da vorhanden ;-)

Zitat von: DS_Starter am 09 Dezember 2016, 15:51:51
Mir fällt addhoc kein allgemein gültiges Lösungsszenario ein.

Idee: Wir könnten zum Wechselzeitpunkt(Nullpunkt) ein weiteres Reading  mit Diff erzeugen, das den "unzuordenbaren" Betrag abspeichert.
Dann stimmt die Gesamtsumme, und jedem ist ersichlich, dass es da noch einen wert gibt, der keinem Monat eindeutig zugeordnet werden konnte.
Leuten, denen x% genauigkeit ausreichen, können diese ignorieren, und ich kann mir daraus etwas überlegen, wie ich den wert anteilig aufs alte und aufs neue Monat zurechne.
Ob wir das dann in eine spätere Version des Moduls einfliesen lassen, können wir ja dann später entscheiden...
Dies hätte auch gleich den Vorteil, dass man sieht, wieviele Werte ignoriert werden...


Zitat von: DS_Starter am 09 Dezember 2016, 15:51:51
Du kannst ja mal für dich nur für die Diff-Funktion das Select auf "between" ändern.

Ich kann nicht wirklich Perl... aber mal sehen;
Was war der Fehler von bobyg genau? Dann kann ich mitüberlegen, was die korrekte korrektur seines Fehlers wäre. Hier ist zu 100% das andere das korrekte!

Zitat von: DS_Starter am 09 Dezember 2016, 15:51:51
Eigentlich braucht man immer zwei Messwerte in der DB um einen Nullpunkt herum. Zum Beispiel wenn man eine Stundenaggregation macht genauso.
Nein, sorry, das stimmt nicht! Wenn man GENAU den Nullpunkt nimmt, gilt dieser immer auf beiden seiten! Um beim Beispiel zu bleiben ist dieser kurze Zeitpunkt nämlich beides... Oktober und november.
Da in diesem Augenblick aber kein Strom verbraucht werden kann, weil die Zeiteinheit de rkleinst anzunehmende Wert ist, macht dies auch nichts aus und verändert keinerlei werte.
(( Under der Kurve ist die Fläche =0, ! eine Sekunde später ist die Fläche wieder >0 im November, ene sekunde davor für den Oktober...

Zitat von: DS_Starter am 09 Dezember 2016, 15:51:51
Vielleicht kommt das Modul in genau diesen Grenzfällen an seine Einsatzgrenzen.

Mit meinem Vorschlag von oben nicht... dann wäre alles wieder ok, und wir müssten den Wert nicht über irgendwelche Formeln auf die einzelnen Monate verteilen.


Schöne Güße
Joe
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

Hi Joe,

ich war grad beim Sport und konnte dabei nochmal in Ruhe nachdenken.

Zitatich denke(hoffe), wir verstehen uns schon...

Na klar, wi rlassen uns doch nicht kleinkriegen  :)

Also ich denke DiffValue kann ohne negative Nebenwirken getrost mit between bzw. => und  <= Timestamp ausgeführt werden (between ist schneller glaub ich).
Problematisch ist es eigentlich nur bei SumValue weil dann die "Grenzwerte" auf beiden Seiten addiert werden und dann die Summe über den Gesamtzeitraum mit den Aggregationen nicht stimmt.

Vielleicht habe ich sogar auch einen Ansatz gefunden der so ähnlich wie dein Vorschlag funktionieren könnte.
Ich probiere mal was wenn ich dazu komme und melde mich wieder.

Erstmal einen schönen Abend !

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

Zitat von: DS_Starter am 09 Dezember 2016, 19:42:18
Erstmal einen schönen Abend !

Hallo Heiko,

danke, dir auch, bzw. Wochenende!

schöne Grüße!
Joe
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 Joe, @all,

im ersten Beitrag gibt es eine neu eVersion 4.8.1.

Hier habe ich die Funktion diffValue auf "between" umgestellt. Das bedeutet dass die Differenzen nun von <first Aggregation> 00:00:00 - <next Aggregation> 00:00:00 ausgeführt werden und Values berücksichtigen die genau auf dem "Grenzwert" in der DB abgespeichert sind.

Weiterhin habe ich eine Lösung implementiert die einen Differenzübertrag in eine neue Aggregationsperiode vornimmt.
Das bedeutet dass die Differenz zwischen dem letzten Wert der Voraggregationsperiode X und dem ersten Wert der darauf folgenden Periode X+1 in die Periode X+1 übernommen und dieser zugeschlagen wird.

Um bei Joes Beispiel zu bleiben:

INSERT IGNORE  INTO history VALUES ('2016-11-02 00:00:00','Test','typ','event','test','51000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-12-01 00:00:00','Test','typ','event','test','60000','manuell');
INSERT IGNORE  INTO history VALUES ('2016-12-02 00:00:00','Test','typ','event','test','60000','manuell');


Die Differenz zw. 51000 (2016-11-02 00:00:00) und 60000 (2016-12-01 00:00:00) wird erkannt und diese 9000 in die Monatsaggregation 12.2016 übertragen. Damit würde (sollte) sich für die Monatsaggregation 12.2016 eine Diff von 9000 ergeben.
Das Attribut diffAccept  fließt mit ein was bedeutet dass es in dem Beispiel auf einen Wert > 9000 gesetzt werden müßte um diese Differenz akzeptieren zu lassen.

Diese Verfahren stellt m.M. nach sicher dass mathematisch nichts "verloren" geht. Vom logischen Standpunkt ist es natürlich nicht unbedingt schlüssig da der Verbrauch ja eher zwischen dem 02.11. und 30.11 anfiel. Vielleicht kriege ich das noch besser geregelt, mal schauen.

Ich hatte noch keine Zeit diese Version in allen möglichen Varianten zu testen und möchte euch bitten es als Arbeitsstand anzusehen und eigene Tests damit zu machen und die Ergebnisse zu posten. Bei mir funktioniert es in den "Standardsituationen" tadellos.

@Joe schau mal ob es im Ergebnis schon den Erfordernissen nahekommt. 

Weiteres später ... Grüße und schönes WE,
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