Built in Driver methods Behavior

@mike.maxwell, @bravenel
Can we have a description of when the following methods are called in drivers? They appear to be different from ST. Please see the list below and the behavior I expect based on my limited knowledge.

Installed() - occurs directly after the pairing process.

Initialized() - never totally understood this one but it's usually ran as part of installed. Does this ever occur automatically?

updated() - I expected this to be called when I changed a preference, device name, device label, etc. Does not appear to do so. In ST, this was actually called twice for some reason. Is that also to be expected in HE?

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

5 Likes

Ahh... so editing the device name will not trigger this in HE. In ST it did.

Thanks for the response. I'll have to find a way to code around this.

Any suggestions to have a method run when the device name or label changes?

Never had a need to do this before, what's the specific use case?

I have my child/component devices rename themselves based on the name of the parent. This was really important in ST because of limitations in the android app with changing component devices. Not really critical for HE but I wanted the driver to be as close to my ST version as possible.

You don't name them correctly on creation?

The reason it was added was because Alexa could be very finicky with understanding certain light/fan names and users would often change them to avoid the "there are a few devices with similar names...which one?" message. It's not really an important feature especially in HE. I was just curious if there was a simple way to do this.

I understand the problem with Alexa. I don't understand how the driver having a method fire when the user changes the name solves the issue.

@mike.maxwell, I would give a history of how the driver was developed and the issues/solutions we found but it would require more time than it's worth (and the issue it was meant to resolve shouldn't be present in HE anyway). I appreciate your response above as it clarified what I needed. We can treat this post as resolved. Muchas Gracias.

2 Likes

There are a couple of options you can use for this specific case.

You an use text inputs in the parent device to specify the labels for each fan and light child. Or change each of their labels manually, once they are created. If you set the child as a component device the only thing that is editable for the child is the label. So that seems like the easier route to me. :sunglasses:

2 Likes

Luckily in HE you can easily edit the component names..which is why this is a none issue. In ST you would could not edit the names on android devices (on IOS you could) so we had to allow the recreation of child devices based on the parent. A real PITA but thankfully not present with HE.

2 Likes

Hi @mike.maxwell I know I'm quoting you on a very old post. But its good info and I need some clarification....

I may be wrong, but it apears that updating or changing the driver file on the Device Information page, and then doing a Save Device to load the updated driver does not make a call to either installed() or initialize(). Can you confirm or deny if that is correct? And if not, shouldn't it?

I'm confident a restart of the hub would do it, but that shouldn't be necessary I don't think. Is it possible to get the "Save Device" button to call these two methods to activate the updated driver without requiring a system restart?

installed() is called on device install so the fingerprint must match..

initialize() is called on hub bootup and only if the driver has capability "Initialize".

That's why I put everything to setup a device in configure() with the capability "Configuration"

This also doesn't get called on a driver swap, but it is accepted and commonly referenced practice to hit configure button when changing drivers.

4 Likes

Isn't configure() commonly placed in the updated() code block? That way a configure is performed when Save Preferences is clicked. That seems logical to me.

BUT if configure() has an initialize() put in it, then we're initializing with every Save Preferences. I'm wondering it that is overkill and unnecessary, but not really sure the impact.

Yeah I get that I can manually "Configure" after a driver swap, but is there a reason the "Save Device" action can't trigger it when a driver change is made and then 'saved'?

Not in any of my code..

updated() and configure() are for different purposes..

updated() is called when preferences are changed.. configure() is normally initial configuration that typically only needs to be run once to setup the device.

2 Likes

I wouldn’t do this.. Each method has a purpose..

Thats good info, and ties in with the original topic from years ago about what each of these is for.

So can you help me understand the different purposes for install, initialize, and configure. If configure is only for initial configuration then I'll move all my preference changes to the updated() section. But if configure it then only for initial configuration, then what it initialize() for? And what would be somthing that goes in installed() that wouldn't be in initialize?

installed() on initial install of device during discovery

initialize() when used with capability "Initialize" it will call this method every time the hub boots up. So for things that need refreshing or re-connecting (LAN integrations come to mind here) ..

configure() when used with capability "Configuration" is called when the configure button is pressed on the device page. It is also called on initial install after discovery.

updated() is called when preferences are saved

I normally don't have anything in installed() and put everything that is needed for initial install in configure() so that it can be called when swapping drivers.

2 Likes

Ok, I get the 'timing' of when each method is activated. But I'm still trying to get clarity on the 'things' that should be performed in each step.

What 'things' only get done at install?
What 'things' only get done at initialize?
What 'things' get configured that aren't related to saving preference changes?

I know you're the zwave guy :wink: but I happen to be working on a zigbee driver right now and wondering where is the proper place to put the "ZDO BIND" commands? I currently have them in initialize()

and currently my installed() is basically just initialize() and configure()

I typically don’t use this at all.. This is at bootup so only needed for things like reconnecting to LAN integrations.. as an example

I don’t use this either as configure() is called after discovery too.

I use this to setup a device.. Set initial configuration values needed for proper operation, call to the device for initial values, and read device properties to setup driver functions (example: determine how many buttons a button controller has, or probe what functions a thermostat supports)

1 Like