前記事↓

『ラズパイPICO-W＆Micropython＆MQTT化【その１】』【目的】　複数のラズパイPICOからデータを送り、サーバにてデータを受信、保存する。まず最初にラズパイPICOからデータ送信、PCサーバで受信に関する情報収…

ameblo.jp

↑これのつづきです。
■環境
ラズパイPICO-W

・Micropython

・MQTTライブラリ：umqtt.simple

・Wifi：内蔵2.4GHz帯／DHCP

PC

・N95、8Gbyte、SSD／256Gbyte、Window11Pro、有線LAN接続
・コード開発：Thonny

・操作：macOSからリモートデスクトップ接続

近傍（２ｍ以内）で動作中の機器
・2.4GHz無線マウス３、同キーボード２、Bluetooth機器多数
・WindowsPC３台、macOS２台、スマホ１台

■複数PICO-Wでの接続：その１

まずはPico-W２台まったく同じままで挑戦！

トライ１：Pico-W２台同一トピック、同一ClientIDでPubした場合
　・１台目のPubデータをPythonのSubで受信できました
　・２台目の電源ON・・・

　　２台目のPubデータを受信開始以後に１台目のデータが来ません。

　→１台目の接続が止まったようです。
　　ClientIDが同一の場合、後から接続が先の接続を遮断してしまいます。
　　それを確認したような当然の結果になりました。

ということでClientIDに着目して再挑戦

トライ２：Pico-W２台同一トピック、別々ClientIDでPubした場合

　コードの一部を変更
　　　myId = 'kabayon'
　　　　　　　↑この部分をPICO-W２台で別々にしました。
　結果
　・１台目のPubデータをPythonのSubで受信できました
　・２台目の電源ON・・・

　・２台目のPubデータを受信開始以後、１台目のデータも来ました！

　・が・・・２台目あるいは１台目のデータが「途中から」切れます。

いけてるやん！と思わせて・・・なんでやねん！？

現在の浅い知識から思い浮かべた着目点

【Pub側】

▲最初は受信して途中から切れるから、まるでタイムアウトの感じ。
　Pubのコードの中に関係する項目があるのかも・・・

　→コードを見ますと・・・

　　　# MQTTオブジェクト(変数)定義
　　　client = MQTTClient(myId, mqttBroker, keepalive=3600)

　　この「keepalive=3600」が該当していそうですが・・・
　　3600秒＝1時間・・・これじゃない！他に見当たらない！

▲そもそもPubコード内のどの段階で切れている？
　　１：Wifi接続が切れている？

　　２：MQTTサーバ接続が切れている？

　　３：無限ループ送信から落ちている？
　これを調べるには・・・
　　・２がOKならばPICO基板上LEDを点灯
　　・３がループ内ならば所定待機時間のなかでLEDを点滅させる。
　　　例えば、待機3秒の場合は、

　　　　　待機開始前にLED消灯、0.5秒スリープ、LED点灯、2.5秒スリープ
　　　とする。これなら簡単にできそうです。

　さらにもうひとつ、PubがMQTTサーバからリターンコードを受けているか？

　コードのなかの・・・　
　　# ブローカーからの返信メッセージ確認
　　client.check_msg()
　　time.sleep(3)
　PICO-Wには画面出力がないので、Thonnyでターミナルに表示させる？か、
　I2Cの表示デバイスなどに表示させられるはず。（まだやってません）
　
▲同一トピックだと２台のPubのタイミング次第で衝突？

　~~→Pico-Wごとに別トピックにするとSub側もトピックごとに必要だろうし、~~
　　~~そうなるとトピック切替て受信ということになるし、~~
　　~~しかしそれが本来のMQTTの使いかたのように思えますし・・・~~
　　~~これは安直にトライするよりも別の要因を確認してからにします。~~
　→調べてみますと・・・

　出典：

MQTT パブリッシュ/サブスクライブパターンの概要 - QiitaEMQX Blogをぜひご覧になってくださあい目次MQTT パブリッシュ/サブスクライブパターンMQTT パブリッシュ/サブスクライブでのメッセージルーティングMQTT と HTTP …

qiita.com

MQTT Topics and Wildcards: A Beginner's GuideThis article introduces MQTT topics and wildcards by cases, and answers common questions during use to help readers get started with MQTT.

www.emqx.com

