add support for minuteman device PRO1500RT2U (a0a0) #1848
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JonGilmore
changed the title
|
Thanks for taking a look at this @jimklimov - just being honest here, this PR hasn't been tested yet (which is why it's marked as draft). I'm struggling to get nut installed from source on my debian machine. |
JonGilmore
force-pushed
the
minuteman-delta-a0a0
branch
from
06b5873
to
3c1d5c4
Compare
|
For testing, it may suffice to just build, not necessarily install in a "proper" fashion (see wiki link above) |
|
Hm, I'm a bit of a noob here, well out of my comfort zone, so excuse my moronic questions, lol. What driver am I supposed to use for testing? After a bit of stumbling around, I was able to get |
|
Here you are changing a HID subdriver that becomes part of Also On a side note, regarding not-finding a config file, which should probably be |
|
Thanks, that helps me get onto the next thing. It seems like I'm still not doing something correctly, I dont actually have the Am I correct to assume that the |
|
Yes, as long as it finds the prerequisites (e.g. The summary shown after |
|
Ah, great call. I had missed It does fail with the following permission issue, I assume that I've screwed something else up along the way: |
Update subdriver version along with content bump
JonGilmore
force-pushed
the
minuteman-delta-a0a0
branch
from
3c1d5c4
to
0e90cc9
Compare
|
That sounds like For the test, you can run it in dump mode (e.g. with Running as a non-root user however it may have issues accessing the devfs USB node for the device -- something that an installed and recognized |
|
Thanks so much for the help, feels like this is lookin better output |
|
Looks promising. Voltages at zero are not nice, but a lot of other data and
the status are there. You can also look at docs for generating a subdriver
with the explore mode, to maybe submit a new HID mapping (move minuteman
ID(s) there), or extend an existing one if just a few lines differ from
some `*-hid.c` file already defined.
|
|
@JonGilmore : should this PR be merged as at least an interim solution (some access for device now exists, even if imperfect), or do you intend to soon "explore" if an improved subdriver is possible (or have already done that) - and post a better PR? Just roughly - is there a better solution (or verdict that it is not low-hanging fruit) to expect as a matter of days, or better merge this PR to have something quickly, and wait for the best indefinitely? :) |
|
I'll let you decide how to handle it, but I'd love to get it merged as is to at least get it functional and I'll try to carve out some time later to dig into the subdriver. Unfortunately, I've had nearly no time lately so prioritize this. |
|
Okay then, hope you get around to it later - e.g. when you miss the voltages too much :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
took inspiration from #555
associated issue: #1849
General points
Described the changes in the PR submission or a separate issue, e.g.
known published or discovered protocols, applicable hardware (expected
compatible and actually tested/developed against), limitations, etc.
There may be multiple commits in the PR, aligned and commented with
a functional change. Notably, coding style changes better belong in a
separate PR, but certainly in a dedicated commit to simplify reviews
of "real" changes in the other commits. Similarly for typo fixes in
comments or text documents.
Frequent "underwater rocks" for driver addition/update PRs
Revised existing driver families and added a sub-driver if applicable
(
nutdrv_qx,usbhid-ups...) or added a brand new driver in the othercase.
Did not extend obsoleted drivers with new hardware support features
(notably
blazerand other single-device family drivers for Qx protocols,except the new
nutdrv_qxwhich should cover them all).For updated existing device drivers, bumped the
DRIVER_VERSIONmacroor its equivalent.
For USB devices (HID or not), revised that the driver uses unique
VID/PID combinations, or raised discussions when this is not the case
(several vendors do use same interface chips for unrelated protocols).
For new USB devices, built and committed the changes for the
scripts/upower/95-upower-hid.hwdbfileProposed NUT data mapping is aligned with existing
docs/nut-names.txtfile. If the device exposes useful data points not listed in the file, the
experimental.*namespace can be used as documented there, and discussionshould be raised on the NUT Developers mailing list to standardize the new
concept.
Updated
data/driver.list.inif applicable (new tested device info)Frequent "underwater rocks" for general C code PRs
structure layout and alignment in memory, endianness (layout of bytes and
bits in memory for multi-byte numeric types), or use of generic
intwherelanguage or libraries dictate the use of
size_t(orssize_tsometimes).Progress and errors are handled with
upsdebugx(),upslogx(),fatalx()and related methods, not with directprintf()orexit().Similarly, NUT helpers are used for error-checked memory allocation and
string operations (except where customized error handling is needed,
such as unlocking device ports, etc.)
Coding style (including whitespace for indentations) follows precedent
in the code of the file, and examples/guide in
docs/developers.txtfile.For newly added files, the
Makefile.amrecipes were updated and themake distchecktarget passes.General documentation updates
Updated
docs/acknowledgements.txt(for vendor-backed device support)Added or updated manual page information in
docs/man/*.txtfilesand corresponding recipe lists in
docs/man/Makefile.amfor new pagesPassed
make spellcheck, updated spell-checking dictionary in thedocs/nut.dictfile if needed (did not remove any words -- themakerule printout in case of changes suggests how to maintain it).
Additional work may be needed after posting this PR
Propose a PR for NUT DDL with detailed device data dumps from tests
against real hardware (the more models, the better).
Address NUT CI farm build failures for the PR: testing on numerous
platforms and toolkits can expose issues not seen on just one system.
the changed codebase.