Am I right in ascertaining that the design principle behind the API is to allow an operator to operate as they please, with very few "fundamental" charging behaviours defined by the charging robot itself?

Yes, behaviour is very configurable and should give operators a large degree of freedom. The only “rules” we have is that operators should keep the customer in focus, and make it clear for users the behaviour to expect from different actions.

If we have access to a charger do we have access to all that charger's history through the API? So, for instance, say an operator moves a charging robot from one site to another site for asset management purposes, can we still access data from before the move? Or is there a limit to how far in the past you can obtain historic consumption data through the API?

Yes if you are in control of the charger you have access to the full history. As an Easee partner we have the policy to treat trust partners and through the partner access in the API there is a lot of information. Should we be informed of misuse or abuse of this trust that we will give fair warning, but also reserve the right to revoke partner access in extreme cases.

• [ ] Follow-up Q: Is the history linked to the chargeberry or the backplate?

Eirik: This is a very good question, and I am not sure. Given how ChargeSessions and consumption in general is tied to ChargerId (SerialNumber) in the back end, I think all existing code ties it to chargeberry. If it should be that way is a different question.

Is there a way to set a specific charging rate? Or is a charger either 'off' or 'on' (and if on, charging as quickly as possible given building circuit constraints?)? Previously Eirik mentioned DynamicChargerCurrent as an option available through the Stream API but I haven’t seen a reference to this in the current documents.

There are multiple ways of doing this and this is a topic on its own 😊

• Top level rates defined by installer / electrician for both site and fuse
• For Home devices there is a ChargerMaxCurrent that is a non-volatile (survives device power loss) limit that users can access.
• DynamicCircuitCurrent, set on primary / master devices to constrain max load on circuit. This is a volatile value and is reset on powerloss. Setting the constraint on circuit level allows the primary device to handle load balancing of circuit locally through Easee Link (radio).
• DynamicChargerCurrent, can be set on all devices to constrain output. The is a volatile value and is reset on powerloss AND car connected event. It was typically forgotten by implementers and caused a lot of confusion for users, so the additional reset on a new charging session was added.
• Basic charge plan. Allows you to define a recurring or one off schedule through REST for timewindows when power is enabled and restricted.

It is worth noting that it is ALWAYS the lowest of these values that define the active limit. There is no hierarchy, the lowest value is always the limit.

It is possible to override a charge plan that is active and limiting current for the current charging session by calling “POST /api/chargers/{id}/commands/override_schedule" This will disable the charge plan for the ongoing session (not available in OCPP).

For limitations on OCPP charge plans, please see the Notion document.

• Follow-up action: Send Peter the REST API command for dynamic current setting.

DynamicCircuitCurrent can be sent to "primary / master" devices and restricts current on a circuit level. For most home users though site = circuit = charger, because there is only 1 charger.