CCU-Historian: Ein Langzeitarchiv für die CCU

[Pert]

Hallo Mathias,
erst einmal großes Kompliment für die saubere Arbeit! Das Logging der Daten für Auswertungen war überfällig.

Sieht jemand eine Möglichkeit, das ganze direkt auf der CCU laufen zu lassen? Damit würde man einen ständig laufenden Server sparen. Auch der Betrieb auf einer Fritzbox wäre toll.

Grüße...

pert

[Mathias]

Hallo Holger!

Ich tue mir nur mit der Ausgabe der Sonnenscheindauer schwer. Hierzu gibt es ja einen Zähler (SUNSHINEDURATION ), der aber blöderweise nach 255 Minuten zurückgesetzt wird. Habe mal alles versuch, aber ich bekomme keine SQL zusammen, mit dem ich die Sonnenscheindauer pro Tag abfragen kann.
Hast du noch ne Idee?

Diese Berechnung in einem SQL-Ausdruck zu realisieren wird extrem aufwändig. Vom Zeitaufwand ist es bestimmt besser das in Deiner Web-Applikation mit ASP.NET zu implementieren. Wenn der CCU-Historian in einer der nächsten Versionen auch Systemvariablen archiviert, könnte das auch ein kleines Skript auf der CCU erledigen und das Ergebnis dann in eine Variable schreiben.

Hallo Pert!

Sieht jemand eine Möglichkeit, das ganze direkt auf der CCU laufen zu lassen? Damit würde man einen ständig laufenden Server sparen. Auch der Betrieb auf einer Fritzbox wäre toll.

Der CCU-Historian benötigt zur Ausführung eine Java Virtual Machine (JVM). Er läuft also auf allen Plattformen, für die es eine JVM gibt. Für Windows oder Linux auf einem x86-Prozessor gibt es die Standard-JVM von Sun/Oracle.

Für ein Embedded-Linux, wie es auf der CCU oder auf der Fritz-Box zum Einsatz kommt, muss eine Open-Source-JVM speziell für die Zielplattform übersetzt werden. Und da wird die Luft dünn. Die Open-Source-JVMs sind nicht immer auf dem aktuellen Stand oder standardkonform. Zusätzlich haben die Geräte nur sehr beschränkte Ressourcen. Eine JVM läuft auf diesen Geräten nur mit geringer Performance und würde einen großen Teil des Hauptspeichers in Beschlag nehmen. Zudem ist ein Festplattenlaufwerk fast schon zwingend erforderlich, da die Datenbank kontinuierlich wächst, wodurch der eingebaute Flash-Speicher nach kurzer Zeit voll geschrieben ist.

Der CCU-Historian benötigt keinen leistungsfähigen PC. Ein Nettop aus dem Niedrigpreissegment ist völlig ausreichend, und der benötigt nur paar Watt. Zudem kann der Mini-Server auch noch andere Aufgaben für das Hausnetzwerk übernehmen.

Gruß
Mathias

[Mathias]

Hallo,

ich möchte die Verfügbarkeit der Version 0.2.0 des CCU-Historians verkünden. Eine aktualisierte Beschreibung und den Download-Link findet Ihr im ersten Beitrag.

Änderungen

• Neue Tabelle DATA_POINTS mit Meta-Informationen zu den Datenpunkten
• Neue Web-Schnittstelle:
• Standardsatz an Web-Seiten zur Erkundung der Datenpunkte und Trend-Darstellung
• Export von Zeitreihen im CSV-Format
• Generierung von Trend-Diagrammen

Hervorzuheben ist die Web-Schnittstelle zur Erkundung der Datenpunkte und Trend-Darstellung. Dazu sind zwei Bilder angehängt. Für die Trend-Darstellung muss nichts konfiguriert werden. Die Trends stehen automatisch für alle Datenpunkte zur Verfügung. Auch für Daten, die mit der CCU-Historian Version 0.1.0 gesammelt wurden.

Übersichtsseite der Datenpunkte

ÜbersichtDatenpunkte.png (17.03 KiB) 10531 mal betrachtet

Details zu einem Datenpunkt

Gruß
Mathias

[holgerwolf]

Sehr schön Mathias.
Update installiert. Funktioniert. Und meine Webseiten auch noch

Vielen Dank und Gruß
Holger

[holgerwolf]

Hallo Mathias,

ich hab hier mal einen Feature Request:

