Teslife のダッシュボードは、バッテリー残量や位置、充電状態を秒単位で更新します。この記事では、そのデータが車両からアプリに届くまでの道のりと、途切れたときの備えを紹介します。
「ポーリング」ではなく「ストリーミング」
従来の方法は、アプリやサーバーが一定間隔で車両に「今の状態は?」と尋ねるポーリングでした。この方式では、間隔より細かい変化は見えず、尋ねるたびに車両へ負荷もかかります。
Teslife は主に、車両側から変化のたびにイベントが届くストリーミングを使っています。Tesla が提供する Fleet Telemetry を利用しており、最短 1 秒間隔での更新が可能です。
車両からアプリまでの 4 段階
Tesla 車両
└─(暗号化 WebSocket)──► ストリーミングサーバー
└─(メッセージキュー)────► サーバー処理
└──────────► データベース
└──────► アプリ(リアルタイムリスナー)
- 暗号化 WebSocket: 車両と Teslife のサーバーの間は、相互 TLS 認証で暗号化されます。Virtual Key を登録した車両だけが接続できます。
- メッセージキュー: メッセージが一時的に滞留しても欠損しないよう、キューを挟んでいます。
- データベース: 受け取ったデータはサーバー側で処理して保存します。
- リアルタイムリスナー: アプリを開いている間はデータベースの変更を購読していて、データが着いた瞬間に画面が更新されます。
途切れたときの備え
通信は、どこかの段階で止まることがあります。そこで Teslife は、ストリーミングが 15 分以上沈黙した車両を検知すると、5 分間隔のスケジュール処理が代わりにデータを取得するようにしています。
スリープ中の車両は起こさない
Tesla は、使われていない間はスリープして電力を節約します。データを取るために無理に起こすと、バッテリーを消耗させかねません。
Teslife は、車両がスリープ中だと分かっている間はウェイクアップしません。車両が自然に起きたときに、改めてデータを受け取ります。リモートコマンドのようにユーザーが操作を求めた場合に限って、車両を起こして実行します。
更新間隔は、Pro・Fleet プランではデータの種類ごとに 1〜60 秒の範囲で調整できます。走行中は短く、駐車中は長くすると、必要な精度を保ちながら通信量を抑えられます。
もっと詳しく
より細かい仕組みや設定は、ドキュメントのリアルタイムモニタリングとシステム概要にまとめています。接続やデータの扱いについてはセキュリティもご覧ください。