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

[BartButenaers]

Hi folks,

Based on another discussion, I created the node-red-contrib-ui-multistate-switch UI node:

Thanks to our CSS guru @hotNipi for all styling tips!!

Known issues:

• Too much space between the widgets. Need to have a look at that... Had expected that height: {value: 1}, would have solved that automatically ...

• The slider touches the border at the end:

  

• The border needs to become adjustable.

If anybody wants to give tips (or pull-requests), that would be very much appreciated because I'm seriously running out of free time...

P.S. It is not published on NPM yet, so you can install it directly from my Github repository by running this command in your .node-red folder:

npm install bartbutenaers/node-red-contrib-ui-multistate-switch

Have fun with it!!
Bart

[dceejay]

Bart and his amazing unfinished projects ;-)....
(does look good though... I knew someone would crack )

Needs a bit more work under light theme.

[hotNipi]

Heh, good old @BartButenaers - no patience what so ever But OK, let see what you have done and then figure out better solutions for sizing and positioning of that moving element.

[BartButenaers]

@hotNipi

let see what you have done

Well the initial idea was quite simple: take your template node and convert it to a UI node. But the dynamically created radio buttons didn't want to fire the watch of the scope variable. Have been reading through 50% of Stackoverflow, but then I was tired of the AngularJs ng-model mystery and I decided to use simple click events. And that worked from the first time. No magic for me anymore

[hotNipi]

All of that could be built without radio element (forcibly hidden) usage. Just one internal state to manage. For ui_template it makes sense but for dedicated node ... hmm... can't we really do better?

[BartButenaers]

@hotNipi

could be built without radio element

When the node was almost done, I was thinking the same: why on earth am I using a radiobutton, because it is in fact hidden and I don't use anything from it anymore...

But I was running out of time ...

@hotNipi

can't we really do better?

Probably yes.

[dceejay]

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

[BartButenaers]

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},

[dceejay]

Yes but width should be 0 (auto)

[cymplecy]

@dceejay

Bart and his amazing unfinished projects ;-)....

How very dare you say something like that!

[SonoraTechnical]

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....

[Paul-Reed]

@SonoraTechnical

Your multistate node takes up more than 1 line

What do you mean by line?

[SonoraTechnical]

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

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

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)...

[hotNipi]

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.

[BartButenaers]

@hotNipi

All of that could be built without radio element (forcibly hidden) usage. Just one internal state to manage. For ui_template it makes sense but for dedicated node ... hmm... can't we really do better?

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:

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 ...

[Paul-Reed]

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

[BartButenaers]

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

[Paul-Reed]

@BartButenaers

Fixed now:

Right hand image has a missing 'i'
Type ui_mult_state_switch

[Colin]

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.

[Paul-Reed]

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