Hello, I am currently using nHaystack version 3.2.0, which was released on October 4, 2021. I have noticed that there have been no new releases since then. Could you please provide an explanation for the absence of further updates in recent years? Are there any plans for new releases of nHaystack in the near future?

WARNING [09:30:03 29-Oct-20 PDT][web] Invalid authorization header, scheme not supported: bearer
WARNING [09:35:03 29-Oct-20 PDT][nhaystack.watch] Watch ea19df5a-d851-4f55-8c1b-13beac44d8c6 timed out.

Not sure what has changed as API. It is not working with version 2.1.2 testing with 3.0.1

The company I work for has been using nhaystack to collect data out of Niagara instances into SkySpark for many years, and I'd like to request a feature (or at least a discussion!) to prevent something that I see that happens relatively frequently. There are times when an MSI or BAS engineer will move the location of point folders in a Niagara station. If that event occurs, the way we use nhaystack now (either by dropping nhaystack site or equip records, or by using the slotPath [ComponentSpace] ) will cause SkySpark to stop collecting data, and display an "Unknown RecErr" on the point's curErr tag. This requires our project engineers to fix the haystackCur/haystackHis tags inside SkySpark, once it is discovered. This is a costly process, in terms of time required to rebind these points to their new location path, and timeseries data that is not captured by SkySpark.

I've been working with @xVenturi to try and fix this problem, and found that there is a unique identifier that does not change, regardless of what happens to the point record, or the folder that contains the point. I'd like to propose that nhaystack use the "handle" tag, (or ordInSpace, handleOrd, ordInSession, or absoluteOrd tags) to bind the the point's haystackCur/haystackHis tags in SkySpark. This value is unique, and does not change if the record's location changes in the Niagara station. See the "SpaceNode" section below in the attached screenshot. Please let me know if you need further clarification, and thank you for reading! We would be more than happy to test this new functionality if it is made available.

@briansfrank any comments would be appreciated!

Hi Richard,

Cross-posting this from the Skyspark forum post:

The problem seems to arise only from enum points. If we pull the information from the history extension on the Niagara server, the "Display" value is stored there so that is what we get; however, the curVal in Skyspark seems to be reading the "Tag" value (which does not support the problematic characters). See the link: https://www.dropbox.com/s/24ayqk2v6tbu2ad/String%20issue.bmp?dl=0

I am not sure what can be done about this, but this is the issue we are seeing.

Thanks,
Taylor

Specifically interested if there is a release planned to include this commit: ec59e60

Installed nhaystack-3.2.0-4.10.1.36 on Niagara_4_Developer-4.12.2.16.1. Connected to remote SkySpark 3.1.5 server (see properties.png) and attempted to discover points. AD log displays error (see ioexception.txt). No problem discovering histories. If you need more info, let me know what you need and I will provide it. I haven't found any info online regarding this error related to nhaystack. I cloned the driver and added some debug to BNHaystackLearnPointsJob. Both of the for loops in run are completing. 325 key/value pairs are found and all are added, but the error is thrown before anything is added to the learn pane.

ioexception.txt

have point imported to skypark via nhaystack driver. Have duplicate niagara history id but unique haystack history.

haystack history
H.PHL7_NC_01.PHL7_EF_01_exhaustFan
C.Drivers.NiagaraNetwork.PHL7_NC_01.points.EF.EF_01.exhaustFanStatus

niagara history id
/PHL7_NC_01/PHL7_EF_01_exhaustFanStatus

Where is the H. type located and how do I remove from the import to skyspark?

I'm using the nHaystack module 3.2.0-4.10.1.36 on a Niagara Supervisor 4.12.2.16.

When I add site and equip tags and then try to edit them in the Workbench, I get this error message: "Cannot load plugin"

I have restarted the Supervisor.
 I have rebuilt the cache after adding sites.
I can make successful calls through the API and receive trends but I cannot filter for site.

Any suggestions on what might be causing this issue or troubleshooting steps?

Paul Quinn

Resolved: I did not have the nHaystack module installed on the Workbench version I was using.

When building, I get the error:
Slot with name yyy not found on class xxx have you run slot-o-matic?

What is slot-o-matic? is it an executable on my system, or where can I get it from?

We found an issue when using this on N4 (we have N4.9 and latest Haystack driver) where histories that are brought up to the supervisor are not all appearing in the HistorySpace. This happens for points that were brought up to the supervisor and can be found in the ComponentSpace. We have tried to re-build the cache on the driver and still they do not appear. Any idea what could be causing this?

I am trying to use the nhaystack where the Niagara (4.11.0.11.2) instance is behind a firewall and a J2 Fin instance on the wan side, i have forwarded port 443 which connects without issue, however once you pull points through and start polling them the connector in J2 Fin disconnects after about 2 mins and produces SSL Errors. Anyone else tried to do this and have any hints?

Debug log from Fin Connector

ConnActor is busy; no details available

