この経過時間があちこちで違うので参った。JST(日本標準時)の扱い方が、サイトやNTPのオプションで違うのか、どうしても数が合わない。最終的な解決は、この前もやったと思うが、現場合わせである。NTPをJSTオプションで使ったタイマー値は、地道に計算した1970/1/1の経過秒より一日増やせば一致することがわかった。釈然としない解決だが、とりあえずは、一分遅らせることに成功である。このあたりでブログの原稿をまとめよう。(土)ESP8266の赤外線リモコンウェブサーバー実装にはまる2年越しの課題、古いエアコンの赤外線リモコンの制御に成功して意気が上がったのも束の間、またブログの更新間隔が1ヵ月を越えてしまった。久しぶりのソフト開発に思いのほか手間がかかった。ソースの公開のためのスクラッチビルドが遅々として進まず、開発が難航していたのだ。最近、ソースコードを公開していないので、そろそろソフトを公開しようとしていた。人様のソースの流用なので、許諾を得るために何度か先方に問い合わせをしてきた。今になっても返事がない。仕方がないので、ソースコードをこちらで書き直すことにした。本来は、クリーンルームなどにこもって、既存のコードとは完全に切り離した形で開発しないといけないのだが、まあ、アマチュアなのでそこは大目に見ていただき、ソースコードをモジュール単位に分解して作り直す。しても似たようなコードになってしまうのは仕方がない。それでも、独自のロジックを組み込んだりして、何とか目鼻がついてきたので、このへんでそろそろ公開することにする。ウェブサーバーからリモコン操作ができるようにする(5/12/2018)参考にさせてもらったサイトはここである。ESP8266でコード式の赤外線リモコンの送受信までの機能がある。記事の続編には、ウェブサーバー版もあるようなので、これも少し参考にさせてもらった。ここでは、赤外線リモコンのコードは手入力でソースコードのHTMLデータにセットしている。赤外線コードが得られているのに、これを手書きで入れ直すのはあまり嬉しくない。そこで、これをもっと使いやすく、受信したコードをコンパイルなしにウェブを通して送信する機能を追加することにした。この世界は所長の慣れないウェブプログラミングである。それでもAVRなどと違ってESP8266はかなりのフラッシュを持っているので、相当なことが出来そうだ。ここで勉強して経験を積み、このあたりの開発力をもう少し高めておきたいという下心もある。このため、最近何冊か参考書を買って勉強しているが、今一つ成果は上がっていない。意気込んでプログラミングにとりかかったもののなかなか先に進まない。ウェブを漁ったり、過去の参考書を引っ張り出したり、悪戦苦闘の連続で、まともに動き始めるのに、結局ほぼ2週間かかった。Arduinoのライブラリーを活用しようとしているので、回り道が多い。調べているうちESP8266のウェブサーバー関係のプログラム例は沢山、ウェブ上に見かけるが、まとめると大きく2つの流れがあることがわかった。ESP8266のウェブサーバーライブラリには2種類あり微妙に違う(5/14/2018)まず、ひとつは、この参照サイトにも使われているESP8266webserver.hというライブラリ(クラス)を使ったコードで、もうひとつはArduino本来のWiFiシールド時代からとみられるWiFiserver.hである。最初のライブラリは、クライアントからリクエストが上がると、server.on()というイベントドリブン的な関数が呼ばれて、ここでそれぞれイベントに応じた処理が行える。メインのloop()の中は、HandleClient()しかなく、ここでこまごまとした処理を一手に引き受けているようだ。一方は、clientというクラスを定義して、クライアントからのレスポンスをloop()の中で常時待ち、リクエストそのものを実際に受け取りながら処理を制御する。こちらの方はやや原始的だが多彩な操作が出来そうである。ウェブサーバーのGET/POSTといったデータのやり取りは今一つ理解できていないので、後者の系統が分かりやすくて良いのだが、クライアントからのデータの取り出しが難しい。見様見真似でコードを書いていくのだが、今一(いまいち)しっくり来ない。前者はそのへんを組み込み関数一発で解決できる。ウェブサーバーの処理以外の並行処理をしようとすると(たとえばタクトスイッチ制御など)、どうもうまく動いてくれない。loop()のなかの、handleclient()がブラックボックスになっていて難しい。50年ぶりの葵祭は小ぎれいになっていた(5/15/2018)開発の話が続いたので、たまには、電子工作以外の話題をご紹介。所長の例の京都の小学校の同窓会の話である。これまでは京都近郊の少し離れた会場(石山寺、宇治など)に惹かれて、東京から足を運んでいたが、こんどは別のおさそいである。幹事もなかなかやるものだ。前は場所につられたが、今度は京都三大祭りのひとつである葵(あおい)祭の当日がクラス会という趣向である。われわれのクラスの卒業時の総数は51名、そのうち物故者4名、所在が分かっている人32名で、今回は15名の参加であった。半分に近い結構な出席率だ。関東からの出席者が半数近くもいる。祭りの威力はたいしたものである。子供の頃見物した葵祭は、平安時代の装束をつけた行列が鴨川の土手を練り歩く頃は、祭りが終盤に近いので、学生アルバイトが汗みずくで疲れ果てて歩いており、近くで見ると見映えの決して良いものではなかった。50年ぶりに見た祭りの行列は、なかなか小ぎれいになっていた。みな溌剌としており、藤の花で飾られた牛車(ぎっしゃ)がとても優雅だ。馬に乗った人の列も昔より沢山いる。馬はみなサラブレッドで昔はこんな立派な馬ではなかった。話に聞くと、関東方面の牧場から乗馬用の馬を大量に借りて来るそうで、人ごみに慣れておらず、時々、暴れるそうだ。関係者がおり、直垂(ひたたれ)姿で乗馬していて、御所内で落馬しかけている報道写真を数年前新聞で見たことがある。ウェブプログラミングが通る(5/25/2018)開発の話に戻ろう。2年越しでエアコンの作動に成功したといっても、これはモニターにしているシリアルコンソールからの発信で、ブラウザー画面からではない。ハードはこの前に使ったミニブレッドボードの携帯型の学習リモコンで、ここにウェブサーバーのソフトを流し込んでいく。ウェブサーバー用のソースコードは既にサイトに紹介されているのだが、スクラッチから開発したいため、別のライブラリーWiFiserver.hで動くようにコードを書き換えて行く。前にも述べたように、このライブラリーは、loop()の中でGET/POSTという、クライアントとサーバーのやりとりが目に見える形で操作できるのでプログラミングがしやすい。帰ってくるデータが制御文字を避けるためのエンコードが残ったままで(スペースが%20など)、これをデコードしなければならない。%20をスペースに戻すくらいなら簡単だが、サーバーには日本語が使いたいので漢字となるとお手上げである。ウェブ上で解決法を探したが手ごろな仕掛けは見つからない。迷ったが、結局、オリジナルのESP8266webserver.hに戻し、なるべく元のソースコードを見ないようにして開発していくことにした。こちらのライブラリでは、GET/POSTで入ってくるコードは、argsという組み込み関数にパラメーターを与えれば、コマンドのStringデータを次々に一発で得ることが出来る。データはエンコードされておらず(というより、関数内でデコード済み)、大幅に開発量を減らせる。お手本があるので進捗が早い。オリジナルのWiFiがAPモードで使いにくかったので、STAモードに換え、一般のブラウザーでも画面が出るようにする。これで使いにくいスマホをクライアントにしないで、一般のPCから操作が出来るようになった。HTML文書は、以前、ESP32で画像付きサーバーを作ったときのソースを流用して、とりあえず画面を立ち上げる。styleシートの扱いが難しく、素人まるだしの無粋な画面だが、動かしてみると、これが意外にも簡単に動いた。電子音量リモコンの上下ボタンと、エアコンのスタート/ストップだけの操作だが、PCの画面から、ボタンをクリックすると、音量リモコンが動き、エアコンが、厳かに音を立てて始動するのを確認した。いやいや、まだオリジナルのソースのかなりの部分が残っているが、とりあえずは完成である。コンパイルなしに新しい赤外線コマンドを画面から追加する(5/27/2018)次の課題は、ウェブサーバー上でのコマンドの追加である。受信部はまだこのサーバープログラムには実装していないので、まずはFORMタグによるクライアント画面上からのコマンド名と、その赤外線データの文字入力でコマンドを新設する機能を開発する。ブラウザーの画面で、データのやりとりをするのは簡単ではない。シリアルコンソールなどの送受信は、双方が同等の機能を持ち、独立して動くので、やりとりを設計するのに苦労しないが、HTMLを介したサーバーとクライアントのやりとりは、サーバーからクライアントにトリガーをかけることは基本的には出来ないので、一筋縄ではいかない。いわゆるプッシュ通信という、あたかも、サーバーからデータが来るように見える機能があるが、これは、あらかじめクライアント側のアプリに仕掛けがしてあるからで、基本的にサーバーは、あくまでもクライアントからのリクエストを待つしかない。継続して通信を続けるには、必ず、クライアント側にお膳立てが必要で、HTML文書やCGIなどでサーバーが事前に準備しておく必要があるのだ。悪戦苦闘の結果、画面上の形や位置は、とてもスマートと言えない状態だが、コマンド名とそのコード化された赤外線コマンド($から始まる16進コード、オリジナルがまだ残っている)を画面上に表示し、FORMタグで取りこむことに成功した。下の行に、クリッカブルになったコマンドが表示され、これをクリックすると、めでたくリモコンとして動作した。やれやれ、これでまた一歩前進である。なると、受信部の実装が急がれる。赤外線受信のハードの部分は携帯型学習リモコンに実装済みで、オリジナルのソースコードでは動作を確認している。これを独自ソースに書き換えなければならない。受信部分で最も大変なのが、得られたRAWデータ(パルス幅μs)をコード化する部分である。オリジナルは、AEHA(家電協)方式と、NEC方式しかサポートしておらず、あとからSONY方式を追加したのだが、今度は、いちから作り直しである。苦労したところは、NEC方式とSONY方式の区別だ。基本のパルス長が562μsと600μsと非常に近接しており、この差だけで区別することは難しい(テストのときは何とか特定データで誤魔化した)。これを全く違う方法で区別するように頭を捻った。その方法は、ソースを見て頂ければわかるが、NECとSONYの基本長がほぼ同じで、論理ビットがちょうど反転しているのを利用している(NECはONパルスの長さが一定で、OFFの長さで0.1を判断し、SONYはその逆)。得られたON/OFFのビット長の平均を比較すれば、ほぼ間違いなく両者を区別できるしくみだ。EEPROMが曲者だった。いくつかの落とし穴にはまる(6/5/2018)受信部のスクラッチ開発は手間がかかるので、その作業のかたわら、EEPROMでデータを保存する機能をつけてみた。ESP8266でのEEPROMの実装は始めてであるが、見たところ簡単そうなので気楽にコードを加えて行ったところ、最初は大はまりにはまった。プログラムがひんぴんと落ちるのである。データを書き込むと、一瞬でメモリ破壊でシステムがリセットする。ためしにネットにある例題をコーディングすると問題ない。