feat(sbmd): add temperature/humidity sensor support with composite device claiming by kfundecmcsa · Pull Request #202 · rdkcentral/BartonCore

kfundecmcsa · 2026-04-08T20:49:04Z

Add SBMD-based drivers for temperature, humidity, and combined
temperature/humidity sensors. This introduces composite device support
so a driver can require multiple Matter device types before claiming
a device, preventing simpler single-type drivers from incorrectly
claiming multi-function devices.

Commits

docs(openspec): Add openspec design, specs, and tasks for the change
feat(sbmd): add composite device support and endpoint fallback —
IsCompositeDriver(), two-pass claiming priority in GetDriver,
ResolveEndpointForCluster for cross-endpoint resource binding,
multi-endpoint virtual device support
feat(sbmd): add temperature, humidity, and composite sensor drivers —
SBMD specs, virtual devices, mock wrappers, integration tests

OpenSpec-Change: sbmd-temperature-humidity-spec

Refs: BARTON-350

Copilot

Pull request overview

This PR adds SBMD support for Matter temperature, humidity, and composite temperature+humidity sensors by introducing composite driver claiming semantics (ALL device types required) and endpoint/cluster fallback resolution for composite devices with clusters split across endpoints.

Changes:

Add deviceTypeMatch (any/all) to SBMD Matter metadata, including parser + schema updates and new SBMD specs for temperature, humidity, and composite sensors.
Add composite-driver prioritization in MatterDriverFactory::GetDriver() and add MatterDevice::ResolveEndpointForCluster() for cross-endpoint cluster binding.
Add new matter.js virtual sensor devices, Python fixtures, and integration tests for commissioning + dynamic updates + negative claiming cases.

Reviewed changes

Copilot reviewed 34 out of 34 changed files in this pull request and generated 10 comments.

Show a summary per file

File	Description
`testing/test/temperature_humidity_test.py`	New integration tests covering commissioning, reads, updates, and driver-claiming behavior for sensor drivers.
`testing/mocks/devices/matterjs/src/VirtualDevice.js`	Extend virtual device base to support multi-endpoint devices via `createEndpoints()` + `endpoints[]`.
`testing/mocks/devices/matterjs/src/TemperatureSensorDevice.js`	New single-endpoint virtual temperature sensor with sideband ops.
`testing/mocks/devices/matterjs/src/HumiditySensorDevice.js`	New single-endpoint virtual humidity sensor with sideband ops.
`testing/mocks/devices/matterjs/src/TemperatureHumiditySensorDevice.js`	New two-endpoint composite temp+humidity virtual device with sideband ops.
`testing/mocks/devices/matterjs/src/LightDevice.js`	Update existing virtual light to new multi-endpoint base API.
`testing/mocks/devices/matterjs/src/DoorLockDevice.js`	Update existing virtual door lock to new multi-endpoint base API.
`testing/mocks/devices/matter/matter_temperature_sensor.py`	New Python wrapper + fixture for temperature virtual device.
`testing/mocks/devices/matter/matter_humidity_sensor.py`	New Python wrapper + fixture for humidity virtual device.
`testing/mocks/devices/matter/matter_temperature_humidity_sensor.py`	New Python wrapper + fixture for composite virtual device.
`testing/conftest.py`	Register new pytest plugin modules for the added Matter devices.
`core/test/src/sbmdParserTest.cpp`	Add unit tests validating parsing of new sensor SBMD specs + `deviceTypeMatch`.
`core/test/src/MatterDeviceEndpointMapTest.cpp`	Add tests for endpoint/cluster fallback binding and `any` vs `all` claim semantics.
`core/deviceDrivers/matter/sbmd/specs/temperature-sensor.sbmd`	New SBMD spec for temperature sensor resource mapping.
`core/deviceDrivers/matter/sbmd/specs/humidity-sensor.sbmd`	New SBMD spec for humidity sensor resource mapping.
`core/deviceDrivers/matter/sbmd/specs/temperature-humidity-sensor.sbmd`	New composite SBMD spec requiring both device types with `deviceTypeMatch: all`.
`core/deviceDrivers/matter/sbmd/SpecBasedMatterDeviceDriver.h`	Add `IsCompositeDriver()` override declaration for SBMD drivers.
`core/deviceDrivers/matter/sbmd/SpecBasedMatterDeviceDriver.cpp`	Implement `IsCompositeDriver()` based on `deviceTypeMatch`.
`core/deviceDrivers/matter/sbmd/SbmdSpec.h`	Add `deviceTypeMatch` field (default `any`) to SBMD Matter metadata.
`core/deviceDrivers/matter/sbmd/SbmdParser.cpp`	Parse/validate `deviceTypeMatch` from YAML.
`core/deviceDrivers/matter/sbmd/sbmd-spec-schema.json`	Extend JSON schema to allow `deviceTypeMatch` with enum validation.
`core/deviceDrivers/matter/MatterDriverFactory.cpp`	Two-pass driver claiming to prioritize composite drivers.
`core/deviceDrivers/matter/MatterDeviceDriver.h`	Add `IsCompositeDriver()` API with documentation.
`core/deviceDrivers/matter/MatterDeviceDriver.cpp`	Update `ClaimDevice()` to support composite (“all required types”) semantics.
`core/deviceDrivers/matter/MatterDevice.h`	Declare `ResolveEndpointForCluster()`.
`core/deviceDrivers/matter/MatterDevice.cpp`	Implement `ResolveEndpointForCluster()` and refactor binding to use it.
`openspec/changes/sbmd-temperature-humidity-spec/*`	Add OpenSpec proposal/design/specs/tasks documenting the change set.

