Support for Raspberry PI

[andrijasinski]

Hi there! I tried to run doppler on my raspberry pi 3b+ but got this error - cannot execute binary file: Exec format error. It basically means that the software is meant to run on x86 platform, not on mobile like the raspberry pi.

So my question would be if there are any plans on supporting Raspberry PIs? Or maybe you have already investigated this? Thanks.

[EnKrypt]

That's correct, there are no builds right now for ARM.

Someone on reddit had expressed interest in running Doppler on RPi, but I guess I lost track of time.

My main concern is stability. Often packages compiled on one architecture doesn't work well on the target architecture. It's a known issue in the build tool I am using.

So I want someone to test it out first. If you're interested, just shoot me an email. I'll send you a build compiled specifically for ARM, and if you can confirm that it works without issues, I'll add that build to the official release list.

[andrijasinski]

@EnKrypt Sure, send me one to [redacted] !

Edit from Owner: Removed personal info.

[EnKrypt]

I have some disappointing news. I attempted to build for armv7, but the build tool did not like that at all.

The compiler I am using is pkg. It refuses to build for armv7 on any x64 host. Linux, Windows or Mac.

This problem is directly related to zeit/pkg#457.

Looks like for now, the only way to get a build for armv7 is to actually build it within an armv7 environment itself, but sadly I don't have access to such a device currently.

Maybe I will get my hands on a RPi in the future for this, but until then if somebody reading this wants to go ahead and manually create a build themselves, here are the instructions :

(Requirements: nodejs-lts with yarn or npm installed on a Raspberry Pi)

1. Clone the Doppler repository on your Raspberry Pi.
2. Globally install pkg via yarn global add pkg or npm -g install pkg. If you haven't globally installed a node module before, make sure the yarn or npm global bin is added to PATH.
3. Go to backend/ folder and install dependencies. (run yarn or npm install)
4. Come back and go to frontend/ folder and install dependencies. (run yarn or npm install)
5. Come back to the project root and make a JS build. (run yarn build or npm run build)
6. Finally, compile by pasting and running the following (still in project root folder) :

cd backend/dist && pkg app.js --target=linux-armv7 --out-path ../../release/ --config ../../package.json

Come back to the project root folder. If everything goes well, you should have your binary in the release/ folder.

[andrijasinski]

Hey, thank you for the instructions. I will try to build on RasPi today/tomorrow, but will also check the docker option like here. The hope is still here! 😄

[philw07]

Hey, I am running Doppler on my RPi for just over a week now and it's working fine so far. However, it doesn't read CPU temperature as it is, because the cores array returned by the systeminformation package is empty on the RPi, while the max temp is given. I patched it as follows.

diff --git a/backend/src/app.ts b/backend/src/app.ts
index 1bd1558..92d11d0 100644
--- a/backend/src/app.ts
+++ b/backend/src/app.ts
@@ -115,6 +115,9 @@ const poll = async () => {
     network = await SI.networkStats();
     try {
         cpuTemp = await SI.cpuTemperature();
+        if (!cpuTemp.cores.length && cpuTemp.max > 0) {
+            cpuTemp.cores = Array(cpu.cores).fill(cpuTemp.max);
+        }
         if (!cpuTemp.cores.length) {
             throw new Error('Cannot monitor CPU temperature');
         }

I wrote the following Dockerfile to build the Doppler executable and then copied it to the host. Running in a container also works, but some of the information isn't available in that case. The ${COMMIT}.patch file contains the patch above.

#######################
### BUILD CONTAINER ###
#######################

FROM debian:buster-slim as build

WORKDIR /build

RUN apt-get update && \
    apt-get install -y --no-install-recommends git npm python && \
    npm install -g typescript react-scripts pkg yarn

ARG COMMIT=bf513e5

RUN git clone https://github.com/EnKrypt/Doppler.git . && \
    git checkout ${COMMIT}

ADD ${COMMIT}.patch /

RUN git apply /${COMMIT}.patch && \
    cd backend && \
    yarn install && \
    cd ../frontend && \
    yarn install && \
    cd .. && \
    npm run-script build && \
    cd backend/dist && pkg app.js --out-path ../../release/ --config ../../package.json --targets linux

#####################
### APP CONTAINER ###
#####################

FROM debian:buster-slim

WORKDIR /app

COPY --from=build /build/release/doppler /app/doppler

EXPOSE 80

CMD [ "/app/doppler", "-p", "80" ]

[EnKrypt]

Thanks a lot, @BearWithTie

I think I will find a way to provide first party docker support since it is proving to be a popular setup for a good chunk of our users.

It's good to know that Doppler runs fine on the RPi. I encourage you to submit that patch as a Pull Request in the meantime.

Given the kind of response I'm getting, I'm thinking it might be worth it to just borrow a RPi from a friend and release a build, just so this particular issue is put to rest.

Btw, I really appreciate the support. I never expected so many people to actually run what was originally just a pet project.

[philw07]

I added pull request #4. I actually figured instead of adding a patch for the RPi, it would be better to directly switch to using the max temperature provided by systeminformation. Not sure if there was a reason you were using the core temperature array in the first place?

[EnKrypt]

Hey, thanks for the PR.

I don't think we can switch directly to using the value in max because the strategy used to source the values for cores and max is different, as can be seen here in these lines.

On the systems I've tested with, there is a separate onboard sensor value for showing maximum temperature, and it is often incorrect by design in order to show a conservatively higher value, or because it uses some external offset.

In the case where the cores array is empty, it makes perfect sense to show such a sensor's value if it seems to be the only thing available, but otherwise where the cores array does exist, I think manually computing the maximum value in the array, while a bit crude, might be the most reliable way to show the temperature for now.
Ideally I would have liked a reading for 'CPU Package Temperature' which is by definition the highest single core temperature value, but the module we're using doesn't look like it has direct support for it.

So I think your original intended patch was more in line with what we wanted. Since this fixes an edge case only for the RPi (as far as I can see), having a specific patch that addresses it is fine according to me.

[philw07]

I see, tbh I didn't check the source, but it makes sense as you say. I reverted and added the patch.