currentMessage:
id: houseKeeping
dur: 49sec
threadId: 666
dev1-Haystack-Worker-3 [666: RUNNABLE]
java.net.SocketInputStream.socketRead0(Native Method)
java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
java.net.SocketInputStream.read(SocketInputStream.java:171)
java.net.SocketInputStream.read(SocketInputStream.java:141)
sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:457)
sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165)
sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1143)
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1054)
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:394)
- locked: sun.security.ssl.TransportContext@3f1ffe58
sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:708)
- locked: sun.security.ssl.TransportContext@3f1ffe58
sun.security.ssl.SSLSocketImpl.access$100(SSLSocketImpl.java:72)
sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:961)
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
- locked: java.io.BufferedOutputStream@50de87d3
fan.sys.SysOutStream.flush(SysOutStream.java:91)
fan.web.WebClient.writeReq(WebClient.fan:467)
fan.auth.AuthClientContext.send(AuthClientContext.fan:251)
fan.auth.AuthClientContext.get(AuthClientContext.fan:221)
fan.auth.AuthClientContext.openStd(AuthClientContext.fan:181)
fan.auth.AuthClientContext.doOpen(AuthClientContext.fan:87)
fan.auth.AuthClientContext.open(AuthClientContext.fan:28)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
fan.sys.Method.invoke(Method.java:573)
fan.sys.Method$MethodFunc.call(Method.java:367)
fan.sys.Method.call(Method.java:145)
fan.haystack.Client.open(Client.fan:37)
fan.haystackExt.HaystackClient.open(HaystackClient.fan:22)
fan.haystackExt.HaystackConnBase.onOpen(HaystackConnBase.fan:67)
fan.connExt.Conn.open(Conn.fan:151)
fan.connExt.Conn.openLinger(Conn.fan:117)
fan.connExt.Conn.openLinger(Conn.fan)
fan.connExt.Conn.ping(Conn.fan:208)
fan.connExt.Conn.checkReopen(Conn.fan:424)
fan.connExt.Conn.doHouseKeeping(Conn.fan:343)
fan.connExt.ConnActor.receive(ConnActor.fan:173)
fan.concurrent.Actor._dispatch(Actor.java:274)
fan.concurrent.Actor._work(Actor.java:229)
fan.concurrent.ThreadPool$Worker.run(ThreadPool.java:273)

Actor
pool: dev1-Haystack
state: running
queue: 9 (peak 14)
received: 4624
ticks: 38sec (avg 8ms)
curMsg: ConnMsg(houseKeeping)
ConnMsg(poll)
ConnMsg(callRes a=fan.haystackExt.HaystackCallRes@7c1a10a6 b=fan.haystackExt.GridOrErr@52e610d1)
ConnMsg(callRes a=fan.haystackExt.HaystackCallRes@f88426 b=fan.haystackExt.GridOrErr@e3f7a49)
ConnMsg(callRes a=fan.haystackExt.HaystackCallRes@1ad2fca b=fan.haystackExt.GridOrErr@f6ad18f)
ConnMsg(callRes a=fan.haystackExt.HaystackCallRes@19435910 b=fan.haystackExt.GridOrErr@1be66dbe)
ConnMsg(callRes a=fan.haystackExt.HaystackCallRes@784c6452 b=fan.haystackExt.GridOrErr@58f040e6)
ConnMsg(callRes a=fan.haystackExt.HaystackCallRes@dd0929e b=fan.haystackExt.GridOrErr@3b437d43)
ConnMsg(connDetails)
ConnMsg(callRes a=fan.haystackExt.HaystackCallRes@428aea34 b=fan.haystackExt.GridOrErr@3f716739)

ActorPool
name: dev1-Haystack
maxThreads: 100
maxTime: 1sec
hasPending: false
pending: 0
idle: 1
workers: 2
dev1-Haystack-Worker-3: HaystackConn "Haystack Conn" [queue: 9]
dev1-Haystack-Worker-1: idle

When I attempt to discover points, I'm getting "java.io.IOException: javax.baja.xml.XException: java.io.IOException: circuit closed". Nothing added to the learn pane. No problem discovering histories.

@ci-richard-mcelhinney As discussed, we have a proposal to extend the Haystack client capabilities to include pushing history data to a Haystack server. It supports pushing to pre-defined entities or automatic creation of point entities if they don't exist. If support is detected via ops op, it will use a create operation, which is a WideSky extension to the Haystack REST API standard.

Below is a proposed update to the docs which adds to the existing section 7 "Using NHaystack as a client"

7.1. Exporting history to another Project Haystack server

The NHaystack client can be used to push history stored on the Niagara station
to an upstream Project Haystack-compatible server. This feature has been
successfully tested on both NHaystack server and on WideSky, but should
work with any Project Haystack server.

The NHaystack History Export Manager can be found by right-clicking on
Histories beneath your Project Haystack server instance and selecting Views →
NHaystack History Export Manager. From here, clicking Discover will present
you with a list of all the histories on the station.

After selecting the histories of interest, click Add, and you'll be presented
with a dialogue box listing the histories and the options to be set.

From this form, each history must be associated with the Ref of the point
to which it will write its historical data. There are three ways this can be
done.

7.1.1 Manual association of points via the Add form

The lowest-common denominator method here is to use a standard Project
Haystack client to get a list of valid points from your server, then manually
copying the id of each point into the Id field on the Add form.

This should work for any Project Haystack server. The point is assumed to
carry a his tag, be of the correct kind for the type of history being
exported, and either carries a tz tag matching that of the history, or is on
a server that supports time-zone conversion.