cleithner-comcast

Generally good with it, some open questions.

tleacmcsa

partial review... just the sbmd files so far.

tleacmcsa · 2026-04-13T16:37:51Z

+    - 0x0302  # Temperature Sensor
+    - 0x0307  # Humidity Sensor
+  deviceTypeMatch: "all"
+  revision: 1


it does not make sense to have a shared revision across device types.

makes sense, removed

im not sure simply removing it is the right choice either.

Right, good point.

What if we restructured deviceTypes so each entry is a mapping that pairs the device type ID with its revision?

deviceTypes: - id: 0x0302 revision: 3 - id: 0x0307 revision: 3

This would be a schema-wide change affecting all existing SBMD specs, so might be best tackled in a separate ticket. Worth noting that revision is currently unused at runtime; it's parsed and stored but never consumed. For now, I propose leaving it as revision: 3 with a TODO comment explaining the situation.

Thoughts?

Thought about this more. I now DO think that we should remove it until we think we need it. Sorry for the thrash.

Add proposal, design, specs, and tasks for SBMD temperature and humidity sensor drivers with composite device type matching support. Current ClaimDevice uses OR semantics, claiming a device if any listed type matches any endpoint. This prevents combined drivers that require all types, and grouping cross-endpoint clusters under one SBMD endpoint breaks resource binding. This change proposes: - deviceTypeMatch field for AND-match claiming - ResolveEndpointForCluster fallback for cross-endpoint resource binding - Three new SBMD sensor driver specs OpenSpec-Change: sbmd-temperature-humidity-spec Refs: BARTON-350

Matter devices can expose multiple device types across their endpoints (e.g. a combined temperature/humidity sensor). Without composite support, a simple single-type driver would claim such a device first, preventing a more specific composite driver from handling it correctly. - Add `deviceTypeMatch` field to SBMD specs: "any" (default) claims on any matching device type; "all" requires every specified type to be present across non-root endpoints before claiming - Add `IsCompositeDriver()` virtual method to `MatterDeviceDriver` - Add two-pass claiming in `MatterDriverFactory::GetDriver`: composite drivers get priority in the first pass; non-composite drivers run in the second pass only if nothing claimed the device yet - Add `ResolveEndpointForCluster` to `MatterDevice` (Thomas Lea): when binding a resource to an SBMD-mapped endpoint that doesn't host the needed cluster, fall back to scanning all endpoints for one that does - Refactor duplicated endpoint resolution in `BindResourceReadInfo` and `BindResourceEventInfo` to use the new method - Update `VirtualDevice.js` to support multiple endpoints (`this.endpoint` > `this.endpoints[]`); adapt `LightDevice` and `DoorLockDevice` accordingly OpenSpec-Change: sbmd-temperature-humidity-spec Co-authored-by: Thomas Lea <35579828+tleacmcsa@users.noreply.github.com> Refs: BARTON-350

Implement SBMD-based drivers for three sensor device classes using the composite device support added in the parent commit. - Add SBMD specs for `temperatureSensor`, `humiditySensor`, and `temperatureHumiditySensor` (composite, requires both device types) - Add matterjs virtual device implementations for all three sensors - Add Python mock device wrappers for use in integration tests - Add `conftest.py` fixtures for the three sensor device types - Add integration tests covering commission, initial subscription reports, dynamic attribute updates, and composite driver rejection of single-type devices - Add SBMD parser tests for the new sensor specs - Update openspec tasks OpenSpec-Change: sbmd-temperature-humidity-spec Refs: BARTON-350

tleacmcsa · 2026-04-15T12:57:45Z

@@ -0,0 +1,78 @@
+# Temperature Humidity Sensor SBMD Specification
+# Maps composite Matter device with both temperature and humidity sensor


