SET_COMMAND_RESPONSE TIMER_ACK - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · November 2nd, 2018

I realized I should have given an example in my prior post:

In several of my implementations I have a mix of sensors. Some of the sensors are GET'able and SET'able, but others are GET only. This drives the Automated test suites crazy, and they return lots of warnings.

Sometimes it makes sense to SET a sensor. Let's say you have a fog machine that measures the heater current, and tracks MIN/MAX current. For that sensor, you can use SET to reset the min and max values.

But for the Fog Fluid Level sensor there's nothing to set. It's reading a physical level, and doesn't track min/max. SET'ing that sensor doesn't do anything, so it's appropriate to NACK it.

In cases like this it's legit to NACK SET for some sensors, and ACK it for others. I could "fix" the test suite warnings by always ACK'ing SET, but that would be misleading since the SET didn't actually do anything.

November 2nd, 2018	#19
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	I realized I should have given an example in my prior post: In several of my implementations I have a mix of sensors. Some of the sensors are GET'able and SET'able, but others are GET only. This drives the Automated test suites crazy, and they return lots of warnings. Sometimes it makes sense to SET a sensor. Let's say you have a fog machine that measures the heater current, and tracks MIN/MAX current. For that sensor, you can use SET to reset the min and max values. But for the Fog Fluid Level sensor there's nothing to set. It's reading a physical level, and doesn't track min/max. SET'ing that sensor doesn't do anything, so it's appropriate to NACK it. In cases like this it's legit to NACK SET for some sensors, and ACK it for others. I could "fix" the test suite warnings by always ACK'ing SET, but that would be misleading since the SET didn't actually do anything.