IoT+WEBのためのホームサーバ計画、IoTコントローラ部分です。

IoTコントローラの電源がONしたところから始まります。
ここでは、RaspberryPiが起動したところからになりますね。

コントローラはまず、自分の存在をHomeServerに知らせるところから始まります。
でも、もちろんHomeServerの存在もIPもわかってないのです。
そこで、UDPでブロードキャストして、自分のその存在を示しに行きますよ。
それが、UDPブロードキャスト送信の部分ですね。

よくみると、LOOPしてますね。
これは、まぁDHCPのLAN前提なので、いつ、IPが変わるかもしれないので、
とりあえず、時間を置いて延々と送信し続けます。
まぁ、何分なのか何時間なのか何日なのか、、まぁあとで決めましょ。

もちろん、延々とLOOPするわけなので、別Threadか別Processか、どっちでもよいですね。
これもあとで決めましょ。

まぁUDPなので、投げっぱなしなわけです。
あとは、HomeServerからCALLされるのを待ちますよ。
CALLされるっていうか、なんらかを受信するわけですね。
それが、TCP_Server部分です。

ここはここで、延々と受信し続けて、何かを受信するごとに、別ProcessかThreadで何かを実行させますよ。
もちろん、実行させるのに時間もかかるものもあるし、そもそも非同期が前提なので。
例えば、５秒ごとに部屋の写真を送り続けるのであれば、
５秒ごとに何かを返信しなきゃいけないけど、
１つのリクエストの受信に対して、複数の返信は不可能ですからね。
汎用性を考えれば、非同期は非同期で、別の方法で返信するように考えます。

『ひとつの機能を実行するのはひとつの単位であるべき』

というのを、小学生の時に、無線の雑誌でクリスタルコンバーターの例で、
ダブルスーパー、トリプルスーパーにしたほうが効率が良いってことを学びましたよ。(o^^o)

そして、TCP_Serverで何かを受信したら、そのあとは別Thread/Processにします。
このIoTコントローラが何ができて、どんなパラメータで、、、
みたいな情報取得の場合には、ここですぐに戻します。
この場合だけは、同期にします。まぁ非同期でもいいんですけどね。

そして、最終的には何かを実行し、その結果をsendします。

基本的に、メッセージのやりとりは、全てjson、バイナリは全てBase64で考えときましょう。

もちろん、ネットワークものは、エラーや例外が発生しやすいので、
そこんとこは注意が必要ですね。

とにかく動き続ける限り、途中で停電することもあるし、
人が間違ってケーブル引っこ抜いちゃうこともあるし、
人的であろうとそうでなかろうと、

知らないうちにシステムがとまっていた！

とかは、あってはいけないですからねー。

実行が終わったら、そのThread/Processは勝手に終了します。
そうですねー。タイムアウトとか、必要ですねー。
そうすると、Pythonだし、美しく実装するにはProcessにするしかないのかな。

まぁバグってて、③の部分で送信が行われなくても、送信元がコントローラ側なので、
タイムアウトを検出した部分が、代わりにエラーを送信すれば、それで済みますね。