Arduinoの別のサーモスタット、ただしOpenThermを使用

見出しの最初の部分を読んでいる間、あなたの多くはおそらく考えました-長い間苦しんでいるArduinoの別のサーモスタット。 そして...それは本当です-はい、これは別のボイラー、別の家のための別のサーモスタットですが、真実は部分的にしかありません-私はデバイス自体に集中したくない記事では-それらは本当にたくさんあります（記事） もちろん、サーモスタットについて説明しますが、マイクロコントローラー自体をボイラーに接続する方法について詳しくお話したいと思います。 だから、誰が気に-してください...

すべての始まり

まず第一に、私はまったくプログラマーではなく、実際のマイクロコントローラーとは何の関係もなかったと言いたいです。 MK AVR（そして実際にはMK）を初めて知ったのは高校に戻ったときで、この不思議なことがどのように機能するかを知りたいと思いました。 私はいくつかの記事を読みましたが、それ以来、DDRとPORTという2つの単語で説明できる文章しか覚えていませんでした。 それから5年目の大学がありました。「プログラミングマイコン」で、私たち全員が仮想環境でMSC51と出会いました。 既に中断、タイマー、その他すべてがありました。 さて、このような豊富な知識により、私は問題に直面しました。 この自伝的ノートを終了し、さらに興味深い部分に進みます。



だから、実際には、サーモスタットの作成を開始したもの-ガスボイラーで自律暖房を設置した後、私は、多くのように、一般的な問題に遭遇しました-家の温度は外の天気に非常に依存していました-霜-アパートは寒いので、クーラントの温度を上げる必要がありますバッテリー、ウォームアップ-逆に。 タンバリンとのそのようなダンスはあまり私には似合いませんでした、なぜなら ボイラーの調整は、ドアの後ろに設置され、ドアが電子レンジで支えられており、その上にゴミの山が置かれているため、複雑でした。 さて、あなたは理解しています-卵の中の針、アヒルの中の卵など



この問題は非常に簡単に解決されました-OTCセンサー（外気温度補正）は、ボイラーに接続し、街路の温度に応じてクーラントの温度を自動的に調整できるようにします。 問題は解決されたように見えましたが、ボイラーのサービスマニュアル（Ferolli Domiproject C24D）を読むとすぐに私の希望が打ち砕かれました-このモデルの外部温度センサーの接続は提供されません。 それだけですか？ それだけです そして今、おそらく、終了することは可能ですが、夏にはコントロールボードが雷雨で燃え尽きてしまい、わかりにくい方法でサービスマンと話します（ボードは後で修理されました）OTCをボイラーに接続できるかどうかを尋ねましたか？ 彼は、外部サーモスタットを使用して接続すると答えました。 それは私の記憶に預けられましたが、寒い天気が始まる前に、それとまったく同じ問題に本当に集中しませんでした。



同じサービスマニュアルに目を通しましたが、すでにサーモスタットの接続方法を確認する目的で、「OpenThermコントローラー」が同じ端末に接続されていることに気付きました。 それから私は気づいた-ここにある！ 「OpenTherm Arduino」をGoogleで検索すると、再び気分を害しました。 メッセージモニターはありましたが、そうではありません-聞く必要はありません。何もありません-サーモスタットが必要です。



それから、記事habrahabr.ru/post/214257に出会いましたが 、その終わりは私を混乱させました-オシロスコープのない著者は、ボイラーをマイクロコントローラーに接続できませんでした。 そして、MKに精通した人が働かなかった場合、私は何をしようとするべきですか？！ Opentherm v2.2プロトコルの詳細な説明がインターネットで見つかりました。これは私の熱意をさらに冷やしました-プロトコルの物理レベルはやや洗練されました-ボイラーからのデータが現在のレベル（5-7mA-低、17-23mA-高）で送信される電流ループ、およびサーモスタットからボイラーまでの電圧レベル（<7V-低レベル、15-18V-高）、これにはペアリング回路が必要になります。私は電子機器に非常に近いです。 さらに、データはマンチェスターコードによって送信されました。



