イーサネットおよびタブレットをディスプレイデバイスとして使用する気象ステーション

はじめに

私は経験のある国内の気象観測所のユーザーであり、これは二重の災害です。 まず、私は家の内外の天気が私に知られているという事実に非常に慣れており、この情報がないと認知的不協和音の状態になります。 第二に、私は慢性的に気象観測所に不運です。 それらのうちの2つが故障し、あらゆる種類のインジケーターデバイスについて言うように、「天気を表示する」ようになりましたが、まったく逆で、天気だけではなく、何でも表示しました。 私はアメリカから3分の1を連れて来て、1年間忠実に奉仕し、ゆっくりとリラックスし始めましたが、両親が偶然に走り込んでしまいました（そして妻と私に一時的に肩を背負って家から逃げ出す機会を与えました）強制介護の攻撃により、窓を洗うという切実な欲求が生じました。 窓を徹底的にこすることの結果は、輝く窓だけでなく、飛び降りた気象ステーションのセンサーでもあります。 2階なので、センサーはほとんどクラッシュしませんでしたが、ご存知のように、各高層ビルの窓の下には目に見えない時空の特異点があります。 この現象が標準モデルの枠内で説明できるかどうかはわかりませんが、「落ちたものが失われる」という原則が特異性の基礎であることは間違いありません。 そのため、センサーが見つかりませんでした。

当然のことながら、デバイスを変更する必要性は完全に高まりましたが、「exe」のどれも私の家に1年以上滞在していなかったという考えは驚くべきものでした。 そして、「自分でやらなかった」という考えが頭に浮かんだ。



このようなイベントの開発には前提条件がありました。 技術教育は彼の強みを冷静に評価することを可能にしました、豊かなアマチュア無線の子供時代は、ソフトウェア部分だけでなく、少なくとも原始的な鉄片でも問題にならないように対処することが可能であるという希望を与えました。 さらに、購入したステーションとは異なり、自作のソリューションの保守性ははるかに高く、私は一般的にカスタマイズ性について沈黙しています。



当初は、家のさまざまな部分や外壁、中央ユニットに一定数の温度および湿度センサーを作成するというアイデアでした。 センサーはデータを取得して中央ユニットに送信する必要があり、中央ユニットはそれを視覚化する必要がありました。 副次的な機能として、統計を収集するためにイーサネットデータを既存のサーバーに送信する可能性（「どうだったか」を確認したい）と、その後のiPad、iPhone、Androidなどの電子機器のようなホームベースのガジェットへの転送を検討しました。



非常に迅速に（つまり、それほど高価ではないマイクロコントローラーと市販の周辺機器の機能を研究する段階で）、中央ユニットの視覚化のアイデアは消滅したため、サーバーに送信し、即興のデバイスの視覚化を続けてヘッドステータスを取得しました。

Arduinoは、このアイデアを実装するためのプラットフォームとして選ばれました。 理由：開発されたインフラストラクチャ、多くの例、販売中の多くのコンポーネント、価格（本物のArduinoではなく、中国のミラークローンについて話す場合）、アクセシビリティ（Ebayの利点は、あらゆる好みに見られます）。 原則として、むき出しのコントローラーにも同じことが実装できますが、テクノロジーを入力しただけなので、既存のエントリーしきい値を上げたくありませんでした。 唯一の気象センサーは美的なデバイスではありませんでしたが、壁に20 cmの直線サイズのcoをかけたくなかったので、Arduino Pro Miniがベースとして選択され、いくつかの印象的なUnoサイズではありませんでした。



したがって、概念的には、システムは4つの部分で構成されています。

• 気象センサー。 タスクは天気を測定し、データを無線で中央ユニットに送信することです
• 中央ユニット。 タスクは、気象データを受信し、HTTPでラップしてサーバーに投稿することです。
• サーバー タスクは、中央ユニットからデータを受信し、データベースに保存して、あらゆる種類の家庭用機器での視覚化に適した形式で転送することです。
• 視覚化デバイス。 タスクはユーザーに天気を表示することです

交換プロトコル

