Rpi gpio library not work with dietpi trixie

General
44

Rasperry Pi themselves changed how software interacted with the GPIO pins and a LOT of software stopped working.

As I think you've found out, not many people use other OSes, such as DietPi, on Raspberry Pi boards so that is probably why your issue has not been addressed before now

1 Like
45

What requires the change? The boards are the same. I use the same boards, what requires the change? Everything worked perfectly. Can you imagine having an egg incubator built on an RPi that hatches little chicks? And there are dozens or hundreds of them. With one update, everything goes into the bin. Fortunately, this scenario is not true, but it is worth considering.

46

Do you mean why did the pi developers change the way the gpio access works? I think you would have to ask them that.

47

Yes, it is. But I don't know how to do it. As I described, I am a user! And why do you think they changed it?

49

Could be many reasonsā€¦ the pi hardware has changed over the years.. newer processor families. Armv6 -> v7 -> v8. The way they have interfaced from the processor to usb bus and other channels including io has thus had to change as well. Trying to keep that all hidden just by software may have got too hard. Or maybe became inefficient, or maybe the original developer of the original library moved on, orā€¦

So either which way, they changed it and ā€œbrokeā€ it. So we ( at the next level up the chain - but below you the user) have also to change. We can either a) rewrite a node to use the new supported library but this will only then work on new OS and will not work on older installs so may break existing users unless they do a complete upgrade, or b) we can use a compatibility shim they have provided ( the lgpio mentioned ) that makes the new way of interfacing look like the original (so the existing node should work - for both old and new installs). We (I) chose to go for option b. Th downside is that you then have to use the default underlying gpio or remove it and install lgpio, depending on which OS you have. I do try to do this with the default PiOS Node-RED installer script, but I can well imagine the DietPi installer may not.

If I get a chance later this week Iā€™ll try to install Diet Pi on an old Pi2 and see what state I get into and what we can do about it..

50

I'm glad you're joining the discussion. In my opinion, nothing should be touched in Node Red. The problem is elsewhere. We'll solve it together. Thank you.

51

Hopefully it is indeed. But if I can help mitigate it in my script or elsewhere I will try to do so.
( but not quite up for the full node re- write yetā€¦)

52

In all the time I've dealt with people, it's clear that you need to call the boss. :slight_smile:

53

I installed the latest revision of Dietpi Trixie. I then installed Node Red and the original node-red-node-pi-gpio 2.0.7 library and everything worked as it should. No need to modify the Node Red libraries. Best regards.

54

Thank you to everyone who took the time to solve this problem.

55

In a perfect world, there would be no documentation about how GPIO works on Raspberry Pi, but about how it works on Linux, and all drivers for all hardware which exposes GPIO pins would implement the same generic API, hence the same set of libraries would work on all hardware.

But RPi used to implement a lot of RPi-only APIs, based on closed source drivers, where everyone knew that this won't survive forever. But since there was no working alternative for RPis, the ecosystem with libraries and software like Node-RED plugins emerged around those closed source/vendor APIs. This does not only include GPIO, but GPU/video, camera, and more.

During the last years, the inevitable transition happened, and the RPi kernel migrated from a lot of those those RPi-only APIs and drivers to generic native Linux ones, affecting the GPIO libraries, RPi video => KMS/DRM, RPi camera => libcamera, etc. Since the ecosystem which develops all the software and higher-level libraries consists almost only of volunteers, which are not paid for their work by anyone, the required rework was too large for many, hence the projects died, or still exist but are functional only with workarounds or scattered hacks, or ancient distro versions necrod in Docker containers.

This was not a surprise, since all those APIs were deprecated a long time ago, but equal functionality not reached by native alternatives at the same time.

On the bright side: it can only become better. IMO important is that open source developers stop wasting time on these legacy RPi-only APIs, but switch to the existing sustainable alternatives. But this is easier said than practically done. But I am indeed surprised that there is literally no maintained Node-RED plugin which supports any of the modern GPIO libraries, while the legacy ones are still developed. IMO a waste of time, as hard as it is to accept that fact, when the consequence is to either require a major rework or archive the own project.

1 Like
56

