リモートコントロール暖房システム

モノのインターネット（IoT、モノのインターネット）は有望な分野です、とアナリストは言います。 IoTの主な傾向の1つは、住宅の自動化、またはマーケティング担当者が言うように「スマートホーム」の作成です。

口頭での練習はそのままにして、特定のプロジェクトを検討しましょう。

問題の声明

私はモスクワ近くの自分の家に住んでいます。 このタイプの宿泊施設の明らかな利点に加えて、いくつかのニュアンスがあります。 管理会社がアパートの建物で共同作業の大部分を引き受ける場合、自分の家で個別に解決する必要があります。

私にとってこれらのタスクの1つは、加熱システムのリモート監視と制御の必要性でした。 ロシア中部の冬の暖房は快適さの問題ではなく、生き残りの問題であることは事実です。 繰り返し確認されている経験則によると、すべてのトラブルは最も不適切なタイミングで発生します。 私の家で10年以上生活してきた私は、この法律の有効性も確信しました。

しかし、たとえば、30度の霜の中で給水ポンプの故障が何とか克服できる場合、暖房ボイラーの故障は災害に変わります。 このような霜では、通常断熱された家は1日以内に冷えます。

冬を含め、私はしばしば長い間家に帰らなければなりません。 したがって、暖房システムの状態とその制御をリモートで監視する機能は、私にとって急務となっています。

私の家では、暖房システムには2つのボイラーがあります。1つはソーラーボイラー（また、ガスはなく、予期されていません）と1つです。 この選択は、予約の問題だけでなく、暖房費の最適化にも起因しています。 夜には、激しい霜を除いて、電気ボイラーが作動します。これは、2関税の電気メーターが家に設置されているためです。 このボイラーの電力は、快適な夜の温度（18〜19度）に十分です。 午後、ソーラーボイラーが仕事に入り、温度を22〜23度に上げます。 このモードでは、加熱システムは数年間稼働しており、このオプションが経済的であると結論付けることができます。

加熱システムの毎日の手動切り替えが最も合理的な選択ではないことは明らかであるため、このプロセスを自動化すると同時に、リモートコントロールの可能性を提供することが決定されました。

参照条件

開発者の習慣に従って、私が最初にしたことは、作成される制御システムの要件を体系化して、技術的なタスクに似たものを自分で作成することでした。

設計ソリューションの基本的な要件の短いリストは次のとおりです。

• 家や路上で温度を制御する
• 加熱ボイラーを選択するための3つのモードを提供します（詳細は以下）
• システムの状態とその管理のリモート監視を提供します

最初は、リストにはさらにいくつかの項目がありましたが、さまざまな理由で除外されました。 たとえば、現在のパラメーターの表示とタッチスクリーンを介して制御する機能を備えた画面をシステムに装備することを計画しました。 しかし、インターネットを介したリモートコントロールの不必要な複製のように思えました。 もちろん、ローカルでの表示と制御が必要な場合、非常に現実的な状況を思いつくことができます。 私は議論しませんが、この機能がシステムの複雑さとコストをさらに必要とすることを忘れないでください。

暖房システム制御アルゴリズムには、完全な停電に関連する黙示録シナリオが含まれています。 明確なビジネス。この場合、リモートコントロールについて話す必要はありません。 しかし、家にいる人は、いくつかの簡単な操作で緊急暖房モードに入ることができます。 1つの外部4極トグルスイッチを切り替えて、予備のガソリン駆動発電機を起動するだけで十分です。 これにより、ソーラーボイラーの運転がオフラインになります。 実際には、氷雨が電力線の配線の大規模な破損につながったときに、これはすでに数回発生しています。

近代的な暖房ボイラーは、通常、従来の2線ケーブルで接続されたリモートコントロールユニットを備えています。 工場の制御回路に入らないように、これらのワイヤ自体を通勤させることが決定されました。 従来の電気機械式リレーによる断線は、ボイラーのシャットダウンにつながります。

IoTセキュリティ方法

