https://github.com/solectrus/power-splitter
Accessing InfluxDB at http://influxdb:8086, bucket solectrus
Sensor initialization started
- Sensor 'grid_import_power' mapped to 'SENEC:grid_power_plus'
- Sensor 'house_power' mapped to 'SENEC:house_power'
- Sensor 'heatpump_power' mapped to 'Consumer:power'
- Sensor 'wallbox_power' mapped to 'SENEC:wallbox_charge_power'
- Sensor 'battery_charging_power' mapped to 'SENEC:bat_power_plus'
- Sensor 'custom_power_01' mapped to 'Washer:power'
- Sensor 'custom_power_02' mapped to 'Fridge:power'
- Sensor 'custom_power_03' mapped to 'KabelFritz:power'
- Sensor 'custom_power_04' mapped to 'Synology:power'
- Sensor 'custom_power_05' mapped to 'iMac:power'
- Sensor 'custom_power_06' mapped to 'Dishwasher:power'
- Sensor 'house_power' excluded 'heatpump_power'
Sensor initialization completed
Starting endless loop for processing current data...
2026-07-14 10:16:17 +0200 - Processing day 2026-07-14
Pushing 123 records to InfluxDB
Sleeping for 300 seconds...
...
```
Fehler protokolliert der Power-Splitter ebenfalls, etwa wenn die InfluxDB nicht erreichbar ist.
## Quelltext
Der Power-Splitter ist in Ruby implementiert, der Quelltext ist auf GitHub verfügbar: \
[github.com/solectrus/power-splitter](https://github.com/solectrus/power-splitter)
---
# Inbetriebnahme des Power-Splitters
> Die Voraussetzungen für den Power-Splitter – ein weiterer Verbraucher neben dem Haus, die passenden Sensoren und der erste Durchlauf.
[HELIOS](/docs/referenz/helios/) installiert den Power-Splitter automatisch, sobald die Voraussetzungen erfüllt sind.
## 1. Ein weiterer Verbraucher
Neben dem Hausverbrauch muss mindestens ein weiterer Verbraucher an SOLECTRUS angebunden sein: ein E-Auto, eine Wärmepumpe oder ein benutzerdefinierter Verbraucher. Deren Messwerte müssen im Dashboard sichtbar sein.
Gibt es nur den Hausverbrauch, gibt es nichts aufzuteilen.
## 2. Die passenden Sensoren
Zugeordnet sein müssen mindestens `GRID_IMPORT_POWER` (Netzbezug) und `HOUSE_POWER` (Hausverbrauch), dazu die Sensoren der Verbraucher, deren Verbrauch aufgeteilt werden soll. Die Zuordnung erfolgt in HELIOS unter _Konfiguration → Sensoren_.
Sind alle drei Teile beisammen – Netzbezug, Hausverbrauch und ein weiterer Verbraucher – nimmt HELIOS den Power-Splitter beim nächsten Start automatisch mit auf.
## 3. Der erste Durchlauf
Beim Start arbeitet der Power-Splitter zunächst die Vergangenheit ab, beginnend beim ältesten noch unbearbeiteten Tag. Je nach Datenmenge und Rechenleistung dauert das eine Weile, eine halbe Stunde ist nicht ungewöhnlich. Mitverfolgen lässt sich das im [Protokoll](/docs/anleitungen/logging/).
Danach leert der Power-Splitter den Redis-Cache und setzt die Tageszusammenfassungen zurück, damit sie seine Werte enthalten. Von Hand ist dafür nichts zu tun.
## Im Dashboard
Bei einem gewählten Zeitraum (Tag, Woche, Monat, Jahr, Gesamt) zeigt der Tooltip dann bei jedem Verbraucher die Aufteilung seines Verbrauchs. Die Diagramme erscheinen gestapelt.
---
# Konfiguration des Power-Splitters
> Die Umgebungsvariablen des Power-Splitters, vom Berechnungsintervall über InfluxDB und PostgreSQL bis zu den Sensoren.
Der Power-Splitter wird über Umgebungsvariablen konfiguriert.
## Umgebungsvariablen
### `POWER_SPLITTER_INTERVAL`
Abstand zwischen zwei Berechnungen in Sekunden, eine Ganzzahl. Standardwert ist `3600`, also eine Stunde. Kleinere Werte lassen den Power-Splitter häufiger laufen. Genauer wird die Berechnung dadurch nicht, nur aktueller, und das sieht man ausschließlich am laufenden Tag im Dashboard.
Werte unter `300` haben keine Wirkung: Der Power-Splitter hebt sie auf `300` an, also auf fünf Minuten.
```properties title="Beispiel"
POWER_SPLITTER_INTERVAL=300
```
> **HELIOS**
>
>
> HELIOS trägt fest `300` ein. Einzustellen gibt es nichts.
>
### `INFLUX_HOST`
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`.
```properties title="Beispiel"
INFLUX_HOST=influxdb
```
> **HELIOS**
>
>
> HELIOS setzt den Hostnamen fest auf `influxdb`, auch bei aktivem [Ingest-Dienst](/docs/referenz/ingest/). Einzustellen gibt es nichts.
>
### `INFLUX_SCHEMA`
Schema für die Verbindung zu InfluxDB, `http` oder `https`. Standardwert ist `http`. Bei einer externen InfluxDB mit TLS gehört hier `https` hin.
```properties title="Beispiel"
INFLUX_SCHEMA=https
```
> **HELIOS**
>
>
> HELIOS setzt `http`, denn innerhalb des Docker-Netzwerks wird nicht verschlüsselt.
>
### `INFLUX_PORT`
Port für die Verbindung zu InfluxDB, eine Ganzzahl. Standardwert ist `8086`. Bei einer externen, per TLS abgesicherten InfluxDB ist es oft `443`.
```properties title="Beispiel"
INFLUX_PORT=443
```
> **HELIOS**
>
>
> HELIOS setzt den Port fest auf `8086`. Einzustellen gibt es nichts.
>
### `INFLUX_TOKEN`
Token, mit dem sich der Power-Splitter bei InfluxDB anmeldet. Er muss dort existieren und das Recht haben, den angegebenen Bucket zu **lesen** und in ihn zu **schreiben**. Ein reiner Schreib-Token genügt nicht: Der Power-Splitter holt sich die Messwerte der Sensoren aus InfluxDB, rechnet und legt das Ergebnis dort wieder ab.
Passt der Token nicht, weist InfluxDB die Zugriffe ab. Der Power-Splitter protokolliert Fehler, und im Dashboard bleibt die Aufteilung des Netzbezugs leer.
```properties title="Beispiel"
INFLUX_TOKEN=my-super-secret-readwrite-token
```
> **HELIOS**
>
>
> HELIOS gibt dem Power-Splitter einen Token mit Lese- und Schreibrecht, siehe [`INFLUX_TOKEN_READWRITE`](/docs/referenz/helios/konfiguration/#influx_token_readwrite). Den reinen Schreib-Token der Kollektoren bekommt er nicht.
>
### `INFLUX_ORG`
Organisation in InfluxDB, in der die Messwerte liegen. Eine Organisation ist der Mandant, dem Benutzer, Buckets und Tokens gehören. InfluxDB legt sie [beim ersten Start](/docs/referenz/influxdb/konfiguration/) 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 Power-Splitter nur ins Leere greifen.
```properties title="Beispiel"
INFLUX_ORG=solectrus
```
> **HELIOS**
>
>
> HELIOS gibt `solectrus` vor. Einzustellen gibt es nichts.
>
### `INFLUX_BUCKET`
Bucket in InfluxDB, aus dem der Power-Splitter die Messwerte liest und in den er seine Ergebnisse schreibt. Ein Bucket ist das, was anderswo die Datenbank wäre: ein benannter Speicher mit eigener Aufbewahrungsdauer. Auch ihn legt InfluxDB [beim ersten Start](/docs/referenz/influxdb/konfiguration/) an. Eine SOLECTRUS-Installation kommt mit einem einzigen aus, er heißt `solectrus`.
Es muss derselbe Bucket sein, in den die Kollektoren schreiben und aus dem das Dashboard liest. Ein anderer Name führt den Power-Splitter auf einen leeren oder nicht vorhandenen Bucket, und er hat nichts zu rechnen.
```properties title="Beispiel"
INFLUX_BUCKET=solectrus
```
> **HELIOS**
>
>
> HELIOS gibt `solectrus` vor. Einzustellen gibt es nichts.
>
### `REDIS_URL`
Adresse des Redis-Cache, den das Dashboard nutzt. Der Power-Splitter leert ihn einmalig, nachdem er die Vergangenheit durchgerechnet hat. Sonst zeigt das Dashboard weiter die alten, zwischengespeicherten Werte.
Ohne die Variable schreibt der Power-Splitter eine Warnung ins Protokoll und lässt den Cache stehen. Er ist dann [von Hand zu leeren](/docs/referenz/redis/#cache-leeren).
```properties title="Beispiel"
REDIS_URL=redis://redis:6379/1
```
> **HELIOS**
>
>
> HELIOS setzt die Adresse fest auf `redis://redis:6379/1`. Einzustellen gibt es nichts.
>
### `DB_HOST`
Hostname der PostgreSQL-Datenbank des Dashboards. Läuft sie im selben Docker-Netzwerk, ist das der Name des Docker-Services, also `postgresql`.
Wirksam nur zusammen mit `DB_USER` und `DB_PASSWORD`. Der Power-Splitter braucht die drei, um nach einer Neuberechnung die Tageszusammenfassungen des Dashboards zu löschen. Fehlt eine davon, schreibt er eine Warnung ins Protokoll, und die Zusammenfassungen sind im Dashboard von Hand zurückzusetzen.
```properties title="Beispiel"
DB_HOST=postgresql
```
> **HELIOS**
>
>
> HELIOS setzt den Hostnamen fest auf `postgresql`. Einzustellen gibt es nichts.
>
### `DB_USER`
Benutzername für die PostgreSQL-Datenbank, üblicherweise `postgres`.
Wirksam nur zusammen mit `DB_HOST` und `DB_PASSWORD`. Fehlt eine der drei, kann der Power-Splitter die Tageszusammenfassungen des Dashboards nicht löschen.
```properties title="Beispiel"
DB_USER=postgres
```
> **HELIOS**
>
>
> HELIOS setzt den Benutzernamen fest auf `postgres`. Einzustellen gibt es nichts.
>
### `DB_PASSWORD`
Passwort für die PostgreSQL-Datenbank.
Wirksam nur zusammen mit `DB_HOST` und `DB_USER`. Fehlt eine der drei, kann der Power-Splitter die Tageszusammenfassungen des Dashboards nicht löschen.
```properties title="Beispiel"
DB_PASSWORD=ExAmPl3PA55W0rD
```
> **HELIOS**
>
>
> HELIOS reicht das Passwort durch, das es bei der Installation für PostgreSQL erzeugt hat, siehe [`POSTGRES_PASSWORD`](/docs/referenz/postgresql/konfiguration/). Einzustellen gibt es nichts.
>
### `INSTALLATION_DATE`
Datum der Inbetriebnahme der PV-Anlage im Format `JJJJ-MM-TT`. Es gibt der Neuberechnung einen definierten Startpunkt.
Ohne die Variable sucht der Power-Splitter den ältesten Tag, für den Messwerte vorliegen, und beginnt dort. Liegt der weit vor der Inbetriebnahme, rechnet er unnötig lange.
```properties title="Beispiel"
INSTALLATION_DATE=2020-11-27
```
> **HELIOS**
>
>
> HELIOS fragt das Datum unter _Konfiguration → Grundeinstellungen → PV-Anlage_ ab, es ist ein Pflichtfeld.
>
### `TZ`
Zeitzone gemäß [Liste](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). Standardwert ist `Europe/Berlin`.
Sie bestimmt, wo ein Tag beginnt und endet, denn der Power-Splitter rechnet tageweise. Eine falsche Zeitzone verschiebt die Tagesgrenzen und damit die Aufteilung an den Rändern.
```properties title="Beispiel"
TZ=Europe/Rome
```
> **HELIOS**
>
>
> HELIOS fragt die Zeitzone unter _Konfiguration → Grundeinstellungen → PV-Anlage_ ab, vorbelegt mit `Europe/Berlin`.
>
## Sensor-Definition
Der Power-Splitter nutzt dieselben Sensoren wie das Dashboard, beschrieben unter [Sensor-Konfiguration](/docs/referenz/dashboard/sensor-konfiguration/). Im Einzelnen sind das diese Variablen:
- `INFLUX_SENSOR_GRID_IMPORT_POWER`
- `INFLUX_SENSOR_HOUSE_POWER`
- `INFLUX_SENSOR_WALLBOX_POWER`
- `INFLUX_SENSOR_HEATPUMP_POWER`
- `INFLUX_SENSOR_BATTERY_CHARGING_POWER`
- `INFLUX_SENSOR_CUSTOM_POWER_01`
- `INFLUX_SENSOR_CUSTOM_POWER_02`
- `INFLUX_SENSOR_CUSTOM_POWER_03`
- `INFLUX_SENSOR_CUSTOM_POWER_04`
- `INFLUX_SENSOR_CUSTOM_POWER_05`
- `INFLUX_SENSOR_CUSTOM_POWER_06`
- `INFLUX_SENSOR_CUSTOM_POWER_07`
- `INFLUX_SENSOR_CUSTOM_POWER_08`
- `INFLUX_SENSOR_CUSTOM_POWER_09`
- `INFLUX_SENSOR_CUSTOM_POWER_10`
- `INFLUX_SENSOR_CUSTOM_POWER_11`
- `INFLUX_SENSOR_CUSTOM_POWER_12`
- `INFLUX_SENSOR_CUSTOM_POWER_13`
- `INFLUX_SENSOR_CUSTOM_POWER_14`
- `INFLUX_SENSOR_CUSTOM_POWER_15`
- `INFLUX_SENSOR_CUSTOM_POWER_16`
- `INFLUX_SENSOR_CUSTOM_POWER_17`
- `INFLUX_SENSOR_CUSTOM_POWER_18`
- `INFLUX_SENSOR_CUSTOM_POWER_19`
- `INFLUX_SENSOR_CUSTOM_POWER_20`
- `INFLUX_EXCLUDE_FROM_HOUSE_POWER`
`INFLUX_SENSOR_GRID_IMPORT_POWER` und `INFLUX_SENSOR_HOUSE_POWER` sind Pflicht. Fehlt eine der beiden, bricht der Power-Splitter beim Start ab. Alle übrigen sind optional, und je mehr davon gesetzt sind, desto feiner teilt er den Netzbezug auf.
## Measurement
Der Power-Splitter schreibt seine Berechnungen in ein neues Measurement mit der (unveränderlichen) Bezeichnung `power_splitter`. Eine eigene Variable für das Measurement ist daher nicht nötig.
---
# Methodik des Power-Splitters
> Wie der Power-Splitter den Netzbezug minutenweise auf die Verbraucher verteilt, mit Vorrang für die Wallbox und anteiliger Verteilung des Rests.
Der Power-Splitter unterteilt einen Tag in 1-Minuten-Abschnitte und betrachtet jeden separat. Für jeden Abschnitt wird die durchschnittliche Leistung (in W) jedes Verbrauchers ermittelt: Haus, Wallbox, Wärmepumpe, Akkuladung und die benutzerdefinierten Verbraucher. Der Hausverbrauch ist dabei der bereinigte Wert, also ohne die Verbraucher, die aus ihm herausgerechnet sind. Geschrieben werden die Ergebnisse anschließend als 5-Minuten-Mittelwerte, das sind 288 Punkte pro Tag.
Die Aufteilung der Leistung auf die Verbraucher erfolgt dann so: Der Netzbezug wird zunächst der Wallbox zugeordnet (maximal bis zu deren Verbrauch). Der Rest geht **anteilig** an die übrigen Verbraucher, jeder also nach seinem Anteil am Verbrauch, und auch hier bekommt keiner mehr zugeordnet, als er verbraucht hat. Diese Priorisierung folgt dem Gedanken, dass der Ladevorgang an der Wallbox bewusst gestartet wird, während Haus und Wärmepumpe dauerhaft nebenherlaufen.
Ein Zahlenbeispiel:
- Netzbezug: 5 kW
- Wärmepumpe: 2 kW
- Wallbox: 4 kW
- Hausverbrauch: 1 kW
Es sind also 5 kW aufzuteilen. Die Wallbox hat 4 kW benötigt und erhält diese vollständig zugeordnet. Es bleibt 1 kW übrig. Auf Haus und Wärmepumpe entfallen zusammen 3 kW Verbrauch, das Haus stellt davon ein Drittel, die Wärmepumpe zwei Drittel. Genau so wird der Rest verteilt:
- Netzbezug für Wallbox: 4 kW (von 4 kW)
- Netzbezug für Haus: 0,33 kW (von 1 kW)
- Netzbezug für Wärmepumpe: 0,67 kW (von 2 kW)
Einen eigenen Netzbezugs-Wert bekommt jeder benutzerdefinierte Verbraucher. Was er bedeutet, hängt davon ab, ob der Verbraucher aus dem Hausverbrauch herausgerechnet ist:
- **Herausgerechnet**: Er zählt als eigener Verbraucher. Sein Netzbezug kommt zu dem des Hauses hinzu.
- **Nicht herausgerechnet**: Er steckt weiterhin im Hausverbrauch. Sein Netzbezug ist dann ein Teil des Haus-Netzbezugs und darf nicht dazuaddiert werden.
Aufgeteilt wird nur der Netzbezug, nicht der PV-Strom. Für den Akku heißt das: Strom **aus** dem Akku gilt als PV-Strom, denn der Akku nimmt üblicherweise nur PV-Strom auf und gibt ihn zeitverzögert wieder ab. Beim Laden zählt der Akku dagegen als Verbraucher wie jeder andere und bekommt seinen Anteil am Netzbezug zugeordnet, als `battery_charging_power_grid`.
---
# Was ist Redis?
> Die In-Memory-Datenbank, in der SOLECTRUS seinen Cache ablegt und die Live-Aktualisierung des Dashboards abwickelt.
SOLECTRUS legt seinen Cache in der In-Memory-Datenbank **Redis** ab. Das Ergebnis jeder InfluxDB-Abfrage bleibt eine Zeit lang im Cache, sodass identische Abfragen die InfluxDB nicht erneut belasten.
Redis transportiert außerdem die Live-Aktualisierung des Dashboards. Ohne Redis startet das Dashboard nicht.
Beim Beenden, etwa im Rahmen eines Reboots, geht der Cache nicht verloren: Redis schreibt ihn in die Datei `dump.rdb` und liest sie beim nächsten Start wieder ein.
Unterstützt wird Redis in Version 5 oder höher, wobei die aktuelle Version **8** empfohlen wird.
## Cache leeren
Nötig ist das selten, etwa nachdem Messwerte aus der Vergangenheit nachträglich in die InfluxDB gekommen sind. In [HELIOS](/docs/referenz/helios/) gibt es dafür beim Dienst _Redis_ den Knopf **Cache leeren**.
Ohne HELIOS erledigt das ein Befehl im Installationsverzeichnis:
```bash
docker compose exec redis redis-cli FLUSHALL
```
Danach baut SOLECTRUS den Cache im laufenden Betrieb wieder auf. Die ersten Abfragen dauern dann etwas länger.
## Logging
Wie alle Docker-Container schreibt auch Redis ein Protokoll ins Docker-Log, das in etwa so aussieht:
```log
...
Starting Redis Server
1:C 14 Jul 2026 10:00:50.838 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:C 14 Jul 2026 10:00:50.838 * Redis version=8.8.0, bits=64, commit=00000000, modified=1, pid=1, just started
1:C 14 Jul 2026 10:00:50.838 * Configuration loaded
...
1:M 14 Jul 2026 10:00:50.889 * Ready to accept connections tcp
...
```
## Docker-Image
Das offizielle Docker-Image von Redis ist auf Docker Hub verfügbar: \
[https://hub.docker.com/\_/redis](https://hub.docker.com/_/redis)
---
# Konfiguration von Redis
> Zwei Umgebungsvariablen genügen Redis, für den Speicherort der Datei dump.rdb und für die Zeitzone im Protokoll. Ein Passwort gehört nicht dazu.
Redis läuft im offiziellen Docker-Image. Viel gibt es nicht einzustellen: zwei Variablen, mehr braucht der Cache nicht. Ein Passwort ist keine davon, denn der Container ist nur im Docker-Netzwerk erreichbar.
## Umgebungsvariablen
### `REDIS_VOLUME_PATH`
Pfad, in dem Redis seine Daten ablegt. Er geht nicht an Redis selbst, sondern an Docker, das ihn als Volume in den Container mountet. Dort landet die Datei `dump.rdb`, in die Redis beim Herunterfahren den Inhalt seines Speichers schreibt.
Liegt am Pfad schon eine `dump.rdb`, liest Redis sie beim Start ein, und der Cache steht sofort wieder bereit. Fehlt sie, startet Redis mit leerem Cache. Verloren geht dabei nichts: Das Dashboard füllt den Cache im laufenden Betrieb neu, die ersten Abfragen dauern dann etwas länger.
```properties title="Beispiel"
REDIS_VOLUME_PATH=/somewhere/solectrus/redis
```
> **HELIOS**
>
>
> HELIOS legt den Pfad bei der Installation fest, standardmäßig auf den Unterordner `redis` im Installationsverzeichnis. Unter _Konfiguration → Grundeinstellungen → Speicherorte_ zeigt HELIOS ihn an, ändern lässt er sich dort nicht.
>
### `TZ`
Zeitzone gemäß [Liste](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). Standardwert ist `UTC`.
Sie betrifft ausschließlich die Zeitstempel im Protokoll des Containers. Was im Cache liegt, berührt sie nicht.
```properties title="Beispiel"
TZ=Europe/Berlin
```
> **HELIOS**
>
>
> HELIOS fragt die Zeitzone unter _Konfiguration → Grundeinstellungen → PV-Anlage_ ab, vorbelegt mit `Europe/Berlin`.
>
---
# Was ist der SENEC-Charger?
> Der SENEC-Charger belädt einen SENEC-Stromspeicher aus dem Netz, wenn der Strompreis niedrig ist und die PV-Prognose wenig Ertrag erwarten lässt.
Der **SENEC-Charger** steuert einen SENEC-Stromspeicher bei Verwendung eines dynamischen Stromtarifs (von [Tibber](https://tibber.com/de)). Er belädt ihn aus dem Netz, wenn der Strompreis unter einem Schwellwert liegt und die PV-Prognose zu wenig Ertrag erwarten lässt.
Damit der SENEC-Charger funktioniert, werden zwei weitere Kollektoren benötigt:
- Der [Tibber-Collector](/docs/referenz/tibber-collector/) sammelt die Strompreise von Tibber und schreibt sie in die InfluxDB.
- Der [Forecast-Collector](/docs/referenz/forecast-collector/) sammelt die Wettervorhersage und schreibt sie ebenfalls in die InfluxDB.
> **Hinweis**
>
>
> Da für die Beladung des Speichers ein direkter Zugriff auf den SENEC-Stromspeicher notwendig ist, funktioniert dies nicht mit dem SENEC.Home 4 oder neuer. Unterstützt werden ausschließlich SENEC.Home V2.1 und V3.
>
## Funktionsweise
Der SENEC-Charger liest stündlich die Strompreise und die Prognose aus der InfluxDB und entscheidet, ob der Stromspeicher aus dem Netz beladen werden soll. Diese Faktoren gehen ein:
- Betriebszustand des Stromspeichers, der einen leeren Akku meldet
- Strompreis in den kommenden Stunden
- Erwartete PV-Erzeugung laut Prognose
Wie die Entscheidung im Einzelnen fällt, steht unter [Methodik](/docs/referenz/senec-charger/methodik/).
## Logging
Der Charger schreibt ein Protokoll ins Docker-Log, das im Normalfall so aussieht:
```log
SENEC charger for SOLECTRUS, Version 0.7.2, built at 2026-03-22T09:10:09.586Z
https://github.com/solectrus/senec-charger
Copyright (c) 2023-2026 Georg Ledermann, released under the MIT License
Using Ruby 4.0.2 on platform aarch64-linux-musl
Connecting to SENEC at https://192.168.178.29
Connecting to InfluxDB at http://influxdb:8086, bucket solectrus, measurements Prices and Forecast
#1 - 2026-07-14 10:09:48 +0200
Grid power not cheap, nothing to do
Checked prices between Sunday, 07:15 - Monday, 00:45, ⌀ 1.06
Best 4-hour range: Sunday, 07:15 - Sunday, 09:00, ⌀ 0.75
Ratio best/average: 70.9 %
Sleeping for 3600 seconds ...
...
```
Fehler protokolliert der Charger ebenfalls, etwa wenn der Stromspeicher oder die InfluxDB nicht erreichbar ist.
## Quelltext
Der SENEC-Charger ist in Ruby implementiert, der Quelltext ist auf GitHub verfügbar: \
[github.com/solectrus/senec-charger](https://github.com/solectrus/senec-charger)
---
# Konfiguration des SENEC-Chargers
> Umgebungsvariablen des SENEC-Chargers – Zugang zum Stromspeicher, Schwellwerte für Preis und Prognose sowie InfluxDB-Zugang.
Der SENEC-Charger wird über Umgebungsvariablen konfiguriert.
> **HELIOS**
>
>
> HELIOS verwaltet den SENEC-Charger, richtet ihn aber nur ein, wenn die Voraussetzungen stimmen: ein lokal abgefragter SENEC-Speicher (V2.1 oder V3) und ein eingerichteter [Forecast-Collector](/docs/referenz/forecast-collector/). Dann erscheint die preisoptimierte Beladung unter _Konfiguration → Grundeinstellungen → Dynamische Strompreise_, zusammen mit den [Tibber-Preisen](/docs/referenz/tibber-collector/), die sie voraussetzt.
>
## Umgebungsvariablen
### `SENEC_HOST`
Hostname des SENEC-Stromspeichers, üblicherweise eine IP-Adresse im lokalen Netz. Eine lokale Domain geht ebenso.
Hier gehört nur der Host hin, **kein** `http://` oder `https://` und keine Portnummer. Das Protokoll steht getrennt in `SENEC_SCHEMA`. Ergibt beides zusammen keine gültige URL, bricht der Charger beim Start ab.
```properties title="Beispiel"
SENEC_HOST=192.168.1.42
```
> **HELIOS**
>
>
> HELIOS setzt den Hostnamen aus den Angaben zum [SENEC-Collector](/docs/referenz/senec-collector/), abgefragt unter _Konfiguration → Datenquellen → SENEC-Collector_. Charger und Collector teilen sich denselben Wert.
>
### `SENEC_SCHEMA`
Protokoll für die Verbindung zum Stromspeicher, `http` oder `https`. Standardwert ist `https`, denn ein SENEC.Home V3 antwortet ab Werk verschlüsselt.
Ein anderer Wert als `http` oder `https` ergibt keine gültige URL, der Charger bricht dann beim Start ab.
```properties title="Beispiel"
SENEC_SCHEMA=http
```
> **HELIOS**
>
>
> HELIOS setzt das Protokoll aus den Angaben zum [SENEC-Collector](/docs/referenz/senec-collector/), abgefragt unter _Konfiguration → Datenquellen → SENEC-Collector_. Charger und Collector teilen sich denselben Wert.
>
### `CHARGER_INTERVAL`
Abstand zwischen zwei Prüfungen in Sekunden, eine positive Ganzzahl. Standardwert ist `3600`, also eine Stunde.
Bei jeder Prüfung liest der Charger Preise und Prognose aus der InfluxDB und entscheidet über eine Beladung. Ein kürzeres Intervall bringt wenig, denn die Preise stehen für 24 Stunden im Voraus fest. Eine `0` oder ein nicht-numerischer Wert lässt den Charger beim Start abbrechen.
```properties title="Beispiel"
CHARGER_INTERVAL=1800
```
> **HELIOS**
>
>
> HELIOS fragt das Prüfintervall unter _Konfiguration → Grundeinstellungen → Dynamische Strompreise_ ab, vorbelegt mit `3600`.
>
### `CHARGER_PRICE_MAX`
Preisgrenze in Prozent, bezogen auf den Durchschnittspreis der nächsten 24 Stunden. Erlaubt ist eine Ganzzahl größer als `0` und kleiner als `100`, alles andere lässt den Charger beim Start abbrechen. Standardwert ist `70`.
Der Charger sucht das günstigste zusammenhängende Zeitfenster der nächsten 24 Stunden (siehe `CHARGER_PRICE_TIME_RANGE`) und vergleicht dessen Durchschnittspreis mit dem Durchschnitt der gesamten 24 Stunden. Bei `70` gilt der Strom als günstig, sobald das Fenster höchstens 70 % dieses Durchschnitts kostet. Beginnt das Fenster gerade, lädt der Charger. Liegt es später, wartet er darauf. Je kleiner der Wert, desto seltener wird geladen.
```properties title="Beispiel"
CHARGER_PRICE_MAX=60
```
> **HELIOS**
>
>
> HELIOS fragt die Preisgrenze unter _Konfiguration → Grundeinstellungen → Dynamische Strompreise_ ab, vorbelegt mit `70`.
>
### `CHARGER_PRICE_TIME_RANGE`
Länge des Zeitfensters in Stunden, eine positive Ganzzahl. Standardwert ist `4`. Gemeint ist die Zeit, die der Speicher ungefähr für eine volle Beladung braucht, abhängig von seiner Kapazität und der Ladeleistung.
Der Charger legt ein gleitendes Fenster dieser Länge über die nächsten 24 Stunden und sucht darin das günstigste zusammenhängende Zeitfenster. Ein zu langes Fenster verwässert den Preisvorteil, ein zu kurzes endet, bevor der Speicher voll ist. Eine `0` oder ein nicht-numerischer Wert lässt den Charger beim Start abbrechen.
```properties title="Beispiel"
CHARGER_PRICE_TIME_RANGE=3
```
> **HELIOS**
>
>
> HELIOS fragt die Ladedauer unter _Konfiguration → Grundeinstellungen → Dynamische Strompreise_ ab, vorbelegt mit `4`.
>
### `CHARGER_FORECAST_THRESHOLD`
Grenze für den erwarteten PV-Ertrag der nächsten 24 Stunden in kWh, eine positive Ganzzahl. Standardwert ist `20`.
Liegt die Prognose über diesem Wert, lädt der Charger **nicht** aus dem Netz, denn der Speicher füllt sich ohnehin aus der PV-Anlage. Der Wert gehört damit zur Größe der Anlage: Zu hoch gesetzt, verhindert er die Netzbeladung fast immer. Eine `0` oder ein nicht-numerischer Wert lässt den Charger beim Start abbrechen.
```properties title="Beispiel"
CHARGER_FORECAST_THRESHOLD=25
```
> **HELIOS**
>
>
> HELIOS fragt die Prognose-Schwelle unter _Konfiguration → Grundeinstellungen → Dynamische Strompreise_ ab, vorbelegt mit `20`.
>
### `CHARGER_DRY_RUN`
Trockenlauf. Erlaubt sind `true` und `false`, jeder andere Wert gilt als `false`. Standardwert ist `false`.
Bei `true` rechnet und protokolliert der Charger wie sonst auch, rührt den Speicher aber nicht an: Er startet keine Beladung und gibt keine Entladung frei. So lässt sich die Konfiguration beobachten, bevor sie scharf geschaltet wird.
```properties title="Beispiel"
CHARGER_DRY_RUN=true
```
> **HELIOS**
>
>
> HELIOS bietet dafür einen Schalter unter _Konfiguration → Grundeinstellungen → Dynamische Strompreise_, standardmäßig aus.
>
### `INFLUX_HOST`
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`.
```properties title="Beispiel"
INFLUX_HOST=influxdb
```
> **HELIOS**
>
>
> HELIOS setzt den Hostnamen automatisch auf `influxdb`.
>
### `INFLUX_SCHEMA`
Schema für die Verbindung zu InfluxDB, `http` oder `https`. Standardwert ist `http`. Bei einer externen InfluxDB mit TLS gehört hier `https` hin.
```properties title="Beispiel"
INFLUX_SCHEMA=https
```
> **HELIOS**
>
>
> HELIOS setzt das Schema nicht, es bleibt beim Standardwert `http`. Innerhalb des Docker-Netzwerks wird nicht verschlüsselt.
>
### `INFLUX_PORT`
Port für die Verbindung zu InfluxDB, eine Ganzzahl. Standardwert ist `8086`. Bei einer externen, per TLS abgesicherten InfluxDB ist es oft `443`.
```properties title="Beispiel"
INFLUX_PORT=443
```
> **HELIOS**
>
>
> HELIOS setzt den Port nicht, es bleibt beim Standardwert `8086`.
>
### `INFLUX_TOKEN`
Token, mit dem sich der Charger bei InfluxDB anmeldet. Er muss dort existieren und das Recht haben, den angegebenen Bucket zu **lesen**. Mehr braucht der Charger nicht: Er fragt Preise und Prognose ab und schreibt nie etwas zurück.
Passt der Token nicht, weist InfluxDB die Abfragen ab. Der Charger findet dann weder Preise noch Prognose und belädt den Speicher nicht.
```properties title="Beispiel"
INFLUX_TOKEN=my-super-secret-read-token
```
> **HELIOS**
>
>
> HELIOS gibt dem Charger den Lese-Token, siehe [`INFLUX_TOKEN_READ`](/docs/referenz/helios/konfiguration/#influx_token_read). Mehr als Lesen braucht er nicht.
>
### `INFLUX_ORG`
Organisation in InfluxDB, unter der die Messwerte liegen. Eine Organisation ist der Mandant, dem Benutzer, Buckets und Tokens gehören. InfluxDB legt sie [beim ersten Start](/docs/referenz/influxdb/konfiguration/) 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 lässt den Charger ins Leere lesen.
```properties title="Beispiel"
INFLUX_ORG=solectrus
```
> **HELIOS**
>
>
> HELIOS gibt `solectrus` vor, einzustellen gibt es nichts.
>
### `INFLUX_BUCKET`
Bucket in InfluxDB, aus dem der Charger Preise und Prognose liest. Ein Bucket ist das, was anderswo die Datenbank wäre: ein benannter Speicher mit eigener Aufbewahrungsdauer. Auch ihn legt InfluxDB [beim ersten Start](/docs/referenz/influxdb/konfiguration/) an. Eine SOLECTRUS-Installation kommt mit einem einzigen aus, er heißt `solectrus`.
Der Name muss zu dem Bucket passen, in den Tibber- und Forecast-Collector schreiben. Gibt es ihn nicht, lehnt InfluxDB die Abfragen ab.
```properties title="Beispiel"
INFLUX_BUCKET=solectrus
```
> **HELIOS**
>
>
> HELIOS gibt `solectrus` vor, einzustellen gibt es nichts.
>
### `INFLUX_MEASUREMENT_PRICES`
Measurement in InfluxDB, aus dem der Charger die Strompreise liest. Standardwert ist `Prices`.
Es muss dasselbe Measurement sein, in das der [Tibber-Collector](/docs/referenz/tibber-collector/) die Preise schreibt, dort heißt die Variable `INFLUX_MEASUREMENT`. Der Charger liest daraus das Feld `amount`. Passt der Name nicht, findet er keine Preise und belädt den Speicher nie.
```properties title="Beispiel"
INFLUX_MEASUREMENT_PRICES=Prices
```
> **HELIOS**
>
>
> HELIOS setzt das Measurement gemeinsam mit dem [Tibber-Collector](/docs/referenz/tibber-collector/): Es ist der Wert aus _Konfiguration → Grundeinstellungen → Dynamische Strompreise_, vorbelegt mit `Prices`.
>
### `INFLUX_MEASUREMENT_FORECAST`
Measurement in InfluxDB, aus dem der Charger die PV-Prognose liest. Standardwert ist `Forecast`.
Es muss dasselbe Measurement sein, in das der [Forecast-Collector](/docs/referenz/forecast-collector/) die Prognose schreibt. Der Charger liest daraus das Feld `watt` und rechnet daraus den erwarteten Ertrag der nächsten 24 Stunden in kWh aus. Passt der Name nicht, sieht der Charger einen Ertrag von 0 kWh und lädt bei günstigem Strom auch dann, wenn die Sonne scheint.
```properties title="Beispiel"
INFLUX_MEASUREMENT_FORECAST=Forecast
```
> **HELIOS**
>
>
> HELIOS setzt das Measurement auf denselben Wert wie beim [Forecast-Collector](/docs/referenz/forecast-collector/), abgefragt unter _Konfiguration → Datenquellen → Forecast-Collector_, vorbelegt mit `forecast`.
>
### `TZ`
Zeitzone gemäß [Liste](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). Standardwert ist `UTC`.
Sie betrifft die Zeitstempel im Protokoll des Chargers, also auch die Uhrzeiten der geprüften Preisfenster. Auf die Entscheidung selbst wirkt sie sich nicht aus.
```properties title="Beispiel"
TZ=Europe/Berlin
```
> **HELIOS**
>
>
> HELIOS fragt die Zeitzone unter _Konfiguration → Grundeinstellungen → PV-Anlage_ ab, vorbelegt mit `Europe/Berlin`.
>
---
# Methodik des SENEC-Chargers
> Unter welchen Bedingungen der SENEC-Charger den Stromspeicher aus dem Netz belädt und wie er jede Prüfung durchläuft.
Eine Beladung erfolgt unter folgenden Bedingungen, die alle erfüllt sein müssen:
- Der Strompreis ist gerade besonders günstig
- Es ist nur wenig Solarstrom zu erwarten
- Der Speicher ist leer
„Leer" meldet dabei der Speicher selbst über seinen Betriebszustand. Ein bestimmter Prozentwert steckt nicht dahinter.
Ob die Bedingungen erfüllt sind, prüft der Charger in regelmäßigen Abständen (normalerweise stündlich). Im Docker-Log protokolliert und begründet er jede Entscheidung.
Steigt der Ladestand während einer laufenden Beladung seit der letzten Prüfung nicht mehr – in der Regel, weil der Akku voll ist –, gibt der Charger die Entladung wieder frei.
## Flussdiagramm
Jede Prüfung folgt diesem Ablauf:
```mermaid
flowchart
BEGINN --> CHA{Läuft gerade eine Netzbeladung?}
CHA -->|JA| INC{Ladestand erhöht seit letzter Prüfung?}
CHA -->|NEIN| EMPTY{Akku leer?}
INC -->|JA| END1[ENDE]
INC -->|NEIN| STOP[Entladung zulassen!]
EMPTY -->|JA| SUN{Wird es nennenswert Sonnenschein geben?}
EMPTY -->|NEIN| END4[ENDE]
SUN -->|JA| END3[ENDE]
SUN -->|NEIN| CHEAP{Netzstrom günstig?}
CHEAP -->|JA| START[Starte Beladung!]
CHEAP -->|NEIN| END5[ENDE]
```
Geprüft wird dabei nur die Netzbeladung, die der Charger selbst ausgelöst hat. Eine laufende Beladung aus der PV-Anlage zählt hier nicht.
> **Hinweis**
>
>
> Der SENEC-Charger lässt sich auch im Trockenlauf („dry run") betreiben. Er **simuliert** die Entscheidung dann nur, ohne den Speicher zu beladen. Mehr dazu in der [Konfiguration](/docs/referenz/senec-charger/konfiguration/#charger_dry_run) unter `CHARGER_DRY_RUN`.
>
---
# Was ist der SENEC-Collector?
> Der SENEC-Collector liest die Messwerte eines SENEC-Stromspeichers aus und schreibt sie in die InfluxDB – lokal oder über die SENEC-Cloud.
Der **SENEC-Collector** sammelt die Messwerte, die von einem SENEC-Stromspeicher gemeldet werden, und schreibt diese in die InfluxDB.
Der Collector ist kompatibel mit folgenden Stromspeichern:
- SENEC.Home V2.1
- SENEC.Home V3
- SENEC.Home 4
## Betriebsmodi
Grundsätzlich kann der Collector in zwei verschiedenen **Betriebsmodi** eingesetzt werden:
- **Lokal:** Direkter Zugriff auf den SENEC-Stromspeicher über dessen lokale IP-Adresse. Die Daten werden über die `lala.cgi`-Schnittstelle ausgelesen. Möglich ist das beim V2.1 und V3, nicht aber beim Home 4, denn dieser hat keine lokale Schnittstelle. Der Collector liest in kurzem Intervall aus, standardmäßig alle 5 Sekunden.
- **Cloud:** Abholen der Messwerte aus der SENEC-Cloud, über die Schnittstelle, die SENEC für seine Mobil-Apps bereitstellt. Dafür sind die SENEC-Zugangsdaten anzugeben (E-Mail und Passwort). Möglich ist das auch für den Home 4. Neue Werte liefert die Cloud allerdings nur in größeren Abständen: beim Home 4 im 1-Minuten-Takt, beim V2.1 und V3 im 5-Minuten-Takt. Ein kürzeres Abfrageintervall bringt daher nichts, der Collector lässt ohnehin nur mindestens 60 Sekunden zu.
### Vergleich der Betriebsmodi
| | Lokal | Cloud |
| :-------------- | :-------- | :-------- |
| SENEC.Home V2.1 | Ja (5sec) | Ja (5min) |
| SENEC.Home V3 | Ja (5sec) | Ja (5min) |
| SENEC.Home 4 | Nein | Ja (1min) |
Beim V2.1 und V3 sind also beide Betriebsmodi möglich. Über die Cloud läuft SOLECTRUS auch komplett auf einem Cloud-Server, ohne Rechner im lokalen Netzwerk. Dafür kommen die Messwerte nur alle 5 Minuten statt alle 5 Sekunden.
## Erfasste Messwerte
Der Collector schreibt die folgenden Messwerte als _Field_ in das angegebene _Measurement_ der InfluxDB. Einige Messwerte sind nur im lokalen Betrieb verfügbar (also nicht beim Home 4).
In der Cloud hängen vier Felder zusätzlich am Abfragemodus: `case_temp`, `application_version`, `current_state` und `current_state_ok` liefert der Collector nur bei `SENEC_REQUEST_MODE=full`. Beim Home 4 bleiben `current_state` und `current_state_ok` auch dann leer.
| Field | Beschreibung | Lokal | Cloud |
| :---------------------- | :-------------------------------------------- | :---: | :--------: |
| `application_version` | Version der Firmware | Ja | Nur `full` |
| `bat_charge_current` | Batterie-Ladestrom, in A | Ja | Nein |
| `bat_fuel_charge` | Batterie-Ladestand, in % | Ja | Ja |
| `bat_power_minus` | Batterie-Entladeleistung, in W | Ja | Ja |
| `bat_power_plus` | Batterie-Ladeleistung, in W | Ja | Ja |
| `bat_voltage` | Batterie-Spannung, in V | Ja | Nein |
| `case_temp` | Gehäuse-Temperatur, in °C | Ja | Nur `full` |
| `current_state_code` | Aktueller Betriebszustand, als Zahl | Ja | Nein |
| `current_state` | Aktueller Betriebszustand, als Text | Ja | Nur `full` |
| `current_state_ok` | Aktueller Betriebszustand ist OK (Boolean) | Ja | Nur `full` |
| `ev_connected` | Elektroauto verbunden, Ja/Nein | Ja | Ja |
| `grid_power_minus` | Netzeinspeisung, in W | Ja | Ja |
| `grid_power_plus` | Netzbezug, in W | Ja | Ja |
| `house_power` | Hausverbrauch, in W | Ja | Ja |
| `inverter_power` | Erzeugte Leistung des Wechselrichters, in W | Ja | Ja |
| `mpp1_power` | Leistung von Strang 1, in W | Ja | Nein |
| `mpp2_power` | Leistung von Strang 2, in W | Ja | Nein |
| `mpp3_power` | Leistung von Strang 3, in W | Ja | Nein |
| `power_ratio` | Leistungsbegrenzung, in % | Ja | Nein |
| `response_duration` | Dauer der Antwort, in ms | Ja | Nein |
| `wallbox_charge_power` | Wallbox-Ladeleistung, in W | Ja | Ja |
| `wallbox_charge_power0` | Wallbox-Ladeleistung für erste Wallbox, in W | Ja | Nein |
| `wallbox_charge_power1` | Wallbox-Ladeleistung für zweite Wallbox, in W | Ja | Nein |
| `wallbox_charge_power2` | Wallbox-Ladeleistung für dritte Wallbox, in W | Ja | Nein |
| `wallbox_charge_power3` | Wallbox-Ladeleistung für vierte Wallbox, in W | Ja | Nein |
## Logging
Der Collector schreibt ein Protokoll ins Docker-Log, das im Normalfall so aussieht:
```log
SENEC collector for SOLECTRUS, Version v0.21.0, built at 2026-06-01T11:03:23.082Z
https://github.com/solectrus/senec-collector
Copyright (c) 2020-2026 Georg Ledermann, released under the MIT License
Using Ruby 4.0.5 on platform aarch64-linux-musl
Pushing to InfluxDB at http://influxdb:8086, bucket solectrus, measurement SENEC
Wait until InfluxDB is ready ... OK
Pulling from your local SENEC at https://192.168.178.29 every 5 seconds
Getting state names (language: de) from SENEC by parsing source code...
OK, got 99 state names
Got record #1 at 2026-07-14 10:22:29 +0200 within 144 ms, FERNABSCHALTUNG, Inverter 4251 W, House 460 W, Wallbox 0 W
Successfully pushed record #1 to InfluxDB
...
```
Fehler protokolliert der Collector ebenfalls, etwa wenn der Stromspeicher oder die InfluxDB nicht erreichbar ist.
## Quelltext
Der SENEC-Collector ist in Ruby implementiert, der Quelltext ist auf GitHub verfügbar: \
[github.com/solectrus/senec-collector](https://github.com/solectrus/senec-collector)
---
# Konfiguration des SENEC-Collectors
> Umgebungsvariablen des SENEC-Collectors – Betriebsmodus, Zugang zum Stromspeicher oder zur SENEC-Cloud und InfluxDB-Zugang.
Der SENEC-Collector wird über Umgebungsvariablen konfiguriert.
Welche Variablen nötig sind, hängt am Betriebsmodus: `SENEC_ADAPTER=local` fragt den Stromspeicher im Heimnetz ab, `SENEC_ADAPTER=cloud` holt die Messwerte bei `mein-senec.de`. Jeder Modus hat seine eigenen Pflichtvariablen, die des anderen Modus ignoriert der Collector.
## Umgebungsvariablen
### `SENEC_ADAPTER`
Betriebsmodus des Collectors. Erlaubt sind `local` für den direkten Zugriff auf den Stromspeicher und `cloud` für den Abruf über die SENEC-Cloud. Standardwert ist `local`.
Jeder andere Wert bricht den Start ab. Der Home 4 hat keine lokale Schnittstelle, für ihn kommt nur `cloud` in Frage.
```properties title="Beispiel"
SENEC_ADAPTER=cloud
```
> **HELIOS**
>
>
> HELIOS fragt die Zugriffsart unter _Konfiguration → Datenquellen → SENEC-Collector_ ab, vorbelegt mit dem lokalen Zugriff. Bei einem Home 4 entfällt die Frage, HELIOS setzt dann `cloud`.
>
### `SENEC_HOST`
Hostname des SENEC-Stromspeichers, üblicherweise eine IP-Adresse. Pflicht, solange `SENEC_ADAPTER` auf `local` steht. Im Cloud-Modus wird die Variable ignoriert.
Hier gehört nur der Host hin, **kein** `http://` oder `https://`. Das Protokoll steht getrennt in `SENEC_SCHEMA`. Fehlt der Host im lokalen Modus, bricht der Collector beim Start mit einer Fehlermeldung ab.
```properties title="Beispiel"
SENEC_HOST=192.168.178.29
```
> **HELIOS**
>
>
> HELIOS fragt die IP-Adresse unter _Konfiguration → Datenquellen → SENEC-Collector_ ab und prüft auf Knopfdruck, ob das Gerät antwortet. Die Frage erscheint nur beim lokalen Zugriff.
>
### `SENEC_SCHEMA`
Protokoll für die Verbindung zum SENEC-Stromspeicher, `http` oder `https`. Standardwert ist `https`. Im Cloud-Modus wird die Variable ignoriert.
Ältere Geräte sprechen mitunter nur `http`. Passt das Protokoll nicht, kommt keine Verbindung zustande.
```properties title="Beispiel"
SENEC_SCHEMA=http
```
> **HELIOS**
>
>
> HELIOS fragt das Protokoll unter _Konfiguration → Datenquellen → SENEC-Collector_ ab, vorbelegt mit `https`. Die Frage erscheint nur beim lokalen Zugriff.
>
### `SENEC_LANGUAGE`
Sprache der Status-Texte, die der Collector vom Gerät liest. Erlaubt sind `de`, `en` und `it`, andere Sprachen liefert das SENEC-Gerät nicht aus. Standardwert ist `de`. Im Cloud-Modus wird die Variable ignoriert.
Der Collector liest die Namen der Betriebszustände aus der Weboberfläche des Geräts und schreibt sie als `current_state` in die InfluxDB. Die Sprache entscheidet also, in welcher Sprache dieses Feld gefüllt wird.
```properties title="Beispiel"
SENEC_LANGUAGE=en
```
> **HELIOS**
>
>
> HELIOS fragt die Sprache unter _Konfiguration → Datenquellen → SENEC-Collector_ ab, vorbelegt mit Deutsch. Die Frage erscheint nur beim lokalen Zugriff.
>
### `SENEC_USERNAME`
E-Mail-Adresse für die Anmeldung bei `mein-senec.de`. Pflicht, sobald `SENEC_ADAPTER=cloud` gesetzt ist. Im lokalen Modus wird die Variable ignoriert.
Der Collector prüft beim Start, ob der Wert ein `@` enthält, und bricht sonst ab.
```properties title="Beispiel"
SENEC_USERNAME=mail@example.com
```
> **HELIOS**
>
>
> HELIOS fragt die E-Mail-Adresse unter _Konfiguration → Datenquellen → SENEC-Collector_ ab. Die Frage erscheint nur beim Cloud-Zugriff.
>
### `SENEC_PASSWORD`
Passwort für die Anmeldung bei `mein-senec.de`. Pflicht, sobald `SENEC_ADAPTER=cloud` gesetzt ist. Im lokalen Modus wird die Variable ignoriert.
```properties title="Beispiel"
SENEC_PASSWORD=my-secret-password
```
> **HELIOS**
>
>
> HELIOS fragt das Passwort unter _Konfiguration → Datenquellen → SENEC-Collector_ ab. Die Frage erscheint nur beim Cloud-Zugriff.
>
### `SENEC_TOTP_URI`
URI für die Multi-Faktor-Authentifizierung (MFA) bei `mein-senec.de`. Nötig ist sie nur im Cloud-Modus und auch dort nur, wenn das Konto MFA verlangt. Im lokalen Modus wird die Variable ignoriert.
Anzugeben ist der vollständige String in Anführungszeichen. Er muss mit `otpauth://` beginnen und einen `secret`-Parameter enthalten, sonst bricht der Collector beim Start ab. Aus dem QR-Code von SENEC oder dem Eintrag im Google Authenticator lässt sich die URI mit dem [QR Code Secret Decoder](https://marq24.github.io/qr-code-decoder/) ermitteln.
```properties title="Beispiel"
SENEC_TOTP_URI="otpauth://totp/SENEC:mail%40example.com?secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&digits=6&algorithm=SHA1&issuer=SENEC&period=30"
```
> **HELIOS**
>
>
> HELIOS fragt die TOTP-URI unter _Konfiguration → Datenquellen → SENEC-Collector_ ab, als optionales Feld beim Cloud-Zugriff. Ohne Eintrag lässt HELIOS die Variable weg.
>
### `SENEC_SYSTEM_ID`
ID des SENEC-Systems, dessen Messwerte der Collector aus der Cloud holt. Nötig ist sie nur, wenn am Konto mehr als ein System hängt. Im lokalen Modus wird die Variable ignoriert.
Ohne die Variable listet der Collector die verfügbaren IDs im Protokoll auf und verwendet die **erste**. Für eine andere als die erste ID sind drei Schritte nötig:
1. Die Variable leer lassen und den Collector starten.
2. Die gewünschte ID aus dem Protokoll ablesen.
3. Die ID hier eintragen und den Collector neu starten.
```properties title="Beispiel"
SENEC_SYSTEM_ID=12345
```
> **HELIOS**
>
>
> HELIOS fragt die System-ID unter _Konfiguration → Datenquellen → SENEC-Collector_ ab, als optionales Feld beim Cloud-Zugriff. Ohne Eintrag lässt HELIOS die Variable weg.
>
### `SENEC_INTERVAL`
Intervall in Sekunden, in dem der Collector die Messwerte abfragt, eine Ganzzahl. Standardwert ist `5` im lokalen Modus und `60` im Cloud-Modus.
Diese Werte sind zugleich die Untergrenze: Ein kleinerer Wert wird stillschweigend angehoben. Häufigeres Abfragen brächte ohnehin nichts, denn die Cloud liefert neue Werte nur alle 5 Minuten, beim Home 4 jede Minute.
```properties title="Beispiel"
SENEC_INTERVAL=10
```
> **HELIOS**
>
>
> HELIOS fragt das Intervall unter _Konfiguration → Datenquellen → SENEC-Collector_ ab. Vorbelegt ist es passend zum Zugriff: 5 Sekunden lokal, 60 Sekunden beim Home 4 in der Cloud, sonst 300 Sekunden.
>
### `SENEC_IGNORE`
Messwerte, die der Collector **nicht** an InfluxDB sendet. Nötig, wenn ein Messwert aus einer anderen Quelle stammt, etwa die Wallbox-Leistung von einem Shelly. Erlaubt ist eine komma-getrennte Liste von [Feldnamen](/docs/referenz/senec-collector/#erfasste-messwerte) ohne Leerzeichen. Ohne die Variable sendet der Collector alle Messwerte.
Ein unbekannter Feldname bricht den Start ab. Der Collector nennt ihn dann im Protokoll.
```properties title="Beispiel"
SENEC_IGNORE=wallbox_charge_power,grid_power_minus
```
> **HELIOS**
>
>
> HELIOS leitet die Liste selbst ab: Es trägt jedes Feld ein, das ein anderer Collector in dasselbe Measurement schreibt. Einzustellen gibt es nichts.
>
### `SENEC_REQUEST_MODE`
Umfang der Abfrage in der Cloud. Erlaubt sind `minimal` und `full`, jeder andere Wert bricht den Start ab. Standardwert ist `minimal`. Im lokalen Modus wird die Variable ignoriert.
Mit `minimal` fragt der Collector nur einen Endpunkt mit den wichtigsten Feldern ab. Mit `full` holt er zusätzlich `case_temp`, `application_version`, `current_state` und `current_state_ok`. Die letzten beiden liefert der Home 4 allerdings nicht. Das kostet eine zweite Anfrage pro Durchlauf und erzeugt entsprechend mehr Last auf den SENEC-Servern.
```properties title="Beispiel"
SENEC_REQUEST_MODE=full
```
> **HELIOS**
>
>
> HELIOS fragt den Abfragemodus unter _Konfiguration → Datenquellen → SENEC-Collector_ ab, mit den Optionen _Minimal (empfohlen)_ und _Voll_. Die Frage erscheint nur beim Cloud-Zugriff.
>
### `INFLUX_HOST`
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`.
```properties title="Beispiel"
INFLUX_HOST=influxdb
```
> **HELIOS**
>
>
> HELIOS setzt den Hostnamen automatisch: normalerweise `influxdb`, bei aktivem [Ingest-Dienst](/docs/referenz/ingest/) stattdessen `ingest`. Nur bei einer externen InfluxDB fragt HELIOS ihn unter _Konfiguration → Grundeinstellungen → InfluxDB_ ab.
>
### `INFLUX_SCHEMA`
Schema für die Verbindung zu InfluxDB, `http` oder `https`. Standardwert ist `http`. Bei einer externen InfluxDB mit TLS gehört hier `https` hin.
```properties title="Beispiel"
INFLUX_SCHEMA=https
```
> **HELIOS**
>
>
> HELIOS setzt `http`, denn innerhalb des Docker-Netzwerks wird nicht verschlüsselt. Nur bei einer externen InfluxDB fragt HELIOS das Protokoll ab.
>
### `INFLUX_PORT`
Port für die Verbindung zu InfluxDB, eine Ganzzahl. Standardwert ist `8086`. Bei einer externen, per TLS abgesicherten InfluxDB ist es oft `443`.
```properties title="Beispiel"
INFLUX_PORT=443
```
> **HELIOS**
>
>
> HELIOS setzt den Port automatisch: `8086` für InfluxDB, `4567` beim Umweg über den [Ingest-Dienst](/docs/referenz/ingest/). Nur bei einer externen InfluxDB fragt HELIOS ihn ab.
>
### `INFLUX_TOKEN`
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.
```properties title="Beispiel"
INFLUX_TOKEN=my-super-secret-write-token
```
> **HELIOS**
>
>
> HELIOS gibt dem Collector den Schreib-Token, siehe [`INFLUX_TOKEN_WRITE`](/docs/referenz/helios/konfiguration/#influx_token_write). Lese- oder Admin-Zugriff bekommt er nicht.
>
### `INFLUX_ORG`
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](/docs/referenz/influxdb/konfiguration/) 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.
```properties title="Beispiel"
INFLUX_ORG=solectrus
```
> **HELIOS**
>
>
> HELIOS gibt `solectrus` vor, einzustellen gibt es nichts. Nur bei einer externen InfluxDB fragt HELIOS den Namen der vorhandenen Organisation ab.
>
### `INFLUX_BUCKET`
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](/docs/referenz/influxdb/konfiguration/) 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.
```properties title="Beispiel"
INFLUX_BUCKET=solectrus
```
> **HELIOS**
>
>
> HELIOS gibt `solectrus` vor, einzustellen gibt es nichts. Nur bei einer externen InfluxDB fragt HELIOS den Namen des vorhandenen Buckets ab.
>
### `INFLUX_MEASUREMENT`
Measurement in InfluxDB, unter dem die Messwerte des Collectors landen. Standardwert ist `SENEC`.
Der Name muss zu dem passen, den das Dashboard für die SENEC-Sensoren erwartet. Eine nachträgliche Änderung ist heikel: Bereits geschriebene Messwerte bleiben dauerhaft an den alten Namen gebunden.
```properties title="Beispiel"
INFLUX_MEASUREMENT=power_storage
```
> **HELIOS**
>
>
> HELIOS fragt den Namen unter _Konfiguration → Datenquellen → SENEC-Collector_ ab, vorbelegt mit `SENEC`.
>
### `TZ`
Zeitzone gemäß [Liste](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). 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.
```properties title="Beispiel"
TZ=Europe/Rome
```
> **HELIOS**
>
>
> HELIOS fragt die Zeitzone unter _Konfiguration → Grundeinstellungen → PV-Anlage_ ab, vorbelegt mit `Europe/Berlin`.
>
---
# Was ist der Shelly-Collector?
> Der Shelly-Collector liest den Stromverbrauch von Shelly-Geräten aus, lokal oder über die Shelly-Cloud, und schreibt ihn in die InfluxDB.
Der **Shelly-Collector** sammelt den Stromverbrauch, der von einem Shelly-Stromzähler gemessen wird, und schreibt diesen in die InfluxDB.
Der Collector ruft die Messwerte entweder direkt vom Gerät (über die HTTP-Rest-API) oder über die Shelly-Cloud ab. Über die Cloud läuft der Collector auch außerhalb des lokalen Netzwerks, etwa auf einem Cloud-Server.
Unterstützt werden Shelly-Geräte der ersten, zweiten und dritten Generation. Erfolgreich getestet wurden die folgenden Geräte:
- Shelly Pro 3EM
- Shelly Pro EM-50
- Shelly Pro 1PM
- Shelly Pro 4PM
- Shelly 3EM
- Shelly Plus Plug S
- Shelly PM Mini Gen3
- Shelly Plug S (Gen3)
- Shelly Plug 2
- Shelly EM
## Erfasste Messwerte
Der Collector schreibt die folgenden Messwerte als _Field_ in das angegebene _Measurement_ der InfluxDB:
| Field | Beschreibung |
| :------------------ | :----------------------- |
| `power` | Leistung, in W |
| `power_a` | Leistung Phase A, in W |
| `power_b` | Leistung Phase B, in W |
| `power_c` | Leistung Phase C, in W |
| `power_d` | Leistung Kanal 4, in W |
| `temp` | Temperatur, in °C |
| `response_duration` | Dauer der Antwort, in ms |
> **Hinweis**
>
>
> Die Verfügbarkeit einzelner Messwerte hängt vom verwendeten Shelly-Gerät ab. Nicht alle Geräte liefern alle Messwerte.
>
## Logging
Der Collector schreibt ein Protokoll ins Docker-Log, das im Normalfall so aussieht:
```log
Shelly collector for SOLECTRUS, Version v0.13.0, built at 2026-06-19T05:08:20.190Z
https://github.com/solectrus/shelly-collector
Copyright (c) 2024-2026 Georg Ledermann, released under the MIT License
Using Ruby 4.0.5 on platform aarch64-linux-musl
InfluxDB at http://influxdb:8086, bucket solectrus
Device (local, every 5s):
http://192.168.178.83 => Heatpump (no auth)
Wait until InfluxDB is ready ... OK
#1 - 11:44:52, Power 430.9 W, Temperature 46.2 °C (75 ms)
Successfully pushed record #1 to InfluxDB
...
```
Sind mehrere Geräte konfiguriert, listet der Collector sie beim Start alle auf und fasst ihre Messwerte je Durchlauf zusammen.
Fehler protokolliert der Collector ebenfalls, etwa wenn der Shelly oder die InfluxDB nicht erreichbar ist.
## Quelltext
Der Shelly-Collector ist in Ruby implementiert, der Quelltext ist auf GitHub verfügbar: \
[github.com/solectrus/shelly-collector](https://github.com/solectrus/shelly-collector)
---
# Konfiguration des Shelly-Collectors
> Die Umgebungsvariablen des Shelly-Collectors, für den lokalen Zugriff oder den Weg über die Shelly-Cloud, auch für mehrere Geräte gleichzeitig.
Der Shelly-Collector wird über Umgebungsvariablen konfiguriert.
## Lokal oder Cloud
Der Collector erreicht die Geräte auf zwei Wegen. Welcher gilt, entscheidet `SHELLY_CLOUD_SERVER`:
- **Lokal**: Die Variable bleibt leer. Der Collector fragt jedes Gerät direkt im Heimnetz ab, adressiert über `SHELLY_HOST`.
- **Cloud**: Die Variable ist gesetzt. Der Collector holt die Messwerte aus der Shelly-Cloud, adressiert über `SHELLY_DEVICE_ID` und `SHELLY_AUTH_KEY`.
Sind `SHELLY_HOST` und `SHELLY_CLOUD_SERVER` gleichzeitig gesetzt, bricht der Collector beim Start ab. Lokale und Cloud-Geräte lassen sich nicht mischen.
## Mehrere Geräte
Ein einziger Collector bedient alle Shelly-Geräte. Dafür nehmen `SHELLY_HOST` (lokal) bzw. `SHELLY_DEVICE_ID` (Cloud) und `INFLUX_MEASUREMENT` eine Komma-getrennte Liste auf. Jedes Gerät schreibt in sein eigenes Measurement.
```properties title="Beispiel für zwei lokale Geräte"
SHELLY_HOST=192.168.178.5,192.168.178.6
INFLUX_MEASUREMENT=Heatpump,Fridge
```
Geräteabhängige Optionen (`SHELLY_PASSWORD`, `SHELLY_INVERT_POWER`, `INFLUX_MODE`, `INFLUX_POWER_DATA_TYPE`) nehmen entweder einen einzelnen Wert für alle Geräte oder eine gleich lange Komma-getrennte Liste.
Für alle Geräte gemeinsam gelten `SHELLY_INTERVAL`, `SHELLY_CLOUD_SERVER`, `SHELLY_AUTH_KEY` und die InfluxDB-Einstellungen.
## Umgebungsvariablen
### `SHELLY_HOST`
Hostname des Shelly-Geräts. Pflicht beim lokalen Zugriff. Beim Cloud-Zugriff bleibt die Variable leer, dort tritt `SHELLY_DEVICE_ID` an ihre Stelle.
Üblich ist die IP-Adresse, ein lokaler Gerätename tut es auch. Hier gehört nur der Host hin, **kein** `http://` oder `https://` und keine Portnummer.
```properties title="Beispiel"
SHELLY_HOST=192.168.178.5
```
> **HELIOS**
>
>
> HELIOS fragt die Adresse jedes Geräts ab: unter _Konfiguration → Sensoren_ beim zugehörigen Sensor, unter _Konfiguration → Datenquellen → Shelly-Geräte_ bei allen übrigen. Aus diesen Adressen baut HELIOS die Liste. Steht die Verbindungsart auf **Über Shelly Cloud**, lässt HELIOS die Variable weg.
>
### `SHELLY_PASSWORD`
Passwort des Shelly-Geräts. Nötig ist es nur, wenn das Gerät passwortgeschützt ist. Festgelegt wird der Schutz in der Web-Oberfläche des Shelly unter _Settings / Device Settings / Authentication_. Ohne die Variable fragt der Collector das Gerät ohne Zugangsdaten ab.
Der Benutzername steht fest auf `admin`, dafür gibt es keine Variable. Verwendet wird das Passwort nur beim lokalen Zugriff, beim Cloud-Zugriff ignoriert der Collector es.
```properties title="Beispiel"
SHELLY_PASSWORD=my-shelly-password
```
> **HELIOS**
>
>
> HELIOS fragt das Passwort je Gerät ab, zusammen mit dessen Adresse. Bleibt das Feld überall leer, lässt HELIOS die Variable weg.
>
### `SHELLY_CLOUD_SERVER`
Adresse des Shelly-Cloud-Servers, samt `https://`. Pflicht beim Cloud-Zugriff. Beim lokalen Zugriff bleibt die Variable leer.
Sie ist der Schalter zwischen beiden Zugriffsarten: Ist sie gesetzt, holt der Collector die Messwerte aus der Cloud statt aus dem Heimnetz. Welcher Server der richtige ist, steht in der [Shelly-Cloud](https://control.shelly.cloud) unter _Settings / User Settings / Authorization cloud key_. Das Gerät muss dort registriert sein und seine Daten in die Cloud senden.
```properties title="Beispiel"
SHELLY_CLOUD_SERVER=https://shelly-42-eu.shelly.cloud
```
> **HELIOS**
>
>
> HELIOS fragt die Server-URL unter _Konfiguration → Datenquellen → Shelly-Collector_ ab, sobald die Verbindungsart auf **Über Shelly Cloud** steht. Ein Knopf daneben prüft, ob die Cloud antwortet.
>
### `SHELLY_AUTH_KEY`
Schlüssel für den Zugriff auf die Shelly-Cloud. Pflicht beim Cloud-Zugriff. Beim lokalen Zugriff ignoriert der Collector die Variable.
Der Schlüssel muss das Recht haben, die Daten der angegebenen Geräte abzurufen. Erstellen und ablesen lässt er sich in der [Shelly-Cloud](https://control.shelly.cloud) unter _Settings / User Settings / Authorization cloud key / Get Key_.
```properties title="Beispiel"
SHELLY_AUTH_KEY=ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890
```
> **HELIOS**
>
>
> HELIOS fragt den Schlüssel unter _Konfiguration → Datenquellen → Shelly-Collector_ ab, sobald die Verbindungsart auf **Über Shelly Cloud** steht.
>
### `SHELLY_DEVICE_ID`
ID, unter der die Shelly-Cloud das Gerät führt. Pflicht beim Cloud-Zugriff. Beim lokalen Zugriff ignoriert der Collector die Variable, dort adressiert `SHELLY_HOST` das Gerät.
Abzulesen ist die ID in der [Shelly-Cloud](https://control.shelly.cloud) beim jeweiligen Gerät unter _Settings / Device information_.
```properties title="Beispiel"
SHELLY_DEVICE_ID=12345abcdef0
```
> **HELIOS**
>
>
> HELIOS fragt die Cloud-ID jedes Geräts ab: unter _Konfiguration → Sensoren_ beim zugehörigen Sensor, unter _Konfiguration → Datenquellen → Shelly-Geräte_ bei allen übrigen. Steht die Verbindungsart auf **Lokal**, lässt HELIOS die Variable weg.
>
### `SHELLY_INTERVAL`
Abstand zwischen zwei Abfragen in Sekunden, eine Ganzzahl. Standardwert ist `5`, das ergibt eine gute Auflösung. Kleinere Werte als `2` hebt der Collector auf `2` an.
Beim Cloud-Zugriff fragt der Collector bis zu zehn Geräte in einer Anfrage ab. Läuft er in das Rate-Limit der Shelly-Cloud, wartet er und versucht es erneut.
```properties title="Beispiel"
SHELLY_INTERVAL=10
```
> **HELIOS**
>
>
> HELIOS fragt das Intervall unter _Konfiguration → Datenquellen → Shelly-Collector_ ab, vorbelegt mit `5`.
>
### `SHELLY_INVERT_POWER`
Dreht das Vorzeichen der Leistung um, aus negativen Werten werden positive und umgekehrt. Erlaubt sind `true` und `false`, jeder andere Wert gilt als `false`. Standardwert ist `false`. Nötig ist `true`, wenn der Shelly eine Erzeugung misst, etwa an einem Balkonkraftwerk.
Betroffen ist nur das Feld `power`. Die Einzelwerte `power_a` bis `power_d` schreibt der Collector unverändert.
```properties title="Beispiel"
SHELLY_INVERT_POWER=true
```
> **HELIOS**
>
>
> HELIOS bietet dafür je Gerät einen Schalter **Leistung invertieren**, standardmäßig aus. Invertiert kein Gerät, lässt HELIOS die Variable weg.
>
### `INFLUX_HOST`
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`.
```properties title="Beispiel"
INFLUX_HOST=influxdb
```
> **HELIOS**
>
>
> HELIOS setzt den Hostnamen automatisch: normalerweise `influxdb`, bei aktivem [Ingest-Dienst](/docs/referenz/ingest/) stattdessen `ingest`. Nur bei einer externen InfluxDB fragt HELIOS ihn unter _Konfiguration → Grundeinstellungen → InfluxDB_ ab.
>
### `INFLUX_SCHEMA`
Schema für die Verbindung zu InfluxDB, `http` oder `https`. Standardwert ist `http`. Bei einer externen InfluxDB mit TLS gehört hier `https` hin.
```properties title="Beispiel"
INFLUX_SCHEMA=https
```
> **HELIOS**
>
>
> HELIOS setzt `http`, denn innerhalb des Docker-Netzwerks wird nicht verschlüsselt. Nur bei einer externen InfluxDB fragt HELIOS das Protokoll ab.
>
### `INFLUX_PORT`
Port für die Verbindung zu InfluxDB, eine Ganzzahl. Standardwert ist `8086`. Bei einer externen, per TLS abgesicherten InfluxDB ist es oft `443`.
```properties title="Beispiel"
INFLUX_PORT=443
```
> **HELIOS**
>
>
> HELIOS setzt den Port automatisch: `8086` für InfluxDB, `4567` beim Umweg über den [Ingest-Dienst](/docs/referenz/ingest/). Nur bei einer externen InfluxDB fragt HELIOS ihn ab.
>
### `INFLUX_TOKEN`
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.
```properties title="Beispiel"
INFLUX_TOKEN=my-super-secret-write-token
```
> **HELIOS**
>
>
> HELIOS gibt dem Collector den Schreib-Token, siehe [`INFLUX_TOKEN_WRITE`](/docs/referenz/helios/konfiguration/#influx_token_write). Lese- oder Admin-Zugriff bekommt er nicht.
>
### `INFLUX_ORG`
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](/docs/referenz/influxdb/konfiguration/) 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.
```properties title="Beispiel"
INFLUX_ORG=solectrus
```
> **HELIOS**
>
>
> HELIOS gibt `solectrus` vor, einzustellen gibt es nichts. Nur bei einer externen InfluxDB fragt HELIOS den Namen der vorhandenen Organisation ab.
>
### `INFLUX_BUCKET`
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](/docs/referenz/influxdb/konfiguration/) 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.
```properties title="Beispiel"
INFLUX_BUCKET=solectrus
```
> **HELIOS**
>
>
> HELIOS gibt `solectrus` vor, einzustellen gibt es nichts. Nur bei einer externen InfluxDB fragt HELIOS den Namen des vorhandenen Buckets ab.
>
### `INFLUX_MEASUREMENT`
Measurement in InfluxDB, in das der Collector die Messwerte schreibt. Ein Measurement ist das, was anderswo die Tabelle wäre. Standardwert ist `Consumer`.
Bei mehreren Geräten steht hier ein Name je Gerät, in derselben Reihenfolge wie in `SHELLY_HOST` bzw. `SHELLY_DEVICE_ID`. Stimmt die Anzahl nicht überein, bricht der Collector beim Start ab. Mehr dazu unter [Zusätzliche Shelly-Verbrauchszähler](/docs/anleitungen/mehrere-shelly/).
```properties title="Beispiel"
INFLUX_MEASUREMENT=Heatpump
```
> **HELIOS**
>
>
> HELIOS fragt das Measurement je Gerät ab und setzt die Namen zu einer Liste zusammen. Beim Sensor eines benutzerdefinierten Verbrauchers trägt HELIOS es selbst ein.
>
### `INFLUX_MODE`
Bestimmt, welche Messwerte in InfluxDB landen. Erlaubt sind `default` und `essential`, jeder andere Wert lässt den Collector beim Start abbrechen. Standardwert ist `default`.
Im `default`-Modus schreibt der Collector jeden gelesenen Messwert. Im `essential`-Modus schreibt er nur, solange Leistung fließt. Das spart Speicherplatz bei Geräten, die selten laufen, etwa Waschmaschine oder Geschirrspüler. Die Ränder schreibt er trotzdem mit: beim Abschalten einmalig 0 Watt, beim Wiedereinschalten den zuletzt verworfenen 0-Watt-Wert. Die Kurve beginnt und endet damit auf null, und InfluxDB rechnet die Verbrauchsmenge weiterhin richtig aus.
```properties title="Beispiel"
INFLUX_MODE=essential
```
> **HELIOS**
>
>
> HELIOS bietet dafür keine Einstellung. Nur beim Übernehmen einer vorhandenen Installation liest HELIOS einen bereits gesetzten Wert ein und behält ihn bei.
>
### `INFLUX_POWER_DATA_TYPE`
Datentyp der Leistungswerte in InfluxDB. Erlaubt sind `Float` und `Integer`, jeder andere Wert lässt den Collector beim Start abbrechen. Standardwert ist `Float`.
Mit `Integer` speichert der Collector `power` und `power_a` bis `power_d` als Ganzzahlen. Nötig ist das bei der Migration von einem System, das diese Werte bereits als Ganzzahlen abgelegt hat, denn InfluxDB lässt den Datentyp eines Feldes nachträglich nicht mehr ändern.
```properties title="Beispiel"
INFLUX_POWER_DATA_TYPE=Integer
```
> **HELIOS**
>
>
> HELIOS bietet dafür keine Einstellung. Nur beim Übernehmen einer vorhandenen Installation liest HELIOS einen bereits gesetzten Wert ein und behält ihn bei.
>
### `TZ`
Zeitzone gemäß [Liste](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). 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.
```properties title="Beispiel"
TZ=Europe/Berlin
```
> **HELIOS**
>
>
> HELIOS fragt die Zeitzone unter _Konfiguration → Grundeinstellungen → PV-Anlage_ ab, vorbelegt mit `Europe/Berlin`.
>
---
# Was ist der Tibber-Collector?
> Der Tibber-Collector fragt die Strompreise von Tibber ab und schreibt sie viertelstündlich in die InfluxDB. Für die Kostenberechnung dienen sie nicht.
Der **Tibber-Collector** fragt die Strompreise des Anbieters [Tibber](https://tibber.com/) über dessen API ab und schreibt sie in die InfluxDB.
Die erhaltenen Preise können für den [SENEC-Charger](/docs/referenz/senec-charger/) verwendet werden, um einen SENEC-Stromspeicher kostenoptimiert aus dem Netz zu laden.
> **Hinweis**
>
>
> Der Tibber-Collector setzt einen aktiven Vertrag bei Tibber voraus, dazu einen API-Token. Er lässt sich kostenlos auf der Tibber-Website erstellen.
>
> Die Preise werden von SOLECTRUS **nicht** verwendet, um die tatsächlichen Kosten durch den Netzbezug zu berechnen. Dafür gelten allein die im Dashboard hinterlegten [Strompreise](/docs/bedienung/kosten-berechnung/).
>
## Verarbeitete Werte
Der Collector holt die Preise in **Viertelstunden-Auflösung**, für den laufenden Tag und, sobald Tibber sie veröffentlicht, für den Folgetag. Je Viertelstunde schreibt er einen Datenpunkt als _Field_ in das angegebene _Measurement_ der InfluxDB:
- `amount`: Strompreis inklusive Steuern und Abgaben, in der Währung des Tibber-Vertrags
- `level`: Preisstufe, in Textform (`NORMAL`, `CHEAP`, `VERY_CHEAP`, `EXPENSIVE`, `VERY_EXPENSIVE`)
## Logging
Der Collector schreibt ein Protokoll ins Docker-Log, das im Normalfall so aussieht:
```log
Tibber collector for SOLECTRUS, Version v0.4.2, built at 2026-03-22T09:13:32.723Z
https://github.com/solectrus/tibber-collector
Copyright (c) 2023-2026 Georg Ledermann, released under the MIT License
Using Ruby 4.0.2 on platform aarch64-linux-musl
Pulling from https://api.tibber.com/v1-beta/gql every 3600 seconds
Pushing to InfluxDB at http://influxdb:8086, bucket solectrus, measurement prices
#1 - 2026-07-14 10:09:10 +0200
Fetching prices from Tibber ... OK
Pushing prices to InfluxDB ... OK
Sleeping for 3600 seconds ...
...
```
Ist die Tibber-API nicht erreichbar, protokolliert der Collector den Fehler und versucht es im nächsten Durchlauf erneut. Bei einer nicht erreichbaren InfluxDB bricht er dagegen ab. Docker startet den Container daraufhin neu.
## Quelltext
Der Tibber-Collector ist in Ruby implementiert, der Quelltext ist auf GitHub verfügbar: \
[github.com/solectrus/tibber-collector](https://github.com/solectrus/tibber-collector)
---
# Konfiguration des Tibber-Collectors
> Die Umgebungsvariablen des Tibber-Collectors: Access Token für die Tibber-API, Intervall der Abfrage und die Verbindung zur InfluxDB.
Der Tibber-Collector wird über Umgebungsvariablen konfiguriert.
HELIOS richtet ihn unter _Konfiguration → Grundeinstellungen → Dynamische Strompreise_ ein. Dieselbe Eingabemaske steuert auch den [SENEC-Charger](/docs/referenz/senec-charger/), der die Preise nutzt.
## Umgebungsvariablen
### `TIBBER_TOKEN`
Access Token für die Tibber-API. Er lässt sich [auf der Developer-Website von Tibber](https://developer.tibber.com/settings/access-token) 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.
```properties title="Beispiel"
TIBBER_TOKEN=3A77EECF61BD445F47241A5A36202185C35AF3AF58609E19B53F3A8872AD7BE1-1
```
> **HELIOS**
>
>
> HELIOS fragt das Token unter _Konfiguration → Grundeinstellungen → Dynamische Strompreise_ ab, sobald dort die Erfassung eingeschaltet ist.
>
### `TIBBER_INTERVAL`
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.
```properties title="Beispiel"
TIBBER_INTERVAL=7200
```
> **HELIOS**
>
>
> HELIOS setzt das Intervall nicht, es bleibt beim Standardwert `3600`. Ein anderer Wert lässt sich nicht einstellen.
>
### `INFLUX_HOST`
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`.
```properties title="Beispiel"
INFLUX_HOST=influxdb
```
> **HELIOS**
>
>
> HELIOS setzt den Hostnamen automatisch auf `influxdb`. Nur bei einer externen InfluxDB fragt HELIOS ihn unter _Konfiguration → Grundeinstellungen → InfluxDB_ ab.
>
### `INFLUX_SCHEMA`
Schema für die Verbindung zu InfluxDB, `http` oder `https`. Standardwert ist `http`. Bei einer externen InfluxDB mit TLS gehört hier `https` hin.
```properties title="Beispiel"
INFLUX_SCHEMA=https
```
> **HELIOS**
>
>
> HELIOS setzt das Schema nicht, es bleibt beim Standardwert `http`. Innerhalb des Docker-Netzwerks wird nicht verschlüsselt. Nur bei einer externen InfluxDB fragt HELIOS das Protokoll ab.
>
### `INFLUX_PORT`
Port für die Verbindung zu InfluxDB, eine Ganzzahl. Standardwert ist `8086`. Bei einer externen, per TLS abgesicherten InfluxDB ist es oft `443`.
```properties title="Beispiel"
INFLUX_PORT=443
```
> **HELIOS**
>
>
> HELIOS setzt den Port nicht, es bleibt beim Standardwert `8086`. Nur bei einer externen InfluxDB fragt HELIOS ihn ab.
>
### `INFLUX_TOKEN`
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.
```properties title="Beispiel"
INFLUX_TOKEN=my-super-secret-write-token
```
> **HELIOS**
>
>
> HELIOS gibt dem Collector den Schreib-Token, siehe [`INFLUX_TOKEN_WRITE`](/docs/referenz/helios/konfiguration/#influx_token_write). Lese- oder Admin-Zugriff bekommt er nicht.
>
### `INFLUX_ORG`
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](/docs/referenz/influxdb/konfiguration/) 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.
```properties title="Beispiel"
INFLUX_ORG=solectrus
```
> **HELIOS**
>
>
> HELIOS gibt `solectrus` vor, einzustellen gibt es nichts. Nur bei einer externen InfluxDB fragt HELIOS den Namen der vorhandenen Organisation ab.
>
### `INFLUX_BUCKET`
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](/docs/referenz/influxdb/konfiguration/) 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.
```properties title="Beispiel"
INFLUX_BUCKET=solectrus
```
> **HELIOS**
>
>
> HELIOS gibt `solectrus` vor, einzustellen gibt es nichts. Nur bei einer externen InfluxDB fragt HELIOS den Namen des vorhandenen Buckets ab.
>
### `INFLUX_MEASUREMENT`
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](/docs/referenz/senec-charger/) unter `INFLUX_MEASUREMENT_PRICES` liest. Groß- und Kleinschreibung zählt dabei: `prices` und `Prices` sind zwei verschiedene Measurements.
```properties title="Beispiel"
INFLUX_MEASUREMENT=Prices
```
> **HELIOS**
>
>
> HELIOS setzt das Measurement, vorbelegt mit `Prices`. Ändern lässt es sich unter _Konfiguration → Grundeinstellungen → Dynamische Strompreise_. Ein nachträglicher Wechsel ist kaum möglich, denn die bereits geschriebenen Preise bleiben an den alten Namen gebunden.
>
### `TZ`
Zeitzone gemäß [Liste](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). 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.
```properties title="Beispiel"
TZ=Europe/Berlin
```
> **HELIOS**
>
>
> HELIOS fragt die Zeitzone unter _Konfiguration → Grundeinstellungen → PV-Anlage_ ab, vorbelegt mit `Europe/Berlin`.
>
---
# Was ist Watchtower?
> Der Dienst, der neue Versionen der Docker-Images erkennt und einspielt. Warum Docker das nicht von selbst tut und wie HELIOS Watchtower einrichtet.
**Watchtower** hält die Docker-Container von SOLECTRUS auf dem aktuellen Stand.
Nötig ist das, weil Docker ein Image nur einmal herunterlädt und es danach immer wieder verwendet. Auch beim Tag `latest` sieht Docker von sich aus **nicht** nach, ob es inzwischen eine neuere Version gibt. Ohne Zutun läuft eine Installation vom Mai im Dezember noch mit dem Image vom Mai.
Watchtower prüft daher regelmäßig, ob neue Versionen der verwendeten Images vorliegen. Findet es eine, lädt es das Image herunter, stoppt den alten Container und startet ihn mit der neuen Version neu. Watchtower läuft selbst als Container und aktualisiert auch sich selbst.
Bei einer Installation mit [HELIOS](/docs/referenz/helios/) ist Watchtower dabei. Standardmäßig sieht es einmal täglich nach. Ein anderes Intervall bietet HELIOS unter _Konfiguration → Grundeinstellungen → Software-Stand_ an, sobald mindestens ein Dienst auf _Entwicklung_ steht.
## Nur die eigenen Container
Damit Watchtower nicht sämtliche Container auf dem Host anfasst, kennzeichnet HELIOS die Dienste von SOLECTRUS mit dem Label `com.centurylinklabs.watchtower.scope=solectrus`. Watchtower hält nur diese aktuell. Andere Container auf demselben Server bleiben unangetastet.
Das Label bekommen nur die Dienste, die HELIOS selbst erzeugt. Fremde Zusatzdienste, die es beim Übernehmen einer bestehenden Installation unverändert durchreicht, etwa `dozzle`, tragen es nicht. Watchtower aktualisiert sie deshalb nicht.
## Fork statt Original
Das ursprüngliche [Watchtower](https://containrrr.dev/watchtower/) wird nicht mehr gepflegt und funktioniert mit Docker 29+ nicht mehr ohne weiteres. SOLECTRUS verwendet daher den [Fork von Nicholas Fedor](https://github.com/nicholas-fedor/watchtower), also das Image `nickfedor/watchtower`.
> **Ältere Installation?**
>
>
> Wer noch das alte Image `containrrr/watchtower` verwendet, bekommt unter Docker 29 oder höher möglicherweise keine Updates mehr. HELIOS erkennt das und weist unter _Dienste_ auf den Wechsel zum Fork hin.
>
---
# Konfiguration von Watchtower
> Die Umgebungsvariablen von Watchtower für das Prüfintervall, das Scope-Label, das Aufräumen alter Images und die Zeitzone im Protokoll.
Watchtower wird über Umgebungsvariablen konfiguriert.
## Umgebungsvariablen
### `WATCHTOWER_POLL_INTERVAL`
Abstand zwischen zwei Prüfungen auf neue Images, in Sekunden. Standardwert ist `86400`, also einmal am Tag. Der Abstand zählt ab dem Start des Containers.
Zwischen zwei Prüfungen bleibt ein Container auf seiner Version, auch wenn im Registry längst eine neuere liegt.
```properties title="Beispiel"
WATCHTOWER_POLL_INTERVAL=28800
```
> **HELIOS**
>
>
> HELIOS setzt den Wert immer, standardmäßig `86400`. Zur Wahl stellt es ihn erst, wenn mindestens ein Dienst auf _Entwicklung_ steht, unter _Konfiguration → Grundeinstellungen → Software-Stand_. Dort stehen täglich (`86400`), alle 8 Stunden (`28800`) und stündlich (`3600`).
>
### `WATCHTOWER_SCOPE`
Beschränkt Watchtower auf die Container, die das Label `com.centurylinklabs.watchtower.scope` mit genau diesem Wert tragen. Welche Dienste von SOLECTRUS das Label bekommen, steht in der [Übersicht](/docs/referenz/watchtower/). Der Sonderwert `none` kehrt die Auswahl um: Watchtower übergeht dann alle Container, die ein Scope-Label tragen.
Ohne die Variable nimmt sich Watchtower **jeden** Container auf dem Host vor, auch die, die nichts mit SOLECTRUS zu tun haben.
```properties title="Beispiel"
WATCHTOWER_SCOPE=solectrus
```
> **HELIOS**
>
>
> HELIOS gibt `solectrus` vor, einzustellen gibt es nichts.
>
### `WATCHTOWER_CLEANUP`
Entfernt das alte Image, sobald der Container auf die neue Version umgestellt ist. Erlaubt sind `true` und `false`. Standardwert ist `false`.
Ohne die Einstellung bleiben die abgelösten Images liegen und belegen weiter Platz auf der Platte.
```properties title="Beispiel"
WATCHTOWER_CLEANUP=true
```
> **HELIOS**
>
>
> HELIOS setzt `true`, einzustellen gibt es nichts.
>
### `TZ`
Zeitzone gemäß [Liste](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). Standardwert ist `UTC`.
Sie betrifft die Zeitstempel im Protokoll von Watchtower. Auf den Abstand zwischen zwei Prüfungen wirkt sie sich nicht aus, den bestimmt allein `WATCHTOWER_POLL_INTERVAL`.
```properties title="Beispiel"
TZ=Europe/Berlin
```
> **HELIOS**
>
>
> HELIOS fragt die Zeitzone unter _Konfiguration → Grundeinstellungen → PV-Anlage_ ab, vorbelegt mit `Europe/Berlin`.
>
## Weitere Variablen
Watchtower kennt noch etliche Variablen mehr, etwa für Benachrichtigungen bei Updates, private Registries oder eine HTTP-API. HELIOS setzt keine davon, und für den Betrieb von SOLECTRUS braucht es sie nicht.
Wer sie trotzdem nutzen will, findet sie in der Dokumentation des Watchtower-Projekts unter [Configuration → Arguments](https://watchtower.nickfedor.com/latest/configuration/arguments/). Zu beachten ist dabei: HELIOS erzeugt die `compose.yaml` bei jeder Änderung neu und verwirft dabei alles, was es nicht selbst geschrieben hat.
---
# Support
> Support zu SOLECTRUS läuft über GitHub, per Issue oder Diskussion. Was einer Anfrage beizulegen ist und was im Support-Paket von HELIOS steckt.
Diese Dokumentation enthält neben der [Referenz](/docs/referenz/) zu den einzelnen Komponenten auch [Anleitungen](/docs/anleitungen/) zu häufigen Aufgaben und Problemen.
Hilft das nicht weiter, läuft der Support über **GitHub**:
- Bei technischen Problemen und Fehlerberichten ist ein **Issue** anzulegen: \
[https://github.com/solectrus/solectrus/issues](https://github.com/solectrus/solectrus/issues)
- Für alles andere, etwa Fragen zur Installation, Verbesserungsvorschläge oder Kritik, steht der **Diskussionsbereich** zur Verfügung: \
[https://github.com/solectrus/solectrus/discussions](https://github.com/solectrus/solectrus/discussions)
Die Suchfunktion von GitHub findet bestehende Issues und Diskussionen. Oft ist eine Frage dort schon beantwortet.
## Was mitzuschicken ist
Je mehr über die Installation bekannt ist, desto schneller lässt sich helfen. Dafür gibt es das **Support-Paket**, das [HELIOS](/docs/referenz/helios/) unter _Support_ auf Knopfdruck erzeugt: ein ZIP-Archiv mit den Protokollen der Dienste, der Konfiguration und einer Momentaufnahme des Systems.
Passwörter und Tokens ersetzt HELIOS dabei durch Platzhalter.
> **Was im Paket erhalten bleibt**
>
>
> Zwei Dinge werden nur abgeschwächt, nicht entfernt:
>
> - **Koordinaten** behalten ihre Vorkommastellen, die Nachkommastellen werden genullt (`52.51627` wird zu `52.00000`). Der Standort bleibt damit auf rund 100 km eingrenzbar.
> - **Hostnamen** maskiert HELIOS nur, wenn sie öffentlich erreichbar sind. Private IP-Adressen und Namen wie `.local` oder `.fritz.box` bleiben lesbar, damit sich die Netzwerkstruktur nachvollziehen lässt.
>
> Vor dem Anhängen in einem öffentlichen Issue lohnt sich deshalb ein Blick ins Archiv.
>
Genügt ein Ausschnitt, reicht der passende Teil aus dem [Protokoll](/docs/anleitungen/logging/) des betroffenen Dienstes.
> **Keine Support-Anfragen per E-Mail**
>
>
> Support läuft ausschließlich über GitHub. Dort bleiben Frage und Antwort für die Nächsten lesbar, die auf dasselbe Problem stoßen.
>
> Ein GitHub-Konto lässt sich kostenlos anlegen.
>
# Integrationen
---
# SOLECTRUS als Alternative zur SENEC-App
> SOLECTRUS liest deinen SENEC-Stromspeicher aus, lokal oder über die Cloud. Ladestand, PV-Erzeugung, Netzbezug und Verbrauch, live und über Jahre.
Dein SENEC-Speicher misst ständig, wie viel Strom geladen, entladen, erzeugt und verbraucht wird. SOLECTRUS bindet ihn ein und macht diese Messwerte sichtbar. Live und über Jahre, in einem Dashboard, das dir gehört.
## Welche SENEC-Modelle werden unterstützt?
SOLECTRUS unterstützt die gängigen Generationen. Der Weg zu den Daten unterscheidet sich je nach Modell:
- **SENEC.Home V2.1 und V3**: Diese Modelle erlauben **lokalen Zugriff**. Die Messwerte lassen sich direkt vom Gerät im eigenen Netzwerk abholen – schnell und ohne Umweg übers Internet.
- **SENEC.Home 4**: Die aktuelle Generation bietet **keinen lokalen Zugriff**. Der Weg führt über die **SENEC-Cloud**, dieselbe Schnittstelle, die auch die SENEC-App nutzt.
## Lokal oder über die Cloud?
Erlaubt dein Modell lokalen Zugriff, ist das die erste Wahl: unabhängig vom Internet und engmaschiger. Die Werte holt der **SENEC-Collector**, ein kleiner Dienst, der sie abruft und in die Datenbank schreibt. Lokal liest er im **5-Sekunden-Takt**, über die Cloud nur etwa **einmal pro Minute** (V2.1/V3 sogar nur alle 5 Minuten). Lokal kommen außerdem mehr Messwerte an als über die Cloud.
Beim Home 4 führt der Weg über die Cloud. Dafür meldet sich der SENEC-Collector mit denselben Zugangsdaten an, die du auch in der SENEC-App nutzt. Das funktioniert zuverlässig, hängt aber davon ab, dass SENEC seine Schnittstelle stabil hält. Auch hier bleiben deine Daten bei dir: Der SENEC-Collector holt die Werte aus der Cloud und speichert sie lokal in deiner eigenen Installation. Niemand sonst sitzt dazwischen. Auch deine SENEC-Zugangsdaten bleiben lokal auf deinem Gerät und dienen ausschließlich dem Login bei SENEC.
Keine Sorge: Der SENEC-Collector greift nur lesend zu und stört die SENEC-App nicht. Du kannst sie weiter nutzen. Die meisten SOLECTRUS-Nutzer werfen aber nur noch selten einen Blick hinein.
## Welche Daten ausgelesen werden
Nach der Anbindung stehen in SOLECTRUS folgende Messwerte zur Verfügung:
- **PV-Erzeugung** deiner Anlage – beim lokalen Zugriff bis hinunter auf die Leistung einzelner PV-Strings (MPP-Tracker)
- **Ladestand** des Speichers (Prozent) sowie **Lade- und Entladeleistung** in Echtzeit
- **Netzbezug** und **Einspeisung** am Hausanschluss
- **Hausverbrauch** – also der Stromverbrauch deines gesamten Haushalts
- **Wallbox-Ladeleistung**, sofern eine SENEC-Wallbox angebunden ist, sowie ob gerade ein **Fahrzeug angeschlossen** ist
- **Gehäusetemperatur** des Speichers
- beim lokalen Zugriff zusätzlich der **Betriebszustand** des Speichers – ein eigener Status-Sensor zeigt den genauen Zustand aus über hundert möglichen, vom normalen Laden und Entladen bis zu Sonderfällen wie einer Fernabschaltung
- ebenfalls lokal die **Leistungsbegrenzung** – wie stark die Einspeisung gerade gedrosselt wird
Aus diesen Werten berechnet SOLECTRUS Autarkiegrad, Eigenverbrauch, Kosten und Ersparnis. Live und aggregiert über Jahre hinweg.
## So bindest du deinen SENEC-Stromspeicher an
Der **SENEC-Collector** läuft als Teil deiner SOLECTRUS-Installation und fragt den Speicher regelmäßig ab, lokal oder über die Cloud. Im Kern sind es drei Schritte:
1. **SOLECTRUS installieren** – am einfachsten über die [webbasierte Installation](/install/).
2. **Sensoren ergänzen** und dabei den SENEC-Collector als Quelle wählen. Sobald du den ersten SENEC-Sensor hinzufügst, werden die übrigen automatisch mit ergänzt.
3. **SENEC-Collector einstellen** – lokal die IP-Adresse, für die Cloud die Zugangsdaten. Fertig: Die Werte landen ab sofort im Dashboard.
Du brauchst dafür weder Docker-Kenntnisse noch von Hand geschriebene Konfigurationsdateien: Bei der webbasierten Installation richtest du den SENEC-Collector **komplett im Browser** ein – Felder ausfüllen, speichern, fertig.
## Schon in Home Assistant oder ioBroker?
Liegen deine SENEC-Messwerte bereits in einem Smart-Home-System wie [Home Assistant](/integration/home-assistant/) oder [ioBroker](/integration/iobroker/), kannst du sie auch direkt von dort übernehmen. Den SENEC-Collector brauchst du dann gar nicht. Wie das geht, steht im jeweiligen Artikel.
## Deine bisherigen Daten mitnehmen
Du musst nicht bei null anfangen. SENEC stellt deine historischen Messwerte als CSV-Datei zum Download bereit. Nicht in voller Auflösung, aber die zentralen Werte, und das vom Tag der Inbetriebnahme bis heute. Die importierst du einmalig in SOLECTRUS. So hast du deinen Verlauf von Anfang an im Dashboard, statt erst ab der Anbindung Daten zu sammeln. Über die webbasierte Installation läuft der Import ohne Kommandozeile.
## Live-Demo
In der Live-Demo läuft eine echte SOLECTRUS-Instanz mit allen Auswertungen. Angebunden ist dort ein SENEC.Home V3.
> **Aus dem echten Leben**
>
>
> Die Akkus der Demo-Anlage sind [seit Anfang 2026 defekt](https://github.com/orgs/solectrus/discussions/5111) und warten auf den Austausch durch SENEC. Du siehst also live, wie sich ein fernabgeschalteter Speicher in den Daten bemerkbar macht – auch das ist eine Form von Monitoring. Den Status-Sensor habe ich dafür abgeschaltet, deshalb steht im Dashboard schlicht „Live" statt „Fernabschaltung". Und falls jemand bei SENEC mitliest: Ich würde mich über eine baldige Lösung freuen.
>
---
# Shelly anbinden
> SOLECTRUS bindet Shelly-Stromverbrauchszähler nativ ein – lokal oder per Cloud. Leistung und Verbrauch einzelner Verbraucher live und im Langzeitverlauf.
Du willst wissen, was deine Wärmepumpe, die Wallbox oder der Server im Keller zieht? Das messen Shelly-Stromverbrauchszähler. SOLECTRUS bindet sie **nativ** ein, ohne Umweg über ein Smart-Home-System. So siehst du einzelne Verbraucher getrennt, live und über Jahre.
## Welche Shelly-Stromverbrauchszähler passen?
Geeignet sind alle Shelly-Zähler mit **Leistungsmessung**: vom Plug S für die einzelne Steckdose über die PM-Modelle bis zu den Klemmenzählern wie **3EM**, **Pro 3EM** oder **EM**, mit denen du den Hausanschluss dreiphasig misst (Netzbezug und Einspeisung). Unterstützt werden Geräte der **Generationen 1 bis 3**, samt Plus- und Pro-Serie.
Welches Modell du hast, musst du nicht selbst wissen: Das Abfragen übernimmt der **Shelly-Collector**, ein kleiner Dienst, der die Werte vom Gerät abruft und in die Datenbank schreibt. Er **erkennt den Gerätetyp automatisch** und liest die passenden Messwerte aus.
## Lokal oder per Cloud
Auslesen lassen sie sich auf zwei Wegen: **lokal** im eigenen Netzwerk oder über die **Shelly-Cloud**. SOLECTRUS unterstützt beides.
Lokal kommen die Werte direkt vom Gerät: schneller und ohne Cloud-Account. Deine Daten bleiben bei dir zu Hause. Dazu hinterlegst du die IP-Adresse des Geräts. Und es geht engmaschig: Lokal fragt der Shelly-Collector die Werte bis zum **5-Sekunden-Takt** ab, fein genug für eine echte Live-Darstellung.
Über die Cloud erreichst du deine Shellys auch dann, wenn sie nicht im selben Netzwerk hängen. Dafür brauchst du den Cloud-Zugang deines Shelly-Kontos (Auth-Key und Geräte-ID). Auch dann bleiben deine Messwerte bei dir: Der Shelly-Collector holt sie aus der Cloud und speichert sie lokal in deiner eigenen Installation.
## Welche Daten ausgelesen werden
Mit angebundenen Shelly-Zählern stehen in SOLECTRUS folgende Messwerte zur Verfügung:
- die **Momentanleistung** jedes gemessenen Geräts (lokal bis im 5-Sekunden-Takt)
- den daraus berechneten **Verbrauch** über Tage, Monate und Jahre
- einzelne **Verbraucher** getrennt – Wärmepumpe, Wallbox, Server und Co.
- bei dreiphasigen Klemmenzählern wahlweise **eine einzelne Phase (A, B oder C) oder die Gesamtleistung** – ein einziger Zähler kann so gleich mehrere Geräte erfassen, und der Shelly-Collector teilt die Phasen auf einzelne Verbraucher auf
Der Shelly-Zähler liefert die Leistung in Watt. Den Energieverbrauch über die Zeit berechnet SOLECTRUS daraus. So siehst du, was einzelne Verbraucher kosten und wie viel davon aus der PV-Anlage gedeckt wird. Welche Werte genau ankommen, hängt vom jeweiligen Shelly ab.
Der **Shelly-Collector** arbeitet **speichereffizient**: Geräte, die nur sporadisch laufen, etwa Waschmaschine oder Geschirrspüler, erzeugen nur dann Einträge, wenn sie in Betrieb sind. In den langen Ruhezeiten dazwischen wird nichts gespeichert. Das hält die Datenbank schlank, ohne dass dir ein Betriebszyklus entgeht.
Für jeden gemessenen Verbraucher trennt der **Power-Splitter** von SOLECTRUS den Verbrauch automatisch in **PV-Strom und Netzstrom**. Du siehst also nicht nur, wie viel ein Gerät zieht, sondern auch, wie viel davon direkt vom Dach kam und wie viel teuer aus dem Netz. Tagesgenaue, sich ändernde Strompreise rechnet er mit ein.
Bei Bedarf lassen sich die Werte auch **umdrehen** (Vorzeichen invertieren). Praktisch, wenn ein Shelly nicht einen Verbraucher misst, sondern eine Erzeugung – etwa die Einspeisung eines Balkonkraftwerks.
## So bindest du Shelly an
Der **Shelly-Collector** läuft als Teil deiner SOLECTRUS-Installation und fragt alle angebundenen Shelly-Zähler regelmäßig ab, lokal bis im 5-Sekunden-Takt. Im Kern sind es drei Schritte:
1. **SOLECTRUS installieren** – am einfachsten über die [webbasierte Installation](/install/).
2. **Sensoren ergänzen** und dabei den Shelly-Collector als Quelle wählen.
3. **Shelly-Collector einstellen** – lokal die IP-Adresse, für die Cloud Auth-Key und Geräte-ID. Fertig: Die Werte landen ab sofort im Dashboard.
Mehrere Shellys lassen sich parallel anbinden. Du brauchst dafür weder Docker-Kenntnisse noch von Hand geschriebene Konfigurationsdateien: Bei der webbasierten Installation richtest du den Shelly-Collector **komplett im Browser** ein – Felder ausfüllen, speichern, fertig.
## Schon in Home Assistant oder ioBroker?
Liegen deine Shelly-Messwerte bereits in einem Smart-Home-System wie [Home Assistant](/integration/home-assistant/) oder [ioBroker](/integration/iobroker/), kannst du sie auch direkt von dort übernehmen. Den Shelly-Collector brauchst du dann gar nicht. Wie das geht, steht im jeweiligen Artikel.
## Live-Demo
In der Live-Demo siehst du Shelly im Einsatz: Dort wird die **Wärmepumpe** per Shelly gemessen, dazu mehrere **Einzelverbraucher** wie Waschmaschine, Geschirrspüler oder Kühlschrank. Jeder mit eigener Leistung und eigenem PV-Anteil.
---
# PV-Anlage per MQTT anbinden
> Über MQTT lässt sich praktisch jede PV-Anlage und jedes Gerät herstellerunabhängig an SOLECTRUS anbinden. Der Collector abonniert die Topics am Broker.
Dein Wechselrichter, Speicher oder Zähler wird nicht direkt unterstützt? Dann führt **MQTT** zum Ziel: der herstellerunabhängige Weg, über den praktisch jede Anlage und jedes Gerät in SOLECTRUS landet.
MQTT braucht eine zentrale Sammelstelle, den **MQTT-Broker**. Der **MQTT-Collector** von SOLECTRUS verbindet sich mit ihm und abonniert gezielt die Werte, die du auswählst.
## So funktioniert MQTT
MQTT ist ein etabliertes Protokoll aus der Welt des Internet of Things: schlank und in fast jedem Smart-Home-System zu Hause. Im Zentrum steht der **MQTT-Broker**, eine Art Vermittlungsstelle:
- Geräte **veröffentlichen** ihre Messwerte beim Broker, jeweils unter einem frei gewählten Namen, dem **Topic** (publish).
- Andere Teilnehmer **abonnieren** genau diese Topics und bekommen jeden neuen Wert zugestellt (subscribe).
Sender und Empfänger kennen sich nicht. Sie treffen sich nur über den Broker. Genau hier setzt der **MQTT-Collector** von SOLECTRUS an: Er ist ein solcher Abonnent.
## Welcher Broker?
Der **MQTT-Collector** spricht mit jedem MQTT-Broker. Du bist also an keinen bestimmten gebunden. Am häufigsten ist der Broker schlicht Teil deines Smart-Home-Systems:
- **[Home Assistant](/integration/home-assistant/)** bringt mit dem Mosquitto-Add-on einen Broker gleich mit.
- **[ioBroker](/integration/iobroker/)** kann über seinen MQTT-Adapter selbst als Broker dienen.
Sofern dein Smart-Home-System die Werte per MQTT bereitstellt, lassen sich auch Wechselrichter von Herstellern wie Kostal, Fronius, SMA, Sungrow, SolarEdge oder Growatt anbinden, und viele weitere. Die Marken sind nur Beispiele: Was dein Smart-Home-System einliest, lässt sich auch per MQTT weiterreichen.
Einen **eigenständigen Broker** richtest du nur in einem Fall ein: wenn ein Gerät von sich aus MQTT funkt (etwa ein ESP-Projekt wie ESPAltherma, ein Tasmota-Gerät oder mancher Zähler) und du kein Smart-Home-System betreibst, bei dem es seine Werte abladen könnte. Dann genügt ein schlanker **Eclipse Mosquitto** auf einem Raspberry Pi. Hängen deine Quellen nicht alle im selben Netzwerk, übernimmt ein gehosteter Dienst wie **HiveMQ Cloud** die Vermittlung.
Wichtig ist nur eins: dass Quelle und Collector denselben Broker erreichen.
## Was sich übergeben lässt
Der **MQTT-Collector** empfängt beliebige Messwerte – du bestimmst, welche das sind:
- Erzeugung des **Wechselrichters**
- Werte des **Stromspeichers**
- jeder **Zähler** und jeder einzelne **Verbraucher**
- Betriebswerte von Geräten wie **Wärmepumpe** oder **Wallbox**
Der Collector ist flexibel genug für die unterschiedlichsten Quellen:
- **JSON auslesen**: Viele Geräte verpacken mehrere Werte in eine JSON-Nachricht. Der Collector pickt sich gezielt den richtigen heraus – auch aus verschachtelten Strukturen.
- **Rechnen und umrechnen**: Per Formel lassen sich Werte skalieren oder Einheiten anpassen, etwa von Watt auf Kilowatt oder von einem Rohwert auf die tatsächliche Leistung.
- **Vorzeichen trennen**: Ein einziges Topic kann auf zwei Messwerte aufgeteilt werden – zum Beispiel Netzbezug und Einspeisung aus einem Zähler, je nachdem ob der Wert positiv oder negativ ist.
So passt der Collector den ankommenden Datenstrom genau an das an, was SOLECTRUS braucht, ganz gleich, wie die Quelle ihre Werte liefert.
## So richtest du den MQTT-Collector ein
Am einfachsten geht das über die [webbasierte Installation](/install/), der empfohlene Weg ohne Kommandozeile oder von Hand geschriebene Konfigurationsdateien. Der Ablauf:
1. Deine Anlage oder dein Smart-Home-System **veröffentlicht** ihre Messwerte am Broker.
2. Du hinterlegst die Verbindungsdaten deines Brokers und legst je Sensor fest, welches Topic er abonniert und wie der Wert behandelt wird.
3. Der MQTT-Collector abonniert die konfigurierten Topics und schreibt die Werte in die SOLECTRUS-Datenbank – fertig, sie erscheinen im Dashboard.
Die Zuordnungen stellst du komplett im Browser ein, inklusive JSON-Auslesung, Formeln und Vorzeichen-Trennung.
> **Werte müssen laufend gesendet werden**
>
>
> Der Collector verarbeitet nur, was tatsächlich am Broker ankommt. Die Quelle muss ihre Werte daher kontinuierlich veröffentlichen – eine Einstellung wie „nur bei Änderung senden" solltest du deaktivieren, sonst bleiben Lücken im Verlauf.
>
## Live-Demo
In der Live-Demo läuft der MQTT-Collector selbst mit: Er holt die **internen Betriebswerte der Wärmepumpe** ein: Vor- und Rücklauftemperatur, Durchfluss und Warmwassertemperatur. Die Daten stammen von einer **Daikin Altherma**, ausgelesen über das Projekt **ESPAltherma**, das diese Werte abgreift und per MQTT bereitstellt.
Eine Besonderheit zeigt, wozu die Formeln gut sind: Die **erzeugte Wärmeleistung** meldet die Wärmepumpe nicht direkt. Der Collector berechnet sie aus den Rohwerten, kurz gesagt als `Durchfluss × (Vorlauf − Rücklauf) × Wärmekapazität`.
Hier kommen zwei Quellen zusammen: Den **Stromverbrauch** der Wärmepumpe misst dort ein [Shelly](/integration/shelly/), die **erzeugte Wärme** rechnet der MQTT-Collector aus den Temperaturen. Die **Arbeitszahl (COP)** berechnet SOLECTRUS dann selbst aus beiden Werten.
---
# Home Assistant anbinden
> Home Assistant führt deine Messwerte zusammen. Für die dauerhafte Aufbewahrung und ausführliche Energie-Auswertungen über Jahre übernimmt SOLECTRUS die Werte.
[Home Assistant](https://www.home-assistant.io/) ist eine der populärsten Smart-Home-Zentralen: Über unzählige Integrationen bindet es Geräte und Dienste an und führt deren Messwerte an einer Stelle zusammen – Wechselrichter, Speicher, Zähler, Wärmepumpe, Wallbox. Im Automatisieren und Steuern ist Home Assistant richtig stark.
Beim Langzeitverlauf hört der Komfort auf. Verlaufsdaten hält Home Assistant zwar vor, dünnt ältere Werte aber aus. Für die detaillierte Auswertung von Energiedaten über Jahre ist es nicht gebaut. Genau dafür gibt es SOLECTRUS: Du übergibst die Messwerte, SOLECTRUS bewahrt sie dauerhaft auf und wertet sie aus.
## Wo SOLECTRUS ergänzt
Lückenlose Verläufe über Jahre, automatisch berechnete Kennzahlen: dafür ist SOLECTRUS gebaut. Jeder übergebene Messwert wird dauerhaft gespeichert, auf Wunsch über Jahre. Home Assistant steuert dein Zuhause. SOLECTRUS speichert die Werte und wertet sie aus.
## Was SOLECTRUS daraus macht
SOLECTRUS übernimmt die Werte aus Home Assistant und legt sie in einer **InfluxDB-Zeitreihendatenbank** ab, in **voller Auflösung** und auf Wunsch über Jahre. Aus den Rohwerten berechnet SOLECTRUS automatisch **Autarkiegrad, Eigenverbrauch, Kosten und Ersparnis**. Live und aggregiert über Jahre hinweg. Dargestellt wird das in einem Dashboard, das auf Energiedaten zugeschnitten ist. Deine Daten bleiben in deiner eigenen Installation.
Die Kommunikation mit den Geräten bleibt bei Home Assistant. SOLECTRUS bekommt die fertigen Messwerte überreicht.
## Welche Daten du übergeben kannst
Du übergibst alle Sensoren, die SOLECTRUS kennt – also die typischen Energiewerte rund um PV-Anlage, Speicher, Verbrauch und Wärmepumpe. Aus deinen Home-Assistant-Sensoren wählst du die passenden aus und ordnest sie den SOLECTRUS-Werten zu.
## Zwei Wege der Anbindung
Für die Übergabe an SOLECTRUS gibt es zwei Wege. Welcher besser passt, hängt von deinem Setup ab.
### Weg 1: Abruf per MQTT
Home Assistant veröffentlicht die gewünschten Sensorwerte an einen **MQTT-Broker** – das Mosquitto-Add-on bringt einen solchen gleich mit. Der **MQTT-Collector** von SOLECTRUS abonniert die Werte dort und holt sie ab (Pull). Praktisch, wenn du ohnehin schon mit MQTT arbeitest. Das Prinzip dahinter beschreibt der separate Artikel zu [MQTT](/integration/mqtt/).
### Weg 2: Direkt nach InfluxDB
Alternativ schiebt Home Assistant die ausgewählten Werte über die **Home-Assistant-Integration von SOLECTRUS** selbst direkt in die InfluxDB-Datenbank von SOLECTRUS (Push) – ohne Umweg über einen MQTT-Broker. Du wählst aus, welche Sensoren übergeben werden. Installation und Einrichtung beschreibt das [zugehörige Repository](https://github.com/solectrus/ha-integration).
## Live-Demo
Wie die Auswertungen in SOLECTRUS aussehen, zeigt die Live-Demo mit echten Daten – inklusive Langzeitverlauf über Monate und Jahre.
---
# ioBroker anbinden
> ioBroker verbindet deine Geräte und kennt ihre aktuellen Messwerte. SOLECTRUS übernimmt sie und wertet sie live sowie über Jahre aus.
[ioBroker](https://www.iobroker.net/) ist eine offene Smart-Home-Zentrale: Über Adapter werden unzählige Geräte und Dienste angebunden und deren Datenpunkte an einer Stelle zusammengeführt – Wechselrichter, Speicher, Zähler, Wärmepumpe, Wallbox. Stark im Einsammeln und Steuern.
Eine Verlaufsaufzeichnung bringt ioBroker von Haus aus nicht mit: Dort wird für jeden Datenpunkt nur der **aktuelle** Messwert gespeichert. Hier kommt SOLECTRUS ins Spiel.
## Übergabe der Messwerte an SOLECTRUS
SOLECTRUS legt die erhaltenen Messwerte in einer **Zeitreihendatenbank** (InfluxDB) ab und rechnet damit weiter. Aus der Leistung in Watt wird beispielsweise die Energie in Kilowattstunden, summiert über Tage und Jahre. Darauf bauen Kennzahlen wie **Autarkiegrad, Eigenverbrauch, Kosten und Ersparnis** auf.
Die Rollen sind klar verteilt: ioBroker verbindet sich mit den Geräten, wie bisher. SOLECTRUS bekommt permanent die Messwerte überreicht und kümmert sich um den Rest.
## Zwei Wege der Anbindung
Aus deinen ioBroker-Datenpunkten wählst du die passenden aus und ordnest sie den SOLECTRUS-Werten zu: die typischen Leistungswerte rund um PV-Anlage, Speicher, Verbrauch und Wärmepumpe. Für die Übergabe gibt es zwei Wege. Welcher besser passt, hängt von deinem Setup ab.
### Weg 1: Übertragen per MQTT
Aktivierst du in ioBroker den **MQTT-Adapter** (im Broker-Modus), stellt ioBroker die Datenpunkte zur Abholung bereit. Der **MQTT-Collector** von SOLECTRUS abonniert die Werte dort und schreibt sie in die InfluxDB. Praktisch, wenn du ohnehin schon mit MQTT arbeitest. Das Prinzip dahinter beschreibt der separate Artikel zu [MQTT](/integration/mqtt/).
### Weg 2: Direkt nach InfluxDB
Alternativ kann ioBroker die Datenpunkte aber auch selbst direkt in die InfluxDB-Datenbank von SOLECTRUS schreiben, also ohne Umweg über einen MQTT-Broker. Dafür gibt es den Community-Adapter [ioBroker.solectrus-influxdb](https://github.com/patricknitsch/ioBroker.solectrus-influxdb). Du hinterlegst die Zugangsdaten deiner SOLECTRUS-InfluxDB und wählst die Datenpunkte aus, die übertragen werden sollen.
Der Adapter ist ein mächtiges Werkzeug: Er kann die Datenpunkte nicht nur weiterreichen, sondern bei Bedarf auch **umrechnen**. Denn nicht jedes Gerät liefert die Werte so, wie SOLECTRUS sie erwartet. Manche melden die Leistung pro Phase statt als Summe. Andere melden Bezug und Einspeisung als einen vorzeichenbehafteten Wert statt als zwei getrennte Datenpunkte. Für solche Fälle bringt er eine **Formel-Engine** mit: Du addierst Phasen oder trennst positive und negative Anteile, ohne ein Skript zu schreiben. Ein visueller **Formel-Editor** mit Live-Vorschau hilft beim Zusammenbauen.
## Live-Demo
In der Live-Demo siehst du, wie die Werte im Dashboard dargestellt werden und wie der Langzeitverlauf über Monate und Jahre aussieht.
---
# evcc anbinden
> evcc kennt die Energiewerte deines Hauses und veröffentlicht sie per MQTT. SOLECTRUS übernimmt sie und wertet sie live sowie im Langzeitverlauf aus.
[evcc](https://evcc.io/) steuert das PV-optimierte Laden deines E-Autos und kennt dabei eine Menge Energiewerte deines Hauses. Genau diese Werte lassen sich an SOLECTRUS übergeben und dort live sowie über Jahre auswerten.
## evcc als Brücke zu deiner Hardware
Das Schöne daran: evcc spricht von Haus aus mit vielen Wechselrichtern, Speichern, Zählern und Wallboxen – von Kostal über SMA, Fronius und SolarEdge bis Sungrow und etlichen weiteren.
Damit wird evcc quasi zum **Adapterstück** zwischen deiner Hardware und SOLECTRUS: Was evcc ohnehin schon kennt, kannst du direkt weiterreichen. Eine separate Anbindung jedes einzelnen Geräts entfällt.
## Welche Daten du übernehmen kannst
evcc liefert beides: die **Energiebilanz des Hauses** (PV-Erzeugung, Hausverbrauch, Netzbezug und Einspeisung sowie den Stromspeicher) und die **Details rund ums Laden** von Hausakku und E-Auto, etwa Ladeleistung, geladene Energie und (wenn dein Fahrzeug ihn meldet) den Ladestand des Autos.
## So kommen die Werte in SOLECTRUS
evcc gibt seine Werte über **MQTT** weiter. SOLECTRUS holt sie von dort ab. Wie das grundsätzlich funktioniert, beschreibt der Artikel zu [MQTT](/integration/mqtt/).
Eine ausführliche Schritt-für-Schritt-Anleitung speziell für evcc gibt es aus der Community: \
[evcc mit SOLECTRUS verbinden (Howto)](https://github.com/larknafets/howtos/blob/main/solectrus/evcc.md).
## Live-Demo
In der Live-Demo siehst du, wie Anlagen- und Ladewerte im Dashboard zusammenlaufen.
---
# PV-Prognose: Solarertrag der nächsten Tage
> Der erwartete Solarertrag der nächsten Tage in SOLECTRUS, je nach Anbieter bis zu 7 Tage im Voraus. Prognose und echter Ertrag im direkten Vergleich.
Wie viel Strom liefert deine Anlage morgen? Und übermorgen? Die **Ertragsprognose** in SOLECTRUS zeigt es dir – für die kommenden Tage, je nach Anbieter bis zu 7 Tage im Voraus. So planst du deinen Verbrauch nach der Sonne: Wärmepumpe, Wallbox, Waschmaschine oder die Speicherladung wandern in die ertragreichen Stunden, statt teuren Netzstrom zu ziehen.
## Was die Prognose zeigt
SOLECTRUS stellt die erwartete Erzeugung direkt neben den tatsächlichen Ertrag:
- **Prognose für die kommenden Tage** – je nach Anbieter und Tarif bis zu 7 Tage im Voraus
- **mehrere Dachflächen getrennt** – Ost und West laufen nicht in einen Topf, sondern werden einzeln vorhergesagt
- **Prognose und Realität im direkten Vergleich** – Tag für Tag siehst du, wie gut die Vorhersage zur Wirklichkeit passt
So erkennst du auf einen Blick, ob ein ertragreicher Tag bevorsteht und ob sich deine Anlage so verhält, wie sie soll. Bleibt der echte Ertrag dauerhaft hinter der Prognose zurück, ist das oft das erste Anzeichen für Verschattung, Verschmutzung oder einen schwächelnden String.
## Welche Anbieter werden unterstützt?
Die Prognose holt der **Forecast-Collector** ein, ein kleiner Dienst deiner SOLECTRUS-Installation, der die Werte beim Anbieter abruft und in deine Datenbank schreibt. Drei Anbieter stehen zur Wahl:
- **[pvnode](https://pvnode.com/)** – gleicht die Vorhersage per **Nowcast** mit aktuellen Satellitendaten ab, je nach Tarif bis zu alle 10 Minuten statt nur ein- oder zweimal am Tag. So bleibt die kurzfristige Prognose nah an der aktuellen Wetterlage, gerade bei wechselnder Bewölkung. Nebenbei liefert pvnode eine Außentemperatur- und Wetterprognose mit.
- **[Solcast](https://solcast.com/)** – der etablierte Klassiker. Kostenloser Tarif für die private Nutzung, Registrierung vorausgesetzt.
- **[Forecast.Solar](https://forecast.solar/)** – am schnellsten ausprobiert. Ohne Registrierung nutzbar, ebenfalls mit kostenloser Variante.
> **Tarife bei pvnode**
>
>
> pvnode bietet einen kostenlosen Einstieg (**Free**: Prognose für heute und morgen, ein Update am Tag). Die Vorschau über volle 7 Tage gibt es ab dem **Light**-Tarif. Der Nowcast mit 10-Minuten-Updates steckt im **Plus**-Tarif – die genaueste Variante. Dort lässt sich die Prognose zusätzlich anhand deiner echten Ertragsdaten kalibrieren.
>
## So richtest du die Prognose ein
Am einfachsten geht das über die **webbasierte Installation** – komplett im Browser, ohne Kommandozeile und ohne von Hand geschriebene Konfigurationsdateien:
1. **Anbieter wählen** – pvnode, Solcast oder Forecast.Solar.
2. **API-Schlüssel holen** – bei pvnode und Solcast nach einer kostenlosen Registrierung, bei Forecast.Solar optional.
3. **Dachflächen hinterlegen** – bei pvnode und Solcast legst du deine Anlage (eine „Site" mit deinen Dachflächen) direkt beim Anbieter an und trägst im Collector nur deren ID ein; bei Forecast.Solar gibst du Ausrichtung, Neigung und Leistung der Dachflächen direkt im Collector ein. Fertig.
Wann genau abgefragt wird, regelt der Forecast-Collector selbst: Er holt die Daten passend zum Update-Rhythmus deines Anbieters und im Rahmen deines Tarif-Kontingents. Du musst kein Intervall einstellen.
Die genauen Felder je Anbieter stehen in der [Dokumentation des Forecast-Collectors](/docs/referenz/forecast-collector/).
## Live-Demo
In der Live-Demo siehst du die Prognose für mehrere Tage nebeneinander – Vorhersage neben echtem Ertrag. Die Werte stammen dort von **pvnode im Nowcast-Tarif**: Die Prognose wird alle 10 Minuten gegen frische Satellitendaten neu gerechnet, 7 Tage im Voraus, für eine reale 9,24-kWp-Anlage.
# Blog
---
# HELIOS ist angekommen
_2026-07-24_
> HELIOS 1.0 ist da. SOLECTRUS lässt sich jetzt komplett im Browser installieren und konfigurieren. Ohne Docker-Wissen, ohne YAML von Hand.
[Im Mai schrieb ich hier noch](/blog/2026-05-09-helios-ist-unterwegs/): „HELIOS ist unterwegs.“ Jetzt ist er da, der Installateur für SOLECTRUS. **HELIOS 1.0** ist fertig und ab sofort der empfohlene Weg, SOLECTRUS einzurichten und zu betreiben.
## Alles im Browser
Bisher brauchte SOLECTRUS etwas Linux- und Docker-Wissen und die Bereitschaft, in der Kommandozeile YAML-Dateien zu editieren. Ich habe im Laufe der letzten Jahre erfahren, dass das für für viele eine ganz erhebliche Hürde ist. Genau diese fällt jetzt weg. Mit HELIOS vereinfacht sich die Installation und Konfiguration von SOLECTRUS ganz gewaltig.
Ein kleines Skript prüft, ob der Server bereit ist, installiert alles Notwendige und übernimmt auch eine bestehende Installation von SOLECTRUS, liest also deren Konfiguration ein (das war übrigens der wirklich anspruchsvolle Part in der Entwicklung). Beruhigend, falls du SOLECTRUS schon länger nutzt: Du fängst **nicht** von vorne an. Danach öffnest du HELIOS im Browser und machst alles Weitere dort.
## Was HELIOS für dich übernimmt
HELIOS läuft als kleine Web-App neben SOLECTRUS auf demselben Gerät. Ab der Installation bedienst du alles im Browser:
- **Sensoren statt Umgebungsvariablen.** Du wählst aus, welche Sensoren du nutzen willst (PV-Erzeugung, Hausverbrauch, Speicher, Wärmepumpe, Wallbox und etliche mehr) und verbindest sie mit den Datenquellen. Rund 50 Sensoren stehen zur Auswahl. Die aktuellen Messwerte siehst du direkt daneben und prüfst so, ob die Zuordnung stimmt.
- **Datenquellen mit Verbindungstest.** SENEC, Shelly, MQTT oder eine PV-Prognose: HELIOS prüft auf Knopfdruck, ob die Verbindung steht und die Zugangsdaten passen.
- **Dienste im Blick.** Eine Liste zeigt alle Bestandteile mit Status und Version. Per Klick können sie gestartet oder gestoppt werden. Die Protokolle können eingesehen werden, ohne kryptische Befehle.
- **Backup inklusive.** HELIOS sichert die Messwerte sowie die Konfiguration (auch automatisch und regelmäßig) und spielt sie bei Bedarf zurück.
- **Einfache Updates.** Updates für die Datenbanken lassen sich mit einem Klick installieren. Updates für Kollektoren, den Power-Splitter und die sonstigen Bestandteile von SOLECTRUS kommen automatisch. HELIOS selbst hält sich ebenfalls automatisch auf dem aktuellen Stand.
Auch die laufende Pflege wird damit einfacher. Einen neuen Shelly ergänzen, eine Wallbox hinzufügen, einen Sensor umbauen: Du klickst es zusammen, HELIOS schreibt die Konfiguration neu und startet die betroffenen Dienste durch. Von Docker und YAML musst du nichts mehr wissen.
Und wenn es doch mal irgendwo hakt und du nicht weiterkommst, kann HELIOS die wichtigsten Informationen deiner Installation anonymisiert als Zip-Datei zusammenstellen. Damit kannst du im Forum um Hilfe bitten.
Für die Profis unter euch: HELIOS weiß sehr genau, wie SOLECTRUS konfiguriert werden muss. Je nachdem, was man sich in der Web-Oberfläche zusammen geklickt hat, erzeugt HELIOS die passenden Docker-Dateien (`compose.yaml` und `.env`) und startet die Container. Bei jeder Änderung wird die Konfiguration aktualisiert. Wer möchte, kann jederzeit weiterhin sehen, wie die Konfiguration aussieht und was Docker damit macht. HELIOS ist keine Blackbox.
## Deine Daten bleiben zuhause
HELIOS läuft auf deinem eigenen Gerät. Deine Konfiguration und deine Messwerte verlassen dein Zuhause nicht. Das Installationsskript ist vor der Ausführung auf GitHub einsehbar, und der komplette Quellcode von HELIOS liegt offen.
Auf der Hardware-Seite bleibt HELIOS genügsam: etwas RAM für den zusätzlichen Dienst und etwas Speicherplatz auf der Disk. Es läuft auf AMD64 und ARM64, ein Raspberry Pi reicht also weiterhin. Wenn Docker noch nicht vorhanden ist, wird es automatisch installiert.
## An wen richtet sich HELIOS?
Für eine Neuinstallation von SOLECTRUS ist HELIOS die erste Wahl. Aber auch wer SOLECTRUS schon länger nutzt, dem möchte ich HELIOS sehr ans Herz legen. HELIOS modernisiert eine bestehende Installation und behebt viele kleine Unzulänglichkeiten, die sich über die Jahre eingeschlichen haben könnten und die sonst nicht aufgefallen wären.
Es gibt einige seltene Szenarien, in denen HELIOS nicht eingesetzt werden kann, das steht genauer in der [Referenz](/docs/referenz/helios/#was-helios-nicht-kann). HELIOS prüft vor der Übernahme einer bestehenden Installation, ob die Konfiguration kompatibel ist - und stoppt die Übernahme, wenn es nicht passt. In allen anderen Fällen wird ein Backup der bestehenden Konfiguration erstellt, bevor HELIOS übernimmt. So kann man jederzeit wieder zurück, falls man später merkt, dass es doch nicht passen sollte.
## Los geht's!
Wenn du SOLECTRUS neu aufsetzt, führt dich die neue [Installationsseite](/install/) direkt zu HELIOS. Wenn du einen Linux-Server zur Verfügung hast, läuft HELIOS innerhalb weniger Minuten und die Einrichtung von SOLECTRUS kann beginnen.
[Zur Installation ❯](/install/)
Wer es genau wissen möchte: Alle Details zu Diensten, Backup und den einzelnen Einstellungen stehen in der [Referenz zu HELIOS](/docs/referenz/helios/).
## Der Konfigurator geht in Rente
Mit 1.0 löst HELIOS den bisherigen [Konfigurator](https://configurator.solectrus.de/) ab. Der hat jahrelang gute Dienste geleistet, konnte aber nur Bausteine erzeugen, die du danach von Hand weiter pflegen musstest. HELIOS macht beides in einem: Erstinstallation und die laufende Pflege.
## Danke an die Tester
HELIOS konnte entstehen und reifen, weil viele von euch früh mitgemacht haben. Ihr habt mir eure Konfigurationen geschickt, Fehler gemeldet und die rauen Kanten abgeschliffen. Das hat echt geholfen - herzlichen Dank dafür!
Probier HELIOS aus und berichte, wie es bei dir läuft – im [Forum](https://github.com/orgs/solectrus/discussions) lese ich gerne von deinen Erfahrungen.
---
# Version 1.2 räumt die Oberfläche auf
_2026-05-30_
> Neue Menüleiste fürs Smartphone, Hausverbrauch als Tabelle, präzisere Darstellung bei Sensorausfällen und viele weitere Details.
Version 1.2 ist da. Im Mittelpunkt stehen zwei Neuerungen: eine Menüleiste fürs Smartphone und der Hausverbrauch jetzt auch als Tabelle. Dazu kommen viele kleinere Verbesserungen – an der Oberfläche und unter der Haube. Der Überblick:
## Neue Menüleiste für kleine Displays
Auf dem Smartphone war der Weg über das Hauptmenü oft ein Klick zu viel. Mit der neuen Menüleiste am unteren Bildschirmrand wechselst du direkt zwischen den wichtigsten Bereichen – mit dem Daumen, ohne Umwege.
## Hausverbrauch jetzt auch tabellarisch
Die Aufschlüsselung der Verbraucher gab es bisher nur grafisch. Übersichtlich, aber für kleine Verbraucher fehlten oft die genauen Zahlen.
Ein neuer Button (links in der Klammer) schaltet jetzt auf die **Tabellenansicht** um. Alle Verbraucher mit ihren Werten auf einen Blick, perfekt zum Vergleichen. Die Einstellung bleibt gespeichert – wer die Tabelle bevorzugt, sieht sie beim nächsten Mal wieder.
## Diagramme berücksichtigen auch Sensorausfälle
Sensoren fallen schon mal aus – kurz oder länger. Bisher hat SOLECTRUS solche Aussetzer im Diagramm einfach überbrückt. Das sah aufgeräumt aus, war aber irreführend: Aus einer echten Lücke wurde eine glatte Kurve, die so nie gemessen wurde.
Damit ist Schluss. Längere Ausfälle zeigt das Diagramm jetzt als das, was sie sind: eine Lücke. Je nach Gerät unterscheidet SOLECTRUS das sauber von echten Ruhephasen, in denen der Messwert wirklich Null ist.
## Soll-Temperatur des Wasserspeichers
Du hast eine Wärmepumpe? Der neue Sensor `HEATPUMP_TANK_TEMP_SETPOINT` zeigt jetzt die Soll-Temperatur des Wasserspeichers – als gestrichelte Linie direkt im Diagramm. So siehst du auf einen Blick, warum die Wärmepumpe selbst im Sommer arbeitet.
## Die kleineren Dinge
Auch im Detail hat sich einiges getan:
- Live-Diagramme: pulsierende Markierung am rechten Rand bei neuen Messwerten
- Wischgesten auf Touch-Displays: der Inhalt folgt weich dem Finger und federt zurück
- Fortschrittsbalken bei Seitenwechseln erscheint sofort – klare Rückmeldung beim Laden
- Aufschlüsselung mehrerer Wechselrichter jetzt auch in der „Jetzt"-Ansicht
- PV-Prognose nun auch in den Zeiträumen 24 h, 48 h und 72 h sichtbar
- Trend-Anzeige für den Batterieladestand ist wieder da
- Eingabe des Codeworts visuell überarbeitet, passt jetzt zum übrigen Design
## Unter der Haube
Nicht sichtbar, aber genauso wichtig:
- Codewort-Schutz und Admin-Anmeldung an mehreren Stellen gehärtet
- Das Abrufintervall der „Jetzt"-Seite passt sich automatisch an den Rhythmus deiner Sensoren an – das verhindert Fehlkonfigurationen, die ich oft gesehen habe
- Statische Inhalte werden vorkomprimiert ausgeliefert und laden schneller
- Ruby, Rails und unzählige weitere Pakete auf den neuesten Stand gebracht – gut für Sicherheit und Stabilität
- Dazu viele Verbesserungen bei Stabilität, Performance und Fehlerbehandlung
## SOLECTRUS unterstützen
SOLECTRUS ist Open Source und kostenfrei nutzbar. Wenn du SOLECTRUS regelmäßig verwendest, freue ich mich über deine Unterstützung: Mit einem [Sponsoring-Abo](/sponsoring/) ab 5 € im Monat schaltest du alle Features frei und machst die Weiterentwicklung möglich.
---
# HELIOS ist unterwegs
_2026-05-09_
> Ich arbeite an HELIOS, einem Werkzeug zur einfachen Installation und Konfiguration von SOLECTRUS – komplett im Browser.
Hier war es zuletzt etwas ruhiger – und das hatte einen Grund. Ich arbeite an einem ganz neuen Werkzeug, das die Installation von SOLECTRUS erheblich vereinfachen wird.
## Warum das nötig ist
SOLECTRUS einzurichten erfordert heute etwas Linux- und Docker-Wissen und die Bereitschaft, die Kommandozeile zu verwenden. Für viele ist das gut machbar – für andere eine spürbare Hürde, die mehr Zeit kostet als nötig. Bei Support-Anfragen sehe ich das immer wieder.
Das muss einfacher werden. SOLECTRUS sollte für alle zugänglich sein, die ihre PV-Anlage verstehen wollen – nicht nur für die, die nebenbei auch noch Linux-Profi sind. Deshalb habe ich vor einigen Monaten mit der Entwicklung von **HELIOS** begonnen.
## Was HELIOS für dich tun kann
HELIOS ist eine kleine Web-App, die parallel zu SOLECTRUS auf demselben Gerät läuft. Du holst sie dir mit einem einzigen Befehl auf den Server – ab da bedienst du alles im Browser. Vier Dinge übernimmt HELIOS für dich:
- **Es versteht, was du schon hast.** Wenn SOLECTRUS bei dir bereits läuft, liest HELIOS deine bestehende Einrichtung ein – auch dann, wenn die Konfiguration über Jahre gewachsen ist. Du fängst nicht von vorne an.
- **Es denkt in Sensoren, nicht in Variablen.** Im Mittelpunkt stehen die Sensoren, die SOLECTRUS kennt – PV-Erzeugung, Hausverbrauch, Stromspeicher, Wärmepumpe, Wallbox und mehr. Du wählst aus, welche du nutzen willst, und „verdrahtest“ sie in HELIOS mit deiner Anlage. Was du nicht brauchst, lässt du weg. Gleichzeitig siehst du, was möglich ist.
- **Es kümmert sich um den technischen Kram.** Im Hintergrund schreibt HELIOS die Docker-Konfigurationsdateien, die SOLECTRUS braucht – jedes Mal frisch, sobald du etwas änderst. Was bisher Handarbeit war, passiert jetzt beim Klicken.
- **Es zeigt dir, was läuft.** Statt abstrakter Docker-Container, die man bislang nur mit kryptischen Befehlen aufspüren kann, findest du eine übersichtliche Liste aller Bestandteile mit ihrem jeweiligen Status. Du siehst auf einen Blick, was funktioniert und was nicht – und kannst alles mit einem Klick starten, stoppen oder auch Updates durchführen.
Auch die laufende Pflege wird damit einfacher. Einen neuen Shelly ergänzen, einen Sensor umkonfigurieren, eine Wallbox hinzufügen: Du klickst es zusammen, HELIOS macht den Rest. Du musst nicht mehr wissen, welche Umgebungsvariablen zu definieren sind, wie man unfallfrei eine YAML-Datei editiert oder wie man generell mit Docker jongliert.
HELIOS läuft auf deinem eigenen Gerät, deine Konfiguration und deine Messwerte verlassen dadurch dein Zuhause nicht.
## Wo es hingeht
HELIOS ist funktional fast fertig. Erste mutige Tester sind seit ein paar Wochen dabei und melden zurück, dass es schon erstaunlich gut läuft. Hier und da gibt es noch Ecken und Kanten, an denen ich arbeite. Sobald HELIOS stabil ist, wird es den bisherigen [Konfigurator](https://configurator.solectrus.de/) ablösen und der empfohlene Weg sein, SOLECTRUS einzurichten und zu betreiben.
## Du kannst beim Testen helfen
Damit HELIOS am Ende für jedes denkbare Szenario fit ist, teste ich es sehr breitgefächert mit unterschiedlichsten Konfigurationen. Und dabei könntest du mir helfen: Wer mir die Konfiguration seiner bestehenden SOLECTRUS-Instanz zur Verfügung stellen möchte, kann mir dieser gerne per E-Mail an info@solectrus.de zusenden (Passwörter und andere sensible Daten bitte unkenntlich machen). Details dazu finden sich im [Forum-Posting auf GitHub](https://github.com/orgs/solectrus/discussions/5516).
Danke fürs Mitmachen! HELIOS ist unterwegs – ich melde mich wieder, wenn er ankommt.
**Ergänzung 24. Juli 2026:** HELIOS ist angekommen, ich berichte in einem eigenen [Beitrag](/blog/2026-07-24-helios-ist-angekommen/).
---
# Version 1.1 zeigt die Strombilanz im Zeitverlauf
_2026-03-10_
> Die Strombilanz gibt es jetzt als Diagramm über den Tagesverlauf. Woher der Strom kommt und wofür er draufgeht, sichtbar in jedem Moment des Tages.
Genau zwei Monate nach [Version 1.0](/blog/2026-01-10-version-1-0/) erscheint das nächste größere Update. Im Mittelpunkt steht ein neues Diagramm, das die Strombilanz im Zeitverlauf sichtbar macht. Dazu kommen weitere Verbesserungen bei Darstellung und Bedienung.
## Strombilanz als Diagramm
Ein häufig gewünschtes Feature ist die gleichzeitige Darstellung mehrerer Messwerte in einem Diagramm. Das klingt auf den ersten Blick einfach, aber damit allein ist noch nicht viel gewonnen. Entscheidend war, daraus eine Darstellung zu machen, die auch auf einen Blick verständlich ist.
Die Lösung: Die bereits bekannte [Strombilanz](/features/#strombilanz) wird jetzt über den Tagesverlauf als Diagramm dargestellt. Man sieht sofort, woher der Strom kommt und wofür er draufgeht - nicht nur als Summe, sondern in jedem Moment des Tages.
Oberhalb der Zeitachse steht die **Herkunft** des Stroms: PV-Erzeugung, Akku-Entnahme und Netzbezug. Unterhalb sieht man die **Verwendung**: Hausverbrauch, Wärmepumpe, Wallbox, Akku-Beladung und Einspeisung. Die Farben machen sofort sichtbar, wie gut der verfügbare Strom genutzt wird. Beide Hälften zusammen ergeben ein vollständiges Bild der Energieflüsse eines Tages.
Zwei Beispiele zeigen, wie unterschiedlich dieses Diagramm im Alltag aussehen kann:
Das Diagramm gibt es auch für beliebig große Zeiträume, die Darstellung erfolgt dann mit gestapelten Säulen.
## Neue Farbpalette für mehr Kontrast
Gerade im neuen Strombilanz-Diagramm ist eine klare Farbtrennung wichtig. In der bisherigen Farbpalette lagen einige Töne zu nah beieinander. Deshalb gibt es jetzt die neue Palette **Kontrast** mit kräftigeren und besser unterscheidbaren Farben.
Die Einstellung wirkt sich auf alle Sensoren aus. Wer es zurückhaltender mag, bleibt beim Standard.
## Diagramme vergrößern
Per Klick lassen sich jetzt alle Diagramme maximieren. Im Vollbild füllen sie das gesamte Browserfenster aus. Bei Tagesdiagrammen wird auf 1-Minuten-Intervalle umgeschaltet. So werden deutlich mehr Details sichtbar als in der normalen Ansicht.
## Wärmepumpen-Seite neu gestaltet
Hier wurde die Darstellung grundlegend überarbeitet und auf die wichtigsten Informationen konzentriert:
**Arbeitszahl als Ringdiagramm**: Die Zusammensetzung der erzeugten Wärme aus PV-Strom, Netzstrom und dem (meist größten) Anteil der Umgebungswärme wird jetzt als Ringdiagramm ("Donut") dargestellt. Dadurch wird die Arbeitszahl deutlich greifbarer. Eine Arbeitszahl von 4 zeigt zum Beispiel auch visuell, dass _3/4_ der erzeugten Wärme aus der Umgebung stammen und nur _1/4_ aus Strom.
**Stromkosten im Zeitverlauf**: Die Verbrauchskosten der Wärmepumpe werden zusätzlich als Diagramm dargestellt.
Die Kosten für den Stromverbrauch setzen sich aus tatsächlich zu zahlenden Netzbezugskosten sowie den Opportunitätskosten zusammen. Denn auch selbst erzeugter Strom ist nicht kostenlos, wenn er stattdessen eingespeist oder anderweitig genutzt werden könnte.
## Vollbild-Modus für große Displays
Manche nennen es eine [unbezahlbare Verbesserung](https://github.com/orgs/solectrus/discussions/5321#discussioncomment-16002446): Der Vollbild-Modus eignet sich jetzt noch besser für sehr große Bildschirme. Texte und andere Elemente skalieren mit, damit sie auch aus größerer Entfernung gut lesbar bleiben.
## Zeitraum-Auswahl überarbeitet
Relative Zeiträume wie „Letzte 30 Tage“ sind jetzt direkt auswählbar. Das spart Klicks und macht die Bedienung intuitiver.
## Die kleineren Dinge
Neben den großen Neuerungen hat sich auch im Detail einiges getan – hier die Kurzfassung:
- Tagesprognose als schraffierte Fläche auf der Erzeugungs-Seite
- Temperaturprognose mit Min/Max-Balken
- Bessere Tooltips und glattere Kurven in allen Diagrammen
- Gesamtwert für eigene Verbraucher im Kennzahlen-Fenster
- Stabilere Flow-Animation beim Ändern der Fenstergröße
- Sauberer Umgang mit fehlerhaften Sensorwerten
- Kurzes Aufblitzen beim Navigieren zur Hauptseite im Dunkelmodus auf iOS behoben
- Genauere Durchschnittswerte und Prognoseabweichung
- Automatische Auffrischung der Anzeige nach längerer Inaktivität
## SOLECTRUS unterstützen
SOLECTRUS ist Open Source und kostenfrei nutzbar. Einige der neuen Funktionen wie das Strombilanz-Diagramm und die kontrastreiche Farbpalette sind den Sponsoren vorbehalten. Wenn du SOLECTRUS regelmäßig verwendest, freue ich mich über deine Unterstützung: Mit einem [Sponsoring-Abo](/sponsoring/) ab 5 € im Monat schaltest du alle Features frei und machst die Weiterentwicklung möglich.
---
# Version 1.0 ist da!
_2026-01-10_
> Fünf Jahre Entwicklung, jetzt die Eins vor dem Punkt. Version 1.0 bringt die Wärmepumpe mit Arbeitszahl und frei wählbare Zeiträume für jede Auswertung.
Lange hat es gedauert – jetzt ist sie da: Version 1.0. Was vor fünf Jahren als Hobbyprojekt begann, trägt endlich die Eins vor dem Punkt. Fühlt sich gut an.
Steigen wir ein, es gibt einiges zu entdecken!
## Endlich: Die Wärmepumpe im Blick
Du hast eine Wärmepumpe und deren Messwerte über Home Assistant oder ähnliches verfügbar? Dann wird dir die neue Seite gefallen. Erzeugte Wärme, Wasserspeicher- und Außentemperatur – alles auf einen Blick, parallel zu Strombilanz und Hausverbrauch.
Die Darstellung zeigt, woher die Wärme kommt: Strom aus dem Netz, Strom aus PV und – idealerweise der mit Abstand größte Anteil – aus der Umgebung.
Die Arbeitszahl (COP) wird automatisch berechnet – für jeden Zeitraum, den du wählst. Und ja, natürlich gibt's dafür auch eine Top-10.
[Live-Demo ❯](https://demo.solectrus.de/heatpump/heatpump_heating_power/2026-01-01)
## Zeitraum? Du entscheidest.
Das wurde oft gewünscht: freie Zeitraumauswahl, überall. „Letzte 30 Tage", „Letzte 12 Monate" – oder einfach per Kalender einen beliebigen Zeitraum festlegen. Geht jetzt.
## Wo bleibt das Geld?
Kosten, Ersparnis, Einspeisevergütung – bisher nur als Summe sichtbar, jetzt auch als Verlauf über die Zeit. Wer wissen will, wo das Geld hingeht (oder herkommt), wird sich über die neuen Finanzdiagramme freuen:
## Was bringen die nächsten Tage?
Die Prognose zeigt jetzt bis zu eine Woche im Voraus – auf einer eigenen Seite, mit Clear-Sky-Kurve und Temperatur. Praktisch für die Planung.
Neu dabei: [pvnode als Prognose-Anbieter](/blog/2025-11-27-pv-prognose-mit-pvnode/) mit besonders genauen Vorhersagen.
## Trends erkennen
Was lief gut, was eher nicht? Die neuen Trend-Darstellungen helfen beim Einordnen:
- Heatmaps nach Tagen und Monaten – für alle wichtigen Sensoren
- Höchst- und Tiefstwerte sowie Tagesdurchschnitt
- Vergleich mit Vorjahr und Vormonat
- Spezifischer Ertrag (kWh/kWp) zum Anlagenvergleich
## Opportunitätskosten, sauber getrennt
Wer Strom selbst verbraucht statt einzuspeisen, verzichtet auf Vergütung. Diese Opportunitätskosten hat SOLECTRUS schon länger auf dem Schirm – jetzt werden sie klarer visualisiert und sauber von den anderen Kosten getrennt.
So wird gerechnet:
$$
\begin{aligned}
\text{Netzbezugskosten} &= \text{Energiebezug aus dem Netz} \times \text{Arbeitspreis} \\
\text{Opportunitätskosten} &= \text{Eigenverbrauchte Energie} \times \text{Einspeisevergütung} \\
\text{Gesamtkosten} &= \text{Netzbezugskosten} + \text{Opportunitätskosten}
\end{aligned}
$$
## Unter der Haube
Der Code wurde in großen Teilen neu geschrieben. Klingt nach viel Arbeit – war es auch. Aber das Ergebnis: Neue Sensoren und Diagramme lassen sich künftig viel einfacher ergänzen.
Auch bei der Performance hat sich was getan. Viele Berechnungen laufen jetzt direkt in PostgreSQL. Jahresübersichten und Gesamtauswertungen laden spürbar schneller.
Und keine Sorge: Version 1.0 ist vollständig kompatibel zu früheren Versionen. Konfiguration anpassen? Nicht nötig – es sei denn, du willst die neuen Sensoren für Wärmepumpe oder Prognose nutzen.
## Danke!
Ein großes Dankeschön an alle Beta-Tester – euer Feedback war Gold wert. Viel Spaß mit SOLECTRUS 1.0!
## SOLECTRUS unterstützen
SOLECTRUS ist Open Source und kostenfrei nutzbar. Einige der neuen Features wie die Wärmepumpen-Seite, die Trend-Darstellungen sowie die Finanzdiagramme sind jedoch den Sponsoren vorbehalten. Mit einem [Sponsoring-Abo](/sponsoring/) (ab 5 € im Monat) unterstützt du die Weiterentwicklung – und schaltest alle Features frei.
---
# PV-Prognose mit pvnode
_2025-11-27_
> Der Forecast-Collector unterstützt ab sofort pvnode als weiteren Prognose-Anbieter. Für SOLECTRUS-Nutzer gibt es dort ein Einstiegsangebot.
Es gibt Neuigkeiten zur Darstellung des prognostizierten PV-Ertrages: Der [Forecast-Collector](/docs/referenz/forecast-collector/) von SOLECTRUS unterstützt ab sofort [pvnode](https://pvnode.com/) als weiteren Anbieter.
## Was ist pvnode?
**pvnode** ist ein deutsches Startup für PV-Ertragsprognosen und weiterer Analysen rund um Photovoltaikanlagen. Ich verwende deren Dienst selbst seit einigen Monaten und bin sehr zufrieden mit der Genauigkeit der Prognosen. Nun steht pvnode allen SOLECTRUS-Nutzern zur Verfügung.
> **Spezialangebot für SOLECTRUS-Nutzer**
>
>
> Das Unternehmen hinter pvnode hat für SOLECTRUS-Nutzer ein spezielles Angebot geschnürt. Die ersten **40 Interessenten** können den vollen Funktionsumfang zur Abfrage **eines** Standorts im Rahmen eines **Early-Access Paket** für **nur 10€ pro Jahr** erhalten. Bei Interesse bitte [Kontakt aufnehmen mit pvnode](https://www.pvnode.com/contact) und dabei SOLECTRUS erwähnen.
>
> Wie ich höre, sind einige der limitierten Pakete bereits vergeben. Schnell sein lohnt sich!
>
## Demo
In der [Live-Demo von SOLECTRUS](https://demo.solectrus.de/forecast) kann die Prognose eingesehen werden. Die dortige Darstellung mit mehreren Tagen nebeneinander gehört zu den Neuerungen der bevorstehenden Version 1.0 von SOLECTRUS, die sich momentan noch im Beta-Stadium befindet.
## Kostenlose Nutzung
Wer pvnode erst einmal ausprobieren möchte, kann den Dienst in reduziertem Umfang auch kostenlos nutzen. Es gelten dann diese Einschränkungen:
- Prognose nur **für den aktuellen und den folgenden** Tag verfügbar
- Maximal **40 Abfragen pro Monat** möglich
Beim kostenpflichtigen Tarif sind Prognosen für bis zu 7 Tage und bis zu 1.000 Abfragen pro Monat möglich.
## Konfiguration
Die Einrichtung von pvnode in der aktualisierten Version `v0.7` des Forecast-Collectors ist in der [Dokumentation](/docs/referenz/forecast-collector/) beschrieben. Es ist wie üblich ein API-Schlüssel erforderlich, den man nach der Registrierung bei pvnode erhält.
---
# API-Umstellung bei SENEC
_2025-08-03_
> SENEC hat im Juli 2025 seine interne API auf OpenID Connect umgestellt, was für Fremdanbieter wie SOLECTRUS für reichlich Wirbel sorgte.
Im Januar 2024 konnte ich die Anbindung des SENEC-Collectors an die SENEC-App-API [ankündigen](/blog/2024-01-31-unterstuetzung-des-senec-home-4/). Besitzer eines Stromspeichers der aktuellen Generation V4 (z.B. **SENEC.Home P4**) konnten seitdem ihre Messwerte direkt in SOLECTRUS einbinden.
Doch am **21. Juli 2025** [änderte sich die Situation abrupt](https://github.com/solectrus/senec-collector/issues/639): SENEC schaltete die bislang genutzte Schnittstelle ab. Drittanbieter-Software – darunter auch der SENEC-Collector – erhielten nur noch eine Fehlermeldung: `401 - Unauthorized`.
Was folgte, war eine Phase intensiver Analyse und Umstellung. Die gute Nachricht: **Nach einer Woche** war eine Lösung implementiert. SOLECTRUS kann wie gewohnt die aktuellen Messwerte abholen und anzeigen, auch vom **SENEC.Home P4**.
## Rückblick: Wie kommen überhaupt die Messwerte zu SOLECTRUS?
SOLECTRUS unterstützt verschiedene Stromspeicher und Wechselrichter. Bei SENEC gab es bislang zwei verschiedene Wege, um an die Daten zu gelangen:
- **Lokaler Zugriff**: Messwerte werden direkt vom Gerät abgeholt – offline, stabil und schnell. Das unterstützen aber nur ältere Modelle wie der **V2.1 und V3**. Die V4-Familie bietet hingegen **keinen lokalen Zugriff**.
- **Cloud-Zugriff**: Dieser Weg ist nicht offiziell dokumentiert und eigentlich nur für die SENEC-eigene App gedacht. Sie funktionierte dennoch auch für Drittanbieter wie SOLECTRUS – bis vor kurzem.
## Was hat sich technisch geändert?
SENEC setzt seit Ende Juli 2025 beim Cloud-Zugriff auf **OpenID Connect**, ein modernes Authentifizierungsverfahren für Single Sign-On. Es reicht fortan nicht mehr, nur Benutzername und Passwort zu kennen – auch die App selbst muss sich als vertrauenswürdig ausweisen und für den Login ein mehrstufiges Authentifizierungsverfahren durchlaufen.
Diese Umstellung war aus Sicht von SENEC schon aus Sicherheitsgründen sinnvoll: Die bisherige API arbeitete mit sehr langlebigen Access-Tokens, was keineswegs ideal ist. Das neue OpenID Connect-Verfahren verwendet zeitlich begrenzte Tokens, die regelmäßig erneuert werden müssen.
## Die Herausforderung für Drittanbieter
Für die offizielle SENEC-App war das kein Problem, da SENEC die API-Umstellung und App-Anpassung aufeinander abstimmen konnte. Tools wie der SENEC-Collector mussten aber ohne Vorwarnung und ohne Dokumentation umgestellt werden. Dieser Schritt war technisch anspruchsvoll und erforderte ein umfassendes Redesign der Kommunikation mit den Servern von SENEC.
Klar ist natürlich: Die Schnittstelle war und ist nicht offiziell für Drittanbieter vorgesehen. Trotzdem ist diese Anbindung für viele Nutzer, die eine Alternative zur offiziellen App von SENEC haben möchten, ein zentrales Feature.
## Die Lösung: Anpassung an die neue Authentifizierung
Nach intensiver Arbeit unterstützt der SENEC-Collector ab [Version 0.18.0](https://github.com/solectrus/senec-collector/releases/tag/v0.18.0) nun das neue OpenID Connect-Verfahren. Der Zugriff auf aktuelle Messwerte funktioniert wieder – auch für den P4. Wer sich für die technischen Details interessiert, findet im GitHub-Repository meines Ruby-Gems die genaue [Implementierung](https://github.com/solectrus/senec/blob/v0.21.0/lib/senec/cloud/connection.rb).
> **Ergänzung vom 12.08.2025**
>
>
> Mittlerweile werden einzelne SENEC-Nutzer beim Login auf `mein-senec.de` zur Einrichtung einer Multi-Faktor-Authentifizierung (MFA) aufgefordert. Führt man diese durch, ist bei zukünftigen Anmeldungen die Eingabe eines MFA-Tokens notwendig, auch in der SENEC-App und beim SENEC-Collector.
>
> Ich habe daher ein weiteres Update in Form der [Version 0.19.0](https://github.com/solectrus/senec-collector/releases/tag/v0.19.0) nachgeschoben, dass dies unterstützt. Wichtig ist dabei, dass man den initialen QR-Code, den man von SENEC erhält, **sorgfältig aufbewahrt**. Dieser QR-Code (bzw. dessen textlicher Inhalt) ist notwendig, um den SENEC-Collector zu konfigurieren.
>
Essenziell war die Unterstützung von Matthias Marquardt ([@marq24](https://github.com/marq24/)). Von ihm kamen entscheidende Hinweise zur Implementierung der neuen Authentifizierung. Seine [Home-Assistant-Integration](https://github.com/marq24/ha-senec-v3) war der Schlüssel zur Lösung. Vielen Dank dafür!
Wir haben uns übrigens gemeinsam darauf verständigt, dass wir unsere API-Clients offen und transparent gestalten. Das soll heißen, dass wir nicht versuchen, die Zugriffe auf die SENEC-Server zu verschleiern, sondern einen klar identifizierbaren User-Agent verwenden. Für den SENEC-Collector heißt das konkret, dass bei allen Anfragen an die SENEC-API die folgende Information gesendet wird:
```http
User-Agent: SENEC-Collector/0.19.0 (+https://github.com/solectrus/senec-collector)
```
Damit ist klar erkennbar, welcher Client auf die Schnittstelle zugreift - und ermöglicht es SENEC prinzipiell, gezielt zu filtern und unliebsame Clients auszusperren. Das ist ein bewusstes Signal: offenes Visier statt Versteckspiel.
## Mein Standpunkt
In einer idealen Welt gäbe es von SENEC eine offizielle API – offen dokumentiert, stabil, mit Unterstützung für Entwickler. Denn als Betreiber eines Stromspeichers sollte man jederzeit Zugriff auf die **eigenen** Messwerte haben – nicht nur per App, sondern auch über offene Schnittstellen, die Drittanbieter in alternative Software integrieren können.
Nur zur Klarstellung: SENEC ist hier beileibe nicht der einzige Hersteller, der ganz auf die eigene App setzt und seinen Nutzern keinen anderen Weg anbietet, an die Messwerte heranzukommen. Das ist leider ein weit verbreitetes Problem in der Branche. Wer schon mal versucht hat, automatisiert an die Messwerte seiner Wärmepumpe oder seines E-Autos zu kommen, weiß, wovon ich spreche.
Falls SENEC künftig einen offiziellen API-Zugang anbieten sollte, implementiere ich das für SOLECTRUS sehr gerne. Bis dahin gilt: Auf inoffiziellem Weg steht die Verbindung wieder.
---
# Balkonkraftwerke und mehrere Dachflächen
_2025-06-05_
> Bis zu fünf Strings oder Wechselrichter, jeder einzeln ausgewertet und in der Summe. Auch ein zusätzliches Balkonkraftwerk ist dabei.
SOLECTRUS `v0.20` ist da: Es können jetzt PV-Anlagen mit mehreren Dachflächen, unterschiedlichen Wechselrichtern und zusätzlichen Balkonkraftwerken dargestellt werden.
## Mehrere Erzeuger auf einen Blick
Bis zu fünf Strings oder Wechselrichter lassen sich konfigurieren. Jeder wird separat angezeigt, dazu gibt es eine Gesamtsumme.
Wie das eingerichtet wird, ist in der [Dokumentation](/docs/anleitungen/multiple-erzeuger/) beschrieben.
## Hausverbrauch korrekt berechnen
Betreibst du ein Balkonkraftwerk ("Steckersolargerät") **zusätzlich** zu einer Dachanlage, ergibt sich eine Besonderheit: Der Strom aus dem Balkonkraftwerk fließt direkt ins Hausnetz. Der Wechselrichter der Dachanlage misst bzw. berechnet dadurch einen zu geringen Hausverbrauch. SOLECTRUS kann das korrigieren und den **tatsächlichen** Hausverbrauch darstellen.
Die hierfür notwendigen Konfigurationsschritte finden sich ebenfalls in der [Dokumentation](/docs/referenz/ingest/).
---
> **Exklusiv für Sponsoren**
>
>
> Die Darstellung mehrerer Erzeuger ist [Sponsoren](/sponsoring/) vorbehalten. Für 5 € im Monat hilfst du, SOLECTRUS weiterzuentwickeln und erhältst Zugriff auf diese Funktion.
>
---
# Photovoltaik-Visualisierung im Ladenlokal
_2025-06-02_
> Andre Holtfreter zeigt die Erträge seiner Photovoltaik-Anlagen auf großen Displays im Verkaufsraum von EP: Bölsche in Berlin. Ein Erfahrungsbericht.
**EP: Bölsche** in Berlin-Friedrichshagen am Müggelsee ist ein inhabergeführtes Elektrofachgeschäft für Haus- und Unterhaltungselektronik mit 7 Angestellten. Das Geschäft existiert bereits seit 1990 und wurde von mir 2021 übernommen.
## Von der kleinen PV-Anlage zum smarten Dashboard: Wie aus Energiebedarf ein echtes Hobby wurde
Was als kleine Photovoltaikanlage auf dem eigenen Dach begann, entwickelte sich in wenigen Jahren zu einem echten Herzensprojekt – für mich privat und für uns als Team bei EP: Bölsche.
Im Jahr 2021 habe ich meine erste kleine private PV-Anlage mit 15 Modulen auf dem Hausdach installiert. Damals war das Thema Energiekrise bereits präsent – und mit jedem Tag wuchs das Bedürfnis nach mehr Unabhängigkeit und Autarkie. Die wachsende Begeisterung für Photovoltaik übertrug sich schnell auf meinen Arbeitsalltag – und auch auf mein Umfeld. Ein Jahr später rüstete ich unsere Geschäftsräume mit einer eigenen Anlage aus.
Parallel dazu suchte ich nach einer Möglichkeit, die aktuellen Erträge nicht nur technisch auszulesen, sondern ansprechend darzustellen – idealerweise in Echtzeit und für Kunden sichtbar. Die Originalsoftware des Herstellers SENEC war hier keine große Hilfe: Die Aktualisierung erfolgte nur im 5-Minuten-Takt, die Oberfläche war eher nüchtern als einladend.
## SOLECTRUS: Echtzeit-Visualisierung, die begeistert
Bei meiner Recherche stieß ich auf SOLECTRUS, ein Open-Source-Projekt, das genau dieses Problem löst: Es visualisiert die Daten von (nicht nur) SENEC-Anlagen in Echtzeit, übersichtlich, modern und intuitiv – direkt auf dem Smartphone, Tablet oder einem Display im Verkaufsraum.
Schnell war klar: Das ist nicht nur ein nützliches Tool, sondern eine echte Bereicherung. Mein Kollege installierte SOLECTRUS ebenfalls auf seiner privaten Anlage, und wir nahmen Kontakt zum Entwicklerteam auf. Seitdem stehen wir im regelmäßigen Austausch und haben bereits einige praxisnahe Erweiterungen gemeinsam angestoßen.
## Photovoltaik – erst Energiequelle, dann Leidenschaft
Was ursprünglich als Beitrag zur Energiewende gedacht war, wurde für mich privat zu einem echten Hobby. In den letzten drei Jahren habe ich meine Anlage mehrfach erweitert:
- von 15 auf 23 Module auf dem Hausdach
- zusätzlich 12 Module auf dem Carport
- und zuletzt 8 weitere Module entlang eines neuen Gartenzauns, um auch den Pool mit Pumpe und Heizung solar zu versorgen.
## Photovoltaik bei EP: Bölsche Frikom – jetzt auch für unsere Kunden
Diese persönliche Begeisterung spiegelt sich inzwischen auch in unserem Geschäft wider. Seit über einem Jahr bieten wir bei EP: Bölsche auch Photovoltaik-Dienstleistungen an. Unser Portfolio umfasst:
- Balkonkraftwerke und Zubehör
- Beratung zu Eigenverbrauch und Erweiterungen
- Vermittlung qualifizierter Installationsbetriebe (auch Partner der Firma SENEC)
- Unterstützung bei der Einrichtung von Visualisierungssoftware wie SOLECTRUS
Was aus einem ganz persönlichen Wunsch nach mehr Unabhängigkeit entstand, ist heute ein fester Bestandteil unseres Unternehmens geworden. Und wir sind gespannt, wohin die Reise mit Photovoltaik und smarter Energie noch führt.
**EP: Bölsche Frikom GmbH** \
Bölschestr. 115 \
12587 Berlin \
[www.ep-boelsche.de](https://www.ep-boelsche.de)
---
# Selbstdefinierte Verbraucher
_2025-03-11_
> Version 0.19 teilt den Hausverbrauch auf einzelne Verbraucher auf. Wärmepumpe oder Wallbox bekommen damit ihre eigene Auswertung.
Nach einer intensiven Entwicklungsphase steht nun Version `0.19` von SOLECTRUS bereit. Wichtigste Neuerung ist die Integration **selbstdefinierter Verbraucher**.
Während bisher die **Erzeugung** von Strom im Vordergrund stand, bietet die neue Version Analysemöglichkeiten für den **Verbrauch** des Stroms. Diese Funktion gehört zu den am häufigsten gewünschten Erweiterungen und wurde ausführlich von der Community im [Beta-Test](https://github.com/orgs/solectrus/discussions/3749) erprobt.
## Aufteilen des Hausverbrauches
Der Hausverbrauch setzt sich aus vielen Einzelverbräuchen zusammen. Mit separaten Stromzählern (z.B. von Shelly) lassen sich diese Einzelwerte erfassen.
Bis zu 20 Geräte können via [MQTT](/docs/referenz/mqtt-collector/) oder dem [Shelly-Collector](/docs/referenz/shelly-collector/) in SOLECTRUS eingebunden werden. Vorzugsweise betrachtet man größere Verbraucher wie Geschirrspüler, Waschmaschine, Trockner, Kühlschrank, Sauna usw. Diese werden anschließend übersichtlich auf einer neuen Seite mit Diagrammen und Statistiken dargestellt. Es wird ersichtlich, wie der Verbrauch im Verhältnis zum Gesamtverbrauch des Hauses steht.
Mit dem [Power-Splitter](/features/#power-splitter) berechnet SOLECTRUS außerdem für jeden Verbraucher den Anteil des „grünen“ (also selbst erzeugten) Stroms.
[Demo ❯](https://demo.solectrus.de/house/custom_power_02/2025-W02)
Optional können ausgewählte Verbraucher direkt in der Strombilanz sichtbar gemacht werden. Deren Verbrauch wird dann aus dem Hausverbrauch herausgerechnet.
Die Konfiguration von SOLECTRUS muss um neue Sensoren erweitert werden. Eine Anleitung ist in der [Dokumentation](/docs/referenz/dashboard/sensor-konfiguration/) verfügbar.
> **Exklusiv für Sponsoren**
>
>
> Dieses Feature steht exklusiv den [Sponsoren](/sponsoring/) zur Verfügung. Mit €5 im Monat unterstützt du aktiv die Weiterentwicklung von SOLECTRUS und erhältst Zugang zu exklusiven Funktionen.
>
## Weitere Neuerungen
- Die Tageszusammenfassungen (eingeführt in [v0.18](/blog/2024-11-10-version-0-18/)) wurden grundlegend überarbeitet und werden jetzt effizienter verwaltet. Nach Installation des Updates erfolgt einmalig eine Neuberechnung.
- Die Diagramme wurden im Detail weiter verbessert. So passt sich die Skalierung besser an die Werte an und es gibt ein Fadenkreuz, das genauer die Position anzeigt, wenn man mit der Maus über das Diagramm fährt.
- Die Hauptnavigation wurde neu gestaltet und verwendet nun Icons statt Text.
- Der Power-Splitter wurde präzisiert und es erfolgt eine tages-bezogene Anpassung für exaktere Ergebnisse.
- Zusätzlich enthält das Update wie immer zahlreiche Fehlerkorrekturen und Optimierungen ‐ ermöglicht durch hilfreiches Feedback aus der Community, für das ich sehr dankbar bin!
---
# Mehr Performance durch Tageszusammenfassungen
_2024-11-10_
> Ein Klick auf GESAMT dauerte schon mal 20 Sekunden. Version 0.18 rechnet mit Tageszusammenfassungen und antwortet in Sekundenbruchteilen.
Dank der Unterstützung durch die Sponsoren war es möglich, in den letzten Wochen eine Verbesserung zu entwickeln, die mir ganz besonders am Herzen lag. Im Gegensatz zu den bisherigen Arbeiten ist das Ergebnis diesmal zwar kaum sichtbar, aber dafür deutlich zu spüren.
Es geht um die **Performance** der Benutzeroberfläche. Je nach angesammelter Datenmenge und Leistungsfähigkeit des eingesetzten Servers konnte SOLECTRUS in der Vergangenheit etwas träge reagiert haben, insbesondere wenn es um die Auswertung längerer Zeiträume ging.
Hast du in deiner SOLECTRUS-Installation schon mal auf "GESAMT" geklickt? Dann weißt du vielleicht, dass das Ergebnis manchmal auf sich warten ließ. 20 Sekunden und mehr waren keine Seltenheit. Das ist jetzt Geschichte. Mit der heute veröffentlichten Version `0.18` wurde die Reaktionsgeschwindigkeit der Benutzeroberfläche erheblich verbessert, die Darstellung beliebiger Zeiträume erfolgt jetzt in Sekundenbruchteilen.
## Tageszusammenfassungen
Die Idee dahinter: SOLECTRUS erstellt nun für jeden Tag eine sogenannte „Tageszusammenfassung“. Diese enthält die Messwerte des jeweiligen Tages in aggregierter Form, wie z.B. die insgesamt erzeugte Energie, den Tagesverbrauch einzelner Geräte, den minimalen und maximalen Ladestand des Akkus und vieles mehr. Diese Zusammenfassungen werden in der Datenbank abgelegt und für alle Zeitraumauswertungen herangezogen, was eine blitzschnelle Darstellung ermöglicht.
Ein willkommener Nebeneffekt ist, dass einige manchmal auftretende Ungenauigkeiten in den Zahlen nun der Vergangenheit angehören.
> **Zu beachten:**
>
>
> Die Tageszusammenfassungen werden automatisch und kontinuierlich erstellt. Direkt nach Installation des Updates ist aber ein einmaliger Vorgang notwendig, um die Zusammenfassungen für die Vergangenheit zu erstellen.
>
> Diese Nachberechnung erfolgt, wenn man einen vergangenen Zeitraum wie z.B. ein Jahr, einen Monat oder gar "GESAMT" wählt. Meist dauert das nur wenige Minuten, kann aber bei sehr großen Datenmengen etwas länger dauern. Im Beta-Test war die längste Dauer 30 Minuten auf einem Synology-NAS.
>
> Dieser Vorgang ist **nur einmal** erforderlich. Für zukünftige Tage werden die Zusammenfassungen sukzessive automatisch erstellt - und das ist kaum spürbar.
>
Die Einführung der Tageszusammenfassungen war eine erhebliche Umstellung, die viele Bereiche des Programmcodes betraf. Wer sich für die technischen Hintergründe interessiert, kann sich auf GitHub informieren. Dort fand der Beta-Test statt, mit weiteren Erklärungen und begeisterten Rückmeldungen: \
https://github.com/orgs/solectrus/discussions/3587
## Was kommt als Nächstes?
Im [letzten Blog-Eintrag](/blog/2024-09-23-version-0-17/) wurde die Frage gestellt, welches Feature als Nächstes gewünscht wird. Die meisten Stimmen gab es für die [Unterstützung zusätzlicher Verbraucher](https://github.com/solectrus/solectrus/issues/3396). Das wird daher mein Thema in den nächsten Wochen sein.
Dir gefällt SOLECTRUS und möchtest die weitere Entwicklung unterstützen? Es ist nie zu spät, [Sponsor zu werden](/sponsoring/) :-)
---
# Neuer Dunkelmodus
_2024-09-23_
> SOLECTRUS bekommt einen Dunkelmodus, der auf OLED-Displays sogar Strom spart. Dazu neu ist der Ladestand des E-Autos samt Verbindungsstatus.
Dank der Unterstützung durch die Sponsoren war es möglich, in den letzten Wochen zwei neue Features zu entwickeln. Diese sind in die heute veröffentlichte Version 0.17 eingeflossen.
## Neu: Der Dunkelmodus
Es ist soweit: SOLECTRUS unterstützt nun auch den Dunkelmodus, bietet also auf Wunsch eine abgedunkelte Benutzeroberfläche.
Der Dunkelmodus sieht nicht nur gut aus und ist schonend für die Augen, sondern spart auch Energie. Gerade bei OLED-Displays wird weniger Strom verbraucht, wenn dunkle Flächen dargestellt werden. Das ist natürlich besonders interessant für Nutzer, die SOLECTRUS auf ihrem Smartphone verwenden.
Der Dunkelmodus wird automatisch aktiviert, wenn das Betriebssystem dies unterstützt. Bei iOS funktioniert es am besten mit der neuen Version 18. Alternativ kann eine manuelle Aktivierung über das Hamburger-Menü erfolgen.
## Neu: Ladestand des E-Autos
Besitzer eines E-Autos müssen einen weiteren Akkuladestand stets im Blick behalten. Mit SOLECTRUS ist das jetzt möglich. Wer den Ladestand grundsätzlich zur Verfügung hat (was ein Thema für sich ist), der kann nun dafür sorgen, dass SOLECTRUS den Ladestand des E-Autos darstellt.
Optional ergänzt werden kann diese über den Verbindungsstatus des Autos. Wenn das Auto nicht mit der Wallbox verbunden ist, wird es leicht transparent dargestellt.
Um diese Darstellung zu erhalten, müssen zwei neue Sensoren konfiguriert werden. Die [Dokumentation](https://github.com/solectrus/solectrus/wiki/Konfiguration) dazu ist bereits aktualisiert.
## Was kommt als Nächstes?
Bei der Planung der weiteren Entwicklungsarbeit möchte ich gerne die Nutzer einbeziehen.
Es gibt derzeitig 43 offene Issues bei GitHub. Einige davon sind größere Features, andere sind kleinere Verbesserungen. Hier ein paar Beispiele größerer Themen, die möglicherweise für viele interessant sind:
- Amortisationsrechner für die PV-Anlage ([#2416](https://github.com/solectrus/solectrus/issues/2416))
- Vergleich der Kosten des E-Autos mit einem fiktiven Verbrenner ([#2407](https://github.com/solectrus/solectrus/issues/2407))
- Darstellen zusätzlicher Verbraucher ([#3396](https://github.com/solectrus/solectrus/issues/3396))
Bei GitHub lassen sich Issues bewerten und dann als sortierte Liste ausgeben. Das ist eine einfache Möglichkeit, um zu sehen, welche Features die Nutzer am meisten interessieren.
Ich möchte alle Nutzer aufrufen, sich die Liste anzusehen und die Issues zu bewerten, die am wichtigsten erscheinen. Das hilft mir, die Prioritäten richtig zu setzen.
> **Zu beachten:**
>
>
> - Die Bewertung erfolgt im einzelnen Issue. Aus der Liste heraus ist also das zu bewertende Issue aufzurufen.
> - Es wird nur die Bewertung des **ersten** Beitrags berücksichtigt, also nicht die der Kommentare darunter.
> - Relevant ist die Bewertung mit "Daumen hoch" (👍). Andere Reaktionen werden in der Auswertung nicht berücksichtigt (auch nicht "Daumen runter"). Eine Bewertung kann aber zurückgezogen werden, was auch berücksichtigt wird.
> - Ergänzende Kommentare sind natürlich willkommen.
> - Neue Issues können gerne erstellt werden. Bitte vorher die Suchfunktion verwenden, um Duplikate zu vermeiden.
> - Um eine Bewertung abzugeben, musst du bei GitHub angemeldet sein. Das ist kostenlos und dauert nur wenige Minuten.
> - Man muss kein Sponsor sein, um abzustimmen. Jeder Nutzer ist eingeladen, sich zu beteiligen.
>
Genug der Vorrede, hier der Link zur Abstimmung:
→ [Zur Abstimmung bei
GitHub](https://github.com/solectrus/solectrus/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc)
---
# Power-Splitter berechnet grünen Stromanteil
_2024-08-31_
> Der Power-Splitter ermittelt, wie viel Strom für Wärmepumpe und E-Auto vom eigenen Dach kam. Damit stehen auch deren tatsächliche Kosten fest.
## Der Power-Splitter
Wolltest du schon immer mal wissen, wie "grün" der Strom ist, den deine Wärmepumpe oder dein E-Auto verbraucht? Für die gesamte PV-Anlage ist das kein Problem – diese Information ergibt sich aus der Autarkie. Aber die Betrachtung einzelner Verbraucher ist nicht so einfach.
Mit dem neuen [Power-Splitter](/features/#power-splitter) von SOLECTRUS wird das jetzt möglich. Er berechnet zuverlässig für jeden Moment, wie sich der aus dem Netz bezogene Strom ("rot") auf die einzelnen Verbraucher aufteilt. Die Differenz ergibt dann den PV-Strom ("grün"), und so lassen sich die tatsächlichen Kosten des Verbrauchers ermitteln.
Ein **Beispiel**: Du weißt, dass deine Wärmepumpe in einem Jahr insgesamt 3.000 kWh verbraucht hat. Das ist einfach und wird vielleicht schon von der App deiner Wärmepumpe angezeigt. Mit dem Power-Splitter erfährst du nun aber auch, dass z.B. 30 % davon eingekauft werden mussten, während 70 % selbst erzeugt wurden. Das hat natürlich Auswirkungen auf deine Stromkosten. SOLECTRUS berechnet dies genau und berücksichtigt dabei optional auch die entgangene Einspeisevergütung. Du erfährst also mit dem Power-Splitter endlich, was deine Wärmepumpe (oder dein E-Auto) wirklich an Stromkosten verursacht.
Ein Beta-Tester meint dazu: "Tolle Sache! Bevor ich es in der Live-Demo gesehen habe, wusste ich gar nicht, dass ich so etwas brauchen könnte, aber das Ganze wertet die Auswertungen doch enorm auf!"
> **Hinweis**
>
>
> Wie du nach dem Update auf Version `0.16` den Power-Splitter in Betrieb nimmst, erfährst du in der [Dokumentation](https://github.com/solectrus/power-splitter/wiki/Installation). Es muss nur ein zusätzlicher Docker-Container eingerichtet werden.
>
> Falls du SOLECTRUS mit dem [Konfigurator](/docs/referenz/helios/) neu installierst, wird der Power-Splitter automatisch mit installiert.
>
## Nachhaltige Software-Entwicklung
Kommen wir nun zu etwas völlig anderem. 😉
SOLECTRUS erfreut sich immer größerer Beliebtheit. Es fasziniert mich zu sehen, wie sich immer mehr User registrieren und die App regelmäßig nutzen. Ursprünglich war SOLECTRUS ja nur für meinen eigenen Bedarf gedacht.
Bisher habe ich SOLECTRUS in meiner Freizeit entwickelt – wobei Freizeit ein dehnbarer Begriff ist, wenn man selbstständig ist. Mittlerweile gibt es jedoch so viel zu tun, dass die Entwicklung nicht mehr nebenbei erledigt werden kann. Es gibt viele Ideen und Anfragen, die ich gerne umsetzen würde. Und mit der steigenden Nutzerzahl steigt auch der Support-Aufwand.
Damit SOLECTRUS weiterhin wachsen und gedeihen kann, ist es nun an der Zeit, das Projekt auf eine professionelle Basis zu stellen. Denn unentgeltliche Arbeit hat ihre Grenzen. Um auch in Zukunft neue Features und Verbesserungen umsetzen zu können, ist finanzielle Unterstützung unerlässlich.
Die bisherigen freiwilligen Zuwendungen über Ko-Fi waren ein guter Anfang, und ich danke sehr dafür. Um das Projekt nachhaltig zu sichern, sind jedoch regelmäßige Einnahmen erforderlich. Deshalb gibt es ab sofort das [Sponsoring-Abo](/sponsoring/).
Mit monatlich 5 € hilfst du, die Weiterentwicklung von SOLECTRUS zu sichern und erhältst Zugriff auf exklusive Features. Der oben erwähnte Power-Splitter ist das erste Feature, das exklusiv für Sponsoren verfügbar ist. Weitere sind bereits in Planung.
Ich verstehe natürlich, dass in Zeiten von Netflix, Spotify, iCloud und Co. ein weiteres Abo nicht unbedingt das ist, was man sich wünscht. Ich hoffe daher auf euer Verständnis – gute Software zu entwickeln, kostet Zeit und Geld.
Habe ich dich überzeugt? Das Abo kannst du abschließen, indem du in deiner SOLECTRUS-Installation rechts oben auf das Menü-Icon klickst und dann auf _Registrierung_. Der Hinweis auf das Abo ist dann nicht zu übersehen. Zahlen kannst du bequem mit PayPal, Kreditkarte, Apple Pay oder Google Pay.
Übrigens: Wer sich an der Entwicklung von SOLECTRUS mit signifikanten Code-Beiträgen beteiligt, erhält die Sponsoring-Vorteile dauerhaft kostenlos. Gleiches gilt für diejenigen, die individuelle Features in Auftrag gegeben haben.
Du brauchst noch etwas Bedenkzeit? Kein Problem, du kannst SOLECTRUS weiterhin kostenlos nutzen. SOLECTRUS wird dich nur ab und zu an die Möglichkeit des Sponsoring-Abos erinnern.
> **Hinweis**
>
>
> Wer über Ko-Fi oder GitHub bereits ein Sponsoring abgeschlossen hat, dem empfehle ich, auf das neue Sponsoring-Abo umzusteigen - also das bisherige Beenden und das neue Abschließen. Das muss leider manuell erfolgen, ein automatischer Wechsel ist technisch nicht möglich.
>
---
# Update für SENEC Firmware 0828/8828
_2024-08-06_
> SENEC verteilt die Firmware 0828/8828. Ohne SENEC-Collector 0.15.0 zeigt SOLECTRUS danach keine Messwerte mehr an. Also updaten.
Im Rahmen des laufenden Austauschprogramms auf LFP-Batteriemodule verteilt SENEC derzeitig die Firmware `Revision MCU 0828` bzw. `Revision MCU 8828`. Dieses Firmware-Update bringt eine kleine Änderung mit sich, die eine Anpassung des SENEC-Collectors von SOLECTRUS erfordert.
Wer die neue Firmware auf seinem Speicher hat, muss dafür sorgen, dass der SENEC-Collector in der heute von mir veröffentlichten Version `0.15.0` läuft, andernfalls funktioniert beim nächsten Start des Collectors die Abfrage der Status-Bezeichnungen nicht mehr und SOLECTRUS zeigt keine Messwerte mehr an. Es besteht also Handlungsbedarf.
Der aktualisierte SENEC-Collector funktioniert übrigens auch mit älteren Firmware-Versionen von SENEC. Es ist also kein Problem, das Update schon jetzt zu installieren, auch wenn man gar nicht vom Tausch der Batteriemodule betroffen ist.
> **Hinweis**
>
>
> Die Versionsnummer des SENEC-Collectors ist nur zufällig identisch mit der aktuellen Version von SOLECTRUS. Das ist reiner Zufall und hat keine Bedeutung. Beide Docker-Images werden unabhängig voneinander aktualisiert.
>
## Update des SENEC-Collectors installieren
Wer Watchtower nutzt, muss nichts weiter tun, das Update wird automatisch installiert. Eine manuelle Installation des Updates gelingt hingegen wie folgt:
1. Das aktualisierte Docker-Image muss geholt werden, das geht mit:\
`docker compose pull`
2. Anschließend müssen die Container neu gestartet werden, wie üblich geht das mit:\
`docker compose up -d`
(Bei älteren Versionen von Docker, z.B. auf einem Synology-NAS, bitte `docker-compose` statt `docker compose` verwenden)
---
# Wärmepumpe und externe Wallbox
_2024-07-15_
> Version 0.15 weist den Stromverbrauch der Wärmepumpe getrennt aus und bindet externe Wallboxen ein. Der neue Konfigurator vereinfacht die Installation.
Ich freue mich sehr, die neueste Version meines OpenSource-Photovoltaik-Dashboards SOLECTRUS vorzustellen. Version **0.15** bringt endlich die Unterstützung für Wärmepumpen und erweitert die Möglichkeiten, eine externe Wallbox zu integrieren. Dazu gibt es viele Detailverbesserungen und intern wurde einiges umgekrempelt. Version 0.15 ist das größte Update seit langem. Und den neuen Konfigurator gibt's obendrauf.
Aber der Reihe nach:
## Unterstützung für Wärmepumpe
SOLECTRUS kann nun eine **Wärmepumpe** in der Strombilanz ausweisen und natürlich den Stromverbrauch im Zeitverlauf als Diagramm darstellen. Da üblicherweise der Stromverbrauch der Wärmepumpe im Hausverbrauch enthalten ist, kann dieser herausgerechnet werden, um eine Doppelzählung zu vermeiden. Das Ergebnis sieht dann so aus:
Voraussetzung ist natürlich, den Stromverbrauch der Wärmepumpe abfragen zu können. Das könnte z.B. per MQTT über ioBroker, HomeAssistant oder andere Systeme möglich sein. Der zu SOLECTRUS gehörende MQTT-Collector wurde übrigens vollständig neu implementiert und funktionell erweitert. [Die neue Konfiguration des MQTT-Collectors ist im Wiki beschrieben.](https://github.com/solectrus/mqtt-collector/wiki/Konfiguration)
Alternativ steht der [Shelly-Collector](https://github.com/solectrus/shelly-collector) zur Verfügung, der den Stromverbrauch beispielsweise über einen Shelly Pro 3EM auslesen kann.
Um eine bestehende Installation von SOLECTRUS um die Wärmepumpe zu erweitern, sind ein paar Anpassungen in der Konfiguration nötig. [Wie das genau funktioniert, habe ich auf GitHub beschrieben.](https://github.com/orgs/solectrus/discussions/2861)
## Unterstützung für externe Wallbox
Bislang konnte SOLECTRUS nur eine **interne** Wallbox darstellen, die also auf den Hausverbrauch "oben drauf" kommt, beispielsweise die Wallbox von SENEC.
Jetzt ist es möglich, die Verbrauchswerte einer **externen** Wallbox per MQTT abzuholen und - das ist die wesentliche Neuerung - aus dem Hausverbrauch **herauszurechnen**.
Voraussetzung ist, den Stromverbrauch der Wallbox per MQTT abfragen zu können. Auch hier können wieder ioBroker, HomeAssistant oder andere Systeme helfen. Zu beachten ist auch hier [die neue Konfiguration des MQTT-Collectors, die im Wiki beschrieben wird](https://github.com/solectrus/mqtt-collector/wiki/Konfiguration).
## Neue Sensoren-Konfiguration
Intern waren dazu größere Anpassungen bei der Konfiguration nötig. SOLECTRUS definiert nun sog. **Sensoren**, um Messwerte aus der InfluxDB zu lesen. Sensoren sind eine Zwischenschicht, um die Messwerte (in InfluxDB gespeichert) von der Darstellung in SOLECTRUS zu entkoppeln. Das macht die Software flexibler und wird zukünftige Erweiterungen erleichtern. [Mehr dazu im Wiki auf GitHub.](https://github.com/solectrus/solectrus/wiki/Konfiguration)
Wer keine Wärmepumpe oder Wallbox hat, kann die Sensoren auch einfach ignorieren, Version `0.15` ist vollständig abwärtskompatibel zu früheren Versionen. Falls es im Einzelfall doch irgendwo haken sollte, helfe ich gerne weiter.
## CO₂-Reduzierung für jeden Zeitraum
Neben der finanziellen Ersparnis ist auch die CO₂-Reduzierung ein wichtiger Aspekt der Photovoltaik-Anlage. In einem ersten Schritt wird diese auf eine simple Weise errechnet, nämlich durch Multiplikation des erzeugten Stroms mit einem konstanten CO₂-Faktor. Das ist aber nicht das Ende der Fahnenstange, eine genauere Berechnung ist in Arbeit (mehr dazu siehe unten).
Die Darstellung erfolgt in einem zusätzlichen Infokreis sowie als Diagramm für den gewählten Zeitraum.
## Verbesserungen an der Benutzeroberfläche
**Swipe:** Auf Touch-Devices (Smartphone, Tablet) kann jetzt mit Wisch-Gesten zum nächsten/vorhergehenden Tag (oder Woche, Monat, Jahr) navigiert werden.
**Smartphone-Optimierung:** Die Darstellung auf Smartphones passt sich nun besser auf sehr kleine Displays an.
Und für die visuellen Effekte gibt's jetzt kleine Animationen beim Klick auf Buttons.
## Interne Verbesserungen
Unter der Haube hat sich auch einiges getan. Viele interne Verbesserungen und Code-Refactorings machen die Software stabiler, effizienter und besser wartbar.
Ich habe außerdem die Abhängigkeiten aktualisiert: SOLECTRUS verwendet jetzt die neueste Version von Ruby, Ruby on Rails und anderen Bibliotheken. Das bringt mehr Sicherheit und Stabilität.
## Behobene Bugs
Das Update räumt auch einige Fehler aus dem Weg:
- Bei der Fortschreibung der Diagrammen auf der Aktuell-Seite gab es gleich zwei Probleme: Neue Messwerte erschienen zeitversetzt (d.h. immer ein paar Sekunden zu spät) und bei Null-Werten blieb das Diagramm einfach stehen. Beides gehört jetzt der Vergangenheit an.
- In machen Fällen gab es kleine Inkonsistenzen bei der Berechnung von Summen, beispielsweise stimmten die Angaben der Top10 oder die Balken von Diagrammen nicht exakt mit den Einzelansichten überein. Das wurde korrigiert.
- Die Tooltips in der Strombilanz zeigen jetzt immer die vollen Nachkommastellen an. Gut für jeden, der es genau wissen will.
## Kompatibilität
Für die neue Version gab es einen ausführlichen Beta-Test, an dem viele von euch teilgenommen haben. Vielen Dank für das Feedback und die Unterstützung!
Ganz wichtig: Die Version 0.15 ist **abwärtskompatibel** zu den früheren Versionen, kommt also trotz der vielen Änderungen auch mit einer alten Konfiguration klar. Dennoch empfehle ich, einen Blick ins Docker-Log zu werfen, um sicherzustellen, dass alles korrekt läuft.
Wenn es im Einzelfall doch zu Problemen kommen sollte, legt bitte ein [Issue auf GitHub](https://github.com/solectrus/solectrus/issues) an, damit wir schnell eine Lösung finden können.
> **Hinweis**
>
>
> Wer noch eine Betaversion im Einsatz hat, sollte auf die stabile Version wechseln. Das heißt, wer in seinem `docker-compose.yml` noch die Docker-Tags `pr-137`, `pr-2836` oder `separate_consumer` stehen hat, sollte unbedingt auf `latest` wechseln, um die zukünftige Versorgung mit Updates sicherzustellen.
>
> Wer eine Entwicklerversion verwendet (Docker-Tag `develop`), sollte ebenfalls einen Wechsel auf die stabile Version in Erwägung ziehen - oder zumindest automatische Updates (mit Watchtower) aktivieren.
>
## Neuer Konfigurator
Für eine Erstinstallation von SOLECTRUS verwendet man am einfachsten den neuen [Konfigurator](https://configurator.solectrus.de/), der vieles einfacher macht. Anstatt manuell die Dateien `docker-compose.yml` und `.env` zu bearbeiten, werden diese jetzt automatisch generiert, nachdem man einen web-basierten Fragebogen durchlaufen hat.
Das ist übrigens auch für bestehende Solectronauten interessant, die damit prüfen können, ob alles optimal konfiguriert ist.
## Ausblick
Und was steht als Nächstes an? Ich arbeite bereits an neuen Features. Geplant sind unter anderem:
- **Deckung je Verbraucher**: Wisst ihr, wie viel das E-Auto oder die Wärmepumpe tatsächlich an Stromkosten verursacht hat? Nun, der Stromverbrauch des Verbrauchers ist dank SOLECTRUS bekannt - aber nicht, wie viel davon **selbst erzeugt** wurde. Das möchte ich ändern.
Für jeden Verbraucher (Haus, Wärmepumpe, Wallbox) wird zukünftig berechnet, wie viel Strom selbst erzeugt wurde und wie viel aus dem Netz bezogen wurde - inklusive der **tatsächlichen Stromkosten** des jeweiligen Verbrauchers.
Im Ergebnis könnte das etwa so aussehen:
Ich halte das für eine spannende Fragestellung, die man mit bisherigen Tools nicht beantworten kann. [Mehr zur Idee und zur Implementierung findet sich auf GitHub.](https://github.com/solectrus/solectrus/issues/2436)
- **CO₂-Reduktion:** Welchen Beitrag leistet die eigene Photovoltaik-Anlage zur Erreichung der Klimaziele im Land? Ich möchte eine genauere Berechnung in SOLECTRUS integrieren.
Da die tatsächliche CO₂-Emission eines Landes üblicherweise im Tagesverlauf stark schwankt, ist die derzeitige Berechnung mit einem konstanten Emissionsfaktor sehr ungenau. Nachts ist nämlich die CO₂-Emission meist höher, weil Photovoltaik wegfällt und mehr Kohle- oder Gasverstromung zum Einsatz kommt. Über eine externe API soll die tatsächliche CO₂-Emission am Standort des Nutzers abgefragt und in die Berechnung einbezogen werden. [Auch hierzu lassen sich die technischen Details auf GitHub nachlesen.](https://github.com/solectrus/solectrus/issues/3198)
- **Kombiniertes Diagramm:** Die bisherigen Diagramme stellen nur jeweils einen einzelnen Messwert dar. Oft kommt die Frage, ob nicht eine kombinierte Darstellung möglich ist. Und ja, daran wird tatsächlich gearbeitet, und das sogar mit tatkräftiger externer Unterstützung. [Es ist noch einiges zu tun](https://github.com/solectrus/solectrus/issues/2056), aber die ersten Schritte sind gemacht.
Danke für eure Unterstützung und viel Spaß mit Version 0.15 von SOLECTRUS!
---
# Neues aus der Kollektoren-Werkstatt
_2024-06-05_
> Solcast als zweiter Prognose-Anbieter, ein Power-Splitter für den grünen Stromanteil und ein CSV-Importer für alte Messwerte.
SOLECTRUS ist bekanntlich [modular aufgebaut](/docs/grundlagen/) - rund um das eigentliche Dashboard gibt es eine Vielzahl von sog. "Kollektoren", die Messwerte von verschiedenen Quellen einsammeln und in die Datenbank einpflegen.
Hier ein kurzer Überblick über die aktuellen Entwicklungen und Neuerungen aus diesem Bereich, die sich auch in Form von Updates bemerkbar machen:
## Forecast-Collector v0.5.0
Neben [Forecast.solar](https://forecast.solar/) wird nun auch der Anbieter [Solcast](https://solcast.com/) unterstützt, der eine genauere Vorhersage der PV-Erzeugung bietet. War es bislang so, dass eine Vorhersage oft um 50% bis über 100% daneben lag, ist das bei Solcast um einiges zuverlässiger.
Für die Nutzung ist eine Registrierung bei Solcast notwendig (kostenfrei bei bis zu zwei Dachflächen). Anschließend konfiguriert man dort seine PV-Anlage und erhält einen API-Key, den man dann im Forecast-Collector [einträgt](https://github.com/solectrus/forecast-collector/blob/develop/.env.solcast.example).
Aber das Beste ist: Die Programmierung der Solcast-Unterstützung wurde von einem Nutzer [beigesteuert](https://github.com/solectrus/forecast-collector/pull/322). Herzlichen Dank an [Gereon](https://github.com/gereons)!
Technische Details zum Update findet sich [auf GitHub](https://github.com/solectrus/forecast-collector/releases/tag/v0.5.0).
## CSV-Importer v0.4.0
Für den Import historischer Messwerte gibt es eine neue Version des CSV-Importers. Die wichtigste Neuerung ist die Unterstützung von SolarEdge. Wer also einen solchen Wechselrichter hat, kann die Messwerte aus früheren Zeiten in die SOLECTRUS-Datenbank übernehmen.
Auch dieses Feature wurde im Wesentlichen von einem Nutzer [implementiert](https://github.com/solectrus/csv-importer/issues/217). Vielen Dank an [Sascha](https://github.com/AlpenFlizzer)!
Technische Details zum Update findet sich [auf GitHub](https://github.com/solectrus/csv-importer/releases/tag/v0.4.0).
## SENEC-Collector v0.14.2
Mit dem SENEC-Collector fing [damals](https://ledermann.dev/blog/2021/02/03/photovoltaik-dashboard-als-web-applikation/) alles an. Inzwischen ist dieser Kollektor weitgehend stabil und ausgereift.
Die [kürzlich eingeführte Cloud-Unterstützung](/blog/2024-01-31-unterstuetzung-des-senec-home-4/) hat noch eine kleine Optimierung erhalten und es wurde an der Stabilität gefeilt. Auch lassen sich nun einzelne Werte ignorieren, was insbesondere nützlich ist, wenn man eine Wallbox eines anderen Herstellers hat, dessen Messwerte per MQTT eingelesen werden.
Technische Details zu den letzten Updates findet sich [auf GitHub](https://github.com/solectrus/senec-collector/releases).
## Shelly-Collector v0.3.0
Der Shelly-Collector ist noch recht frisch und ermöglicht das Abgreifen von Messwerten von Shelly-Geräten. Neben dem Shelly Pro 3EM wird nun auch der Shelly Plus Plug S unterstützt.
Technische Details zum Update findet sich [auf GitHub](https://github.com/solectrus/shelly-collector/releases/tag/v0.3.0).
## Und sonst so?
Abschließend noch zwei Hinweise auf laufende Entwicklungsarbeiten:
### MQTT-Collector: Großes Update in Arbeit
Für den Anschluss auch exotischer Stromspeicher und Wechselrichter ist der MQTT-Collector zuständig. Dieser wird schon seit längerem grundlegend überarbeitet und wird bald in einer neuen Version erscheinen.
Schwerpunkt ist eine neue Konfiguration. Es lassen sich damit beliebige Messwerte vom MQTT-Broker abrufen, es können JSON-Daten extrahiert und Berechnungen durchgeführt werden.
Die neue Konfiguration ist abwärtskompatibel, niemand muss also nach einem Update seine Konfiguration neu schreiben.
Wer sich für die technischen Details interessiert, kann sich hier einlesen: https://github.com/solectrus/mqtt-collector/pull/137
### Ganz neu: Der Power-Splitter
Mit dem "Power-Splitter" ist ein weiteres Tool [in Arbeit](https://github.com/solectrus/solectrus/issues/2436#issuecomment-2053977326). Damit wird es möglich, genau zu berechnen, woher der für die einzelnen Verbraucher benötigte Strom kommt.
Hat man einen großen Verbraucher wie z.B. eine Wärmepumpe oder eine Wallbox, dann möchte man vermutlich wissen, wie viel des verbrauchten Stroms selbst erzeugt und wie viel aus dem Netz bezogen wurde. Der Power-Splitter rechnet dies aus, indem der Netzbezug rechnerisch auf die betriebenen Geräte aufgeteilt wird.
Im Ergebnis erfährt man, wie hoch die Stromkosten eines Verbraucher **wirklich** sind. Ein Wärmepumpen-Betreiber weiß zwar sicherlich, wie viel Strom (in kWh) seine Wärmepumpe z.B. in einem Jahr verbraucht hat, aber nicht, wie viel das in Euro sind. Denn es macht ja einen gewaltigen Unterschied, ob der Strom vom Dach kommt oder gekauft werden musste. Der Power-Splitter rechnet genau das aus.
Und das Beste ist: Dies funktioniert auch im Nachhinein, also mit den bereits in SOLECTRUS vorhandenen Messwerten. Voraussetzung ist nur, dass diese hinreichend noch aufgelöst sind, also mindestens im 5-Minuten-Takt vorliegen.
Dies nur als Ausblick, später mehr dazu.
### Dashboard: Großes Update voraus
Das Dashboard selbst, also die Benutzeroberfläche, erfährt derzeit auch einige grundlegende Verbesserungen. Die Konfiguration ändert sich und wird flexibler, so dass eine [externe Wallbox](https://github.com/orgs/solectrus/discussions/2865) und eine [Wärmepumpe](https://github.com/orgs/solectrus/discussions/2861) unterstützt werden. Etliche Solectronauten nehmen derzeitig an einem Beta-Test teil und geben wertvolles Feedback, danke dafür auch an dieser Stelle!
Hierzu wird es demnächst einen eigenen Blog-Beitrag geben.
---
# Unterstützung des SENEC.Home 4
_2024-01-31_
> Der SENEC.Home 4 hat keine lokale Web-Oberfläche mehr. SOLECTRUS holt seine Messwerte deshalb über mein-senec.de, mit den Login-Daten der SENEC-App.
In letzter Zeit häufen sich die Anfragen: "Wann wird SOLECTRUS den SENEC.Home 4 unterstützen?". Ich freue mich, verkünden zu können: Die Zeit ist gekommen! Ab jetzt ist SOLECTRUS auch für Besitzer des SENEC.Home 4 verfügbar.
Anders als seine Vorgängermodelle bietet der SENEC.Home 4 keine lokale Web-Oberfläche, über die man Messwerte erhalten könnte. Daher musste nach einer alternativen Methode gesucht werden, um Zugang zu den Messdaten zu erhalten. Die Lösung ist die Nutzung der API der SENEC-App, die dankenswerterweise von einem engagierten Nutzer analysiert und [dokumentiert](https://documenter.getpostman.com/view/932140/2s9YXib2td) wurde. Der Zugriff erfolgt über die persönlichen Login-Daten, die jeder SENEC-Kunde für `mein-senec.de` besitzt.
## Vor- und Nachteile
Diese Methode bringt einen interessanten Vorteil mit sich:
- Ein lokaler Server zum Abholen der Messwerte ist nicht mehr erforderlich. Da keine direkte Verbindung zum Stromspeicher erfolgt, sondern nur zur SENEC-Cloud, kann der Zugriff auch über einen Internet-Server erfolgen. Dadurch ist es möglich, SOLECTRUS komplett auf einem Cloud-Server zu betreiben. Natürlich bleibt auch der Betrieb auf einem zeitgemäßen Linux-Server, wie beispielsweise einem Raspberry Pi, weiterhin möglich.
Es gibt jedoch auch Nachteile:
- Im Gegensatz zum direkten Zugriff auf den Stromspeicher, der nahezu Echtzeit-Daten liefert, bietet die App-API von SENEC eine Aktualisierungsrate von nur 60 Sekunden (bei Verwendung des Home 4). Dadurch ist die Datenanzeige in SOLECTRUS für dieses Modell weniger "live" als bei einem direkt angebundenen V3.
- Nicht alle Daten sind über die App-API verfügbar. Beispielsweise fehlt der aktuelle Speicherstatus (wie "AKKU VOLL", der auch im Display des V3 angezeigt wird). Aber die wesentlichen Messwerte wie Erzeugung, Verbrauch, Akkustand und Wallbox-Daten sind verfügbar.
## Ausprobieren
Um die App-API nutzbar zu machen, wurde nicht SOLECTRUS selbst, sondern nur der [SENEC-Collector](https://github.com/solectrus/senec-collector) angepasst. Die neue Version `0.12.0` des Collectors unterstützt sowohl den direkten Zugriff (jetzt als "local" bezeichnet) als auch den Zugriff über die App-API ("cloud").
Für Interessierte steht eine neue [Anleitung zur Installation auf einem Hetzner-Cloud-Server](https://github.com/solectrus/hosting/tree/main/guide/external-server-cloud) zur Verfügung. Wer ein wenig Erfahrung mit der Linux-Kommandozeile hat, kann SOLECTRUS damit in wenigen Minuten auf einem Cloud-Server installieren und ausprobieren.
Die bestehenden Anleitungen für Raspberry Pi und Synology NAS wurden ebenfalls aktualisiert. Ein guter Einstiegt ist die [Gesamtübersicht aller Anleitungen](https://github.com/solectrus/hosting).
## Feedback
Ich freue mich über Feedback und Anregungen. Am besten über die [Issues](https://github.com/solectrus/hosting/issues) bzw. das [Forum](https://github.com/orgs/solectrus/discussions) auf GitHub oder per E-Mail.
---
# Preisoptimierte Speicherbeladung aus dem Netz
_2024-01-28_
> Ein neues Tool lädt den SENEC-Speicher aus dem Netz, sobald der Tibber-Preis niedrig ist. Wie die Automatik entscheidet und was sie dafür abfragt.
Dynamische Stromtarife erfreuen sich immer größerer Beliebtheit. Wenn der Strompreis stündlich an den aktuellen Großhandelspreis angepasst wird, ergibt sich für den Endkunden eine interessante Möglichkeiten zur Reduzierung der Stromkosten, indem der Verbrauch in die kostengünstige Zeit verschoben wird.
Für den Besitzer einer Photovoltaik-Anlage mit Stromspeicher eröffnet sich eine zusätzliche Option: Wenn die Ausbeute der eigenen PV-Anlage gering ist, zum Beispiel im Winter, lädt man den Speicher zu günstigen Zeiten aus dem Stromnetz. Davon profitiert man dann einige Stunden später, wenn der Strompreis wieder deutlich gestiegen ist.
Das könnte sich lohnen, auch wenn natürlich Ladeverluste und die Degradation des Speichers berücksichtigt werden müssen. Darüber hinaus gibt es rechtliche Aspekte zu beachten, die weiter unten skizziert werden.
## Vorstellung der Beladungsautomatik
Wenn dein Stromanbieter [Tibber](https://tibber.com) heißt und du einen Stromspeicher von [SENEC](https://senec.com) hast (v2.1 oder V3), dann gibt es hierfür ein neues OpenSource-Tool, das die kosten-optimierte Beladung des Speichers aus dem Netz automatisiert. Es ist als Docker-Container verfügbar, läuft auch auf einem Raspberry Pi und lässt sich einfach in deine bestehende SOLECTRUS-Installation integrieren. Es kann aber auch ganz ohne SOLECTRUS verwendet werden.
### Wie arbeitet die Automatik?
Die Automatik des Tools besteht aus vier Komponenten:
1. Die aktuellen Strompreise werden regelmäßig über die Tibber-API abgefragt. Jeder Tibber-Kunde kann sich ein kostenloses API-Token erstellen, über den die individuellen Strompreise der nächsten 12-36 Stunden abgerufen werden können.
2) Die erwartete Stromerzeugung für die eigene PV-Anlage der nächsten 24 Stunden wird ebenso regelmäßig abgefragt. Hierfür wird die PV-Ertragsvorhersage von [forecast.solar](https://forecast.solar) verwendet, die bereits in SOLECTRUS integriert ist.
3) Der aktuelle Status und Füllstand des Speichers wird ebenfalls regelmäßig abgefragt. Hierfür wird die lokale Schnittstelle des SENEC-Speichers verwendet.
4) Eine Logik entscheidet nun jeweils, ob der Speicher voll beladen, eine Beladung freigegeben oder ob gar nichts getan werden soll. Die Logik ist konfigurierbar und kann an die eigenen Bedürfnisse angepasst werden. Verwendet wird die Funktion "Notbeladung", die auch über die lokale Web-Oberfläche des Speichers verfügbar ist (im Menü `Setup` > `Wartung` > `Vollladung`).
### Wie wird über die Beladung entschieden?
Die Logik ist das Kernstück des Tools und überraschend komplex. Sie berücksichtigt verschiedene Kriterien:
- Eine Beladung aus dem Netz wird nur dann durchgeführt, wenn der Speicher vollkommen leer ist. Ermittelt wird dies über den Status des Speichers, der über die lokale Schnittstelle abgefragt wird. Der Status muss `Akku leer` lauten. Das bedeutet auch: Wenn der Speicherfüllstand 0% ist, aber gerade eine Batteriediagnose durchgeführt wird oder ein sonstiges Problem vorliegt, dann wird nicht geladen.
- Eine Beladung erfolgt außerdem nur dann, wenn in den nächsten 24 Stunden wenig PV-Strom erwartet wird. Was genau "wenig" bedeutet, kann konfiguriert werden. Es kann ein Schwellenwert in kWh angegeben werden. Gibt man beispielsweise 5 kWh an, dann wird der Speicher nur dann beladen, wenn in den nächsten 24 Stunden weniger als 5 kWh PV-Strom erwartet werden.
- Das letzte, aber wichtigste Kriterium ist natürlich der Strompreis. Eine Beladung aus dem Netz erfolgt nur bei günstigem Preis. Nur, was genau heißt "günstig"? Es hat einige Fehlversuche benötigt, um den passenden Algorithmus zu finden:
1. Es wird zunächst ermittelt, wie hoch der durchschnittliche Strompreis in den nächsten 24 Stunden ist. Da Tibber die Preise für den nächsten Tag aber erst gegen Mittag des Vortages bereitstellt, kann es sein, dass man (im ungünstigsten Fall) nur die nächsten 12 Stunden betrachten kann. Falls also weniger als 24 Stunden zur Verfügung stehen, wird der durchschnittliche Strompreis für die verfügbare Zeit ermittelt.
2. Anschließend wird das günstigste Zeitfenster in den nächsten 24 Stunden ermittelt. Wie lang ein Zeitfenster ist, kann konfiguriert werden. Es sollte so lang sein, wie eine volle Ladung etwa dauern wird, hängt also von Kapazität des Speichers und der Ladeleistung ab. Für einen Speicher mit 10 kWh Kapazität und einer Ladeleistung von 2,5 kW sollte das Zeitfenster also 4 Stunden betragen. Es wird also ermittelt, welcher 4-Stunden-Zeitraum den geringsten Durchschnittspreis hat.
3. Wenn das günstigste Zeitfenster einen deutlich geringeren Preis hat als der bevorstehende 24-Stunden-Durchschnitt, dann wird der Speicher beladen. Was genau "deutlich geringer" heißt, kann über einen Schwellenwert konfiguriert werden. Ein Beispiel wäre `70%`, das bedeutet: Das günstigste Zeitfenster muss 70% der Kosten des 24-Stunden-Durchschnitts **unterschreiten**.
- Der SENEC-Speicher hat die Besonderheit, dass eine durchgeführte Netzbeladung auch explizit freigegeben werden muss. Ansonsten würde zwar geladen, danach aber der Verbrauch weiterhin aus dem Netz gedeckt. Die Logik prüft also, ob eine Beladung das Maximum erreicht hat. Maximum bedeutet, dass sich der Füllstand nicht weiter erhöht. Es wird also nicht einfach auf 100% Ladestand gewartet, weil es ja auch gedrosselte Geräte gibt, die maximal 70% Ladestand erreichen. Ist das Maximum erreicht, wird die Beladung freigegeben.
Wie die Logik sich jeweils entscheidet, wird im Log ausgegeben. Es empfiehlt sich, gerade in der ersten Zeit nach Installation das Docker-Log genau im Auge zu behalten.
Wer unsicher ist, kann das Tool auch in einem "Dry-Run-Modus" laufen lassen, der fast alle Schritte durchführt - nur nicht die tatsächliche Beladung oder Beladungsfreigabe.
### Einschränkungen, Fallstricke und Pferdefüße
Der rote Kasten ist etwas größer geworden. Bitte in Ruhe lesen, bevor du das Tool installierst!
> **Wichtige Hinweise**
>
>
> - Ob eine Beladung aus dem Netz wirklich lohnenswert ist, muss jeder für sich selbst entscheiden. Es gibt Ladeverluste und ein Akku wird durch häufiges Be- und Entladen sicherlich nicht besser.
>
> - Zu beachten ist unbedingt, dass durch das Beladen des Speichers mit sogenanntem Graustrom die **EEG-Vergütung (Einspeisevergütung) erlischt**. Details lassen sich bei der [EEG-Clearingstelle](https://www.clearingstelle-eeg-kwkg.de/haeufige-rechtsfrage/181) nachlesen.
>
> - Ob und wie sich eine manuelle Beladung aus dem Netz durch eine automatische Steuerung auf die SENEC-Garantie auswirkt, kann ich nicht beurteilen. Ich übernehme keinerlei Haftung, weder für defekte Stromspeicher, hohe Stromrechnungen, Verlust der EEG-Vergütung, abgebrannte Häuser oder sonstige Schäden.
>
> - Jede Beladung und Beladungsfreigabe wird im Log des Speichers protokolliert. SENEC bekommt das also mit. Da sich die Funktion aber auch über die Web-Oberfläche des Speichers auslösen lässt, handelt es sich nicht um eine Geheimwissenschaft.
>
> - Ob SENEC die Existenz des Tools gutheißen oder zumindest tolerieren wird, kann ich nicht sagen. Ich habe keine Kontakte zu SENEC und habe das Tool ohne deren Wissen entwickelt. Falls jemand von SENEC dies liest - ich freue mich über einen Gedankenaustausch, zumindest wenn dieser nicht über eine Anwaltskanzlei erfolgt.
>
> - Sollte SENEC irgendwann die lokale Schnittstelle des Speichers dahingehend ändern, dass eine manuelle Vollladung nicht mehr durchgeführt werden kann, kann das Tool nicht mehr verwendet werden.
>
> - Unterstützt wird nur der SENEC.Home V3 und V2.1, nicht aber der V4. Getestet wurde es außerdem nur mit dem V3, beim V2.1 sind aber keine Unterschiede zu erwarten.
>
> - Das Abholen von Strompreisen funktioniert derzeitig nur mit Tibber. Andere Anbieter dynamischer Stromtarife werden derzeitig nicht unterstützt.
>
> - Das Tool ist noch sehr neu und kaum getestet. Fehler sind also nicht unwahrscheinlich. Bei technischen Problemen bitte ein [Issue auf GitHub](https://github.com/solectrus/senec-charger/issues) erstellen.
>
### Installation und Dokumentation
Die Installation auf einem lokalen Server (wie z.B. einem Raspberry oder NAS) erfordert Linux- und Docker-Kenntnisse. Wer SOLECTRUS installiert bekommen hat, wird das aber auch schaffen. Es geht letztendlich um zwei weitere Docker-Container, die über Umgebungsvariablen konfiguriert werden. Dokumentation gibt es bislang kaum, aber das wird sich vielleicht noch ändern.
Auf GitHub steht alles bereit:
- https://github.com/solectrus/senec-charger/
- https://github.com/solectrus/tibber-collector
> **Sponsoring**
>
>
> Ich freue mich besonders, dass durch Sponsoring ein Teil des Entwicklungsaufwands finanziert wurde. Die Firma [EP: Bölsche Frikom GmbH](https://www.ep-boelsche.de/) aus Berlin hat die Entwicklung beauftragt. Herzlichen Dank dafür!
>
> Da ich aber nicht nur für Geld arbeite, sondern auch für die Freude an der Sache, ist das Tool OpenSource und kostenlos verfügbar. Weitere finanzielle Unterstützung ist dennoch sehr willkommen.
>
> Du hast Interesse an einer Zusammenarbeit? Deine Firma benötigt eine individuelle Lösung oder ein besonderes Feature für SOLECTRUS? Dann sollten wir darüber reden !
>
---
# Neue Kachel-Darstellung
_2023-12-03_
> Ausgewählte Messwerte als große Kacheln auf einer eigenen Seite, auch aus einigen Metern noch ablesbar. Dazu eine neue Seitenleiste.
Das letzte Update ist schon eine Weile her, aber nun ist es endlich soweit: Version **0.14** ist verfügbar. Es gibt einige interessante Neuerungen, die ich vorstellen möchte.
## Einzelwerte in Kachel-Darstellung
Die größte Neuerung ist die Darstellung ausgewählter Messwerte in Form von Kacheln auf einer separaten Seite. Das ist insbesondere dann nützlich, wenn man eine Darstellung benötigt, die auch aus der Ferne gut sichtbar ist.
Dargestellt wird der Photovoltaik-Ertrag für verschiedene Zeiträume sowie die CO₂-Einsparung und die eingesparten Stromkosten im laufenden Jahr. In einer Titelzeile können Angaben zum Betreiber und zur PV-Anlage dargestellt werden.
> **Sponsored Feature**
>
>
> Ich freue mich besonders, dass diese Funktion als "Sponsored Feature" realisiert werden konnte. Die Firma [EP: Bölsche Frikom GmbH](https://www.ep-boelsche.de/) aus Berlin hat die Entwicklung dieser Funktion beauftragt und finanziert. Vielen Dank dafür!
>
> Ziel der Zusammenarbeit war es, ausgewählte Messwerte in prägnanter Form auf einem Digital-Signage-System zu präsentieren und damit Laufkundschaft auf die Photovoltaik-Anlage aufmerksam zu machen.
>
> In einem separaten Blog-Beitrag werde ich demnächst etwas mehr über diese Art der Entwicklungs-Finanzierung schreiben, vielleicht ist das ja auch für andere interessant.
>
Aus dem Sponsoring resultiert auch, dass die dargestellten Kacheln derzeitig fix sind, das heißt, sie sind nicht änderbar. Das muss für die Zukunft aber nicht so bleiben.
## Einstellungen verbergen
Wenn man seine SOLECTRUS-Installation öffentlich betreibt, möchte man vielleicht nicht unbedingt, dass jedermann die gezahlten Strompreise, die Einspeisevergütung oder andere Einstellungen sehen kann. Diese Dinge waren auch in früheren Versionen immer nur für den Admin zu **ändern**, aber nun sind sie auch nur für den Admin zu **sehen**.
Nicht vergessen: Das Admin-Passort hast Du selbst festgelegt, als Du SOLECTRUS installiert hast. Es findet sich in der `.env`-Datei als `ADMIN_PASSWORD`.
## Vollbildmodus
Um den verfügbaren Platz besser auszunutzen, lässt sich nun der Vollbildmodus des Browsers aktivieren. Das ist insbesondere dann nützlich, wenn ein Tablet oder andere Gerät verwendet wird, das sonst keine Möglichkeit bietet, das Browser-Interface auszublenden.
## Neue Seitenleiste
Zu viele Icons sind unübersichtlich. Deshalb wurde die Navigation überarbeitet und es gibt eine Seitenleiste, die bei Bedarf geöffnet werden kann.
## Stromverbrauch reduziert
Kein Witz - SOLECTRUS verbraucht nun tatsächlich weniger Strom. Die Fluss-Animation und der pulsierende Status-Indikator hatten sich als unnötig CPU-belastend und damit als Stromfresser herausgestellt. Die Animationen wurden deshalb entfernt.
## Und sonst noch?
- Auf Mobilgeräten erfolgt jetzt eine verbesserte Nutzung des verfügbaren Platzes
- Außerdem wurden viele Abhängigkeiten aktualisiert, so läuft SOLECTRUS nun auf Basis von Ruby on Rails in der aktuellen Version 7.1
- Es gab einige kleinere Fehler, die behoben wurden und SOLECTRUS robuster machen
---
# Version 0.13.2 verfügbar
_2023-10-01_
> Das Update bringt eine verbesserte Statusanzeige und zeigt eine etwaige Einspeisebegrenzung an. Fehlerbehebungen gibt es natürlich auch.
Ein neues Update ist da, nachdem es in den letzten Wochen etwas ruhiger war. Es bringt einige Detailverbesserungen und Fehlerbehebungen. Eigentlich sollte es die Version `0.13.1` sein. Ein kurzfristig entdeckter Fehler macht aber ein weiteres Update auf die Version `0.13.2` notwendig.
Hier die wichtigsten Änderungen im Einzelnen:
## Differenziertere Status-Anzeige
Ein SENEC-Speicher liefert einen Statuscode mit einem Wert zwischen 0 und 98. Einige Werte repräsentieren den Normalzustand ("Laden", "Entladen", "Peak-Shaving: Warten" und einige mehr), die anderen stehen für Probleme jeder Art. Ein Statuscode, der nicht zum Normalbetrieb gehört (z.B. "NPU-Fehler"), wird nun farblich hervorgehoben angezeigt.
Diese Situation ist zu unterscheiden von einer verlorenen Verbindung, wenn also überhaupt kein aktuelle Messung vorliegt. Dies wird nun als "Keine Verbindung" angezeigt (anstelle des bisherigen "FAIL").
Wenn kein genauer Statuscode bekannt ist (z.B. bei Verwendung des MQTT-Collectors), wird "Verbunden" angezeigt (anstelle des bisherigen "LIVE").
## Darstellung von aktiver Einspeisebegrenzung
Je nach Größe, Alter und Konfiguration der PV-Anlage kann es sein, dass die Einspeisung auf 70% der PV-Leistung begrenzt wird. Wenn ein solcher Zustand erkannt wird (verursacht durch hohe Erzeugung bei gleichzeitig geringem Eigenverbrauch), wird dies nun in der Grafik angezeigt.
Sieht man einen solchen Hinweis ist, ist das eine gute Gelegenheit für Waschmaschine, Geschirrspüler und Co.
> **Zu beachten**
>
>
> Die (reguläre) Einspeisebegrenzung hat nichts mit dem Konditionierungsmodus zu tun, der von SENEC derzeitig bei einigen Speichern aus Sicherheitsgründen aktiviert wurde.
>
## Aktualisierungs-Intervall einstellbar
Die Häufigkeit der Messwert-Aktualisierung kann nun über die Umgebungsvariable `INFLUX_POLL_INTERVAL` eingestellt werden. Der Standardwert ist 5 Sekunden.
Wenn man also die (schon immer vorhandene) Variable `SENEC_INTERVAL` auf einen höheren Wert als die standardmäßigen 5 Sekunden gesetzt hat, kann man das Dashboard daran anpassen. `SENEC_INTERVAL` und `INFLUX_POLL_INTERVAL` sollten den gleichen Wert haben.
> **Übersicht**
>
>
> - `SENEC_INTERVAL` Wie oft werden Messwerte durch den SENEC-Collector vom Speicher abgerufen und an InfluxDB übertragen?
> - `INFLUX_POLL_INTERVAL` Wie oft sollen die Messwerte von InfluxDB abgefragt und im Dashboard angezeigt werden?
>
Die neue Variable ist auch dann nützlich, wenn bei Verwendung des MQTT-Collector seltener als alle 5 Sekunden Messwerte übertragen werden. Es lässt sich dann vermeiden, dass der Status "Keine Verbindung" angezeigt wird.
## Solarprognose für mehrere Dachflächen
Falls du Solarmodule auf mehr als nur einer Dachfläche installiert hast, kann dies bei der Solarprognose berücksichtigt werden. Der Forecast-Collector (ab [Version 0.4.0](https://github.com/solectrus/forecast-collector/releases/tag/v0.4.0)) kann nun entsprechend konfiguriert werden.
Eine genaue Anleitung für die Konfiguration findet sich hier: \
https://github.com/orgs/solectrus/discussions/2396
## Verbesserte Effizienz bei der Messwertabfrage
Der SENEC-Collector (ab [Version 0.10.0](https://github.com/solectrus/senec-collector/releases/tag/v0.10.0)) nutzt nun eine [persistente Verbindung](https://en.wikipedia.org/wiki/HTTP_persistent_connection), um Messwerte vom Speicher abzurufen. Dies bedeutet, dass die Verbindung nach dem Erhalt eines Messwerts nicht getrennt, sondern für die nächste Abfrage offen gehalten wird. Der folgende Messwert wird nach 5 Sekunden über dieselbe bestehende Verbindung abgerufen.
Diese Methode ist signifikant effizienter im Vergleich zur alten Vorgehensweise, bei der für jeden einzelnen Messwert eine neue Verbindung etabliert wurde. Dies ist besonders vorteilhaft bei Verbindungen über `https`, da der SSL/TLS-Handshake entfällt. Während dies für SOLECTRUS kaum Auswirkungen hat, entlastet es den SENEC-Speicher erheblich.
Laut meinen Messungen dauerte der Abruf eines Messwerts unter Einbeziehung des Verbindungsaufbaus etwa 250 ms. Mit einer persistenten Verbindung reduziert sich die Zeit für den einzelnen Abruf auf lediglich 8 ms, was einer Verbesserung um den **Faktor 30** entspricht.
## Fehlerbehebungen
Diverse kleinere Problemchen konnten abgestellt werden:
- Bei Uhrzeitabweichungen zwischen Server und Browser kommt es nicht mehr zu Darstellungsfehlern in den Diagrammen.
- Die Berechnung der Autarkie erfolgt nun auch dann korrekt, wenn es keinen Verbrauch gibt, was beispielsweise bei Verwendung eines Balkonkraftwerks der Fall sein kann.
- Bei unterbrochener Verbindung werden jetzt nicht mehr sehr alte Messwerte angezeigt, sondern die Anzeige wechselt nach einer Stunde auf eine leere Darstellung.
---
# Erfahrungen mit dem SENEC-Update
_2023-09-06_
> Was sich beim Zugriff auf den internen Webserver des Speichers nach dem Firmware-Update ändert. Beobachtungen aus Sicht eines Software-Entwicklers.
Wie [kürzlich beschrieben](/blog/2023-08-18-unterstuetzung-fuer-neue-senec-firmware/), hat SENEC die Firmware des Speichers aktualisiert und damit einige Dinge geändert. Entsprechend groß ist der Wirbel in den User-Foren und auf Facebook. Dieses Update ist heute auch bei mir angekommen und ich möchte meine Beobachtungen dazu mitteilen - aus Sicht eines Software-Entwicklers.
> **Hinweis**
>
>
> Ob und wie sich das Update stromtechnisch auswirkt, lasse ich in diesem Beitrag völlig außen vor. Gleiches gilt für den derzeitig laufenden Konditionierungsbetrieb, von dem ich auch nicht betroffen bin und daher nicht beurteilen kann. Ich betrachte hier nur den Zugriff auf den integrierten Webserver.
>
> Ich betreibe auch **kein** SENEC-Bashing. Als Entwickler weiß ich zu gut, dass Fehler nie ganz zu vermeiden sind. Dass mein SENEC.Home V3 seit mittlerweile 3 Jahren wartungsfrei durchläuft und dabei automatisiert mit Updates versorgt wird, finde ich beachtlich.
>
Die Firmware des SENEC-Speichers besteht aus verschiedenen Komponenten (MCU, NPU, GUI etc.), die nacheinander aktualisiert werden. Der Speicher startet dabei mehrmals neu, das Ganze zieht sich über Stunden hin. Es finden diverse Tests zwischendurch statt (Selbsttest, Batteriediagnose).
Während ich diese Zeilen schreibe, ist der Versionsstand meines Speichers wie folgt:
- REVISION MCU: **0825**
- REVISION MCU-BL: **2307**
- REVISION NPU-REGS: **10**
- REVISION NPU-IMAGE: **2106**
- REVISION GUI: **0966**
**Ergänzung 07.09.2023:** Heute kam eine weiteres Update hinzu:
- REVISION NPU-IMAGE: **2309**
**Ergänzung 18.09.2023:** Die NPU wurde erneut aktualisiert:
- REVISION NPU-IMAGE: **2310**
**Ergänzung 04.10.2023:** Heute wurde MCU erneut aktualisiert:
- REVISION MCU: **0826**
Nun zur Aufstellung dessen, was sich aus meiner Sicht geändert hat:
## API-Änderungen
Die JSON-API, die vom Speicher bereitgestellt wird (das allseits bekannte `/lala.cgi`, das von allen Tools zum Abgreifen von Messwerten benutzt wird, auch von SOLECTRUS), liefert die Daten mit etwas anderer Strukturierung zurück. Einige Werte sind auch ganz verschwunden. Das macht eine Anpassung aller Tools erforderlich, die darauf zugreifen.
Hier zwei Dinge, die ich für SOLECTRUS anpassen musste:
1. Einen genauen Zeitstempel der Messung gibt es offenbar nicht mehr, zuvor stand dieser in `STATISTIC.MEASURE_TIME`. SOLECTRUS bedient sich nun bei `RTC.WEB_TIME`. Das erscheint mir als eine Verschlechterung der Messgenauigkeit, weil dies offenbar die Uhrzeit des Speichers ist, nicht der Zeitpunkt der Messung. Die zu erwartende Abweichung dürfte sich aber nur minimal auswirken.
2. Der Status des Speichers steht nicht mehr in `STATISTIC.CURRENT_STATE`, sondern in `ENERGY.STAT_STATE`.
## URL-Änderungen
Die URL einiger Webseiten hat sich minimal geändert, es ist jetzt eine veränderte Groß-/Kleinschreibung zu beachten. Das betrifft die folgenden Seiten:
- Log-Viewer: `/log.html` => `/Log.html`
- Tages-Logs als reiner Text: `/log/yyyy/mm/dd.log` => `/Log/yyyy/mm/dd.log`
- Display-Anzeige: `/display.html` => `/Display.html`
- Variablen: `/vars.html` => `/Vars.html`
- Diagramme: `/chart.html` => `/Chart.html`
Die alten URLs führen zu einer Fehlermeldung "Unauthorized" (http-Status `401`). Dies lässt einige User vermuten, dass SENEC nützliche Informationen vor allzu neugierigen Blicken absichtlich verbergen möchte. Für mich sieht das aber eher nach unbeabsichtigten Fehlern aus, die SENEC vermutlich bald korrigieren wird.
Klar ist aber auch: Dass es kein automatisches URL-Redirect gibt, ist unschön.
**Ergänzung 04.10.2023:**
Die URLs haben sich erneut geändert, es ist sind jetzt **zwei** Slashes nach der IP-Adresse notwendig:
- Log-Viewer: `//Log.html`
- Tages-Logs als reiner Text: `//Log/yyyy/mm/dd.log`
- Display-Anzeige: `//Display.html`
- Variablen: `//Vars.html`
- Diagramme: `//Chart.html`
## Umstellung auf https
Der Zugriff auf den Speicher ist nur noch per `https` möglich, nicht mehr per `http`. Leider wurde das unschön implementiert, denn es gibt keinen automatischen Redirect von http zu https.
Alle Tools, die direkt auf den Speicher zugreifen, müssen also zwingend angepasst werden. Das betrifft natürlich SOLECTRUS, aber auch ioBroker, Home Assistant, evcc, etc. Soweit ich das mitbekomme, stehen solche Updates aber auch bereit. Alle haben eines gemeinsam: Als User muss man die Zugriffsmethode (engl. "Schema", hier `http` oder `https`) manuell und explizit einstellen.
Die Umstellung von `http` auf `https` scheint übrigens zuletzt dran zu kommen, bei mir ist sie jedenfalls noch gar nicht erfolgt, mein Speicher werkelt noch auf `http`. Ein SOLECTRUS-User hatte die [Vermutung geäußert](https://github.com/solectrus/senec-collector/issues/224#issuecomment-1698827094), dass erst das NPU-Update die Umstellung auf `https` bewirkt. Das könnte stimmen, denn bei mir ist die Revision des NPU-Images bislang unverändert bei `2106`.
**Ergänzung 07.09.2023:** Seit heute ist auch bei mir die Umstellung auf `https` erfolgt, nachdem das NPU-Image auf `2309` aktualisiert wurde. Insofern stimmt die obige Vermutung.
Eine weitere, etwas unschöne Sache bezüglich `https` sei erwähnt: Der Datenverkehr wird zwar nun verschlüsselt, was grundsätzlich eine gute Sache ist.
**ABER:** Das für `https` prinzipiell erforderliche Zertifikat ist selbst-signiert, sodass der Browser die Gültigkeit nicht bestätigen kann:
Je nach Browser wird dadurch eine mehr oder weniger alarmistische Warnung ausgegeben. Diese Warnung gilt es zu ignorieren.
Ich denke, hier hat SENEC einen Kompromiss gewählt: Einerseits wird der Datenverkehr nun verschlüsselt, was eine Verbesserung darstellt. Denn über den Webserver werden auch Passwörter verschickt, nämlich wenn der Installateur den Speicher in den Admin-Modus versetzt. Andererseits wurde die Warnmeldung bezüglich der Signierung in Kauf genommen.
Mir ist übrigens kein Weg bekannt, mit der SENEC diese Warnmeldung hätte verhindern können, ohne dem User noch mehr zuzumuten. Eine Aufforderung zur Installation eines Root-Zertifikats hätte zu weiteren Irritationen geführt. Ein solcher Hinweis tauchte übrigens vor einigen Tagen in der SENEC-App auf, wurde aber offenbar wieder entfernt.
**Ergänzung 10.09.2023:** Inzwischen hat SENEC auf `mein-senec.de` im Bereich "Allgemeine Dokumente" tatsächlich ein Zertifikat mit der Bezeichnung `SenecGui-Root` bereitgestellt. Dieses Root-Zertifikat kann man sich installieren und als vertrauenswürdig einstufen, aber das ist kein trivialer Vorgang. Ich habe das mal gemacht und kann bestätigen, dass die Warnmeldung im Browser dann verschwindet. Aber das ist sicherlich keine Lösung für den normalen User.
In Firefox läuft die Installation des Zertifikats beispielsweise wie folgt ab:
- Zip-Datei von `mein-senec.de` (Allgemeine Dokumente) herunterladen und entpacken. Enthalten ist eine `.pem`-Datei
- In Firefox über Einstellungen die Zertifikatsverwaltung aufrufen, dort zum Tab "Zertifizierungsstellen" wechseln
- Button "Importieren" klicken, dann `.pem`-Datei auswählen, öffnen und per Checkbox festlegen, dass dieser CA zur Identifizierung von Websites vertraut werden soll
- Danach ist die Warnmeldung in Firefox beim Aufruf von `https://[speicher-ip]` verschwunden
## Fehler in der neuen Firmware
Soweit ich das sehe, stecken zumindest zwei Fehler in der neuen Firmware, die in den verschiedenen User-Foren für größere Aufregung sorgen:
### 1. Display-Anzeige ohne Werte
Unter `/Display.html` erscheine eine leere Anzeige, es sieht folgendermaßen aus:
Es ist also nur das Layout zu sehen, die eigentlich anzuzeigenden Werte fehlen. Schaut man in die DevTools des Browsers, stellt sich schnell heraus, dass die Seite bestimmte Variablen per `/lala.cgi` abfragt, die es in der API gar nicht mehr gibt:
```json
{ "DISPLAY": { "IMAGE": "VARIABLE_NOT_FOUND", "LEDS": "VARIABLE_NOT_FOUND" } }
```
Das ist ein Fehler und vermutlich keine Absicht. Hier wird SENEC sicherlich nachbessern - entweder, indem die API diese Variablen in einer zukünftigen Version wieder zurückliefert **oder** indem die Seite `/Display.html` ganz entfernt wird.
**(Ergänzung 02.10.2023)**
Laut einer Ankündigung von SENEC hat man sich dort für die zweite Möglichkeit entschieden - die Display-Anzeige wird in Kürze **wegfallen**. Weitere Informationen dazu finden sich im Abschnitt "Häufige NPU-Fehler" weiter unten.
**(Ergänzung 04.10.2023)**
Die Display-Anzeige ist auch durch das Update auf MCU-Version 826 **nicht** entfernt worden, es hat sich aber die URL auf `//Display.html` geändert. Der Fehler mit der leeren Anzeige ist geblieben.
### 2. Lov-Viewer bleibt leer
Unter `/Log.html` erscheint ebenfalls eine leere Anzeige, es sieht folgendermaßen aus:
Auch das dürfte keineswegs Absicht sein, ein Blick in die Browser-Devtools verrät die Details:
```
Request URL: /log/2023/09/06.log
Request Method: GET
Status Code: 401 Unauthorized
```
Der aufmerksame Leser erkennt den Fehler sofort: Die URL stimmt einfach nicht, der Log-Viewer greift auf die alte URL mit `/log` zu, nicht auf die neue, die ja auf `/Log` lautet. SENEC hat einfach vergessen, den Programmcode des Log-Viewers anzupassen. Ein ganz banaler Fehler. Auch hier wird es sicherlich ein weiteres Update geben.
**(Ergänzung 04.10.2023)**
Auch hier hat sich die Adresse geändert, nun lautet es `//Log.html`. Die Anzeige ist aber weiterhin leer, weil intern unverändert die alte URL (mit `/log`) aufgerufen wird.
### 3. Häufige NPU-Fehler
**(Ergänzung 09.09.2023)**
Im Log finden sich seit den Updates häufige Mitteilungen wie diese:
```
2023-09-09 03:14:32 [I|NPU] Switched off
2023-09-09 03:15:03 [I|Energy Management] State: Entladen -> NPU-Fehler
2023-09-09 03:15:07 [I|NPU] Correctly started
2023-09-09 03:15:10 [I|NPU] Communication established
2023-09-09 03:15:11 [I|NET] IP address changed from 192.168.178.29 to unconnected (255.255.255.255).
2023-09-09 03:15:11 [I|NPU] NPU: Change backend server to 0
2023-09-09 03:15:18 [I|NPU] NPU: image version 2309-b5746b50
2023-09-09 03:15:18 [I|NPU] NPU: protocol version 10 (0xB574)
2023-09-09 03:15:20 [I|NET] IP address changed from unconnected (255.255.255.255) to 192.168.178.29.
2023-09-09 03:15:41 [I|Energy Management] State: NPU-Fehler -> Netz & Entladen
```
Bei mir passiert das etwa 10 Mal am Tag. Während dieses etwa eine Minute dauernden Vorgangs ist der Speicher über das Netzwerk nicht erreichbar und zeigt im Display die Meldung `NPU-Fehler` an. Tools wie der SENEC-Collector von SOLECTRUS können in dieser Zeit keine Messwerte abfragen.
NPU ist die Kommunikationseinheit,
also der Teil des Speichers, der für den Netzwerkzugang zuständig ist. Offenbar
wird die NPU neu gestartet, vielleicht weil irgendein Problem festgestellt
wurde, das im Log nicht erwähnt wird. Die Auswirkungen sind recht gering, aber
normal ist das sicherlich nicht.
Da die Logs automatisch an SENEC übertragen werden, dürfte dort das Problem bekannt sein. Potential für weitere Updates ist also vorhanden.
**(Ergänzung 15.09.2023)**
Die Protokollierung von `Switched off` und die damit verbundene Anzeige von `NPU-Fehler` im Display traten bei mir nach dem Firmware-Update insgesamt fünf Tage lang auf und wurden 73 Mal im Log vermerkt, also alle 1-2 Stunden. Dann hört es plötzlich auf, seit mittlerweile vier Tagen findet sich die Meldung nicht mehr im Log. Die Installation eines weiteren Updates kann ich nicht erkennen. Von anderen Usern höre ich ähnliches.
Völlig **spekulative**, aber denkbare Erklärung: Im Rahmen des Firmware-Updates lief ein mehrtägiger Prozess im Gerät ab, der viel Rechenleistung verschlungen hat (Prüfvorgänge, Aufräumen oder was auch immer). Ein Watchdog-Modul hat das erkannt und die NPU sicherheitshalber bei einer bestimmten Schwelle neu gestartet. Nach Fertigstellung des Prozesses ist die Auslastung wieder normal und der Watchdog greift nicht mehr ein.
**(Ergänzung 02.10.2023)**
Zwischenzeitlich ist der NPU-Fehler bei mir sporadisch wieder aufgetreten. Das Problem ist also nicht aus der Welt.
In diesem Zusammenhang findet sich seit heute in der SENEC-App der Hinweis, dass in Kürze (ab dem 04.10.2023) ein weiteres Firmware-Update (826) kommen wird, das u.a. den "NPU-Fehler" beheben soll. Ich bin gespannt. Leider wird außerdem angekündigt, dass die Funktionen `/Display.html` und `/Vars.html` nicht mehr unterstützt werden.
Begründet wird der Wegfall mit der Optimierung des Speicherverbrauchs der Firmware und der allgemeinen Erhöhung der Sicherheitsstandards. Zumindest wird dies in einem Schreiben von SENEC an die Installateure so dargestellt, das derzeitig auf Facebook kursiert.
`/Vars.html` ist eine Komfortfunktion, die sämtliche Variablen und Messwerte aus dem Speicher abruft und tabellarisch darstellt. Durch den Wegfall dieser Funktion ist es aber **nicht** so, dass man an diese Daten gar nicht mehr herankommt. `/Vars.html` verwendet intern die API (`/lala.cgi`) die es weiterhin gibt. Es fällt nur der bequeme Zugriff über den Browser weg. Für neugierige, aber weniger versierte User ist das allerdings eine deutliche Einschränkung.
**(Ergänzung 04.10.2023)**
Das von SENEC angekündigte MCU-Update auf Version 826 ist bei mir heute angekommen. Neustart und Selbsttest liefen problemlos durch, der Speicher ist wieder erreichbar. SOLECTRUS funktioniert unverändert weiter. Ob sich die NPU-Fehler dadurch wirklich erledigt haben, wird sich zeigen.
Der angekündigte Wegfall von `/Display.html` und `/Vars.html` ist nicht erfolgt, die URLs haben sich aber erneut geändert. Sie lauten nun `//Display.html` und `//Vars.html`, die bekannten Fehler der leeren Anzeige sind aber geblieben.
**(Ergänzung 06.10.2023)**
Auch nach dem MCU-Update auf 826 ist heute in meinem Speicher ein NPU-Fehler aufgetreten, der zu einer 10-minütigen Nichterreichbarkeit geführt hat. Das Thema ist also noch nicht durch.
### Ausblick
Soweit der aktuelle Stand. Ich bin gespannt, wie es weitergeht. Ich werde diesen Beitrag aktualisieren, sobald es Neuigkeiten gibt.
> **Funfact**
>
>
> Aus Entwicklersicht erheiternd ist, dass SENEC im aktualisierten GUI auch die JavaScript-Bibliothek [jQuery](https://jquery.com/) aktualisiert hat: Statt jQuery `3.2.1` (aus dem Jahr 2017) kommt nun jQuery `3.6.1` (aus 2022) zum Einsatz.
>
> Der Einsatz von jQuery ist **der** Legacy-Indicator schlechthin - ok, dieses Bashing konnte ich mir dann doch nicht verkneifen :-)
>
---
# Unterstützung für neue SENEC-Firmware
_2023-08-18_
> SENEC aktualisiert die Firmware des Speichers auf Revision MCU 3825 und stellt damit auf https um. Das macht eine Anpassung des SENEC-Collectors erforderlich.
Derzeit rollt SENEC ein Firmware-Update aus, dass es in sich hat - es ändert nämlich die API, über die SOLECTRUS mit dem Speicher kommuniziert. Das führt dazu, dass SOLECTRUS nicht mehr funktioniert, wenn die neue Firmware installiert ist.
Die neue Firmware hat die Versionsnummer `Revision MCU 3825`, möglicherweise gibt es aber auch andere Versionen, die die API ändern. Ob man die neue Firmware hat, erkennt man sicher daran, ob die Webseite des Speichers über `http` (alte Firmware) oder über `https` (neue Firmware) erreichbar ist. Sobald die neue Firmware installiert ist, funktioniert SOLECTRUS nicht mehr, d.h. es werden keine neuen Messwerte mehr angezeigt. Das ist nicht so schön.
Wann genau dein Speicher von SENEC aktualisiert wird, weiß nur SENEC. Du solltest aber darauf vorbereitet sein, dass es in den nächsten Tagen oder Wochen passieren kann.
Die gute Nachricht: In Zusammenarbeit mit betroffenen SOLECTRUS-Benutzern habe ich eine Lösung erarbeiten können und ein Update für den SENEC-Collector veröffentlicht, das die neue Firmware unterstützt.
## Update des SENEC-Collectors installieren
Nutzer von SOLECTRUS, bei denen die neue Firmware bereits auf dem SENEC-Speicher angekommen ist, müssen ein Update des SENEC-Collectors installieren. Das geht wie folgt:
1. In der Datei `.env` muss die Zeile `SENEC_SCHEMA=https` ergänzt werden
2. In der Datei `docker-compose.yml` muss unter `services.senec-collector.environment` der Eintrag `SENEC_SCHEMA` ergänzt werden (damit die Variable aus der `.env`-Datei auch im Container ankommt)
3. Das aktualisierte Docker-Image muss jetzt geholt werden, das geht mit:\
`docker compose pull`
4. Abschließend müssen die Container neu gestartet werden, wie üblich geht das mit:\
`docker compose up -d`
(Bei älteren Versionen von Docker, z.B. auf einem Synology-NAS, bitte `docker-compose` statt `docker compose` verwenden)
> **Wichtig**
>
>
> Ergänze die Zeile `SENEC_SCHEMA=https` erst dann, wenn Du festgestellt hast, dass der Speicher im Browser wirklich über `https` erreichbar ist. Es ist leider so, dass die Website der alten Firmware **nur** über `http` erreichbar ist, die Website der neuen Firmware hingegen **nur** über `https`.
>
Nach diesen Schritten sollte SOLECTRUS wieder funktionieren. Falls nicht, bitte im [Forum auf GitHub](https://github.com/orgs/solectrus/discussions) melden.
Technische Hintergrundinformationen finden sich im zugehörigen Issue auf GitHub:\
https://github.com/solectrus/senec-collector/issues/224
---
# Version 0.13 verfügbar
_2023-08-13_
> Das Update enthält Fehlerbehebungen und führt die Registrierung ein. Unterstütze die weitere Entwicklung, indem du deine Instanz registrieren lässt!
Ein neues Update für SOLECTRUS ist verfügbar. Diesmal stehen vor allem Fehlerbehebungen und die Einführung einer Registrierung im Mittelpunkt.
## Die Registrierung
Es ist bereits über zwei Jahre her, seit ich die erste Version von SOLECTRUS veröffentlicht habe. Ehrlich gesagt hätte ich nicht erwartet, dass sich so viele Menschen für dieses Projekt begeistern würden. Das zahlreiche Feedback lässt zwar großes Interesse erahnen, konkrete Nutzerzahlen habe ich jedoch bisher nicht. Um das zu ändern und SOLECTRUS gezielt weiterzuentwickeln, führe ich nun die Registrierung durchgeführter Installationen ein.
Nach Installation der aktuellen Version `0.13` wirst du daher einen gelben Hinweisbalken bemerken:
Falls du nicht als Administrator eingeloggt bist, sieht du stattdessen nur den Hinweis, dich für die Registrierung zunächst als Admin einzuloggen. Fragen dazu? Die [Anleitung](/docs/bedienung/administrator/) hilft dir weiter!
Ein Klick auf `Jetzt registrieren` leitet dich zu einem Formular, das du weitestgehend anonym ausfüllen kannst. Lediglich eine E-Mail-Adresse wird benötigt, sodass ich dich bei Bedarf kontaktieren kann. Keine Sorge: Dein Posteingang wird nicht überflutet, und deine Daten werden vertraulich behandelt und nicht an Dritte weitergegeben.
Deine Registrierung unterstützt mich bei der Planung und Weiterentwicklung von SOLECTRUS. Ein großes Dankeschön für dein Engagement und das entgegengebrachte Vertrauen!
## Fehlerbehebungen
- In der `JETZT`-Ansicht konnte es passieren, dass beim Wechsel des Messwertes (z.B. von `Erzeugung` zu `Hausverbrauch`) das Diagramm nicht korrekt fortgeführt wurde. Dieser Fehler ist nun behoben.
- Wenn Messwerte verzögert eintreffen, konnte der Batterieladestand in der `JETZT`-Ansicht kurzzeitig auf 0% fallen. Auch das ist nun behoben.
## Sonstige Verbesserungen
- Die Balkendiagramme in den Ansichten `WOCHE`, `MONAT`, `JAHR` und `GESAMT` werden nun mit abgerundeten Ecken dargestellt.
- Unter der Haube wurden die verwendeten Fremdkomponenten auf den neuesten Stand gebracht, jetzt läuft SOLECTRUS mit den aktuellsten Versionen von Ruby on Rails und anderen Bibliotheken.
---
# Version 0.12 verfügbar
_2023-07-08_
> In der Top-10 wird die Peak-Leistung dargestellt. Außerdem gibt es ansprechendere Diagramme und Verbesserungen für große Displays
Ein weiteres Update steht bereit, Folgendes hat sich getan:
## Neuerungen
- In der Top-10 lässt sich neben der Energie (in kWh) nun auch die höchste erreichte Leistung (in kW) ermitteln. Damit kannst du herausfinden, ob und wann deine PV-Anlage die theoretische Peak-Leistung der Module erreicht hat.
Hier im Screenshot zu sehen: Die Module (mit einem Nominalwert von **9,24 kWp**) erzielen tatsächlich bis zu **10,5 kW** - gemittelt über 5 Minuten. Damit kann man zufrieden sein.
Wenn du den Zeitraum auf "Jahr" stellst, kannst du außerdem die Degradation ermitteln, also die unvermeidliche Leistungsreduktion der Solarmodule im Laufe der Zeit. Aber auch die maximale Ent- und Beladeleistung des Akkus oder die höchste Leistungsaufnahme des Hauses sind interessante Werte, die du jetzt ermitteln kannst.
## Verbesserungen
- Die Diagramme kommen nun in einer aufpolierten Darstellung daher. Zusammen mit einem Farbverlauf und einer interpolierten Darstellung von Liniendiagrammen sehen sie jetzt deutlich ansprechender aus.
- Auf sehr großen Displays wird der zur Verfügung stehende Platz besser ausgenutzt, die Darstellung erscheint breiter.
- Auf Touch-Displays (Smartphone, Tablet) kann jetzt durch längeres Tippen auf ein Segment der Strombilanz der zugehörige Messwert angezeigt werden.
## Fehlerbehebungen
- Die Kompatibilität mit englisch-sprachigen Systemen wurde verbessert
---
# Version 0.11 verfügbar
_2023-06-10_
> Die Kostenberechnung zeigt jetzt, was der Netzbezug tatsächlich gekostet hat, ohne entgangene Einspeisevergütung. Top 10 auch wochenweise.
Es ist einiges passiert seit dem letzten Update. Hier sind die wichtigsten Punkte, die du wissen solltest:
## Neuerungen
- Die Kostenberechnung wurde umgebaut. Sie basiert jetzt auf den tatsächlichen Kosten anstatt auf Opportunitätskosten. Es wird jetzt also berechnet, was **tatsächlich** an Kosten (durch Netzbezug) entstanden ist. Die entgangene Einspeisevergütung, die durch den eigenen Verbrauch von Strom entsteht, wird nicht mehr berücksichtigt. Die Berechnung ist dadurch einfacher und transparenter geworden. Ein [Artikel](/docs/bedienung/kosten-berechnung/) erklärt es genauer.
- Die "Top 10"-Seite wurde erweitert, jetzt gibt es zusätzlich eine wöchentliche Ansicht.
## Verbesserungen
- Die Genauigkeit der Statistiken für Tage/Wochen/Monate wurde verbessert. Die Gruppierung der Messwerte in InfluxDB berücksichtigt jetzt nämlich die aktuelle Zeitzone, was zu präziseren Ergebnissen führt. Ja, die meisten SOLECTRUS-Nutzer dürften alle in der gleichen Zeitzone leben, daher ist das vielleicht etwas unverständlich. Aber InfluxDB rechnet standardmäßig in UTC, was nun mal von der mitteleuropäischen Sommerzeit abweicht und zu geringfügig falsch gruppierten Tagen, Monaten und Wochen führte. Nichts Dramatisches, aber jetzt ist es eben besser.
- Die Benutzeroberfläche wurde optimiert, sodass nicht mehr unnötig Daten geladen werden: Wenn du einen Wert in der Strombilanz (linke Seite) auswählst, wird nur das Diagramm (rechte Seite) neu geladen, also nicht mehr die gesamte Seite. Das hatte einige interne Umbauarbeiten notwendig gemacht.
- Die Handhabung von Tooltips auf Touch-Displays (Smartphone, Tablet) wurde deutlich verbessert. Ein Tooltip wird nun, wie man das auch erwarten würde, beim ersten Tippen angezeigt und beim zweiten wieder geschlossen.
- Die Hauptnavigation auf Smartphones und Tablets wurde optimiert. Beim Tippen auf das Menü-Icon wird der bisherige Inhalt überdeckt, nicht mehr verschoben. Das ist deutlich intuitiver.
- Das gilt auch für die auf kleinen Displays sichtbare Navigation am unteren Bildschirmrand, die eine neue Optik erhalten hat.
- Ein Link zur Dokumentation wurde in die Hauptnavigation aufgenommen. Dort gibt es z.B. zwei neue Artikel, in der die [Kosten-Berechnung](/docs/bedienung/kosten-berechnung/) sowie die [Ersparnis-Berechnung](/docs/bedienung/ersparnis-berechnung/) erklärt werden.
## Fehlerbehebungen
- Ein kleines Problem mit der Skalierung des Temperaturdiagramms wurde behoben.
---
# MQTT-Anbindung für SOLECTRUS
_2023-06-01_
> Der neue MQTT-Collector holt Messwerte von jeder Anlage, die per MQTT sendet. SOLECTRUS ist damit nicht mehr auf SENEC beschränkt.
Es gibt spannende Neuigkeiten für alle, die SOLECTRUS nicht nur mit SENEC-Stromspeichern, sondern auch mit Anlagen anderer Hersteller nutzen möchten.
Bisher war SOLECTRUS speziell auf Nutzer von SENEC-Stromspeichern ausgelegt. Der [SENEC-Collector](https://github.com/solectrus/senec-collector) sammelt Messwerte direkt vom Stromspeicher, was zwangsläufig nicht kompatibel mit Anlagen anderer Hersteller ist.
Mit dem neuen [MQTT-Collector](https://github.com/solectrus/mqtt-collector) wird diese Einschränkung nun aufgehoben. Es können jetzt Messwerte von allen Anlagen empfangen werden, die über das MQTT-Protokoll angebunden werden können. Das bedeutet, dass ab jetzt auch Anlagen von anderen Herstellern mit SOLECTRUS kompatibel sind.
MQTT (Message Queuing Telemetry Transport) ist ein weit verbreitetes Kommunikationsprotokoll, das insbesondere im Bereich des Internet der Dinge (IoT) Anwendung findet. Es ermöglicht eine sichere, zuverlässige und einfache Kommunikation zwischen verschiedenen Geräten und Plattformen. Zentrale Instanz ist der MQTT-Broker, der die Kommunikation zwischen verschiedenen Clients koordiniert.
Für die Nutzung des MQTT-Collectors ist es notwendig, dass die Messwerte von der Anlage an einen MQTT-Broker gesendet werden, wo sie dann vom MQTT-Collector abgeholt werden. Das Abfragen und Senden kann z.B. über eine Hausautomatisierungs-Software erfolgen. Bis jetzt wurde folgende Software im Zusammenspiel mit dem MQTT-Collector getestet:
- [ioBroker](https://www.iobroker.net/) (enthält einen integrierten MQTT-Broker)
- [evcc](https://evcc.io/) (benötigt einen separaten MQTT-Broker)
Auf GitHub findet sich ein erster [Erfahrungsbericht zur Nutzung von evcc mit dem MQTT-Collector](https://github.com/evcc-io/evcc/discussions/8139).
Der neue MQTT-Collector befindet sich in einem noch experimentellen Stadium. Es wäre daher großartig, wenn Ihr den Collector ausprobiert, testet und Feedback gebt! Nützliche Informationen zur Einrichtung finden sich in der [Installationsanleitung](https://github.com/solectrus/hosting).
---
# Version 0.10.1 verfügbar
_2023-05-06_
> Die Prognose reicht jetzt sechs Tage voraus, das Temperaturdiagramm beginnt bei 20 °C, und fehlende Werte erscheinen nicht mehr als Null.
Es gibt ein neues Update: SOLECTRUS hat ein paar kleinere Verbesserungen und Fehlerbehebungen erhalten, die es noch benutzerfreundlicher und ansprechender machen. Lasst uns einen Blick auf die Neuerungen werfen:
## Änderungen
- Der Vergleich der Stromerzeugnis mit der Vorhersage (z.B. "x% mehr/weniger als erwartet") erscheint jetzt nur noch dort, wo die Prognose auch im Diagramm angezeigt wird. Das ist nur bei der Tages-Darstellung der Fall, nicht aber bei Woche/Monat/Jahr/Gesamt. Bei größeren Zeiträumen hat der Vergleich außerdem nur eine beschränkte Aussagekraft, da es ja nicht um einen Wettkampf zwischen Vorhersage und tatsächlichem Ergebnis geht. Eine hohe positive Abweichung heißt nicht unbedingt, dass die PV-Anlage so toll ist, sondern möglicherweise nur, dass die Prognose ungenau war.
- Es lassen sich nun die nächsten sechs Tage anzeigen, also nicht nur der jeweils nächste Tag. Dadurch können die kostenpflichtigen Vorhersagen von [forecast.solar](https://forecast.solar) genutzt werden, die sich ja über mehrere Tage erstrecken.
- Das Temperaturdiagramm wurde optimiert: Es beginnt jetzt bei 20°C statt bei 0°C - der Strom-Speicher ist ja kein Kühlschrank. Außerdem wird eine fließendere Kurve angezeigt, da die Originalwerte ungerundet verwendet werden.
## Fehlerbehebungen
- Keine Verwirrung mehr in den Diagrammen: Fehlende Werte werden nicht mehr fälschlicherweise als `0` angezeigt.
- Tritt ein Fehler in der App auf (was hoffentlich gar nicht vorkommt), dann gibt es fortan zumindest eine schickere Darstellung dafür. Zuvor konnte es passieren, dass nur eine kryptische Nachricht wie "Content missing" erscheint.
- In der `.env`-Datei zur Konfiguration können jetzt auch Sonderzeichen verwendet werden – zuvor konnte es zu seltsamen Fehlern kommen, wenn z.B. ein Datenbank-Passwort mit einem `#` beginnt.
- Keine unnötigen Warnungen mehr im Logfile, wenn kein API-Schlüssel für den Error-Tracker _Honeybadger_ hinterlegt ist. Außer in der Demo kommt _Honeybadger_ sowieso nicht zum Einsatz.
- Kleinere Layout- und Markup-Fehler wurden behoben. Dies wird niemand spüren, gibt aber dem Entwickler ein besseres Gefühl :)
- Diverse Fremdkomponenten wurden aktualisiert, um das Dashboard noch flüssiger und schneller laufen zu lassen.
## Installation des Updates
Wie alle Updates von SOLECTRUS lässt sich auch dieses auf einfache Weise über die Kommandozeile (SSH-Login) installieren:
```bash
# Im Ordner ausführen, in dem die docker-compose.yml von SOLECTRUS liegt:
docker compose pull
docker compose up -d
```
oder (bei älteren Versionen von Docker, z.B. auf einem Synology-NAS)
```bash
# Im Ordner ausführen, in dem die docker-compose.yml von SOLECTRUS liegt:
docker-compose pull
docker-compose up -d
```
## Ausblick
Es gibt noch etliche Ideen und Verbesserungen, die ich in den nächsten Wochen und Monaten je nach verfügbarer Zeit umsetzen möchte. Einen Überblick darüber kann man sich in den [Issues auf GitHub](https://github.com/solectrus/solectrus/issues) verschaffen.
Zu guter Letzt möchte ich ein riesengroßes Dankeschön aussprechen für die Flut an wunderbaren, positiven Rückmeldungen, die in den vergangenen Wochen eingegangen sind. SOLECTRUS hat eine noch kleine, aber stetig wachsende Fan-Gemeinde – grandios!
Ein besonderer Applaus gebührt all den großzügigen Usern, die ihren Obulus in den [virtuellen Klingelbeutel](https://ko-fi.com/ledermann) geworfen haben, um die Weiterentwicklung von SOLECTRUS zu unterstützen. Vielen Dank dafür!
---
# Version 0.10 verfügbar
_2023-04-01_
> Der Ladestand des Speichers als Kurve über Tag, Monat und Jahr. Dazu der Temperaturverlauf, jetzt in einer brauchbaren Skalierung.
Kein (April-)Scherz, es gibt wieder ein Release mit weiteren neuen Features:
## Diagramme für den Verlauf des Akku-Ladestands
Der Ladestand des Speichers lässt sich nun im Zeitverlauf in einer Weise darstellen, die in der offiziellen App so nicht möglich ist. Neben der bereits schon länger vorhandenen Darstellung von Be- und Entladung (in kWh) wird der Ladestand (in Prozent) visualisiert. So lässt sich ablesen, wie voll oder leer der Akku im Zeitverlauf gewesen ist.
### Akku-Ladestand im Verlauf eines Tages
Zunächst ein Beispiel für einen Tag im März 2023: Der Akku wurde bis zum Morgen zur Hälfte geleert, bevor er dann tagsüber wieder nahezu voll geladen wurde.
### Akku-Ladestand im Verlauf eines Monats
Interessanter ist die Darstellung für einen Monat, weil jeder Tag als **Spannbreite** angezeigt wird. So lässt sich ablesen, wie der geringste und höchste Ladestand an jedem Tag war. Hier am Beispiel von März 2023 lässt sich erkennen, dass der Akku in der zweiten Monatshälfte zu keinem Zeitpunkt leer geworden ist.
### Akku-Ladestand im Verlauf eines Jahres
Noch interessanter ist die Darstellung für ein Jahr: Dargestellt wird wieder eine Spannbreite, diesmal aber für einen **durchschnittlichen** Tag im jeweiligen Monat. Gut zu sehen hier im Beispiel des Jahres 2021: In den Wintermonaten wird der Akku nicht voll, im Sommer hingegen nicht leer. Je größer ein Balken ist, desto mehr kam der Akku zum Einsatz.
Wohlgemerkt: Jeder Balken zeigt die Spannbreite vom **durchschnittlichen** Mindestladestand bis zum **durchschnittlichen** Höchstladestand des Monats an.
## Diagramme für die Temperaturverlauf
Ähnlich wird nun auch der Verlauf der Gehäuse-Temperatur dargestellt. Es werden jedoch keine Durchschnitte gebildet, sondern des absolute Maximum und Minimum, einzelne Ausreißer werden also sichtbar.
Da die Gehäuse-Temperatur erst ab Version 0.5.0 des SENEC-Collectors (vom März 2022) erfasst wird, steht für frühere Zeiträume leider kein Datenmaterial zur Verfügung. Und da in den von SENEC bereitgestellten CSV-Dateien die Temperatur leider nicht enthalten ist, sie kann auch nicht nachträglich importiert werden.
## Was noch?
- Das gewünschte Diagramm kann nun auch über ein Dropdown-Menü ausgewählt werden
- In der Top-10 werden jetzt auch sehr kleine Balken mit Zahlen beschriftet
- In den Diagrammen wurde der Hover-Effekt verbessert, d.h. beim Überfahren mit der Maus erfolgt die Anzeige des Wertes deutlicher
Ansonsten gibt es die üblichen kleinen Verbesserungen und Fehlerbehebungen.
---
# SOLECTRUS hat Küchendienst
_2023-03-22_
> Henning Groß hat SOLECTRUS in der Küche hängen, auf einem Tablet im Kiosk-Mode. Sein Erfahrungsbericht zu PV-Anlage und SENEC-Speicher.
Der Photovoltaik-Enthusiast [Henning Groß](https://mitkaracho.de) schreibt in seinem Blog über die Installation von SOLECTRUS in seiner Küche. Er verwendet ein Tablet im Kiosk-Mode, um den Status seiner PV-Anlage jederzeit im Blick zu haben. Lesenswert!
https://mitkaracho.de/posts/2023/solectrus-mit-senec/
---
# Version 0.9 verfügbar
_2023-03-12_
> Kosten des Stromverbrauchs, "Flop-10", Temperatur-Anzeige, URL-Shortcuts für Kiosk-Modus, Internationalisierung (I18n)
Es gibt ein neues Release mit einigen interessanten neuen Features:
## Kosten des Stromverbrauchs
SOLECTRUS berechnet nun die Kosten für den Stromverbrauch innerhalb eines gewählten Zeitraums. Es wird dabei die tatsächliche Situation mit einem theoretischen Szenario ohne jeden Verbrauch (und somit Volleinspeisung) verglichen.
Wichtig ist dabei das Verständnis, dass auch der Verbrauch von selbst erzeugtem Strom Geld kostet - nämlich in Form der entgangenen Einspeisevergütung.
Die Kosten werden aufgeteilt auf Haus und E-Auto (sofern vorhanden) dargestellt. Es wird dabei pragmatisch davon ausgegangen, dass Netzbezugskosten primär durch das E-Auto veranlasst wurden.
Grundlage der Berechnung sind die erfassten Strompreise sowie die Einspeisevergütung.
Die Kostenberechnung ergänzt die bereits vorhandene Ermittlung der Einsparung, die durch die Photovoltaik-Anlage erzielt wird.
## "Flop-10"
Nicht nur die **besten** Resultate sind von Interesse, sondern auch die **schlechtesten**. Um diese darzustellen, lässt sich die Top-10 jetzt auch aufsteigend sortieren. Damit lassen sich z.B. folgende Fragen beantworten:
- "Wann gab es die geringste Stromerzeugung?"
- "Wann habe ich das E-Auto am wenigsten geladen?"
- "Wann habe ich am wenigsten Strom aus dem Netz bezogen?"
Um Irritationen zu vermeiden, werden bei aufsteigender Sortierung nur vollständige Perioden berücksichtigt, d.h. der Zeitraum ganz am Anfang (bei Installation der Anlage) sowie der aktuelle Zeitraum sind nicht enthalten.
## Temperatur-Anzeige
Auf der Seite `Jetzt` wird nun zusätzlich die aktuelle Gehäuse-Temperatur des Speichers dargestellt.
## URL-Shortcuts für Kiosk-Modus
SOLECTRUS kann nun besser in einem Kiosk-Modus (oder als Slideshow) verwendet werden, bei dem automatisch und ohne Interaktion einzelne Seiten rotierend aufgerufen werden. Dazu gibt es jetzt URL-Shortcuts, die direkt auf einen aktuellen Zeitraum verweisen.
Bisher enthält eine URL den konkreten gewünschten Zeitraum, also z.B. `/inverter_power/2023-03-12` für die Stromerzeugung am 12.03.2023. Hinzugekommen ist jetzt die Möglichkeit, Shortcuts zu verwenden, z.B. `/inverter_power/day`, womit direkt auf die Stromerzeugung des aktuellen Tages verwiesen werden kann. Konkret gibt es Shortcuts für vier verschiedene Zeiträume:
- `/{field}/day`
- `/{field}/week`
- `/{field}/month`
- `/{field}/year`
## Internationalisierung (I18n)
Die Benutzeroberfläche ist nun in **Englisch** und **Deutsch** verfügbar. Die Darstellung hängt davon ab, welche Sprache in deinem Browser eingestellt ist. Wenn du einen deutschen Browser verwendest, wirst du somit keinen Unterschied feststellen.
## Danke!
Vielen Dank an alle, die mit ihren Anregungen und Ideen dazu beitragen, dass SOLECTRUS immer besser wird!
---
# Version 0.8 verfügbar
_2023-02-16_
> Tag, Woche, Monat und Jahr aktualisieren sich jetzt alle fünf Minuten von selbst. Und die Anzeige nennt nun den Status des Speichers.
## Live-Anzeige auch für Perioden
Bisher wurde die Darstellung nur auf der Seite `Jetzt` automatisch (im **5-Sekunden-Takt**) aktualisiert. Dies gilt nun auch für die Periodendarstellung, also die Seiten `Tag`, `Woche`, `Monat`, `Jahr` und `Alle`, wobei hier die Anzeige alle **fünf Minuten** aktualisiert wird.
Dies ist nützlich bei der Verwendung von SOLECTRUS in einem öffentlichen Bereich, z.B. in einem Büro oder einem Geschäft.
## Statusanzeige
Anstelle der bisherigen Anzeige `Live` wird nun der aktuelle Speicherstatus angezeigt. Es handelt sich um die gleiche Information, die auch auf dem Display des Speichers angezeigt wird. Die grüne "Leuchtdiode" signalisiert weiterhin, ob die Daten aktuell sind, also innerhalb der letzten Sekunden aktualisiert wurden.
Damit das funktioniert, muss der [SENEC-Collector](https://github.com/solectrus/senec-collector/releases) in Version 0.6.0 oder neuer installiert sein.
---
# Website für SOLECTRUS
_2023-01-03_
> solectrus.de ist online. Warum aus einem Feierabend-Projekt rund um PV-Anlage und SENEC-Speicher eine eigene Website geworden ist.
SOLECTRUS nimmt so langsam Fahrt auf. Die Zahl der Nutzer steigt, was ich insbesondere an den vielen Anfragen per E-Mail sehe.
Auf meiner persönlichen Website [ledermann.dev](https://ledermann.dev) habe ich ja schon länger einen Link zu SOLECTRUS, aber das ist nicht wirklich ein Marketing-Kanal.
Grund genug, endlich mal die Domain `solectrus.de` zu registrieren und eine eigene Website aufzusetzen. Mal sehen, wohin die Reise geht.
## Historische Entwicklung
Die Idee zu SOLECTRUS stammt ursprünglich aus 2020. Damals wurde die Photovoltaikanlage auf dem Dach unseres Hauses installiert und ein Stromspeicher von SENEC im Keller platziert. Als Software-Entwickler war ich natürlich neugierig, nachdem ich herausfand, dass die Daten der Anlage und des Speichers über eine undokumentierte API abgefragt werden können.
Ich habe das damals ausführlich [in einem Blog-Artikel](https://ledermann.dev/blog/2021/02/03/photovoltaik-dashboard-als-web-applikation/) aufgeschrieben.