Py3status: sysdata - improve cpu_temp

[fam4r]

Hi,

I noticed that sysdata module makes a call to sensors and searches for "CPU Temp" or "Core 0" in order to get temperature: see here.

But some temp modules (in my case k10temp and it87) are using "temp1"..."tempN" labels:

$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
temp1:        +12.9°C  (high = +70.0°C)
                       (crit = +90.0°C, hyst = +87.0°C)
...

it8721-isa-0290
Adapter: ISA adapter
...
temp1:        +30.0°C  (low  = -15.0°C, high = +51.0°C)  sensor = thermistor
temp2:        +25.0°C  (low  = +28.0°C, high = +108.0°C)  sensor = thermistor
temp3:       -128.0°C  (low  = -84.0°C, high = -30.0°C)  sensor = disabled
...

Is possible to add that labels in search function?
Thank you :)

[lasers]

Hi. I wish to deprecate {cpu_temp} from sysdata in favor of new module lm_sensors #1294.

The module lm_sensors is sitting on a wanted feature. In the meantime, please give lm_sensors a try without the auto threshold stuffs. If you see bugs, wanted features, or have some feedback about the new module, do let me know. Many thanks.

Use thresholds = [] in the config to turn the thresholds off or to use monochrome colors.

For colors, this config should work okay with most temperature sensors. Thanks. :+1:

lm_sensors {
    format_sensor = '[\?color=darkgray {name}] [\?color=input {input:g}]'
    thresholds = [(0, 'degraded'), (20, 'good'), (80, 'orange'), (90, 'bad')]
}

[lasers]

@fam4r Hi. Can we get an update? Did you try lm_sensors?

[fam4r]

Hi @lasers ,

Yes I tried the module, and.. it works! Both on my laptop and tower PCs (which respectively use "Core 0" and "temp1" labels).

I waited to answer because I didn't had time to make a screenshot to explain the following point.

I just want to let you know that imho output it's too verbose with the default configuration for format_sensor parameter ([\?color=darkgray {name}] [\?color=input.auto {input:g}]):

As you can see, even if I put it at first position, it uses the whole screen size.

I know that it depends on system, and of course I used less info, but I thought it was useful to let you know that.

Thank you!

[lasers]

I just want to let you know that imho output it's too verbose with the default configuration

That is my intent and oh my, you have some really cool sensors there. I don't want to hide information in default format because...

I know that it depends on system, and of course I used less info, but I thought it was useful to let you know that.

Yes. That's exactly it. I expect users to hide things afterward via the usage of sensors, chips and format. I feel it is the only way to let users understand how to use lm_sensors and what sensors they can use. I do same thing with hddtemp and nvidia_smi modules.

If you're only wanting certain sensors, then do try to use chip too so lm_sensors does not have to waste time parsing leftover chips on every cache_timeout. I said this because you have so many sensors + chips and I don't. :-) Your sensors definitely will look cool with auto per-sensor thresholds too one day.

Thank you for letting me know. Much appreciated. :-)

[fam4r]

That is my intent and oh my, you have some really cool sensors there. I don't want to hide information in default format because...

Yes, ok, that makes sense. You can maybe optimize parameters description and nothing else, because following explaination (with examples) is very clear!

If you're only wanting certain sensors, then do try to use chip too so lm_sensors does not have to waste time parsing leftover chips on every cache_timeout.

That's exactly what I did :+1:

Your sensors definitely will look cool with auto per-sensor thresholds too one day.

I tried to use default configuration for thresholds parameter (and not the one you posted in that issue):
thresholds = {'input.auto': True} but I'm getting following error in py3status log:

2018-03-29 16:41:08 WARNING Instance `lm_sensors _anon_module_6`, user method `lm_sensors` failed (TypeError) lm_sensors.py line 217.
2018-03-29 16:41:08 INFO Traceback
TypeError: threshold_get_color() got an unexpected keyword argument 'auto'
  File "/usr/lib/python3.6/site-packages/py3status/module.py", line 729, in run
    response = method()
  File "/home/famar/.config/i3status/module/lm_sensors.py", line 217, in lm_sensors
    _input, 'input.auto', auto=input_auto)

