Dacor column refrigerator/freezer — samsungce.sabbathMode declared but has no OCF resource (device returns NOT_FOUND)

Devices & Integrations
1

I have four Dacor column appliances on SmartThings and I’m trying to automate Sabbath mode. It works correctly via the physical button sequence on all four, but it is not reachable from the cloud/API on any of them. I’ve done a fair amount of API-level diagnosis and I think I’ve isolated the root cause, so I’m posting the findings in case they’re useful to others and in the hope that someone from Samsung can route this to the right team.

Existing support case: sconnect-26090210048

The setup

The four appliances split into two groups running completely different integrations.

Group A — freezers (model DRZ36980LAP/DA)

  • Device profile: d9f70a77-5b29-3bf2-b95a-d478be32a07f
  • Presentation ID / vid: DAC-REF-NORMAL-01001
  • mnmn: Samsung Electronics
  • Model: TP2X_REF_DACOR_20K
  • OCF firmwareVersion: A-RFWW-TP2-21-COMMON_20220110
  • WiFi module software: 02144A220110
  • Micom firmware: 1908160A,17091902
  • Driver version: 26070101

On these, samsungce.sabbathMode is declared on the main component, but it appears in custom.disabledCapabilities, and both supportedActions and status return null.

Group B — refrigerators (model DRR36980RAP/DA)

  • Device profile: 9a0ad552-a7ea-3fb4-a657-4836c69e558f
  • Presentation ID / vid: DAC-REF-NORMAL-100001
  • mnmn: Dacor Electronics
  • Model: 16K_REF_B_LCD_T9000
  • Driver version: 22083101

On these, samsungce.sabbathMode doesn’t appear at all. The main component exposes only nine capabilities and reports no mnfv, mnpv, or mnos values — this looks like a legacy Dacor cloud connector rather than the OCF/TizenRT stack the freezers run.

What I tested

Capability-level commands against samsungce.sabbathMode return HTTP 422. Rather than stop there, I used the execute capability (which is not in the disabled list on the freezers) to query the OCF resource tree on the appliance directly.

Sabbath-named resources — device returns NOT_FOUND:

/sabbath/vs/0        -> HTTP 422, "response code is NOT_FOUND"
/sabbathmode/vs/0    -> HTTP 422, "response code is NOT_FOUND"
/sabbath/mode/vs/0   -> HTTP 422, "response code is NOT_FOUND"

Resources that do exist — device responds normally:

/mode/vs/0           -> HTTP 200, status COMPLETED
/mode/0              -> HTTP 200, status COMPLETED

I also tried writing sabbath values into the mode resource:

POST https://api.smartthings.com/v1/devices/{deviceId}/commands
{"commands":[{"component":"main","capability":"execute","command":"execute",
  "arguments":["/mode/vs/0",{"x.com.samsung.da.modes":["SABBATH_ON"]}]}]}

I tried SABBATH_ON, SABBATH, SABBATH_MODE_ON, HOLIDAY_ON, and SABBATH_ENABLE. All five returned ACCEPTED (not COMPLETED) with no state change on the appliance. Note the asymmetry: reads against real resources come back COMPLETED, but these writes only ever reach ACCEPTED — queued by the cloud, never acknowledged by the device. /mode/vs/0 reports supportedModes: [HOMECARE_WIZARD_V2, ENERGY_REPORT_MODEL], with nothing sabbath-related.

The part I think is conclusive

The samsungce.driverState attribute on these freezers contains a full dump of the OCF resource tree the appliance publishes — /alarms/vs/0, /temperatures/vs/0, /defrost/delay/vs/0, /icemaker/one/vs/0, /drlc/vs/0, and so on.

There is no sabbath resource anywhere in it.

So the capability is declared in the device profile, but there’s nothing in the appliance firmware for a command to land on. That explains the 422s, the null attributes, and why it sits in disabledCapabilities.

Why the standard troubleshooting doesn’t apply

Support asked me to remove and re-add the appliances. I don’t think that can help: custom.disabledCapabilities is a status attribute with a live timestamp that the device republishes on every refresh — mine updated today. It isn’t a stored cloud setting that re-pairing would clear. The device would republish the identical list within seconds, and I’d lose room assignments and automations for nothing.

Firmware is also current — newVersionAvailable returns false on all modules for both freezers.

What I’m asking

Is anyone able to route this to the appliance team as a firmware + device profile issue rather than a configuration one? As far as I can tell the fix requires a WiFi module firmware update that implements the sabbath OCF resource, followed by a profile update to enable the capability.

And a question for the community: has anyone gotten Sabbath mode working over the API on any Samsung or Dacor refrigerator? If there’s a model where it does work, comparing its driverState resource list against mine would confirm whether the resource path simply differs from the ones I guessed.

Happy to provide full device JSON exports, request IDs, and timestamps to anyone from Samsung who wants them.

2

