前記事↓
↑これのつづきです。
■環境
ラズパイ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の使いかたのように思えますし・・・
これは安直にトライするよりも別の要因を確認してからにします。
→調べてみますと・・・
出典：
そもそも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処理に絞られます。
次はこれに注力してみます。
【その３】へつづく