How to deal with the Raspberry Pi Zero?

[JaapvanEkris]

Hi all,

I ran into a bit of a dead end here, and I want some advice on how we should proceed.

From its inception, OpenRowingMonitor ran on basically all Raspberry Pi's under the sun. Under the hood, the Raspberry Pi Zero (and thus the original Raspberry Pi) were supported by selecting a backported version of version 14 of Node.js (our development platform). This was a quick fix by Lars, put in two years ago (see laberning#32). As the rest of the Pi's ran on V16 of that same platform, not big deal.

However, fast forward two years and Node.js has moved on to V18 and V20. And most packages have moved as well. However, as far as I can tell, the reason for the Pi Zero being stuck on V14 of Node.js is still there (i.e. WebAssembly will not work on Node.js V16 on ArmV6), so that will remain there indefinitely.

On the newer Pi's, I've been able to upgrade to Node.js V18 with holding several non-essential (development) packages back to an old version. So, we got rid on an annoying warning about using an outdated version of Node.js. And as far as I can tell, we keep compatibility with the V14 version. But, as I haven't got the hardware, there is no way for me to test this. So the current V1Beta_Updates package streches the capabilities, but doesn't break anything.

HOWEVER, Operating Systems move on, and the current version of Raspberry OS (bookworm) has moved to Python3.11, which actually requires several of the held back packages to upgrade to newer versions then node V14 can support. As one package specifically is quite essential (gyp) in compiling things in the background, we are required to do an upgrade of the node versions. The Pi Zero is still on sale and although Bookworm supports the original Pi Zero, the underlying libraries we need won't support the ArmV6 architecture. So, in essence we are in a squeeze here: abandon the original Pi Zero and move on to Bookworm, or stay put and keep the original Pi running as long as possible.

In theory I could make a smarter install script that paces the correct package lists, but that would probably break our automated test procedures, so that isn't much of a solid start.

What I propose:

• We remove the Raspberry Pi Zero from the list of supported devices, as Bookworm will break compatibility and at a certain moment we have to break compatibility to stay in reasonably easy installable and supported configurations.
• We will maintain the current install until either the Zero W, BullsEye and Node.js V18 are out of support, allowing people a grace period to migrate. In practice:
  • The Pi Zero will be sold until January 2026
  • Bookworm's successor will probably be released around October 2025 (and thus BullsEye will not be easily accessible anymore)
  • Node.js V18 support will be stopped in April 2025
• Add a warning to the install script that support will stop as soon as April 2025
• I will prepare a V20/Bookworm build behind the scenes as a separate branch, allow it to be installed (just like the current script) and push it to the main branch when the time comes. How to keep the branches both functionally identical is a bit tricky, especially given the limited resources of the Pi Zero, but I'll figure it out.
• If needed, we could keep the old branch available.

This will give people about 18 months to migrate to a Pi Zero 2W, or at least secure the install image, which sounds reasonable to me.

Any better ideas, objections, etc. on this?

[Gordon-Shumway2]

Hello Jaap,

is there any way to check how many users would be affected by removing Pi Zero? Maybe this is a non-issue due to no one (or a very small number) using the Zero.
Would it make your live easier if you had a Zero W v1.1 or a Zero 2 (without w)? I have both of these lying around and would happily offer them.

Regards,
Gordon aka Michael

[JaapvanEkris]

Hi Micheal,

Thank you for the very kind offer.

Unfortunately we have absolutely no clue how many people installed onto these devices. We don't even know how often it is installed at all. But regardless of that, I like to think that cutting of any user from future updates is one too many. This isn't a decision that is taken easily, regardless of numbers. A Pi Zero 2W is a good and cheap replacement, and a lot faster. But it might hurt people in their wallet in a way they might not be able to afford.

As long as we stay within the walled garden of JavaScript, any functional changes shouldn't break anything. So maintaining two baselines is doable. Coming to think of it: the upgrade script (which allows repository switches) must check what machine it is, to prevent people destroying their install with an update).

Having a Pi Zero would shine some light on what we are breaking by upgrading installed packages, but as I understand it, it still is stuck on Node.js V14, and many people made a fuss about it already. I could install an emulator or have my daughter get one from her school, and get some more info. But as I see it, in the end it won't change the final issue as WebAssembly won't run on Node16+ for ARMV6, and some package upgrades require Node18 or Node20.

[Abasz]

So maintaining two baselines is doable. Coming to think of it: the upgrade script (which allows repository switches) must check what machine it is, to prevent people destroying their install with an update).

The above is something I would suggest: i.e. have a separate branch that has the outdated packages for the V14. Basically only one commit will be in that branch and that is the compatbile package.json. That branch can be rebased on the latest version after updates. So the JS code will be the same. Of course we will hit some deprecation and other issues at some point (i.e. where a feature is used that is not available in the old packages) but if we are lucky by that time Pi Zero is out and this will not be an issue.

