2024年4月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        
無料ブログはココログ

« 2023年6月 | トップページ | 2023年8月 »

2023年7月の6件の投稿

2023年7月30日 (日)

シンクに置く砥石台を自作

10年以上使ってきたハンディ砥石がだいぶ変形してきて、平面がほぼ無くなり研ぎにくくなってきました。(下図)
Img_9619_20230730175101

かみさんの怪我の元なので、刃物の刃は余り研がない様にはしていますが、それでも切れなくなると荒研ぎ程度に研ぎます。
でも変形し過ぎて、砥石面と刃面の角度も安定せず、まともに研げているのか不安ですし、ハサミの時は最悪でグラグラ動いて安定せず、やりにくいんです。

最近は時間もあるし、やる気もまあまああります。何かやるにもちゃんとやってみたい感じでして、ホームセンターでまともな砥石(#220 税込み1300円)を買ってきました。
砥石だけでは使いにくいので、ぐらつかず水も掛け易い様に、シンクの枠に置ける砥石台を作ってみました。
市販品も結構出ているようですが、自分的にはDIYで十分ですね。

材料は家にあった合板の端材で、シンクの枠の長さで切り、ボンドで砥石止めを貼り付け、角を面取りし、水性床用ワックスをたっぷり吸収させる下塗りをして乾燥、表面のざらつきを紙やすりで削り平坦にし、更に仕上げ塗りでこれでもかとワックスを塗っては乾かしを繰り返し防水性・防汚性を上げて完成です。

早速使ってみると結構使い易い感じに出来ました。


シンクの枠に置いた様子です。グラつきはありません。左上の白く丸いのが蛇口で、いつでも水を掛けられますし、そのまま流せます。
Img_9615

手前からの様子です。砥石の上下にはMDFの端材を接着し砥石止めにしました。
Img_9616_20230730174901

木製なので耐水性を高めるべく、いつもの様にリンレイall床用ワックスを塗り、ドライヤー熱風で気泡を飛ばしながら乾燥、これを何度も繰り返しました。
表面が滑らかで光沢が出る(下の写真)程にアクリル被膜を付けておけば、耐水性・防汚性は十分でしょう。
下の写真2枚はワックスが乾いた状態、光沢があるので窓からの光が良く反射しています。
Img_9627
Img_9628
(ニスやラッカーを塗るのが普通なのでしょうが、リンレイall床用ワックスを何かと使いたい派なもんで。)

買った砥石の箱です。#220 荒砥ぎ用で十分です。
Img_9617Img_9618

これで、楽に安定して研げますし、自作したぶん楽しんでできそうです。

続報あればまた。

2023年7月24日 (月)

窓用断熱フィルムで真夏の室温上昇を抑制

2階は特に真夏の直射日光で昼間に室温がグングン上がります。

風呂や寝室が2階にあるので、2階に行かないわけにもいきません。
2階に上がれば、夕方でも高温のもわっとした熱気で、一瞬で汗が噴き出します。
外が少し涼しくなる夕方に窓を全開、扇風機2台を強で回し2階の熱気を外に出し、外気を入れて室温を少しでも下げるのを、毎夏シーズンに毎日やってます。
時間がかかるので寝る直前までやりますし、毎日で自分でもいつまでやるのって感じ、今年は何か一歩進めたいと考えました。

調べると室温を上げる原因の73%は窓やドアからとの事らしく、そんなにあるのって感じです。
確かに直射日光下の窓ガラスやサッシの金属部分を触ると結構熱くなってます。
高温になる窓ガラスやサッシの金属部分から、輻射や対流が起き熱がどんどん室内に移り、室温を上昇させ熱気ムンムンにするのでしょうね。
ならば、窓を何とかして室温上昇を抑えるのが効果的と考え、窓用断熱フィルム(下)を買って、貼ってみました。
Photo_20230724203201Photo_20230730161401
レビューを見てシルバーを選択、マジックミラーみたいに昼間は外からの日光を反射し温度上昇を抑えるフィルムです。
日射熱取得率(*)と言うのがあって、窓ガラスを通して室内に入る日射熱は85%もあるらしいです。
マジックミラー効果で赤外線の90%も反射してくれるなら断熱効果が期待できます。

貼るのは割と大変で、最初は勝手が分からず、保護フィルムを剥がしながら貼っていくとフィルムが歪むし、あちこち折れ曲がるし、なかなか綺麗に貼るなんてできずで、結局ガラスから一旦全部剥がしてから再度位置合わせしてまた貼り直すとか、最初の2面は繰り返しました。
駄目だこりゃと考え、3面目以降は、数cm程度ガラス面より大きくフィルムを切っておき、保護フィルムは全部剥がしておいて、ガラス面に対し上下左右でフィルムの位置合わせをし、先に中央部だけ水で縦に貼り付けてから、気泡を横に逃しながら右面と左面をそれぞれ貼っていくのが、歪を抑え気泡もうまく逃がして綺麗に貼るコツに思えたのでそうしました。
最後は外周の余ったフィルムをカッターで切って完成です。位置合わせまでは2人作業でないと厳しいですね。
位置合わせしたら養生テープなどでフィルムが落ちない程度に上辺だけでも仮止めしておけば、もっと楽だったかも知れません。ゴムベラとかないので、適当なプラ板でこすって気泡を逃がしたため、フィルム表面にはいっぱい傷が付きましたが、そんなに目立たないので良しとするしかありません。
後で説明書(右)を良く見たら、本体フィルムを傷つけない様に保護フィルムを再度貼り気泡と水を抜くと書いてありますね。(ははは!今更 自分が情けない)

Img_9624
でこぼこ面のガラスでは、一工夫が必要でした。
平坦なガラス面だと水だけでしっかり張り付き問題ないのですが、西窓は小窓なので最後にフィルムが余ったら貼る予定で進めたため、フィルムの切れ端しか残っておらず継ぎはぎになってしまいました。

しかも西窓はガラスの表面がでこぼこで、フィルムとガラスの接触は分散した点状で隙間だらけ、指でずらせば簡単に剥がれる感じになってしました。
昼の温度上昇でフィルムは柔らかくなり、端から剥がれかける始末。
しょうがないので、ガラス全体に貼ったフィルムの外周部とそれに接するサッシのゴムパッキン部分にかけてと、フィルム同士の境界部分に、木工ボンド(ダメならいつでも剥がせる)を塗って接着、まあ目立たない所なので気にしません。
一番右の写真だけ夜に室内から撮影したので、ハーフミラーに見えます。

Img_9609 Img_9610 Img_9608

東南西面の直射日光が入る窓には全部貼り、幅90cm×縦2m×5枚をほぼ全部使い切りました。

最初は半信半疑な気持ちもありましたが、貼ってから数日様子をみる範囲では、窓ガラスの温度もそんなに上がらず、室温ももわっとした熱気とまではいかず、5分程度いても汗が出てくるほどでもないです。
昼間の外気温から考えて今までは2階に上がると直ぐに汗がふき出す感じでしたので、こんなのって今までなかったと思え、効果ありを実感しています。

やっと梅雨明けし、今シーズンの猛暑もまだ始まったばかり、まだまだ暑くなりますし、夜の外気温も下がらなくなるでしょう。
窓の断熱フィルムの効果がどの程度か、今シーズンを通して様子を見て過ごす感じになりそうです。


2023-7-29追記
最近は連日晴れて最高気温35℃位の猛暑日が続きます。
朝から夕方まで、2階の窓とカーテンを閉めきった方が、汗が噴き出す程の熱気にもならず、壁とかもさほど熱くならないので、今までの様に室内全体に熱気が充満する程の熱の総量が入らなくなった感じを実感できます。
たぶんですが、直射日光が当たると、窓ガラスもカーテンも結構温度が上がりますが、その間の狭い隙間が空気層の役割をし、それ自体が2重ガラス的な断熱効果になっているんだろうと感じます。空気の熱伝導率は相当に低いですしね。

夕方気温が下がったら窓を全開して、扇風機2台を寝るまで強運転で回せば、だいぶ室内の温度を下げられるので、熱気に辛い思いをする事がだいぶ減ってきました。

夏本番はこれから1か月以上続きますので、まだまだ様子見継続です。
カーテンの上下の隙間をなるべく塞げば対流も抑えられるので、より室内温度の抑制効果が上げられる気もします。
様子見しながらどこかで試すかもですね。


2023-8-20追記
夏本番で、猛暑続きの毎日ですが、日中2階の窓を閉め切ってカーテンをしていると、室温はそれなりに高くなりますが、汗びっしょりになる感じはありません。
手で触った感じでは壁の温度もそんなには上がってなく、夕方外気温が下がってから窓全開で外気を入れれば、そこそこ室温を下げられる感じです。
思うに、昼間の窓ガラスの熱は空気を伝って室温を上げますが、熱量そのものは断熱フィルムで抑制されているので、室内の空気から壁等に移る熱量も減っていて、温度の上がった室内の空気を出す事で室温を下げられる感じです。

室温を測る温度計とか、壁の温度を測る表面温度計とか、何も使っておらず、体感だけの説明ですが、昨年に比べればだいぶ違うと実感しています。

内心もっと断熱効果が必要なら、窓の内側に空気層を作るため、プラダン(10倍高いが透明なポリカ中空ボード)やプチプチを貼ると良いかとも考えていましたが、今後の改善ネタで残しておくかな。

続報あればまた。


参考
省エネルギー建材普及促進センター | 【Q&A】開口部からの熱の出入りは、どの位あるのですか? (kensankyo.org)
 Photo_20230727195401
暑さの7割寒さの6割は窓が原因なのに、日本の窓は中国の最低基準以下 | 住まいの本当と今を伝える情報サイト【LIFULL HOME'S PRESS】 (homes.co.jp)
家の中が暑くなるのは住まいに3つの原因が!? (sankouhome.jp)
 住宅の中で最も熱の出入りが大きい場所は、窓・ドアなどの開口部です。全体の73%の熱が窓やドアから
【家が暑くなる原因】真夏の「窓」からの熱を防ぐには? 簡単にできる日差し対策 (aruhi-corp.co.jp)
空気は熱を伝えない (kingparts.co.jp)
(*)窓への省エネ対策はどんなものがありますか?また、その効果算定方法は?<建築物省エネその3:窓の二重窓化> | 省エネQ&A | J-Net21[中小企業ビジネス支援サイト] (smrj.go.jp)
  Photo_20230730161101 

2023年7月21日 (金)

MACアドレス登録は許可か制限か

ESP32でのWi-Fi Lチカの応答速度が気になって、今日Wi-Fiルーターを更新しました。

今まで使っていたのが NEC Aterm WG1200HP(2015/1/22発売)、今日から使うのが ELECOM WRC-2533GST2(2018/10/中旬発売と古い)です。

自宅のWi-Fiのセキュリティが気になるので、今までせっせと繋ぎたい機器のMACアドレスを登録してアクセスできる様にし、登録されないMACアドレスの機器からの接続は排除(制限)してきました。
なので、新しいルーターでも同じように接続したい機器のMACアドレスの登録をしましたが、なぜか繋がらない症状に悩まされました。
ただ、携帯(iPhone)では、プライベートWi-Fiアドレスにチェックを入れると繋がるが、チェックを外すと繋がらないのが分かったので、MACアドレス関係が怪しい感じがありました。

設定項目の役割を調べながらのチェックやカットアンドトライで、数時間程原因究明にかかりましたが、ELECOMのWi-FiルーターでのMACアドレスの取り扱いと私の認識のズレの問題が原因でした。

ELECOM WRC-2533GST2 ではMACアドレス登録は、接続を排除(制限)するためのものだったんです。

私の認識と全く逆なので驚いちゃいましたが、今までの認識のままMACアドレス登録をしてしまうと排除され繋がらない訳ですよ。


ELECOM WRC-2533GST2 の取説の抜粋です。下は拡大。
接続を拒否する機器のMACアドレスを入力とあります。
Photo_20230721184101
Photo_20230721184102

Aterm WG1200HPのマニュアルの抜粋です。
MACアドレスを登録した子機とのみデータ通信できるとあります。
2_20230721183601


しかしまあ、メーカー(あるいは製品の種類か)によって扱いがこうも違うのかとの思いです。

ただ、ELECOMでも機種によっては、拒否か許可かを切り替えられるのもある(*1)ので、たまたまNifty光のキャンペーンでもらったWi-Fiルーターが拒否設定限定だっただけかもしれません。
まあ、当時発売から約1年半ほど経過した9000円相当のルーターをもらった訳なので、文句は言えません。

近年ではMACアドレスは簡単に調べられ、セキュリティ強化にならないとの情報も結構見つかるので、私の認識が古いままなのでしょう。

ELECOM WRC-2533GST2 でのMACアドレス登録は止めて、セキュリティ強化でステルスを有効にしました。
SSIDが見えませんが、最初だけ手動入力で繋げれば、繋がった事のあるSSIDへの自動接続機能があるので、そんなに困らない感じです。

 


参考

Wi-Fiの「プライベートアドレス」をオフにするとどうなる? - いまさら聞けないiPhoneのなぜ | マイナビニュース (mynavi.jp)
MACアドレスフィルタリングとは – Wi-Fiの使い方初心者用ガイド | Wi-Fiの使い方~ワイファイ初心者用ガイド~ (manualjp.com)
MACアドレスフィルタリングって何?【“Wi-Fiの困った”を解決:基本編 第8回】 - INTERNET Watch (impress.co.jp)
・(*1)【エレコムルーター】MACアドレスフィルタリングを設定したい (elecom.co.jp)
 Photo_20230722181201

2023年7月12日 (水)

ESP32 Wi-Fi Lチカのスケッチを読解

30年程前にPICをやったっきりで、Arduinoとかも知らかなった自分が、はやりのIoTをやってみたくてESP32を買い、ネット記事を真似してWi-FiでLチカをやってみました。関連情報も探せばたくさん出てきますし、それこそコピペでできてしまう便利な時代ではありますが、仕組みを知らないと面白くないし、応用もきかないので、自分なりに頑張って読解してみました。

目次

 前置き
 基本的な理解から
 処理全体の流れ
 クライアントとサーバーのやり取り
 リクエストの中身
 リクエストの文字列処理の詳細
 HTMLの生成

 読解を終えて
 おまけ:高速化のあがきと顛末

参照した記事を書いた諸先輩達に感謝。この記事が少しでも誰かの役に立てば幸いかな。

 

前置き

ESP32を買ってから1か月半経ちました。
Wi-Fiを使った初IoTのWi-Fi Lチカですが、下の動画の様にスマホのブラウザ画面のボタンを押して、ESP32に繋いだLEDをOn/Offさせる事が出来ます。初めてだからか、これだけでもなんだか感動するものがありましたね。

スマホでESP32に繋いだLEDをOn/Offさせる様子。

でも実は、スマホでLEDを制御しているブログにあったスケッチ(これ)をコピペしただけで、中身の理解が出来ておらず、実はチンプンカンプン、やったら簡単にできたと言う印象だけの状態で、まともな応用もできないでしょう。

ワンショットリモコンのIoT化もそうでしたが独自のIoT工作やスケッチ作成をするにも、エイヤなカットアンドトライになるので、良くありません。
今後のために、ここで一旦Wi-Fi Lチカのスケッチ1行1行をにらめっこし、分からない事をネットで調べ、先人達の知恵も借りて、各行の処理の役割、全体の制御の流れなど自分なりに読解し、理解を深めたいと考えました。
何でもそうですが、分かっていないと面白くないですしね。

ネットにだいぶ助けて貰いましたが、部分部分を個々に解説した記事や言葉で説明した記事は良く見かけるものの、自分の頭の中で多数の記事の断片を繋ぎ合わせ、全体を把握するのに数日掛かりました。
自分は分かり易く全体が見える様にするのが好きなので、Excelでテキストや図・矢印等を付けて分かり易い資料を作成し本記事にpdfで添付してみました。

                    

上記動画では、ボタンを押してから約2秒でLEDが切り替わるので、もっさりと遅いです。
本記事の最後では応答を高速化したくて少しあがき原因が判明。約0.2秒と大幅に改善(下)。果たしてその原因は?

 

基本的な理解から

Wi-Fiを使ったIoT工作の基本的な理解からですが、Lチカの事例ではESP32側がサーバーで、PCやスマホのブラウザ画面がクライアントになります。(中間のWi-Fiルーターとのやり取り等は省略)

クライアントからはリクエストが送られ、サーバーがレスポンスを返すというやり取りの繰り返しです。
Photo_20230712165401_20230806090501


ESP32側のWi-Fiルーター接続時のIPアドレスを、クライアント側ブラウザに入力する事で初めて、クライアントとサーバーが接続し、クライアントからリクエストが送られ、サーバーからレスポンスとしてブラウザ画面用のHTMLを返す事で、クライアントのブラウザ画面が構成されます。

以下、Wi-Fi Lチカでクライアントがサーバーに接続した直後のブラウザ画面です。
サーバー側からのレスポンスとして受信したHTMLでブラウザ画面の各パーツが配置されます。
予めボタンにはLEDをOn/Offするためのリンク先を、HTMLの<a href=リンク先>~ボタン配置~</a>の形式で付けてあります。
1_20230713205601_20230806090501

画面のボタンをクリックすると、ボタンに貼られているLEDのOn/Offのためのリンク先へのリクエストがサーバーに送信され、サーバー側でリクエストの文字列から"GET /26/on"等を見付け、必要なGPIOを操作し、次の操作のためのブラウザ画面の更新用のHTMLデータをクライアントへ送信し、接続を解除します。

その後の動作は、ブラウザのボタンを押すたびに、ボタンのリンク先へのリクエストが送られ、サーバーで必要な処理をしてレスポンスを返すという繰り返しですね。

 

処理全体の流れ

簡単には、ざっとこんな感じですが、中身は細かい処理が並んでいて結構複雑ですね。
リクエストの中身を知らないと、サーバー側での必要な処理の仕方が分かりませんし、どう言う構成でレスポンスを返すかも知っておく必要があります。HTTPプロトコルと言うらしいですけどね。
特にサーバー側でのリクエストの中身の文字列を、どんな方法で判別しているかを理解する事が重要に思います。

とは言え、まずは全体の流れを追い、大まかでも良いので全体を理解するのが良い気がします。
と言う事で、先ずは全体の大まかな流れを書いてみました。

大雑把には、初期化・Wi-Fi接続を終えたら、クライアントからのリクエストを待ちます。
リクエストが来たら、リクエストの受信完了後に、GETコマンドに従った処理と、レスポンス送信(HTMLも更新)をして、再度リクエスト待ちを繰り返すって感じですね。
Photo_20231225161701
注意:シリアルモニタへのメッセージ送信とか、レスポンス送信後のクライアントとのWi-Fi接続の切り離し処理とか、タイムアウト処理とかは先ずは考えないで書いています。

前項で書いたように、リクエストで大事な所は”GET /リンク先"です。
最初にIPアドレスだけでアクセスすると、”GET /"だけがクライアントから送られますが、/以降のリンク先(26/onとか)が無いので、LED点灯の操作は実施されず、ブラウザ画面を構成するためのHTMLをクライアントへ送信するだけです。
それ以降は、ブラウザ画面のボタンを押す事で、"GET /26/on"とかのリクエストが送られ、GPIO26のLEDを点灯させる操作が実施され、その状態にブラウザ画面も更新されます。

この大まかな流れを、細かい処理で実現しますが、細かい処理では良く分からない部分が残ってしまうでしょうから、後で詳細を追えば良いと思います。

と言う事で細かい処理の全体像として、スケッチ1行1行を読解し説明を加えてみた図です。クリックでpdfが開きます。
先人達のWi-Fi Lチカの解説ブログやHTTPプロトコルのネット情報など、書き加えて全体が見える様に書いてみました。
Photo_20230805165601_20230806090601

左側がESP32側がWi-Fiルーターに接続するまでの部分で、ESP32の電源OnでWi-Fiに繋ぐまで1回だけ実行されます。
右側がクライアントと接続し、ブラウザのボタン操作でLEDの点灯/非点灯をする部分で、クライアントとの接続と切り離しを繰り返します。

クライアント側ブラウザ画面のボタンが押されるとサーバーと接続し、ボタンのリンク先を含むGETリクエストがクライアントがサーバーに送信されるので、サーバー側ではリクエスト文字列を1字づつ受信しながら、行末判定と行末処理を全行繰り返し、最後のリクエスト受信終了の判定の後、レスポンス送信・リンク先文字列により必要なGPIO操作・更新用HTML送信を行い、接続を切り離し、次の接続を待つと言う流れです。

自分もそうでしたが初めてだと、しばらく頭をもやもやさせて脳内の情報整理と定着が必要でしょうし、ネット検索でヒント探しを繰り返すとか、必要な気がします。コツは何度も繰り返して考えながら見る事かな。

 

クライアントとサーバーのやり取り

クライアントとサーバーのやり取りの、たぶん通例的な形式であろう部分が、予備知識ほぼゼロの自分にはとっても分かりにくいと感じたので、少し補足です。

クライアントからのリクエストはGETメソッドを使っていて、リクエスト内のリンク先を示すURI文字列は、ブラウザのURL欄にも表示される様です。以下、少し順を追って実際の画面例を見ながら説明してみます。

ブラウザでURLに192.168.1.8を入力し、クライアントと最初に接続した場合のリクエストには、ボタンからのリンク等何もないので、サーバー側の"GET /26/on"等の検索にヒットすることなく、初期値のoutput26State = "off"、output27State = "off" のまま、サーバーからHTML構成のレスポンス送信が行われ、下記の画面が表示されます。
注意:このスケッチ例では、ブラウザ画面のボタンの文字や色は押した後の状態を示す様になっています。

接続直後のクライアントのブラウザ画面。URL欄は"192.168.1.8"だけです。
1_20230713205601_20230806090501

この状態で、GPIO26の ON ボタンを押すと、URL欄は192.168.1.8/26/on になり、GET /26/on リクエストがサーバーに送られ、サーバー側でGET /26/onの検索がヒットし、GPIO26出力がHIGHになり、HTML生成を含むレスポンスにより、GPIO 26 - State on で  OFF  にブラウザ画面が変わります(下図)。
GPIO26の ON ボタンを押した後の画面。URL欄は"192.168.1.8/26/on"に変わっています。
2_20230713205701_20230806090801

更に、GPIO26の OFF ボタンを押すと、URL欄は192.168.1.8/26/off に変わり、GET /26/off リクエストがサーバーに送られ、サーバー側でGET /26/offの検索がヒットし、GPIO26出力がLOWになり、HTML生成を含むレスポンスにより、GPIO 26 - State off で  ON  にブラウザ画面が変わります(下図)。
GPIO26の OFF ボタンを押した後の画面。URL欄は"192.168.1.8/26/off"に変わっています。
3_20230713210101_20230806090901

注意:上記画面はPCでの画面ですが、スマホ(iPhoneのSafari)では画面が小さいためかドメイン表示しかせず、URL欄に/26/on等の文字は一見表示されませんが、URL欄を選択すれば表示されました。

で、ここで肝心なのは、上記URL欄にも表示される、GETリクエストの1行目にあるリンク部分です。
その文字列によって、GPIO操作の判別を行えば良い事になります。
下記は、最初の全体像のpdfの一部拡大です。
Photo_20230805171801_20230806091001

最初だけ取り出したのが、以下の記述です。

// turns the GPIOs on and off
if (header.indexOf("GET /26/on") >= 0) {
    Serial.println("GPIO 26 on");
    output26State = "on";
    digitalWrite(output26, HIGH);
} else if (header.indexOf("GET /26/off") >= 0) {
...

リクエスト文字列は文字列変数headerに入っているので、"GET /26/on"の文字を検索し、ヒットすればGPIO26をonにするため、digitalWrite(output26, HIGH);を実行しています。

これで、リクエスト文字列から、GPIO操作に必要な情報を得る方法が分かりました。
HTML書式に則り、ボタンのリンク先の部分へGPIO操作のキーワードを埋め込んでおき、ボタンが押されたら指定されたGPIO操作を行う感じで、なかなか上手い方法と思います。

尚、上記では文字列変数output26stateに現在の状態として"on"を代入しています。
この変数は更新用HTMLの生成で、現在の状態に応じてボタンの色や文字とGPIOの状態表示を変えるためです。

 

 URL欄GPIOコマンド操作 

この方法では、サーバーとの最初の接続時に、例えば 192.168.1.8/26/on とURL欄に入力すると、接続時点でGPIO26のLEDをOnさせる事も出来ます。
接続とブラウザ画面の立ち上がりを待ってボタンを押す操作をするまでもなく、URL欄だけの情報で操作できる訳で、まさに「GPIOコマンド操作」と言えそうです。
ブラウザ上のボタンが無くても操作できるので、面倒なボタン配置用HTMLのスケッチ記述を後回しにして、GPIO操作のスケッチ記述のデバッグに集中できますし、ブラウザ画面にボタンすらない簡易サーバーで済ませるとか、いろいろと応用できそうです。
ボタンがある方がIoTって感じが強くなりますし、何よりカッコいいですけどね。

PCブラウザのURL欄だけでGPIO操作をしている動画です。ボタンは一切押していません。

やってみたことはありませんが、26/onとか、27/offの文字列は、ESP32側の処理の振り分けのためのキーワードになっているだけなので、26onでも27offでも良いはずです。その場合は、if文での検索文字も合わせる必要があります。
HTMLのリンクの仕組みをそのままESP32側での処理の振り分けに利用した方法と言えます。

 

リクエストの中身

上記やり取りの背景となるりリクエストの中身の理解も必要です。
具体的に、リクエスト文字列を見た方が早いので、スケッチの一部を変えて、リクエスト文字列をシリアルモニタに送るSerial.write(c);を有効と無効とした各々で、シリアルモニタ画面の差を見てみました。

Serial.write(c);の有効・無効でのシリアルモニタ画面。クリックでpdfが開きます。
Photo_20230806091101

これで、リクエストの中身の構成が分かりました。
シリアルモニタでは改行されるだけで文字として見えないので少し分かりにくいですが、各行末には実際には CR LF (\r\n or ¥r¥n or 0x0d 0x0a ASCII文字)が定型的に付加される様です。

リクエストのフォーマット 参考(*1)の説明を抜粋
Photo_20230715121001_20230806091201

上記の様に行末が\r\nとなる複数行と、最後の\r\nだけの空行で、GETリクエストをクライアントが送ってくるので、この特徴を使ってサーバー側の処理をする事になります。
Wi-Fi Lチカのスケッチでは、参考(*2)での説明(下)が分かり易いです。

HTTPでは「\n」と「\r\n」のどちらにも対応することを定めています。
しかし「\r\n\r\n」だと煩雑になるので、読み取った文字が「\r」の場合はcurrentLineに追加しないことで、「\r」の排除を行っています。
currentLineの長さが0になるのは「\n」を読み取った後です。
その後に他の文字を読み取ればcurrentLineの長さは1以上になります。

「\n」を読み取った直後にまた「\n」を読み取った場合、currentLineの長さが0の状態で「\n」を読み取ったということは、HTTPリクエストの区切りの空白行なので、これでリクエストが完了したとみなし、HTTPレスポンスの送信を開始しています。

 

リクエストの文字列処理の詳細

リクエストの文字列は把握できましたが、今度はサーバー側での具体的な処理のアルゴリズムをどうしているのか、具体的に知っておく必要がありそうです。
サーバー側でのリクエストの1文字処理を行う部分は結構長い記述ですので、元のスケッチのまま処理を追っていては、目が上下に行き来してしまうし、頭もこんがらがってしまいます。
途中をはしょって、受信するリクエストも4行と簡略化して、スケッチに従って1文字ずつ単純に処理するCPUの身になり、処理の流れを追ってみました。

以下、リクエストの処理の読解図です。クリックでpdfが開きます。
Photo_20230806091301

上記では矢印が多すぎてかえって分かりにくいかもしれませんが、大事な所は\nを受信した際の処理です。
\n受信で、行末判定とリクエスト受信終了判定が行われます。

\n受信での行末判定は、受信した行の\rの直前までの文字列がcurrentLineに入っているので、\n受信時かつcurrentLine.length()==0が成り立たない事で行の終わりと判断され、currentLine=""でクリアするだけで次の行の文字受信に移行します。

\n受信でのリクエスト受信終了判定は、リクエストの最後は\r\nだけの空行の受信となるので、一つ前の行末処理でcurrentLine=””のまま、\r\nの受信に入る事になり、\n受信時かつcurrentLine.length()==0が成立する事でリクエストの終了と判断し、レスポンス送信・GPIO操作・更新用HTML送信に移行します。

尚、受信した文字はそのまま文字列変数headerにため込んでいきますし、1行毎の可読文字(\r\n以外)は文字列変数currentLineへ取り込みます。文字列変数headerはGPIO操作にも使われますが、文字列変数currentLineは行末判定とリクエスト受信終了判定に使われるだけですね。

以上、ざっとした説明ですが、スケッチ1行1行の処理内容・流れが追えたので、やっと全貌が把握できた気がします。
やれやれでした。

スケッチで最初にインクルードされる WiFi.h に定義されているライブラリの説明が、以下参考(*3)にありました。
元のスケッチ内のコメントと綴りでだいたいの意味は分かりますが、一度きちんと見ておいた方が良いと思われます。

WiFiServer begin() WiFiサーバを開始
available() WiFiクライアントからの接続を取得
WiFiClient connected() ホストとの接続状態を返却
available() ストリームで利用可能なバイト数を取得
read() 受信したデータを1バイト読む
stop() ホストとのTCP接続を切断

ESP32をサーバー側として、クライアントPC・スマホとやり取りするのですが、ESP32側のスケッチ内にあるread()がWiFiClient側にあって、WiFiServer側にないのかとか、良く分からない部分もあるので、知っておくべきタイミングで調べる必要がありそうです。
この辺まで来ると、本当に詳細を知るのが必要な時に調べれば良いと思います。

 

HTMLの生成

上記まででほぼWi-Fi Lチカのスケッチの重要な部分は読解できました。
あと残りはサーバー側のレスポンスで更新用HTMLをクライアントへ送る部分で、HTMLとして一般的な文字列表示、ボタン配置、リンクの埋め込み、CSSでの見え方指定などで、本Wi-Fi Lチカの例もそうですが、比較的簡易なブラウザ画面構成を生成する部分と思います。

スケッチでは、client.println(”HTMLの各行”)を多数並べHTML各行を順にクライアント側に送信する形になります。
以下は、実際のスケッチのclient.println(”HTMLの各行”)の”HTMLの各行”部分だけを取り出し、そのままブラウザで見れる様に少し加工したHTMLファイルを作成し、PCで見たものです。
ブラウザの右クリックで「ページのソース表示」を選択すればHTMLテキストが見れます(Edgeの場合)。
Photo_20230809134601
注意:このブログにHTMLファイルを置いたので、ボタンを押しても/26/on等のLink先が無く、ココログ サーバーは「ページが見つかりません」とエラーを返します。
この時ブラウザのURL欄を見ると、末尾に/26/on等のリンク先が付加されているのが分かります。


下が上記のテキストで、<html><head><body>の順の一般的な構成です。
赤字の部分は実際にはESP32側のスケッチで処理する部分になります。

<!DOCTYPE html>
<html>

   <head>
      <meta name="viewport" content="width=device-width, initial-scale=1">
     <link rel="icon" href="data:,">

     <style>html { font-family: Helvetica; display: inline-block; margin: 0px auto; text-align: center;}
         .button { background-color: #4CAF50; border: none; color: white; padding: 16px 40px;
                       text-decoration: none; font-size: 30px; margin: 2px; cursor: pointer;}
         .button2 {background-color: #555555;}
      </style>
   </head>

   <body>
      <h1>ESP32 Web Server</h1>
      <!-- 以下GPIO26の現在の状態表示は、実際はoutput26State変数を表示させている-->
      <p>GPIO 26 - State output26State変数の中身</p>

      <!-- 以下はif文でoutput26Stateの内容によりどちらか選択して表示させている-->
      <p><a href="/26/on"><button class="button">O N</button></a></p>
      <p><a href="/26/off"><button class="button button2">OFF</button></a></p>

      <!-- 以下GPIO27の現在の状態表示は、実際はoutput27State変数を表示させている-->
      <p>GPIO 27 - State output27State変数の中身</p>

      <!-- 以下はif文でoutput27Stateの内容によりどちらか選択して表示させている-->
      <p><a href="/27/on"><button class="button">O N</button></a></p>
      <p><a href="/27/off"><button class="button button2">OFF</button></a></p>

   </body>

</html>

現在の状態表示の赤字部分は、実際にはESP32側スケッチでは以下の記述で、現在の状態を保持している文字列変数output26Stateの中身の"on"か"off"の文字列を表示させています。
client.println("<p>GPIO 26 - State " + output26State + "</p>");

ボタンの文字と背景色の赤字部分も、実際にはESP32側スケッチでは以下の記述で、リンク先・ボタンのクラス・ボタンの文字を、output26Stateが"off"か否かで、どちらかを選択しています。
// If the output26State is off, it displays the ON button
if (output26State=="off") {
    client.println("<p><a href=\"/26/on\"><button class=\"button\">ON</button></a></p>");
} else {
    client.println("<p><a href=\"/26/off\"><button class=\"button button2\">OFF</button></a></p>");
}

GPIO27の方も同様です。

IoT工作では、ブラウザ画面のボタンの色や表示内容を変えたり、ハードウェアの状態表示や、センサーから得た数値の表示を行う程度で、そんなに複雑なブラウザ画面にはならないと思いますし、HTMLの文法・構成等は一般的な内容です。
今回のWi-Fi Lチカのスケッチ読解の趣旨目的から少し外れるので、ざっとした説明に留めます。
もっと複雑な画面構成が必要な場合は、HTMLエディタ等でひな形を作成し、1行ずつclient.println()内に記述してクライアントへ送るか、文字列変数htmlbodyへ htmlbody += HTMLの各行毎記述; を繰り返し、文字列全体を作り一気に送るとかで、対応できると思われます。

 

読解を終えて

やっとほぼ読解できたと思います。
クライアントサーバー間のリクエストとレスポンスの形式、リクエスト文字列からのサーバー側処理内容の検出方法、HTMLのheaderやbodyの書式、など理解しESP32言語で必要な処理を記述すると言う、IoTならではの知識が必須なのを痛感しました。

今回読解したWi-Fi Lチカのスケッチですが、かなり理解が少し進みました。

ブラウザ画面にボタンを数個並べてクリックする事で、ESP32側でGPIOの操作等をするのが、IoT工作の第一歩でしょうし、そんなの常識、当たり前って言われる気もします。
が私にとってはES32を入手した約1か月前までは何にも知らなかった訳ですので、今回の読解でIoT工作の階段を一段登れたって感じでいます。

でも、まだまだ知らない事だらけでしょうから、今後も分からない事は、ネットの情報検索で先人達の知識や情報を借りながら、更に理解を深めながらIoT工作等をしていきたいと思います。

 

おまけ:高速化のあがきと顛末

実はこのWi-Fi Lチカは、ブラウザのボタンを押してから、体感で2秒程しないとLEDが変わらないもっさり感があります。最初の動画です。
スケッチの読解により、GETリクエストの1行目だけでやりたい事はできるので、残りの文字列全部の1文字づつの処理は時間の無駄に思えます。
最初の1行目の最後の改行を受信し終えたら、GPIO操作やブラウザ画面更新に移行してしまえば、応答が早くなるとは思いますが、リクエストの受信途上でサーバー側の処理を始めてしまうと、それはそれで、リクエスト・レスポンスのやり取りの同期が取れなくなり、見えないライブラリの内部処理とかで不都合が発生する気もします。
特に最初にクライアントと繋がった際は、一旦全部リクエストを受け取らないといけない気もしますが、今回のスケッチがクライアント-サーバーのやり取りの全てであるならば、今回のスケッチではリクエストの最初の1行目でしか意味ある処理はしていません。
ならば、無知な私に考えつくのは、1行目の\r\nを受信したら、レスポンス送信・GPIO操作・更新用HTML送信動作へ直ぐに移行させ、接続を切ってしまうスケッチにしたら、高速化できるのか? 不都合は生じるのか? 見えない内部処理からのエラーに見舞われるのか? など試してみたい気がします。ESP32だと手軽に試せますしね。
今のスケッチでも、接続時間が2秒をこえるとタイムアウトが働き、Whileループを抜け、client.stop(); で強制的に接続を切っているくらいですし、大丈夫な感じもします。

-----------------------------------------------------
2023-7-17 上記やってみましたが、特にエラーとかは発生しないものの、高速な応答にはならず、体感的には余り変わらないかな。
ボタンを押してももっさりLEDが切り替わる状況は変わりませんでした。
ハハハ 我 浅はかなり! まだまだ修行が足りません。

変更してみたスケッチです。
最初に\nを受信したら、currentLine ="" にして、リクエストの最後だと勘違いさせる方法です。

77行目が追加した部分。
Photo_20230717211901_20230806091501

シリアルモニタを見ると、IPアドレス表示後の、リクエストを返す部分には、1行目の GET / HTTP/1.1 や GET /26/on HTTP/1.1 等しか表示されないので、2行目以降のリクエスト文字列は見ていません。やった事は正しそうです。
Serial_20230717212201_20230806091501

比較のための元のスケッチでのシリアルモニタ画面です。2行目以降のリクエスト文字列も表示されています。
Motonoserial_20230806091601

-----------------------------------------------------
2023-7-18追記
参照したwak-techさんの記事にあった動画では、ボタンを押してからLEDが変わるまでの応答が早いです。
【ESP32】Wi-Fi経由でスマホからLチカ - YouTube
スケッチはタイムアウト処理がないくらいですが、コピペして実行しましたが、全く早くなりません。
それどころか、スマホのブラウザ画面では通信データ待ちのクルクルが回る状態になったりします。
しばらくしてから実行すると反応が早くなっていたりと、安定しません。
どうも、自宅のWi-Fi通信環境の問題な気がしてきました。
これとは別に、Freenove社へ質問しているので、回答来たらUpdate予定です。
今となっては、MACアドレスフィルターリングを止めてみろとか、Wi-Fi通信環境を調べるべきとの回答が期待かな。
-----------------------------------------------------
2023-7-20追記
Freenove社への質問は、「最初に\nを受信したら、currentLine ="" にして、リクエストの最後だと勘違いさせる方法」でも早くならないので、簡単で一般的な高速化のアイデアとかを問いかけたものです。
回答としては、「You can refer to chapter 30 of our esp8266 kit.」(esp8266 kitのChapter 30 を参照できるよ)だけで、以下の紹介を受けました。

https://github.com/Freenove/Freenove_Ultimate_Starter_Kit_for_ESP8266/archive/refs/heads/main.zip
 
以前の記事にも書いたのですが、Freenove社の各種キットのドキュメント・スケッチ類はフリーでダウンロード可能で、上記はFNK0073と思います
Photo_20230721090501_20230806091701

DLして出てきたスケッチ sketch_30.1_control_led_through_web.ino を試してみましたが、高速化されませんでした。

この結果は今の認識としては思っていた通りで、スケッチやESP32の処理の問題ではなさそうなので効果はありません。

------------------------------------------------------------------
しかし、このスケッチ、今まで試したWi-Fi Lチカ スケッチ(ブラウザ画面は以下、ボタン2つで、LED 2個をOn/Offのもの)と中身ほぼ同じでした。
1_20230713205601_20230806091701
オリジナルがどれなのか分かりませんが、世界中でほぼ同じスケッチを使ってWi-Fi Lチカのブログ記事やYoutube動画が発信されているんですね。
それだけお手軽で誰でもできるって事でなのでしょう。
------------------------------------------------------------------

別アイデアとして試したのが、MACアドレスフィルターリングの停止です。
停止させると、早い時は0.5秒位でLEDが切り替わり高速化されましたが、不安定で遅いときは2秒くらいかかりました。
やはり自宅のWi-Fi環境が原因の可能性が高そうです。
ははは、今のWi-Fiルーターは約8年前から使っていますが、MACアドレスフィルターリングで10台程度の機器をWi-Fiで繋いでいるので、性能が足りていないのでしょう。
3年程前にNifty光にした際にキャンペーンでもらっていたWi-Fiルーターがあるので、取り替えてみるのが良いかな。

 

  もっさり応答の原因はWi-Fiルーターでした   
2023-7-21追記
今日Wi-Fiルーターを更新しました。高速応答の効果が出ました。
ボタンを押してからLEDが変わるまで体感的には0.2秒程度、応答時間は大幅に短縮されました。
今までの2秒程度のもっさり感はなくなり、指で押して直ぐ反応、ストレスを感じません。
以下、動画です。

動画をWindows10のビデオエディターを使いコマ送りで変化点を追ってみました。
見たのは16秒過ぎ辺りで、ボタンを押した瞬間⇒LEDが点灯した瞬間⇒ブラウザ画面が更新された瞬間の順です。
コマが荒いのですが、ボタンを押してから LED点灯まで0.16秒、画面更新まで0.33秒 なのが分かります。
タイミングによって多少の時間差がありますが、最大でも0.5秒以内に画面更新までされるようになりました。

ボタンを押した瞬間16.50秒 LEDが点灯した瞬間16.66秒 画面が更新された瞬間16.83秒
1_20230726094701 2_20230726094701 3_20230726094701

ちなみに、77行のcurrentLine ="" を有効にしてみましたが、より早くなる感じはなく、ほぼ上記と同じ反応速度でした。
リクエスト全行の処理よりもWi-Fiルーターの応答速度が、もっさり応答の主因で間違いなさそうです。

Wi-Fiルーターの更新でインターネット通信速度も改善しました。
今まで100Mbpsを超える事は無かったのですが、超えるケースが出てきました。
Photo_20230726120301_20230806091901

Wi-Fiルーター起因は全く予想もしていない原因でしたが、更新により内外の速度が早くなり良かったです。
これで、サクサク動くESP32 IoT工作ができそうです。

 

続報あればまた。

 


参考
ESP32を使ってスマホからLチカ(LED点滅)する【webserver】 | Wak-tech
SimpleWiFiServer (fc2.com)
 └client.available()で、読み込み可能なバイト数を取得します。1文字以上読み取りできる場合は、client.read()で1文字読みます。
ESP32入門 通信機能が標準搭載されたマイコン・ボード (4) サンプル・プログラムを用いてWi-Fi経由でLEDのON/OFFを行う(2) - Arduinoクックブック (denshi.club)
・(*1)HTTP リクエストとレスポンスの形式に関する注記 | AppExpert (netscaler.com)
・(*2)ESP-WROOM-32でWebサーバーを作ってHello World!をする - Qiita
HTTPプロトコル (quu.cc)
「HTTPリクエスト」と「HTTPレスポンス」 | ITSakura
・(*3)https://garretlab.web.fc2.com/arduino/esp32/reference/libraries/WiFi/

 

2023年7月 4日 (火)

ESP32-WROVER-E PSRAM有効化

ESP32-WROVER-EでttBasicを使った際に、スケッチのコンパイル時のメッセージには、メモリの使用量が出ていました。

最大1310720バイトのフラッシュメモリのうち、スケッチが749337バイト(57%)を使っています。
最大327680バイトのRAMのうち、グローバル変数が46112バイト(14%)を使っていて、ローカル変数で281568バイト使うことができます。
との事です。
Compile_noerror

ESP32-WROVER-Eは8MBのPSRAMを搭載しているので、余りにも少なすぎます。

調べると、PSRAMをIDEで有効にし、setup()が開始されている事との記事がありました。
ESP32で外部ライブラリ等でのPSRAM割当制御 | Lang-ship
Photo_20230704214701

ttBasicをコンパイルする際に、Arduino IDE - ツール - PSRAM:"Enabled"のEnabledにチェックが入っている記憶がないので、おそらく原因はこれかなー!と言う事で、チェックを入れてコンパイルしてみます。

ESP32-WROVER-E アルティメットスターターキットでは、PSRAMを含めRAMを大量に使うはずのカメラを使ったアプリがあります。
その辺りのドキュメントをよく見ればヒントもある気がします。

今日は仕事で手がつかないので、明日続報かな。


2023-7-5追記
Arduino IDE(最新の2.1.1)ではPSRAM:"Enabled"が出てきません。探してもそれらしい所が見当たりません。
で、スターターキットのカメラアプリの357ページでは、以下の設定をせよとの事が記載されていました。
意味は良く分かりませんが、
Partition Scheme:Huge APP (3MB No OTA/1MB SPIFFS) を選択する必要がある様です。
Cameraserversample

Arduino IDEで同じ設定をやってみました。
Photo_20230705121501

コンパイル後のメッセージが出ました。
最大3145728バイトのフラッシュメモリのうち、スケッチが749337バイト(23%)を使っています。
最大327680バイトのRAMのうち、グローバル変数が46112バイト(14%)を使っていて、ローカル変数で281568バイト使うことができます。
Arduinoidecompile

単純にRAM容量が増えるメッセージは出ず、RAMに関しては変わりありませんが、フラッシュメモリの方の最大値が大きくなっています。
FLASHやPSRAMは、パーテーションやファイルシステム、作業用メモリ領域確保など、いろいろと使い方のバリエーションがありそうで、単純ではない様ですね、ははは!、まだまだ未熟で浅はかなり。。。以下参考。
ESP32-WROVER-Bで4MBもの広大なメモリ空間を手にいれる | kohacraftのblog
Use PSRAM (upesy.com)


続報あればまた。

 

2023年7月 1日 (土)

ESP32-WROVER基本スターターキット他購入と動作チェック

ESP32-WROVER-Eですが、以前買ったアルティメットスターターキットだけで、今まで幾つか回路を組んだりしてきましたが、マイコンボードもブレッドボードも1つしかないので、何かとやりにくさを感じる様になってきました。

ブレッドボードも回路が簡単に組めるのが便利で良いのですが、別の事をやろうとすると部品と配線を外す必要があり、一旦ばらしてしまうと、元の回路の再現には、また組み上げるのが必要になるので、なかなかばらせないおっくうさが付きまといます。

要は、1つしかないのがやりにくさの原因なので、買い足せば不足感は解消し、いろいろ同時並行的にやり易くなるはずです。

と言う事で、どうせならGPIOエクステンションボードも手に入るし、カメラ等のパーツ類もブレッドボードも付いて、コスパ良しで安心なFreenove 基本スターターキットと、評判が比較的高めで大小ブレッドボードが2枚づつ入っているブレッドボードセットを買い足しました。


買った基本スターターキットです。
Photo_20230701202201

合わせて買ったブレッドボードセットです。
2_20230701202201


2023-7-6追記

2つのパッケージを並べた写真です。
Img_9550

箱を開けた写真です。
Img_9551
右のブレッドボードセットは残念ながら全体が収納できるプラケースが入っていませんでした。
アマゾンの製品レビューでは写真も多数掲載されていますが...まあ中?品質ってところでしょう。

箱から取り出して並べた写真です。
Img_9552

基本スターターキットにも一通りのものが入っています。
Img_9553

自宅Wi-Fiへ繋ぐためMACアドレスを調べ、Wi-Fiルーターに登録し、ttBasicを入れて動かしてみました。
Photo_20230706140401
Wi-Fiも繋がり、ttBasicも走り、ESP32の動作が確認出来ました。

これで、ESP32-WROVER-Eの工作環境が2つになりましたし、ブレッドボードもジャンパー線もタップリです。
いろいろとやれそうです。


続報あればまた。

 

« 2023年6月 | トップページ | 2023年8月 »