For more detail on tagging assumptions, see section 7.1.2 below.

7.1.2 Automatic look-up using axStation and axHistoryId.

Depending on the Project Haystack server, it may be easier to retrieve a list
of histories from the station and tag the points so the station can find them.
Such a list can be obtained from WorkPlace via the following procedure:

1. Double click on your station's "History" space (it'll take you to a chart
   view)
2. Press CTRL+L to bring up the ORD dialogue
3. At the end of the text field (after history:), add
   bql:select id, recordType, timeZone from /
4. From the File menu, select Export.
5. Choose "Text to CSV" and "Save to File"
6. Enter the path where you want the file and click OK.

Filter out of that list the histories you want to upload. To associate a
history in this list to a point in your asset model, tag the point with the
following two tags:

• axStation (Str): should be the name of your Niagara station (as seen in
  brackets in the WorkPlace navigation tree, e.g. mystation).
• axHistoryId (Str): should be the ID of the history taken from your BQL
  query dump.

The point will also need to have kind and tz set up properly:

• Histories of type history:NumericTrendRecord should be tagged with
  kind=="Number". Ideally these should also be tagged unit (Str) with an
  appropriate Project Haystack unit.
• Histories of type history:BooleanTrendRecord should be tagged with
  kind=="Bool"
• Histories of type history:EnumTrendRecord should be tagged with
  kind=="Str" and ideally should also be tagged enum (Str) with a
  comma-separated list of valid enum values.
• Histories of other types should be tagged with kind=="Str".

7.1.3 Automatic creation of points

If the server supports the createRec call, then points will be automatically
created on the Project Haystack server. The station will issue a HTTP POST
instruction to the server's createRec endpoint with a single-row grid
containing the following columns:

• name (Str): This will be the name of the control point, or if that's not known,
  the name of the history.
• dis (Str): This will be the Display Name of the control point (or
  history), or if those are blank/null/not known, the name of the new point.
• point (Marker)
• his (Marker)
• kind (Str): The point kind; one of Str, Bool or Number, depending on
  the type of history being exported.
• tz (Str): The timezone of the history (this is set in the Add dialogue,
  default is automatically determined from the history database).
• axStation (Str): The name of the Niagara station exporting the history
• axHistoryId (Str): The ID of the history being exported
• axSlotPath (Str): If known, the slot path of the control point (may be
  omitted if not known).
• unit (Str): If known and history is a NumericTrendRecord, the
  measurement unit for the control point
• enum (Str): If known and history is a EnumTrendRecord, the list of valid
  enumeration values for the control point

It is assumed that siteRef and equipRef are optional and can be filled in
later via other CRUD ops by the end user. The axStation and axHistoryId
should be used to obtain listings of the orphaned point entities so they can
be associated with the correct site and equip.

7.2 Fine tuning payload sizes

The number of records exported at a time can be tuned by configuring the
Upload Size. This is a count of the number of rows used in each hisWrite
request. It defaults to 10000, which depending on the server may work, or may
result in a "Request Entity Too Large" error message from the server.

In such cases, the driver will automatically divide this value by two and try
again, so if the server experiences difficulty processing the set number of
records, you'll see smaller payloads (5000, 2500, 1250, etc) attempted. (It
will not go any smaller than 1 record.)

You can manually set this value to any payload size suits your requirements.

7.3 Setting an alternate start point

By default, exports begin at the very first record in the history. This can
be configured via the "Upload From Time" field. This specifies the start
point for the very next export task.

It can be used to "skip over" invalid data that was captured during the
commissioning process, as well as to re-upload data in the event that data is
lost or corrupted on the upstream Project Haystack server.

When running nhaystack v3.0.1 service on N4.7, integrated to SkySpark 3.0.25, issue with a clearn uninstall of nhaystack driver.
Unable to uninstall nhaystack from N4 station because of persistent dependencies, even after clearing out all nhaystack palette objects and rebuilding cache, removing broken refs.

The haystackLastWrite facet is added to the Niagara points after a point write from a remote haystack server (SkySpark). This facet does get removed, even after point write is released, and all nhaystack service actions are attempted (clear caceh, remove borken refs, re-initialize, disable/enable). This creates a dependency that does not allow for nhaystack module to be uninstalled and station restarted cleanly.

We have installed nhaystack verison v3.2.0.4.10.1.36 on our 4.10.0.154 instance of Niagara, and querying this Niagara instance from a 3.1.3 version of SkySpark. A contractor added two tags that are causing issues when we try to use haystackReadAll to look for records in the instance of Niagara from SkySpark (see below).

I've tried to run readLink(@p:CLIENT:r:29a96504-7dd2889d).haystackRead(point) [works], readLink(@p:CLIENT:r:29a96504-7dd2889d).haystackReadAll(parseFilter(\\\"point and not ORHum\\\"))\") [does not work], and readLink(@p:CLIENT:r:29a96504-7dd2889d).haystackReadAll(equip) [does not work], and readLink(@p:CLIENT:r:29a96504-7dd2889d).haystackReadAll(parseFilter("point and fes!=ORHum and hs!=ORHum")). The returned error message is:

