AlphaESS SMILE-G3-EVCT11 Wallbox (EN+) mit OCPP

[Kavino112]

Hallo zusammen,

ich verwende die Wallbox EN+ SMILE-G3-EVCT11 (AlphaESS OEM) und habe sie erfolgreich über OCPP via WLAN mit evcc verbunden. Die Verbindung über WebSocket steht stabil, der Status wird regelmäßig aktualisiert, und es gibt keine offensichtlichen Verbindungsprobleme.

Was nicht funktioniert:
OCPP-Steuerkommandos wie RemoteStartTransaction, RemoteStopTransaction oder SetChargingProfile werden von evcc zwar gesendet und auch vom Charger mit Accepted bestätigt – jedoch hat das keine praktische Auswirkung. Der Ladevorgang startet nicht, und auch ein Stop-Kommando bewirkt nichts. Auch das setzten der Phasenanzahl funktioniert nicht.

Bereits geprüft:

 Die RS485-Verbindung zum AlphaESS-Wechselrichter habe ich  getrennt.

Im Log taucht regelmäßig ocpp: sync error: unsupported OCPP command: TriggerMessage auf.

Firmwareseitig scheint laut EN+ Support alles in Ordnung, OCPP 1.6J wird vollständig unterstützt.

Antwort von EN+:
Der Support hat mir u. a. geraten, das SetChargingProfile-Kommando testweise mit "Relative" statt "Absolute" Zeitangaben zu senden, da z. B. "Absolute" oder "Recurring" einen recurringType benötigen.

Meine Fragen an euch:

Nutzt evcc bei EN+-Wallboxen standardmäßig SetChargingProfile mit "Absolute"? Falls ja, kann man das irgendwo umstellen oder testen?

Gibt es bekannte Einschränkungen oder offene Punkte mit dieser Wallbox und evcc?

Hat jemand das Verhalten mit einer EN+ Box unter evcc stabil ans Laufen gebracht?

Ich wäre sehr dankbar für jede Rückmeldung oder einen technischen Hinweis, an welcher Stelle das scheitern könnte.
Vollständiges Log: https://xup.in/dl,14358759
Mailverlauf mit EN+: https://www.xup.in/dl,13372684/Mailverlauf.pdf/

Viele Grüße
Kevin

[ocpp ] 2025/06/12 15:20:51 connecting to: ws://192.168.178.55:8887/EVSEID
[ocpp ] 2025/06/12 15:20:52 connected
[ocpp ] 2025/06/12 15:20:52 send boot notification
[ocpp ] 2025/06/12 15:20:52 call BootNotification: {ChargePointVendor:ENPLUS ChargePointModel:SMILE-G3-EVCT11 FirmwareVersion:EVCT11_20231023}
[ocpp ] 2025/06/12 15:20:52 call result BootNotification: Accepted, interval=60s
[ocpp ] 2025/06/12 15:20:52 set status: Available
[ocpp ] 2025/06/12 15:20:53 call Heartbeat
[ocpp ] 2025/06/12 15:20:53 call result Heartbeat: currentTime=2025-06-12T13:20:53Z
[ocpp ] 2025/06/12 15:20:58 status: Preparing
[ocpp ] 2025/06/12 15:20:58 setting status: Preparing

Versuch Start
[ocpp ] 2025/06/12 15:21:04 call RemoteStartTransaction
[ocpp ] 2025/06/12 15:21:04 call result RemoteStartTransaction: Accepted
[ocpp ] 2025/06/12 15:21:08 call MeterValues: [value=0.00 W]
[ocpp ] 2025/06/12 15:21:12 call SetChargingProfile
[ocpp ] 2025/06/12 15:21:17 call result SetChargingProfile: Accepted
[ocpp ] 2025/06/12 15:21:20 call MeterValues: [value=0.00 W]

Versuch Stop
[ocpp ] 2025/06/12 15:21:26 call RemoteStopTransaction
[ocpp ] 2025/06/12 15:21:30 call result RemoteStopTransaction: Accepted

