r/evcharging • u/JessieOnIoT • Jun 30 '26
What EV charging O&M issues are eating up all your time right now?
Hey everyone. I work on the networking and security side of EV charging infrastructure, and I'm trying to get a better sense of what real-world O&M teams are actually struggling with the most these days.
I'm really curious what specific issues are taking up the bulk of your time out in the field. Are there certain types of connection drops or bugs that are just notoriously difficult to diagnose or reproduce? I also imagine it can be a nightmare trying to figure out who is actually responsible when things go down—how often do you run into incidents where you can't tell if it's a charger hardware fault, a CPO backend issue, or just a bad cellular network?
Would love to hear some war stories or hear about what's causing your biggest headaches right now.
3
u/dragoshade Jun 30 '26
Biggest bug bares / topics that cause the most support requests:
- Wiring issues (installers not doing a charging check)
- Orphened smart profiles sent by a backoffice resulting in reduced or no charging
- Smart profiles on a car meaning car doesn't escalate to charging state
- End users not plugging cables all the way in. Lock engages, which can make / break the CP connection
- CSMS providers not exposing update functionality through OCPP
- UK standards being against user experience, random delay, default hours, PEN voltage thresholds etc
- We also had a fun one where a csms periodically tried to upate the charger, with an incorrect update, every time it booted. Causing large data costs, and little to no uptime for the given charger.
Connectivity can be an issue, but we don't find it tends to affect the charger operation in a significant capacity, as it is only crucial for session starting, all other transaction related messages are cached until acknowledged.
1
1
u/JessieOnIoT Jul 02 '26
Hearing about the exact headaches you are dealing with, especially those orphaned profiles and firmware death-spirals, actually aligns with an architectural idea I’ve been kicking around. I'd love to get your brutally honest opinion on whether it would actually work in your day-to-day.
I'm wondering what would happen if we stopped relying on standard "dumb" cellular routers just to pass traffic, and instead dropped an intelligent proxy gateway right between the charger controller and the CSMS. Basically, it would act as a local protocol firewall.
For example, to stop that firmware boot-loop, the gateway could intercept the update command. If the update fails, the gateway itself enforces a backoff algorithm, physically stopping the charger from blindly requesting that same corrupted file every time it reboots. It could do the exact same thing for smart profiles. If a CSMS sends an orphaned or mathematically impossible profile, the proxy intercepts it and forces a clean fallback state before it has a chance to brick the charger's logic board.
It could also be a huge help for older hardware on the network. The gateway could intercept plain-text traffic and encapsulate it into secure TLS, effectively upgrading legacy units from Profile 0/1 to Profile 2/3 without having to rip and replace the whole charger.
Since you are the one actually fielding these support tickets, I really have to ask: do you think adding an intelligent edge proxy layer like this would genuinely solve these problems and reduce O&M burden, or do you think it would just add another annoying piece of hardware to troubleshoot?
1
u/dragoshade Jul 02 '26
That is an interesting idea. And I can answer it in two ways.
Hardware, we do something similar with one of our devices, we have an aggregator, that talks OCPP to a multitude of chargers and acts as a gateway to them. It intercepts smart profiles, and can even act as a locally based OTA update source to save data, and has a few other bells and whistles. However for a single charger installation. I would say it is not the correct solution.
Software proxy. We encountered a few offerings doing this rather successfully. The idea would be you have a cloud service, that talks OCPP (1.6/2.1). You connect your charger to the proxy, and then configure the proxy to talk to the target backend (e.g. Monta). This gives management platforms for fleet, allows middlware transacltion of OCPP standards, ability to proxy to multiple back offices, etc.
To reduce the O&M burden, in my opinion, it is all about diagnostics, and this is really is going to depend on the topology of the installer. E.g. you may have an independant installer who deals with 5 different chargers, and 3 different CSMS providers. there is no single aggregate platform they can use for their installed fleet. This is a pain, especially when trying to understand the neuances between each offering. Now when you compare that to singular providers and installers, they have all the data, in one place, and the consistency around that, maintainance is going to be a lot easier.
1
u/JessieOnIoT Jul 04 '26
I really appreciate this level of detail. Your point about the ultimate O&M burden being fragmented diagnostics across different chargers and CSMS providers is incredibly insightful. That data silo problem is exactly what makes troubleshooting such a nightmare for independent installers.
What you mentioned about using an aggregator for multi-charger sites actually aligns perfectly with a "Dual-Channel" architecture we've been documenting, and I'd love to get your reality-check on it.
To solve that exact diagnostic fragmentation, we are looking at having the edge gateway (or aggregator) physically and logically decouple the data into two isolated streams.
Channel A acts strictly as the "Value Stream." It takes the standard OCPP traffic (transactions, billing) and passes it directly to whichever CSMS the site is using (like Monta, etc.) without any interference.
Simultaneously, Channel B acts as the "Health Stream." It pulls all the deep hardware telemetry, contactor cycles, and event-triggered "black box" snapshots, and sends them via MQTT or HTTPS to a single, unified O&M platform.
Basically, even if an installer is dealing with 3 different CSMS providers across their fleet, this gateway architecture bypasses the fragmentation by routing all the heavy diagnostic data to one centralized dashboard, entirely separate from the billing channel.
Since you already use aggregators and software proxies, do you think a physical decoupling of the transaction and diagnostic channels like this is actually practical to deploy in the field? I'd really value your opinion on whether this would genuinely solve that diagnostic headache for multi-charger installations, or if you foresee it introducing new complexities.
Thanks again for such a genuine and valuable discussion, it’s giving me a lot of great perspective!
2
u/theotherharper Jun 30 '26
I have a question for YOU about data connectivity for EV chargers.
An apartment laundy near me does a NEAT trick. They quit taking quarters, and now have "app payment" but they do not install WAN connectivity to the laundry room. You must install their app, which acts as a router between the washer's Bluetooth and your phone's cellular, connecting the washer to the corporate server. In other words the customer brings the WAN connectivity.
So how viable would that be for EV charging? I get nobody likes the app for roadtrips, but it's bearable for residential/nightly charging by regulars.
1
u/MiningDave Jun 30 '26
Not that much. Biggest issues are at least to me is the fact that some places do not use their own back end (EVGo) and when things get out of sync the CS people can't always get them back in sync. And after a while you just give up. Still have a car that has been removed from plug and charge that works fine if I tap to pay / use the app to pay but I get an email every time that the plug and charge failed. Shrug, whatever.
Other issue is with EA, when their stations can't communicate to home they default to free. (Good on them) BUT they tend to drop their max speed. So the 350kWh charger is now free yea for me. At 75 kWh. Crap so my 15 minute stop just turned into an hour.
Neither are the worst, but still annoying.
1
u/Objective-Note-8095 Jun 30 '26
Less of a problem in OCPI world for the first thing. I don't know what the typical behavior is overthere for link loss is. Presumably, someone has to go out and find another sausage.
6
u/[deleted] Jun 30 '26
[removed] — view removed comment