ESP8266/ESP-WROOM-02/ESP32あれこれ

運用・記事アップ遅延理由

　本来ならモノとプログラムができていれば、即、運用に入り、早ければ運用と同時、遅くとも運用直後にはアップする記事。

　にも関わらず、今回、2023/11/21に思い立ち、2023/12/30にスケッチ完成、モノもほぼ完成しながらも、稼働はそれから2ヶ月以上経った2024/02/13...、更に、それから2ヶ月以上経った今日、記事をアップ...。

　その記事がこれ、自作スマートロック。

　時間がかかったのは、長年に渡るGoogleのお告げへの対策にいい加減、辟易したから...。

　この前後から顕在化していた2度に渡るGoogle検索エンジン検索結果順位だだ下がり(今回は特にCLS)対策と結果待ち2ヶ月、CLS値改善・解決後、順位が回復してきたものの、そこまでのようで1〜2キーワードでトップだったワードもことごとく、戻ることなく陥落...。

　それも解決してみれば、原因はGoogle Adsense(記事量に応じ、サイズ不定でGoogleが自動挿入する任意の数の広告)や埋め込んだYoutube動画...、原因が自社製品ならそっちでなんとかしてくれ状態で更にゲンナリ...。

　より上位にあるのは、ちょっとやり過ぎ感のある以前、Googleがペナルティと言っていたようなSEO対策を施したページばかりだったり...。

　中には、なぜか、とある製品の製品名1語のキーワードで当サイトのレビュー記事がトップだったものもあり、その後、メーカーのページや大手ネット通販のページがより上位になったのは、納得中の納得ですけどね。

　似たようなことは、半年とか1年ごととか、なんだかんだと、しょっちゅうあって対処したとしても、その影響からの回復に数ヶ月以上かかり...。

　つまり、年中、泣いてるGoogleの子守が必要な一方、泣きたいのはこっちみたいな状況...。

　多かれ少なかれ、どこのサイトもそうかとは思うものの、多すぎ、かまってちゃん過ぎ...。

　数時間後にはインデックスされ検索結果に表示されるBing系の検索エンジンよりはだいぶ遅いながら、以前は1日もあればインデックスされていたGoogleも、今では月単位が当たり前。

　そんな中、もう少し早くインデックスされていた頃でも、こりゃ、世界初でしょとか、稀有でしょとか、一刻も早くアップしたい！見てほしい！とか、新鮮さこそが重要！といったような気張った記事に限って数ヶ月経ってもインデックスされなかったり...。

　タイトルが日付になってしまって調べて即、対処したものの、既に1年半とか2年とか経過、それでも未だ改善されないページが2件ほどあったり...。

　嫌がらせなのかって...。

　前も後述するような結構な期間ネガティブSEOが検索結果に大量に表示されてるとトップページで指摘をした翌日には、検索結果からネガティブSEOが激減したりとかあって、書くとGoogleに証拠隠滅されそうだけど、例えば、検索結果上、タイトルが日付になってるのは、

　「debian wine 7.0 kindle」でトップに表示される「2022/09/03」とか...、「raspberry pi 28byj-48 パン チルト」で表示される「2022/05/04」とか...って、これ、同時に上げたからタイムスタンプは同じにしても、このタイトルで2ページある...。

　前者は、当時、「wine 7.0でkindleが読めない」という情報が乱立、解決策が見当たらなかったため、これは朗報でしょ！と書いた記事で、その頃は[debian]の代わりに[linux]でも、バージョンである[7.0]を入れなくても検索結果でトップでした。

　後者は、当時、[Raspberry Pi]において[Python]で[Flaskサーバ]を使ってステッピングモータ[28-BYJ-48]で[カメラ]を[パン][チルト]するという情報が皆無だったためアップ。

　そもそも28BYJ-48は有名なのに動作確認ばかりロボットアームの作例程度で実用例が少なかったため、自作ロールカーテンや普通のカーテンをスマート化する際に使ってみたりと28BYJ-48の使いみちを常々考えてたりするんですよね。

　何れにせよ、タイトルが日付なんて全く、興味もそそられない記事、トップに表示されたとしても、そうじゃなければ尚更、誰が読みたい？読みたい人どれだけいますかね？

　途中、Googleのアルゴリズムで人によって表示結果が異なる仕様になったこともあったものの、それより前の話だったと記憶しています。

　確か当時調べたところ、「タイトルに占めるアルファベットの割合が多すぎる(日本語が少なすぎる)」のが原因とあり、マイコンやパーツに焦点を当てれば、自ずとそうなるでしょと納得いかなかったものの、一応対処しつつ、他にタイトルに重複がないことも確認したものの、1年半以上経った今も変わらず...1ヶ月も経った時点で鮮度も落ちて意味もないので以来放置。

　Googleについては、それまで上位表示されて訪問者数も多かったページの順位が大きく陥落して内容的に関連の薄い自サイト内の他のページが検索結果の2〜5ページめ程度に表示されていたり...。

　Bingについては、最近、Googleのエンジン使ってる？と見受けられる現象があったり、比較的上位表示されていて訪問者数も多かったページに限って原因不明のインデックス削除が起きたり...。

　もちろん、過剰なSEOを施しているわけでもなく、他のページとも遜色ないのに(むしろ、もう10年以上？SEO対策には無関心で自身の雛形に沿って思いのままに記事を書くことに専念)。

　今でこそ、Alexaとかも出てきますが、Googleで[raspberry pi スマートスピーカー]とか検索すると、当初は、[Google AIY Voice Kit]ばかりでAlexaや微妙に違うけどJuliusやOpen JTalkを使ったページは、5ページめあたりにあれば良い方みたいな状況でGoogleの恣意的なものを感じることも多々あったり...。

　他にも逆SEO|ネガティブSEO(他社・他者のサイトと無縁の無駄なページからリンクを張ることにより、検索エンジンに質の悪いページ・サイトと認識させることで検索順位を不当に下げようとする手法)もあって、わざわざ被害者が詳細調べてGoogleに報告しないと対処されないという...。

　その報告件数だけでも重複チェックもした上で既にドメイン数が1200件超えてたり...。

　ってか、今なら芸能人の詐欺目的のニセ広告動画じゃないけど、Google側でわかるだろうし、排除できるっしょ...。

　どこの地域に住んでるかもわかって地域も併せて検索結果に表示してるし、地域によって、人によって結果変えたり、順位つけられるほど、どれほど情報搾取してんだよってほど調べ上げる技術あるんだから...。

　それとも、あえて排除してないの？もしかしてブログとか雛形のあるレンタルサイトと違ってHTML/CSS/JavaScriptで一から起こしてるサイトの場合、Googleのアルゴリズムの思惑通りにならない？から、ネガティブSEOしてる方じゃなくて、そういうサイトを強制排除するためにGoogleが逆SEOやってる？とか勘ぐりたくもなるよね...。

　何れにせよ、どれもこれも放っとけば尚更、その悪影響は無期限に続くという...。

　そんなこんなで記事を書く気になれず、アップするのが、今日に至った次第。

ESP32に妥当なArduino IDEボードリストからボード選ばないとエラーになる

　Raspberry Pi 400パソコン(arm64)におけるArduino IDE(1.8.19)でESP32ボードに書き込みをしようとしたら以下のエラーに見舞われ、結果、Arduino IDEのボード選択時、2種類あったリストの一方から妥当なボードを選択することでエラーを回避できた(他方のリストから選ぶと各種エラーに見舞われた)話。

['class WiFiClientSecure' has no member named 'setInsecure']

