スマートロックシステムを自作してみた話。
もちろん、後付け可能。
運用開始は、2024/02/13からと既に2ヶ月以上経過。
ここ数年、スマート系の自作づいている自身も全く作る気も予定もなかったスマート系デバイスだったこともあり、今更感はありますが、いざ作ってできてみるとスマートロックは、もう手放せない、なくてはならないものになっており、常備はしているものの、以来、一般的な金属製の物理鍵を使ったことは一度もありません。
これを作るモチベーションが上がらなかった理由は、ほぼ唯一「締め出される可能性を払拭できない」ことでしたが、必要に迫られ、いるならいるで当然、自作だよねと、よく考えてみたら、払拭できる目処が立ったので。
自作当時、丸ノブ錠でしたが、交換したレバーハンドル錠でも使用できました。
自作したスマートドアロックの仕様は、おおまかに言うとこんな感じ。
ブラウザからの操作は、あったとしても基本、在宅時でも外出時でも鍵のロック状態確認がメイン、自作中のドアホン完成後なら、併用して親類・友人・知人来訪時に使うかどうかというところ。
尚、仕様変更で理由などは詳述しますが、カード/タグ認証は、(FeliCaのみでも良いものの、今回は)Mifareのみとし、FeliCa、そして増設つまみについては、今回は見送ることにしました。
気づけば、自身が参考にさせて頂いたRFID/Keypad/指紋認証併用の参照先やWi-FiとBluetoothの併用は別として、世の自作スマートロックのほとんどは、ロック機構部の実現に重きを置いているのか、宅内ボタンはともかく、顔認証、指紋認証、ICカード認証、ノック(リズム)認証、ブラウザを介して開閉、Bluetooth内蔵スマホで近づいた時・離れた時に開・閉、オートロック等々、何れかのみの単機能なものな模様。
一方、1〜3万円ほどで買える市販スマートロックも基本スペックは単機能、また、遠隔ロックするためのWi-Fiユニットが別売りだったりする模様。
自身は、構想当初から、前述の機能は必須かなというところからスタートしたのですが、結果、期せずして贅沢なハイスペック仕様になってしまったようです。
ちなみにオートロック含め、ロック・アンロックにおける他の方法や各種認証を利用しなかった理由については、仕様決定までの経緯で触れています。
ドア外に設置の認証パネル。
左が扉付きキーパッド、その右側のスペースがRFID認証パネル、中間上部の黒く見える部分の小さな窓はLED用でキーパッドの扉を開いた時にも視認可能。
この位置まで雨が吹き込むことは、まず滅多にないものの、ケースの蓋裏面全面には、簡易な防水を兼ねつつ、キーパッド保護用に液晶保護フィルムを、ケース外側開閉付け根部分とキーパッド扉の同部分に90度折り曲げ可能な透明防水テープを貼付。
キーパッドの扉をチラッと開けたところ。
キーパッドに登録済みパスワードを入力するか、登録済みNFCカードやタグ、シールを貼ったもの、NFC対応スマホ等を認証パネルに近づけるか当てるとキーロック側にパスワード、またはカード・タグのIDが送信され、NGならレッド、OKならグリーンにLEDが点灯し、グリーンの場合、キーロック側センサーで鍵が開いているか閉まっているかを検出、結果に応じて解錠・施錠。
写真左に見える黒い帯は、撤去することも考慮し、養生テープ+シリコンテープ、更にケース付近ではLEDテープ用シリコンチューブで防水処理、ちょっとしたテープ1枚でも開閉できなくなる玄関ドアの隙間を通したUSB用フレキシブルフラットケーブル/FFC。
認証パネルは簡単に取り外せるように引っ掛け式。
壁に凹凸面でも効果抜群の超強力両面テープで水回りでも使えるというPVC製透明フックを貼り付け、ケース裏側にガタ付き防止の発泡スチロール貼付とケース加工時の端材やスペーサでパネルケース側に引っ掛ける部分を追加工。
追加工が終わってみれば、何もわざわざ、わずかながらも水の侵入の可能性を高めずとも穴あけ不要な金属プレート+(ケース内から)磁石にするのもよかったかと思いつつも、億劫でそのまま採用。
ケースごと完全に外す場合は、コントローラに給電しているFFC/Flexible Flat Cable先端USBプラグモジュールのロックを解除、FFCを外してケースから抜くことで可。
ただ、回路は、取り外し可能な同ケース中蓋に固定してあり、回路を取り出すだけなら、ケースを開けてコントローラからUSBプラグを抜き、中蓋を外すだけでOK。
盗難・持ち去りの可能性は(あるわけないし、そんな物好きいるはず)ないものと想定している一方、後日、構想自体は先行していた自作テレビドアホンを認証パネル上に位置するインターホン・ドアホン専用スイッチボックス内に取り付け予定なので、尚、心配無用かと。
我が家のドアの鍵は、MIWA(美和)ロック製でサムターンが楕円の円柱形?のもの。
そんなサムターン周辺に設置のドアを解錠・施錠するドアロック・アンロック構造物。
ドア外の認証パネルからのパスワードやIDを受信、認証、OK/NG結果送信、認証OKなら解錠・施錠。
また、宅内でLAN上にあるパソコンやスマホ、タブレットから、外からはVPN経由で鍵のライブ映像を表示したブラウザ上のボタン押下で施錠・解錠。
もちろん、在宅時や外出時など遠隔で鍵の施錠確認も可能。
ただ、前掲の写真は、玄関照明を点灯させた状態、この写真は鍵機構部分だけをライトアップしたもの。
日がとっぷり暮れて室内からの明かりも一切ない場合は暗闇なので玄関の照明は当然、点けます。
が、今や、そういう状況であっても、どれも小さく、視認性十分と言うにはほど遠いものの、自作スマートロックのマイコン、センサー、IPカメラなどの電源用LEDの灯りがあるので照明を点けるまでもない状況。
そもそも夜間でも室内から漏れる程度のわずかな明かりでもあれば施錠・解錠には十分、とは言え、そういう状況下でも足元は暗いので自作の人感センサーライトで足元をライトアップ、光センサーも使っているものの、実質、終日機能しているという状況でもあります。
そんなこんなで人的には終日にわたり、玄関の照明を点けるのは稀な一方、カメラ映像的には、朝から晩まで終日暗めな玄関ということもあり、解錠・施錠状態を視認するには厳しいので何らかの明かりは欲しいところ。
かと言って終日点けっぱなしというのはナンセンス、玄関照明はスマート化していないし、使用頻度が少なすぎてスマート化する予定もないので連動はできない、というか、鍵の確認のためだけに点灯させるには大げさ過ぎる...。
電子工作に使える赤外線LEDライトも複数手持ちがあるも人などが対象でないからか光量不足気味...なら、カメラ前方の限られた範囲に光を放つ方法で手を打つかとなんとも小さな基板にSMD LED3灯が載っただけながら、とても明るいUSBライト5Vと迷いつつ、単色でリーズナブルな5Vタイプは手持ち在庫が切れていたものの、12VタイプはあったのでLEDテープライトを選択。
というわけで結果、スマホ/タブレットやパソコンから操作パネルを開いてキー操作したり、施錠確認する際のみ、内鍵部周辺を照らすべく、こんな感じでライトアップして運用中。
ドア内側からは、ボタン(レバー)で施錠・解錠。
そのボタンとなるのが、ケース上に伸びる白いプレートでケース内のタクトスイッチを押下することで機能するレバースイッチ。
尚、施錠・解錠については、モーションセンサーで傾きを検知、その状態に応じて作動。
ロック機構の固定については、幸いなことにドアが内外ともに金属製ゆえ磁石。
気づけば4年以上前に買ったWi-Fiドアベルの押しボタンもホットボンドで貼り付けたHDDから部品取りした超々強力な磁石の磁力でドア外面に固定、外そうにも容易には取れないほどドアとガッツリ、すっかり一体化していたほど。
ちなみにその電源は、電池で、なんと12V/23A、ドアベル以前の5年以上前にそんなんあるんか!?と5本セット買ってあったものの、付属電池の初交換は、つい数日前という長持ちっぷり。
そんな古い3.5インチHDDから部品取りした超々強力な金属プレート付き磁石や磁力はやや弱いながら2.5インチHDDから部品取りしたものなど、いくつか持っていたりします。
その内、3.5インチHDDの超々強力な金属プレート付き磁石+追加購入した補助の強力丸磁石2個でケースに固定したL字アングルステーを挟んでドアと磁力で固定。
加えてサムターンをつまんでいる(スライドさせて挿抜できる)恰好のグリップと給電用プラグがつながっているのみ。
よって給電プラグを抜き、手で外そうとすると、かなり強力ながら磁石をドアから、グリップをサムターンから、(サムターンの向きに応じた方向に)ズラすように外すことで簡単に脱着可能。
構造的には、磁石を挟んでアングルステーの穴とケース、タミヤのユニバーサルアームをボルト+スプリングワッシャー+平ワッシャー+ナット締め。
モータ2箇所の取り付け穴を挟むように組んだユニバーサルアーム2本にモータを固定、モータカップリング、スペーサー、歯車と共締めしたパイプ椅子グリップ、同軸上に共に回転するようサムターンの角度を検出するセンサーを設置。
当初構想製作、よりコンパクトで丸いドアノブより内側、少なくとも面一ほどに収まるはずだった、モータ軸がドアノブ方向を向く恰好のモータ・中間・サムターン用の3枚ギア構成の構造物の強度不足により、急遽、写真のようにモータ軸延長上でサムターンを回す構造に変更。
給電は、12V 2AのACアダプタによる有線、ドア軸方向に対して前述の追加購入した複数個の強力丸磁石で配線モールを横方向と縦方向2本固定、ドア開閉を考慮し、遊び部分を配線チューブで包みつつ配線。
ただ、手で外そうとすると容易ではない強力な磁力ながら、さすがに服がひっかかったり、身体が激突するようなことがあると簡単にズレたり、落下したり、そうなると給電ケーブルから芋づる式に磁石留めの配線モールも落下したりすることも。
よって奥行きも限りなく薄くでき、なんならサムターン部以外は設置の自由度が上がり、ひっかけたり、激突のしようもない、まさにスマートな構成にすることも可能な複数枚ギア構成を再検討の上、うまく機能すれば差し替え予定。
また、当初の構想では、樹脂製ギアに固定用ビスのタップを立てステッピングモータ軸に直接はめ込むべく、中学時代、技術の授業で真鍮にタップを立てて以来ながら、工具を買ってやってみたところ2箇所の内、1箇所失敗、うまく固定できず、宿題として今回は断念したものの、これができればカップリング分だけ更に薄型にできる為、再チャレンジ予定。
=> [2024/05/21]
現行構造でも滑りが出てホットボンドでごまかしていましたが、タップに再挑戦してみたら、前回はM3に対し2.0mmと下穴径を間違えていたのも一因だったようで下穴を2.5mmとしたからか、KHK樹脂歯車DS1-28軸上の2箇所のタップ、上手くいきました。
よって当初構想の構造に替える際もカップリング分の空間を省いて28BYJ-48を直接固定できます。
これに伴い、丸ノブのまま回せなくもないものの、角度的に干渉しやすい為、買ったのが丸ノブに装着できるドアレバー。
他のメーカーなら色も選べたものの、構造上、最も安定しているように感じ選定、なおかつ、見た中では最も安価で尚良しということで。
お気に入りのダイソーの『らくらく蛇口レバー』があるくらいだから、100円ショップにはないにせよ、玄関ドアの丸ノブ用もあるでしょと探したら、まさに数種あり、市販のスマートドアロックを買った丸ノブな人々も愛用している模様でそうしたレビューも多数。
尚、サムターン付近のギアは3枚ギア構造物の名残で、この代替した構造上、当然ながら歯車である必要なし...。
ドア内外でESP32開発ボード2つ、Web操作含むESP32カメラボード1つとマイコンは3つ。
ドア内外の2つのESP32ボードについては、CPUコアを2つ(デュアルコア・マルチコア)に加え、複数タスク(マルチタスク)を使用。
ドア外の認証パネルにおいては各種タグに対応のRFIDリーダー/ライターモジュールPN532/ELECHOUSE NFC MODULE V3を使って電子マネーや交通系ICカード、各種RFIDカードなどのカードキー・タグキー、これらに対応のスマホやスマートウォッチなどのスマートデバイス、もしくは、メンブレンマトリックス4x4キーパッドによるパスワード入力、ライブ映像が表示されたブラウザ上のボタン押下、室内のボタン押下(か物理的な金属製の鍵)の何れかでロック(施錠)・アンロック(解錠)。
ブラウザ操作については、VPN経由で外出先からライブ映像を確認しながらのロック・アンロックも可。
TCP通信でドア外の認証パネルからキーを送信、これをドア内ロックシステムが受信、認証、結果に応じたALLOW/DENY応答によって認証パネル上にLEDのグリーン/レッドで色分け表示、加速度・ジャイロ6軸モーションセンサーで開閉状態(サムターンの向き)を検知しつつ、バイポーラに改造したお気に入りのユニポーラ激安ステッピングモーター28BYJ-48-5V+モータードライバDRV8825でサムターンを回し、状態に応じて施錠・解錠。
我が家の場合、平常の静けさなら鍵を開け閉めする程度のドア際なら外からでも、なんともカッコよく、心地よい響きでウィーーンといった微かなモータ動作音も確認可能。
電源断の際はシャフトはフリー、また、モータードライバDRV8825+ユニポーラからバイポーラに改造したステッピングモータ28BYJ-48は、駆動していない時はシャフトフリーになるように配線、相応にプログラムすることで電源の供給の有無によらず、フリーとは言え、28BYJ-48なりの僅かな重みはありつつも物理鍵による解錠・施錠が可能。
尚、モーションセンサーが引っかかったり、固定が緩んだり、それによって想定角度外になったりといった有事の際に備え、開閉に必要な一定の時間を測定の上、所定角度範囲への到達か、経過時間、何れか早い方でモータを停止すべくプログラム。
結果、仮に電動動作しない場合でもモーションセンサー周りは機能に支障ない一方で物理鍵での開閉を邪魔しない程度に固定してあり、万一、センサー構造物が他の装置部分と引っかかることがあったとしても締め出される可能性はまずなし。
Wi-Fi・ブラウザを介したドアロック・アンロックボタンは、宅内から、もしくはVPN経由で外出先からロック状態の確認を主としてロック・アンロックボタンを映像・ストリミーング、スマート機器用操作パネルホームへのボタンと共にESP32カメラWebサーバ上に実装、ドアロック用ESP32ボードをWebsocketサーバとしてESP32カメラサーバ上のボタン押下時にWebsocket通信することで認証なし、同様の機構で施錠・解錠。
万一、ハッキングされて侵入された場合、ここはESP32ボード側で認証しておくべきか?と思わなくもありませんが、何れにせよ後で考えることに。
ドア内では、押しボタンスイッチにより、(当然、認証なしの)同様の機構で施錠・解錠。
電源と配線については、
ドア外側の認証パネルについては、防水も考慮しつつ、ドアやサッシにも配線できる薄いFFC/Flexible Flat Cable(Flat Flexible Cable)タイプのUSBケーブル+USB充電器+スイッチ付きコンセントで給電(建物既存のスイッチボックスに設置の自作ドアホン用ESP32カメラも同様にする予定)。
ドア内側のロック機構については、ドアの開閉軸側経由で配線モールを設置(固定は数個の磁石)、ドアの軸付近は、開閉時支障ないように、かつ、噛まない程度に配線モールなしのケーブルに遊びを設け、ACアダプタ12V+ACアダプタコネクタ付きケーブル+配線ケーブル+ACアダプタプラグ付きケーブルを個別スイッチ付きコンセントから給電。
IPカメラとしてのESP32S3カメラボードにおいて操作パネルを開いている時のみロック機構部をライトアップする回路がこれ。
今回、5V用がなかったので12V LEDテープライトを使用。
Websocketの接続・切断時にライトをON/OFF、使用したESP32S3ボードにおいて出力設定したGPIOピン電圧3.3Vの有無をNチャネルMOSFETのゲートが感知して12V ACアダプタからのドレイン-ソース間の電流を制御。
ただ、期待通り、機能はしているのものの、(LEDテープは抵抗内蔵?だから別途抵抗は不要だよね?、LEDは逆流しない?から整流ダイオードは不要だよね?とか)回路として安全なのかとか、正しいのかについては自信なし。
解錠・施錠方法について。
NFC/RFIDカードキー・タグ・シールキー、対応スマホ・スマートウォッチなどについては、パネルに近づけるだけ。
キーパッドについては、後掲スケッチでは、指定した桁数のパスワード(暗証番号)の後に[*]を、入力をやり直すには、[#]を押すだけ。
ブラウザについては、ライブ映像を確認しつつ、[施錠/解錠]ボタンをタップ・クリックするだけ。
ボタン(レバー)は、押すだけ。
何れの方法もモーションセンサーでサムターンの傾きを検出し、施錠されていれば解錠、解錠されていれば施錠します。
ストレスフリーなこともあり、正確に計測したことはありませんが、どの方法もタイムラグは、ないようなもの、あって1秒くらいでしょうか。
物理鍵で開閉する方法については、言わずもがな。
ドア内外とWeb操作機能付きカメラ、3つのスケッチ共にmDNS(Avahi/Bonjour)対応としつつ、Android対策でIP固定、無線アップロードArduinoOTA対応、送受信は、ルーターを介したLAN内TCP通信。
ドア外の認証パネルについては、メッセージ内に仕込んだID/パスワードをパネルからドア内へ、ALLOW/DENYをドア内からドア外パネルへ送信する恰好で認証。
続けてドア内ロック・アンロック機構も同様に、サムターンと共に回転するよう仕込んだモーションセンサーで角度を検出し、サムターンの向きを検知しつつ、状態に合わせて作動(解錠・施錠)。
認証パネルではRFIDとキーパッド、ドア内ロックについては認証パネル操作とブラウザ経由のWebロック、ボタンスイッチ及びモーションセンサー用に何れもFreeRTOS(リアルタイムOS)搭載のESP32のCPUにおいてデュアルコア(コア2つ)+追加タスクでマルチタスク。
コアもタスクも同じxTaskCreatePinnedToCore関数でコアを何れにするかによってマルチコア(ESP32の場合、0か1別々のコア)、マルチタスク(同一コア上で別タスク)、これらの併用を使い分けできます。
ESP32のCPUにおいてデュアルコア(コア2つ)、マルチタスク(CPUコアに関わらず複数タスク)を使うにあたり、タスク関数名とタスクハンドル名を同じにするとエラーになるので注意。
各タスクのスタックサイズについては、限界まで追い込んだわけではないものの、大小共に過ぎたるは動作・挙動に影響があるにせよ、それほど制限はきつくなさ気、1000もしくは、1024の倍数が無難と思われ、今回は後者を採用、処理に応じて十分なサイズを模索することになるでしょう。
今回の処理については、1024だと支障が出るケースがあった一方、コア・スタック数との兼ね合いもあるでしょうが、2048、3072、4096、5120、6144、7168、8192、10000などでも動作しました。
実は、知らず知らずに決まった値に置き換えられているなんてこともあったりするのかも?しれませんが。
コア・タスクには優先順位(1〜24、大きいほど優先度が高い)があります。
今回認証パネル側のカードとパスワードの読み取り・送信については、何れも甲乙つけがたいので共に1とし、期待する動作をしていますが、一方を1増やしただけで機能しないなど動作に影響が出たこともあり、これも処理に応じて設定する必要があるようです。
デュアルコアでコアを別にした認証パネル側については、コアが別なのであまり意味はなさないでしょうが、それぞれ優先度1としました。
デュアルコアでタスクを4つとしたドアロック機構側については、幾通りか試した結果、サムターン角度の計算のみ優先順位3、キーパッド認証とカード・タグ認証のみ通常のコアと同一のcore1、ブラウザボタンスイッチ、物理ボタンスイッチ、それぞれの応答、解錠・施錠タスクをcore0でデュアルコアとしつつ、優先度は何れも1としました。
また、センサー値をリアルタイムに受け取るべく、今回は、キュー(xQueueCreate()/xQueueOverwrite()/xQueueReceive()など)を使いました。
サンプルスケッチでは、パスワードの桁数は固定、6桁としてあり、より強固にするには、双方のスケッチで桁数を変更のこと。
また、サーバ(ロック機構)側では、FeliCa、MIFARE、パスワードを同一の配列に入れていますが、数が多ければ多いほど、別にした方がよりスマートであり、実感できるレベルか否かは別として認証にかかる時間もより短縮できるかなと。
そういえば、この配列、Arduino IDEでWarningが出ていて深く考えることもなく無視しましたが、修正?するか、もしくは、他の方法の方が良さ気。
ドアロック・アンロックシステムの認証パネル(ドア外RFIDモジュール/キーパッド)側のスケッチはこんな感じ。
ドアロック・アンロックシステムの認証、施錠・解錠機構(ドア内側ロック機構)のスケッチはこんな感じ。
ブラウザを介したロック・アンロックボタンは、鍵のライブ映像配信用WebサーバとしたESP32カメラにもたせることにしました。
まず、ESP32カメラには、技適ありのESP32S3(freenove ESP32-S3-WROOM-1)を使用しました。
ついては、スケッチもFreenove技適済みカメラ付きESP32-S3-WROOM-1開発ボードの通りに[FNK0085 Freenove ESP32-S3-WROOM Board]用をダウンロード、その中の[Sketch_07.2_As_VideoWebServer.ino]をベースとしました。
その際の注意事項もリンク先にありますが、ファイル構成は次のようになっています。
これをmicroSDカードは使わないものとしつつ、スケッチとディレクトリ名を任意のファイル名に改名してこのようにしました。
この内、編集するのは、esp32_cam_with_web_lock.inoとapp_httpd.cppの2つ。
そのesp32_cam_with_web_lock.inoのスケッチがこれ。
技適ありのESP32S3(freenove ESP32-S3-WROOM-1)カメラではないカメラを使う場合は、camera_pins.hを参考にスケッチのdefine値を変更のこと。
また、Webロック用の施錠解錠ボタン、カメラ映像、自作スマートホーム操作パネルのメインメニュー遷移ボタンが配置されたWebsocket通信等JavaScriptを含むHTMLファイルソースなどをapp_httpd.cppに定義しました。
内、定義部分がこれ。
htmlでサイズを%指定しただけ、スマホには良いですが、パソコンやタブレットには、ライブ映像サイズが大き過ぎる感があるのでCSSなどで調整した方が良いでしょう。
この場合、WebSocketクライアントは、ESP32カメラ、WebSocketサーバとなるのは、キーロック機構用ESP32ボードなのでアクセスすべきIPアドレス(とポート)は、ESP32カメラではなく、キーロック機構用ESP32ボードのものとします。
これにより、ESP32カメラのIPアドレスにアクセスした際、ロック・アンロックボタンやライブ映像が表示され、ロック・アンロックボタン押下時、設定値をWebsocketを介してロック機構用ESP32ボードに送信します。
ちなみに当初、小洒落たCSSでタップ・クリックの度に角丸の四角形が回転しつつ、中央の「開」「閉」の文字が入れ替わり、色も変わるようにしてみたら、結構カッコよく良い感じになり、使いたかったのですが、センサー値を取得するのも面倒だし、仮にもラグがあったらしょうもないしと普通のボタンにしました。
終日玄関が暗めなため、施錠確認、キー操作時のみ鍵部分あたりをライトアップさせるのに伴うesp32_cam_with_web_lock.inoの追加ロジック部がこれ。
WebSocketsServer.hの追加とライト点灯消灯用GPIO追加によるもの。
尚、これまで自身は、WebSocketでは、webSocketEventにおいてpayloadによる操作でWStype_TEXTしか使ってきませんでしたが、今回の要件を考えるにあたり、ブラウザ(IPやポート)への接続・切断判定ってどうしたら...?そう言えば、Websocketにはアクセス/切断の選択肢もあったよねというわけで初めてWStype_CONNECTED/WStype_DISCONNECTEDを利用してみるに至りました。
また、app_httpd.cppに定義したHTML/JavaScriptの方はこれ。
JavaScriptにてライト用のESP32カメラへのWebsocketを用意、後述のようなこともあり、結果不要とは思いつつも念の為、keep alive対策として任意データの定期的な送信(ping)を追加。
また、当初、入れていたbody部のJavaScriptを削除。
wssにすればよいのかもしれませんが、少なくともwsだとブラウザのセキュリティ設定によっては、機能しないので要注意。
というのもブラウザの開発者用コンソールを眺めてみるとWebsocketに接続(connect)直後、即、切断(disconnect)される(セッションを維持できない)状況に見舞われ、検索しても即、5分後、10分後になど遭遇した人はいれど、少なくとも即の場合の原因や解決策は見当たらず、なぜ?と悩むこと数日...。
もしやと気づいてみれば、検証を行っていたパソコンで常用のFirefoxについては、[設定]の[プライバシーとセキュリティ]で普段からトラッキング防止機能を[標準]ではなく、意図して[厳格]に、やや強固にしておいたのが原因で[標準]にしたら切断されることなくセッションを維持できたので。
Chromiumも同様に接続後、即切断されますが、デフォルトの設定で拒否されているのか、これについては未だ、原因ははっきりしませんが。
あれから、バッチリ機能していたライトアップですが、数日前から突如、点かなくなりました。
中継器のSSIDに切り替えてスケッチをアップした直後から同症状になり、もとのSSIDに戻しても同じ。
あれこれやってみると映像表示はいけてライトアップがダメ、ライトアップがいけて映像表示がダメといった状況。
他のPCでもスマホでも、ブラウザもFirefoxだけじゃなく、Chromiumでも多少の違いはあれど現象としては同じ、ブラウザキャッシュもクリアしながらやってみるもダメ。
そもそもWebsocketのパスに接続できない、結果、open、closeができていないからなのですが、パスに間違いはなく、というか、機能していた頃のスケッチでダメだったので、むしろ、Websocket周りの問題じゃないでしょという印象。
それもスマートロック用のWebsocketには接続できるのに、自分であるカメラ用のWebsocketのポートには接続できない旨のエラーメッセージ、にも関わらず、そのパスをベースにした映像は表示されたりする状況。
CORS?と思って(ポート番号, "*")としてスケッチ側でWebsocketインスタンスを生成してみたり、app_httpd.cppのストリーム用HTTPヘッダに[Access-Control-Allow-Origin: *]を追記してみたり外したりしてみたものの、どうやら違うっぽい、ポートを変えてみてもダメ。
マルチコアで処理を分けてもダメ。
なにか仕様が変わる境にあったのか?何れにせよ、未だ原因不明。
ふぅ...やっと解決。
というか、原因は不明なまま詰まったのでライブラリをWebSocketsServerからESPAsyncWebServerとAsyncTCPに変更してみたら、いけました。
inoファイルの追記・編集はもちろん、プロトタイプ宣言含め、startCameraServer関数は使い続けつつ、app_httpd.cppのURLトップページ表示に関する一連の部分をコメントアウト(さもないとESPAsyncWebServer側の設定が有効にならない)、代わりかつ、ついでにSPIFFSを採用、当該スケッチフォルダ配下に作成のdataフォルダにindex.htmlファイルを作成してアップロード。
尚、WebSocketもサポートするESPAsyncWebServerでAsyncWebSocketインスタンス生成においてポート指定方法の有無すらわからなかったので、それまで[:81]としていたところをスケッチにおいて[AsyncWebSocket ws("/ws");]、よってアクセスすべきJavaScript側のWebSocketインスタンスのパスも(URL or 標準ポート付きのURL:80に続けて)[/ws]に。
一方、カメラ映像であるimgのsrcの方は、app_httpd.cppのストリーム用コードをそのまま踏襲したので(ws://ではなく、http://とした)[URL:81/stream]のままとしました。
あと最終的に[初期値]に戻したものの、対処中にArduino IDEの環境設定でコンパイラの警告を[全て]にしてみたり、[ツール]から[Core Debug level]を変更したりしたからか、エラーでつまづいた関係で次のようにして凌ぎました。
ESPAsyncWebServerライブラリ配下のAsyncEventSource.cpp/AsyncWebSocket.cppで既に数行コメントアウトされているのに1つだけ残っていた[ets_printf()]行を、また、WebAuthentication.cppの[#ifdef ESP32]部で[mbedtls_md5_starts_ret()]/[mbedtls_md5_update_ret()]/[mbedtls_md5_finish_ret()]の各行をコメントアウト。
これはなくてもいけるような気はしますが、setup()内のserver.on(...){}で[request->send(SPIFFS, "/index.html");]の前にDefaultHeaders::Instance().addHeader("Access-Control-Allow-Origin", "*");のようにしてオリジンの他、["Access-Control-Allow-Headers", "*"]、["Access-Control-Allow-Methods", "GET, POST, PUT"]を入れてみました。
RFID/キーパッド実装については、合わせて指紋認証までやっている次のURLを参考にさせて頂きました(なぜかアクセスできないこともあり)。
TCP通信実装については下記を参照させて頂きました。
感謝。
トップページから転載・追記。
既に運用から2ヶ月以上経過で今回記事をアップ。
2023/11/21に思い立ち、2023/12/30にスケッチ完成、モノもほぼできていたのに稼働は、その2ヶ月後の2024/02/13、更に記事のアップが更に2ヶ月以上経った今日2024/04/23という本来あり得ない状況になったのは、G社周りでゲンナリする状況が相次いだから...。
さておき、作ってからカード認証についての注意喚起の記事を見つけてしまいましたが、とりあえず、カードには、スキミング防止カードやケースを使用、セキュリティ・防犯・安全対策するものとします。
FFC/Flexible Flat Cableをドアの隙間に配線していましたが、経路が過酷だったらしく、認証に影響が出て、もう1本買ってあった方と交換、ほぼ開閉しないサッシ経由で配線、快調。