システムのコンポーネントの説明に進む前に、プロトコルと空中のデータ交換の原理について簡単に説明します。 無線交換は、 VirtualWireライブラリに基づいています。このライブラリには、マンチェスターコーディングやチェックサム検証などの「正しい」送信手段が既にあります。 パケット構造が固定されたマイクロプロトコルが、このライブラリの上に実装されました。 各パケットは、送信デバイスのアドレス（uint16）、センサーのタイプ（int16）、およびデータ（float）の3つのフィールドで構成されています。 追加のセキュリティ対策がサーバー側で実装されているため、パケットの長さをチェックすることを除いて、着信データの正確性に関する追加の検証はありません。 送信デバイスのアドレスは、デバイスがオンになったときに、以前に生成されていない場合はランダムに生成され、EEPROMに記録されます。 各デバイスには、さまざまなタイプのセンサーの多くの読み取り値を任意に送信する権利があります。 そのため、各気象センサーは2つのパケットを送信します-温度測定値と湿度測定値を持つパケット。

したがって、一般的なバストポロジを持つ無線ネットワークが編成されますが、衝突検出や配信保証などの高度な機能はありません。 2つのデバイスが同時にデータを送信しようとすると、衝突の結果としてデータが失われます。

マイクロプロトコルの実装は、送信と受信という2つの主要なメソッドを含む個別のライブラリで発行されました。 他のすべてのメソッドは、たとえば送信デバイスのアドレスを生成するために必要なサービスメソッドです。

気象センサー

天気センサーの作成は簡単に思えました。 既存のMK（これはArduino Pro Miniの一部としてATMega328であることを思い出します）で温度と湿度センサー（プロジェクトではDHT11でした）をフックし、433 MHz OOKトランスミッターをフックし、センサーからデータをポンプし、トランスミッターにアップロードするソフトウェアポンプを作成し、それだけですできた。 DHT11をArduinoに接続する方法については説明しません。この種の資料は、Habré（ http://habrahabr.ru/post/171525/、http://habrahabr.ru/post/184966/ ）を含めていっぱいです。 OOKトランスミッターを433 MHzで接続することも問題ではありません（ http://habrahabr.ru/post/210830/ ）。 Adafruit DHTライブラリは、データの取得に使用されます（ライブラリのセットは、 https ： //github.com/adafruitにあります ）。 コミュニケーションの編成には、説明されているマイクロプロトコルが使用されます。



完璧主義への渇望のためではないにしても、すべてがシンプルになります。 事実は、センサーはバッテリーで動作しなければならず、長時間動作するという信念は脳に根ざしているということです。 そして、ここで待ち伏せが行われました。Arduinoが元の状態で、アクションが取られなかった場合、約50mAを消費するためです。 一般的なAAAバッテリーの楽観的な容量は1200mAhです。 この食欲により、バッテリーのセットは24時間持続します。 すべてのセンサーのバッテリーを1日に1回交換するという考えは熱意を引き起こさなかったので、Atmelのコントローラーの省電力モードを研究して、すべてを試しました。 ソフトウェアのトリックに加えて、周辺機器、つまりDHT11とトランスミッターで何かをする必要がありました。 バッテリーが絶えず消耗しないように、+ 5Vを電源バスではなく、別のArduino脚に接続することにしました。 これにより、必要な場合にのみ周辺機器を含めることができます。 また、気象データを5分に1回以上送信するのは意味がないため、周辺機器も5分に1回、数秒間必要です。 仕様によると、ATmega328はピンを介して40mAを供給することができますが、一方で、トランスミッターの消費は30mA、DHT11の消費ははるかに少なく、同時に動作することはありません。センサーからのデータが最初に読み取られ、送信されます。 したがって、40mAで十分です。 要約すると、デバイスには3つのコンシューマーがあります。

1. 周辺機器（実質的には別のレッグから電源供給されます）
2. マイクロコントローラー自体（ここでは、省エネに対処する必要があります）
3. Arduinoボード上の不必要な周辺機器（たとえば、電源の存在を示すLED）

+ 6.5V ... 12Vから5VのLEDおよび電圧コンバーターは、Arduinoボード上にあり、12Vを超えて何かに電力を供給したい場合に必要です。センサーは3つのバッテリーから電力を供給されるため、すぐに切断されました。合計電圧が3.7V ... 5.1VのAAA（鮮度の程度による）であるため、降圧コンバーターは役に立ちません。 LEDは私にとっても役に立たない、とにかく誰もケースの中にそれを見ません。 万歳、手術により食欲がほぼ半分に減少しました-最大28mA。 しかし、これはまだたくさんあります。 測定時までに、周辺電源はすでにMKフットから供給されており、その時点でオフになっていたため、28mAがコントローラー自体の食欲であると結論付けられました。 ソフトウェアのみジャムできます。 多くの指示とマニュアルが読まれました。 この知識には最も多くの知識が含まれています。 省エネの試練をスキップすると、ウォッチドッグタイマーがトリガーされたときに終了する省エネモードSLEEP_MODE_PWR_DOWNを含めること、アナログ-デジタルコンバーターがオフになること、許容できない低電源電圧での動作モードの検出（いわゆるブラウンアウトモード）が最も助けになったと言えます。 私のリストの最初の2つのポイントだけを管理してエネルギー太った人を無酸素状態にした場合、消費量は約20uAになります。 これは元の28mAよりも1000倍小さく、原則としてそこで停止できますが、ATmega328データシートには、マイクロコントローラが何かでビジーでないとき、1uA未満しか消費できないと書かれています！

