But are you actually using it in dashboard 2.0 ? It seems like it is literal a copy of 1.0 - I was hoping that it would actually modernize (not just the tech behind it) - the massive paddings (none seem equal), fontsizes, hardcoded widths/heights are all still there, in this day and age of tailwind and modern css techniques this is not needed me thinks (I assume this is all related to the layout editor? ). There is a lot of inefficient screen real estate with dashboard, which is unfortunate. I hope that 2.0 brings something new and useful to the table.
Yes we mainly use Node-RED dashboard for data visualization (large amount of data).
Users can zoom in to see data details. Usually with tens of thousands data points in a chart.
So efficiency and chart speed are critical. There are also many features required for the charts.
An example of the vibration data FFT analysis chart is as the following:
Currently we use UI template from Dashboard 1.0 and 3rd party chart tool (Echarts and Plotly) for the chart function. It will be great that Dashboard V2.0 can support UI template with minimum modification.
2 Likes
I can assure you that we are. Pretty much every widget we have uses Vuetify, as does our Base UI Layout for sidebar, navigation, etc.
It will look similiar to Dashboard 1.0 because Vuetify is based on Material Design, as was Dashboard 1.0's dependency, AngularMD.
I have investigated (very briefly at the moment) the use of Tailwind, or at least, the flexibility for users to inject their own Tailwind to control layouts, etc.
The complexity here is in how Tailwind compiles. It will scan your code at build-time, and then generates CSS files based on the classes that you've actually used (given that there are too many classes available in core Tailwind to just include them all). With Node-RED, users would define these classes at runtime, and so Tailwind would have no context of what classes it should make available in the build.
It's definitely on our radar though, as I'm an avid user of Tailwind, and we use it in our product and website at FlowFuse too.
One of the first big changes I made when starting Dashboard 2.0 was the removal of a hardcoded layout. Instead, I introduced the concept of a "Layout Manager" (we have 3 so far) that can be assigned to a page to control how, given a list of groups/widgets, they're positioned on screen. Our "Flex" layout is the equivalent of how Dashboard 1.0 defines layout. Our "Grid" layout (which I will likely rename) is equivalent of Bootstraps Column layout, whereby all content will adapt to screen size with (default) 12 columns available.
This architecture means we can introduce more layouts as we evolve, and is definitely something we plan to do. Ideally l, we would have a drag/drop style layout builder too, but as @tve will atest to, this is by no means a trivial feat.
My ultimate plan is that, in the same way we support third party widgets, we can also support user's own third party layouts too.
This is a pattern I have seen and hesrd of a lot, but havent been able to dive into flows that do this. Would love to be able to talk through with you what the user experience for you was like to set this up, and understand what we can do in Dashboard 2.0 to assist.
If you're open to chat would be great if you could put 30 mins into my calendar please: Calendly - Joe Pavitt
(Will also point out that offer is open to anyone else that would like to chat on this in more detail too)
This wont be a seamless transition due to the underlying technology changes, but am planning on writing migration guides, and understanding the most common community uses of ui-template to ensure we've taken as much as possible into account
1 Like
It depends how you use it i guess. I mean, looking at dashboard 2.0 - intial pageload is 5+ MB(!?) - sending the whole vuetify thing + all of its required css classes - which is 800KB (this is nuts lol). I am using the CDN javascript version of tailwind (locally stored), which is Ā±100KB, includes everything needed, renders using JIT, sure not optimal, but one will never notice, pack this together with alpinejs (which borrowed a lot from vue, but way simpler to implement) for about 7KB gzipped and you have a massive powerhouse. But ok that was not my point - I am just hoping for better screen layout and sensible design choices using a design system and not heavily opinionated components with bad fonts like roboto :')
Appreciate the feedback. As mentioned, Vuetify uses Material Design, which is built with Roboto Font, so thats going to be sticking around.
You can always override the font using the ui-template node to define new CSS.
The opinionated components will also likely stay. As mentioned above, there is no one-size fits all Dashboard solution. Dashboard 1 (and hopefully Dashboard 2's) role is generally fitting in the plug and play Dashboard, with customisation should you require it. For that to be the case, we need a collection of pre-styled widgets.
Thanks for the insight, will definitely give this another look.
We are also very encouraging of community PRs if you'd like work on new layouts, integrating Tailwind, or anything else you can think of!
@joepavitt Thank you very much! Scheduled meeting and talk to you soon.
@bakman2 Yes agree with you that efficiency, and program size (load time) is important
It is indeed quite critical, especially for mobile devices. However, the use of a large framework is always going to come with a significant overhead. One of several reasons that I ditched using them some while back. Though admittedly, I'm not writing large, complex web apps on a daily basis so perhaps a little different for me.
Load size is only one aspect though of course. Equally important is the time from network load to UI available.
I actually started pushing all the data to a MySQL database instead of using global context or MQTT as an interface between data gathering and the dashboard. This makes the data easily accessible to other kinds of visualization (regular websites, apps, etc) and/or integration with SAP/ERP systems.
How do you display dynamic data when it's stored in a database? I assume your dashboard would be populated once upon the browser connection, but what if the data stream was constantly changing, how do you update your dashboard widgets with the current data?
Are you querying the data every 'x' seconds.
1 Like
First of all, you need to gather the data and write it to the DB for each machine (but only if there have been changes).
On your DB you will need to add a column to specify in which tab of the dashboard you'll be showing that data, and another column (updated_on) that gets updated with CURRENT_TIMESTAMP() every time you modify the data on the row. For the raw data machine, I recommend to use a JSON type column and directly store the normalised object, so it'll be easier to display.
On Node-Red, add an inject node that creates queries every certain time, but only for the rows that are relevant to the current tab of the dashboard, and from those, only the ones that were updated since the last time you read the data (which means they have new values). This reduces the overhead a lot, and also allows you to query quite often (every 500 ms if you want, since you'll only get results if there's any new information to display).
If you use a regular website, you can use JQuery or similar to poll the database in a similar manner.
Doing polling of a database even with optimisations is far from ideal, especially since you are already in an event-driven environment. As described, I don't think it really helps where you have multiple dashboard users or even multiple dashboard displays that might be on different tabs.
Even if you wish to cache data for other purposes, using flows to dynamically update your front-end(s) is generally going to be better all round.
In my recent example producing an MQTT monitor for example, I wanted to accumulate all subscribed MQTT topics in Node-RED so that new instances of the dashboard (which uses UIBUILDER) would get both current and historic data. So on connection, the new page gets a full copy. But since that can be a very significant amount of data, I don't want to have to grab the latest changes every few seconds. Instead, I also pass through each update and the front-end accumulates the data there as well.
So a full refresh is only needed if the page is reloaded or if it has been offline for a while (e.g. the tab or PC was sleeping).
The point is that currently I'm using Dashboard to display information, but in the long run, we won't. The idea is to integrate the data into our SAP/ERP system, that also stores information about our stocks and should benefit from tracking the batches that are in production, as well as having feedback on the current production status. It also has advanced analytics tools, which aren't present in NR.
SAP has modules to interface with OPC/UA and MySQL, and it has other modules for advanced user interfaces that include analytics/tracking. Down the road, the idea is having node-red exclusively on the data gathering part, and feed everything into the database, and let SAP do the rest.
1 Like
You might want to take a look at surrealdb - it has features like direct websockets with live queries - which means:
- user A updates a record
- user B has a live query running with a websocket and the update gets instantly pushed over the websocket, it is truly nuts and awesome.
1 Like
eagerly waiting for this.....
Thanks for the nudge, it got a little delayed after a few notable bugs were raised and I've had to prioritise.
I still have 1 more of those to go linked with ui-template, but this is then my next priority ahead of my webinar next week
1 Like
After looking into it, yes, it turns out there are several websocket servers that can handle push notifications by using the callback from the MySQL DB too.
In my case, I may have (at most) half a dozen concurrent users (pushing it, about a dozen), so it is not so critical. And once it's integrated with SAP, the system will handle dynamic updates, historical data, and analytics.
In the mean time, I'll keep using Dashboard.
