クーラーをつけっぱなしにしても明け方に暑くなるメカニズム

夏になり寝るときにはエアコンを使うようになった。
電源を入れっぱなしにしているにも関わらず、明け方になると暑くて目が覚める。
やすらかシステムを使い温度と湿度を1分毎にロギングして解析してみた。

下のグラフをご覧いただきたい。
22:45頃にエアコンのスイッチをONし5:50頃にOFFしている。

いろいろと気になる点があるが、明け方になると暑くなるという点について考察すると、温度は約±1℃の範囲でコントロールされている。湿度は時間の経過と共に上昇し80%を超える。湿度のために不快と感じて目が覚めるようである。
室温が設定温度に達すると、熱交換器を冷やす必要がなくなり、結露による除湿が行われなくなるというメカニズムである。冷たい飲み物が入ったグラスを部屋に置いておくとグラスの外側に水滴が付くが、室温と同じ温度の飲み物なら乾いたままであることと同じである。
最新型の上級グレードのエアコンには、再熱除湿という機能が付いており、除湿して温度が下がった空気を再び加熱して吹き出す機能が付いてる。2009年製のエアコンを古いとは思っていなかったが、技術は進歩しているようである。

湿度が上がる要因をネット上では扉やサッシの隙間と分析されているケースが多いが本当だろうか?下のグラフをご覧いただきたい。上のグラフは就寝時(夜間)のデータであるが、こちらは昼間に誰も寝ていない時間帯のデータである。外気温は異なるものの、人間の有無が支配的とは考えられないか?除湿器で湿度を下げると明け方に目覚めることなく快適に寝れるのかもしれない。

他の部屋で寝るほど研究熱心ではないが興味深い。

エアコン:三菱電機 霧ヶ峰 MSZ-EX25E6  体感OFF 冷房モード 27度設定 2009年製
部屋:鉄筋マンション 北向き 約8畳 2名就寝

TSキュービックカードの請求書をCSVファイルへ出力

TS3カードはWEBページからpdfファイルをダウンロード可能である。しかし画像データであるためExcel等の表計算ソフトでインポートできない。画像認識ソフトやAdobeのACROBATで変換できないか試行錯誤したものの、表として認識させるに至らなかった。

仕方なくツールを作成した。

オープンソースで公開します。

ESP8266のSmartPlugを試す

ESP8266_IOT_PLATFORMに含まれるSmartPlugを試してみた。
装置の各種設定をWEBページで行えるようにしたいのだが、ゼロから作るのは大変なのでSmartPlugが使えないかと考えた。
結論から言うと、バグを直せば使えそうである。
解凍したままでは、WEBページが正しく表示されないバグがある。

1つ目は、ESP8255_RTOS_SDK内でIPを実装しているlwipのマルチスレッド対応部分のうち、closeを行う部分で状態をSHUTODOWN_NONE状態に戻さないバグ。
closeを実行した後にselectで同期を取ろうとすると返り値が継続的に-1になってしまい、全てのソケット通信を続けられなくなってしまう。

2つ目は、espfsが扱うファイルイメージが4バイト境界に整列する前提であるにも関わらず、特に指定がなされていないため4バイト境界に整列しない場合があるバグ。
一つの直し方を下記に示す。
espfsというセクションを新設し4バイト境界に整列させる考え方。

この2つを修正すれば、ちゃんと動くようになる。

実害は無いが、ESP8266_IOT_PLATFORM内のHTTPサーバを実装する部分で、ポート番号とIPアドレスを保持する部分に抜けがあり、接続先のIPアドレスとポート番号を保持できない部分がある。代入されたconnData[index].remote_portとconnData[index].remote_ipはどこでも使われていないため問題は顕在化しない。

 

ESP8266_RTOS_SDKのsocketサポート

FreeRTOSのサポートは十分でなかった状況とは異なり、socketでソケットを作成し接続、データ送受信くらいの範囲では、完全に互換性が取れている。
既存のソースを張り付けるだけでコンパイルでき、動作も問題ない。