MCの内部では、電源電圧の低下に対するデバイスの応答が異なります。 そのため、供給電圧が低下すると、水晶の主要部分が動作し、一部のデバイスが正常に動作しない、不安定になる、または正常に動作しないという状況が発生する可能性があります。 このような鉄の不整合を回避するために、MCは電源電圧の臨界レベル以下の低下を検出し、完全にオフにすることができます。 ただし、この機能は判明したとおり、非常に大きなパワーを必要とします。 ブラウンアウトを無効にすると、マイクロアンペア電流を測定するモードの私の中国のマルチメータDT838は、何も感じないことを示しました。 ここにある！ 電流が1uA未満になったとは言えませんが、マイクロ電流計の感度しきい値よりも確実に小さくなりました。これは確かに20uA未満です。 測定の精度がそれ以上のトレーニングを許可しなかったため、結果を満足のいくものとみなし、エネルギー消費に関する研究を終了することが決定されました。

そのため、センサーが組み立てられ、コードが内部に縫い付けられます。これは、5分ごとにオンになり、残りの時間はディープスリープになる同じポンプを実装しています。 ブレッドボードでは、送信されたデータの受信機がホイップアップされました。 すべてがパワーアップされ、...省略記号の後、通常は予期しない叙事詩ファイルを書き込みますが、いや、すべてがスムーズに進み、テストレシーバーはデータを受信し始め、データは完全に適切に見えました：温度-25度、湿度-40％。 ほら、仲間！ ジョブが完了しました。 興味深いことに、フィールド条件に近い条件にデバイスを配置すること、つまり、送信機と受信機の間の距離を10cmから5mに増やすことが決定されました。 そして、ここで叙事詩ファイルは忍び寄った。 5mの距離での直接視界の条件では、受信機は何も登録しませんでした。 私はそのようなイベントの準備ができていて、何が起こっているのか知っていたと思いました。 事実は、その時点で受信機も送信機もアンテナを持っていなかったということです。 すべての規則に従って、1対の1/4波長アンテナが即座に測定され、切断されました（433MHzの場合、これは約17.5 cmのワイヤであることを思い出します）。 導体はアンテナと奇跡の代わりに密閉され、送信は完了しました！ 次のステップは、レシーバーとトランスミッターの間に厚さ375 mmのケイ酸塩壁を配置することにより、見通し線をなくすことです。 また、トラブル、伝送、つまりそうではありません。 デバイス、アンテナ、それらの形状、および内部の位置に合わせて踊る（撚り線、単芯、異なる絶縁体で（なぜ？））何にもつながりませんでした。 伝送速度を途方もない256 bpsに下げても、状況はそれほど改善しませんでした。 アンテナのブランド化を試みて、放射線物理学の分野での私の知識不足により、3人が放射線物理教育に携わりました。そのうちの1人は物理科学の候補者です。 すべての合唱団は、「アンテナはそれとは何の関係もない、これらの送信機は、信号が正しくエンコードされていれば、アンテナとして取り付けられたごみと一緒に動作し、おそらく10メートル以内に動作しないように何か特別なことをした」 。 VirtualWireがマンチェスターコードを使用し、その上に追加のチェックを加えているため、皮肉を噛み砕いてコーディングが正しいと主張したため、何か間違ったことをする可能性があると考え始めました。 一見明白に見えますが、欠陥のある送信機または受信機に出くわしたという信じられないほどの仮定をすべて破棄すると（5つのセットがあり、試してみましたが、結果は同じです）、1つのバージョンしかありませんでした-私は送信機を完成していません。 実験目的のために、MKフットから+ 5Vバスと送信機に送信機の電力を転送しました。受信機にデータがあります。 さらに、アンテナの位置、アンテナの構成、受信機と送信機が家のどこにあるかに関係なく、それらはそこにあります。 伝送を中断することができた唯一の状況は、送信機を鉄のキャップで覆うことでした（ただし、これはすでに「aaaaa」というシビア人の厳しい男性によるシリーズです）。 さらに、10秒間洗脳しました（以前にやったことがないのはなぜですか）。OOKトランスミッターは、何も送信しないときに何も食べないので、「外部」の方法でバッテリーを保護する意味がありません。 トランスミッターの電源がMKフットによって十分に供給されないバージョンの時間。 このテーマに関する理論を正式に確認したことはありませんが、オシロスコープはありません。オシロスコープはありません。正確に見つけることはおそらく不可能ですが、そのような有効な仮説です。 勇敢な中国人によって送信機に宣言された30mAは、何を意味してもかまいません。 たとえば、テストシーケンスを送信するときの平均消費量。 同時に、ユニットの転送中のピーク消費は、40mA以上を含め、何でもかまいません。 一方、MK出力用に宣言された40mAは正確に上限であり、それを超えると何も保証されないと確信しています。 そのため、トランスミッタのピーク消費量は、MKの能力を簡単に超える可能性があります。 センサーを設計する2週間（当初は数日が計画されていました）のうち、送信機の問題を解決するために時間の90％を費やしたことは注目に値します。

