Variable evaluation fails when expression added

Grafana InfluxDB
1

  • What Grafana version and what operating system are you using?
    [v10.1.9]

  • What are you trying to achieve?
    An InfluxDB query with a math operation that involves a variable with a decimal point

  • What happened?
    the decimal point is preceded by inserted two back slashes

  • What did you expect to happen?
    not to insert the two back slahes

  • Can you copy/paste the configuration(s) that you are having problems with?

Desired InfluxDB query where $consthousesizem2 is 2744.59:
SELECT sum(“jednotky”)/$consthousesizem2 as dumm2 FROM (SELECT spread(“value”) as jednotky FROM “teplo_kWh” WHERE $timeFilter GROUP BY “unit”::tag fill(null))

Correct query variable evaluation when no expression is involved:
q:“SELECT sum("jednotky")/2744.59 as dumm2 FROM (SELECT spread("value") as jednotky FROM "teplo_kWh" WHERE time >= now() - 30d and time <= now() GROUP BY "unit"::tag fill(null))”

image
image2576×476 38.4 KB

Failing query variable evaluation when an expression is added (variable decimal point with two back slahes):
query:“SELECT sum("jednotky")/2744\\.59 as dumm2 FROM (SELECT spread("value") as jednotky FROM "teplo_kWh" WHERE $timeFilter GROUP BY "unit"::tag fill(null))”

image
image2572×706 51 KB

If this is already solved, sorry for disturbing you :slight_smile:

2

What is a point of that expression? Just $A doesn’t make any sense to me?

3

The expression shows that if it exists then the query is not working any more. In other words its existence breaks the query (breaks the variable evaluation)

Just $A does not make any sense - just keeping it as simple as possible

4

My wild guess is when Grafana sees the variable with a floating-point value (2744.59) being used in the query, it likely anticipates potential issues with the period being interpreted as a regex wildcard. To prevent this, it automatically adds a backslash to escape the period. However, since the backslash itself is a special character in many contexts (including string formatting), Grafana adds another backslash to escape the first one. This results in the double backslash (\\.) you’re seeing.

The above syntax might have to be changed to something like:

"consthousesizem2"::tag =~ /^$consthousesizem2$/)
5

Thanks for the guess, but the above syntax cannot be changed as you propose. The $consthousesizem2 variable is not a tag here. It is just a number for a math operation. The strange thing is that it works until a new Expression is added (see the pictures).