Support for interrupts on GPIO Binary Sensor

[AndersWestman]

Describe the problem you have/What new integration you would like

There is, as I know, no easy way to independent detect an incoming pulse on a GPIO pin shorter than the 16ms cycle time.
A possibility to enable an interrupt feature for the GPIO Binary Sensor would be a great benefit for those cases.

Please describe your use case for this integration and alternatives you've tried:

I added an ESP32 into an existing product to be able to read/sniff some signals, but some signals was as short as 100us which cause some problems as it is too short to be detected other then by just pure luck by the GPIO Binary Sensor.
The time between the pulses in this case can be widely different from a few times/s to several hours in between.

I was able to make a workaround by using the Pulse Counter Sensor, but it's not an optimal solution.
I had do use a very low update interval, create a binary sensor to evaluate if the counter has changed and set the logger to INFO to not flood the logs due to the low update interval on the Pulse Counter Sensor.
But it works.

Additional context

I don't have the knowledge how/if/what is possible to implement, but I can see at least two different main functional princips here.

1. The interrupt detects a pulse and ESPHome handles it in the next cycle which will cause a delay of some ms. Probably the easiest to implement (I guess?) and probably good enough for the majority of use cases.

2. The interrupt detects a pulse and ESPHome immediately handles it.
   I can't really see any obvious cases for this behavior as the cycle time will cause some ms delay for anything else anyway, but maybe there is?

Some possibilities to select which edge to trig on, and maybe even something for filtering would be nice if possible.
And there are surely some more things that I have not thought of... :)

I see something like this in my mind:

binary_sensor:
  - platform: gpio
    pin:
      number: D2
      mode:
        interrupt: true
          trig_mode: rising_edge     (or falling_edge or both_edges)
          internal_filter: 2ms
    name: ...

[ssieb]

If you use the pulse_meter, it will trigger on every pulse (minimum every loop).
You can't actually trigger anything from the interrupt. It would still have to wait until the loop.

[AndersWestman]

Yes, it would still have to wait for the loop, but the main idea here is to use the interrupt to be able to detect pulses shorter than the loop time.

The pulse counter was only used as a workaround to "get the job done".

[ssieb]

Try the pulse_meter.

[AndersWestman]

I have used the pulse counter and the exact same will be possible to achieve with the pulse meter, but those components are quite bulky and not wery convenient to use for the purpose of just catching a pulse shorter than the loop time, as described in the first post.

For that I had preferred a more obvious solution e.g. some way to "speed up" the Binary Sensor in the cases faster detection is needed for a single input.

[ssieb]

The pulse meter is very much better for this case than the pulse counter and I don't know why you think it's "bulky". Adding interrupt support to the gpio binary sensor is not suitable. A new component would be needed, but it would be basically the same as the pulse meter.

[AndersWestman]

Ok. It's possible that a new comportment is needed to solve this, but that is OK. I don't have that knowledge.

I may miss something wery obviously here with the pulse meter, so please feel free show/guide me how to solve this situation, that was my original case:

• Detect a single pulse with a length of 100us on a gpio pin
• When the pulse is detected, run an automation e.g. flash a led

Edit: As I understand, the main difference between pulse counter and pulse meter is that pulse counter measure frequency of the pulses and pulse meter measure the time between the pulses, which will give better accuracy at lower rates.
But maybe there is more into it?

[ssieb]

The pulse counter has an update interval. It accumulates pulses until that time. The pulse meter updates for every pulse, with a minimum of the loop interval, so it's still possible to get multiple pulses in an update.

sensor:
  - platform: pulse_meter
    id: pulses
    pin: GPIOXX   # whatever settings you need
    on_value:
      - flash led

[AndersWestman]

Ohh, I see. Yes, that makes some difference.
In that case I can absolutely understand your point.
I will try the pulse meter and see how it works for me in that use case.

[AndersWestman]

I have played some with the pulse_meter now, and it does pretty much what I'm looking for, but with one quite large drawback.
When no more pulses is present for a wile and the timeout for the pulse_meter kicks in, it will publish zero pulses which causes a false triggering of the automation (flashing the led).

Of course, some kind of workaround could be to set the timeout to some really high value if you are absolutely sure that some pulse will be present in that time frame, otherwise it will for sure get back and bite you at some time...

Is it possible to prevent the timeout publishing to occur?

Otherwise, the only way to solve it, as I can see, is my "bulky" solution that I used with the pulse_counter mentioned earlier, there I use a template sensor to evaluate if the value of the total counter have changed.
Or do you have any better solutions that I'm not aware of?

[ssieb]

Just filter out the 0.

[AndersWestman]

Yes, of course. Way did I not thought of that...?

[AndersWestman]

Some more testing, and as you predicted this seems to work very well to catch and take actions on very short pulses.

sensor:
  - platform: pulse_meter
    pin: GPIO27
    id: trigger
    filters: 
      - filter_out: 0
    on_value: 
      then:
        - output.turn_on: led
        - delay: 500ms
        - output.turn_off: led

Thanks for guiding me to this solution!

However, as I was searching quite widely and asked in the forum without any real success, it looks like this usage of the pulse_meter is not very widely known and I didn't fully realized/understood the differences between pulse_counter and pulse_meter even that I have read the documentation quite carefully.

Maybe it's worth mentioning some more in the pulse_meter documentation about this use case, if a new dedicated function like e.g. pulse_catch. or something similar is considered unnecessary?

[ssieb]

Would you be able to make a PR to the docs repo to improve it? You could maybe also add an entry to the cookbook section.

[AndersWestman]

Maybe, have never made a PR.
I have to figure out how that should be done correctly.
I assume contributing-to-esphome-docs could be a good place to start?