Support charging with delayed start

[sveinse]

The Zaptec chargers seems to be configured to automatically start charging on connect if a) the car is ready and b) no authorization is needed. Some users might want to have delayed start of charging, e.g. for when price is low or consumption is low.

There is a method that seems to work which involves setting the charge current (depends on PR #48):

1. Set available charge current to 0 before cable is inserted.
2. Insert cable. Observe that the charger goes into charger operation mode "waiting"
3. Set the wanted charge current. Charging will start automatically
4. Pause, resume and finish charging as per usual

The major downside to this method is that it controls the charge current on installation level. This means if one have several circuits and/or chargers it will affect them all. So this method doesn't really work in larger installations with multiple chargers.

Side note: There is an (undocumented) setting on each charger named ChargerMinCurrent and ChargerMaxCurrent. Perhaps they can be used for this on per-charger basis? I've reached out to Zaptec to ask how delayed start should best be implemented. Other 3rd party integrations are able to do this, but it's not evident how.

The above procedure is different from the pause/resume logic which is implemented with zaptec_*_switch. How can we (best) implement an automatic charging scheme for the users that wants to configure delayed start?

[Hellowlol]

I think the default settings from Zaptec make sense.

I don't really see the problem if the charger is locked or you ajust the current so it's possible that the charger allows charging. Eather way there is something external that triggers an action that allow the charging to start. One possible option could be to create a service that execute a call at a specific time in the future, but the same could be done with automation.

My solution for my own charger was that the charger was unlocked by a presence sensor of the car. I hope we get some answers from Zaptec on the best way to solve this.

[sveinse]

I guess it all depends on the use case. For those users that only connect the car and then charge, the default behavior is fine. But e.g. for smart home control like charging when the energy prices are low, the charger should not auto start on connect. This is what I'm aspiring for in HA (in order to use this for a refund from Enova).

When the car is connected, the charge current must be set to 0 in advance in order to prevent it from auto starting. This can be automated on cable disconnect. When connected, turning on zaptec_*_switch or issuing resume_charging does nothing, as the charger is internally already in charging, but in a waiting state. The switch is off since its not in active charging mode. That is possibly unexpected behavior.

The above logic is automatable in HA, but this outlined use case will require some tinkering to work. I could envision a setting switch: "Don't start charging on cable connect." and then start/stop switch/services work as before.

[gustafssone]

Glad to see that someone else ran into same problem as me. @sveinse I solved it with a webhook: https://github.com/gustafssone/zaptecwebhook

[sveinse]

Glad to see that someone else ran into same problem as me. @sveinse I solved it with a webhook: https://github.com/gustafssone/zaptecwebhook

Awesome. I'll take a look at this. I have disregarded how to handle charging authentication for now, but at a glance it seems you have considered it.

[JensDebergh]

Hey guys!

Just wanted to share an easier way to do delayed charging without installing docker containers, setting up a public routes or tampering with the current of your zaptec installation!

Steps:

1) Create a new service in this library called authorize

2) Setup zaptec to only charge on authorisation (this can be done via the mobile app). You will be able to authorize a charging session via the zaptec app. Only users with an authorization clearance for your charger will be allowed to charge.

3) Plug in your car

4) You car will probably "error" out on charging with error code "No charge" (atleast this is the error I get on a tesla)

5) Create an automation that calls the authorise service at the desired time. Your car should start to charge by calling this endpoint, from there on out you have a valid session and all the other services in this library like resume, pause, stop should just work.

I already opened an issue here https://github.com/custom-components/zaptec/issues/55 for a new service that needs to be integrated for this to work out of the box.

