[Feature Request] HWiNFO Shared Memory backend and custom sensor mapping

[lekigalletas]

Hi!

First of all, thanks for this project. I am currently using Turing System Monitor with a TURZX 9.2" display and it works very well, especially compared with the original TURZX software.

However, I have found a limitation with hardware monitoring that I think could be solved in a generic way and would be useful for many users.

The problem

My PC uses a Corsair Commander CORE to control the AIO pump and several fans.

HWiNFO correctly detects all of these sensors:

• Pump RPM
• Coolant temperature
• Fan 1 RPM
• Fan 2 RPM
• Fan 3 RPM
• Fan 4 RPM
• Fan 5 RPM
• Fan 6 RPM

However, LibreHardwareMonitor does not expose most of these sensors.

Because Turing System Monitor currently relies mainly on LibreHardwareMonitor on Windows, I cannot use these values in my themes even though they are already available and working correctly in HWiNFO.

For example, HWiNFO can show something like:

Corsair Commander CORE

• Pump: 2600 RPM
• Coolant: 36 °C
• Fan 1: 1100 RPM
• Fan 2: 1080 RPM
• Fan 3: 1120 RPM
• Fan 4: 1230 RPM
• Fan 5: 1210 RPM
• Fan 6: 1240 RPM

But Turing System Monitor cannot currently use these values.

Proposed solution: HWiNFO Shared Memory backend

It would be great to add HWiNFO Shared Memory as an optional hardware monitoring backend.

For example:

Hardware monitoring:

• LibreHardwareMonitor
• Python libraries
• HWiNFO Shared Memory
• Auto

HWiNFO already exposes a very large number of sensors from proprietary controllers that may not be supported by LibreHardwareMonitor.

This could avoid having to implement support individually for every Corsair, NZXT, ASUS, Aqua Computer, etc. controller.

Even better: generic custom sensor mapping

Ideally, Turing System Monitor could expose a sensor browser where users can select any available sensor and assign it to a theme element.

Something like:

Backend:
HWiNFO

Device:
Corsair Commander CORE

Sensor:
Fan #4

And then use that sensor in a TEXT, RADIAL, GRAPH, etc.

Conceptually:

HWiNFO
└── Corsair Commander CORE
├── Coolant Temperature
├── Pump
├── Fan 1
├── Fan 2
├── Fan 3
├── Fan 4
├── Fan 5
└── Fan 6

It would also be useful if sensors could be referenced directly from theme.yaml through a generic custom sensor definition.

For example:

CUSTOM:
AIO_PUMP:
BACKEND: HWiNFO
SENSOR: "Corsair Commander CORE/Pump"

COOLANT:
BACKEND: HWiNFO
SENSOR: "Corsair Commander CORE/Coolant Temperature"

CASE_FAN:
BACKEND: HWiNFO
SENSOR: "Corsair Commander CORE/Fan 4"

Then those values could be used by normal theme elements.

GUI sensor mapping

Another possible improvement would be to let users select sensors directly from the configuration/theme editor instead of having fixed mappings such as CPU temperature, CPU fan, GPU fan, etc.

For example:

Widget:
Fan RPM

Data source:
HWiNFO

Device:
Corsair Commander CORE

Sensor:
Fan 4

This would make the theme system much more flexible.

Instead of Turing System Monitor deciding which physical sensor corresponds to "CPU FAN", the user could decide which sensor should feed each widget.

Why I think this would be useful

This would not only solve Corsair Commander CORE support.

It could provide a generic solution for many devices that are already supported by HWiNFO but not by LibreHardwareMonitor.

It would also allow much more advanced custom themes, for example displaying:

• AIO coolant temperature
• AIO pump RPM
• Individual radiator fan RPM
• Individual case fan RPM
• SSD temperatures
• VRM temperatures
• motherboard temperature sensors
• custom temperature probes
• power sensors
• controller-specific sensors

without requiring Turing System Monitor to add explicit support for every piece of hardware.

Even a basic implementation where users can select an HWiNFO sensor by ID/path and expose it as a CUSTOM sensor would already be extremely useful.

Thanks for considering it!

[c0ldJS]

Repo owner has touched upon HWiNFO in the past. See #205.