Edge Device Profiles leaking into other channels?

@nayelyz / @andresg In the past 2 days I have had users start reporting issues with their devices. They are on the same channel and driver that they have been since 1-6-23. I have had them verify this both on the command line and in the app. During that same 2 days, I have been working on a new feature locally and publishing it to a private test channel. As part of these changes, I am updating the device profiles. Some of the users are getting the new device profiles even though I have not published them.

The profile IDs match the new ones I am using locally, but they are still on the old 1-6-23 driver. Did ST make updates that would somehow allow these unreleased profiles to be distributed.

Here is one example profile. This list of capabilities and settings has never been released on the beta channel in a driver.

smartthings deviceprofiles 783ae447-61e9-3fc5-830b-a19f80c99d7e -y
id: 783ae447-61e9-3fc5-830b-a19f80c99d7e
name: group-dim-alerts
  vid: 853bcae6-2c6f-3e49-b253-0b8ea7f00fda
  mnmn: SmartThingsCommunity
  driverId: adeec9e8-efe9-43ff-b35a-28c0121c4a57
  driverStatus: DEVELOPMENT
  deviceProfileName: group-dim-alerts
migrationStatus: NOT_MIGRATED
  - preferenceId: importdelete
    name: importdelete
    title: Re-Import Deleted Devices
    description: Allow the device group to rediscover previously deleted devices
    required: true
    explicit: false
    preferenceType: boolean
      default: true
  - preferenceId: defaultscene
    name: defaultscene
    title: Default Scene
    description: Default scene to recall when switched on
    required: false
    explicit: false
    preferenceType: string
      stringType: text
  - preferenceId: enableAnimations
    name: enableAnimations
    title: Enable Lighting Effects
    description: >-
      Enable lighting animations and flashing effects. WARNING: This feature may
      potentially trigger seizures for people with photosensitive epilepsy. User
      discretion is advised.
    required: false
    explicit: false
    preferenceType: boolean
      default: false
  - label: main
    id: main
      - id: switch
        version: 1
        ephemeral: false
      - id: mediaPresets
        version: 1
        ephemeral: false
      - id: switchLevel
        version: 1
        ephemeral: false
      - id: colorTemperature
        version: 1
        ephemeral: false
      - id: colorControl
        version: 1
        ephemeral: false
      - id: orangebrook39927.hueAlerts
        version: 1
        ephemeral: false
      - id: execute
        version: 1
        ephemeral: false
      - id: refresh
        version: 1
        ephemeral: false
      - id: orangebrook39927.hueDiscovery
        version: 1
        ephemeral: false
      - name: Light
        categoryType: manufacturer
  ownerType: IMPLICIT
  ownerId: '474'
1 Like

I had a similar one today.

I updated a driver that already existed on my dev channel and hub by adding a new profile that hadn’t existed before. The initial edge:drivers:package -I of the driver completed with no errors, and the driver loaded. I paired the zwave device to the hub to test and while it found the correct driver and the profile name was correct, the presentation and capabilities displayed in the app was for another driver and device all together. This included the preferences too (so device A was bound correctly to driver A, but was showing presentation and preferences for driver B). I was confused as this made no sense. The presentation/preferences it was showing wasn’t in this driver at all!

I then added some debug logging to the driver so I could figure out what was going on, and this time when I did a edge:drivers:package -I, I got an error:

    Error: Request failed with status code 422:
    device profile specification for
    76b1baad-f3f2-49b6-b595-1a4665c84f35","details":[{"code":"SizeError","target":"name","message":"name must have a
    length between 3 and 24.","details":[]}]}}

Turns out, one of the preference names in the new profile I had created was 26 characters. But why did it package/compile correctly the first time?

I updated the preference name to fit the limit of 24 characters, re packaged it and it uploaded fine. I then excluded and included the device and it indeed was using the correct presentation/preference list this time.

