verbrauch und gewinn dauerhaft speichern

hallo und guten tag !

ich habe einen sack voll daten. meine ganze zähler lese ich einmal die woche ab und schreibe die daten in eine excel tabelle. die sachen kommen hoffentlich bald mal automatisch ins ips.
dazu habe ich meine daten der heizung und wetterdaten im ips als variablen. diese sachen kann ich schick im wiips darstellen. aber ja eher nur als „momentaufnahme“.

wie kann ich es schaffen, all diese daten gemeinsam z.b. in einer datenabnk abzulegen? ich möchte z.b. auswertungen machen können, die den januar 2008 mit dem januar 2009 vergleichen können. und das in sachen pv und thermie und stromverbrauch und gasverbrauch. hat jemand sowas vielleicht schon realisiert?

happy day und dank, frank

Das speichern ist kein Problem.
Eine Datenbank Deiner Wahl nehmen, entweder für jeden Sensor eine Tabelle mit Datum und Wert oder alles in eine Tabelle (Datum, Sensor,Wert) schreiben.
Schwieriger ist das Auslesen der Daten bzw. genauer das Vergleichen der richtigen Daten. Bei grossen DB-System gibt es sogenannte OLAP-Funktionen wie Cube und Dimension, mit denen Du die Daten (relativ) einfach gruppieren kannst.
Eine einfachere Methode für das Problem „Januar mit Januar vergleichen“, die bei allen DBs funktioniert, wäre z.B. sich erst die Daten von Januar(1) zu selectieren, daraus einen Graphen machen und dann das Gleiche für Januar(2) und die Graphen übereinander legen. Mache Chart-Programme machen das in einem Rutsch, in dem man Ihnen gleich beide Datasets zur Verfügung stellt.

Es gibt noch weit mehr Ansätze für dieses Problem, aberr am Ende muss es immer ein Kompromiss zwischen Aufwand, Resourcenbelastung und Laufzeit werden.

HTH
Tommi

hallo tommi !

danke für deine antwort. ich bin eher ein „nicht“ programmierer. daher kann ich leider nicht sagen, dass das speichern kein problem ist :slight_smile: das würde ich mal als ersten schritt sehen. das auswerten dann eher als 2. oder 3. :wink:

hast du einen tipp, wie man das speichern am besten machen kann? ich kenne mysql von den web-sachen. aber alle daten vom server aus direkt auf eine mysql datenbank im internet abzulegen?

happy day und dank, frank

… hier eine private Seite (langsamer Uplink) mit einem Beispiel einer Verbrauchsdaten-Auswertung

MST

hallo michael. danke für den link :slight_smile:

das sieht super aus. vor allem das gegenüberstellen zum vorjahr. ich hab in meiner tabelle dann z.b. noch eine gegenüberstellung von pv-gewinn zum verbrauch. aber das ist ja das gleich vom prinzip.

hast du eine ahnung, wo dort die daten gespeichert werden und wie sie ausgewertet werden?

happy day, frank

Hallo,
dieses Thema interessiert mich auch. Ich habe eine mysql Datenbank, habe aber keine Ahnung wie ich meine Werte in die Datenbank bekomme. Kann mal jemand ein Beispiel zeigen wie das geht. Also ein tempwert in die Datenbank als Tabelle mit Datum und Wert.

Der Link von Steiner funzt bei mir nicht, weisse Seite.

cu uwe

Der IE hat Probleme mit der Seite. Im Firefox und Opera funktioniert sie.

… mit „Safari“ (schnell und einfach) geht es auch …

Ich würde immer eine lokale DB vorziehen. Die kann man auf seinem IPS-PC mitinstallieren oder auch auf einen anderen Rechner auslagern, ja:zur not auch auf dem Server beim Provider.

Anbei ein Beispiel, wie ich meine FHT-Daten in die DB schreibe (Hier mit Postgresql, aber mysql tut das auch).
Die Tabelle muss natürlich vorher angelegt sein:


