Version: 2.13-beta6 ignores postprocess "sprintf" for temperature.conf

[mushu999]

This has been noted before as "my temperature is always null or zero". However, the actual bug is in the rpi monitor code: it fails to use the sprintf() command properly (or at all) in the temperature.conf file for some reason. Yet it works fine in the other .conf modules. not sure why but author needs to check this out.

Temperature won't work if you use: dynamic.99.postprocess=sprintf("%.1f",$1/1000) but works fine with: dynamic.99.postprocess=$1/1000

[Leepic]

Duplicate of #250

[hdecoded]

Facing the same issue. but with just $1/1000 sometimes the temperature is 5 digits with the period and it overlaps on the bar

[dineiar]

@hdecoded, please check my comment with a solution to this problem:

Using dynamic.1.postprocess=$1/1000 according to @licaon-kter's suggestion causes the temperature to display three-digit numbers and sometimes overflow the gauge area (see this example).

To fix this, I changed the web to show only two digits. I.e. change from:

web.status.1.content.1.line.1=JustGageBar("CPU Temperature", data.soc_temp+"°C", 40, data.soc_temp, 80, 100, 80)

to:

web.status.1.content.1.line.1=JustGageBar("CPU Temperature", data.soc_temp+"°C", 40, data.soc_temp.toFixed(2), 80, 100, 80)

I added .toFixed(2) in the number displayed in the center of the gauge.

[DaDeedz]

Bumping this thread, as no suggested solution seemed to work for me. Solution is most likely not as elegant as could be, but it gets the job done on my end.

In postprocess, I divide by 100 because I only want 1 digit after the value. This float value I pass through int() function, which removes any decimals. Then I divide by 10 to get down to the appropriate units.

dynamic.1.name=soc_temp dynamic.1.source=/sys/devices/virtual/thermal/thermal_zone0/temp dynamic.1.regexp=(.*) dynamic.1.postprocess=int($1/100)/10 dynamic.1.rrd=GAUGE