Certify Your Device

For Device Certification, it is strongly recommended to start the Edge Driver development process by simply adding a fingerprint to an existing Edge Driver. You can find existing Edge Drivers in the SmartThingsEdgeDrivers GitHub repository. If you do not find an existing Driver and Device Profile that match your desired user experience and you wish to create a new Device Profile, add a sub-driver, or add a new Edge Driver, contact us at partners@smartthings.com before proceeding. 

tip

For more in-depth info on the WWST certification process, visit the Certification section.

Hub Connected Devices Certification Process Overview

1. Submit a pull request in the SmartThings Edge Drivers GitHub repository containing your Edge Driver changes. Please submit one pull request for each device seeking certification.
2. Submit a certification request in the SmartThings Console: From the Console, add your product information and complete a certification request. This request will be passed to an Authorized Test Provider, who will issue you a price quote for certifying your device.
3. Ship your device: After accepting your quote, ship your device to the Authorized Test Provider according to the instructions (may vary based on region).
4. Device testing: Once the Test Provider has received the device, they will begin certification testing. The test results will be delivered to you within 10 working days. If a re-test is required, a quote for additional tests will be issued. Products that have passed the test can be published in SmartThings.
5. Publish your device: Your product will be automatically published in the SmartThings catalog once certified and will be permitted to use the WWST logo. If you would like to schedule a publishing date, please contact us at partners@smartthings.com.

Included in Your Console Submission

Device manufacturers with a Hub Connected Device backed by an Edge Driver wishing to receive Works With SmartThings (WWST) certification must submit a certification request through the SmartThings Console.

Brand

Your company brand name and logo are displayed in the SmartThings app, where users can discover and integrate with your device. Your company can have more than one brand displayed in the SmartThings app, but each device can only appear under a single brand name.

Edge Driver Pull Request

Each product you submit must include a pull request containing your Edge Driver changes against the SmartThingsEdgeDrivers public repository. Enter your pull request GitHub URL into the SmartThings Console.

✅ Each device seeking certification must have its own pull request.

✅ Ensure your pull request code adheres to the Code Formatting and Submission Criteria outlined below.

✅ Thoroughly test your device behavior.

✅ Submit your pull request containing your changes against the SmartThingsEdgeDrivers public repository. By submitting a pull request, you represent that you have the right to license your contribution to SmartThings and agree that your contributions are licensed under the Apache 2.0 license.

✅ After submitting your pull request, you will be asked to agree to the SmartThings Individual Contributor License Agreement before your contributions can be merged.

✅ Once your device is certified, your pull request will automatically be merged and your Certified Device will be available publicly in the SmartThings app.

You will also be asked to associate your product with a driver and fingerprint in the Console. The driver package is uploaded and associated with your organization ID during the development process using the SmartThings CLI (we recommend using an existing Edge Driver and simply adding your device's fingerprint).

If your driver and fingerprint do not appear in the Console dropdown menu when creating your product in the Console, you can use the following command in the SmartThings CLI to upload your driver and associate it with your organization ID:

smartthings edge:drivers:package [path_to_dir] -O [organization_id]

Onboarding Profile

An onboarding profile is a set of screens with pairing and troubleshooting instructions the user will see when adding your device for the first time. The same onboarding profile can be used for multiple product submissions if the instructions are the same. This name will be displayed under the Brand and device category in the SmartThings app. If your device is available in multiple languages, provide translations for each language by selecting the applicable language and adding the translated text in the area provided.

Code Formatting and Submission Criteria

Before submitting your pull request, please review the following to ensure your pull request is approved in a timely manner.

Code Formatting

Area	Rule
Indentation	Code should be indented using 2 spaces, indexed off the most recent level of indentation.
Line Length	Lines of code longer than 100 characters should be avoided and wrapped across multiple lines. This rule may be relaxed in some situations, but should generally be followed. If this limit is being pushed due to many levels of indentation, consider refactoring to extract methods in order to reduce indentation and complexity. Early returns may also help to reduce indentation levels.
Variable Names	Variables should be named using snake_case. If the variable name is short and sufficiently clear without underscores, underscores may be omitted (as is done in the Lua built-in modules). If in doubt, include underscores for ease of reading.
Function Names	Function names should follow the variable naming convention of snake_case.
Class Names	A table that acts as a class (data with associated functions) should use PascalCase.
Acronyms in Class Names	If a class name contains an acronym, the Rust convention of making the consecutive letters beyond the first lowercase should be followed. For example a "ZCL Command Handler" class should be named ZclCommandHandler and NOT ZCLCommandHandler.
Constants	Constants should be all uppercase with words being separated by underscores (e.g. MY_CONSTANT_NAME).
Module Names	Where possible, module names should be all lowercase. Underscores may be added for clarity between word names.
Semicolons	Semicolons should only be used where syntactically required and should otherwise be omitted, including at the end of statements.
Operator Spacing	Operators should be surrounded by one space on either side. Correct: local x = 128 Correct: if x > 57 then Incorrect: local x=128 The exception to this rule is in for-loop initializer lists, where omitting the space is required for syntactic correctness: for i=1,10 ...

Submission Criteria

Pull requests will be denied if they contain any of the following:

• Multiple devices per certification request.
• Custom Capabilities, such as those that are not in the SmartThings namespace.
• Custom Preferences, such as those that are not in the SmartThings namespace.
• The device uses a custom Zigbee, Z-Wave, Matter cluster.
• A duplicate fingerprint already in use by another SmartThings Edge Driver
• When possible, manufacturer-specific names should not be used in naming a profile.