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.
KNX Data Secure Unterstützung
für KNX Logger und KNX Busmonitor
KNX Diagnose Monitor, Import des ETS Projektes deutlich beschleunigt, Suche in der Navigation
Mehr Informationen dazu hier im Forum
Insider Version 6 zur 4.5 jetzt für alle Mitglieder des Insider Clubs installierbar
Alle Infos zum Update im Timberwolf Wiki
[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
-
- Reactions:
- Beiträge: 2670
- Registriert: Sa Sep 15, 2018 10:26 am
- Wohnort: Kerpen
- Hat sich bedankt: 999 Mal
- Danksagung erhalten: 787 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 |
-
- Reactions:
- Beiträge: 1395
- Registriert: Mi Okt 10, 2018 2:39 pm
- Hat sich bedankt: 864 Mal
- Danksagung erhalten: 1199 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)
-
- Reactions:
- Beiträge: 4089
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1416 Mal
- Danksagung erhalten: 1901 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
-
- Reactions:
- Beiträge: 2670
- Registriert: Sa Sep 15, 2018 10:26 am
- Wohnort: Kerpen
- Hat sich bedankt: 999 Mal
- Danksagung erhalten: 787 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 |