comment puis-je réinitialiser les statistiques de la batterie du powermanager?


12

J'ai changé mes piles et les statistiques des piles du gestionnaire GNOME se sont faussées. Où seraient les fichiers contenant les statistiques de la batterie?

Réponses:


17

Edit: Ubuntu utilise désormais le gestionnaire de puissance UPower de freedesktop. Après avoir parcouru la source de UPower, il semble que la base de données persistante où l'historique est stocké est définie comme history-%s-%s.dat. J'ai cherché dans mon système de fichiers et les noms de mes bases de données sont:

./var/lib/upower/history-time-empty-DELL_KP4377-57-22096.dat
./var/lib/upower/history-time-full-DELL_KP4377-57-22096.dat
./var/lib/upower/history-charge-DELL_KP4377-57-22096.dat
./var/lib/upower/history-rate-DELL_KP4377-57-22096.dat

Vos noms de fichiers sera évidemment différent , mais ils devraient être dans le même répertoire ( /var/lib/upower/) quel que soit. Ces quatre fichiers, bien qu'ils soient ".dat", ne sont en réalité que des documents texte lisibles par l'homme avec l'historique. Je dirais que de sauvegarder ces fichiers, puis les supprimer soit ou supprimer leur contenu et vous devriez être bon d'aller! Faites-moi savoir comment cela fonctionne.

Réponse originale:

Bonne question. On pourrait penser que gnome-power-manager aurait son propre fichier journal quelque part pour le stocker - je ne trouve cependant rien de la sorte.

Il semble que la plupart des informations qu'il lit sur la batterie proviennent d'acpi via /proc/acpi/battery/BAT0/info(mon chemin est "BAT0" le vôtre peut être différent du vôtre) Par exemple, voici le mien:

present:                 yes
design capacity:         5200 mAh
last full capacity:      3665 mAh
battery technology:      rechargeable
design voltage:          11100 mV
design capacity warning: 520 mAh
design capacity low:     157 mAh
cycle count:          0
capacity granularity 1:  52 mAh
capacity granularity 2:  52 mAh
model number:            DELL KP4377
serial number:           22096
battery type:            LION
OEM info:                DP-SDI52

Mais à part le nombre de cycles et la dernière pleine capacité, il n'y a pas beaucoup d'informations d'historique ici, donc il doit y avoir un autre fichier quelque part que gnome-power-manager utilise pour les informations d'historique. Il est possible qu'au lieu de le stocker dans son propre fichier, il utilise une base de données plus grande que gnome utilise pour une variété de paramètres ... Je suppose qu'il est également possible que ACPI stocke également les informations d'historique quelque part, bien qu'une fois encore il n'y en ait pas. Il ne semble pas y avoir de documentation pour cela.

Si elles existent, vous pourriez obtenir un peu plus d'attention à votre question par des gens qui connaissent gnome-power-manager mieux si vous ajoutez des balises plus spécifiques, par exemple. "gnome-power-manager", "acpi", etc. Désolé, je ne peux pas vous aider beaucoup, bonne chance!


viens de voir ici, bugs.archlinux.org/task/16970 , que les fichiers étaient stockés en tant que fichiers .cvs dans ~ / .gnome2 / gnome-power-manager /, évidemment ils ne sont plus là mais au moins ça laisse entendre qu'ils pourraient toujours être des fichiers .cvs. De plus, l'affiche a découvert ces informations en demandant à #gnome sur irc.gnome.org, vous pouvez donc essayer de découvrir où se trouvent les fichiers.
adempewolff

Il est assez intéressant de noter que les informations sur la batterie de gnome-power manager sont désormais stockées dans une base de données persistante. Je me demande comment les graphiques de précision de la prévision de la durée de vie de la batterie sont produits.
viyyer

Mon erreur, Ubuntu utilise actuellement le gestionnaire d'alimentation UPower de freedesktop plutôt que le gestionnaire d'alimentation gnome, après avoir parcouru la source de UPower, je pense avoir trouvé la base de données d'historique persistante. Je mettrai à jour ma réponse avec les résultats.
adempewolff