sql !!!
create table FHT_Temperatur(sensor integer,zeit integer,Temperatur numeric(4,1),Position numeric(4,1));

Die dazu angelegten Varablen haben ein gemeinsames Schema: FHT_, wobei eine Nummer ist. Die Variablen für die Postion heissen dann FHT__Open.
Das Script wird als Update-Trigger an die Temperatur-Variablen gehangen (Immer das gleiche Script). Die FHT-Nummer des gerade empfangenen Datensatzes wird aus der IPSVariablen gewonnen. Die Update-Zeit wird ausgelesen und so gleich als Integer gespeichert. Man könnte jetzt hier auch gleich noch ein „richtiges“ Datum draus machen, aber so kann man besser vergleichen.Dann einfach DB-Öffnen, Schreiben, (Commit),Schliessen, fertig.
Das Commit ist bei manchen DBs je nach Einstellung notwendig, Postgresql macht per default ein AutoCommit.


<?
/*
*******************************
 IP-SYMCON Event Scripting
*******************************
File     : FHT_Temperatur_Update.ips.php
Trigger  : 
Interval : 
*/
$variable=$IPS_VARIABLE;
$sensor=substr($variable,4,1);
$value=GetValueFloat($variable);
$position=GetValueFloat("FHT_".$sensor."_Open");
$time=IPS_GetUpdateTime($variable);
$dbh=pg_connect("host=server dbname=ips user=ips password=xxxxx");
if (!$dbh) {
   echo "Connect error!";
   return;
}

$result = pg_query ($dbh, "INSERT INTO FHT_Temperatur(sensor,zeit,Temperatur,Position) values ($sensor,$time,$value,$position)");
if (!$result) {
   echo "Insert Error!";
}
pg_close($dbh);
?>

Hallo tommi und die anderen Poster,

ich muss auch mal meinen Senf hier nun dazugeben. Bevor man sich dazu entschliesst, was man am besten verwendet, sollte man sich doch erstmal Gedanken machen, welche Daten in welcher Folge und Menge gespeichert werden sollen. Hierbei treten doch schon massive Unterschiede auf. Tommi speichert FHT Daten, die maximal aller 12 bis 15 Minuten eintreffen. Hmpf99 will aber Daten speichern, die jede Minute, vielleicht sogar aller 15 Sekunden einen neuen Wert bringen. Und damit werden logischerweise unterschiedliche Datenmengen erreicht, wenn man sich den Speicherzeitraum betrachtet. Hier finde ich eine Hochrechnung erstmal wichtig, und ob man dann nicht fuer die Vorjahre und Archivjahre auf komprimierte Daten zurueckgreift. Was nuetzt einem ein Wert, der am 12.4.2006 um 08.04 und 15 Sekunden entstanden ist? Eigentlich gar nix. Kein Mensch wird sich vom Vorjahr noch die Einzelwerte ansehen wollen. Also muss man diese ganzen Werte entsprechend komprimieren.

Ich vertrete also die Meinung, man muss nicht unbedingt eine SQL Datenbank dafuer einsetzen, man kann auch klassische Datenbankstrukturen wie Textfiles oder Arrays verwenden. Diese sind hierfuer noch flexibler und auch sehr schnell.

Ich bin mal auf Eure Meinung gefragt, ich sitze naemlich auch gerade ueber diesem Thema, um fuer die Stromzaehler von 1-Wire.de ein kleines WIIPS Addon zu realisieren.

Ich muss Torro recht geben. Eine Datenbank ist nicht unbedingt die schnellste Art Daten zu speichern. Und gerade wenn es sehr viele Daten sind dauert es bist die gesuchten wiedergefunden wurden u.U. schon sehr lange. Ausserdem ist wichtig wie lange die daten gesammelt werden sollen. 5 Jahre alle 15 Sekunden sind wesendlich mehr Daten als alle 10 Minuten Daten der letzten 14 Tage - Klar.

