Is patching fanMode display labels acceptable for WWST certification, and what are the alternatives?

Apps & Clients SmartThings (Samsung Connect)
1

Hello,

I’ve been asking quite a few questions lately — thank you for your patience.

Our device uses SmartThings Direct Connect, and through a recent thread I learned that WWST certification is required to commercially launch a product with SmartThings integration. We’ve decided to remove our Custom Capabilities and pursue WWST certification instead.

Before moving forward, I’d like to confirm whether our current use of the fanMode capability could cause any issues with WWST certification.

Our device has the following operation modes: Manual (user-controlled fan speed), Temperature (auto fan speed based on temperature), CO2 Detection (auto fan speed based on CO2 level), Dust Detection (auto fan speed based on particulate matter), and Cycle Vent (periodic on/off cycling).

image
image1497×1487 218 KB

To represent these modes in SmartThings, we’re using the standard fanMode capability with patched display labels, as shown below:

{
        "component": "main",
        "capability": "fanMode",
        "version": 1,
        "values": [],
        "patch": [
          {
            "op": "replace",
            "path": "/0/label",
            "value": "Operation Mode"
          },
          {
            "op": "replace",
            "path": "/0/list/command/alternatives",
            "value": [
              { "key": "auto",   "value": "Manual",       "type": "active" },
              { "key": "high",   "value": "Temperature",  "type": "active" },
              { "key": "medium", "value": "CO2 Detection","type": "active" },
              { "key": "low",    "value": "Dust Detection","type": "active" },
              { "key": "turbo",  "value": "Cycle Vent",   "type": "active" }
            ]
          },
          {
            "op": "replace",
            "path": "/0/list/state/alternatives",
            "value": [
              { "key": "auto",   "value": "Manual",       "type": "active" },
              { "key": "high",   "value": "Temperature",  "type": "active" },
              { "key": "medium", "value": "CO2 Detection","type": "active" },
              { "key": "low",    "value": "Dust Detection","type": "active" },
              { "key": "turbo",  "value": "Cycle Vent",   "type": "active" },
              { "key": "off",    "value": "Off",          "type": "inactive" }
            ]
          }
        ],
        "visibleCondition": {
          "value": "fanMode.value",
          "operator": "ONE_OF",
          "operand": "[\"auto\",\"high\",\"medium\",\"low\",\"turbo\"]",
          "component": "main",
          "capability": "fanMode",
          "version": 1,
          "hideOnUnmatch": false
        }
      },

We are not changing the capability ID or attribute keys — only the display strings via patch.

With that context, I have the following questions:

  1. Does renaming the fanMode display values via patch cause any issues for WWST certification?
  2. If it does, would using the mode capability instead be acceptable?
  3. If mode is recommended for operation modes, we have a conflict — we’re already using mode for cycle preset selection (e.g. 1h10m, 1h20m, etc.). Is there another standard capability suitable for a list-based preset selector? (This question only applies if the answer to question 1 is that fanMode patching is not allowed.)

Thank you.

2

Hi @JohnJo

Our engineering team reviewed the behavior and recommended using the “mode” capability instead of modifying the default labels for the “fanMode” capability.

This is because the WWST certification test cases are designed around the default capability labels and enum values. In contrast, the “mode” capability allows partners to define their own custom mode values, which should not cause issues during the WWST certification process.

3

Hi @Itati

Thank you for the clarification! Using the mode capability instead of fanMode makes sense.

However, I’m already using the mode capability for a different purpose — cycle preset selection (e.g. 1h10m, 1h20m, etc.). So I have one more question: is it possible to use two separate instances of the mode capability in a single device profile?

I’ll test this on my end as well, but I’d appreciate an official answer before moving forward.

Thank you!

4

Yes, this is possible, but it would require adding a new component that includes the corresponding capability.

5

Thank you! I’ll proceed with this approach, and if any issues come up, I’ll open a new topic.

Closing this topic for now. :slightly_smiling_face: