So I’m setting up some basic scripts for testing. I can observe that it is possible to construct the script using a call service as well as by choosing a device. I also chanced upon some post that said that its preferred to use call service since if the device has to be replaced in the future with another one then the replacement process is easier with this method. Is this true?
So, lets say I create a lot of scripts and automation and for some reason I have to change one or more of the devices sometime in the future. Is it possible to easily update the scripts to incorporate the new devices? If yes, how exactly? Or does the script have to be re created from scratch?
Yes. You just rename the entity_id of the new device to the same as the old device and everything else just works.
Other than that you can edit all of the scripts and automations and lovelace config to use the new device info thru the ui editors. But there should be no need to write them all from scratch.
I thought that was the whole point of a device id - that it was unique to that device.
I’m not really sure how the system would know that you got rid of an old device and that the new one is supposed to replace it. As far as I know there is no way to re-configure the device_id, etc in a user accessible way.
I’ve never tried this experiment but if I were to replace a Tasmotized device with an identical one, bearing the same name, etc, I wonder if its discovery information will be identical to the previous one. Because if it’s just a tiny bit different then it’ll look like a new device to Home Assistant (via the Tasmota integration).
To drive the point home, even if I physically remove the Tasmotized device, Home Assistant continues to believe it exists (albeit is unavailable) until I explicitly remove it via Configuration > Devices.
I’m not 100% sure but I think the tasmota device discovery info is based in some way on the device MAC address so it would always be unique.
And I don’t have any tasmota devices left to test it with since I’ve moved everything to ESPHome.
Again I could be completely wrong.
However, that’s kind of going to the point of the OP. There’s no way to know for sure if the new devices will take over the old device info or an easy way to make them do it as far as I know.
So it’s still best to avoid device automations/scripts if possible unless they are only used in one or two and they are easily updated to the new device.
I agree; I avoid Device Triggers/Conditions/Actions because, depending on the integration involved, the replacement device’s device_id may be different (that and the fact they don’t support templates and are more verbose).
In contrast, traditional State/Numeric State/etc trigger/conditions and service calls don’t reference an entity’s device_id and rely solely on entity_id. As long as the replacement device has the same entity_id, all existing automations/scripts/template sensors/etc that reference it will work without having to modify anything.
)