GPIO resistor setting has no effect

chabadoo commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

```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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Fixed in v0.14.1

chabadoo commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

CrazyIvan359 / mqttany