Hi all, is it possible to create a relation between remote histories (imported into the station) and points (imported via station join) in order to export to SkySpark?
Do you mean you have discovered points from a station and also the associated histories as well? If so, then all you need to do is manually add the hs:his tag to the points and the export will attempt to resolve histories first locally via a history extension. If no history is found from a history extension and the point is detected to be a point integrated via a Niagara Network, it will search for a matching history that was imported.
If this is not the scenario you are in, could you please provide some more information on your setup.
hi, this was the exact scenario and it works 80%. Where it does not work is when a point references a history which is located in a historyDevice having name different to the point’s station name
An example is: do point joins from multiple JACEs into a single supervisor. Sync histories from multiple JACEs into a single supervisor (each creating it’s own historyDevice). Point join all supervisor points into a cloud supervisor under a single station, also sync all histories but this will again create multiple historyDevices. Add n:history and h:his tags with correct referencing to the history locations.
When station and historyDevice share the same name it works fine, but the scenario above results in no histories being reconciled by the haystack+ driver.
I am not following the issue as described. It seems you say the scenario both fails and works in that last statement so I am not sure of what scenario you are currently configured for and failing to resolve histories.
when the point’s station and historyDevice share the same name, histories are pushed
when the point’s station and historyDevice do not share the same name, histories are not pushed
The history device and station name should always be matched pair as that is how they are imported and tracked. The histories from station GREYST189 would NOT be associated with the history device (station) GRY189GND.
I’m trying to understand the expectation for the histories from 189 to exist in GND. The scenario you describe sounds exactly as expected behavior but I do not understand the failure to resolve correct histories in this scenario as points from GRY189GND should not be linked to points in GREYST189.
Can you elaborate on why it is you expect these seemingly two different stations to be linked in this manner?
Here is the exact scenario as I tried to explain before:
- Site has 3 JACEs on the site, trending is done on the JACE
- The 3 JACEs are point joined to an on-site supervisor
- Histories are synced from each of the JACEs, this creates 3 different history devices
- The on-site supervisor is point joined to a cloud supervisor as a single niagara station, but when histories are synced it still separates into 3 different history devices
- We have added the appropriate n:history tags to define where the associated history object lives but it seems like this is not being used by your driver
The retention of the history device is how Niagara keeps track of the true source of the history so that it is always tracked back to the correct originating location. Addition of the hs:his tag is all that is required for the driver to know to lookup a history for that point when it is a Niagara Network point. The n:history tag will be ignored during the history resolution process.
The history device naming convention matching the station name is how the resolution process matches and keeps track of the correct source in the same way that Niagara utilizes this same naming pattern. The two layered import you have in your system I believe is causing an issue as on the second server import, the proxy extension has lost the reference to the originating station name that is used by the driver to resolve the correct history device.
Could you please provide the proxy extension path at the top level import for one of the points for inspection to see if there may be a way to detect this type of scenario? If you don’t wish to publish that data in a public space, you can message it to me in private.
Speaking with James from Tridium and he agrees that the n:history is what should be used for resolving histories, that was the intention for it’s implementation as of Niagara 4.2
I agree this may be a good way to override the drivers lookup process but it is unlikely a user will go through and add all n:history tags to points that were discovered through the Niagara network. When a history extension is added to a point, I believe this tag is auto generated but does not exist once discovered through the Niagara network.
@kodaroJonathan the n:history tag was added in 4.2 and does autogenerate during the point join process. It would be much more compliant if you could seek the n:history tag and resolve it that way first before falling back to the legacy method
I’m running N4.6 and attempting this same thing and having issues. I’m able to add the hs:his tag the export still doesn’t pick it up and it doesn’t show up under implied tags like anything else I add. The history is resolving correctly in charts so Niagara knows it’s there but the export isn’t resolving it.
I also can’t seem to add a n:history tag - it’s not an option in the niagara tag dictionary.
Can you download and install the latest version of the driver, 1.0.20? There is a major update in that version that addresses a lot of the history resolving issues and scenarios reported from previous versions. You may want to check the application note History Resolving and Merging Options to determine which settings best fit your scenario. It likely won’t require you to change the default settings but it is good information to have depending on the setup of your system.