Question about resetting sensors

[nomis52]

The standard states:

"The SET_COMMAND may be used in conjunction with SENSOR_VALUE to reset or clear a given sensor. When a sensor is successfully reset the values for Present, Lowest/Highest, Recorded values in the response message shall all be equal. "

What does this actually mean? I'd read that to say that at the moment of resetting, the current value should be copied into present and lowest, highest & recorded set to the current value.

But further in the standard it states:

"Recorded Value:
... Support for this data is optional. If this value is not supported, then this field shall be set to 0x0000.
"""

The same text is used for highest & lowest as well.

So if the responder doesn't support recording values or highest / lowest, what should the value of the recorded/highest/lowest field be? This is one of the last tests I need to write and I'm having a hard time deciding what behavior to expect.

There is the separate issue of what to return when all sensors (0xff) have but that's been discussed before.


Simon

[ericthegeek]

What does this actually mean? I'd read that to say that at the moment of resetting, the current value should be copied into present and lowest, highest & recorded set to the current value.


I concur with that interpretation.


"If this value is not supported, then this field shall be set to 0x0000."
...
So if the responder doesn't support recording values or highest / lowest, what should the value of the recorded/highest/lowest field be?


The bitfield in SENSOR_DEFINITION tells you if high/low and recorded values are supported, so most controllers should ignore whatever values are in high/low and recorded if those bits are not set.

The 0x0000 rule is not in E1.20-2006. I believe it's part of what will probably become '-2011. Still, it's probably best for responder to fill unsupported sensor fields with 0x0000 just to be sure.

[nomis52]

The 0x0000 rule is not in E1.20-2006. I believe it's part of what will probably become '-2011. Still, it's probably best for responder to fill unsupported sensor fields with 0x0000 just to be sure.

What's the state of the -20XX version? Can we get the contradiction removed before it's standardized?

[ericthegeek]

Any changes would be very disruptive at this point. It would have to be recalled from ANSI, and would probably delay the document by a year or more.

I'd consider this issue to be more of an Errata than a full stop. I think it's unlikely to be misinterpreted. A controller has two ways to know that the data isn't supported.

[sblair]

The 2011 version is beyond change at this point. It basically means starting the process all over again.

We did make changes in the 2011 version in this area. The following sentence was added to Lowest and Highest Detected values as well as the Recorded Value: "If this value is not supported, then this field shall be set to 0x0000."

As Eric said, a controller can determine whether a responder supports the functionality by looking at the bit field in the Sensor Definition message and if they are not supported then we have explicitly said what the fields should stuff now.