Value Retrieval Method should read integer value of Digital tag, not string
If you try to do Value Retrieval Method (like Min) of a Digital type tag, you will get an error saying non-numeric data. AF should be smart enough to realize that the data is actually a set of integers and not try to read the string representation.
I support this idea. The numeric order of the states does not necessarily have to apply to any real-world scenario for this feature to be valuable. Things like averages and totals for binary 0/1 attributes would be extremely useful for things like downtime % and fault count.
If there is an issue with the states' numeric order not reflecting any real-life sequence, then the end user can account for this in their analytics. Such a concern should not discourage development of this feature.
I would vote against this idea. While it is possible to create a state set where the numeric order aligns with a notion of "min" and "max" for states in relation to each other, this is not a requirement of state sets. I have seen some state sets where a given state is not higher than or lower than another - it just happens to have a certain integer code that may be greater than or less than another.
In the purest sense, digital state sets are simply a finite set of choices that happen to be stored by some integer. Just like with SQL table keys, that integer is not supposed to be meaningful data.
I support this idea. The numeric order of the states does not necessarily have to apply to any real-world scenario for this feature to be valuable. Things like averages and totals for binary 0/1 attributes would be extremely useful for things like downtime % and fault count.
If there is an issue with the states' numeric order not reflecting any real-life sequence, then the end user can account for this in their analytics. Such a concern should not discourage development of this feature.