[ST Edge] - Driver/Device timers

Is there a way get a list of outstanding timers (one-shot or scheduled) from the driver class? I need to be able to cancel any outstanding timers at a point in my driver, but don’t see a way to do that from the driver documentation.

I know the alternative - keep track of them in a table myself…


Not yet, but I’ll check with the engineers if this is going to be addressed at some point.

For the moment you should be able to track your all your device timers under device.thread.timersand cancel them using the device.thread:cancel_timer method (for better reference, check the st.thread.Thread documentation).

Thanks Erick - For now, I’ve started tracking my own timers.

I have not explored the use of the thread libraries yet. I was hoping for some clarity in the documentation on why/when it’s needed (vs. just the regular driver stuff), how to use, and ideally an example. All that I see right now is just the reference API, but nothing addressing the aforementioned.


Check the lifecycles flow from the SampleDrivers/lightbulb-lan-esp8266 sample as it has a few references on how/when to schedule certain functions.

It also provides a reference to cancel the timers for devices that are being removed from the driver’s context.

Sorry for being obtuse, Erick - I was referring to more info on the threads library, not timers. :grimacing:

1 Like

I agree with you, even if it is a low-level API that is not intended for explicit use, it might be useful to know what’s happening down there. So, added to the report! = )

As at the moment the device.thread.timers doesn’t provide a human-readable reference of the timer/schedule, I think you might find useful the following references to keep track of your timers/schedules:

  • driver.device_cache[<device_id>].thread.watched_sockets
  • driver.message_handlers

These resources provide the reference of the driver and device timer/schedules including the label, which can help you to debug and maintain your timers.

1 Like

Ok thank-you!

Is that really the case? Since it’s documented (threads) in the driver reference it looks like it is intended for explicit use in certain cases. It’s those certain cases I’d like to understand better. (Patrick had also pointed me to threads when we were talking about possible blocking problems in one of my drivers.)

1 Like

It can be considered as such because it is not only a big part of the driver model but also a feasible block to build driver features that are not exclusively attached to the platform.

For example the register_socket API to initialize TCP/UDP servers (see example).