Correct. If you upgrade, Node-RED will complain that there are a bunch of undefined nodes. You unfortunately have to delete them and re-create them. Or for the example flows it's easier to re-import the full example.
I finished my A/C controls with the addition of the timeline-plot to show when the compressor is active and how fast it is running (gradient).
And I implemented another tab to control the rolling window shutters. For this one I had to develop a new button-bar widget. I did that outside of the FlexDash repo in its own NPM package to test writing a custom node & widget for FlexDash. A bunch of stuff got broken due to the migration to Vuetify 3 but I believe it's all fixed and back together now. Docs are not quite there yet, except for documentation of the internals so I remember the next time I have to deal with this crazy javascript linking stuff 
.
Supporting all this is a new release:
20 Aug 09:09:59 - [info] Node-RED FlexDash plugin version 0.4.88
20 Aug 09:10:01 - [info] Node-RED FlexDash version 0.4.88
20 Aug 09:10:01 - [info] Node-RED FD Core Widgets version 0.4.39
20 Aug 09:10:02 - [info] FlexDash UI version 0.4.47
I also resurrected the node-red-fd-testnodes repo for the custom button-bar but 'til the docs at least minimally describe how to write a custom widget that's not ready for prime time yet...
6 Likes
Just having an initial play with FlexDash and it looks great so far.
Is there a dropdown selector widget? I can't seem to see one. It may well just be impending blindness on my part 
2 Likes
Thanks for giving it a spin!
There is no dropdown selector widget at this point 
Do you want to write one or prefer me to throw something together?
If the latter, post the help & props (i.e. something like flexdash/push-button.vue at main · flexdash/flexdash · GitHub) and I'll fill out the rest.
I don't think my skill level is up to writing one. I will see if I can come up with a spec.
It might be a few days though, I sense real life is about to make demands
1 Like
Nice work so far! 
One suggestion, please start using some kind of i18n right away. When I started translating the original Dashboard to German I had to put a lot of extra work into extracting existing English text into translation files, so that translation was even possible.
Here is the example I looked at: flexdash/push-button.vue at 4e1fec8804c511d3e97e077e529b113c6c9dcb58 · flexdash/flexdash · GitHub
I think it's only a small extra effort for new code, but it's a lot of work to do it afterwards for a whole project.
2 Likes
Thanks for giving it a spin!
I thought about it but don't have any experience with i18n and wasn't really excited by what I saw, it really obscures the source code. I'm OK doing it if someone comes up with a decent framework, but right now the number of FlexDash users is <10, and the list of things for me to fix is ... endless.
That's what I thought too in my first i18n projects, but it's really not that bad. It actually even shortens the amount of text sometimes.
Flexdash should be able to access the RED object at anytime, right? Calling the RED underscore function should be all that needs to be done...
This is how I access it in my Dashboard nodes:
More information: Internationalisation : Node-RED
Not really... FlexDash is a project independent of Node-RED. The dashboard is used in other projects too and I definitely want to keep it that way. The i18n would have to fit into Vue (which has i18n support).
The main help text and the names of props as well as their tips comes from the vue files, which have nothing to do with Node-RED. What you see in the NR flow editor is auto-generated from the vue files. It would, however, be pretty easy to extract all the help text, prop names, and tips into a file that could be translated and from which the translations could be taken to replace the english text at run-time. That would probably also be the best way to do the translations 'cause you then see the whole picture of what you're translating.
That would leave placeholders for input fields to translate and error messages plus misc other text fragments.
Is the toggle working OK in your latest, or have I missed a config?
Also, (and I know I'm going to regret asking... but) what is a 'prop'??
[EDIT] - Oh 'properties'... I'm more familiar with the term 'config', which is used generally in node-RED.
1 Like
It should be working... But not as you expect... When you click it it outputs a message but doesn't change on its own. You need to feed it the new value in explicitly.
It's something I've always struggled with the std dashboard and I decided to try something else. On the std dash you toggle something and it shows as toggled but you don't know whether anything actually happened. So I decided that the author of the flow should figure out when/how to let the user know that the input was processed. The simplest is to use a junction node to feed the output back to the input. I'm open to discussion...
WRT props... It's from Vue, where each component has "props", short for "properties" as you surmised. I wasn't sure what Node-RED calls these things. I know it's "config" in the code, as you point out, but I looked in the docs and Nodes : Node-RED has a whole section about "editing node properties" and if you look at the UI in the flow editor the tab is called "Properties".
2 Likes
If I set the on/off values from 'string' to boolean, it does not trigger a deploy, and reopening the config (props) reverts back to 'string'
1 Like
Hmmm, looks like I still have another round of battling typedInput ahead of me... I'm still misunderstanding something about how it works. Thanks for pointing it out!
On the topic of "What have you done today?" ... I implemented a color picker in Node-RED for the over 200 material design colors that are in the palette...
Now released, but I'm sure I'll get to fix issues with it, I'm not used to all this jQuery stuff to build UIs...
21 Aug 15:50:32 - [info] Node-RED FlexDash plugin version 0.4.90
21 Aug 15:50:34 - [info] Node-RED FlexDash version 0.4.90
21 Aug 15:50:34 - [info] Node-RED FD Core Widgets version 0.4.39
21 Aug 15:50:34 - [info] FlexDash UI version 0.4.48
5 Likes
Not a question that I have considered!
I've never known anyone develop a project so quickly as you have done over the past few weeks
5 Likes
I believe I fixed the typedInput madness , i.e. this should work correctly now. Requires updating node-red-flexdash and node-red-fd-corewidgets.
21 Aug 21:48:04 - [info] Node-RED FlexDash plugin version 0.4.91
21 Aug 21:48:06 - [info] Node-RED FlexDash version 0.4.91
21 Aug 21:48:06 - [info] Node-RED FD Core Widgets version 0.4.40
21 Aug 21:48:11 - [info] FlexDash UI version 0.4.48
Sorry, what I wrote was just a rhetorical question, had nothing to do with what you wrote before, but I see how I was ambiguous.
I can completely understand your design decision. You can see that for the node-red-contrib-ui-multistate-switct node, that we allow the user to choose which behaviour he wants. At the beginnen we had implemented it indeed like the standard switch: i.e. immediately visually switch. But then somebody asked us that he wanted to do it like you do: that the switch is not visually switched, until the machine is really switched on. However due to the roundtrip to the Node-RED server, then to the machine (e.g. via mqtt) and all the way back to the dashboard, it might take some time before you see the switch visually changing. Such unresponsive behaviour is quite confusing for users. Therefore my CSS hero @hotNipi introduced that visual ripple effect, to show at least that the dashboard has processed your click event...
Personally - if possible of course - I would let the user choose on the config screen how he wants the switch to behave....
It looks like you have made a custom typedinput for colors? If so, don't hesistate to contribute that to the core... Such a typedinput would be very useful. Colors are being used in iot all over the place. I use it in a lot of my nodes, but it is very inconvenient that there is no typedinput for it. Because now I have a mix of typedinputs and normal html inputs 
1 Like
Yeah, that seems like the right thing to do. I'm using the vuetify toggle, have to look whether it supports some ripple.
It's not actually a typedInput. It's simply a class that constructs a color picker. The result is a string with the color name, not the hex value (although hex values work fine with FlexDash color props). It's also pretty specific to the material design color palette and how it's represented in Vuetify. Soooo, the code is available at node-red-flexdash/plugin/resources at main · flexdash/node-red-flexdash · GitHub and if you're putting together a node for FlexDash with custom node code then it should be easy to use. Beyond that... 
1 Like
Ah vuetify has such stuff all out-of-the-box. Didn't know that. How convenient is that for developers...
For the record, that behaviour (which I think is the optimum one) can be achieved in the standard dashboard Switch node by not selecting Pass Message Through, and selecting Switch Icon shows state of Input.
I think there may still be a small bug in the flexdash toggle. If the output is fed into a debug node, with no feedback back to the input, then I believe that when clicked it should send a message with the new state each time it is clicked. So if it is currently off it should send the on message each time it is clicked. In fact it seems to send it only every second time it is clicked.
One thing I really miss from the standard dashboard nodes is the ability to specify the topic in nodes that have an output. I use MQTT to interface between the dashboard and the IO/logic flows so the output of dashboard nodes almost always goes direct to an MQTT node. I find with flexdash that I almost always need to follow the node with a Change node to set the topic. Was this feature something that was intentionally not included in fd? I wonder whether that decision would be worth re-visiting.
for adding topic
1 Like
