The Z440 sensors you have to switch on yourself
My HP Z440 Proxmox hosts had fan and ambient sensors the whole time. Linux ships the driver, nothing loads it. Here is what appeared, what else the board exposes, and why I measured before I tuned.
This week I put my three Proxmox hosts on an efficiency profile: a demand-based CPU governor, an energy-leaning preference, and turbo off. Two of those hosts are second-hand HP Z440 workstations. The question that came up straight away was the obvious one. Did it actually help, and how would I know?
On the Z440s, the honest answer was that I could not fully tell. I had the CPU’s own temperature and energy counters. I had nothing from the board: no fan speeds, no case temperature. That is a bad place to be if you plan to keep turning knobs. What you cannot measure, you cannot make better.
The driver was already there
HP publishes a WMI interface on these workstations that reports the firmware’s own sensor table. Linux has had an in-tree driver for it for a while, hp-wmi-sensors. The Proxmox kernel includes it. It just never gets loaded, because nothing in the system asks for it.
modprobe hp-wmi-sensors
sensors # or read /sys/class/hwmon directlyOn both machines five channels came up immediately and reported a Normal state:
- CPU temperature, as the firmware sees it, separate from the per-core readings.
- System ambient temperature.
- CPU fan speed.
- Rear chassis fan speed.
- Front chassis fan speed.
For reference, the idle readings looked like this. These are firmware numbers taken at different moments, not a calibrated comparison.
| Host A | Host B | |
|---|---|---|
| CPU | 50 °C | 40 °C |
| Ambient | 26 °C | 25 °C |
| CPU fan | 503 RPM | 492 RPM |
| Rear fan | 784 RPM | 742 RPM |
| Front fan | 615 RPM | 535 RPM |
Host A is the one carrying a GPU and a large LLM VM, which explains the warmer CPU.
The firmware actually lists sixteen sensor objects. The other eleven, a second CPU, liquid-cooling pumps, auxiliary fans and four memory-fan slots, all report Not Present. The schema is shared across HP’s workstation line, so a listed entry does not mean the single-socket Z440 can drive it. It is just a table.
To keep the sensors after a reboot, one line in a modules-load file does it:
echo hp-wmi-sensors > /etc/modules-load.d/hp-wmi-sensors.confTwo caveats from the kernel documentation worth knowing. The driver can also expose alarm attributes, but reading them may clear a latched alarm, so I left those alone. And if the ordinary hp-wmi driver is loaded first, it may own the firmware events and the sensor driver will not raise alarms at all. For plain readings, none of that matters.
What the board does not tell you
Nothing in this interface reports voltages, current, or whole-system wattage. The Z440 does not expose power-supply telemetry at all. The CPU and DRAM energy counters from Intel RAPL are still the only power numbers the machine will give you, and they only cover the CPU package and memory, not the GPU, disks, fans, or the PSU’s own losses.
So the new sensors answer “is the cooling doing what I expect” rather than “how much electricity am I using”. For the second question you still need a meter at the wall. A metering smart plug feeds the UPS in front of one of them, and that reading is what the efficiency work will be judged against.
The levers that are also there
While poking around I inventoried what the board lets you change from Linux, through the HP BIOS attribute interface and the kernel’s power-capping layer. None of these were changed; this is the list for later.
- Fan minimums. BIOS settings for a fan idle mode and a minimum percentage for the front and rear chassis fans. Mine already sit at the lowest listed values and the fans still spin, so zero is a floor, not off.
- No fan curve. There is no per-fan PWM value or custom curve interface. The
hp-wmidriver exposes apwm1_enabletoggle, but what a write to it actually does on this board is untested. - CPU power caps. RAPL exposes a long-term and a short-term package limit, currently 140 W and 168 W with enforcement enabled. The attributes are writable. Whether the firmware honours a lower value is the part I have not tested yet. The cap only matters under load; at idle the CPU is already well below it.
- Platform toggles. Runtime power management, idle power savings, turbo, behaviour after power loss, wake-on-LAN, scheduled power-on, and per-port USB, SATA and PCIe slot enablement.
Turbo is the one I am already using, but not through the BIOS setting. The BIOS still reads Enable; Linux’s intel_pstate/no_turbo is what holds it off, and that is reversible without a reboot.
Measure first
The efficiency profile dropped the reported CPU-package draw on Host A from about 31 W to about 25 W in a short sample. Host B barely moved, because it was already spending 99% of its time in a deep idle state. Those are package counters under uncontrolled workloads, so they are observations, not a saving I can put on a bill. A slower CPU can also take longer to finish the same job and erase the gain.
That is exactly why the sensors matter. Now each change has a before and an after: fan RPM and ambient for cooling, package watts and job time for efficiency, and the wall meter for the only number that counts. Loading one kernel module gave me most of that for free. It was always there.