UDPでfloat型の値を送りたい．

Question

Arduino IDEを用いてESP32からRaspberry Piにfloat型のデータ送信したいのですが，うまく受け取ることが出来ません．
(Raspi側の受信にはNODE-REDを用いています．)
試しに

const int sensor_pin = 5;
int input_value = 0;
float convert_V = 0.00;
float i = 2.5;
int input_value_send = 0;

input_value = analogRead(sensor_pin);
convert_V = (input_value * 5 ) / 1024;

UDP.write(1);
UDP.write(100);
UDP.write(255);
UDP.write(256);
UDP.write(2.5);
UDP.write(i);
UDP.write(convert_V);
UDP.write(input_value);

input_value_send = input_value / 4;

UDP.write(input_value_send);

と送ってみたところ受信側結果は

1
100
255
0
2
2
0
0

186

だったので1byte以上の値を送ることが出来ないのかなという状況です．

UDP.writeを使ってfloat型の数値の送り方を教えていただきたいです．

追記::もしくは受信側に問題があるのでしょうか．
追記2::float型でデータを送信できたわけではないので自己解決方法で記入はしませんが，ひとまず，生データ2bitシフトしたデータ(4で割り算したデータ)を送信し，受信側で再度2bitシフトする(4で掛け算)という形をとりました．

Answer 1

お使いの言語は知りませんが、引数の値を持つ1バイトデータを送る機能のようなので、複数バイトのデータを送る場合は、バイトに分解して、1バイトずつ送る必要があります。
受信側では、受け取った複数のバイトから元データを組み立てる必要があります。

また、バイトオーダー（上位バイトを先に送るか、下位バイトから順に送るか）を送受信側で合わせておく必要があります。普通は、上位バイトから順に送ります。

Answer 2

UDP.writeには、

Syntax

UDP.write(message);
UDP.write(buffer, size);
message: the outgoing message (char)
buffer: an array to send as a series of bytes (byte or char)
size: the length of the buffer

という２つの書式があります
提示のコードでは、１バイトの送信となりますんで、そりゃバイトの範囲内でしか送信できません
ということでどうするかというと、そのFloatの数値を文字配列に文字列として展開し、それを送信することになります

char bff[32];
sprintf(bff,"%f\n",floatvalue);
UDP.write(bff,strlen(bff));

そして受信側では、改行で区切られた文字列を読み込み、floatに変換すればよろしい

Answer 3

はずしていたら、ごめんなさい。

　通常は float を含む、実数の表現は、CPU のアーキテクチャ等に依存するので、通信には向きません。

一般的に、実数を通信に使用する場合は、送る側で、テキスト形式等にエンコードし、受信する側でデコードします。

蛇足）
正数であっても、２バイト以上になれば、エンディアンの影響を受けるので、これも通信には、ネットワークバイトオーダの変換を行うことになります。

Comments

[WK_ZAKK]

回答ありがとうございます．勉強になります．
テキスト形式というのはstring型に変換して送信し，受信側でint型に再変換するということでしょうか？
ArduinoでのUDP.writeではstr型で送信できなかったため，別の方法を試してみたいと思います．
String thisString = String(13, HEX);
UDP.write( thisString);

error　:no matching function for call to 'WiFiUDP::write(String&)'
といった形でした。

[ikadzuchi]

そうは思いません。
現代の浮動小数点数はCPUのアーキテクチャ等によらずほぼ例外なくIEEE754形式に統一されており通信に向きます。(エンディアンの違いは問題になりうるが、実数に限ったことではない)
テキスト形式はエンコード・デコードに手間が掛かる点、正しい値が復元できるエンコード・デコードは処理が複雑でバグが入りやすい点、データ量が多い点から、通信に向かないと思います。

[showkit]

ikadzuchi さんが、おいくつの方かは、存じませんが。「ほぼ例外なく」の、「ほぼ」の時点で例外はあるのですよね？
そういう例外で痛い目に合ったことがないのかと思います。痛い目にあった経験では、確実なものを求めます。生の値に頼るのは危険であるという認識です。
「テキスト形式は...データ量が多い点から、通信に向かない」に関しては、おっしゃる点、じゅうぶんわかります。
実際、サンプリングレート最大 8000Hz のデータにそれより低いサンプリングレートのデータで、8、16、32ビット が混合しているデータを、周期的に通信するものでは、「テキスト形式」以外に別途、表現形式を定義して通信していました。

[ikadzuchi]

まあ悪魔の証明ですからねえ。
私の知っているのはPICマイコンのライブラリで内部的に使われているもの(ビット配置が違うだけ; IEEEとの変換は用意されている)と、最近流行りのbfloat16(IEEEの前半のみとったもの)くらいですが、中にはIEEEと根本的に違う例えばIBMの古い16進のものなどを使っている環境も今もあるかもしれません。
そのような環境で、IEEEとの変換も用意されていない場合も、無いとは言い切れません。
一方、そのようなごく稀な環境を気にして欠点の多い方式を使うべきか(特に初心者に教えるべきか)という点について、私はそう思いません。
(コードの簡単さを理由にテキスト形式を勧めるのなら有りだと思います)

[showkit]

おっしゃること、ごもっとも、ご意見は、納得できます。