Thanks a lot Danny!!
Can you please give this APK a try? https://www.dropbox.com/s/350kvnawm7vl1yk/mobile-foss-beta-debug.apk?dl=0
It’s a build off the branch belonging to the pull request mentioned above. If any of you could confirm that
- the ‘slider sends float values instead of integer’ issue is fixed and
- there are no regressions when modifying UoM number items (UoM -> type is e.g. ‘Number:Temperature’ instead of ‘Number’)
that would be great. Thanks!
1 Like
@maniac103: I tested the beta version succesfully and the sliders work now fine again! So this is the right fix, thanks!
1 Like
I have a similar problem with integer and decimal values.
Changing a Number itemtype from BasicUI:
2019-08-29 08:12:35.477 [ome.event.ItemCommandEvent] - Item 'SunDetectLux' received command 16000
2019-08-29 08:12:35.483 [vent.ItemStateChangedEvent] - SunDetectLux changed from 17000 to 16000
gives me an integer, changing the same Number itemtype from Android app after 2.8:
2019-08-29 08:11:52.014 [ome.event.ItemCommandEvent] - Item 'SunDetectLux' received command 16000.0
2019-08-29 08:11:52.022 [vent.ItemStateChangedEvent] - SunDetectLux changed from 15000.0 to 16000.0
gives a decimal.
item:
Number SunDetectLux (gRestore)
rule:
if (Lux_five_avg > Integer::parseInt(SunDetectLux.state.toString())) {
sitemap:
Setpoint item=SunDetectLux label="Sonne West [%d]" minValue=10000 maxValue=70000 step=1000 icon="sun"
openhab.log:
2019-08-29 08:12:03.631 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'sun lux west detection': For input string: "16000.0"
I tried with app version 2.8 and 2.8.7 beta. Problem persists.
Just don’t use parseInt 
Correct way is using .intValue on the state itself, since a Number isn’t (necessarily) an integer. See [SOLVED] Parse Number to Integer
There are complications with Dimmer and Rollershutter types though; I don’t know if these are required to be integers but a lot of bindings assume they are.
That’s fine, will test this.
Still there is a difference between setting the value through BasicUI and Android App, though.
Edit: and it used to work with Android App version 2.7 
For those, I assume the bindings provide [%d%%] as default format, which makes the app send integers. Basically, the app always uses the specified format and defaults to floats otherwise. We want a bit back and forth there; I’m not sure whether there’s a better approach. Is there a specification on how the app (or any client really) should behave in that regard? I’m not aware of any at least.
Did not work unfortunately:
if (Lux_five_avg > Integer::parseInt(SunDetectLux.state as Number).intValue) {
2019-08-29 17:40:06.033 [vent.ItemStateChangedEvent] - SunDetectLux changed from 18000 to 17000.0
It’s still a decimal.
This does not work either:
if (Lux_five_avg > (SunDetectLux.state as Number).intValue) {
2019-08-29 17:46:01.293 [vent.ItemStateChangedEvent] - SunDetectLux changed from 18000 to 17000.0
That’s fine … the difference is that your rule can deal with that.
?
My rule does not work with that …
With the first change I get:
2019-08-29 17:44:59.147 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'sun lux west detection': An error occurred during the script execution: Could not invoke method: java.lang.Integer.parseInt(java.lang.String) on instance: null
With the second change I get:
2019-08-29 17:46:49.168 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'sun lux west detection': For input string: "17000.0"
I think you want
Float::parseFloat( someString ).intValue
because “17000.0” is not an integer.
But tell us more about -
Surely all you want here is
if (Lux_five_avg > (SunDetectLux.state as Number).intValue )
Thanks, already tried that:
The debug message doesn’t tell us anything about why the if statement supposedly doesn’t work. I suggest storing the right part of the comparison to a variable before doing the if and printing the value there. I even think that comparing like if (Lux_five_avg > SunDetectLux.state) could/should work.
With that I still get a decimal from the Android App and an integer from BasicUI:
if (Lux_five_avg > Float::parseFloat(SunDetectLux).intValue) {
App:
2019-08-29 19:01:47.589 [vent.ItemStateChangedEvent] - SunDetectLux changed from 18000 to 17000.0
BasicUI:
2019-08-29 19:01:06.712 [vent.ItemStateChangedEvent] - SunDetectLux changed from 17000 to 18000
My item is a number:
Number SunDetectLux (gRestore)
Thx, will try tomorrow.
What still bothers me: why do BasicUI and Android App behave different when changing the same item?
Why did this work without any problems before the Android App update?
Well, yes, of course. Doing things like intValue in a rule is definitely not supposed to change the value of your Item’s state.
If you want to change the state, this is what postUpdate is for.
I agree, this is a change in behaviour. I’m sure you would not be the only one expecting an integer return from a slider if you happen to start out with an integer.
But I don’t think that is a written guarantee anywhere? Not sure.
1 Like
The only thing I want to achieve is reading that number value to use it in my rules.
Since a couple of month in this software nothing is guaranteed anymore … unfortunately.
I will ditch the App and use BasicUI instead.
Edit: and I am tired of this: