ECHONET Liteのメーカーコードと製品ブランドが一致しなかった話

自宅の構成と調査のきっかけ

我が家は建売住宅で、シャープ製の太陽光発電設備が設置されている。 自分でHEMSを構築したわけではなく、エネルギー機器をまとめて制御する仕組みも導入していない。

調査を始めた理由は、節電や自動制御が必要だったからではない。 機器がすでに発電量や消費電力を計測しているなら、その情報を自分でも取得してみたいという興味からだった。

そこで、自宅の電力情報をローカルで収集するツールを作り始めた。 その過程で、家庭内LANにあるECHONET Lite機器をまとめて探索したところ、製品ブランドとは異なるメーカーコードを返す機器が見つかった。

ECHONET LiteでLAN内の機器を探す

今回の探索に使ったのが、ECHONET Liteである。 ECHONET Lite対応機器は、共通のオブジェクトとプロパティを使って、家庭内LAN上で情報をやり取りする。

機器を探すときは、UDPポート3610を使い、マルチキャストアドレス224.0.23.0へ問い合わせる。 問い合わせ先は、各ノードが持つ機器情報を管理するノードプロファイル（EOJ 0EF001）である。

最初に取得したプロパティは次の二つだった。

frame = build_get(EOJ(0x0E, 0xF0, 0x01), [0xD6, 0x8A])
transport.sendto(frame.encode(), (ECHONET_MULTICAST_IPV4, ECHONET_PORT))

応答を送信元IPアドレスごとに集計すれば、LAN上のどのノードが、どのECHONET Liteオブジェクトを公開しているか分かる。

製品ブランドと一致しないメーカーコード

自宅で探索すると、一つのIPアドレスから次の応答が返ってきた。

NODE 192.168.1.2  maker=00000B
  - 027901  住宅用太陽光発電
  - 028701  分電盤メータリング
  - 028E01  分散型電源電力量メータ
  - 05FF01  コントローラ

一つのノードが複数のオブジェクトを公開する構成自体は不自然ではない。 気になったのは、メーカーコードとして返された00000Bだった。

ECHONETコンソーシアム公式の「発行済会員ID／メーカコード一覧」（2026年8月6日版）では、00000Bをパナソニック ホールディングス株式会社など4社が共用している。 一方、応答元はシャープブランドの電力検出ユニットJH-ASP01だった。

製品ブランドはシャープだが、ネットワークから取得したコードはパナソニック各社に割り当てられている。 この食い違いを調べることにした。

MACアドレスから立てた誤った仮説

最初に、応答元IPアドレスのMACアドレスをarp -aで確認した。 MACアドレスの先頭部分であるOUIをIEEEの公式レジストリで照合すると、登録先はLIMNO Co., Ltd.だった。

000324     (base 16)        LIMNO Co., Ltd.

LIMNOは、鳥取三洋電機から社名を変更した会社である。 私はこの沿革を見て、電力検出ユニットの通信部分がパナソニック系の設計に由来するのではないかと推測した。

しかし、この推測には資本関係の時系列が抜けていた。 LIMNOの公式沿革によると、同社は2015年にパナソニックグループを離脱している。

OUIから確認できるのは、MACアドレスの登録先である。 それだけでは、現在の資本関係や、ECHONET Liteのメーカーコードが00000Bになった理由までは説明できない。

したがって、「LIMNOが現在もパナソニック系だから00000Bを返す」という仮説は成り立たなかった。

オブジェクトごとに型番を確認する

次に、メーカーコードだけを見ていた調査方法を改めた。 全オブジェクトへ個別に問い合わせ、0x8Cの型番と0x8Dの製造番号を取得した。

EPCS = [0x8A, 0x8C, 0x8D]

for eoj_hex in ["0EF001", "027901", "028701", "028E01", "05FF01"]:
    frame = build_get(EOJ.parse(eoj_hex), EPCS)
    ...

