Hi,

du kannst Variablen erstellen und von Aussen setzen.

Schau mal dir: https://www.cfos-emobility.de/network/antworten/kann-ich-die-charging-manager-variablen-auch-ueber-die-api-setzen-http-mqtt/

Dann kannst du z.B. mit einer Regel mit "plugin_energy <= var1" laden.

Ja, das mit dem SoC ist tatsächlich erstmal etwas unkomfortabel, aber man muss ja mit dem arbeiten was man hat ;)
Die Eingabe des SoC geht aber schon einigermaßen über openhab. Entweder per App und Schieberegler oder per Alexa Sprachbefehl.

Der Hinweis mit der Variablen "txn_energy" ist echt gut, das würde mir ein bisschen rumrechnen ersparen. Ich werde da mal die Tage ein wenig mit rumprobieren.

Mein erster Ansatz wäre folgender:

1. SoC über OH erfassen (kann man später noch optimieren)
2. OH berechnet aufgrund des SoCs sowie der Kapazität bei 80% die zu ladenden kWh
3. OH überwacht die aktuelle Transaktion ob der Wert txn_energy die zu ladende kWh übersteigt und stoppt dann den Ladevorgang

Ich werde mal berichten ob's geklappt hat!

Dir vielen Dank für den super Ansatz mittels CM Variablen!

Schönes Wochenende! :)

Ahh okay!
Das ist dann so oder so am ende "unkomfortabel" :D
Die Frage da ist eben auch WIE der Soc dann immer eingeben werden kann bzw. muss.
Also weiterhin gibts die möglichkeit, das trotzdem komplett innerhalb des CM zu machen, über Laderegeln und die bedingung-Formel funktion geht ja quasi "alles".  Du könntest dann eine variable anlegen, wie viel kwh dein Azto laden kann (also inkl. der ladeverluste) und dann ja mit dem soc zusammen ausrechnen wie viel kwh bis 80 nötig sind, so wie dus eben vor hattest in openhab.
Den SoC könnte man dann als globale CM variable immer angeben, oder wenn das zu umständlich ist auch da über die API für die CM Variablen (in der Doku etwas versteckt!) setzen (je nachdem wo du das eben eingeben willst, wenn du da eh was neues bauen musst).

oder halt wie du schon sagst als alternative Variante das ganze komplett auslagern, wie viel kwh grade geladen sind sollte ja auch in der txn_energy variable stehen (siehe dazu diese dokuseite), die du ja auch als global setzen kannst per regel und dann regelmäßig holen oder eben  auch per output direkt in openhab setzen. Aber das ist nur theorie :D

gibt sicher auch noch mehr varianten, aber was da jetzt die beste und schnellste is weis ich nicht.

Übrigends gibts auch beim mokka sicherlich möglichkeiten an den SoC zu kommen - was ja auf jeden fall am komfortablesten wäre am ende. Ich persönlich hab tronity, und die bieten ne api an, wo man dann auch den soc holen kann. in meinem fall früher per iobroker oder seit neusten in nodered und dann von dort aus per eigener  zählerdefintion in den cm. aber tronity kostet halt geld :D
aber ist auch nur eine von mehreren optionen sicherlich.

EDIT: die links haben nicht geklappt, dann so:
HTTP API für die globalen CM variablen (die versteckte doku): https://www.cfos-emobility.de/de/cfos-charging-manager/documentation/active-power-control.htm
formeln (txn_ernergy): https://www.cfos-emobility.de/de/cfos-charging-manager/documentation/formulas.htm

und laderegeln e-Auto (kennst du ja aber sicher schon): https://www.cfos-emobility.de/de/cfos-charging-manager/documentation/charging-rules.htm

Edit2:
eine möglichkeit budgets direkt per api dynamisch zu setzen ist mir leider nicht bekannt!

Aber quasi per Laderegel und txn_energy mit einem aus openhab vorgegeben "eigenen budget" (was per CM-variable in den CM kommt) vergleichen und nur solange laden kommt da ja eig am nähesten! :D

Hi,

danke dir für deine schnelle Antwort. Dabei fällt mir auf, dass ich das im Post etwas ungenau geschrieben habe. Den SoC müsste ich in OH zu Beginn des Ladevorgangs manuell einstellen, da wir den nicht aus dem Auto auslesen können (oder zumindest ist mir das nicht bekannt wie es geht).

D.h. dass  der sich, für die Wallbox gesehen, während des Ladevorgangs nicht ändert. Daher war meine Idee im Vorfeld zu berechnen wieviel kWh denn geladen werden müssten und den Ladevorgang dann entsprechend abzubrechen.

Ohne da jetzt zu viele Worte zu verlieren:
Ja klar, das hab ich umgesetzt (und noch viel mehr).
Wenn du sowieso Openhab hast und dort den soc des auto hast: warum dann nicht einfach den SoC per eigener Zählerdefinition in die cfos holen oder alternativ per obenhab und via CM-Variablen in die cfos schreiben (rum wie num wahrscheinlich) und dann per Laderegel direkt den SoC abfragen.
Der Wer mit Budgets und über die geladene Energiemenge ist für dein Ziel ja im Grunde nur ein "umweg" :)