Yeah, I was away from computers and did read it from phone so not much I could do but I see you have manged it going. I was pretty sure there will be such edge cases but life shows - surprisingly not too many 
I think the remaining "0 case" is walk in the park to fix ... 
2 Likes
@smcgann99,
That should now be fixed when you install the new version from Github.
It is meanwhile already dark in the park, but still easy to find it ...
3 Likes
Potential bug. When I use a new multistate switch node and leave the initial defaults in place (including use theme colors), I run into an anomaly. If I add 3-4 different states and then deploy my flow I find that my first option (when selected) shows white text on blue background. My first option shows gray text on white background when another option is selected. Regardless of which option is selected, options 2-n all show gray text with the background driven by selection or not.
Weirdly, experimentation shows that if I create 3 options, deploy, then delete the first option and then deploy again, then all options are gray text. So it is almost like the very first option has a text color hardcoded.
I am using version 1.2.0 from the palette manager.
Additional question
I am using an "All Lights" multiswitch for a room where I have multiple lights (each with their own switch on the dashboard). I would like for my multiswitch to be able to accept an on touch input for on/off to do the obvious change to all of the lights, but I would like it to be able to display that some are on state, but to never allow that to be a user selectable state. (ie. ignore that input, while accepting and outputting either of the other 2. I will programmatically change it to some when only some of the rooms lights are triggered. Is this possible or should I just treat the user input of some as an on, turn on all the lights and then programmatically update the switch to on selected?
The node does some semi-smart work to preserve readability in all conditions. It tries avoid situations where bright text is rendered on top of bright background. As you can choose any color for state, it is needed. The text color is not under user control directly so it may seems a little bit as random but it definitely not. If you'll find it does not provide enough contrast, then it is definitely bug.
For additional question - I cant see a way to make the widget that smart. The switch is simple device. It can not do such logical decisions.
@tmichaeltx,
So your switch has 3 options:
- All lights on.
- All lights off.
- Some lights on.
And only option 1 and 2 are manually selectable, while option 3 is automatically selected by your flow via an input message.
Something like that is currently not possible. In that case e.g. each option in the editableList (on the config screen) should have a checkbox "selectable", or something like that. And that would determine which options are disabled and which enabled. Such a feature would unfortunately be quite a lot of work to implement (e.g. the partially disabled look and feel)...
@BartButenaers Not a surprise that this corner case would be hard to implement. I will just build my workaround. Thanks for verifying that I wasn't just missing something semi-obvious.
Shouldn't the color of the text when using the theme colors be the same for all options (whether good contrast or bad at least consistent)?
Well, consistency vs readability in situation you can't control - for me the readability wins. But let's see what @BartButenaers says.
I agree that given a choice, I would choose readability. I am not sure I am conveying what I mean. Here are some images to explain:
As initially created (notice no custom colors) with 2 items
Deployed as initially created notice the first selection is white on blue
Deployed as initially created with second option selected. Notice Black on blue
Now if I add a third option
Option 1 selected white on blue, Option 2 black on blue, Option 3 black on blue
Then if I delete the first option
Option 1 black on blue, Option 2 black on blue
Finally if I reorder the 2 options
and change Full v2 back to Full
Now Options 1 and 2 are both black on blue unlike the initial case where the first option was white on blue
This is what I mean by consistent (though if I had an option I prefer white on blue in this case).
Please don't take this the wrong way as I love the multiswitch and have workarounds for my corner cases that it does not support.
OK .Must check for that. This is inconsistent for sure. Will see if I can reproduce. Seems like situation based on default light theme?
Yes, though I may have picked the blue color
Bug confirmed. Pushed fix to the master. Routines to test as usual - install from git repository.
1 Like
Version 1.2.1 is now available in the Node-RED palette:
The release notes contain a list of what has been implemented.
Great work Bart et al
I have a problem with the control though
See screenshot below
You can see i have implemented 3 of the multi state objects and they are over writing portions of other dashboard objects.
I am runnign NR 2.1.1 in a VM on Ubuntu 20.04 - dashboard 3.0.4 and 1.2.1 of multistate switch
Google Chrome on Windows 10
This same behaviour was in place with 1.3.5 of NR
Any ideas on why i am getting this over writing ?
Craig
I have seen this kind of failure before. Can't be sure we can blame the widget here. If you can test it by replacing the multistate switches with some other dashboard widgets but leaving the sizes of the groups and widgets same, and see if it works, then it is definitely somehow related to widget.
1 Like
Indeed. The overall layout algorithm sometimes fails when there are groups of differing widths
1 Like
OK thanks guys - will follow the advice and report back
Craig
Hi, I am trying to use your switch and struggling with the following:
Wondering if you could assist? Thanks!
Let's try and keep the discussion in one topic please!
