[SOLVED] Slider items with new Android App 2.8.0 not working anymore

Who knows? Has anyone reported the KNX binding issue?

That’s probably not a good approach to getting volunteer coders to work on their free product.

Will this be fixed in the future?

Yes: https://github.com/openhab/openhab-android/pull/1469

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 released https://github.com/openhab/openhab-android/releases/tag/2.8.6-beta with the fix.

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 :wink:
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 :innocent:

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?