　そもそもSubはワイルドカードのような記述で複数のトピックを同時に取得可能
　だそうです。トピックを「/」で階層的にするのはそういうことなんですね！！！
　自分の例では、Pub側で、
　　test_mqtt/Pico1

　　test_mqtt/Pico2

　といった感じで複数のPICO-Wの各々でトピックを分ければよいようです。

　そしてSub側のトピックを、　　test_mqtt/+
　として受信するとよさそうです。（まだやってません）

　ワイルドカードは「+」。つい「*」と打ってしまいそう。

▲Wifiが2.4GHz帯だから通信が遅い？
　→2.4GHz帯でも通常は10Mbps以上出るし・・・

　　通信速度自体が遅いとは考え難いですが、遅くなる要因はありそう。

　　→半径30cm以内に２台のWifi接続があると混信でデータが切れる？？？
　　　他にも2.4GHz帯利用機器が多々動作しているし、これはあるかも。。。

【Sub側】

▲安物PC上でMQTTサーバーとSubをVScode上のJupyterとPythonで

　動作させていて、かつ結果を標準出力画面に出していて、
　しかもリモートデスクトップでMacOSから操作していたら、

　処理が追いつかない？

　→VScode上でもよいからJupyterではなく普通にpythonで動作させ、
　　かつリモートではなくPCに接続のモニターで操作。

　　Sub動作速度向上させるのに現時点で一番簡単な方法には違いない。

　　ただし、これが原因ではないようにも思いましたので、
　　まずはPub側から攻めてみます。

■複数PICO-Wでの接続：その２

上記考察から、一番先に

　トピックを階層表現に変えてSubでワイルドカードにて受信
とします。問題解決しようとしまいとこれは必要になること。
つぎに、
　Pub接続切れのコード位置を調べる
ことにします。

~~が・・・ちょっと休憩~~

機器配置、トピック、id（Connectid）をこんな感じにしました。

MQQTサーバー：N5105/8GB/256GB、Windows11（23H2)、LAN有線接続
　　　MQosquittoサービス稼働
Sub：Mac-mini/M1-2020/16GB/256GB、sonoma14.6.1、LAN有線接続
　　　VScode＋Jupyter＋python3.11　トピック：test_mqtt/+
Pub：同上　トピック：test_mqtt/kabamini2　id：kabamini2

Pub：i5-12450H/8GB/256GB、Windows11（23H2)、LAN有線接続
　　　VScode＋Jupyter＋python3.11
　　　トピック：test_mqtt/kabanucm3　id：kabanucm3
Pub：PICO_WHM/MicroPython　トピック：test_mqtt/rpp01　id：rpp01
Pub：PICO_WHM/MicroPython　トピック：test_mqtt/rpp02　id：rpp02
Pub：PICO_WHM/MicroPython　トピック：test_mqtt/rpp03　id：rpp03
Pub：PICO_WHM/MicroPython　トピック：test_mqtt/rpp04　id：rpp04
Pub：PICO_WHM/MicroPython　トピック：test_mqtt/rpp05　id：rpp05

ちょっとずつ増やすつもりがどどっといってしまいました。

■結果

いけちゃいました！！！

