Strange decimal setpoint behavior in the Android APP

I have noticed some strange behavior of the setpoint in the android app
My recuperator has 7 gears for the ventilator, and I have a setpoint defined for that and put it into the sitemap.

Number B_Provent_gear_selected			"Ventilation Gear [%d]"   <fan> (gVentilation) { mqtt="<[olmo:provent/gear_selected:state:default]" }
Setpoint item=B_Provent_gear_selected minValue=1 maxValue=7 step=1

It works great from the BasicUI but when used from the android APP the setpoint sent to the script contains a decimal point. notice in the debug it is sending 6.0 instead of 6.

2017-05-30 11:26:07.573 [DEBUG] [eclipse.smarthome.model.script.TERMO] - --------- Send ventilation gear command kicked in set to:5
2017-05-30 11:26:07.580 [INFO ] [lipse.smarthome.io.net.exec.ExecUtil] - executed commandLine '/home/pi/curl_provent_put_gear.sh 5'
2017-05-30 11:26:37.233 [DEBUG] [eclipse.smarthome.model.script.TERMO] - --------- Send ventilation gear command kicked in set to:6.0
2017-05-30 11:26:37.255 [INFO ] [lipse.smarthome.io.net.exec.ExecUtil] - executed commandLine '/home/pi/curl_provent_put_gear.sh 6.0'
2017-05-30 11:26:47.643 [DEBUG] [eclipse.smarthome.model.script.TERMO] - --------- Send ventilation gear command kicked in set to:7
2017-05-30 11:26:47.653 [INFO ] [lipse.smarthome.io.net.exec.ExecUtil] - executed commandLine '/home/pi/curl_provent_put_gear.sh 7'

An I doing something wrong or that is a bug? I know I could sort it out in a script but that a patch to a problem that should not exist IMHO

More a “feature” than a bug, I think. There is nothing to say a setpoint value must be integer.

I would assume if I define it in the *.items as integer and not as a float, that would be respected in the setpoint widget in the APP. The Basic UI does that right.

That’s a neat trick. How is that done?

isn’t [%d] in the item definition for integer?

The [%xx] stuff is only about formatting for display. It doesn’t affect the underlying Item, which in the case of a ‘Number’ is a decimal number. So the Item doesn’t mind if you send it a 6 or 6.0 or 6.00000, the effect is the same.

I suppose you could ask for an enhancement to have the android app interrogate the [%xx] (I’m not sure if there is actually a way to do that over the REST API?) and then format the number it sends back to OpenHAB. I don’t know what benefit that would give, since it makes no difference to the receiving Item.

If your rule/script doesn’t like decimal Numbers, that is something to deal with in the rule/script. You cannot change the nature of an Number Item.