Für hohes Datenaufkommen kann es nötig werden ein professionelles DBMS zu verwenden. Da gibts zwar auch kostenlose, aber die wollen mit einem gewissen Know-how administriert werden.

BTW:
Ich arbeite an einer rudimentären Datenbank-Anbindung „für Dummies“ für IPS. Damit wird es möglich sein auf einfachste Weise, mit nativen IPS-Funktionen, Daten zu loggen und auszuwerten. Für jemanden der sich ein bissel mit Datenbanken auskennt wird das nichts sein. Dafür ist es einfach zu banal. Ist, wie gesagt, „für Dummies“ gedacht. Soll am ende jeder mit klarkommen. Dauert aber, wie immer bei mir, noch ne Weile. :wink:

Gruß,

Toni

moin !

also mir geht es ja darum, eine ganze menge werte über ein paar jahre zu speichern um sie vergleichen zu können. ich hab gestern nachmittag mal mysql installiert und lege seit dem jede minute 2 werte ab. erstmal nur innentemperatur und aussentemperatur.
stand jetzt habe ich ca. 1620 einträge in der db. ich bin auch etwas unsicher, ob man das mit ca. 30 werten über ein paar jahre machen kann.

happy day ,frank

Nur mal als Beispiel. Ich verwalte auf Arbeit eine Datenbank in der pro Tag eine Datenmenge von ca 9000 (geschätzt) Datensätzen (Zeiterfassung) mit Informationen zum Erfassungsort und der Tätigkeit, Beginnzeit und Endzeit der Tätigkeit, Einsatz von Material etc.

Dort kommt im Jahr eine Menge von etwa 1GB zusammen. Die maximale Größer unserer alten Interbase-Datenbank (eine schon recht professionelle) liegt bei 2GB so dass ich jedes Jahr auslagern und reorganisieren muss. Die Geschwindigkeit geht zum Ende des Jahres dermaßen in die Knie, dass man, wenn 3 oder 4 User gleichzeitig arbeiten eine Abfrage bis zu 3 Minuten dauern kann. spätestens dann ist für mich wieder Zeit zum handeln :wink:

Eine Erfassung der Daten über mehrer Jahre ist in einer Datei überhaupt nicht möglich. Gottseidank auch nicht erforderlich :smiley:

Gruß,

Toni

dann muss ich meine daten einfrieren, bis es eine passende lösung gibt :slight_smile:
sonst gehen sie bis dahin alle verloren und ich kann nächstes jahr nicht mit diesem vergleichen :frowning:

Vielleicht den Intervall etwas herabsetzen und nur den Mittelwert von den letzten 10 Werten speichern oder sowas… Oder halt wie ich die Datenbank jedes Jahr backuppen und für jedes Jahr eine neue, leere Datenbank erstellen und von forne anfangen.

Man muss sich immer auch fragen ob man jeden einzelnen Wert in dieser Datenbank, nach 3 Jahren oder so, noch wissen muss oder obs eine Summe auch tut…

Toni

Hallo Frank und auch die anderen,
wenn Du die Daten reduzierst, wie angesprochen, reicht das dir doch bestimmt aus.
Temperaturen im 2 Minutenbereich ändern sich doch bestimmt nicht wesentlich, von wenigen Sonderfällen abgesehen.
Wenn Du dir aus den 2-minütlichen Werten einen stündlichen Durchschnitts- sowie Max- und Minwert bastelst,
hast Du schon statt 30 nur 3 Werte.

Die Berechnung in IPS, die stündliche Speicherung in der Datenbank.
Und auch nicht das rrd-Tool vergessen. Das kann doch auch vieles, Ich kenne mich damit aber nicht aus.
Ich glaube Torro ist hier der Spezialist.

hallo !

ich denke auch, dass eine reduzierung der daten die einfachste lösung ist. würde dann eine stündliche speicherung gehen? oder sind das noch immer zu viele daten?

ist es schwer, sowas in einem script zu machen?

happy day und dank ,frank

Hallo Frank,