[JaapvanEkris]

I now have two branches:

• A Raspberry Pi Zero W branch
• A modern Raspberry Pi branch

[Gordon-Shumway2]

Funnily enough I only noticed today that the pi I thought was a zero 2 is actually an zero (1). Some months ago I had given my zero 2 to a friend, used a zero (1) instead, had forgotten about it and did not switch back when I got the zero 2 back.
So the installation of v1beta_updates I did today was actually done on the zero (1), succeeded but once ORM was und running it ran into issues when trying to connect my HRM belt (tickr x 2, which had worked on all previous installations).

I am now going back to my zero 2 so no bugfix is required by me. Given the nature of zero's ORM future does it make sense to upload the logs?

Regards,
Michael

[JaapvanEkris]

Currently I'm struggling to get everything working on a RPi 4 on Bookworm. I got it working, until I did a fresh install. Let's say I have plenty of puzzle left on the table at the moment.

I already order an extension cable for my MicroSD card, to allow changing the card while the case stays together......

Regards,

Jaap

[Abasz]

During the weekend I spent like 5 hours get it to work. Have not read the forum discussion at that point on this topic. :):) Then read the stuff and switched back from Bookworm.

I think as well that gyp does not like python 3.11. I tried to downgrade but I was out of luck so I gave up. I like the new oneliner install script download it work very well :)

[JaapvanEkris]

Yeah, it took some puzzling, but I think the v1beta_updates_Bookworm_Node20 branch works now. Will do a lot of testing before I release it.

[pxStrato]

Sorry in case this is the wrong location for my question.
I just learned about the project and was thrilled to give this a go with my Topiom rowing machine.
So I dusted off an old Pi Zero WH I had laying around, followed the installation instructions, but encounter errors when running the validation commands:

May 08 23:59:21 rowingmonitor systemd[1]: Started Open Rowing Monitor.
May 08 23:59:37 rowingmonitor npm[3185]: > [email protected] start /opt/openrowingmonitor
May 08 23:59:37 rowingmonitor npm[3185]: > node app/server.js
May 08 23:59:55 rowingmonitor npm[3258]: ==== Open Rowing Monitor 0.9.0 ====
May 08 23:59:55 rowingmonitor npm[3258]: bluetooth profile: FTMS Rower
May 08 23:59:56 rowingmonitor npm[3258]: Starting a just row session, no time or distance target set
May 08 23:59:56 rowingmonitor npm[3258]: heart rate profile: Off
May 08 23:59:56 rowingmonitor npm[3258]: ant plus profile: Off
May 08 23:59:56 rowingmonitor npm[3258]: webserver running on port 80
May 09 00:00:03 rowingmonitor npm[3281]: Gpio-service: pin number 17, polling interval 5 us, triggered on Up flank, mi>
May 09 00:06:11 rowingmonitor npm[3281]: 2024-05-09 00:06:11 sigHandler: Unhandled signal 18, terminating
May 09 00:06:11 rowingmonitor systemd[1]: Stopping Open Rowing Monitor...
May 09 00:06:11 rowingmonitor npm[3258]: SIGTERM signal was received, shutting down gracefully
May 09 00:06:11 rowingmonitor npm[3258]: shutting down all peripherals
May 09 00:06:12 rowingmonitor npm[3281]: 2024-05-09 00:06:12 sigHandler: Unhandled signal 18, terminating
May 09 00:06:12 rowingmonitor npm[3281]: 2024-05-09 00:06:12 sigHandler: Unhandled signal 11, terminating
May 09 00:06:12 rowingmonitor npm[3281]: 2024-05-09 00:06:12 sigHandler: Unhandled signal 11, terminating
May 09 00:06:12 rowingmonitor systemd[1]: openrowingmonitor.service: Succeeded.
May 09 00:06:12 rowingmonitor systemd[1]: Stopped Open Rowing Monitor.
May 09 00:06:12 rowingmonitor systemd[1]: openrowingmonitor.service: Consumed 58.217s CPU time.
-- Boot 09f3377bd76f48b5879ee73f336420b7 --

I tried to find something on the unhandled signal errors on here or via Google, but had no luck.
Anybody here who can help me find the right direction of where to look for what is not setup correctly? :)

[JaapvanEkris]

Typically it does this when something goes wrong. Could you run it manually, as it tends to say where it goes wrong?

You can do so by running

cd /opt/openrowingmonitor/app
sudo npm start

[pxStrato]

I don't really understand why, but after disabling the service and starting ORM manually, it started working.
Went back to enable the service and it all seems to be working fine.

Appreciate your help a lot, Jaap! :)