トラブルシューティング

ブラウザからコピペ（範囲選択してコピー操作を行い、そのままArduino編集画面に貼り付け）していませんか。
OS（パソコン動作の基本を担うベースとなるソフトで、WindowsやMacOS、androidと呼ばれているもの）とブラウザ（Microsoft Edgeやchrome、Safariなどと呼ばれるインターネットを表示させるソフト）の文字制御の仕組みの違い（非互換）のため、文字化けすることがあります。
上記の例では、ダブルクォーテーション記号が同記号と酷似した別の記号に置き換わってしまった例で、他には半角スペースが全角スペースに置換された、半角記号全てが全角記号に置換された例などを確認しています。
似ている文字や全角記号／半角記号の違いでも、コンピュータでは別のものとして扱われるため、エラーとなります。
各プログラムの説明文に書かれているダウンロードリンクからダウンロードしたプログラムを使用してください。

プログラムの書き込みは、副MCUに対して行われます。
主MCUと副MCUは、UARTという通信手法を使って互いに電文（パケットのようなものとお考えください）の交換をしながら動作しているのですが、USBからのプログラム転送もUARTで行っています。
そのため、副MCUの転送先をジャンパピンによって主MCUとUSBコントローラを切り替えています。

電力不足などが原因で書き込みに失敗することがあります。
USBハブを使用せず、直接パソコンに接続してください。

乾電池駆動（停電モードでの動作）では、２分に一度、２０秒間しか副MCUの電源が入らないため、プログラムを書き込むことができません。
僻地の山小屋等で、どうしてもACアダプタの入手ができない場合、乾電池を入れ直して通電後、約２分待ってから書き込み操作をしてください。
但し、水晶振動子（クオーツ）で正確に計時しているわけではないため、120秒でも若干の誤差があることや、電文の受付時間が短いことから根気よく何度も書き込み操作を行う必要があります。

主MCUから副MCUに電文を送信してから30秒以内に返事をしないと、フリーズしたと判断して自動リセットを掛けます。
これをウォッチドッグタイマーと言います。
ジャンパーピンを書き込みモードに切り替えても、副MCUの電源制御は書き込みとは別の処理として主MCUで動作しているため、強制的に電源が切られます。
DCジャックから電源をはずして差し直し、５秒程度経過してからプログラム書き込み操作をしてください。

パソコンからプログラムの書き込み操作をしても、すぐには書き込み開始しません。
プログラムの書き込みを行う際、まず最初に人の目で読み取れるテキストベースのプログラムコードを、マイコンが認識できるバイナリーに変換するプロセスを踏みます。
これをコンパイルといいますが、パソコンの性能や使用する開発ソフト、プログラムサイズによって差はありますが、数十秒から数分、不利な条件が重なると10分近くかかるケースもあります。
H10は、主MCUから30秒間応答がないと、自動的に副MCUをリセット（電源を再投入）する設計となっております。
このため、コンパイル中に副MCUにリセットがかかってしまうことで、プログラムの転送ができなくなっています。
これを回避するには、プログラム開発ソフトの画面を注視し、どの段階がコンパイルで、どこからが転送を試みようとしているか判断し、プログラムの転送が始まったタイミングでACアダプタをDCジャックに差し込みます。
Arduinoをお使いの場合、以下の画面が表示されたらACアダプタをDCジャックに差し込むタイミングです。

H10を買い替えたり、パソコンを買い替えた、デスクトップパソコンなどで制御系統（USBコントローラチップ）の異なるUSB端子に挿し替えた場合は、COMポートの番号が変わることが多いです。
デバイスマネージャーでCOMポートの番号を確認したり、Arduinoソフトウェアの[ツール]->[シリアルポート]で選択できるポート番号が増えていないか確認して正しいCOMポート番号を選び直してください。

ジャンパピンを元に戻さないと、主MCUと通信ができないので、動作しません。

例えば、夏場に室温が25度を超えたら換気扇を回すようにプログラムしたとします。
室温が25度以上の状態から徐々に下がっていき、25度を切ったら、リレーがOFFになり、換気扇への通電を止めます。
しかし、換気扇が止まった瞬間から再び室温が上がり始めます。
すると、1秒後に行われる次の測定で、25度以上を測定することで、リレーをONにしてしまいます。
これが繰り返されることで、リレーのONとOFFを頻繁に繰り返します。
これを防ぐためには、以下のように作ります。

