So, because I was curious, some more details/background:
When you look at the device_tracker entity in the frontend, like this:
The “4 hours ago” probably comes from states.device_tracker.xxx.last_changed. And as we’ve discussed, this doesn’t go any further back than the last HA restart. (More on that below.) However, the bar graph, and the times shown when hovering the mouse over one of the time periods, comes (effectively) from GET /api/history/period/<timestamp>. You can see this if you look at home-assistant.log when you click on the entity and that window opens:
2018-07-11 15:43:07 INFO (MainThread) [homeassistant.components.http.view] Serving /api/config/entity_registry/device_tracker.phillip_bruckner to xx.xx.xx.xx (auth: True)
2018-07-11 15:43:07 INFO (MainThread) [homeassistant.components.http.view] Serving /api/history/period/2018-07-11T20:42:50.654Z to xx.xx.xx.xx (auth: True)
2018-07-11 15:43:07 DEBUG (Thread-2) [homeassistant.components.recorder.util] converting 0 rows to native objects took 0.023312s
2018-07-11 15:43:07 DEBUG (Thread-2) [homeassistant.components.history] get_significant_states took 0.039570s
So, basically, that information comes from querying the database for entity state changes during the last 24 hour period.
Regarding states.device_tracker.xxx.last_changed, when HA starts, the recorder component is used to retrieve the last state of the entity. The entity is then added to the state machine with that state. However, this creates a state “change”, from None, to the retrieved state. Since that’s a state change, last_changed is updated accordingly. I suppose it might be nice if last_changed was someone set according to the last state change recorded in the database, which would then make it agree with the bar graph. But, I guess it just doesn’t work that way. And there may be other, less obvious reasons, why it shouldn’t.
So, bottom line, I think @petro’s idea of creating and using a history statistics sensor is the right idea.