いわゆる知識人、コンサルタントの中に、ＩｏＴをやるならRaspberryPiみたいなことを言っている人が居るが、そういう安易な考えだと爆死する・・・もし、そのレベルの理解力でＩｏＴ案件関わろうとしていたら、絶対逃げろ！という根拠をこれから書いていく。
■センサーからサーバーまでのつなぎ方
IoTの開発手順－従来開発との違い
http://blog.goo.ne.jp/xmldtp/e/5c5a4246be99188526a224c1ea75efdb
の（４）入出力インターフェースの決定（有線、無線？）に当たるところの話。
センサーからサーバーまでをどうつなぐか・・・
クラウドだと、おうちのセンサーからAmazonのデータセンターまで、何百キロも線をつなぐことは、現実的には出来ない。そこで、どこかで無線の処理が入る。
ここで、クラウドにセンサーデータを上げるコンピューターを「ゲートウェイ」とよぼう。
すると、２通りの方法が考えられる（細かく分けると３とおり）
ゲートウェイに直接センサーをつなげてしまい、その値をインターネット経由でクラウドに送る
この考え方は、よさそうだけど、課題が結構多い
【課題】
（１）センサーから直接線でつないでしまうと、ある一定以上の長さで
電気が通らなくなり、センサー値が読めなくなる。
電線には抵抗があるので、長くすると、電線の抵抗が大きすぎ、
電気が流れなくなる。電気が流れないと、センサーは使えない
（２）ゲートウェイをＰＣにしてしまうと、センサーとつなげない。
ＰＣの口はＵＳＢとかだけど、センサーはＵＳＢでつなげるのではなく、
ただの線で、それをＧＰＩＯとかにつなげるしくみになっている。
なので、センサーはＰＣにそのままでは使ない。
そこで、RaspberryPiの登場といいたいところだが。。。
（３）RaspberryPiは、ＧＰＩＯの口をたくさん持っている。たしかに。
でも、ＧＰＩＯは、デジタル入力はＯＫだけど、アナログ入力直接はＸ
なんらかの変換がいる・・・
ということで、変換するくらいならということで、
センサーとゲートウェイの間を無線で結ぶ。無線を送受信するものをＲＦモジュールという。
ＲＦモジュールに直接センサーをつけても構わない
（この場合、親機で子機の状態を取得するように指示する）
が、子機のＲＦモジュールとセンサーの間に処理プロセッサ（ここでは「エンド処理」とした）
を置くと、受け取ったセンサー内容を処理加工して送信できるので、自由度が増す。
これにより、先ほどの課題は、
（１）は、解決した。センサー、エンド処理プロセッサ。ＲＦモジュール間をできるだけ
短くし、ゲートウェイには無線で送ればよい
（２）（３）エンド処理プロセッサをArduinoにすれば、アナログもＧＰＩＯもいける
というふうに、解決する。
■ＵＡＲＴ
そうすると、ここで新たな疑問が出てくる
【課題】
（４）ArduinoとＲＦモジュール、ＲＦモジュールとゲートウェイ間は、
何でつなげばいいのか
（５）ＲＦモジュール間は、どの周波数帯で、どのプロトコルを使えばいいのか
ここで、（５）は、ZigBee,Wifi,BLE,920MHz特小（プロトコルは固有の場合あり）が考えられる。
そして、（４）は、ZigBee,920MHz特小などのＲＦモジュールの場合、ＵＡＲＴ接続が
多い気がする。
ＵＡＲＴとは
・シリアル通信を行うのだが、シリアルの端子ではなく、ＵＳＢ端子で接続できるように
するもの
・実際には、ＡＴコマンドを書き出し、それをＲＦモジュールで送信する。
なので、
方式２－１の場合には、
・GPIOやアナログ入力で繋がっているセンサーの値をArduinoが読み込み、
適切に処理し、ＡＴコマンドをシリアルへ書き込むことにより
・ＵＡＲＴ経由でＲＦモジュールからセンサー値が親機に伝わり、
・親機は、ＲＦモジュールからＵＡＲＴ経由で何か受け取る
ことになり、
方式２－２の場合には、
・親機は、子機のデータを読み込むようにＵＡＲＴ経由でＲＦモジュールに書き出し
・ＲＦモジュールはそれを子機に伝え
・子機のＲＦモジュールは自分に繋がっているセンサーから値を読み込み
・親機に返す
ことになる。
よって、親機をRaspberry Piにすると（子機のエンドをRaspberry Piにできないのは、
（３）で書いた）Raspberry PiとＲＦモジュールをＵＡＲＴ接続することになる。
これはRaspberry Pi2はできる。
しかし、今売られているRaspberry Pi3でこれをしようとすると・・・
Raspberry Pi3 のシリアルコンソールで通信速度が合わない
http://qiita.com/komeda-shinji/items/03546ae1014c6b4edc92
や
Raspberry Pi 3 Model Bでシリアル通信で接続してコンソールにログインする方法
http://www.neko.ne.jp/~freewing/raspberry_pi/raspberry_pi_3_uart_tips/
に書かれているように、単純ではない。で・・・
■Wifi
では、（５）でZigBeeでなく、Wifiを選ぶとどうなるか
Wifiを選ぶと、親機側のＲＦモジュールは、Ｗｉｆｉのアクセスポイントでよい
（子機からＷｉｆｉで通信を送るのだから）
となると、ＰＣがあれば、ＰＣをアクセスポイントにすれば
【AP】Windows7/8/8.1を無線親機にしてWi-Fiを飛ばす！？
http://ahiru8usagi.hatenablog.com/entry/Windows7_8_8.1_Wi-Fi
ＰＣ１台で、ＲＦモジュール～ゲートウェイ～インターネットにいく。
Raspberry Piはいらない。
子機側もArduinoでいい（３）の理由でRaspberryPiはむかない。
つまり、Wifiを選ぶと、RaspberryPiは要らない。
ということで、IoTをやる場合、Raspberry Piは要らなかったり、
むしろ、難しかったりする。
Raspberry Piを使うのは、自作でなにかをする人にとってはいいけど、
IoTのお仕事で使うのに、本当にいいのかはぎもん・・・
なので「IoT、はいRaspberryPiつかって・・・」みたいな、その程度の
考えで取り組むと、爆死する。
■センサーからサーバーまでのつなぎ方
IoTの開発手順－従来開発との違い
http://blog.goo.ne.jp/xmldtp/e/5c5a4246be99188526a224c1ea75efdb
の（４）入出力インターフェースの決定（有線、無線？）に当たるところの話。
センサーからサーバーまでをどうつなぐか・・・
クラウドだと、おうちのセンサーからAmazonのデータセンターまで、何百キロも線をつなぐことは、現実的には出来ない。そこで、どこかで無線の処理が入る。
ここで、クラウドにセンサーデータを上げるコンピューターを「ゲートウェイ」とよぼう。
すると、２通りの方法が考えられる（細かく分けると３とおり）
ゲートウェイに直接センサーをつなげてしまい、その値をインターネット経由でクラウドに送る
この考え方は、よさそうだけど、課題が結構多い
【課題】
（１）センサーから直接線でつないでしまうと、ある一定以上の長さで
電気が通らなくなり、センサー値が読めなくなる。
電線には抵抗があるので、長くすると、電線の抵抗が大きすぎ、
電気が流れなくなる。電気が流れないと、センサーは使えない
（２）ゲートウェイをＰＣにしてしまうと、センサーとつなげない。
ＰＣの口はＵＳＢとかだけど、センサーはＵＳＢでつなげるのではなく、
ただの線で、それをＧＰＩＯとかにつなげるしくみになっている。
なので、センサーはＰＣにそのままでは使ない。
そこで、RaspberryPiの登場といいたいところだが。。。
（３）RaspberryPiは、ＧＰＩＯの口をたくさん持っている。たしかに。
でも、ＧＰＩＯは、デジタル入力はＯＫだけど、アナログ入力直接はＸ
なんらかの変換がいる・・・
ということで、変換するくらいならということで、
センサーとゲートウェイの間を無線で結ぶ。無線を送受信するものをＲＦモジュールという。
ＲＦモジュールに直接センサーをつけても構わない
（この場合、親機で子機の状態を取得するように指示する）
が、子機のＲＦモジュールとセンサーの間に処理プロセッサ（ここでは「エンド処理」とした）
を置くと、受け取ったセンサー内容を処理加工して送信できるので、自由度が増す。
これにより、先ほどの課題は、
（１）は、解決した。センサー、エンド処理プロセッサ。ＲＦモジュール間をできるだけ
短くし、ゲートウェイには無線で送ればよい
（２）（３）エンド処理プロセッサをArduinoにすれば、アナログもＧＰＩＯもいける
というふうに、解決する。
■ＵＡＲＴ
そうすると、ここで新たな疑問が出てくる
【課題】
（４）ArduinoとＲＦモジュール、ＲＦモジュールとゲートウェイ間は、
何でつなげばいいのか
（５）ＲＦモジュール間は、どの周波数帯で、どのプロトコルを使えばいいのか
ここで、（５）は、ZigBee,Wifi,BLE,920MHz特小（プロトコルは固有の場合あり）が考えられる。
そして、（４）は、ZigBee,920MHz特小などのＲＦモジュールの場合、ＵＡＲＴ接続が
多い気がする。
ＵＡＲＴとは
・シリアル通信を行うのだが、シリアルの端子ではなく、ＵＳＢ端子で接続できるように
するもの
・実際には、ＡＴコマンドを書き出し、それをＲＦモジュールで送信する。
なので、
方式２－１の場合には、
・GPIOやアナログ入力で繋がっているセンサーの値をArduinoが読み込み、
適切に処理し、ＡＴコマンドをシリアルへ書き込むことにより
・ＵＡＲＴ経由でＲＦモジュールからセンサー値が親機に伝わり、
・親機は、ＲＦモジュールからＵＡＲＴ経由で何か受け取る
ことになり、
方式２－２の場合には、
・親機は、子機のデータを読み込むようにＵＡＲＴ経由でＲＦモジュールに書き出し
・ＲＦモジュールはそれを子機に伝え
・子機のＲＦモジュールは自分に繋がっているセンサーから値を読み込み
・親機に返す
ことになる。
よって、親機をRaspberry Piにすると（子機のエンドをRaspberry Piにできないのは、
（３）で書いた）Raspberry PiとＲＦモジュールをＵＡＲＴ接続することになる。
これはRaspberry Pi2はできる。
しかし、今売られているRaspberry Pi3でこれをしようとすると・・・
Raspberry Pi3 のシリアルコンソールで通信速度が合わない
http://qiita.com/komeda-shinji/items/03546ae1014c6b4edc92
や
Raspberry Pi 3 Model Bでシリアル通信で接続してコンソールにログインする方法
http://www.neko.ne.jp/~freewing/raspberry_pi/raspberry_pi_3_uart_tips/
に書かれているように、単純ではない。で・・・
■Wifi
では、（５）でZigBeeでなく、Wifiを選ぶとどうなるか
Wifiを選ぶと、親機側のＲＦモジュールは、Ｗｉｆｉのアクセスポイントでよい
（子機からＷｉｆｉで通信を送るのだから）
となると、ＰＣがあれば、ＰＣをアクセスポイントにすれば
【AP】Windows7/8/8.1を無線親機にしてWi-Fiを飛ばす！？
http://ahiru8usagi.hatenablog.com/entry/Windows7_8_8.1_Wi-Fi
ＰＣ１台で、ＲＦモジュール～ゲートウェイ～インターネットにいく。
Raspberry Piはいらない。
子機側もArduinoでいい（３）の理由でRaspberryPiはむかない。
つまり、Wifiを選ぶと、RaspberryPiは要らない。
ということで、IoTをやる場合、Raspberry Piは要らなかったり、
むしろ、難しかったりする。
Raspberry Piを使うのは、自作でなにかをする人にとってはいいけど、
IoTのお仕事で使うのに、本当にいいのかはぎもん・・・
なので「IoT、はいRaspberryPiつかって・・・」みたいな、その程度の
考えで取り組むと、爆死する。
アクセス
トータル
ランキング
