A project culminating in my frustration with the EVC not working locally for me (regardless of firmware version) and the collapse of GivEnergy, I decided to write my own OCPP server for the charger. OCPP is the language which many chargers speak under the hood, and I was glad to see the EVC is no different.
GivEnergy’s portal simply translates web service calls to and from standard OCPP calls which means it’s trivial to “speak” EVC (trivial is underplaying the effort somewhat but once you know it’s trivial).
My integration is installed via HACS in Home Assistant and stands up an OCPP portal which your EVC can connect to and be managed fully locally. It can even do firmware updates (and downgrades) for those inclined.
Features compared to the portal is almost complete - some bits remain and it is in active development but it’s controlling my charger on a daily basis now.
Thanks to the people over on Facebook who helped get it to where it is now.
The screenshots are outdated. The feature list is up to date.
Max Charge Energy Per Session is a server-side feature. It’s not currently implemented because you can manage that in Home Assistant with an automation. I can add it but it’s pretty pointless
Max Charge Power is implemented
Set DNO Fuse Size is implemented
Factory reset is consciously not implemented as it will undo the workaround used to get the charger to talk to the integration. Can easily be added
Charger Configuration is a server side feature. Unless I’m mistaken there is no local equivalent. Changing the setting does not write anything to the charger.
Read and Write CP values are not implemented
Charge Suspended State Wait Time is implemented but hidden unless the user is on v1.14.
Scheduling and RFID tag management are handled via service calls (actions). There are entities available to show schedule and RFID tag data.
The fact the screenshots are outdated goes to show just how quickly this was put together. There has been new features for the past few days. The code is almost done now, I only plan to implement feature parity with the Giv portal then it’s a finished product, and we’re 90% done.
Firmware updates are something we can do that was never possible from the customer portal.
I’ve pushed an update tonight which closes some of the gaps;
Factory reset (with obligatory warning in the readme)
Read CP Duty Cycle button which updates two new entities with the results
Change CP Voltage Range is now confirmed as a server-only function so I’m not implementing that, likewise the other server-side stuff I mentioned earlier
So by my reckoning, that’s fully aligned with the portal now.
Hi yah, a few questions about my system and will this work please. I have a GE Gateway and 2 x AIO’s. The GE EVC is wired onto the GW and has a CT clamp. It’s also Ethernet wired not WiFi. When I charge the car it will not use the battery.
Can your method still be used please.
Will it prevent my AIO’s discharging to the car?
I’m not sure. I have an identical setup to you and my EVC is wired exactly the same but I’ve never been able to get my setup to not discharge from the battery - I have always managed it with Predbat (and GivTCP before it).
Maybe @TheDragon has a view how it might work. If it’s handled by the gateway with no input from the charger (other than the CT clamp) then the portal / my integration is doing nothing so the answer is “it will work the same” but if the Gateway is doing something behind the scenes to control the EVC via the cloud then no, it won’t work.
I’d like to think it’s the gateway handling it but…
GivTCP and GivEVC-OCPP provide comparable functionality in reality - the only difference being my solution is completely disconnected from Giv’s servers but unless that is a consideration for somebody, it’s not necessary to upgrade. Firmware updates are something which might interest more people.