- Ich weiß nicht, ob du einen Wettersensor OC3 hast. Dort wird für den Helligkeitswert auch mit einem Zähler gearbeitet, der blöderweise nur bis 255 Minuten läuft. Um die Sonnenscheindauer anzeigen zu können bräuchte man noch einen Zähler, der bei Überlauf des Ersten hochgezählt wird. So wäre eine SQL Abfrage der Sonnenscheindauer pro Tag (oder Woche...) dann einfach MAX (Zähler1 + Zähler2 *255) - MIN (Zähler1 + Zähler2 *255) gruppiert über die Dauer, möglich.
Das Gleiche könnte man auch bei der Gesamtregenmenge machen. Auch wenn es hier dauert bis der Zähler überläuft.

Falls du eine Kopie meiner Datenbank brauchst, melde dich. Hier hab ich seit 30. Januar alle Werte gespeichert.

Danke und Gruß
Holger

[Mathias]

- Ich weiß nicht, ob du einen Wettersensor OC3 hast. Dort wird für den Helligkeitswert auch mit einem Zähler gearbeitet, der blöderweise nur bis 255 Minuten läuft. Um die Sonnenscheindauer anzeigen zu können bräuchte man noch einen Zähler, der bei Überlauf des Ersten hochgezählt wird. So wäre eine SQL Abfrage der Sonnenscheindauer pro Tag (oder Woche...) dann einfach MAX (Zähler1 + Zähler2 *255) - MIN (Zähler1 + Zähler2 *255) gruppiert über die Dauer, möglich.
Das Gleiche könnte man auch bei der Gesamtregenmenge machen. Auch wenn es hier dauert bis der Zähler überläuft.

Hallo Holger,

ich habe mir mal Deine Daten angeschaut und etwas mit SQL herum gespielt.

Mit folgendem SQL-Ausdruck bekommst Du die Sonnenminuten pro Stunde (vom 27.2., 00:00 Uhr bis 1.3., 00:00 Uhr):

Code: Alles auswählen

SELECT DATEADD('HOUR', STUNDE, '2011-01-01') AS TS, SONNEN_MIN FROM 
(
    SELECT TBL1.STUNDE, (TBL2.MAX_VAL-TBL1.MAX_VAL<0)*256+TBL2.MAX_VAL-TBL1.MAX_VAL AS SONNEN_MIN
    FROM 
        (SELECT DATEDIFF('HOUR', '2011-01-01', TS) AS STUNDE, MAX(VALUE) AS MAX_VAL 
		    FROM V_XXXXXXXXXX_1_SUNSHINEDURATION WHERE TS>='2011-02-27' AND TS<'2011-03-01' GROUP BY STUNDE) AS TBL1,
        (SELECT DATEDIFF('HOUR', '2011-01-01', TS) AS STUNDE, MAX(VALUE) AS MAX_VAL 
		    FROM V_XXXXXXXXXX_1_SUNSHINEDURATION WHERE TS>='2011-02-27' AND TS<'2011-03-01' GROUP BY STUNDE) AS TBL2
    WHERE TBL1.STUNDE+1=TBL2.STUNDE ORDER BY STUNDE
)

Ergebnis:

min_pro_stunde.png (5.11 KiB) 10461 mal betrachtet

Um den Ausdruck oben kann noch ein SELECT gebaut werden, um die Sonnenstunden pro Tag zu erhalten:

Code: Alles auswählen

SELECT DAY(TS) AS TAG, SUM(SONNEN_MIN)/60 AS SONNEN_STUNDEN_PRO_TAG FROM
(
	SELECT DATEADD('HOUR', STUNDE, '2011-01-01') AS TS, SONNEN_MIN FROM 
	(
		SELECT TBL1.STUNDE, (TBL2.MAX_VAL-TBL1.MAX_VAL<0)*256+TBL2.MAX_VAL-TBL1.MAX_VAL AS SONNEN_MIN
		FROM 
			(SELECT DATEDIFF('HOUR', '2011-01-01', TS) AS STUNDE, MAX(VALUE) AS MAX_VAL 
				FROM V_XXXXXXXXXX_1_SUNSHINEDURATION WHERE TS>='2011-02-27' AND TS<'2011-03-01' GROUP BY STUNDE) AS TBL1,
			(SELECT DATEDIFF('HOUR', '2011-01-01', TS) AS STUNDE, MAX(VALUE) AS MAX_VAL 
				FROM V_XXXXXXXXXX_1_SUNSHINEDURATION WHERE TS>='2011-02-27' AND TS<'2011-03-01' GROUP BY STUNDE) AS TBL2
		WHERE TBL1.STUNDE+1=TBL2.STUNDE ORDER BY STUNDE
	)
)
GROUP BY TAG

Ergebnis:

stunden_pro_tag.png (2.01 KiB) 10461 mal betrachtet

Kompliziert, aber es geht. Vielleicht sollten solche Berechnungen auch in den CCU-Historian, damit die Abfragen einfacher gestaltet werden können.

