How can I avoid units like kWh to be changed to MWh with Grafana V12

Grafana Dashboards
1

Grafana V12
I have set Unit to kWh, but it displays as MWh (over 1000 kWh)
I like to have the unit displayed but not changed
Older tips e.g. misc/none are not available anymore

2

welcome @hansge31 to the community
When you select Energy → Kilowatt-hour (kWh) from the unit dropdown, Grafana automatically scales values above 1000 kWh to MWh.

Screenshot (369)
Screenshot (369)1920×896 182 KB

Instead of selecting kWh from the energy category, type kwh directly as a custom unit string in the Unit field. Grafana treats it as plain text suffix and never auto scales it.
Steps
Open panel editor → Standard options → Unit
Clear the current unit
Type kwh directly (do not select from dropdown)
Set Decimals to 2
Click Apply

Screenshot (371)
Screenshot (371)1920×894 176 KB

Grafana only auto scales units it recognises from its built in unit system. A custom text unit like kwh is treated as a plain label and no scaling logic is applied.

3

Hello Shanker, thank you for your perfect and detailed answer. I really appreciate it. I have another question in this area. I have Grafana V12 and Influxdb 1.
For the regular reporting I try to create a panel, where only the 1st enrty per month is listed for the various database entries.
I tried with various options from copilot but all failed:
SELECT first(“value”)
FROM “REE-PV-Zählerstand-Einspeisung”
WHERE $timeFilter
GROUP BY time(31d)

4

On InfluxDB 1.8.10 GROUP BY time(1mo) returns invalid duration. Using GROUP BY time(30d) or time(31d) creates fixed-duration buckets rather than real calendar months, and the returned timestamps differ depending on the bucket size.

Screenshot (383)
Screenshot (383)1920×913 147 KB

I verified this by comparing time(30d) and time(31d) and observing different bucket timestamps. Therefore, InfluxQL 1.x does not provide native calendar-month grouping, so it cannot reliably return the first value of each calendar month. For exact monthly reporting, you would need a solution outside standard InfluxQL grouping, such as Flux, pre-aggregated monthly data .

Screenshot (386)
Screenshot (386)1920×900 149 KB

Table view for GROUP BY time(30d) showing bucket timestamps (2023-12-19, 2024-01-18), demonstrating fixed-duration windows rather than calendar-month boundaries.
Screenshot (387)
Screenshot (387)1920×906 148 KB

5

Hi Shanker,

thank you so much for your inestigation and testing.
I will follow your proposal and see how flux can help to achieve the goal.

Best Regards,

Hans-Georg

6

Hi Shanker,

I upgraded now to InfluxDB 2.9 and Flux
Now I tried again, to get the value in the first day of the month, first hour
The result is “2026-06-01 02:00:00” so not midnight but 2 a.m.
Copilot does not really help to get it corrected, do you have any idea?

7

Here is the current query:

import "date"
from(bucket: "iobroker2")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r.\_measurement == "REE-PV-Zählerstand-Einspeisung")
  |> filter(fn: (r) => r.\_field == "value")
  |> aggregateWindow(every: 1h, fn: mean, createEmpty: true)   // <- FIX!
  |> fill(usePrevious: true)
  |> filter(fn: (r) =>
      date.monthDay(t: r.\_time) == 1 and
      date.hour(t: r.\_time) == 0
  )
  |> set(key: "\_field", value: "REE-PV-Einspeisung")
  |> set(key: "\_measurement", value: "")
8

The 2:00 AM result is a timezone offset issue. Flux processes all timestamps in UTC by default. Since you are in CEST (UTC+2) in June, what is midnight local time appears as 22:00 UTC the previous day. So filtering for hour == 0 in UTC never aligns with your local midnight.

Testing on InfluxDB 2.x + Grafana V13 using real continuous stream data:

Initially → the query returned:

Screenshot (532)
Screenshot (532)1920×915 172 KB

Time Result
2024-02-01 01:00:00 wrong (CET = UTC+1)
2024-03-01 01:00:00 wrong (CET = UTC+1)
2024-04-01 02:00:00 wrong (CEST = UTC+2)

With the fix — the query returned:

Screenshot (533)
Screenshot (533)1920×912 171 KB

Time Result
2024-02-01 00:00:00 correct
2024-03-01 00:00:00 correct
2024-04-01 00:00:00 correct

Here is the corrected query:

flux

import "date"
import "timezone"

from(bucket: "iobroker2")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r._measurement == "REE-PV-Zählerstand-Einspeisung")
  |> filter(fn: (r) => r._field == "value")
  |> aggregateWindow(every: 1h, fn: mean, createEmpty: true)
  |> fill(usePrevious: true)
  |> filter(fn: (r) =>
      date.monthDay(t: r._time, location: timezone.location(name: "Europe/Berlin")) == 1 and
      date.hour(t: r._time, location: timezone.location(name: "Europe/Berlin")) == 0
  )
  |> set(key: "_field", value: "REE-PV-Einspeisung")
  |> set(key: "_measurement", value: "")
  1. Added import "timezone" at the top
  2. Added location: timezone.location(name: "Europe/Berlin") to both date.monthDay() and date.hour() calls

This tells Flux to evaluate the day and hour in Europe/Berlin time instead of UTC. It automatically handles both CET (UTC+1) in winter and CEST (UTC+2) in summer, so you will always get the correct first entry at local midnight on the 1st of each month → no matter the time of year.

9

@infofcc3 this “fix” smells a bit off to me. Does this account for daylight savings transitions?

Can you add a test harness with mock data for every day of the month for a whole year and does it work for daylight savings months?

10

Hi Shanker,

Thank you very much for your support.

As I have Influx b and Grafana on Windows, the timezones approach is not directly working.

I tried to download and add an env. variable for it but failed as well.

I’ll see what works.