OpenSprinkler › Forums › OpenSprinkler Unified Firmware › Problems with gpiod v2
- This topic has 9 replies, 4 voices, and was last updated 7 months, 1 week ago by
Ray.
-
AuthorPosts
-
August 10, 2025 at 3:35 am #83335
psmedleyParticipantHey all,
Heads up – I updated one of my Pi’s that runs opensprinkler to trixie, and it comes with gpiod v2 which has a different API.
I get the following trying to rebuild the firmware:
gpio.cpp: In function ‘int assert_gpiod_chip()’: gpio.cpp:242:25: error: ‘gpiod_chip_iter’ was not declared in this scope; did you mean ‘gpiod_chip_open’? 242 | gpiod_chip_iter *iter = gpiod_chip_iter_new(); | ^~~~~~~~~~~~~~~ | gpiod_chip_open gpio.cpp:242:42: error: ‘iter’ was not declared in this scope 242 | gpiod_chip_iter *iter = gpiod_chip_iter_new(); | ^~~~ gpio.cpp:242:49: error: ‘gpiod_chip_iter_new’ was not declared in this scope; did you mean ‘gpiod_chip_open’? 242 | gpiod_chip_iter *iter = gpiod_chip_iter_new(); | ^~~~~~~~~~~~~~~~~~~ | gpiod_chip_open gpio.cpp:244:43: error: ‘gpiod_chip_iter_next’ was not declared in this scope; did you mean ‘gpiod_chip_open’? 244 | while (tmp_chip = gpiod_chip_iter_next(iter)) { | ^~~~~~~~~~~~~~~~~~~~ | gpiod_chip_open gpio.cpp:245:45: error: ‘gpiod_chip_label’ was not declared in this scope; did you mean ‘gpiod_chip_open’? 245 | if (!strcmp(gpiod_chip_label(tmp_chip), chip_name)) { | ^~~~~~~~~~~~~~~~ | gpiod_chip_open gpio.cpp:247:41: error: ‘gpiod_chip_iter_free_noclose’ was not declared in this scope 247 | gpiod_chip_iter_free_noclose(iter); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ gpio.cpp:253:25: error: ‘gpiod_chip_iter_free’ was not declared in this scope; did you mean ‘gpiod_chip_info_free’? 253 | gpiod_chip_iter_free(iter); | ^~~~~~~~~~~~~~~~~~~~ | gpiod_chip_info_free gpio.cpp:255:32: error: ‘gpiod_chip_open_by_name’ was not declared in this scope; did you mean ‘gpiod_chip_info_get_name’? 255 | chip = gpiod_chip_open_by_name("gpiochip0"); | ^~~~~~~~~~~~~~~~~~~~~~~ | gpiod_chip_info_get_name gpio.cpp: In function ‘int assert_gpiod_line(int)’: gpio.cpp:271:35: error: ‘gpiod_chip_get_line’ was not declared in this scope; did you mean ‘gpiod_chip_get_info’? 271 | gpio_lines[pin] = gpiod_chip_get_line(chip, pin); | ^~~~~~~~~~~~~~~~~~~ | gpiod_chip_get_info gpio.cpp: In function ‘void pinMode(int, unsigned char)’: gpio.cpp:290:25: error: ‘gpiod_line_request_input’ was not declared in this scope; did you mean ‘gpiod_line_request_get_fd’? 290 | gpiod_line_request_input(gpio_lines[pin], gpio_consumer); | ^~~~~~~~~~~~~~~~~~~~~~~~ | gpiod_line_request_get_fd gpio.cpp:293:88: error: ‘GPIOD_LINE_REQUEST_FLAG_BIAS_PULL_UP’ was not declared in this scope 293 | od_line_request_input_flags(gpio_lines[pin], gpio_consumer, GPIOD_LINE_REQUEST_FLAG_BIAS_PULL_UP); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gpio.cpp:293:25: error: ‘gpiod_line_request_input_flags’ was not declared in this scope; did you mean ‘gpiod_line_request_set_values’? 293 | gpiod_line_request_input_flags(gpio_lines[pin], gpio_consumer, GPIOD_LINE_REQUEST_FLAG_BIAS_PULL_UP); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | gpiod_line_request_set_values gpio.cpp:296:25: error: ‘gpiod_line_request_output’ was not declared in this scope; did you mean ‘gpiod_line_request_get_fd’? 296 | gpiod_line_request_output(gpio_lines[pin], gpio_consumer, LOW); | ^~~~~~~~~~~~~~~~~~~~~~~~~ | gpiod_line_request_get_fd gpio.cpp: In function ‘unsigned char digitalRead(int)’: gpio.cpp:313:19: error: ‘gpiod_line_get_value’ was not declared in this scope; did you mean ‘gpiod_line_value’? 313 | int val = gpiod_line_get_value(gpio_lines[pin]); | ^~~~~~~~~~~~~~~~~~~~ | gpiod_line_value gpio.cpp: In function ‘void digitalWrite(int, unsigned char)’: gpio.cpp:331:15: error: ‘gpiod_line_set_value’ was not declared in this scope; did you mean ‘gpiod_line_value’? 331 | res = gpiod_line_set_value(gpio_lines[pin], value); | ^~~~~~~~~~~~~~~~~~~~ | gpiod_line_valueNot urgent for me as it’s still winter in Adelaide 😉
August 10, 2025 at 8:28 pm #83344
RayKeymasterWell, it’s that game again: every couple of years, there’s another breaking change to how GPIOs work, and we have to update firmware code just to keep up.
I don’t understand why, for something as basic as GPIO control, the Raspberry Pi Foundation can’t provide a stable API that lasts for many years. On Arduino, the same
pinMode,digitalWrite, anddigitalReadfunctions have worked for decades—you never have to worry about core GPIO functions breaking after a system upgrade, let alone breaking repeatedly every couple of years.The original
WiringPilibrary existed to solve exactly this problem, making GPIO access straightforward, but it’s now unmaintained and only kept alive as a community fork. I understand that Raspberry Pi OS now sits on top of Debian and inherits upstream changes, but the reality is that anyone using it for embedded projects needs GPIO access. At the current pace, the changes feel messy and disruptive.We’ve essentially had to write our own “wrapper” library in our firmware just to shield our code from these changes—something that really should have been provided and maintained by the platform itself.
Anyway, apologies for the rant, but I doubt I’m the only one feeling this frustration. My advice is to stick with Bookworm unless there’s a feature in Trixie you absolutely need.
August 11, 2025 at 3:48 am #83346
psmedleyParticipantHi Ray – I remembered as soon as I saw the issue the problems with bookworm, and no need to apologise for the rant 🙂
I had no real reason to upgrade this Pi to trixie, it was one of those ‘I could, so I will’ things 🙂 I knew there was risk, but was happy to be the one to identify any issues.
I’ll likely just swap out the SD card next time I’m at the holiday house and stick with bookworm 🙂 Or one lazy day I may try and rewrite the code.
August 13, 2025 at 4:49 am #83369
psmedleyParticipantI still need to test the code, but I used Gemini to help re-write things – source at https://github.com/psmedley/OpenSprinkler-Firmware/tree/libgpiod-2.x
I also need to find a way to determine if the installed libgpiod is v1 or v2 – right now, the v1 code is wrapped in a ‘#if 0’
Interestingly, when I load the GUI, I get a ‘Stations Currently Paused’ message that I don’t seem to be able to clear 🙁
August 15, 2025 at 4:00 am #83384
psmedleyParticipantSo I haven’t been able to get the writes to success with libgpiod 2.2; however, I did manage to compile libgpiod v1.6.5 on trixie; and build ospi against the older library.
I’m still seeing the ‘Stations Currently Paused’ message that I don’t seem to be able to clear. Any clues on what causes this? searching the code didn’t give too many clues.
November 14, 2025 at 8:15 am #84182
MichaelParticipantHmm, I was just thinking of updating the Opensprinkler Pi (along with the others) to Trixie, but I guess I’ll hold off on that.
Good call!November 14, 2025 at 9:51 am #84183
RayKeymasterFirmware 2.2.1(4), which will be released this weekend:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/pull/381
addresses this issue by switching from gpiod to lgpio, which works on trixie and doesn’t make breaking changes across raspbian versions.November 14, 2025 at 11:33 am #84184
MichaelParticipantSounds perfect!
November 17, 2025 at 10:15 am #84203
GregTParticipantWith the release of 2.2.1(4), the note “firmware currently does NOT work with Trixie due to the breaking changes it made regarding GPIO operations” on https://openthings.freshdesk.com/support/solutions/articles/5000631599-installing-and-updating-the-unified-firmware-on-ospi is no longer valid, correct? Thank you!
November 17, 2025 at 12:55 pm #84205
RayKeymasterCorrect. I’ve updated those statements.
-
AuthorPosts
- You must be logged in to reply to this topic.
OpenSprinkler › Forums › OpenSprinkler Unified Firmware › Problems with gpiod v2