Closed GoogleCodeExporter closed 9 years ago
fixed with
http://code.google.com/p/openhab/source/detail?r=957412a8ac2195a3c6631844d621168
7cf398ba9
Original comment by teichsta
on 12 Jul 2013 at 1:58
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
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
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
@Victor could you implement the same behaviour in HABDroid?
Original comment by teichsta
on 12 Jul 2013 at 7:07
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
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
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
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
What is your proposal of the algorithm of this magic? :-)
Original comment by belovic...@gmail.com
on 14 Jul 2013 at 9:15
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
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
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
"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
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
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
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
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
Original comment by kai.openhab
on 12 Oct 2013 at 6:24
Original issue reported on code.google.com by
honkton...@gmail.com
on 2 Jul 2013 at 3:46