Uninitialized number item won't change from classic UI

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Have a uninitialized number item, setpoint widget in sitemap
2. Change from classic UI: Error and change not possible
3. CHange from HABdroid: value is generated starting with minValue 

What is the expected output? What do you see instead?
HABdroids behaviour is the expected way because otherwise there's no convinent 
way to set a new value

What version of the product are you using? On what operating system?
Build #435, HABdroid #78

Please provide any additional information below.

Original issue reported on code.google.com by honkton...@gmail.com on 2 Jul 2013 at 3:46

[GoogleCodeExporter]

fixed with 
http://code.google.com/p/openhab/source/detail?r=957412a8ac2195a3c6631844d621168
7cf398ba9

Original comment by teichsta on 12 Jul 2013 at 1:58

• Changed state: Fixed
• Added labels: Version-1.3.0

[GoogleCodeExporter]

The fix does not seem to provide identical behaviour as HABDroid: It sets the 
value either to minValue or maxValue depending which button was pressed. 
HABDroid, if I understand the issue right, always sets the value to minValue.
So what should the behaviour ideally be? I would actually suggest trying to 
avoid extremes (who knows, what temperature might be controlled by the 
widget...). So (min+max)/2 might actually be the best option.

Original comment by kai.openhab on 12 Jul 2013 at 4:11

[GoogleCodeExporter]

After reading the text a third time one could also interpret it your way, right 
;-)

I agree setting the value to the average would be good option. Will refix that 
…

Original comment by teichsta on 12 Jul 2013 at 6:59

[GoogleCodeExporter]

see 
http://code.google.com/p/openhab/source/detail?r=3f1e6101068c6a44c9ad1b8d1fe6c76
e29a376a8 for further fix

Original comment by teichsta on 12 Jul 2013 at 7:06

[GoogleCodeExporter]

@Victor could you implement the same behaviour in HABDroid?

Original comment by teichsta on 12 Jul 2013 at 7:07

• Changed state: Started

[GoogleCodeExporter]

What will happen if only minimum or only maximum is set? 20+0/2 = 10? :-)

Original comment by belovic...@gmail.com on 12 Jul 2013 at 7:27

[GoogleCodeExporter]

hmm ... or none of them. Since both of them are optional fields this would be 
possible as well. Well first of all setting the value if the state is undefined 
is a convenience feature. We could restrict the functionality to only work IF 
min and max are set?

Original comment by teichsta on 13 Jul 2013 at 8:46

[GoogleCodeExporter]

I suggest that we don't do some background calculations, cause it will always 
be some unpredicted magic for the user (I mean nobody will read docs in that 
details to understand we make it min+max/2 :-) What I suggest is introducing 
another field - defaultValue which will be set if setpoint is uninitialized. 
Otherwise I would like to keep it as it is - setting minimum value.

Original comment by belovic...@gmail.com on 14 Jul 2013 at 9:00

[GoogleCodeExporter]

If you don't want unpredicted magic, we should reject the issue altogether - an 
unititialized value simply cannot be increased or decreased by a step...
If you want magic, starting in the "middle" of the given range imhp makes 
sense. And choosing the minValue has the same problem, if the minValue is not 
given, right? So if min or max is not specified, I would actually stick to 
uninitialized.

Original comment by kai.openhab on 14 Jul 2013 at 9:14

[GoogleCodeExporter]

What is your proposal of the algorithm of this magic? :-)

Original comment by belovic...@gmail.com on 14 Jul 2013 at 9:15

[GoogleCodeExporter]

if i rethink that issue we should revert my current fix and remove any magic in 
any client. If the state is Undefined, UP and DOWN should not do anything. I 
(now) think that is the most expected behaviour.

Original comment by teichsta on 14 Jul 2013 at 7:55

[GoogleCodeExporter]

I think this is also incorrect. How the user will initialise a setpoint then???

Original comment by belovic...@gmail.com on 22 Jul 2013 at 6:39

[GoogleCodeExporter]

He will have some hardware device which sets it or if not, he can use a rule to 
set an initial value.

Original comment by kai.openhab on 22 Jul 2013 at 7:37

[GoogleCodeExporter]

"Honey! Can you PLEASE finally write initialisation rule for this living room 
thermostat???"
No, it can be a virtual device implemented in rules. It can be volume. It can 
be anything. So we need a way to initialise it from UI, I think. Will check how 
it works on GIRA thermostat...

Original comment by belovic...@gmail.com on 22 Jul 2013 at 7:43

[GoogleCodeExporter]

Right, it can be anything. So only the admin/installer knows what is a 
reasonable initial value. So he should write a rule and set it.

Original comment by kai.openhab on 22 Jul 2013 at 7:48

[GoogleCodeExporter]

Right. And they do it through min and max values.
What about my proposal on new setpoint attribute - defaultValue?

Original comment by belovic...@gmail.com on 22 Jul 2013 at 7:50

[GoogleCodeExporter]

Will revert my changes. From my point of view we agreed upon the fact that we 
don't want any magic in the UI: unintialized means "-" that it :-)

Original comment by teichsta on 13 Aug 2013 at 7:55

[GoogleCodeExporter]

reverted to its original version to avoid unexpected/magic behaviour (see 
http://code.google.com/p/openhab/source/detail?r=65b936ff141645c6825b9942864902f
8ffc237da)

Original comment by teichsta on 31 Aug 2013 at 7:29

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by kai.openhab on 12 Oct 2013 at 6:24

• Changed state: Rejected