ver:"3.0" errType:"axon::EvalErr" err errTrace:"axon::EvalErr: Func failed: haystackReadAll(Expr conn,Expr filterExpr); args: (Call,Call)\n  haystack::CallErr: java.lang.IllegalArgumentException: Invalid tag name: ORHum [eval:1]\n=== Axon Trace ===\n  evalOrReadAll (eval:1)\n\n=== Remote Trace ===\njava.lang.IllegalArgumentException: Invalid tag name: ORHum\n  at org.projecthaystack.HDictBuilder.add(HDictBuilder.java:79)\n  at nhaystack.server.TagManager.generateComponentTags(TagManager.java:296)\n  at nhaystack.server.TagManager.createComponentTags(TagManager.java:463)\n  at nhaystack.server.SpaceManager\$CIterator.findNext(SpaceManager.java:230)\n  at nhaystack.server.SpaceManager\$CIterator.next(SpaceManager.java:211)\n  at nhaystack.server.SpaceManager\$CIterator.next(SpaceManager.java:190)\n  at nhaystack.collection.CompositeIterator.findNext(CompositeIterator.java:67)\n  at nhaystack.collection.CompositeIterator.next(CompositeIterator.java:39)\n  at org.projecthaystack.server.HServer.onReadAll(HServer.java:115)\n  at nhaystack.server.NHServer.onReadAll(NHServer.java:120)\n  at org.projecthaystack.HProj.readAll(HProj.java:141)\n  at org.projecthaystack.server.ReadOp.onService(HStdOps.java:149)\n  at org.projecthaystack.server.HOp.onService(HOp.java:48)\n  at org.projecthaystack.server.HServlet.onService(HServlet.java:90)\n  at org.projecthaystack.server.HServlet.doPost(HServlet.java:53)\n  at nhaystack.server.BNHaystackServlet.doPost(BNHaystackServlet.java:99)\n  at javax.baja.web.BWebServlet.service(BWebServlet.java:151)\n  at javax.baja.web.BWebServlet.doService(BWebServlet.java:195)\n  at javax.baja.web.BWebServlet.access\$000(BWebServlet.java:34)\n  at javax.baja.web.BWebServlet\$Servlet.doPost(BWebServlet.java:333)\n  at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)\n  at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n  at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:763)\n  at org.eclipse.jetty.servlet.ServletHandler\$CachedChain.doFilter(ServletHandler.java:1655)\n  at com.tridium.web.filters.WebStartServletFilter.doFilter(WebStartServletFilter.java:47)\n  at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)\n  at org.eclipse.jetty.servlet.ServletHandler\$CachedChain.doFilter(ServletHandler.java:1642)\n  at com.tridium.web.filters.ContextFilter.doFilter(ContextFilter.java:42)\n  at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)\n  at org.eclipse.jetty.servlet.ServletHandler\$CachedChain.doFilter(ServletHandler.java:1642)\n  at com.tridium.web.filters.LocaleFilter.doFilter(LocaleFilter.java:31)\n  at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)\n  at org.eclipse.jetty.servlet.ServletHandler\$CachedChain.doFilter(ServletHandler.java:1642)\n  at com.tridium.web.filters.TridiumSecurityFilter.doFilter(TridiumSecurityFilter.java:42)\n  at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)\n  at org.eclipse.jetty.servlet.ServletHandler\$CachedChain.doFilter(ServletHandler.java:1642)\n  at com.tridium.web.filters.AddSubjectFilter.lambda\$null\$0(AddSubjectFilter.java:59)\n  at java.security.AccessController.doPrivileged(Native Method)\n  at javax.security.auth.Subject.doAs(Subject.java:422)\n  at com.tridium.web.filters.AddSubjectFilter.lambda\$doFilter\$1(AddSubjectFilter.java:58)\n  at java.security.AccessController.doPrivileged(Native Method)\n  at com.tridium.web.filters.AddSubjectFilter.doFilter(AddSubjectFilter.java:56)\n  at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)\n  at org.eclipse.jetty.servlet.ServletHandler\$CachedChain.doFilter(ServletHandler.java:1642)\n  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:572)\n  at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n  at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:567)\n  at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)\n  at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)\n  at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1612)\n  at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)\n  at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1434)\n  at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)\n  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)\n  at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1582)\n  at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)\n  at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1349)\n  at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n  at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234)\n  at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)\n  at com.tridium.jetty.NiagaraSecurityHandler.handle(NiagaraSecurityHandler.java:59)\n  at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)\n  at org.eclipse.jetty.server.Server.handle(Server.java:516)\n  at org.eclipse.jetty.server.HttpChannel.lambda\$handle\$1(HttpChannel.java:383)\n  at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:556)\n  at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)\n  at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)\n  at org.eclipse.jetty.io.AbstractConnection\$ReadCallback.succeeded(AbstractConnection.java:311)\n  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)\n  at org.eclipse.jetty.io.ssl.SslConnection\$DecryptedEndPoint.onFillable(SslConnection.java:540)\n  at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:395)\n  at org.eclipse.jetty.io.ssl.SslConnection\$2.succeeded(SslConnection.java:161)\n  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)\n  at org.eclipse.jetty.io.ChannelEndPoint\$1.run(ChannelEndPoint.java:104)\n  at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)\n  at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)\n  at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)\n  at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)\n  at org.eclipse.jetty.util.thread.ReservedThreadExecutor\$ReservedThread.run(ReservedThreadExecutor.java:375)\n  at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:773)\n  at org.eclipse.jetty.util.thread.QueuedThreadPool\$Runner.run(QueuedThreadPool.java:905)\n  at com.tridium.nre.util.PrivilegedRunnable.lambda\$run\$0(PrivilegedRunnable.java:30)\n  at java.security.AccessController.doPrivileged(Native Method)\n  at com.tridium.nre.util.PrivilegedRunnable.run(PrivilegedRunnable.java:28)\n  at java.lang.Thread.run(Thread.java:748)\n\n=== Fantom Trace ===\naxon::EvalErr: Func failed: haystackReadAll(Expr conn,Expr filterExpr); args: (Call,Call)\n  haystack::CallErr: java.lang.IllegalArgumentException: Invalid tag name: ORHum [eval:1]\n  axon::FantomFn.callx (FantomFn.fan:117)\n  axon::LazyFantomFn.callLazy (FantomFn.fan:161)\n  axon::Call.eval (Call.fan:39)\n  skyarcd::Context.evalOrReadAll (Context.fan:113)\n  axon::CoreLib.evalOrReadAll (CoreLib.fan:2547)\n  jdk.internal.reflect.GeneratedMethodAccessor256.invoke (Unknown)\n  jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)\n  java.lang.reflect.Method.invoke (Method.java:568)\n  fan.sys.Method.invoke (Method.java:573)\n  fan.sys.Method\$MethodFunc.callList (Method.java:212)\n  fan.sys.Method.callList (Method.java:138)\n  axon::FantomFn.doCall (FantomFn.fan:125)\n  axon::AxonContext.callInNewFrame (AxonContext.fan:153)\n  axon::AxonContext.callInNewFrame (AxonContext.fan)\n  axon::FantomFn.callx (FantomFn.fan:113)\n  axon::Fn.callLazy (Fn.fan:84)\n  axon::Call.eval (Call.fan:39)\n  skyarcd::Context.evalOrReadAll (Context.fan:113)\n  skyarcd::EvalAllOp.evalAllExpr (ApiMod.fan:504)\n  skyarcd::EvalAllOp.onService (ApiMod.fan:474)\n  fan.sys.List.each (List.java:604)\n  haystack::GbGrid.each (GridBuilder.fan:393)\n  skyarcd::EvalAllOp.onService (ApiMod.fan:470)\n  skyarcd::ApiWebMod.onService (ApiMod.fan:150)\n  skyarcd::HttpRootMod.onService (HttpMod.fan:122)\n  8 More...\nCause:\n  haystack::CallErr: java.lang.IllegalArgumentException: Invalid tag name: ORHum\n    concurrent::ActorFuture.get (ActorFuture.java:108)\n    hxConn::Conn.sendSync (Conn.fan:190)\n    hxHaystack::HaystackFuncs.dispatch (HaystackFuncs.fan:237)\n    hxHaystack::HaystackFuncs.haystackReadAll (HaystackFuncs.fan:105)\n    jdk.internal.reflect.GeneratedMethodAccessor360.invoke (Unknown)\n    jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)\n    java.lang.reflect.Method.invoke (Method.java:568)\n    fan.sys.Method.invoke (Method.java:573)\n    fan.sys.Method\$MethodFunc.callList (Method.java:212)\n    fan.sys.Method.callList (Method.java:138)\n    axon::FantomFn.doCall (FantomFn.fan:125)\n    axon::AxonContext.callInNewFrame (AxonContext.fan:153)\n    axon::AxonContext.callInNewFrame (AxonContext.fan)\n    axon::FantomFn.callx (FantomFn.fan:113)\n    axon::LazyFantomFn.callLazy (FantomFn.fan:161)\n    axon::Call.eval (Call.fan:39)\n    skyarcd::Context.evalOrReadAll (Context.fan:113)\n    axon::CoreLib.evalOrReadAll (CoreLib.fan:2547)\n    jdk.internal.reflect.GeneratedMethodAccessor256.invoke (Unknown)\n    jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)\n    java.lang.reflect.Method.invoke (Method.java:568)\n    fan.sys.Method.invoke (Method.java:573)\n    fan.sys.Method\$MethodFunc.callList (Method.java:212)\n    fan.sys.Method.callList (Method.java:138)\n    axon::FantomFn.doCall (FantomFn.fan:125)\n    22 More...\n    haystack::CallErr: java.lang.IllegalArgumentException: Invalid tag name: ORHum\n      haystack::Client.call (Client.fan:230)\n      haystack::Client.call (Client.fan)\n      haystack::Client.readAll (Client.fan:146)\n      hxHaystack::HaystackDispatch.onReadAll (HaystackDispatch.fan:140)\n      hxHaystack::HaystackDispatch.onReceive (HaystackDispatch.fan:36)\n      hxConn::ConnMgr.onReceive (ConnMgr.fan:88)\n      hxConn::Conn.receive (Conn.fan:264)\n      concurrent::Actor._dispatch (Actor.java:274)\n      concurrent::Actor._work (Actor.java:229)\n      concurrent::ThreadPool\$Worker.run (ThreadPool.java:273)\n" dis:"axon::EvalErr: Func failed: haystackReadAll(Expr conn,Expr filterExpr); args: (Call,Call)\n  haystack::CallErr: java.lang.IllegalArgumentException: Invalid tag name: ORHum [eval:1]"

