u/RussellQwerty

Disclosure up front: I make BetterKey, the iOS app this bridges from.

I wanted to bring the passive automations from BetterKey into my smart home. I found that Home Arrival was something I would actually use and allowed the app to have a deeper integration for connected car/home automation enthusiasts. Sharing in case it's useful to others who would also be interested in BetterKey.

What it does:

• One motion sensor per vehicle, named {Vehicle} Parked at Home.
• Each time BetterKey confirms the car parked inside a home area you drew on the map, the sensor flips to "motion detected" for about 30 seconds and then back to "no motion." That's enough for Apple Home to run an automation like "when Forester Parked at Home detects motion after sunset, turn on the driveway lights."
• Dynamic platform, so vehicles are added and removed automatically as they show up in BetterKey.
• Polls the BetterKey API on a configurable interval (default 60s, range 30 to 600s). Confirmed arrivals persist server side for 24h, so a Homebridge restart during that window will still catch the event.
• Verbose logging option that records event ids and dispatch outcomes. The API key is never logged.

A few things worth calling out up front:

• Requires an active BetterKey subscription and the iOS BetterKey app with Home Arrival turned on (feature overview at https://betterkey.xyz/home-arrival). If you are not already a BetterKey user, this plugin will not be useful on its own.
• Arrival only. It never reports "away" or "not parked," and if iOS suspends BetterKey in the background a specific park can be missed. A missed trigger is inconvenient rather than unsafe, since nothing downstream is treating the sensor as authoritative presence.
• The comparison between "where the car is" and "the home area you drew" happens entirely on the iPhone. Only a short-lived arrival event (id, vehicle, timestamp) leaves the device for this plugin to poll. No coordinates, no radius, no vehicle location.

Install from the Homebridge UI by searching for BetterKey, or from the CLI:

npm install -g homebridge-betterkey

Repo, config, and troubleshooting: https://github.com/CMLabsLLC/homebridge-betterkey

Happy to answer questions or take device reports in the thread.

I could have sworn that the window status used to show in the MySubaru Vehicle Diagnostics Page, but when I looked today it was gone. Anyone else experiencing this?

What I built

BetterKey is a small iOS/watchOS system that sits on top of OEM vehicle APIs and tries to make remote lock/unlock predictable. The user-facing surfaces are the iPhone app, Apple Watch, Siri Shortcuts, and a few Lock Screen flows. Vehicle commands go through a protocol-based abstraction, with Smartcar as the primary provider.

It is not trying to replace a physical key. It is a lower-friction path for common cases: walking up to the car, or using the watch when the phone is not convenient.

Why I built it

I kept running into small unlock friction: phone in pocket, hands full, OEM app slow to launch, Bluetooth key behavior inconsistent, or the car's own app needing several taps before issuing a command. The real problem was that the system never felt deterministic.

For a lock/unlock app, trust is the product. If the UI says "locked" based on optimism instead of confirmed state, it only has to be wrong once before the user stops believing it.

Architecture / Stack

The iOS and watchOS apps are SwiftUI on Swift 6, using async/await, actors, and u/MainActor on the UI layer. Most client code is shared through Swift packages with platform adapters for iOS, watchOS, and UI tests.

The backend is a Go API on Fly.io. It handles auth, Smartcar/OEM token management, command orchestration, token refresh jobs, and push fanout. Firestore stores state and command metadata; FCM handles delivery.

Deep problem: OEM APIs are not real-time systems

Lock/unlock APIs look simple, but they behave like eventually consistent remote calls into a car that may be asleep, offline, busy, or behind a flaky backend.

A command can be accepted before the car has moved a latch. Status can be stale, providers return 502s, and immediate polling can make success look like failure. Rate limits mean "just poll harder" is not a real solution.

I initially treated command success too much like state success. That broke down quickly, especially around Lock on Depart, where an optimistic "locked" state is worse than no automation at all. Smartcar surfaces this directly: a successful response can carry `X-Command-Confirmation: unconfirmed`, meaning the request was accepted but not confirmed by the vehicle. BetterKey maps commands into `VehicleCommandResult.confirmed` or `.unconfirmed`, and the UI separates "sent but unconfirmed" from "locked."

Deep problem: Park, depart, and Lock on Depart

The naive version is simple: detect departure and issue a lock command. The real version has to account for location accuracy, background limits, duplicate events, stale state, and cases where the user intentionally leaves the car unlocked.

Lock on Depart sits on top of Park Location, which confirms that the car is parked. The coordinator is a phase-driven actor that watches geofence and motion signals, applies cooldown windows, and exits if vehicle state is too stale.

The tradeoff was responsiveness versus unnecessary commands. I biased toward fewer commands and clearer state transitions.

Lock Screen surfaces

The Lock Screen piece is Live Activities and App Intents, not a general purpose lock/unlock widget. That constraint shaped the design: Lock on Depart can expose monitoring/locking state, while Prompt to Unlock can present one narrow action when motion looks like returning to the vehicle. App Intents keep that action on the same command pipeline as the in-app button.

App Review and demo mode

Demo mode mattered more than I expected. App Review, testers, and every developer cannot be expected to have a compatible real vehicle connected through Smartcar.

At the network edge, an `InterceptorNetworkClient` swaps in a noop implementation. At the service layer, a `SimulatorVehicleService` actor provides seeded vehicles, deterministic transitions, and toggleable states like "needs reauth" or "window open."

The tradeoff is that demo mode has to stay honest enough for review and testing. If it drifts too far from production behavior, it stops being useful.

What I learned

- HTTP success can still be UX failure if the state is not confirmed.
- Background constraints shape product design more than UI decisions.
- Lock state UX needs careful language. Pending, confirmed, and unconfirmed are different things.
- Hardware-adjacent apps need a credible demo/review path from day one.
- Automations on physical hardware need a foundation feature you trust.

Happy to answer questions about the architecture.

Hey everyone,

I built an app called BetterKey for compatible connected vehicles (via Smartcar). It lets you lock, unlock, and run a few lightweight automations from your iPhone and Apple Watch.

I originally built it because I kept having that annoying “did I remember to lock the car?” moment after walking inside, going to bed, or parking somewhere unfamiliar.

A few things it does right now:

• Lock and unlock from iPhone or Apple Watch
• Park Location: saves where you parked so you can find your car later
• Lock on Depart: can automatically lock the car when you walk away
• Prompt to Unlock: one-tap unlock on your lock screen and watch when you approach the car
• Open Window Alert: notifies you if you parked with a window left open and its going to rain/snow.
• Shortcuts support: build your own automations and flows if you want

The goal is not to replace the key, just to remove some of the small, repetitive “car admin” moments.

It’s live on the App Store and I’m actively iterating based on feedback.

I’d really appreciate thoughts on:

• Would features like Lock on Depart or Prompt to Unlock actually be useful in your day-to-day?
• What would make you trust an app like this with your vehicle?
• Any car-related friction points you wish your current app handled better?

Website: https://betterkey.xyz
App Store: https://apps.apple.com/us/app/betterkey/id6745559471

Thanks for checking it out. Happy to answer questions or go deeper on how it works under the hood.