GPIO resistor setting has no effect

[chabadoo]

Describe the bug

Can neither set pullup nor pulldown works on raspberry pi (tested pi3b and pi4b).
Pulldown was not implemented as it seems - so that is okay.
My workaround is to use resistor: 'off' and change desired behavior for all used pins in /boot/config.txt

Environment

• MQTTany most recent branch add-rpi4
• Platform: Raspberry Pi 3B
• Platform: Raspberry Pi 4B

Configuration

gpio:
 my-pin:
    pin: '17'
    resistor: 'pullup'
    digital:
     interrupt: 'falling'

Logs

I added some debug outputs

2021-01-10 17:52:52,003 [DEBUG] [gpio    ] [core.gpio.pin.digital   ] Line is 17
2021-01-10 17:52:52,004 [DEBUG] [gpio    ] [core.gpio.pin.digital   ] Mode is PinMode.INPUT
2021-01-10 17:52:52,006 [DEBUG] [gpio    ] [core.gpio.pin.digital   ] Edge is PinEdge.FALLING
2021-01-10 17:52:52,007 [DEBUG] [gpio    ] [core.gpio.pin.digital   ] Bias is PinBias.PULL_UP
2021-01-10 17:52:52,009 [ERROR] [gpio    ] [core.gpio.pin.digital   ] Failed to setup GPIO17 using cdev, an invalid argument was given

[CrazyIvan359]

Is this behaviour the same on both devices or do they give different errors? I am currently working on the RPi4 in the other issue you mentioned and it doesn't seem to be working as expected.

RPi boards do not support pull downs on any pins as the hardware does not support that, hence it is not an option in MQTTany.

There are 2 levels of debug logging already in MQTTany. Starting it with -v will give you debug logging, and -vv will give you trace logging. Please use those instead of adding logging yourself as I don't know where in the code you have added it, so it isn't very helpful. Also please use code fences for logs and configs, they are already in the issue templates.

[chabadoo]

Let me first say, that your piece of software is really helpful. Thanks a lot for that. I think I may contribute to it a little.

Let me answer your question:
The behaviour on both devices is identical.

The Line
[ERROR] [gpio ] [core.gpio.pin.digital ] Failed to setup GPIO17 using cdev, an invalid argument was given
is the error.

I just printed out the arguments that are passed to create the GPIO for debug purposed to make sure they are valid (but they are). Of course I use the -vv option.

Why do you think pulldowns are not supported on RPI devices? You can set almost all I/Os (except those used for I2C) to Pulldown. I did this modification for IO4 IO5 and IO6 in the config.txt file as a workaround.

gpio=4-6=ip
gpio=4-6=pd

Also there may be issues with interrupts and debouncing. I tried to follow your code in mqttany/gpio/pins/digital.py, but did not yet understand it 100%.

Shouldn't it look more like this.
https://raspberrypi.stackexchange.com/a/76738

In my application, I need to switch on and dim lightbulbs with these button. Therefore, I would like to receive a message through MQTT (check for an event on a rising edge if the value is still high after that period - debouncing, then send "ON"). Of course no other events are valid in this period. I also need to detect the falling edge afterwards, because I would like to start the process of dimming the lightbulb in openhab until the button is released (falling edge send to openhab "OFF").

[CrazyIvan359]

Thank you! Contributions are welcome

---

an invalid argument was given

This is what the other person testing on an RPi4 is getting as well, something has possibly changed with the cdev implementation.

---

I just printed out the arguments that are passed to create the GPIO for debug purposed to make sure they are valid (but they are). Of course I use the -vv option.

They are actually printed out when the module is being loaded (see below example from the RPi4 thread). I see now that you are using the flags, I didn't notice the thread names the first time I looked because I almost always look at debug logs, sorry.

Configured 'channel1' on GPIO26 with options: {'ID': 'channel1', 'pin mode': 'OUTPUT', 'interrupt': 'NONE', 'resistor': 'NONE', 'invert': False, 'initial state': 'OFF'}

---

