-
Notifications
You must be signed in to change notification settings - Fork 779
BasicUI: display rollerblind state if required, fixes #976 #990
BasicUI: display rollerblind state if required, fixes #976 #990
Conversation
…d#976 Signed-off-by: Vlad Ivanov <vlad-mbx@ya.ru>
if (!_t.hasValue) { | ||
return; | ||
} | ||
if (value === "DOWN") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this already be handled by the RollershutterItem in the setState function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, for some reason there are SSE events which contain DOWN
and UP
as a new state. This happens if I press up
or down
button twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
which contain DOWN and UP as a new state
@kaikreuzer I would assume this is a bug in the core framework then. Correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the RollershutterItem defines UP/DOWN as accepted values for its state: https://github.com/eclipse/smarthome/blob/master/bundles/core/org.eclipse.smarthome.core/src/main/java/org/eclipse/smarthome/core/library/items/RollershutterItem.java#L42
This has been like this since the very beginning.
We can discuss whether this should be considered to be a bug and we should only allow UNDEF or a PercentType instead - it would make things indeed easier for consumers such as the Basic UI. The problem is that such a change would break the auto update feature, because this is the one which currently sends the UP update when an UP command is sent for the item.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My intention was not to remove the accepted state type.
The problem is that such a change would break the auto update feature, because this is the one which currently sends the UP update when an UP command is sent for the item.
I missed the auto update feature. Could you point me to the implementation?
Such a feature is used for demonstration only, or is there any other use case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I would assume this one: org.eclipse.smarthome.core.autoupdate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or is there any other use case?
Yes, it is always active and pro-actively assumes a state change when a command is seen on the event bus.
Bindings should be able to deactivate this (this was possible in OH1, but is an open issue for ESH, see #595)
BasicUI: display rollerblind state if required, fixes #976
…lind-value BasicUI: display rollerblind state if required, fixes eclipse-archived#976
Signed-off-by: Vlad Ivanov vlad-mbx@ya.ru