A curStatus tag can have any one of the following values:

ok
fault
down
disabled
unknown

whereas a Niagara AX Status value can have any combination of the following values, represented as a set of flags (except "ok" indicates that no other flags are set):

ok
disabled
fault
down
alarm
stale
overridden
null
unackedAlarm

There is a bug in NHaystack at present, in that it will report the values "alarm", "stale", "overridden", "null", and "unackedAlarm" as the value of a curStatus even though they are not part of the haystack spec.

I'd like to propose the following approach to translating AX Status values properly. For each AX Status, NHaystack will check certain flags in the following order. If it finds that the flag is set, it will return the mapping that is shown on the right.

ok       ==> { curStatus: "ok"       }
disabled ==> { curStatus: "disabled" }
fault    ==> { curStatus: "fault"    }
down     ==> { curStatus: "down"     }
null     ==> { curStatus: "unknown"  }

For all other AX Status flags, the curStatus value will be set to "ok", and a camel case marker tag will be added as well:

overridden   ==> { curStatus: "ok", axOverridden   } 
alarm        ==> { curStatus: "ok", axAlarm        } 
stale        ==> { curStatus: "ok", axStale        } 
unackedAlarm ==> { curStatus: "ok", axUnackedAlarm }

If more than one of those four flags is set, there will be more than one marker tag:

overridden,alarm ==> { curStatus: "ok", axOverridden, axAlarm } 

Does this approach look reasonable? Does anyone have suggestions for improvement?

You have my vote for this.

Just curious as to the use case for the ax marker tags.

If your wanting the curStatus and you are not using an AX system, then you would reference the haystack value "ok", "disabled", "fault", "down", and "null", but if you are using an AX system you would reference the marker tags instead?

I say either create an ax tag for each status or get rid of them all together.

i.e.

ok ==> { curStatus: "ok", axOk } disabled ==> { curStatus: "disabled", axDisabled } fault ==> { curStatus: "fault", axFault } down ==> { curStatus: "down", axDown } null ==> { curStatus: "unknown", axNull } overridden ==> { curStatus: "ok", axOverridden } alarm ==> { curStatus: "ok", axAlarm } stale ==> { curStatus: "ok", axStale } unackedAlarm ==> { curStatus: "ok", axUnackedAlarm }

Of course then when AX throws more than one status at the same time, you would get the multiple marker affect.

disabled,down,stale ==> { curStatus: "disabled", axDisabled, axDown, axStale }

Just a thought.

EDIT: That post came out all garbled. Hope some sense can be made of it.

I see your point, and that was the first way I though of doing it. However I was worried that I would be cluttering things up with a bunch of "ax" marker tags that restated the same information that is conveyed by the curStatus value.

It has been my experience that only one of disabled, fault and down ever show up in practice in an AX system, even though in theory it is possible for them to co-exist.

So what I was attempting to accomplish with my design is provide a clean mapping when I know there will be a one-to-one correspondence, and for the those status flags that can appear together, just claim that they are "ok", but provide extra marker tags to bring the rest of the AX state over.

In particular I have had a request to provide some indication that a point was overridden, and since that turned out to be a surprisingly complex topic, I thought that a simple "axOverriden" tag would suffice for now.

I think the basic strategy is good. This provides an immediate Niagara solution, but doesn't conflict with what we have formally defined so far in Haystack. And I'm sure at some point in near feature those other conditions (overrides, alarming, etc) will be defined and we want to ensure we are future proof for that work.

Assuming we want to map the Niagara status then the two options seem to be:

1. map each enumerated value to an axFoo marker tag (your proposal)
2. map status to axStatus: "foo" string tag

For some reason option 2 seems better to me for two reasons: it is easier for client code to check one tag and its parallels curStatus more consistently.

One other thought I have is that all of the Niagara specific tags are getting prefixed with "ax". What happens when this code is ported to Niagara 4? The "ax" prefix will be a little confusing, but I think we have to stick with it because a lot of people are already starting to depend on it. But before we declare that ship sailed we might want to have a discussion on it: should we use ax prefix or pick another prefix (even if it means a breaking change).

