# 台北車站場域定位需求
> 如需撰寫權限，請 email anton.tw (at) gmail.com 或 以評論方式 留下 email
> Member:
> @yck // anton yu (guni)
> @Jamie-Tong // jamie tong (guni)
> @Toastest // henry chen (Henry Jr.) (guni)

# 資料流程圖
{%hackmd j-qGWsGHRPyJmtvLGt77tg %}

## 2. Device ID 預留表格 (待跟交大同步)
> * 裝置 ID 目前是 2 個 byte ，受限於 Mesh 的架構， APP 取得的 Device ID 也必須是 2 個 bytes 且不能和 Receiver 重複。
> * Device ID 的 Table 應有三個部份：(1 for Receiver / 2 for Beacon Device / 3 for Beacon APP)

| 10 進位 | 16 進位 | 個數 | 定義說明 |
| --- | --- | --- | --- |
| 1 ~ 999 | 0x0001 ~ 0x03e7 | 999 | Receiver |
| 4096 ~ 4499 | 0x1000 ~ 0x1193 | 404 | Provisioner |
| 4500 ~ 4999 | 0x1194 ~ 0x1387 | 500 | Beacon 裝置 |
| 5000 ~ 15000 | 0x1388 ~ 0x3a98 | 10001 | Mobile Phone |

{%hackmd sM0kD2TORtW6IgDzGrevGQ %}

# Cloud 需求說明
:mega: IoTTalk 應該要有一個 device 專用的 database ，可以提供我方更新上傳
> 這邊主要是怕同步花時間，不是功能上的需要。 (anton)

:mega: IoTTalk 需幫 APP 做註冊以識別 ID (**10,000 個 ID**)，這邊應該提供 APP 註冊的 API
> 這邊是功能上的需要，因為 APP 提供 uuid 需要拿到上面 Device ID 的對照
> 不需提供個人資料的註冊方式，手機則需要識別是不是同一隻手機的安裝，所以會由 APP 提供手機的 UID ， IoTTalk 註冊到 Device ID 的 Table 上，然後發給 APP Device ID 來使用。

:mega: 需配合北車的室內地圖按**分區做畫面分割**
> 這裡的分區是依 Mesh Network 做切分，但是整條商店街一定很多人，所以一定會需要切分成小區塊來處理以避免 mesh network 塞車的問題 (這也是 B6 的設計)

:mega: 使用情境 (需考量控制中心與一般使用者兩種使用需求)

## 使用者版本
:mega: 需能負荷北車人潮 **750 裝置同時上線**
:mega: 使用者從A區進入B區時，需能 **自動切換區域**
:mega: 能設定目的地，配合地圖自動導航 **路徑顯示**

## 控制中心版本
:mega: 使用者 filter / search (不然 10,000 個 ID 同時顯示，列表會有多長？)
:mega: 燈號指引 -> 能在 IoTTalk 上設定，然後配合手機操作，顯示在 LED 方向指引
:::info
* 活動 -> 活動場地方向指引
* 災難應變 -> 逃生方向指引
:::

## 路徑導引流程圖

## 手機方面 (Both Android / iOS)
:mega: IoTTalk 應具備能 **顯示 Mobile Web** 的能力 (Web 顯示在 Mobile 上面不會亂)
:mega: API List 應具備 { 註冊, 取得地圖Url, 通知 }
:mega: Notification 由 IOTTalk 透過第三方平台(如:Firebase) **推播訊息** 給APP
:::warning
* Firebase相關連結如下:
* (Android) https://fightwennote.blogspot.com/2019/03/android-firebase-fcm.html
* (IOS) https://medium.com/@mikru168/ios-google-notification-firebase-cloud-message-c2849117be08
* (PHP) https://ithelp.ithome.com.tw/articles/10198620
:::