スマートロックシステムを自作してみた話。
もちろん、後付け可能。
ここ数年、スマート系の自作づいている自身も全く作る気も予定もなかったスマート系デバイスだったこともあり、今更感はありますが、いざ作ってできてみると、もう手放せない、なくてはならないものになっており、常備はしているものの、以来、物理鍵を使ったことは一度もありません。
これを作るモチベーションが上がらなかった理由は、ほぼ唯一「締め出される可能性を払拭できない」ことでしたが、必要に迫られ、いるならいるで当然、自作だよねと、よく考えてみたら、払拭できる目処が立ったので。
自作したスマートドアロックの仕様は、おおまかに言うとこんな感じ。
ブラウザからの操作は、あったとしても基本、在宅時でも外出時でも鍵のロック状態確認がメイン、自作中のドアホン完成後なら、併用して親類・友人・知人来訪時に使うかどうかというところ。
尚、仕様変更で理由などは詳述しますが、カード/タグ認証は、(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も同様に接続後、即切断されますが、デフォルトの設定で拒否されているのか、これについては未だ、原因ははっきりしませんが。
今回、RFID/NFC認証に使ったのは、ELECHOUSE NFC MODULE V3(PN532互換)ボード。
PN532/ELECHOUSE NFC MODULE V3ボードは、HSU/IIC(I2C)/SPIに対応、それぞれ同ボード上の印字に従ってディップスイッチ2つの組み合わせで設定する必要があります。
ここでは、I2Cとしたのでスイッチ[1]を[ON]、[2]を[OFF]としました。
尚、このスイッチ、表面にセロファンのようなものが貼られており、回路に組み込んだ方は、これを剥がして設定しましたが、再検証用にもう1つ買った方は、ふと、このまま切り替えるのが正解か?と少しシワが寄りつつも、剥がさずに切り替えました。
ちなみにスケッチ書き換え・アップロード直後に関しては、結構な頻度でというか、ほぼほぼ起動時にNFCボードが見つからず、そうなるとソフトウェアリセット(ESP.restart())ではダメでUSBポートに挿し直すなど電源を入れ直す以外、NFCボードを見つけることができなくなることがありました。
NFCモジュールボードが見つからない場合、停止するロジックにしてるからですが、キーパッド入力もできない為、OTAでもこうだとするとスケッチを書き換える度にUSB抜・挿なり、スイッチ付きコンセントならOFF/ONなりする必要が生じます(今のところ、ソフトウェア的な解決策はなさ気)。
一方、運用してみるとキーパッド入力による認証、施錠・解錠はできるのに、当初できていたカード認証自体ができない状況がたまに発現、つまり、当初、機能していたPN532モジュールボードが何らかの理由で機能停止したようで、電源切・入を要する状態になることが...。
認証パネルが外だけにWi-Fiが一時的に切断され、再接続される(その際、ELECHOUSE NFC MODULE V3がnot foundになる)ような状況があるのでしょうか?
そこで2台あるアクセスポイントにしている無線LANルーターの内、距離にすると僅かながらも、よりドアに近く、電波障害が少なそうな方にしてみたところ、この現象はなくなったので、やはり、Wi-Fiが途切れるほどに電波が弱かったことが原因だったようです。
尚、通電中、なんらかの状況でVCC/GNDに限らず、PN532モジュールへの配線が外れてしまうと無反応になるので再配線の上、電源断・電源再投入必須。
本稼働させてみると不具合が出る(無線が途切れる)ことはなくなったので特に対処する必要はないと判断しましたが、必要なら遠隔操作を考慮し、認証パネル側は自作スマートプラグから給電、これと別電源のキーロック側の再起動時に認証パネル側のスマートプラグをOFF/ONすれば良さ気。
これに関して前述のスケッチ上は、キーパッドから[#0000]を入力すると認証パネル側とロック機構側をソフトウェアリセットESP.restart()するようプログラムしたものの、現在は、ロック機構側のみ実行、認証パネル側はソフトウェアリセット部分をコメントアウトして実行しないようにしてあります。
尤もロック機構側はそもそも不具合が起きることはなく、認証パネル側も不具合が無線が途切れることに起因し、今となっては解消されたことから、ロック機構側のソフトウェアリセットも必要ないので、ここ以外で機能として紹介もしていませんが。
というわけでRFIDについては、基本、解錠・施錠をし始める程度(認証OKのLEDが点灯する)まで認証パネル(モジュール)とできる限り水平かつ、認識可能な距離に近づけないと機能しないことがありますが、そこさえ留意すれば正常に機能することを確認済み。
他方、キーパッドからのパスワード認証時、何度も繰り返しやっていると反応しなくなることがあり、コアが別だからというのはありますが、一度なるとRFID認証はできるのにキーパッド側は一向に機能しなくなることがありました。
と思ったら、これは、気づかないうちにキーパッドを押し損ねること(があって実際の入力数と認識にズレがあること)に起因する模様であることが判明。
この場合は、前掲スケッチでは[#]で入力値をクリアできるようになっており、クリア後、適切なキーワードを入力し直すことで正常に機能することを確認済み。
なんなら、毎回、[#]から入力を始めても良さ気。
今回、使ったものは以下の通り。
共有できたり、内容物の一部しか使っていないものなどを除き、ざっと使った分だけでも7500円前後ですかね。
3000〜4000円でできるかななんて安易に思っていたものの、結果、案外かかってしまいましたが...。
言うまでもなく、単なる個人の趣味、むき出しだったり、仕上がりの雑さはさておき、単品製作でハイスペックであることを考えると市販品よりは遥かに安価なので良しと言うことで。
それにワケあっていくつか機能を削ぎ落としつつもスマートロックにRFID認証とパスワード認証が付いていてパソコンに限らず、RFID認証だけでなく、在宅時や外出時にブラウザ操作でもスマホやタブレットが使えて鍵のライブ映像付きとなれば、尚、お得!?
自作ライブカメラ分コストアップしてますが、それは市販品を使っても同じということで。
ちなみにウェットシート用の開閉扉、後に気づけば、サイズはともかく、ダイソー、セリア、キャンドゥなど100均各社ともに扉のみ単品で取り扱いがあり、ダイソーとセリアに関しては選択肢が複数ありました。
認証パネルについては、当初、流用を想定、100均やAliExpressにもあり、何れも調達してみた市販の「お風呂でスマホ操作可能なケース」だとESP32開発ボードのピンヘッダをストレートからアングル(L字)タイプのものに替えてはんだ付けし直しても尚、微妙に空間が足りず、結果、先のケースを使用するに至りました。
通信については、結構な回数、いろいろやってみた結果、ESPNowもUDPも試すまでもなく、TCP通信で実用に十分と判断。
尚、それぞれは難なく実用的な時間で操作可能も、いざMifare/FeliCaを併用してみると共に反応が激遅(FeliCaに至っては30秒前後)になることが判明。
タイミング的には併用直後からも通信方法に起因する可能性を排除できることを確認すべく、UDP通信で試しても同じ様子。
よって今回は、FeliCaの使用を断念、予定通り、TCP通信を採用。
オートロックについては、時間経過やBluetooth等いくつかのケースで実装可能も、玄関先のポストを確認とか、草花に水やりとか、隣家訪問とか、スマホやNFCカード、物理鍵を持たず、鍵をかけずにちょっと玄関を出ることもあり、キーパッド入力があっても万一停電になったら締め出される可能性を考慮し、不採用。
サムターンの向き(開閉状態)のチェックは、物理的な鍵での開閉もあり、ESP32ボードのリセットや停電・復帰もあり得、電源復帰したなら、まさに、その時点の状態を知りたい為、DBデータ等ではなく、都度、センサーによる検出で判定。
というわけでどこかでひっかかったり、故障したりする可能性はさておき、普段はセンサーで事足りる気がする、万一の停電時も停電前の状態を保持しておいても意味はなさ気なのでEEPROM/SPIFFS/littleFS/SDや外部DBへの保存はしない。
臨時キーについては、考慮していないながら宅内にいればもちろん、外からでもVPN経由など遠隔からスケッチを修正する恰好でなら発行することも可能も、今まで必要だと思ったことは1度もないので今後もないものとして臨時キーの発行はしない。
鍵の遠隔操作については、そもそもドア内やドア外での操作は時間がかかるため、基本、他の方法を使い、Webロックを使うことはなく、締め忘れなどロック状態確認以外での使用機会はまずない、同居人がいる場合などかえって操作が迷惑な可能性などもあり、一般にも不要と思われる。
が、数日〜長期不在などを想定した場合、なんらかの防犯対策になり得る可能性をも考慮し、Web操作により、ロック機構部のライブ映像を表示させつつ、iPhone、iPadやAndroidデバイスなどスマホ・タブレットからも操作可能としておく。
鍵の開閉(サムターンの回転)機構において当初想定し仮組みしてみたギア3枚による間接的なサムターン操作構造は強度的に無理があり、手持ちのSG90/MG90S/28BYJ-48など何れも機能させるに至らず、MG995はタイミング悪く壊れており、MG996Rを追加購入するも到着を待つまでもなく、構造上の問題と見切って見送り。
また、手持ち材料から軸径6mmのMG996Rより5mmのステッピングモータ28BYJ-48の方が都合が良い中、作業の流れ上、他のモータや改造前には試さなかったものの、気分転換にトルクや回転数アップとなることが知られている28BYJ-48をユニポーラからバイポーラに改造、先んじてこれを試してみるとモーター軸延長上で直接サムターンを操作することはできたため、今回はこれを採用することに。
尤もより省スペース化できることに越したことはなく、当初想定の3枚ギア構造の再検討、各種モータでの再検証の上、いけるのなら、運用後にでもギア3枚構造に差し替える予定。
あと意外とセキュリティ的に脆弱、誤動作の可能性、オーバースペックなどの理由からノックのリズム、音声操作、また、指紋認証、静脈認証、顔認証など生体認証による解錠・施錠は除外。
給電には、次のような理由からスイッチ式コンセント経由を採用。
電池式なら停電時でもキーロックシステム部分は使えるとは言え、今回の場合、全てESP32間はESPNowを使用の上、カードキーやキーパッドなら認証パネル側も併せて電池式にしないと停電時には使用できず、ライブ映像付きブラウザパネル上のボタンに至っては仮にIPカメラを電池式にしたにしても停電時にはLANひいてはVPNが使えずスマホ操作が行えず、意味はなく、一方でオートロック機能をなしとし、ロックして出かける際は、万一に備え、物理鍵常備前提であり、通電時も電源断時も物理鍵での開閉が可能であること。
仮にそれらがクリアになったとて予定されたものならまだしも、不測の停電になることは稀、それに比べると仮に数年もてば似たようなものも数ヶ月程度なら電池交換の方が頻繁な可能性が高く、電池にする場合、今回の構想だと玄関ドア内外の2つのESP32ボード共にそうする必要もあり、電池切れの心配含め、むしろ煩雑そうであること。
よって今のところ、電池にするメリットを思いつかないこと。
というか、過去検証の為だけにESP32開発ボードにおける電池からの給電をテスト含め、考えてみたことがあったものの、一定時間間隔によるセンサー値のロガー(ログ取り)や植物への水やり、(万一にも電池切れして食いっぱぐれるとかわいそうなので実際コンセント給電にしたくなるだろう)給餌器など時間のほとんどがディープスリープ状態で、かつ、GPIO入力で復帰する方法がない限り、年単位の交換頻度は無理があると思えたのでハナから除外。
RFID/Radio Frequency IDentificationとは、タグとリーダー間の近距離無線通信であり、タグ自体は電源をもたず、リーダーからの電波で起動・データ送信する技術やその概念。
タグには、カード型や各種形状のシールなど様々なタイプがあり。
ソニー発のFeliCaやオランダPhilips社開発のMifare Classic/Mifare Type-AなどMifareは、非接触型の内、近接型ICカードやICタグ、ICシールなどで使われている通信方式。
FeliCa(ISO/IEC 18092|NFCIP-1 => ISO/IEC 21481|NFCIP-2(NFCIP-1+ISO/IEC 14443+ISO/IEC 15693、NFCフォーラム仕様:NFC/Near Field Communication:NFC-F)は、プリペイド式の電子マネーや交通系カードなどで採用されている日本で主流の通信規格。
Mifareは、日本でも古くはテレホンカードなどで使用されたこともある欧州で主流の通信規格。
近年、FeliCa/NFCの一方や両方の機能が搭載されたスマホもあります。
RFID/キーパッド実装については、合わせて指紋認証までやっている次のURLを参考にさせて頂きました(なぜかアクセスできないこともあり)。
TCP通信実装については下記を参照させて頂きました。
感謝。
トップページから転載・追記。
既に運用から2ヶ月以上経過で今回記事をアップ。
2023/11/21に思い立ち、2023/12/30にスケッチ完成、モノもほぼできていたのに稼働は、その2ヶ月後の2024/02/13、更に記事のアップが更に2ヶ月以上経った今日2024/04/23という本来あり得ない状況になったのは、G社周りでゲンナリする状況が相次いだから...。
さておき、作ってからカード認証についての注意喚起の記事を見つけてしまいましたが、とりあえず、カードには、スキミング防止カードやケースを使用、セキュリティ・防犯・安全対策するものとします。
FFC/Flexible Flat Cableをドアの隙間に配線していましたが、経路が過酷だったらしく、認証に影響が出て、もう1本買ってあった方と交換、ほぼ開閉しないサッシ経由で配線、快調。