ただ一つの結論があります-気にしないで-ただ電子レンジと規範を動かしてください。 しかし、私は性格に1つの特徴があります-あなたがあなたの頭に何らかのアイデアを置くと、遅かれ早かれそれが実現します-はい、私はそれを忘れます（このアイデア）が、それでもどこにも行かないでしょうXBMCのメディアセンター、それに対するサテライト、DVBカード、その他多くの多くのもの）。 あなたは寝ていて、マンチェスターのコードを受け入れる方法についての計画がすでに頭の中で循環しています。



そこで、OT / +プロトコルの仕組みを簡単に説明します（OTの種類については、上記の記事で説明しています）。 デバイス間の通信は、要求と応答の形式で行われます。 イニシエーターはサーモスタットのみです。 1秒間に少なくとも1回要求を送信し、20〜800ミリ秒の応答を待ちます。 メッセージ自体は、1つの開始ビットと1つの停止ビットを持つ32ビットです。



MSG-TYPE-メッセージタイプ-サーモスタットの場合：

0x0-READ-DATA-データの読み取り。

0x1-WRITE-DATA-書き込み。

ボイラー用：

0x4-READ-ACK-読み取りを確認します（答えが入っています）。

0x5-WRITE-ACK-記録を確認します。

0x6-データ無効-データが正しくありません。

0x7-UNKNOWN-DATAID-そのようなDATA-IDはありません。



DATA-ID-パラメーターの識別子。 最初の128個は予約されており、それらのほとんどはすでに仕様で指定されており、残りの128個は各ベンダーがその裁量で使用しています。



DATA-VALUE-パラメーター値自体。 パラメーター自体に応じて、異なる形式になる場合があります。 2つの8ビットフラグ値、符号なし16ビット整数、固定小数点付き分数など パラメーターごとに、値のタイプが定義されています。



各OTデバイスに対して、パラメーターのセットが定義されています。これは必ずサポートする必要があります。

データID	説明	サーモスタット	ボイラー
0	デバイスステータスフラグ	DATA-VALUEフィールドの上位バイトに必要な機能を設定して、読み取り要求を送信する必要があります	DATA-VALUEフィールドの下位バイトにステータスビットを設定して、リクエストに応答する必要があります
1	希望のクーラント温度を設定する	希望の温度値で書き込み要求を送信する必要があります	必要な温度の設定の確認で応答する必要があります
3	ボイラー構成	パラメーターを読み取る必要があります	要求に応答し、応答で送信されるすべての機能をサポートする必要があります
14	最大火炎変調	オプションのパラメーター	実装する必要があります
17	現在の火炎変調レベル	オプションのパラメーター	実装する必要があります
25	クーラント温度	オプションのパラメーター	実装する必要があります

他のすべてのパラメーターに対する答えは、ボイラーの製造元の要求に応じています。



知らない人にとっての火炎変調とは何かを少し説明します。 最新のガスボイラーはすべて、炉内の火炎レベルを制御することができます-これは変調と呼ばれます。 バーナーの出力が大きいほど、熱媒体の加熱が速くなり、出力が大きすぎるとボイラーの常時オン/オフ（クロック）が少なくなり、設定温度に達することができなくなります。 ボイラーが停止せず、所定レベルのクーラントを維持するのに十分な強度で燃焼する最適な動作モードが考慮されます。



ご覧のとおり、すべてが非常に簡単です-実装を記述し、ボイラーの制御を取得します。 しかし、悪魔は、彼らが言うように、ささいなことにあります。 物理レベルを思い出してください-ボイラーからのデータは現在のレベルで、電圧レベルでボイラーに送信されます-これは電子工学に慣れていない人を混乱させます。 ボイラーを搭載していますか？ それでは、電圧を制御する方法は？ ボイラーからArduinoにワイヤを接続することはできません。 知っている人にとっては、答えは明らかです-これは電流ループであり、ペアリング回路は非常に簡単です。 私は真ん中のどこかにいるので、インターネットに登って、愛好家がOpenTherm Gatewayを作ったotgw.tclcode.comというサイトをPICで見つけました。 ペアリング回路がありました。 それは思えます-PICを取りますが、ところで-良い試み、怠iness、しかしいいえ-私はそれではなく、私のものが欲しいです。