（１）リレー制御のタイミングを１分ごとにする。
主MCUから副MCUに約１秒ごとに送られる電文の31バイト目は、通常250が送信されますが、約1分ごとに255が送信されます。
副MCUで255を受け取ったタイミングでのみ、リレー制御を行うようにプログラムしてください。

（２）ONとOFFの閾値を分けて考える。
たとえば、

とした場合、25度を少しでも超えたらリレーがONになり、少しでも下回ったらOFFになるため、境界付近の温度の時、頻繁にリレーのONとOFFを繰り返します。
通常このような時、季節が変わるまで（換気扇がないと部屋の温度が上がり続ける条件が維持され続ける限り）ずっと数秒おきにON/OFFを繰り返します。
これを避けるため、

このように、ONにする条件とOFFにする条件を分けます。
27度以上になったらONにして、22度以下になったらOFFにするという制御を行っています。

以上の（１）と（２）を組み合わせることで、リレー動作は落ち着きます。

その他、おもしろい失敗例としては、暗くなったことを検知して照明をONにするというプログラムで、夕方頃に電球がつながっているリレーがONになった1秒後にその電球の明るさを検知してリレーがOFFになるという動作を延々と繰り返した例もあります。

DCジャックにACアダプタを差し込んだ直後は、電圧が安定せず、加えて起動処理をしていることもあるため、すぐに処理を始めることはできません。
また、電気的ノイズが通信線に流れ込むこともあります。
その場合、誤ったデジタルデータとして扱われるため、フリーズすることがあります。
電源を入れてから１時間の節目ごとにフリーズする原因は、１時間ごとに主MCUから副MCUをリセットしているためです。
これを防ぐためには、システムが安定するまで待つ処理を入れます。
一般的なマイコン（MCU）であれば、0.5秒程度待てば十分ですが、副MCUとして採用しているマイコンはWiFiやbluetoothなどのワイヤレストランスミッターを搭載しているため瞬間的に流れる電力が非常に大きく、高機能であるため起動に時間がかかります。
安全を見て、２秒程度お待ちいただくことをおすすめいたします。
加えて、万一電気的ノイズが通信線（UART）に流れ込んでも、デジタルデータとして扱われないように、内容を消去してから主処理ループ（void loopの中の処理）に移るように作ります。

上記のプログラムでは、１行目の通り電源投入時に一度だけ実行されるプログラムグループの中で、２行目で２秒間待つ処理をしています。
３行目で通信線をONにして、４〜６行目で受信内容を消しています。
「Serial.available() >= 1」は、「受信バッファに１バイトでもデータが存在するならば」という意味です。
whileは、（）内の条件が継続している限り、{ } 内の処理を繰り返しなさいという意味です。
つまり、電源投入直後に受信バッファの中身をチェックして、ゴミデータがあれば、それがなくなるまでずっと受信処理を繰り返すことで、きれいな状態にします。

臭気（におい）センサーは最低でも３日、安心して測定値として採用できる状態になるまでは１週間程度連続動作させる必要があります。
特に使いはじめの頃は数百程度のとても低い値が出力され、１週間が経過する頃には３月の晴れた屋外で3000以上の値になります。
気温や湿度によっても誤差が生じます。
運用して日が経っていても、電源を切って時間が経っている場合、本来の値が出るまで数時間かかることがあります。
また、夏場は実際よりも数百程度低く出力されます。
においセンサーは、においの強さと値は反比例します。
使い始めも、夏場も、しばらく電源を切られた際も、共通して値が小さく出るため、10分間の移動平均量を取り、急激に値が下がったらにおいが発生したとみなす処理にすることをお勧めします。