Weiterhin keine Reaktion – Status bleibt Preparing
[ocpp ] 2025/06/12 15:21:38 status: Preparing
[ocpp ] 2025/06/12 15:21:44 call MeterValues: [value=0.00 W]
[ocpp ] 2025/06/12 15:21:59 call MeterValues: [value=0.00 W]
[ocpp ] 2025/06/12 15:22:14 call MeterValues: [value=0.00 W]

Fahrzeug wurde manuell geweckt
[ocpp ] 2025/06/12 15:22:20 status: Charging
[ocpp ] 2025/06/12 15:22:29 call MeterValues: [value=2468.10 W]
[ocpp ] 2025/06/12 15:22:45 call MeterValues: [value=2480.60 W]
[ocpp ] 2025/06/12 15:23:00 call MeterValues: [value=2512.20 W]

Versuch Stop erneut
[ocpp ] 2025/06/12 15:23:04 call RemoteStopTransaction
KEINE ANTWORT vom Charger, obwohl er lädt
[ocpp ] 2025/06/12 15:23:15 call MeterValues: [value=2501.00 W]
[ocpp ] 2025/06/12 15:23:30 call MeterValues: [value=2499.20 W]
`

# ===========================
# evcc.yaml - Konfigurationsdatei
# Stand: 2025-06-14
# ===========================

# --- Allgemeine Einstellungen ---
network:
  host: evcc.local
  port: 7070

log: debug
levels:
  ocpp: debug        # zeigt alle OCPP-Nachrichten
  charger: debug     # zeigt Steuerbefehle auf Wallbox-Ebene
  auth: debug         # zeigt z. B. RFID/IDTag-Aktionen

# === Strommessung über AlphaESS Wechselrichter ===
#meters:
#- type: template
#  template: alpha-ess-smile
#  id: 85
#  host: 192.168.178.174
#  port: 502
#  usage: grid
#  modbus: tcpip
#  name: grid1
#- type: template
#  template: alpha-ess-smile
#  id: 85
#  host: 192.168.178.174
#  port: 502
#  usage: pv
#  modbus: tcpip
#  name: pv2
#- type: template
#  template: alpha-ess-smile
#  id: 85
#  host: 192.168.178.174
#  port: 502
#  usage: battery
#  modbus: tcpip
#  name: battery3

# === Wallbox ===
chargers:
- type: template
  template: ocpp-enplus
  stationid: ALP***
  name: AlphaESS_SMILE_G3_EVCT11
  remotestart: true
#  idtag: ***
  connecttimeout: 10m
  meterinterval: 10s
  metervalues: Energy.Active.Import.Register,Power.Active.Import,SoC,Current.Offered,Power.Offered,Current.Import,Voltage

# === Ladepunkt ===
loadpoints:
- title: AlphaESS SMILE G3 EVCT11
  charger: AlphaESS_SMILE_G3_EVCT11
  vehicle: Peugeot-e208
  mode: now
  guardduration: 30s
#  mincurrent: 6
#  maxcurrent: 16
#  phases: 1

# === Auto  ===
vehicles:
-   title: Peugeot e-208
    name: Peugeot-e208
    type: template
    template: peugeot
    user: ***
    accesstoken: ***
    refreshtoken: ***

# === Standortkonfiguration ===
site:
  title: PV-Ladestation Zuhause
#  meters:
#    grid: grid1
#    pv: pv2
#    battery: battery3
```

[mfuchs1984]

RemoteStopTransaction sendet evcc in aktuellen Versionen nicht, stattdessen sendet es ein charging Profile mit Limit 0. Woher kommt das Log? Mach mal ein vernünftiges mit ocpp auf trace, Rest auf debug. Darin sollte der Start von evcc ohne Auto, das anstecken, der Start eines Ladevorgang, sowie Umschalten zwischen schnell, min+PV und aus enthalten sein, alles mit genügend Zeit zwischen den Vorgängen.

[Kavino112]

Danke für deine Antwort. Aktuell habe ich nur dieses Log.

log: debug
levels:
ocpp: debug
charger: debug
auth: debug

Vollständiges Log: https://xup.in/dl,14358759