My main questions are:

1. How can I query around these tags from inside SkySpark? What is the proper Axon query to exclude these points?
2. What about these tags are causing SkySpark to throw an error? Is the only way to fix this error to remove/edit these tags to be Axon-safe (https://skyfoundry.com/doc/lib-axon/func~toTagName)?

Thank you!

There is potential for standard facets on Control Points to be configured with a different type than expected. For example, the Niagara documentation states that the Min facet field should be a Number. However, the user can configure this to be something else.

This causes a Class Cast Exception when trying to retrieve the facet as the type is unexpected.

Need to add some better handling for this so it doesn't crash out.

I had some custom components in my module where I expected the hs:id tag to be applied. However, when inspecting the implied tags on the component, and this was verified once the tags were shipped out of Niagara, the 'hs:id' tag wasn't there. Looking at the rules in the tag dictionary it seems that the 'hs:id' tag should be applied to every baja:component.

This needs to be looked into because the 'hs:id' tag is vital to a number of operations.

@esanderson you might need to check this out in the Tridium tag dictionaries.

nHaystack version: v3.2.0
Niagara N4 v4.12.2.16

The Issue

Creating a tag dictionary, then a tag group where the tag group name is e.g. "valve-Actuator", causes any read op filter query to return Invalid tag name: valve$2dActuator" errTrace:"java.lang.IllegalArgumentException. Full stack trace below. The tag group appears to be treated as a tag itself when its merely a container for other tags.

Steps to reproduce

1. Add a new smart tag dictionary to a station with the configuration in the screenshot below.
   
2. Create a control point in the station and add the tag group "valve-Actuator" as a direct tag to to the control point.
3. Run the following read op query against the station: https://localhost/haystack/read?filter=point
4. Expect the following stack trace and errors to show up:

ver:"3.0" dis:"java.lang.IllegalArgumentException: Invalid tag name: valve$2dActuator" errTrace:"java.lang.IllegalArgumentException: Invalid tag name: valve$2dActuator
  at org.projecthaystack.HDictBuilder.add(HDictBuilder.java:79)
  at nhaystack.server.TagManager.generateComponentTags(TagManager.java:296)
  at nhaystack.server.TagManager.createComponentTags(TagManager.java:463)
  at nhaystack.server.SpaceManager$CIterator.findNext(SpaceManager.java:230)
  at nhaystack.server.SpaceManager$CIterator.next(SpaceManager.java:211)
  at nhaystack.server.SpaceManager$CIterator.next(SpaceManager.java:190)
  at nhaystack.collection.CompositeIterator.findNext(CompositeIterator.java:67)
  at nhaystack.collection.CompositeIterator.next(CompositeIterator.java:39)
  at org.projecthaystack.server.HServer.onReadAll(HServer.java:115)
  at nhaystack.server.NHServer.onReadAll(NHServer.java:120)
  at org.projecthaystack.HProj.readAll(HProj.java:141)
  at org.projecthaystack.server.ReadOp.onService(HStdOps.java:149)
  at org.projecthaystack.server.HOp.onService(HOp.java:48)
  at org.projecthaystack.server.HServlet.onService(HServlet.java:90)
  at org.projecthaystack.server.HServlet.doGet(HServlet.java:47)
  at nhaystack.server.BNHaystackServlet.doGet(BNHaystackServlet.java:79)
  at javax.baja.web.BWebServlet.service(BWebServlet.java:152)
  at javax.baja.web.BWebServlet.doService(BWebServlet.java:198)
  at javax.baja.web.BWebServlet.access$000(BWebServlet.java:50)
  at javax.baja.web.BWebServlet$Servlet.doGet(BWebServlet.java:329)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
  at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)
  at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1656)
  at com.tridium.web.filters.WebStartServletFilter.doFilter(WebStartServletFilter.java:47)
  at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
  at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
  at com.tridium.web.filters.ContextFilter.doFilter(ContextFilter.java:42)
  at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
  at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
  at com.tridium.web.filters.LocaleFilter.doFilter(LocaleFilter.java:31)
  at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
  at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
  at com.tridium.web.filters.TridiumSecurityFilter.doFilter(TridiumSecurityFilter.java:42)
  at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
  at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
  at com.tridium.web.filters.AddSubjectFilter.lambda$null$0(AddSubjectFilter.java:58)
  at java.security.AccessController.doPrivileged(Native Method)
  at javax.security.auth.Subject.doAs(Subject.java:422)
  at com.tridium.web.filters.AddSubjectFilter.lambda$doFilter$1(AddSubjectFilter.java:57)
  at java.security.AccessController.doPrivileged(Native Method)
  at com.tridium.web.filters.AddSubjectFilter.doFilter(AddSubjectFilter.java:55)
  at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
  at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1626)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:552)
  at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
  at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:560)
  at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
  at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
  at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
  at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
  at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
  at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)
  at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
  at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
  at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
  at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
  at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:234)
  at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
  at com.tridium.jetty.NiagaraSecurityHandler.handle(NiagaraSecurityHandler.java:76)
  at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
  at org.eclipse.jetty.server.Server.handle(Server.java:516)
  at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
  at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
  at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
  at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
  at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
  at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:555)
  at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:410)
  at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:164)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
  at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
  at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
  at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
  at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
  at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
  at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
  at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
  at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
  at com.tridium.nre.util.PrivilegedRunnable.lambda$run$0(PrivilegedRunnable.java:30)
  at java.security.AccessController.doPrivileged(Native Method)
  at com.tridium.nre.util.PrivilegedRunnable.run(PrivilegedRunnable.java:28)
  at java.lang.Thread.run(Thread.java:750)
