Justification: Test Profile: 88S-C-04 does not align test and required responses. Two random "5." Clarification needed on Fan Only Mode with (fan speed) if fan speed may be adjusted based on set points.

Friday, May 29, 2026 | 10:52am
Attachment Size
6.16.14.8 Profile 88s.docx 17.61 KB
You must be logged in to comment. Log in
7 comments

Nick Irons Member for 2 weeks 6 days

  • For the 88S-C-04 updates here are my notes:
    • Required Response 4 and 5 are missing "Same" at the beginning of the result to be "Same as Step 1..."
    • Test 5 adds nothing new outside of cooling the temperature sensor, but the Required Response to 5 will never generate a fail. The result states "may be allowed to decrease". If the fans must shut off when in automatic and at set point that should be the result of the test. If fans should stay active in fan only mode & automatic, then that should also be the intent. If neither are the case as there's no requirement for either side, then this test should be removed entirely.

       

Martin Perlot Member for 9 months 2 weeks

For Response 5, the failure conditions would be 

  • The unit does not start at 100%
  • The fan speed and temperature do not decrease together.  

The first case duplicates Response 1's failure condition, but I think the inclusion is tolerable as it clarifies the test.  However, there is one subtle problem.  There is particular reason for the RVIA to specify 5 degrees as the point where the fan should run at 100%.   If a vendor wanted to make a AC that didn't go full-speed until 6 degrees, the protocol should not object.  However, 5 degrees is a pretty big number in this context, so I doubt that it's worth complicating the description with a more general term.

The second condition is pretty unlikely to ever be a problem in the field.  It's hard to imagine a coder using a formula for fan speed that wasn't monotonic.  But the sub-test is still valuable as guidance for programmers unsure about how to report the status.  

As always, any ideas for how to describe it better are appreciated.

Lucas Salviano Member for 1 month 2 weeks

Hi,

Some points about the changes:

  • ID 88S-C-04:
    • Test 3:
      • "3. Same as Step 2.".
      • Justification: If the temperature is higher than the set-point and the fan is at auto speed the fans must turn off.
    • Test 5:
      • Keep note about Thermostat command:
        • "Note that THERMOSTAT_STATUS_1 Fan Speed shall be 0 (Automatic)."
      • Justification: We understand that this test doesn't have a failure condition, but it can be used to test the algorithm implemented for Fan Speed Auto (if it exists).

Points not related to the modifications, but in section 6.16.14.8. (Let me know if it would be better to start a new thread).

  • Introduction:
    • "During the delay, AIR_CONDITIONER_STATUS should be sent with Max Output Level 0 (0%) and Output Level 0 (0%)."
    • Question: Why is the "Max Output Level" changed to 0 when the load is in protection delay? Is this related to the state of the compressor and not about the compressor output capacity? (usually 100% or different values in special conditions, e.g. Eco Mode).
  • ID 88S-C-05:
    • Test 1:
      • "1. THERMOSTAT_COMMAND_1 is sent with Operating Mode = 4 (Fan Only), Fan Mode 1 (On), Fan Speed 0 (Auto)."
    • Justification: The description about this field behavior is:
      "Note that this is different than the “Fan Only” above. This forces the fan to be on all the time, but allows the heat and cool turn on and off according to the Operating Mode".
      Off Mode not operate any cool or heat operation, it does not make sense to operate the fans if the intention is to turn off AC all loads.

Martin Perlot Member for 9 months 2 weeks

Regarding Max Output Level :  This is intended to indicate the maximum output level enforced upon the AC for reasons unrelated to the Thermostat.  That can be due to power constraints, compressor protection, or pretty much anything.  It's a crude mechanism, but it allows a smart thermostat some ability to anticipate the AC behavior, particularly when managing multiple AC units.  There is a good argument for adding additional details to clarify the source of the limitation, but so far no AC builder has proposed any.

Regarding Fan Only mode:  There are many reasons to run the fans without the compressors.  In a multi-zone RV, There may be AC power available to run, say, one compressor but multiple fans, and the additional air movement can make the cabin more comfortable.  When leaving the coach in humid conditions, running the fan constantly can reduce mold, mildew and general stuffiness without draining the batteries overmuch.  In cold weather, the AC fans can spread the heat more effectively than the furnace alone.

Lucas Salviano Member for 1 month 2 weeks

Hi Martin,

I understand about the maximum output level and I agree with your point of view. This limitation can be set by a thermostat or by the control board itself, according to a protection or equivalent condition.

Related to Fan Only  in ID 88S-C-05 test 1 is about running the fans in Off Mode it seems that this is legacy of Roof Fan Fan Mode parameter (ROOF_FAN_COMMAND_1 - DGN 1FEA6h), my point is if desired turn on only the fans without compressor, the unit must be set with THEMRMOSTAT_COMMAND to Mode: Fan Only and not  Mode: Off with Fan Mode: On, since in Mode: Off all AC loads must be off (It seems something like press the power button in a TV controller and the speakers keeps on, just the screen turn off).

Let me know what you think, maybe this deserves a notation in THEMRMOSTAT_COMMAND Fan Mode field to clarify the correct behavior, if we align something I can suggest it.

Martin Perlot Member for 9 months 2 weeks

Did you see this submission (https://www.rvia.org/rv-c/1631/6162-thermostat-status-1-version-3)?  It hasn't made it to the full document yet and it's meant to clarify this particular issue.  With RV-C, I'm probably not the best judge of  clarity, so if think that there can be further improvement in the explanations, I won't try to dissuade you from writing up an edit.

As for the fact that it requires multiple fields to describe the desired state, that's something we see in many other places in the protocol.  If all the fields are in the same DGN, it's generally harmless (and often logically necessary).  In some cases it can introduce some ambiguity, as we generally leave it to the vendor as to how the device should handle impossible combinations (e.g. does the device reject new settings that contradict the existing state, or does it make a 'best effort' to implement the new setting?).  In real life this is a non-problem, as there is a general understanding that devices shouldn't be sending impossible commands in the first place.

Lucas Salviano Member for 1 month 2 weeks

Hi Martin,

Good catch, we discuss this point about Fan's behavior in the past on the submission that you shared. So, I think that is enough to clarify the behavior to the user.

For now, I don't have any more contests on this current submission.