# Rpi gpio library not work with dietpi trixie

**URL:** <https://discourse.nodered.org/t/rpi-gpio-library-not-work-with-dietpi-trixie/100595>\
**Category:** General\
**Created:** [18 March 2026 20:00 UTC](https://discourse.nodered.org/t/rpi-gpio-library-not-work-with-dietpi-trixie/100595 "2026-03-18T20:00:20Z")\
**Posts on this page:** 1\
**Showing post:** 57

<div class="post-metadata">

**Author:** ![MichaIng](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/michaing/32/24824_2.png) [@MichaIng](https://discourse.nodered.org/u/MichaIng)\
**Post date:** [23 March 2026 17:51 UTC](https://discourse.nodered.org/t/rpi-gpio-library-not-work-with-dietpi-trixie/100595/57 "2026-03-23T17:51:00Z")

</div>

> [@cymplecy](#):
>
> Most of us now use microcontrollers to interact with hardware and then usually use MQTT to communicate to and from a Pi

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 😄.

---

_[View the full topic](https://discourse.nodered.org/t/rpi-gpio-library-not-work-with-dietpi-trixie/100595)._