Installed and uninstalled not called on driver install or removal?

Have noticed that the install() and uninstalled() methods are not called when you change a driver for a device if it has been loaded before... so also wondering what other things remain in "state" between changing between drivers for a device??

Can the logic for how "installed/uninstalled" is called be provided so that we can better appreciate what is going on under the hood ??


Another example of changing a driver odd behaviour - if you start with Driver A (and it creates a runin schedule) and the change to Driver B, and then back to Driver A, the previous schedule will continue to be valid and execute !? That's a bit odd and assumptive on behalf of the past use of the driver A right ???

I don't believe that there's an install() method .... there's installed() which is called when a device is first created.

As far as I'm aware, there's no uninstalled() method (if you think about it, "uninstalled" implies after the event, at which point the device is gone and the driver is no longer active).

It will actually still execute under Driver B since it's a "system" job at that point i.e. the system will try to call the method from Driver A at the scheduled time. If that no longer exists you'll get an error in the logs.

As far as I'm aware there's no hook for a "driver change" so it's not possible to do any cleanup when a user chooses to change a driver.

In my drivers I tend to use updated() and configure() to check for any unwanted states, schedules, etc and then clean them away. That way at least if the user clicks configure() or saves preferences, the driver will set a default state.


Martin is correct on updating driver data and state. I run Updated from the App as an instruction every time someone updates data, installs a new device, or as part of the instructions for updating drivers. In the driver, method updated:

  • includes unschedule() to stop all running scheduled activities
  • Checks if the update is for a driver version change. if a change:
    • add new data and states
    • update existing
  • Then reschedules all periodic activities.


I have this saved in my Templates:

mike.maxwell (Leader)
May 25, 2018

installed()  - runs when driver is installed, via pair or virtual
configure()  - runs when driver is installed, after installed is run. if capability Configuration exists, a Configure command is added to the ui
initialize() - runs first time driver loads, ie system startup when capability Initialize exists, a Initialize command is added to the ui.
updated()    - runs when save is clicked in the preferences section

Initialized() is not a capability or built in driver command, it's a local method only, I've never understood it either, i guess it saves a few lines of duplicate calls...

But it seems one definition is missing:

uninstalled() - runs when device is removed

My driver template is nothing but those routines and so on... if I install it as-is, and then create a virtual device to use it, I can see the methods being called easily enough:

dev:433 2021-04-20 09:29:40.346 am trace Msg: uninstalled ran
dev:433 2021-04-20 09:29:32.084 am trace Msg: updated ran
dev:433 2021-04-20 09:29:20.267 am trace Msg: installed ran
dev:433 2021-04-20 09:29:20.262 am trace Msg: initialize ran

Initialize and installed both ran as a result of creating the virtual device.
Updated ran as a result of clicking Save Preferences.
Uninstalled ran as a result of clicking Remove Device.

1 Like

Interesting, wasn't aware that existed!

Maybe back in 2018 when @mike.maxwell wrote those words, uninstalled() didn't yet exist. But it does now :smiley:

yeah :slight_smile: Guess there's no excuse for not doing driver / app cleanup on uninstalled() then.

Wonder what else is available .....

My template contains a massive amount of cleanup code:

void uninstalled() {
    log.warn "uninstalled..."

:smiley: :smiley:

States get removed by the platform. I've only found scheduled tasks to be left behind.

uninstalled() is documented... !?

1 Like

Just shows really how much the docs could do with an overhaul since it's not documented on the "Driver Object" Driver Object - Hubitat Documentation which is probably where most people would look for driver related code.

Download the Hubitat app