OmniHub 1.3.3

Four fixes. One of them is self-perpetuating, which is why this follows 1.3.2 within the hour.

If you are on 1.3.0, 1.3.1 or 1.3.2, the app will not offer you this release. Its update checker is blind — that is the bug being fixed. Install this one by hand and the checker works normally from then on.

The update checker could not see any release newer than 1.2.0. It identified an OmniHub release by requiring an asset ending in .zip, which was correct until 1.3.0 made the download a setup program. A release failing that test is skipped rather than reported, so the newest release visible to the app was 1.2.0 — which loses to any 1.3.x. Two symptoms from one rule: "you are on the latest version" shown to people a release behind, and a release-notes list in Settings that stopped at 1.2.0.

Fixed

• The update checker could not see any release newer than 1.2.0. It identified an
  OmniHub release by requiring an asset ending in .zip, which was correct until 1.3.0 made
  the download a setup program. A release that fails that test is skipped rather than
  reported, so the newest release the application could see was 1.2.0 — which loses to any
  1.3.x. Two symptoms, one cause: anyone on 1.3.x was told they were already on the latest
  version, and the release-notes list in Settings had nothing newer than 1.2.0 to show. A
  setup executable now counts and outranks a zip, so the older releases still resolve.
  If you are on 1.3.0, 1.3.1 or 1.3.2 your updater is blind and will not offer you this
  — install it by hand once and it works from then on.
• Downloading an update saved it under the wrong name. DownloadAsync built
  OmniHub-<tag>-win-x64.zip unconditionally, so from 1.3.0 it would have written a setup
  executable under a .zip name: a file Explorer will not run and no archiver will open. It
  follows the published asset name now.
• The tray flyout cut off its own button. Its height was hardcoded and the content
  measured taller, clipping Open OmniHub along the bottom edge. It sizes to its content
  now, which also covers themes that carry more padding than the one it was measured
  against.
• The divider in the tray flyout was a three-pixel dot. It set both Width="3" and
  HorizontalAlignment="Stretch"; width wins.

---

---

SHA-256 of OmniHub-1.3.3-setup.exe, built from commit b9fa0f5:

f503166eadc7b585a11c53842740c75a9f8b0680dca2d345b3397273e886f5c7

The build is not code-signed, so SmartScreen will warn. That means Microsoft has not seen the file vouched for, not that it has been inspected and cleared.

OmniHub 1.3.2

Eight themes that differ in more than colour, and a live battery draw readout.

The Dashboard title bar now shows what the machine is pulling from the pack — 31.3 W 2h 14m left — or AC, with the charge rate when charging. Straight from root\wmi BatteryStatus, which the codebase has read since 1.0 for the battery-saver's runtime estimate and never once put on screen.

A theme is no longer a recolour. A palette now sets corner radius, card padding, the heading typeface, the weight of every progress track, the size of the big readouts, and whether cards carry any lift at all. Terminal is monospaced with hairline tracks and perfectly flat surfaces at the tightest density here; Sandstone is the opposite corner of every one of those axes. Four new themes — Nord, Terminal, Sandstone, Mono — for eight in total, and the default moves to Midnight.

Added

• Live battery draw. The Dashboard title bar shows what the machine is actually pulling
  from the pack and the runtime that implies — 31.3 W 2h 14m left — or AC, with the
  charge rate when charging. Straight from root\wmi BatteryStatus, which the codebase had
  read for the battery-saver since 1.0 and never surfaced. The runtime estimate is
  deliberately unsmoothed: it is remaining capacity over draw at that instant, so it swings
  when load swings, because an estimate that looks stable while the truth is moving is worse
  than one that visibly moves.
• Four more themes, for eight: Nord, Terminal, Sandstone and Mono alongside Midnight,
  OLED Black, Graphite and Ember. The default moves to Midnight.

Fixed

• Two themes were indistinguishable. Rebasing the palettes on the 1.3.0 reference gave
  OLED Black and Midnight the same blue-to-cyan accent, and the picker drew three colour
  chips and nothing else, so the two previews rendered identically.

Changed

