CommodityTariff.DayEntryStruct.RandomizationType has both default: 0 and conformance [RNDM], so setStateOf() rejects its own auto-fill

[lboue]

matter.js version

0.17.9

Node.js version

v24.18.0

Operating system

Ubuntu Linux 6.17.0-35-generic, x86_64

Description

What I did:
Built a CommodityTariff cluster server (feature Pricing only, Randomization NOT enabled) on an
endpoint, then used endpoint.setStateOf(CommodityTariffServer, { dayEntries: [...], ... }) (via
Matterbridge's setAttribute() helper) to publish a flat-rate day schedule after the endpoint was
already installed/active. The dayEntries value was:

dayEntries: [{ dayEntryId: 1, startTime: 0 }]

i.e. a plain DayEntryStruct with only the two mandatory fields (DayEntryId, StartTime) — no
RandomizationOffset/RandomizationType key at all.

What I expected:
The write to succeed, since RandomizationType's conformance ([RNDM]) means the field must be
absent when the Randomization feature isn't enabled — and I never supplied it.

What happened:
The write is rejected:

Validating Matterbridge.Matterbridge.electricalMeter1.electricalMeterCurrent.commodityTariff.state.0.randomizationType:
Conformance "[RNDM]": Matter does not allow you to set this attribute (135)

Full stack trace (from the attached log, matterbridge-commoditytariff-bug.log):

Error: Validating Matterbridge.Matterbridge.electricalMeter1.electricalMeterCurrent.commodityTariff.state.0.randomizationType: Conformance "[RNDM]": Matter does not allow you to set this attribute (135)
    at disallowValue (file:///.../node_modules/@matter/node/dist/esm/behavior/state/validation/conformance-compiler.js:432:13)
    at Object.randomizationType (file:///.../node_modules/@matter/node/dist/esm/behavior/state/validation/conformance.js:20:19)
    at validateStruct (file:///.../node_modules/@matter/node/dist/esm/behavior/state/validation/ValueValidator.js:275:23)
    at file:///.../node_modules/@matter/node/dist/esm/behavior/state/validation/ValueValidator.js:30:7
    at file:///.../node_modules/@matter/node/dist/esm/behavior/state/validation/conformance.js:28:22
    at validateEntries (file:///.../node_modules/@matter/node/dist/esm/behavior/state/validation/ValueValidator.js:320:11)
    ...

Analysis:
Looking at the Matter model source (@matter/model/src/standard/elements/commodity-tariff.element.ts):

Field({ name: "RandomizationOffset", id: 0x3, type: "int16", conformance: "[RNDM]" }),
Field({
    name: "RandomizationType", id: 0x4, type: "DayEntryRandomizationTypeEnum", conformance: "[RNDM]",
    default: 0
})

RandomizationType is declared with both:

• conformance: "[RNDM]" — the field must be entirely absent unless the Randomization feature is
  enabled (which I don't have — only Pricing).
• default: 0 — an unconditional default value.

When the write path (endpoint.setStateOf() → the attribute-server validated write, as opposed to
behaviors.require()'s initial-injection path, which does not hit this) canonicalizes the partial
DayEntryStruct I supplied against the full model, it fills the missing randomizationType key with
its declared default (0) — and then the conformance validator rejects that very same auto-filled
value for violating the [RNDM] gate. The model's own default-filling and its own conformance rule
contradict each other for any consumer that doesn't enable Randomization.

Confirmed this only affects the list-attribute write path: writing a single DayEntryStruct
attribute (e.g. currentDayEntry) with the exact same shape ({ dayEntryId, startTime }) succeeds
without error — only dayEntries (List[DayEntryStruct]) triggers the crash. So the bug is specific
to how struct defaults are filled/validated for list-attribute elements versus a bare struct attribute.

Proposed fix (not verified against the codebase, just a hypothesis):
Either:

1. RandomizationType/RandomizationOffset should have no default in the model (leave them
   undefined when absent, so canonicalization doesn't synthesize a value that then fails its own
   conformance check), or
2. the conformance validator should treat an auto-filled default value for a [FEATURE]-gated
   optional field as "absent" rather than "set", when the caller never supplied it explicitly, or
3. struct defaulting inside List[Struct] attribute writes should follow the same (working) code path
   used for a bare struct attribute write.

Full log attached (matterbridge-commoditytariff-bug.log, ~1300 lines): covers plugin/endpoint
construction, the three preceding successful setAttribute() calls (tariffInfo, tariffUnit,
startDate — all succeed), the failing dayEntries write, the rollback, and the full stack trace.
Reached through Matterbridge (a wrapper around matter.js), but the failing call is a plain
endpoint.setStateOf(CommodityTariffServer, { dayEntries: [...] }) — no Matterbridge-specific logic is
involved in the failure itself.
matterbridge-commoditytariff-bug.log

Confirmation

• I attached a complete log file (not just a few quoted lines) covering the context around the problem.
• Any analysis of behavior or log output in my description — whether written by me or by an AI tool — is backed by that attached log.
• I have reviewed and understand everything in this report and can explain it in my own words (AI policy).
• I searched existing issues and this is not a duplicate.

[lboue]

Checked against the spec text (transcribed in @matter/model/src/standard/resources/commodity-tariff.resource.ts):

RandomizationOffset: "If this field is not indicated, randomization shall use the value in the DefaultRandomizationOffset attribute."
RandomizationType: "If this field is not indicated, randomization shall use the value in the DefaultRandomizationType attribute."

Absence of either field is spec-meaningful ("fall back to the cluster's Default* attribute"), not "value is None/0". RandomizationOffset correctly has no default in the model — RandomizationType does, which is inconsistent with its sibling field and would silently collapse that fallback semantic to a concrete None even when Randomization is enabled, on top of causing the [RNDM] conformance crash when it isn't. Removing the default: 0 (my patch above) fixes both.

[lboue]

Opened a fix: #4375

[lboue]

Related DX issue for the silent require() no-op that made this bug hard to notice in the first place: #4376

[Apollon77]

I need to check Spec but when the text above is right there athen the Fallback value of "None" is wring because needs to be "desc" spec-wise ... I need to check that

[lboue]

Got the actual spec table (Application Cluster Spec § 9.12.5.10, DayEntryStruct field table, page 798-800 of 23-27350-010 Matter 1.6 ACS):

ID	Name	Fallback	Conformance
3	RandomizationOffset	(empty)	[RNDM]
4	RandomizationType	None	[RNDM]

So the spec's own Fallback column confirms RandomizationType = None, matching what the model already had (default: 0) and what CHIP's XML encodes (default="None"). This isn't a transcription error — the model was right.

That means my PR (#4375) is the wrong fix. Removing the default makes the crash go away, but it also removes the spec-correct fallback: once Randomization is supported and a dayEntries entry omits RandomizationType, a reader should see None, not undefined. My PR trades a real bug for a (smaller, silent) spec-compliance regression.

The actual bug looks like it's on the write/validation side, not the model: SelectDefaultValue() (packages/model/src/logic/SelectDefaultValue.ts) already correctly guards with scope.hasOperationalSupport(member) — returning no default at all when the feature isn't supported, which is exactly the right behavior here. But the list-of-struct write path that actually crashes (Endpoint.setStateOf → StructManager.ts → ValueValidator.ts's validateEntries/validateStruct) appears to fill in RandomizationType's default before checking whether Randomization is supported, then rejects that same fill for violating the very conformance it never should have applied a default under in the first place. A bare (non-list) struct attribute with the identical field shape doesn't crash, which points at something specific to how list entries get defaulted/validated rather than the general default-selection logic.