はじめに
私はBluetooth(BLE)を主に触っており
・ビーコンの開発（ソフト側、ファーム作成）
・中継器（ラズパイ等を使った中継処理）
・集計ソフト（サーバー側の集計処理）
という事をやってます。（ハードについてはさっぱりです）
BLEの失敗した案件や実証実験も見てきてるので、技術選定の参考になるような情報を残しておこうと思います。
全体図
IoTには様々な工程がありますが、データ取集処理以降を大きく分けると、以下の４つの項目に分ける事ができます。
IoT CSSA(Internet of Things - Collect, Send, Save, Analysis)
1. データを取集する（Collect）
- 有線、無線、距離（１ｍ～数㎞）、電力源（ボタン電池、ソーラー発電、コンセント）、一時保存（MySQLオンメモリ）
発信側と受信側両方のことです。スマホ、タブレット、スマートウォッチ、ラスパイ、専用機器いろいろあると思います。この記事で書くのはデータ発信側の機器についてです。
ここら辺はC,Python,node.js,Java,Swiftを使って開発してます。
また、この分野のみ必要なスペックの製品がなかったのでハード（ビーコン）まで手を出してます。（ファームまでいじってるのはその為）
2. データをサーバーへ送信する（Send）
- 有線LAN、無線LAN、LTE（公開、閉鎖網）、LPWA、物理（SDカード等）
ネット回線でデータをPOSTするのもありですが、閉鎖網サービスなんかもあります。（さくらインターネット、SORACOM等）純粋に製品のロジックに工数をかけたい場合はいいかもしれません。
また通信回線が確保しづらい環境の場合、SDカードに保存しておいて手動で回収なんて事もあります。
httpsでPOSTするだけの事も多いですが、個人的にはさくらインターネット信者なので（唐突な告白!）プライベートで一度使ってみたいですね。
3. データを保存する（Save）
- API、リレーショナルDB
これもまた専用回線サービスに付随して、API化されたデータ保存サービスを各社が提供しています。
送信データをできるだけ最終利用時に適した形で保存したかったので集計ロジックを含めて自作しています。とは言ってもMVCのMにゴリゴリ書いているだけですが。
4. データを解析する（Analysis）
- ビックデーター、機械学習、インターフェイス
解析部分は記事や本も出てるし省きますが、インターフェイスについては必ずデザイナーさん達に協力してもらいましょう。1ページに分析結果が要約されて、10秒で状況が把握できるような物が理想です。最終クライアントはここしか見ません、詳細ページなんて深い階層は見ません、TOPページがすべてです。開発に時間を取られて、間に合わせで技術屋が使ったようなインターフェイスで出すような事は避けましょう。
技術選定の考え方
作りたいサービスを基準に通信規格を選定する
技術屋が陥りやすい点なんですが技術から物事を考えだしてしまいます。
「Bluetooth5面白そう！LPWAすげー！これで何か作りましょうよ！」
IoTでは現実の制約が絡みます、使用する技術を先に決めるという事はすごく危険です。お金的な意味で。
「完成像」を明確にした上で必要な技術（規格）を逆算して決めましょう。
通信規格→サービス（間違い）
例えば「通信規格→サービス」で考えてしまうと、通信規格の間違った
選定に気付いた時点でかなりの工数を使ってしまいます。
- よし「Bluetooth」を使った製品を何か作ろう
- Amazonなんかで売ってる数千円のビーコン（class2）を買う
- スマホアプリでサービス部分を実装してみる
- 通信距離が短すぎて想定したような動きにならない
- LPWA対応製品なら距離が出せるかも・・・あっ、スマホ側が通信規格に対応してない（涙）。
- 失敗
上記の内容は「Bluetooth」ありきで開発を進めてしまった為
最後の最後でどうしようもなくなったパターンです。
（因みにAmazonとかで買える安いビーコンはclass2の製品が多いので、多くの企業案件や行政の実証事件が上記のような状況でプロジェクト凍結だったり、失敗した話を聞いています。
ただし、通信距離が短いことを利用した「通信が切れたことをトリガーにする」製品等も出ており（落とし物を探すやつです、スマホとの通信が切れた時の位置をGPSで保存しておきスマホに通知する）一概にclass2製品が悪いわけではありません。）
サービス→通信規格（正解）
- よし「〇〇」みたいなサービスを作ろう
- これを実現するにはどんな通信規格があっているのだろう？
- 実距離で家1軒分くらいの距離をカバーできる
- コイン電池で動くような省電力
- 身に着けられる小サイズ
- etc
- この条件だと「Bluetooth」あたりがいいかもしれない
- 選定の結果→「Bluetooth5」が魅力的だが対応製品が少ないので「BLE・Bluetooth4（class1相当）」で進めていこう
上記の場合条件の中に「実距離で家1軒分くらいの距離をカバーできる」という距離の条件から「Bluetooth」が条件にはいりましたが、これが「工場で」とかになった場合「LPWA」になったり、さらに巨大な範囲だと「LTE ＋GPS」で直接サーバーにデータを送ったりする事になります。
実際には他にも様々な条件が重なってきます、必要な要件をリストアップし本当に選択した規格で実装できるか検証しましょう。
- NFC(近距離無線通信)
- Bluetooth（サブGHz帯）
- LPWA（920MHz帯）
- LTE ＋GPS ＊１
＊１．位置情報を補足として使う事が多いので、合わせて記述している。ただし、Wi-Fi環境を使った位置補正がないGPSの精度は結構悪い
現在上記の規格を複数扱えるチップも出ているようですが、その分お値段も高くなっており大量の最終的なコストに跳ね返ってしまいます。初めから要件を明確にする事によってコスト削減にも繋がります。
距離
一番聞かれることの多い距離について。
カタログ燃費と実燃費
車の燃費は気にする方ですか？CMでバンバン「リッター３５㎞！」と言っていて「ほーすごいなぁ、よし燃費もいいしこの車にするか」となっても実際はリッター25㎞ちょっとだったりするわけです。これは計測の仕方が問題であって、すごくいい条件で車を走らせて宣伝用の燃費を出している訳です。
IT業界はどうなのか
例えば、日本のノートパソコンのバッテリー性能で言うと2014年までJEITAバッテリ動作時間測定法（Ver.1）という2001年にできた測定方法で測定しておりました。ほとんど何も作業していないような状態でのバッテリー持ちをカタログ表示していたので、すんごい差がありました。Wi-FiでネットしながらYouTubeの動画を見続けるなんて想定もしていなかった訳です。
Bluetooth
私が仕事でよく扱っているBluetoothです。普通に分かりにくいです。
| 項目 | 数値 |
|---|---|
| 送信電力 | +5 dBm |
| レシーバの感度 | -96 dBm |
例えば上記のような記述から何メートル通信可能な製品なのか推測できるでしょうか。
私は今だにパッと分かりません。
しかし、何故こんなわかりにくい表記をしているのでしょうか？
外部環境からの影響を受けやすい
- 水分の影響を受けやすい（木、地面、人等）※地面には水分が多いので、端末を高い所に設置すると通信距離が延びます。
- 人という水分（人混みでは当然距離は落ちますし、スマホを持ってる本人もまた水分の塊です。）
受信する側の性能も関係してくる
例えばスマホにBluetoothのアプリを入れて距離測定をしようとしたとします。class1のビーコンを使ったので長距離通信が可能と思いますが、スマホ側はclass2のチップが載っているで**受信はできるが送信できない（ビーコンを発見できるがコネクションを張れない）**といった状況がおきます。class1のチップをわざわざ乗っけてるSONYのスマホもありますが
〇〇ｍ通信できますと断言しずらい
と言った形で中々〇〇ｍ通信できます！とは書きにくいんですよね。それでも分かりやすく伝えないといけないのでカタログには１０ｍとか１００ｍとか書いているわけです。
最後にBluetooth製品の目安を書いておきます。
- Bluetoothで20〜30mと書いてあったら１０畳の部屋をカバーするくらい。
- Bluetoothで100mと書いてあったら２階建一軒家をカバーするくらい。
- データ通信可能距離はその半分。
- トンネルや体育館の天井などの好条件だと２〜３倍に距離が伸びる。
ちなみにBluetooth5の最新チップ+アメリカだと日本の２倍の出力を出せます。
（日本も電波法改正早くこないかなぁ。）
電池持ち
スマホやタブレット：GPS使用時より低い。充電が間に合わなくなるような事はおきない。
ビーコン系：「class1,CR3032,3秒間隔発信」とかで6〜８ヶ月あたり。大型バッテリーとかだともっと長い。class2とかだともっと長い。
製品
発信側
発信側の機器を選ぶ時は、基本class1相当の出力ができる製品を選びましょう。
class2相当の製品は合うサービスが限定されます。（落し物アラート系）
かならずサンプル機器を買うか、借りるかして検証して下さい。
受信側
スマホ（タブレット）とラズパイを触ったことがありますが
おすすめの選定ポイントは受信アプリの起動時間です。
- スマホ（タブレット）：短時間起動
- ラズパイ：長時間起動
です。作りたい目的に合わせて選びましょう。
スマホ(タブレット) ＝ 低工数は間違い！
やった事ある人なら分かって貰えると思いますが、制限と制約が大きいです。
OS側の不具合も沢山あります。
短時間の通信目的であればありですが、長時間起動するようなアプリは難しいです。
キャッシュ、ゾンビ、OSバージョンアップ、端末固有のバグ。心が擦り切れます。
iOS
MacアドレスがランダムなUUIDに変換され個を特定するのが困難です。
また、自身のMacアドレスに関しては定期変更されるダミーをします。実際に接続する段階まで本当のMacアドレスはわかりません。（これはapple製品だけというより、ここ最近の製品全般に言える事ですが。）
これはマーケティング業界からユーザー情報を守ると言う建前と、自分達を通さず
広告サービスをするなよという本音からこのような仕様になっているようです。
また、バックグラウンドでの動作には厳しい制限がかけられており
バッテリー消費を抑えるためBluetoothのスキャンが数十秒単位まで間引かれます。
Android
ルートをとってしまえば何でもできるAndroidですが、それでもいくつか問題はあります。
MacアドレスはiOSと違い、生データ取得できます。（が、どんどんiOSに近い厳しい仕様に変化していっています。）
バックグラウンドでの動作についても年々制限が厳しくなってきており
バッテリー消費量削減の為、意図的にKILLされてしまうようです。
この判断はメーカーによって違うので開発側としては、要件に端末指定を盛り込むことが必要です。
参考↓
スマートフォンのバッテリー寿命を節約するためにバックグラウンドでアプリを終了させてしまうメーカー14選
まとめ
- 要件ありきで規格を選ぼう
- カタログスペックを信じるな、ちゃんと試そう
- class1相当製品は値段が高いが距離が出る->もっと値段の高い受信機を減らせる
- Bluetoothを使ったサービスでスマホ（タブレット）を安易に選択するな
です。以上、お疲れ様でした。