The drive to support GPIO access on the main Pi hardware has vastly decreased.

Most of us now use microcontrollers to interact with hardware and then usually use MQTT to communicate to and from a Pi (or another computer)

It was fun playing with pins directly back in the day but the fun went away and we got 10 years older :slight_smile:

2 Likes
57

Isn't this an extra step if you are processing the I/O at the Pi anyway? Of course there are use cases when you want to have one or multiple tiny sensors somewhere remotely, and one central system to process stuff, but otherwise this sounds more like a workaround than a solution.

And which API/library do you use on the microcontroller itself? I imagine there are low-level methods, likely somewhat vendor-specific (prone to same problem the RPis ran into), but otherwise it is probably the very same you'd use on any other Linux system, and can theoretically use on RPi just fine as well?

But makes sense that probably the use cases has shiftet, now that Raspberry Pis have become a lot more powerful (and expensive), being overkill for common GPIO applications. So maybe that went hand in hand with the legacy GPIO API removal.

EDIT: But it explains even less why the plugins that use legacy RPi-only APIs are still actively maintained :smile:.

58

I choose to use a Raspberry Pi 4B to run Node-red.
If I kill it by borking the IO pins that's from Ā£49 upwards.

I run sensors on ESP32s, which cost upwards of Ā£1.50.
They might be remote or even connected to the Pi for power via USB.

The firmware I use is mostly Tasmota, but you are right that there are several options, including the Arduino API, which is C (++?)
Either way, the code is compiled for the ESP hardware as an executable, there is no operating system, which feels safer.
Tasmota is the only code I don't habitually update, so these are maintenance free.
They start up within seconds from a power outage, reconnect to lost wifi and MQTT.

A brilliant, low cost, low risk & high availability solution IMHO.

3 Likes
59

I think bodged to keep on working would be a better description than maintained :slight_smile:

Like I say, it was fun back in the day - I personally know the author of the RPi.GPIO python library - he just lives a few miles away but us old timers aren't really interested in using Pi anymore

I personally was the author of a Python prog that let kids control the pins using Scratch to control Pi robots.

But now that can be done using MicroBlocks directly running on a range of microcontrollers at far less than the cost of even a PiZeroWH.

Tasmota running on microcontrollers is the weapon of choice amongst many of the IoT crowd here.

MQTT is the superglue that links things together nowadays :slight_smile:

3 Likes
60

Thanks for the insights both. Makes sense that much cheaper microcontrollers can do tasks done by an SBC a decade ago, and do so much faster.

What I have in mind for where it still makes sense to use the SBC's GPIOs, is when you need its performance and flexibility anyway, like for serving a web interface to control stuff, visualize stuff with like Grafana or so, and/or Node-RED for a more complex system for home automation and similar. Modern SBCs can run all of this perfectly in parallel, and be a media center and home cloud, your router and ad blocker on top, all on the same host. If it is practically (distance) possible to attach the sensors or switches or whatever to its GPIO directly, using microcontrollers and MQTT in between only adds complexity, costs, most importantly additional knowledge/time to read into things.

For Swiss Army knife applications, it would be great to have software support, based on modern APIs that are expected to remain.

However, in the end, the obscene of certain software also gives a hint about the demand. And with python3-rpi-lgpio it still works (when not running it in a dir where the user has no write access :sweat_smile:), and if anything more generic is needed, anyone can pick up https://github.com/s5z6/node-red-contrib-libgpiod.

1 Like
61

Hello. What happens if the network connection between devices communicating via MQTT is broken, and you have an interface built on Node Red? Therefore, it is necessary that the libraries that communicate with the Rpi pins work. I am currently exposed to such a scenario. I have important pins on the Rpi that must work without fail, and such, as you said, via MQTT. If the network is interrupted, the most important processes remain working (personally tested many times). With MQTT there is a problem with the transmission of data (0,1,2) which in turn can disrupt the process that you have built and should work. Let's not forget why Rpi was created! For training, that is, these pins are not brought out on the board just like that.
This is why we use Rpi for everything because of its flexibility, it is a factor that all available tools for it should be available. Another issue is that the prices of Rpi boards have gone into space and they have to look for other alternatives. Greetings.

62

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.