Expose pluggedIn / charging on VehicleEntity for Shortcuts automations

[mrscoopman]

VehicleEntity should expose EV plug and charge state so it's readable via "Get Details of Vehicle" in Shortcuts.

Right now VehicleEntity exposes batteryPercentage but not plug status, and GetVehicleStatusIntent only returns a spoken dialog string (.result(dialog:)) with no usable output value. That leaves no way to build a conditional automation — for example, "at 10 PM, if the car isn't plugged in, send a notification." This is a core use case for an EV companion app, and right now the app can't support it.

The data already exists on BBVehicle.evStatus (pluggedIn, charging). Exposing it is a small change: copy those two booleans into VehicleEntity exactly the way batteryPercentage already is in init(from bbVehicle:). Once they're on the entity, Shortcuts can read them as booleans and conditional charging-reminder automations become possible.

Please add pluggedIn and charging to VehicleEntity. Thanks for the great app.

[schmidtwmark]

That's an easy fix, absolutely can do it.

I don't do much shortcut automation--is there anything else I can do to help make it easier?

[mrscoopman]

That's great, thanks for jumping on this so fast.

Since you asked — a few things that would make this genuinely powerful for automations, in rough priority order:

1. Expose the EV/status fields as typed properties on VehicleEntity, not just the two booleans. While you're in init(from bbVehicle:), it'd be worth copying over the rest of the useful status data so Shortcuts gets each as its own real variable via "Get Details of Vehicle": pluggedIn, charging, chargeSpeed, lock status, climate on/off, and ideally odometer / 12V / charge limits. The key thing is they should be proper typed properties (Bool, Int, etc.) — that way Shortcuts can branch on them directly with no string parsing. A Bool for pluggedIn is all that's needed to make "if not plugged in, notify me" work.

2. A way to force a fresh poll before reading status. Right now GetVehicleStatusIntent / VehicleEntity read cached BBVehicle data. For a scheduled automation (e.g. a 10 PM check), the cached status could be hours stale and give a wrong answer. Two options that would solve it: either have RefreshVehicleStatusIntent return the updated VehicleEntity as a result value (so a shortcut can do Refresh → read fields in one chain), or add an optional "refresh first" boolean parameter to the status intent. Either works — the goal is just that an automation can guarantee it's acting on current data.

3. Make GetVehicleStatusIntent return a value, not only a dialog. It currently returns .result(dialog:) only, so the spoken string can't be used programmatically. If it also returned the VehicleEntity (or the typed fields) as .result(value:), that intent becomes usable in automations too, instead of being voice-only.

If #1 lands with pluggedIn as a Bool, that alone unblocks my use case. #2 and #3 just make it robust. Happy to test any of these!

Thanks again.

[schmidtwmark]

Thanks for the detailed write up! That all sounds reasonable--I've wanted to improve the shortcuts primitives for a while. I can take a look at this tomorrow, but you're more than welcome to open a PR!

[mrscoopman]

Thanks! I'm not set up to build the project myself, so I'll leave the PR to you — but here's the exact change so it's zero guesswork:

In VehicleEntity, add two stored properties alongside batteryPercentage:

swiftvar isPluggedIn: Bool
var isCharging: Bool

Add matching parameters to the memberwise init (with defaults so existing callers don't break):

swiftisPluggedIn: Bool = false,
isCharging: Bool = false,

And in init(from bbVehicle:), set them inside the existing EV branch where evStatus is already unwrapped:

swiftif bbVehicle.modelContext != nil, let evStatus = bbVehicle.evStatus {
    batteryPercentage = evStatus.evRange.percentage
    isPluggedIn = evStatus.pluggedIn
    isCharging = evStatus.charging
    ...
} else {
    batteryPercentage = nil
    isPluggedIn = false
    isCharging = false
    ...
}

(I'm guessing at evStatus.pluggedIn / evStatus.charging — worth confirming the actual property names against BBVehicle.)

That covers the core ask. The freshness and value-returning items from above would be great as follow-ups, but isPluggedIn as a Bool alone unblocks the main use case.

Thanks again for your awesome app!

[mrscoopman]

I confirmed the property names from GetVehicleStatusIntent — it already uses evStatus.pluggedIn, evStatus.charging, and evStatus.chargeSpeed, so the VehicleEntity change is exactly right.

One thing that jumped out reading VehicleAppIntents.swift: suggestions #2 (fresh poll) and #3 (return a value) collapse into a single change. RefreshVehicleStatusIntent already builds a fresh VehicleEntity (updatedVehicle) after forcing a real-time poll with cached: false — it just discards it into a dialog string. If the intents return that entity as a value, a shortcut can do "refresh → read isPluggedIn" in one action, with guaranteed-fresh data. That covers both asks at once.

For RefreshVehicleStatusIntent — change the return signature from:

swiftfunc perform() async throws -> some IntentResult & ProvidesDialog {

to:

swiftfunc perform() async throws -> some IntentResult & ReturnsValue<VehicleEntity> & ProvidesDialog {

and the final return from:

swiftreturn .result(dialog: "\(updatedVehicle.displayName) status updated. \(updatedVehicle.rangeText)")

to:

swiftreturn .result(value: updatedVehicle, dialog: "\(updatedVehicle.displayName) status updated. \(updatedVehicle.rangeText)")

That's the whole change for #2 — updatedVehicle is already built right there, and it's already a non-cached poll.

For GetVehicleStatusIntent — same return-signature change, but it currently only builds statusComponents and never constructs an entity. It'd need to build one before returning, the same way RefreshVehicleStatusIntent does:

swiftlet unit = AppSettings.shared.preferredDistanceUnit
let allPresets = try await ClimatePresetEntity.defaultQuery.suggestedEntities()
let statusEntity = VehicleEntity(from: bbVehicle, with: unit, allPresets: allPresets)

let statusText = statusComponents.joined(separator: "\n")
return .result(value: statusEntity, dialog: IntentDialog(stringLiteral: statusText))

With that, the action's output exposes isPluggedIn / isCharging as real booleans in Shortcuts — no string parsing. RefreshVehicleStatusIntent returning a value is probably the highest-value single change since it also guarantees fresh data for scheduled automations.

The ReturnsValue syntax is the standard App Intents pattern but worth a build-check on your Xcode version. Happy to test these whenevers — thanks!

[mrscoopman]

I just tried some of the awesome new stuff you exposed in the latest build in Shortcuts -- they all work and are 🔥🔥🔥

Thanks for adding these so quickly!

[schmidtwmark]

Glad it works! Let me know if there's anything else I can or should add! I'm going to close this issue out, but feel free to open another.