Nachtrag:
So, noch einmal darüber geschlafen. Mit einer temporären Tabelle wird es etwas einfacher:

Code: Alles auswählen

CREATE LOCAL TEMPORARY TABLE TEMP_TABLE AS SELECT ROWNUM() AS ROW, * FROM (
    SELECT * FROM V_XXXXXXXXXX_1_SUNSHINEDURATION WHERE TS>='2011-02-27' AND TS<'2011-03-01' ORDER BY TS
);
SELECT DAY(TBL1.TS) AS TAG, SUM((TBL2.VALUE-TBL1.VALUE<0)*256+TBL2.VALUE-TBL1.VALUE)/60 AS SONNEN_STUNDEN
    FROM TEMP_TABLE AS TBL1, TEMP_TABLE AS TBL2 WHERE TBL1.ROW+1=TBL2.ROW GROUP BY TAG;
DROP TABLE TEMP_TABLE;

Wenn die Sonnenstunden pro Tag von einem Monat berechnet werden sollen, dauert es allerdings eine Minute bei mir. Die Datenbank muss dann 17000 Datensätze auswerten.

Gruß
Mathias

[holgerwolf]

Hallo Mathias,

die SQL Abfragen übersteigen dann doch meine Kenntnisse
Deine Beispiele habe ich aber jetzt verstanden und auch angepasst, dass jeweils die letzte Woche, Monat, Jahr abgefragt werden.
Aber es dauert tatsächlich alles zu lange. Zur Anzeige auf einer Webseite nicht brauchbar.
Kann Historian nicht bei diesen Zähler-Sensoren den Überlauf feststellen und in ein separates Feld abspeichern? Dann sind die Abfragen viel einfacher und müssten schneller gehen.

Hier die Abfrage des Regenzählers im letzten Monat. Dauert eine Sekunde:

SELECT PARSEDATETIME(Formatdatetime (TS, 'yyyy-MM-dd'),'yyyy-MM-dd'),MAX(VALUE)-MIN(Value) FROM V_XXXXXXXXXrain_Counter Where DATEDIFF('day', TS, current_timestamp) < 30 Group by PARSEDATETIME(Formatdatetime (TS, 'yyyy-MM-dd'),'yyyy-MM-dd') Order by PARSEDATETIME(Formatdatetime (TS, 'yyyy-MM-dd'),'yyyy-MM-dd')

Man müsste nur den Value jeweils mit dem neuen Überlaufzähler multiplizieren und fertig, oder?

Gruß
Holger

[Mathias]

Hallo Holger,

ich werde die Behandlung von überlaufenden Zählern in den CCU-Historian einbauen. Ein bisschen habe ich mich dagegen gewehrt, weil es dem generischen Ansatz vom CCU-Historian widerspricht. Es ist halt eine Sonderbehandlung für einzelne Datenpunkte. Aber in diesem Fall ist es absolut sinnvoll.

Ich hatte auch nachgedacht generell virtuelle Datenpunkte, deren Werte aus realen Datenpunkte berechnet werden, einzuführen (Thema: Softsensoren). Das wäre der generische Ansatz gewesen. Da muss ich mich aber selber zurückhalten: Die CCU steuert nur ein einfaches Haus und keine Produktionsanlage mit komplexen Prozessen. Da färbt mein Job etwas ab.

Ich habe die Doku von den Datenpunkten mal durchgeschaut (HM_Script_Teil_4_Datenpunkte_V1.0.pdf). Dort sind mir bisher nur Deine zwei Datenpunkte, die überlaufen können, aufgefallen:
RAIN_COUNTER, max. Wert 9666,265 mm
SUNSHINEDURATION, max. Wert 255 min.

Der CCU-Historian wird für alle Datenpunkte mit diesen Namen die Überläufe berücksichtigen und immer den korrigierten Wert in die Tabelle schreiben. Eine zusätzliche Spalte oder Tabelle ist in diesem Fall nicht nötig. Deine SQL-Anfrage muss daher auch nicht geändert werden. Ich denke, dass ich die Änderungen in der nächsten Woche einbauen kann.

Gruß
Mathias

[holgerwolf]

Prima, danke..

Für den Regenzähler hätte ich dann aber noch ne Idee:
Kann man den Zähler so einrichten, dass er immer hochzählt, auch wenn der Sensor mal neu angelernt werden muss, und wieder bei Null beginnt.
Das Problem habe ich zwar nicht, aber hier schrieben einige davon, dass es dazu kommen kann.

Gruß
Holger

[Mathias]

Ja, das kann ich so einrichten.

Weiß eigentlich jemand warum der RAIN_COUNTER so einen krummen Max-Wert hat (9666,265)?

Gruß
Mathias