Should we drop float and integer in favour of number in homie5

[Tieske]

Since I've started implementing Homie5 devices, I find my self doing this:

"type": "float",
"format": "0:10:1",

instead of:

"type": "integer",
"format": "0:10",

Internally it is still an integer, it is just more permissive to the user. By using the float with step 1, it automatically rounds, drops extraneous zeros, etc.
If I were using integers all I can do is drop the value, and report an error.

[schaze]

I have somewhat strong feelings about this topics.
A float is an inherently different concept of a number in the way it is represented as a type and also how it is handled.

e.g. there is also Perfect vs Imperfect Representation

• 1.0 + 1.0 == 2.0 is true because all values involved are exactly representable.
• 0.1 + 0.2 == 0.3 may not be true due to representation and rounding issues, as 0.1, 0.2, and 0.3 are not exactly representable in binary floating-point.

This can lead to issues or unpredictable behavior in various scenarios when mixing integer and float and just specifying something as a "number". If I pass a 1.0 to the property it is not the same as if I pass a 1.

With regards to the spec:
If a field is of type integer it should not accept non integer values.
I would also argue if it makes sense to define a float with 0:10:1 format. If you want integers use integers.

In my opinion we took a questionable turn with the spec for the numbers when we defined that the device should perform not only input validation based on the format but actually "round/correct" wrong input. IMHO a float property that defines a 0:10:1 format should discard all input that is not 0,1,2,3,4,5,6,7,8,9,10. As it clearly defines what a valid input is. The burden of providing proper values as input is on the sender side, that is what the format description is for.

--> It is not the job of a devices to correct the input coming in.

We do not do this for any other property value, e.g. we do not convert a rgb color value passed to a device to xy when the device only accepts xy.

Why do we round a 1.4 to a 1 in a float that only accepts numbers 0 to 10 on 1 steps intervals? A 1.4 is simply an invalid value and should be discarded.

[Tieske]

A float is an inherently different concept of a number in the way it is represented as a type and also how it is handled.

Technically that is the case, but not to a user.

Perfect vs Imperfect Representation

by having a step size, arithmetic is forced when validating, this will lead to false negatives (due to imperfect representation). Hence rounding is required to prevent that.

Then there's already JSON being used, which also only has 'number'.

rethinking on why I do the float + "::1" thing; it's mostly improved interoperability. Say you have a temperature sensor that returns a temperature in tens of a degree (20.1, 20.2, 20.3, etc, so format "::0.1"). And a thermostat that accepts a temperature measurement in degrees (20, 21, 22, etc, so an integer). I can now pass values directly from one to the other. If it were to drop invalid values, then I'd be forced to have intermediate arithmetic somewhere.

so in essence; be forgiving in what you accept, and strict in what you provide.

That said, I guess leaving both in, as we currently have will satisfy all users.

[schaze]

by having a step size, arithmetic is forced when validating, this will lead to false negatives (due to imperfect representation). Hence rounding is required to prevent that.

That is a good point. However I am not sure if the rounding will be able to prevent all potential issues of false negatives...

rethinking on why I do the float + "::1" thing; it's mostly improved interoperability. Say you have a temperature sensor that returns a temperature in tens of a degree (20.1, 20.2, 20.3, etc, so format "::0.1"). And a thermostat that accepts a temperature measurement in degrees (20, 21, 22, etc, so an integer). I can now pass values directly from one to the other. If it were to drop invalid values, then I'd be forced to have intermediate arithmetic somewhere.

I get the idea in general. Question for these is where do we stop? We could also argue that we should always accept all kinds of color formats for a color property and simply convert to the supported format. You could e.g. have a color choosing component only emitting rgb color values you want to connect it to a light that only accepts xy. Or 0 and 1, "on" and "off", "open" and "close" as true and false equivalents for boolean properties (a bit more far fetched than the numbers but still the same idea).
Also when you have a component that will connect two devices usually it should validate and take care of proper conversion between them.