macOSのJupyterでSubした結果例（抜粋）

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Sub msg: b'kabaMini2 count 756' on test_mqtt/pub_kabamini2 with 0
Sub msg: b'rpp04 send 153' on test_mqtt/rpp04 with 0
Sub msg: b'rpp05 send 50' on test_mqtt/rpp05 with 0
Sub msg: b'rpp03 send 78' on test_mqtt/rpp03 with 0
Sub msg: b'rpp01 send 34' on test_mqtt/rpp01 with 0
Sub msg: b'kabanucm3 count 689' on test_mqtt/pub_kabanucm3 with 0
Sub msg: b'rpp04 send 154' on test_mqtt/rpp04 with 0
Sub msg: b'rpp02 send 63' on test_mqtt/rpp02 with 0
Sub msg: b'rpp03 send 79' on test_mqtt/rpp03 with 0
Sub msg: b'rpp01 send 35' on test_mqtt/rpp01 with 0
Sub msg: b'rpp04 send 155' on test_mqtt/rpp04 with 0
Sub msg: b'kabaMini2 count 757' on test_mqtt/pub_kabamini2 with 0
Sub msg: b'rpp04 send 156' on test_mqtt/rpp04 with 0
Sub msg: b'rpp05 send 51' on test_mqtt/rpp05 with 0
Sub msg: b'rpp03 send 80' on test_mqtt/rpp03 with 0
Sub msg: b'rpp01 send 36' on test_mqtt/rpp01 with 0
Sub msg: b'rpp02 send 64' on test_mqtt/rpp02 with 0
Sub msg: b'kabanucm3 count 690' on test_mqtt/pub_kabanucm3 with 0
Sub msg: b'rpp04 send 157' on test_mqtt/rpp04 with 0
Sub msg: b'rpp03 send 81' on test_mqtt/rpp03 with 0
Sub msg: b'rpp01 send 37' on test_mqtt/rpp01 with 0
Sub msg: b'rpp04 send 158' on test_mqtt/rpp04 with 0
Sub msg: b'kabaMini2 count 758' on test_mqtt/pub_kabamini2 with 0
Sub msg: b'rpp02 send 65' on test_mqtt/rpp02 with 0
Sub msg: b'rpp04 send 159' on test_mqtt/rpp04 with 0
Sub msg: b'rpp03 send 82' on test_mqtt/rpp03 with 0
Sub msg: b'rpp05 send 52' on test_mqtt/rpp05 with 0
Sub msg: b'rpp01 send 38' on test_mqtt/rpp01 with 0
Sub msg: b'kabanucm3 count 691' on test_mqtt/pub_kabanucm3 with 0
Sub msg: b'rpp04 send 160' on test_mqtt/rpp04 with 0
Sub msg: b'rpp03 send 83' on test_mqtt/rpp03 with 0
Sub msg: b'rpp01 send 39' on test_mqtt/rpp01 with 0
Sub msg: b'rpp04 send 161' on test_mqtt/rpp04 with 0
Sub msg: b'kabaMini2 count 759' on test_mqtt/pub_kabamini2 with 0
Sub msg: b'rpp02 send 66' on test_mqtt/rpp02 with 0
Sub msg: b'rpp04 send 162' on test_mqtt/rpp04 with 0
Sub msg: b'rpp03 send 84' on test_mqtt/rpp03 with 0
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Pub7台の送信間隔を少しずらせてあります。

■ここまででわかったポイント

１：ConnectIDはPub機器ごとに変える。

２：MQTTサーバーとSub処理は機器自体を分ける。

３：トピックを「/」で構造化し、Subでワイルドカード（+）を使う。
４：2.4GHz帯Wifiでも低ノイズ環境ならば問題ない

上記１は必須。
２，３はいかようでもできるが、自分ルールにしてしまえば間違いが減る。

■おまけでわかったこと
Windowsに新規にThonnyをインストールし、設定済のPICO-Wを繋いでも
USBのコネクションができない。
→PICO-Wを一旦USBメモリモードで接続し、UF2ファイルを上書きすると
　ThonnyとPicoとのコネクションが成立する。
　それがThonnyに記録されるようで、以後はコネクションで問題は生じない。

■PICO-W配線外観

rpp01は拡張ボード上にてUSB給電

rpp02~05はブレッドボード上に電源装着して給電

この電源、充電式で事前にUSB-Cで充電しました。
５VをV-SYS（39番ピン）に、グランドを38番ピンに接続。

電源出力を５Vに設定、ボードに装着、電源基板上の電源SWをオン。
うっかりPICOに直接USB給電をしないように（40番ピンV-BUSと衝突危険）

PICOに直接USB端子を挿すときはとにかく赤黒線両方はずす。
電源出力は3.3Vと5.0Vの切り替え可能。
この電源基板、注意点さえ守ればけっこう便利です！

以上、とりあえず複数Pubの一括Subができました。
ルールどおりにすれば簡単にできることもわかりました。

■以後の進めかた

Pub側の基本的なプロセスは、
　イベント検出→送信データ生成→送信処理（→後処理、繰り返し処理）

ですが、今回のねらいの現場で実際にイベントが発生する間隔は３０秒程度。

送信の前後処理は余裕で実行可能と推察さることから、
Pub側の技術的な見込みは概ねたちました。
Sub側のプロセスは、
　受信処理→DBMS記録

の繰り返しですが、今回の結果からは、
複数のPubデータが短間隔で到来しても受信処理はなんとかなるんじゃないか？
と推察されます。そうなるとSub側の処理繰返しの課題はDBMS処理に絞られます。
次はこれに注力してみます。

【その３】へつづく

ラズパイPICO-W＆Micropython＆MQTT化【その２】