" err

Additional Coments

Note that when I rename the tag group from "valve-Actuator" to "valveActuator" then the read op succeeds as expected. What is unexpected is that the control point on which the tag group "valveActuator" added, the resulting read op returns "valveActuator" as a marker tag to the control point. The tag group is unexpectedly getting treated as a maker tag.

I have a project with a soft jace at 4.12.2.16, the nhaystack-3.2.0-4.10.1.36 modules are giving me a signature error. Should these work with version 4.12 or am I doing something wrong?

Currently the workbench view does not support displaying the proper SEP hierarchy. It would be good to be able to show the proper hierarchy in this view.

Hello,
Could you please confirm if a patched haystack module is still required when using Niagara 4.9?
Is dragging the Haystack tag dictionary from the N4Haystack module sufficient, or am I missing a step?

I'm having difficulty getting tags to be automatically applied, I've got as far as getting the haystack slot added if I do it manually, via the service. I can then add tags manually using the field editor. I'm using the version 3 beta release.

Edit: I appear to now have my custom tags applied automatically to my points after setting the correct references and rebuilding cache. So just wondering if the patched haystack module is a requirement still.

Hi, I'm working on a Haystack client library and have reports that when connecting to a Niagara 4 server with nHaystack installed, it is not getting the expected 401 response from a HELLO message to the /about op as documented in the Project Haystack SCRAM Auth docs. Instead, it receives a 200, but I'm not sure how to interpret that and what the ramifications are for re-authenticating later.

