Telemetry vs polling: decision table
- Need realtime / continuous signals? Use Telemetry.
- Need occasional values (few times/day)? Use minimal endpoints + caching.
- Need commands (charge limit, precondition)? Schedule, then wake only at execution time if required.
Design goal: the UI should still be useful when the vehicle is asleep (show cached + “last updated”).
Wake strategy (owner-friendly)
- Never wake “just to display fresh data”.
- Wake only when you’re about to execute a user-requested or scheduled command.
- Use exponential backoff and stop after a few tries (avoid loops).
Telemetry windows (keep cost under control)
- Stream during charging sessions.
- Stream during driving sessions if you need it (otherwise don’t).
- Stop streaming when the event ends.
Practical: many apps only need a handful of signals and only during “active” periods.
Alerting patterns that don’t annoy users
- Alert on deltas (change), not on every raw sample.
- Add hysteresis and minimum durations.
- Rate-limit alerts and include a “mute for 24h” switch.
Common mistakes that cause high cost
- Polling large vehicle/device data endpoints on a timer.
- Waking vehicles repeatedly because the UI “must be live”.
- Storing every raw sample forever (store deltas / aggregate instead).
- Streaming everything 24/7 instead of windowed streaming.