Otherwise if I use configuration posted in your comment above (thresholds = [(0, 'degraded'), (20, 'good'), (80, 'orange'), (90, 'bad')]) it works.

[lasers]

You don't see darkgray colors because I think you're still on 3.7. My screenshots are what it will look like out of the box... White chips with darkgray sensors. Nothing like yours. If you update to -git, you should be able to see it... or just replace darkgray with #a9a9a9.

You can't use the default configuration. If you want to.. You can try and copy py3.py too, then you could try the default non-optimized working auto thresholds. That's why I gave you manual colors. :-)

P.S. Can I have your sensors -u too to play around? See if I can make things better somehow.

[fam4r]

Ok @lasers

I switched to -git version and used your py3.py:

• darkgray works
• auto thresholds parameter is giving no errors (yeah!). I only see white chips: is that what you mean with "non-optimized"?

Here you are my laptop sensors -u.

Don't care the 0 temperature value for nouveau-pci-0100 sensor in temp1 label: is issuing in battery mode; when I use AC adapter is printing the real current temp.

Please wait for my tower PC sensors detail, I'll post it later (hope...)

[fam4r]

@lasers here you can find my tower pc sensors -u.

Thank you for your help and support!

[lasers]

white chips

If you're only seeing white chips, then check if you are whitelisting sensors in sensors. If you are, then you probably didn't whitelist any chips so their name (correctly) shows up on the bar. In that case, whitelist the chips too (to get rid of it... and to reduce work too).

non-optimized

thresholds = [(x[0], self._get_color(x[1])) for x in auto] in py3.py will convert bad, good, degraded, oran... etc to #ff000, #00ff00, #ffff00, #ff... etc repeatedly. This is something that could be converted once, then added to a cache dict to be used repeatedly.

I added one more color to auto for zero or less value. It'll be painted bad instead of good due to bad or unavailable value. It should look better for you now. :-)

Also, you have some placeholders that I don't have.. offset, type, and alarm. If you can test them too... just to see if it's outputting the values okay, then we'll know it's perfect.

[lasers]

@fam4r I added few more colors. Let me know what you think about it... and if things looks out of place. I'm not sure if you'll see all of them. You may notice lightgreen for min value and no color in vbat because it does not give more than input (former good color).

To solidify a well-working auto threshold that works with everything, I wouldn't mind more lm_sensors outputs (Not from yours... I haz yours). Also, I wonder if your lm_sensors is sound... because some min is more than max so maybe we need to check the numbers first to see if we need to sort the threshold backward for some sensors too.

[fam4r]

If you're only seeing white chips

My fault, I was using old placeholders in thresholds.

I added one more color to auto for zero or less value

It works!

Also, you have some placeholders that I don't have.. offset, type, and alarm. If you can test them too... just to see if it's outputting the values okay, then we'll know it's perfect.

Yes, I'll do! I don't see in code any placeholder: are they implemented?

---

Can you please tell me when it will be merged in upstream? I would like to use default py3.py source.

[lasers]

Yes, I'll do! I don't see in code any placeholder: are they implemented?

They're implemented directly via this.

Placeholders are retrieved directly from the sensors -u command for
format_chip and format_sensor without the prefixes. The list was
harvested once, simplified, and should not represent a full list.

I believe it would work okay. Most sensors will have input, max, min, etc... is which why I added them. Others like alarm, offset, hyp*, etc are all supported just the same, but won't be available in all sensors so I don't add them to avoid confusion about available placeholders. Also, 99.9% of time, people will want just input.

Can you please tell me when it will be merged in upstream? I would like to use default py3.py source.

I can't tell you when because I don't know the answer. It is up to others. Maybe in a year.

[lasers]

Closed via https://github.com/ultrabug/py3status/pull/1294.