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
- 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?