[ANNOUNCE]node-red-contrib-ui-multistate-switch: v1.0.0

I think default should be auto size (EG 6 wide)

This widget should only be adjustable in width but not in height.
Isn't it then correctly to set height to 1 as in this snippet:

width: {
   value: 3,
   validate: function(v) {
      ...
   }},
 height: {value: 1},

Yes but width should be 0 (auto)

How very dare you say something like that! :slight_smile:

1 Like

I went through hotNipi's original UI Template and got it working very well in a 5X wide group w/ 3 options.
On then 7" 800x480 official RaspberryPi TouchLCD Display, where my widget size is 24, I got the object taking up just one line.

Your multistate node takes up more than 1 line ... and enough CCS was overwritten to make the tweaked UI-template versions take up more than 1 line now as well.

I posted my code in the Multistate Flow that I shared, you can see the dimenstions I applied to make it fit nicely on the RaspberryPi official display...

None of this is criticism (you did absolutely awesome work)... just sharing the results of my testing....

What do you mean by line?

Here is what they look line when they take up 1 line: (size 6x1 or 5x1)
Multi-StateToggleExamples

This is what happens when the dimensions aren't correct, and you re trying to fit it into a 6x1 or 5x1 grid:
3WayTogglesTooTall

When adding your Node.. CSS settings affected my UI-Template nodes too.... they all require scroll bars to fit .

Your node is sized 25% larger than my UI-Template objects... So I had to increase my grid size to 32x32 (from 24x24). If you are using HotNipi's original work, they will be the larger... But remember that I re-sized his work so that it would fit comfortably in the default size often used on the RaspberryPI Official Display. A 32x32 grid size is too big on the Raspberry PI displays and really limits content.

I know I represent only a subset of users.... but I think this is as small as you need to plan for... 840x400 on a 7" screen.

As an aside, 24x24 grid with 4x4 for widget spacing also makes my graphics display very nicely on a cellular phone as well... with more than enough room to effectly issue commands with a touch... (it helps that cellular touch screens are often very precise and we've trained ourselves to use them carefully.... it's funny how instantly sloppy we become when using larger touch screen panels)...

Most of the default dashboard widgets don't support unit size 24x24 px. It is very extreme and requires to override many things to get useful results.
The unit size adjustment is not magic wand and definitely not last one and singe option to fit something into small screen.
Any node built for dashboard should and mostly do follow same standards and they behave on same rules. So I cant see why this node should support it by default. It is painful to do so. Believe me I have tried a lot.

1 Like

Got a new template node from @hotNipi which was based on div elements instead of radio buttons. I have redesigned the UI node to use the same mechanism, so the code is now much cleaner.

Moreover I have converted the option's "value" field to a TypedInput, so it is now possible to use both strings and numbers:

image

BTW the current version has no rounded borders anymore. Will add soon a section on the readme page how to accomplish that, but need some assistance from my partner ...

Just noticed a few typos for node-red-contrib-ui-multistate-switch

toggle2

toggle

Some remainders from the first draft version ...
Fixed now:

image

1 Like

Right hand image has a missing 'i'
Type ui_mult_state_switch

This will be very useful. Great work.

A couple of issues I have found, apologies if they have already been noted, if one of the states is selected by numeric 0 then feeding that in does not select the state. It works ok with string "0".

Are you planning to add the optional message pass through checkbox, and the ability then to show state of input or output, as seen in the core switch node? I find that very useful, and the Show state of Input feature cannot be replicated with external nodes.

1 Like

Also, it would be great to have an optional label to identify the purpose of the toggle, as well as labels for each state. (like the ui_switch)

For example;

Garden Lighting ON/OFF/AUTO
Drive Lighting ON/OFF/AUTO

1 Like

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:

    image

  • 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 :champagne: :partying_face: :clinking_glasses:

image

2 Likes

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 :wink:

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.