When devices in the smart home have to be replaced, the current process requires that we delete the old tile, and create a new tile.
The preferred solution would be to be able to re-assign a tile to another device.
There are two scenarios that I can see this being used: Existing tile
For the existing tile scenario, the user should be able to select an existing tile, select the tile options, and “reassign device” menu option. This will then present the typical item search. The new tile should then copy all compatible settings to the new tile. In the most basic form, this will perform a delete and add, and making all the same customization settings to the new tile. the typical use case would be to replace a switch with another switch, but a switch could be replaced by a color bulb, or a dashboard tile.
Placeholder tile
When a device has been deleted from the HA hub, the device’s tile is converted to a place holder. In edit mode, the user should be able to re-assign the device the same as in the prior scenario, restoring all the visuals of the tile from before being replaced with a placeholder.
Changing out a ‘Thing’ with another ‘Thing’ that has the same attributes seems relatively straightforward.
–
But switching out a ‘Thing’ tile for a completely different thing (switch to motion sensor) or a ‘Thing’ to a totally different tile type (Dashboard) comes with challenges. Even when manually changing between layouts of a tile, the various Additional Options that can be configured for different tile layouts as well as state mappings get cleared out as they more often than not fundamentally incompatible with each other.
For example, a temperature sensor might configured with styles for various different numeric temperature thresholds – if the ‘target’ of that tile was changed to a True/False variable, for example, then the mappings would be fundamentally incompatible. Similarly, additional options from a Switch Tile (like ‘Enable Glow’) don’t translate to something like a Thermostat (which has options for Heat/Cool Color)
Thank you for your consideration of my feature request.
I do understand that dissimilar tiles have challenges. What I would propose is to store the customization as a map of settings. Then replace the underlying thing with the new thing. Now, obtain the available customizations of the new thing as a map. Next, perform a union intersect of the keys for the two maps to obtain the list of compatible attributes. Using the intersected keys, apply all the changes from the old map to the new thing’s tile. All incompatible attributes are thrown out.
I realize it may not be this simple. I realize that it is entirely possible that all tiles may not share a consistent attribute naming system. And that (for example, a tile that supports one icon, vs a tile that supports two) the icon states may not align (like on/off vs open/close). For these cases, I would resort back to default state for those attributes.
Ultimately, what it comes down to is that position, size, & title would always be retained. Custom styles, icons, colors, etc… may or may not be. Additional attribute states may or may not be (like tap via long press behavior).
But overall, being able to replace the tile with a new tile that has the same position, and size is actually enough to make this worth the implementation, as we can more quickly reassign tiles.
Why?
Because currently, if we remove the old tile, the dashboard reflows. And when we put back the new tile, the flow may remain broken if the tile size was not 1x1.
Another use for the ability to change the device assignment would be when developing new dashboards. This feature was available in the now defunct HubiVue and was great when adding a number of the same type of devices where a lot of style modification were made. I would develop one tile and then copy / paste as many as I needed, then could go in and simply point the copied tile to the correct device.