ささいな電気回路は次のようになります。





注意深い読者は、ファームウェアがDHTから読み取られたデータの修正を導入することを可能にしたことに気付くでしょう。 実際のところ、DHT11には多くの欠点があります。すなわち、整数度の精度、極端に低いキャリブレーション、測定から測定、およびセンサーからセンサーへの結果の再現性です。 そのため、近くに立っている2台のDHT11は2度の温度差を示すことがありますが、これは私には適していませんでした。 さらに、次の記事のトピックに目を向けると、私の家はボイラーで加熱されていると言います。ボイラーはその瞬間に手で制御されていました。 路上の状況に基づいて、目的のボイラー出力を設定します。 ほとんどすべての最新のボイラーには、少なくともオン/オフモードで制御する機能があります。 そのため、次のプロジェクトでは、通りや部屋で利用可能な温度データを使用して、室内環境をサーモスタットで制御します。 この目的のために、部屋の内部の温度をある程度の精度で測定することは非常に無礼です。そのような無礼は温度制御システムの自励振動につながります。 そのため、DHT11を、修正を必要としないはるかに高価なDHT22に置き換えることが決定されました（2つのDHT22、1箇所に立つと、読み取り値は10分の1度まで一致します）。

中央ユニット

そのため、気象データはオンエアで利用できます。 問題は、次に何をすべきかです。 そして、それらをキャッチし、HTTPでカプセル化し、既存のホームのサーバーに転送する必要があります。 これを行うために、中央ユニットにArduino Nano、433MHz超再生レシーバー、ENC28J60イーサネットモジュールを装備することにしました。 Proボードの代わりにNanoを使用するには、Nanoボードに3V3コンバーターが必要であり、ENC28J60は、情報ピンの+ 5Vの許容値にもかかわらず、3V3の電力を必要とします。

スキームは次のようになります。



ご覧のように、ENC28J60に加えて、回路には中央ユニットの位置の温度/湿度を取得するためのDHTセンサー（最終的にはDHT22）と、圧力の測定に使用されるBMP085センサーも含まれています。 ハードウェア実装の機能のうち、BMP085が異なり、センサー自体は3V3で駆動されることに注意する価値がありますが、組み込みの5V-> 3V3コンバーターで購入したため、両方の電圧で駆動できます。 Nanoの場合、独自のコンバーターがあるため、これは無関係ですが、Pro Miniを使用する場合は便利な機能になります。

