TCRT5000 too fast?

[Officer-on-duty]

I changed several GPIO binary sensors from "rpi_gpio" to "ha_gpiod". All sensors work fine. Thank you.

But there is one issue with a fast-working TRCT5000. I realise the flash on LED on the TRCT board but the sensor will not catch the impulse. If I release the TRCT-LED manually by turning the trimmer the gpio indicates the sensor. I already reduced "debounce: 1".

The sensor worked also with "rpi_gpio".

best regards

[jdeneef]

Let me try. You have an infrared receiver, connected to the RPI gpio's? The infrared receivers led is receiving signals which should trigger the gpio, where ha_gpiod should pass the signal to hass? Don't think this is in debounce. One thing that could cause this is that the signal is too weak to trigger. You could test with bias to PULL_DOWN instead of the default PULL_UP for the sensor? Guessing though, please test?

[Officer-on-duty]

Thank you for taking care! I tested it but unfortunately no success :-(. Here some pictures for a better explanation:

If the LED flashes short the sensor will not react.

If I release the LED manually (at 5:05) it takes 5/100 sec. to release the sensor:

Sensor released (at 5:10)

By the way... 5/100 sec. = 50/1000 sec.. Mybe it's relatet to the bouncetime after all?

[jdeneef]

debounce is to mitigate the effects of signal noise and mechanical bounce, which in your case should not be an issue. debounce indeed should be lower than your led timing. Never tested with low debounces though, since I only have a push button. Will test a bit more and validate setting debounce in the code, not sure what else to do ..

[Officer-on-duty]

Maybe this is a hint: In the old integration "rpi_gpio" - 'bouncetime: 1' fix this problem. In your integration 'debounce: 1' seems to has no effect.

[jdeneef]

Agree, thanx for confirmation, I will doublecheck debounce functionality, probably somewhere next weekend ;-)

[jdeneef]

ok, tested, debounce is working as expected, setting to 500 removes any 'noise' when switching manually, setting to 1 triggers for all clicks and releasing. Then again, manually testing is not fast enough for your case. Could you test with increasing time to see when it is picked up? My guess is that the listener loop is the culprit, after every click it is restarted where rpi_gpio had a listener in the library itself. This is a TODO because I don't like the listener loop I added but could not find a way around it .. At least gives me some reason to see if I can find a way around.

If you can test from 1ms upto eg 50ms, that might at least help others to currently specify the lowest debounce that is working. In the meantime I will try and find a solution for a listener which relies on libgpiod only, skipping the listener loop.

logs (see enable logs in the README):

