Eine Beschreibung der Konfigurationsdatei von vzlogger, der Übersichtlichkeit halber in Abschnitte aufgeteilt.

Formatiert ist sie nach JSON; kompakt, manuell lesbar und einfach zu parsen. Entgegen dem Standard unterstützt vzlogger auch Kommentare /*…*/ oder // innerhalb der Konfigurationsdatei.
Korrekte Kommata und Klammerung sind zwingend. Der vzlogger.conf-Editor hilft dabei. Er bietet auch eine meter- und channel-Vorauswahl und blendet dann Schlüssel aus die nicht benötigt werden.
Zeichenketten (String) müssen in Anführungszeichen gesetzt werden, Ganzzahlen (Integer) und Logische Ausdrücke (Bool) hingegen nicht. Gruppen {} und Schlüssel dürfen in root nur einmalig verwendet werden, in Arrays [] aber mehrmals.

Bestimmte Schlüssel bekommen, wenn sie nicht explizit genannt werden, bei Bedarf einen Standardwert (Default) zugewiesen.

Im Wurzelverzeichnis haben wir die allgemeinen Einstellungen.

{
  "retry": 0,
  "verbosity": 0,
  "log": "/var/log/vzlogger/vzlogger.log",

Wartezeit in Sekunden nach einer fehlgeschlagenen Anfrage.

Ausführlichkeit des Fehlerlogs.
In der höchsten Detailstufe werden auch alle verfügbaren OBIS-Codes eines SML-Telegramms gelistet.

Speicherort des Fehlerlogs.

Empfangsort des VZ-Push-Servers.
Über den Dienst ist es zum Beispiel möglich Daten an die VZ-Middleware zu schicken die zwar dargestellt, aber nicht gespeichert werden. Es muss parallel dazu der Push-Server der Middleware aktiviert werden.

  "push": [
    {
      "url": ""http://127.0.0.1:5582""
    }

Zielort an dem die Daten in Empfang genommen werden.

HTTP-Dienst (httpd) für Daten-Pull. Stellt die Daten der konfigurierten meter zu manuellen Kontrolle oder für andere Anwendungen bereit. Erspart einem z.B das Parsen des SML-Telegramms von einem eHz.
Es können alle Werte angezeigt werden für die ein channel angelegt wurde, auch jene die „api“ : „null“ konfiguriert wurden.

  "local": {
    "enabled": false,
    "port": 8081,
    "index": false,
    "timeout": 0,
    "buffer": 0
  },

Aktiviert den httpd.

Der Port an dem der Dienst auf Anfragen hört. Wenn auf der selben Maschine bereits ein httpd arbeitet ist darauf zu achten das der Port nicht doppelt verwendet wird! Für HTTP ist der Standard-Port 80, PPM bieten wir üblicherweise auf 8080 an.

Normal sollte die Anfrage auch die UUID des gewünschten channel enthalten, z.B.: http://localhost:8081/c673b290-fdac-11e0-a470-1d9351203a00. Wird der Index aktiviert werden auf Anfrage http://localhost:8081/ alle channel ausgegeben.

?

? Größe des Ringspeichers ?

Hier kann die Verbindung zum einem MQTT-Broker (Server) eingetragen werden. Die in meters angegebenen Kanäle werden dann in das entsprechende MQTT-Topic übertragen.

  "mqtt": {
    "enabled": false,
    "host": "test.mosquitto.org",
    "port": 1883,
    "id": "vzlogger",
    "cafile": "",
    "capath": "",
    "certfile": "",
    "keyfile": "",
    "keypass": "",
    "keepalive": 30,
    "topic": "vzlogger/data",
    "id": "",
    "user": "",
    "pass": "",
    "retain": false,
    "rawAndAgg": false,
    "qos": 0,
    "timestamp": false
  }

MQTT an- oder abstellen.

Server-Adresse des MQTT-Brokers.

Port des MQTT-Brokers.

Optionaler Dateiname der Server CA

Optionaler Pfad für Server CAs

Optionaler Dateiname des Client-Zertifikats (z.B. client.crt)

Optionaler Pfad zum privaten Schlüssel des Client-Zertifikats (z.B. client.key)

Optionales Passwort des privaten Schlüssels

Optionales Angabe der Sekunden zur Aufrechterhaltung der Verbindung (Keepalive)

Optionale Angabe des MQTT-Topics, in welches die Werte der verschiedenen meters geschrieben werden sollen. Im angegebenen Topic werden die meter durch ein Unter-Topic chnX unterschieden. Der erste meter ist im Unter-Topic chn0, der zweite meter im Unter-Topic chn1 usw. zu finden.

Optionale statische Client-ID. Bei Nichtangabe wird eine Client-ID nach dem Muster vzlogger_<pid> verwendet.

Optionaler Benutzername zur Anmeldung an den MQTT-Broker.

Optionales Password zur Anmeldung an den MQTT-Broker.

Optionale Anweisung zum Zwischenspeichern der MQTT-Nachricht, um bei Neuverbindung sofort darauf zugreifen zu können (Retain-Flag). Bei der Angabe von false ist der Wert erst sichtbar, wenn der Wert an den MQTT-Broker gesendet wird.

Optionale Veröffentlichung der Rohdaten selbst wenn der Zusammenfassungs-Modus (aggmode) verwendet wird.

Optionale Angabe des Quality of Service.

Optionale Angabe, ob ein Zeitstempel im Payload mit angegeben werden soll.

Hier werden die Datenquellen (Zähler, Sensoren) definiert mit denen der vzlogger kommunizieren soll. Jede Quelle ist eine Gruppe von Schlüsseln, es sind also mehrere Meter möglich.
Nicht alle Paramter sind in allen Konfigurationen erforderlich oder sinnvoll. Erst werden die Allgemeinen, dann die speziellen Parameter, in Abhängigkeit von protocol, beschrieben.

  "meters": [
    {
      "enabled": false,
      "allowskip": false,
      "aggtime": -1,
      "aggfixedinterval": false,
      "protocol": "s0",
      "device": "",
      "channels": [],

Den betreffenden Meter (z.B. für Diagnosezwecke) an- oder abstellen.

Schlägt das öffnen des Meter fehl bricht vzlogger ab oder ignoriert ihn und setzt mit dem nächsten konfigurierten Meter fort.

Vzlogger kann Messwerte sammeln und zusammenfügen (aggregieren) bevor sie an die MW gesendet werden. Hier wird die Sammelzeit in Sekunden definiert. Es ist darauf zu achten, dass die aggtime nicht kürzer ist als interval.
aggtime arbeitet zusammen mit aggmode.

Für eine optisch schönere Darstellung im Frontend ist es möglich alle aggregierten Kanäle dieses Meters mit identischem Timestamp an die Middleware zu senden.

Das Protokoll mit dem der Meter sendet. Der JSON-Editor hilft bei der korrekten Wahl.

Das Linux-Device über den der Meter angebunden ist.

So ziemlich die wichtigste Gruppe. Hier erfolgt die Zuordnung der von vzlogger gelesenen Daten zu den Kanälen der Middleware. Es sind mehrere channels in jedem meter möglich.

      "channels": [
        {
          "uuid": "",
          "identifier": "",
          "api": "volkszaehler",
          "middleware": "http://localhost/middleware.php",
          "host": "127.0.0.1",
          "secretKey": "",
          "type": "device",
          "scaler": 1,
          "timeout" : 30,
          "aggmode": "none",
          "duplicates": 0
        }

Über die UUID werden die Kanäle der Middleware identifiziert. Sie wird beim Erstellen eines Kanals von der Middleware generiert.

Über diesen String werden die Werte zu diesem channel aus den Daten des meter identifiziert. Wie der String aussieht hängt vom protocol ab.

Hier wird die Programmierschnittstelle definiert über die der vzlogger Kontakt aufnehmen soll.

Achtung: Der Wert ist ggfs. „null“, nicht null.

Die URL über welche die api zu erreichen ist.

Die URL über welche die InfluxDB api zu erreichen ist.

Schlüssel für die Kommunikation mit der mySmartGrid-api

Art des meter, nur für mySmartGid-api

Faktor für die Werte, nur für mySmartGid-api

Zeit in Sekunden für die Zustellung per Curl nach der die Verbindung als misslungen betrachtet wird.

Mathematische Art der Aggregation die der vzlogger vornehmen soll. Nur wirksam in Verbindung mit aggtime größer als 0.
Wenn aggtime auf -1 steht (deaktiviert), dann bitte auch aggmode auf „none“ setzen, um undefiniertes Verhalten zu vermeiden.

Zeit in Sekunden in denen wiederholende, identische Werte (z.B. unveränderte Zählerstände) nicht an die api weitergeleitet werden sollen.

Jedes protocol hat eine eigene Reihe erforderlicher und optionaler Schlüssel.

      "gpio": -1,
      "mmap": "",
      "gpio_dir": -1,
      "configureGPIO": true,
      "resolution": 1000,
      "send_zero": false,
      "debounce_delay": 30,
      "nonblocking_delay": 100000,

Bestimmt den GPIO am RaspberryPi an dem der Meter angeschlossen ist.

Für hochfrequente Impulssignale können die GPIO des RaspberryPi auf Memory-Mapping umgestellt werden. Die Ports müssen manuell als Eingänge konfiguriert werden. Nur für Impulssignale!

Es kann die Zählrichtung umgekehrt werden.

Vzlogger kann die E/A-Konfiguration des GPIO übernehmen.

Impulse/kWh, wird bei api:mysmartgrip und identifier:Power benötigt.

Wenn keine Impulssignale eintreffen wird der vzlogger auch keinen Datentupel an die MW senden. Ist send_zero aktiv wird jede Sekunde ein Tuple gesendet auch wen keine Impulse registriert wurden. In Verbindung mit aggtime kann der Zeitraum vergrößert werden.

Bei mechanischen Impulsquellen (Reedkontakten) kann es zu Kontaktprellen kommen. Hier wird definiert wie viele Millisekunden nachfolgende Signalflanken ignoriert werden.

Zeitverzögerung in Nanosekunden bei aktiviertem mmap.

Manche Zähler senden ihre Daten unaufgeforder alle paar Sekunden (Push), andere müssen dazu aufgefordert werden (Pull). Ob es sich um einen Pull- oder Push-Meter handelt kann mit einer Digitalkamera an der IR-Diode geprüft werden. Vielleicht ist dein Zählertyp aber auch schon im Wiki dokumentiert.

      "interval": -1,
      "host": "",
      "dump_file": "",
      "pullseq": "",
      "ackseq": "auto",
      "baudrate": 300,
      "baudrate_read": 300,
      "parity": "7e1",
      "wait_sync": "off",
      "read_timeout": 10,
      "baudrate_change_delay": 0

Verzögerung zwischen Zugriffen auf Pull-Meter in Sekunden. Es ist darauf zu achten das der Meter genug Zeit hat zu antworten, z.B. wenn er seriell mit nur 300bd sendet.

Für Meter die nicht lokal sondern übers TCP/IP-Netz angebunden sind.

Das Datentelegramm kann zu Diagnosezwecken zusätzlich in eine Datei ausgegeben werden.

Initialisierungssequenz für Pull-Meter.

Nach der Initilisierungssequenz antwortet ein Pull-Meter mit einem Einzeiler, um das Datentelegramm zu erhalten ist eine Startsequenz nötig. Ev. wird dabei auch die Baudrate umgestellt. Ist aber stark vom Zähler abhängig.

Die serielle Geschwindigkeit mit der der Meter kommuniziert.

Pull-Meter erlauben teilweise auch mehr als 300bd. Diese muss in der ackseq angefordert und hier dem vzlogger mitgeteilt werden.

Frameformat der seriellen Kommunikation.

Manche Zähler schicken kein Synchronisationssignal „!“ sondern weiter Datentelegramme ohne auf eine pullseq zu warten.

Zeit in Sekunden nach denen der vzlogger die Kommunikation für beendet erachtet. Ist erforderlich falls der Zähler kein Synchronisationssignal sendet, die Startsequenz fehlt schlägt oder sonstwie Zeichen verloren gehen. Die Zeit darf aber nicht zu kurz sein sonst wird mitten im Datentelegramm abgebrochen.

Zeit in ms nach ackseq bevor die Baudrate auf baudrate_read umgestellt wird.

Manche Zähler senden ihre Daten unaufgeforder alle paar Sekunden (Push), andere müssen dazu aufgefordert werden (Pull). Ob es sich um einen Pull- oder Push-Meter handelt kann mit einer Digitalkamera an der IR-Diode geprüft werden. Vielleicht ist dein Zähler aber auch schon im Wiki dokumentiert.

      "interval": -1,
      "host": "",
      "pullseq": "",
      "baudrate": 9600,
      "parity": "8n1",
      "use_local_time": false

Verzögerung zwischen Zugriffen auf Pull-Meter in Sekunden. Es ist darauf zu achten das der Meter genug Zeit hat zu antworten, z.B. wenn er seriell mit nur 300bd sendet.

Für Meter die nicht lokal sondern übers TCP/IP-Netz angebunden sind.

Initialisierungssequenz für Pull-Meter.

Die serielle Geschwindigkeit mit der der Meter kommuniziert.

Frameformat der seriellen Kommunikation.

Nutzt zur Erstellung des Timestamp die aktuelle Uhrzeit des Rechners („true“) statt des Zählers („false“).
Die meisten Zähler liefern im Datenstrom die Echtzeit mit. Wenn diese bei der Inbetriebnahme korrekt eingestellt wurde, verwenden wir sie um z.B. mögliche Zeitverschiebungen durch FiFo-Puffer auszuschließen. Sind die Timestamp falsch oder fehlen sogar ganz muss der vzlogger die lokale Rechnerzeit heranziehen.

—-

Zufallsgenerator

Auswerten einer bestehenden Datei, wird mittels format weiter parametriert

In einem exec-Kanal wird für jede Abfrage das im Parameter command angegebene Shellkommando aufgerufen und die Standard-Ausgabe dieses Kommandos geparst. Dabei kann das erwartete Format mit Hilfe des format Parameters spezifiziert werden.

• exec-Kanäle sind nicht möglich, wenn der vzlogger als root ausgeführt wird. Durch einen Compiler-Parameter lässt sich diese Sicherheitsmaßnahme ausschalten. Es wird allerdings empfohlen, den vzlogger besser nicht als root auszuführen. In vielen Standard-Images ist dies nicht der Fall.
• Es wird für den Aufruf eine Shell verwendet, damit sind Pipes etc in vollem Umfang möglich
• Enthält der Formatstring kein $t, wird die aktuelle Uhrzeit als Timestamp verwendet

Dieses Kommando wird ausgeführt; seine Ausgabe geparst

Jede Zeile der Ausgabe des command wird mit diesem Formatstring geparst und für jede Zeile ein eigener Datensatz erzeugt. Somit können sowohl mehrere Werte (z.B. verschiedene Register, die mit einem einzigen Aufruf des command ausgelesen wurden) als auch Werte unterschiedlicher Zeitstempel (z.B. man fragt die Quelle alle 30 Sekunden ab, möchte aber aus Gründen immer Batches von sechs Werten gleichzeitig in die Datenbank schreiben) mit einem einzelnen Aufruf eingetragen werden.

• $t: timestamp (in Sekunden)
• $i: identifier (beliebiger String, taucht im Channel unter identifier wieder auf)
• $v: value

Werte ohne identifier-Angabe landen beim Channel mit '„identifier“: „“'.

Weitere Dokumentation könnte man in den Mailinglistenarchiven, z.B. hier ff., finden.

Protokoll der FlukSo-Meter

Bilderkennung

Open Metering System, ein Ableger von M-Bus

Für 1-Wire-Temperatursensoren am Busmaster DS2482 sind keine weiteren Parameter nötig.

Und ganz wichtig: Klammern schließen!

     }
  ]
}