How can a team test a direct connected device?

Developer Programs Support
1

Hi,
How can a team test a direct connected device?
In this case team = multiple persons with separate developer accounts but with all accounts tied/connected to the same company.

This should be a very standard situation?!?

I have a working code-base running on an ESP32 for a specific direct connected device. I, as the author, can install a device on my phone. Connected team members cannot install separate devices on their phones.

All devices have separate identities (= keypairs) installed on the device, all serial numbers and public keys are visible and registered in the developer workspace.

The console error message, from the device, looks like (formatted into nice json)
{
“error”: {
“requestId”: “6f1facf2-af70-46cf-a2ff-c76f7d6904df”,
“error”: {
“code”: “ConstraintViolationError”,
“message”: “The request is malformed.”,
“details”: [
{
“code”: “NotValidValue”,
“target”: “profileId”,
“message”: “Profile 0a306763-4964-4111-9682-8fab74f19761 is not owned by location member!”
}
]
}
},
“target”: “STDKJfPohRB0rAYP”,
“event”: “error”,
“source”: “device-backend”,
“category”: “platform”
}

Cheers
/AH

2

Hi, @senspix

Based on the error message, it seems that all the registered test devices are pointing to the same device profile, so, to make it available to the whole team/organization, it must be published executing the following command through the SmartThings CLI:

smartthings deviceprofiles:publish [DEVICEPROFILE_ID]

Note: you can install the CLI following the linked documentation or directly from NPM.

1 Like
3

Hey Erick - This is interesting - I did not know that you could publish a direct-connected device profile, since it has some additional metadata specific to direct-connected devices. I know for example you can’t create them through the API - you have to do it on the Developer Workspace.

But if this works, that would be great. I had a direct-connect project I was sharing, but was telling users they had to (re)create their own device profiles. This would eliminate that error-prone process!

There was also the problem of sharing custom capabilities - something, last I knew, you couldn’t do since the Developer Workspace didn’t allow you to select custom capabilities outside your own workspace. Is that still the case?

4

Hi,

Thanks! It worked. I did not submit any additional information to the Smartthings backend so it seems like this publish method is not the same as publishing for commercial launch.

1 Like
5

Thanks for the heads-up, @senspix. And yes, these are different processes that are often executed during the certification of an integration.

However, the team has decided to share the deviceprofiles:publish API with the community, to overcome these accessibility issues. Also, you may find it useful in the future if you ever need to patch the metadata of your device.

Yes @TAustin, but publishing the device profile will allow users to use your metadata without the hassle of creating their own version of your custom capabilities to then create the device profile, simplifying a lot the installation steps.

6

Hi,

An additional question @erickv: It’s time to add OTA functionality to our project.
I have not added the firmware…-capability to the published device profile. I wanted to get the main functionality working first.
So…
Do you know if I can modify my device and then republish device profile OR do I need to set up a new project/device with all new info.

After this device (a type of water leak sensor) is finished and launched commercially the next project/device will need to include multiple custom capabilities that require user input as well as simple textual output.
In addition the device should/must include push notifications for alarm conditions in the device. Do you know if push notifications are possible for custom capabilities.

Thanks in advance

/Anders Holm, Sweden

7

Initially, you’ll need to create a new device profile, because a PUBLISHED device profile can no longer be updated.

Now, as the device and the device profile are attached by the deviceIntegrationProfileKey (referred at the onboarding_config.json file), I’m not quite sure if with just a reference patch is enough to actually update the device’s metadata and presentation. However, please let me check this in detail and once I have an update, I’ll ping you back!

1 Like
8

@senspix, good news = )

I double-checked this metadata update flow, and you’ll be able to update the metadata of your devices (those under your published integration) by patching the onboarding_config.json file.

So, to make this happen, I suggest you to do as follows:

  1. Create a new Direct-Connected project (for testing purposes).
  2. Create the new device profile.
  3. From this new device profile you’ll need the following information:
    • The vid and deviceTypeId (in case it changes), which you can get through the ST CLI:
    smartthings deviceprofiles [DEVICE_PROFILE_ID] -j
    • The Device Integration Profile Key Id, and version, which are displayed at the Developer Workspace, e.g.:
      image
  4. Patch the onboarding_config.json accordingly.
1 Like
9

Hi,
Another related issue (I’ll also post separate item): After multiple project tracks and project-owner switches it seems like my team has leftover onboarding profiles. Currently we have 2 live projects, 1 limited to a specific developer and 1 “owned” by an organization. We can see 2 onboarding configs in the (web) developer workspace but…

  • An Android phone sees 6 “device type name” (= onboarding profiles) when trying to add/register a device
  • An iPhone sees 4 “device type name” (= onboarding profiles) when trying to add/register a device.

This is why we believe there are leftover onboarding profiles. How do we delete them?