|
|
|
2023/02/25
カテゴリ：DIY:スマートホーム（自作と機器設定)
以前よりスマートホーム機器を自作してきましたが、その際には必ず
「スマートホーム機器に繋ぐ電源とネットワーク接続」が問題になりました。 ＬＡＮケーブル・ＷｉＦｉ飛距離・ＷｉＦｉ接続数・ＷｉＦｉ機器交換ナドナド そんな中で2021年頃よりESP32/ESP8266で使えるESP-NOW通信を使う様になり 独自作成の中継ハブ機構を作りました。中継さえすれば家の隅から隅まで通信が 可能になり満足・・・ するツモリでした・・・ が・・・ 最近WiFi MeshとBLE Meshという規格の機器が出つつあり、独自の中継ハブ機構は 自分でも「なんか古クサイし設定が面倒クサイよね～」と思う様になりました。 そこで！ 2024年になって独自のMesh機構を思いついたので挑戦してみます。 約1年に渡って中継ハブ機構を検討したからコソ可能な案カナ？っと。 =>独自Meshの基本構想 ・ネットワークへの接続調停無しで即データ送受信出来る様に・・ させたい ・通信伝達はESP-NOWのBroadcast送信を使う。 ・受け取った通信はBroadcast送信する。次に同じ通信を受け取ると破棄。 ・直接相手局と送受信するモードも用意しておく。 ・メッセージの伝達は通常の基地局が担う。(専用のハブ局は不要) ・メッセージはテキスト200バイト程度が一区切り（バイナリや大サイズは未考慮） ・メッセージ送信成功が判る受信応答と未受信時再送を考慮・・・ する ・iOS機から機器一覧が見れる様にする(この時は通信頻度が増大するが、これを想定する) ・通信頻度は各機で１時間３電文程度を想定、（通常での混信は想定外） =>何となくソフトを作ってしまいました。 とりあえず８台を繋いで動くソフトを作りました。 以下の様な感じでつまづきましたが、まーソレ・・・ エイヤッで対処してます。 つまづき１：要求にあったMesh機構ライブラリが無い！ 電池駆動で毎時センサ値を報告するセンサで１回の動作時間を １秒以内に収めようとしたら良いライブラリがありませんでした。 折角なのでMACアドレス・論理アドレス混合で動く仕様を考えます。 つまづき２：Broadcast送信で非暗号化とかナメとんのか問題 以前の中継ハブ機構も非暗号化でしたがMACアドレス指定だったので、 「まだマシ」でしたが今回から常時Broadcast通信です。 そもそも僕の独自仕様をワザワザ解析してチョッカイを誰がするんだと考えると悩むダケ無駄。 つまづき３：従来の自作中継ハブ機構どうすんねん問題 Mesh機構と中継ハブ機構の間は通信できない仕様にして諦めます。 ただしGoogleSpreadSheet・BLEブリッジ・リモコン受信機構は、 Mesh機構と中継ハブ機構双方の通信を受け付ける仕様を構築します。 ＜これで常設基地局が３基地局も出来ちゃっう感じです＞ つまづき４：基地局４台ぐらいで送受信が困難になる。 iOS機からBLEブリッジ経由で各基地局との通信が頻繁に失敗し始めました。 ESP32とESP32C3とESP8266で行ってるとESP8266の方で顕著に発生。 最初の発信は電波状況が良くても次の発信は数局の発信で混信が原因と予想。 対策１：各基地局ディレイを設けてタイミングをずらす 対策２：非伝達基地局を設定出来る様にする 目標 ：伝達基地局10台ぐらい集合して動かしても動く確認までしたい。 つまづき５：重複した論理アドレスでも運用できちゃう MACアドレス6桁に任意アドレスを振って論理アドレスとする仕様にしたので、 重複アドレスでもできます・・・ 今のEthernetも一緒だと思えば運用次第ですね。 =>何となく動くソフトで動作確認しています 一応従来ハブ機構と通信ライブラリの差し替えコンパイルで動く様に作りました。 当初は従来ハブ通信との共存を考えていたのですが作成したMesh通信が予想より 調子良いのと従来ハブ通信との共存処理の手間と不具合で死んでも無問題な事から 完全移行をする事にしました。まずは自宅から行っていく事にします。 気づき2:WPS機能作るよりセンター機を設ける？ WPS機構を突き詰めていくと「何処へ報告すれば良いか？」が判らないから ペアリングが必要なんだと気づきました。 そうなると答えは簡単です。 「報告先を固定にしとけば万事解決」という事でセンター機を設けます。 センター機はGoogleSpreadSheetから設定を読み込んで動けばいいですよね。 ココから下は中継ハブ機構に関する日記です 2018年より検討を始めたESP-NOWですが個々の機能検討も進み 自宅や古民家に複数台設置してデータをGoogleSpreadSheetに上げる 事が出来る様になりました。またNatureRemoの赤外線リモコン頼りで 「OKグーグル、居間の電気を灯けて」も対応可能になっています。 設定が面倒なのと照明ユニットの交換が進まないので自宅と古民家１室づつですけどね～。 そして最近はDeepSleepや常時電源OFFを使って電池駆動の機器も 検討し始めたのですが、いざ動作確認段階になると「置きたい場所で ESP-NOWの通信ができない」「デモで部屋の端から端までの通信が できない」などと残念な問題に遭遇しました。 実例：「玄関チャイムのボタン」「侵入者検知のPIRセンサー」「庭の植木鉢に土の湿度計」 電池駆動が主ですが、家の面積が広いとそれだけで通信が届きません。 また以前からの検討で近所でWiFi AP局が乱立してたりスマートフォンが多数あったりすると ESP-NOWの飛距離が怪しくなる症状があるので、設置時の飛距離を過信するのは危険です。 そーいった時はESP8266/ESP32の電波強度等疑いたくなるのですが、 それ以前にAliExpressで買った品が規格品ですら怪しいと気になります。 検品で電波強度が高ければ設定で下げれば済む話ですが、元々低い奴は正規品での販売は無理 なので規格外品として処分されるカモしれません。(！！僕の妄想なので事実未確認です！！) とは言え今までの動作確認でESP機毎のWiFiの飛び具合にバラツキがある と思っている僕としてはESP-NOW用の中継ハブ導入を検討します。 ユニットはESP-01Sで管理機器台数は最低64台ぐらいを目指します。 ※運が良ければ今まで作った機器に組み込んで中継ハブ専用機を作らない様にしたいです。 ※ESP-NOW機の接続数が20台近辺なのを考えると中継ハブの用意でArduinoIDEソースを いじらなくて見かけ上の台数が増やせるなーと考えてみたりして・・・ ESP-NOW用中継ハブの作る簡単な初期テスト まず最初に気になるのは複数台のESPNOWユニットの中継動作できる のかどうかだったのですが、簡単に２回中継動作させる事が出来ました。 ※お手軽に会社の敷地で試しました、コンクリート壁や金属棚など通過しています。 同機材でメッセージのループバックを行ったところ約13mSec程度・・ 機器１=>中継１=>中継２=>機器２=>中継２=>中継１=>機器１の 経路を辿っての応答なのでコンナもんかと思います。 また通信経路にて人間の往来があった場合にメッセージ喪失が発生し易い 事も確認しており、重要なメッセージは受信確認が必要と感じました。 僕が使う用途では十分イケてます。 ESP-NOWハブ仕様作成の七転八倒メモ 各ハブを動かす為の基本ソフト作成・動作確認でのメモです ・既に同一ハブ番号のハブが稼働している ハブの管理ができていない時にあった内容です。 後から電源を入れたハブは野良ハブとして待機させたいトコロです。 同時の電源投入だと早く調停したもん勝ちという状態も解決したいトコ。 ・同一の親ハブ番号を持つ子機間は直接通信させたい もし親ハブが機能停止した場合に遠方の機器への通信は無理だとしても、 近所の機器間の通信が子機間で維持できないか考えます。 ※あまり意味の無い事かもしれない・・ 解決・無理・論理アドレスとＭＡＣアドレスの平行運用がしたい ハブ未登録の機体を登録する為に必要な機能。 また個々で通信する時も 使えますがMACアドレスより論理アドレスの方が運用が簡単なのが悩ましい。 iOS(Pythonista)とBLE通信する機体のみで平行運用する事にしました。 Pythonista画面でハブ・子機設定できるようになったので良い事にします。 解決(そんなもんだと思う事にした)・broadcast応答で６台以上の機器は見つけにくい 台数を増やして調べた印象なのですが、近くに１０台以上の機器があるのに HUB機のbroadcastに即応答するのは毎回同じの６台ぐらいの印象です。 親機子機のbroadcast時の通信が原因と予想。 現状のソフトはデバッグが簡単なので放置します。 解決・broadcastが欲しい・・・・ 各ハブ通信範囲が違うので総てでbroadcastしないと隅々まで飛ばないし、 broadcastした実機に応答を返す仕様も考える必要があるし 各ハブの通信重複地域ではどちらに応答するかも考えないといけないし・・ イロイロ考えた末に親機・子機の関係が出来ている状況は親機にbroadcast応答を返す仕様にして、 それ以外は今までどうりの応対をする事にしました。他にも手間はありますが何とかなった感じ。 解決・せっかくなので時刻を同期したい ネットワーク内にNTPで時刻合わせしている子機に沿って時間同期しました。 特にどーって事では無いです・・・・ 折角なので同期しただけです。 解決・論理番号＋子機番号を各子機の論理アドレスとします。 簡単な仕様で作れそうだったので現在検討中です。 ※従来仕様のMACアドレスを使った通信は各子機間で残しておきます。 解決・ハブ機・通信子機が消滅した時の処理・・ 仕様が簡単なので、ケセラセラです。 考え的には解決していますｗ 解決・ハブ機に論理番号を与えて管理します。 ハブ機毎に制約を作ってハブは隣接する論理番号としか通信しません。 ※ハブ間の接続ルールの簡素化と安易に通信距離を延ばす事を考えました。 ※１番と４番のハブで通信する場合は１・２・３・４番のハブに電文が流れます。 各１階に設置したとしても３階建て＋屋上の家がカバーできます。 解決・ESP-NOW１台の接続台数は標準２０台程度 ESP-NOWの仕組み上は台数無制限で繋がりそうですが、ライブラリの Define定義によって台数制限がかかっています。今回は１HUBに１0台の 子機を繋ぐツモリで仕様を考えています。 断念・メッシュ通信仕様 論理番号＋子機番号で動かす仕様を拡張してメッシュ化できないか・・・ まずは論理番号＋子機番号でマトモに動く様になってから考えます。 ESP-NOWハブ設定ツール作成の七転八倒メモ ESP32のBLE通信で繋がるiOS(Pythonista)の設定ツールでの機能追加メモです。 解決・アップデートでPythonistaのBLE通信使えなくなった 仕方ないのでWiFi UARTで繋ぐ仕組みで逃げました。 セキュリティーは最悪になりましたが、独自仕様を解析する人いないでしょ？とタカくくってます 解決・新規ハブと子機の登録処理 新規ハブに論理アドレスを設定するだけでした。しかし運用中の状態で 新たに追加する時はネットワーク外の端末を検出・通信する必要があり 特別設定で動かす条件決めに苦労しました。 ※気にせず動かせるならメッシュ運用が出来るのですが、ロストした子機の検出が難しいです。 解決・子機の削除処理 子機とハブで記憶するＭＡＣアドレスと論理アドレスを消す ※ハブを削除した後は子機にハブ経由でアクセス出来ない状況が発生したので、対策として ハブと連携が取れていない子機はＭＡＣアドレス運用の電文で動作する様にしました。 解決・ハブの削除処理 ハブの論理アドレスを消してハブに残った連携用のＭＡＣアドレスを消す 程度で完了しました。※先に子機の削除をしないと面倒な事になる事が判りました。 解決・ハブ一覧と子機一覧 pythonista3で接続中機器の一覧を各画面で表示出来る様にしました。 いままで作った各機能 解決・DeepSleepする子機 DeepSleepから復帰する毎にハブと調停するのは電力消費がキツイので、 ハブと子機にお互いのMACアドレスを記憶しておき毎回照合する事にしました。 ＝＝長期で動作確認しないと判らなそうな機能です＝＝ 解決・動作確認中・iOS(Pythonista)との通信について 通信専用の子機を用意する事にしました。コイツだけ特別にbroadcast通信を 行ってネットワーク外の未設定子機の通信をして初期設定が出来る様にしました。 解決・動作確認中・毎時GoogleSpreadSheetにデータを上げる奴について ハブにすると収集が付かなかったので子機として作りました。 今まで動作確認していた端末の再設定が面倒クサかったので、MACアドレス直で 送信されたデータも特例として受付可能にすることにしました。 動作確認中・普通の子機 ネットワークから脱退させる仕様・設定・画面を作る必要がありました。 ネットワーク未加入の端末を設定する仕様・設定・画面を作る必要がありました。 ネットワーク未加入でも動作させる様にしました。(従来モード) ハブ実機の作成メモ ・プラットフォーム：ESP-01S 安くて省スペースを考えるとコレしかありません。 ・電池駆動も考慮 ハブを電池駆動する事を考えてハブ機はデータ収集端末と同じ機構を備えて 一定周期で電源電圧を報告する様にします。 電池のソーラー充電も考えるならキャパシタ駆動とかまで検討したいですね。 ・簡易仕様  以前DHT-11で温度測定をしていたユニットが検討終了でゴロゴロしていたので DHT-11を外した状態で使う事にしました。電源電圧が測れない簡易仕様ですが 台数検討には持ってコイの端末かなっと。 あとは照明のOn/Off用のユニットから5V電源を供給してもらって動くタイプも 用意すれば良いかなーと思っています。(当分機能統合はしないで別々で作る予定) 作成メモ 何とかハブ機と子機のソフトを作り子機＜＞ハブ＜＞子機の通信が 出来る様になりました。ココからは稼働テストですが、どうなるやら・・ 結構良い感じで動いています。 現状はESP-NOWハブの台数は３台で ハブ両端の距離で７ｍぐらいしか無いので、２台ほど追加してハブ両端で １２ｍぐらいに欲張ってみたいトコロです。 とは言えその前に接続する ユニットを増やした方がいいですよね～。 と思ってユニット作成中～ 固定仕様に関するメモ ・ハブ機は０～Ｆ/ハブ子機は１～Ｆとする事で0x00～0xFFでMACアドレスの 代わりとして使える様にしました。 ・メッシュWiFi風は欲張らずにハブの０～Ｆで隣接する番号との通信で割り切る 事にしています。 ※ハブ０からハブＦへの通信は１２３４５６７８９ＡＢＣＤＥのハブを経由して行うノンビリした仕様 ですが１区間３ｍで考えると両端子機も入れて５４ｍの距離を通信する事が可能になります。 ・ハブ機８の配下に特殊機能を配置する事にしました。 GoogleSpeadSheet書き込みや赤外線リモコンなどの登録時に面倒だったので 「もう固定アドレスにしちゃえ！」って割り切る事にしました。 ※システムを売る場合は困ると思いますが、僕の自宅・古民家で運用するESP-NOWシステムなので 設定などが楽な方に割り切る事にします。 2024年9月14日 これから検討を開始します 8月に映画撮影とかの電気機器撤去でログが途絶える良い機会がありました。 今までのESP-NOW機器をESP-MESH仕様に再コンパイルして検討開始します。  とりあえず用意出来る15機器、後は照明スイッチとかありますがオイオイです。 2023年4月より、作ったハブの動作確認を行っていきます スマートホーム計画もジワジワと進んでおりハブの設置場所や使用機器としての スマートスイッチ照明も出来つつあるので古民家に取り付けています。 ※スマートスイッチ照明と一緒にハブも取り付けてます。  古民家でWiFiを使っている時に「こんな距離でも切れるんだ」という実感を 元に５ｍという距離を割り出したので途切れない距離として３ｍぐらいの間隔に ある照明に設置しています。※10/11/12は照明が間に合わないので仮設で置いてる ※図に書いてみると今までWiFiが届かなくて首を傾げていた場所が遠くて電波が届かないのに納得です。 ※現在データをハブ番号順に渡す仕様で作っていますがMESH仕様で考えたい衝動に駆られます。 ＊＊いざ設置してみて＊＊ ・設置・初期デバッグ取りを終えてからはGoogleSpereadSheetへのセンサデータ 書き込みも順次アップされ妥当な値が上がってきているので良い感じであります。 ※初期デバッグでは台数を増やすと出てくるバグとかあったりして結構大変でした。 ※設置状況から見るとやっぱりメッシュネットワークに各子機の自動調停が行いたくなります。 ・ハブを８台動かすのはもったいないのでハブに機能追加したくなる まだ初期段階ですが管理機４台にユニット7台ぐらいしか無いのに８台のハブは なんだか間抜けっぽいのでハブに機能追加したくなります。 ただ・・ 暴走しにくい機能を入れる必要があるので凄い悩ましいです。 2023年8月 中継ハブに報告データの一時預かり機能を追加する 中継ハブを作ったお陰でユニットを配置できる場所が格段に増えたお陰で古民家では 照明の半数をスマート化しました。またDeepSleep機やセンサON動作機も配置して 結構イケてる感じはしていたのですが・・ DeepSleep機とセンサON動作機の通信 内容を把握する術がGoogleSpreadSheetしか無いという事に気付きました。 そもそもGoogleSpreadSheet書き出し設定する前は確認する術が無いｗｗｗ これについては悩んでも始まらないのでハブのソフトに仕様を追加する事にしました。 配下のデータ・電文を一時預かりする 配下のデータをGoogleSpreadSheet報告機に報告する 配下機器は15台しか無いので各128byteでも2Kbyteぐらい保持できるだろ？と想像 今までは配下の機器はGoogleSpreadSheet報告機に報告していたのですが、これだと 送信応答待ち時間のバッテリ消費がもったいないので直近のハブとの通信で終わらせる 仕様を考えます。  電子工作ランキング  お気に入りの記事を「いいね！」で応援しよう
Last updated
2024/09/14 01:40:00 PM
コメント(0) | コメントを書く
[DIY:スマートホーム（自作と機器設定)] カテゴリの最新記事
|
