Repository navigation
Output voltage is now wrong - off by about 220V #1973
Description
Something is underreportng the output voltage of my UPS - Im sure it used to be correct, when I set it up about 18 months ago...
See below - input voltage is 230V, output 10.
I'm using NUT Tools in Homeassistant Hassos.
- Homeassistant community addon Nut Tools.
NUT Tools config:
- config: []
driver: usbhid-ups
name: myups
port: auto
- Home assistant Yaml showing NUT sensor for correct Powerwalker device.
sensor:
UPS PowerWalker Device
- platform: nut
name: "PowerWalker VI USB 6500"
host: a0d7b954-nut
username: !secret nutups_user
password: !secret nutups_password
resources:
- battery.charge
- battery.runtime
- ups.load
- ups.status
- Homeassistant Integration showing data from the Nut Tools device - note seems to get the vendor and device type OK...
"integration_manifest": {
"domain": "nut",
"name": "Network UPS Tools (NUT)",
"codeowners": [
"@bdraco",
"@ollo69",
"@pestevez"
],
"config_flow": true,
"documentation": "https://www.home-assistant.io/integrations/nut",
"integration_type": "device",
"iot_class": "local_polling",
"loggers": [
"pynut2"
],
"requirements": [
"pynut2==2.1.2"
],
"zeroconf": [
"_nut._tcp.local."
],
"is_built_in": true
},
"data": {
"entry": {
"entry_id": "96848fcb81c918f44c4b066b12ebe4e1",
"version": 1,
"domain": "nut",
"title": "a0d7b954-nut:3493",
"data": {
"host": "a0d7b954-nut",
"port": 3493,
"password": "REDACTED",
"username": "REDACTED"
},
"options": {
"scan_interval": 60
},
"pref_disable_new_entities": false,
"pref_disable_polling": false,
"source": "user",
"unique_id": null,
"disabled_by": null
},
"nut_data": {
"ups_list": {
"myups": "Description unavailable"
},
"status": {
"battery.charge": "100",
"battery.charge.low": "10",
"battery.charge.warning": "20",
"battery.mfr.date": "1 ",
"battery.runtime": "2520",
"battery.runtime.low": "300",
"battery.type": "PbAcid",
"battery.voltage": "13.7",
"battery.voltage.nominal": "12",
"device.mfr": "1 ",
"device.model": " 650",
"device.serial": " ",
"device.type": "ups",
"driver.name": "usbhid-ups",
"driver.parameter.pollfreq": "30",
"driver.parameter.pollinterval": "2",
"driver.parameter.port": "auto",
"driver.parameter.synchronous": "auto",
"driver.version": "2.8.0",
"driver.version.data": "CyberPower HID 0.6",
"driver.version.internal": "0.47",
"driver.version.usb": "libusb-1.0.26 (API: 0x1000109)",
"input.frequency": "50.2",
"input.transfer.high": "290",
"input.transfer.low": "165",
"input.voltage": "241.3",
"input.voltage.nominal": "230",
"output.frequency": "50.2",
"output.voltage": "10.9",
"ups.beeper.status": "enabled",
"ups.delay.shutdown": "20",
"ups.delay.start": "30",
"ups.load": "12",
"ups.mfr": "1 ",
"ups.model": " 650",
"ups.productid": "0601",
"ups.realpower.nominal": "360",
"ups.serial": " ",
"ups.status": "OL",
"ups.timer.shutdown": "-60",
"ups.timer.start": "-60",
"ups.vendorid": "0764"
}
},......
I posted details in the HA Core - suggestion there that it may be a NUT tools/driver issue...hence posting here for ideas...
home-assistant/core#95157
Activity
jonandel commentedon Jun 25, 2023
I notice this in the addon log though - is it significant ?
jimklimov commentedon Jun 26, 2023
Hello, thanks for the post. It may be significant - one of the changes in NUT v2.8.0 release was about detecting malformed protocol information and amending that (stemming from issue #1024 and later issues and PRs on this matter; another related thread is #439). Looking at related key words, I think #1969 is quite similar to yours (although there the bogus value is larger and does not change over time).
It is possible that some of that did misfire and better amendments could have been made, so in the NUT master branch there were some fixes later, e.g. #1338 or #1497
jonandel commentedon Jul 1, 2023
thanks - yes I saw several that were similar - interestingly #1512 reports the same problem but with a slightly different product - - mine is a 650 with no LCD, rather than a 500 with LCD.
However, I see NUT is reporting same vendor and product ID's....
Dunuin commentedon Aug 5, 2023
Same problem here with my PowerWalker STL 800. Worked perfectly fine with latest NUT shipped with Debian 11, then I upgraded Debian to 12 and the output voltage directly dropped from ~235V to ~5V and is now fluctuating between 2V and 10V for 3 weeks.
jimklimov commentedon Aug 5, 2023
Cheers, thanks for the reports. Are any of you in position to try custom-building NUT to query the device with current codebase (to check if this was solved after 2.8.0 release)? This can be done from a build workspace without compromising the packaged installation, see https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
jonandel commentedon Aug 19, 2023
Im running HASOS, so will need to pull out a rPi and setup a test rig....give me a week or so - and Ill give it a go.
jonandel commentedon Aug 21, 2023
Jim, Ive fired up a rPi and the master branch built (2.8.0.1)... which build do you suggest I try ?
jimklimov commentedon Aug 21, 2023
I think
mastershould do it for tests. And then fiddle with driver options: what it does by default now, if it reports better again or still wrong as in 2.8.0 vs. 2.7.4; I think there was a toggle to disable the fix for presumed bad usb logical min/max encoding... can't remember quickly now - but should be in man pages (to see if that is the culprit).jonandel commentedon Aug 21, 2023
Erm OK. Remember though, I'm seeing the error in 2.8.0 pulled through in the Home Assistant add in an of about a month ago...but I don't know which version was used previously (which I don't think had the issue)....
Let me play around for a few days..and ill come back....
jimklimov commentedon Aug 22, 2023
Thanks! Note that Home Assistant builds generally include a version of NUT from packaging, e.g. Debian's 2.7.4 or 2.8.0 release plus their tweaks and backports over time. So even a 2.8.0 is a bit over a year old, and some fixes have landed since, and maybe something among these impacts the handling of your device.
Thinking of it, you might want to build a custom HA plugin with current NUT. Never did that myself, but there is a contributed post on the Wiki about it.
jonandel commentedon Aug 28, 2023
Hey Jim, Im not quite sure what Im doing frankly - but I think I have the mast branch installed and running. (although tools such as nut-scanner complain about a missing libusb...
anywhooo... when I probe with usb-hid-ups driver it seems to be communicating with the USB, and I get the below output.
Is this any use? What should I do next ?
jonandel commentedon Aug 28, 2023
PS, any ideas why this doesnt work ? Whats the subdriver ?
(I used the quoted subdriver thats 'discovered' too - no luck 'EXPLORE HID 0.2'
jimklimov commentedon Aug 29, 2023
Try
usbhid-upswithout the-x exploreflag (it discovers and reports known data points to help write new sub-drivers, but does not interpret them).At least, according to the initial report the device was handled with
usbhid-upswhich is about a different protocol than whatnutdrv_qxuses (that said, its subdriver would be like plaincyberpower- single token, without versions).jonandel commentedon Aug 31, 2023
ok done... not sure it particularly helpful... gives the same as nutdrv_qx...:
jonandel commentedon Aug 31, 2023
either way - it shows the current Master has the same problem as reported: ie
So probably confirmed its still a problem !
However, the
logmax is less thanstatments appear to apply to the reportID's corresponding to the output voltage (at least word 0x12) - so perhaps IS related to that in the code....jonandel commentedon Sep 3, 2023
@jimklimov Any ideas where to start looking ? I see the cyberpower driver was updated about a year ago - but I dont see those HID Report desciptors having changed.
I pulled the patest mast yesterday - as I see a few changes to the cyberpower-mib recently. I rebuilt, but still get the same incorrect reporting value for output voltage.
Also, in my original post, the sub-driver version is being reported as "driver.version.data": "CyberPower HID 0.6" - but current version here is 0.54 ... Where should I start looking ?
jimklimov commentedon Dec 18, 2024
PR #2718 is presumed to have fixed the broken CPS input/output voltage reports mentioned in this issue.
jonandel commentedon Dec 19, 2024
Great news ! thanks to all !
I have to admit I gave up after tinkering for a while, and packed away my rPi dev machine.
Now I only have to wait until Home Assistant Code team integrate these changes !
jimklimov commentedon Dec 19, 2024
There's a wiki article about building your own HA plugin... I don't use it yet, so can't help directly.