Currently I have this implemented at home with a custom API call (since the service isn't in this library yet).

The API call (which is undocumented - more details in the above issue) that needs to be added is:

URL: https://api.zaptec.com/api/chargers/<charger_id>/authorizecharge Method: POST Headers:

Authorization: Bearer <ACCESS_TOKEN>

I'm not too familiar with python, but would anyone be able to add this service endpoint?

From there I have actions hooked up to my HA / apple watch to do manual charging.

[philsson]

Hey guys!

Just wanted to share an easier way to do delayed charging without installing docker containers and setting up a public route to your home assistant!

Steps:

1. Create a new service in this library called authorize
2. Setup zaptec to only charge on authorisation (this can be done via the mobile app). You will be able to authorize a charging session via the zaptec app. Only users with an authorization clearance for your charger will be allowed to charge.
3. Plug in your car
4. You car will probably "error" out on charging with error code "No charge" (atleast this is the error I get on a tesla)
5. Create an automation that calls the authorise service at the desired time. Your car should start to charge by calling this endpoint, from there on out you have a valid session and all the other services in this library like resume, pause, stop should just work.

I already opened an issue here #55 for a new service that needs to be integrated for this to work out of the box.

Currently I have this implemented at home with a custom API call (since the service isn't in this library yet).

The API call (which is undocumented - more details in the above issue) that needs to be added is:

URL: https://api.zaptec.com/api/chargers/<charger_id>/authorizecharge Method: POST Headers:

Authorization: Bearer <ACCESS_TOKEN>

I'm not too familiar with python, but would anyone be able to add this service endpoint?

From there I have actions hooked up to my HA / apple watch to do manual charging.

This sounds promising. Thanks for sharing.

[sveinse]

Nice work! I've implemented this (as buttons, not services) in my zaptec-dev branch already, which I hope will find its way into the mainline code.

I think we have the following charge startup use cases:

1. Immediate charge on plug-in, no authentication required ("public charge", works out of box)
2. Immediate charge on plug-in after authentication with rfid tag (works out of box)
3. No charge on plug-in, no authentication required. Delayed start by HA (e.g. night charging)
4. No charge on plug-in, immediate authentication by rfid tag. Delayed start by HA.
5. No charge on plug-in. Authentication by HA when charging is to begin.

We need to support all of these I think. Per now I use no 3, but I'm considering no 4. No 5 is @JensDebergh use-case I believe.

[JensDebergh]

Hi @sveinse

I would go for the security by default route. The user won't be affected because they can automate the process through the authentication flow (which is tucked away in this library). They don't have to worry about it.

1. You setup in home assistant when you want to charge
2. Plug in your vehicle with authentication enabled by default - (I think this was the setting that came with my charger by default, documentation also hints this is becoming the default)
3. Zaptec auth service authorises at the time you want it to charge.

---

Cool thing about this working now is that I've fully automated the charging based on my solar production and peak usage. If peak usage is high because multiple heavy appliances are running in the house I'm pausing the charging session until the peak usage drops below a certain treshold. (We get punished in belgium for having a high peak usage)

The API services make it so easy to do, so don't remove them please!

[sveinse]

I would go for the security by default route. The user won't be affected because they can automate the process through the authentication flow (which is tucked away in this library). They don't have to worry about it.

I think we need all of them. Not all use authentication and it should be equally easy to use all of them. Delayed start doesn't need authentication, which is discussed below.

Cool thing about this working now is that I've fully automated the charging based on my solar production and peak usage. If peak usage is high because multiple heavy appliances are running in the house I'm pausing the charging session until the peak usage drops below a certain treshold. (We get punished in belgium for having a high peak usage)

Please note that pausing a charge session will put it into "Finished" mode, which (I think) will unlock the cable. So possibly we need to consider the security aspects of cable locking if it is a part of the needs for authentication.

If a car is connected to the charger and it doesn't immediately start charging, it doesn't actually matter if the delayed start of it is done via start charge commands or via authentication from HA. Unless there is a way for HA to verify that the right car is connected, authentication doesn't add anything. A "blind" authenticate command from HA is simply a start charge command without any added security.

Since the EV doesn't start charging immediately on connect, having anyone else connecting to the charger to steal power won't work. HA needs to enable it.

The API services make it so easy to do, so don't remove them please!

Got it. I'll leave them in. -- Personally I find digging up and using the long charger UID for the service much harder to do user-wise than to interact with a button entity. The latter seems to be the normal HA way of doing this. But I see the point and will leave it in as an alternative. Thanks.

[sveinse]

I got feedback from Zaptec that there are two ways to delay start of charging:

• Setting available current to 0 A in the installation object (-- which is already supported in our zaptec HA integration)
• Use the portal to set "scheduled power control"

The available current is set on the installation level. I haven't officially confirmed it, but I would expect that setting it will affect all chargers in the installation. I interpret this to that it won't be possible to schedule two (or more) chargers independently of each others. Even if on different circuits.

I don't know how many HA zaptec users will control an installation with multiple chargers.