ぐりふぉんです。
ご訪問ありがとうございます。
「危険な？ロボット掃除機」の続報です。
ようやく謎電波の正体がわかりましたのでご報告。
前回のブログ
簡単に経緯を説明します。
家の中に謎のWi-Fi電波
が飛んでいました。
このWi-Fi電波は2.4GHz帯で、家のルーターのチャンネルとぴったり同じチャンネルで追随してきます。
しかもかなり強力で、外部からの発信とは思えませんでした。
さては盗聴か
と、少し慌てました。
色々調べた結果、ECOVACS社のロボット掃除機から発信されていることを突き止め、サポートセンターに事の次第を報告し、何か対策はないかと尋ねました。
その結果、
①謎電波はステーションから発信している。
②電波の目的はロボット掃除機の帰還用ビーコン。
という返答がありました。
しかしながら、Wi-Fi電波のような指向性のない電波を帰還用ビーコンに使うのはおかしいし、謎電波は明らかにロボット掃除機本体から発信されていました。
ここからが新しい内容になります。
さらに問い合わせを実施しました。
ロボット掃除機の電源を切ると謎電波が停止するが、ステーションから電波が発信されているとするとこれはおかしくないか
これに対するサポートセンターからの返答：
当該のSSIDは、ステーションとロボット掃除機本体が相互に通信を行うことによって発信される仕様となっております。
ステーションが掃除機本体を検知して初めて有効になるため、ステーションに電源が入っていても、ペアリングされている本体側の電源が切れてしまうと、通信リンクが切断され、ステーション側からの信号発信も自動的に停止する仕組みとなっております。
一見、筋が通っているように思えますが、私は納得できませんでした。
サポセンへさらに問い合わせ
①チャンネル追随について
自宅のWi-Fiルーターの使用チャンネルを変更すると、「E_xxxx_xxxx」のSSIDもほぼ即座に同じチャンネルに移動することを確認しています。ステーションとロボット本体間の通信のためのSSIDであれば、自宅ルーターのチャンネルに追随する必要はないように思われます。
②セキュリティ脆弱性修正ファームウェアの配信について
DEEBOT X1 OMNIに関するセキュリティ脆弱性（CVE-2025-30198、CVE-2025-30199、CVE-2025-30200）が報告されており、グローバル版ではファームウェアバージョン2.4.45で修正済みと認識しています。しかし現在、日本向けのアプリでは2.3.9が最新版と表示されており、修正済みバージョンが配信されていません。
日本国内でのセキュリティ修正版ファームウェアの配信予定時期をお教えください。
これに対するサポートセンターからの返答：
①無線LAN（Wi-Fi）の通信チャンネルに関する仕様について
本機はネットワークインターフェースカードを1枚搭載する仕様となっております。
そのため、外部ネットワーク接続用（wlan0）と製品専用SSID「E_xxxx_xxxx」（wlan1）は、常に同一の通信チャンネルで動作いたします。
お客様のご利用環境において、接続先の無線ルーターのチャンネルが切り替わった場合、それに追随して製品専用SSIDのチャンネルも自動的に変更されます。
本件につきましては、現在のところ仕様変更や修正の予定はございません。
何卒、ご了承いただけますようお願い申し上げます。
②セキュリティアップデートの配信予定について
現在、より安全にご利用いただくための「セキュリティ強化版」のソフトウェアアップデートを準備しております。
開発および検証にお時間をいただいており、お客様への正式な配信開始は本年9月?10月頃を予定しております。
===============================
基本、「ゼロ回答」でしたので、さらにサポセンを追求しました
回答内容を踏まえ、以下の実験で最終確認を行いました。
・ロボット掃除機本体の電源オフ、ステーション電源オン → SSID消滅
・ステーション電源オフ、ロボット掃除機本体電源オン → SSID発信継続
この結果から、「E_xxxx_xxxx」はロボット掃除機本体に搭載されたNICから発信されていることが確認できました。回答1の「本機」はロボット掃除機本体を指しているという理解で相違ないでしょうか。
これに対するサポートセンターからの返答：
この度は詳細な検証結果をご共有いただき、誠にありがとうございます。
また、これまでのご案内内容に一部説明の不整合、認識不足がありましたこと、お詫び申し上げます。
ご認識いただいております通り、製品専用SSIDはステーション側から発信されるものではなく、DEEBOT本体側から発信されるものとなります。
構成としては、DEEBOT本体がいわば「ルーター」のような役割を担い、「E_xxxx_xxxx」を発信し、ステーション側がそれへ接続することで、本体とステーション間の通信を実現しております。
例えるなら、DEEBOT本体がWi-Fiルーター、ステーションが接続される端末のような関係となります。
サポセンがようやく初期回答の誤りを認めてきました。
これでも私はまだ納得できませんでした。
さらに追求です。
DEEBOT本体がルーター役、ステーションが端末役という構成は理解しました。
一点確認させてください。以前のご回答で「DEEBOT X1 OMNIは、ステーションへ戻る際、このホットスポット信号を拾うことで正確に帰還する」とご説明いただきました。
しかし、SSIDがDEEBOT本体から発信されている以上、本体が自ら発信した信号を本体自身が帰還のために「拾う」ことは技術的に成立しません。
「Wi-Fiホットスポット信号を拾うことで帰還する」という当初のご説明も認識不足による不正確な説明だった、という解釈でよろしいでしょうか。
これに対するサポートセンターからの返答：
お客様からご指摘いただいた通り、「本体が発信したホットスポット信号を自ら拾って帰還する」という以前の説明は、技術的に誤りであり、当方の認識不足による不正確なものでございました。
お客様を混乱させてしまいましたことを、深くお詫び申し上げます。
改めて正確な仕様を確認いたしましたところ、本製品のベースへの帰還（自動充電）は、主にステーションからの赤外線信号を頼りに行われており、Wi-FiのSSID信号は帰還動作には直接関係しておりません。
なお、セキュリティ修正版の件につきまして、ファームウェア（バージョン 2.4.45）をお客様宛に配信しておりますので、 お手数をおかけいたしますが、アプリ上の通知をご確認いただき、お早めにファームウェアの更新を行っていただけますでしょうか。
今後はこのような誤った情報をご案内することのないよう、製品知識の向上とチェック体制の強化に努めてまいります。
というわけで、完全勝利しました
サポセンに勝ってどーする
しかも、日本向けにはまだ配信されていないファームウェアを個別配信してもらったというおまけ付きです。
掃除機の帰還は赤外線ビーコンだったということもわかりました。
普通はそうするよね。
さて、以上を踏まえて最終考察です。
X1 OMNIが他社や後継機（X2 OMNI）と異なる特殊な仕様になった理由は、この機種が「全自動ステーション（ゴミ収集＋モップ洗浄・乾燥）」を世に送り出した先駆的モデルであったことによる、開発段階の妥協（技術的負債）である可能性が極めて高いと考えられます。
技術的な背景として、以下の3点が推測されます。
①大容量データ通信の必要性（Wi-Fiの採用）
X1 OMNIは、モップやゴミの制御に加え、見守りカメラの映像転送や独自の音声アシスタント（YIKO）など、ステーションと本体間でやり取りするデータ量が従来のロボット掃除機とは桁違いに増加しました。
そのため、帯域の狭いBluetoothや近距離の赤外線だけでは制御しきれず、ステーションとの通信に大容量のWi-Fiを使わざるを得なかったという事情があったのではないか？
②ハードウェア設計のショートカット（NIC1枚構成）
本来であれば、外部ネットワーク接続用とステーション通信用で物理的にチップ（NIC）を分けるか、デュアルMACに対応した高度なSoCを搭載すべきです。
しかし、開発スピード（市場への早期投入）とコストの制約から、1枚の安価なNICに無理やり「ルーター機能（アクセスポイント）」と「子機機能（クライアント）」を兼任させるという、力技の設計で乗り切ってしまったと考えられます。
③後継機（X2 OMNI）での軌道修正
この「1枚のNICを酷使する力技」は、電波干渉や、CVEで指摘されたセキュリティの脆弱性といった深刻な問題を引き起こしました。メーカー側もX1 OMNIの市場投入後にこのアーキテクチャの限界を痛感したため、後継のX2 OMNIではハードウェア設計を根本から見直し、通信仕様の適正化を行ったのではないか。
結論として、X1 OMNIのあの仕様は、スマート家電の過渡期に生まれた「多機能化とコストダウンを急ぐあまり、ネットワーク設計のセオリーを無視してしまったハードウェアの歪み」だと言えるのではないか。
特にECOVACSはハードウェアに新機軸を取り入れるのは早いのですが、それにソフトウェアが追いついていないのではないかというもっぱらの評価です。
ではなぜ、ECOVACSはX1 OMNIでわざわざWi-Fi（しかも本体をルーター化する変則的な構成）を使ったのか。
内部の設計思想については推測の域を出ませんが、技術的な観点から以下の理由が考えられます。
①本体とステーションの連携を「TCP/IP」で組んでしまった
開発当初、本体とステーション間の高度な連携（ゴミ収集、モップ洗浄、乾燥、ステータス同期など）の制御プログラムを、シリアル通信ではなく、IPアドレスを利用したネットワーク通信（TCP/IP）ベースで設計してしまった可能性が高い。
②ユーザーの「Wi-Fi設定の手間」を省くための力技
ステーションと本体をTCP/IPで通信させる場合、本来であれば「本体」と「ステーション」の両方を自宅のWi-Fiルーターに接続させるのがセオリーです。
しかし、ユーザーにアプリから2つの機器のWi-Fi設定をさせるのは手間がかかり、接続エラーの要因にもなります。
そこで、「ユーザーが設定するのは本体だけ」にし、「ステーションは工場出荷時から、本体が発信する固定SSID（E_xxxx_xxxx）に自動接続する」という仕様にした。
これにより、設定の手間を省きつつ、両者間でTCP/IP通信を確立させた。
要するに設計の初期判断ミスをWi-Fiという力技で誤魔化した結果、本体が常にルーターと同じチャンネルでアクセスポイントとして電波を吹き続けるという、ネットワーク環境に負荷をかける仕様が世に出てしまったと推察されます。
長々とお付き合いいただき、本当にありがとうございました。
IoTの技術論に興味のない人にはつまんない内容でしたね。
あ、そうそう、この機種のユーザーの方は是非サポセンに連絡して、セキュリティリスクの少ない最新版のファームウェアを配信してもらってください。
まだ個別配信しか対応していないみたいなので。