Hello,
I currently work on a custom note implementing the homie convention. The main procedure setting parameters to a remote devices over mqtt is to send a value to the .../parameter/set topic. The device then confirms the new value by sending it to the .../parameter topic. This gives feedback that the value arrived at the device (All media especially wireless can be unreliable).
Here you see the .../dimmer/set value and the confirmation on .../dimmer
So it would be useful that a dashboard node indicates the prediction of the new value a user enters (like pushing a switch or moving a slider) until a new value arrives on the input. This don’t have to be the same as the sent value and the ui node don’t have to do any checks. Only a graphic representation that the displayed value or state is a result of the user input (I call it 'predicted') and not from a message received on the input. This can be color, or font size (i.e. a little bit bigger font or bold type) or a corona around an icon until a message arrives on the input.
This feature should be selectable in the node configuration because state changes inside Node-RED can be assumed to be reliable or devices don’t acknowledge new values.
An example: I use the a slider to set a dimmer on an RGBW bulb. There is a loop between the slider and the homie node which handles the IO to the device. If the user moves the slider the .../dimmer/set value is send via mqtt to the device . When a message on the topic /dimmer (without /set) arrives it clears the predicted flag and send the (new) value to the slider. The ui Nodes do not have to use the predicted flag because they can assume that all values arriving on the input clear the "predicted" state.
Yes, you must be sure to uncheck the "pass values form the input to the output" to avoid endless loops.
What do you think? I'm willing to help doing these modifications if we can agree on the concept.
Looking forward to hear form you and thank you for your great work so far.
Chris
This would only be useable when "pass values.." is unchecked as you realise, and only on a few nodes - the switch node already does something similar in that it can be set to show the in or out value - Not sure how we would maintain that and add this at the same time.
How would this even work in the case of the slider - when the user drags the slider - it moves... we can't have it not move and then move later when the feedback happens - the user would go huh ??? I'm not sure it would be obvious to users why the output changed when they set it, then "jumps" to another value for no apparent reason.
In a lot of cases the feedback would be very short (< 1 sec) so would there be any point ? I guess where I am getting to is that this seems like a fairly minor use-case that wouldn't have much utility for the average user.
Can you not provide this level of feedback via a separate node (eg led like indicator next to the control) ? Or you could possibly use a ui_control msg to possible change the font etc ?
Hi, thank you for your reply.
Slider is the Item why I wrote this post because this node don`t have ui_control over its appearance. I can use a "Button as a switch" which configuration can look like this:
It do the job via ui_controll messages.
But for the slider?
My idea the user drags the slider around and it send data (or after release). Perhaps the little mark gets bigger (or change color) when the user starts dragging until a message arrives on the input. So the bigger Mark helps during dragging on a touch screen device and can relax then the new value is confirmed.
during drag and after release (photoshoped)
after value received
With a switch i simulate it by using ui_control icons ... but the visual effect is not so nice. BTW who you can control the size of the icons?
One idea can be to have only the outlines or a de-saturated color in the predicted state
And here is the result of the configuration above:
It first goes to the predicted color and after confirmation (input) it switches to light green or red to indicate the actual state. (Side question: Why the label of a button is forced to caps?)
quick answer first - the whole dashboard uses the angular-material design library and the material design style is all caps for button text.
Understood ... That's fine 
Even they nowadays leave the decision up to us https://material.angular.io/components/button/overview
Coming from Germany we are used to upper / lower case that writing in all caps reads a little bit loud (if you know what I mean): Would like to label "alternative" options in lower case and "main" option in upper case like cancel / CONFIRM
I`m not familiar with angular library but exposing the color value of the slider
@Input() color: ThemePalette Theme color palette for the component.
via ui_control can perhaps be a workaround, like the button example.
Thank you pointing me to the angular material libraray
digging a little bit deeper I found the md-warn palette ... details here
Perhaps the md-warn could be used to say Warning: This value is NOT confirmed!
The color difference is not very obvious.
the off state shows nearly no difference.
Hi,
It was a wile when I post this question. I still wonder how is the best way to implement this feature:
A) expand the existing ui nodes (PR)
B) or roll out a conrib node (or many) as expanded versions.
For a) speaks that I think it do not break the current node behavior - perhaps there has to be a little config element if the user want the predicted state to be displayed (perhaps the tickbox could be changed to radio buttons (or dropdown) to show if the user whants to show the state of the button: input/output/output as predicted until input arrives) or there could be an extras / advanced features tab to offer more gimmicks.
For B) speaks that I could implement more features like
- Last updated, last seen
- blink/fade background if a new value arrives with settable duration (like in a stock exchange live spreadsheet) to visually identify updates
- other values (perhaps as a hover/tooltip window) for battery indicator, wifi strength, system health ...)
B) will be more difficult for me to maintain, users have to decide if they will use A or B or have two different versions of a similar node ...
Don’t worry I currently have a lot of other projects to do and finish before I actually can start with this.
Chris
Well as usual it all depends... but you are basically correct. If extending the existing node then yes the basic behaviour should not break any existing users - but also it should not add too much complexity to the config options, and indeed most are fairly busy already.
Extra nodes are always welcome - but ideally they should be new types of widgets. So yes a tricky balance - but we are always happy to discuss concrete proposals before you start writing code.
Best would to first prepare a PR to discuss a first proposal. From there we will see where the journey goes.
Well - words may be easier to write and discuss before you write code / PR.
Which nodes are you looking to enhance ? What with ? etc
A) Basically all ui-nodes who are setting values.
B) currently you can choose if the state/value of the input or output is shown. I like to add a third option “both”: which means that if the value/state is set by user input it is displayed differently. To keep it simple I suggest to desaturate colors and dimm the brightness by a certain amount. (If somebody likes individual styling we can use ui_control objects to set these)
The idea is that the user knows that the set value arrives the device physically (ie. wireless) and the set was successful (ie. the temperature is within a suitable range or the pump really started). The state between flipping the switch and the actual action & acknowledgment I call “predicted” and should be graphically visible because of the possible delay. I had the experience in a huge bms system where light switches had quite a big delay (the bus was too busy because it had too many devices connected) so the users pushed the button a second time because they got no response that the first push was recognized and the lights never got switched on because the second push was recognized as a off command. Very annoying. (See above examples too)
When you say all that are setting values... you don't really mean all ? or do you ?
How would it help on a text input box ? or a date picker ? or colour picker ? or slider ? or just about anything apart from the switch node... that already has the in / out state "problem" you mention. Happy to consider just the switch node.
Yeah, I really think about all dashboard nodes with an output.
Examples
- text input: I have LED matrix display for state messages connected to an ESP8266. Nice to have a feedback if it really displays what it should - Like text messengers, I think all shows received states.
- numeric: I have a (big) valve controlled by a linear motor with analog feedback. When I set a value I need feedback that (and when) the desired state is really achieved
- date: Working on my heating system good to know that a date event is within range and programmed correctly
- slider: in principle as numeric (see example shown above)
- color picker: Good to know that the set color of a led bulb (not within sight) is how it`s intended to be
- [...]
How do I think it should look in the configuration dialog?
I like to add a third option "[...] shows state of input or predicted output" or something similar
How should it look like during predicted state
- text: de-saturated or dimmed font color, or italic instead of normal
- switch: Outline versions of the icon instead filled (because the "normal" off state is already "dimmed")
- slider: dimmed colors and/or outline slider knob
- dropdown: same as text
- date: same as text
- color: frame around color box and dimmed text (if used)
- button: de-saturated background color
additional thoughts
- in normal (best case scenario) the predicted state will be barely visible. All works as expected and instantly
- errors/problems could be visible to the user (light not switched on because the bulb lost RF connection)
- if more sophisticated styling is needed this could be set by ui_control messages i.e.
ui_control.predicted_bgColor for buttons or ui_control.predicted_textColor for all ui elements showing text
- I think the impact to beginners or "normal" users is minimal
- for some nodes (i.e. slider, switch, ...) it can only be achieved with a change in code. I tried with quite a lot of afford to achieve this with
mechanics
form a runtime / editor point of view the dashboard nodes will behave as it is currently (sending and receiving messages). The only difference is that when the user make an input the value is displayed as described above (or defined by ui_control objects). If the value/state results of a message on the input it is displayed "normal"
I hope together with all my posts before I managed to make the idea is clearer now.
Chris
So this would only be an option when the "Pass through messages from input" was not set. Also I think it's not really predicting anything so I think the name needs to change - but we can think about that. maybe requested ? - and the label is more just "Show state" rather than state of input or output.
For others apart from switch the option would either be this behaviour or not.
As I said I think maybe start with the switch only to see how it looks before going wild and spending too much time on all the others.
That was the plan (starting with only one). I let some native speakers decide on naming things correct, I can do the German “Bezeichnung” then 
The switch is a good one because I don’t like my workaround (tweaking the icon) as you can see on the gif above.
Let’s see what I’m able to do. This will take a while because I have so many other things to do...
Don't worry - I'm not rushing 
