New Device (Matter Switch) Shin Dong A ES productId: 0x1000 #1872
Conversation
Adding an override, so that end point 2 on the device uses switch-binary and does not use plug-binary
|
Invitation URL: |
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against 2e18057 |
| @@ -153,6 +153,7 @@ local device_type_attribute_map = { | |||
| local child_device_profile_overrides = { | |||
| { vendor_id = 0x1321, product_id = 0x000C, child_profile = "switch-binary" }, | |||
| { vendor_id = 0x1321, product_id = 0x000D, child_profile = "switch-binary" }, | |||
| { vendor_id = 0x156B, product_id = 0x1000, child_profile = "switch-binary" }, -- Shin Dong-A ES Smart Switch | |||
There was a problem hiding this comment.
I think this might override the profile for every child device, including endpoints 3-6 which should use a color temperature light profile
There was a problem hiding this comment.
Yeah you are right, for some reason I thought this was only for overriding switch vs plug, but you're right this would apply to all the child devices.
We could make it so it just applies to the switch/plug types though as I think that is the only situation where this would be used. Does that make sense?
There was a problem hiding this comment.
Yeah makes sense! Should that be in a separate PR?
There was a problem hiding this comment.
Yeah we can put it in a separate PR in case it needs to be used by another device before this one completes cert (unlikely, but might as well)
There was a problem hiding this comment.
Ok that sounds good, I'll put something together!
There was a problem hiding this comment.
Depending on the deployment of that change too, we may need to update this PR to be rebased so that the partner can also get that experience as well
We are asking them to test with this driver sharing link, so it would b best to have that in there too
Thanks @ctowns and @nickolas-deboom
There was a problem hiding this comment.
I made a PR to address this here: #1874
There was a problem hiding this comment.
#1874 has been merged
There was a problem hiding this comment.
I don't know if I should post this here, but [email protected] says that support requests are no longer be monitored.
I checked out what you discussed and I think the profile we initially set up makes more sense.
The reason for this is that the switch directly controls the lights and plugs through relays inside the switch, not the IoT lights and plugs.
So Endpoints 1 and 2 are better labeled as plugs.
Also, Endpoints 3 through 6 can be viewed as lights.
This is because the switch directly controls the dimming and color temperature of the lights.
Please review again.
There was a problem hiding this comment.
In that case it sounds like we can remove this device from the child_device_profile_overrides list and change the fingerprint to "plug-binary" instead of "switch-binary". That way the first endpoint will join as a plug and the remaining end points will have child devices created based on their device type. cc @lelandblue @ctowns
Type of Change
Checklist
Description of Change
The purpose of this PR is to add a device to SmartThings for WWST Certification.
Summary of Completed Tests
Further testing is planned as part of the WWST Process
Link to CSA site on the Product.
The device is for a Shing Dong-A ES device that has multiple endpoints.
VID: 0x156B
PID: 0x1000
Matter Device Type according to the CSA (103)
The changes I made include adding the fingerprint and also adding an override for end point 2 on the device so it shows up as a "switch" instead of a "plug".