How do I push historic data to Entities in Python?
Historic records let an Entity keep its previous values against a date and time, so you can ask what it looked like at any point rather than only what it looks like now. Backfilling readings from another system is the usual reason to write them yourself.
First, connect an attribute to a date-time
History is keyed on one of your own date-time attributes. In the Entity Type's Data Schema, set HistoricKey on each attribute you want tracked, pointing at that date-time attribute. That date-time is the historic key, and the attributes pointing at it are the historic attributes.
Nothing is recorded until that link exists, so this is the step to check first when a write appears to do nothing. See the Entity historic data documentation for the full definition.
For an attribute nested inside a Structure, the HistoricKey is slash separated from the root. Eg: readings/taken.
With that in place, updating an Entity with a new value in the date-time attribute records the previous state automatically. The rest of this page is about writing records directly, which is what a backfill needs.
You will want to install our Python library to facilitate this process.
Recording where the Entity was, too
A record keeps a full snapshot of the platform managed values as well as your attributes, so a moving Entity can keep its past positions. Pass them as internal and they are nested under the record's Bruce key.
Reading it back as the Entity
Once written, the records are what a point-in-time read overlays. Ask for an Entity at a date and time and the nearest matching record replaces its values, reported in the Outline like any other source.
Things worth knowing
Write the key attribute into the values. The date-time named by the historic key should appear in the recorded values as well as in the record's own DateTime. A record missing it still saves, but reading the Entity back at that point in time will not show the date it came from.
There is a record limit per Entity. The default is 1,000 records per Entity ID unless an upgraded limit is discussed. Past that, the oldest are dropped, so a long backfill at a fine interval can quietly evict its own earliest records.
Writing a record does not change the Entity. Its current values are untouched, which is the point. Update the Entity itself if you also want the latest state to move.
Scenarios. Passing a scenario writes the series as a variant rather than as real world data, and a Scenario identifies its own records, so the date-time and attribute become optional there.
Removing a bad backfill. Two options. delete_records takes the records themselves, so the ones you just wrote or just read are the ones removed. delete takes the same filter as a read, so the range you wrote is the range you clear; it requires the attribute and both ends of the range, which is what stops an unbounded delete.