リトコが団結

少し前にご紹介させていただきました スマートサーモスタット。 この記事は元々、ファームウェアと制御システムのデモンストレーションを目的としたものでした。 しかし、サーモスタットのロジックと実装内容を説明するには、全体の概念を全体的に概説する必要があります。

自動化について

従来、すべての自動化は次の XNUMX つのカテゴリに分類できます。
カテゴリー1 — 個別の「スマート」デバイス。 さまざまなメーカーから電球やティーポットなどを購入します。 長所: 各デバイスは機能を拡張し、快適性を高めます。 短所: 新しいメーカーごとに独自のアプリケーションが必要です。 異なるメーカーのデバイスのプロトコルは、相互に互換性がないことがよくあります。

カテゴリー2 — シングルボード PC または x86 互換のインストール。 これにより、コンピューティング能力の制限がなくなり、MajorDoMo またはスマート ホームを管理するためのその他のサーバー ディストリビューションがこのマシンにインストールされます。 したがって、ほとんどのメーカーのデバイスは単一の情報空間に接続されています。 それらの。 スマートホーム用の独自のサーバーが表示されます。 長所: 単一センターでの互換性により、管理機能が強化されます。 短所: サーバーに障害が発生すると、システム全体がステージ 1、つまりステージ XNUMX に戻ります。 断片化したり、役に立たなくなったりします。

カテゴリー3 - 最もハードコアなオプション。 修理段階では、すべての通信が敷設され、すべてのシステムが二重化されます。 長所: すべてが完璧になると、家は真にスマートになります。 欠点: カテゴリー 1 および 2 に比べて非常に高価で、事前にすべてを検討し、あらゆる細部を考慮する必要があります。

ほとんどのユーザーはオプション 3 を選択し、その後スムーズにオプション XNUMX に進みます。 そして、最も持続的なものはオプション XNUMX に到達します。

しかし、分散システムと呼ぶことができるオプションがあります。つまり、個々のデバイスがサーバーとクライアントの両方になります。 本質的に、これはオプション 1 とオプション 2 を組み合わせて検討する試みです。両方の長所をすべて取り入れ、短所を排除して、黄金比を見つけます。

おそらく、そのようなオプションはすでに開発されていると誰かが言うでしょう。 しかし、そのような決定は狭い範囲に焦点を当てています。 プログラミングに詳しい人向け。 私たちの目標は、エンドデバイスの形でも、既存のデバイスをシステムに統合する形でも、このような分散システムへの参入障壁を下げることです。 サーモスタットの場合、ユーザーは古いサーモスタットを取り外し、スマートサーモスタットを取り付け、既存のセンサーをそれに接続するだけです。 追加の手順は必要ありません。

例を使用してシステムへの統合を見てみましょう。

ネットワーク上に 8 つの Sonoff モジュールがあると想像してみましょう。 一部のユーザーにとっては、Sonoff クラウド (カテゴリ 1) 経由の制御で十分です。 一部のファームウェアはサードパーティのファームウェアを使用し始め、スムーズにカテゴリ 2 に移行します。サードパーティのファームウェアの大部分は、MQTT サーバーにデータを転送するという同じ原理で動作します。 OpenHub、Majordomo、またはその他のものは、インターネットまたはローカル ネットワーク上にある単一の情報空間に異種のデバイスを統合するという XNUMX つの目的を果たします。 したがって、サーバーの存在は必須です。 ここで主な問題が発生します。サーバーに障害が発生すると、システム全体が自律的に動作を停止します。 これを防ぐために、システムはより複雑になり、サーバー障害が発生した場合の自動化を二重化する手動制御方法が追加されます。

私たちは、各デバイスが自立するという別の道を選びました。 したがって、サーバーは決定的な役割を果たさず、機能を拡張するだけです。

思考実験に戻りましょう。 同じ 8 つの Sonoff モジュールをもう一度使用して、Lytko ファームウェアをそれらにインストールしてみましょう。 すべての Lytko ファームウェアにはこの機能があります SSDP。 SSDP は、ネットワーク サービスのアドバタイズと検出のためのインターネット プロトコル スイートに基づくネットワーク プロトコルです。 リクエストに対する応答は、標準または拡張のいずれかになります。 この回答には、標準機能に加えて、ネットワーク上のデバイスのリストの作成が含まれています。 したがって、デバイス自体がお互いを見つけ、それぞれがそのようなリストを持つことになります。 SSDP シートの例:

"ssdpList": 
	{
		"id": 94967291,  
		"ip": "192.168.x.x",
                "type": "thermostat"
	}, 
	{
		"id": 94967282,
		"ip": "192.168.x.x",
                "type": "thermostat"
	}