I tried to figure this out by looking at other implementations:

1. The Haxall haystack connector has a short-circuit on 200 responses to the hello message
2. pyHaystack appears to be using different endpoints for Niagara 4 - like hitting /prelogin and /j_security_check instead of /about

I have the following questions:

1. Does nHaystack follow the same Authentication flow and endpoints as the Project Haystack docs? If not, is there documentation on the authentication flows it uses?
2. If a client receives a 200: OK from the /about endpoint, does that mean that the client may continue with subsequent haystack requests? Or does it mean that user has already authenticated and the client may just use the provided cookie? Are there considerations for re-authenticating in this case?
3. What is the best way to run this package for live testing? Is a Niagara instance and license required?

Posted originally via haystack forums:
https://project-haystack.org/forum/topic/886

In Niagara there is a point configured which has an alarm extension set to place the point's value in its fault state. When making either a WatchSub or WatchPoll request against this point, the curStatus=fault as expected however both the zinc and json responses come back with a null value as shown below:

The json reponse:

{
    "meta": {
        "ver": "2.0",
        "watchId": "143da86f-7fa7-4681-9be0-c2c0745249d9",
        "lease": "n:10000 ms"
    },
    "cols": [
        {
            "name": "curStatus"
        },
        {
            "name": "curVal"
        },
        {
            "name": "id"
        }
    ],
    "rows": [
        {
            "curStatus": "ok",
            "curVal": true,
            "id": "r:C.Examples.AHU~2d01.FanStatus"
        },
        {
            "curStatus": "fault",
            "id": "r:C.Examples.AHU~2d01.SupplyTemp"
        }
    ]
}

The zinc response:

ver:"3.0" watchId:"3b9e058b-5830-4557-bc73-d7726f9b968f" lease:10000ms
curStatus,curVal,id
"ok",T,@C.Examples.AHU~2d01.FanStatus
"fault",,@C.Examples.AHU~2d01.SupplyTemp

Is it expected that nHaystack should return a null curVal when curStatus is in fault? If this is expected behavior what would be the reasoning for not returning the value when the point is in fault?

Software versions

    {
        "productUri": "u:http://www.tridium.com/",
        "tz": "London",
        "moduleName": "nhaystack",
        "serverName": "test",
        "productName": "Niagara 4",
        "haystackVersion": "2.0",
        "productVersion": "4.11.0.142",
        "moduleVersion": "3.1.0",
        "serverTime": "t:2022-04-06T13:19:34.051+01:00 London",
        "moduleUri": "u:https://bitbucket.org/richiemac_77/nhaystack",
        "serverBootTime": "t:2022-04-01T13:10:47.319+01:00 London"
    }

Issuing the following request via postman returns a list of available histories.

https://xxx.xxx.xxx.xxx/haystack/nav?navId=his:/SITE00007_L001_O011

However the results returned display the dis and navName fields having identical values, when in this case the dis should show "ASHP Discharge Temperature"