• A theme is no longer a recolour. A palette now sets corner radius, card padding, the
  heading typeface, the weight of every progress track, the size of the big readouts, and
  whether cards carry any lift at all — so switching theme changes the feel of the layout,
  not only its hue. Terminal is monospaced with hairline tracks and perfectly flat surfaces
  at the tightest density here; Sandstone is the opposite corner of every one of those axes.
  Those tokens moved out of Theme.xaml into the palettes and every reference became
  DynamicResource, since a StaticResource is resolved once when a style is sealed and
  would bake one theme's geometry into all the others.
• The theme preview draws a miniature card using each theme's own radii and inset,
  because the difference a palette now makes is one a colour chip cannot show.

---

---

SHA-256 of OmniHub-1.3.2-setup.exe, built from commit 8d34907:

89a87f905253e625615809fc9afbbf5aafd3b18bebd1149bf2278a374f777f90

The build is not code-signed, so SmartScreen will warn. That means Microsoft has not seen the file vouched for, not that it has been inspected and cleared.

OmniHub 1.3.1

A correctness release for the one thing 1.3.0 got wrong — and it is the thing 1.3.0 was largely about.

The sign-in task never actually received its battery settings. Every XML registration since the feature was written had been failing silently, on every machine: the generated task document carried an XML comment whose prose contained a double hyphen, which XML forbids, so schtasks rejected it with incorrect comment syntax and a fallback registered a command-line task instead. That form cannot express DisallowStartIfOnBatteries or StopIfGoingOnBatteries — so the task looked fine, refused to start on battery, and was killed on unplug. Exactly the defect 1.3.0's notes claimed to have fixed.

If you installed 1.3.0 and ticked "Start OmniHub when I sign in", your task is affected. Installing 1.3.1 and re-ticking it fixes the task; or turn the option off and on again under Settings.

Fixed

• The sign-in task never actually got its battery settings. Every XML registration since
  the feature was written had been failing, silently, on every machine. The generated task
  document carried an XML comment explaining the schema constraints, and that comment held a
  double hyphen in ordinary prose; XML forbids one inside a comment, so schtasks rejected
  the document with incorrect comment syntax and the fallback registered a task using the
  command-line form instead — which cannot express DisallowStartIfOnBatteries or
  StopIfGoingOnBatteries. The result looked like a working task, refused to start on
  battery, and was killed on unplug: exactly the defect 1.3.0 claimed to have fixed.
• A degraded registration is no longer reported as success. -InstallStartup returns 0
  when the task was registered as intended, 2 when it fell back, and 1 when it failed
  outright, and writes the reason to %AppData%\OmniHub\logs\startup-task.log. A file
  rather than a console, because the installer runs it hidden — and because attaching a
  console here writes into a window nobody sees rather than into a redirected stream, which
  is what hid this for one round of diagnosis.

---

---

SHA-256 of OmniHub-1.3.1-setup.exe, built from commit 3bf15ba:

e9d3a60d98680ab44607e557944a7621105fb8ac3db5254a5828dc78bfbf266d

The build is not code-signed, so SmartScreen will warn. That means Microsoft has not seen the file vouched for, not that it has been inspected and cleared.

OmniHub 1.3.0

Battery, an installer, and a rebuilt interface.

The download is now a setup program. Run it, agree to the licence, choose a directory, and tick what you want: a desktop shortcut, a sign-in task, and the PawnIO driver. Setup asks you to close a running OmniHub rather than killing it to free a file lock — a hard kill never reaches the shutdown path that hands fan control back to the BIOS.

On battery, measured on one machine (HP Victus 15-fb2999ax): 43.3 W discharge became a 17.9 W mean with a 12.7 W floor, and OmniHub is no longer terminated when the charger comes out.

Fixed

• The app was not crashing on unplug — Windows was killing it. The auto-start task carried
  both of Task Scheduler's battery defaults, DisallowStartIfOnBatteries and
  StopIfGoingOnBatteries, because schtasks' command-line form cannot express either and the
  task had always been created with it. So OmniHub did not start at sign-in while unplugged, and
  was terminated the moment the charger came out — LastTaskResult 0x8007042B, the process
  terminated unexpectedly. It is a hard kill, so the fan controller never reached its shutdown
  path and never handed control back to the BIOS: a power event could leave the fans pinned at
  whatever was last commanded, on the rail where a stuck fan is also draining the battery. The
  task is registered from XML now, with both flags false and no execution time limit.
