Setting up a driver timer

I need to run something only once per driver rather than per device. All the examples have setup of timers happening in device - init handler. Is there a driver init handler that allows me to setup a timer at the driver level? There is a driver:call_on_schedule, but setting it up has been the issue…

I have been hacking it by setting it up in device init but then trying to make sure it only happens once. The driver lifecycle method says only the shutdown event is sent. Would be great if there was also can init event that is sent to the same method… Or is there another way to do it?

Hi, @schwark!
When would you want to execute this action for the driver?
This is because its execution depends on the device’s discovery. This means it isn’t “active” until it discovers at least one device.
Also, would this action have to interact with the discovered devices?

This is a timer I want to setup on the driver, and it runs every x mins - and it does update state on ALL devices it had created. If there are no devices, it can just return immediately.

Given that the driver discovers many devices, setting up this timer from the init of the device is quite hacky as it should only be setup once. I would prefer to setup the timer at driver init - and it only does anything if there are child devices.

Was not completely sure of the exact intent of the questions, but hopefully this answer them?

1 Like

Yes, this provided a better overview of the issue. I asked the team and they mentioned we can do the following:

local driver = Driver("MyDriver", {
     --...
  })

log.info("Starting Driver run loop")
driver:call_on_schedule(5, function() log.info("This is an example timer that runs every five seconds") end, "test_timer")
driver:run()

Using this configuration:

  1. The schedule is created using the Driver object
  2. It will start once the driver starts running, this means when a device gets associated with it.
  3. Considered that if the driver gets restarted (e.g. there’s a script update), the schedule will be affected as well.
  4. The timer itself can be stored on the Driver object as well. This would allow you to access it (and cancel it) from a lifecycle for example.

Note: The driver object can be used as an arbitrary local state store for things that don’t need to be reflected up into the rest of the integration. We can create new keys.

When I did that, it prevented the driver from starting up properly… it went into some weird loop and the driver would not start… When I move that call into the device init, everything went smoothly… That was what prompted my initial question.

Which type of driver was it, did you create several devices consecutively?
This is just to check if the configuration could be related, the team made a test before I shared the information and it worked correctly…

Update:
Can you share your configuration of the timer including the callback, please?

Calling setup_timer before driver:run causes the driver to not startup properly…

Hi, @schwark

Sorry for the late response. I am Andres, a member of the Developer Support team.

Can you elaborate on this? I did some tests on my own and I don’t find any weird behavior.