Items with states defined do not do any limits checking. This has been the default behavior for a long time but it's a bit unexpected. If you define a limits range and then define a single state for a particular error code I wouldn't expect my previously defined limits to not be used.
I think the logic should be to first check states for state colors and then apply limits if no state color was applied. This would allow states to be used in conjunction with LIMITS.
The text was updated successfully, but these errors were encountered:
@ryanatball I checked the code in packet.rb and we check for if item.states and try to find a state key based on the value. If not we run apply_format_string_and_units which is exactly what we do to non-state values. I think an item with STATES should not allow LIMITS, LIMITS_RESPONSE, FORMAT_STRING or UNITS and should return the same string for CONVERTED, FORMATTED, and WITH_UNITS. RAW would return the raw value as usual. Thoughts?
If it has any states it could sometimes come back as a string and thus we should probably format it as a string all the time. Otherwise you wouldn't be able to handle it in a database. So maybe we just take a hard line and say no LIMITS with STATES. If you really want limits then apply the limits. If you have some weird state value you want to flag then use a derived telemetry point which reads the value and applies the state.