Would it be possible to correct this if my assumptions are correct?

    {
        "tz": "London",
        "axHistoryId": "/SITE00007_L001_O011/P0006",
        "point": "m:",
        "dis": "SITE00007_L001_O011_P0006",
        "his": "m:",
        "axType": "s:history:HistoryConfig",
        "navName": "SITE00007_L001_O011_P0006",
        "id": "r:H.SITE00007_L001_O011.P0006 SITE00007_L001_O011_P0006",
        "kind": "Number",
        "unit": "°C"
    }

Thanks

When attempting to use the pointWrite op to read a schedule event I get an issue parsing the zinc due to the ver:"3.0" line in the nested grid. Per a discussion on the SkyFoundry forum (https://skyfoundry.com/forum/topic/7109) it looks like it could be an encoding issue due to a missing "<<" and ">>".

Previously, I was able to sign the module using gradle :

// Include additional files in module jar 
jar { 
  from('src') { 
    include 'res/*.csv'
    }
    def passwd = "mypassworf"
    def app_alias = "my_alias"
    def jks_file = "C:\\0Programmes\\Java\\Eclipse\\my_keystore\\my_keystore"
    def tsa_url = "http://timestamp.digicert.com"
    def exec_line = "jarsigner -keystore " + jks_file + " -storepass " +
        passwd + " -keypass "+ passwd + " -tsa " + tsa_url + " " + jar.archivePath + " " + app_alias
    print  exec_line
    exec_line.execute()
}

Now I get > Could not find method jar() for arguments error.

I suspect gradle changed since I last used it.

I ended up using jarsigner directly on the command line. Could you share a way to include the signing "task" to gradle ?

Command line (for reference)

jarsigner -keystore "C:\\0Programmes\\Java\\Eclipse\\my_keystore\\my_keystore" -storepass mypassworf-keypass mypassworf -tsa http://timestamp.digicert.com C:\JCI\FXWorkbench-14.9\modules\nhaystack-rt.jar my_alias

jarsigner -keystore "C:\\0Programmes\\Java\\Eclipse\\my_keystore\\my_keystore" -storepass mypassworf-keypass mypassworf -tsa http://timestamp.digicert.com C:\JCI\FXWorkbench-14.9\modules\nhaystack-wb.jar my_alias

Hello,

I'm trying to use nHaystack to send a command to a point on a Jace (firmware version 4.8). I've managed to set a value on different levels, but I'm not being able to set a command duration. Here is the curl call that I'm doing to the server:

curl --location --request POST 'http://<server_ip_address>/haystack/pointWrite' \
--header 'Content-Type: text/zinc; charset=utf-8' \
--header 'Authorization: Basic <authentication>' \
--data-raw 'ver:"3.0"
id,level,val,who,duration
@S.site.GRUPPO1.fan_speed,8,1,"test",50ms

And this is the answer from the server:

ver:"3.0"
levelDis,level,val
"level 1",1.0,
"level 2",2,
"level 3",3,
"level 4",4,
"level 5",5,
"level 6",6,
"level 7",7,
"level 8",8,1.0
"level 9",9,
"level 10",10,
"level 11",11,
"level 12",12,
"level 13",13,
"level 14",14,
"level 15",15,
"level 16",16,
"level 17",17,

The duration just seems to be ignored. I've tried different unit of measurements and to send a raw number with no effect.
Any idea on what I'm doing wrong?
Thank you

Hello, I am using the function haystackInvokeAction for Niagara Points that are not writable. I have been able to invoke actions "set" or "override" with this for Numeric Points, However, when I tried to do the same with Enumeric Point I get an error. the call I am using is: readLink(@p:devServer:r:2df512bd-e60e50c3).haystackInvokeAction(@C.Drivers.NiagaraNetwork.AHU01.points.B173~2d1.points.VavDmprOvrdCmd,"override",{value:"OPEN",duration:1min})

this Enum point has ranges for: OPEN, CLOSE, AUTO on Niagara.

the error I received is:

axon::EvalErr: Func failed: haystackInvokeAction(Obj conn,Obj id,Str action,Dict args); args: (GbRow,Ref,Str,Dict2) axon::EvalErr: Func failed: haystackInvokeAction(Obj conn,Obj id,Str action,Dict args); args: (GbRow,Ref,Str,Dict2)

haystack::CallErr: java.lang.ClassCastException: javax.baja.sys.BString cannot be cast to javax.baja.sys.BDynamicEnum [eval:1]
Can you help me to find a solution?

Thanks,

Carlos

Related to nHaystack v3.0.1+. When performing a read operation such as read?filter=point+and+cur against a large point count N4 Supervisor (as above), we have seen the watchdog timeout get triggered and the station restarts. The watchdog event occurs even when adding the optional and a low value for the limit parameter.

Questions:

1. Is a filter based read operation currently executed on the main engine thread within Niagara?
2. Are there any optimizations to make the read op better here or to ensure the op performs work off the main engine thread?

I'm running nhaystack on Niagara 4.11. Is the batch hisRead functionality supported?

Getting an UnknownNameException: range error.

POST /hisRead

ver:"3.0" range:"today"
id
@123.RmTmp
@123.RmRh

https://project-haystack.org/doc/docHaystack/Ops#hisRead