スマートホームをハッキングした場合の結果についてのホラーストーリーを読んで、私はそれを安全にプレイし、外部のハッキングの可能性を最小限に抑えることにしました。 誰かがあなたのスマートホームを解く必要があると言うでしょう。 私は同意しますが、その可能性は最小限ですが、Webサーバーの定期的なハッキングの試みを観察して、私は原則に基づいて行動することにしました。 冗談。

これを行うために、中央サーバーが分散スマートセンサー（デバイス）の管理を開始するときに、一般的なパラダイムを放棄しました。 クライアントがスマートセンサーである従来のクライアント/サーバースキームを使用することが決定されました。
このようなアーキテクチャの選択は、IoTでは常に可能というわけではありませんが、この場合、暖房システムは十分に大きな慣性を持っているため、非常に受け入れられます。 システムの設定（部屋の温度など）が瞬時かつ任意に変更される可能性がある場合でも、設定されたパラメーターを即座に達成することはできません。

データ交換のイニシアチブをスマートセンサーの側面に転送することにより、見知らぬ人によるハッキングをほぼ完全に排除することができます。 結局のところ、センサーはサーバーからの要求に対する応答のみを認識します。 理論的には、このようなリクエストをインターセプトしてレスポンスを置き換えることができますが、この脅威は、たとえばhttpsプロトコルによって最小限に抑えられます。 センサーでこのプロトコルを上げる必要がない場合は、攻撃者が事前に知らないパラメータを考慮してチェックサムを計算するバリアントがあります。 しかし、この暗号の問題はこのトピックの範囲を超えています。

サーバーが要求に対する応答を受信しなかった場合、スマートセンサーは、特定のタイムアウトを待った後、以前に設定されたモードで動作し続けます。

サーバーとして、MySQLデータベースを持つ小さなWebサイトを作成することが決定されました。MySQLデータベースは、私のサイトのいずれかの第3レベルドメインにデプロイされました。 このサイトはアダプティブレイアウトを使用して記述されているため、スマートフォンで快適に作業できます。
サーバーと情報を交換するために、5分間が選択されました。

一部には、この選択は電気ボイラーの微妙な違いによるものです。 ヒーターフラスコ内の熱湯が発熱体の余熱から沸騰するのを防ぐため、いわゆるボイラーランアウトが使用されます。 言い換えれば、加熱素子をオフにした後、円形ポンプはしばらく動作し続けます。 ボイラーでは、デフォルトでは4分間実行されますが、もっと長くすることもできます。 したがって、5分間の交換間隔は加熱システムのロジックに適合します。 はい、そして、より頻繁なデータ交換は何の利益ももたらさず、サーバーデータベース内のレコード数の増加につながりました。

作業アルゴリズム

気象モジュールと呼ばれるスマートセンサーの動作には、異常なものは含まれていません。 サイクルでは、温度および湿度センサーが調べられます。 これは約4.5分間続きます。 次に、サーバーへのGET要求が生成され、受信した応答が処理されます。 その結果、期間（メインサイクル）は約5分の期間で取得されます。 完全な精度は必要ありませんが、実際には数秒で期間が短くなり、徐々にシフトします。 1日5分の理想的な期間では、288の測定値が送信されますが、実際には289〜290があります。 これは、システムの動作にまったく影響しません。

詳細なコメント付きのプログラムのメインスケッチがリストに表示されます。 膨大なコードのため、使用したルーチンの実装を公開しませんでした。 リストには、端末への出力用の診断メッセージが含まれています。


前述したように、天気モジュールには3つの動作モードがあります。

• 自動
• 半自動
• マニュアル

自動モードでは、気象モジュールは、内蔵のリアルタイムクロックに基づいて、一度にオンにするボイラーを選択します。 電気の関税が引き下げられた時間の間に、電気ボイラーが起動されます。

