[ANNOUNCE] node-red-contrib-ui-multistate-switch: 1.2.0

[BartButenaers]

Hi folks,

After a delay of some months (due to circumstances), @hotNipi and I proudly present the first 1.2.0 beta of the node-red-contrib-ui-multistate-switch node

Since there were lots of feature requests from the community, we had to spend quite some time together to implement all of those. After a while, my wife (alias "The colonel") was getting quite suspicious. Because me staying up lately every evening, to chat with somebody named 'hotnipi'

The list of new features (which you can also find in our release notes page):

1. The options in the editable list can now be reordered.

2. The height of the widget can be increased (a.o. to visualize long labels).

3. Improved options configuration validation.

4. Support for multi-line labels.

5. Allow Mustache syntax inside labels.

6. Show ripple effect when the switch is clicked.

7. Align path color to text colors (for svg icons).

8. Multiple options to configure the passthrough of input messages.

9. Multiple options to configure if user input is allowed.

10. Multiple options to configure if input messages should be accepted.

11. Allow the options (from 7, 8, 9) to be configured dynamically via an input message.µ

12. Wiki pages have been added. For example how to show icons in the label and switch options.

We would appreciate if people contribute to our node by testing this beta version. You can install it by executing following command (from within your .node-red folder):

npm install node-red-contrib-ui-multistate-switch@1.2.0-beta.1

As always, all "constructive" feedback is very welcome!

Have fun with it!!!

@hotnipi and Bart

[jodelkoenig]

@BartButenaers

Because me staying up lately every evening, to chat with somebody named 'hotnipi'

Oh dear

[BartButenaers]

Hi folks,

My partner @hotNipi and I finally managed to process all the above feedback on our first beta.
Here is the resulting list of changes between the first beta and the final npm version:
1.
2.
3.

Hopefully we didn't forget anything

Version 1.2.0 is now available in the Node-RED palette:

Have fun with it!

[eddee54455]

Hi B & N,

Awesome!!

Thank you sooooo much!!

