Switch: Button Type

[joepavitt]

Description

https://discourse.nodered.org/t/dashboard-2-is-there-a-simple-way-to-configure-button-so-that-it-toggles/90830/9?u=joepavitt

Consider the addition of a "Type" for switches, which would permit control over a "Toggle Switch", "Icon Only" or "Button"

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[colinl]

I think it would be useful if, at least in button mode, the 'Waiting' state display was configurable in the same way as the on and off states. In button mode should the text overlay be configurable for each state? The problem is knowing when additional features should be provided, and when to say that Bloat mode is being approached.

[bartbutenaers]

Yes - unless I misunderstood the original requirement - I think this will make the code complex.
If I want a button that behaves like a switch, then I add a button to my flow and I expect the button's config screen to contain the required settings. I would never add a switch to my flow, and ask it to look like a button. Seems a bit weird to me personally.

I "think" that this discusson on Discourse is related to this. I expect that the button config screen has the same feature as the switch, that you can put it in the waiting state.

If you agree with this @joepavitt, I will try to implement that feature on the button node this week. I will use the same implementation as in the switch node, because I really like the simplicity of your solution. Although the dropdown options are not very clear to me what it can be used for.

[Paul-Reed]

 I would never add a switch to my flow, and ask it to look like a button. Seems a bit weird to me personally

The basic action of a switch has 2 states - on & off, and therefore can easily give a misleading indication that a device is switched on, but that of course may not be true, due to many reasons including poor communication between server & remote device.

A button however does not retain a state by itself, and can easily be used to flip a current state regardless of what it is. The current state is provided from the device itself, and stored in the flow, so we always know what it is, and by flipping it, what is should become.

I have always used buttons in preference to switches, for that reason, and the example below show such buttons changing color to reflect feedback from remote devices. Note the slight network latency.

[joepavitt]

I think, given the blurring of lines between switch and button here, we go with the D1.0 way and have this as a third-party node called "button-state"?

[Paul-Reed]

Sounds a good way forward, and would stop new users becoming bewildered with a plethora of options. What are your thoughts @bartbutenaers ?

[bartbutenaers]

Hi guys, Yes indeed such a feature is very useful. For the ui-multistate node (at the time being), we have also implemented such a waiting state. To keep the button in sync with the target that is being switched on or off.

And now the big question is, where to put that functionality.

1. To ask a switch node "can you please change your shape so you look like a button" seem quite ridiculous to me.

2. Add an extra property to the ui-button node. Like you say, we need to make sure not overwhelm the users with loads of properties. But let's be honest: the ui-button node doesn't have much properties, because it is one of the simplest widgets around...

3. To create a separate node indeed sounds logical. Call it a ui-toggle-button or whatever. I see 2 disadvantages about this approach:

   • Except from the toggle feature, this node is almost identical to the ui-button. So an extra ui node to maintain, whose code needs to be kept mostly in sync with the ui-button node. Which I would find not the best idea, when you look at the enthousiasm of our community to contribute to this repo..
   • Imho it is very weird that my heatmap node has been banned, because 1 extra node in the palette was a complete no-go. And now we would create a new ui node, just avoid a single extra property on the ui-button node. Which means an exta node in the palette for everybody who wants to have such a toggle-button...

So I vote entirely for option 2.

[Paul-Reed]

You make some valid points Bart which I hadn't really considered, so I'd also support No2 as well.

Regarding creating a new node... I could of course be wrong, but Joe called it a 'third-party node' which to me suggests a contrib node which wouldn't be included in the default palette, but like your heatmap node would be loaded by choice from the palette manager by those wanting it.

[bartbutenaers]

Yes correct Paul. But you and I and others will install the new toggle-button node, so we will have 1 extra node in our palette...

[colinl]

1. To ask a switch node "can you please change your shape so you look like a button" seem quite ridiculous to me.

I am not certain of that. If you think of physical switches there are rocker switches, but there are also push on push off switches. The button is the thing that sits on top of the switch itself. The button does not have wires connected to it, it is the switch under the button that has the wires. In retrospect perhaps we should only have one node which can be instantaneous action, or toggle, and has various visualisations. Probably too late to think of that though.

[Paul-Reed]

But you and I and others will install the new toggle-button node, so we will have 1 extra node in our palette..

Yes, I get that, and agree, but I only mentioned it because your post suggested to me that you thought that there were double-standards because your heatmap node is not included in the dashboard default node list instead of being a contrib node.

Imho it is very weird that my heatmap node has been banned