What I don't like about option 2 is that it makes it harder to query for overridden points. If a point is both in alarm and overridden, then its axStatus tag would be "alarm,overridden", so you could no longer query for "point and axStatus == "overridden"". We do not currently have the ability to query for contains() or startsWith(), etc on strings.

Note that in my original proposal I'm not saying that there will be e.g. an "axOk" tag, since I'm only proposing that there be extra AX marker tags for those cases where more than one tag can actually occur. Christopher was proposing that we do "axOk" etc, etc but I'm lukewarm to the idea. If we choose option 1, then what are your thoughts on Christopher's proposal? It does have the virtue of being simpler to explain than mine.

I take your point about the "ax" marker prefix being potentially confusing once Tridium's N4 project ships. I suppose we could come up with a more neutral prefix, but I'm hesitant to make a breaking change, and we could perhaps solve that issue with some documentation.

One thing that Tridium is doing differently with the new Tag Api in N4 is that tags can have a namespace prefix, e.g. "ns:device" or "h:equip". These prefixes will be defined in each of potentially multiple Tag Dictionaries, one prefix per dictionary. It will apparently be possible to bless one of the tag dictionaries as not needing a prefix, so for instance the Haystack Tag Dictionary could be assumed to not have the "h:" prefix.

But that still leaves us with a problem because "ns:device" is not a valid tag name currently. We will have to figure out how to translate that. I assume that we will probably not want to introduces namespaces ourselves, that would be a really big change.

There are probably some other things that will crop up as well when porting NHaystack to N4. For one thing we will have to start shipping two jars with each build, due to the breaking changes in the javax.baja API that Tridium announced last week.

I think in oBIX we made status an enum, but yeah in Niagara since you can multiple status flags active at one time your design makes more sense.

I would say you do not duplicate what we already have in curStatus - no reason to be more verbose than necessary.

Lets use this as an example. This device is currently down and disabled. In haystack, which status will it display? down or disabled? Since haystack according to what I understand, can only display one status at a time, the logic will have to choose one or the other. Perhaps the last status thrown? In any case, If haystack only shows one or the other status, the other status will get dropped. Because there is no axTag assigned to either of these status values, there will be no indication of the other status. In my opinion, this indicates a broken status that does not fully display the current status of the device. With what is mentioned above, you will be able to display some of the axTags, but not all of them. This doesn't make it very useful.

I agree that axOk will not be very useful except for standardizing all of the tags.

Am I missing something?

This device is currently down and disabled. In haystack, which status will it display?

By definition disabled implies there is no communication (ie down), so you aren't losing any information.

The status really is three exclusive conditions:

• ok: active successful communication
• disabled: communication disabled
• down or fault: unsuccessful communication (down means you know its a network problem and fault means something else like config error)

We did the same thing in oBIX - although there even though there was potential non-exclusive conditions we picked most important one down. I don't actually think we should do that in Haystack. But in this case I think the conditions are exclusive, so its ok.

This has been some good feedback. Here's what I'd like to propose to wrap up this discussion.

For each AX Status, NHaystack will check certain flags in the following order. If it finds that the flag is set, it will return the mapping that is shown on the right.

ok       ==> { curStatus: "ok"       }
disabled ==> { curStatus: "disabled" }
fault    ==> { curStatus: "fault"    }
down     ==> { curStatus: "down"     }
null     ==> { curStatus: "unknown"  }

In addition, if the AX Status value is anything other than "ok", then ax-prefixed tags will be added as well. For example, if the AX Status is "overridden", then an axOverridden tag will be added, and if the AX Status is "disabled,down", then an axDisabled and axDown tag will be added.

I think this covers everything that was brought up in this thread.

That makes sense. Sounds good to me.

One thing that we've run into while attempting to implement the suggestions in this discussion for NHaystack, is that we need to formalize how these "extra" status tags get passed back during COV changes. We are hesitant to start passing all these miscellaneous tags like axOverridden with every COV.

What we really want to do is re-open the discussion of why curStatus behaves as it does. I wish there were some way to express that a point was overridden in standard haystack tags rather than these ad-hoc ax Tags.