Cool, I think you’ve found the best solution. Just in case though I wanted to provider another option. I’ve had a couple of cases where I needed debounce behaviour and implement a module:

if you add this module to your dependencies:

def deps do
   [{:debouncer, "~> 0.1.3"}]
end

you can just do:

  def handle_info({:circuits_gpio, _, at, 1}, %{on_push_fn: on_push_fn} = state) do
    Debouncer.immediate(:circuits_gpio, fn -> on_push_fn.(at) end, 5_000)
    {:noreply, state}
  end 

And it will ensure that the event identified by the first argument (:circuits_gpio) is not triggered more often than every 5_000 millisecond.

There is actually a range of different debounce behaviors I needed in some of my projects so the module implements four different functions. All of them take 3 argument: (event_key, function, timeout)

• apply() - executes an event after TIMEOUT and so creates a regular interval from frequent events
• immediate() - is the same as apply() but triggers also immediate on the first event
• immediate2() - executes the first event as well immediately but mutes all further events until after TIMEOUT
• delay() - every event delays the trigger by TIMEOUT, will issue an event only once there has been no event for TIMEOUT milliseconds

Or here in a text graph:

  EVENT        X1---X2------X3-------X4----------
  TIMEOUT      ----------|----------|----------|-
  ===============================================
  apply()      ----------X2---------X3---------X4
  immediate()  X1--------X2---------X3---------X4
  immediate2() X1-----------X3-------------------
  delay()      --------------------------------X4

Hope this helps some readers.

Wow, nice! Thanks. I will definitely keep that in my toolbox.

I’d use send_after & cancel_timer or sleep functions instead of if statement. For example: Process.send_after(self(), {:debounce, on_push_fn, msg}, @debounce_time) + handle_info for :debounce.