Zum Ende der Metadaten springen
Zum Anfang der Metadaten

statistics.json

Die Bezeichnung databases.dat ist jetzt statistics.json, um die verschiedenen "Datenbanken" besser voneinander abzugrenzen, und um die konfigurierten Statistiken logisch von möglichen Datenzielen ("Sinks") zu unterscheiden.

{
   "Stat" : {
      "1" : {
         "activated" : 1,
         "Source" : "Loxone",
         "fetchStatus" : "error",
         "fetchStatusError" : "No values returned",
         "fetchStep" : "300",
         "statCfgFile" : "statcfg_0001.json",
         "statidOld" : "0001"
      }
   }
}

Alle Statistiken sind grundsätzlich im Hash Stat. Der Hash-Identifier jedes Elements ist die statid und enthält einen Hash mit den Daten. Die statid identifiziert nicht mehr den Dateinamen des Datenfiles, sondern dient als Referenz auf den Datensatz im statCfgFile.

ParameterBedeutung
activatedINT 0 oder 1
SourceIst die Datenquelle dieser Statistik. Derzeit nur "Loxone". Der Fetcher soll das Feld auswerten, um zu wissen, ob er diese Datenquelle beherrscht.
fetchStatusStatus des Fetch. Werte sind "running", "paused", "error". Das entspricht dem xxxx.status File und wird bei der Migration von dort übernommen.
fetchStepDas Intervall des Fetch.
statCfgFileDer Dateiname des detaillierten Config-Files dieser Statistik. Der volle Pfad bildet sich aus $CFG::MAIN_CONFIGFOLDER / $statCfgFile
statidOldDie alte ID als vierstelliger String. Wird nicht mehr verwendet.


statcfg_<statid>.json

Jede Statistik hat eine dieser Dateien mit allen Details zu einer Statistik. Beim Fetchen sollte es nie notwendig sein, diese Datei zu SCHREIBEN.

Ein Fetcher, der die Source nicht unterstützt, oder dessen fetchStep gerade nicht dran ist, sollte die Datei auch nicht lesen müssen.

Im Sourcecode werden die geladenen Daten meist als $statcfg oder $statscfg bezeichnet.


{
   "Sink" : {
      "RRD" : {
         "filename" : "0001.rrd",
         "maxValue" : "70",
         "minValue" : "\\-70",
         "step" : "300",
         "sinkStatus" : "error",
         "sinkStatusError" : "Something happened with your database",
         "
      }
   },
   "Source" : {
      "Loxone" : {
         "blockType" : "Lox1wireAsensor",
         "category" : "Wetter",
         "fetchSource" : "Außentemperatursensor",
         "outputs" : { "AQ" : "value",
				       "AQ1" : "value2"
                     },
         "msno" : "1",
         "place" : "",
         "uid" : "00ac8517-0961-11e1-99b9f25d750310ed",
         "unit" : " °C"
      }
   },
   "description" : "",
   "name" : "Aktuell: Außentemperatur",
   "statid" : 1
}

Die Details enthalten allgemeine Informationen, sowie weils einen Hash für die Source (Datenquelle), sowie einen Hash für die Sink (Datenziel).

Der Fetcher liest seine "Source" (z.B. für "Loxone"), wo spezifische Eigenschaften für diese Quelle definiert sind. Ebenso könnte ein anderer Fetcher die Daten aus einer anderen Datenquelle holen.

Der Writer liest seine Parameter aus der "Sink". Jeder Writer definiert seine spezifischen Daten in seiner Sink (hier "RRD"). Ein weiterer Writer könnte "MySQL" heißen und dort spezifische Properties speichern.

Es wird hier noch ein Hash "Plot" kommen, darunter der Name der Engine, und darunter die Parameter der Engine.

ParameterBedeutung
Parameter direkt im Hash
descriptionIst eine freie Beschreibung. Diese wird beim Import leer befüllt.
nameDer Name der Statistik. Beim Import wird das DB-Feld Description übernommen, bzw. beim Import die "Beschreibung" von Loxone.
statidIst die Referenz zur statistics.json
Parameter der Source "Loxone"
blockTypeDie Loxone-Bezeichnung des Config-Objekts. Wird beim Import befüllt.
categoryDie Loxone-Kategorie
fetchSourceDer eindeutige Name, der für den Fetch verwendet wird. Beim Import wird hier die "Bezeichnung" von Loxone übernommen, es kann aber auch die UID drin stehen.
msnoDie Miniserver-Nummer entsprechend get_miniservers.
placeDer Loxone-Raum
uidDie Loxone-UID, die das Element dort eindeutig identifiziert
unitDie Loxone-Einheit des Bausteins
outputs

Enthält einen Hash mit Loxone-Ausgang ↔ Label-Kombination. Der Loxone-Ausgang entspricht der Bezeichnung des Outputs, das Label der Datenquelle des RRD.

"AQ" : "Verbrauch_kWh"
"AQ1" : "Aktueller_Verbrauch"

In jedem Fall wird im returnhash der value zurückgegeben, je nachdem, was verfügbar ist:

  1. outputs->AQ
  2. value (jenes am root-Element)

Dies dient dazu, dass ein Datenziel, das keine Mehfachwerte unterstützt, dennoch den Hauptwert des Blocks erhält. RRD ignoriert den value, wenn outputs definiert sind.

Parameter der Sink "RRD"
filenameIst der Dateiname des RRD-Datenfiles. Den vollen Pfad erhält man mit $CFG::MAIN_RRDFOLDER / $filename
maxValueDer zulässige Maximalwert
minValueDer zulässige Minimalwert
stepDie Schrittweite in Sekunden
Parameter des Plot "irgendwas"




interfaces.json

Die interfaces.json enthält die Grundkonfiguration für alle Sources und alle Sinks.

Welche Grundkonfiguration in der jeweiligen Source oder Sink enthalten ist, ist Sache des jeweiligen Interface-Plugins.

  • Das Loxone-Interface benötigt (vorerst) keine spezielle Konfiguration, da diese direkt von LoxBerry übernommen wird.
  • Das RRD-Interface kann Konfigurationen enthalten wie
    • Speicherort der RRD-Datenbanken
    • Vorlagen für Datenbanken-Schemas
  • Ein MySQL-Interface könnte beispielsweise die Konfiguration von Datenbank-Zugriffsdaten, Hostnamen und Datenbank-Namen enthalten.

Was und in welcher Form die jeweiligen Interfaces Daten innerhalb ihres Bereichs speichern, ist ihnen selbst überlassen.

Die interfaces.json enthält also alle Konfigurationen, die für alle Statistiken dieses Interfaces gleich sind. Die statcfg_xxx.json Dateien hingegen enthalten Einstellungen pro Statistik.

Es kann sowohl mehrere Sinks als auch mehrere Sources geben.  Der Name von Sink bzw. Source ist der Schlüssel für die statcfg-Source und -Sink.

{
   "Sink" : {
      "RRD" : {
         ... settings ...
           }
   },
   "Source" : {
      "Loxone" : {
         ... settings ...
      }
   }
}
  • Keine Stichwörter