H10に搭載されている臭気（におい）センサーと二酸化炭素センサー、一酸化炭素センサーは、触媒を加熱して成分を抽出する性質上、熱を伴います。
極端に通気の悪い場所に設置したり、温度センサーが熱を持つセンサーの真上になるような角度で設置した場合、センサーの熱が温度センサーに伝わることで高く表示されます。
このような場合、ファンで風を送るか通気の良い場所に設置し直してください。
実際に温度を測定して、その誤差を副MCUのプログラムで吸収する（オフセットを取る）ことも有効です。

１時間ごとに主MCUから副MCUをリセットしているためです。
WiFi使用時に、不測の事態により接続が切れてしまうと初心者の方には接続の回復処理をプログラミングするのは困難です。
そのため、万一このような状況になっても１時間ごとに再接続の機会が提供できるよう、副MCUにつながる電源線を主MCUから強制的にOFFにして再度ONにすることで再起動させています。

サンプルプログラムでご紹介した「int」で宣言して扱うことができる数は、32767までの「整数」です。
小数点は扱えません。
intで宣言すれば、どんな数でも扱えるというわけではありません。
扱う数や数の性質で、宣言に使うプログラムは異なります。
詳しくは「C言語 変数 型」で検索してみてください。

STAGEA H10は、プログラミング初心者が使うことも想定して作られております。
不安定なプログラムで使用すると、フリーズした時に回復する手段がなく、山岳部の別荘等など無人で運用した場合、見守りができなくなる危険があります。
そのため、主MCUから１時間ごとにシステムリセットを掛けています。
その際、リレーが一旦OFFに戻ります。

インターネット接続機能のある副MCUは非常に消費電力が高いため、乾電池で長期間動作できるよう、停電時は２分に一回２０秒程度しか通電しません。
そのうち前半の１０秒はWiFi接続処理を行うことを想定しておりますので、電源投入後１０秒が経過してから時報（250）が送信されます。
接続先のクラウドサービスやサーバーの負荷が高かったり、WiFiの接続処理がスムーズにいかなかった場合、時間内に処理を終わらすことができないため、アップロードに失敗します。
クラウドサービスは、特に負荷が高くなりやすいので、普段はクラウドサービスを使用していても、停電時は制作例（１）のようなCGIに値を渡すだけのような負荷の軽い方法でデータをアップロードしたり、主MCUから時報データ（250）が送られてくるのを待つことなく、先に返事をすることも方法の一つです。（時報が送られてくるのを待たずに返事をした場合でも正常に動作します。）
詳しくは、[プログラミング・リファレンス]をご覧ください。

クラウドの負荷が高くてデータが登録されない場合があります。
この場合、正しくプログラムしていて、転送完了画面が表示されているにもかかわらず意図した通りの動作をしないので、迷宮入りするケースとなります。
時間を空けて再度お試しいただくか、制作例（１）のCGIに登録するサンプルをお試しいただく、またはほかのクラウドで正しく動作するかお試しください。

センサーの制御は非常に複雑であることに加えて、信号タイミングを誤ると触媒が焼損（故障）するセンサーも含まれており、主MCUのプログラムを変えることはお勧めしていません。
上級者の方であればファームウェアの変更は可能な状態になっておりますが、変更を行った場合弊社のサポートや補償はなくなることをご了承ください。

クラウドのアップロード上限数を超えると、STAGEA H10からアップロードしてもデータに反映されないことがあります。
例えばサンプルコードとしてご紹介したAmbientの場合、1日のアップロード上限数は3000となります。
それを超えた場合、STAGEA H10での処理では正しく動くはずなのに、データが登録されません。
IoTクラウドによっては、データが上限を超えた場合、エラーコードを返すものもありますので、サービスガイドなどをご覧ください。

本機で使用されているWiFiトランスミッターに、相性があることを確認しています。
一部の海外製アクセスポイントでは、一度で接続ができず、STAGEA H10のウオッチドッグタイマー（30秒間、副MCUから応答がなければ強制リセットを掛ける）処理が行われたタイミングでやっとつながる現象を確認しております。
iPhone8とiPhoneSE（第2世代）では、一度で素早く接続されることを確認しております。
相性が悪いと感じた場合は、周波数帯や通信規格（802.11a/b/g/n）を変えてお試しください。

コントラストを調整します。
液晶画面のすぐ下にある調整ツマミを廻すと調整できます。