ist es normal, dass während eines Ladevorgangs die mqtt-Variable „evse.charging“ zeitweilig oft zwischen true und false wechselt?
| ♥ 0 |
Ich überwache den Ladevorgang mit Hilfe der mqtt-Daten (E1 und Ladedaten aus dem Fahrzeug). Diese werte ich aus, indem ich bei 3 Ereignissen einen Datensatz in einer csv-Datei ablege:
Hierbei fällt mir wiederholt auf, daß die mqtt-Variable „evse .charging“ zeitweilig oft zwischen true und false wechselt, vgl. Anhang. Ist das normal und warum passiert das? Woher kommt das Signal ursprünglich, aus dem Fahrzeug oder aus der Wallbox? Wenn das jedes Mal zu einem Schaltvorgang am Schütz im Fahrzeug führt, dürfte das dessen Lebensdauer nicht zuträglich sein. Und btw: Die mqtt-Variable „phases“ steht auch beim 3-phasigen Laden auf 1. Und: Die meisten mqtt-Variablen sind selbsterklärend, aber leider nicht alle, wo gibt es eine Beschreibung? Anhänge:
markiert als Spam
|
Antworten (8)
|
Private answer
Da ich gerade eine Wallbox auf Basis des cFos PowerBrainControllers in betrieb nehme und bei mir über MQTT in den Hausserver zur Visualisierung (NodeRed/Influx/Grafana) einbinde bin ich auf diesen Thread mit der Beschreibung der Variablen gestoßen (wo mir die Antwort von Geotec erstmal weitergeholfen hat). Dabei ist mir auch noch die Feststellung von baeringer aufgefallen:
hierzu meine Anmerkung: Das Fahrzug kann über das Ladekabel Typ2-Standard nach IEC 62196 Pin CP schon eine Rückmeldung an die Wolbox geben, der dann in den Variablen evse.cp_state und state landet wovon dann evse.charging abgelegt wird. Mich würde interessieren, ob und wie alle Zustände des Standards in evse.cp_state und state abgebildet sind. Beschreibung Typ2 Ich würde mir hier eine vollständige beschreibung der MQTT Schnittstelle wünschen, damit man nicht über Trail/Error auf die Werte schließen muss. z.B. bekomme ich beim Laden über 3Phasen in phases den Wert 7 (Im gegensatz zum Orginal Poster ??) oder charging_duration is in 0.1sec angegeben. Kann mir das jemand bestätigen solange es keine offizielle Doku dazu gibt? (Hab jetzt die V 2.6.1 am laufen) markiert als Spam
|
|
|
Private answer
Habe ich getan und 2 Antworten erhalten: am 17.01.25 : das habe ich intern mal weitergeleitet und um Ansicht gebeten. am 19.02.25: wir sind keine mqtt Experten und können da eher keinen Beitrag leisten.
Auf meine Bemerkung, dass der SW-Entwickler, der die Variable angelegt hat, doch Bescheid wissen müsste, habe ich zu diesem Thema nichts wieder gehört.
markiert als Spam
|
|
|
Private answer
Gestern abend hatte ich wieder einmal 3-phasig geladen, und zwar unmittelbar nach einer längeren Fahrt. Ohne dass evse.charging auch nur einmal unterbrochen wurde. Wenn die Ursache aus dem Fahrzeug kommt, könnte es dadurch erklärbar sein, dass die Batterie nicht so kalt war wie sonst. Der Knackpunkt ist die Frage, woraus entsteht das mqtt-Signal evse.charging?
markiert als Spam
|
|
|
Private answer
Gestern konnte ich wieder einmal dreiphasig laden und den Vorgang aufzeichnen, mit dem gleichen Effekt wie ursprünglich. Die Daten habe ich in einer Excel-Tabelle aufbereitet und zum Hochladen auf .txt umbenannt. Das aktuelle Tabellenblatt zeigt die m. E. für den Ladevorgang relevanten Daten, das erste Tabellenblatt beinhaltet alle Daten, die von E1 per mqtt exportiert werden. Dazu die Logdatei über den gesamten Ladevorgang mit den Einstellungen gem. Anhang, wegen der Größenbegrenzung beim Hochladen gezippt und wieder in .txt umbenannt. Anhänge:
markiert als Spam
|
|
|
Private answer
Ja, aber dazu sollte ich wissen, welche Log-Details ich auf Information stellen soll, damit das Protokoll nicht überladen wird. Die Erläuterungen sind z. T. sehr hilfreich und interessant, vielen Dank. Manche sind aber nur ins deutsche übersetzt. Sicher weiß jeder bei cFos, was der PP-Status ist, aber dem außenstehenden Nutzer sagt das genausoviel wie evse_pp_state. Dgl. was ist ein DC-Fehler und ein CP-Fehler?
markiert als Spam
|
|
|
Private answer
Statt Diagnoselog kannst du einfach unter "Log Aufzeichnung" die Detaileinstellungen öffnen und die benötigten Punkte auf "Information" stellen. ta_en Energie der akt. Transaktion charging_dur -ation? Zeit der akt. Transaktion state Status: 1 warten, 2 eingesteckt, 3 laden, 4 laden mit Lüftung, 5 Fehler, 6 offline (Wallbox) lreason Ladegrund: 0=ohne Regel, 4=Laderegel paused Ladepause pause_time bereits abgelaufene Pausenzeit pause_min_time eingestellte Pausenzeit evse_dc_sensor_faults Anzahl erkannter DC-Fehler evse_dc_last_fault_time Datum/Uhrzeit letzter DC-Fehler evse_dc_last_test_time letzter DC-Sensor-Test evse_dc_sensor_fault liegt aktuell ein DC-Fehler an evse_dc_sensor_glitches Fehler des DC-Sensors evse_cp_state CP-Status: warten, eingesteckt, laden, laden mit Lüftung, Fehler evse_cp_fault CP-Fehler evse_pp_state PP-Status evse_phase_switch_time Wartezeit zwischen Phasenumstellung evse_phase_switch_disconnect Ausstecken simulieren markiert als Spam
|
|
|
Private answer
Ich habe heute einmal einphasig geladen. Eine Ladung wie aus dem Bilderbuch. Nicht eine Unterbrechung zwischen Start und Erreichen des Ziel-SoC. Nur die Effizienz ist niedriger (ca. 90%) als beim 3-phasigen Laden mit ca. 95%. Die Zoe hat einen Fahrmodus mit erhöhter Brems-, bzw. Rekuperationswirkung, wenn man das „Gas“ wegnimmt. Benutze ich diesen, (und nur dann) bekomme ich derzeit oft die Meldung, daß die Lademöglichkeit der Batterie temperaturbedingt eingeschränkt ist. Insofern halte ich es durchaus für möglich, dass die Ursache fahrzeug- bzw. temperaturbedingt ist. Und deshalb interessiert mich, woraus die Variable „evse.charging“ generiert wird. Das Fahrzeug kann ja kaum eine Rückmeldung an die Wallbox geben, sh. Thema SoC. Aber die Wallbox könnte evse.charging vom Strom ableiten, den das Fahrzeug zieht. Die nächste Ladung der Batterie werde ich wieder dreiphasig vornehmen und einen Diagnoselog speichern. Was muß ich diesbezüglich beachten? Der Diagnoselog läuft nur 5 Minuten. Kann man das verlängern? Ich kann im Voraus schlecht sagen, wann die Unterbrechungen während des Ladevorgangs auftreten. Oder gibt es unter den publizierten mqtt-Daten etwas, womit ich auf das Starten des Ladevorgangs und sein beabsichtigtes Ende bei Erreichen des Ziel-SoC triggern kann? Und die unklaren mqtt-Daten sind ta_en
Anhänge:
markiert als Spam
|
|
|
Private answer
Warum die Ladung unterbrochen wird könnte man höchstens in einem Diagnoselog erkennen. Vielleicht machst du mal eins uns schickst es an cFos. Die Variablennamen sind aus der config. Das sind alles Einstellungen aus der Wallboxkachel (z.b. die Phases). Sag welche dir unbekannt sind. Alle kenne ich auch nicht, aber die meisten kann man gut mit ausprobieren herausbekommen. markiert als Spam
|
