Skip to content

fix(npu): alert on the temperature both interfaces already ask for - #3718

Merged
nicolargo merged 1 commit into
nicolargo:developfrom
ntdatt812:fix/npu-temperature-alert
Sep 10, 2026
Merged

nicolargo merged 1 commit into
nicolargo:developfrom
ntdatt812:fix/npu-temperature-alert

Conversation

@ntdatt812

Copy link
Copy Markdown
Contributor

The NPU plugin's temperature is never alerted, in either interface, at any reading.

update_views() does not extend the views the base class built — it replaces them:

self.views[i[self.get_key()]] = {'load': {}, 'freq': {}, 'mem': {}}

temperature is not in that dict, so views[npu_id]['temperature'] does not exist, and both readers fall back to no style:

  • msg_curse asks get_views(item=..., key='temperature', option='decoration') (npu/__init__.py:249), and get_views returns the string 'DEFAULT' for a key it cannot find.
  • plugin-npu.vue:35 calls getDecoration(npu.npu_id, 'temperature'), whose first line returns undefined when the view is missing, so no class is bound.

Both sides were written expecting a decoration that nothing produces. The reading itself is real: cards/intel.py:82 sets it from the driver (temp_value / 1000.0); AMD and Rockchip document it as not implemented and leave it None.

The sibling GPU plugin has had all three alerts — proc, mem, temperature — since it was written, so this is the NPU plugin missing one its own callers assume, not a feature neither has.

The change

Adds 'temperature': {} to the view dict and the alert beside the other three, in the GPU plugin's shape. A card that reports no reading keeps an empty view rather than being alerted on None, which get_alert would otherwise score through (None * 100) / 100.

conf/glances.conf gains the matching [npu] thresholds on the same 60/70/80 ladder [gpu] uses. That half is not cosmetic: with no limits configured, get_alert takes its not careful and not warning and not critical branch and returns 'DEFAULT', so the code change alone would be invisible.

I did not add mem_* thresholds to [npu], although update_views computes a mem alert that is unconfigured for the same reason. Leaving a stat unthresholded is a normal default across the plugins; temperature is different only because two call sites already read a style for it.

Verification

pytest tests/test_plugin_npu.py is 13 passed (new file); with test_plugin_gpu.py and test_plugin_quicklook.py, 56 passed / 9 skipped. ruff check and ruff format --check are clean.

Each half was checked by reverting it:

reverted fails
'temperature' dropped from the view dict (the shape on develop) all 9 plugin tests
the alert block removed, the view key kept 8 of 9 — the "driver reports None" test still passes, which is the discrimination it is for
the [npu] thresholds removed from conf/glances.conf the 4 shipped-config tests only

The last row is why the config assertions exist at all: without them the code change could be reverted in conf/glances.conf alone and every behavioural test would still pass while the alert stayed invisible.

I have no NPU to hand, so the assertions drive update_views over a synthetic card rather than a real one.

update_views() replaced the base class's per-field views with a dict naming
only load, freq and mem, so views[npu_id]['temperature'] did not exist. Both
readers then fell back to no style: msg_curse's get_views() returns 'DEFAULT'
for a missing key, and the WebUI's getDecoration returns undefined. An Intel
NPU -- the one driver that reports the reading -- was printed plain at any
temperature.

Adds the key and the alert, mirroring the GPU plugin, which has had the same
three alerts (proc/mem/temperature) all along. A card whose driver leaves the
reading None (AMD, Rockchip) keeps a view with no decoration rather than being
alerted on nothing.

conf/glances.conf gains the matching [npu] temperature thresholds, using the
same 60/70/80 ladder as [gpu]: without limits get_alert() returns DEFAULT, so
the code half alone would change nothing.
@nicolargo nicolargo added this to the Glances 4.5.7 milestone Sep 10, 2026
@nicolargo nicolargo added the bug label Sep 10, 2026
@nicolargo
nicolargo merged commit b903fa3 into nicolargo:develop Sep 10, 2026
17 of 19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants