I’ve got a page with a map with my locations, which I really only use to check whether openHAB is aware of the fact that I’m not home. But with the holidays approaching, I though it would be fun to be able to “go back in time” with my locations. Something like this:
And I was wondering whether anyone had figured something similar out for openHAB. No use in reinventing the wheel, right? 
Depending on how robust you want this to be, something like Reitti and a webview on your sitemap/MainUI might give you a better overall experience.
Doing it all with native OH capabilities is going to be complicated, brittle and ultimately not provide a smooth end user experience. But there are a couple of approaches discussed in that thread. If you want to draw lines on the map you’ll need to use Google Maps and a rule and a custom HTML file. If you just want markers, you’ll need to create Items for each marker so you can show the last N locations and a rule to maintain the marker Items.
I’ve often wished the OH map capability were more robust.
In any case, I need to figure out how to get previous coordinates. And as always, I struggle with this persistence…
var locationitem = items.getItem("DBE_OwnTracks__Locatie");
var previouslocation = locationitem.previousState;
var hudigelocation = locationitem.state;
console.log("previous location = " + previouslocation);
console.log("current location = " + hudigelocation);
var daybeforeyesterday = time.toZDT('08:00').minusDays(2);
console.log("daybeforeyesterday = " + daybeforeyesterday);
var daybeforeyesterdaylocation = locationitem.persistence.persistedState(daybeforeyesterday, "mapdb").state;
var numberoflocationssincedaybeforeyesterday = locationitem.persistence.getAllStatesSince(daybeforeyesterday, "mapdb");
console.log("location daybeforeyesterday = " + daybeforeyesterdaylocation);
console.log("number of locations since daybeforeyesterday = " + numberoflocationssincedaybeforeyesterday);
Output
17:04:44.828 [INFO ] [utomation.jsscripting.rule.scratchpad] - previous location = [REDACTED LOCATION, WHERE I'M NOT AT THE MOMENT]
17:04:44.828 [INFO ] [utomation.jsscripting.rule.scratchpad] - current location = [REDACTED LOCATION, WHERE I AM AT THE MOMENT]
17:04:44.832 [INFO ] [utomation.jsscripting.rule.scratchpad] - daybeforeyesterday = 2026-06-16T08:00+02:00[Europe/Brussels]
17:04:44.833 [INFO ] [utomation.jsscripting.rule.scratchpad] - location daybeforeyesterday = [REDACTED LOCATION, WHERE I AM AT THE MOMENT]
17:04:44.834 [INFO ] [utomation.jsscripting.rule.scratchpad] - number of locations since daybeforeyesterday = PersistedItem (Timestamp=2026-06-18T13:41:07+02:00[Europe/Brussels], State=[REDACTED LOCATION, WHERE I AM AT THE MOMENT])
The problem is that I most certainly was not at my present location at 8h00 on 16/06…
mpdb only saves one value. There is no history in mapdb. The value stored in mapdb is almost always going to be the Item’s current state. MapDB doesn’t have any other information.
The docs should make this clear.
The **MapDB (opens new window)**persistence service is based on a simple key-value store that only saves the last value. MapDB is useful for restoring items that have the
restoreOnStartupstrategy because other persistence options have some drawbacks if only the last value is needed on restarts.Some disadvantages of other persistence services compared to MapDB are that they:
- grow in time
- require complex installs (
influxdb,jdbc,jpa)rrd4jcannot store all item types (only numeric types)It is only possible to query the last value and not other historic values because the MapDB persistence service can only store one value per item.
Bolding is mine.
You can’t query MapDB for your location yesterday becuase it doesn’t have it. It only knows your current location and that’s what it gives you.
Persistence need not be a struggle.
At a the highest level, persistence is a log consisting of a timestamp and an Item’s state. If you were to print one out for a Switch it might look something like:
| Timestamp | State |
|---|---|
| 1781710620000 | “OFF” |
| 1781710680000 | “ON” |
| 1781710800000 | “OFF” |
That’s it. That’s all persistence is. A log of timestamps and states indicating that at that timestamp the Item was in that state.
This log gets saved in a special format to make both storage and retrieval of the data effecient. And there is special software used to read and write to this special format. Those are the persistence add-ons.
There are more than one persistence add-ons because there are advantages and disadvantages to each one. Some require installation of an external software service (e.g. InfluxDB), others manipulate the data over time (rrd4j decimates the data as it ages in order to maintain a fixed size), do not support all Item types (rrd4j only supports numbers and numeric Item types), and others have other limitations (e.g. MapDB only saves one entry).
Not all persistence add-ons are suitable for all purposes. You can’t draw a chart with MapDB. You can’t store a Location Item in rrd4j. You have to perform maintenance on databases that grow forever to keep them from filling up your disk.
Depending on what you need, you must set up a suitable persistence for that purpose. You will likely need more than one as no one persistice is best at everything.
You have a Location Item. You can’t use rrd4j because rrd4j doesn’t support it. You can’t use MapDB because it only saves one value. So you must use something else to save the history for these Items. I’d recommend SQLite unless you think at some future date you might want to analyze your historic data using external tools. If so, InfluxDB, MariaDB, or PostgreSQL would be my recommendation depending what external tools you want to use for analysis (I know that InfluxDB is installable through openHABian).
When you configure the persistence, a good approach is:
However, be aware that having the location values stored in persistence won’t help you put them on a map in MainUI. The MainUI map widgets have no access to persistence data. They might help with a rule to populate Items put on the map though.
I don’t think I’ll do crazy analyses. But I might dive into that Reitti rabbit hole you suggested. Would that be able to work with data from SQLite? I don’t know how to interpret the section Data Import & Integration of its readme. I see a few JSON mentions, but is that enough?
No, what ever you are using to report locations to openHAB will need to report locations to Reitti instead or in addition (OwnTracks, GPS Tracker, etc).
Reitti is a wholly separate service which knows nothing of openHAB.
And the whole point of an embedded database like SQLite is that it’s private to the service that’s hosting it. Only openHAB can see and use the data in it’s own SQLite database.
Not quite what you asked for, but you could use openHAB and its cloud as a proxy to forward the location data to Owntracks, Dawarich, Reitti… running somewhere in your LAN.
I’m collecting my location data with Owntracks via MQTT and openHAB subscribes to the location topic as well to get the current location.
This is possible, because my phone is always in my LAN via VPN.
Owntracks is running on another Raspi.
After each month, I pick the location JSON from Owntracks and import it into Dawarich. I use it on my laptop to manage the complete location history and for backups.
I use something like that, using exactly Owntracks with GPSTracker Binding to record locations store in InlfuxDB and draw with Grafana on the map. Initially I also use that to know when some of the family are at home or not, but I have done this for experimentation and is not bad.
But is not the same as you show, because the locations are reported no so quickly to avoid waste phone battery. Other drawback is due security of Android, you need to start manually OwnTracks after phone reboot to allow them to track your locations. Is not permited on Android to start location services in background without user intervention from some Android version.
That is for example previous year movements recorded:
