Phasor data history in OpenHistorian

GPA Products openHistorian
1

Hi guys,

I just wanted to confirm something. I add a device for a while and collect history on that device. I delete that device, then add the same device with a few different parameters. Will the prior history be lost forever, or is there is a way of combining the history of the removed device and the newly added device ( being the same physical device )?

2

Hi jeffhill,

Unfortunately, openHistorian 2.0 relies heavily on the configuration database to manage its metadata. There is an autoincrementing integer associated with each measurement which is used as part of the key for the corresponding measurements in the historian database. By deleting the device, you delete all the metadata for that device including its original measurement IDs, and there is no way to get these back without a backup of the configuration. When you recreate the device, it creates all-new data points based on the configuration it receives via the synchrophasor protocol. This creates brand new IDs that are not linked to the original data, and there’s no way to reassociate them since the original IDs were lost when you deleted the device in the first place.

Note that there is a folder called ConfigurationCache in the openHistorian directory that maintains five consecutive backups every time the system reloads configuration. If you’ve already deleted a device and need a copy of those IDs, you should be able to find them there, assuming you haven’t reloaded configuration five times since then.

Thanks,
Stephen

3

Thanks Stephen.

The reason I was asking this is because the Goose device needed to have its measurements manually added to the device, I ended up writing a program to do it for me. While testing I would delete and re-add measurements (which generated a new GUID) hence made me start thinking about how to keep history. Currently I am just backing up the Measurements table anytime a measurement is modified and then I can simply use the initially created GUID. A bit cheesy, and I haven’t tested it yet, but everything else works fine.

image
image1393×638 110 KB

image

4

Hi,

I’m facing the same issue.

I did the following.

  1. I deleted a existing device from OpenHistorian
  2. Before deleting existing device, I took the backup of OpenHistorian.db file and noted device ID and
    unique ID.
  3. Add again the same device and it was added with new device id in device table as well as measurement table.
  4. I modified old device ID in both tables, now I’m able to work with this device using old id and able to see the current readings. But I’m not able to see the previous history even updating the old id.

Could you please clarify? what would be require to handle this scenario? basically I need to view the old history data for this device.

Please help.

5

Hi Loganathan,

There is a PointID field in the Measurement table which gets stored in the openHistorian archive files. Those IDs are used to link metadata from the database to values stored in those archive files. The device’s ID and UniqueID fields are not stored in the archive and therefore restoring those IDs will have no relevant effect.

Thanks,
Stephen

6

Hi Stephen,

Thanks for your quick response. It is working fine and I’m able to see the old history data.
However, please clarify, below queries

Replacing old PointID value for this newly created device, I’m able to see the old history data.
Is there any impact for that newly created device by replacing old PointID value, which was created for the deleted device?

Will OpenHistorian take the automatic backup of openHistorian.db?
Is there any settings to enable database backup?

Thanks & Regards
Logu

7

The point ID is like a local unique identifier for the signal, where any systems accessing the openHistorian directly can use it to refer to that signal. Configuration parameters in adapters, such as the InputMeasurementKeys parameter, may use it to refer to individual signals. In a similar fashion, other systems using GEP or STTP to receive real-time streaming data may use it to subscribe to individual signals. And, of course, the historian attaches it to the data points in the archive so it can be reassociated with the metadata in the relational database. The impact of restoring the old point ID on the new device would be to reassociate the signal with all the old processes that were previously configured to identify that signal using the point ID.

openHistorian does not take any backups of openHistorian.db automatically. It really has no basis for doing so as it treats the database as a data source that is equally likely to come from an external MySQL or SQL Server database as it is from a local SQLite database file. Relational database backups should be handled through procedures external to the openHistorian process and, depending on the requirements for the backup, will likely need to be placed in a separate drive, box, or physical location anyway.

Thanks,
Stephen

8

Dear Stephen,

Thanks for your quick response.