"composite" has meaning in the Matter spec, and it does not match this usage. Let's call this "combined". A composite device uses PartsList attribute on the Descriptor cluster to "string together" endpoints and their device types into a complex device composed of explicit parts from the standard. Like a refrigerator should have temperature sensors, lights, etc. This Ikea device is just one device with two things in it.

tleacmcsa · 2026-04-15T13:37:09Z

+
+# Barton device class mapping
+bartonMeta:
+  deviceClass: "temperatureHumiditySensor"


I'm unsure about this device class, so we should have a discussion. There is not necessarily a 1:1 mapping between the end device type and our device class. Are we making a Barton device class this specific, or are we making something like an air environmental sensor or some such? could be defined to have optional resources that might include other stuff if the end device has it.

tleacmcsa · 2026-04-15T13:39:25Z

+# Matter device type support
+matterMeta:
+  deviceTypes:
+    - 0x0302  # Temperature Sensor


It just occurred to me that another approach would be to have this be the ikea TIMMERFLOTTE driver that binds to the vendor and product ids rather than these two combined device types. What are the odds that someone else will make a sensor that combines these two things? Will we ever need drivers for specific vendor devices? probably... Might be able to ditch the deviceTypeMatch stuff if we went down that route.

tleacmcsa · 2026-04-15T13:42:49Z

        std::vector<uint16_t> deviceTypes;
        uint32_t revision;
        std::vector<uint32_t> featureClusters; // Optional: cluster IDs to get feature maps from
+        std::string deviceTypeMatch = "any";   // "any" (default) or "all" for composite device matching


composite->combined ? just a reminder that we should think about the terminology everwhere we added it

tleacmcsa · 2026-04-15T13:45:52Z

+        // One SBMD endpoint maps to one Matter endpoint, but the SBMD endpoint's
+        // resources may reference clusters that live on different Matter endpoints


Isnt this contradictory? First it says a 1:1 mapping of SBMD endpoints to Matter endpoints, then says an SBMD endpoint's resources could refer to other Matter endpoints.

tleacmcsa · 2026-04-15T13:46:28Z

+        // Use the mapped endpoint if it hosts this cluster (or if we can't
+        // verify because cache data isn't available yet).


Is there ever a case whereby we dont have a cache available yet?

tleacmcsa · 2026-04-15T13:50:35Z

+         * @brief Returns true if this driver requires ALL advertised device types to match
+         * before it will claim a device, rather than matching on any single type.
+         *
+         * Composite drivers model multi-endpoint devices that expose several distinct


Consider the Matter specification's definition of a composite device in this description to make sure we dont design an API that wont make sense when we add real support for true composite devices.

cleithner-comcast · 2026-04-22T14:58:11Z

Should this be draft?

kfundecmcsa · 2026-04-23T18:48:20Z

Should this be draft?

yes, done

Copilot AI review requested due to automatic review settings April 8, 2026 20:49

kfundecmcsa requested review from cleithner-comcast, mkkoch, rchowdcmcsa and tleacmcsa as code owners April 8, 2026 20:49

Copilot started reviewing on behalf of kfundecmcsa April 8, 2026 20:49 View session

Copilot AI reviewed Apr 8, 2026

View reviewed changes

cleithner-comcast reviewed Apr 13, 2026

View reviewed changes

Comment thread core/deviceDrivers/matter/MatterDevice.cpp Outdated

Comment thread core/deviceDrivers/matter/MatterDeviceDriver.cpp Outdated

Comment thread testing/test/temperature_humidity_sensor_test.py

tleacmcsa reviewed Apr 13, 2026

View reviewed changes

kfundecmcsa and others added 3 commits April 13, 2026 17:42

kfundecmcsa force-pushed the kfun/dev/sbmd-temp-humidity branch from d8c8fd4 to e77cfb0 Compare April 14, 2026 18:39

kfundecmcsa requested review from cleithner-comcast and tleacmcsa April 14, 2026 18:42

cleithner-comcast approved these changes Apr 14, 2026

View reviewed changes

tleacmcsa reviewed Apr 15, 2026

View reviewed changes

kfundecmcsa marked this pull request as draft April 23, 2026 18:48

		@@ -0,0 +1,78 @@
		# Temperature Humidity Sensor SBMD Specification
		# Maps composite Matter device with both temperature and humidity sensor

		// One SBMD endpoint maps to one Matter endpoint, but the SBMD endpoint's
		// resources may reference clusters that live on different Matter endpoints

		// Use the mapped endpoint if it hosts this cluster (or if we can't
		// verify because cache data isn't available yet).

Conversation

kfundecmcsa commented Apr 8, 2026

Commits

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cleithner-comcast left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tleacmcsa left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cleithner-comcast commented Apr 22, 2026

Uh oh!

kfundecmcsa commented Apr 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants