Thank you for your awesome work! 👍
I really appreciate your effort.

I would love to merge the pull request, but on Windows nbfc-probe does not work, because you forgot to initialize the plugin.

Anyway, nbfc-probe fits perfectly into this project and I'm really happy that you managed to fix OpenHardwareMonitorLib for Linux. :)

I'll try to address these issues in the next few days and will update the code accordingly. Thanks!

Hmm… I really don't get how this happend but all-of-a-sudden the OpenHardwareMonitor plugin is not being built for Linux anymore and the kernel's hwmon interface is used to obtain temperature readings.

…

It turns out: OpenHardwareMonitor was used by the CpuTempratureMonitor plug-in. While this plug-in is not added to the release under Linux by default (target ReleaseLinux), I had changed the target to Debug, while working on these patches, to make sure that debugging symbols are created for all files. Since the C (of CpuTemperatureMonitor) comes before the F (of FSTemperatureMonitor) in the alphabet the CPU temperature monitor plug-in (based on OpenHardwareMonitor) was loaded first and used as temperature monitoring plug-in.
Another thing I just noticed is that the FSTemperatureMonitor does not attempt to load the coretemp kernel driver before using its interface (the /sys/class/hwmon/* "files"). When the driver is not loaded through, the temperature value stick to the value of the last successful reading. If the daemon was just started then this value will be 0. Compare this information to my first post and you'll probably too realize what my actual problem was. :-)

Should I just keep the OpenHardwareMonitor patches in this repository? Or should I just add some coretemp driver auto-loading and error handling code to the FSTemperatureMonitor plugin?

Could you explain to me why FSTemperatureMonitor scans to list of available temperature monitors on first startup, then stores them into a configuration file and, for all ages to come, assumes that this information is static? The implementation looks pretty bogus to me…

I created FSTemperatureMonitor to replace CpuTemperatureMonitor on Linux because OpenHardwareMonitorLib's Linux support is (as you mentioned) improvable ;)
It enables the users to define temperature sources themselves. The bogus code just creates an example configuration file.
I didn't (yet) have the time to implement proper auto detection of temperature sensors.

Now that CpuTemperatureMonitor works on Linux (thanks to you :)), I will add it to the ReleaseLinux build configuration instead of FSTemperatureMonitor.

Please keep the OpenHardwareMonitorLib patches in this pull request.
If you want to improve FSTemperatureMonitor, I think it would be better to create a separate pull request for those changes.

I think FSTemperatureMonitor is the way to go actually, directly querying the MSR is not very portable (for different CPU types, remember that Linux does not only run on x86?) and needlessly low-level. hwmon is pretty much the standard interface to query hardware sensor information and supports ARM CPU and many other things neither of us know about.
I can create a separate pull request for those FSTemperatureMonitor related changes, but switching to back to CpuTemperatureMonitor should only be a short-term solution.

I think I fixed everything up with regards to CpuTemperatureMonitor. Please check and merge! Thx!

nbfc-probe ec-dump did not actually work. I fixed it and made some minor improvements to ec-write and ec-read.
Everything else works fine.

Thank you very much for your contribution 👍