このシステムの初期バージョンでは、ディーゼル燃料を節約するために、昼間でも電気ボイラーを作動させることが可能でした。 この実施形態では、気象モジュールは、日中の電気ボイラーの持続時間を監視した。 1時間以内に家の設定温度に達することができなかった場合、電気ボイラーの電源を切り、一時停止してからソーラーボイラーをオンにしました。

最初の冬の経験によると、このオプションは削除されました。 理由は、電気ボイラーの電力が不十分であったため、比較的厳しい霜（-10度未満）で所定の快適な温度を達成できなかったためです。 そのため、午後に自動モードで明確にソーラーボイラーを起動することが決定されました。

半自動モードは、気象モジュールの温度センサーに応じてその動作の自動調整を維持しながら、ボイラーを厳密に選択することを意味します。 このモードは、いくつかの場合に有用であることが証明されています。 まず、1つのボイラーが故障すると、時刻に関係なく、別のボイラーの動作が強制的に設定されます。 第二に、穏やかな霜と雪解けでは、24時間電気ボイラーをオンにすることができます。逆に、非常に厳しい霜では、ソーラーボイラーのみを起動できます。

私は実質的に手動モードを使用しません。 これは、操作のために特定のボイラーを選択するだけでなく、標準の外部ユニットに制御を移すことも意味します。 つまり、ボイラーは、このユニットの設定温度パラメーターによって制御されます。 このモードの気象モジュールは、温度と湿度を監視するためのステーションとしてのみ機能し続けます。

サーバーへのリクエストで、気象モジュールは、ボイラーの現在の状態（選択されているボイラー、稼働していないボイラー）、気象モジュールの現在の現地時間、過去5分間のボイラーの期間、家の内外の現在の温度と湿度に関する情報を含むデータパケットを送信します。 要求には、天気モジュールの識別子も含まれます。 私の場合、これは不要ですが、スケーリングのための設計の習慣が感じられました。

要求を送信した後、天気モジュールは20秒以内にサーバーの応答を待ちます。 受信した回答は、正規表現を使用して解析されます。 サーバー応答には4つのパラメーターがあります。

• 家の中の温度のしきい値
• 家の外の閾値温度
• 操作モードを設定する
• モジュールのリアルタイムクロックの初期セットアップ時間

現在のバージョンでは、外気温度のしきい値は使用されていません。 この可能性は、「船外」の温度に応じて、加熱パターンの選択の実装に提供されました。 おそらくこの機能は実装されるでしょう。

最後のパラメーターはほとんど必要ありません。 私は彼に二度だけ尋ねた。 モジュールの最初の起動時、およびリアルタイムクロックモジュールのバッテリー交換後。 一時的な設定を変更する必要がない場合、このパラメーターはゼロです。

サーバーからの応答を解析した後、ボイラーの現在の操作時間カウンターがリセットされます。 結局、以前の値は既にサーバーに送信されています。 リセットするとき、サーバーからの応答を待つための一時停止時間が考慮されます。

送信されたボイラー運転時間には推定値があることに注意してください。 このパラメーターは、たとえば消費電力を許可しません。 これは、加熱ボイラーの機能によるものです。 たとえば、ボイラー内の温度が80度に達するとオフになりますが、循環ポンプは動作し続けます。 クーラントの温度が60度に下がると、ボイラーは再びオンになります。 気象モジュールは、ボイラーが家の中の温度しきい値に達するまでにかかった合計時間のみを測定します。

設定温度に達すると、ボイラーのスイッチがオフになり、気象モジュールは30秒の頻度で温度インジケーターを読み取り続けます。 温度が0.5度以上低下すると、加熱ボイラーが再びオンになります。 このヒステリシス値は、加熱システムの慣性を考慮して経験的に選択されました。

気象モジュールの操作性を視覚的に示すため、温度測定サイクル間の遅延サブルーチンに点滅する内蔵LEDが追加されています。

ボイラーの動作モードの選択は、5分間の終わりに発生することに注意してください。 モジュールを初めてオンにしたとき、またはモジュールを再起動したとき、デフォルトモードは自動です。

実装

