Save and apply "Switch Profiles" - Useful for firmware updates and applying same settings to multiple switches

Idea is to have the ability to save (and later apply) switch profiles to your switches.
Use-case 1: Firmware updates within Smartthings via the direct method (i.e. not secondary hub method) require the exclusion and re-inclusion of switches. The switch will then need to have all previous settings manually adjusted (either via app or IDE parameters or manually on switch). If there were an option so SAVE any existing switch’s settings as a Profile, one could re-include the switch and simply APPLY the saved profile back to the switch - and all previous settings would be restored.

Use-case 2: If users wish to set up a group of switches to have similar settings (e.g. all have LED light bar be purple, Notifications are mirrored across all switches, dim rates, etc) so that they all look and behave the same way. With this feature a Switch Profile is created or saved from an existing switch’s current configuration. Then user can go into the settings of any other switch and Apply the same switch profile from the menu and all settings are magically applied to that switch. Updating the Switch Profile would also allow updates in one place that essentially immediately roll out to all other switches with that profile.

1 Like

@EricM_Inovelli – this is a cool idea. Is this possible from a product perspective or is this a hub limitation?

Could be something to add to our hub if we ever release one :wink:

It is a cool idea that would have to be implemented on the hub. In Hubitat you could create a rule that sets the custom command “setParameter” on a bunch of parameters and manually apply it to switches as a group.

Hubitat V2.2.5 added a feature called Preference Manager.

Hubitat Elevation Platform update 2.2.5 is now available:

New Apps

  • Preference Manager: Set any or all of your device preferences at one time.

Its a nice tool for setting multiple preferences on multiple devices all at one time. It works pretty well, but does not support the saving of multiple profiles.

4 Likes

+1 - I use this, works 90% of the time and fails on occasion. It allows store/apply based on parameter name or device type.

@Eric_Inovelli - parameter consistency across product families would be great. For example, “LED Color” is “Light LED Indicator Color” (18), “Fan LED Indicator Color” (20), “LED Strip Color” (5) and “LED Strip Color” (13). This becomes complicated when we go across many other parameters. Realize this may be a bottom of the pile request :slight_smile:

I realize Fan/Light will have to be separate parameters, but, even on Fan+Light, a “LED Strip Color” as the common denominator setting would make it easy to configure consistency across all 20 switches at home :slight_smile:

A stretch request - change parameter names to be java package naming convention. All lowercase, dot separated - led.color, led.color.on.brightness, led.color.off.brightness, notification.1.led.color, notification.1.led.effect, notification.1.led.brightness etc.

1 Like

tagging @EricM_Inovelli – this is above my pay-grade lol

1 Like

+1 on that request. I realize it may not get high priority, but continued efforts to standardize parameter names/numbers and increase consistency in settings across the product line would enhance the overall owner experience that much more :slight_smile:

2 Likes

+2. Programming these is a nightmare if you have more than 1 product in your house that you want to behave similarly (same notification, etc.).

2 Likes

Must be a HA thing . . .SmartThings shows the settings in plain English . . . :rofl: :rofl: :rofl:

j/k . . +1 from me too. In addition to standardizing the parameter numbers and parameters the descriptive text equivalents (where used) should be standardized as well.

For Hubitat users you could create a Rule that sets several parameters via the custom command setConfigParameter. You could have the actions be to call the custom command on a bunch of like devices (Inovelli Dimmers, Inovelli Switches, etc.). The trigger could be a virtual button. If you add a device just put it in the rule and run it again.

1 Like

Equivalent on HA would be scripts, but it’s manual/prescriptive.

I use Node Red and it’s not THAT bad, but I do have to split the command into unique paths for each type of device.

1 Like