lwIPにより実装されており、BSDソケットと互換性がある。
ホームページ上のドキュメントではソケットのサポートはオプションとなっているが、実装されているようだ。

ESP8266_RTOS_SDKのFreeRTOSサポート

FreeRTOSのホームページ上でAPI Referenceを見てコーディングしてもエラーが出てしまう。

xTimerCreate をコールするために、TimerHandle_t型を使いたいのだが、無いとのエラーが表示される。

ESP8266_RTOS_SDK\include\freertos\timers.h の中を見てみると、xTimerHandle型になっている。
他にも TickType_t 型が portTickType 型だったりする。

NONOS環境での型名とのバッティングを避けるためなのか分からないが、これではFreeRTOSサポートとは言えない。

既存の資産を移植するようなプロジェクトにはラッパーが必要である。

ESP8266_RTOS_SDKやESP8266_NONOS_SDKのサンプルをコンパイルする

ESPRESSIFのサイトからSDK(ESP8266_RTOS_SDKやESP8266_NONOS_SDK)をダウンロードして解凍しただけでは、サンプルのコンパイルでエラーが発生したり、ライブラリのコンパイルでエラーが発生したりする。

  • NONOS_SDK環境では、プロジェクトをSDK直下に置かなければならない

例えば、expamples/IoT_Demo 直下で gen_misc.sh を実行してもコンパイルは行われない。IoT_Demo直下にあるMakefileの最終行に sinclude $(PDIR)Makefile と記述されており、SDK直下に存在する最上位のMakefileがインクルードされるためには、SDK直下にあるディレクトリでコンパイルを行う必要がある。
よって、下記のコマンドを実行しディレクトリごと1階層上に移動させる必要がある。

この問題はRTOS_SDKでは起きない。しかし一方で、gen_misc.sh 中に記述されているSDKのパスをコンパイル環境に合わせて書き換える必要がある。

  • RTOS環境でリンク時にROMに置かれている関数コールを解決できない

ROMのシンボル情報は下記の場所にあり、NONOS環境には全ての関数が列挙されているものの、RTOS環境にはRTOS固有と思われる関数しか記述されていない。

NONOS_SDKの /ld/eagle.rom.addr.v6.ld の情報を転記するか、各コンパイル環境直下にあるMakefileのDEPENDS_eagle.app.v6 にldファイルを追加する必要がある。

  • バグ

ESP8266_RTOS_SDK v1.5.0 は一部手を加えないとライブラリのコンパイルができない。

ESP8266開発環境の比較

ESP-WROOM-02(ESP8266)のソフト開発環境を比較してみた。

2017年4月27日現在

環境 概要 開発環境 費用 その他
arduino
Ver1.6.9
・必要とされる知識が少ない
・オブジェクト指向の実装が可能
・NONOSと同じマルチタスキング
Windows
Mac OS-X
Linux
フリー ・導入も簡単
・コンパイルに時間がかかる
ESP8266_NONOS_SDK
Ver.1.5.4
・上限3タスク※1のマルチタスク
・独自ソケットライブラリ
・JSON
Linux
Solaris
Windows※2
Mac OS-X※2
・コンパイルが速い
・SDKを解析して使うスキルが必要
          結構バグがある
・解凍しただけではサンプルのコンパイルさえ通らない
・英文マニュアルを読む必要がある
ESP8266_RTOS_SDK
Ver1.5.0
・freeRTOSによるマルチタスキング
TickTImeは10ms,変えられないことは無さそうだが、変えやすく作られていない。構造体の型がアレンジされている。
lwIPによるソケットをサポート
・JSON

※1 情報源=2C-ESP8266-SDK__API Guide__EN_V1.5.4.pdf
※2 VirtualBoxを利用

下に行くほど、高機能かつ知識が要求される。
C言語,Linux,マイコンの知見は必須。
やすらかシステムでは、イベントのスキャン,TCPコネクションの維持で2つのタスクを使っており、今後の機能追加時に上限3タスクを超える見込みであり、ESP8266_RTOS_SDKを選択する。