How do you store and keep customer credentials safe?

Authentication details are handled by a dedicated enclave service with the minimal surface area. Its only exposed functions are 1. Store a credential, 2. Evict a credential, and 3. Use a credential to obtain a vendor's session (the expiring token for which it then emits). It persists to a dedicated database, of which it is the only client, a relationship enforced both by authentication and network topology.

Credentials are symmetrically encrypted at rest using AES-256-CBC, with the enclave holding rotating runtime-provisioned keys in RAM. On the way in, a salted SHA-256 hash of credentials is kept outside the enclave for lookup purposes (used in a caching mechanism) though we will soon be able to drop this practice due to an architectural change. Credentials are evicted when: A. The vendor reports them to be invalid, B. Deauthorize User or Delete User is called for the owner or C. They have been unused for 30 days

We treat them independently, so yes. Both are stored and linked to two different users.Nothing. The persons' access is unaffected.

What happens when a user's EV credentials change?

When a user changes their password:

In this case, the user should be sent again through the Link User flow, where they will have the opportunity to sign in using their new password.

How do you store vehicle data?

By default:

That last-value storage is in service of future functionality that will enable opting into partial-refresh requests and could be disabled if needed. Additionally, webhook notifications are created and persisted upon each change and are only evicted upon successful delivery to the configured endpoint. Thus, if your server handling the webhooks becomes unreachable or fails to return 200, then webhook notifications containing vehicle data will pile up on our side. These undelivered notifications are evicted after 24 hours if they remain undeliverable.

A derivative of the location data is stored (in the form of "this vehicle is within geofence X") - but not the coordinates themselves. Given the ~300m resolution of the geofence presence derivative, it can be considered effectively just as sensitive a piece of information as the coordinates themselves in rural contexts. On a related note, the coordinates of each charging location (user-provided lat+lon) are persisted for the lifetime of that user's account, as you would expect.

The radius to enter the geofence is contextual and generally much smaller (say 50m). Still, hysteresis is built to prevent jitter, so a larger 300m radius is used as the "exit" condition. So from a sensitivity perspective, if you steal a database row that shows a vehicle as being "at" a charging location, the only thing you know about that point in time is that the vehicle is within that 300m.


How should we treat Vehicle ID?

You should treat it as an opaque, universally unique id string.

Will a vehicle keep the same Vehicle ID?

Yes! It stays the same. A vehicle can be added to multiple users, and they will all see the same ID. Same when you unlink and link a vehicle again.

How long does command endpoints normally take to return?

Typically < 1000 ms.

How many events can we expect from a single Firehose payload?

Webhook batch size limit is configurable but defaults to `100`. A payload always contains at least one event and never more than the configured batch size limit.

Will I receive a Firehose notification with a new charging state after a command is sent?

Following the use of a charging command, you will expect to receive a firehose notification shortly after indicating that is_charging has transitioned. This can take up to 2 minutes to happen.

Should I rely on Firehose for state changes following a charge command?

You should rely on the Firehose to inform you. This may be a good opportunity for us to expose an "optimistic" variant such as is_charging_transition with intermediate states such as STARTING_CHARGE, STARTING_CHARGE_TIMEOUT, etc. - though we do not currently do this. There may be a synchronous failure (auth problems, reachability problems), which you receive immediately as the response, or asynchronous failure (unknown failure, conflict with something else attempting to control the vehicle, physical user intervention, power supply failure), which you would discover by the lack of transition of is_charging to the expected state. A transition property may best handle this.

What's the median time for a firehouse notification?

Evenly distributed between ~1 second and 2 minutes - where the delay is due to coincidence in a polling interval. When we do go for the "expecting transition" state of some kind, as mentioned above, we would also use that to shorten the polling window temporarily to perhaps 20 seconds.

Smart Charging

Do you have a set charge limit command?

Currently, we do not support that command mainly because most vendors do not support it. However, we are likely going to add a `capabilities` attribute to our vehicle's model, so this, in turn, could be used to know what vehicle supports what and thus make it easier to extend with commands like that. It is on the roadmap, but we haven't set a date yet. It would also be great to see/hear what you are thinking about the use case and maybe even how important you think this feature is for you. We are always open to shifting prioritization.

Will a smart charge plan charge in bursts?

We used to burst, but after re-evaluating the savings and loss (charging efficiency is lower when you do bursts), we switched back to find the optimized single session charge duration. This might change in the future depending on the market structure of electricity prices.

Is the `chargeTimeRemaining` always the amount of time left to charge fully?

`chargeTimeRemaining` will be the same regardless of a charge deadline being set or not. This will always reflect the time until the EV is estimated to hit the full charge. The charging policy with a deadline set won't exactly match up with the `chargeTimeRemaining` simply because we have some buffers to ensure we reach fully charged by the deadline. Things like weather conditions, hot/cold vehicles, parked inside/outside, type of charger all affect the efficiency of a charge, which again affects the actual time it takes to charge fully. For now, we have a reasonably good model with some added buffers, and I am confident this will improve over time.

Will an EV charge past its deadline if it did not hit its full charge on time?


Could smart charging collide with an EVs own schedule?

We override those. For instance, a user has a schedule in his BMW app but then connects his BMW to the "Energy Company" app. He then proceeds to enabled smart charging/only charge between 2 and 6 am. A STOP command sent to this vehicle, say 7 pm, will also update his schedule to reflect that he should not be charging. A proceeding START will do the same but then indicate that the vehicle should charge. So in those cases, we actually use the built-in charging schedule to control the vehicle's charging.

Could smart charging collide with a charging schedule app?

Unfortunately, these services could clash. There is no way for us to communicate to the charger via the vehicle. Potentially this would mean that a "start charge" command would fail if the power were restricted at the charger. Stop charge during a charge would work, though.

What happens if I start/stop charging during a smart charging schedule?

We will not override what we interpret as a manual intervention from you.

If I send a manual start charging command, then unplug the vehicle and plug it back in, would it immediately start charging again? I.e., is the start charging command "remembered"

Yes, it would charge, but it would not be because we did anything. If you did the opposite (and sent "stop charge"), unplugged, and plugged back in again, it would also charge.