Zum Inhalt springen

Konfiguration des MQTT-Collectors

Der MQTT-Collector wird über Umgebungsvariablen konfiguriert.

Hostname des MQTT-Brokers, bei dem der Collector die Topics abonniert. Das kann die IP-Adresse eines lokal erreichbaren ioBroker sein, aber auch die Domain eines externen Brokers.

Hier gehört nur der Host hin, kein http:// oder https:// und keine Portnummer. Der Port steht getrennt in MQTT_PORT.

Beispiel
MQTT_HOST=192.168.178.31

Port des MQTT-Brokers, eine Ganzzahl. Ohne TLS lauscht ein Broker üblicherweise auf 1883, mit TLS auf 8883. Ob der Collector TLS spricht, entscheidet aber nicht der Port, sondern MQTT_SSL. Beides muss zusammenpassen.

Beispiel
MQTT_PORT=1883

Sichert die Verbindung zum Broker mit TLS ab. Erlaubt sind true und false, jeder andere Wert gilt als false. Standardwert ist false, denn ein lokaler ioBroker verlangt TLS üblicherweise nicht.

Beispiel
MQTT_SSL=true

Benutzername für den Zugriff auf den MQTT-Broker. Nötig ist er nur, wenn der Broker eine Anmeldung verlangt. Ohne die Variable meldet sich der Collector ohne Zugangsdaten an.

Beispiel
MQTT_USERNAME=solectrus

Passwort für den Zugriff auf den MQTT-Broker. Nötig ist es nur, wenn der Broker eine Anmeldung verlangt. Ohne die Variable meldet sich der Collector ohne Zugangsdaten an.

Beispiel
MQTT_PASSWORD=my-mqtt-password

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 Messwerte hin und liest nie etwas zurück.

Passt der Token nicht, weist InfluxDB jeden Schreibzugriff ab. Der Collector läuft dann weiter, protokolliert aber Fehler, und im Dashboard bleiben die Kurven leer.

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

Organisation in InfluxDB, unter der die Messwerte 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, mehr als eine braucht es nicht.

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 Messwerte 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, und zu dem, aus dem das Dashboard liest. Gibt es ihn nicht, lehnt InfluxDB die Schreibzugriffe ab.

Beispiel
INFLUX_BUCKET=solectrus

Zeitzone gemäß Liste. Standardwert ist UTC.

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

Beispiel
TZ=Europe/Berlin

Für jedes Topic, das der MQTT-Collector abonnieren soll, muss ein Mapping definiert werden. Ein Mapping besteht aus mehreren Umgebungsvariablen, die mit dem Präfix MAPPING_X_ beginnen, wobei X eine eindeutige Zahl sein muss.

Eine ausführliche Beschreibung eines Mappings findet sich auf der folgenden Seite:
Abonnieren von Topics.