Thanks for your effort!
If I've followed the rabbit hole correctly then the python code that handles the pin does debounce by waiting the bounce time and then reporting the pin state (the method you suggested)
Just trying to find out why a value of 0 isn't allowed
My current thinking is this
node-red uses a python prog nrgpio.py to handle the Pi pins
That uses standard RPi.GPIO library
RPi.GPIO library handles debouncing internally but doesn't accept a value of 0 for bouncetime - reports an error and that error causes the node to stop
Going to see if I can make a small mod to nrgpio.py to test for 0 bouncetime
I made a mod and it worked (as in 0 bounce time doesn't stop the node from working)
I don't have a source of 1ms pulses handy (prob going to need another Pi to generate them) but maybe your able to modify the same file on your Pi and see what happens?
I'm off to bed now
Also off to bed now. Will try in the morning and report back.
@cymplecy Happy to look at a Pull request for this mod if you want to provide one.
I rigged up a WEMOS D1 mini to produce 1ms pulses every 3 seconds and connected it to my Pi - my modified node seems to catch them reliably with bounce time set to 0
I made the changes to the code as you did above. I can confirm that a debounce time of 0 no longer causes the flow to stop.
However, it still does not catch my pulses.
I will put my pulses on a scope tomorrow and come back with more exact information of my setup.
In the meantime, a quick question. Does the GPIO node make use of the interrupt functionality of the pin? Or is it simply polling the pin on a regular basis? I can get it to work with the node-red-contrib-opi-gpio library. It uses the interrupt to trigger the change. The difference might be with how the two gpio nodes are triggered...
I don't know whether it uses interrupts or polling I'm afraid - I'll see if I can find out
What settings are you using (board type / pin number) to get this opi node to work on a Pi?
Where are you getting your pulses from BTW?
Well the code was as per above
It uses interrupts on both edges - which then call the callback code which does
ie waits for the debounce time then re-reads the pin.
What I mean is - I don't know whether the RPi.GPIO library is reacting to hardware interrupts or just doing fast polling and generating the callbacks that way - does the Pi have hardware interrupts on its GPIO pins?
Reading the RPi.GPIO docs - I think it strongly implies that it is using interrupts
Sorry for the long silence.
I have since hooked up my scope and checked the pulse width. It is a low going pulse of around 0.2ms in duration. See below (0.1ms per div):
It is generated by a diesel flow meter.
I'm using board type as "other".
I then use a stray rpi-gpio node just to enable the pullup on the pin.
I believe this is the first time you have mentioned that you are using node-red-contrib-opi-gpio node. Everyone here has (I imagine) been assuming that you are using the standard node-red gpio node. Try the standard one and see if it works ok.
In addition I dread to think what the effect of also using a standard gpio node watching the same pin is. Why are you not just using that for reading the pin, now that you can specify 0 debounce on that node?
No - they told us earlier that they got it work using it
Ah, I missed that. I take it all back.
Aah - that could possibly explain why the standard node isn't catching it - it will get triggered by the high/low transition but the pin value could have returned to it high before it state is read and sent out
I'll have a play using 0.1ms pulses and see if I can come up with method of reporting them
maybe try with with node's debounce time set to 0 ?
I have already tried with the node's debounce time set to 0. It doesn't catch my short pulses.
OK - You could try the gpiod nodes instead https://www.npmjs.com/package/node-red-node-pi-gpiod - they use a native C service - which may cope better. (But I've not tested it in your situation)
Thanks for pointing out this node! It helped me eliminate a pythonshell node and corresponding script it called in a garage door controller I'm working on.