Parse outpout of 'sensors --label-map' to customize labels

[remiberthoz]

This draft PR assumes merging of another PR over at lm-sensors: lm-sensors/lm-sensors#577. The change is functional with my fork of lm-sensors: https://github.com/remiberthoz/lm-sensors/tree/reflection also it would need path adjustments for the fork on line 356 and 357.

It makes configuration of labels for temperature, fan, PWM and voltage sensors adjustable via /etc/sensors.conf, /etc/sensors3.conf or /etc/sensors.d/. It also masks sensors that are ignored by this configuration files.

[corecoding]

Launching a subprocess is very risky. It's why I was so slow to adopt GPU stats. It is so easy to cause system stutter. I think the right course of action here is to add /etc/sensors3.conf parsing directly into Vitals. We actually talk about it in issue #83. Hoping that Vitals has permission to read this file with no special permissions.

This would be a one time load of the file and stored in memory. I know that this file supports other things like thresholds and conversions, but for now labels would be nice. The goal is to keep the changes as minimal as possible. Please note that I've pushed some changes to both develop and main that you'll want to use.

[remiberthoz]

Thank you for the feedback. I agree that issuing a subprocess command is not great. It's possible to do asynchronously, that would be better. I'll follow your lead anyway.

I have tested parsing of /etc/sensors3.conf, for labels only it's straightforward. My problem is that I don't know how to link a "chip" from that configuration file to a "device" in the hwmon sysfs tree.

I will take care of merging your commits to my branch. Thanks again.

[corecoding]

I created a branch called feature/sensors3 - unfortunately I don't have a machine with matching chipsets to try it out. Can you check it out?

[remiberthoz]

Yes! I currently have issues with the version of your latest commits (ad47fdd): most entries report "No Data", but voltages labels are correctly reported alongside chip names:

I will attempt to identify the origin of the problem for other sensors and report here.

[remiberthoz]

My bad. I forgot to recompile the updated schemas. I get correct readings for some but not all chips.

This snippet of configuration is parsed and reported:

chip "nct6798-*"
label temp1 "Motherboard" # SYSTIN
label temp2 "CPU Socket" # CPUTIN ; responds to cpu stress
label temp8 "CPU via PECI" # PECI Agent 0 ; mirrors CPU
label temp9 "CPU via PECI (cal)" # PECI Agent 0 ; mirrors CPU ; calibration signal (not sure of meaning)
label temp3 "VRM" # AUXTIN0 ; responds to cpu stress
label temp6 "Chipset" # AUXTIN3
ignore temp4 # AUXTIN1 ; always reports +4°C
ignore temp5 # AUXTIN2 ; always reports +127°C
ignore temp7 # AUXTIN4 ; mostly reports +127°C
ignore temp10 # PCH_CHIP_CPU_MAX_TEMP ; always reports 0°C
ignore temp11 # PCH_CHIP_TEMP ; always reports 0°C
ignore temp12 # PCH_CPU_TEMP ; always reports 0°C

But this one is not:

chip "nvme-pci-0200"
ignore temp1 # virtual anyway
set temp1_max 70
label temp2 "NVME SSD NAND memory cells"
set temp2_max 75
label temp3 "NVME SSD ASIC controller"
set temp3_max 65
bus "i2c-3" "SMBus I801 adapter at 0000:00:1f.4"
chip "spd5118-i2c-3-51"
label temp1 "RAM stick A2"
chip "spd5118-i2c-3-53"
label temp1 "RAM stick B2"

I suspect the bus specifications are the cause, I will investigate.

[remiberthoz]

Well yes, the issue is due to the explicit chip "spd5118-i2c-3-51"/chip "spd5118-i2c-3-53" in my configuration. With the bus specified, chipPatternMatches will test the unspecific value spd5118-*-* against the specific pattern ^spd5118-i2c-3-51$ and they will not match.

---

I can unspecify the buses in the configuration by setting:

chip "spd5118-*"
label temp1 "RAM stick"

and I then get reports of RAM stick and RAM stick 2 with Vitals; but I loose mapping to the motherboard socket labels.

---