Why do you think pulldowns are not supported on RPI devices? You can set almost all I/Os (except those used for I2C) to Pulldown. I did this modification for IO4 IO5 and IO6 in the config.txt file as a workaround.

Where is this documented? I have never seen anything saying that the BCM chips used on any RPi support pulldowns.

---

Shouldn't it look more like this.

That is exactly what I am doing for this exact reason:

As joan points out, the bouncetime parameter in RPi.GPIO does almost exactly the wrong thing: it means when your switch bounces, you'll get the very first event, but that may not actually be representative of the correct state of the switch.

I can walk you through how interrupts operate in more detail if you want, but in short the interrupt for each pin runs on its own thread and runs the callback on a different thread. This is somewhat memory intensive, but I built MQTTany to be fast first and effecient second.

---

Also there may be issues with interrupts and debouncing. I tried to follow your code in mqttany/gpio/pins/digital.py, but did not yet understand it 100%.

There were some issues with the debounce time introduced in v0.12.0 but I figured that out and it is now fixed. What issues are you seeing? What parts don't you understand?

In my application, I need to switch on and dim lightbulbs with these button. Therefore, I would like to receive a message through MQTT (check for an event on a rising edge if the value is still high after that period - debouncing, then send "ON"). Of course no other events are valid in this period. I also need to detect the falling edge afterwards, because I would like to start the process of dimming the lightbulb in openhab until the button is released (falling edge send to openhab "OFF").

This would be the exact behaviour of the interrupt setting both.

[chabadoo]

Where is this documented? I have never seen anything saying that the BCM chips used on any RPi support pulldowns.

Afaik Arduino does not have internal pull-down, RPI always had. However they changed how you set it in RPI4, because it is possible to read the status of the pull-up pull-down registers.