それだけです-それを取り、集めてください。 その後、詳細とセット全体の価格を尋ね始めましたが、マンチェスターのコードという形でまだ障害がありました-それを受け入れるためにどちらの側に近づくべきかはわかりませんでした。 これが私の物語の次の部分の始まりです。

マンチェスターコード

Openthermプロトコルでは、マンチェスターコードを使用してデータを物理的に表します。または、Bi-Phase L.仕様で呼ばれています。



実際には、ここにあります：







全体のポイントは、ビットが信号レベルではなく、期間中のレベル間の遷移によってエンコードされることです。







さらに、この同じ遷移は、期間の真ん中に正確には発生しませんが、どこかで発生します：







ご覧のとおり、期間自体は1ms -10％+ 15％であり、移行はその中間にあります。



これは私が長い間停止した場所です。 インターネットから何かをコピーしたいという欲求はありませんでした。 各プロジェクトには独自のつまずきがあり、あなたは単にライブラリの考えのないコピー・ペーストリストであるだけでなく、このプロジェクトを行う開発者だと感じていると判断しました。 これは実際、サーモスタットの心臓部です。OTと連携して、それをコピーするということは、デザイナーから別のおもちゃを組み立てることを意味し、独自の何かを作成することを意味しません。



ここで、割り込みとタイマーなど、MKについての私のわずかな知識をすべて適用したかったのです。 はい、遅延（）ですべてがはるかに簡単になりますが、まず、遅延（）を使用して受信するには送信が遅すぎますが、受信/送信中に他のアクションを並行して実行したいと思いました。すべてがまともで、男子生徒の工芸品ではありませんでした。



まさにその変化を捉えることがどれほど美しいか、それが前線か後退かを問わず、それを別の角度から見るとすぐにすべてが明確になりました。 結局、期間の前半のレベルはビットの望ましい値です：







最初のステップがあります-期間の前半（開始後250μs）のレベルを取得する-それがすべてデコードです。 しかし、ここでは次の失望が待っていました-期間の始まりをキャッチすることは常に可能というわけではありません：01または10の組み合わせがある場合、期間の間に顕著なものは何も起こりません。 明らかに、レベルは変更されません-さらに調べる必要があります。 そして、ここに2番目の啓示があります-期間の途中で常に遷移があります-それらは0と1にエンコードされます。したがって、それにアタッチすることができ、次のビットの値は期間の半分になります！ ここで、すべてが完全に明らかになりました。



すでにいくつかのビットを受け入れており、最初の期間のちょうど中間に位置していることを想像してください。







入力信号の変化で割り込みを有効にするだけです。 これが起こるとすぐに、それはまさに私たちが期間の真ん中にいることを意味します。 信号の変更時に割り込みをオフにし、タイマーをリセットし、タイマー割り込みがトリガーされたときに、3/4周期後（OTの場合は750 µs）にタイマー割り込みを発生させ、入力レベルを記録し、タイマー割り込みを無効にします。残りのすべてのビットについて、もう一度繰り返します。



最初のケースは特別なケースになります。なぜなら、 彼のレベルが3/4ではなく、1/4の期間になるのを待ちます



割り込みハンドラーはすぐにスケッチされ、ファームウェアが組み立てられましたが、オシロスコープと信号発生器なしでどのようにデバッグできますか？ 知識が大学から救い出されました-プロテウスでは、何が起こっているかを段階的に見ることができます。



