I2C パワーコントロールモジュール

[照度計を作って](https://qiita.com/yamori813/items/48284ec2e5d88b97cba3)いて、節電のために深夜帯を停止する方法がないか考えました。

初期の32Bit SOCにはあまりPower Save機能はありませんでした。BCMの最後の頃のチップには機能がありましたが、クロックなどの操作も必要で取り扱いが難しそうです。

MIPS 4Kには[waitインストラクション](https://qiita.com/yamori813/items/1762e38e2ecf4e0a7d13)がありますが蟹さんにはありません。またwaitは効果が限定的です。

以前555でリレーを制御して、ルーターの電源を遅延させる回路を作ったのですが、マイコンで同じようにリレーを制御して、電源をコントロールする方法を思いつきました。

ホストからはI2Cでコマンドを受け付け、指定された時間だけ電源をオフにする回路を作ってみることにしました。

![I2C_Power.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104066/40f4c616-a900-de0d-9bc4-61484685f40d.png)

照度計のプログラムからADCのコードを抜き、Timerのコードを追加しました。

RTCのように1秒毎の割り込みのためセカンダリークロックに32.768kHzの水晶を使うことにしました。ちょうど捨ててしまったビデオのリモコンに付いていたので、それを使いました。

自分が中学生のころの汎用トランジスターは2SC945でした。

![写真（2020-05-04 15.36）.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104066/4888d425-567f-9323-5a29-18ea104bb327.jpeg)

3.3Vのレギュレータは何かのI2CモジュールからはがしたSOT-23な部品を裏面に貼り付けてあります。パッケージには662Kと書かれてありTOREXのXC6202と思われます。

![写真（2020-05-04 12.23）.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104066/fc67b333-5e5c-fd86-0861-5381cc637d15.jpeg)

リレーの接点は2つありますが、オンの状態の利用が多い場合はデフォルトで接続されている方を使い、オフの方が多い場合は接続されてない方を使うのが良いです。

たまたま持ち合わせがあったタカチのSW-50に入れました。

![写真（2020-05-05 11.13）.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104066/ddd1b8b9-589e-7e7d-48ee-819d30c6d453.jpeg)

auの蟹さんのアダプタは2種類あり、ケーブルが平ったいものと丸いものがあります。穴をあける楽なので丸いものを使いました。

3つデータを送って60分間電源をオフにするようにmrubyのコードを書いてみました。

![スクリーンショット 2020-05-06 6.10.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104066/01508ab2-b35c-29c2-b441-4d5489e556de.png)

リレーの駆動に20mAくらいかかりますが、蟹さんは200mA以上食っていたはずなので、十分効果があります。

一時間おきにデータを収集するIoTモジュールなどでも有効な方法ではないでしょうか。

どうにか動くようになりましたが、PICのI2C Slaveと蟹さんがすこぶる相性が悪いです。:(

蓋を閉じようと思ったら、ジャックの部品とリレーがあたり閉まらなかったので、リレーを少しずらして、どうにか閉まるようになりました。出たとこ勝負で作るので、ケース加工は苦手です。^ ^;

![IMGP0007.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104066/9de526ab-ce07-00f5-94ad-7ab538c0be88.jpeg)

LUNAをやってた頃にある事情で定期的にLUNAの電源を入れる必要があり、秋月のクロックのキットと、リレーで似たような事をやっていた事を思い出しました。

テストしていたところ、起動に失敗してハングすることがありました。Ethernetの対向のポートのログを見ると一度落ちたような形跡があります。

```
May 14 04:19:21  kernel: ue0: link state changed to UP
May 14 04:19:25  kernel: ue0: link state changed to DOWN
May 14 04:19:27  kernel: ue0: link state changed to UP
May 14 04:21:45  kernel: ue0: link state changed to DOWN
May 14 04:21:47  kernel: ue0: link state changed to UP
```

うーむ

再現性を確認するために10分おきにしていたところ2回飛ばしたことが確認された。おそらく上記の問題とは別だと思われる。

![スクリーンショット 2020-05-20 4.57.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104066/beb9a745-3c1e-d966-5747-aa1ab1d78329.png)

```
May 20 02:46:51  dnsmasq-dhcp[98]: DHCPACK(ue0) 
May 20 03:03:35  dnsmasq-dhcp[98]: DHCPOFFER(ue0) 
May 20 03:03:35  dnsmasq-dhcp[98]: DHCPREQUEST(ue0) 
May 20 03:03:35  dnsmasq-dhcp[98]: DHCPACK(ue0) 
May 20 03:16:52  dnsmasq-dhcp[98]: DHCPOFFER(ue0) 
May 20 03:16:52  dnsmasq-dhcp[98]: DHCPREQUEST(ue0) 
```

46分に起動しているのに50分をやらずに57分に停止命令して58分に停止して、3分に起動して10分は正常処理したようだな。

この時間のネットワークトラフィックは減っていた。

![filename-50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/104066/f21fd94f-5e2f-3e3b-83b9-61815474f0e1.png)

同時間帯に照度計の登録には問題は見られない。

ThingSpeakはどきどき3時くらいにメンテしているようなので、その影響の可能背もあり得るかもしれない。