[https://www.raspberrypi.org/forums/viewtopic.php?t=264691]

On RPI4 the result of the command of "raspi-gpio get 17" is:
GPIO 17: level=0 fsel=0 func=INPUT pull=DOWN

I can walk you through how interrupts operate in more detail if you want, but in short the interrupt for each pin runs on its own thread and runs the callback on a different thread. This is somewhat memory intensive, but I built MQTTany to be fast first and effecient second.

Thank, I may come back to that offer later. I understand most of it, but for some reason I get plenty of [TRACE] messages when I toggle my button. I figured deadtime means only, that the command is not send via MQTT. Unfortunately I end up with the button in the wrong state, because often the falling edge is not recognized. Why do you use a sleep 5ms command? It seemes the behavior was made for switches and not for buttons.

This would be the exact behaviour of the interrupt setting both.

Not exactly. Buttons are a little different and in the end I would like to send signal changes (or later also toggle times) to openhab through MQTT.

My Pins are Pull Down (set via config.txt)
Press Button (apply 3.3V to the PIN) -> Interrupt (rising edge) -> Debouncing (wait for signal to settle, ignore any rising and falling edges) -> Check pin level -> If still high level (valid rising edge), send MQTT command to openhab (button pressed) -> Wait for falling edge, ignore rising edges (button release expected next).

Pin Level is high now -> Interrupt (falling edge) -> Debouncing (wait for signal to settle, ignore rising and falling edges) -> check pin level -> If low level (valid falling edge), send MQTT command (button released) -> Wait for rising edge (button release expected next). Otherwise continue to wait for falling edge interrupt.

From Openhab perspective it looks like this:
When the state of the lightbulb is "off", a button pressed signal will switch it on immediately. If there is no button released (OFF) signal within a certain period, openhab will initiate dimming until the button released command is seen.

When the state of the lightbulb is "on", a button pressed signal will initiate a timer (instead of switching the light off directly). Openhab will wait for a predefined time for the release of the switch signal. Only if a MQTT Released signal is received in this window (e.g. 200ms) the light will switch off (lightbulb "off"). If the released signal is not seen, the lightbulb enters dimming mode until release of the button.

[CrazyIvan359]

RPI always had. However they changed how you set it in RPI4, because it is possible to read the status of the pull-up pull-down registers.

Well in theory CDev should support that, possibly sysfs as well. You could test this by adding that capability in mqttany/gpio/boards/rpi.py, look in odroid.py for how to do that.

---

I understand most of it, but for some reason I get plenty of [TRACE] messages when I toggle my button. I figured deadtime means only, that the command is not send via MQTT. Unfortunately I end up with the button in the wrong state, because often the falling edge is not recognized.

I added some more logging recently, I'll take look when I get home later and see if I can't understand what is happening.

Why do you use a sleep 5ms command? It seemes the behavior was made for switches and not for buttons.

It is actually 0.5ms, debounce times should be in the milliseconds domain so this is a good delay to still catch all events. No specific use was in mind when I did this, you can change the debounce time in settings (default 50ms).

---

Not exactly. Buttons are a little different and in the end I would like to send signal changes (or later also toggle times) to openhab through MQTT.

Yes exactly. MQTTany doesn't know or care what is connected, it just looks at pin states. If the pin transitions HIGH and stays that way for the debounce time it sends an ON message. After that, if the pin transitions LOW and stays that way for the debounce time it sends an OFF message. If it is not doing that then it isn't working as designed, but more likely in your case you need to lower the debounce time to get the desired behaviour.

[chabadoo]

Well in theory CDev should support that, possibly sysfs as well. You could test this by adding that capability in mqttany/gpio/boards/rpi.py, look in odroid.py for how to do that.

I will give it a try, but right now even pullup is not accepted from CDev.

MQTTany doesn't know or care what is connected, it just looks at pin states. If the pin transitions HIGH and stays that way for the debounce time it sends an ON message. After that, if the pin transitions LOW and stays that way for the debounce time it sends an OFF message. If it is not doing that then it isn't working as designed, but more likely in your case you need to lower the debounce time to get the desired behaviour.

Of course a lower debounce time can minimize the effect, but that kind of behavior still has an issue. If bouncing (rising edge interrupt) prevents the transition (falling edge) to be recognized and the stable state afterwards is low level no message is send. The level is 0 but openhab still sees ON.

I see many more rising edges than falling edges. Just on/off and it remains ON:

Trace Log

2021-01-11 21:01:34,170 [TRACE] [mqtt    ] [mqtt.client             ] Received PINGRESP
2021-01-11 21:01:47,311 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.310076s
2021-01-11 21:01:47,314 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.313315s
2021-01-11 21:01:47,318 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.316646s
2021-01-11 21:01:47,321 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.320165s
2021-01-11 21:01:47,324 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.323647s
2021-01-11 21:01:47,328 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Falling edge detected on pin GPIO17 with timestamp 1610395307.327068s
2021-01-11 21:01:47,331 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Falling edge detected on pin GPIO17 with timestamp 1610395307.330322s
2021-01-11 21:01:47,334 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Falling edge detected on pin GPIO17 with timestamp 1610395307.333815s
2021-01-11 21:01:47,338 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.337121s
2021-01-11 21:01:47,341 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.340520s
2021-01-11 21:01:47,361 [TRACE] [gpio    ] [gpio.digital            ] Rising edge trigger fired with state ON logic HIGH for 'IO17' on GPIO17
2021-01-11 21:01:47,364 [TRACE] [core    ] [bus.transmit            ] Message received on publish queue: PublishMessage('gpio/pi3-pin-6', 'ON')
2021-01-11 21:01:47,374 [TRACE] [mqtt    ] [mqtt                    ] Message received to transmit: PublishMessage('gpio/pi3-pin-6', 'ON')
2021-01-11 21:01:47,376 [TRACE] [mqtt    ] [mqtt.client             ] Sending PUBLISH (d0, q0, r0, m85), 'b'pi3/gpio/pi3-pin-6'', ... (2 bytes)
2021-01-11 21:01:47,540 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.539983s
2021-01-11 21:01:47,546 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.544835s
2021-01-11 21:01:47,549 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.548098s
2021-01-11 21:01:47,552 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.551311s
2021-01-11 21:01:47,556 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.554674s
2021-01-11 21:01:47,559 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.558182s
2021-01-11 21:01:47,562 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.561465s
2021-01-11 21:01:47,566 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Falling edge detected on pin GPIO17 with timestamp 1610395307.564870s
2021-01-11 21:01:47,569 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.568274s
2021-01-11 21:01:47,572 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.571404s
2021-01-11 21:01:47,576 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.574673s
2021-01-11 21:01:47,579 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.578678s
2021-01-11 21:01:47,583 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.581901s
2021-01-11 21:01:47,586 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.585559s
2021-01-11 21:01:47,589 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.588218s
2021-01-11 21:01:47,591 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.590760s
2021-01-11 21:01:47,594 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.593351s
2021-01-11 21:01:47,597 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.596096s
2021-01-11 21:01:47,599 [TRACE] [gpio    ] [core.gpio.pin.digital   ] Rising edge detected on pin GPIO17 with timestamp 1610395307.598667s
2021-01-11 21:01:49,381 [TRACE] [mqtt    ] [mqtt.client             ] Sending PINGREQ
2021-01-11 21:01:49,384 [TRACE] [mqtt    ] [mqtt.client             ] Received PINGRESP
2021-01-11 21:02:04,404 [TRACE] [mqtt    ] [mqtt.client             ] Sending PINGREQ

For buttons and switches there is no need to be fast. 50ms will be certainly good enough. There should be a mechanism to (e.g. enable/disable rising and falling edge detection dynamically). After a rising edge event a falling edge event must follow and nothing else.

[CrazyIvan359]

I will give it a try, but right now even pullup is not accepted from CDev.

Yeah I've had issues with that before. I can't seem to nail down any documentation for CDev, I'm starting to think it may change based on hardware/kernel version.

There should be a mechanism to (e.g. enable/disable rising and falling edge detection dynamically). After a rising edge event a falling edge event must follow and nothing else.

Such a mechanism sounds complicated and unnecessary if it is working as designed. The behaviour you describe should be how it works, once the pin is confirmed in a HIGH state, only a LOW edge that stays that way for the length of the denounce time will cause the pin to change state.

I will look over your logs and my code tonight and get back to you.

[CrazyIvan359]

Are you saying that this is pressing the button:

Rising edge detected on pin GPIO17 with timestamp 1610395307.310076s

and this is releasing it?

Falling edge detected on pin GPIO17 with timestamp 1610395307.327068s

These events are 17ms apart. With a debounce time of 50ms these events are noise that it is filtering out.

After that I see this falling edge followed 3.4ms later by another rising one, again this looks to the code like the noise it is meant to filter out:

Falling edge detected on pin GPIO17 with timestamp 1610395307.564870s
Rising edge detected on pin GPIO17 with timestamp 1610395307.568274s

Am I missing something? This looks to me like it is working as expected, but your button click events are coming much faster than you think.

[CrazyIvan359]

Went digging and found the C library libgpiod and compared flag values to the periphery library I'm using a found discrepencies.

You seem to know your way around Python, so lets try something. Find periphery/gpio.py and go to the CdevGPIO class at line 420 and change these enums to the values below:

    _GPIOHANDLE_REQUEST_ACTIVE_LOW = 0x4
    _GPIOHANDLE_REQUEST_OPEN_DRAIN = 0x1
    _GPIOHANDLE_REQUEST_OPEN_SOURCE = 0x2
    _GPIOHANDLE_REQUEST_BIAS_PULL_UP = 0x20
    _GPIOHANDLE_REQUEST_BIAS_PULL_DOWN = 0x10
    _GPIOHANDLE_REQUEST_BIAS_DISABLE = 0x8

Does that fix the pull up/down errors you're seeing?

[CrazyIvan359]

Never mind that last suggestion, it doesn't work...

I've been digging deeper and deeper and I think I might have found something. Periphery seems to be using static request codes for ioctl calls, I'm wondering if those codes are no longer correct. If that doesn't work I might just write my own, I've spent enough time looking at libgpiod and python bindings or reimplementations it wouldn't take much since I only need pieces of it.

Anyway, out of time for today. I will test this theory tomorrow.

[CrazyIvan359]

Ok I went all the way into the Linux kernel code for the cdev interface and came up empty.
I'm starting to think this is being caused by something in Raspbian itself... and I didn't even finish typing this post before I found it!

So not Raspbian actually, just the fact that it is running a Linux kernel prior to 5.5, when the bias settings were introduced. I will find a way around this, if cdev doesn't support functions that MQTTany is trying to use it needs to handle it gracefully.

[CrazyIvan359]

I will get the bias resistor problem fixed later today I hope. While digging around in the kernel I found another way I can set the bias resistor, which also means I can control the resistors when using sysfs on older kernels.

Solving this problem also crosses the only item off the list that stopped me from merging the RPi4 support as well.

If you have any resources handy that indicate which RPi boards support pull down resistors I would greatly appreciate links. I also be adding those to the board configs, but I need to know which boards support it because all of the RPi board classes inherit from the 26 and 40pin base classes. If only some of them can do pull downs I will need to separate that.

And finally, I will be closing this issue with the PR that implements the bias resistors correctly. If you are still having issues with your interrupt events, please open a new issue and we can continue there.

[chabadoo]

Sorry for the late reply - I had some work projects to finish.

I will try what you proposed and the new version. Thank you.

My issue in my log was that the state send via MQTT was still ON, but the button had been released. I think it is caused by an edge event that causes the real event to be filtered out (SW Debounce) and afterwards nothing is noticed. Of course the level of the pin is as expected, but the MQTT message was never send.
In case the issue is still there I will implement what I proposed and share it with you. Other option will be HW debouncing.

[CrazyIvan359]

Something else is happening, the software won't filter out the event if the pin stays in that state, which it doesn't do in your logs.

The fix for the resistor error and RPi4 support are merged into master now. You will have to continue to set the resistors using the dt_overlay though, there is not other way until Raspbian updates to kernel 5.5.

[chabadoo]

I gave it a try and updated to master. A warning is displayed now when the resistor in the config file is set to pullup or pulldown. So that is fine.

However, even when setting it to none - Interrupts do not work anymore. Something is wrong with rising and falling edge events. Will look closer into it this evening.

2021-01-21 15:10:37,480 [INFO ] [gpio ] [gpio.digital ] Setting up 'IO17' on GPIO17 as INPUT
2021-01-21 15:10:37,483 [DEBUG] [gpio ] [core.gpio.pin.digital ] Setting up pin GPIO17 using chardev
Exception in thread Thread-7:
Traceback (most recent call last):
File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
self.run()
File "/usr/lib/python3.7/threading.py", line 865, in run
self._target(*self._args, **self._kwargs)
File "/opt/mqttany/mqttany/gpio/pins/digital.py", line 275, in _poll
self._state, self._start_s = self.get_event()
File "/opt/mqttany/mqttany/gpio/pins/digital.py", line 321, in get_event
event = self._pin._interface.read_event() # type: ignore
File "/home/openhabian/.local/lib/python3.7/site-packages/periphery/gpio.py", line 712, in read_event
raise GPIOError(None, "Invalid operation: GPIO edge not set")
periphery.gpio.GPIOError: [Errno None] Invalid operation: GPIO edge not set

[CrazyIvan359]

Sure does... I did a stupid lol. I'll fix that tonight.

In the CDev setup function I put a conditional on the edge setting instead of the bias setting.

[CrazyIvan359]

Fixed in v0.14.1

[chabadoo]

Gave it a try - still issues.

**There seemes to be an issue with this line in digital.py
bias="none" if not common.cdev_bias else periphery_PinBias[self.bias],

shouldn't it be
bias="default" if not common.cdev_bias else periphery_PinBias[self.bias],**

2021-01-23 17:11:53,982 [INFO ] [core ] [core ] Module 'mqtt' started successfully
2021-01-23 17:11:53,987 [TRACE] [core ] [core ] Creating process for 'gpio'
2021-01-23 17:11:53,989 [TRACE] [core ] [core ] Process created successfully for module 'gpio'
2021-01-23 17:11:53,991 [TRACE] [core ] [core ] Starting process for 'gpio'
2021-01-23 17:11:54,001 [DEBUG] [mqtt ] [mqtt ] Creating MQTT client
2021-01-23 17:11:54,001 [INFO ] [core ] [core ] Module 'gpio' started successfully
2021-01-23 17:11:54,008 [DEBUG] [mqtt ] [mqtt ] Attaching callbacks
2021-01-23 17:11:54,011 [DEBUG] [mqtt ] [mqtt ] Queuing connect event
2021-01-23 17:11:54,011 [DEBUG] [core ] [bus ] Starting Message Bus Receive thread
2021-01-23 17:11:54,012 [DEBUG] [mqtt ] [mqtt ] Starting MQTT client thread
2021-01-23 17:11:54,015 [TRACE] [core ] [bus.receive ] Message Bus Receive thread started successfully
2021-01-23 17:11:54,016 [DEBUG] [core ] [bus ] Starting Message Bus Transmit thread
2021-01-23 17:11:54,018 [DEBUG] [gpio ] [gpio ] Setting up hardware
2021-01-23 17:11:54,021 [INFO ] [gpio ] [gpio.digital ] Setting up 'IO04' on GPIO04 as INPUT
2021-01-23 17:11:54,020 [TRACE] [core ] [bus.transmit ] Message Bus Transmit thread started successfully
2021-01-23 17:11:54,023 [DEBUG] [gpio ] [core.gpio.pin.digital ] Setting up pin GPIO04 using chardev
2021-01-23 17:11:54,025 [ERROR] [gpio ] [gpio ] An exception occurred while running function 'start'
2021-01-23 17:11:54,033 [ERROR] [gpio ] [gpio ]

Traceback (most recent call last):
File "/opt/mqttany/mqttany/modules/init.py", line 83, in call
retval = func(**kwargs)
File "/opt/mqttany/mqttany/modules/gpio/core.py", line 164, in start
if not pins[pin].setup():
File "/opt/mqttany/mqttany/modules/gpio/pin/digital.py", line 178, in setup
if self._handle.setup():
File "/opt/mqttany/mqttany/gpio/pins/digital.py", line 128, in setup
if self._setup_cdev():
File "/opt/mqttany/mqttany/gpio/pins/digital.py", line 165, in _setup_cdev
label="MQTTany",
File "/home/openhabian/.local/lib/python3.7/site-packages/periphery/gpio.py", line 487, in init
self._open(path, line, direction, edge, bias, drive, inverted, label)
File "/home/openhabian/.local/lib/python3.7/site-packages/periphery/gpio.py", line 512, in _open
raise ValueError("Invalid bias, can be: "default", "pull_up", "pull_down", "disable".")
ValueError: Invalid bias, can be: "default", "pull_up", "pull_down", "disable".

[CrazyIvan359]

That's what I get for rushing... you are absolutely correct.

Try this new branch: https://github.com/CrazyIvan359/mqttany/tree/fix-kernel-version

[chabadoo]

Thank you Ivan.

However, I am still a litte unhappy with digital button handling in my project. As explained "On" is just a very temporary state for me (less than 5 seconds button pressed) and still sometimes the last falling edges are not recognized (due to debouncing). My issue is that I cannot determine a proper debounce value. Setting it low will cause many messages, which I can filter out the "noise" at the receiving end, but this still does not guarantee, that the last edge is seen.
Thus I sometimes have issues will have the correct value until after the next polling routine. It would be nice to have a timer to send an automatic "Off" after a configurable period (or individual polling of just the pin, that caused the interrupt).

Any other ideas? Thank you.

[CrazyIvan359]

As I said, let's move out of this issue as it's a different problem. Give me details of your hardware setup and I will recreate it on my end so that I can test better.