Based on cpu2 module, but use `sensors -j` and some json path walking to
better parse CPU temp and fan speeds. The output of `sensors -u` can
contain many duplicates of the same sensor name, but from different
sensor device paths.
Signed-off-by: SuperQ <superq@gmail.com>
* with newer versions of pi-hole, it is not possible
anymore to use the password hash for the API authentication.
Instead, one needs to use the dedicated API token for that.
In order to stay backwards compatible, and not break existing
bumblebee_status setups, the 'pwhash' parameter is still supported
(in case someone runs an outdated pi-hole version).
* the new pi-hole API endpoints do not allow to access the summary
endpoint without an API token. So, therefore '&auth=<api token>' was
added.
Fixed publicip bug arising from last PR review
Simplified ip change detection code
Added pause after location.reset() call to allow completion before query
util.location - change order of information providers as default was not returning geo coords
The logic for the critical/warning handling on the battery modules was
applied BEFORE the discharging-<pct> logic. This made it possible for
those discharging states to get applied over a critical/warning and
allow a theme to override the critical/warning colors with a state of
"discharging-10", for example.
This change moves that logic after the discharging state, so that it
will always "win" if critical or warning states are set.
This also adds the "discharging" battery state to the critical/warning
check so the state will apply if the battery is not on AC power, but
would return normal otherwise. Meaning, if the battery is "critical"
from a percentage check, but is plugged into power, the critical state
is removed.
This adds an option allowing you to specify
"taskwarrior.show_active=true" in your bar configuration and will
display the current, active task id and description on the status bar, but will show the
number of pending tasks if one isn't active.
This also adds the scrolling decorator, since task descriptions can be
quite long.
Added a second check for indications of possible change of public IP address since netifaces does not properly handle all Linux routing tables (ref: http://linux-ip.net/html/routing-tables.html) which can lead to changes being missed if only looking at defauilt route. Consequently an additional check for changes to the network interface names/numbers was added to further help in identifying potentially notable changes. Note that netifaces is no longer being maintained so the underlying issue with its handling of gateways is unlikely to be resolved (https://github.com/al45tair/netifaces). An alternative would be to use direct calls to the OS like 'ip route list table all' (note the difference to 'ip route list all') but this might lead to unpredicatble results between distributions/flavours so probably best to stick with a library for now. all') but this might lead to unpredicatble results between distributions/flavours so probably best to stick with a library for now.
Introduced time.sleep(2) following calls to util.location.reset() since it can take util.location a while to update following a call to .reset() which can cause calls to .location_info() to return unpredicatable/unuseful results.
Added location_info() to util/location API to return a dict of all location information. Updated modules/contrib/publicip to use that API. Changed modules/contrib/publicip refresh period back to 60 minutes. Changed /util/location API from 'country_name' back to 'name'
Added another API endpoint, Added options to display country name, country code, city name and lat/long coordinates, attempt to handle failure to fetch info from API endpoints cleanly
I run the same bumblebee-status configuration on my laptop and my
workstation. On my laptop, the upower module works fine: it says "ac"
when plugged in, charging, all that stuff is great.
But on my workstation, it's completely broken: it thinks there's a
battery (which is a mistake: there is no battery at all, apart maybe
from the CMOS battery, but that's not covered by upower), and it
thinks it's discharged, which makes a very noisy warning in the bar.
Now maybe there's something wrong with dbus, Debian, the kernel,
Linux, or some thing else in the stack. All I know is that
`self.power.get_display_device()` returns something like a valid
dbus object here and from there it confuses the heck out of the
module.
So this just adds a function to check if the actual device we're
talking about is actually present, and bails earlier otherwise.
Before: battery logo and "0% 00:00m!", all marked as critical ("red")
After: "ac" with the plugged in logo, not marked critical ("black")
