Adopt to the Zaptec API fair use policy

[sveinse]

With reference to the on-going discussions with Zaptec devs in #176 there is a need to make changes to this Zaptec Home Assistant integration. Currently its polling too frequently and its using mechanisms that are not documented in the API. The Zaptec integration should adhere to the Zaptec API fair use policy.

This issue is a overview of the ongoing efforts:

• [ ] #125
• [x] #176
• [x] #183
• [x] #186
• [x] #187
• [x] #189
• [x] #190

[steinmn]

These are the undocumented/deprecated API-calls I've come across that don't have any PRs yet:

1. POST chargers/{self.id}/localSettings
   • Used for setting HmiBrightness and PermanentCableLock
   • Not possible to handle with current officially supported API, but these settings do seem like they would fit naturally in chargers/{self.id}/update
   • If these settings are added to chargers/{self.id}/update by Zaptec, dropping the use of localSettings becomes very simple.
2. ~~GET chargers/{self.id}/live~~ (removed in #198)"
   • ~~I honestly have no idea what this does, neither on the HA side, nor on the Zaptec side. I’m not touching it unless someone explains what it does.~~
3. GET installation/{self.id}/messagingConnectionDetails (deprecated)
   • Should be moved to userGroups/{id}/messagingConnectionDetails
   • Where do we find "User Group ID"?
4. Authentication/Authorization
   • Used calls
     • ~~PUT installation/{self.id} with data = {"Id": self.id, "IsRequiredAuthentication": bool}~~ (not used for some time, code removed in #240)
     • POST chargers/{self.id}/authorizecharge
   • Not possible to handle with current officially supported API as far as I can see
   • authorizecharge could perhaps be handled by an added command option for chargers/{self.id}/sendCommand/{commandId}?
   • ~~IsRequiredAuthentication could make sense to include in installation/{self.id}/update if Zaptec update the API. On the other hand, this does seem like something you only set once, so maybe we could live with having to set it from the Zaptec portal/app?~~

[sveinse]

The use-case for authentication/authorization is two-fold:

• Be able to have authorization via e.g. NFC tags
• Prevent charge auto-start (delayed start)

By requiring authentication any cars plugged into the charger will not start charging immediately and the cable remains locked. This is a commonly used scenario when using HA to control when to charge. When charging is to commence, the HA integration can authorize and start the charging. This is currently the most reliable method to provide delayed start.

It is possible to prevent auto-start of the battery charging by setting the installation "Available current" and or "ChargerMaxCurrent" to 0. This is how charge current is regulated when charging. Unfortunately, these parameters reset to their max value by Zaptec cloud on some occasions. If the max current has been reset to max, the car will start to charge on cable insert, which is unintended.

[sveinse]

@steinmn Thank you for the run-down of API calls. I've created #192 where I intend to collect a list of the features we'd like to have implemented into the official Zaptec API.

[sveinse]

@steinm item number 2 in your list above has been removed. Could you update it, by placing a strike-through on it, please? "~~GET chargers/{self.id}/live~~ (removed in #198)" or somesuch.