Could I trouble you to raise an issue Paul (and link back too)?
As far I understand, configuration for chart options is not yet available so fixing this one issue maybe is not right thing to do. Defaults don't work on all possible situations. Best results do require fine turning.
To provide good enough amount of easy to use configuration options will be challenging enough. Nobody likes overcrowded config pages. But what would make it really powerful is to have full access for all of it. Not like D1 currently has. Almost all but when it does require chart object reference those are not configurable.
Looks like it would be some option like line-butt or join or something that defines how two thick lines intersect.
Maybe borderjoinstyle ? Interface: LineOptions | Chart.js
The default is mitre... maybe 'round' or 'bevel' would resolve...
An update for you all. v0.5.0 was released this morning with some new goodies - see the release nodes for more info: Release v0.5.0 · flowforge/flowforge-nr-dashboard · GitHub
Interesting but it seems to crash my browser! Or at least the Dashboard 2 & Editor pages anyway.
THe 2nd of those is my Dashboard 2 page
Massive memory leak to go with the CPU hitting 15-20%
Got up to >2GB before I killed it manually!!
Thanks for the feedback Julian
Thanks Julian. Did you have any particular widgets configured for the page at all? Or was this a purely empty Dashboard Instance?
This is the config:
I do have both the old and new Dashboards installed if that makes a difference. I didn't get a chance to trigger the input to the template node.
Couple of other things about the new Dash.
Might be helpful to slightly change the colour of the nodes so that they are more easily differentiated from the old
There are still some places in the code that don't take account of the
httpNodeRootsetting. Both the link in the sidebar and the link show in startup.
0|Node-RED | 15 Sep 20:04:56 - [info] [ui-base:Dash3] Node-RED Dashboard 2.0 (v0.5.0) started at /dashboard 0|Node-RED | 15 Sep 20:04:56 - [info] [ui-base:Dash3] Created socket.io server bound to Node-RED port at path /nr/dashboard/socket.io
- The link in the group node doesn't do anything.
With Node-RED's standard dashboard I accomplished the following UI, mainly for use on mobile devices:
In order to achieve this I extensively use html-tags to format both, label and value. Are you planing to enable html-tagging in the future as well?
Do you mean html elements in the html template node?
No. I am using standard nodes (switch, text, etc.).
Here is how I format values f.e. for a text node.
And here is how I set the label f.e. for a switch node. Two lines, where msg.pollen and msg.pm25 values are formatted as well (green, yellow, red), depending on their values. (see bottom of the first screenshot in my post above)
That would indeed be useful.
Not sure if this has been discussed already, but I would find it very helpful if the new ui nodes would end up in a separate V2 category:
To make it clear which ui nodes are available for V1 and V2.
So I deleted all of my previous setup for Dashboard v2 and started from scratch. It now works.
I have to say though, finding and removing everything was not easy. I did it from the sidebar but that didn't actually clear everything. I had to go to the Info sidebar, global and find the entries in there and delete them separately. Deleting them from the Dashboard 2 sidebar removed them from the sidebar but did not actually delete.
On a clean install of Node-RED v3.1 and the latest Dashboard beta. I added a single text node to a single group on a single page and deployed. Then I deleted the flow and re-deployed which gave me the expected unused nodes warning for the config nodes. Then I deleted what I could via the Dashboard 2 sidebar and re-deployed. No warnings now. Checked the info sidebar which shows this:
With the consequence that the Dashboard nodes cannot be uninstalled via the palette manager because something is still in use. Once I removed those config nodes manually, the Dashboard Node could be removed via the palette manager.
Oh, another oddity. The link to the Dashboard page from the sidebar now works. BUT the Dashboard is on the wrong path. It ignores the
httpNodeRoot setting completely now. This is dangerous since it could now clash with other web endpoints defined on that device. Worse still, if I try to access via the correct path, the dashboard reloads on
And even worse, once redirected, if you then try to reload the page, it fails!
Manually go back to where it should be and you are redirected again but it works:
Until you reload the page again.
nr (I'm assuming all other settings are default). Now access the old dashboard on
http://localhost:1880/nr/ui which is correct. Try to access
http://localhost:1880/nr/dashboard and you are redirected to
http://localhost:1880/dashboard. The Dashboard 2 sidebar opens
Please make sure that the new Dashboard uses the
Thanks Julian. I'm not sure I recall adding delete functionality to the sidebar, how are you deleting the entries there?
Regarding the difficulty over removing, Im assuming, based on what you've described, and my own experiences, the primary complexity/pain here is the config nodes?
Please make sure that the new Dashboard uses the
We have every intention to, this is broken in error, not by intention.
We are also open to PRs too btw, I know you're well versed with Vue, and obviously Node-RED, so any contributions you'd like to make are most welcome.
Thanks for the suggestion Bart. It was raised as a GH issue, and is definitely something we plan on getting in very soon.
@jodelkoenig thanks for the insight into how tou used Dashboard 1.0
I hadn't considered this use case, and wasnt even aware D1.0 supported it.
We are constrained a little by the Vuetify Framework that we are using for most of the Widgets in D2.0.
Could I trouble you to raise an issue on the GH repo please? Happy to take a look and see what we can do.
I'm curious actually if this is a core Node-RED issue? Any set of nodes that use condig nodes would have the same problem?
A prompt at the point of uninstalling that checked if only config nodes were present in the flows, and asked user if they wanted to remove all of them feels a cleaner workflow here?