Using Grafana as Node-Red Dashboard?

For FlexDash I am exploring how to embed grafana in an iframe in FlexDash and started to wonder how it would be to use Grafana as the dashboard for Node-Red... Thoughts:

  • Grafana now uses React, so modern stuff, but it still supports plugins written with AngularJS, does that mean there might be a way to support many ui_template nodes?
  • Grafana supports back-end data sources, which means a server-side plug-in that can talk to new data sources, Node-Red could easily be a data source
  • Using the back-end data sources it becomes quite straight-forward to support data input, i.e., buttons, sliders, etc that capture user input and send messages to some back-end, like node-red
  • The next version has some new real-time push capability over websocket, so not everything has to be based on data source queries
  • Obviously Grafana has a large collection of visualization plugins, so there's a ton to leverage there
  • In the end the model would be very similar to the pub/sub stuff in FlexDash or uibuilder: the user would instantiate a panel plugin in Grafana, say a gauge, then choose the node-red data source, and then select the topic for the data to display, or something similar that can be customized to node-red.
  • In terms of installation, it would be a std Grafana install and then add a node-red "application", which is really a bundling of a data source and some panel plugins.

I've gotten pretty far with FlexDash but I'm wondering what a U-turn would look like... So I dug a bit into what it takes to write a plugin for Grafana... There is a very relevant example: MQTT back-end and panel. It contains a back-end plugin to talk to an MQTT broker and a simple panel with a button to publish a message to the broker.

The big downsides I've encountered:

  • Installing grafana isn't difficult per-se but it's another big software package that needs to be configured and figured out by users, user accounts need to be created, authentication needs to be dealt with, a port needs to be opened, etc
  • To develop a plugin, the amount of boilerplate at every level is staggering, the simple button panel from that example alone consists of a directory of 9 files. Some have very little in them, but it still takes effort to even figure out what that stuff is, what needs to be changed, and what all the magic incantations are.
  • The plugin development docs suck, to be more precise, they don't exist. I've looked at writing a plugin several times over the years and each time turned around when I realized that past the baby-steps tutorial there was nothing more.

I'm still somewhat torn. I'm using Grafana. It's a system that will be around for a long time. Lots of people use it. The UI is well done and stuff like moving and resizing panels works very well (unlike the current NR dash or FlexDash). Even if the start-up cost to writing plugins is high, it's bound to amortize over the years. But I can't imagine the average NR ui_template hacker to come even close to a Grafana plug-in. Looking at the plugins available for Grafana, the majority consists of data sources written by vendors who want to make sure grafana can connect to their product. The number of panel (UI) plugins is actually not that big considering how wide-spread Grafana is, and my experience has been that most of the 3rd party plugins are of very low quality, i.e. break unless you feed them exactly the data the author did. I think this is an indication of how difficult, or rather obscure it is to write plugins. Frustrating...

Has anyone else explored the above?

Another issue with grafana is the fact that it keeps changing. I believe the plugin API changed recently so old plugins no longer work, for example. I was using the original MQTT plugin which stopped working. How long the one you linked to will keep working who knows. Also Grafana is opinionated in terms of browser usage. It complains when I use Waterfox for example.
The documentation is lamentably lacking or out of date, both for development and user docs. The forum is hopeless, both for user help and developers.
I think it is heavy in terms of run-time resources too, though I can't put a figure on that. I would really like a dashboard solution that is lighter than the current dashboard, rather than heavier, so that it opens quicker in mobile devices, for example.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.