1
aussi, pas particulièrement pertinent maintenant que nous avons trouvé les bases de données d'historique, mais j'avais tort que power-manager récupère les informations de / proc / acpi / battery / BAT0 / info, il semble en fait qu'elles proviennent de / sys / devices / LNXSYSTM: 00 / appareil: 00 / PNP0C0A: 00 / power_supply /
BAT0

Après avoir supprimé les fichiers, mon historique est toujours biaisé. Mon ordinateur portable meurt à environ 73%. Je sais que ma batterie est défectueuse mais pour l'instant j'ai vraiment besoin d'une tête avant qu'elle ne soit vide (environ 30 min). Avez-vous d'autres idées sur la façon de réinitialiser UPower (MATE Power Manager)?
dotnetCarpenter

4

Je viens d'essayer l'approche de suppression de fichiers. J'ai supposé que puisque upowerd était toujours en cours d'exécution, ces fichiers seraient automatiquement régénérés, mais ils ne l'étaient pas - ils n'étaient pas non plus immédiatement après le redémarrage.

Initialement, après la suppression de /var/lib/upower/*.dat, gnome-power-statistics a simplement fonctionné comme une fenêtre GUI vierge sans contenu, mais est revenue à son image habituelle après le redémarrage. Curieusement, il montrait quelques minutes d'historique de batterie depuis le redémarrage sans que rien n'ait recréé les fichiers de données / var / lib / upower, et je n'ai trouvé nulle part ailleurs dans le système de fichiers où il aurait pu stocker les données (il n'y avait aucun descripteur de fichier pour upowerd ou gnome-power-statistics pointant vers n'importe où sur le système de fichiers, juste des sockets du noyau).

Je suppose que quelque chose d'autre que upower doit avoir un journal à court terme de ces données, ce qui était affiché dans gnome-power-statistics. L'exécution de "upower -d" génère également des points d'historique pour le taux de charge et de décharge lorsque les fichiers de données n'existent pas. Il est donc probable qu'il puisse également accéder à la même source de données indépendante des fichiers d'historique / var / lib / upower. upowerd semble recréer les fichiers de données après une dizaine de minutes après la suppression, il est donc possible que ceux-ci soient nécessaires pour stocker des points de données sur une période plus longue.


1
Juste un additif: / sys / class / est power_supply un lien symbolique utile / sys / devices / LNXSYSTM: 00 / appareil: 00 / PNP0C0A: 00 / power_supply (comme dans le commentaire de adempewolff ci - dessus)
Harry Willis

Il peut simplement contenir les points de données en mémoire ou les écrire pour échanger de l'espace avant de les écrire sur le disque toutes les 10 minutes. Je ne vois pas vraiment pourquoi, mais je ne trouve aucun autre fichier dans les répertoires UPower ressemblant à un journal ...
adempewolff

1
De plus, étant donné les résultats de vos tests, je pense que la suppression des fichiers devrait répondre aux besoins de @ viyyer - cela supprimera tout l'historique de l'ancienne batterie qui gâcherait ses statistiques. Alternativement, il pourrait aller dans les fichiers et supprimer uniquement les points de données d'avant la nouvelle batterie.
adempewolff

Je viens de supprimer les .datfichiers et ils ont été régénérés (je ne sais pas si cela se produit immédiatement, mais ils sont là). Sur Ubuntu Mint 16.04
dotnetCarpenter

0

Harry, tu as raison. Vous ne vous souvenez pas qu'Ubuntu vous a demandé de brancher le chargeur avant l'installation? C'est parce qu'il prend un instantané de la capacité de la batterie. Si vous souhaitez réinitialiser le gestionnaire d'alimentation, je suppose que vous devrez réinstaller Ubuntu ou essayer un cycle d'alimentation. En d'autres termes, laissez votre batterie s'éteindre, puis allumez-la au même moment que vous branchez le chargeur et gardez-la sous tension jusqu'à ce qu'elle atteigne le 100%.


4
Je ne sais pas si je le crois. Je crois qu'il vous demande de brancher le chargeur avant l'installation, car le manque de batterie au milieu de l'installation, ou Dieu ne plaise au milieu du partitionnement, vous laisserait au mieux un Ubuntu inutilisable et au pire, ferait frire les autres tables de partitionnement des OS. .
adempewolff
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.