取得結果は、二つの型番に分かれた。

型番と製造番号の組み合わせから、オブジェクトは次の二群に分かれる。 製造番号は末尾3桁を伏せているが、同じ表記の行は実機でも同一の番号を返している。

• JH-ASP01：ノードプロファイル、分電盤メータリング、コントローラ
• JH-55SP4：住宅用太陽光発電、分散型電源電力量メータ

同じIPアドレスから応答していても、各オブジェクトが示す製品は一台とは限らない。 今回の結果では、電力検出ユニットとパワーコンディショナの情報が同じノードに並んでいた。

電力検出ユニットが別の機器を代理公開している

型番をシャープの公式製品情報と照合すると、JH-ASP01は電力検出ユニット、JH-55SP4はパワーコンディショナだった。

JH-55SP4の製品情報には、出力制御に電力検出ユニットJH-ASP01が必要だと記載されている。 二つの機器は、組み合わせて使う構成である。

LAN上で応答したIPアドレスは一つであり、そのノードが二製品分のオブジェクトを公開していた。 この観測結果から、JH-ASP01がJH-55SP4の情報を受け取り、住宅用太陽光発電と分散型電源電力量メータのオブジェクトを代理公開していると考えられる。

ただし、これはECHONET Liteの応答、型番、製造番号、公式製品情報を組み合わせた推定である。 機器間の通信仕様や実装を、シャープの技術資料で直接確認できたわけではない。

00000Bになった理由は確定していない

型番を調べたことで、同じノードの背後に二つの製品があることは分かった。 しかし、すべてのオブジェクトが00000Bを返す理由は確定していない。

通信ソフトウェアやモジュールがパナソニック系の実装に由来する可能性はある。 パナソニックグループ在籍時の設計から、メーカーコードの設定値が引き継がれた可能性もある。

どちらも、現時点では観測結果から考えられる仮説にすぎない。 理由を確定するには、シャープまたは当該機器の設計元への確認が必要になる。

メーカーコードから分かる範囲

今回の結果だけで「ECHONET Liteのメーカーコードは信用できない」と結論づけることはできない。 00000Bは、公式一覧に掲載されている会員ID／メーカーコードだからである。

一方で、0x8Aを製品ブランドと一対一で対応する情報として扱うこともできない。 公式一覧でも、一つのコードを複数の法人が共用している。 今回の機器では、シャープブランドの製品がパナソニック各社の共用コードを返した。

今回のように一つのノードが複数の製品を扱う構成では、メーカーコードだけで製品を識別できない。 オブジェクトごとの型番0x8Cと製造番号0x8Dも併せて確認する。 少なくとも今回の構成では、この二つを取得したことで、電力検出ユニットとパワーコンディショナを区別できた。

共通規格にも実装差は残る

今回の食い違いは、一台の機器だけに生じた特殊な問題に見える。 しかし、ECHONET Lite対応機器の実装差や解釈差は、事業者や研究者からも指摘されている。

ECHONETコンソーシアムは、重点機器の相互接続性を高めるため、通常の規格に加えてAIF仕様を定めている。 AIF仕様では、搭載する機器オブジェクトや、サポートするプロパティの組み合わせまで具体化する。 基本規格だけでは実装の選択肢が残るため、対象機器を絞った追加仕様で振る舞いをそろえる構成になっている。

実際、エネルギー事業者への業界インタビューでは、メーカーごとの対応状況にばらつきがあり、仕様の解釈差をゲートウェイ側で吸収していると説明されている。 小さな仕様変更でも相互接続できなくなる場合があるという指摘もある。

機器メーカーの案内にも同じ前提が現れている。 ダイキンはECHONET Lite対応機器同士の接続について、規格対応だけで無条件に接続や動作を保証するものではないと明記している。

