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:
They (BasicUI vs. app, previous app behaviour vs. new one) behave differently because there’s no definition for the expected behavior, so every client does it as he seems fit.
(@Kai Can you or somebody else from the core team shed some light on this? My take on this is that float and integer are both numbers, so both variants should be equally OK when sent to the backend.)
For discussion on the app behavior change, see https://github.com/openhab/openhab-android/pull/1390 … the old implementation simply had broken cases as well.
2 Likes
BTW, an easy workaround is adding a state format to the item, as mentioned above: Number SunDetectLux "Sun light intensity [%d]" (gRestore)
Thx, I already have that:
Setpoint item=SunDetectLux label="Sonne West [%d]" minValue=10000 maxValue=70000 step=1000 icon="sun"
Or does it make a difference if the state format is applied to the sitemap?
I think it might, actually. It does for e.g. default units for UoM Items.
Would you find out for us? (applying it to the Item definition)
That part is working fine. If you show us the parts of your rules that don’t work, we can help you fix them.
The use of
(SunDetectLux.state as Number).intValue
is a good example. If you must have an integer for whatever reason, then this will enforce that, it doesn’t matter if you start off with one or not.
Yes, “correct” behaviour is not all clear. Setpoint and slider widgets perform broadly similar functions, and working with floats is definitely an expectation of Setpoint.
I can’t see any reason why we shouldn’t use a slider widget to e,g set a temperature with a min of 12.5 a max of 25.0 and a 0.5 step.
This general business of a Number type being magically different for “7” and “7.0” with no clear way to make it one or the other crops up again and again.
1 Like
I don’t think so. If you have that in the sitemap widget definition, updates should be sent as integer. I’ll try to replicate tomorrow.
Yeah, and this worries me a bit. As mentioned above, IMHO nothing in the stack (be it core, bindings or UIs) should make any difference between the two. In my book, we should fix anything that does that differentiation (like the rule above) instead of talking about the subtle client differences.
1 Like
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 
1 Like
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.
1 Like
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.
1 Like
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