Update OpenHistorian subscription


I have Openhistorian connected to openHistorian with Internal gateway subscription (configuration is:
interface=; compression=false; autoConnect=true; securityMode=None; server=LOCALHOST:6165; internal=True; receiveInternalMetadata=True; receiveExternalMetadata=False; outputMeasurements={FILTER ActiveMeasurements WHERE Protocol = ‘GatewayTransport’}.
How can I update configuration without reset openhistorian subscription and lost all data saved ?



You want to install a new version of openHistorian without losing your current configuration, right?

A new install can “upgrade” your existing configuration using the configuration setup utility using steps like:

(1) Select “I want to use an existing configuration”
(2) Select “Database”
(3) Select “I want to upgrade to the latest schema”

These steps will “migrate” your existing configuration to a new schema, even a new database type…


I have OpenPDC and OpenHistorian connected with GEP.
I add new PMU in OpenPDC and I want to refresh configuration in openhistorian.



The openHistorian should automatically “see” the newly added device when added to the openPDC


I changed the configuration several times, by deleting or adding new PMUs but I don’t see changes in openistorian.



What happens if you re-initialize the subscription in the openHistorian? That is, go to the GEP device and click the Initialize button…


Attached error find in the openhistorian error.log

Application Domain: openHistorian.exe
Assembly Codebase: C:/Program Files/openHistorian/openHistorian.exe
Assembly Full Name: openHistorian, Version=, Culture=neutral, PublicKeyToken=null
Assembly Version:
Assembly Build Date: 6/1/2018 12:22:34 AM
.Net Runtime Version: 4.0.30319.42000

_Exception Source: _
Exception Type: System.InvalidOperationException
Exception Message: Failed to synchronize meta-data to local cache: Duplicate entry ‘f905cc35-8979-11e6-8a05-68b59975c00c-WAMS!PRRP#225’ for key ‘IX_Device_NodeID_Acronym’


Hi Pietro,

It means that the openHistorian has encountered two separate devices with the acronym WAMS!PRRP#225 when attempting to synchronize its metadata with the remote system. I would say that the most likely cause is that the UniqueID for PRRP#225 on the WAMS system was modified after the device’s metadata had been synchronized with the openHistorian. This could happen if you deleted the PRRP#225 device on the server and then recreated it while the openHistorian was offline or otherwise unable to receive configuration change notifications. Note that this would also change all the SignalIDs of the measurements.

The easiest solution in this case would be to delete the WAMS device and recreate it, though you said you don’t want to do that. You can also just delete the WAMS!PRRP#225 device, and any other offending devices. The extent to which this issue occurred is currently unknown and you’d have to work through it device by device. After each deletion, let the system resynchronize to get the configuration back. Unfortunately, you would lose the past data for any of the deleted devices.

The best solution to prevent data loss would be to manually synchronize the UniqueID field for your devices AND the SignalID field for your measurements between the two systems. UniqueID can be synchronized by Acronym. I’m thinking that the best way to synchronize SignalID is probably by SignalReference.