Matter Switch: Configure individual electrical clusters if electrical sensor device type is not found - #3149
Conversation
|
Invitation URL: |
Test Results 73 files 541 suites 0s ⏱️ Results for commit b593c00. |
|
matter-switch_coverage.xml
Minimum allowed coverage is Generated by 🐒 cobertura-action against b593c00 |
|
Thank you again for investigating this. We now have on-device logs from a P316M-specific test build, and they clarify the failure considerably. Confirmed P316M endpoint structureSmartThings supplies the Edge driver with the complete Matter endpoint inventory: The six Electrical Sensor endpoints also return the expected All six reads completed successfully. This rules out several possible causes:
The P316M follows the existing Electrical Sensor plus I still think that fallback is a useful generic compatibility improvement. However, the new on-device evidence indicates that it is not the missing piece for the P316M regression. Result of creating children before electrical profiling completesThe test build enumerated the known On/Off endpoints immediately and requested basic SmartThings successfully registered all five children. After all six On/Off reports for endpoints 2–6 were then emitted on the corresponding child devices. This confirms that:
Suggested generic driver changeI suggest separating structural endpoint creation from optional profile enrichment. The current order in The relevant code currently begins with: function DeviceConfiguration.match_profile(driver, device)
if profiling_data_still_required(device) then return end
local default_endpoint_id = switch_utils.find_default_endpoint(device)
local server_onoff_ep_ids = device:get_endpoints(clusters.OnOff.ID)
if #server_onoff_ep_ids > 0 then
ChildConfiguration.create_or_update_child_devices(
driver,
device,
server_onoff_ep_ids,
default_endpoint_id,
SwitchDeviceConfiguration.assign_profile_for_onoff_ep
)
end
-- Remaining parent-profile matching
endBecause child creation is below the global profiling gate, any unresolved profiling field prevents the driver from even attempting to create otherwise valid and independently controllable On/Off children. A more fault-tolerant order would be: Conceptually, the flow could be split like this: function DeviceConfiguration.match_profile(driver, device)
local default_endpoint_id =
switch_utils.find_default_endpoint(device)
local server_onoff_ep_ids =
device:get_endpoints(clusters.OnOff.ID)
-- Structural configuration:
-- create independently controllable OnOff endpoints first.
if #server_onoff_ep_ids > 0 then
ChildConfiguration.ensure_basic_onoff_children(
driver,
device,
server_onoff_ep_ids,
default_endpoint_id
)
end
-- Optional capability/profile enrichment can wait.
if profiling_data_still_required(device) then
return
end
-- Apply final profiles to the parent and existing children.
if #server_onoff_ep_ids > 0 then
ChildConfiguration.create_or_update_child_devices(
driver,
device,
server_onoff_ep_ids,
default_endpoint_id,
SwitchDeviceConfiguration.assign_profile_for_onoff_ep
)
end
-- Existing parent-profile matching continues here.
endThis is only pseudocode. The important design distinction is: rather than:
Idempotency for asynchronous child creationThe existing child-creation function should not simply be moved above the profiling gate without an additional guard.
The test build used a non-persistent pending set keyed by endpoint ID. Its behavior was: The pending entry was cleared when the corresponding child reached its configuration lifecycle. Keeping this state non-persistent also permits a clean retry after a driver restart if a child-creation request is lost or rejected. An implementation could follow this general pattern: local pending = device:get_field(fields.PENDING_CHILD_CREATIONS) or {}
if existing_child_device then
existing_child_device:try_update_metadata({
profile = child_profile,
optional_component_capabilities = optional_component_capabilities
})
elseif not pending[ep_id] then
pending[ep_id] = true
device:set_field(fields.PENDING_CHILD_CREATIONS, pending)
driver:try_create_device({
type = "EDGE_CHILD",
label = label_and_name,
profile = child_profile,
parent_device_id = device.id,
parent_assigned_child_key = string.format("%d", ep_id),
vendor_provided_label = label_and_name
})
endThe exact storage location and lifecycle used to clear the pending entry can of course follow the conventions preferred by the driver. Why early child creation appears to be the relevant changeAn earlier test build restored explicit The subsequent test build retained those reads and added early basic child creation. With that change:
This makes the placement and timing of child creation the strongest current explanation for the observed difference. Suggested regression testIn addition to the single-endpoint electrical-cluster tests already added in this PR, I suggest adding a multi-endpoint fixture representing the P316M structure: The tests should verify that:
Separate electrical-value observationThe test build successfully selected the power/energy profile and subscribed to: The logs then showed repeated errors originating in the generated SmartThings This appears to be separate from the missing-child regression, because all five children had already been created and assigned their final profiles. It may nevertheless explain why actual power or energy values remain blank even after the topology and profiles are correct. Testing the three electrical attributes separately would help identify the exact report or data shape that triggers the decoder error. SummaryI think PR #3149 should remain as a generic improvement for devices that expose electrical clusters without Electrical Sensor device types. For issue #3147, the on-device logs support an additional generic change: create basic On/Off children independently of electrical profiling, then enrich their profiles after the topology information becomes available. That avoids a P316M-specific workaround and ensures that an incomplete optional profiling step cannot hide valid, independently controllable Matter endpoints. |
2 participants
Description of Change
Electrical clusters (energy/power measurement) are often associated with the Electrical Sensor device type. We have support today for the device type and its corresponding Power Topology cluster. However, some devices do not support this device type, but do still expose these clusters. This is generally allowed, per spec, though it loses clarity for the controller what those electrical clusters actually map to. Still, this should be supported in a general way, since there are several popular devices in the field that do not appear to expose the Electrical Sensor device type for one reason or another.
It is unclear what the internals of the problem exactly are in this issue: #3147, but I believe this may be the solution.
Summary of Completed Tests
Unit tests added. On-device testing still required.