このアイデアを実装するために、手元にあるものを使用しました。 Arduinoモジュールを使用して天気モジュールを構築することが決定されました。 プロセッサボードがMega 2560になったため、これまでの実験の残りの部分。 このボードはこのタスクには明らかに冗長ですが、利用可能でした。 さらに、彼女のプロトタイプシールドがあり、その上に他のほとんどすべてのモジュールが配置されていました。 これは、リアルタイムクロックDS3231およびWiFiモジュールESP8266（01）です。 電気ボイラーとソーラーボイラーを別々に制御するために、2つのリレーを備えたスイッチングユニットが購入されました。

既存のコンピューターの電源が電源として使用されました。 ご存知のように、このようなブロックでは、二次供給電圧のかなり幅広い選択があります。 + 5Vがあり、ESP8266 WiFiモジュールを使用する場合は特に重要で、+ 3.3Vです。 さらに、これらのユニットは気象モジュールの連続性を考慮して非常に信頼性があります。



図は、回路基板の切り替えを示しています。 回路図は、その証拠を考慮して描かれていません。 図には、天気モジュールの動作モードを視覚的に示すRGB LEDがあります。 緑色はボイラーがオフであることを示し、赤色はソーラーボイラーを意味し、青色は電気を意味します。 私は手元に220オームの抵抗器を持っていなかったため、RGB LEDは電流制限抵抗器なしでボード出力に直接接続されていました。 私は自分が間違っていたと告白しますが、意識的にリスクを冒しました。 各LED出力の消費電流はわずか20 mAで、ボードの出力により最大40 mAを接続できます。 3年間の運用では、これまで問題はありませんでした。

温度センサーとしてDHT21（AM2301）が使用されました。 当初、家の中の温度を測定するためにDHT11センサーを使用していましたが、測定精度が非常に低く、不明な理由により、2つの異なるタイプのセンサーが回路で使用されたときにDTH.hライブラリが正しく機能しませんでした。 しかし、過度のエラーによるDHT11の置き換えは明らかだったため、ライブラリの問題には対処しませんでした。

四角の中の数字は、外部デバイスをメインボードに接続するワイヤの数を示しています。



回路全体は、配線に使用されるヒンジ付き金属シールドに組み立てられました。 そのようなケースの選択は、手元にあったものとも関連していました。

しかし、ここでは完全に予測可能な驚きが待っていました。 ドアを完全に閉じた状態で、シールドハウジングがWiFi信号をシールドしました。 別の適切な建物を探してすべてを再マウントする必要はなかったため、ドアを半開きにしておく必要がありました。 だから私はドアを開けて3年間住んでいます。

管理サーバー

監視と制御に使用されるWebサーバーは、純粋なPHPで記述され、適応レイアウトを備えています。 当初は、Android用のアプリケーションを作成するというアイデアがありましたが、サーバーが必要になるため、このアイデアを拒否しました。

承認後、情報を含むいくつかのページが利用可能になります。 これは、気象モジュールから最後に受信した要求、現在の時間の値の表、および任意の期間の要約情報のグラフィック表示によるシステムの現在の状態です。 天気モジュールを制御するための設定を選択できるページもあります。

この記事を書いている時点では、暖房シーズンが終了しているため、天気モジュールは既にオフになっています。 したがって、サイトのメインページのすべてのパラメーターは、シャットダウン時に関連しています。 気配りのある読者は、5月2日であることに気付くでしょう。





グラフの例として、値は2018年1月25日に表示されます。 棒グラフはボイラーの稼働時間を示しています。





パラメータ設定ページ



すでに述べたように、個人住宅の暖房システムを監視および制御するためのこのソリューションは、3つの暖房シーズンですでに機能しています。 この間、インターネットへのチャネルが長期にわたって消失したことによるハングは2つしかありませんでした。 さらに、天気モジュール全体がハングしたのではなく、ESP8266 WiFiモジュールのみがハングしました。

一般に、システムの機能は私に完全に合っていますが、使用するプラットフォームの明らかな冗長性を考慮して、拡張することを考えています。