「Lite」で普及の兆しを見せる「ECHONET」、波乱万丈の20年史と今後の課題：IoT観測所（18）（3/4 ページ）

実態に即していなかった仕様

　また、全般的にプロトコルも、今から見ると重厚な構成だった（Photo04）。特にIoT向けの場合、消費電力を抑えるためにパケットサイズをどこまで抑えるかも課題になっているのだが、この当時想定されていた対応機器は、基本外部電源が利用できる事を考えていたのか、あまりパケットサイズを削減する事は考えていなかったように思われる。

Photo04:ECHONET SPECIFICATION Version 3.21の"第2部 ECHONET通信ミドルウェア仕様"の図4.1-1より抜粋。昔の通信プロトコルはこんな感じが一般的であったが...ちなみにこの形式IIが、ECHONET Liteでは形式Iになった

　また、当時は考えうる全ての仕様を取り込もうと考えたのだろう。オブジェクトもスゴいことになっている。例えばAPPENDIXで定義されている機器オブジェクト詳細規定を見てみると、センサー関連オブジェクトだけで44種類が定義されており、このうち43種類には詳細規定まで定義されている（なぜか昼光センサーのみ、詳細規定がない）。

　同様に空調関連機器クラスは8種類、住宅・設備関連機器が16種類、調理・家電関連機器クラスは6種類と重厚な割に、健康関連機器クラスは体重計のみ（なぜか活動量計はセンサークラスに含まれている一方、体脂肪計や血圧計などは含まれていない）とか、調理・家電関連機器に掃除機がない（つまりルンバの様な自動掃除ロボットを扱う方法がない）とか、実装に手間がかかりそうな一方で、ヌケも多いのが実情である。

　プロトコルが重いとかいう以前に、そもそもこれでアプリケーションを作ろうとすると大変というのが実情であった。仕様を定めるのに時間がかかりすぎ、その間に仕様が陳腐化してしまったというべきであろうか。

現実に即して生まれ変わった「ECHONET Lite」

　こうした反省を踏まえて、ECHONETをベースにもう少し現実に即したものを、ということで2011年から仕様策定が始まったのが「ECHONET Lite」である。

　このECHONET Liteの構成は「ECHONET Lite 開発の目的」（リンク先PDF）の中で「MACアドレスなどの固定アドレスを持ったメディアやIP対応機器の普及により冗長となったECHONETアドレスと、実装実績が少ない機能である通信定義オブジェクト、プロファイルオブジェクト、サービスオブジェクト、ECHONETルータ、NetIDサーバなどを削除するとともに、電文構成をシンプルにした、ECHONET Lite規格を開発することとしました。」と記されている。

　要するに冗長性を排除して軽量化を図ったというワケだ。実際、ネットワーク構成（Photo05）を見ると、一応IPがベースという事になっているが、事実上何も規定していないも同然で、ここはNetwork層にお任せである。

Photo05:ECHONET Lite SPECIFICATION Version 1.12の"第１部 ECHONET Liteの概要"の図2-3より抜粋。Photo03と比較するとなかなか面白い

　これはブロック図（Photo06）からも明らかで、OSIのモデルで言うところの第4層以下はノータッチとなっている。

Photo06:ECHONET Lite SPECIFICATION Version 1.12の"第１部 ECHONET Liteの概要"の図3-1より抜粋。OSIレイヤーの説明がある意味すがすがしいというか……

　これにあわせて、ECHONETの時代には「Full_Device」（ECHONET用のI/Fを内蔵し、単独でECHONETに接続できる機器）、「Flex_Device」（ECHONET通信処理部以上の機能を内包し、ECHONETアダプターと組み合わせてECHONETに接続できる機器）、「Ready_Deivce」（ECHONET通信処理部との共通APIにのみ準拠した機能を持ち、通信処理部以下の機能を持つECHONETアダプターと組み合わせてECHONETに接続できる機器）の3種類が定義されていたのが変更された。

　ECHONET LiteではFlex_Deviceに相当するものがFull_Deviceとされ、Flex_Deviceの定義がなくなる（Ready_Deviceはそのまま）といった形に変更されている。そんなわけで、根っこの部分では同じECHONETとECHONET Liteであるが、実際に運用する際の互換性はない（ECHONET対応機器やネットワークがほとんど存在しない状態だったから、問題にはならないと思うが）。