Merge branch 'main' into docs/ui_configuration

Author: naltatis

blog/2025-12-18/eu-data-act-petition.mdx

@@ -0,0 +1,128 @@
+---
+title: "Dein Auto, deine Daten? Unterstützt die Petition für den EU Data Act!"
+authors: [naltatis]
+tags: [politics]
+hide_table_of_contents: false
+---
+
+Dein Auto sammelt ständig Daten – aber du hast keinen Zugriff darauf.
+Der EU Data Act, seit dem 12. September 2025 in Kraft, soll das ändern.
+Die Realität sieht anders aus: Die meisten Autohersteller bieten keinen oder nur sehr eingeschränkten Zugang.
+
+[![Dein Auto, deine Daten?](./eu-data-act-petition.webp)](/blog/2025/12/18/eu-data-act-petition)
+
+{/* truncate */}
+
+## Warum evcc Fahrzeugdaten braucht
+
+evcc optimiert das Laden deines Elektroautos mit PV-Überschuss.
+Dafür brauchen wir Echtzeitdaten aus deinem Fahrzeug: Ladestand, Reichweite, Ladezustand.
+Aktuell sind wir oft auf reverse-engineerte APIs angewiesen.
+Das funktioniert, ist aber keine nachhaltige Lösung.
+
+Offizielle APIs würden ermöglichen:
+
+- **Zuverlässiges Überschussladen** mit aktuellen Batterie- und Ladedaten
+- **Besseres Batteriemanagement** durch präzise Steuerung
+- **Energiekostenoptimierung** mit dynamischen Tarifen
+- **Netzstabilität** durch intelligente Lastverteilung
+
+## Warum das auch dich betrifft
+
+„Bei mir läuft doch alles" – das hören wir oft.
+Die Realität dahinter: Die meisten Fahrzeuganbindungen in evcc basieren auf inoffiziellen, undokumentierten APIs.
+Entwickler analysieren in ihrer Freizeit, wie die Hersteller-Apps intern kommunizieren, und bauen darauf ihre Integrationen.
+
+Das funktioniert – aber nur so lange, bis der Hersteller etwas an seinen Systemen ändert.
+Dann bricht die Integration ohne Vorwarnung zusammen.
+Das ist in der Vergangenheit immer wieder passiert und wird auch weiterhin passieren.
+
+Das Problem betrifft nicht nur evcc.
+Alle Open-Source-Lösungen wie Home Assistant stehen vor der gleichen Herausforderung.
+Solange Hersteller keinen offiziellen Zugang bereitstellen, bleibt es ein ständiges Katz-und-Maus-Spiel mit ungewissem Ausgang.
+
+Mit offiziellen Schnittstellen wäre das anders: dokumentiert, stabil, zuverlässig.
+Du könntest dich darauf verlassen, dass deine Integration nicht plötzlich aufhört zu funktionieren.
+
+## Elektromobilität und Energiewende
+
+Offener Datenzugriff ist wichtig für die Energiewende.
+Vehicle-to-Grid (V2G) braucht bidirektionalen Datenaustausch.
+Smart-Home-Integration funktioniert nur mit Echtzeitdaten.
+Optimiertes Laden senkt CO₂-Emissionen und Stromkosten.
+
+## Die Realität: Eingeschränkter Zugang
+
+Der EU Data Act ist Gesetz.
+Die Umsetzung durch die Hersteller ist aber noch sehr unterschiedlich.
+
+**BMW** und **Tesla** bieten API-Zugang an.
+
+**Bei vielen anderen sieht es anders aus:**
+Einige Hersteller stellen Daten auf Anfrage per E-Mail bereit.
+Andere haben Webformulare, bei denen man 15 Minuten alte Daten als ZIP-Datei bekommt.
+Das sind keine praktikablen Lösungen für Echtzeitanwendungen wie Smart Charging.
+
+**Daten-APIs existieren bereits:**
+Fahrzeugdaten sind bereits in guter Qualität und per API verfügbar.
+Allerdings nur für Drittanbieter-Unternehmen, die für den Zugang bezahlen.
+Datenzugang ist für Hersteller ein Geschäftsmodell im B2B-Bereich.
+Für Fahrzeugbesitzer gibt es diesen direkten Zugriff oft nicht.
+
+In unserer [GitHub-Diskussion](https://github.com/evcc-io/evcc/discussions/23684) sammeln wir den aktuellen Stand pro Hersteller.
+
+## Was sagt die EU?
+
+Die [EU-Kommission hat im September 2025 klare Richtlinien](https://digital-strategy.ec.europa.eu/en/library/guidance-vehicle-data-accompanying-data-act) veröffentlicht:
+
+**Nutzer haben das Recht auf:**
+
+- Roh- und vorverarbeitete Fahrzeugdaten
+- Einfachen, kostenlosen Zugriff auf eigene Daten
+- Daten in derselben Qualität, wie sie der Hersteller selbst nutzt
+- Weitergabe an Dritte ihrer Wahl
+
+**Hersteller müssen:**
+
+- Daten einfach und direkt zugänglich machen
+- Ohne zusätzliche Kosten für persönliche Nutzung
+- In maschinenlesbarem Format
+- Inklusive der Metadaten zur Interpretation
+
+Die rechtliche Grundlage ist vorhanden.
+An der praktischen Umsetzung hapert es noch.
+
+## Die Petition
+
+Maximilian Hauser aus der evcc Community hat eine [Petition gestartet](https://www.change.org/p/eu-data-act-durchsetzen-autohersteller-müssen-uns-zugang-zu-unseren-fahrzeugdaten-geben), um die Umsetzung des Data Act voranzutreiben.
+
+**Gefordert wird:**
+
+- Bundesnetzagentur soll den Data Act durchsetzen
+- Klare technische Standards für APIs
+- REST-API mit OAuth 2.0
+- Mindestens 12 Anfragen pro Stunde pro Fahrzeug
+- Öffentliche API-Dokumentation
+- 99 % monatliche Verfügbarkeit
+
+## Was du jetzt tun kannst
+
+### 1. Petition unterschreiben
+
+👉 **[Hier unterschreiben](https://www.change.org/p/eu-data-act-durchsetzen-autohersteller-müssen-uns-zugang-zu-unseren-fahrzeugdaten-geben)** 👈
+
+### 2. Hersteller kontaktieren
+
+Frag bei deinem Autohersteller nach API-Zugang gemäß EU Data Act.
+Verweise auf die EU-Richtlinien.
+Je mehr Anfragen eingehen, desto eher bewegt sich etwas.
+
+### 3. Thema weiter tragen
+
+Teile die Petition in deinem Umfeld: Foren, Discord-Server, Facebook-Gruppen, Freundeskreis und Familie.
+Gib deinen Lieblings-YouTube-Kanälen, die sich mit E-Mobilität, Smart Home und erneuerbaren Energien beschäftigen, einen Hinweis.
+
+---
+
+Der Data Act ist da.
+Die Umsetzung braucht Druck von Nutzerseite.

blog/2025-12-18/eu-data-act-petition.webp

@@ -1,4 +1,4 @@
 ```yaml
-# trial token, valid until 2025-12-17
-eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJldmNjLmlvIiwic3ViIjoidHJpYWwiLCJleHAiOjE3NjYwMDUyMDAsImlhdCI6MTc2NTQwMDQwMCwic3BlIjp0cnVlLCJzcmMiOiJtYSJ9.yJgXi8MF9brca18VNitJBm1sJWMs1eGUc_F1sxW9O24
+# trial token, valid until 2025-12-24
+eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJldmNjLmlvIiwic3ViIjoidHJpYWwiLCJleHAiOjE3NjY1OTkyMDAsImlhdCI6MTc2NTk5NDQwMCwic3BlIjp0cnVlLCJzcmMiOiJtYSJ9.Ls6XxNahmQnolsSCLQuKVzY9uuK_PI9v559oxz5yT-k
 ```

docs/_sponsortoken.mdx

@@ -30,6 +30,7 @@ Zusätzlich können Plugins auch für die in [Messaging](/docs/reference/configu
 - [JavaScript Plugin](#javascript) - Plugin, das Werte in über ein JavaScript Skript bereitstellt oder entgegennimmt.
 - [Shell Plugin](#shell) - Plugin, das ein Shell Skript ausführen kann, um Daten zu extrahieren oder schreibend entgegennimmt.
 - [Prometheus Plugin](#prometheus) - Plugin zum Lesen von Metriken aus Prometheus über PromQL.
+- [GPIO Plugin](#gpio) - Plugin zum direkten Zugriff auf GPIO-Pins (nur Linux).
 
 ### Helpers
 
@@ -736,6 +737,46 @@ energy:
 Die Abfrage muss einen einzelnen numerischen Wert zurückgeben.
 Bei Vektor-Ergebnissen muss genau eine Metrik enthalten sein.
 
+### GPIO <Tag label="lesen" category="read" /> <Tag label="schreiben" category="write" /> {#gpio}
+
+Das `gpio` Plugin ermöglicht den direkten Zugriff auf GPIO-Pins (General Purpose Input/Output) unter Linux.
+Es ist besonders für Raspberry Pi und ähnliche Einplatinencomputer geeignet.
+
+**Parameter**:
+
+| Parameter | Typ    | Erfordert | Beschreibung                                   |
+| --------- | ------ | --------- | ---------------------------------------------- |
+| function  | string | ja        | Modus: `read` (Eingang) oder `write` (Ausgang) |
+| pin       | int    | ja        | Pin-Nummer (BCM-Nummerierung, z. B. GPIO 17)   |
+
+**Funktionsweise**:
+
+- **Lesen** (`function: read`): Liest den Zustand eines GPIO-Pins als Boolean-Wert (`true` = HIGH, `false` = LOW)
+- **Schreiben** (`function: write`): Setzt einen GPIO-Pin auf HIGH (`true`) oder LOW (`false`)
+
+Die Pin-Nummerierung folgt dem BCM-Schema (Broadcom-Nummern, nicht die physische Pin-Position).
+Für ein Raspberry Pi Pinout siehe z. B. [pinout.xyz](https://pinout.xyz/).
+
+**Beispiel Lesen**:
+
+```yaml
+source: gpio
+function: read
+pin: 17 # BCM pin number
+```
+
+**Beispiel Schreiben**:
+
+```yaml
+source: gpio
+function: write
+pin: 27 # BCM pin number
+```
+
+:::note
+Dieses Plugin funktioniert nur auf Linux-Systemen mit Zugriff auf `/dev/gpiomem`.
+:::
+
 ## Helpers
 
 ### Const <Tag label="lesen" category="read" /> {#const}

docs/devices/plugins.mdx

@@ -38,6 +38,24 @@ influx:
   org: home
 ```
 
+---
+
+## HTTPS mit selbst-signiertem Zertifikat
+
+Bei Verwendung von HTTPS (`https://`) wird standardmäßig das TLS-Zertifikat überprüft.
+Falls ein selbst-signiertes Zertifikat verwendet wird, kann die Zertifikatsüberprüfung deaktiviert werden:
+
+**Beispiel**:
+
+```yaml
+influx:
+  url: https://influxdb.example.com:8086
+  database: evcc
+  token: 1234567890abcdef
+  org: home
+  insecure: true
+```
+
 ## VictoriaMetrics
 
 [VictoriaMetrix](https://github.com/VictoriaMetrics/VictoriaMetrics) ist eine Time Series Datenbank mit InfluxDB kompatibler REST API.

docs/reference/configuration/influx.md

@@ -28,7 +28,7 @@ mqtt:
 
 ## MQTT mit TLS-Verschlüsselung
 
-Beispiel:
+**Beispiel**:
 
 ```yaml
 # mqtt message broker
@@ -40,6 +40,12 @@ mqtt:
   # password:
 ```
 
+Bei Verwendung von TLS-Verschlüsselung (`tls://`) wird standardmäßig das TLS-Zertifikat des Brokers überprüft.
+Falls ein selbst-signiertes Zertifikat verwendet wird, gibt es zwei Möglichkeiten:
+
+1. Das Zertifikat systemweit installieren (z. B. unter Linux in `/etc/ssl/certs`), damit evcc es automatisch verwendet
+2. Die Zertifikatsüberprüfung mit `insecure: true` deaktivieren (siehe unten)
+
 ---
 
 ## Erforderliche Parameter
@@ -67,4 +73,63 @@ Das Anmeldepasswort am MQTT-Broker.
 
 ### `clientid`
 
-Erlaubt eine feste MQTT-Client ID vorzugegeben. Andernfalls wird diese dynamisch vergeben.
+Erlaubt eine feste MQTT-Client ID vorzugegeben.
+Andernfalls wird diese dynamisch vergeben.
+
+### `insecure`
+
+Deaktiviert die TLS-Zertifikatsüberprüfung bei Verwendung von `tls://`.
+
+**Beispiel**:
+
+```yaml
+mqtt:
+  broker: tls://broker.example.com:8883
+  topic: evcc
+  insecure: true
+```
+
+### `caCert`
+
+CA-Zertifikat für die Überprüfung des Broker-Zertifikats (Zertifikatsinhalt).
+
+**Beispiel**:
+
+```yaml
+mqtt:
+  broker: tls://broker.example.com:8883
+  topic: evcc
+  caCert: |
+    -----BEGIN CERTIFICATE-----
+    MIIDXTCCAkWgAwIBAgIJAKZm...
+    ...
+    -----END CERTIFICATE-----
+```
+
+### `clientCert`
+
+Client-Zertifikat für gegenseitige TLS-Authentifizierung (Zertifikatsinhalt).
+Muss zusammen mit `clientKey` verwendet werden.
+
+**Beispiel**:
+
+```yaml
+mqtt:
+  broker: tls://broker.example.com:8883
+  topic: evcc
+  clientCert: |
+    -----BEGIN CERTIFICATE-----
+    MIIDXTCCAkWgAwIBAgIJAKZm...
+    ...
+    -----END CERTIFICATE-----
+  clientKey: |
+    -----BEGIN PRIVATE KEY-----
+    MIIEvQIBADANBgkqhkiG9w0B...
+    ...
+    -----END PRIVATE KEY-----
+```
+
+### `clientKey`
+
+Privater Schlüssel des Client-Zertifikats (Schlüsselinhalt).
+Muss zusammen mit `clientCert` verwendet werden.