Colin,
Can you please explain a bit more how it works? Not clear to me at the moment after a day at work ..
Yes I had seen that one, but had not changed it because then the testers of this node would have errors in their flow when I change it. But yeah, better to change it now ...
@hotnipi and I have now a new version on Github with following changes:
The typo is fixed in the node id, but this means that you need to remove existing multistate switch nodes (because the old ones won't be recognized anymore)!
Colin's bug (with the 0 payload) is fixed.
I is now possible to specify a label on the config screen.
The styling has been finetuned, a.o. to allow larger series of states:
The styling can be changed, e.g. rounded corners. There is a section on the readme explaining how to do this.
Since it now contains the basic functionality, we have published version 1.0.0 on NPM 
The node as you have it operates the way a ui-switch does with the Pass Through checkbox selected. If a message comes in it sets the visual state and the message is passed on.
If Pass Through is not selected then there is the additional dropdown selection labelled Indicator which can either be Show State of the Output or Show State of the Input.
With Show State of Output selected clicking the switch causes it to change state and the visual state changes. An incoming message does not change the switch and is not passed through. In fact I can't see the point of this mode as it appears to be exactly the same as Pass Through mode but with no inputs connected.
With Show State of Input selected then clicking the switch sends the message, but does not change the internal or visual state of the switch. The switch state can only be changed by passing in a message (which is not then passed on). An example of the use of this is where the switch is controlling something in the real world, which has a way of indicating back to node-red what its current state is. For example a light controlled by a Sonoff or similar device. The switch can be configured to not pass through, and to show state of the input. Then when the switch is clicked it sends the message to the Sonoff which switches on and sends it state back to node-red, where it is connected into the input of the switch, which changes state. This acts as confirmation that the device has actually changed state, as the visual indication does not change until the acknowledgement comes back. Also if the Sonoff is switched by another route such as pressing the button on it then that gets sent back to node-red so the node-red switch follow the state of the real world.
Couldn't the 'rounded corners' have been a user option from within the node config?
Most ui nodes control their own appearance from the config screen, such as size, colour, background, icon, label, etc... and don't rely upon additional css templates.
Using a template node to achieve that change means further coding by users, and yet another node in the workspace, and IMO, most users will wish to use rounded corners.
Intended as constructive feedback Bart/Hotnipi 
None of default nodes provide that option via config. And how much rounded is perfect?
But they do control their own individual appearance, and allow multiple instances of those nodes to display differently in the same workspace. Using a template node sets the styling for all multistate nodes, regardless if it's wanted or not.
IMO most users will use rounded corners, because it looks aesthetically better, but it's not configured like that by default.
If all ui nodes relied upon template nodes for their appearance, workspaces would become cluttered and over complicated.
The 15px rounding looks a good acceptable option, and would appease most users. But of course if any advanced users wanted something different, then yes, let them override the css.
If I want to do this, the any predefined rounding does not help me at all.
To get individual elements to look differently is advanced stuff anyway. Much more important is to allow them be styled with less and simple rules. The one node can't be that smart to be art proven in all terms.
If this node will allow rounded corners, and you'll need the buttons also be rounded, you still have no more choice but to go with the ui_template and modify some defaults.
Hi Colin,
Thanks for the explanation. This use case indeed makes sense.
But I would like to have something that is a bit self-explaining, even after a hard day at work 
Can't we add something like this:
Then you can combine those two input fields to achieve your "Show State of Input" functionality.
Does this makes sense?
This is as bad as it can be. If you controlling some device and the processing takes time, then how can you be sure that processing has been started? Was my click successful? Can I click again?
The user action must always produce at least some kind of immediate feedback.
No, but maybe two options - rounded or not rounded will satisfy 95% of users.
I'll leave the discussion here, because this is just my personal opinion, but instead of using 2 nodes to achieve this, I will probably use the html version in a single node - Feature Request - Off - Auto - On Toggle - #13 by hotNipi
So true ... No objections ...
15px does not satisfy all the situations
Just an idea. Can't we have a "rounding" percentage input field? Then users can set it to 0% if they don't want rounding, or if they don't want us to apply it (e.g. when they want to do it via css on their own)?
I know I said... but
Is an 11 way switch going to be a popular choice?
Most probably not. But popularity of choices should not drive the deign flaws.
Not much to do with percentage. It works only for perfectly square element. for rectangular stuff youll need some solid value.
Can we introduce some kind of button-clicked effect (which can be activated optionally), to indicate that somebody has clicked a div element? Then we don't need to switch immediately to the new state, but we "temporarily" show that a state has been clicked...
E.g. like the ripple button effect (see here), or some other fancy css effect which I'm currently still not aware of
A post was merged into an existing topic: Feature Request - Off - Auto - On Toggle
In the mode in which this is used the current state of the process is fed back in to the input so you know whether the process has started because the switch will change. It is not appropriate for all use cases, but where it is it is just what is required.
Here is a simple flow demonstrating the way it is used. The delay and the link nodes simulate going out the process and back in again.
I am torn between whether it should use the same words as the ui_switch node uses for the same modes of operation, or whether the wording could be improved.
In the meantime I has posted a question relating to how the ui_switch works as it seems a bit odd to me. Switch node - what is point of Show State of Output option?
Colin,
The tricky part about having the State fed back is the following example.
Say I have a pump... it can be ON/OFF by operator selection (let's call that manual mode)
Or it can be On/Off by control decisions (lets' call that auto mode).
So, if I were to have Off - Auto - On options on my multi-switch node (these are very common options in automation and control for controlling devices), the status would be on/off .. even when we select a command of auto ... it' status would be on/off... I display a red/green LED for on/off status next to the 3 option toggle switch.
All of this is easy to do with a simple on/off command/status structure... It's more complicated when you are using a 3 options switch to handle a combination of command/status and mode selection.
I always find I have to be very specific about startup modes and so forth when my flows start to set these things properly... Because my equipment as a whole has many phases/modes of operation, I am exploring saving everything to retentive variables to handle a power issue while in the middle of an operation that is not a default 'startup mode'. that way when I startup.. I can recover properly and everything is indicating properly.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarksā¢ or registeredĀ® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy