V2/V3 Hub Beta Firmware 50.X

shows as 50.9 on the iOS app. I do wish the app developers would select a darker color for the text… the current light grey along with small text is hard to read :slight_smile:

1 Like

I must have gotten 50.9, but I don’t know when since hub event logs no longer exist for stuff like this.

What was introduced/fixed in 50.9?

1 Like

More information coming soon!


must be top secret SDC related changes :shushing_face:


Ive just checked and im on 50.9 now, smartthings are still monitoring my hub, had some strange stuff going on last night, Smart sockets switched off in afternoon for no reason, a smart socket that would switch off as soon as it was switched on eventhrough i had switched all @utomations off to this smart socket, also had motion sensors that was saying no motion in history but not reporting the motion it had received 30 seconds before, wonder ifits linked to the latest firmware update.

Im the same here

Hi @nayelyz

I’m making some changes to a driver and something that I don’t remember happening before is driving me a little crazy.

In one driver I have several profiles.
In the fingerprints.yml file I change a device from one profile to a different one and package the driver.

With the CLI I publish it and install it in the Hub.

I see in the logcat that the new version is installed, but the new profile is not assigned.

At first I thought it was because the capabilities were identical and only the preferences were different, but then I tried to change to a profile with different capabilities and the same thing happens.

I have tried two different drivers.

You can also check in my.smartthings.com advanced users, that the new profile has not been assigned

The only way for the new profile to be assigned is to make a change from any other driver or by reinstalling the device.

Has anyone else noticed this?

I can’t say I have experienced it but I wouldn’t expect anything different. The device has already been initialised with the profile in the fingerprints.yml file so that has made its contribution. The device’s profile could have been changed by the driver since then.

As you say, you could expect exactly that because you have no experience in that.

Device Profile changes in fingerprints.yml have been made daily to the stock drivers, the driver is updated in the Beta channel and the device is assigned a new profile when the driver is started after the update.
You can see a multitude of PRs in the github smartthings repository, this is one of the latest: muli-sensor.yml added a garagedoor preference and assigned this profile to old smartthings multipurpose sensors model: PGC313EU and model: PGC313, with smartsense-multi.yml profile assigned in previous driver version:

This has been happening for more than two years and I think it is a mistake since it would make corrections in profile assignment impossible without having to change the device to another driver or reinstall the device.

The latter seems desirable to me. As I say, the profile in the fingerprints file is just a starting point. If you have changed the profile since the device was initialised, either using the driver itself or via manipulation of the device object (which I think is possible, though I haven’t tried for a while), why would you want a change to the initial profile to be able to affect your running device? It would be a mistake to allow it.

If there has been an error in the profile assignment then you could always get the driver itself to change it.

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!

Hi @Mariano_Colmenarejo
Let me check it with the team, please give me some time

Hi @AlejandroPadilla

Are there any new comments on this?
Thank you

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’m sorry to disagree with that answer.

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


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.

Does this make any sense to do it like this?

If the parents say so, this will be so!

Thank you Alejandro

1 Like

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.

Well that’s what I say!

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.

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.