Smart charging

Regular or “dumb” charging would be that after the source of electricity plugs in an electric vehicle, it starts charging. It charges with as high of an effect as possible until fully charged.

Smart charging is anything other than that.

Why?

So, what are some of the reasons to smart charge a vehicle:

• Energy Price powered – The most obvious motivation for smart charging is to charge when the energy price is low and not charge or charge slower when the price is high.
• Load Balancing – Combined with other sensors, a smart charging algorithm can avoid going over the main breaker by slowing down or temporarily stopping charging.
• Peak Shaving – This is a very similar concept to Load Balancing. The only difference is that the limiter isn’t a breaker but a financial incentive in the electricity price plan.
• Demand Response – DR is not as common, but it will be an essential piece of the puzzle of electrification in the future. It means limiting charging based on a signal from the grid operator if a load is too high in a region.

How?

There are multiple ways to control the charging.

Vehicle Computer

Today, vehicles are advanced computers on wheels. Most of the time, they have some onboard way to configure how the charging should happen. The downside is that we have no programmatic control over how the sessions work, so looking at the changing spot price, for example, is impossible.

Manufacturer API

Now this is where things start being interesting. Modern car comes with connectivity. They have their own SIM card installed, and via a cellular network, they connect to the Internet.

The primary reason is that the car can connect to the manufacturer’s server and report data. Another reason is to enable these consumer apps – “car remote” that come with a vehicle.

It is possible to reverse-engineer the APIs used by the car remotes. It is a remote client running on a phone. In the end, there needs to be some form of API that talks to the OEM (Original Equipment Manufacturer) server and sends commands to the car.

For Hyundai – which is the car I tested this with – there is a bluelinky library. So there you can do simple commands such as:

const BlueLinky = require('bluelinky');
const client = new BlueLinky({
    username: credentials.email,
    password: credentials.password,
    pin: credentials.pin,

    region: 'EU',
    brand: 'hyundai',
})

const vehicle = client.getVehicle(connection.vehicle.vin);
await vehicle.startCharge();

I built a test app to learn more about the concept. Check it out if you would like. ZapZenith is the way I charge my car primarily nowadays.

CONS:

Using manufacturer API works great for simple tests. And many companies are built around the concept. For example, there is SmartCar that abstracts away these APIs for all the manufacturers and provides a unified interface.

Another con I encounter with my car is that the car system, when I instruct the vehicle to stop charging within a couple of hours, will re-enable charging on its own. So I had to build a guard that checks every 20 minutes if it is not charging when it is not supposed to and turns it off again.

And finally, these APIs are not exactly public and well documented. There are daily limits (like hundreds of calls per day), and the OEMs can change or block access at any time.

Charger

Another way to approach the problem is to control the chargebox.

It turns out chargers are way less secretive about their API. A de-facto standard governs these devices – OCPP (Open Charge Point Protocol). Check the Open Charge Alliance website to learn more.

How it works is that the on charger you can configure its OCPP server it is supposed to connect to. Then the charger initialises the connection to a server, and they establish a websocket. After that, bidirectional communication starts happening, and both the client and server can send messages defined in OCPP standards to each other.

To make things even easier, there are basic implementations of the OCPP protocol. I am using this one.

There are a few messages to look into when it comes to smart charging, but the core ones are the ones related to Charging Profiles.

With Blive, we have just become an OCA member and are going to the following industry event to test some prototypes we have been working on together with other players in the industry.

Roaming

I am looking into learning more about the area of OCPI (Open Charge Point Interface) as one of the roaming protocols.

The core concept is that traditionally, there is only one OCPP backend per charger. To limit the number of user accounts, we need to set up with different charging apps we have roaming.

So the charger talks to its backend over OCPP, and then these backends talk between themselves via OCPI. The topology gets more complicated as a hub also connects the backends in practice.

The bottom line is that as long as your system controls the charging session via OCPI, you can also set a charging profile. Although, from what I’ve seen so far, it is more limited and less supported than a direct OCPP setup.

Final Note

There are many ways to achieve smart charging. We have barely scratched the surface of the use cases in this space.

Also, the technologies are quickly changing. For example, the upcoming OCPP 2.1 should introduce the ability to control smart charging by the vehicle and many more cool applications.

OCPP is the most reliable way to implement a form of control like that. That being said, I’ll probably learn more and be proven wrong many times in the future 🙂