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

Apps & Services Android App
1

Since the new update of the Android OpenHAB app version 2.8.0 (August 1st, 2019) my slider items for shutter (“Rolladen”) are not working anymore. In previous versions, everything worked fine!!!

Excerpt of my .items file are attached below:

//–> Rolläden[0/x/x] {knx="LZ, KZ, Position+<Position_Rückmeldung}
//================================================================

//–> UG Wohnen [0/2/x]
Rollershutter RUGWohnenWest “UG Wohnen West Rolladen [%d %%]” (gWohnenUG, gRollo) {knx = “0/2/1,0/2/2,0/2/3+<0/2/4”}
Rollershutter JUGWohnenSued “UG Wohnen Jalousie [%d %%]” (gWohnenUG, gRollo) {knx = “0/2/8,0/2/9,0/2/10+<0/2/12”}
Dimmer LUGWohnenSued “UG Wohnen Jalousie Lamellen [%d %%]” (gWohnenUG) {knx = “5.001:0/2/11+<0/2/13”}

Excerpt of my .sitemap:

Text label= “UG” icon= “groundfloor” {
Text label=“Eingang UG” icon=“frontdoor” {
Frame label= “Heizung” {
Text item=TIstUGEingang icon= “temperature”
}
Frame label= “Beleuchtungen” {
Switch item=BelUGEingang
}
}
Text label=“Wohnen UG” icon=“sofa” {
Frame label= “Heizung” {
Text item=TIstUGWohnen icon= “temperature”
Text item=TStellUGWohnen icon= “heating”
Setpoint item=TSollUGWohnen icon=“temperature” step=0.5 minValue=4 maxValue=30
Switch item=TModiUGWohnen mappings=[1=“Komfort”, 2=“Standby”, 3=“Nacht”, 4=“Frostschutz”]
Text item=THVACUGWohnen icon= “heating”
}
Frame label= “Rolladen” {
Slider item=RUGWohnenWest
}
Frame label= “Jalousien” {
Slider item=JUGWohnenSued
Slider item=LUGWohnenSued icon=“rollershutter”
}

1 Like
2

Thanks for the report, I’ll look into it!

3

I copied your item and sitemap definitions (except the KNX stuff, since I don’t have any KNX devices) for RUGWohnenWest. I can drag the slider and it changes it’s value.
Can you describe your issue? Maybe someone with KNX can test this as well.

4

An events.log of what happens when dragging the slider (if anything) might be useful.

5

When I move the slider, nothing happens.
The events.log shows the following:

  1. correct function using basic ui or Apple OpenHAB app:
    2019-08-06 07:11:05.172 [ome.event.ItemCommandEvent] - Item ‘RUGWohnenWest’ received command 47
    2019-08-06 07:11:10.922 [vent.ItemStateChangedEvent] - RUGWohnenWest changed from 0 to 47
    ================================================
  2. not working using Android OpenHAB app:
    ==> /var/log/openhab2/openhab.log <==
    2019-08-06 07:12:34.746 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Value ‘50.0’ could not be sent to the KNX bus using datapoint ‘command DP 0/2/3 RUGWohnenWest, DPT main 0 id 5.001, low priority’ - retrying one time: 5.001 Scaling: wrong value format: 50.0

==> /var/log/openhab2/events.log <==
2019-08-06 07:12:34.745 [ome.event.ItemCommandEvent] - Item ‘RUGWohnenWest’ received command 50.0

==> /var/log/openhab2/openhab.log <==
2019-08-06 07:12:34.752 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Value ‘50.0’ could not be sent to the KNX bus using datapoint ‘command DP 0/2/3 RUGWohnenWest, DPT main 0 id 5.001, low priority’ - giving up after second try: 5.001 Scaling: wrong value format: 50.0

6

Can you post the output of http://openhab:8080/rest/items/RUGWohnenWest and go to http://openhab:8080/rest/sitemaps/ and navigate to the page where Slider item=RUGWohnenWest is?

7

The KNX channel expects an integer (as a percent type, like a dimmer)

The UI slider here used to send integer, now it sends decimal.

As I understand slider behaviour in other UI’s, when start Item value is integer and step value is integer (which it will be for default step=1) an integer gets sent. But that’s more by luck than design, I’d say.

I think the weak link here is really the KNX binding - it should be doing its own conversion from decimal to integer if that’s what it needs?
This is a related KNX issue but going in the opposite direction, KNX DPT 5.001 to OH number/dimmer types

8

The issue is: openHAB uses a JSON API. From wikipedia:

JSON’s basic data types are:

  • Number: a signed decimal number that may contain a fractional part and may use exponential E notation, but cannot include non-numbers such as NaN. The format makes no distinction between integer and floating-point. JavaScript uses a double-precision floating-point format for all its numeric values, but other languages implementing JSON may encode numbers differently.

Before that app sent a “number”, now it sends a “number”. IMO the issue is, that the binding cannot cast from float to int. Let me see, if it’s possible to add a workaround to the app.

@starranger In the meantime, you can download version 2.7.0 from GitHub: Release 2.7.0-release · openhab/openhab-android · GitHub. You need to uninstall 2.8.0 before.

9

@mueller-ma Thanks a lot for your help! I downloaded openhab 2.7.0 release and everything works fine again, slider for rollershutter are working perfect again :blush:
Please inform me when you have a fix for the newest Android openHAB App.
Thanks again!!!

10

@mueller-ma IIRC, state updates are sent as strings, not numbers. The slider value is converted into a string by formatting the numeric value. Problem is in that value formatting, we previously distinguished between integer and float and used the respective toString methods, whereas we now always do Float.toString. We should apply the same logic asin toString also for formatValue, which should fix this issue.

11

So far as I can make out, OH2.4 Slider widgets only deal with integers until now. A step=2.5 doesn’t seem to allowed, for example.
However, there doesn’t seem to be any good reason for that?

There has been update to slider, I think in OH2.5 M1


I cannot test if this now allows decimal steps, limits, etc.

The broadly similar Setpoint widget works quite happily with decimal steps and decimal values, and will of course send decimal values to OH.

What I’m saying is that it seems perfectly legitimate to send decimal commands to a Dimmer or RollerShutter Item.
It’s a binding limitation if it can’t handle that.

12

Hey guys,
I’m facing the same issue.
Will this be fixed in the future? Having to downgrade to 2.7.0 is not really a fix.
I can only imagine a company who did 100 openhab installs and now has 100+ customers calling they can’t change their screens and dimmers anymore.
It’s been very very annoying for me, that’s for sure.
Thanks
Stijn

13

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.

14

Will this be fixed in the future?

Yes: Use format specifier also when updating non-UoM items. by maniac103 · Pull Request #1469 · openhab/openhab-android · GitHub

15

Thanks a lot Danny!!

16

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
17

@maniac103: I tested the beta version succesfully and the sliders work now fine again! So this is the right fix, thanks!

1 Like
18

I released https://github.com/openhab/openhab-android/releases/tag/2.8.6-beta with the fix.

19

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.

20

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