Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correct voltage and battery capacity for Opti-UPS 230VAC and/or 24VDC models #2089

Merged
merged 7 commits into from
Oct 6, 2023

Conversation

moonbuggy
Copy link
Contributor

The optiups driver only gave accurate voltage information with 120VAC models and assumed a 12V battery when calculating capacity.

There's an FV command that gives a (fixed) voltage that correlates with the voltage selection DIP switches on the back of the UPS, taking into account whether ti's a 120 or 240VAC model. So it's easy enough to do if (FV > 180) then voltage = voltage * 2, still using the NV and OV commands to pull the live in/out voltage data.

I suspect this would apply to all UPS using this protocol, under the assumption that the driver was developed on 120VAC devices where the scaling issue wasn't apparent. However, as I can only test on a PS-1440RM at 230VAC, I've only applied the change to "PS-*" series UPS through a new _pollv_ps[] struct.

It would make sense to apply the change by default via the _pollv[] struct, if it can be confirmed it doesn't break things for other models at 120VAC.

The battery capacity fix is applied globally., based on whether or not the battery voltage is greater than 20V.

I don't work with C very often, and due to my lack of familiarity there's some inefficiency with how the FV command is handled. It really should only need to be run once, during init. I have it being run on every update because I wasn't sure how best to set it during init and then get it for the updates. So that's not ideal, but it works and a few extra bytes each update doesn't seem like the end of the world. :) I'd be happy to fix the inefficiency if someone wants to point me in the right direction though.

drivers/optiups.c Outdated Show resolved Hide resolved
@jimklimov jimklimov added this to the 2.8.1 milestone Oct 4, 2023
@jimklimov
Copy link
Member

Thanks for the contribution, seems right to do this in the update loop - wall voltages can change over time...

One question posted above; another suggestion is to add a note to NEWS.adoc about this update. And perhaps an entry to data/driver.list.in (HCL) to mark the device model as known supported.

A post of data etc. dump for the DDL would also be welcome, see tools/nut-ddl-dump.sh :)

@moonbuggy
Copy link
Contributor Author

Sorry, I possibly didn't explain it well enough. 'FV' always seems to respond with the same fixed voltage, depending on how the DIP switches on the back of thing are set. So for my 230V model, I expect 'FV' will only ever be 200, 220, 230 or 240V, regardless of the actual line voltage.

At least, in my testing it changed from 240V to 230V when I flipped the relevant switch, and stayed at that value while the voltage reported by NV/OV happily wobbled around at 117-120V (before scaling, obviously). I assume it should behave the same for 120V models, just locked to the lower voltages.

Anyway, that's why it should ideally be requested during init rather than during an update. (Which is what the official Opti-UPS software does, ask for it at init and then just uses NV/OV after that.)

Here's the section from the manual about the DIP switches, just for clarity:
Opti-DIP-switches

I've just done a pull request with a data dump here: networkupstools/nut-ddl#39

And I've updated the device list.

Signed-off-by: moonbuggy <[email protected]>
@jimklimov
Copy link
Member

Thanks, seems good. If CI likes it too, will merge :)

@jimklimov jimklimov merged commit 3bf526e into networkupstools:master Oct 6, 2023
@jimklimov jimklimov added the documentation-protocol Submitted vendor-provided or user-discovered protocol information, or similar data (measurements...) label Oct 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation-protocol Submitted vendor-provided or user-discovered protocol information, or similar data (measurements...) enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants