I have an odd issue seeing the full set of histories in Tridium. We have nHaystack installed on a Tridium AX Supervisor, and I can connect to it through SkySpark Haystack connector successfully.

Through the Haystack connector on SkySpark, I can see five of the histories on the Tridium side, but I do not see any of the histories that contain the point data I want to see. The five available histories appear to be system-logging histories, containing log data like AuditHistory and LogHistory. However, I have another 88 histories on the station containing controls point data that I need to pull, and these are nowhere to be found through nHaystack.

To troubleshoot, I setup a new history on the station for one of the points in our office. Tridium created a new history set for it (called Office) and I can see the history fine in SkySpark through the same Haystack connector I built above. However, when I created a new history with fake data in the history set (called Ares) that has the point histories I need, I can't see that fake history in SkySpark.

I've compared the properties of the available histories with those that aren't and can't find any substantial differences between them. I've also went through the motions of building the SkySpark point from one of the available histories, which worked fine. I then manually built another point for the unavailable history, using Haystack tag values for the history and the good point as a template. The result was a org.projecthaystack.UnknownRecException error.

Does anyone have any suggestions to make these Tridium histories appear in SkySpark through nHaystack?

What happens if you go to the Query View on the NHaystackService in workbench, and invoke a query with a filter of "his"? Do you see the missing points/histories in the resulting output?

Mike, Thanks for the tip, we can see the missing histories in the nHaystackService's Query View. Which is nice to know we're not crazy. But this led to another oddity, as the histories we need to see don't appear to be listed as histories in the Query View.

The histories we can see conventially in SkySpark's Haystack Connector's HistorySpace all have id names in the format of "H.<History Container>.<Point Name>" in the nHaystack Query View. All the histories that we can't see in the SkySpark's HistorySpace have a Query View id in the format of "C.Drivers.<strange subfolder name (in my case, "Logic")>.<Remote Station Name>.<Point Name>".

And sure enough, when I go to the SkySpark Haystack Connector's Component Space > Drivers, I see the Logic folder there and can see all the missing histories.

The oddity is, all the histories, Logic folder and regular, are all available in Tridium where you'd expect to find histories: the Station > History container. All the unavailable histories I'm trying to reach above are in the Station > Drivers > Logic (folder) > <Remote Station Folder> > <Point Name>.

And, in the nHaystack Service Query view, the unavailable histories all have an axSlotPath tag using the same "Station > Drivers > Logic (folder) > <Remote Station Folder> > <Point Name>" folder path. And they all have an axType tag of "control:BooleanWriteable" or "control:NumbericWriteable".

So, I think at root the problem is these histories aren't really histories, and we need to pull the data from the history instead of the live point. Is there such thing as a Tridium derived history? And do you have any suggestions for getting these fake histories set up as real histories?

We're working from a backup copy of the Tridium site on a development server, and we didn't set up the original, so we're learning about the site as we're going along as well.

Thanks for your suggestion, that got us through our first roadblock.

Jerry

I'm out of town at the moment but will be back at work tomorrow (Wed). I'll have a look at this issue in detail then.

From reading over your last post, I think that there might not actually be anything wrong here. In the nhaystack documentation, I describe how the module glues histories and points together. In Project Haystack, there is no separate entity for a history the way there is in AX. So if there is a history in AX with no corresponding ControlPoint, I just expose that history as a point that has no cur tag. Does that make sense?

I think what you are seeing is that you have to go in more than one place from the connector to find all the points you want. For the ControlPoints, you look for them in the ComponentSpace. For the AX Histories that have no corresponding ControlPoint, you look in the HistorySpace. So you should be able to bring everything in already. Read back over that documentation and see if it makes sense to you, and let me know if you still can't import it all properly.

Mike, Thanks for your help on this. We've been working on the Tridium site and have had more progress getting the histories in the right place. It appears the copy of the Tridium site we're using for testing was quite old and didn't have the histories set up conventionally.

I'm working to get an updated version of the site for testing and will let you know if we continue to have this problem.

Thanks, Jerry

I am experiencing the same issue and confusion, where we have histories defined on server level, however when I run haystackReadAll(conn,his) it returns both C. and H. addresses.

I am assuming that C. links directly to control points on the Jace/controller and H. is referencing the back up histories with no limit on the server level.

I definitely prefer to have all the addresses linked to H. To prevent pinging the controller and in case of connection issue we can always use H. unlimited history back up from server.

Whats the suggestion to enable H. to be discovered by nHasytack for the C. addresses ?

I should also mention that I can see all the histories under history folder of Obix connector.

I had a similar experience yesterday with nHaystack running against an N4 supervisor.

multiple histories that had been imported from field JACEs were working fine until I added points to the NiagaraNetwork that had the corresponding histories in the haystackHistory space.

once the points were added all the haystack ID's that pointed to the H space wouldn't show up in a builder browse. The skyspark points using haystack connectors would not sync either.

Before adding point into NiagarNetwork the haystackHis tag: H.collins_379_clipsal.mech_level_08_power_sum -> worked fine

After adding points to niagaraNetwork, the haystackHis tag needed changing to : C.Drivers.NiagaraNetwork.collins_379_clipsal.points.meter.mssb_9a.level_07.power_sum

Is it possible to have it so that both IDs are valid?

I would like to keep adding to this dialog because I have similar frustrations trying to get at Histories only on a supervisor. I'm currently working with a client that has a campus of buildings (50+). They have a Niagara campus supervisor that is only used for alarm and history consolidation, no user interface. Histories are imported from the underlying supervisors or jaces. No points are mapped to the campus supervisor. I'm using haystackReadAll to automatically discover points and add them to SkySpark with the appropriate haystackRef tag.

If I leave the NHaystack "Show Linked Histores" Off and call haystackReadAll(his) I get Control Points with histories but only the axSlotPath, no axPointRef and no axHistoryRef. On History only records I get axHistoryIds (actual history name, not the point name) but no axHistoryRef (H. column), no axPointRef (C. column) and no axSlotPath. I see the histories I'm interested in but they have no axHistoryRef to put on the point haystackRef. My expectation is that with "Show Linked Histories" Off I would see Control Points with axPointRef (C. column), History only objects with axHistoryRef (H. column) and axHistoryId and no attempt to link the two.

If I turn "Show Linked Histories" On I would expect to still see Control Point and History only objects but now an attempt to link them together showing their appropriate axPointRef, axHistoryRef and axHistoryId where appropriate and left blank if no linking could be determined. What appears to be happening is all histories are returned but only the axPointRef (C. column) is shown if there is a match to a Control Point. An axType HistoryConfig will show axHistoryId but no axHistoryRef (H. column).

I've tried every combination I can think of to get History only records with their axHistoryRef (H. column) and axHistoryId and I haven't found a combination that works. I would request that any time there is a History the axHistoryId and axHistoryRef is returned and any time there is a Control Point the axPointRef is returned regardless if "Show Linked Histories" is on or off.

Just for everyones benefit.

Paul has contacted me offline and I will work through this with him and report back when we have more information.

Was a solution ever reached on this issue between Richard and Paul? I'm running into the same issue on one of my projects.