## Summary
Fresh Matter commissioning of a TP-Link/Tapo P316M power strip curre…ntly creates only one SmartThings device, mapped to outlet 1. Edge child devices are not created for outlets 2 through 6.
The available evidence points to a fresh-onboarding and dynamic-profiling problem in the Matter Switch driver:
* P316M strips commissioned previously still expose all six outlets as individual SmartThings devices.
* A previously working P316M was deleted and recommissioned; after recommissioning, only outlet 1 was created.
* A factory reset did not change the result.
* Direct commissioning and Matter multi-admin commissioning produced the same result.
* Fresh commissioning of the same device in Apple Home and Home Assistant exposes all six controllable outlets.
* The two older SmartThings installations and the newly commissioned installation all report the same current Matter Switch driver package.
The current Matter Switch driver still contains generic parent/child creation code for multi-endpoint On/Off devices. However, that code is reached only after all fields in `profiling_data` have been populated.
The P316M exposes six separate Electrical Sensor endpoints using PowerTopology `SET_TOPOLOGY`. The driver waits for `AvailableEndpoints` data from the Electrical Sensor endpoints before proceeding with profile matching and child creation. If that process does not complete, `match_profile()` returns before any children are created.
This is the most likely explanation for the reported behavior, but an onboarding log is still required to identify the exact missing or rejected report and to confirm that execution never reaches `try_create_device()`.
Forum discussion:
https://community.smartthings.com/t/driver-for-tp-link-tapo-p316m/310364
## Device information
**Device:** TP-Link/Tapo P316M Smart Wi-Fi Power Strip
**Controllable outlets:** 6 independently controllable AC outlets
**Matter specification:** 1.3
**Vendor ID:** `0x1392` / decimal `5010`
**Product ID:** `0x0112` / decimal `274`
**Primary device type:** On/Off Plug-in Unit, `0x010A`
**Certified firmware:** `1.3.0`
**Certificate:** `CSA25115MAT45159-24`
Official product page:
https://www.tapo.com/en/product/smart-plug/tapo-p316m/
CSA certification:
https://csa-iot.org/csa_product/smart-wi-fi-power-strip-13/
## Corroborating endpoint information
Independent Matter device telemetry reports the following P316M endpoint structure:
* Endpoint 0: Root Node
* Endpoints 1–6: On/Off Plug-in Unit endpoints with the OnOff server cluster
* Endpoints 7–12: Electrical Sensor endpoints
* Electrical Sensor endpoints 7–12 expose:
* Electrical Power Measurement
* Electrical Energy Measurement
* PowerTopology
* `SET_TOPOLOGY`
* `AvailableEndpoints`
Source:
https://www.matter-survey.org/device/smart-wi-fi-power-strip-5010-274
This is third-party telemetry rather than a SmartThings onboarding log, but it demonstrates that the P316M device structure exercises the exact multi-Electrical-Sensor SET-topology path implemented by the Matter Switch driver.
With this structure, the driver should normally select endpoint 1 as the parent/default On/Off endpoint and create child devices for endpoints 2–6.
## Affected driver package
The user reports this driver package timestamp:
```text
2026-07-23T15:54:53.299816878
```
That corresponds closely to the July 23, 2026 production roll-up:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/commit/165b12e44a4d6086eebacfdfa37e53b5a815d51f
The uploaded Matter Switch package used for this analysis matches that production code. The relevant Git blob SHAs are:
```text
src/switch_utils/device_configuration.lua
9c5235d1e2fa3c7a598d3c5fc0b16726277660fa
src/switch_utils/utils.lua
d2457bfb4d4bb4c5d358b69ef53ecd270997be3e
src/switch_handlers/attribute_handlers.lua
b7feed6344c640cd2c113976e4f19c62177143af
src/init.lua
9d4e22fb15dd6a48cab78c26fe9a12e5e10c78fe
src/switch_utils/fields.lua
5873cb40b232f6c6337d438d93bf042d39d21fb6
fingerprints.yml
6a4321c1a587645317dc8ff1866459184914eb60
```
The July 23 roll-up did not materially change the generic child-creation or power-topology profiling logic. The timestamp therefore identifies the running package, but does not establish that the July roll-up introduced the underlying defect.
## Steps to reproduce
1. Factory-reset a Tapo P316M.
2. Start Matter Switch driver logging with:
```text
smartthings edge:drivers:logcat
```
3. Commission the P316M directly to SmartThings.
4. Allow commissioning and device configuration to complete.
5. Inspect the SmartThings devices created for the power strip.
6. Optionally repeat after commissioning first to Apple Home or Home Assistant and sharing the Matter device to SmartThings.
## Actual behavior
SmartThings creates only one device.
That device controls outlet 1. No Edge child devices are created for outlets 2 through 6.
## Expected behavior
SmartThings should expose all six On/Off Plug-in Unit endpoints:
* endpoint 1 as the parent/default device;
* endpoints 2–6 as five Edge child devices.
Each outlet should be independently controllable.
After the Electrical Sensor topology has been resolved, the appropriate power and energy capabilities should be assigned to the outlet associated with each Electrical Sensor endpoint.
Failure or delay in electrical-topology enrichment should not permanently suppress the five otherwise functional On/Off child devices.
## Evidence of a fresh-onboarding regression
One forum participant reports owning three P316M strips:
* Two P316M strips commissioned previously still expose all six outlets.
* A third strip also exposed six outlets before it was deleted from SmartThings.
* Recommissioning that same physical strip now creates only outlet 1.
* Factory-resetting it does not help.
* Adding it through Matter multi-admin from Apple Home or Home Assistant still creates only outlet 1 in SmartThings.
* Apple Home and Home Assistant themselves expose all six outlets.
The older SmartThings installations show each outlet as an individual device with On/Off state and per-outlet power usage.
This strongly points to a failure during fresh SmartThings device profiling or child creation, rather than a runtime command-routing problem affecting children that already exist.
It does not, by itself, identify whether the regression is in:
* this Edge driver;
* Matter subscription handling in the Lua libraries or hub firmware;
* delivery of initial subscription reports;
* or another part of the SmartThings Matter onboarding path.
## Relevant driver behavior
### 1. Generic On/Off child creation is still present
The Matter Switch driver sorts the server-side endpoint IDs, skips the default endpoint and calls `driver:try_create_device()` for every other endpoint:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/165b12e44a4d6086eebacfdfa37e53b5a815d51f/drivers/SmartThings/matter-switch/src/switch_utils/device_configuration.lua#L25-L57
Relevant code:
```lua
function ChildConfiguration.create_or_update_child_devices(
driver,
device,
server_cluster_ep_ids,
default_endpoint_id,
assign_profile_fn
)
table.sort(server_cluster_ep_ids)
for device_num, ep_id in ipairs(server_cluster_ep_ids) do
if ep_id ~= default_endpoint_id then
local label_and_name =
string.format("%s %d", device.label, device_num)
local child_profile, optional_component_capabilities =
assign_profile_fn(device, ep_id, true)
local existing_child_device =
device:get_field(fields.IS_PARENT_CHILD_DEVICE)
and switch_utils.find_child(device, ep_id)
if not existing_child_device then
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
})
else
existing_child_device:try_update_metadata({
profile = child_profile,
optional_component_capabilities =
optional_component_capabilities
})
end
end
end
end
```
If this function receives On/Off endpoints 1–6 and endpoint 1 is the default, it should request five child devices with assigned keys `"2"` through `"6"`.
### 2. Child creation is after a global profiling-completion gate
`match_profile()` returns immediately if any entry in `fields.profiling_data` is still `nil`:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/165b12e44a4d6086eebacfdfa37e53b5a815d51f/drivers/SmartThings/matter-switch/src/switch_utils/device_configuration.lua#L242-L263
```lua
local function profiling_data_still_required(device)
for _, field in pairs(fields.profiling_data) do
if device:get_field(field) == nil then
return true
end
end
return false
end
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
end
```
The required profiling fields are:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/165b12e44a4d6086eebacfdfa37e53b5a815d51f/drivers/SmartThings/matter-switch/src/switch_utils/fields.lua#L182-L185
```lua
SwitchFields.profiling_data = {
POWER_TOPOLOGY = "__power_topology",
BATTERY_SUPPORT = "__battery_support",
}
```
Consequently, unresolved electrical topology or battery-support detection prevents all generic On/Off child creation.
For the mains-powered P316M, `BATTERY_SUPPORT` should normally be set to `NO_BATTERY` during `init`. The more likely blocking field is therefore `POWER_TOPOLOGY`, but this must be verified in the onboarding log.
### 3. The P316M takes the SET-topology path
`handle_electrical_sensor_info()` obtains all Electrical Sensor endpoints.
For a device with no Electrical Sensor endpoints, it sets `POWER_TOPOLOGY` to `false`, allowing profile matching to continue.
For a device whose first Electrical Sensor endpoint advertises `SET_TOPOLOGY` or `TREE_TOPOLOGY`, it stores all Electrical Sensor endpoints in `ELECTRICAL_SENSOR_EPS` but leaves `POWER_TOPOLOGY` as `nil`:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/165b12e44a4d6086eebacfdfa37e53b5a815d51f/drivers/SmartThings/matter-switch/src/switch_utils/utils.lua#L440-L475
```lua
if clusters.PowerTopology.are_features_supported(
clusters.PowerTopology.types.Feature.SET_TOPOLOGY,
endpoint_power_topology_feature_map
) or clusters.PowerTopology.are_features_supported(
clusters.PowerTopology.types.Feature.TREE_TOPOLOGY,
endpoint_power_topology_feature_map
) then
device:set_field(
fields.ELECTRICAL_SENSOR_EPS,
electrical_sensor_eps
)
end
```
Independent P316M telemetry reports six SET-topology Electrical Sensor endpoints, 7–12. The driver will therefore wait for topology association data from this group before full profiling proceeds.
### 4. Topology association currently depends on subscription reports
When `POWER_TOPOLOGY` is unresolved, the driver adds a wildcard subscription for one of these attributes:
* `PowerTopology.AvailableEndpoints` for SET topology;
* `Descriptor.PartsList` for TREE topology.
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/165b12e44a4d6086eebacfdfa37e53b5a815d51f/drivers/SmartThings/matter-switch/src/switch_utils/utils.lua#L560-L577
For the P316M, the relevant request is:
```lua
local ib = im.InteractionInfoBlock(
nil,
clusters.PowerTopology.ID,
clusters.PowerTopology.attributes.AvailableEndpoints.ID
)
subscribe_request:with_info_block(ib)
```
The endpoint ID is `nil`, so the subscription is intended to cover matching `AvailableEndpoints` attributes across the node.
### 5. Profiling resumes only after the pending endpoint table is considered empty
The `available_endpoints_handler()` searches `ELECTRICAL_SENSOR_EPS` for the endpoint that generated the report, removes that table entry, stores its association and checks whether the pending endpoint table is empty:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/165b12e44a4d6086eebacfdfa37e53b5a815d51f/drivers/SmartThings/matter-switch/src/switch_handlers/attribute_handlers.lua#L321-L350
```lua
for i, set_ep_info in pairs(set_topology_eps) do
if ib.endpoint_id == set_ep_info.endpoint_id then
switch_utils.remove_field_index(
device,
fields.ELECTRICAL_SENSOR_EPS,
i
)
local available_endpoints_ids = {}
for _, element in pairs(ib.data.elements or {}) do
table.insert(
available_endpoints_ids,
element.value
)
end
switch_utils.set_fields_for_electrical_sensor_endpoint(
device,
set_ep_info,
available_endpoints_ids
)
break
end
end
if #set_topology_eps == 0 then
device:set_field(
fields.profiling_data.POWER_TOPOLOGY,
clusters.PowerTopology.types.Feature.SET_TOPOLOGY,
{persist = true}
)
device_cfg.match_profile(driver, device)
end
```
If the driver never considers all six Electrical Sensor endpoints complete, `POWER_TOPOLOGY` remains `nil`, the subsequent `match_profile()` call does not occur and the original `doConfigure` call has already returned at the profiling gate.
Possible reasons include:
* one or more initial `AvailableEndpoints` reports are absent;
* the wildcard subscription does not produce a report from every endpoint;
* a report arrives before `ELECTRICAL_SENSOR_EPS` is initialized and is ignored;
* an endpoint ID does not match an entry in the stored table;
* a report contains an error status or unusable data;
* lifecycle ordering prevents the expected subscription;
* or the failure occurs elsewhere before child creation.
The log is required to distinguish these cases.
### 6. Current tests require topology completion before child creation
The SET-topology test does not expect child creation after `doConfigure`.
It first injects all expected `AvailableEndpoints` reports, and only then expects the child device:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/165b12e44a4d6086eebacfdfa37e53b5a815d51f/drivers/SmartThings/matter-switch/src/test/test_electrical_sensor_set.lua#L384-L407
The TREE-topology test follows the same pattern with `Descriptor.PartsList`:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/165b12e44a4d6086eebacfdfa37e53b5a815d51f/drivers/SmartThings/matter-switch/src/test/test_electrical_sensor_tree.lua#L233-L257
There does not appear to be a test for:
> Multiple valid On/Off Plug-in Unit endpoints exist, but one or more expected power-topology reports never arrive.
The current control flow leaves basic child creation dependent on completion of optional electrical-profile enrichment.
## Relevant history
PR #2444 introduced PowerTopology-based profiling for multi-switch devices with Electrical Sensor endpoints:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/pull/2444
PR #2792 changed initial topology discovery from explicit per-endpoint reads to a subscription-based mechanism:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/pull/2792
Before PR #2792, `handle_electrical_sensor_info()` sent an explicit combined READ request:
```lua
local available_eps_req = im.InteractionRequest(
im.InteractionRequest.RequestType.READ,
{}
)
for _, ep in ipairs(electrical_sensor_eps) do
available_eps_req:merge(
clusters.PowerTopology.attributes.AvailableEndpoints:read(
device,
ep.endpoint_id
)
)
end
device:send(available_eps_req)
```
PR #2792 intentionally replaced those reads with subscriptions to use Matter subscription retry behavior.
That change is directly relevant to the suspected failure, but it should not be identified as the confirmed regression point until the onboarding log shows that the expected subscription reports are incomplete or mishandled.
The July 23, 2026 production roll-up did not materially alter this logic.
## Root-cause assessment
### Confirmed
* The P316M contains six independent On/Off Plug-in Unit endpoints.
* The P316M also contains six Electrical Sensor endpoints using SET topology.
* Generic On/Off child creation still exists in the production driver.
* The driver’s generic child creation occurs after the profiling-completion gate.
* `POWER_TOPOLOGY` remains `nil` while SET-topology association processing is pending.
* Full profile matching resumes only after the pending SET-topology endpoint collection is considered complete.
* The current tests expect child creation only after all test topology reports have been supplied.
* The production fingerprints do not contain VID/PID `0x1392/0x0112`.
### Strongly indicated by the observed behavior
The newly commissioned P316M is likely remaining in the incomplete electrical-topology profiling state, so `create_or_update_child_devices()` is never reached.
### Not yet confirmed
Without a SmartThings onboarding log, it is not yet possible to state:
* which `AvailableEndpoints` reports SmartThings receives;
* whether all six Electrical Sensor endpoints are present in `device.endpoints`;
* whether `BATTERY_SUPPORT` is resolved;
* whether the initial topology subscription is sent;
* whether a report is ignored because of lifecycle ordering;
* whether `try_create_device()` is called and fails;
* or whether the fault is partly in hub firmware or the Matter Lua libraries rather than exclusively in this driver.
## Suggested fix
A robust fix should address both initial topology discovery and the dependency between electrical enrichment and basic switch functionality.
### 1. Restore deterministic explicit topology reads
Keep the existing subscription, but also send an explicit read for `AvailableEndpoints` on every detected SET-topology Electrical Sensor endpoint during initial configuration.
For example:
```lua
local request = im.InteractionRequest(
im.InteractionRequest.RequestType.READ,
{}
)
for _, ep in ipairs(electrical_sensor_eps) do
request:merge(
clusters.PowerTopology.attributes.AvailableEndpoints:read(
device,
ep.endpoint_id
)
)
end
device:send(request)
```
For TREE topology, the equivalent request should read `Descriptor.attributes.PartsList`.
This combines:
* deterministic initial discovery;
* explicit endpoint targeting;
* and the retry behavior of the existing subscription.
The current handlers already reject topology reports after `POWER_TOPOLOGY` has been finalized, so duplicate reports can be safely ignored, subject to normal status validation.
This is the least invasive likely fix if logs confirm missing initial subscription reports.
### 2. Decouple basic On/Off child creation from electrical enrichment
Basic endpoint functionality should not depend indefinitely on successful electrical-topology profiling.
The driver could split the current process into two stages:
1. Ensure that child devices exist for all valid On/Off endpoints.
2. After power topology is known, enrich or update those devices with power and energy profiles.
`assign_profile_for_onoff_ep()` already returns:
* `plug-binary` for an endpoint whose device type maps to On/Off Plug-in Unit;
* or `switch-binary` as its generic fallback.
`create_or_update_child_devices()` already supports updating an existing child’s profile after electrical tags become available.
A possible structure would be:
```lua
function DeviceConfiguration.match_profile(driver, device)
ensure_basic_onoff_children(driver, device)
if profiling_data_still_required(device) then
return
end
update_parent_and_child_profiles(driver, device)
end
```
However, `ensure_basic_onoff_children()` must be idempotent.
`match_profile()` can run more than once while profiling remains incomplete, and `driver:try_create_device()` is asynchronous. A naive move of the existing child-creation call above the profiling gate could issue repeated creation requests before the newly requested children appear in the driver cache.
The implementation should therefore track creation attempts per `parent_assigned_child_key`, check existing children and safely retry failed attempts without creating duplicates.
### 3. Improve pending-state and error logging
When `match_profile()` returns because profiling data is incomplete, log the unresolved fields and pending endpoint IDs.
Useful log entries would include:
* all detected On/Off endpoint IDs;
* all detected Electrical Sensor endpoint IDs;
* selected PowerTopology feature;
* the `AvailableEndpoints` subscription request;
* every received topology report and status;
* the decoded associated endpoint IDs;
* the remaining pending Electrical Sensor endpoint IDs;
* every child creation or profile-update request;
* and any error returned from `try_create_device()`.
At present, the initial profiling gate can return silently.
### 4. Avoid using a permanent “unsupported” fallback for a temporary failure
A timeout should not simply persist:
```lua
POWER_TOPOLOGY = false
```
That would cause later valid topology reports to be ignored and could permanently suppress power and energy enrichment.
A safer fallback is:
* expose basic On/Off children;
* keep topology discovery pending;
* retry explicit reads;
* and upgrade the existing child profiles when valid association data arrives.
### 5. Consider adding a P316M fingerprint separately
The current production fingerprints include a Tapo Smart Power Strip with VID/PID `0x1392/0x010D`, but not the P316M’s `0x1392/0x0112`:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/165b12e44a4d6086eebacfdfa37e53b5a815d51f/drivers/SmartThings/matter-switch/fingerprints.yml#L4191-L4206
A possible initial fingerprint is:
```yaml
- id: "5010/274"
deviceLabel: Tapo Smart Power Strip
vendorId: 0x1392
productId: 0x0112
deviceProfileName: plug-binary
```
The profile should be reviewed against the expected initial commissioning behavior.
Adding this fingerprint may improve identification and the initial parent profile, but it should not be treated as the generic fix. Standards-based multi-endpoint devices should not lose their additional On/Off endpoints solely because they lack a product-specific fingerprint.
## Suggested tests
### P316M-style SET-topology fixture
Create a test device with:
* On/Off Plug-in Unit endpoints 1–6;
* Electrical Sensor endpoints 7–12;
* `SET_TOPOLOGY` on endpoints 7–12;
* one `AvailableEndpoints` association per Electrical Sensor endpoint.
Expected result:
* endpoint 1 is represented by the parent;
* child keys `"2"` through `"6"` are created;
* the children receive the appropriate electrical profiles after all associations are known.
### Missing topology report
Run the same fixture but omit one `AvailableEndpoints` report.
Expected result:
* all six outlets remain available with at least basic On/Off profiles;
* profiling remains marked as incomplete;
* no duplicate children are created;
* diagnostic logging identifies the missing Electrical Sensor endpoint.
### Delayed topology report
Deliver the omitted report later.
Expected result:
* the existing basic child is updated to the enriched profile;
* no second child with the same assigned key is requested.
### Out-of-order reports
Deliver reports in a non-sequential endpoint order.
Expected result:
* pending endpoint tracking remains correct;
* completion is detected only when all expected endpoints have been processed.
The pending-endpoint implementation should avoid relying on Lua’s length operator for sparse tables. Removing numeric entries with `table[index] = nil` and then testing `#table` can produce undefined results when holes exist. A keyed set with an explicit remaining count would be safer.
### Explicit-read test
Verify that initial configuration sends one combined READ request containing `AvailableEndpoints` for Electrical Sensor endpoints 7–12 while retaining the wildcard subscription.
### Idempotency test
Call the basic child-creation path multiple times before simulated child creation completes.
Expected result:
* only one creation request is made per `parent_assigned_child_key`;
* failed creation attempts can still be retried deliberately.
## Requested onboarding log information
A complete log should begin before commissioning and continue through device configuration.
The most useful information would be:
1. `added`, `init` and `doConfigure` lifecycle events.
2. The complete endpoint list.
3. On/Off server endpoint IDs.
4. Electrical Sensor endpoint IDs.
5. PowerTopology feature maps.
6. The outgoing `AvailableEndpoints` subscription.
7. Any explicit topology reads, if tested with a modified driver.
8. Each `AvailableEndpoints` report:
* endpoint ID;
* interaction status;
* decoded endpoint array.
9. Values of:
* `POWER_TOPOLOGY`;
* `BATTERY_SUPPORT`;
* `ELECTRICAL_SENSOR_EPS`.
10. Any call to `try_create_device()` and its result.
The decisive questions are:
* Does SmartThings see On/Off endpoints 1–6?
* Does it see Electrical Sensor endpoints 7–12?
* Does `init` execute before `doConfigure`?
* Is `BATTERY_SUPPORT` set to `NO_BATTERY`?
* Is the wildcard `AvailableEndpoints` subscription sent?
* Which Electrical Sensor endpoints return initial reports?
* Does the pending endpoint collection ever reach a valid completed state?
* Does execution reach `create_or_update_child_devices()`?
* If it does, are five `try_create_device()` calls made?
## User impact
A six-outlet Matter power strip that previously produced six independently controllable SmartThings devices now exposes only outlet 1 after recommissioning.
The impact is particularly serious because:
* factory reset does not resolve it;
* Matter multi-admin does not resolve it;
* deleting an older working installation can convert it into the broken state;
* other Matter controllers still expose the six outlet endpoints;
* and the five missing endpoints are fully functional basic On/Off devices even if energy topology cannot immediately be resolved.
Optional electrical capability enrichment should not prevent valid On/Off Plug-in Unit endpoints from being exposed.
## References
Forum reports:
https://community.smartthings.com/t/driver-for-tp-link-tapo-p316m/310364
Official Tapo product page:
https://www.tapo.com/en/product/smart-plug/tapo-p316m/
CSA certification:
https://csa-iot.org/csa_product/smart-wi-fi-power-strip-13/
Independent endpoint telemetry:
https://www.matter-survey.org/device/smart-wi-fi-power-strip-5010-274
Production Matter Switch driver:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/tree/production/drivers/SmartThings/matter-switch
PowerTopology implementation:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/pull/2444
Change from explicit topology reads to subscriptions:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/pull/2792
Production commit matching the reported driver package:
https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/commit/165b12e44a4d6086eebacfdfa37e53b5a815d51f
