I just remembered the other silliness with float/integer - some persistence will restore-on-startup to float. So that could easily restore a float dimmer value etc.
This PR suggests the KNX binding issue float/int should have been fixed in 2.4 - I think?
Either it didn’t work or this particular combination was missed.
I do not have KNX to test or raise new issue.
That seems to do it:
item:
Number SunDetectLux "Testing state format [%d]" (gRestore)
sitemap:
Setpoint item=SunDetectLux minValue=10000 maxValue=70000 step=1000 icon="sun"
BasicUI:
2019-08-30 07:34:09.955 [vent.ItemStateChangedEvent] - SunDetectLux changed from 18000 to 17000 → OK
Android App version 2.8.0:
2019-08-30 07:34:52.165 [vent.ItemStateChangedEvent] - SunDetectLux changed from 17000 to 18000.0 → wrong
Android App version 2.8.7 Beta:
2019-08-30 07:35:42.175 [vent.ItemStateChangedEvent] - SunDetectLux changed from 18000.0 to 17000 → OK
So I need to use the Beta app 
Seems to be solved with the Beta version of the app and applying the state format to the item instead of the sitemap:
I see I shouldn’t make statements without looking at the code first 
(I was on mobile yesterday)
I completely forgot about beta being needed, even though I submitted that fix myself:https://github.com/openhab/openhab-android/pull/1469
As for format in widget vs. item … after re-checking the code I see that the client doesn’t get to see the format specified for the sitemap widget (it’s only used for formatting the value which is part of the label that’s sent to the client). For items, the format is part of the item’s stateDescription field, hence is the only indicator of the format desired by the user that we have … hence we’re using that one when populating setpoint widgets or for sending item updates/commands.
Still, I think you should fix your rules instead of relying on integer vs. float though, especially given the fix is relatively simple.
Thx, I already did.
Reminder; it’s not just rules but can be bindings like KNX, which may or may not be fixed.
Not sure I get the full context (the thread is already a bit lengthy), but yes: Number and Dimmer items both must accept integers and float values and they should not make any difference between them.
If I look at the original issue report at the top, it seems to me as if there’s a bug in the KNX binding as it should convert floats to integers, if the KNX DPT expects an integer.
Hey everyone,
The Android app is already a few version numbers further but I’m still having the same issue. I can’t upgrade the app passed 2.7.0 or my sliders don’t work anymore.
Anyone still having the same issue today?
Thanks
Hi, issue is still there for me, too. Dimming does not work. I can just enable/disable lights (OFF/ON) by tapping the item. Version: 2.10.3 – 31.10.2019 10:48:51 on Android (Play Store).
Please show us your events.log for your use of slider. What binding do the commands get passed to?
Please try the latest beta. There was a bug fix for sliders recently.
You need to add switchSupport for that to work: https://www.openhab.org/docs/configuration/sitemaps.html#element-type-slider
With the latest beta (2.10.14 from 23.11.2019) the slider items work fine! Seems that the initially bug is fixed.
Hi, I still have this issue (Android openHAB app 2.11.0 - 25.12.2019 12:26:37 and openHAB runtime Version 1.8.3 – yes, still this old one).
I wonder whether the fix made it into the official 2.11 and why this is still broken there. To be clear: It worked with an older app version fine and sending ON/OFF still works for dimmers (short tapping). I just cannot set a percent value (by sliding) in app. In Web UI (of 1.8.3) all dimmer elements work as designed.
I think the REST API the app uses to be aware of updates has changed a bit since then. That might mean that an up to date UI isn’t ever going to work so well with older OH.
Why, what happens? Can you see the commands arriving in your events.log?
events.log shows: “received command 30.0” (when sliding to 30%)
This results in openhab.log: Value ‘30.0’ could not be sent to the KNX bus using datapoint ‘command DP 1/2/3 TestDimmer, DPT main 0 id 5.001, low priority’ - giving up after second try: wrong value format 30.0
The dimmer item is defined with this name: “My test dimmer [%d %%]”. It is included in the sitemap using groups (so there is no single sitemap entry for this dimmer).
I know this probably is fixed in the 2.x KNX binding, but currently cannot upgrade quickly. I hoped the fix (see above in this thread) was applied and solved this.
At heart, it’s a binding bug, revealed by UI changes.
I think you’ll have to regress to older UI version.
@stb IIRC the item formatting spec (here: %%%d) is not part of the item response in OH1. Can you post the output of visiting http://<serverip>:8080/rest/items/<itemname> in a browser? It should be a bunch of XML data.
Yes, there is not formatting spec in the XML. Ok, that obviously means I shouldn’t stay with 1.x much longer… Thanks everyone for help.
Hey guys,
I’m also still having the same issue as stb.
I also have the beta version of the android app installed but it’s the same problem for months now.
Do I understand correctly that the only fix is to migrate to OH2?
Thanks
Stijn