Hi,

Actually, in the implementation of the module, enum histories aren't identified by a "kind" tag.

In haystack, does enum values must be treated as string ? Or is there an "enum" kind available ?

Enum can be integer (0-255). This integer, via a facet can be "renamed" (example : LOG_OFF, LOG_ON, LOG_NULL instead of 0,1,255).

Opinions ?

Yeah, we haven't done anything specific for enums. They are sort of a odd corner case because they don't come up that often compared to true analog or digital data. But they do happen. I sort of like just treating them as numbers versus making a whole new special case, maybe just add a tag to map numbers to their string names. Or we could come up with a proposal to make enums their own first class kind if everyone in the community preferred that approach.

Tipically, from my point of view, enum are used to generate states, wich are most of the time, strings (ex.Auto[0] - Cool[1] - Heat[2]). If we treat them as number, we'll probably loose something when transferring the data. I've seen systems wich were unable to read text tag of enum variables in bacnet and it was hard to follow. (is Alarm 1 or 2 ?, what was the mode for state #5 cooling or heating).

That's why, my vote would be to deal with enum as string, using the existing HStr.

I've been thinking about this for a while now. I'm still not sure I have a opinion on the right way to model enum/multistates. Here are the options as I see them:

1. model them as numbers with some meta data about how to interpret the ordinal numbers
2. model them as strings
3. create some new first class enum type

I discount option C because it adds a lot of complexity for what I consider sort of a 5% use case.

Option A is easy and leverages existing optimization that most BMS systems probably already handle for efficient storage/compression of history/trend data.

But I'm sort of leaning towards option B. By just always encoding the actual string value it provides a lot of self-annotation for exactly what the data means. For most use cases that extra overhead isn't a big deal. That is the way I've been considering a curStatus tag (such as oBIX status attribute). But when it comes to storage of enums in a historian, it makes things more complex - I've been trying to get my head around that from SkySpark's perspective to ensure an efficient compression.

If go option B route, then I think we would just annotate a multi-state/enum point as kind of Str. But the expectation was that the value was of a limited range which maybe is declared in another tag like range. For example:

point
kind: Str
range: off, slow, fast

We could use that tag for boolean points too:

point
kind: Bool
range: off, on

I think we probably should go ahead and make a decision on this. So here is my proposal:

1. Enumerated or multi-state points should define a kind tag with a value of "Str"
2. Current and historical values should use Str value types
3. We add a new tag called enum which is defined a comma separated list of the an enumeration's range. This tag is applied to to a Str point or may be applied to a Bool point in which case the value should be "false,true"

So a multi-state point might look like this:

dis: Fan Speed
point
kind: Str
enum: off, slow, fast

Or if you wanted to add display names for a digital point:

dis: Fan Cmd
point
kind: Bool
enum: off, on

I agree with the proposition.

I agree with this proposition as well.

I agree with this proposal.

I also agree and am working on incorporating it into the axhaystack module along with a couple of improvements suggested by Christian.

Cheers, Richard