🚀 [FlexDash] alpha release - a dashboard for Node-RED

[tve]

New release :

13 Sep 12:42:43 - [info] Node-RED FlexDash plugin version 0.4.105 
13 Sep 12:42:44 - [info] Node-RED FlexDash version 0.4.105  
13 Sep 12:42:44 - [info] Node-RED FD Core Widgets version 0.4.46 
13 Sep 12:42:46 - [info] FlexDash UI version 0.4.61 

Please update node-red-corewidgets in addition to node-red-flexdash. And refresh any open browser windows.

To install FlexDash from scratch or for other help, please refer to the documentation,
especially the quick start section.

Fixes :

• k for kilo in stat widget
• support for precision in stat widget
• fix colors (supporting names like purple-darken-4)
• fix error caused by moving widgets in FD when there are disabled widgets
• fixes for scrolling of tables and also in pop-ups, still not 100%
• added sorting to simple-table

Not fixed :

• Use msg.payload in label widget and a bunch more
• Sparkline doesn't handle 0 value input correctly
• fix redirect for URL without slash and query string, e.g., http://localhost:1880/flexdash/?theme=dark
• find a fix for loopback, e.g. toggle node (work-around: please disable loopback and use wires & junction node to loop back in the flow)
• did I forget something?

Musings :

I'm pondering a bit about the component hierarchy in FlexDash. Right now there are tabs, grids and widgets. Tabs and grids are containers (contain other FD components), widgets are leaves in that tree. Except for panels, which are widgets but contain other widgets, a bit of a hack. So there are 3 levels in the tree (tabs, grids, widgets) or sort of 4 with the panel hack.

I'm wondering whether I should scrap all this and just have widgets and remove any built-in notion of tabs and grids and make it so a widget may or may not contain other widgets. (I may keep the notion of tabs 'cause they tie into nav and other rather special stuff, could allow to plug in a different implementation with different representation, though).

I believe this would simplify the code base somewhat and it would make FD more flexible 'cause at some level it then allows pretty arbitrary types of web pages to be built. On the other hand, a bunch of weeks would disappear into making this change. The good news is that by and large such a change would not be that disruptive in that the widgets that display stuff wouldn't really have to change and the NR nodes would also remain the same (grids and panels are already both "fd_container"). So I'm inclined to push forward as-is and worry about the refactoring when there's a bigger push to try alternate page layouts.

As always, I'm sure you will let me know about issues

[craigcurtin]

I am following on with the discussion avidly but have not had time to do any testing of moving my dashboard across to this point.

It might be an idea though each time you publish an update to put a link in the description about how to install from scratch (as the update you publish might tweak someones interest enough to get them moving on trying Flexdash !)

And indeed a link to how to reinstall the core widgets etc if they require that as part of the process (rather than a complete reinstall)

Just wanted to say great work on this also - very much admire the amount of effort you are putting into this one.

Craig

[dceejay]

This is one of the corners we got stuck in with dashboard. When we wanted to create sub-groups of widgets (ideally that could be then re-useable/repeated ) it all got rather too complicated. So thinking about it now is a good idea, especially if it can handle greater depths.

[tve]

@craigcurtin

It might be an idea though each time you publish an update to put a link in the description about how to install from scratch

Thanks for the suggestion! I added a link to the docs quick start page.

@craigcurtin

And indeed a link to how to reinstall the core widgets etc if they require that as part of the process (rather than a complete reinstall)

What is actually the recommended way to pull in an updated package? I would assume either

npm upgrade

or going to the palette manager > install, entering 'corewidgets' into the search, and I presume there will be an update button next to the package?

@craigcurtin

Just wanted to say great work on this also

Thanks now you have no excuse not to try it out

@dceejay

we wanted to create sub-groups of widgets (ideally that could be then re-useable/repeated )

