keine Reaktion auf MQTT Befehle

keine Reaktion auf MQTT Befehle

0
0

Ich habe testweise an einem Tesla während des Ladens versucht, den Ladestrom über MQTT zu reduzieren.
(Mit einem Smart wollte die cFos ja überhaupt nicht laden)
Startbefehl war: {„E1“:{cur: 6000, ena: true, wke: true, phs: 1}}
Damit startete das Laden, aber 3-phasig und mit voller Leistung von 11kW.
Wenn ich die Befehle sende: {„E1“:{ena: false}}  bzw. {„E1“:{ena: true}}  wird der Ladevorgang gestoppt und wieder gestartet. Wunderbar.
Das heißt: MQTT Befehle werden korrekt gesendet und auch empfangen, aber außer enable/disable werden Vorgaben zu Ladestrom oder Phasenumschaltung völlig ignoriert.
Ich habe hier zwar schon von solchen Problemen gelesen, aber das bezog sich noch auf Firmware 2.4.x.
Eigentlich hätte ich erwartet, dass mit 2.8.1 solch elementare Probleme gelöst sind.
Hat jeman einen Trick oder kann mir sagen, was ich falsch mache?
Muss ich es mit Modbus-TCP versuchen?
Oder müssen wir noch auf ein Firmware Update warten?

RESOLVED
markiert als Spam
Posted by (Fragen: 3, Antworten: 13)
Gefragt am 26. August 2025 15:41
101 views

Antworten (6)

0
Private answer

Verrückt! Das grenzt ja wirklich an ein Wunder.

In der Tat tut es sehr gut zu sehen, dass es nicht am Kunden lag, sondern tatsächlich die Mutter aller MQTT-Fehler schuld war.
Ich werde aber trotzdem auf v2.2.1 verbleiben, so lange wie ich die neuen Features nicht unbedingt brauche. Hab kein Vertrauen mehr in die Software und den Support. Und wie du schlicht keine Zeit Tage mit Debugging und Testen zu verbringen wie beim letzten Mal.

markiert als Spam
Posted by (Fragen: 1, Antworten: 14)
Answered on 9. Oktober 2025 23:13
0
Private answer

Wahnsinn...es geschehen offenbar noch Wunder!
Die gute Nachricht: dynamisches Ladestrom-Limitieren sowie die Phasenumschaltung funktionieren jetzt endlich auch über MQTT !
Aber: es geht erst seit Firmware 2.9.1-beta !!!

Monatelanges Rumeiern, den Kunden für doof verkaufen, unbrauchbare Kommentare seitens cFos ("...wir geben keinen MQTT Support...") sowie wenig hilfreiche "Ratschläge" von cFos ("...neuste FW 2.9.0 installieren..." - die aber nie in der Upgrade Liste auftauchte) haben nichts erbracht. Sogar die empfohlenen HTTP-Befehle haben nicht funktioniert.
Nun nach Androhung von Schadenersatzforderungen und Kaufvertragswandlung hat sich offensichtlich doch noch ein kompetenter Programmierer bei cFos erbarmt und der MQTT Thematik gewidmet.

Heute habe ich die 2.9.1-beta installiert - und plötzlich funktionierten alle meine MQTT Befehle einwandfrei.
Ich konnte den Ladestrom dynamisch begrenzen und sogar 1-/3-phasiges Laden dynamisch umschalten. Hurra.
Erfolgreich getestet an unserem neuen KIA EV3. Wir sind glücklich.

Es lag also nicht am dummen Kunden, der zu dämlich ist, die "Dokumentation" (falls man diese als solche überhaupt bezeichnen kann) zu lesen. Es lag ganz offensichtlich ein Software-Bug vor.
Trotzdem hat es sich cFos nicht nehmen lassen, monatelang das Problem zu ignorieren. Kundenservice sieht definitiv anders aus.

Eines musste ich jedoch feststellen: sobald ich per MQTT den Ladestrom begrenzt hatte, ging dieser nach 1 Minute trotzdem wieder auf die maximalen 16A hoch. Offenbar ein Time-Out mit Failsafe.
Wenn ich jedoch den MQTT-Befehl regelmäßig wiederholt hatte (alle paar Sekunden), gab es diesen Rücksprung auf maximalen Strom nicht.
Das ist zwar nicht elegant, aber immerhin kann ich dieses Problem leicht umgehen, indem ich den Befehl eben regelmäßg innerhalb von 60 Sekunden sende.

Jetzt kann ich nur hoffen, dass die funktionierende Software den Einzug in eine stabiles Release überlebt und dauerhaft verfügbar bleibt.

...und obwohl cFos meine IP-Adresse für den Login in dieses Netzwerk gesperrt hatte, konnte ich dank eines VPN doch noch einloggen und Euch die frohe Kunde mitteilen ;-)

markiert als Spam
Posted by (Fragen: 3, Antworten: 13)
Answered on 9. Oktober 2025 13:52
1
Private answer