ハードウェア部分に驚きはありませんでしたが、ソフトウェアには驚きました。 サプライズはイーサネットコントローラーに接続されています。 まず、ENC28J60は、イーサネットシールドで広く使用されているW5100とは異なり、TCP / IPハードウェア実装を含まず、スタックはプログラムで実装され、このチップで動作するライブラリを備えています。 第二に、コミュニティ体験全体はArduinoでのプリミティブHTTPサーバーの実装に集中していますが、私の仕事は、ArduinoをHTTP GETリクエストを介してサーバーにデータを送信する「ブラウザ」にすることです。 このようなブラウザを実装しようとすると、かなりの困難に直面しました。 イーサカードライブラリは必要なことを行うbrowseUrlメソッドを定義しているにもかかわらず、その動作は安定していません。 メソッド自体は、GET要求を生成するためのライブラリへの要求のみを意味します。 要求自体を実行するには、サーバーからデータを受信したときに呼び出されるコールバックメソッドを定義し、browseURLを呼び出した後、直接トラフィックをポンピングするpacketLoopメソッドを呼び出す必要があります。 したがって、理論的には、メッセージを送信する作業は、browseUrlへの単一の呼び出しと、要求をポンピングして応答を受信するpacketLoopへの複数の呼び出しの2つの段階で構成されます。 packetLoopを何回プルする必要があるかは完全に理解できません。 このメソッドはステータスを返しません。 入力は、パケットの長さを受け入れます。これは、packetReceiveメソッドを呼び出すことで決定できます。 私が最初に考えたのは、packetReceiveがゼロ以外を返すまでpacketReceiveとpacketLoopをプルすることでした。 ただし、まず、browseUrlを呼び出した直後に、多くのpacketReceive呼び出しがゼロを返します。 第二に、最初の非ゼロが出現した後、一連のゼロが移動し、再びゼロではなくなります。 サーバーからの回答は私には興味がないので、主な問題は、サーバーへのGETリクエストを取得するために必要な回数だけpacketLoopを呼び出すことです。反対方向の転送はスキップされます。 ここでコールバックが役立ちました。これは、データがENC28J60バッファに表示されるときにイーサカードが呼び出すものです。 最初の呼び出しを待って、サーバーへの転送が行われ、転送が反対方向に開始されたことを確認するだけで十分です。 その後、packetLoop呼び出しを終了できます。 問題は、コールバックがbrowseUrlの後に呼び出されない場合があり、その後packetLoop呼び出しのループで永久に呼び出される場合があることです。 この手順を時間に制限する必要がありました。 Arduinoが5秒以内にサーバーから応答を受信しない場合、現在の要求試行をスローします。 別の非常に不快な驚きは、時々送信されます（非常に不安定に再現されますが、確実に1日に1回発生します）タンデムENC28J60 /イーサカードは、何も送受信されない場合に安定状態になります。 MKを再起動することで処理されます。 そのため、転送に失敗した試行を検討し、それらが大量に蓄積した場合、コントローラーを強制的にオーバーロードする必要がありました。

これらすべてのトリックにより、中央ユニットは安定して動作します。私は現在、1か月間、その動作に干渉していません。





ご覧のとおり、DHT22は側面にぶら下がり、ケースに配置することはできません。さらに、ケース内に配置することはできません。デバイスは、温度センサーを配置するのに十分な少量の熱を生成するためです。例として、ケース内にあるBMP085センサーの温度測定値は、正しい値より2度安定しています。

サーバー側

後で表示する数字を保存するためのものを作成するときに頭に浮かぶ最初の考えは、おそらくこのホイールを発明しようとしている最初の人ではないでしょう。インターネットの簡単な調査は、ソリューションの範囲が「プログラマーのchtoliではなく、何から？」と非常に広いことを示しました。ここにあなたのVisualBasicがあり、それをプログラムし、ここで、ここで少し調整して、すべてが箱から出して動作します。真実は、いつものように、中間のどこかにあります。一方では、すべてを美しく行うためには、コードに徹底的に投資する必要があり、熱意を簡単に消すことができることは明らかです。一方、ボックス化されたソリューションは、彼らが望むものを決して実行しません、彼らはカスタマイズに欠けています。 Majordomo（smartliving.ru）という素晴らしいプロジェクトがあり、その目的はスマートホーム用のプラットフォームを作成することであるという事実に、私はゆっくりと導かれました。「なぜ十分に賢い気象観測所がスマートホームの一部ではないのですか？」私は考えて座って問題を研究しました。 Majordomo IMHOの美しさは、非常にシンプルで典型的なものが、少しカスタマイズしてすぐに使用できることです。しかし、何か気に入らない場合は、追加する（PHPによく開発されたスクリプトツールがあるため）か、書き直す（プラットフォームが開いている、ソースコードが利用できる）機会が常にあります。 Majordomoでサポートされているツールのうち、オブジェクトは有用であり、HTTPリクエストとホームページを介して外部から更新できるデータで、HTML / JS / CSSおよびその他のWebテクノロジー動物園で好きなものを描画してサポートできます。しかし、何か気に入らない場合は、追加する（PHPによく開発されたスクリプトツールがあるため）か、書き直す（プラットフォームが開いている、ソースコードが利用できる）機会が常にあります。 Majordomoでサポートされているツールのうち、オブジェクトは有用であり、HTTPリクエストとホームページを介して外部から更新できるデータで、HTML / JS / CSSおよびその他のWebテクノロジー動物園で好きなものを描画してサポートできます。しかし、何か気に入らない場合は、追加する（PHPによく開発されたスクリプトツールがあるため）か、書き直す（プラットフォームが開いている、ソースコードが利用できる）機会が常にあります。 Majordomoでサポートされているツールのうち、オブジェクトは有用であり、HTTPリクエストとホームページを介して外部から更新できるデータで、HTML / JS / CSSおよびその他のWebテクノロジー動物園で好きなものを描画してサポートできます。

