Repository navigation
FAQ
This FAQ reflects the current documented HWcontrol2.0 architecture and implementation status. Platform- or hardware-dependent capabilities must not be interpreted as universally available.
HWcontrol2.0 is a cross-platform desktop hardware monitoring and control application.
Architecture: Flutter/Dart GUI → authenticated localhost Go bridge → native C++ engine → platform-specific hardware APIs.
The project targets Windows 10/11 x64, Linux x64 (primarily Debian/Ubuntu-family distributions), and macOS 14+ on Apple Silicon. Individual capabilities vary by platform, driver, firmware, permissions, and hardware model.
The project source is publicly hosted on GitHub. The repository and its license are authoritative for source and licensing information.
The bridge provides a controlled boundary between the GUI and native/privileged hardware operations. It also enforces authentication, validation, rate limits, safety checks, and fail-closed behavior.
Not every operation requires elevation. Some hardware-control or platform-specific operations may require additional permissions.
On Windows, the bridge service is designed to run as NT AUTHORITY\LocalService rather than LocalSystem to reduce unnecessary privilege.
Use the official package for your platform. Avoid manually modifying installed binaries or runtime files because integrity monitoring and release trust mechanisms may detect unexpected changes.
Telemetry depends on the operating system, drivers, firmware, hardware model, and available sensor backend. A missing value should not be treated as a valid zero reading.
Monitoring and control are separate capabilities. A device can expose fan RPM without exposing a safe writable fan-control interface. Unsupported or unverified control capabilities remain unavailable rather than being forced through an unsafe fallback.
Vendors expose different sensors, control interfaces, firmware behavior, and permissions. Support must be implemented and validated per backend and hardware family.
Yes. The bridge and dashboard can report mounted storage volumes, total/used/free capacity, usage percentage, and read/write throughput when the operating system exposes usable I/O counters.
Not universally yet.
HWcontrol does not invent a health percentage when the platform does not provide a trustworthy device-health source. The current generic storage layer reports health as unknown when no platform-specific reliability backend is available.
Windows provides an official Storage Reliability Counter interface with device temperature, errors, wear, and power-on information; a native backend can use that information in a future platform-specific health implementation.
Throughput is calculated from changes in cumulative operating-system I/O counters. The first sample establishes a baseline, so a subsequent sample is required before a meaningful bytes-per-second value can be calculated.
Yes. The hardware health engine can report a storage-near-full warning when a monitored volume reaches the configured high-utilization threshold.
bridge.key is a credential used by the local bridge authentication mechanism. It is not intended to be exposed to ordinary users or applications.
HWcontrol includes runtime integrity monitoring as a defense-in-depth control. If a monitored critical target is modified, replaced, missing, or fails integrity validation, the bridge can enter a fail-closed state and sensitive hardware-control operations are stopped.
Trusted repair or reinstall is required for recovery; the system does not automatically regenerate a tampered credential.
No. Localhost reduces network exposure, but a local service can still form a security boundary. HWcontrol therefore applies authentication, input validation, privilege reduction, rate limiting, replay protection, file permissions, and integrity monitoring.
No. It is defense-in-depth and does not protect against a fully compromised administrator/root account, kernel-level compromise, or direct compromise of the monitored process.
The health engine can use:
- SAFE
- WARNING
- CRITICAL
- FAIL_SAFE
The state considers available telemetry, detected anomalies, hardware capabilities, and integrity status.
The safety engine can request a fail-safe recovery action such as stopping hardware control and reducing thermal load. The exact response depends on available telemetry and control capabilities.
The project is designed around local hardware telemetry and a local bridge. Diagnostics and telemetry behavior should be evaluated against the current implementation and configuration.
Diagnostics expose health status, safety state, hardware capabilities, anomalies, and non-sensitive configuration state. Diagnostic export and telemetry history are also part of the project.
No. Local AI is optional and is not the foundation of hardware monitoring or safety control.
The local model is large compared with the core application and is handled separately. The model-management path verifies its expected SHA-256 value before accepting the model.
AI is not the authority for safety-critical hardware control. Hardware control remains governed by the bridge, validation, capability checks, and safety state.
- Confirm that the platform is supported.
- Check the relevant driver or platform sensor interface.
- Restart HWcontrol2.0 after hardware-driver changes.
- Check diagnostics for detection status and available capabilities.
- Check whether the specific backend supports the requested sensor or control.
- Collect diagnostic information before reporting a bug.
Not necessarily. RPM monitoring and writable fan control are different capabilities, and hardware or firmware may expose read-only telemetry.
Do not bypass the safety state. Check diagnostics for the reported anomaly or integrity failure. If integrity monitoring detected a modified critical file, use a trusted repair or reinstall path instead of manually regenerating credentials or replacing files with unverified copies.
The main components use C++/CMake for the native engine, Go for the bridge, and Flutter/Dart for the GUI. Repository build and CI workflows are authoritative for exact commands and supported environments.
Validation includes C++/CMake/CTest, Go tests, Flutter analysis/tests, platform/package validation, security scanning, and release/package workflows. A successful source build does not prove hardware control works on every device.
Yes. Add support through the appropriate platform/backend layer with detection logic, safe failure behavior, tests where practical, and platform/hardware validation before documenting the capability as supported.
Beta builds are pre-release builds used for validation and feedback. They may change as new validated code reaches the release pipeline.
No. The application has a common cross-platform architecture, but hardware APIs and permissions differ between Windows, Linux, and macOS.
No. Building a package proves that an artifact was produced. Stronger release confidence requires installation, launch, runtime, hardware detection, and where applicable signing and integrity verification.
Include:
- operating system and version
- CPU/GPU/motherboard model where relevant
- HWcontrol2.0 version or commit
- exact reproduction steps
- relevant diagnostics and logs
- whether the issue is reproducible
Never include passwords, bridge credentials, API keys, private certificates, or other secrets in bug reports.
This FAQ distinguishes:
- Implemented — present in the current codebase
- Platform-dependent — depends on OS, driver, firmware, or hardware
- Planned — intended future work
- Unavailable — not currently supported
Repository source, tests, CI results, packaged artifacts, and real hardware validation remain the authoritative evidence for implementation status.