• A failed registration no longer leaves the machine with no task at all. /Create deletes
  before it writes, so a rejected XML left nothing behind and OmniHub stopped coming back after a
  reboot — worse than the defect being fixed. It falls back to the plain command-line form now,
  which carries Windows' battery defaults but does exist, and says plainly that it did rather
  than reporting success for something degraded.
• A failure says what Windows said. The error from the call that actually failed was being
  overwritten by the status re-query that follows it, so a dialog reporting "The system cannot
  find the file specified" was faithfully quoting a query for a task that had just failed to be
  created, and the create's own reason had already been discarded. schtasks is also resolved
  from Environment.SystemDirectory rather than by bare name — not a diagnosis, just one
  possibility taken off the table, since a system binary should not be reached through an
  inherited PATH.
• The AC-to-battery transition reached 90 °C. Unplugging switched profiles, which switched
  out of Adaptive, so the controller that would have backed the limit off had stopped running.
  Adaptive now owns both rails itself and the profile switch stands aside.
• The discrete GPU never slept on battery. nvidia-smi reported P4 at 0% utilisation against
  a 43 W discharge — awake and idling rather than in D3cold — because polling it over PCIe wakes
  the card, and because the TGP re-assertion loop kept overriding the firmware's own reclaim. On
  battery the loop stands down and the card is left alone; the ceiling is released on unplug
  rather than waiting ~90 s for the firmware to take it back.

Added

• An installer. The download is a setup program now: licence, install directory, optional
  desktop shortcut, an optional sign-in task, and a tick-box that fetches the PawnIO driver
  through winget. Uninstalling removes the scheduled task, which previously survived a
  deleted folder and failed at every sign-in thereafter. Built by installer\build.ps1,
  which also pins down how a release is produced: the repository's ordinary Release output
  is framework-dependent and useless on a machine without the .NET desktop runtime, while
  every shipped zip has been self-contained, and nothing recorded the difference except
  somebody's shell history.
• A licence. MIT, in LICENSE. There was no licence file at all, which made "source
  available" on the website a description of nothing in particular and left the installer
  with no text to show.
• A battery rail for adaptive tuning. Separate maximum wattage and temperature target that
  take effect on unplug and are restored on plug-in, clamped immediately on the transition
  instead of drifting into the new rail over the following minutes.

Changed

• The interface, against a supplied reference. Blue into cyan as a two-stop accent ramp;
  tinted rather than neutral grounds; 10px card corners; gradient progress tracks whose
  colour carries meaning (accent for utilisation, green to amber for memory pressure, amber
  to red for a temperature against its limit). A selected mode segment is a raised panel now
  rather than a solid accent fill that was the loudest thing on a window whose job is the
  readings.
• The Dashboard, rebuilt. Gone: a 27px heading reading SYSTEMCORE, presets named MAX
  TURBO / SMART BALANCED / TRAVEL ECO, and a 250x250 circular gauge redrawing at frame rate.
  In their place a chip bar carrying state, model, temperature and load; presets named Eco,
  Balanced and Performance and ordered quietest to loudest; and four equal cards each with a
  value badge, a reading, a labelled sub-row and a track. The gauge showed a 0-to-100 score
  that tapered from 30 C to 95 C and was capped at 25 while throttling: the endpoints, the
  taper and the penalty were all choices and none of them was a reading. It is degrees of
  margin as text now, beside the temperature it comes from.
• The fan level is read two bytes at a time. hpqBIntM exposes one method per response-buffer
  size, and the 128-byte one costs ~300 ms on this firmware against ~8 ms for the 4-byte one. That
  single call was 94% of the hardware poll. Measured: tick body ~314 ms to ~72 ms, real cadence
  2.32 s to 2.08 s.

---

---

SHA-256 of OmniHub-1.3.0-setup.exe, built from commit d025bc4:

8e5a094d95a525583ba0571927e63b2bf17ecc848b5472cff3b6ec8efe311ee3