Arduinoのセンサー用に、次の構造を持つオブジェクトの個別のクラスが編成されました



。DeviceIDは、マイクロプロトコルパケットに参加するデバイスのまさにアドレスです。残りのフィールドの説明は、それ自体を物語っています。作業のロジックは次のとおりです。

中央ユニットがデータを送信すると、このクラスのオブジェクトの中で、DeviceIDとSensorTypeが送信されたものと一致するものが検索されます。見つかったオブジェクトに対して、渡された値（microprotocolパケットのfloatフィールドの値）が設定され、UpdateTimeがNowに設定され、Actualが1に設定されます。中央ユニットまたはセンサー自体に何かが起こった場合、センサーは長時間更新されていないため、センサーは無関係です。そのようなセンサーがいくつかあります。



これらのセンサーの値は、ホームページを使用して視覚化されます。異なるページを使用して、異なるデータまたは同じデータを、異なるデバイスでの表示に最適化された形式で表示しました。

ディスプレイデバイス

かなりの量のほこりで覆われた古いDell Streak 5は、中央ディスプレイデバイスとして使用されました。[ディスプレイデバイスの選択を含む段落の記事の冒頭を参照]は、Arduinoに直接ねじ込まれた1.8または2.2インチスクリーンよりもはるかに有益です最大でテキストと8x8アイコンを表示できます。Dolphinブラウザを開始時に自動実行するようにセットアップされ、気象ページが開き、気象ステーションの準備が整った顔になりました（気象ステーションだけでなく、温度制御に関する今後の記事を再び発表します）。対応するMajordomoホームページのテキストでは、ブラウザーをフルスクリーンモードにし、アドレスバーやAndroidステータスバーなどの余分なものをすべて隠すトリックに頼らなければならなかったことに注意してください。

さらに、子供部屋の気候状況を監視するために、データは主に配偶者によってiPhoneおよびiPadで表示されます。

テスト、結論、計画

現在までに、システムは約1か月半稼働しています。 ENC28J60が完全にオフになっている（リンクLEDとアクティビティLEDが点灯しなかった）中央ユニットが2回ホバリングすることを除いて、特に不満はありません。数秒間、ユニットの電源を切ることで対処しました。この振る舞いの理由は、家の車内ネットワークの電気の質があまり良くないことが記録されていました。一瞬のうちに消えます。このような条件下で電子機器がどのように動作するかは不明です。この要因の影響を防ぐ手段として、1Fに2つのイオニスタ（5Vコントローラの電源用、イーサネットアダプタ用の3V3）を設置することが計画されていました。蓄電池をバッテリーの形で管理することは可能でしたが、はるかに高価です（イオニスタのコストは数十ルーブル、通常のバッテリーセットは500ドルかかりますが、それはおもしろくありません（バッテリーを何度も見ましたが、初めてイオン検出器を目にします）、目標を達成しません（目標はネットワーク内の短期の厄介な秒数の影響を防ぐことであり、電気がない状態でユニットに電力を供給しないためです） ）

結論では、腺のセットはそのタスクに対処し、次の方向に拡張するための準備ができていると書くことができます：

• センサーのネットワークを拡大します。セントラルユニットは、マイクロプロトコルを介して送信されたデータを受信できます。つまり、気象センサーだけでなく、想像することもできます。例：水道メーターと、明確な物理インターフェイスを備えた電力メーターへのインターフェイスモジュール-RS232およびまだ理解されていない通信プロトコル
• アクチュエータシステムの紹介

近い将来の概要は次のとおりです。

• ボイラーコントローラーは、気象センサーと一緒に、家の中に閉じた温度制御システムを形成します。プロトタイプはすでに作成されており、テスト中です。私はこの技術に別の記事を捧げることを約束します。
• 漏水検知モジュール付きの電気および水道メーターに言及