[ST Edge] - Driver Lifecycle Inquiries

Question/comment regarding lifecycle handlers:

From what I can tell, when you reinstall a driver, this lifecycle event is first generated from the existing driver, then there is a 10 second delay, and then the new driver is actually installed. I could use this event to assume there is a new driver about to be installed, and in my case, take the device offline. However I don’t think I can assume this is the only case where this lifecyle event might be called.

Can someone share some other examples of when infoChanged gets generated, and what data is likely to have been changed?

Documentation is a little fuzzy on this: only deleted is listed as a lifecycle event handler, but there is also a referenced to removed below that:

removed will remove the device from the device cache and make the device inoperable.

Isn’t that similar to updated() in a DTH? So things like the device name being changed and the device preferences being updated?

Maybe so, but I’m not seeing any data that HAS changed when I look the old_st_store arg. At least not when it’s invoked because of a driver reinstall…

I haven’t figured out a way to programatically compare it to the device arg that is passed (which supposedly has the new data), because they are two completely different tables.

That’s right! The infoChanged lifecycle will be invoked if a preference/setting gets updated.

As for the removed lifecycle, its going to be called if you change the driver of the device or if it gets deleted and given that the removed lifecycle handles deletion operations, I’m not sure if the deleted lifecycle was supported and then replaced by the removed or accomplishes additional tasks in the background. I’ll double check this one with the team right away!


Based on this log, it seems that the deleted lifecycle was replaced by removed, however, I’ll patch below as soon as I get a confirmation.

DeviceLifecycleDispatcher: 230022
1 Like

I am not seeing a removed lifecycle when changing drivers. I am seeing an infoChanged . And don’t see what data has actually changed in old_st_store when that lifecycle handler is called in that scenario. So it’s not clear to me what my handler is actually supposed to do.

Hmm… it is really odd that neither of us are able to trigger the driverSwitched lifecycle because even if we don’t specify the handler, we should be able to see the log reference:

received unhandled lifecycle event: ...

I’ll document these issues, and as soon as I have an update, I’ll patch this post.

1 Like

Could you also find out about a lifecycle handler to indicate the hub is shutting down? To give the driver a chance to cleanly shut down open links, subscriptions, etc. to devices.


I have now seen this open topic about lifecycle handlers.
I put here the link of a post that I put about this item in another thread.

Mariano - Have you been able to figure out how to tell within an info_changed handler that it was called because of a driver update? Unfortunately I never heard back from Eric so my questions above have gone unanswered.

Do you mean the logcat of the infoChanged event of when the driver is updated to another new version or when you change a driver for a different one?

I’m referring to when you install a new version of the driver. Before Edge actually installs the new driver, it generates info_changed lifecycle handler calls to each device. There is then a 10 second delay (presumably to give your driver/devices time to do whatever they need to do), and then the driver is actually updated and init lifecycle handlers are called to re-initialize devices.

So within the driver’s lifecycle handler for info_changed, how can you programatically know that it is being invoked because of a driver update? What data can you inspect by looking at old vs. new device metadata that would indicate a driver update?

There’s a lifecycle that should indicate when the Driver is changed. (driverSwitched). However, it is not being triggered as it should, Erick already reported that so, as soon as we get more info about it, we’ll get back to you. :wink:

1 Like

I have created a new version of the smoke detector heiman driver that has 2 devices connected.

I send you the log where you see the infoChanged event on both devices.

I send you a screenshot of the information of one of the devices in API before installing the new version and after installing the new version. I don’t see any change, I don’t know if you can see anything.

There is no change in the app driver details either
I don’t know if this is what you mean.

Thanks for your reply! What Nayely is saying is that the info_changed should NOT be called with a driver change anyway. Instead there is another lifecycle handler called driverSwitched that is supposed to be called instead by Edge, but it is not currently working. Hopefully this will be fixed soon.

Yes, as I mentioned in the post, with driver chance by other, the logcat show as is called ini-> added-> driverSwitched-> infoChanged in this order and in this case the device info is changed, the driver id changes

I understand then, that in the future, when a device’s driver version is updated, the “driverSwitched” + “infoChanged” life cycle will be activated, just as it is done now when a device is changed from a driver to a different one in the app?

Please @nayelyz , could you clarify what it means in the logcat when an event is received … received lifecycle event: added and then it shows
received unhandled lifecycle event: added.

For example, in a process of changing a driver on a device for a different one in the app:

  • The only lifecycle event that does not have the unhandled lifecycle event is “driverSwitched”

Does this mean that “driverSwitched” is the only lifecycle handler that is executed in this process?

I attach a screenshot of the process logcat:



I have now seen that it seems that the lifecycle event is executed even if the unhandled is received, since I have seen that in the driver from where the device was removed to added with the new driver. The unhandled appears and the device was removed correctly.

This is because the driver goes through those lifecycles but there are no handlers that “catch” the event to execute other actions, print logs, etc.
For example:
We can add a handler for the removed lifecycle as follows:

-- Function called during the removed lifecycle
local function dev_removed(self,device)
    print("device removed")

local zigbee_multipurpose_driver_template = {
    supported_capabilities = {
    lifecycle_handlers = {
        added = added,
        doConfigure = do_configure,
        removed = dev_removed       -- added line

This way, there would be a handler for this lifecycle that prints “device removed” in the logs when the device is deleted. That message won’t appear, however, this is not necessary unless you need it for other purposes, the device is deleted correctly in each case.

1 Like

Lifecycle infoCanged executed every 1 hours.
Is this a driver default configuración,?

I checked some details with the engineering team and it seems this is the current behavior. To avoid any issues getting the new values of a preference value, take a reference to Persistent Store: