私たちのアプリケーションの1つはセンサーによって送信されたデータを受信します。メッセージの内容を調べることによって、アプリケーションは、どのタイプのメッセージを見ているのか、センサーが動作しているファームウェアのバージョンを把握しなければなりません。新しいバージョンのファームウェアは余分なデータを送信するため、別の方法で処理する必要があります。構造化されていないメッセージからデータを抽出するためのパターン
以下の例では、異なるバージョンのデータメッセージと、異なる構造を使用する構成メッセージを示しています。
一部のデータはコンマ区切りで、一部は新しい行で区切られています。メッセージには、メッセージタイプを決定するのに役立つマーカーもあります。
私たちはメッセージの構造を変更することができず、メッセージにファームウェアのバージョンが示されていないことを前提に、データを解釈する明確かつ維持可能で拡張可能な方法の提案と例を探しています。私たちができる最善のことは、私たちの目的のためにできるだけ優雅に物事を処理することです。
通常のメッセージの旧バージョン
[MSG]
4 031116 080423
543215432154321
3711mV
30
1,0,0
[READINGS]
00451,00450,00402,06017
00000,021116 083000
00000
00000
00000
00000,031116 080000
[MSGEND]
通常のメッセージの新しいバージョン
[MSG]
4 031116 080423
543215432154321
3711mV
30
1,0,0
**0000006216** <- Extra data added on extra line
[READINGS]
00451,00450,00402,06017
00000,021116 083000
00000
00000
00000
00000,031116 080000
[MSGEND]
構成レポート
[MSG]
2 050416 194503
3913mV
30
1,1,0
0000006216
[CONFIG]
543215432154321
234,15,0037,01DE,-60,234,15,0037,42B0,-76
[MSGEND]
メッセージはどのように識別されますか?合計引数の数?行ごとの引数?議論の順序? []マーカー?マーカごとの議論?メッセージタイプを決定する条件を明確にしたら、これらをチェックして、データからより有用なメッセージオブジェクトを作成することができます。 – EpicSam
メッセージのタイプ(読み取り/設定)は、[CONFIG]フラグで判断できます。 ファームウェアのバージョンがより困難です。これは、新しいバージョンのファームウェアで予想される余分なデータを探すことに依存します。 –
次に、フラグを最初にチェックして、メッセージタイプを判別します。その後、[MSG]と[MESSAGETYPE]の間の引数の数を数えて、ファームウェアのバージョンを決定しますか? – EpicSam