Feature request: Auto use dashboard variables as querystring.

[gdassori]

Hello, to begin I must say thanks for your work: the plugin is exactly was I was looking for. Really, thank you 👍

Now a request, or maybe an hint, if this can be done already: I'd like to use, as mentioned in the subject, all the variables defined in the dashboard as QueryString parameters of a specific query to the JSON Datasource, without declaring all the var:$var, var2:$var2 verbose key:val pairing. Any way to do that or any interest by you in supporting that?

Thanks!

[marcusolsson]

Thanks for the kind words! ❤️

We could introduce a macro, $__variableParams, that expands to a query string for the Path tab, but I don't want to promote passing a query string in the Path field. I'd much rather use the Params tab for this.

We could add a switch/check box to the Params tab—"Include dashboard variables" or something—that would add the dashboard variables to the UI, but disable the fields. That way you could see what's actually being passed as well. WDYT?

[gdassori]

The "include dashboard variables" check would definitely solve the issue in my use case.

[AgentBignose]

Dear Marcus,

thx so much for this excellent Plugin! For me its a game changer because it turned grafana from a Historian DB visualization tool to a dynmaic API visualization tool.

I even visualize some of grafanas own api inforamtion in grafana panels using your plugin (annotation list for instance).

Now i'd like to elaborate on a use case where dashboard vars as query params would be super helpful, but in a slightly different way then before mentioned:

We use grafana in production plants to analyse prcess data collected by mqtt-telegraf-influx.
Yet there is lots of legacy systems which are not supported by grafana and it's not acceptable to duplicate all data. SCADA systems with their historians are a good example for this. But also MongoDB with quality data.

This is where you plugin comes so handy! Often I use node-red to connect to the douzends of differnt protocols and extract data by call, I then have node-red serve an http api with http auth node and bearer auth. This I consume with your plugin.

I have to tell the node-red api what timespan I need - here the new experimental features are super helpful and already solve one of my problems.
And I also have to have the user tell in query editor which tag of the production he is interested in.
I do this over query Params:

Howerver my useres are used to have a convenient drop down to select auto populated and searchable tag values from working with influx. They are not able to manually enter the query param strings with the tagnames.

What would be awesome:
Have Key field not as a normal input, but as a combobox populated with dash vars.
In dashvars I could again use your plugin to make a query var and have an node-red api fill it with all known tag names.
Have value Input would also be a combobox, populated with the value list of my dashboard var.

This way I would be able to give the "influx db editor experience" with any SCADA database or other data source.
I think it gues fully inline with the idea of IoT to combine the strength of a set of differnt tools with open interfaces!

Do you think you could implement such a feature? Anyhow I could help? Unfortunately I am not a web developer :-(

[marcusolsson]

Thanks @AgentBignose for the kind words, and for the detailed feature request ❤️

I like the idea! Unfortunately, afaik plugins can't query the full set of values for a variables (only the currently selected ones), which would make this rather difficult to implement.

I guess the reason why you can't use a top-level dashboard variable as is, is because you want to change it for each panel?

[AgentBignose]

Hi @marcusolsson ,

thx for your instant reply!

afaik plugins can't query the full set of values for a variables

Yes that limitation really is unfortunate.

(only the currently selected ones)

Hm, so if I'd had a single query var but holding an array of the possible TAGNAMES returned by my meta-api and have this var selected in the dash it could work?
It would be so elegant to utilize the query var feature with all its nice candy such as json-path etc.
If the editor would have to query the TAGNAME collection itself, it would again need backend call instead of client side I guess and setting up, handling credentials etc.
If one would add such a meta-api in datasource editor, it would also mean a lot of implementation, ui, concept etc.

I think today it's really important to have things dynamically connected. There is lots of potential for grafana.
Another (off topic) example for this is the lack of dynamic thresholds just because grafana ist number parsing the Inputfield of threshold, thus disabling variable use. :-( and not addressed long time even though there are PRs.

I guess the reason why you can't use a top-level dashboard variable as is, is because you want to change it for each panel?

Yes, Exactly

[marcusolsson]

so if I'd had a single query var but holding an array of the possible TAGNAMES returned by my meta-api and have this var selected in the dash it could work?

Yes, but I think not many data sources in Grafana would let you return a JSON array, and we'd have to somehow tell the JSON plugin to parse the value as an array.

Another alternative would be to have a drop-down where you could select from the selected values in a variable. You could then create a Multi-value variable with "Include all" selected to achieve the same thing?

Another challenge is how the plugin would know that TAGNAMES refer to a dashboard variable. In your example, you have a separate tab for this, but I'd like to integrate this in the key value component, so that it could be used with both params and headers.