Would you mind elaborating? (btw "dashboard group" == "flexdash panel") The intent of the change I was musing about would allow panels to contain panels (among other things). Could you elaborate on the re-usable part? Panels could also contain SubflowPanels so one could create a subflow with a dashboard representation and re-use that. Or did you have something else in mind? (It helps me hear how others phrase it 'cause often I miss the obvious.)

[craigcurtin]

@tve

@craigcurtin

And indeed a link to how to reinstall the core widgets etc if they require that as part of the process (rather than a complete reinstall)

What is actually the recommended way to pull in an updated package? I would assume either

npm upgrade

or going to the palette manager > install, entering 'corewidgets' into the search, and I presume there will be an update button next to the package?

As long as they are just standard packages and do not have any other dependencies that can not be met - then yes that should be the way (its the way i do it) - not sure if it is the recommended way though ?

Craig

[domenicquirl]

Apologies for apparently posting to the wrong location. For some context, while I was dealing with our Node-RED infrastructure this week, this is not my usual work which is entirely unrelated. Hence also why I was not using this forum and the most natural place for me to post feature requests was the project's issue tracker. If this is undesired, perhaps it would make sense to add a note to the start of the README (it currently mentions this forum exists "for help" but does not mention issues or feature requests).

The above is also why it didn't make sense for me to ask and then wait for new additions/features/fixes if other solutions exist, because I want to / have to get back to my actual work and don't want to keep coming back to this. I fully expect you to eventually have all of the things in my list, as said originally for being in alpha FlexDash already does a lot!

Regarding your follow-ups:

Did the dropdown-button not fit the bill?

There was no dropdown-button node. I have a dropdown select, a push button and a popup button. The button-bar looks similar to the multistate switch from dashboard, though I can't say if their functionality matches exactly. Basically what I was looking for is a single-selection multiple-choice visually represented not as radio buttons or a dropdown, but as a conjoined panel of buttons that can be switched between by clicking. Preferably, the labels of the different choices would be distinct from their internal values (the multistate switch allows this).

preventing feedback loops

So this one is related to how I wanted to handle our devices. We have parts of the UI that interact with remote hardware via various forms of network communication. This means that there are two distinct values behind any device value:

• the actual current state of some device value
• the current state that a device value is supposed to have according to the user, i.e. what the user wants to set the value to

and there are three things you need to display in the UI:

• the actual value
• the intended value
• a UI element to change the intended value

Sometimes these values influence one another, so e.g. a command that you send will change both the on-device command, but will also affect the state of the device somehow, which you also need to display. A different flow that we have has a dashboard that solves this by showing individual UI elements for all these things. So there is a separate UI node for the actual command, the sent command, the state, and a button to change the command. This was perceived as unwieldy and confusing by users and it was requested to find a different solution for the current project.

The multistate switch allows me to use a single UI element for three of the above (everything except the state) by setting it up such that it always shows the actual device value, but allows clicking, which triggers a command and has a visual indication of a short "ripple". This is only possible though because I can configure it to accept and react to message input, but not pass them on even if they change the switch position, but also accept and show user input from the UI (and pass that on as a message). Otherwise, there would be a feedback loop where the user changes the command, but then the widget is updated with the actual command from the device (which has not yet changed), which changes the switch again, which triggers a new command. Then the first command completes and switches the widget again, while the second is being executed. And so on and so forth.

colour overrides

Simply being able to adjust the colours of widget elements more granularly. For example, setting both an "on" and an "off" colour for the toggle, and/or for the text. I keep using the multistate switch as an example, but that's maybe because it just does this really well: you can either have it use the theme colour (or just any colour) for the active variant, or you can set colours for each variant individually. The latter can be used to create a green/red on/off switch, for example, or a green/yellow/red status indicator (ok/warning/alarm), etc.

[Paul-Reed]

@tve

New release :

I don't think that the update is available for users to try @tve
I've checked Manage Palette and it shows no update;

and indeed using the cli update process & rebooting still does not bring in the changes in the changelog, or change the version numbers.

I see npm is showing the current node-red-flexdash at v0.4.100, yet your repo is v0.4.105, so maybe the npm publish failed?

[dceejay]

@tve

@dceejay

we wanted to create sub-groups of widgets (ideally that could be then re-useable/repeated )

Would you mind elaborating?

There were 2 (or 3) inter-related thoughts here.

The main one being could we create "super widgets" out of a small group of widgets - such that they could be re-used... eg a group containing a gauge with text and led - that you "fix" the layout of - but can then re-use multiple times for a whole set of readings from different devices or rooms etc.

Part 2 of that was could this super-widget then be "exported" as a package that could then be re-imported to another flow. IE this is the UI version of subflows.

All this of course would need widgets to be able to be placed in groups - and those groups within other groups as you suggest, so this is the starting point.

[jbudd]

I'm finding this thread too long to digest.
Would it be better to close this single thread and create a new category 'Flexdash' for more, shorter, discussions on this project?

[Paul-Reed]

Just had a quick look at GitHub - flexdash/node-red-flexdash: Node-RED server integration for FlexDash and noticed that the recommended install command has a typo.

[tve]

@Paul-Reed

I don't think that the update is available for users to try @tve

Of course you're right... I pushed to the 'dev' tag and somehow was convinced I had pushed the release. It's done now and changes to:

13 Sep 12:42:43 - [info] Node-RED FlexDash plugin version 0.4.106 
13 Sep 12:42:44 - [info] Node-RED FlexDash version 0.4.106  
13 Sep 12:42:44 - [info] Node-RED FD Core Widgets version 0.4.46 
13 Sep 12:42:46 - [info] FlexDash UI version 0.4.61

Apologies for having wasted your time.

@jbudd

I'm finding this thread too long to digest.

I can sympathize! I'll create new threads for musings and discussions. The issue I'm having is that I can't subscribe to 'threads with "flexdash" in the title' and I don't read all new posts in the forum, so unless someone tags me I may well not see posts. I'll try to open new threads with musings or discussion topics though. I'm open to suggestions!

[Paul-Reed]

@tve

No need to change anything dynamically. If you set iso_prefix to true and precision to 3 you get exactly the behavior you describe

That is working great, and enabled me to remove code from my flow.
It would be great if this action could also be added to the spark-line widget.

Sparkline widget
Is something broken?

It should be `msg.title'
EDIT - just noticed same behaviour in other widgets too

@tve

fix colors (supporting names like purple-darken-4)

Doesn't seem to work in the Sparkline widget.

Also, and I don't know if it's related to 'Spark line not handling 0' problem that I posted above, but.. I've found that if the same (any) number is injected more than once, the Sparkline ignores the input until a different number is injected (which maybe is why 0's are ignored)
(I'm guessing that you are already aware, but just in case you weren't )

[{"id":"e27c736b60e62a81","type":"fd-spark-line","z":"1543d308b342690a","fd_container":"69c2e3f5798c3475","fd_cols":1,"fd_rows":1,"fd_array":false,"fd_array_max":10,"name":"","title":"Test","popup_info":"","value":0,"color":"blue","fill_color":"lime-accent-3","text_color":"red-accent-3","show_value":false,"unit":"","x":465,"y":470,"wires":[]},{"id":"b7038cbfe349e009","type":"inject","z":"1543d308b342690a","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"3","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"330","payloadType":"num","x":330,"y":450,"wires":[["e27c736b60e62a81"]]},{"id":"6b12b28111036b22","type":"inject","z":"1543d308b342690a","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"10","payloadType":"num","x":315,"y":485,"wires":[["e27c736b60e62a81"]]},{"id":"69c2e3f5798c3475","type":"flexdash container","name":"Energy","kind":"StdGrid","fd_children":",43719d5359575f6b,bb113511ea8e41fd,3a60132d9af9f863,862f372b75d35aa4,e27c736b60e62a81","title":"","tab":"fef6c0f6d48841d6","min_cols":"8","max_cols":10,"parent":"","solid":false,"cols":"1","rows":"1"},{"id":"fef6c0f6d48841d6","type":"flexdash tab","name":"Energy","icon":"mdi-home-lightning-bolt-outline","title":"","fd_children":",69c2e3f5798c3475","fd":"e8f5aea52ab49500"}]

Version 0.4.61

[SonoraTechnical]

I'm not getting prompted in Pallette Manager for new versions....

[Paul-Reed]

@SonoraTechnical

I'm not getting prompted in Pallette Manager

I updated using the cli - npm i @flexdash/node-red-flexdash & npm i @flexdash/node-red-fd-corewidgets from within .node-red.
Have you tried refreshing your browser cache?

[SonoraTechnical]

Did all of the above. I am seeing the latest versions now. Thank you Paul-Reed for responding!

[tve]

@Paul-Reed

It should be `msg.title'

I must have looked at this multiple times and not seen it ,

@Paul-Reed

I've found that if the same (any) number is injected more than once

Yes, it's a fundamental problem. Communication with FlexDash is based on mirroring state, and if you send the node the same value multiple times the state doesn't change, so nothing happens.
The fact that the widgets accept a single number (or row in the case of the time-plot) and append that internally to what's being displayed, i.e. to the state, is an anti-pattern. It doesn't work. I didn't really understand this when I wrote the widgets and I haven't fixed it. The fix is to do the append in the node and make the mirroring of the state efficient, i.e. not always retransmit the whole state array.

(An ugly workaround would be to add some insignificant random digits to the value you feed in, such as msg.payload = msg.payload + (Date.now()/1E18) -- I'm ducking now...)

@SonoraTechnical

I'm not getting prompted in Pallette Manager for new versions....

You know, I last did this two weeks ago, you'd think I remember how to do this...
I forgot to go to the flow library and press the "check for updates" button...
It does seem like the flow library auto-updates now?

and I didn't click the "check for updates" button anytime in recent days...
But my palette manager doesn't want to have anything to do with the new version

Yes, I did hit the refresh button. Multiple times. So why does it not want to update to 0.4.46 when that's what's in the flow library?
Go figure and better stay with "npm i @flexdash/node-red-fd-corewidgets". You only need to update the core widgets in any case 'cause they should bring the rest in via dependencies. (Or does one have to use "npm upgrade" to make that happen? Grrr. Too many package managers to remember what each one does!)

[tve]

@jbudd

I'm finding this thread too long to digest.

Hrm, I wanted to edit the very first post of this thread to put a note for new readers there so they know there's not much point in reading the whole thread. But now I can't edit that post anymore... Is this something a forum admin can re-enable? If not, maybe I'll start a fresh thread...

[Paul-Reed]

@tve

It does seem like the flow library auto-updates now?

No, I saw that you had not pressed it so I updated it for you, about 30 minutes or so after you posted that you'd published the correct branch, which would be about 2hrs before @SonoraTechnical posted.
The library was updated almost immediately.

[jbudd]

I did ask the moderators if this should be closed and a whole new category created. I think they'll probably do so if you agree it's a good idea.

[tve]

@Paul-Reed

No, I saw that you had not pressed it so I updated it for you, about 30 minutes or so after you posted that you'd published the correct branch

Hmmmm, I can't make my release automation press that button, but I could make it send you an email so you press the button for me...