No, I missed it, but I agree with your comment for what I've experienced. Nevertheless, I'm still convinced that a well studied node-red / Grafana interaction would bring the benefit of a powerfully usage of the best of each environment.
Node-red provides the flexibility, one can make their own dashboards with the http-in/out nodes, node-red-dashboard, uibuilder or any other form. I use grafana extensively but also the other options mentioned.
However, Grafana, in my case, purely relies on the database (influx and json), which is not necessarily related to node-red as you can feed data by other means. It is a stand-alone application that uses datasources to represent the data. "Interaction" is only available to the visualisation/dashboard itself and not to other applications.
I would highly recommend to move your data over to influx as Grafana is used for time series data and Influx is geared towards this type of data. Which makes it much faster and efficient than an all-purpose RDBMS.
Grafana does have the capability of showing live data too (via MQTT for example). If it had capabilities as sophisticated as the node red dashboard then it would be a viable alternative, with the advantage that it has sophisticated multi-user capabilities, which the node-red dashboard does not. In addition, if one wants the charting features of Grafana as well as a real-time dashboard then this would mean there was only one ui to manage. Currently to achieve that one has to either keep the two UIs separate or embed one within the other which is possible but not ideal.
Whether Grafana will every have the ability to easily construct a dashboard with the sophistication of the node-red dashboard I don't know.
1 Like
You're right, but this is more like a workaround since node-red dosen't born for this. For what I've seen on what you've pointed out, that requires a very good knowledge of other languages (php, java script, etc). And who can do that, rather build a more dedicated solution
But you need to store this value in a DB as well? or not?
For the rest, that's why I'm thinking of having Grafana on a server with a public IP, and node-red locally, where very often, in my situation at least, you have private IP under nat, so not reachable from outside.
Honestly I like the way node-red acts, its simplicity even if so incredibly powerful, and reading the forum I understand why it's single tenant 
In my opinion Grafana and node-red born for different scope and for reaching different goals. I don't see any competition, as well as I don't believe neither of them will integrate the each other's capabilities. It's better for all of us that they just continue to improve what they're born for
Assuming you are talking about node-red-dashboard then no, uibuilder, for example, is not a workaround to get around the limitations of node-red-dashboard. node-red-dashboard is a simple and easy to use UI addon to node-red, uibuilder is another UI addon to node-red, that is much more flexible, but not so simple to use. They fulfil different requirements.
No. Did you see the MQTT plugin linked from the other thread I posted? GitHub - s-torneo/mqtt-grafana-backend-panel-plugins: A panel plugin and a datasource backend plugin to work with MQTT in Grafana..
In that case I have absolutely no idea what this thread is about. In particular I don't know what you meant, in your initial question, when you said
Thanks I'll take a look at it
For uibuilder, yes I know it and it's absolutely not easy to use without other advanced languages competencies (for me at least)
Correct, but it is not a workaround, it is an alternative.
Maybe, I' m not able to say.
This is for what I have seen, for what I tried with it (knowing I'm not so expert on these others programming languages) and even reading other users experience. At the end node-red give a big hand to build powerful program even to who have other skills than web programming.
If I'm not wrong with the ui_builder you have to write more or ess the full code (or at least quite a while) of the front end. This is what I understand even from other users that at the end, having this skill, for complex situation prefer to find other solution.
But I repeat, absolutely I'm not able to say more, and probably looking at it from your knowledge point of view you're right, and it could be much more easier than what we see.
Yes, you are right. For those with limited web programming skills node-red-dashboard provides an easy to use, but restricted capabilities, dashboard. If the capabilities are not sufficient for a particular use then the alternative is to use something more configurable like uibuilder. This is one of the facts of life which applies to software just as it applies to kitchen cupboards. If you want something quick and easy to use there is an off-the-shelf solution. If you need something with extra features than that then you can build it yourself, but that requires different skills.
Yet ... 
Well, if you can build a spreadsheet with formulae, you can build a simple, data-driven UI with uibuilder. But you are talking about a number of additional capabilities:
- Multi-user - I'm "working" on that (well I'm not but I will again when I get more time).
- High performance charts from a variety of data sources. If node-red provides the data (which it easily can) then we need some standard chart components for VueJS. I created some examples but more work is needed.
- An interactive DB query builder - well that is a looooong way past my skill level and available time I'm afraid.
So there is hope for uibuilder yet 
Well, you have to write some code, certainly. But the roadmap has ideas for resolving some of that and making it so that it isn't much harder than taking the template and adding a couple of components to get a layout then sending it data in a standard format.
I'm also planning on adding a feature so that anyone can create full-featured templates that you can install direct from GitHub so even the template part could be dealt with by someone else.
Not there yet though of course. And this time of year is not good for developing code - at least for me - since family commitments and exercise take preference in the summer months.
I think that we will see both alternative solutions and improvements to uibuilder to start to close that gap during this year.
Unfortunately, unless other people step up with programming support, everyone will need to be patient. What you've described is certainly the current situation.
1 Like
Thanks Colin and Julian for all the clarifications. As soon as I can I will spend some times to go deeper with ui_builder, for what you say it's worth it.
Thanks so much
1 Like
thanks for the advice
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
