FlyingDiver wrote:It gets the name of the door from the MyQ servers (plus the MyQ unique ID). I had to fiddle that code a little because I had at least one user that didn't use unique names.
The devices really need to be deleted and let the plugin create new ones. You should never need to create new devices manually. I know that's not the norm for Indigo. I guess I could redo it to cache the known devices and let the user create them the normal way.
Ah. I was confused because you mention above that the device had to be recreated - so that's what I was trying to do...
I'd highly recommend that you follow the normal Indigo pattern - only create a device when the user goes through the standard new device creation steps/experience. It's a fundamental process that every Indigo user learns early and to do otherwise is pretty jarring. It's a bit like those old ports of windows (or java) apps to the Mac where it just feels wrong. There are some places where we do it, but that's only when there are dependent devices (airfoil speakers on an airfoil instance) or multi-function devices (multi sensors which have motion, temp, humidity, etc). But the user starts the process the same way by creating a new device so it still follows the UX pattern.
It would also solve the problem that anyone doing this upgrade is going to have to deal with: editing ALL locations where the door device is used. The process is much easier if the user can just "fix" the device that's already there (thereby preserving all dependencies) vs having to go to all dependent locations to change them to use the new device.
Just some thoughts...