@CFOS

Gibts hierzu endlich mal ein Statement??

markiert als Spam
Posted by (Fragen: 0, Antworten: 8)
Answered on 7. Oktober 2025 15:41
0
Private answer

Ich habe weiter getestet. Geotec hatte ja im Mai einen Workaround beschrieben, den ich testweise umgesetzt habe ("evse" durch "IP-Adresse:4701" manuell in der Config ersetzen und zurücklesen).
Getestet an einem Tesla. Ergebnis: es wird immer wilder.
Den Ladestrom konnte ich tatsächlich nun per MQTT dynamisch verändern - wunderbar. Die Freude war kurz.
Die Phasenumschaltung wird weiterhin ignoriert. Es passiert jedoch etwas sehr merkwürdiges.
Wenn ich auf 6A 3-phasig stelle, lädt der Tesla brav 6A auf jeder Phase.
Wenn ich auf 6A 1-phasig stelle, lädt der Tesla auf L1 mit 3x6A = 18A.
Die Wallbox meldet auf MQTT jedoch, dass nur auf L1 6A fließen, auf L2/L3 0A fließt.
Als Gesamtleistung meldet die Wallbox auf MQTT 4.351 W.
Das ist ja eindeutig falsch gerechnet.
Faktisch werden 4.3 kW ins Auto geladen, aber die MQTT-Werte und selbst die Kachel-Anzeigen von cFos sind völlig falsch.
Screenshots habe ich angehängt.
-
Das ist jedoch nur das eine Problem (falsche Anzeige und falsche Regelung durch cFos).
Wenn das Workaround von Geotec durchgeführt wird, dann fehlen in der "cfos_mqtt/get/E1"-Payload plötzlich die Werte unter "/evse/", z.B. für mich sehr wichtige Info über cp_state, pp_state, enabled, charging, current. Diese Werte werden dann einfach nicht mehr übertragen. Das stört meine NodeRed Auswertung massiv und ich erhalte Fehlermeldungen. Außerdem benötige ich die Daten.
Wie kommen wir denn nun zu einer Lösung, dass ich MQTT für die Steuerung benutzen kann - und realistische Werte zurücklesen kann?
Alle bisherigen Versuche, cFos über Email oder Support-Formular anzusprechen sind bisher ergebnislos geblieben. Tatsache ist aber, dass diese Probleme bereits bei anderen Leidgenossen schon vor einem halben Jahr hier beschrieben wurden, ohne dass ich eine Lösung dafür erkennen kann.

markiert als Spam
Posted by (Fragen: 3, Antworten: 13)
Answered on 28. August 2025 22:43
0
Private answer

Danke für den Hinweis. Ja, diese Antwort hatte ich schon gesehen. Die war im Mai. Das Problem haben einige, nicht nur ich.
Aus unerfindlichen Gründen hatte ich die Erwartung, dass nach dieser Zeit und Versionssprüngen das Problem gefixt sein sollte.
Ich werde mal den Workaround probieren, weigere mich aber, solche Sonderlocken in einem professionellen Produkt zu akzeptieren.
Schließlich habe ich mich bewusst für cFos entschieden, da ich dort den Versprechungen Glauben geschenkt habe, dass die Schnittstellen offen sind (stimmt) und mit MQTT problemlos bedient werden können (stimmt nicht). Gerade MQTT ist mein Kaufkriterium. Modbus ist zweite Wahl. Alles andere lehne ich ab.
Ich unterstütze sehr gerne, erwarte aber auch von den Entwicklern zeitnahes und konsequentes Handeln.
2 volle Tage habe ich nun mit Tests und Rückschlägen verbracht - ohne sinnvolles Ergebnis.
Bei einer Wallbox, die nicht zu den billigsten im Markt gehört, bin ich dann doch überrascht.
Smileyman hat zwar eine interessante Alternative gefunden, aber die werde ich derzeit auf keinen Fall in Erwägung ziehen. Ich habe schlicht keine Zeit, mich nun auch noch mit der völlig neuen Thematik der Laderegeln und cFos-proprietären Semantik auseinandersetzen zu können.
Die Übersetzung der Modbus-Dokumentation in eine MQTT-Dokumentation ist schon schwierig genug. Die Dokus und Beispiele von cFos sind leider nicht wirklich so hilfreich oder verständlich, wie ich mir das wünsche.
Warten wir mal ab und hoffen, dass cFos hier jetzt endlich mal das MQTT Thema ernsthaft adressiert.

markiert als Spam
Posted by (Fragen: 3, Antworten: 13)
Answered on 26. August 2025 22:42
0
Private answer

Schau mal hier: https://www.cfos-emobility.de/network/antworten/mqtt-steuerung/

Das Problem mit dem "Standalone-Modus" scheint entweder nicht gefixt worden zu sein oder es ist wieder da.

markiert als Spam
Posted by Top Networker (Fragen: 0, Antworten: 1650)
Answered on 26. August 2025 21:14