規格対応と実際の使われ方の隔たりを問題視する声もある。 Natureの創業者は2019年の投稿で、家電メーカーがECHONET Liteを実装しながら、自社製品での囲い込みを進めていたと批判している。 競合製品を提供する事業者の立場からの評価ではあるが、共通規格がそのままメーカー横断の利用につながらないという不満は共通している。

別の層にも実装差がある。 ECHONET Liteのマルチキャスト通信を扱った研究報告では、規格の範囲外にあるIGMPの解釈差によって、端末やルーターの動作が異なると報告されている。 これはメーカーコードとは別の問題だが、規格が定めない範囲で実装差が生じる例である。

したがって、ECHONET Liteに「方言がある」という感覚は的外れではない。 ただし、その原因をすべて「仕様が曖昧だから」とまとめることもできない。 任意プロパティ、規格の対象外にある通信層、仕様の版、メーカー独自拡張は、それぞれ異なる理由で差を生む。

規格に残るベンダーの事情

ECHONET Liteは共通規格だが、その仕様は企業が参加するコンソーシアムで策定される。 エコーネットコンソーシアムの公式FAQによると、機器オブジェクトの追加や変更は会員から提案を募り、ワーキンググループで検討する。

現在の幹事会員は、シャープ、東京電力ホールディングス、東芝、パナソニック ホールディングス、三菱電機の5社である。 エコーネットコンソーシアムの公開資料では、幹事会員が規格策定とコンソーシアム運営を担うと説明されている。

ただし、公開情報から確認できるのは、このような規格策定の体制までである。 個別のコードの扱いがどのような議論を経て決まったかは確認できていない。

それでも、共通規格が参加企業の合意で作られる以上、各社がすでに持つ製品、実装、運用上の事情は規格策定の制約になる。 出荷済みの製品は容易に変更できないため、多くの製品と実装実績を持つベンダーほど、既存仕様との互換性を無視しにくい。

今回のメーカーコードは、その違和感が表に出た例だった。 「メーカーコード」という名前からは製品メーカーを識別できるように見えるが、実際には一つのコードを複数法人が共用し、別ブランドの製品から返る場合もある。 コード表、型番、製品構成まで調べなければ意味を解釈できないのであれば、その負担は機器をつなぐ側へ移っている。

標準化では既存製品との互換性も守らなければならない。 しかし、既存実装を受け入れ続けた結果として名称と実態がずれるなら、「共通のことば」を掲げる規格として説明が足りない。 私には、実装実績の多いベンダーの事情が規格に残り、利用者や小規模な実装者が解釈の負担を引き受けているように見える。 その構図には、苦さを感じる。

同じ方法で調べるときの手順

1. ノードプロファイル0EF001へ0xD6を問い合わせ、オブジェクト一覧を取得する。
2. 0x8Aの値は、ECHONETコンソーシアムの公式一覧で照合する。
3. 各オブジェクトへ0x8Cと0x8Dを問い合わせ、型番と製造番号で機器を分ける。
4. 型番はメーカーの公式製品情報と照合し、組み合わせて使う関連機器も確認する。
5. OUIはネットワークインターフェースの登録先を調べる材料にとどめ、現在の資本関係や製品ブランドの証拠には使わない。

出典

• ECHONET Lite規格書 Version 1.14 第2部 通信ミドルウェア仕様
• ECHONETコンソーシアム 発行済会員ID／メーカコード一覧
• ECHONET Lite規格の概要
• ECHONETコンソーシアム よくあるご質問
• エコーネットコンソーシアムについて
• エコーネットコンソーシアム CEATEC公開資料
• スマートグリッドフォーラム ECHONET LiteとIoTゲートウェイの開発
• ダイキン スマートアプリ よくある質問
• Nature Remo Eの狙いは電気のメルカリ
• ECHONET Lite搭載機器の相互接続性を阻害する家庭用ルータの実装状況調査
• IEEE OUIレジストリ
• 株式会社LIMNO 沿革
• シャープ JH-ASP01 製品情報
• シャープ JH-55SP4 製品情報