The build is not code-signed, so SmartScreen will warn. That means Microsoft has not seen the file vouched for, not that it has been inspected and cleared.

OmniHub 1.2.0

Measurement, broader hardware support, and a UI grouped by subject.

The thread running through all of it: 1.1.1 compiled, passed every test, and was wrong. Most of this release is about being able to tell.

Added

Diagnostics tab. A load test that pins every core for a chosen duration and records temperature, package power, CPU clock and fan speed, writes the run to a CSV, and reports median, p90, max and the clock floor — the figure that moves when sustained behaviour does. It only reads: no fan commands, no power writes, so it is safe to run while OmniHub is controlling the fans, which is the point. Alongside it, the firmware's own capability answers and a one-click probe report. Also available as OmniHub.exe -LoadTest <minutes>.

What is limiting the processor (Performance › CPU). All five constraints — sustained power, boost power, EDC, TDC, temperature — each as a fraction of its own limit. Being at 99% of core current and 60% of power says plainly that raising the power limit will change nothing, which no single figure on the page could say. Hidden entirely without an SMU.

Shared CPU/GPU thermal budget. The two chips are cooled by one heatpipe but were tuned as independent knobs, so a GPU-bound game left the CPU holding a sustained limit it was not using while the package sat at its thermal target. When the GPU is busy and the package has reached target, the CPU yields. Both conditions are required: a busy GPU on a cool machine is not competing for anything.

Per-model fan calibration. profiles/<baseboard>.json can carry a chassis's real raw fan band, measured with the Manual Calibration tool. A profile missing a value, or one whose ceiling sits at or below its floor, is refused rather than half-applied.

Changed

Seven sidebar destinations instead of nine, grouped by subject: CPU tuning and GPU power are two halves of one decision about how much the machine may draw, so they share a Performance tab; app GPU routing joins the Windows settings under System. No screen's content moved.

The firmware gates behaviour. GetSystemData decoded completely and fed nothing but a line of -Probe output. It is read at startup now, and three states are kept distinct: supported, denied, and not stated. Only a stated denial disables a control — a reply carrying nothing is unknown, and switching off working hardware on the strength of a failed read is the silent failure worth avoiding.

Legacy boards get the right fan encoding. Pavilion Gaming and early Omen take a 0/1/2 thermal policy; current Omen and Victus take 0x30–0x50. The legacy path existed with zero callers, so those boards were being sent an out-of-range mode byte.

Fixed

• The GPU query is off the fan curve's critical path. It held a global lock while launching nvidia-smi and waiting up to three seconds, and the callers behind that lock were the fan control loop and the hardware poll.
• A dead reading no longer sits on screen when the performance reader fails.
• The readiness card appears. It was written, styled, and never called, so a machine missing the PawnIO driver got no explanation for why half the application was dark.
• Dragging the adaptive target no longer freezes the window — each intermediate slider position applied a thermal limit inline on the UI thread.
• Tabs build in the background rather than on first click; the tray flyout stops subscribing to the poll forever after one click; the gauge stops rebuilding unfrozen geometry at frame rate; thermal logs are pruned after a fortnight.

Verification

190 tests, up from 118. The XAML layer is now tested too: all four palettes build the complete style layer, every resource reference is checked to resolve, and 15 of 17 view files are parsed against the real merged dictionaries — so a broken screen fails the build rather than a click.

Install

Unzip anywhere and run OmniHub.exe as administrator. Not code-signed, so SmartScreen will warn.

1.1.1 should be skipped; 1.1.2 fixed a regression in it.

SHA-256 of OmniHub-1.2.0-win-x64.zip:

b42d0c8962e59ee45c1f41da2951b8403dcd3534937c41450b263667484d18a2

OmniHub v1.1.0

Updates, power plans, and broader hardware support. The theme running through all of it: ask the machine what it can do instead of assuming, and say plainly when the answer is "unknown".

Added