　Arduino IDEの[ファイル] => [環境設定]の[追加のボードマネージャのURL：]においてESP32用に指定するURLとして[https://dl.espressif.com/dl/package_esp32_index.json]から[https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json]に変更しないとうまくいかなくなったことがありました。

　これとは別にボード管理画面におけるアップデートでだと思いますが、いつしか、Arduino IDEの[ツール]でボードを選択する際、ESP32については、[ESP32 Arduino]と[ESP32 Arduino(in sketchbook)]の2つのリストが表示されるようになりました。

　今回、この内、[ESP32 Arduino]からESP32のボードを選択しないと([ESP32 Arduino(in sketchbook)]から選択すると)先のエラーに見舞われることが判明しました。

　自身は、以前、dynabook/DebianをメインにArduino IDEを使っていたこともあり、ある時、これとは逆のリストを選ばないとうまくいかなかったケースがあった記憶があります。

　よって常にどちらが正解ということはないのかも？と思っています。

　こんな経験をもつ自身でも、今回、これに起因するのではと思うまでにかなり時間を要しました。

　実際には、websocketのスケッチでこれに遭遇し、webSocketEvent関数のswitch case文でWStype_*の各種case文が不足しているエラーにも見舞われ追加しましたが、先の正解リストからボードを選択していれば、これがエラーになることもなかったでしょう。

　違うwebsocketのスケッチをアップしようとしたら、やはり、webSocketEvent関数のswitch case文でWStype_*の各種case文が不足しているエラー、そう言えば、returnが必要なのに条件分岐であてはまらない場合のreturnが欠如していてelse文を追記することで対処する必要もありました。

　よって、これらについては、ボード選択リストの違いではなく、Arduino IDEのエラーチェック性能が向上したようです。

Arduino IDE 1.8.10以降も使えるようになった

　あれ、ESPボードだけArduino IDE 1.8.9含む以前のバージョンでしか、まともに使えなくなっていた問題、いつの間にか解消したっぽいです。

　1.8.19と2.0.0で確認済み。

　2.0.0入れたからじゃないよね？

Wi-Fi 6/Bluetooth 5対応ESP32-C6

　時代は、Wi-Fi 6(IEEE 802.11ax)かー、ってESP32は？と思ってたら、もう8ヶ月も前にWi-Fi 6/Bluetooth 5対応ESP32であるESP32-C6のリリースがアナウンスされていました。

　技適は？と思ったら、そもそもESP32でもS2やS3、C3、C6など複数種類ある...ESP32の開発ツールに入っているesptoolは古くESP8266とESP32、ESP32S2の3種類しか対応していませんなんて話もあるので、まだまだですかね。

開発ボードESP8266とESP32の電圧・電流

　ESP8266(ESP-12Eベースとか)とESP32の開発ボード、後者の方が、内部(GPIO出力にかかる)電圧が高め、それとも電流が多めになる？チップやボードにもよる？

　というのも順次実施しているESP8266からESP32への移行、今回、サーボによる壁スイッチ切り替え(スマートスイッチ)用のボードをESP32にしたのですが、ESP8266と同じスイング角度だと勢いが強すぎるのか、まさか振りが大きくなるのか、大げさに言うとスイッチに対して食い込み気味になったのです。

　これにより、時に平然と、時に基準位置へ戻るのに時間がかかったり、時にスイングが基準位置へ戻らないこともあったりし、フリーズ、ボードリセットか電源を再投入しないと機能しなくなる事象が続発。

　いろいろ試した結果、といっても最初からスイングの勢いや角度に的を絞っていたわけですが、これを(今回は3度ほど)小さくすることで安定した次第。

　ESP32の方が体力有り余ってて元気ってことですよね？

TG0WDT_SYS_RESET

　ESP32-CAMでdeep sleepで遊んでいたら、シリアルモニタ上でTG0WDT_SYS_RESETがエンドレス表示され、最終的にサンプルスケッチCameraWebServerをアップしたら動作するようにはなったものの、deep sleep系の設定がまだ何か残っているっぽい話。

　外部リセット(ext0/ext1)やタッチセンサで復帰できないかと思い、外部リセットを試すべく、サンプルスケッチExternalWakeUpにesp_wifi.hやdriver/adc.hをincludeし、esp_wifi_stop()や非推奨となったadc_power_off()の代替adc_power_release()などを追記、当該スケッチのフォルダにcamera_pins.hのついでにcamera_index.h、デフォルト画面設定をいじるべく追加したcamera_index1.h/camera_index2.h、更にapp_httpd.cppをコピーしてアップしたりしている内に首題のWDT系リセットが連発することに...。

　逆にesp_wifi_start()や非推奨となったadc_power_on()の代替adc_power_acquire()を入れてアップしても、オリジナルのdeep sleepを入れていたESP32CAM用スケッチや素のExternalWakeUpをアップしてみても改善されず、TG0WDT_SYS_RESET連発、結果、CameraWebServerをアップしたら解消されました。

　ただし、Brounoutエラーが出るようになったのでこれを回避すべく、CameraWebServerにもsoc/soc.hとsoc/rtc_cntl_reg.hのincludeが必要でした。

　更に以前は、そのままでもアップ・実行できていた外部スイッチとすべく、接続していた人感センサーを付けたままにしておくとBrounoutが発生することがわかり、これらを外すことでbrounoutが解消。

　また、当初動いてはいたオリジナルのdeep sleepを入れていたESP32CAM用スケッチは、その後もTG0WDT_SYS_RESETされる状態に。

　そもそもTG0WDT_SYS_RESETの症状に見舞われた情報は多数あるも原因がイマイチはっきりせず、決定的な解決策を見いだせない中、URLを失念しましたが、(ESP-IDFで言うところの)「sdkconfigの中身をボードに応じて一から設定するしかない」というのが、本命かなという気がしています。

　これらのことから、brounoutの回避は要しつつも、TG0WDT_SYS_RESETされることなく、CameraWebServerは機能するようにはなったものの、adc_power_*系をいじってしまったことでbrounoutとか電源系設定などボード上の何らかの既定値が変更されてしまって、そのままになっている可能性がある？かなと思っていますが、これいかに。

　おっと、各種エラーの原因は、超シビアな配線だった模様、特に5V/GNDに挿すジャンパワイヤ...、ESP32-CAMに限ったことではありませんが、熱で微妙に溶けるのか、いつの間にかユルユルになってる気が...ジャンパワイヤを替え、連結していたものも1本にしたら絶好調。

Arduino IDEのボードに[AI Thinker ESP32-CAM]が追加

　いつの間にかArduino IDEのボードに[AI Thinker ESP32-CAM]が追加されており、ESP32-CAMにおいては、従前の[ESP32 Wrover Module]ではなく、これを選択することになっています。

　これに伴い、ESP32-CAMで修正したようにボードには、[AI Thinker ESP32-CAM]を選択、プログラムのアップロード時も入力は、3.3Vではなく5V、フラッシュメモリの選択肢はなく、NO OTA...云々を選択する必要はなくなりました。

　これにより期待通り、ESP32-CAMではこれまで使えなかったArduino OTAも使えるように(まだ試してはいませんが、シリアルポートの選択肢として検出され、表示されるように)なり、[AI Thinker ESP32-CAM]ボード用サンプルスケッチにはArudinoOTAもあります。

　メモリ使用量が減ったからか、以前に比し、しばらくストリーム再生していてもチップ自体は、それほど熱をもたなくなった気がします。

　尚、PCだとUSB経由で最大でも電流500mAという上限ゆえでしょう、OTAを加えた程度では大丈夫ですが、更に機能追加したりすると場合によっては、解像度を下げても映像遅延が目立ちますが、1A以上対応のUSB接続ACアダプタでコンセントに接続すると全くと言ってよいほど遅延なく映像再生できます(これは以前からですが、mDNSでmDNS.localアクセスも利用可)。

　久々にESP32-CAMを使ってみようと思ったら、アップロードすらできず、ビックリ、まさかと思い、ボードを見ると新設されてる...、その後、試行錯誤、アップ時、5V入力でなければならないことに気づきました。

　なんかわかりやすい周知方法があると良いのにね。

Arduino IDEでのESPボードの不具合

　先日、Arduino IDE 1.8.16がリリースされていたので、これまで同様、他のバージョンと使い分けられるようダウンロード、展開しました。

　が、相変わらず、ESP8266/ESP32ボードだと[ツール]内のオプション選択において全てデフォルトが選択されていない状態が続いています。

　選択すれば、表示されますが、表示されないだけで良き値にデフォルト設置されているのかも不明、ESP8266/ESP32ボードをつなぐ度に全て設定するのも面倒なので遡って使えるArduino IDE 1.8.9を使っていますが、なんででしょうね。

　特に検索はしていないのでなんですが、Linux版だけの現象なのか、インストールしていない場合だけに起きるのか、両方なのか、そうした情報を目にしたことは1度もないんですよね...。

ESP32 on Arduino IDE 謎のエラー再発

　ここ数日、ESP32でもArduino IDE 1.8.13が使えていたのですが、解消されたかに思われた謎のエラー再発、しかも最初のArduino IDE 1.8.9まで遡らないとダメな状態に。

　ライブラリの更新をした記憶はある一方、ボードの更新はしてないと思うのですが、気のせいか...。

DNSのリセット

　ESP8266/ESP32でホームオートメーション化している各家電のブラウザ操作パネルには、Androidからは使えないのでIP直指定もパソコンからは、mDNSを利用していますが、何かの拍子に一部の家電用のみ異なるネットワークアドレスのIPアドレスとmDNS.localが関連付けられてしまうという事象に遭遇しました。

　SoftEtherのだったのかな？

　これは、avahi-daemon.socketやavahi-daemon.serviceをsystemctl restartしても解消されませんでした。

　今回は、ESPボードのリセットボタンを押すことで事なきを得ましたが、外出時、VPN越しにこうなった場合には、物理的なボードのリセットボタンに代わる手段が必要じゃんか...。

　一瞬、例えば、esp32のハードウェア的な強制リセット方法のようにESPボードのENピンを使ってソフトウェア的にESPボードをリセットしないとダメかなとも思いましたが、avahi-dnsconfdなるパッケージを発見、これでDNS情報をリセットできそう...ということでapt install。

　冒頭の事象を再現できないので異なるネットワークアドレスのIPに関連付けられてしまった場合、mDNS.localがちゃんと振り直されるのかは未確認ですが、manを読むとどうやら、avahi-dnsconfd -rでいけそうな予感。

　各ボードのスケッチ・回路共にいじるのは、面倒なのでavahi-dnsconfd頼むよー。

　っていうか、いざ、VPN越しの操作時になって再現してしまった場合、困る...から、avahi-dnsconfd頼むよー。

　avahi-dnsconfd -rで済む場合もありそうですが、IP固定していないとダメなケースの方が多そうです。

　今回は、ESPボードではなく、Raspberry Piでネットワークアドレス違いのIPが割り当てられました...。

　ルータでIP固定範囲を決めておき、/etc/dhcpcd.confで[interface eth0]/[static ip_address=IP_Address/Network_Address_bit]/[static routers=IP_Address]を、念の為、更に[static domain_name_server=DNS_IP_Address]を設定後、systemctl stop dhcpcd/systemctl daemon-reload/systemctl restart dhcpcdするか、マシンを再起動、起動したら、avahi-dnsconfd -r。

　指定が間違っていない限り、ここまでやれば、xxx.localで確実にアクセスできました。

　というか、IP固定したので以後、ネットワークアドレスを取り違える事自体ないでしょうが。

　ESP8266/ESP32/Raspberry PiでもとなるとPCでもありえるのかな！？そもそもなんでこうなるんだろ...。

　そもそもSoftEther VPNの影響だったようで対策したら異なるネットワークデバイスにIPが関連付けらることはなくなったようです。

　が、別の問題が...。

　スマホからVPN接続した場合、LAN内の端末へのSSHやVPNサーバ以外へのVNCもでき、ZoneMinderによるカメラ映像もスマホのブラウザ越しに確認できますし、AndroidゆえにIP直指定してあるブラウザショートカットで家電操作パネルを表示させていて操作できていますが、ブラウザショートカットの内、常に同じIP直指定の2つだけ、たどり着けないアドレスと判断され開かない...。

　VPNをやめると全てアクセスでき、IPもVPNの接続前後で変化はないのに。

　mDNS(mDNS.local)が一部認識できないなら、まだわかるが、スマホで、かつVPN接続したときだけ、なぜ、同じネットワークアドレス内で、たどり着けるIPとたどり着けないIPがあるのか...もちろんルータで除外している割り当てられるはずのないアドレスというわけでもないのに。

　ちなみに1つは、Websocketでペイロードを受け取る方法、もう1つはWebサーバとして指定パスにアクセスすることで特定機能を実行する方法ですが、何れの方法についても他のパネルは表示されているので実装方法とは関係なさそうです。

　何れも2つあるアクセスポイントの内、古い方の無線LANルータに、他方にスマホがつながっていますが、同じく古い方につながっている複数の他のデバイスにはVPN越しでも、VPNなしなら何れにも接続できていますし、以前減らして調整したりもしたので推奨接続台数を超えているということもないと思うのですが...。

　VPN再設定後、スマホの再起動もしてみましたが、変わらず、同じ状況です。

　っぽい気もしなくもないものの、これに関しては、VPN側に起因するのか否かすらよくわからず...謎...。

　DHCPサーバかな...、VPN接続前も後も仮想DHCPサーバを使わなければ、ルータのDHCPサーバ使うんだよね、だとしてVPN接続後の方が、DHCPサーバが道に迷いやすくなるってことあるのだろうか？

　ONU/ルータからスイッチングハブを介して、それぞれ有線接続している2つのアクセスポイント(WiFiルータELECOM WRC-300FEBKとELECOM WRC-1167GS2-B)のLANケーブルの接続が甘かった(接触不良の)可能性？

　ギガハブが原因か？と思い、スイッチングハブを以前使っていたメガハブに替えてみると、また、ギガハブに戻してみると比較的良好となったので...。

　とは言え、IPが振られなかったデバイスにIPが振られるようになったわけではなく、アクセスしづらく時間がかかっていたものが、だいぶ改善されただけですが。

　尤も何れのアクセスポイントを介していても常に正常にIPが割り当てられている端末もありますし、スイッチングハブは、ほぼいじることがない場所にあるので釈然とはしませんが。

　数日前、つながりにくいと思われた2つは、異なるIPが振られていることが判明、変更後は、VPNの有無に関わらず、接続可能となりました。

　というか、IPが変わっているかの確認も都度しているつもりですが、LAN内のIPやホスト名、ベンダ名等を列挙してくれるスマホアプリやnmapに表示されないこともあって厄介。

　スマホアプリには表示されない一方、nmapに表示された正体不明なIPをavahi-resolve -aしても、avahi-resolve -nにめぼしいmDNS名を渡しても解決できず、正体不明なIPでブラウザ越しにアクセス、ESPガジェット操作用パネル表示の確認を試みても表示されず...。

　IP反映に時間がかかっているのか、IPが振られていないのか、IPとmDNSの関連付けができない、もしくは、関連付けに時間がかかっているのか、特定が難しい...。

　あと、これはイレギュラーでしょうが、自身は、寝る時、メインルーター以外は、スイッチングハブ含め、下流の電源や各ガジェットの電源をOFFにしており、OFFし忘れたESPガジェットだけ電源ONのまま、翌朝、上流の電源含めONすると一晩中ONだったESPガジェットにはIPが振られず、OFFしてONしなおすとすぐにIPが振られたのですが、これって当たり前？

　以前から、たまにOFFし忘れることはあってガジェットの電源を入れ直すまでもなくIP振られて普通に使えていた気が...。

　そうでなくともいくつかある内、1つだけアクセスできないな...という場合、そのガジェットの電源を入れ直すとすぐにアクセスできることも...。

　デバイスによって、まだ微妙にアクセスが遅かったりすることがあるのは、古いWiFiルータ、1度、一瞬だけも急に全てダウンしてつながらなくなったことがあり、壊れかけているWiFiルータの先にIPを配布しようとしてDHCPが混乱している可能性もある？

　もしかして交換すべく新たに買ったつもりが、まだ使えるかなと5年超経った古いのを継続して使った為、結果、買い足しとなったのですが、古いのは引退させるべく、新たにWiFiルータを買えば、解決する可能性もあるのかも。

　というわけで接続台数36台というWi−Fi 5 ルーターを買ってみました。

　今回買う数ヶ月前に買ったWi-Fiルータには、同じELECOMながら古い方のWi-FiルータWRC-300FEBKと違ってアクセスポイント自体にIPが振られるもので、このIP割り当てがDHCPになっていたところを固定IPにしたら、見失うことも、迷うこともなく、遅延しなくなったのか、従前通り、IPが漏れなく正常に自動配布され、安定したように感じるのは、気のせいじゃないはず。

　ただ、買った直後はというか、3ヶ月ほど前に買ってから、少なくとも1ヶ月程度前までは、こうした事象は出てなかった気がしますし、もちろん、固定IPからDHCPに変更したというわけでもないはずなのですが...。

　何れにせよ、とりあえず、これで既存のアクセスポイントとしているWiFiルーター2台とVPNに問題はなさそうなことはわかりましたし、無線接続台数がギリギリだったことに変わりはなく、今回の件にも無関係でもなさそうなので改めて余力あるWi−Fiルーターを追加購入したことにも意味はあると。

　というわけで今時点、アクセスが不能というガジェットはなくなりましたが、アクセスに失敗することがあるESPガジェットがあり、これが特定のものではなく、任意で他のガジェットに順次アクセステストをしている間にアクセス可能になったり、普段は、素早く表示される操作パネルのページでも表示されるまでに結構な時間がかかるというIP割り当て遅延のようなことが起こるんですよね。

　2つ、後述の1つ加え、3つの内、特定のアクセスポイントに接続しているものというわけでもない...。

　特定の状況下でというわけではないですが、ただ、ノートPCをサスペンドから復帰したあとなどは、必ずと言っていいほど、そうなりますね。

　次に一昨日買った激安ながら高性能を謳う、Amazonレビューも多く、高評価が目だつ5GHz/2.4GHz:1300Mbps/600MbpsというTP-LinkのWi-FiルータArcher C80が届いたので、いろいろやってみました。

　が、ファームウェアアップグレードをして検証機の目の前に置いても、より遠くにある手持ちの867Mbps/300Mbps ELECOMのWi-Fiルータより遅く、謳い文句は眉唾っぽい、初期設定時の挙動は、中華品質、せめて接続台数36台は真実であってほしいと願うばかり。

　既存のWi-Fiルータを止め、このSSID/パスフレーズを使ってTP-Linkのをアクセスポイント(静的IP＆DHCP無効)としてやってみた結果、IPアドレス配布に関しては、わずかに差があるようなないような、何も変わらないようななのでWi-Fiルータや接続台数に起因するものではなさそうです。

　ん？IPリース時間の兼ね合いがある可能性を考えるとDHCPサーバを初期化しないとわからないか？初期化ってできたっけ？DHCPの使用する・しないを切り替えれば、実質初期化か？

　もちろん、メインルータのDHCPサーバにおいて配布可能なIPは、使用台数の10倍以上の200ほどあり、足りないなんてことはないので4時間ほどに設定してあるリース時間も問題はないはず。

　どっかに間接的にボトルネックになるところがあるのかな...。

　ちなみにメインルータは、かれこれ5年ほど利用しているONU込みのNTT PR-400KIですが、これのDHCPサーバ云々じゃないですよね...。

　んー、なんだろう...。

　試しにDHCPサーバを初期化して既存Wi-Fiルータを停止、このSSID/パスフレーズでTP-LinkのWi-Fiルータをアクセスポイント化してやってみたところ、直後だからか、mDNSが混乱、チグハグになったり...、今、アクセス可能だったガジェットが、アクセス不可になったり...、パソコンからアクセスできるガジェットにスマホからはアクセスできなかったり...むしろ、状況が悪化...、なんだこれ...。

　と思ったら、しばらくしたら落ち着いてきましたが、やはり、Wi-Fiルータを入れ替える前と変わらない...。

　いや、アクセス不能は別として、どっちもアクセスできるまでにタイムラグがある場合でも、わずかながらにアクセスできるまでの時間とかアクセスが成功する数が違うかな...、んー、だとしても、たまたまなのかな...、気のせいかな...。

　Avahiも関係あるかと思い、探したら、情報少なっ、http://www.avahi.org/にリンクのあるhttps://github.com/lathiat/nss-mdns、Wikipedia、あとはDBusプロジェクトの一部になったり、分離されたりとかいう情報はあるも元ネタに親しく豊富な情報はなさ気...。

　ただ、収穫もありました、それは、https://github.com/lathiat/nss-mdnsにあるglibcのコマンドgetent。

　端末でgetent hosts foo.localとするとIPアドレスとfoo.localのペアを表示してくれる。

　今まで、この目的には、avahi-resolveを使っていましたが...、とは言え、精度は同じ、もしかすると、詰まるところ同じなのかも？

　あ、見えてきたかも...複合要因もありますが、まず、例えば、夜間など何らかの理由でWi-Fiルータ含む上流やIoTガジェット(デバイス・無線子機)の電源をOFFしている場合、Wi-Fiルータ含む上流から電源を投入、上流が、しっかり、待機状態になってから、IoTガジェット(デバイス・無線子機)側の電源を投入すること、即機能することもありますが、1分程度までは待ってみること。

　これで電源投入初期においては、IPが振られないとか、mDNSアクセスできない問題が解消するっぽい。

　というか、アクセスポイントは無線子機からのアクセスを待つ場所であり、アクセスポイントから無線子機ではなく、無線子機からアクセスポイントに接続に行く、基本、無線子機は、電源投入時にもアクセスポイントに接続に行くので、その時点でアクセスポイントの電源が入っていて待機状態にないと接続できないという機会の損失が起き、せっかくの接続チャンスを逃すことになるので先立ってアクセスポイントの電源が入っていることは重要ということですね。

　ただ、とあるアクセスポイントの接続範囲内にあるか否かで接続/切断するような無線子機の場合、位置情報やスリープからの復帰、電源の再投入(再起動)などにも接続のチャンスはありますが。

　そうした設定のない無線子機の場合でもLAN内で運用する子機の場合には、DHCPによるIPアドレス配布時点、AvahiやBonjourが機能するのであれば、IPアドレスが付与されたら、mDNSと関連付けが行われる時点にも居場所を特定でき、LANに参加できたことで無線子機が知っているアクセスポイントがあれば、その範囲内に入ったことにもなるわけで。

　この時、LAN内の居場所は知っているのでブラウザ操作パネルなどから操作される前提でWebサーバが実装された無線子機(のmDNSアドレスやIPアドレス)にアクセスした場合も電源投入時同様、無線子機からアクセスポイントにアクセスにいくようになっていれば、この時にも接続チャンスがあるわけですよね。

　よって電源の投入順が違ったとしても他にも接続のチャンスがあるので端末を含め、LAN上の機器の故障、ルート断絶でもない限り、全く接続できなくなることはないはずということになります。

　ただ、このブラウザから操作するケースにおいて、スマホ(やタブレット)かパソコンかによって挙動が異なるようです。

　スマホ(AndroidゆえIP直指定)なら、スリープからの復帰後含め、電源投入順を守ることでスムースに事が運び、問題解消されます。

　一方、パソコン(Avahiが機能するゆえmDNS)の場合、電源投入順通りに行ない、無線子機をつないだ、その時は順調なのですが、サスペンドからの復帰の際、多くは、即機能するのですが、特定の2つほどスムースではないものがあり、1つは、何度かアクセスを試みれば、もう1つは、更にもっとアクセスし続ければ、機能するという感じ...。

　となるとIPアドレスは払い出され、割り当てられているということなのでDHCPサーバの問題ではないことが、はっきりしたことになるので、mDNSに関わることのようです。

　あ、より多くアクセスを試みないとなかなかアクセスできなかった1つは、サスペンドするまでもなく、しばらく操作せずに放置したあともアクセスしづらく、時にボードをリセットしない限りアクセスできないという状況に...。

　mDNS...、avahi...、パソコン...、サスペンド...、パソコンでもサスペンドからの復帰後でも即機能するESPガジェットもある、というか、その方が多いわけで...、となるとmDNS...、avahi...、んー。

　リセットを要することもある方のESP8266ボードはボードの不具合かなと思いきや、mDNSに影響のある不具合って...、んー...。

　アクセスポイントを変えたら状況が変わるか？とスケッチを改めてアップロードしようと思ったら、CP2102/CP2109として認識されるはずが、このボードだけUSB機器として認識されないからアップロードできない...が、電源は入り、既存のスケッチの実行には問題なく、機能はする...、同じUSBケーブルでも他のボードは認識されるのでUSBポートやUSBケーブルの問題とかではない、となるとボード上のUSBソケット部周辺におけるデータ通信線の断線か？

　事前・事後ともIP直指定ではいけるわけだからmDNS側でのキャッシュした内容の違いの影響ではない...。

　mDNSアドレスとIPアドレスの割り当て遅延...、キャッシュ欠落の可能性、Avahiが一部のIPアドレスを見失うことがある...？、これの合併症？か後者のみに起因する？後者のみだとしたら、それは必然？バグ？、必然だとしたら、どんな時...？

　avahi.orgやリンク先をたどったり、man avahi-daemon、less /etc/avahi/avahi-daemon.confとかしてもキャッシュ欠落というか、どうキャッシュしているのかさえ、また、IP発見メカニズムも見えてこない...詰んだか...。

　ESP8266ボードの手持ちはないし、技適問題もあるので今更、新たに調達するものでもないですし、手持ちのESP32ボードでやり直して...ボードに起因する可能性の有無を検証するしかないか...、仮に特定ボードに起因するなら、これで解消するわけで。

　というわけでESP32ボードに替えてみたら、パソコンでのmDNSによるアクセスにおいて通電時、平常時、サスペンドからの復帰時も問題なく、アクセスできるようになりましたとさ...。

　しかも、他のアクセスも軒並み迅速、電源投入順に神経を使う必要もなくなり、従前と同等以上に快適になりました。

　ただ、もう1つ、稀にアクセスが遅くなるが、何度かアクセスすれば到達できるESP8266ボードもスムースにアクセスできる時もあれば、できない時もあり、できない時は、他のアクセスも遅くなることから、これも壊れているのかもしれません。

　まぁ、残っているESP8266をESP32に移行しようかと思っていたところだったので、ちょうどよかった、これ含め、あと2つ...手持ちがあるから良いけど、AliexpressのESP32相場、めちゃ上がってる...、従来程度に安いとこはセラー評価低い怪しげなとこばかり...と思いきや、検索クォリティが落ちたか？esp32だとそんな感じもesp32 devkitcとすると、まぁまぁ納得な感じ。

　結果、詳細はわかりませんが、ガジェットとして機能はするESP8266ボード(Wi-Fi子機)の何らかの障害(故障・不具合)が、IPアドレスの配布、つまり、DHCP、そしてmDNSアドレスとIPアドレスの紐づけ(、となると、たぶんDNS)にも影響していた可能性が高そうに見えます。

　ちゃんちゃん...。

　ちなみに代替したESP32ボード他、ESPボード7つ中、6つは、5年ほど経過した最古のELECOM WRC-300FEBKに、残るESPボード1つ、ラズパイ2台、パソコンやスマホ他は、3ヶ月ほど前に買ったELECOM WRC-1167GS2-Bに接続しているわけで誇○広告気味なArcher C80はもとより、代替・追加のWi-Fiルータ、まだ要らなかった...。

ESP8266/ESP32設定項目 on Arduino IDE

　というか、Arduino IDEでESP8266/ESP32ボード選択時の設定項目が激増してる...、OTA用のメモリ確保前提になったっぽい...。

ESP8266とESP32の応答速度

　ESP8266よりESP32の方が応答速度が遅い疑惑。

　ちょっとしたホームオートメーション化を図っていて各家電を無線操作できるようにそれぞれに良い子は真似しちゃいけないESP8266やESP32も含むESPボードを使って自作スマートスピーカーから音声操作したり、パソコンやスマホからタップ、クリック操作もできるようにそれら用のブラウザ版スマートホーム操作パネルもあります。

　音声操作できる機能の一部は、自作スマートスピーカー用操作パネルでも実行できるようにしてあり、家電操作については、ブラウザ操作パネルを開くようにしてあります。

　パソコンの場合は、自作スマートスピーカー用操作パネルの任意の家電用ボタンをクリックするとブラウザが起動、ブラウザが起動済みの場合には、追加したタブに表示されるようにしてあってブラウザの起動は、自作スマートスピーカー用操作パネルから、基本、メイン画面を開くことが日常的になっています。

　このブラウザ操作パネルの家電ボタンからブラウザを開く時、ESP12ベースなどのESP8266よりESP32の方が、更にワンクッションある感じでブラウザの起動が遅いことに今更ながら気づきました。

　ESP8266もESP32もそれぞれ、複数使っていますが、同じ傾向です。

　前述のように他の家電用ボタンでブラウザ起動させることはまずなかったのですが、技適済みESP32に全面移行しとこうかなと思い、メイン画面用のマイコンをESP8266とESP32とで交換してみた際、壊れているのかESP32だとリセットをかけないとアクセスできないことがあり、その流れで、他の家電用ボタンでブラウザ起動を試してみるに至り、反応の違いに気づいた次第。

　待てばよいので致命的な話というわけではなく、イメージ的には、ESP32の方が何をするにも速いと思っていたので意外だったのですが、これって、なんの差なんでしょうね？

　ちなみに家にあるスマホはAndroidのみでスマホからの操作は、AndroidでmDNS前提ブラウザ版スマートホームパネル操作のように本末転倒状態でVNCではなく、各家電ごとにIPアドレス直指定のブラウザショートカットをホーム画面に配置して使っている(IP固定しておらず、DHCPからの自動配布、IPが変更になったら都度対応することにしている)為、メイン画面は使っていません。

謎のエラーは解消されたっぽい

　ここのところ、すっかりご無沙汰で、忘れてましたが、何も考えず、Arduino IDE 1.8.13を使ったところ、3.謎のNo programmers available for this board関連のバグは、解消した模様。

　普通に1.8.13でESP8266もESP32もスケッチ編集、アップロード、SPIFFSへのアップロードや利用もできました(できたのは数日前ですが、今日、このページに目を通して、そんなバグがあったことを思い出しました)。

　[ESP32 Arduino(in sketchbook)]は存在するものの、[ESP32 Arduino]が2つ現れることはなく、1つだけ、ESP32ボードについては、[ESP32 Arduino]から選択することで何事もなく、アップロードできています([ESP32 Arduino(in sketchbook)]は未検証)。

　っていうか、これまでのアップグレードの頻度を考えるとArduino IDE 1.8.13、ロングランな気がする、それだけ安定してるってことですかね。

3.謎のNo programmers available for this board

　2. 謎のNo programmers available for this boardに微妙な進展と後退が...。

　また、Arduino IDEでESP32系ボードにもアップロードできるようになったのが進展。

　1.8.9ならOKも1.8.10含む以降のバージョンでは、[ツール]内ボード情報の選択済みのはずの選択肢が表示されない・チェックされていない状態に逆戻りしたのが後退。

　ただし、今度は、ボード設定でESP8266群を挟んでなぜか2つあるESP32群の内、先に出てくる方からボードを選択します。

　これは、謎のNo programmers available for this boardで原因かも？と思ったupdate-alternativesによる変更をリセットすべく、[sudo update-alternatives --remove-all python]後、[sudo ln -s /usr/bin/python2.7 /usr/bin/python]したことによるものだと思います。

　pythonバージョン問題は解消したかのような説明も見受けられたものの、どうも、まだ解消されていないようです。

　ともかく、1.8.12ではありますが、これでまた、ESP系ボードもArduino IDEで使えるようになります。

2.謎のNo programmers available for this board

　謎のNo programmers available for this boardに進展、1.8.13以外の過去のバージョンは全て使えることが判明。

　Arduino IDE 1.8.13においてボードライブラリの更新で途中から？ボードの選択肢が、Arduino、ESP8266、ESP32ごとに分類され、まとめられるようになっています。

　ここをよく見ると[ESP32 Arduino]に加えて、いつの間にか、[ESP32 Arduino(in sketchbook)]が追加されており、一覧内容は、同一のようですが、ここからボードを選ぶとボード情報もラジオボタンが選択済み、テキスト表示された状態になった一方、書込装置は、相変わらず[No programmers available for this board]。

　他方、1.8.12含む以前は、この分類はされず、ずらっと一覧が並ぶ仕様ですが、ボードライブラリが更新されたのに伴い、[ESP32 Arduino]のグループが1つ増えたようで、なんと[ESP32 Arduino]が2つあることに気づき、後から出てくる方でボードを選択したところ、ボード情報も書込装置も選択済みで変更も可能になりました。

　前回までは、1.8.9でないとまともに使えなくなったのですが、これにより、1つ前の1.8.12も使えることがわかりました。

　となると1.8.13のバグということになりますが、ボードライブラリの変更は反映されつつ、最新の1.8.13だけ書込装置の選択肢が表示されないって...、arduino-1.8.13/hardware/arduino/avr/programmers.txtもあるのに、なんででしょ...、まぁ、そういうのをバグって言うんだけど。

1.謎のNo programmers available for this board

　現時点で最新のArduino IDE 1.8.13でESP8266やESP32のボードを選択すると[ツール] => [書込装置:]が[No programmers available for this board]になる状況に見舞われました。

　つまり、ESP系ボードにプログラムを書き込むことができない状態に。

　また、同時にESP系の多くのボードでボードの詳細設定(Upload SpeedやFlash Modeなどすべて)が、ラジオボタンは未選択状態、よってデフォルトの選択肢も表示されない状態に。

　ラジオボタンで選択しても選択はされますが、選択肢の表示はされない...。

　任意に選択した一部のボードで再現しないかと思いきや、改めて選択すると同様になったり...。

　一方、Arduinoボードは、どれを選択してみても、こうした状況にはなりません。

　ボードマネージャでESP32やESP8266、Arduino AVR Boardなどのバージョンを古いものにしたり、戻したりもしましたが、変わらず。

　自身は、Arduino IDEをインストールせずに展開しただけの状態で使い、新しいバージョンがリリースされる度に追加でダウンロード・展開、PCが世代交代したこともあり、結果、今、1.8.x(11を除く7〜13)があり、過去バージョンも起動できる環境。

　そこで試してみると1.8.9なら(未検証ながら、たぶん、それ以前のバージョンも)正常に使うことができることがわかりました。

　ただし、スケッチアップロード時、Arduino IDEの下部のモニタを眺めていると最終的な進捗が0%から動かないものの、しばらく待っていると0%のままアップロード完了となりました。

　完了までの時間が微妙に長いこともあり、それに気づくまでアップロードできない...と思い込み、何度か完了前にUSBケーブルを抜いたりしていました。

　1.8.10/1.8.12については、書込装置は選択済み、他の選択肢も選択可能なのですが、ボード詳細設定が未選択状態、ラジオボタン自体は選択できますが、選択肢のテキスト表示はされない状態に。

　また、1.8.9(おそらくそれ以前のバージョンでも)を起動したままの状態で1.8.13を併せて起動すると書込装置は相変わらずも、ボードの詳細設定については、表示もされ、ラジオボタンも選択された状態に。

　が、改めて1.8.10/1.8.12/1.8.13だけを起動すると、やはり、ボード詳細情報の選択肢が表示されず、ラジオボタンも未選択状態。

　ただ、この挙動、自身の勘違いだったのか？、後述の方法をとったあと確認したところ、事前に1.8.9を起動していようがいまいが、1.8.13の書込装置は選択不能、ボード詳細設定も未選択・未表示状態。

　ネット検索しても日本語情報は皆無、英語でも似て非なるものはあっても、めぼしい情報は全くヒットせず、唯一、ロシア語のQ&Aサイトがヒット、Web翻訳してみると質問者は確かに[プログラマーはいません!「プログラマー」の行には、「このボードで利用できるプログラマーはいない」と書かれています。]と言っていますが、回答はどれも的外れな方向へ...。

　ダウンロードバージョンであるArduino IDE 1.8.13は、リリースされてからだいぶ使っている上、1.8.10や1.8.12も同様なのでIDE自体に起因するものではないでしょう。

　ボードやライブラリは通知があると基本、更新してますが、ボードマネージャで過去のバージョンも試したのでこれも違いそう。

　ライブラリは関係ないでしょうし...。

　ピンポイント過ぎて、これも考えにくいですが、IDEのベースとなっているJava系の更新に伴うバグ？

　ファイル参照関係？だとすると何？

　...と、よくわからないので、しばらく1.8.9を使おうと思います。

　ちなみに制限はありつつもESP32にも使えるというTensorFlow Liteを試すべく、改めてESP-IDF環境を整えたことや、Pro MiniのBODを変更するついでに、しばしArduino ISP/avrdudeを使っていたのは、関係ないはず...。

　その後、確か、AVRISP mkⅡを使って[マイコンボードに書き込む]ボタン押下でスケッチの書き込みもしたはず...だし。

　ただ、ESPボードだけってところからするとESP-IDFの環境設定に起因するの...か...？

　とは言え、ESP-IDF用の環境変数を無効にして再ログインしても改善はされなかったので環境変数の問題ではないでしょう。

　1つ気になることと言えば、ESP-IDFでpython3をデフォルトにすべく、当初、python2.7をpythonにln -sしていたものを、ガイド通りのsudo update-alternatives --install /usr/bin/python python /usr/bin/python3 10という使ったことない技を繰り出してみたことくらいですが、Arduino IDEとPython関係ないもんな...。

　と思ったら、度々忘れてしまうけど、esptoolはおもいっきりPython2に依存してきたわけで無関係とは言い切れないっぽい...。

　が、python同期の影響は、ユーザーベースだろうということでrootでArduino IDE 1.8.13を起動、esp32ボードを追加して試してみたものの、書込装置は、やはり、No programmers available for this board...。

　と思いましたが、suしてpython -Vするとpython3のバージョンが表示されるのでrootも影響を受けている...。

　そりゃそか、sudoつけてupdate-alternativesしたんだから.......これ元に戻してみるの面倒そう...。

　Python2.7とPython3系のバージョン問題だとするとpip/pip3も影響を受ける...。

　日頃pip3を使っている自身の環境におてpipの存在を再確認すべく、dpkg -l python-pipするとあるもpip -Vしてみるとなさ気。

　Python2系、3系ともpipを強制インストール、共にesptoolをアップグレードしてみましたが、状況は変わらず。

　まぁ、esptoolもバージョン1.3以降は、Python2系、3系の何れにも、バージョン2.0以降は、ESP8266、ESP32何れにも対応とあるので影響がなくて当然か。

　ちなみにpyserialも2系3系共に最新。

　結局、man update-alternativesを読んで次のようにやってみましたが、変化はないのでPythonに起因したものではなさそうです。

• [update-alternatives --display python]や[update-alternatives --query python]を実行
  (前述のように事前にsudo update-alternatives --install...していれば、相応の情報が表示される)
• [sudo update-alternatives --install /usr/bin/python python /usr/bin/python2.7 20]を実行
• [update-alternatives --display python]や[update-alternatives --query python]を実行
  選択肢が増えていることを確認
• [sudo update-alternatives --config python]を実行
  有効にしたい選択肢を数字で選ぶ
• [update-alternatives --display python]や[update-alternatives --query python]を実行
  内容が変更されていることを確認
• [sudo update-alternatives --auto python]を実行
  優先順(プライオリティ)の高いものが自動で選択されていることを確認

　ちなみにpriorityの数字が大きい方が優先順が高いのか、後から追加したものが高いのか、よくわかりませんが、この場合、自動だとpython2.7が、最適なものとして選ばれるという結果になりました。

　で、pythonをpython2.7とpython3.7の何れと解釈するかを変更してみても特にArduino IDEへの影響はなかったのでPythonが原因というわけではないようです。

　自身の勘違いでなければ、これをやった以後、Arduino IDE 1.8.9を事前に起動しておくか否かで1.8.10/1.8.12/1.8.13の書込装置やボード詳細表示の状況が変わることはなくなり、不具合は不具合のままとはなったものの、大勢に影響はなさそうです。

　何れにせよ、やはり、ln -sしておくだけの方が、楽そうです。

SPIFFS Error: partition size could not be found!!

　何度か[ESP Sketch Data Upload]していて急に[SPIFFS Error: partition size could not be found!!]なるエラーに見舞われました。

　結果から言うと[ツール]、[Partition Scheme]を[Default 4MB with spiffs(1.2MB APP/1.5MB SPIFFS)]にしたら、正常にアップロードされました。

　Defaultとあるくらいなので何かの拍子に変更してしまったのか、変更前は、[16MB Flash(2MB APP/12.5MB FAT]になっていました...FATってSPIFFSじゃないもんね...そりゃそうだ。

ESPmDNS/ESP8266mDNSの不安定さの善後策？

　ESPボードは、ESPmDNS/ESP8266mDNSライブラリを使うと.localでアクセスできるのは便利なのですが、このところ、名前解決できることもあれば、mDNS名が認識されず、できなかったりするケースがあります。

　結果から言うと最近は、従前の定番設定に以下2点を加えると安定して名前解決できる気がしています。

• setup()内でのMDNS.begin()の第1引数であるmdns名に加え、第2引数にWiFi.localIP()を追加
• loop()内にMDNS.update();を追加

　以前は、これらを行わずとも例外なく、あっさり名前解決できており、最近でもこれらを追加しなくとも名前解決できることもあり、原因はよくわかりません。

　これらを行う前は、光ONU(≒メインのルーター)を再起動したり、systemctlでavahi-daemon.socketやavahi-daemon.serviceをstop、daemon-reload後、改めてstartしたりしましたが効果はありませんでした。

　稀にIPならpingは通るが、mDNS名だと通らず、avahi-resolveでは、IPでもmDNSでも解決できない状態でブラウザからmDNS名.localでアクセスできることがあったり...。

　先の善後策を講じれば、ほぼ解決できているので、よしとするにしても...いろんなページに従前の設定で書いてしまっており、一体どうしたものか...。

ESP32用pyserial(esptool)は未だにPython3.x未対応だった件

　久々にESP32開発ボードにArduino IDEでスケッチをアップロードしてみたところ、ライブラリが複数ある警告と共に[ImportError: No module named serial arduino ide]エラーに遭遇。

　python3-pipパッケージのpip3でpip3 list | grep pyserialすると存在するし、なんで？と思ったら、Eclipse IDE - No module named serial on esp32.comに[esptool.py currently only supports Python 2]というコメントを発見...。

　そもそも、dpkg -l python-pipしてみるとなかったため、sudo apt install -y python-pip、続いてpip install pyserial後、アップロードしてみたらあっけなく、完了した話。

　一方、同時並行してというか、直前までやっていたESP8266では、Python3にも対応しているのか？、アップロードには何の問題もなかったため、余計に意外でした。

　これまで過渡期ということもあってPython3と2は同居してることが当たり前になって2の存在はすっかり薄くなっていましたが、Python2もいよいよ終了の楔を打たれたことですし、早めに対応されることを期待したいところ。

　ただ、2017年10月、先代PCのSSDに換装、メインマシンが替わった1年程度経った2018年09月に32ビットだったDebianに加え、64ビット版のDebian Stretch amd64をインストールしたあたりまでの間には、ESP32にアップロードする機会は多々あったはずですが、こんな状況に遭遇した覚えはありません(...と思ったら、後述の通り、ちゃっかり遭遇しちゃってました...)。

　つまり、その頃には、自身の環境にもpython2系のpipもpyserialも入っていたということになります。

　一方、2019年07月、Debian 10.0 Busterにアップグレード後、2019年11月、やらかして再インストール、現在の10.2(Buster)までの間は、ESP8266/ESP32には触れていなかったかも。

　となると最初からか途中からかBusterでは、Python2は、非推奨ということで、apt update/upgrade時にでもなくなったのかもしれませんね。

　なんて勝手に思考をめぐらしつつ、このページを読み返していてたら、過去に全く同一の事象に遭遇し、その時は、easy_installで凌いでいました...。

ESP8266開発ボードで新規の.localが名前解決されずハマった

　と思ったら、結果、スケッチの書き方に問題があったようで、同じライブラリ群を使っていたHelloServer.inoで試したら、あっさり、名前解決されました。

　おかしいなと思ったら、自身の機能済みスケッチを一部いじる程度、もしくは、他でサンプルを探して試させて頂くのが、最も近道ですよねという話。

　以前、作って動作していたスケッチからWiFiやmdns部分をコピペして書いていたから大丈夫とたかをくくって悩みに悩んで通算10時間以上費やすことになってしまいました...

　ESP8266か、自身のスケッチに起因するのかもとESP32でも試してみるかと以前、機能したスケッチをそのままアップロードしてやってみたら、まさかのpython2系しか対応していない事件に遭遇。

　これを乗り越えてみると、あっさり、名前解決できることが判明、ESP8266のサンプルで試してもできることを確認した次第。

　ただ、サンプルではできた名前解決も、何度見返しても日をおいてみても当該スケッチでできなかった原因は、未だにわからずじまい...。

　ん？

　ブラウザ上でmDNS.localやIPアドレスでいけなかったのは、ブラウザからアクセス時、server.on("/", handleroot)で呼ぶhandleroot()にserver.send(...);を入れ忘れ...。

　コンパイルは通っていたものの、setup()内にserver.on("/", handleroot)が重複して存在したのもまずかったのかも。

　loop()内のMDNS.update();必須になった！？これを入れてから名前解決できるようになったっぽい。

　前者の不足や重複は単純ミスも、後者については、これまでは、入れたことがなく、なくても機能していたはず...仕様変更！？、今回は、あれこれやる中で入れてみたものの、その時は、他に不手際があったのか、名前解決できなかったのですが...。

　まぁ、おかげでavahi-utils、これに含まれるavahi-resolve、avahi-browse、また、それとは別にmdns_scanやAvahi Zeroconfブラウザ(avahi-discover)の存在を知ることができたのは、収穫かなと。

　というか、今度は、SPIFFSで入れた(ESP8266 Sketch Data Uploadした)ファイルが表示されない...。

　今回の検証でも他の複数のスケッチで表示できていたのですが...まさかの書き込み可能回数Max超え！？違うよね？？？

　違った...まだ判然とはしませんが、handleroot()にserver.send(...);の位置(行)が違った(handleroot()の最終行に置いてしまったが、受信文字列判定indexOf()によるif文の前だった)っぽいのとHTMLファイルのVALUE値を全角(日本語)を半角英字に変更したのも影響したのか？フラッシュメモリにも正常にアップロードできるようになりました。

Arduino-IRremoteとIRremoteESP8266の併用は回避が賢明

　何気なく、z3t0/Arduino-IRremoteライブラリを試してみたところ、markszabo/IRremoteESP8266ライブラリとは認識結果が微妙に異なりました。

　ちなみに回路に向け、リモコンボタンを押してシリアルモニタで確認すると定義されたバッファサイズが小さく、IRremoteInt.hのRAWBUFの値の変更を促されました。

　また、同ライブラリは、トップからダウンロードするとVersion - 2.2.3のようですが、2.4.0 beta releaseでベータ版ながら、2.4.0をダウンロードでき、これだと更に若干認識されるエンコード方式が異なりました。

　自身が、今日までに検証したリモコン家電は、シャープAQUOSテレビ、某社製空気清浄機、某社製扇風機、シャープと東芝のエアコン2機種でIRremoteESP8266のIRrecvDump/IRrecvDumpV2では、リモコンエンコード方式としてAQUOSテレビがPANASONIC、空気清浄機がNECで他は全てUNKNOWNと判定されました。

　一方、Arduino-IRremote Version - 2.2.3では、AQUOSテレビのみ結果が異なり、UNKNOWNとなりました。

　また、Arduino-IRremote Version - 2.4.0では、AQUOSテレビが同じくUNKNOWN、東芝エアコンはSANYOと判定されましたが、後者に至っては、CodeがFFFFFFFF (0 bits)となっているので実質、UNKNOWNであり、rawDataを使う必要がありそうです。

　ちなみに、この東芝エアコンは、Arduino-IRremote Version - 2.2.3では、UNKNOWNになったり、SANYOになったりと判定結果が不安定でした。

　結果、自身の検証家電においては、AQUOSテレビの分、IRremoteESP8266ライブラリの結果が好ましい(rawDataでない分、データ量が減る？)ので送受信回路共にESP8266で組むのが妥当という結論に至りました。

　というか、そもそも、これまでArduino-IRremoteで送信、IRremoteESP8266で受信回路などという併用は考えたこともなかったわけで当然と言えば、当然です。

　仮に今回受信をArduino、送信をESP8266にしていたとしてもArduino-IRremote側での結果は、全てUNKNOWNと認識されたも同様なので事なきを得た可能性もありますが、それぞれ操作はできるかと思うものの、なにぶん、Arduino-IRremoteのデータでは実際に試したわけではないため、何とも言えません。

　ただ、この結果から、リモコン信号解析をArduino-IRremoteライブラリを元にしたArduinoによる回路、信号送信回路をIRremoteESP8266ライブラリを元にしたESP8266にする...というのは回避するのが賢明でしょう。

　実は、作った回路を整理している際に自身は、余ってるNanoを使い、そうしようと思って今回試してみるに至ったのですが、検証してみてよかったです。

　尤も既存のリモコンは、全てIRremoteESP8266ライブラリで解析済みだったのですが、検証もせずに回路だけArduinoで作っていたとしたら、新たなリモコン(家電)を入手したときにドハマりしていたかもしれません。

　ちなみにz3t0/Arduino-IRremoteについては、ArduinoだけでなくESP8266にも受信だけならESP32にも対応しているのですが、ESP32 Support #540のYouTube動画を見ると、どうも「MQTTを介せば」という条件付きで？？？ESP32による赤外線信号発信にも対応できる...とのこと。

　と思ったら、よく見るとz3t0/Arduino-IRremoteライブラリには、パッチESP32 Support #540があり、リンク先の通り、各種ファイルを修正しただけでESP32でも少なくともUNKNOWNとなったSHARP AQUOS TVのON/OFFをirsend.sendRaw(...)することで赤外線操作できました。

　もし、赤外線LEDが光らない場合、複数のGPIOピンを試すべきです(自身は、26でダメで12にしたところいけました、ちなみに受信には14を使用、ピンアサイン詳細はESP32 Pinout Reference等参照)。

　ちなみにライブラリ格納場所にコピーを作るとIRsend irsend()にピン番号を渡せなかったり、思わぬエラー(undefined reference to...、collect2: error: ld returned 1 exit status)でハマりますから、必要なら別の場所に元のライブラリを退避しておかなければなりません。

ESP8266とリモコン

　今のところ、日本の技適を通っていて何を考えることなく自由に使えるのは、(技適マーク付きの)ESP-WROOM-02/ESP-WROOM-32か、これらが載った開発ボードのみです。

　リモコンを考えた場合、ESP-WROOM-02は対応している模様もESP-WROOM-32は受信のみで送信は未対応なようです。

　ただ、ESP32でもMQTTやIFFFT、Blynkなどを使うか、若干無駄で嵩張りますが、ローカル環境で済ませるならESP32を無線モジュールとしたArduinoに赤外線LEDをつなげば、いけるでしょう。

　自身は、ESP-WROOM-32開発ボードは複数持っていますが、ESP-WROOM-02は持っていないのでESP8266 NodeMCUボードで検証しました。

[2019/06/14:追記・訂正]　ESP32でも赤外線送信できることを確認しました。

　ちなみにESP8266にも載っていることがあるESP-12E/12Fなど単体チップ、ピッチ変換基板併用などでもできますが、これらは電源周りの工夫ができない場合、かえって大掛かりになるのに対し、NodeMCUなどの開発ボードは、あっさりできて激楽です。

　ESP8266の単体チップを使うとわかるのですが、GPIO00/GPIO02/GPIO15(NodeMCUではD3/D4/D8)などは、特殊なピンなので回路で入出力に使うピンは、別のものにするのが無難です。

　そうでない場合、スケッチをアップロードする前、ガジェットに電源を投入、WiFi接続する前には、一度、それらのピンを外してから等、配慮しないとアップロードやESPによるアクセスポイント、ステーションモードの確立など無線接続に失敗することになるでしょう。

　また、自身は、試しておらず、真偽の程も、仮にそうだったとして、今尚そうなのか、わかりませんが、WiFi機能に関しては、一時的に電流量が多くなり、ESP8266開発ボードの5V/G(ND)のみでは起動できず、USB電源と併用、WiFi機能が有効になった後は、USBを抜いても運用可能といった情報を目にしました。 => 後日試してみたところ、その必要はありませんでした。

　尚、WiFiチップは、結構熱をもつのでケースに入れる場合には、誤動作回避の為にも適度な通気口は必要、できることなら冷却手段があれば尚良いでしょう。

　Arduino-IRremoteとIRremoteESP8266の併用は回避が賢明。

easy_installとpip

　久々にESP32を使おうと思ったら、Arduino IDEにおけるコンパイルで[ImportError: No module named serial]というエラーでハマりました。

　エラー表示の他の部分からpyserialのエラーであることがわかり、ちょっと調べてpip3 install pyserialやアップデート、sudo apt install python3-serialなどをインストールしてみるが、一向に解決しない...。

　更に検索してみるとpythonには、pipが置き換えを図り、それ以前からあったeasy_installなるコマンドがあることを知り、sudo easy_install pyserialとしてみたら、なんと先のArduino IDEでのエラーが解消しました。

　最後にいじったのは、32bit Debian Stretch上ですが、Juliusを使いたくて64bit Debianを追加インストール・常用後、初めてだったから環境が整っていなかったからでした。

ESP8266/ESP32+Arduino IDEでSPIFFSを使う方法

　ESP8266とSPIFFSについては既に記事中で触れたので本末転倒な気もしますが、ESP32とまとめて書いておきます。

　ESP8266については、esp8266/arduino-esp8266fs-pluginの通りにesp8266fs.jarを、ESP32については、me-no-dev/arduino-esp32fs-pluginの通りにesp32fs.jarをダウンロード・展開します。

　最終的には、Arduino IDE展開ディレクトリと同列のArduinoディレクトリ内librariesディレクトリと同じ階層にある[tools]ディレクトリ(なれけば作成)内の、それぞれ、[ESP8266FS]、もしくは、[ESP32FS]以下の[tool]ディレクトリに、これら.jarファイルを配置した恰好となります。

　その後、Arduino IDEを起動(既に起動していた場合は再起動)すると[ツール]メニュー内に[ESP8266 Sketch Data Upload]、[ESP32 Sketch Data Upload]メニューが追加され、表示されます。

　ESP32については、スケッチごとにSPIFFS.hをインクルードする必要があります(ESP8266では不要)。

　保存したい任意の各種ファイルは、Arduino IDE用ESP8266/ESP32のスケッチごとのディレクトリ内に[data]ディレクトリを作成の上、そこに置き、先のメニューを選択することでアップロード(上書き・書き換え)できます。

　SPIFFS/SPI Flash File Systemは、モジュール上のフラッシュメモリ内のファイルシステムに対してSPI経由で読み書きできるようになる仕組み(書き込み上限・寿命があるので頻繁な書き換えには不向き)。

Arduino IDE 1.8.6ではDevKit V1に優しくなりました

　前段の理由でArduino IDEにESP8266/ESP32ボード再追加することになったおかげもあって良い発見もありました。

　従前、Arduino IDEでスケッチを書き込む際、ボード上のBOOTボタンを押す必要があったDevKit V1(互換)ボードにおいてArduino IDE 1.8.6では、その必要がなくなっていることに気づきました。

　[追記]　極々稀だと思われるが1度アップに失敗、BOOT押下が必要になることもあった...と思いきや、それ以後、たまに、BOOTボタン押下を要することが...。

　何れにしてもDevKit V1ボードのバグという情報もありましたが、ESP-IDFでは、そもそも、その必要はなかったことを確認済みなので、何れにしてもバグというわけではなく、Arduino IDE側の仕様によるものと思われ、今回のバージョンアップで、その点がArduino側で改善されたということなのでしょう。

Arduino IDEのバージョンアップに伴うESP8266/ESP32ボード再追加

　Arduino IDE 1.8.6からユーザー設定がまっさらになってしまった為、ESP8266/ESP32ボードを再追加する羽目になりました。

　前回は、ESP8266をArduino IDEの環境設定から、ESP32をgitから展開したが、今回は、これら2つのURL(ESP8266の方は、httpである点に注意)をArduino IDEの[ファイル] => [環境設定]の[追加のボードマネージャのURL:]欄にカンマ区切りで指定、Arduino IDEの[ツール] => [ボード]から[ボードマネージャ]から選択、インストールすることにしました。

　以下は、リンク先と全く同じですが、本来こっちの話なので、そのまま書いておきます。

　ESP32の方は、以前追加したディレクトリをそのままにしておくと[...xtensa-esp32-elf]が既に存在する旨、表示されたりしますが、警告であって別にインストールに支障はない模様(一度、削除、再インストールしてみましたが、今度は警告は出なかった)。

　これでESP8266/ESP32何れかのボードを選ぶとスケッチ例にも対象標準スケッチが表示されるようになることは確認済み。

　念の為、ESP32の方は、以前追加した内の[...xtensa-esp32-elf]をのみ削除(ゴミ箱送りに)しても、削除せず、そのままにしておいてもArduino IDE 1.8.6からサンプルスケッチGetChipIDやStartCounterをアップロードでき、DevKit V1互換ボードで機能することも確認済み。

ESP8266でエアコン自動制御

　以前、ArduinoでエアコンON動作自動制御を思いつきで構想してみたものの、Arduinoより、ESP8266の方が...と思い直し、ここにきて構想を練り直してみたのですが、結果、構想に留めおくことにしました。

　というのは、検証もでき、温度センサによるエアコン(冷房・暖房・除湿)の自動ONの他、無線LAN経由でのブラウザからの遠隔操作、家人が長期不在など自動制御不要の際に電源OFFすべく、人が直接スイッチ付きコンセントをON/OFF、併せてサーボモータで無線LAN経由でブラウザからのスイッチ付きコンセントのON/OFF(少なくとも100Vエアコンでかつ集中スイッチ付き2口コンセントならエアコンだけでなくESP回路の電源も簡単に連動できる)など、機能的には、一通り、実現できること、Arduinoよりも無線搭載でArduino感覚で使えるマイコンがあるESP8266の方が適していることもわかったのですが...

　よくよく考えてみると、特に夏は、窓やカーテンの開閉も併せて自動化・連動でもしない限り、運用上、イマイチとの判断から。

　ちなみに仮に窓やカーテンの開閉を自動化し、連動させることができるにしても手動でも開閉できないと不便極まりないし、安全性の観点からもよろしくない為、そうした配慮も必要だろうと考えると自作にしても市販品を買うにしてもコスト面含め、今のところ、そこまでする必要性はないと思うに至りました。

ESP32とESPNow

　日本の技適済みESP32については、ちょっと前に買ったESP32 DevKitC V4系でありつつ、ボードがDOIT製DevKit風のESP32開発ボードと今日届いたDOIT DevKit V1互換機と2つのESP32開発ボードを持っています。

　これらでESP32同士の通信用サンプルスケッチ[ESPNow]の[Master]/[Slave](わかりやすさ優先の便宜的な区分であり、ESPNOWに存在するコンセプトではないとのこと)を試してみたところ、後者をMaster、前者をSlaveとした際には、正常に機能しました。

　ところが、これらを逆(前者をMaster、後者をSlave)にするとProblems with ESP NOW connectionと全く同じ症状でMaster(前者V4系ボード)側のシリアルモニタ上では、こんな表示が繰り返される...。

　[espnow "slave not found"]でググっても5件しかヒットせず、プログラム内のエラー出力(Serial.print)以外となるとリンク先の1件しかない為、超レアケースっぽい...と思ったら、"Found -2 devices"でぐぐったら4200件あり、[No Slave Found]らしい...以前のメッセージはこれだったのか？

　実際には、最初に当該事象に直面し、Master/Slaveにするボードを逆にしてみたら、正常に機能した次第。

　blink、hello world、scan、GetChipID、bt_discovery...など、いくつか試してみましたが、いまのところ、他のプログラムでは何ら問題はない、リンク先では、プログラム中の%cに着目しているものの、(前者の)ボードに起因するのか...？

　あ、パソコン再起動して、再度試してみたら、ボードが逆でも[Slave Not Found, trying again.]になりました...。

　そこで先の検索結果の内、ESPNow example can't work on latest commit #1425の回答後段に[you need to add WiFi.disconnect(); in the first line into the void InitESPNow() { then it will work.]とあり、Master/Slave共にInitESPNow()関数の最初の行にWiFi.disconnect();を追記してみたら、Master/Slaveにするボードに関わらず、ENボタンでリセットをかけるまでもなく、常時、正常に機能するようになりました。

ESP-01/ESP-12Fで通信

　先日、ESP-01単体とピッチ変換基板にはんだ付けしたESP-12F間(ESP8266同士)の通信テストとして同じ方がアップしている2組のみで完結するAccesspoint - Station Communication Between Two ESP8266 MCUsと別途WiFi環境を要するWiFi Communication Between Two ESP8266 Based MCU Through the Home Routerのプロジェクトを試させて頂きました。

　何れも最初は、うまく機能したのですが、その後は、シリアルモニタ上で文字化けが発生...機能しているのか、否か判断できない状態になりました。

　何をどうすればよいのか、今の自身にはわからない。

　Mosquitto(MQTT broker)を使う手もありますが、これをインストールしたラズパイやパソコンを別途要するので、ESPだけで完結できないかと思っています。

　というか、電力消費量を抑えて電池駆動...を考えれば、BLE(Bluetooth Low Energy)でGATT Server/GATT Clientなどを使うのが妥当なんでしょうね。

ESP8266/ESP32の入力電圧

　ESP8266の操作電圧は、概ね3.0〜3.6V、定格3.3V。

　ESP-WROOM-02/ESP-WROOM-32の操作電圧は、2.7〜3.6V、定格3.3V。

　よって何れのチップやボードもArduinoなどの5V版と通信する場合には、5V側からの通信については、降圧が必要。

　というか、V5なるGPIOピンがあるESP-32開発ボードがあるんですが、これって5V？

 => もう1つのボードはVINとなっているし、入力用端子で5Vに降圧？しているらしいので5V強の単3電池x4をV5とGNDにつないでみたらESP32の電源が入ったため、外部電源入力用のようです。

ESP32 DevKitC/DevKit V1のバグ？

　ESP32の開発ボードEspressif製ESP32 DevKitCやDOIT製DevKit V1、これら互換機においては、Arduino IDEからスケッチを書き込む際、開発ボード上の[BOOT]ボタンを押したまま、[RST/EN]ボタンを押す、または、[BOOT]ボタンだけを押す必要があるとのこと。([2018/08/26] Arduino IDE 1.8.6ではその必要がなくなりました。)

　手持ちのV1互換機では、ESP-IDFにおけるmake flashやCLIにおけるesptool(.py/.exe)では、その必要はなかったのですが、中には、これも先のボタン押下が必要という情報もあるので、もし、書き込めない場合には、試してみる価値はあるでしょう。

ESP8266/ESP32開発ボードにはいろいろある

　ESP8266の開発ボードについては、ESP-12Fなどが載ったNodeMCU、WeMos D1などが、ESP-WROOM-02については、ESPduino、ESP-WROOM-32については、Espressif社製ESP32 DevKitC、DOIT製ESP32 DevKit等々の他、やNodeMCU ESP32Sなどもある模様。

　共に動作確認済みですが、自身2台めとなるESP32開発ボードが届いて気づいてみれば、これら2つだけでもGPIOピン数など結構異なる部分があって驚きました。

　詳細は別としてESP32開発ボードにたくさん種類があるのは知っていましたが、これらの互換機に至っては、Espressif製DevKitCとDOIT製DevKitの間の子みたいなものなどArduinoボードと違ってある程度の統一感もないようで、その分、種類も多いっぽい...。

ESP8266/ESP-WROOM-02/ESP-WROOM-32のピッチ

　転載ついでにESP8266/ESP-WROOM-02/ESP-WROOM-32のピンホールのピッチは、ブレッドボードやユニバーサル基板などの2.54mmとは異なったり、ピンレイアウト上、使えなかったりします。

　よってこれらと共に使うには、空中配線するか、2.54mmのピッチ変換基板(ブレイクアウトボード)付き、または、これを別途用意してハンダ付け、もしくは、これらチップ搭載の上、USBポートなど一通り備えた開発ボードが必要となります。

　尚、ESP-01/ESP-WROOM-02/ESP-WROOM-32に専用のピッチ変換基板、ESP-07/ESP-08/ESP-12に兼用ピッチ変換基板をよく見かける、また、ESP-12やESP-WROOM-32には、各種開発ボードがあります。

ESP8266/ESP-WROOM-02/ESP-WROOM-32の種類

　転載ついでにESP8266/ESP-WROOM-02/ESP-WROOM-32は、Espressif社が開発。

　この内、ESP8266には、AI-Thinker社製造のESP-01、ESP-02、ESP-03、ESP-04、ESP-05、ESP-06、ESP-07、ESP-08、ESP-09、ESP-10、ESP-11、ESP-12、ESP-13、ESP-14があります。

　また、ESP-01には、ESP-01/ESP-01S、ESP-12には、ESP-12/ESP-12E/ESP-12Fなどがあります。

　ESP-WROOM-02/ESP-WROOM-32については、製造もEspressif社。

　他にも多々種類があるようですが、把握しきれていません。

　尚、日本国内での販売については、例えばAmazon Japanを見ると次第にESP-01、ESP-12、ESP-WROOM-32あたりに絞られている感がありますが、Aliexpressなどでは、今尚、いろんなバージョンが販売されています。

　ただし、日本の技適の話になると現時点で通っているのは、ESP-WROOM-02/ESP-WROOM-32のみ。

ESP8266/ESP-WROOM-32の機能概要

　転載ついでにESP8266、ESP-WROOM-02、ESP-WROOM-32は、WiFiモジュールである一方で例えばWiFiと無縁なプログラムを書くことすらでき、Arduinoボードのように使うこともできます。

　ESP-WROOM-32に至っては、WiFiのみならず、Bluetooth、BLE/Bluetooth Low Energy機能もあり、温度センサ、ホールセンサ、タッチセンサなどもワンボードに収まりつつ、メモリも増量、GPIOピンも多かったりと多機能、高性能ですが、国内でも単体で数百円、開発ボードも1500円程度で買えるという驚きのコスパ。

ESP8266/ESP-WROOM-32にスケッチを無線アップロード

　Arduino IDEにおいてArduinoOTA(On The Air)を使うとESP8266やESP-WROOM-02、ESP-32などで無線でスケッチをアップロードすることが可能となります。

　ただし、ESP8266用Arduino Coreライブラリを導入、サンプルスケッチBasicOTAを書き込むのに加え、アップロードしたいスケッチごとにOTA用のプログラムを数行書き込んでおく必要があります。

ESP8266/ESP-WROOM-32の開発環境

　転載ついでにESP8266に限らず、ESP-32もArduino IDEで開発可、他にesptool/esptool.py/esptool.exe、PlatformIOやESP-IDF(make)などによるCLI、Cloud & Desktop IDEにあるようにPlatformIOプラグインを導入できるAtomやVSCode/Visual Studio、NetBeans、Eclipse等々のようなGUIエディタ・IDEなどでも開発可。

ESP8266にはArduino IDEからスケッチを書き込むことも可

　WifiモジュールESP8266は、ICチップとGPIO(General-purpose input/output・汎用入出力)ピンもあってArduino IDEから任意のスケッチを書き込むことができます。

　用途にもよりますが、たいていの場合、ESP8266があれば、これだけで事足り、Arduinoボードを使う必要がないことは多々あります。

　ただ、WifiモジュールESP8266には、多くの種類があってジャンパワイヤで接続できるものもあれば、変換基板がないとブレッドボードなどで気軽に試すことができないもの、技適の有るものや無いもの、リセットボタンがついているもの、ないものなどもありますが、リセットボタンがないものの内、USB-TTLシリアルコンバータモジュールを使う場合、これにRTSピンがないものは、スケッチを書き込むにも、ひと工夫必要らしいことがわかりました。

　そのひと工夫とは、2つのスイッチ付きの簡易回路を作ること。

　FTDIモジュールのDTR、CTS、RTSなどの端子が存在すれば、RTSにRST、DTRにGPIO0を接続すれば、このひと工夫をする必要がないとの情報もありますが、未確認。

　ちなみにESP8266に限ったことではありませんが、通電した状態でVCCとGNDの接続を間違えたりすると壊れる可能性が高いので接続を確認してから通電した方がよいでしょう。(自身は、たぶん、これが原因で買って間もないESP8266を1個壊しました。)