To summarize:

  • The first time I went to package an existing driver with a new device profile that had an (accidental) error in it, the CLI acted like it was successful, but then a device told to use that profile name used a completely different driver’s profile.
  • Packaging the same driver again (correctly) produced an error that indicated I had an invalid profile. I fixed the invalidity and repackaged, and it was successful.
  • I had to exclude and reinclude the device to get it to use the new (corrected) profile.

@smartthings/cli/1.0.1 win32-x64 node-v16.16.0
Hub firmware: 000.046.00008

1 Like

That is also strange. This was on a different level though. I was messaging with a user that was on a driver from a few weeks ago and they were sending me log files and info on the device profiles. The profiles included a capability that I was working on today. It isn’t even completed yet and was somehow in their device. However, the log files showed it was running the original code indicated by the driver version. They had the correct version of the code, but not the correct version of the device profiles. In addition, the devices that had these incompatible profiles didn’t function. ST wouldn’t even send them events when buttons were pressed in the UI. The rest of the driver and untouched profiles were running fine.


Hi, @blueyetisoftware, @csstup

Are you using the same packageKey for every version of the driver? This is just to have a better reference of the issue.

Can you share the driver ID and both channel IDs, please?

Yep, the packageKey didn’t change. This driver already existed on my channel and hub, I just added a new profile to it.

Driver Id 76b1baad-f3f2-49b6-b595-1a4665c84f35
Channel ID: fa24a7e1-8d96-4ffb-9418-29f0731b3b27

The version that was messed up (meaning, it shouldn’t have packaged but it did, and when a device was paired to it, it used another drivers profile details) was
Version 2023-01-19T08:06:02.521866923

Then a few minutes later when I realized I wasn’t crazy and figured out the profile I was trying to add had the error in it I fixed it and packaged again.
Version 2023-01-19T08:23:33.950063219

Everything was the same, just assigning to different channels. I also have the development channel saved in a config, so it goes there by default. I verified that I never sent the profile to the beta channel used publicly by users. Will send IDs via DM. Thanks for taking a look at this.

Thank you both for the info.
I already reported the issue, I’ll let you know if we need more details or logs.


I’m fairly certain that if I start working on that profile again, it will show up for those users. Do you know if it is safe to resume development on profiles? In the short term, I had to create brand new profile names to ensure I didn’t impact users.

I would use a different package key but it can get confusing. I think that is your best bet.

@nayelyz It occurred again this morning. I made a change to a profile in one channel, and it popped up in the other. I can make a different driver locally, but not being able to use the same package key is going to stall development. Here is the development model in case the team needs to know:

4 different channels for deployment

  • Sandbox - Used locally for development and testing
  • Alpha - Sent to a small group of testers that are savvy with the CLI
  • Beta - Published in the community for broad use
  • Prod - Will eventually use for a fully fledged release, not in use

I use the same packageKey and control the version by deploying to different channels. I setup a CI system to manage the publishing so I don’t fat finger it. I personally only publish to sandbox. What I see is that users are getting the most recent profile published to any channel, not just their enrolled channel. This prevents me from doing any work or testing that requires a change to the profiles.

When this occurs, users are left with running code from their correct driver, but a profile from the newer driver. The incompatibility results in a variety of issues depending on the change.


Thank you for the info, @blueyetisoftware.
I already added it to the report. I’ll let you know when we get feedback from the team.

1 Like

Hi, @blueyetisoftware
The team tried to check if they could see something that would indicate why this happened, but there was not enough info.
So, is there a device with this issue? This is for the team to get more info from it, also to know the expected profileId and the current profileId which is incorrect.

@csstup, also in your case, is there a device that is still affected by the issue you mentioned? This is to get further info

No, it resolved itself after I fixed the error in the profile and re-packaged it.

The sequence was:

  • Packaged a driver that had an error in one of the device profiles in it that should not have let it package. It packaged anyway, but when the driver loaded, it would have been using the errored profile, yet the display in the app was for a completely different driver’s profile.
  • I couldn’t figure out what was wrong, I didn’t change anything but repackaged the driver again. This time the package failed with the error about the profile being in error.
  • Fixed the error, repackaged, this time it went clean. Removed the device and re-included it and it loaded the corrected drivers profile.