@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
metadata:
vid: 853bcae6-2c6f-3e49-b253-0b8ea7f00fda
mnmn: SmartThingsCommunity
driverId: adeec9e8-efe9-43ff-b35a-28c0121c4a57
driverStatus: DEVELOPMENT
deviceProfileName: group-dim-alerts
migrationStatus: NOT_MIGRATED
status: PUBLISHED
preferences:
- 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
definition:
default: true
- preferenceId: defaultscene
name: defaultscene
title: Default Scene
description: Default scene to recall when switched on
required: false
explicit: false
preferenceType: string
definition:
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
definition:
default: false
components:
- label: main
id: main
capabilities:
- 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
categories:
- name: Light
categoryType: manufacturer
owner:
ownerType: IMPLICIT
ownerId: '474'
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:
{"requestId":"D1333C37-7282-43D1-8691-21F2359B8FB3","error":{"code":"ConstraintViolationError","message":"Invalid
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.
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.
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.
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.
@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.
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.
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.