Skip to content

OpenHardwareOS v0.1.7 — 服务能说明它在做什么

Pre-release
Pre-release

Choose a tag to compare

@SvenKunkka SvenKunkka released this 15 Sep 10:12
· 31 commits to main since this release

OpenHardwareOS v0.1.7 is about the background service from v0.1.6 being able to say what it is doing — and about the two outage paths the goal asks to be verified. Existing v0.1.0 – v0.1.6 tags and downloads remain available.

Changes

The service now reports each rule, not a count

  • ohm-cli service status prints every rule's status, its confirmed value, and its own sentence about what it is doing:

    rules:
      chassis       fallback  at 70  fan.system.fakechip_fan1/fan.rpm is missing: falling back to 70 %
      gpu-cooling   held      at 64  no change worth writing (0.00 % within the 0.00 % deadband)
    
  • "3 rules loaded" could not distinguish cooling along the curve from sitting on the fail-safe because a sensor went away. The state file carries the difference.

The service writes a log file

A process nobody is watching must leave a record: service run now logs into the config directory's logs/, and its banner prints the exact paths of the state file and the log directory.

Sensor loss and recovery, and suspend and resume, are tested at the service level

  • A prepared hwmon tree is read through OHM_HWMON_ROOT (read-only: this build writes no pwm<N>, so it changes what is read and never what is written). The test's rule reads a tachometer from that tree and drives the simulated fan.
  • Delete the tachometer: the state file reports fallback, the fail-safe 70 %, and names the sensor that went away. Put it back: the rule reads again — status leaves fallback and the message returns to that reading.
  • Suspend and resume: after SIGSTOP beyond the heartbeat window, service status reports "not running" and names whose stale file it is — the state in which another process may take the channels over, which is what a sleeping machine looks like. After SIGCONT the same process is still the owner, with heartbeat and cycle counter moving again.

One behaviour that looked like a bug, now stated

After a reading returns, the rule keeps the fail-safe 70 % rather than stepping to the curve's 65 %. That is hysteresis working: hold until the reading passes the anchor, because less cooling is the dangerous direction. The rule's own message says so ("holding 70 % until … drops below …"), and the page repeats it — it cost an hour to read as "the sensor came back and the rule never recovered".

Install

Nothing here has run on real hardware: the sensor, the channel and the machine are all prepared trees and simulated providers, and the page says so. The Windows desktop installer and the optional PowerShell script are unsigned, and so are the Linux packages. LibreHardwareMonitor is a separate prerequisite for supported motherboard channels on Windows and is not bundled.