例からわかるように、リストにはデバイス ID、ネットワーク上の IP アドレス、ユニット タイプ (この場合は Sonoff ベースのサーモスタット) が含まれています。 このリストは XNUMX 分ごとに更新されます (この期間は、ネットワーク上のデバイス数の動的な変化に対応するには十分です)。 このようにして、ユーザーのアクションを必要とせずに、デバイスの追加、変更、無効化を追跡します。 このリストはブラウザーまたはモバイル アプリケーションに送信され、スクリプト自体が指定された数のブロックを含むページを生成します。 各ブロックは XNUMX つのデバイス/センサー/コントローラーに対応します。 視覚的にはリストは次のようになります。

しかし、他の無線センサーが cc8266 (ZigBee) または nrf32 (MySensors) 経由で esp2530/esp24 に接続されている場合はどうなるでしょうか?

プロジェクトについて

市場にはさまざまな分散システムが存在します。 当社のシステムを使用すると、最も人気のあるシステムと統合できます。

以下は、さまざまなメーカー間の非互換性に関する状況を何らかの形で変えようとしているプロジェクトです。 これは、例えば、 SLSゲートウェイ, マイセンサー または ZESP32. ZigBee2MQTT は MQTT サーバーに関連付けられているため、この例には適していません。

MySensors を実装するための 8266 つのオプションは、ESP32 に基づくゲートウェイです。 残りの例は ESPXNUMX 上にあります。 そして、それらの中で、デバイスの検出とリストの作成という動作原理を実装できます。

別の思考実験をしてみましょう。 ZESP32 ゲートウェイ、SLS ゲートウェイ、または MySensors を使用しています。 それらを単一の情報空間に組み合わせるにはどうすればよいでしょうか? これらのゲートウェイの標準機能にSSDPプロトコルライブラリを追加します。 SSDP 経由でこのコントローラーにアクセスすると、接続されているデバイスのリストが標準応答に追加されます。 この情報に基づいて、ブラウザはページを生成します。 一般的には次のようになります。

ウェブインターフェース

PWAアプリケーション

"ssdpList": 
{
   "id": 94967291, // уникальный идентификатор устройства
   "ip": "192.168.x.x", // ip адрес в сети
   "type": "thermostat" // тип устройства
},
{
   "id": 94967292,
   "ip": "192.168.x.x",
   "type": "thermostat"
},
{
   "id": 94967293,
   "ip": "192.168.x.x",
   "type": "thermostat"
},
{  
   "id": 13587532, 
   "type": "switch"  
},
{  
   "id": 98412557, 
   "type": "smoke"
},
{  
   "id": 57995113, 
   "type": "contact_sensor"
},
{  
   "id": 74123668,
   "type": "temperature_humidity_pressure_sensor"
},
{
    "id": 74621883, 
    "type": "temperature_humidity_sensor"
}

この例は、デバイスが互いに独立して追加されることを示しています。 独自の IP アドレスを持つ 3 つのサーモスタットと、一意の ID を持つ 5 つの異なるセンサーが接続されています。 センサーが Wi-Fi ネットワークに接続されている場合、センサーには独自の IP が割り当てられ、ゲートウェイに接続されている場合、デバイスの IP アドレスはゲートウェイの IP アドレスになります。

デバイスとの通信には WebSocket を使用します。 これにより、リクエストを取得する場合に比べてリソースコストを最小限に抑え、接続時や変更時に動的に情報を取得できます。

データは、サーバーを経由せず、ブロックが属するデバイスから直接取得されます。 したがって、いずれかのデバイスに障害が発生しても、システムは動作を継続します。 Web インターフェイスでは、リストに見つからないデバイスが表示されません。 ただし、紛失に関する信号は、必要に応じて、ユーザーのアプリケーションに通知の形で送信されます。

このアプローチを実装する最初の試みは、PWA アプリケーションでした。 これにより、ブロックベースをユーザーのデバイスに保存し、必要なデータのみをリクエストすることができます。 ただし、構造の特殊性により、このオプションは不完全です。 そして、解決策は XNUMX つだけあり、Android および IOS 用のネイティブ アプリケーションが現在活発に開発されています。 デフォルトでは、アプリケーションは内部ネットワーク上でのみ動作します。 必要に応じて、すべてを外部コントロールに転送できます。 そのため、ユーザーがローカル ネットワークを離れると、アプリケーションは自動的にクラウドに切り替わります。

