# メモ書き
購入検討？
10kΩ抵抗→確定・・・ボタンのスイッチを安定させるため。
人感センサー
サーモグラフィー→高すぎて予算オーバー　１万～
ジャンパーコード(短い,オスオス・・・余裕あったらオスメスも買っておきたい)

EEPROMでエアコンのデータを保存するのは難しそう？
・企業ごとの赤外線通信の配列が不明な点

EEPROMを使用してWifiの情報を保存する

現在時刻を取得して設定時刻でDeepSleepをする。

エアコンの赤外線リモコン情報を取得して再起動するまではそのデータで稼働できるようにする。
→LEDランプで受信中等の目視確認ができるようにすること

https://qiita.com/CoTechWorks/items/441b8d96b30a854ee976

エアコンコードを保存する方向性のほうがいいのかもしれない？

LED　送信短いほうがGND

# pin番号

ボタンとLEDは撤去

pinの指定はGPIOの数字でよい模様

LEDライト
青色 GPIO5
黄緑色 GPIO4
赤色 GPIO2

最終→黄緑GPIO32

タクトスイッチ
プルアップ抵抗買わないと安定しない？？
GPIO34

赤外線受信機
raspberrypiを利用して取得だけする
GPIO15
raspi18

赤外線送信機
GPIO14

温湿度センサー
デフォルト設定から変更不可？
GPIO21
GPIO22
どちらが温度でどちらが室温かは要検証、予想では25のほうが湿度？

# 方法
受信装置をスマートエアにつけるより、raspberrypiでリモコン信号を解析してESP32に書き込むほうがいいのでは？

https://qiita.com/hotchpotch/items/eec0260b8b1938dda696
このサイトを参考にWifiの設定を外部から行えるようにする。
設定時にはセキュリティ的問題がありそう？
検証用に使用していないスマホを利用し、検証する。

成功したか失敗したかのデータを返す。
→成功時の最後の文、失敗時の最後の文にメッセージを返すようにする。

タクトスイッチのＯＮＯＦＦが不安定になっているためそれの解決策。
→試しに10kΩ抵抗を間に挟む？

デフォルト設定での温湿度センサーのデータ取得には成功したのでそれをベースに組み立てる

deep sleepを利用した省電力化の方法を調査
deep sleep中に指示が来た場合復帰できるのか

エアコンが反応したかどうかの確認方法、または複数回送信するか。

ケーブル系統の簡略化。

受信はraspberrypiでデータを取る→ESP32だと安定しないため。

ESP32の送信時の変数の配列の意味調査

不快度指数をDI
乾球気温℃をT
湿度％をH
としたとき、
DI＝0.81T+0.01Hx(0.99T-14.3)+46.3

指定温度になるまでは1分に１回
指定温度になったら３０分に１回
ディレイ中に別の命令を受け取れるのか要検証→millis()を使う

①何も感じない→60~65
②快い→65~70
③暑くない→70~75
④やや暑い→75~80

除湿の条件
湿度が50%以上かつ部屋が30度以下の場合
湿度が50%以上かつ部屋が31度以上の場合、冷房で28度まで冷やしてから除湿

夏場は60~70%の湿度 →65%
①16℃~19℃ 17.5
②19℃~23℃ 21
③23℃~26℃ 24.5
④26℃~30℃ 28

冬場50%の湿度
①16℃~20℃ 18
②20℃~23℃ 21.5
③23℃~28℃ 25.5
④28℃~32℃ 30

湿度50%
①22.4~24.9 23.65
②24.9=27.4 26.15
③27.4~29.9 28.65
④29.9~32.4 31.15

湿度40%
①21.9~24.4 23.15
②24.4~26.9 25.65
③26.9~29.4 28.15
④29.4~31.9 30.65

湿度30%
①21.5~24.0 22.75
②24.0~26.5 25.25
③26.5~29.0 27.75
④29.0~31.5 30.25

