ZigBeeとZ-Waveの違いは？

家の周りのいくつかの場所にZ-Waveスイッチとコンセントを設置しました。しかし、デバイスを購入したときに、私が見ていたブランドで利用できるワイヤレスオプションがいくつかあることに気付きました。

Z-WaveデバイスとZigBeeデバイスの賛否両論を知りたいのですが。BluetoothでWiFiをいつ使用するかについてのこの投稿のような比較はすばらしいでしょう。

たとえば、多くの壁のある家では1つのスタイルが潜在的に有利であるのか、または「騒々しい」ワイヤレスホーム（たとえば、多くのワイヤレスデバイス/信号タイプ）の方が公平であるのかなどの情報に興味があります。

主に注意すべき点が1つあると思います。ZigBeeソリューションは2.4 GHzですか、それとも868/908 MHzですか？2.4 GHzは壁を貫通して900 MHz未満であり、2.4 GHzはWifi、Bluetooth、電子レンジなどとスペクトルを共有します。Z-Waveは900 MHz帯域のみを使用しています。

どちらのソリューションにも完全なネットワークスタックがありますが、少なくともライトコントロールなどのアプリケーションでは相互運用できません。どちらのテクノロジーも携帯電話などでは一般的ではないため、アプリの制御が必要な場合は、選択したテクノロジーのゲートウェイを通過する必要があります。

Z-WaveとZigBeeを実際に区別するいくつかの点があります。

周波数

1つ目は（Eirik Mが指摘したように）それらが動作する周波数です。Z-Waveは、915 MHz ISM帯域内で動作します。これにより、建築材料の適度な浸透（Wi-Fiより優れた）と全体的な距離の確保が可能になります。他のほとんどの家庭用デバイスがその帯域を使用していないという事実（現在900 MHzのコードレス電話はあまり普及していない）は、干渉も少ないことを意味します。

ZigBeeは、2.4 GHzまたは915 MHzで動作します。¹ 2.4 GHzはビジーバンドです。Wi-Fiと電子レンジ（その他）が動作する場所です。つまり、2.4 GHz ZigBeeデバイスは、915 MHz Z-WaveおよびZigBeeデバイスよりも多くの干渉を受けます。彼らはまた、壁を容易に通り抜けません。（2.4 GHz帯域はより高いビットレートを提供するため、そこにWiFiが存在します（5 GHz帯域も使用します）が、ほとんどのIoTデバイスは大量のデータを迅速に転送する必要がないため、915 MHzのより低い帯域幅バンドは欠点ではありません。）

¹ 915 MHzは北米でのみ使用されます。2.4 GHzは世界中で利用できますが、ZigBeeの低周波数帯域は規制地域によって異なります。さまざまな帯域は主に700 MHz〜900 MHzの範囲にあるため、915 MHzの北米の帯域に関する記述は、一般的に他の地域にも適用できます。

開放性

ZigBeeはオープンスタンダードですが、ZigBeeデバイスを販売する場合はZigBeeアライアンス（有料）に参加する必要があります。Z-Waveはライセンスされた独自規格ですが、高水準プロトコルは公に文書化されています。Z-Waveハードウェアを作成する場合は、Z-Waveアライアンスから仕様のライセンスを取得し、デバイスが標準への準拠をテストされている必要があります。適切にプログラム可能なインターフェイスを備えたZ-Waveデバイスを購入すると、既にライセンスされているハードウェアをパブリックプロトコル仕様で使用して、独自のソフトウェアを作成できます。

価格

参入障壁が低いため、ZigBeeデバイスは同じ機能を持つZ-Waveデバイスよりも安価になることがよくあります。もちろん、消費者向けIoTハードウェアは、他の多くの理由で価格が大きく異なる可能性があります。

相互運用性

Z-Waveデバイスは、全体的に相互運用性が高い傾向があります。Z-Wave標準の新しいバージョンがリリースされたとき、それらは下位互換性を維持しています。どのZ-Waveデバイスも、それぞれの年齢や製造元に関係なく、他のZ-Waveデバイスと適切に通信できる必要があります。（明らかに、新しいプロトコル機能は存在しませんが、古い機能は保持されます。）相互運用性テストは、Z-Waveコンプライアンスプロセスの一部です。ZigBeeには厳密なテスト方法がないため、一方または両方のデバイスの実装上の欠陥により、互いに通信できるはずの2つのZigBeeデバイスができない場合があります。

その上、ZigBeeは、すべて同じ基本プロトコルを共有するが、異なる通信詳細を使用する多数の異なるプロファイルをサポートします。;（トランスポートとして使用するHTTPの両方が、Google MapsのAPIを使用すると、GitHubでのサーバーに話をしている場合に非常に有用であることを行っていませんこれは、二つの異なるHTTP APIにやや似ている。） ほとんどのIoT ZigBeeデバイスはホームオートメーションプロファイルを使用しますが、通常はデバイスに文書化されていないため、予期しない問題が発生する可能性があります。例として、Philips HueライトはZigBeeを使用しますが、故意に操作できない方法で使用するため、Philips Hueブリッジを使用してそれらを制御する必要があります。（Z-Waveとは対照的です：Z-Wave認証プロセスでは、すべてのZ-Wave電球が標準の制御クラスを使用する必要があるため、準拠するZ-Waveコントローラーによって管理できます。）

