Support for GPIO monitoring callbacks

[varadero]

I know that GPIO monitoring callbacks is in the roadmap but it would be really great addition. I have tried node-libgpiod with Raspberry Pi 5 4GB (I just needed to change new Chip(0) to new Chip(4)) and it works great for setting the outputs but don't know how to do the "monitoring" (like detecting push buttons connected to some GPIO). I am willing to sponsor the addition of the callbacks to the library.

[sombriks]

Hi @varadero i am doing some cleanup and after that will work on that for 1.x branch first. At some point we can discuss proper api design/ergonomics here, ;-)

[Garfonso]

I would be truly interested in that as well. Did you make any progress?

[sombriks]

Hello @Garfonso indeed this feature is one will be a big improvement, i just need testcases / gpiosim up and running so i can handle the missing bits of 1.x API. staty tuned!

[2bndy5]

Given that javascript was designed as an event-driven language, I would rank this with high priority. It seems you have much on your plate with this project, so patience is definitely worth the reward here.

[hmeerlo]

I don't understand how anybody is using GPIO with nodejs nowadays. Since Bookworm gpiod is the norm to use GPIO, but there is no way to use it properly in nodejs. This library can set and get values, but a very important part of GPIO is event monitoring. I have a reset button attached to a GPIO pin of which I need an event on the rising and falling edge. This was no problem with the old /sys/class/gpio/* interfaces, but with the new way of working it seems almost impossible to achieve. Or am I missing something?

[2bndy5]

This was no problem with the old /sys/class/gpio/* interfaces

Actually, there were problems with the sys FS interface. Most notably, nothing in sys FS interface prevented other threads from appropriating occupied resources (a GPIO chips' exposed pins).

Many of the C/C++ offerings (PiGPIO, MRAA, wiringPi) wrapped the sys FS interface into something that can only be described as "a best effort to shield end-users from the pitfalls of the sys FS interface." But, the limited design of the sys FS interface often required wrappers to have root access... This didn't bode well for environments (a python venv for example) that were designed to avoid messing with system-scoped resources.

The newer (ioctl-based) char dev interface does not require root privileges. FYI, the GPIO API is the latest of Linux kernel's peripheral APIs to switch to a char dev API. The Linux kernel's I2C and SPI interfaces have been using a (ioctl-based) char dev paradigm for years. You might find Linux kernel examples for I2C still using the older sys FS interface (like the undead wiringPi library does).

but with the new way of working it seems almost impossible to achieve. Or am I missing something?

I landed on this repo because npmjs.com showed search results that haven't been updated in years. It would seem that embedded Linux isn't a popular use case for node.js (despite the node-red project which used to ship with RPi OS).

The char dev API depends on using the Linux kernel's ioctl() (which can be differently implemented per OS/platform) and poll() (for event monitoring). The hard part is safely exposing C in node.js.

Alternative Idea

The authors of libgpiod (which is a convenience wrapper for the Linux kernel's char dev API) also ship a rust binding. I thought about wrapping that binding in a napi-rs project, but (like this node-gpiod project) it is not a simple undertaking. The only benefit is that a napi-rs project can ship compiled binaries/modules (*.node) as optional dependencies (per arch type) of a root package (which includes generated TS type definitions).

[jbuonagurio]

@2bndy5 I was about to start working on this myself, and I just found a new project which has a working Node binding for libgpiod events (I have to thank the author): ExpeditionExploration/opengpio

It's not as complicated as I thought, at least compared to the low-level thread synchronization in fivdi/pigpio for example. They just use the libuv uv_work_t thread pool and call gpiod_line_request_wait_edge_events in a worker thread (you could do something similar with napi_async_work in Node-API):

https://github.com/ExpeditionExploration/opengpio/blob/0fd6f3d/cpp/opengpio.cpp#L197-L232

Example:

import { Default, Edge } from 'opengpio';

const button = { chip: 4, line: 27 }; // GPIO27

const watch = Default.watch(button, Edge.Both);

watch.on('change', (value) => {
    console.log('change');
});
watch.on('rise', (value) => {
    console.log('rise');
});
watch.on('fall', (value) => {
    console.log('fall');
});

setInterval(() => {}, 1000);

It's a bit different from this project in that it's not a 1:1 wrapper of the libgpiod API, and it requires libgpiod v2.x. There is a backport available however:

https://packages.debian.org/bookworm-backports/libgpiod-dev

[2bndy5]

I was about to start working on this myself, and I just found a new project which has a working Node binding for libgpiod events (I have to thank the author): ExpeditionExploration/opengpio

Yes, I've been using opengpio for a while now (because of this issue) 👍🏼 . I would talk more about opengpio and my excellent correspondences with the author(s), but we have gone off-topic here.