genau das macht die RRD Datenbank. Sie speichert Einzelwerte fuer einen definierten Zeitraum, und im Archiv dann jeweils gemittelte Werte wieder fuer einen definierten Zeitraum. Bisher habe ich die Zeitraeume allerdings sowohl Zeitraum- wie auch anzahlbezogen fest definiert. Das wird in der Zukunft variabel gestaltet und auch aenderbar werden. Wenn Du dann soweit mit der Navi bist, koennen wir dann auch langsam zu den inhaltlichen Aspekten kommen. Unabhaengig davon wird es noch ein speziell fuer unseren 1-Wire S0 Zaehler passendes Addin fuer WIIPS geben.

Wie ich schon erwähnte, ist das Speichern in eine DB kein Problem. Das Auswerten schon eher.
Die bei uns anfallenden Datenmengen sind eigentlich für jede richtige DB (also nicht MS-ACCESS) kein Problem. Ich sammle jetzt schon seit ca. 2002 Wetterdaten von 8 Temperatursensoren, Regen, Wind, Helligkeit sowie seit fast 3 Jahren dank IPS auch zusätzlich 5xFHT und 2xHMS Werte. Die Datenbanken sind mit allen Zip und Zap auf der Platte ca. 1GB gross.

Für den Zugriff muss man sich schon einige Gedanken machen, wie die Daten später angesehen werden sollen. In grossen RDBMS verwendet man dazu Dimensionen, im kleinen lässt man einfach täglich einen Job laufen, der die benötigeten Aggregationen vornimmt und in sekundäre Tabellen schreibt. Auf die hat man dann sehr schnell Zugriff. Im Prinzip macht RRD auch nichts anderes mit dem Unterschied, wenn mal mal eine neue Metrik braucht, die Basisdaten aus der Vergangenheit weg sind.Außerdem ist man auf die geplanten Aggregationen festgelegt. Es ist dort nicht möglich, direkte (freie)Abfragen gegen den Datenbestand laufen zu lassen. Dazu gibt es SQL und das kann man in Bezug auf Zugriff(z.B. Index) oder Datenverteilung (Partitionierung) hochgradig optimieren. Das ist dann aber nicht gerade eine Tätigkeit für Do Abend nach dem Sport.

Ich arbeite gerne mit Oracle (mach ich auf Arbeit auch für mehrere DBs mit TByte-Tabellen), da gibt es sogar eine auf 4GB begrenzte kostenlose Variante mit vielen Spezialfunktionen, aber das ist nichts mehr für den typischen IPS-PC, so das man dort eher Postgresql oder MySql nimmt und muss halt die fehlenden Funktionen irgendwie nachbilden.
Mit Interbase(oder auch Firebird) habe ich schlechte Erfahrungen gemacht und kann ich nicht empfehlen, vom Supportstatus (Entweder Teuer bei Borland oder „Community only“) mal abgesehen.

Wenn man sich sicher ist, das einem die Möglichkeiten von RRD ausreichen und man nur die damit erstellten Grafiken braucht, dann braucht man auch keine DB mehr, da hat Torro recht. Ansonsten:Erstmal Sammeln, wegschmeissen kann man immer noch!

Es gibt (wie immer)viele Wege
Tommi

Hallo Tommi,

wir setzen bei uns MySQL und SAPDB ein, auch in diesem Bereich. Allerdings sehr viel auch mit Store Proceduren und Views, damit moeglichst viel bereits seitens der Datenbank abgebildet wird. Du kennst das ja auch alles.

Wenn man sich sicher ist, das einem die Möglichkeiten von RRD ausreichen und man nur die damit erstellten Grafiken braucht, dann braucht man auch keine DB mehr, da hat Torro recht. Ansonsten:Erstmal Sammeln, wegschmeissen kann man immer noch!

aber nicht in der jetzigen Variante von WIIPS, da muss ich noch was dafuer tun, damit die Datenhaltung besser wird. Aber das ist schon in Arbeit.