ZigBeeアライアンスは現在、ZigBee 3.0という名前のZigBeeプロトコルの新しいイテレーションを開発中です。新しい仕様の目標の一部は、ZigBeeデバイス間の相互運用性を高めることです。ただし、それがどうなるかを確認する必要があります。しかし、まだ新しい規格の最終決定の予定はありません。

類似点

上記を書いている限り、ZigBeeとZ-Waveに共通していて、IoTデバイスで使用される他のプロトコルとは異なる点がいくつかあると思います。

ZigBeeとZ-Waveはどちらもメッシュネットワークです。WiFiおよびBluetoothとは異なり、すべてのデバイスがコントローラーを認識する必要がありますが、Z *デバイスは、それらの間、同じネットワーク内の他のZ *デバイス、およびコントローラー間に通信パスがある限り問題ありません。（もちろん、Z-WaveデバイスはZ-Waveデバイスとのみメッシュし、特定のプロファイルを持つZigBeeデバイスはそのプロファイルを持つ他のZigBeeデバイスとのみメッシュします。）

ZigBeeとZ-Waveはどちらもマルチベンダープロトコルです。上記の「オープン性」セクションの内容にかかわらず、ZigBeeとZ-Waveの両方には、多くの場合互いに競合するさまざまな企業から入手可能なデバイスがあります。（Z-Waveライトスイッチを作成する企業には、GE、Aeotec、Linear、DragonTechなどが含まれます。）他の多くのIoT関連プロトコルは単一企業のサイロ（LutronCasétaなど）です。他のシステムがそれらを制御できるようにするゲートウェイがあるかもしれませんが、その会社のデバイスだけがネットワークに参加できます。

ソフトウェアの人として、そしてプロトコルスタックの人として、私はこれをあなたとは違う見方をする傾向があります。

私にとって、これらのプロトコルは「低レベル」のものです（OSI 7レイヤーモデルのレイヤー1および2）。

デバイスがバッテリーまたは太陽電池式でない限り、私は特に電力消費について気にしません。私の職業生活では、ハードウェアに関する決定を残すことができます。これは、既製の場合、レイヤー2プロトコルの選択をハードウェア担当者に指示する傾向があります。私の私生活では、価格、サポート（コミュニティの規模とフォーラムの可用性が非常に重要です）、そして仕様を最もよく理解しているものを選んでいます

システム全体の機能を探す傾向があります。たとえば、メッシュネットワークの場合、優れたZigBeeソリューションがいくつかあります。

たとえば、一部の信号は長距離で機能し、一部の信号は「ノイズの多い」環境で優れていますか？

長距離の場合、100mではなく、1km / 1/2マイルの範囲で十分に十分なFlutterを推奨することはできません。

費用はたったのUS $ 20で、これが範囲についての考えを与えるための写真です

ノイズの多い環境は私の専門ではありません。ハードウェアの担当者にお任せください。申し訳ありませんが、ハードウェアではなくソフトウェアであるシャノンリミットなどのノイズへのアプローチ（また、前方誤り訂正、等）

先ほど言ったように、これらのプロトコルは、アプリケーション開発者（実際には少し低いレイヤー3の人）にとって「低レベル」のものです。

はい、そういったことを考慮することが重要ですが、多くの人は「わかっています。RaspberryPI（または何でも）を使います」と言って、それが提供するものをすべて受け入れます。

その後、アプリケーションを開発するときに、使用する上位レベルのプロトコルを決定する必要があります。一般に、サーバーが特定のプロトコルを指示しない限り、主に3つの選択肢があります。

• TCPを使用し、独自のプロトコルを開発します。
• HTTP（S）を使用してRESTfulインターフェースを開発します（マルチスレッドの場合など、非同期の非ブロッキングが必要な場合はAJAXを使用します）。多くのトランザクションがある場合、時間が重要な場合、またはサーバーの操作に時間がかかる場合を除いて、ブロッキングインターフェイスを使用して回避できます。
• 豊富なIoTの「標準」から1つを選択してください。お使いのデバイスが特定のプロトコルを強力にサポートしている場合、またはサーバーがそれを要求している場合にのみ、これをお勧めします。

あなたの質問を正しく理解できたことを願っています。おそらく、よりハードウェア指向であるかソフトウェア指向であるか、IoTデバイスのみで開発するのか、それともサーバーで開発するのか、あるいはこれは一般的な質問にすぎない（推奨されない）かどうかを教えていただけますか？