• In-app updater. Settings gains an Updates card: installed version, a manual check, the release notes for anything newer, and a download with progress that reveals the file in Explorer. It stops short of unpacking over the running install — OmniHub runs elevated and holds the fan service, and swapping its own binary underneath itself to save one manual extract is not a trade worth making in an app whose absence puts the laptop back on the stock curve.
• Changelog in the app and on the website, both read from these published releases rather than from a file either could forget to update.
• Power plan builder (System tab). One slider runs from maximum battery life to maximum performance; every setting is derived from it, and the resolved values for both rails are shown before anything is written. Available values are read from Windows rather than listed in the source, so a machine with a different set of boost modes gets a builder that matches it.
• Automatic power plan switching (Settings), off by default, with a picker per rail listing every scheme on the machine — so an existing tuned plan can be targeted instead of taking the two OmniHub creates.
• GPU telemetry on every machine, not only NVIDIA ones. Win32_VideoController names the adapter and the GPU engine performance counters give 3D load, on any vendor. Temperature, power and clock stay unavailable there rather than estimated, because Windows exposes no generic thermal sensor for a GPU.
• HP capability reporting. GetSystemData (0x28) was declared and never called. It is now decoded, and answers "will this work on my laptop" from the firmware rather than from a hand-maintained list of model numbers. Two fields matter: whether software fan control is supported at all, and which thermal-policy encoding the board speaks — legacy boards including Pavilion Gaming take 0x00–0x03, current Omen and Victus take 0x30–0x50. Smart adapter status, keyboard type and backlight support are read too.
• -Probe reports all of the above, and two screenshots of the running application are on the download page.

Changed

• No coloured status text. Red was decorating permanent labels and repeating what result sentences already said. Numeric readouts keep their thresholds — the temperature figure still turns red past 80 °C — and bars, gauges, chart lines and status chips keep their colour. Prose and labels no longer take it.
• The readiness panel distinguishes no adapter readable at all from an adapter that reports name and load but exposes no thermal sensor.
• Power plans are only ever created, never edited. Duplicating a scheme leaves your own configuration untouched and reversible.

Fixed

• The update checker never offers OmniControl Suite as an OmniHub upgrade. That application shares this repository and its v9.0.0 tag is numerically the highest here, so a naive check would push an unrelated program at every user, forever. A release counts as OmniHub only if it carries an OmniHub-*.zip asset. Covered by tests.
• The system design query is sent with no payload, the way HP's own software sends it. Asked with a four-byte buffer it returned a well-formed reply with every capability byte clear, which decoded into "this machine supports no fan control" — printed on a laptop whose fans the application was driving at that moment. A zeroed capability block is now reported as a failed read rather than a featureless board.
• Boost mode is selected by name, not by index. It was written as 3 under a comment saying "Aggressive"; Windows enumerates 3 as Efficient Enabled and 2 as Aggressive on this hardware. Index assumptions apply cleanly, report success, and do the wrong thing.
• -Probe runs while the application is open. The single-instance guard sat in front of it, so the one command you would run to diagnose a live machine answered with a dialog instead of output. The guard still covers -Calibrate and -RunHeadless, which command the fan.
• The changelog list no longer swallows the mouse wheel on the Settings tab.

Install

Self-contained — no .NET runtime needed. Windows 10/11 x64, runs as Administrator.

Extract somewhere permanent, run OmniHub.exe, accept the UAC prompt. Elevation is not optional: the WMI session requires it and the SMU driver refuses unelevated callers.

The build is not code-signed, so SmartScreen will warn. That means Microsoft has not seen this file vouched for — not that it has been inspected and cleared.

SHA-256 of OmniHub-v1.1.0-win-x64.zip:

755c9a344da3243bded234641b548665cc15b6c102a13804f292c17980bcf803

Get-FileHash .\OmniHub-v1.1.0-win-x64.zip -Algorithm SHA256

Built from commit f01212e. 118 tests pass.

Full changelog: https://github.com/Vomitted/OmniHub/blob/main/CHANGELOG.md

OmniHub v1.0.0

Fan curve control with a safety floor, GPU power and mode, AMD CPU tuning.

Self-contained build — no .NET runtime needed. Requires Windows 10/11 x64 and runs as Administrator.

SHA-256 of OmniHub-v1.0.0-win-x64.zip:
fde03a7c3078c42643abd41f1502a627b9ca8b029f66bc6e0b7f5efaecb0faf6

Built from commit b3bb84f. Not code-signed, so SmartScreen will warn.