homeassistant  | 2024-07-13 14:38:32.493 DEBUG (MainThread) [custom_components.gpiod.hub] Listener loop
homeassistant  | 2024-07-13 14:38:32.891 DEBUG (MainThread) [custom_components.gpiod.hub] Event: <EdgeEvent type=Type.RISING_EDGE timestamp_ns=2854412053397 line_offset=7 global_seqno=131 line_seqno=131>
homeassistant  | 2024-07-13 14:38:32.893 DEBUG (MainThread) [custom_components.gpiod.hub] Listener loop
homeassistant  | 2024-07-13 14:38:32.923 DEBUG (MainThread) [custom_components.gpiod.hub] Event: <EdgeEvent type=Type.FALLING_EDGE timestamp_ns=2854444078640 line_offset=7 global_seqno=132 line_seqno=132>
homeassistant  | 2024-07-13 14:38:32.925 DEBUG (MainThread) [custom_components.gpiod.hub] Listener loop
homeassistant  | 2024-07-13 14:38:33.259 DEBUG (MainThread) [custom_components.gpiod.hub] Event: <EdgeEvent type=Type.RISING_EDGE timestamp_ns=2854780053355 line_offset=7 global_seqno=133 line_seqno=133>
homeassistant  | 2024-07-13 14:38:33.261 DEBUG (MainThread) [custom_components.gpiod.hub] Listener loop
homeassistant  | 2024-07-13 14:38:33.299 DEBUG (MainThread) [custom_components.gpiod.hub] Event: <EdgeEvent type=Type.FALLING_EDGE timestamp_ns=2854820084714 line_offset=7 global_seqno=134 line_seqno=134>
homeassistant  | 2024-07-13 14:38:33.301 DEBUG (MainThread) [custom_components.gpiod.hub] Listener loop
homeassistant  | 2024-07-13 14:38:35.015 DEBUG (MainThread) [custom_components.gpiod.hub] Event: <EdgeEvent type=Type.RISING_EDGE timestamp_ns=2856536047424 line_offset=7 global_seqno=135 line_seqno=135>
homeassistant  | 2024-07-13 14:38:35.017 DEBUG (MainThread) [custom_components.gpiod.hub] Listener loop
homeassistant  | 2024-07-13 14:38:35.067 DEBUG (MainThread) [custom_components.gpiod.hub] Event: <EdgeEvent type=Type.FALLING_EDGE timestamp_ns=2856588081237 line_offset=7 global_seqno=136 line_seqno=136>
homeassistant  | 2024-07-13 14:38:35.069 DEBUG (MainThread) [custom_components.gpiod.hub] Listener loop
homeassistant  | 2024-07-13 14:38:35.419 DEBUG (MainThread) [custom_components.gpiod.hub] Event: <EdgeEvent type=Type.RISING_EDGE timestamp_ns=2856940052506 line_offset=7 global_seqno=137 line_seqno=137>
homeassistant  | 2024-07-13 14:38:35.421 DEBUG (MainThread) [custom_components.gpiod.hub] Listener loop
homeassistant  | 2024-07-13 14:38:35.447 DEBUG (MainThread) [custom_components.gpiod.hub] Event: <EdgeEvent type=Type.FALLING_EDGE timestamp_ns=2856968062817 line_offset=7 global_seqno=138 line_seqno=138>

[Officer-on-duty]

Thank you for your deep investigation. Unfortunately, I'm not able to adjust the time of the IR-Flasch witch is collected by the TCRT500 because it is released from an energy counter (10.000 times p. KW). So for me I still stay in HA Operating System 12.2 with "rpi_gpio" for this issue.

[jdeneef]

ok, need to come up with an other way to verify, cause it can hardly being this looping, this should by usecs not msecs .. I have 1 other idea, to test your setup with gpiod, need to look into that.

[jdeneef]

Could you test using gpiomon to see if you get valid returns? gpiomon is part of libgpiod and is available in the homeassistant docker.

gpiomon -c "/dev/gpiochip0" --debounce-period 10 7

Try and set the debounce-period lower possibly upto 0 to see what happens. Result should be something like this:

/mnt # gpiomon -c "/dev/gpiochip0" --debounce-period 10 7
6385.492050076  rising  gpiochip0 7 "GPIO7"
6385.544062474  falling gpiochip0 7 "GPIO7"
6385.908054003  rising  gpiochip0 7 "GPIO7"
6385.992040806  falling gpiochip0 7 "GPIO7"

Or with python code:

import gpiod
from datetime import timedelta

chip = gpiod.Chip("/dev/gpiochip0")

lines = chip.request_lines(consumer="test", config = {
    7: gpiod.LineSettings(
        edge_detection = gpiod.line.Edge.BOTH,
        debounce_period = timedelta(milliseconds=10))
})

while True:
    try:
        events = lines.read_edge_events()
        for event in events:
            print(f"## Event: {event.event_type} {event.line_offset} {event.timestamp_ns}")
    except:
        print("cancelled")
        break

lines.release()
chip.close()

[jdeneef]

fwiw I also found a solution on removing the loop. I don't expect it to fix your issue, but please test.

[Officer-on-duty]

Deep thank you for taking care. Here is what I figured out: After update to v1.2.2 I had the same issue with not detected impulses. Than I tried “debounce: 0” instead of “debounce: 1” and… it works FINE. Just to make sure I went back to “debounce: 1” and again… not detected impulses. And back to “debounce: 0” fine results. So far my investigation.

[jdeneef]

Perfect. Sort of seems you are really on the edge of what it can catch .. It can be that removing the loop was just enough, it simplified the part of restarting the listener after an event, which could be the exact window where your setup gets a second event .. dunno. Anyways happy this works, hope it stays consistent, closing for now.