Hallo Yves,
hat das einen spezifischen Grund, warum du mit evcc nicht via MQTT sprichst?
Beste Grüße
Jens
Moderation: Dieser Post war ursprünglich in einem anderen Thread, wurde aber nun hier als Einstieg in eine neue Diskussion abgespalten.
Neue Insider Preview 5.2 veröffentlicht

Neue Funktion: Wetter-Service mit Daten zu Umwelt, Wetter, Warnungen & Alarme
- Dieser neue Funktion wird über die Timberwolf Cloud zur Verfügung gestellt
- ElabNET sammelt Daten aus mehreren Quellen in der Timberwolf Cloud
- Timberwolf Server beziehen diese Daten gebündelt und automatisch aus der Timberwolf Cloud
- Aktualisiert 24/7, stündlich, einfache Einrichtung
- Die Daten stehen detailliert im Objektsystem zur Verfügung
Verbesserung VISU: Autom. Rücksprung zur Startseite (verbessert mit IP 5.2)
Erweiterung Logik: Neuer Sendefilter sowie verbessertes Handling Zeichenketten in der Logik (verbessert mit IP 5.2)
Beschreibung aller Neuerungen und Verbesserungen: https://elabnet.atlassian.net/wiki/x/AQCv1w
AKTION: Wir haben noch viele tolle Updates und 150 Videos (und 800 Wiki Seiten) geplant. Bitte unterstütze uns mit einem Software-Wartungsvertrag, damit wir dieses alles erreichen können. Und damit Dein Server weiterhin Updates, Upgrades und Support erhält. Jetzt in der Aktion schenken wir Dir den Insider Club mit derselben Laufzeit wie der am längsten laufende aktive Wartungsvertrag dazu - bei sofortigem Laufzeitbeginn PLUS den Wetter-Service für ZWEI Jahre. Damit profitierst Du auch von einer vorzeitigen Verlängerung. Alle Infos: https://elabnet.atlassian.net/wiki/x/GQB8z
[DISKUSSION] [V4.0 IP7] MQTT-Kommunikation mit evcc
Forumsregeln
- Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
- Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
- Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
- Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
-
blaubaerli
- Beiträge: 2758
- Registriert: Sa Sep 15, 2018 10:26 am
- Wohnort: Kerpen
- Hat sich bedankt: 1055 Mal
- Danksagung erhalten: 841 Mal
[V4.0 IP7] MQTT-Kommunikation mit evcc
Zuletzt geändert von blaubaerli am Mo Feb 05, 2024 6:38 pm, insgesamt 1-mal geändert.
| timberwolf168 | (2600er) | VPN offen | Reboot nach Vereinbarung |
| timberwolf1699 | (3500XL) | VPN offen | Reboot jederzeit |
| wiregate1250 |
-
starwarsfan
- Beiträge: 1423
- Registriert: Mi Okt 10, 2018 2:39 pm
- Hat sich bedankt: 899 Mal
- Danksagung erhalten: 1235 Mal
Hallo Jens
Wie würde das denn grundsätzlich ablaufen? evcc als eigenes MQTT-Subsystem anlegen und dann direkt dahin schreiben?
Nunja, REST-API ist IMHO wesentlich einfacher als MQTT. Das geht im Notfall auch via curl von der Cmdline aus, von daher habe ich mich mit MQTT@evcc gar nicht weiter beschäftigt.blaubaerli hat geschrieben: ↑Sa Feb 03, 2024 6:33 pm hat das einen spezifischen Grund, warum du mit evcc nicht via MQTT sprichst?
Wie würde das denn grundsätzlich ablaufen? evcc als eigenes MQTT-Subsystem anlegen und dann direkt dahin schreiben?
Kind regards,
Yves
TWS 2500 ID:159 / TWS 3500 ID:618 / TWS 3500 ID:1653 + PBM ID:401 / ProxMox / 1-Wire / iButtons / Edomi (LXC / Docker) / evcc / ControlPro
(TW-VPN jeweils offen, Reboot nach Rücksprache)
Yves
TWS 2500 ID:159 / TWS 3500 ID:618 / TWS 3500 ID:1653 + PBM ID:401 / ProxMox / 1-Wire / iButtons / Edomi (LXC / Docker) / evcc / ControlPro
(TW-VPN jeweils offen, Reboot nach Rücksprache)
-
gbglace
- Beiträge: 4302
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1509 Mal
- Danksagung erhalten: 2054 Mal
Hi Yves. Kommt drauf an wie die das umgesetzt haben. Bei Victrons baut der CerboGX einen eigenen MQTT Broker auf. Den kannst im TWS als eigens Subsystem einrichten und dann Mal im MQTT Explorer (da auch den einrichten) welche Topics dann so gesendet werden die dann subscriben/published.
Sollte das Gerät eine Konfiguration des MQTT ermöglichen, dann ist es ggf möglich dem Deinen MQTT-Broker vorzugehen.
Sollte das Gerät eine Konfiguration des MQTT ermöglichen, dann ist es ggf möglich dem Deinen MQTT-Broker vorzugehen.
Grüße Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
-
blaubaerli
- Beiträge: 2758
- Registriert: Sa Sep 15, 2018 10:26 am
- Wohnort: Kerpen
- Hat sich bedankt: 1055 Mal
- Danksagung erhalten: 841 Mal
Hallo zusammen,
evcc kommt nicht mit einem eigenen MQTT-Broker daher, sondern wird über die entsprechenden Passagen in der Konfigdatei gegen eine bestehende Instanz konfiguriert. Doku dazu siehe hier.
Ein zusätzliches MQTT-Subsystem auf Seiten des TWS öffnet ja zunächst im ElabNET-Wording mal eine Kommunikationsstrecke zu einer MQTT-Broker-Instanz.
Wenn also z.B. lokal auf deinem Wolf bereits ein Mosquitto läuft, dann spricht also mal nichts grundsätzliches dagegen, genau diesen auch für die Kommunikation mit evcc zu nutzen. Auch hier mögen Ausnahmen die Regel bestätigen. Wenn also eine speziell gesicherte Verbindung zu einem externen MQTT-Dienstleister eingerichtet ist und du die lokale Kommunikation zwischen dem evcc und dem TWS nicht ohne Not über die externe Verbindung schleusen willst, mag das durchaus für eine zusätzliches MQTT-Subsystem sprechen.
Aus meiner Sicht liegt der klare Vorteil bei der MQTT-Kommunikation, dass eben der Rückkanal von evcc zum TWS damit automatisch per PUSH gleich auch implizit funktioniert. Bei der Rest-API ist halt bei Bedarf zu pollen und das finde ich architekturell immer was "unschön". Zumal es ja die Alternative gibt.
Die MQTT-API von evcc ist hier zu finden.
Zudem ist zu Diagnosezwecken der "MQTT Explorer" da als unabhängige Dritte Instanz immer recht hilfreich.
Beste Grüße
Jens
evcc kommt nicht mit einem eigenen MQTT-Broker daher, sondern wird über die entsprechenden Passagen in der Konfigdatei gegen eine bestehende Instanz konfiguriert. Doku dazu siehe hier.
Ein zusätzliches MQTT-Subsystem auf Seiten des TWS öffnet ja zunächst im ElabNET-Wording mal eine Kommunikationsstrecke zu einer MQTT-Broker-Instanz.
Wenn also z.B. lokal auf deinem Wolf bereits ein Mosquitto läuft, dann spricht also mal nichts grundsätzliches dagegen, genau diesen auch für die Kommunikation mit evcc zu nutzen. Auch hier mögen Ausnahmen die Regel bestätigen. Wenn also eine speziell gesicherte Verbindung zu einem externen MQTT-Dienstleister eingerichtet ist und du die lokale Kommunikation zwischen dem evcc und dem TWS nicht ohne Not über die externe Verbindung schleusen willst, mag das durchaus für eine zusätzliches MQTT-Subsystem sprechen.
Aus meiner Sicht liegt der klare Vorteil bei der MQTT-Kommunikation, dass eben der Rückkanal von evcc zum TWS damit automatisch per PUSH gleich auch implizit funktioniert. Bei der Rest-API ist halt bei Bedarf zu pollen und das finde ich architekturell immer was "unschön". Zumal es ja die Alternative gibt.
Die MQTT-API von evcc ist hier zu finden.
Zudem ist zu Diagnosezwecken der "MQTT Explorer" da als unabhängige Dritte Instanz immer recht hilfreich.
Beste Grüße
Jens
| timberwolf168 | (2600er) | VPN offen | Reboot nach Vereinbarung |
| timberwolf1699 | (3500XL) | VPN offen | Reboot jederzeit |
| wiregate1250 |