from observations I have made over the years: ST staff that use to monitor the forums did not communication with other teams (such as the app team or the appliance team) and would ask you to go through Customer Support. Long story short - the ST Staff who did monitor the forum are gone now.

3

Thanks — that’s genuinely useful context, and it saves me from waiting on something that was never going to arrive. I’ll keep pushing on the support case and ask for a formal escalation there instead.

I’ll leave this thread up for the other half of the question, which is really the part I’m still hoping someone can answer: has anyone here got Sabbath mode working over the API on any Samsung or Dacor refrigerator?

My read is that the capability is declared in the device profile but there’s no matching OCF resource in the appliance firmware — the samsungce.driverState dump on my freezers lists every resource the unit publishes and there’s nothing sabbath-related in it. But I guessed at the resource paths (/sabbath/vs/0, /sabbathmode/vs/0, /sabbath/mode/vs/0) and all three came back NOT_FOUND, so it’s possible I simply never hit the right one.

If anyone has a model where it does work, comparing your driverState resource list against mine would settle it either way

4

This is exceptional diagnostic work - genuinely more thorough than anything I’ve seen on this elsewhere, and it directly answers a question I couldn’t answer with confidence before.

To your question: yes, I have a confirmed-working example. One of my testers has a Samsung fridge (model RF71DB965E22ML, presentationId DA-REF-NORMAL-01011 - not a Dacor unit, standard Samsung line) where samsungce.sabbathMode commands genuinely work over the API - verified via a real on command that actually changed the appliance’s physical state, not just an ACCEPTED response.

Pulling the samsungce.driverState OCF resource dump from that working unit, it does include a sabbath resource, at this exact path:

{
  "href": "/sabbath/vs/0",
  "rep": {
    "x.com.samsung.da.sabbathMode": "Off",
    "href": "/sabbath/vs/0"
  }
}

So the resource path you guessed (/sabbath/vs/0) is correct - it’s real and it’s what the working firmware actually publishes. On the working unit it also is NOT present in custom.disabledCapabilities, consistent with your finding that its absence there tracks directly with whether the resource exists in firmware at all.

This lines up exactly with your conclusion: it’s not a config or capability-declaration issue, it’s that the resource genuinely doesn’t exist in your units’ firmware yet. Given the working unit’s WiFi module firmware and driver version are different from what you listed for your freezers, this really does look like something that needs a firmware update on Samsung’s/Dacor’s end specifically to add that OCF resource, not something fixable from the API-consumer side.

Hope this helps get it routed to the right team - happy to share the full (redacted) driverState dump from the working unit if useful for comparison.

5

Shai,

The detail that matters most to me: /sabbath/vs/0 was one of the three paths I probed, and it returned NOT_FOUND on my freezer. So the path was right and the resource genuinely isn’t there. That was the one alternative explanation I couldn’t rule out on my own.

Your second point is the other half of it. If samsungce.sabbathMode is absent from custom.disabledCapabilities on the working unit, that confirms the disabled list isn’t an arbitrary config flag — it tracks whether the firmware resource exists. Which is why re-pairing was never going to help me: the device republishes that list on every refresh with a live timestamp, so it would come back identical within seconds.

I’d very much like the redacted driverState dump if you’re still willing. A side-by-side against mine is the strongest thing I can put in front of Samsung support — it reframes this from “please add a feature” to “here is the exact resource, at the exact path, on a shipping Samsung refrigerator, absent from ours.”

If your tester can also pull the WiFi module firmware version and driver version from the working unit, that would help a lot. Mine are:

  • OCF firmwareVersion: A-RFWW-TP2-21-COMMON_20220110
  • WiFi module software: 02144A220110
  • Micom firmware: 1908160A,17091902
  • Driver version: 26070101
  • Device profile: d9f70a77-5b29-3bf2-b95a-d478be32a07f

Knowing which build does implement /sabbath/vs/0 gives Samsung a concrete internal reference instead of an open-ended request.

A couple of other findings from tonight, in case they’re useful to anyone else with these units:

Freezer temperature is settable over the API despite the app not exposing it — but only via the onedoor component. Writes to the freezer component return COMPLETED and update the cloud value while never reaching the appliance, so the two go out of sync. onedoor works properly and the panel follows.

On the refrigerators (legacy Dacor connector, driver 22083101) nothing is writable. onedoor and cvroom report null setpoints, cooler reports a value labelled unit “C” that is clearly Fahrenheit, and writes to it are discarded without even updating cloud state. Power Cool is the only working control.

I also confirmed samsungce.sabbathMode exists only on main — addressing it on onedoor is rejected outright as an invalid capability. And the Smart Grid /devices/0/... endpoints documented in the manual aren’t reachable through execute at all; even known-good ones like /devices/0/Fridge/iceMaker return NOT_FOUND, so that whole namespace is a dead end from the SmartThings side.

Thanks again — this genuinely helps me try to move my ticket forward with support.