I'd like to propose making the cur and his tag a scalar and possibly introduce a scalar write tag.

I'd like to have consistent tags for the remote identifier for connected points. Currently each connector has a proprietary tag to hold its remote identifier.

In haystack the remote ref is stored in haystackCur and haystackWrite tags. In bacNet the object identifier is stored in bacnetCur and bacnetWrite tags.

In addition to the {conn}Cur tag, the point also has a cur marker tag. The cur tag could support both purposes where the haystack ref or bacnet object identifier could be stored in a cur tag; and if that tag is a marker then it holds a local value instead of a remote one.

We could use write or the existing writable tag in the same manor; and maybe even the his tag.

I think this may also enhance queries for connected points.

I concur. Or should I say, I cur. :)

It's important to note that those conventions aren't part of Project Haystack per se today. Rather they are conventions we use in the Haxall connector framework as documented here. However, if we create a community repository for equipment templates, then this issue will potentially become a standards issue.

I don't think we would want to change cur from a marker to a value because it's important to create conjunct types used to anchor other tags. But you could also effectively do the same thing with a generic curAddr, writeAddr, and hisAddr tag.

I appreciate the simplicity of that approach, but in my opinion is has a large number of downsides:

• the types, definitions, and validation rules for protocol addresses vary widely across protocol types and you would lose the ability to attach all that metadata to a tag name. Overloading all that important meta-data into a generic address tag isn't possible
• you still are required to have unique connector specific tags for fooConn and fooConnRef (you can't make that generic). So you aren't going to make your application logic much simpler
• if we do templates, then I personally think its going to be more intuitive to see bacnetCur vs modbusCur for addressing (and in some cases you might want both)

A generic curAddr, writeAddr, and hisAddr also sounds good.

1. Couldn't we expand types, defs, and validation rules to be app specific? Where even metadata for a tag can vary depending on the application consuming it or the namespace its operating in.
2. That was the next question, can we simply use connRef instead of the proprietary tag of {connName}Ref. With connRef I could do a simple query to find all connected points. and instead of requiring a specific conn marker tag such as haystackConn, use the conn tag to hold the symbol name of the connector. Such as conn = connector:haystack which could be defined by a def and queried.
   • and we still could find all of a certain type of connected point by using a filter like connRef->conn == "connector:bacnet"
3. the generic curAddr and connRef approach would eliminate the possibility of having two connectors affect the same point. Wouldn't this be a bit confusing? or are there applications that do this.
   • For templates, wouldn't it help to keep the connector abstract so that a template can be applied to a connected device regardless of the protocol.
     • Where some devices may support multiple protocols and two different installations may implement different protocols but could use the same template.
     • Where connRef is simple to define and we can have separate rules to define the point's address based off of the connector. Maybe the template has a list of meta data attached to configure the points based off of the connector its being applied to.

Having the validation available in the def would be pretty cool. So I now see the benefit of having fooCur.

Sounds like Michael has an idea to make defs app specific (his #1 above) but sounds like a big deal and entirely new conversation.

you still are required to have unique connector specific tags for fooConn and fooConnRef (you can't make that generic)

Why can't fooConnRef always be connRef? It's always going to be a ref, what other meta do we need in this case? The conn will always have a conn marker in addition to fooConn. As Michael said this would ensure a point is connected to only one conn.

People do use two connectors on the point. More importantly it is a pretty overwhelming convention to use unique marker tags for unique "types" even when there is a common base type. So the current convention of having both "fooConn" and "conn" is pretty consistent with all prior art for Haystack modeling.

Although in other work the current convention is starting to become ungainly where we might end up with something like "primaryChilledWaterSystemRef". So we might end up needing a new mechanism with a bit more abstraction.

Are you saying people use two connectors on a point simultaneously? That the point history is written by two connectors? What is the real world scenario here?

Are you saying people use two connectors on a point simultaneously?

Yes - one connector for current values and a separate connector for historical data (such as real-time values from BACnet and historical data from a central SQL database)

I've had several instances where I use SkySpark like a babel fish, reading point data from a Modbus point and writing it to a BACnet point. In cases like this, the SkySpark point will have both modbusCur/modbusConnRef and bacnetCur/bacnetConnRef tags.

Great examples, thank you both. That closes the thread in my opinion.

Not sure you have convinced me to be polyconnamous but it's a good design for those that are!

I was away on vacation and love the dialog here. Thanks Brian, this makes total sense.

Question about these installations where multiple connectors affect a single point: is this typically practiced with retrofit or legacy integrations? or is this method also used for new installations?

I've had to use this technique in both legacy and new projects. It's not typical, but is useful when dealing with unusual circumstances or network structures.