私は見つけて、インストールし、ここにすべての練習の魅力がありました-割り込みをオンにする前に割り込みフラグを強制的に削除する必要があり、タイマーモードをFastPWMからCTCに変更する前にOCR2A / Bをロードすると、「このようなクールなスラリーが発生しました」プログラムで、しかしそれが鉄で判明したように、まだもっと楽しいです）。 さて、すぐに決定したその他のささいなこと。 この段階では鉄がなく、サーモスタットに特定の要件を設けていなかったことを思い出させてください。



マンチェスターコードを受信するコードフラグメントを次に示します。

inline void OpenTherm::receive(){ cli(); first=1;//receiving first bit buf=0;//clear buffer rx=1; data_ready=0; length=0; parity=0; PCICR|=bit(rx_pcie); //enabling Pin Change Interrupt for RX port *rx_pcmsk|=rx_bitmask; //enabling Pin Change Interrupt for RX pin of rx Port TCCR2A=bit(WGM21);//mode CTC TCCR2B=0; OCR2A=TICKS_PER_MS*0.75;//interrupt at 0.75ms TCNT2=TICKS_PER_MS*0.5;//preload 0.5ms TIMSK2=bit(OCIE2A);//interrupt on OC0A TIFR2=bit(OCF2A); sei(); bool OpenTherm::extIntHandler(){ *rx_pcmsk&=~rx_bitmask; //Disable PCINT for RX pin if (first) { first=0; } else{ TCNT2=0; } if (length > MSG_LENGTH){ data_ready=1; TCCR2B=0;//disable Timer2 TIMSK2=0; return 1; } else TCCR2B=bit(CS22); //start timer clk/64 return 0; }; void OpenTherm::timer2CompAHandler(){ uint32_t tmp_buf; tmp_buf=buf; tmp_buf=tmp_buf<<1; if (rx) { if (*rx_port & rx_bitmask) { //Reading RX value tmp_buf=tmp_buf | 1; if (length > 1 ) parity^=1; //Don't calculate parity for start bit } *rx_pcmsk|=rx_bitmask; //Re-enabling PCINT for RX pin TCCR2B=0; //stop Timer2 } length++; buf=tmp_buf; }; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

転送は、後で、完全に論理的かつ実際的に同じハンドラーに適合します。



タイマー2はすべて同じCTCモードで動作し、ミリ秒ごとにゼロ化されますゼロ化割り込みハンドラー（CTCモードのOC2A）では、次のビットに従って出力を切り替えます。 さらに、OC2B割り込みがアクティブになります。これは、正確に半周期（0.5ミリ秒）トリガーされ、出力状態を反転します。 それが転送のすべての知恵です。



ここでインターフェイス回路を組み立てて、3時間でその動作の原理を見つけました。これは非常に単純であることが判明し、回路を少し変更して、元のようにデータを反転ではなく直接送信しました。







さらに、信号発生器をHDLに書き込む必要がありました（書き込み方法、インターネットから取得して自分で変更する方法）。 マンチェスターコードで34ビットを手動でダイヤルします。これは4または5ではありません。



最後に、受信/送信が確立され、必要な機器を決定する時が来ました。

装備品

そのため、エミュレータで動作するマンチェスターコードでOTメッセージを送受信するためのボイラー（Ferolli Domiproject C24D）とファームウェアがありました。 次のステップに進みましょう。



まず、Arduinoのほぼすべてのデバイスに必要なものは何ですか？ Arduino自体ですか？ 間違った！ エンコーダーであり、常にボタンが付いています 私はいつもこのタイプの入力デバイスに常に惹かれているだけです。ぜひ試してみてください。



次に、サーモスタットは内部と外部の温度を取得する必要があります-これらの目的のために、2つのDS18B20センサーが非常に適しています。1つは熱い接着剤で満たされ、外側に置かれます。 当然、ディスプレイが必要です。ディスプレイがなければ、ラジオコンポーネントをjarに注いで、Silpoパッケージに包んで防ぐことができます-効果は同じです。 標準の文字生成LCD 20 * 4を使用することにしました-これで十分です、LCD用のI2Cポートエクスパンダー。 コントローラー自体は、Arduino Nanoで十分です（今度はプログラマーと一緒にPro Miniを使用しますが、その理由を説明します）。 さて、インターフェイス回路のいくつかの詳細。



タイトルの写真からわかるように、何かがおかしかった。 売り手はすべてに対して非常に魅力的な価格を持っていたので、リストを少し変更することにしました。 2つのDS18B20の代わりに、1つを防水ケース+ DHT22に入れたので、部屋の湿度を上げることができるようになりました。 LCD 20 * 4は利用できず、Nokia 5110からディスプレイを取りましたが、ボタン付きのエンコーダーがなかったので、通常の+ 2ボタンを取りました。



受領後、すべてがはんだ付けされ、テストケースでテストされました。 まず、LEDを点滅させます（Arduinoボードを最初にオンにしたときにわかりますが、これは神聖です）。 すべてが期待どおりに機能したため、改善を開始できます。

Atmega 328にハードウェアSPIが存在するにもかかわらず、私はそれを放棄することにしました。 彼によって課された制限は私にはあまり喜ばれませんでした-MISOは自動的に入力用に設定され、SS-出力である必要があります-2つの出力を引いたため、ソフトウェアSPIを残します。 ライブラリからCEディスプレイ出力コントロールを削除し、LCDのGNDに直接接続します。 私は得る-のようなもの：







Proteusでインターフェイス回路を配布し、ブレッドボードで同様のことを繰り返します。







ワイヤーの端には、標準のボイラーターミナルブロックがあります。これは非常に便利であることが判明しました。ツールを使用せずにカバーを外すことなく接続および切断できます。



さて、これでプリミティブファームウェアを作成し、ボイラーとの通信を試すことができます。 私は書いて、点滅して、接続しています...



ボイラーは正常に機能し、記事を閉じることができます。

Trollface.jpg



当然、何も機能しません。

インターフェイスカードでテスターを突く-それは動作しません-入力は常に20Vです。 私は分解し、見て、そして笑います。 私は友人に支払いをはんだ付けしました。 私はすぐに対話を思い出しました。



-じゃあ、もっともっと？

-いいえ、ほぼ完了しました。 今、この長いトラックをはんだ付けし、それだけです。 主なことは、次にこれら2つの隣接する連絡先を接続することを忘れないことです。



初めて忘れたと思う？



そのため、「製品」は修正され、接続され、確認されます。 レベルは正常で、コントローラーを接続できます。 接続-沈黙。 すべてが到着しました。 オシロスコープなしでやることはありません。 私は最初の記事の著者として終わります。 しかし、まだ少しの希望があります。



受信に関する部分、つまり、期間の途中でタイマーをレベル変更にリセットすることを思い出します。 突然ゼロになるのは十分ではなく、着信信号のタイミングは一般に災害であると思います。つまり、レベルの4分の1のレベルを読み取る瞬間にそれをオフにし、ゼロからオンにすることを意味します。 それはその勝利でした-以前もMKと話をせずに、インターネットで見つけられなかったライブラリをゼロから書き、さらにオシロスコープなしで2度目に動作するようにしました。 私の喜びは際限がありません。



幸福感から少し離れて、新しいパラメーターを読み取る必要があるたびにコントローラーをフラッシュする（サイクル内のテストファームウェアが同じパラメーターを1秒に1回読み取る）ことは、おそらくユーザーフレンドリーではないため、続行する必要があることに気付きました。



パラメータ値を取得する方法を学びました。この形式でのみ、サーモスタットではなく、リモートディスプレイです。 これが必要なものになるためには、ボイラーを制御する方法を学ぶ必要があり、ここでも私は驚きを待っていました。

OpenThermのデバッグと操作

したがって、最初の値-ボイラーのステータス-が受信されます。 すぐに私を混乱させたのは、ボイラーパネルの設定に関係なく、マイクロコントローラーを接続するときの温水温度がすぐに最大許容値になったことでした。メーカー（Ferolli Romeo W）の標準OTサーモスタットのマニュアルを後で読んだとき：接続すると、ハンドルのみが機能します対応する機能を有効/無効にし、他には影響しません。 DHW温度パラメーターの値はOT接続前と同じままであると仮定することは論理的でしたが、Honeywellプログラマー（ボードの製造元とボイラーの自動化の残りの部分）はこの問題について独自の意見を持っています。



ボイラーを制御するプロセスは、正しいメッセージのシーケンスを見るために手にサーモスタットを持っていなかったという事実によって複雑になったため、目隠しに似ていました。 仕様では、明らかに、給湯の温度に関与していたDHWセットポイントパラメーターが見つかりました（以下、括弧内に呼び出されたパラメーターのDATA-ID、この場合は56を示します）。 撮影中、点滅中-ボタンをクリックすると、希望の温度が送信されました。 確認してください。 水温はすぐに正常になりました。CHSetpoint（1）-加熱回路の温度-すべてが開始された調整を開始します。 ここで私は3日間、長い間立ち往生しています。 どのように試しても、必要な温度が何であっても、ボイラーはそれを約30度に保ちました。 製造業者は他の人のサーモスタットの接続から自分自身を保護するという考えをすでに持っていました-唯一の明らかな決定は、ボイラーからメンバーIDを取得し（3）同じ答えをすることでした（2）。 そしてこれも助けにはならず、友人に状況を簡単に概説し、彼は仮定を持っていました：

-あるベンダーがマスター（サーモスタット）デバイスとスレーブ（ボイラー）デバイスに異なるメンバーIDを使用している場合はどうでしょうか。 ボイラーの自動化が別のボイラーによって制御されていることに気付いたときに、ボイラーの自動化がどのように驚くかを数えますか



しかし、すべてがはるかに単純であることが判明しました。 パラメータMax CH Setpoint（57）-加熱回路の最高温度にありました。 DHW回線でのイベントの後、最大値があると仮定することは論理的でしたが、いいえ、30度の値がそこに設定されました。 その後、物事は著しく楽しくなりました。

これが、サーモスタット自体の物語の始まりです。

サーモスタット

明らかに、ボイラーのパラメーターを大量に提供し、それらを変更できる必要があります。これがないと、別のサーモスタットを作成しても意味がありません。 すでに述べたように、各リクエストはおよそ1秒に1回送信する必要があります。最も論理的なのは、サイクルごとに1つの状態から別の状態に移行する有限状態マシンを記述することでした。 最終的に、オートマトンのブランチは次のようになりました3

1.ボイラーの現在の状態、温度、および変調レベルが調査される作業ブランチ。 つまり、次のように表すことができます。







2.情報およびボイラー分岐：追加の温度センサー、流量センサーなど。 [情報]メニューを終了すると、最初のブランチに戻ります。

3.統計のブランチ：バーナーの稼働時間、ファン/ポンプの始動回数など。 終了時、段落2と同じ。



パラメーターなしのupdate（）関数の呼び出しは、このすべての作業を担当します。 1秒間に約1回呼び出すだけで十分です。 彼女は前のリクエストの結果を受け取り、それに基づいて新しいリクエストを送信します。 ブランチを切り替えるには、目的のブランチの最初のパラメーターに等しいパラメーターで関数を呼び出す必要があります。 たとえば、更新（0）はメインブランチ（0-ボイラーステータスの要求）、更新（18）-パラメーター18（加熱回路の圧力の要求）で始まる2番目のブランチ、ブランチ3-パラメーター116（バーナーの開始数）に進みます。



他の引数値もあります。

1-加熱回路の新しい温度を記録します。

56-DHW回路の新しい温度などを記録します。



可能なすべての引数は、更新関数の最後に表示されます。



それで、すべての必要なパラメータが取得されましたが、軟膏にハエがありました-覚えておいて、私はテーブルの後に書いた-ボイラーメーカーのリクエストで他のすべてのパラメータ？ だから-それらの半分は私のボイラーでゼロであり、半分はまったく知られていない。 少なくとも誰かに役立つかもしれないが、彼は無駄にしか書いていない。



最も日常的で退屈な職業は、明らかにメニューを書くことでした。 約束どおり、サーモスタット自体については詳しく説明しません。すべては最終ファームウェアで見ることができます

この記事の執筆中に最後に追加したのは、「たくさんの文字」を含む退屈な画面ではなく、グラフィックディスプレイ（モデルに似たもの-ロミオW）のように見えました。 さて、時計-アパートにはそれらの多くはなく、RTC DS323xだけが欠落しています-電源を切ると、時間を再設定する必要があります。 これを行うには、いくつかの文字を手動で描画し、フォントに追加する必要がありました。 結果はヘッダーの下の写真で確認できます。









長い間、私は、PIレギュレーターになることが判明するまで、冷却剤の必要な温度を計算する式を変えていました。設定では、係数の変更と積分成分の表示を追加しました。 PIコントローラー自体の前に、必要な温度を計算するために、最初の記事から式を取りましたが、積分成分がないと、温度は必要なものに対応しなかったか、大きな比例係数で必要なものに対応せず、前後にジャンプしました。しかし、Habrを読むと、実装されたPIDコントローラーの説明へのリンクがすぐにわかりました。



一般に、2つの動作モードを作成しました



。1）CHセットポイントの直接制御-結果はボイラーのリモートフロントパネルにすぎません（さらに、外部/内部の温度と湿度も表示されます）。

2）実際にOTCを備えたサーモスタット。



おそらく、OTCセンサーをオフにして曲線の傾きを調整することも追加します（係数（（settings.indoor_target_temp-ext_temp）で））が、この点はまだわかりません。



OTCセンサーの配置について少し説明します。私は窓や壁に穴を開けたくありませんでしたが、この問題を考えると、誤ってMIDIコネクターの古いループに目を向けました。考え直さずに、センサーワイヤーをはんだ付けし、ホットメルト接着剤で接続を密封しました（路上にあるため）。直射日光によって加熱されないように、センサー自体をエアコンの外部ユニットの後ろの日陰に設置しました。

省エネ

コードをもう少し注意深く見ていた人は、おそらく未知のPowerライブラリに気づいたでしょう。実際、デバイス全体のエネルギー消費を削減することを期待していました。ポイントは、メインループの遅延（1000）ではなく、MKを1秒間スリープ状態にすることです。問題は、Timer2を実行してOpenThermメッセージを送受信するための特定のスリープモードが必要なことです。覚えているように、それらは非同期に発生します。しかし、残念ながら、ProteusはSleepではうまく機能せず、この部分をデバッグできませんでした。スリープは機能しており、ミリ秒（）の読み取り値は修正されています（このため、ウォッチドッグタイマーの精度の測定を実装しました）が、OTは機能しなくなります。この目的のために、Pro Miniを購入しました（その後、スタビライザーとLEDを取り外しました）-より小さなボード+ 3.3Vの動作が可能です。これにより、OTインターフェースから直接電源を供給できます。 Powerライブラリコードを持ち込み、興味がある人のために：







, – , , :







– . , :







– , . , 3D-, , , . , :



— , ?

— ?

— , , , – .



:









, , , update(), , communicate() — complete() —

参照資料

github.com/gavrilov-i/OpenTherm

habrahabr.ru/post/214257

otgw.tclcode.com

www.domoticaforum.eu/uploaded/Ard%20M/Opentherm%20Protocol%20v2-2.pdf



PS , , – — , . , .. , OpenTherm, .

PPS , . , — +5, TX ( ), RX ( ) — 1,5, GND.

:

— , . RX ( . ) TX ( R3) +5. 20. R3 — 7 ( 5). , . .