スレッドはセットアップ関係なく実行され続ける。
メインはセットアップ中は機能しない。
外部で宣言した変数はスレッドから変更することで他に影響を及ぼせる
→これを使って不快度指数の設定を変更できるかも？
LEDを使ってWifiの設定ができたかどうかの目視確認をできるようにしたほうがいい

エアコン制御はスレッドで実行したほうが良いと思われる。
メインはwifi関連の機能を入れるべき？→pubsub等

## 時間の処理
時刻は24時間表記
開始時刻と終了時刻のパターンを分ける必要がある。
### 開始時間が終了時間より後に設定されている場合
(例)開始時間19:00 終了時間18:00
この場合運転時間は19:00から翌日の18:00までで停止時間は18:00から19:00

### 開始時間と終了時間が同じ場合
(例)開始時間19:00 終了時間18:00
この場合24時間運転

### 開始時間が終了時間より前に設定されている場合
(例)開始時間07:00 終了時間18:00
この場合運転時間は07:00から18:00までで停止時間は18:00から翌日の07:00

#### 注意点
開始時間終了時間変更時のフラグ管理。
(例)開始時間が07:00終了時間が19:00、現在時刻を12:00とする。
case1:開始時間を11:00に変更した場合フラグの変更を行わず運転を継続する。
case2:開始時間を13:00に変更した場合エアコンの停止命令を出す必要がある。
case3:開始時間を19:00に変更した場合フラグを常に固定して24時間運転にする。
case4:開始時間を23:00に変更した場合フラグ変更を行わず19:00にて運転終了とする。
case5:終了時間を06:00に変更した場合フラグの変更を行わず運転を継続する。
case6:終了時間を07:00に変更した場合フラグを常に固定して24時間運転にする。
case7:終了時間を12:00に変更した場合エアコンの停止命令を出す必要がある。
case8:終了時間を20:00に変更した場合フラグの変更を行わず運転を継続する。

# EEPROMで保存する情報一覧
## SSID
char ssid[64]
## PASS
char pass[64]
## エアコン運転開始時間
String Start_Up_Time = "00:00"
Air_Start
## エアコン運転終了時間
String Ending_Time = "00:00"
Air_End
## エアコン運転時間場合分け処理変数
int Time_Pattern = 0
Air_Pattern
## 自動運転を止めユーザーに設定を全て任せるかどうか
boolean user_control = false
Air_user
## 不快度指数設定
int AirControl = 1
Air_Control
## エアコンの運転設定
boolean air_conditioner = true
Air_Power

## EEPROMは毎回宣言しないといけない模様。

## EEPROMを利用したエアコンコードの保存
各配列要素毎に格納、取り出しする必要有。
その為配列の要素数を想定される最大数に合わす必要がある。
取得してきたデータは要素数が上限に達しなければ上限になるまで０で初期化する
AWSから取得したタイミングで更新する。

## NVSの検証
まとめて処理しようとするとメモリのオーバーフローのエラーが出る。分割して処理できないか調査。
※同一関数内ではエラーが発生した模様。

## mqtt上限
受信上限がJsonarray数値で要素59まで。

3桁→46個まで

エアコンの配列の要素/10した値を45個ずつ。
格納するときに*10して戻して格納

main1にて送信確認完了

配列は要素数45x6で270上限
桁数は最大3桁
全て送る際に1/10すること。
また、取得時に全てx10すること。
→エアコンの信号の最低秒数が10μsであることから、下一桁を省略して受信時の容量を節約するため。

## AWS側の処理
配列を1/10にし、一つ送るごとに、一定時間以内にIoT側から受信完了のメッセージが来ない場合再送する(status200は×)
メッセージを受け取った場合次の配列を送り出す。
これを配列を送りきるまで続ける。

## ESP32側の処理
配列を取得したら、*10してから格納する。格納し終わったらAWSに受信完了のメッセージを送信。この時、何番目の配列で、エアコンのどのコードを受信しているかのデータを送る。
これを配列を受信し終わるまで続ける。
※どこまで配列に格納したかのチェック変数を作ること。