Temp sensor not working after upgrade

Jay_Jarrett · August 23, 2024, 12:42am

I just upgraded from 5 to 6 and it went smooth. I am really liking the new settings and the speed. One little thing that did not change over was the CPU temp. It registered fin in 5 but is not avaialbe in 6. I have pihole install on a baremetal machine running debian 11 and lm-sensors reports the cpu temp as it should. I have dug through all the files trying to find where this gets its info. Can anyone help so I can fix it?

rdwebdesign · August 23, 2024, 12:50am

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

Jay_Jarrett · August 23, 2024, 1:54am

Here you go.

https://tricorder.pi-hole.net/Jrd6pUEb/

yubiuser · August 23, 2024, 8:01am

The info is sourced from /sys/class/hwmon

github.com

pi-hole/FTL/blob/f40d89589bddb53ad9102ca9869d0cbf6796d6ab/src/api/info.c#L354-L368


      
          static int get_hwmon_sensors(struct ftl_conn *api, cJSON *sensors)
          {
          	int ret;
          	// Source available temperatures, we try to read temperature sensors from
          	// different locations. We try to read the sensor label from the label file
          	// and the sensor value from the value file. If the label file does not
          	// exist, we use the value file as label.
          
          	// Hwmon sensors
          	// https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-hwmon
          
          	// Iterate over content of /sys/class/hwmon
          	const char *dirname = "/sys/class/hwmon";
          	DIR *hwmon_dir = opendir(dirname);
          	if(hwmon_dir == NULL)

In v5 we also used /sys/class/thermal/thermal_zone0/temp

github.com

pi-hole/web/blob/be05b0f61d3fcf796dae4cc3f89f8540b2359325/scripts/pi-hole/php/header_authenticated.php#L67-L72


      
          if (file_exists('/sys/class/thermal/thermal_zone0/temp')) {
              $output = rtrim(file_get_contents('/sys/class/thermal/thermal_zone0/temp'));
          } elseif (file_exists('/sys/class/hwmon/hwmon0/temp1_input')) {
              $output = rtrim(file_get_contents('/sys/class/hwmon/hwmon0/temp1_input'));
          } else {
              $output = '';

Pinging @DL6ER if we should re-add the latter.

Jay_Jarrett · August 23, 2024, 11:11am

Makes sense. So if your hardware is not using HWMON it will return null?

DL6ER · August 23, 2024, 4:03pm

There should be nothing in thermal_zone that isn't also in hwmon as it is basically the same kernel interface^[1]. The kernel documentation explicitly states:

The libsensors library offers an interface to the raw sensors data through the sysfs interface. Since lm-sensors 3.0.0, libsensors is completely chip-independent. It assumes that all the kernel drivers implement the standard sysfs interface described in this document.

[...]

Each chip gets its own directory in the sysfs /sys/devices tree. To find all sensor chips, it is easier to follow the device symlinks from /sys/class/hwmon/hwmon*.

We intentionally went away from thermal_zone0 as it sensor was often enough reporting rather low (~ 30°C) temperatures and some random samples revealed them being case or fan sensors. There is nothing anywhere specifying that the first (or, actually, "zeroth") has to be the CPU die sensor so - most often - it was pure luck in previous versions of Pi-hole.

To depend less on "luck", Pi-hole v6.0 has this code, actively trying to infer the most appropriate sensor:

github.com

pi-hole/FTL/blob/f40d89589bddb53ad9102ca9869d0cbf6796d6ab/src/api/info.c#L668-L679


      
          		// 1. AMD CPU temperature sensor
          		// 2. Intel CPU temperature sensor
          		// 3. General CPU temperature sensor
          		// 4. General SoC temperature sensor (https://discourse.pi-hole.net/t/temperature-value-not-shown/66883)
          		if(strcmp(name->valuestring, "k10temp") == 0 ||
          		   strcmp(name->valuestring, "coretemp") == 0 ||
          		   strcmp(name->valuestring, "cpu_thermal") == 0 ||
          		   strcmp(name->valuestring, "soc_thermal") == 0)
          		{
          			cpu_temp_sensor = i;
          			break;
          		}

and I guess we simply need to add another string here. But that's also what the v6 beta is for!

@Jay_Jarrett Please first run

pihole checkout ftl new/list_sensors

and then post the output of

pihole-FTL --sensors

here.

Well, except, of course, if your kernel is built without hwmon support but - even then - it should be available as module. ↩︎

Jay_Jarrett · August 23, 2024, 5:02pm

Got a bit of an error. "Requested option "new/list_sensors" is not available
". Also I noticed the other metrics were wrong as well. The CPU is only reading 50% of what it should be. This is actually running on a unifi cloudkey gen2 with all the unifi stripped out. I am running a script that takes the cpu usage, memory load and temp from lm-sensors and displaying it on the front lcd. Thats how I discovered the CPU load was wrong in pihole. Thanks for the help.

PromoFaux · August 23, 2024, 5:09pm

Whoops! The command is missing a word. Try:

pihole checkout ftl new/list_sensors

Jay_Jarrett · August 23, 2024, 10:47pm

The update installed just fine, but I am still not getting the temp reading. The Memory and the CPU are correct now. I did notice that my CPU reading is not in the standard place. The correct path for this cloudkey is /sys/class/thermal/thermal_zone18/temp. and it spits out a 4 digit number that has to be parsed to celsius.

This is the code that I use to read and adjust to human readable text.
RAW_TEMP=$(cat /sys/class/thermal/thermal_zone18/temp)
CPUTEMP=$(echo "scale=1; $RAW_TEMP / 1000" | bc)°C

DL6ER · August 24, 2024, 5:40am

Can you paste the output of the command?

Jay_Jarrett · August 24, 2024, 9:15pm

root@PiHole:~# pihole-FTL --sensors
{
"list": ,
"cpu_temp": null,
"hot_limit": 0,
"unit": "C"
}

This is just the command sensors

root@PiHole:~# sensors
xo_therm-virtual-0
Adapter: Virtual device
temp1: +0.0°C

xo_therm_buf-virtual-0
Adapter: Virtual device
temp1: +0.0°C

tsens_tz_sensor0-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor1-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor2-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor3-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor4-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor5-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor6-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor7-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor8-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor9-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor10-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor11-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor12-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor13-virtual-0
Adapter: Virtual device
temp1: +0.4°C

tsens_tz_sensor14-virtual-0
Adapter: Virtual device
temp1: +0.3°C

tsens_tz_sensor15-virtual-0
Adapter: Virtual device
temp1: +0.3°C

pm8953_tz-virtual-0
Adapter: Virtual device
temp1: +35.4°C (crit = +145.0°C)

battery-virtual-0
Adapter: Virtual device
temp1: +20.0°C

The cpu temp sensor is "pm8953_tz-virtual-0"

Thanks

DL6ER · August 24, 2024, 9:42pm

Yes, this confirms your kernel has been built without hwmon support. This is too bad but I don't think there is much we should do about it.

Yes, sorry, I haven't seen this before.

Sure, we could hack in thermal_zone handling for exactly this case but hwmon is really a default kernel module which actively has to be removed. lm-sensors reads all possible sources but it is an entire library with exactly this purpose. Pi-hole shows the temperature merely because "it always has". The justification for keeping this is ... questionable. Sure, to some extend one can argue that a high temperature will lead to throttling which, in turn, may affect DNS performance at any point - so does overall CPU utilization and memory usage on the system running Pi-hole. This is still not really a top-class justification and too weak IMO to try to make a fit for everyone even on very exotic configurations.

Sorry to say it like that but it's also honest how I'm thinking about it. This is not a "it will not happen", it's more a "I'm not looking at investing my volunteers free time into coding this". But it's also not meant to be "if someone does it we will merge this without questioning the rationale"

Jay_Jarrett · August 26, 2024, 4:29pm

Something happemed last night and all of a sudden its showing again. Go figure. Yall are doing a great job, and I know you cannot make it fit everyone. Just wanted to give some feedback.

DL6ER · August 27, 2024, 1:00pm

This topic was automatically closed after 19 hours. New replies are no longer allowed.