SystemInfo Widget CPU Temperature always shows as 0°C

[gpread]

Describe the bug The SystemInfo Widget does not report/display CPU Temperature correctly - it always shows 0°C

Expected behavior A temperature value displayed and which updates in line with what the OS reports, or an error value.

Screenshots

Files (please attach the following Files or screenshots when applicable):

• Octoprint.log

OctoPrint server and Plugins:

• Platform : RockPi4
• OS and version : Armbian 21.08.3 Buster with Linux 5.10.63-rockchip64
• OctoPrint version : 1.7.2
• Python version : 3.7.3
• Dashboard version : 1.19.6

Desktop (please complete the following information):

• OS and version : Windows 10 21H1 (OS Build 19043.1466)
• Browser and version : 97.0.4692.71 (Official Build) (64-bit)

Logs octoprint.log.txt

Additional context I am new to Octoprint Dashboard, so I currently have no idea how/where it gets its information from to present in the widgets. I can appreciate much of it probably comes from Octoprint API (and/or g-code but that's definitely not relevant in this issue) but perhaps not that for SystemInfo Widget (data from system on which Octoprint is running) which is the issue here.

Since I am not running OctoPi nor Octoprint on a standard RPi with Raspbian, its perhaps helpful to provide simple working example for retrieving CPU/SYS temperature in my case. Then perhaps, if nothing else, someone can at least point me in the right direction so I could perhaps make changes myself to ensure the Dashboard SystemInfo Widget gets the appropriate value for display.......

The standard Armbian welcome screen displays text for CPU/System Temperature as an integer °C value. Attached below is a bash script which does that, its an extract of only the relevant parts from the standard full system-info Armbian script (so its simple but still somewhat hardware neutral as there are cases to cover some hardware permutations other than mine). armbian_cputemp.txt

This produces an output which looks like this:

[StefanCohen]

Hi. Dashboard uses psUtil to read the cpu temp. You can see how it does it in the psUtilGetStats method in init.py in the plugin. Different systems report temperatures differently and your rockpi is most likely not covered yet. I would suggest that you fire up python on the device, import psutil and see what psutil.sensors_temperatures(fahrenheit=False) returns. You should then be able to modify your init.py accordingly and possibly contribute a PR so that others may benefit from it. The psutil documentation is available here: https://psutil.readthedocs.io/en/latest/#psutil.sensors_temperatures

[gpread]

Hi. Dashboard uses psUtil to read the cpu temp. You can see how it does it in the psUtilGetStats method in init.py in the plugin. Different systems report temperatures differently and your rockpi is most likely not covered yet. I would suggest that you fire up python on the device, import psutil and see what psutil.sensors_temperatures(fahrenheit=False) returns. You should then be able to modify your init.py accordingly and possibly contribute a PR so that others may benefit from it. The psutil documentation is available here: https://psutil.readthedocs.io/en/latest/#psutil.sensors_temperatures

Thanks, I'll look into it

[gpread]

Hi. Dashboard uses psUtil to read the cpu temp. You can see how it does it in the psUtilGetStats method in init.py in the plugin. Different systems report temperatures differently and your rockpi is most likely not covered yet. I would suggest that you fire up python on the device, import psutil and see what psutil.sensors_temperatures(fahrenheit=False) returns. You should then be able to modify your init.py accordingly and possibly contribute a PR so that others may benefit from it. The psutil documentation is available here: https://psutil.readthedocs.io/en/latest/#psutil.sensors_temperatures

@StefanCohen - Ok, so I did that and even with my limited programming skills I found it easy to get a working python script using psUtil to get the cpu temp. Script and output shown in a putty screen capture below:

So, then I went ahead and modified accordingly the __init__.py installed on my Octoprint. I'm pretty sure the change I have made is good/correct.

However, then I could not get Octoprint to accept it, when the modified version is installed/active Octoprint determines the plugin is incompatible (lightning flash next to name in plugin manager and an asterisk (*) prefix shown by octoprint.plugin.core in the Octoprint log file).

Presumably there is some cksum or other such checking to detect if an installed plugin is trustworthy or something ?

Attached below is a copy of the modified __init__.py, any assistance with getting that to be accepted by Octoprint so I can fully test my change will be much appreciated.

init.py_fixed_CpuTemp.txt

[StefanCohen]

There are afaik no checksums to be evaluated by OP to verify the integrity of a plugin. I think it will be enough to simply restart OP.

[gpread]

I did that in the very first place. I backed up the original (added suffix to filename), made a copy, modified it. Then copied modified script file to __init__.py and restarted Octoprint. Dashboard tab is not there after the restart and clearly Octoprint detects something it does not like, showing its now got "incompatible" status.

I know its not a simple syntax error in the/my python code additions because I did have one initially and in such case Octoprint reports it as such in its log.

So if its not local OP integrity checking (cksum or similar against a original manifest) then my guess is its a check against the repository or something like that.

I currently have no experience of modifying installed OP plugins either downloaded by OP plugin manager or installed manually, so nothing to go on really.

[StefanCohen]

Hang on. I haven't touched my OP in like a year so I have a bunch of updates to go thru in order to verify this.

[gpread]

Hang on. I haven't touched my OP in like a year so I have a bunch of updates to go thru in order to verify this.

👍

[gpread]

Ah ha, seems like standard log level does not report all python validation issues. Seems like there is a formating issue in my edits, I found it in the log after setting debug level of logging for plugins and dashboard.

Now perhaps🙏 I just need to figure out exactly what it does not like and change it.

[StefanCohen]

It looks like you have mixed tabs and spaces in your edit. Python doesn't like that. Stick with four spaces instead of a tab and you are golden. ...And you have a pair of redundant paranthesis in there too. Fix that and it looks like it may work. My OP doesn't complain now but I can't verify that it works as I don't have a RockPI.

[gpread]

Yay! After fixing whitespace format issues (invisible death! lol) it works as expected/hoped.

Thanks for your assistance @StefanCohen, apologies if I triggered you to do some OP housekeeping you had been avoiding.

Attached is a modified __init__.py that now works for RockPi (presumably most RockChip CPUs/SOCs in fact) RockPiinit.py.txt

(I didn't change anything with parenthesis since I had duplicated syntax used for other platforms which surely works fine)

[StefanCohen]

Perfect. All that is left is to push a PR to the repo and you can put "Open Source Contributor" in your CV 😃

[gpread]

Perfect. All that is left is to push a PR to the repo and you can put "Open Source Contributor" in your CV 😃

I have created a fork, modified it and created a PR. I also tried to link it to this issue.

Since I am a noob to most of this, I have little idea if I did it successfully (meaning it will work easily for the maintainers) or if I did it the easiest/cleanest way. Therefore I am wide open to constructive feedback 😁

[gpread]

Just tested 1.19.7, I can confirm it seems to be all good. My CPU temp is now reporting correctly.

Thanks for the help and your good work @j7126 and @StefanCohen