Raspberry Pi: CPU temperature and model not reported (apps show 0°C / N/A)

[Kruton1122]

On Raspberry Pi (and likely other ARM SBCs), the cpu_thermal hwmon sensor has no _label file for its single temp1_input entry, so CPU.get_temperatures() falls back to the raw key name temp1. Both the iOS and Android apps only look for Tctl (AMD) or Core N (matching per-cpu frequency indices) when building per-core temperature data, so a Pi's real temperature is silently dropped and the apps show 0°C / N/A.

Repro (Raspberry Pi 4, Debian 13, Docker):

curl http://<pi>:9090/api/status | jq .cpu.temperatures
# {"temp1": [51.608, null]}

No Core N or Tctl key exists, so server-status-ios's transformStatusJSON never populates CPUCore.temperatures, and the app displays 0°C for CPU temperature.

Second, related regression: CPU.get_cpu_info() in lib/machine/cpu.py only parses the model name field from /proc/cpuinfo, which doesn't exist on ARM (Raspberry Pi's /proc/cpuinfo instead has a Model line, e.g. Model : Raspberry Pi 4 Model B Rev 1.4). This fallback used to exist (commit 8fa823e, "machine: Detect Raspberry Pi CPU model name") but appears to have been lost during the backend rewrite (de2ec53). Current behavior: cpu.model is always null on ARM boards, apps show "N/A". Same rewrite also dropped populating cores on ARM since there's no cpu cores line either (stays hardcoded to 1).

Suggested fix (what I patched locally to unblock myself, happy to open a PR if useful):

• In get_temperatures(), when the detected sensor is cpu_thermal and only one reading exists, alias it to Core 0..N-1 (using os.cpu_count()) so existing app-side parsing picks it up. Note the app's CPUCore.temperatures is typed as [Int], so the value must be rounded — the cpu_thermal sensor reports sub-degree precision (e.g. 51608 milli-°C) unlike many desktop sensors that only report whole-degree multiples, and an unrounded float fails Swift's strict JSON decode entirely (this actually broke the app's data loading altogether, not just the temperature display).
• In get_cpu_info(), add back a Model line fallback for cpu_model, and fall back cores to os.cpu_count() when no cpu cores line is found.

Happy to share the small diff if it's useful, or open a PR directly.

[dani3l0]

Seems like more of app's issue, but some improvements on backend are mandatory as well

The problem with os.cpu_count() is that it returns total thread count, not physical cores (on RPi that's fine, but CPUs like Ryzen 5600 or i5-12500 will have 12 cores reported, while both having 6 cores and 12 threads)

I'll try to reproduce this on my Pi 3A+ today and let you know if mine returns the same results

So, to clarify, my fixes most probably will be:

• return a proper number of cores in cpu.cores
• fix CPU model name (like RaspberryPi version, or BRCM if is defined somewhere)

Temperatures object will remain as is, because we only take highest value anyway in webui

Note: will confirm the above after reproducing this on my Pi

Edit: confirmed

[dani3l0]

Okay, did the above

• Changed entire CPU core count detection, so new method should now report the proper count for both x86s and RPis
• Added missing Model line into cpuinfo parser, unfortunately I didn't manage to get pure Broadcom model, we have an SBC name instead

Result on my Pi:

When it comes to iOS app, there's a bug I've mentioned in JGeek00/server-status-ios#3

Please let me know if core count and model name are reported correctly for you.

[Kruton1122]

Confirmed working on a Raspberry Pi 4 Model B Rev 1.4 (Debian 13, Docker) after pulling latest main (0ba0c34):

"cpu": {
  "model": "Raspberry Pi 4 Model B Rev 1.4",
  "cores": 4,
  "count": 4,
  ...
}

Both core count and model name are correct now. Thanks for the fast turnaround — appreciate you reproducing it on your own Pi 3A+ to nail down the thread-vs-core distinction too, that's a real improvement over the naive os.cpu_count() fallback I'd hacked in locally.

Temperature (temp1 only, no per-core keys) looks good on this end too — makes sense to hold off on more changes there until the "single aggregate temperature" approach lands on the app side (JGeek00/server-status-ios#3).

[dani3l0]

Glad it works for you.

When it comes to per-core temperatures, RPis simply do not report them. Most ARM-based systems (some x86 as well) have only a single thermal zone for the entire CPU package registered in hwmon.

Take a quick look at the /sys/class/hwmon/* directories and files inside them. That's exactly where Status pulls the temperature data from.