Releasing constraints on the mapping performed by chipPatternMatches (i.e. stripping bus specifications on the chip name patterns spd5118-i2c-3-51 => spd5118-*-* by using an advanced version of

if (!block.patterns.some(p => chipPatternMatches(p.split("-")[0], chipName))) {
^^^^^^^^^^^^^

on line 142) leads to a similar result, while allowing users to preserve details in their configuration.

The issue would only really appear when very different sensors share a same name: I don't really mind two RAM sticks being indistinguishable, but problems appear if that was two GPUs, two NVMes, or even devices of different kinds.

[remiberthoz]

This draft PR assumes merging of another PR over at lm-sensors: lm-sensors/lm-sensors#577. The change is functional with my fork of lm-sensors: https://github.com/remiberthoz/lm-sensors/tree/reflection also it would need path adjustments for the fork on line 356 and 357.

It makes configuration of labels for temperature, fan, PWM and voltage sensors adjustable via /etc/sensors.conf, /etc/sensors3.conf or /etc/sensors.d/. It also masks sensors that are ignored by this configuration files.

[corecoding]

Launching a subprocess is very risky. It's why I was so slow to adopt GPU stats. It is so easy to cause system stutter. I think the right course of action here is to add /etc/sensors3.conf parsing directly into Vitals. We actually talk about it in issue #83. Hoping that Vitals has permission to read this file with no special permissions.

This would be a one time load of the file and stored in memory. I know that this file supports other things like thresholds and conversions, but for now labels would be nice. The goal is to keep the changes as minimal as possible. Please note that I've pushed some changes to both develop and main that you'll want to use.

[remiberthoz]

Thank you for the feedback. I agree that issuing a subprocess command is not great. It's possible to do asynchronously, that would be better. I'll follow your lead anyway.

I have tested parsing of /etc/sensors3.conf, for labels only it's straightforward. My problem is that I don't know how to link a "chip" from that configuration file to a "device" in the hwmon sysfs tree.

I will take care of merging your commits to my branch. Thanks again.

[corecoding]

I created a branch called feature/sensors3 - unfortunately I don't have a machine with matching chipsets to try it out. Can you check it out?

[remiberthoz]

Yes! I currently have issues with the version of your latest commits (ad47fdd): most entries report "No Data", but voltages labels are correctly reported alongside chip names:

I will attempt to identify the origin of the problem for other sensors and report here.

[remiberthoz]

My bad. I forgot to recompile the updated schemas. I get correct readings for some but not all chips.

This snippet of configuration is parsed and reported:

chip "nct6798-*"
label temp1 "Motherboard" # SYSTIN
label temp2 "CPU Socket" # CPUTIN ; responds to cpu stress
label temp8 "CPU via PECI" # PECI Agent 0 ; mirrors CPU
label temp9 "CPU via PECI (cal)" # PECI Agent 0 ; mirrors CPU ; calibration signal (not sure of meaning)
label temp3 "VRM" # AUXTIN0 ; responds to cpu stress
label temp6 "Chipset" # AUXTIN3
ignore temp4 # AUXTIN1 ; always reports +4°C
ignore temp5 # AUXTIN2 ; always reports +127°C
ignore temp7 # AUXTIN4 ; mostly reports +127°C
ignore temp10 # PCH_CHIP_CPU_MAX_TEMP ; always reports 0°C
ignore temp11 # PCH_CHIP_TEMP ; always reports 0°C
ignore temp12 # PCH_CPU_TEMP ; always reports 0°C

But this one is not:

chip "nvme-pci-0200"
ignore temp1 # virtual anyway
set temp1_max 70
label temp2 "NVME SSD NAND memory cells"
set temp2_max 75
label temp3 "NVME SSD ASIC controller"
set temp3_max 65
bus "i2c-3" "SMBus I801 adapter at 0000:00:1f.4"
chip "spd5118-i2c-3-51"
label temp1 "RAM stick A2"
chip "spd5118-i2c-3-53"
label temp1 "RAM stick B2"

I suspect the bus specifications are the cause, I will investigate.

[remiberthoz]

Well yes, the issue is due to the explicit chip "spd5118-i2c-3-51"/chip "spd5118-i2c-3-53" in my configuration. With the bus specified, chipPatternMatches will test the unspecific value spd5118-*-* against the specific pattern ^spd5118-i2c-3-51$ and they will not match.

---

I can unspecify the buses in the configuration by setting:

chip "spd5118-*"
label temp1 "RAM stick"

and I then get reports of RAM stick and RAM stick 2 with Vitals; but I loose mapping to the motherboard socket labels.

---

Releasing constraints on the mapping performed by chipPatternMatches (i.e. stripping bus specifications on the chip name patterns spd5118-i2c-3-51 => spd5118-*-* by using an advanced version of

if (!block.patterns.some(p => chipPatternMatches(p.split("-")[0], chipName))) {
^^^^^^^^^^^^^

on line 142) leads to a similar result, while allowing users to preserve details in their configuration.

The issue would only really appear when very different sensors share a same name: I don't really mind two RAM sticks being indistinguishable, but problems appear if that was two GPUs, two NVMes, or even devices of different kinds.

[remiberthoz]

This draft PR assumes merging of another PR over at lm-sensors: lm-sensors/lm-sensors#577. The change is functional with my fork of lm-sensors: https://github.com/remiberthoz/lm-sensors/tree/reflection also it would need path adjustments for the fork on line 356 and 357.

It makes configuration of labels for temperature, fan, PWM and voltage sensors adjustable via /etc/sensors.conf, /etc/sensors3.conf or /etc/sensors.d/. It also masks sensors that are ignored by this configuration files.

[corecoding]

Launching a subprocess is very risky. It's why I was so slow to adopt GPU stats. It is so easy to cause system stutter. I think the right course of action here is to add /etc/sensors3.conf parsing directly into Vitals. We actually talk about it in issue #83. Hoping that Vitals has permission to read this file with no special permissions.

This would be a one time load of the file and stored in memory. I know that this file supports other things like thresholds and conversions, but for now labels would be nice. The goal is to keep the changes as minimal as possible. Please note that I've pushed some changes to both develop and main that you'll want to use.

[remiberthoz]

Thank you for the feedback. I agree that issuing a subprocess command is not great. It's possible to do asynchronously, that would be better. I'll follow your lead anyway.

I have tested parsing of /etc/sensors3.conf, for labels only it's straightforward. My problem is that I don't know how to link a "chip" from that configuration file to a "device" in the hwmon sysfs tree.

I will take care of merging your commits to my branch. Thanks again.

[corecoding]

I created a branch called feature/sensors3 - unfortunately I don't have a machine with matching chipsets to try it out. Can you check it out?

[remiberthoz]

Yes! I currently have issues with the version of your latest commits (ad47fdd): most entries report "No Data", but voltages labels are correctly reported alongside chip names:

I will attempt to identify the origin of the problem for other sensors and report here.

[remiberthoz]

My bad. I forgot to recompile the updated schemas. I get correct readings for some but not all chips.

This snippet of configuration is parsed and reported:

chip "nct6798-*"
label temp1 "Motherboard" # SYSTIN
label temp2 "CPU Socket" # CPUTIN ; responds to cpu stress
label temp8 "CPU via PECI" # PECI Agent 0 ; mirrors CPU
label temp9 "CPU via PECI (cal)" # PECI Agent 0 ; mirrors CPU ; calibration signal (not sure of meaning)
label temp3 "VRM" # AUXTIN0 ; responds to cpu stress
label temp6 "Chipset" # AUXTIN3
ignore temp4 # AUXTIN1 ; always reports +4°C
ignore temp5 # AUXTIN2 ; always reports +127°C
ignore temp7 # AUXTIN4 ; mostly reports +127°C
ignore temp10 # PCH_CHIP_CPU_MAX_TEMP ; always reports 0°C
ignore temp11 # PCH_CHIP_TEMP ; always reports 0°C
ignore temp12 # PCH_CPU_TEMP ; always reports 0°C

But this one is not:

chip "nvme-pci-0200"
ignore temp1 # virtual anyway
set temp1_max 70
label temp2 "NVME SSD NAND memory cells"
set temp2_max 75
label temp3 "NVME SSD ASIC controller"
set temp3_max 65
bus "i2c-3" "SMBus I801 adapter at 0000:00:1f.4"
chip "spd5118-i2c-3-51"
label temp1 "RAM stick A2"
chip "spd5118-i2c-3-53"
label temp1 "RAM stick B2"

I suspect the bus specifications are the cause, I will investigate.

[remiberthoz]

Well yes, the issue is due to the explicit chip "spd5118-i2c-3-51"/chip "spd5118-i2c-3-53" in my configuration. With the bus specified, chipPatternMatches will test the unspecific value spd5118-*-* against the specific pattern ^spd5118-i2c-3-51$ and they will not match.

---

I can unspecify the buses in the configuration by setting:

chip "spd5118-*"
label temp1 "RAM stick"

and I then get reports of RAM stick and RAM stick 2 with Vitals; but I loose mapping to the motherboard socket labels.

---

Releasing constraints on the mapping performed by chipPatternMatches (i.e. stripping bus specifications on the chip name patterns spd5118-i2c-3-51 => spd5118-*-* by using an advanced version of

if (!block.patterns.some(p => chipPatternMatches(p.split("-")[0], chipName))) {
^^^^^^^^^^^^^

on line 142) leads to a similar result, while allowing users to preserve details in their configuration.

The issue would only really appear when very different sensors share a same name: I don't really mind two RAM sticks being indistinguishable, but problems appear if that was two GPUs, two NVMes, or even devices of different kinds.

[remiberthoz]

This draft PR assumes merging of another PR over at lm-sensors: lm-sensors/lm-sensors#577. The change is functional with my fork of lm-sensors: https://github.com/remiberthoz/lm-sensors/tree/reflection also it would need path adjustments for the fork on line 356 and 357.

It makes configuration of labels for temperature, fan, PWM and voltage sensors adjustable via /etc/sensors.conf, /etc/sensors3.conf or /etc/sensors.d/. It also masks sensors that are ignored by this configuration files.

[corecoding]

Launching a subprocess is very risky. It's why I was so slow to adopt GPU stats. It is so easy to cause system stutter. I think the right course of action here is to add /etc/sensors3.conf parsing directly into Vitals. We actually talk about it in issue #83. Hoping that Vitals has permission to read this file with no special permissions.

This would be a one time load of the file and stored in memory. I know that this file supports other things like thresholds and conversions, but for now labels would be nice. The goal is to keep the changes as minimal as possible. Please note that I've pushed some changes to both develop and main that you'll want to use.

[remiberthoz]

Thank you for the feedback. I agree that issuing a subprocess command is not great. It's possible to do asynchronously, that would be better. I'll follow your lead anyway.

I have tested parsing of /etc/sensors3.conf, for labels only it's straightforward. My problem is that I don't know how to link a "chip" from that configuration file to a "device" in the hwmon sysfs tree.

I will take care of merging your commits to my branch. Thanks again.

[corecoding]

I created a branch called feature/sensors3 - unfortunately I don't have a machine with matching chipsets to try it out. Can you check it out?

[remiberthoz]

Yes! I currently have issues with the version of your latest commits (ad47fdd): most entries report "No Data", but voltages labels are correctly reported alongside chip names:

I will attempt to identify the origin of the problem for other sensors and report here.

[remiberthoz]

My bad. I forgot to recompile the updated schemas. I get correct readings for some but not all chips.

This snippet of configuration is parsed and reported:

chip "nct6798-*"
label temp1 "Motherboard" # SYSTIN
label temp2 "CPU Socket" # CPUTIN ; responds to cpu stress
label temp8 "CPU via PECI" # PECI Agent 0 ; mirrors CPU
label temp9 "CPU via PECI (cal)" # PECI Agent 0 ; mirrors CPU ; calibration signal (not sure of meaning)
label temp3 "VRM" # AUXTIN0 ; responds to cpu stress
label temp6 "Chipset" # AUXTIN3
ignore temp4 # AUXTIN1 ; always reports +4°C
ignore temp5 # AUXTIN2 ; always reports +127°C
ignore temp7 # AUXTIN4 ; mostly reports +127°C
ignore temp10 # PCH_CHIP_CPU_MAX_TEMP ; always reports 0°C
ignore temp11 # PCH_CHIP_TEMP ; always reports 0°C
ignore temp12 # PCH_CPU_TEMP ; always reports 0°C

But this one is not:

chip "nvme-pci-0200"
ignore temp1 # virtual anyway
set temp1_max 70
label temp2 "NVME SSD NAND memory cells"
set temp2_max 75
label temp3 "NVME SSD ASIC controller"
set temp3_max 65
bus "i2c-3" "SMBus I801 adapter at 0000:00:1f.4"
chip "spd5118-i2c-3-51"
label temp1 "RAM stick A2"
chip "spd5118-i2c-3-53"
label temp1 "RAM stick B2"

I suspect the bus specifications are the cause, I will investigate.

[remiberthoz]

Well yes, the issue is due to the explicit chip "spd5118-i2c-3-51"/chip "spd5118-i2c-3-53" in my configuration. With the bus specified, chipPatternMatches will test the unspecific value spd5118-*-* against the specific pattern ^spd5118-i2c-3-51$ and they will not match.

---

I can unspecify the buses in the configuration by setting:

chip "spd5118-*"
label temp1 "RAM stick"

and I then get reports of RAM stick and RAM stick 2 with Vitals; but I loose mapping to the motherboard socket labels.

---

Releasing constraints on the mapping performed by chipPatternMatches (i.e. stripping bus specifications on the chip name patterns spd5118-i2c-3-51 => spd5118-*-* by using an advanced version of

if (!block.patterns.some(p => chipPatternMatches(p.split("-")[0], chipName))) {
^^^^^^^^^^^^^

on line 142) leads to a similar result, while allowing users to preserve details in their configuration.

The issue would only really appear when very different sensors share a same name: I don't really mind two RAM sticks being indistinguishable, but problems appear if that was two GPUs, two NVMes, or even devices of different kinds.

[remiberthoz]

This draft PR assumes merging of another PR over at lm-sensors: lm-sensors/lm-sensors#577. The change is functional with my fork of lm-sensors: https://github.com/remiberthoz/lm-sensors/tree/reflection also it would need path adjustments for the fork on line 356 and 357.

It makes configuration of labels for temperature, fan, PWM and voltage sensors adjustable via /etc/sensors.conf, /etc/sensors3.conf or /etc/sensors.d/. It also masks sensors that are ignored by this configuration files.

[corecoding]

Launching a subprocess is very risky. It's why I was so slow to adopt GPU stats. It is so easy to cause system stutter. I think the right course of action here is to add /etc/sensors3.conf parsing directly into Vitals. We actually talk about it in issue #83. Hoping that Vitals has permission to read this file with no special permissions.

This would be a one time load of the file and stored in memory. I know that this file supports other things like thresholds and conversions, but for now labels would be nice. The goal is to keep the changes as minimal as possible. Please note that I've pushed some changes to both develop and main that you'll want to use.

[remiberthoz]

Thank you for the feedback. I agree that issuing a subprocess command is not great. It's possible to do asynchronously, that would be better. I'll follow your lead anyway.

I have tested parsing of /etc/sensors3.conf, for labels only it's straightforward. My problem is that I don't know how to link a "chip" from that configuration file to a "device" in the hwmon sysfs tree.

I will take care of merging your commits to my branch. Thanks again.

[corecoding]

I created a branch called feature/sensors3 - unfortunately I don't have a machine with matching chipsets to try it out. Can you check it out?

[remiberthoz]

Yes! I currently have issues with the version of your latest commits (ad47fdd): most entries report "No Data", but voltages labels are correctly reported alongside chip names:

I will attempt to identify the origin of the problem for other sensors and report here.

[remiberthoz]

My bad. I forgot to recompile the updated schemas. I get correct readings for some but not all chips.

This snippet of configuration is parsed and reported:

chip "nct6798-*"
label temp1 "Motherboard" # SYSTIN
label temp2 "CPU Socket" # CPUTIN ; responds to cpu stress
label temp8 "CPU via PECI" # PECI Agent 0 ; mirrors CPU
label temp9 "CPU via PECI (cal)" # PECI Agent 0 ; mirrors CPU ; calibration signal (not sure of meaning)
label temp3 "VRM" # AUXTIN0 ; responds to cpu stress
label temp6 "Chipset" # AUXTIN3
ignore temp4 # AUXTIN1 ; always reports +4°C
ignore temp5 # AUXTIN2 ; always reports +127°C
ignore temp7 # AUXTIN4 ; mostly reports +127°C
ignore temp10 # PCH_CHIP_CPU_MAX_TEMP ; always reports 0°C
ignore temp11 # PCH_CHIP_TEMP ; always reports 0°C
ignore temp12 # PCH_CPU_TEMP ; always reports 0°C

But this one is not:

chip "nvme-pci-0200"
ignore temp1 # virtual anyway
set temp1_max 70
label temp2 "NVME SSD NAND memory cells"
set temp2_max 75
label temp3 "NVME SSD ASIC controller"
set temp3_max 65
bus "i2c-3" "SMBus I801 adapter at 0000:00:1f.4"
chip "spd5118-i2c-3-51"
label temp1 "RAM stick A2"
chip "spd5118-i2c-3-53"
label temp1 "RAM stick B2"

I suspect the bus specifications are the cause, I will investigate.

[remiberthoz]

Well yes, the issue is due to the explicit chip "spd5118-i2c-3-51"/chip "spd5118-i2c-3-53" in my configuration. With the bus specified, chipPatternMatches will test the unspecific value spd5118-*-* against the specific pattern ^spd5118-i2c-3-51$ and they will not match.

---

I can unspecify the buses in the configuration by setting:

chip "spd5118-*"
label temp1 "RAM stick"

and I then get reports of RAM stick and RAM stick 2 with Vitals; but I loose mapping to the motherboard socket labels.

---

Releasing constraints on the mapping performed by chipPatternMatches (i.e. stripping bus specifications on the chip name patterns spd5118-i2c-3-51 => spd5118-*-* by using an advanced version of

if (!block.patterns.some(p => chipPatternMatches(p.split("-")[0], chipName))) {
^^^^^^^^^^^^^

on line 142) leads to a similar result, while allowing users to preserve details in their configuration.

The issue would only really appear when very different sensors share a same name: I don't really mind two RAM sticks being indistinguishable, but problems appear if that was two GPUs, two NVMes, or even devices of different kinds.

[remiberthoz]

This draft PR assumes merging of another PR over at lm-sensors: lm-sensors/lm-sensors#577. The change is functional with my fork of lm-sensors: https://github.com/remiberthoz/lm-sensors/tree/reflection also it would need path adjustments for the fork on line 356 and 357.

It makes configuration of labels for temperature, fan, PWM and voltage sensors adjustable via /etc/sensors.conf, /etc/sensors3.conf or /etc/sensors.d/. It also masks sensors that are ignored by this configuration files.

[corecoding]

Launching a subprocess is very risky. It's why I was so slow to adopt GPU stats. It is so easy to cause system stutter. I think the right course of action here is to add /etc/sensors3.conf parsing directly into Vitals. We actually talk about it in issue #83. Hoping that Vitals has permission to read this file with no special permissions.

This would be a one time load of the file and stored in memory. I know that this file supports other things like thresholds and conversions, but for now labels would be nice. The goal is to keep the changes as minimal as possible. Please note that I've pushed some changes to both develop and main that you'll want to use.

[remiberthoz]

Thank you for the feedback. I agree that issuing a subprocess command is not great. It's possible to do asynchronously, that would be better. I'll follow your lead anyway.

I have tested parsing of /etc/sensors3.conf, for labels only it's straightforward. My problem is that I don't know how to link a "chip" from that configuration file to a "device" in the hwmon sysfs tree.

I will take care of merging your commits to my branch. Thanks again.

[corecoding]

I created a branch called feature/sensors3 - unfortunately I don't have a machine with matching chipsets to try it out. Can you check it out?

[remiberthoz]

Yes! I currently have issues with the version of your latest commits (ad47fdd): most entries report "No Data", but voltages labels are correctly reported alongside chip names:

I will attempt to identify the origin of the problem for other sensors and report here.

[remiberthoz]

My bad. I forgot to recompile the updated schemas. I get correct readings for some but not all chips.

This snippet of configuration is parsed and reported:

chip "nct6798-*"
label temp1 "Motherboard" # SYSTIN
label temp2 "CPU Socket" # CPUTIN ; responds to cpu stress
label temp8 "CPU via PECI" # PECI Agent 0 ; mirrors CPU
label temp9 "CPU via PECI (cal)" # PECI Agent 0 ; mirrors CPU ; calibration signal (not sure of meaning)
label temp3 "VRM" # AUXTIN0 ; responds to cpu stress
label temp6 "Chipset" # AUXTIN3
ignore temp4 # AUXTIN1 ; always reports +4°C
ignore temp5 # AUXTIN2 ; always reports +127°C
ignore temp7 # AUXTIN4 ; mostly reports +127°C
ignore temp10 # PCH_CHIP_CPU_MAX_TEMP ; always reports 0°C
ignore temp11 # PCH_CHIP_TEMP ; always reports 0°C
ignore temp12 # PCH_CPU_TEMP ; always reports 0°C

But this one is not:

chip "nvme-pci-0200"
ignore temp1 # virtual anyway
set temp1_max 70
label temp2 "NVME SSD NAND memory cells"
set temp2_max 75
label temp3 "NVME SSD ASIC controller"
set temp3_max 65
bus "i2c-3" "SMBus I801 adapter at 0000:00:1f.4"
chip "spd5118-i2c-3-51"
label temp1 "RAM stick A2"
chip "spd5118-i2c-3-53"
label temp1 "RAM stick B2"

I suspect the bus specifications are the cause, I will investigate.

[remiberthoz]

Well yes, the issue is due to the explicit chip "spd5118-i2c-3-51"/chip "spd5118-i2c-3-53" in my configuration. With the bus specified, chipPatternMatches will test the unspecific value spd5118-*-* against the specific pattern ^spd5118-i2c-3-51$ and they will not match.

---

I can unspecify the buses in the configuration by setting:

chip "spd5118-*"
label temp1 "RAM stick"

and I then get reports of RAM stick and RAM stick 2 with Vitals; but I loose mapping to the motherboard socket labels.

---

Releasing constraints on the mapping performed by chipPatternMatches (i.e. stripping bus specifications on the chip name patterns spd5118-i2c-3-51 => spd5118-*-* by using an advanced version of

if (!block.patterns.some(p => chipPatternMatches(p.split("-")[0], chipName))) {
^^^^^^^^^^^^^

on line 142) leads to a similar result, while allowing users to preserve details in their configuration.

The issue would only really appear when very different sensors share a same name: I don't really mind two RAM sticks being indistinguishable, but problems appear if that was two GPUs, two NVMes, or even devices of different kinds.

[remiberthoz]

This draft PR assumes merging of another PR over at lm-sensors: lm-sensors/lm-sensors#577. The change is functional with my fork of lm-sensors: https://github.com/remiberthoz/lm-sensors/tree/reflection also it would need path adjustments for the fork on line 356 and 357.

It makes configuration of labels for temperature, fan, PWM and voltage sensors adjustable via /etc/sensors.conf, /etc/sensors3.conf or /etc/sensors.d/. It also masks sensors that are ignored by this configuration files.

[corecoding]

Launching a subprocess is very risky. It's why I was so slow to adopt GPU stats. It is so easy to cause system stutter. I think the right course of action here is to add /etc/sensors3.conf parsing directly into Vitals. We actually talk about it in issue #83. Hoping that Vitals has permission to read this file with no special permissions.

This would be a one time load of the file and stored in memory. I know that this file supports other things like thresholds and conversions, but for now labels would be nice. The goal is to keep the changes as minimal as possible. Please note that I've pushed some changes to both develop and main that you'll want to use.

[remiberthoz]

Thank you for the feedback. I agree that issuing a subprocess command is not great. It's possible to do asynchronously, that would be better. I'll follow your lead anyway.

I have tested parsing of /etc/sensors3.conf, for labels only it's straightforward. My problem is that I don't know how to link a "chip" from that configuration file to a "device" in the hwmon sysfs tree.

I will take care of merging your commits to my branch. Thanks again.

[corecoding]

I created a branch called feature/sensors3 - unfortunately I don't have a machine with matching chipsets to try it out. Can you check it out?

[remiberthoz]

Yes! I currently have issues with the version of your latest commits (ad47fdd): most entries report "No Data", but voltages labels are correctly reported alongside chip names:

I will attempt to identify the origin of the problem for other sensors and report here.

[remiberthoz]

My bad. I forgot to recompile the updated schemas. I get correct readings for some but not all chips.

This snippet of configuration is parsed and reported:

chip "nct6798-*"
label temp1 "Motherboard" # SYSTIN
label temp2 "CPU Socket" # CPUTIN ; responds to cpu stress
label temp8 "CPU via PECI" # PECI Agent 0 ; mirrors CPU
label temp9 "CPU via PECI (cal)" # PECI Agent 0 ; mirrors CPU ; calibration signal (not sure of meaning)
label temp3 "VRM" # AUXTIN0 ; responds to cpu stress
label temp6 "Chipset" # AUXTIN3
ignore temp4 # AUXTIN1 ; always reports +4°C
ignore temp5 # AUXTIN2 ; always reports +127°C
ignore temp7 # AUXTIN4 ; mostly reports +127°C
ignore temp10 # PCH_CHIP_CPU_MAX_TEMP ; always reports 0°C
ignore temp11 # PCH_CHIP_TEMP ; always reports 0°C
ignore temp12 # PCH_CPU_TEMP ; always reports 0°C

But this one is not:

chip "nvme-pci-0200"
ignore temp1 # virtual anyway
set temp1_max 70
label temp2 "NVME SSD NAND memory cells"
set temp2_max 75
label temp3 "NVME SSD ASIC controller"
set temp3_max 65
bus "i2c-3" "SMBus I801 adapter at 0000:00:1f.4"
chip "spd5118-i2c-3-51"
label temp1 "RAM stick A2"
chip "spd5118-i2c-3-53"
label temp1 "RAM stick B2"

I suspect the bus specifications are the cause, I will investigate.

[remiberthoz]

Well yes, the issue is due to the explicit chip "spd5118-i2c-3-51"/chip "spd5118-i2c-3-53" in my configuration. With the bus specified, chipPatternMatches will test the unspecific value spd5118-*-* against the specific pattern ^spd5118-i2c-3-51$ and they will not match.

---

I can unspecify the buses in the configuration by setting:

chip "spd5118-*"
label temp1 "RAM stick"

and I then get reports of RAM stick and RAM stick 2 with Vitals; but I loose mapping to the motherboard socket labels.

---

Releasing constraints on the mapping performed by chipPatternMatches (i.e. stripping bus specifications on the chip name patterns spd5118-i2c-3-51 => spd5118-*-* by using an advanced version of

if (!block.patterns.some(p => chipPatternMatches(p.split("-")[0], chipName))) {
^^^^^^^^^^^^^

on line 142) leads to a similar result, while allowing users to preserve details in their configuration.

The issue would only really appear when very different sensors share a same name: I don't really mind two RAM sticks being indistinguishable, but problems appear if that was two GPUs, two NVMes, or even devices of different kinds.

[remiberthoz]

This draft PR assumes merging of another PR over at lm-sensors: lm-sensors/lm-sensors#577. The change is functional with my fork of lm-sensors: https://github.com/remiberthoz/lm-sensors/tree/reflection also it would need path adjustments for the fork on line 356 and 357.

It makes configuration of labels for temperature, fan, PWM and voltage sensors adjustable via /etc/sensors.conf, /etc/sensors3.conf or /etc/sensors.d/. It also masks sensors that are ignored by this configuration files.

[corecoding]

Launching a subprocess is very risky. It's why I was so slow to adopt GPU stats. It is so easy to cause system stutter. I think the right course of action here is to add /etc/sensors3.conf parsing directly into Vitals. We actually talk about it in issue #83. Hoping that Vitals has permission to read this file with no special permissions.

This would be a one time load of the file and stored in memory. I know that this file supports other things like thresholds and conversions, but for now labels would be nice. The goal is to keep the changes as minimal as possible. Please note that I've pushed some changes to both develop and main that you'll want to use.

[remiberthoz]

Thank you for the feedback. I agree that issuing a subprocess command is not great. It's possible to do asynchronously, that would be better. I'll follow your lead anyway.

I have tested parsing of /etc/sensors3.conf, for labels only it's straightforward. My problem is that I don't know how to link a "chip" from that configuration file to a "device" in the hwmon sysfs tree.

I will take care of merging your commits to my branch. Thanks again.

[corecoding]

I created a branch called feature/sensors3 - unfortunately I don't have a machine with matching chipsets to try it out. Can you check it out?

[remiberthoz]

Yes! I currently have issues with the version of your latest commits (ad47fdd): most entries report "No Data", but voltages labels are correctly reported alongside chip names:

I will attempt to identify the origin of the problem for other sensors and report here.

[remiberthoz]

My bad. I forgot to recompile the updated schemas. I get correct readings for some but not all chips.

This snippet of configuration is parsed and reported:

chip "nct6798-*"
label temp1 "Motherboard" # SYSTIN
label temp2 "CPU Socket" # CPUTIN ; responds to cpu stress
label temp8 "CPU via PECI" # PECI Agent 0 ; mirrors CPU
label temp9 "CPU via PECI (cal)" # PECI Agent 0 ; mirrors CPU ; calibration signal (not sure of meaning)
label temp3 "VRM" # AUXTIN0 ; responds to cpu stress
label temp6 "Chipset" # AUXTIN3
ignore temp4 # AUXTIN1 ; always reports +4°C
ignore temp5 # AUXTIN2 ; always reports +127°C
ignore temp7 # AUXTIN4 ; mostly reports +127°C
ignore temp10 # PCH_CHIP_CPU_MAX_TEMP ; always reports 0°C
ignore temp11 # PCH_CHIP_TEMP ; always reports 0°C
ignore temp12 # PCH_CPU_TEMP ; always reports 0°C

But this one is not:

chip "nvme-pci-0200"
ignore temp1 # virtual anyway
set temp1_max 70
label temp2 "NVME SSD NAND memory cells"
set temp2_max 75
label temp3 "NVME SSD ASIC controller"
set temp3_max 65
bus "i2c-3" "SMBus I801 adapter at 0000:00:1f.4"
chip "spd5118-i2c-3-51"
label temp1 "RAM stick A2"
chip "spd5118-i2c-3-53"
label temp1 "RAM stick B2"

I suspect the bus specifications are the cause, I will investigate.

[remiberthoz]

Well yes, the issue is due to the explicit chip "spd5118-i2c-3-51"/chip "spd5118-i2c-3-53" in my configuration. With the bus specified, chipPatternMatches will test the unspecific value spd5118-*-* against the specific pattern ^spd5118-i2c-3-51$ and they will not match.

---

I can unspecify the buses in the configuration by setting:

chip "spd5118-*"
label temp1 "RAM stick"

and I then get reports of RAM stick and RAM stick 2 with Vitals; but I loose mapping to the motherboard socket labels.

---

Releasing constraints on the mapping performed by chipPatternMatches (i.e. stripping bus specifications on the chip name patterns spd5118-i2c-3-51 => spd5118-*-* by using an advanced version of

if (!block.patterns.some(p => chipPatternMatches(p.split("-")[0], chipName))) {
^^^^^^^^^^^^^

on line 142) leads to a similar result, while allowing users to preserve details in their configuration.

The issue would only really appear when very different sensors share a same name: I don't really mind two RAM sticks being indistinguishable, but problems appear if that was two GPUs, two NVMes, or even devices of different kinds.