Mein Auto ist zurzeit leider auf 100 % geladen und kann dir somit noch kein zusätzliches Log liefern. Hole ich aber die Tage nach.

[mfuchs1984]

Dann beim nächsten mal mit ocpp: trace

Ergebnis am besten hier als Datei hochladen.

[Kavino112]

evcc-test.log

Hier einmal der Log im OCPP-Trace Modus.

Ich habe das Auto angeschlossen und da in meiner Yaml das sofort Laden aktiviert ist, hat das laden sofort begonnen. (Naja, beim ersten Einstecken des Ladesteckers funktioniert es meistens noch nicht. Aber dann beim zweiten Versuch startet das laden. Danach habe ich im 30-Sekundentakt die Modis ausprobiert. AUS, PV, Min+PV und zum Schluss habe ich einmal von einphasigem laden auf dreiphasigem laden und wieder zurückgeschaltet. Zum Schluss nochmal AUS. Leider hat keine meiner Aktionen zu einer Veränderung geführt.

Vielen Dank für euren Support

[mfuchs1984]

Dann probier's mal mit der Home Assistant integration, siehe #18414

Wenn die Version 8.x nicht funktioniert, probier mal die 7.0.

[Kavino112]

home-assistant_2025-06-20T19-54-33.042Z.log

Das Addon funktioniert. Ich kann mit Reset sogar mein Auto aufwecken. Das ist echt genial.

Jetzt muss ich das Addon bei evcc einbinden. Könnte das nicht evcc mal direkt umsetzten?

[mfuchs1984]

Man könnte ein template aus meiner Vorlage machen, damit die Steuerung über das addon einfacher wird, dazu bin ich aber noch nicht gekommen. Probier's mal nach meiner Anleitung aus, wenn du nicht weiter kommst, melde dich.

[Kavino112]

Ja, das wäre auf jeden Fall etwas einfacher. Schöner wäre es allerdings, wenn evcc selber das beherrschen könnte und man nicht diesem Umweg nehmen müsste.

Ich probiere deine Anleitung aus.

Vielen Dank für deine Unterstützung.

[mfuchs1984]

Evcc beherrscht ocpp, das Problem ist hier die Wallbox, die das smart charging Profil nicht vollständig beherrscht. Früher verwendete evcc relative Profile, was aber wiederum bei anderen Wallboxen Probleme machte. Und alles konfigurierbar machen, weil eines von hundert Modellen nicht funktioniert, wäre wohl auch wieder nicht gerechtfertigt. Ist ein schwieriges Thema, das viele Wallbox Hersteller leider nicht unter Kontrolle haben bzw. nicht wirklich wollen.

[Kavino112]

Hallo zusammen,

ich möchte nochmal betonen, dass das aktuelle ocpp-enplus Template in evcc in der Form so nicht funktionieren kann – zumindest nicht mit der EN+ Wallbox, die ich im Einsatz habe.

Der Hersteller hat mir bestätigt, dass die Wallbox vor allem „relative“ Ladeprofile zuverlässig unterstützt, nicht aber die „absoluten“ Profile, auf die das Template aktuell setzt. Das führt in der Praxis dazu, dass Ladestrombegrenzungen oder dynamisches Smart Charging nicht richtig umgesetzt werden können.

Außerdem unterstützt die Wallbox einen Reset-Befehl per OCPP, mit dem man ein Fahrzeug zuverlässig aufwecken könnte.

Das bedeutet:

Die Ladeprofile im Template sollten auf Wunsch „relativ“ statt „absolut“ konfigurierbar sein, um mit der Wallbox kompatibel zu sein.

Der Reset-Befehl zur Fahrzeug-Weckfunktion müsste als optionale Konfiguration im Template ergänzt werden.

Nur so kann das Template die volle Funktionalität der EN+ Wallbox ausnutzen und zuverlässig mit evcc zusammenarbeiten.

Ich kann gern weitere Infos und Logs bereitstellen, falls das bei der Anpassung helfen würde.

Viele Grüße
Kevin

[Kavino112]

Alles klar, versteht mich bitte nicht falsch. Ich möchte selber die Thematik verstehen und aktiv mitwirken.

Ich möchte in keinster Weise eure Art der Steuerung kritisieren. Ich möchte es verstehen und versuchen die Wallbox kompatibel zu machen. Es geht hier ja nicht nur um die Wallbox von AlphaESS sondern auch um en+ und davon gibt es viele auf dem Markt.

Ich werde mich jetzt nochmal mit en+ in Verbindung setzen.

Vielen Dank für Ausdauer mich hierbei zu unterstützen. Hut ab!

[Kavino112]

Allerdings kann ich im Log auch kein remotestart finden.

Aus deinem log

Oct 19 15:40:17 evcc evcc[3071]: [ocpp  ] TRACE 2025/10/19 15:40:17 send ALP231200404112: [2,"1798735663","RemoteStartTransaction",{"connectorId":1,"idTag":"evcc"}]
Oct 19 15:40:18 evcc evcc[3071]: [ocpp  ] TRACE 2025/10/19 15:40:18 recv ALP231200404112: [3,"1798735663",{"status":"Accepted"}]

Vielen Dank. Ich werde es en+ mitgeben. Eventuell findet er den Grund warum der Befehl nur selten bei der Wallbox funktioniert.

[Kavino112]

Leider habe ich von EN+ bisher keine Antwort erhalten. Ich habe heute nochmal erneut angefragt.

[Nagetier]

Hallo,
Ich stehe auch vor der Einrichtung dieser Wallbox mit evcc, hattest du noch eine Antwort erhalten?

[Kavino112]

Nein leider nicht. Ich werde aber trotzdem nochmal ne Mail hin schreiben.
So leicht gebe ich nicht auf.

Eventuell magst du auch einmal ne Mail dort hin schreiben. Vielleicht hast du ja mehr Glück.

[premultiply]

Bitte mal ab morgen das aktuelle Nightly probieren.
Durch #27309 könnte die Kompatiblität mit den EN+-Boxen verbessert worden sein.

Bei Erfolg können wir gerne ein entsprechendes Meta-Template hinzufügen.

[mfuchs1984]

Die wallbox kann keine Phasenumschaltung, zumindest nicht über ocpp.

[Kavino112]

Dann ist es halt so. Viel spannender ist ob die Wallbox mit TXProfile reagiert.

[mfuchs1984]

Das musst du wohl experimentell herausfinden, entweder indem du die lokal eine modifizierte evcc version baust, oder bspw. mit dem OCPP Home Assistant addon https://github.com/lbbrhzn/ocpp oder mit SteVe https://github.com/steve-community/steve oder anderen ocpp Servern.

[Kavino112]

OCPP SmartCharging wird akzeptiert, aber nicht zuverlässig umgesetzt (EN+ / AlphaESS EVCT11)
Zusammenfassung

Bei umfangreichen Tests mit einer EN+ / AlphaESS Wallbox (EVCT11) zeigt sich, dass Smart-Charging-Befehle über OCPP 1.6J zwar akzeptiert werden, aber in der Praxis nicht zuverlässig umgesetzt werden.

Die Wallbox meldet Unterstützung für SmartCharging, jedoch funktionieren dynamische Stromänderungen sowie Ladepausen über ChargingProfiles nicht reproduzierbar.

Wallbox Informationen

Hersteller: EN+ / AlphaESS
Modell: EVCT11
Firmware: V43.0.750
OCPP Version: 1.6J

Aus GetConfiguration
SupportedFeatureProfiles:
Core,Reservation,FirmwareManagement,
LocalAuthListManagement,RemoteTrigger,SmartCharging

Weitere relevante Parameter:

ChargeProfileMaxStackLevel = 5
ChargingScheduleAllowedChargingRateUnit = Current
MaxChargingProfilesInstalled = 3
Testumgebung

Die Tests wurden mit einem eigenen OCPP-Testserver durchgeführt.

Testsetup
OCPP Server: eigener Node.js Testserver
Protokoll: OCPP 1.6J
Verbindung: WebSocket
reales Fahrzeug angeschlossen

Die Ladeleistung wurde überprüft über:

MeterValues der Wallbox
externes Strommessgerät
Getestete Smart-Charging Varianten
ChargingProfile Typen
TxDefaultProfile
TxProfile
ChargePointMaxProfile
ChargingSchedule Typen
Relative
Absolute
Stromlimits
16 A
10 A
8 A
6 A
0 A
Getestete Szenarien
Start mit niedriger Stromstärke → Hochregeln
Start mit hoher Stromstärke → Runterregeln
Ladepause über ChargingProfile mit limit = 0
Stop über RemoteStopTransaction

Die Tests wurden automatisiert in mehreren vollständigen Durchläufen durchgeführt.

Beobachtetes Verhalten
RemoteStartTransaction

Funktioniert zuverlässig.

Beispiel:

Verdict: works

Die Ladung startet korrekt.

Dynamische Stromregelung

Getestet mit:

TxProfile
TxDefaultProfile
ChargePointMaxProfile

Typisches Ergebnis:

accepted but charging active but command not clearly enforced
Beobachtung
OCPP bestätigt den Befehl mit Accepted
die reale Ladeleistung bleibt häufig unverändert
gelegentliche Leistungsänderungen sind nicht reproduzierbar

Dieses Verhalten tritt sowohl bei

Relative
Absolute

ChargingSchedules auf.

Ladepause über 0A ChargingProfile

Getestet mit:

zero
zeroabs
tx0
tx0abs
max0
max0abs

Ergebnis:

accepted but 0 A not enforced
Beobachtung
ChargingProfile wird akzeptiert
Fahrzeug lädt weiter
Ladung wird nicht pausiert
RemoteStopTransaction

Ergebnis:

accepted but charging did not stop
Beobachtung
Befehl wird akzeptiert
Wallbox liefert teilweise weiterhin Leistung
Fazit

Die Wallbox akzeptiert Smart-Charging-Befehle formal, setzt sie jedoch nicht zuverlässig als reale Stromregelung um.

Folgende Funktionen funktionieren in der Praxis nicht zuverlässig:

dynamische Stromänderung während einer aktiven Ladesession
Ladepause über ChargingProfile mit limit = 0
zuverlässiger Stop über RemoteStopTransaction

Damit sind typische Smart-Charging Anwendungen derzeit nicht möglich, z. B.:

PV-Überschussladen
dynamische Lastverteilung
Integration in Energiemanagementsysteme

Diese benötigen zuverlässige Übergänge wie:

16A → 10A → 8A → 6A → 0A

während einer aktiven Transaktion.

[Kavino112]

Hi zusammen,

ich möchte hier einmal den aktuellen Stand zur AlphaESS OpenAPI und Wallbox-Steuerung zusammenfassen, da das Thema evcc direkt betrifft.

Aktueller Stand:
Die AlphaESS OpenAPI bietet bereits erste Funktionen für EV-Charger, z. B.:

Abfrage von Daten
Endpoint setEvChargerCurrentsBySn

Problem dabei:
Dieser Endpoint steuert nicht den tatsächlichen Ladestrom der Wallbox, sondern lediglich eine Art globales Haushaltsstrom-Limit.

Für eine Integration in evcc fehlen zentrale Funktionen:

dynamisches Setzen des Ladestroms während der Ladung
Start / Stop der Session
zuverlässige Umsetzung von Smart-Charging

Und genau das ist das Kernproblem:
evcc benötigt dynamische Steuerung des Ladestroms, z. B. über OCPP Smart Charging (SetChargingProfile) oder direkte APIs.

Ohne diese Möglichkeit ist eine Regelung (PV-Überschuss, Lastmanagement etc.) praktisch nicht umsetzbar.

Die Funktionen sind im AlphaESS-System bereits vorhanden:

Steuerung über die App
interne Regelung zwischen PV / Batterie / Wallbox
Kommunikation über RS485

Das heißt:

Die Steuerlogik existiert bereits – sie wird nur nicht über die OpenAPI bereitgestellt.

Aktuell ergibt sich folgendes Verhalten:

Strom kann nur vor dem Start gesetzt werden
während der Ladung keine Anpassung möglich
„Pause“ über 0A (evcc-Standard) funktioniert nicht

Damit ist die Wallbox über OpenAPI:

nicht evcc-kompatibel im praktischen Betrieb

Das ist kein Einzelfall – mehrere Nutzer haben bereits Tickets bei AlphaESS erstellt.

Hintergrund ist, dass AlphaESS mit Smart-Home / API Integration wirbt, diese im Bereich Wallbox aktuell aber nicht vollständig gegeben ist.

Es geht nicht um neue Features, sondern um:
Bereitstellung vorhandener Wallbox-Steuerfunktionen über die OpenAPI

Sollte hier ein AlphaESS-Nutzer mitlesen kann er gerne Unterstützen und ebenfalls ein Ticket bei AlphaESS erstellen. Das erhöht den Bedarf.
Vorlagen für ein Ticket findet ihr im AlphaESS Forum unter:
https://www.storion4you.de/thread/1898-testlabor-alphaess-openapi-walboxsteuerung/?pageNo=1

[Kavino112]

Hi zusammen,

ich möchte hier noch ein aktuelles Update ergänzen, weil es eventuell für die weitere AlphaESS-Integration in evcc interessant werden könnte.

AlphaESS hat offenbar eine neue Plattform vorgestellt:

AlphaESS Unified API Open Platform / Alpha Connect

Link:
https://connect.alphaess.com/
(Webseite funktioniert noch nicht mit allen Browsern)

Dazu gibt es auch einen Beitrag im Storion/AlphaESS-Forum:
https://www.storion4you.de/thread/1943-revolution-im-speichermarkt-alpha-geht-api/?postID=23959#post23959

Auf der Präsentation wird die Plattform mit „Every asset. One Integration.“ beworben. Nach meinem Verständnis soll es dabei nicht nur um einzelne Wechselrichter/Speicher gehen, sondern um eine einheitlichere Schnittstelle für AlphaESS-Komponenten.

Für evcc wäre das aus meiner Sicht besonders interessant, weil der aktuelle Stand bei der AlphaESS SMILE-G3-EVCT11 Wallbox weiterhin schwierig ist:

• OCPP wird von der Wallbox grundsätzlich angenommen
• SmartCharging/SetChargingProfile wird aber nicht zuverlässig umgesetzt
• dynamische Stromänderungen während einer aktiven Ladung funktionieren nicht reproduzierbar
• Ladepause/0A und Stop sind ebenfalls nicht zuverlässig
• die bisherige AlphaESS OpenAPI bietet zwar EV-Charger-Funktionen, aber nach meinem bisherigen Stand keine echte direkte Ladestromsteuerung, wie evcc sie benötigen würde

Parallel gibt es ja bereits Ansätze, AlphaESS-Wechselrichter/Speicher über Modbus TCP auszulesen bzw. teilweise zu steuern. Genau deshalb wäre es spannend, ob AlphaESS mit Alpha Connect künftig eine offiziellere und vollständigere Schnittstelle bereitstellt, über die evcc sowohl Speicher als auch Wallbox sauberer integrieren könnte.

Aus evcc-Sicht wären aus meiner Sicht vor allem diese Funktionen wichtig:

• Start/Stop der Ladung
• dynamisches Setzen des Ladestroms während der aktiven Ladung
• zuverlässige Ladepause
• saubere Status- und Leistungsrückmeldung
• Speicherinformationen und ggf. Speichersteuerung
• perspektivisch auch Phasenumschaltung, falls AlphaESS das offiziell bereitstellt

Mir geht es dabei nicht um einen weiteren Workaround über interne App- oder Monitoring-Endpunkte, sondern um die Frage, ob AlphaESS mit Alpha Connect künftig eine offizielle Schnittstelle bereitstellt, die für evcc sinnvoll nutzbar wäre.

Vielleicht wäre das für das evcc-Team oder andere AlphaESS-Nutzer einen Blick wert.