Replies: 5 comments 9 replies
-
So my use case is a bit different but we have an Wallbox EVSE which is configured with OCPP to enable billing to e-flux. This allows for automatic payments for the charging sessions with my company car or for visitors. However, I can't add my EVSE to EVCC now because OCPP is already configured with the e-flux endpoint. Would your proposal for a proxy solve this as well? |
Beta Was this translation helpful? Give feedback.
-
Yes, I imagine evcc could proxy-forward all the session logic to your e-flux while only handling energy balancing. |
Beta Was this translation helpful? Give feedback.
-
Im actually looking for this as well as I have my Ratio io6 connected with e-flux road as backoffice to handle the automated invoicing as well. |
Beta Was this translation helpful? Give feedback.
-
FWIW if a proxy like this would be useful to you, consider upvoting this discussion. |
Beta Was this translation helpful? Give feedback.
-
I also like the idea of an OCPP proxy - i own a Wallbox which is connected to Octopus Energy via OCPP - would be great to have the statistics and additional control in EVCC. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey,
I'm using a OCPP-only EVSE – ChargeAmps Aura. So far connecting it up to
evcc
went alright and everything seems to be working as advertised. Thank you!However, even before I deployed
evcc
I had my EVSE connected to a node-red instance, giving me a fair bit of custom control and insight into the EVSE. I had some workflows to:evcc
exposes over mqtt or have it write directly to influxevcc
does not appear to handle or expose measurements like EVSE temperature;evcc
;evcc
;One problem, though. OCPP is a many-EVSE-to-one-controller sorta protocol. So I can't have my Aura connected to both
evcc
and node-red at the same time, even if they wouldn't interfere with each other otherwise.This limitation is quite similar to the issue that seems to have motivated creation of the
modbusproxy
component. Which brings me to the idea at hand. Would it make sense to implement a proxy for OCPP, similar to what was done formodbusproxy
? It likely wouldn't be a fully transparent relay – evcc would still need to intercept and specially handle commands that change the amperage for a given charge session, but special cases like these are mostly an exception and most of the messages could be passed through as-is.Maybe there are other straightforward solutions that I've missed in my search?
Beta Was this translation helpful? Give feedback.
All reactions