Zum Inhalt springen

Konfiguration des Tibber-Collectors

Der Tibber-Collector wird über Umgebungsvariablen konfiguriert.

Der Collector läuft als eigener Docker-Service aus dem Image ghcr.io/solectrus/tibber-collector. Ein Beispiel für den Service-Eintrag in der compose.yaml zeigt das Repository auf GitHub.

HELIOS schreibt die compose.yaml bei jeder Änderung neu, ein von Hand ergänzter Service geht dabei verloren. Der Collector muss deshalb schon vor der Übernahme durch HELIOS Teil der Installation sein.

Access Token für die Tibber-API. Er lässt sich auf der Developer-Website von Tibber erstellen und setzt einen Account mit aktivem Vertrag voraus.

Weist Tibber den Token ab, protokolliert der Collector den Fehler und versucht es im nächsten Durchlauf erneut. In der InfluxDB landen dann keine Preise.

Beispiel
TIBBER_TOKEN=3A77EECF61BD445F47241A5A36202185C35AF3AF58609E19B53F3A8872AD7BE1-1

Intervall in Sekunden, in dem der Collector die Preise von Tibber abfragt. Erlaubt ist eine positive Ganzzahl. Standardwert ist 3600, also eine Stunde.

Ein kürzeres Intervall bringt nichts, denn Tibber veröffentlicht die Preise nur einmal täglich. Es erzeugt lediglich zusätzliche API-Anfragen. Eine 0 oder ein nicht numerischer Wert lässt den Collector beim Start abbrechen.

Beispiel
TIBBER_INTERVAL=7200

Hostname des InfluxDB-Servers. Läuft InfluxDB im selben Docker-Netzwerk, ist das der Name des Docker-Services, also influxdb. Es kann aber auch ein externer Server sein, etwa influxdb.example.com.

Beispiel
INFLUX_HOST=influxdb

Schema für die Verbindung zu InfluxDB, http oder https. Standardwert ist http. Bei einer externen InfluxDB mit TLS gehört hier https hin.

Beispiel
INFLUX_SCHEMA=https

Port für die Verbindung zu InfluxDB, eine Ganzzahl. Standardwert ist 8086. Bei einer externen, per TLS abgesicherten InfluxDB ist es oft 443.

Beispiel
INFLUX_PORT=443

Token, mit dem sich der Collector bei InfluxDB anmeldet. Er muss dort existieren und das Recht haben, in den angegebenen Bucket zu schreiben. Mehr braucht der Collector nicht: Er schickt Preise hin und liest nie etwas zurück.

Passt der Token nicht, weist InfluxDB den Schreibzugriff ab. Die Preise landen dann nicht in der Datenbank.

Beispiel
INFLUX_TOKEN=my-super-secret-write-token

Organisation in InfluxDB, unter der die Preise gespeichert werden. Eine Organisation ist der Mandant, dem Benutzer, Buckets und Tokens gehören. InfluxDB legt sie beim ersten Start an. In einer SOLECTRUS-Installation heißt sie solectrus.

Der Name muss zu der Organisation passen, die in InfluxDB tatsächlich existiert. Ein anderer Wert benennt sie nicht um, er lässt den Collector nur ins Leere schreiben.

Beispiel
INFLUX_ORG=solectrus

Bucket in InfluxDB, in den der Collector die Preise schreibt. Ein Bucket ist das, was anderswo die Datenbank wäre: ein benannter Speicher mit eigener Aufbewahrungsdauer. Auch ihn legt InfluxDB beim ersten Start an. Eine SOLECTRUS-Installation kommt mit einem einzigen aus, er heißt solectrus.

Der Name muss zu dem Bucket passen, der in InfluxDB existiert. Gibt es ihn nicht, lehnt InfluxDB die Schreibzugriffe ab.

Beispiel
INFLUX_BUCKET=solectrus

Measurement in InfluxDB, in das der Collector die Preise schreibt. Standardwert ist Prices, auch bei einem leeren Wert.

Der Name muss zu dem passen, den der SENEC-Charger unter INFLUX_MEASUREMENT_PRICES liest. Groß- und Kleinschreibung zählt dabei: prices und Prices sind zwei verschiedene Measurements.

Beispiel
INFLUX_MEASUREMENT=Prices

Zeitzone gemäß Liste. Standardwert ist UTC.

Sie betrifft ausschließlich die Zeitstempel im Protokoll des Collectors. Die Preise selbst speichert InfluxDB immer in UTC, daran ändert TZ nichts.

Beispiel
TZ=Europe/Berlin