Persisted items renaming and InfluxDB v2 migration (copy + delete)

This post is about:

  • Persistence
  • OpenHab 4
  • InfluxDB v2

(There is already a good post about InfluxDB v1.x).

Renaming items is easy…

Contact Foo ...


Contact Bar ...

But if your item was persisted, you have now the old data in a measurement called Foo and the new data in Bar. It will likely break your charts and if you update your charts, the older data will be gone. Time to clean that up.

To get started, I find it convenient to have a Grafana chart open, showing both the OLD and the NEW item id.

So here is an example.
I renamed my DoorSensorOffice_SensorDoor into Office_Door_SensorDoor.
The value is the state so it is either 0 or 1 but it does not matter, it could be a battery level, a temperature, etc… anything.

Here is the graph:

We see the old ata in red and the new data in green.

Reminder: the following applies to InfluxDB v2.x and not InfluxDB v1.x.
My InfluxDB bucket for OpenHAB is called… openhab.

The following FLUX query will copy the old data into the new measurement (while keeping the new data obviously). I am going back 4 years but you can adjust as needed.

from(bucket: "openhab")
    |> range(start: -4y, stop: now())
    |> filter(fn: (r) => r._measurement == "DoorSensorOffice_SensorDoor")
    |> set(key: "_measurement", value: "Office_Door_SensorDoor")
    |> to(bucket: "openhab")

After submitting the query, we can see in InfluxDB:

and grafana confirms the copy: we can see green everywhere and some remains of red :wink:

Now time to clean up. I did not find a FLUX query that can do that strangely but the command line will do.
We will need:

  • an InfluxDB TOKEN with proper rights
  • a MEAS-urement variable
  • 2 dates

Let’s first set store the MEAS value:


We can now run the command from the terminal:

influx delete \
		--start '2020-01-01T00:00:00Z' \
		--stop '2025-01-01T00:00:00Z' \
		--token $TOKEN \
		--bucket openhab \
		--predicate '_measurement="'$MEAS'"'

A refresh in Grafana shows that we did clean things up:

I hope this can help some.

My tip would be: If you rename items, make sure to keep track both OLD and NEW name somewhere. It makes such a migration easier.

1 Like

Thanks for posting! I’ve moved this to Tutorials and Solutions so it’s easier to find. It’s nice to move posts into that category as opposed to out of it.

A link might save some users some work finding that if you have it handy.

I don’t like calling this renaming because that’s not really what’s happening here. In truth what happens is every time a .items file is unloaded, all of the Items in that file get destroyed. When the file is loaded, all the Items in that file get created.

So you are not really renaming an Item here, you are creating a new Item with a different name.

The distinction may seem pedantic but it has real consequences down the line. It also explains why you cannot rename a managed Item. It’s because you cannot change the UID of an entity and the name is the UID for an Item. You have to delete and recreate a managed Item too, just like happens with file based Items.

If a rename were possible, persistence, rules, and everywhere else that references that Item would automatically follow the name change and this tutorial wouldn’t be necessary.

It’s a subtle distinction but it causes lots of confusion and problems for users on the forum.


I have quite a bunch to handle so this script becomes handy:

#!/usr/bin/env bash

# set -e -x



read -r -d '' QUERY << EOQ
from(bucket: "$BUCKET")
    |> range(start: $START, stop: now())
    |> filter(fn: (r) => r._measurement == "$OLD")
    |> set(key: "_measurement", value: "$NEW")
    |> to(bucket: "$BUCKET")

# echo "$QUERY"

COUNT=$(echo "$QUERY" | influx query \
    --token $TOKEN | wc -l)

echo "Record changed: $COUNT"

influx delete \
    --start '2020-01-01T00:00:00Z' \
    --stop '2025-01-01T00:00:00Z' \
    --token $TOKEN \
    --bucket $BUCKET \
    --predicate '_measurement="'$OLD'"'

echo "$OLD deleted"