Created attachment 87756 [details] upowerd -v output Hello, UPower does not reads the charge information from my ups. It's a MGE (Eaton) protection center 675 usb. The ups is not defective, nut reads the informations correctly from it. With UPower, the state is always emty and percentage 0%. upower -d Device: /org/freedesktop/UPower/devices/ups_hiddev0 native-path: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/usbmisc/hiddev0 vendor: Eaton power supply: yes updated: Thu 01 Jan 1970 01:00:00 AM CET (1381952228 seconds ago) has history: yes has statistics: yes ups present: yes state: empty percentage: 0% Daemon: daemon-version: 0.9.22 on-battery: no on-low-battery: no lid-is-closed: no lid-is-present: no is-docked: yes I've attached the output of upowerd -v it seems to fail reading data from the ups at coldplug, then does not get data: Polling: /org/freedesktop/UPower/devices/ups_hiddev0 no data Please tell me if I can give any more helpful informations. Best regards.
> it seems to fail reading data from the ups at coldplug There doesn't seem to be any failures to run up_device_hid_get_all_data() in your logs, just getting more information out of the device. Can you try using hid-recorder to record data coming out of the device? A run of a couple of minutes where you would plug, unplug the UPS from the mains to simulate a power cut would be best. The hidraw device to use should be listed in the output of "udevadm info --export-db". This should allow us to reproduce the problem.
Created attachment 87936 [details] hid-recorder output
Hello, Here is the hid-recorder output. A few seconds after I unplugged the ups, the numbers showed as expected with upower -d Device: /org/freedesktop/UPower/devices/ups_hiddev0 native-path: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/usbmisc/hiddev0 vendor: Eaton power supply: yes updated: Mon 21 Oct 2013 06:45:19 PM CEST (3 seconds ago) has history: yes has statistics: yes ups present: yes state: discharging time to empty: 28.9 minutes percentage: 99% Daemon: daemon-version: 0.9.22 on-battery: yes on-low-battery: no lid-is-closed: no lid-is-present: no is-docked: yes Now I re-plugged it, the data is still show as expected: Device: /org/freedesktop/UPower/devices/ups_hiddev0 native-path: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/usbmisc/hiddev0 vendor: Eaton power supply: yes updated: Mon 21 Oct 2013 06:46:19 PM CEST (406 seconds ago) has history: yes has statistics: yes ups present: yes state: charging time to empty: 36.9 minutes percentage: 97% Daemon: daemon-version: 0.9.22 on-battery: no on-low-battery: no lid-is-closed: no lid-is-present: no is-docked: no I will check with the battery at 100% if the problem reappears.
ok so it seems the data is updated only when the ups is unplugged. After I plugged it, it stayed at 97% and the updated time did not refresh. (updated : Mon 21 Oct 2013 06:46:19 PM CEST (406 seconds ago)) After restarting the upower daemon, it's back to : Device: /org/freedesktop/UPower/devices/ups_hiddev0 native-path: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/usbmisc/hiddev0 vendor: Eaton power supply: yes updated: Thu 01 Jan 1970 01:00:00 AM CET (1382374944 seconds ago) has history: yes has statistics: yes ups present: yes state: empty percentage: 0%
I couldn't figure out what nuts does differently from UPower in terms of reading the data out of the device. I'm afraid that unless somebody with this device debugs the problem, it's going to languish in bugzilla...
I'm looking at that ATM, and basically all the values passed to up_device_hid_set_values() are set to 0
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/upower/upower/issues/30.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.