chargeTimeRemainingalways the amount of time left to charge fully?
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.
When a user changes their password:
linkedVendorsfor that user at
GET /me- that vendor will still be listed, but with
user:vehicle:deletedwill fire for each vehicle that is now unreachable
GET /vehicles/:idfor those vehicles will return
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.
vehicle.location.longitude), overwriting any previous value stored
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.
You should treat it as an opaque, universally unique id string.
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.
Typically < 1000ms,
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.
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.
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.
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.
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.
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.
chargeTimeRemainingalways 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.
We override those. For instance, a user has a schedule in his BMW app but then connects his BMW to the Bulb 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.
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.
We will not override what we interpret as a manual intervention from you.
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.