外部制御 - 完全なページ複製。 ページがアクティブになると、ユーザーはサーバーにログインし、個人アカウントを通じてデバイスを管理できるようになります。 したがって、サーバーの機能が拡張され、ポート転送や専用 IP に縛られずに、外出先からデバイスを管理できるようになります。

したがって、上記のオプションにはサーバー アプローチの欠点がなく、新しいデバイスを接続する際の柔軟性という形で多くの利点もあります。

サーモスタットについて

例としてサーモスタットを使用して制御システムを見てみましょう。

提供された：

1. 各サーモスタットの温度制御 (別個のブロックとして表示)。
2. サーモスタットの動作スケジュールを設定します（朝、昼、夕方、夜）。
3. Wi-Fi ネットワークを選択し、デバイスをそれに接続します。
4. デバイスを「無線で」更新します。
5. MQTT のセットアップ;
6. デバイスが接続されているネットワークを設定します。

Web インターフェースを介した制御に加えて、ディスプレイをクリックするという従来のインターフェースも提供しました。 Nextion NX3224T024 2.4 インチ モニターが搭載されています。 この選択は、デバイスの操作の容易さから彼に下されました。 しかし、私たちは STM32 に基づいて独自のモニターを開発しています。 その機能は Nextion より劣っていませんが、コストが安くなり、デバイスの最終価格にプラスの影響を与えるでしょう。

他の自尊心のあるサーモスタット スクリーンと同様に、Nextion は次のことができます。

• ユーザーが必要とする温度を設定します (右側のボタンを使用)。
• スケジュールされた動作モードをオンまたはオフにします (ボタン H)。
• リレー動作を表示します（左側の矢印）。
• チャイルドプロテクション機能を備えています（ロックが解除されるまで物理的なクリックはブロックされます）。
• WiFi 信号強度を表示します。

さらに、モニターを使用すると、次のことが可能になります。

• ユーザーが取り付けたセンサーの種類を選択します。
• チャイルドロック機能を管理します。
• ファームウェアを更新します。

WiFi バーをクリックすると、接続されているネットワークに関する情報が表示されます。 QR コードは、HomeKit ファームウェアでデバイスをペアリングするために使用されます。

ディスプレイを操作するデモ:

私たちが開発したのは、 デモページ XNUMX つのサーモスタットが接続されています。

「サーモスタットの何が特別なのですか?」と疑問に思うかもしれません。 現在、Wi-Fi機能、スケジュール運転、タッチコントロールを備えたサーモスタットが数多く販売されています。 また、愛好家は、最も人気のあるスマート ホーム システム (Majordomo、HomeAssistant など) と対話するためのモジュールを作成しました。

当社のサーモスタットはそのようなシステムと互換性があり、上記のすべてを備えています。 しかし、特徴的なのは、システムの柔軟性のおかげで、サーモスタットが常に改良されていることです。 アップデートのたびに機能が拡張されます。 (スケジュールに従った) システム管理の標準的な方法に、適応的な方法を追加します。 このアプリケーションを使用すると、ユーザーの地理位置情報を取得できます。 このおかげで、システムはその場所に応じて動作モードを動的に変更します。 また、天気モジュールを使用すると、気象条件に適応できます。

そして拡張性。 誰でも既存の従来型サーモスタットを当社のサーモスタットに置き換えることができます。 最小限の労力で。 市場で最も人気のある 5 つのセンサーを選択し、それらのサポートを追加しました。 ただし、センサーが独自の特性を持っている場合でも、ユーザーはそれを当社のサーモスタットに接続することができます。 これを行うには、特定のセンサーと連動するようにサーモスタットを調整する必要があります。 ご案内をさせていただきます。

サーモスタットやその他のデバイスを接続すると、Web インターフェイスと PWA アプリケーションの両方のあらゆる場所に同時に表示されます。 デバイスの追加は自動的に行われます。必要なのは、デバイスを Wi-Fi ネットワークに接続することだけです。

私たちのシステムはサーバーを必要とせず、サーバーに障害が発生してもカボチャに変わりません。 コンポーネントの XNUMX つが故障した場合でも、システムは緊急シナリオで動作を開始しません。 コントローラー、センサー、デバイス - 各要素はサーバーとクライアントの両方であるため、完全に自律的です。

興味のある方は、当社のソーシャル ネットワークをご覧ください: Telegram, Instagram, 電報ニュース, VK, Facebook.

Eメール： [メール保護]

PS サーバーを放棄することはお勧めしません。 MQTT サーバーもサポートしており、独自のクラウドも備えています。 私たちの目標は、システムの安定性と信頼性をまったく新しいレベルに引き上げることです。 サーバーが弱点ではなく、機能を補完し、システムをより便利にします。

出所： habr.com