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