Any chance of adding Boolean output(T/F) as an option? (I know it doesn't apply to generic non-binary, more than 2 option scenarios, but would be pretty handy nevertheless!!)

Cheerz
Ed

[BartButenaers]

@eddee54455

Any chance of adding Boolean output(T/F) as an option? (I know it doesn't apply to generic non-binary, more than 2 option scenarios, but would be pretty handy nevertheless!!)

Hi @eddee54455,
Indeed that would only be relevant for switches with 2 options. But for me it is fine to add such a boolean option, when we add that limitation as a comment in the readme. @hotNipi : ok for you?

[hotNipi]

The limitation will come naturally cos the configuration has validation at every step with the rule "options must be unique". The rule must then also check the type of the option. Options true and "true" are different things. I cant see any problems with this improvement.

[eddee54455]

Absolutely Great!

Thanx Heaps!

Ed

[BartButenaers]

@eddee54455

Any chance of adding Boolean output(T/F) as an option? (I know it doesn't apply to generic non-binary, more than 2 option scenarios, but would be pretty handy nevertheless!!)

@eddee54455,
This feature is now implemented on our Github repository:

You can install this version by executing following command (from within your .node-red folder):

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

Would be nice if you could do some tests (before we publish it on npm), to make sure I haven't introduced bugs ...

[eddee54455]

Hi Bart!

Tested and working, only one small issue - on insertion of a new instance of the node, the size defaults to 0 x 1, I presume it should possibly rather be auto? (Not serious!!)

All output formats tested A-Ok, Bool, Alpha and Numeric....

Regds
Ed

[BartButenaers]

Hello @eddee54455,
Thanks for testing all the combinations!
Yes the height 0 has been discussed some time ago. Can't find the link to that post anymore...
@hotNipi Do we publish an 1.2.1 version for this little feature, or do we wait until we have some a few extra features?

[hotNipi]

It is small bug and does not break anything, feel free to do as you like

[smcgann99]

Hi @BartButenaers @hotNipi

I found a couple of possible issues with the node.

If you want to replicate add an extra inject node for msg.enable false to your example flow.

Whatever option is selected, when the switch is disabled changing tabs / refreshing etc moves the slider to the first option, (on the browser that was refreshed only). So you cannot know what the last selected option was.

To get around this I thought I could just inject the correct value again. However after an option is set via input message, another refresh causes the switch to become enabled again, so it can be clicked in ui.

I was looking at using this for intruder alarm modes home away off etc, but need to see that actual state and prevent unauthorised changes, by disabling the switch.

Something to look at maybe when you are not too busy

[jbudd]

It looks like a useful widget, sort of a hybrid between switch and slider, or more stylish radio buttons.

If I setup a new multistate switch, adding two options and change Passthrough to Always, messages are not passed through.

[{"id":"98500dae229603c2","type":"ui_multistate_switch","z":"a8b525f892494ba7","name":"","group":"3ce32370.c60f1c","order":7,"width":0,"height":1,"label":"switch","stateField":"payload","enableField":"enable","passthroughField":"passthrough","inputMsgField":"passthrough","rounded":false,"useThemeColors":true,"hideSelectedLabel":false,"multilineLabel":false,"passThrough":"always","inputMsg":"all","userInput":"enabled_show","options":[{"label":"Option 0","value":"option_0","valueType":"str","color":"#009933"},{"label":"Option 1","value":"option_1","valueType":"str","color":"#999999"}],"x":380,"y":120,"wires":[["aeffaf913bccf9bf"]]},{"id":"becca314f7a35c3d","type":"inject","z":"a8b525f892494ba7","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":240,"y":120,"wires":[["98500dae229603c2"]]},{"id":"aeffaf913bccf9bf","type":"debug","z":"a8b525f892494ba7","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":530,"y":120,"wires":[]},{"id":"3ce32370.c60f1c","type":"ui_group","name":"Demo","tab":"d74bbed4.c2cfb","order":2,"disp":false,"width":"6","collapse":false,"className":""},{"id":"d74bbed4.c2cfb","type":"ui_tab","name":"Demo","icon":"dashboard","order":1,"disabled":false,"hidden":false}]

I then send a message with (only) msg.passthrough = "always" to switch passthrough on. The node throws an error and complains that msg.payload is undefined.

[BartButenaers]

@jbudd

If I setup a new multistate switch, adding two options and change Passthrough to Always, messages are not passed through .

Hi @jbudd,
Seems a typo bug was introduced somewhere near the end of our beta phase. I have added a fix on Github, which you can test by installing the version directly from Github (from within your .node-red folder):

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

@jbudd

I then send a message with (only) msg.passthrough = "always" to switch passthrough on. The node throws an error and complains that msg.payload is undefined.

You use the same input message field for input value and passthrough:

This is not possible to have one field that should contain different values (e.g. "always" for passthrough and "all" for input msg). It is one or the other ...

[jbudd]

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

npm ERR! /usr/bin/git ls-remote -h -t ssh://git@github.com/bartbutenaers/node-red-contrib-multistate-switch.git
npm ERR! git@github.com: Permission denied (publickey).
npm ERR! fatal: Could not read from remote repository.

@BartButenaers

You use the same input message field for input value and passthrough:

Those are default values. I thought it odd.

OK I copied your revised multistate_switch.js over v1.2.0
Messages are now passed through if the Passthrough field is "Always"

Still get an error when msg.passthrough is set (because the default values of Passthrough field and Input msg field are the same)

It no longer complains about undefined msg.payload

[BartButenaers]

@jbudd

Still get an error when msg.passthrough is set (because the default values of Passthrough field and Input msg field are the same)

Yes you are correct that the default value of Input messages should not be "passthrough". That was a copy/paste issue... I have changed it to another default value on Github.
Thanks for the feedback!

[BartButenaers]

@smcgann99

Something to look at maybe when you are not too busy

I did have a quick look but I don't see immediately what is going wrong. The message replaying mechanism of the current dashboard is very complex to work with. We spend quite some time getting it right, but seems you found an edge case.

Will need to find some time to debug it properly.

[EDIT] Reminder for me afterwards, to know what is going wrong:

1. If you refresh a page, the replayed message contains the current switch state:

   

   That state is being applied again, so the switch is going to the correct last state:

   

2. However when you inject a message to disable the switch and afterwards refresh the page, then the replayed message is about disabling the switch:

   

   Since this message doesn't contain the last state, the state won't be updated. Which means the switch goes back to the default state.

Perhaps we can solve this by always adding the state to the msg that we send to the server (in the beforeemit function. Will need to find some time later on, to test whether that would solve it...

[smcgann99]

Sorry it's always me that breaks your work Bart

Don't forget the other problem, that injecting an option then causes switch to be enabled again after a refresh....

[BartButenaers]

@BartButenaers

Perhaps we can solve this by always adding the state to the msg that we send to the server (in the beforeemit function. Will need to find some time later on, to test whether that would solve it...

@hotNipi,
Like @smcgann99 explained, you get very weird effects when you refresh the browser multiple times:

1. Set the switch manually to the second option.
2. Then inject an input message to disable the switch.
3. Then refresh the browser window
4. The last input message will be replayed, which tells our client side to disable the switch. So it will stay correctly disabled, but the switch will go back to its original state (since the replayed INPUT message contains no state).
5. This will trigger an output message (which will not be send, but which we used to update the server side state).
6. When you refresh again, the switch will correctly keep its new state but it will become suddenly disabled (because the replayed OUTPUT message contains the state but not whether the switch is enabled).

So I have now pushed a commit to Github that stores in all INPUT and OUTPUT messages:

• The current state
• The current enabled/disabled status

Then it shouldn't matter whether a message is being replayed or not, because - if I have implemented it correctly of course - the switch should always get again the correct/last state and status. I should have done that from the start, because it might have saved me lots of headaches...

@smcgann99 and others: It would be nice if you could install the Github version and do some tests. Preferrable various checks, because I want to avoid that this fix breaks other existing functionality.

Thanks!!!!

[smcgann99]

Bart,

I think that's fixed the issues I saw, however I found another (sorry)

With the setup as follows, injecting a 0 doesn't select the home option, other numbers work ok.