There are many reasons to want to assign a device to a different profile, for example:
An error was made in the initial device inclusion
It is a profile shared by several devices and that device now needs different preferences than the others.
If when the driver starts after a new driver update the profiles are not assigned to the devices, there would be no way to resolve those problems or needs without having to reinstall the device and that has been done by smartthing and all of us since edge was born. .
In fact, on devices that can have several profiles and are changed from preferences, multiple mosaics, different range presentations, … We have to add a code in the init life cycle so that the profile that the user has chosen in preferences is assigned, since by default always when the driver is initialized by a hub firmware update, reboot, driver update, the fingerprint.yml profile would be assigned and the preference and the profile that the user sees would be desynchronized.
If this has changed without prior notice, then they will know how they are going to solve their own problems with profile changes in stock drivers!
AlejandroPadilla
(Please contact @nayelyz or @Luis_Humberto_Medina )
23
AlejandroPadilla
(Please contact @nayelyz or @Luis_Humberto_Medina )
25
I verified it with the team and this has always been the expected behavior, changing the profile in a device fingerprint only affects new installs, in order for a device to use a new profile via fingerprint it must be rejoined.
I can not believe that this always been the case, I have changed hundreds of times to new profiles and they have been assigned without having to join the device again, simply by installing the new driver version the profile is assigned.
Does that mean that for example, when smartthings have changed these multipurpose sensors from the smartsense-multi profile to the multi-sensor profile, in the BUG-8648, smartthings expect users to find out that they have to uninstall and reinstall their devices for them to work with the new profile?
Or when they changed the fibaro double switch to a profile without buttons or other hundreds of times that they have changed devices to differents profiles?
Do they send an email or something like that to the users so they know they have to reinstall their devices?
Of course, if this has been like this for more than two years, I’m pretty sick in the head!! I better leave it and not touch anything else
AlejandroPadilla
(Please contact @nayelyz or @Luis_Humberto_Medina )
27
This is possible if you also change the profile itself, the team commented that the profile is assigned when the device is fingerprinted, or if the driver uses try_update_metadata, there isn’t another time when a profile can be selected.
That is correct because in this case, the profile wasn’t updated only the fingerprint file
Do you recall that for certain devices, “rejoin” implies that the user needs to contact a certified electrician and remove devices from walls and hidden niches?
Perhaps it could be resolved with software?
So if that is so, in this case the users who paired their devices in the automatic migration with the smartsense-multi.yml profile that does not have the garageDoor preference.
Months later they modify the driver and the fingerprints.yml and assign the multi-sensor.yml profile to those devices.
So users who automatically migrated their devices will never see the multi-sensor.yml profile on their devices until someone tells them, or it occurs to them by chance, to reinstall their devices so they can use it as garageDoor?
And exactly the same as the numerous profile changes made during the beta period.
Will there be user devices that are still using profiles that no longer sync with the code that the driver currently executes? For example, many fibaro double switch users?
This device had the profile switch-1-button-6-power-energy.yml, with 2 switches and 6 buttons and now it is assigned the fibaro-double-switch.yml, which only has 1 switch and 1 button.
The driver no longer has code to control the 6 buttons and switch1 and will give errors.
In this particular case the fibaro-double-switch.yml did have the six buttons when it was introduced alongside parent/child and was modified later when the button code was removed because they were told it wasn’t doing anything. It sounds like they may have been misinformed by their testers.
That doesn’t in any way change your point though. Fundamental changes like that seem to assume a degree of engagement and understanding that a significant number of users don’t have, and seems incompatible with the idea of the automatic migration programme. Put more simply, why are the end users supposed to know about changes like this, and how are they supposed to know?
Going back to the original issue, while I am content that my expectations seem to align with those of the engineering team, I am only saying that the current behaviour you describe is how I assumed it had always worked, not that I believed it actually worked like that.
My particular interest is more in how things link together but my viewpoint is mostly the API. So I can see that a device profile in the API /deviceprofiles endpoint is created for each profile in the driver package, and I know that the drivers/devices actually use the appropriate /deviceprofiles profile pulled from the API, though I’ve never figured out how the mapping between the two works beyond a suspicion that hashing is involved. When the content of a driver profile is updated I can see that a new profile is created in /deviceprofiles (or an existing one is reused if the change is a reversion) and any devices using the old profile magically get switched to the new one (I haven’t checked at what point the change happens). A try_update_metadata uses an internal profile name but actually switches the profile ID that is pulled from the API. That’s my limit though.
It sounds like it looks different on the inside and you have seen an obvious change.
If there is an error with the profile assignment in the migration, the user will only notice if they are missing something that they think should work and it doesn’t. for example, he can no longer use it as a garageDoor.
User open a report and smartthings tell his that they are very sorry, but that function is no longer available for those older devices in the new edge drivers.
If months later smartthings correct the error by assigning a new profile to the device and when the new driver is updated in user hub the new profile is not assigned to their device automatically, then those normal users, without technical knowledge or desire to waste time acquiring them, They will never know that garageDoor preference problem is already solved but you have to reinstall your devices.
Absurd!
My knowledge of how the API works in all this is zero.
I only know what as a user I think is logical and I would expect.
What I have seen when I have made profile changes in different drivers is what I have told.
Just as I have seen now that the new profile is not assigned automatically, I would also have seen it on other previous occasions in the last two years. Whether it worked fine by magic or because the API did things on its own, I don’t know.
I just want to know how smartthings and the users who share drivers have to solve an error that involves having to assign a new profile to a device and that the users see the problem solved without having to inform them when they have to reinstall or not their affected devices since this it would be impossible to do so.