Installed and uninstalled not called on driver install or removal?

[gslender]

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 ??

Thanks

[gslender]

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 ???

[martyn]

@gslender

Have noticed that the install()

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

@gslender

and uninstalled() methods

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).

https://docs.hubitat.com/index.php?title=Driver_Object

Driver initialize question

won't be much consolation but I stumbled upon the need for capability initialize only a week or so ago... so I barely beat you at removing my dunce cap. I've had this set of hints in my "Templates" for years... /** 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() - r…

@gslender

the previous schedule will continue to be valid and execute

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.

@gslender

That's a bit odd and assumptive on behalf of the past use of the driver A right

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.

[djgutheinz]

@martyn

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.

Dave

[csteele]

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.

[martyn]

@csteele

But it seems one definition is missing:

uninstalled() - runs when device is removed

Interesting, wasn't aware that existed!

[csteele]

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

[martyn]

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

Wonder what else is available .....

[csteele]

My template contains a massive amount of cleanup code:

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

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

[gslender]

uninstalled() is documented... !?

https://docs.hubitat.com/index.php?title=Device_Code

[martyn]

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.